AWS में अत्यधिक उपलब्ध प्रणालियों के निर्माण के लिए विकल्प। काम में रुकावटों पर काबू पाना। भाग 1

यहां तक ​​कि अमेज़ॅन जैसे क्लाउड उद्योग राक्षसों में हार्डवेयर समस्याएं हैं। यूएस ईस्ट -1 डेटा सेंटर के काम में हालिया रुकावटों के कारण, यह लेख उपयोगी हो सकता है।

AWS में अत्यधिक उपलब्ध प्रणालियों के निर्माण के लिए विकल्प। ओवरएजिंग आउटेज

गलती सहिष्णुता सभी क्लाउड सिस्टम के लिए मुख्य विशेषताओं में से एक है। हर दिन, कई एप्लिकेशन इस सुविधा पर विचार किए बिना AWS पर डिज़ाइन और तैनात किए जाते हैं। इस व्यवहार के कारणों में तकनीकी अज्ञानता से लेकर AWS सेवाओं के हिस्से के रूप में एक पूर्ण उच्च उपलब्धता प्रणाली बनाने की उच्च लागत के लिए एक दोष-सहिष्णु प्रणाली को ठीक से कैसे डिज़ाइन किया जा सकता है। इस लेख में कई समाधानों पर प्रकाश डाला गया है जो प्रदाताओं के उपकरणों में रुकावटों को दूर करने में मदद करेगा और AWS बुनियादी ढांचे के भीतर अधिक उपयुक्त समाधान तैयार करेगा।
एक विशिष्ट इंटरनेट एप्लिकेशन की संरचना में निम्न स्तर होते हैं: डीएनएस, लोड बैलेंसर, वेब सर्वर, एप्लिकेशन सर्वर, डेटाबेस, कैश। आइए इस स्टैक को लें और उन मुख्य बिंदुओं पर विस्तार से विचार करें जिन्हें अत्यधिक सुलभ प्रणाली का निर्माण करते समय विचार किया जाना चाहिए:

• AWS में एक अत्यधिक उपलब्ध प्रणाली का निर्माण
• वेब सर्वर / एप्लिकेशन सर्वर स्तर पर उच्च उपलब्धता
• लोड संतुलन / डीएनएस स्तर पर उच्च उपलब्धता
• डेटाबेस स्तर पर उच्च उपलब्धता
• AWS उपलब्धता क्षेत्रों के बीच अत्यधिक उपलब्ध प्रणाली का निर्माण
• AWS क्षेत्रों के बीच अत्यधिक सस्ती प्रणाली का निर्माण
• विभिन्न क्लाउड और होस्टिंग प्रदाताओं के बीच अत्यधिक सुलभ प्रणाली का निर्माण

भाग २

वेब सर्वर / एप्लिकेशन सर्वर स्तर पर उच्च उपलब्धता

घटक को विफलता के एकल बिंदु (SPOF) से बाहर करने के लिए, EC2 वर्चुअल सर्वर के दो या अधिक इंस्टेंस पर वेब एप्लिकेशन चलाने के लिए आम बात है। यह समाधान एकल सर्वर का उपयोग करने की तुलना में उच्च दोष सहिष्णुता के लिए अनुमति देता है। एप्लिकेशन सर्वर और वेब सर्वर दोनों को स्टेटस चेकिंग और इसके बिना उपयोग करके कॉन्फ़िगर किया जा सकता है। स्वास्थ्य जांच का उपयोग करते हुए उच्च उपलब्धता प्रणालियों के लिए सबसे आम वास्तु समाधान निम्नलिखित हैं:




इस तरह की व्यवस्था बनाते समय ध्यान देने योग्य मुख्य बातें:

