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

इस भाग में, हम AWS के आधार पर अत्यधिक उपलब्ध प्रणालियों के निर्माण के लिए निम्नलिखित विकल्पों पर विचार करेंगे:

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

पहला भाग यहाँ है ।

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


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

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

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

AWS एंबेडेड इकाइयों का उपयोग कर एक अत्यधिक उपलब्ध प्रणाली डिजाइनिंग:

• वस्तु और फ़ाइल भंडारण के लिए अमेज़न S3
• सामग्री वितरण प्रणाली के लिए Amazon CloudFront
• लोड संतुलन के लिए अमेज़न ईएलबी
• Amazon AutoScaling स्वचालित रूप से EC2 को स्केल करता है
• निगरानी के लिए Amazon CloudWatch
• संदेश सेवा के लिए अमेज़न SNS और SQS

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

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

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

• अनुप्रयोग प्रवासन - AWS क्षेत्रों के बीच एक अनुप्रयोग वातावरण को स्थानांतरित करने की क्षमता
• डेटा सिंक्रनाइज़ेशन - दो या अधिक क्षेत्रों के बीच वास्तविक समय के डेटा को माइग्रेट करने की क्षमता
• नेटवर्क ट्रैफ़िक - क्षेत्रों के बीच नेटवर्क ट्रैफ़िक के प्रवाह को नियंत्रित करने की क्षमता

निम्नलिखित आरेख कई क्षेत्रों में एक सरल, अत्यधिक सुलभ प्रणाली दिखाता है।

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

• डेटाबेस: MySQL मास्टर-स्लेव प्रतिकृति, SQL सर्वर 2012 HADR, SQL सर्वर 2008, प्रोग्रामेटिक RDS
• फ़ाइल संग्रहण: GlusterFS वितरित नेटवर्क फ़ाइल सिस्टम, S3 प्रतिकृति
• कैश: चूंकि क्षेत्रों के बीच कैश के लिए प्रतिकृति ज्यादातर मामलों में महंगी है, इसलिए प्रत्येक क्षेत्र में एक अलग गर्म कैश रखने की सिफारिश की जाती है।
• उच्च गति फ़ाइल स्थानांतरण के लिए Aspera जैसी सेवाओं की सिफारिश की जाती है।

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

• वर्तमान में, अंतर्निहित ईएलबी लोड बैलेंसर क्षेत्रों के बीच लोड संतुलन का समर्थन नहीं करता है, इसलिए यह क्षेत्रों के बीच यातायात को वितरित करने के लिए उपयुक्त नहीं है
• इस उद्देश्य के लिए रिवर्स प्रॉक्सी और लोड बैलेन्सर (जैसे हाप्रोसी, नग्नेक्स) उपयुक्त हैं। हालांकि, यदि पूरा क्षेत्र अनुपलब्ध है, तो लोड वितरित करने वाले सर्वर उपलब्ध नहीं हो सकते हैं या अन्य क्षेत्रों में स्थित सर्वर नहीं देख सकते हैं, जिससे एप्लिकेशन त्रुटियां हो सकती हैं।
• DNS स्तर पर वितरण प्रबंधन का उपयोग करने के लिए एक सामान्य अभ्यास है। UltraDNS, Akamai या मार्ग 53 LBR (रूटिंग) जैसी सेवाओं का उपयोग करना
• प्रतिक्रिया समय के आधार पर) आप क्षेत्रों के बीच यातायात का पुनर्वितरण कर सकते हैं
• Amazon Route53 LBR का उपयोग करके, आप विभिन्न क्षेत्रों के बीच ट्रैफ़िक को स्विच कर सकते हैं और कम रिस्पांस टाइम वाले क्षेत्र में उपयोगकर्ता के अनुरोधों को पुनर्निर्देशित कर सकते हैं। मार्ग 53 के लिए समापन बिंदु के रूप में, सर्वर का सार्वजनिक आईपी पता, इलास्टिक आईपी, ईएलबी आईपी का उपयोग किया जा सकता है।
• अमेज़ॅन इलास्टिक आईपी विभिन्न क्षेत्रों के बीच स्विच नहीं कर सकता है। ऐसी सेवाओं, एफ़टीपी और अन्य आईपी-उन्मुख सेवाएं जो अनुप्रयोगों के बीच संचार के लिए होती हैं, उन्हें आईपी पते के बजाय डोमेन नाम का उपयोग करने के लिए पुन: कॉन्फ़िगर किया जाना चाहिए; यह एक महत्वपूर्ण बिंदु है जिसे कई क्षेत्रों का उपयोग करते समय विचार किया जाना चाहिए

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

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

• बड़े उद्यम जो पहले से ही अपने पैसे का बड़ा हिस्सा अपने डेटा केंद्रों के निर्माण या प्रदाताओं के डेटा केंद्रों में भौतिक उपकरणों को किराए पर देने में लगाते हैं, मुख्य डेटा केंद्र के साथ समस्याओं के मामले में आपदा वसूली के लिए AWS का उपयोग करना चाहते हैं। ऐसे उद्यम जिनके पास पहले से ही अपने निजी बादल हैं, जो यूकेलिप्टस, ओपन स्टैक, क्लाउड स्टैक या vCloud के आधार पर अपने स्वयं के डेटा केंद्रों में स्थापित हैं और आपदा वसूली के लिए AWS का उपयोग करना चाहते हैं। यूकेलिप्टस में अधिकतम एडब्ल्यूएस संगतता है, क्योंकि इसमें एपीआई स्तर की संगतता है। अधिकांश वर्कलोड को AWS और नीलगिरी के बीच एकीकृत किया जा सकता है। उदाहरण के लिए, मान लीजिए कि एक उद्यम के पास Eucalyptus के निजी क्लाउड में AWS API का उपयोग करके Amazon EC2 के लिए विकसित स्क्रिप्ट्स का एक सेट है, यदि दोष सहिष्णुता की आवश्यकता है तो यह क्लाउड आसानी से AWS में माइग्रेट कर सकता है। यदि कंपनी ओपनस्टैक या एक निजी क्लाउड के किसी अन्य प्रदाता का उपयोग करती है, तो स्क्रिप्ट को फिर से लिखना होगा, नए वातावरण में काम करने में सक्षम होने के लिए अनुकूलित होना चाहिए। यह जटिल प्रणालियों के लिए आर्थिक रूप से नुकसानदेह हो सकता है।
• स्केलेबिलिटी या उच्च उपलब्धता के लिए उपयुक्त नहीं के रूप में उनके बुनियादी ढांचे को देखने वाली कंपनियां आपदा वसूली के लिए एडब्ल्यूएस को अपनी प्राथमिक साइट और उनके डेटा केंद्रों के रूप में उपयोग कर सकती हैं।
• वे कंपनियां जो अपने वर्तमान सार्वजनिक क्लाउड प्रदाताओं की स्थिरता और विश्वसनीयता से संतुष्ट नहीं हैं, वे बहुत सारे क्लाउड संरचना का उपयोग करना चाह सकती हैं। यह मामला अभी सबसे दुर्लभ है, लेकिन भविष्य में यह प्रमुख हो सकता है।

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

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

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

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