• चूंकि वर्तमान एडब्ल्यूएस इन्फ्रास्ट्रक्चर एप्लिकेशन स्तर पर मल्टीकास्ट प्रोटोकॉल का समर्थन नहीं करता है, इसलिए डेटा को नियमित यूनिकस्ट टीसीपी का उपयोग करके सिंक्रनाइज़ किया जाना चाहिए। उदाहरण के लिए, जावा अनुप्रयोगों के लिए, आप सर्वर के बीच डेटा को सिंक्रनाइज़ करने के लिए JGroups, टेराकोटा एनएएम या इसी तरह के सॉफ़्टवेयर का उपयोग कर सकते हैं। सरलतम मामले में, आप rsync का उपयोग करके एक-तरफ़ा सिंक्रनाइज़ेशन का उपयोग कर सकते हैं, एक अधिक सार्वभौमिक और विश्वसनीय समाधान नेटवर्क वितरित फ़ाइल सिस्टम जैसे कि ग्लस्टरएफएस का उपयोग करना है।
• उपयोगकर्ता डेटा और सत्र जानकारी संग्रहीत करने के लिए आप Memcached EC2, ElastiCache या Amazon DynamoDB का उपयोग कर सकते हैं। अधिक विश्वसनीयता के लिए, आप विभिन्न AWS उपलब्धता क्षेत्रों में ElastiCache क्लस्टर को तैनात कर सकते हैं।
• अत्यधिक महत्वपूर्ण प्रणालियों के लिए सर्वरों के बीच स्विच करने के लिए इलास्टिकआईपी का उपयोग करना अनुशंसित नहीं है, क्योंकि इस प्रक्रिया में दो मिनट तक लग सकते हैं।
• उपयोगकर्ता डेटा और सत्र को एक डेटाबेस में संग्रहीत किया जा सकता है। इस तंत्र का उपयोग सावधानी से करना आवश्यक है, डेटाबेस में पढ़ने / लिखने के संचालन के दौरान संभावित देरी का मूल्यांकन करना आवश्यक है।
• उपयोगकर्ता द्वारा डाउनलोड की गई फ़ाइलों और दस्तावेजों को नेटवर्क फ़ाइल सिस्टम जैसे कि एनएफएस, ग्लस्टर स्टोरेज पूल या अमेज़ॅन एस 3 पर संग्रहीत किया जाना चाहिए।
• यदि सत्र एकल रिपॉजिटरी, डेटाबेस या अन्य समान तंत्र के माध्यम से सिंक्रनाइज़ नहीं किए जाते हैं, तो सत्र कमिट की नीतियों को अमेज़न ईएलबी या रिवर्स प्रॉक्सी स्तर पर सक्षम किया जाना चाहिए। यह दृष्टिकोण उच्च उपलब्धता प्रदान करता है, लेकिन आवेदन स्तर पर गलती सहनशीलता प्रदान नहीं करता है।

लोड संतुलन / डीएनएस स्तर पर उच्च उपलब्धता

DNS / लोड बैलेंसिंग परत एक वेब अनुप्रयोग के लिए मुख्य प्रवेश बिंदु है। डीएनएस / एलबी स्तर पर एक अत्यधिक सुलभ प्रणाली के निर्माण के बिना जटिल क्लस्टर्स, एप्लिकेशन और डेटाबेस स्तर पर भारी प्रतिकृति वाले वेब फ़ार्म बनाने का कोई मतलब नहीं है। यदि लोड बैलेंसर विफलता का एक बिंदु है, तो इसकी विफलता पूरी प्रणाली को दुर्गम बना देगी। लोड बैलेंसर स्तर पर उच्च उपलब्धता प्रदान करने के लिए सबसे आम उपाय निम्नलिखित हैं:



1) उच्च उपलब्धता के लिए लोड बैलेंसर के रूप में अमेज़न इलास्टिक लोड बैलेंसर का उपयोग करना। अमेज़न ईएलबी स्वचालित रूप से कई ईसी 2 सर्वरों पर एप्लिकेशन लोड वितरित करता है। यह सेवा आवेदन की सामान्य गलती सहिष्णुता से अधिक हासिल करना संभव बनाती है, इससे धीरे-धीरे उन संसाधनों को बढ़ाना संभव हो जाता है जिनके बीच आने वाले ट्रैफ़िक की तीव्रता के आधार पर लोड वितरित किया जाता है। यह आपको कई हज़ार एक साथ कनेक्शन के लिए सेवा प्रदान करने की अनुमति देता है और साथ ही यह बढ़ते लोड के साथ लचीले ढंग से विस्तार कर सकता है। ईएलबी स्वाभाविक रूप से एक असफल-सुरक्षित इकाई है जो स्वतंत्र रूप से अपने काम में विफलताओं को ठीक कर सकती है। जब लोड बढ़ता है, तो अतिरिक्त ELB EC2 वर्चुअल मशीन स्वचालित रूप से ELB स्तर पर जुड़ जाती हैं। यह स्वचालित रूप से विफलता के एकल बिंदु के अस्तित्व को समाप्त कर देता है और पूरे लोड संतुलन तंत्र काम करना जारी रखता है, भले ही कुछ ईएलबी ईसी 2 वर्चुअल डिवाइस विफल हो जाएं। इसके अलावा, अमेज़ॅन ईएलबी स्वचालित रूप से उन सेवाओं की उपलब्धता को निर्धारित करता है जिनके बीच लोड को वितरित करना आवश्यक है और, समस्याओं के मामले में, स्वचालित रूप से उपलब्ध सर्वरों को अनुरोध भेजता है। अमेज़ॅन ईएलबी को राउंड रॉबिन के यादृच्छिक वितरण का उपयोग करके लोड संतुलन के लिए कॉन्फ़िगर किया जा सकता है, सेवाओं की स्थिति की जांच के बिना, और सत्र को सुरक्षित करने और स्थिति की जांच करने के लिए एक तंत्र का उपयोग कर। यदि सत्र सिंक्रनाइज़ेशन कार्यान्वित नहीं किया जाता है, तो सत्र पिनिंग का उपयोग भी यह सुनिश्चित नहीं कर सकता है कि सर्वर के विफल होने पर कोई अनुप्रयोग त्रुटियां नहीं हैं और उपयोगकर्ता किसी उपलब्ध सर्वर पर पुनर्निर्देशित हैं।

2) कभी-कभी अनुप्रयोगों की आवश्यकता होती है:
- कॉम्प्लेक्स लोड कैश करने की क्षमता के साथ संतुलन (वार्निश)
- लोड संतुलन एल्गोरिदम का उपयोग:
- न्यूनतम कनेक्शन - कम सक्रिय कनेक्शन वाले सर्वर अधिक अनुरोध प्राप्त करते हैं
- कम सक्रिय कनेक्शन और अधिक शक्ति वाले भारित कम से कम कनेक्शन वाले सर्वर से अधिक अनुरोध प्राप्त होते हैं
- स्रोत द्वारा वितरण (गंतव्य हैश शेड्यूलिंग)
- प्राप्तकर्ता द्वारा वितरण (स्रोत हैश शेड्यूलिंग)
- स्थान और न्यूनतम कनेक्शन के आधार पर वितरण (स्थानीयता-आधारित कम से कम कनेक्शन निर्धारण) - अधिक अनुरोध कम सक्रिय कनेक्शन वाले सर्वरों द्वारा प्राप्त किए जाएंगे, प्राप्तकर्ताओं के आईपी पते को ध्यान में रखते हुए।
- लोड के बड़े अल्पकालिक विस्फोट पर सुनिश्चित संचालन
- लोड बैलेंसर पर एक निश्चित आईपी पते की उपस्थिति

उपरोक्त सभी मामलों में, Amazom ELB का उपयोग उपयुक्त नहीं है। थर्ड-पार्टी बैलेन्कर्स या रिवर्स प्रॉक्सीज़ का उपयोग करना बेहतर होता है, जैसे: नेग्नेक्स, ज़ीउस, हैप्रोक्सी, वार्निश। लेकिन विफलता के एक बिंदु की अनुपस्थिति को सुनिश्चित करना आवश्यक है, इस समस्या का सबसे सरल समाधान कई बैलेन्सर का उपयोग करना है। ज़ीउस रिवर्स प्रॉक्सी पहले से ही एक क्लस्टर में काम करने के लिए अंतर्निहित कार्यक्षमता है, अन्य सेवाओं के लिए राउंड रॉबिन डीएनएस राउंड-रॉबिन वितरण का उपयोग करना आवश्यक है। आइए इस तंत्र को अधिक विस्तार से देखें, लेकिन पहले हम विश्वसनीय एडब्ल्यूएस लोड संतुलन प्रणाली का निर्माण करते समय विचार करने के लिए कुछ मुख्य बिंदुओं को परिभाषित करेंगे:

• AWS में उच्च उपलब्धता प्रदान करने के लिए कई Nginx या HAproxy सेवाओं को कॉन्फ़िगर किया जा सकता है, ये सेवाएँ उपलब्ध सर्वर के बीच सेवा की उपलब्धता और वितरण का निर्धारण कर सकती हैं
• यदि आवेदन राज्य उपलब्धता की जाँच का समर्थन नहीं करता है, तो नगीनेक्स या HAproxy को साइकल को वितरित करने के लिए कॉन्फ़िगर किया जा सकता है। इसके अलावा, ये सेवाएं सत्र पिनिंग तंत्र का उपयोग करके काम का समर्थन करती हैं, लेकिन यदि सत्र सिंक्रनाइज़ेशन को ठीक से सुनिश्चित नहीं किया जाता है, तो यह गारंटी नहीं देता है कि एक सर्वर के विफल होने पर आवेदन स्तर पर कोई त्रुटि नहीं है।
• ऊर्ध्वाधर स्केलिंग के लोड बैलेन्सर की क्षैतिज स्केलिंग। क्षैतिज स्केलिंग व्यक्तिगत मशीनों की संख्या को बढ़ाता है जो संतुलन कार्य करते हैं, विफलता के एकल बिंदु के अस्तित्व को समाप्त करते हैं। Nginx और HAproxy के रूप में इस तरह के लोड बैलेंसरों को स्केल करने के लिए, आपको अपनी स्वयं की स्क्रिप्ट और सिस्टम छवियों को विकसित करने की आवश्यकता है, स्केलिंग के लिए अमेज़ॅन ऑटोस्केलिंग का उपयोग करना इस मामले में अनुशंसित नहीं है।
• बैलेंसर सर्वर की उपलब्धता का निर्धारण करने के लिए, आप अमेज़ॅन क्लाउडवॉच मॉनिटरिंग सिस्टम या थर्ड-पार्टी मॉनिटरिंग सेवाओं, जैसे कि नगिओस, ज़ैबिक्स, इन्सिंगा का उपयोग कर सकते हैं, और यदि कोई सर्वर अनुपलब्ध है, तो बैलेंसर के लिए एक नया सर्वर इंस्टेंस शुरू करने के लिए EC2 को नियंत्रित करने के लिए स्क्रिप्ट और कमांड लाइन क्षमताओं का उपयोग करें। ।

अब चलिए उस स्तर पर चर्चा करते हैं जो बैलेंसर - डीएनएस से ऊपर है। अमेज़ॅन रूट 53 एक अत्यधिक उपलब्ध, विश्वसनीय और स्केलेबल DNS सेवा है। यह सेवा प्रभावी रूप से सभी अमेज़ॅन सेवाओं जैसे ईसी 2, एस 3, ईएलबी के साथ-साथ एडब्ल्यूएस बुनियादी ढांचे के बाहर उपयोगकर्ता अनुरोधों को वितरित कर सकती है। रूट 53 अनिवार्य रूप से एक असफल-सुरक्षित DNS प्रबंधित सर्वर है और इसे कमांड लाइन इंटरफ़ेस या वेब कंसोल के माध्यम से कॉन्फ़िगर किया जा सकता है। सेवा भार के चक्रीय और वजन वितरण दोनों का समर्थन करती है और बैलेंसर में शामिल व्यक्तिगत ईसी 2 सर्वरों के साथ-साथ अमेज़ॅन ईएलबी के लिए अनुरोध वितरित कर सकती है। परिपत्र वितरण का उपयोग करते समय, सेवा की उपलब्धता की जांच करना और उपलब्ध सर्वरों पर अनुरोध स्विच करना काम नहीं करता है और इसे आवेदन स्तर पर ले जाना चाहिए।

डेटाबेस स्तर पर उच्च उपलब्धता

डेटा किसी भी एप्लिकेशन का सबसे मूल्यवान हिस्सा है और डेटाबेस स्तर पर उच्च उपलब्धता को डिजाइन करना किसी भी अत्यधिक सुलभ प्रणाली में सर्वोच्च प्राथमिकता है। डेटाबेस स्तर पर विफलता के एक बिंदु को समाप्त करने के लिए, उनके बीच डेटा प्रतिकृति के साथ कई डेटाबेस सर्वर का उपयोग करना आम बात है। यह या तो एक क्लस्टर का उपयोग कर सकता है या एक मास्टर दास का उपयोग कर सकता है। आइए AWS के ढांचे में इस समस्या के सबसे लोकप्रिय समाधान देखें:



1) मास्टर-दास प्रतिकृति का उपयोग करना।
हम एक ईसी 2 सर्वर को प्राथमिक (मास्टर) के रूप में और एक या अधिक को माध्यमिक सर्वर (दास) के रूप में उपयोग कर सकते हैं। यदि ये सर्वर सार्वजनिक क्लाउड में हैं, तो आपको ElastcIP का उपयोग करने की आवश्यकता है, लेकिन यदि आप एक निजी क्लाउड (VPC) का उपयोग करते हैं, तो सर्वर के बीच पहुँच निजी IP पतों के माध्यम से किया जा सकता है। इस सर्वर मोड में, डेटाबेस एसिंक्रोनस प्रतिकृति का उपयोग कर सकते हैं। जब मुख्य डेटाबेस सर्वर विफल हो जाता है, तो हम अपनी स्वयं की लिपियों का उपयोग करके माध्यमिक सर्वर को मास्टर मोड में बदल सकते हैं, जिससे उच्च उपलब्धता सुनिश्चित होती है। हम सक्रिय-से-सक्रिय मोड में या सक्रिय-से-निष्क्रिय मोड में सर्वर के बीच प्रतिकृति शुरू कर सकते हैं। पहले मामले में, संचालन लिखना, मध्यवर्ती लिखना और पढ़ना संचालन प्राथमिक सर्वर पर किया जाना चाहिए, और पढ़ने के संचालन को माध्यमिक सर्वर पर किया जाना चाहिए। दूसरे मामले में, सभी पढ़ने और लिखने का संचालन केवल प्राथमिक सर्वर पर, और माध्यमिक सर्वर पर ही किया जाना चाहिए, यदि प्राथमिक सर्वर मास्टर मोड में स्विच होने के बाद प्राथमिक सर्वर अनुपलब्ध है। डिस्क स्तर पर विश्वसनीयता और स्थिरता सुनिश्चित करने के लिए ईसी 2 डेटाबेस सर्वरों के लिए ईबीएस छवियों का उपयोग करने की सिफारिश की गई है। अतिरिक्त प्रदर्शन और डेटा अखंडता प्रदान करने के लिए, आप AWS के भीतर विभिन्न RAID विकल्पों के साथ EC2 डेटाबेस सर्वर को कॉन्फ़िगर कर सकते हैं।

2) MySQL NDBCluster
हम क्लस्टर बनाने के लिए डेटा और एक प्रबंध MySQL सर्वर के लिए दो या अधिक MySQL EC2 सर्वरों को SQLD और डेटा नोड के रूप में कॉन्फ़िगर कर सकते हैं। एक क्लस्टर में सभी डेटा नोड एक दूसरे के साथ डेटा को सिंक्रनाइज़ करने के लिए अतुल्यकालिक प्रतिकृति का उपयोग कर सकते हैं। सभी डेटा संग्रहण नोड्स के बीच पढ़ने और लिखने के संचालन को एक साथ वितरित किया जा सकता है। जब क्लस्टर में स्टोरेज नोड्स में से एक विफल हो जाता है, तो दूसरा सक्रिय हो जाता है और आने वाले सभी अनुरोधों को संसाधित करता है। यदि एक सार्वजनिक क्लाउड का उपयोग किया जाता है, तो क्लस्टर में प्रत्येक सर्वर के लिए ElasticIP पते की आवश्यकता होती है; यदि एक निजी क्लाउड का उपयोग किया जाता है, तो आंतरिक IP पते का उपयोग किया जा सकता है। डिस्क स्तर पर विश्वसनीयता और स्थिरता सुनिश्चित करने के लिए ईसी 2 डेटाबेस सर्वरों के लिए ईबीएस छवियों का उपयोग करने की सिफारिश की गई है। अतिरिक्त प्रदर्शन और डेटा अखंडता प्रदान करने के लिए, आप AWS के भीतर विभिन्न RAID विकल्पों के साथ EC2 डेटाबेस सर्वर को कॉन्फ़िगर कर सकते हैं।

3) आरडीएस के साथ उपलब्धता क्षेत्रों का उपयोग करना
यदि हम डेटाबेस स्तर पर Amazon RDS MySQL का उपयोग करते हैं, तो हम एक उपलब्धता क्षेत्र में एक मास्टर सर्वर और दूसरे उपलब्धता क्षेत्र में एक हॉट स्टैंडबाय सर्वर बना सकते हैं। इसके अतिरिक्त, हम कई एक्सेस जोन में कई सेकेंडरी रेप्लिका सर्वर रखने के लिए मॉडेम करते हैं। प्राथमिक और माध्यमिक आरडीएस नोड्स आपस में सिंक्रोनस डेटा प्रतिकृति का उपयोग कर सकते हैं। रेप्लिका सर्वर एसिंक्रोनस प्रतिकृति का उपयोग करता है। जब मास्टर RDS सर्वर अनुपलब्ध है, तो हॉट स्टैंडबाय कुछ ही मिनटों में स्वचालित रूप से उसी पते पर उपलब्ध हो जाता है। सभी लिखने, मध्यवर्ती पढ़ने और लिखने के संचालन को मास्टर सर्वर पर किया जाना चाहिए, रीड ऑपरेशन को रीड रेप्लिका सर्वर पर किया जा सकता है। सभी RDS सेवाएँ EBS छवियों का उपयोग करती हैं। इसके अलावा, आरडीएस सेवा स्वचालित बैकअप प्रदान करती है और इसके साथ आप एक विशिष्ट बिंदु से डेटा को पुनर्स्थापित कर सकते हैं, साथ ही साथ आरडीएस एक निजी क्लाउड में काम कर सकते हैं।

शेष वस्तुओं पर दूसरे भाग में चर्चा की जाएगी:

• AWS उपलब्धता क्षेत्रों के बीच अत्यधिक उपलब्ध प्रणाली का निर्माण
• AWS क्षेत्रों के बीच अत्यधिक सस्ती प्रणाली का निर्माण
• विभिन्न क्लाउड और होस्टिंग प्रदाताओं के बीच अत्यधिक सुलभ प्रणाली का निर्माण

मूल लेख: harish11g.blogspot.in/2012/06/aws-high-avucation-outage.html
पोस्ट करनेवाले: हरीश गणेशन