मैं Amazon EC2 पर एक स्केलेबल, विश्वसनीय हाइप्रोक्सी क्लस्टर कैसे तैनात कर सकता हूं?

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

ऐसा लगता है कि हैप्रोक्सी नोड्स के सामने एक दिल की धड़कन की परत होने की संभावना होगी, संभवतः आईपीवीएस का उपयोग करके, लेकिन ईसी 2 क्लस्टर परिवर्तनों के रूप में कॉन्फ़िगरेशन परिवर्तन को संभालना (या तो जानबूझकर परिवर्तन के माध्यम से, जैसे विस्तार, या अनजाने में, जैसे कि हारना। EC2 नोड) गैर-तुच्छ लगता है।

अधिमानतः समाधान कम से कम दो उपलब्धता क्षेत्र होगा।

Qs के जवाब में: नहीं, सत्र चिपचिपा नहीं है। और हाँ, हमें एसएसएल की आवश्यकता होगी, लेकिन यह सिद्धांत पूरी तरह से एक और सेटअप द्वारा संभाला जा सकता है - हम एसएसएल ट्रैफिक को गैर-एसएसएल ट्रैफिक से अलग स्थान पर निर्देशित करने में सक्षम हैं।

— डॉन मैकएस्किल
स्रोत

मैं इस बात पर शोध कर रहा हूं कि सॉफ्टवेयर के नए संस्करण में जाने वाले ट्रैफ़िक के धीरे-धीरे बढ़ते प्रतिशत के साथ कैनरी डिप्लॉय कैसे करें, और मैं इस बारे में अति-उत्सुक हूं कि आपने इसे कहां समाप्त किया। क्या आपने जेसपर के किसी भी सुझाव की कोशिश की थी?

— इयान

जवाबों:

ठीक है, मैंने खुद स्मॉगमग के स्तरों पर ट्रैफिक के साथ एक एडब्ल्यूएस लोड बैलेंसिंग समाधान का निर्माण नहीं किया है, लेकिन सिर्फ सिद्धांत और एडब्ल्यूएस की सेवाओं के बारे में सोचकर, कुछ विचारों को ध्यान में रखा जाता है।

मूल प्रश्न कुछ चीजों को याद कर रहा है जो लोड संतुलन डिजाइन को प्रभावित करते हैं:

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

मैं इस बात के परिप्रेक्ष्य से उत्तर दे रहा हूं कि कैसे लोड बैलेंसिंग लेयर को अत्यधिक उपलब्ध रखा जाए। आवेदन सर्वरों को रखना एचए सिर्फ आपके एल 7 लोड बैलेन्कर्स में निर्मित स्वास्थ्य जांच के साथ किया जाता है।

ठीक है, कुछ विचारों को काम करना चाहिए:

1) "AWS रास्ता":

पहली परत, बहुत सामने, एल 4 (टीसीपी / आईपी) मोड में ईएलबी का उपयोग करें।
दूसरी परत, चुनाव के अपने L7 लोड बैलेंसर (nginx, HAProxy, Apache आदि) के साथ EC2 उदाहरणों का उपयोग करें।

लाभ / विचार: L7 लोड बैलेंसर्स काफी सरल EC2 AMI के हो सकते हैं, सभी एक ही AMI से क्लोन किए जाते हैं और समान कॉन्फ़िगरेशन का उपयोग करते हैं। इस प्रकार अमेज़ॅन के उपकरण सभी एचए की जरूरतों को संभाल सकते हैं: ईएलबी एल 7 लोड बैलेंसरों की निगरानी करता है। यदि कोई L7 LB मर जाता है या अनुत्तरदायी हो जाता है, तो ELB और क्लाउडवॉच एक साथ एक नया उदाहरण स्वचालित रूप से स्पॉन करते हैं और इसे ELB पूल में लाते हैं।

2) "निगरानी के साथ DNS राउंड रॉबिन:"

आईपी पते के एक जोड़े पर एक मोटे अनाज वितरण वितरण पाने के लिए बुनियादी डीएनएस दौर रॉबिन का उपयोग करें। मान लीजिए कि आप अपनी साइट के लिए 3 आईपी पते प्रकाशित करते हैं।
इन 3 IP में से प्रत्येक एक AWS इलास्टिक IP एड्रेस (EIA) है, जो आपकी पसंद के L7 लोड बैलेंसर के साथ EC2 उदाहरण के लिए बाध्य है।
यदि EC2 L7 LB की मृत्यु हो जाती है, तो एक आज्ञाकारी उपयोगकर्ता एजेंट (ब्राउज़र) को इसके बजाय अन्य IP में से किसी एक का उपयोग करना चाहिए ।
बाहरी निगरानी सर्वर सेट करें। प्रत्येक 3 EIP पर नजर रखें। यदि कोई अनुत्तरदायी हो जाता है, तो EIP को अन्य EC2 उदाहरण पर ले जाने के लिए AWS के कमांड लाइन टूल और कुछ स्क्रिप्टिंग का उपयोग करें।

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

3) हा सर्वरों के जोड़े के लिए DNS आरआर:

मूल रूप से यह डॉन की खुद की जोड़ी के बीच सरल दिल की धड़कन का सुझाव है, लेकिन कई आईपी पते के लिए सरलीकृत है।

DNS आरआर का उपयोग करके, सेवा के लिए कई आईपी पते प्रकाशित करें। ऊपर दिए गए उदाहरण के बाद, मान लें कि आप 3 IP प्रकाशित करते हैं।
इनमें से प्रत्येक IP EC2 सर्वर की एक जोड़ी में जाता है, इसलिए कुल 6 EC2 उदाहरण हैं।
इनमें से प्रत्येक जोड़ी 1 आईपी पते को सक्रिय / निष्क्रिय विन्यास में रखने के लिए एडब्ल्यूएस टूल के साथ मिलकर हार्टबीट या एक और एचए समाधान का उपयोग करती है।
प्रत्येक EC2 उदाहरण में आपका L7 लोड बैलेंसर स्थापित है।

लाभ / विचार: AWS के पूरी तरह से वर्चुअलाइज्ड वातावरण में यह वास्तव में L4 सेवाओं और विफलता मोड के बारे में तर्क करना आसान नहीं है। समान सर्वरों के एक जोड़े को सरलीकृत करके केवल 1 आईपी पते को जीवित रखने पर, यह तर्क और परीक्षण के लिए सरल हो जाता है।

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

— जेस्पर एम
स्रोत

इसलिए मैं # 1 से प्यार करता हूं, यह वह दिशा है जो मैं झुक रहा हूं, लेकिन अभी भी कुछ दिलचस्प गच हैं - जिनमें से कम से कम यह नहीं है कि ईएलबी एक पूरे AZ को बहुत अच्छी तरह से विफल नहीं करता है (कुछ ऐसा जो हम पहले से ही कर चुके हैं। )। आसान, लेकिन yucky, 'समाधान' वहाँ है AZB पार करने के लिए कॉन्फ़िगर ELB के पीछे haproxies है (शायद एक और AZ में बैकअप क्लस्टर के साथ) तो अगर कम से कम एक haproxy प्रत्येक AZ में है, हम ठीक होना चाहिए। लेकिन यह केवल नकल करता है, समस्या को समाप्त नहीं करता है। इस समस्या के आसपास कोई विचार?

— डॉन मैकएस्किल

@ डॉन मैकएसिल: मुझे पता है कि एडब्ल्यूएस में बड़े पैमाने पर सेवा में कमी आई है, लेकिन एडब्ल्यू की विश्वसनीयता से बेहतर एडब्ल्यूएस पर काम करना कठिन है। फ़्रंट के मल्टी-ऐज़ ऑपरेशन में जाना आसानी से पूरे स्टैक के मल्टी-एज़ेड ऑपरेशन की ओर पहला कदम हो सकता है, और यह साँपों का एक पूरा केटल है ...

— जेसपर एम

@Don MacAskill: एक विकल्प जियो-डीएनएस रिज़ॉल्यूशन जैसे डीएनडीएनएस डायनेक्ट -> ईएलबी + एल 7 एलबी एक अज़ के अंदर होगा, दूसरे एएलबी + एल 7 के साथ दूसरे ऐज़ में हॉट स्टैंडबाय। (भू-जागरूक होने के अलावा, डायनेक्ट की कुछ स्वास्थ्य जांच भी हैं।) डीएनडएनएस का अपटाइम के लिए एक महान ट्रैक रिकॉर्ड है, लेकिन फिर भी, भू-जागरूक डीएनएस को जोड़ना एक अन्य एसपीओएफ है। चाहे 2 AZ में डायनेक्ट + लोड बैलेंसिंग केवल AWS AZ की तुलना में बेहतर दीर्घकालिक अपटाइम मेरे लिए स्पष्ट नहीं है। इसे देखने के लिए जो मेरा मतलब है, मल्टी-एज़ेड डेटाबेस sans: dev.bizo.com/2010/05/improving-global-application.html

— एम

@Don MacAskill: बस एक आखिरी बात - ध्यान रखें कि एक एकल ELB उदाहरण कई AZ का हो सकता है। यह EC2 क्षेत्रों में नहीं फैल सकता है । लेकिन अगर एक ही क्षेत्र के भीतर दो AZ में L7 LB के लिए ELB का उपयोग करना स्वीकार्य है, तो यह सबसे सरल होगा ... आपने लिखा है "ELB एक संपूर्ण AZ को बहुत अच्छी तरह से विफल नहीं करता है", शायद आप पहले से ही अधिक जानते हैं मैं करता हूँ।

— जेसपर एम

हाँ, यदि कोई ELB कई AZ को फैलाता है और किसी प्रकार की विफलता है, जहाँ वह किसी AZ में बैकएंड नोड में से किसी को भी नहीं मिल सकता है (वे अतिभारित हैं, नीचे, 503s, जो भी लौट रहे हैं), अंत उपयोगकर्ताओं को उन त्रुटियों को देखते हैं - यह नहीं है t दूसरे AZ (s) के लिए पुन: मार्ग। मैं उम्मीद कर रहा हूं कि यह योजनाबद्ध है, लेकिन यह हमें एक बार पहले ही काट चुका है।

— डॉन मैकएसिल

यदि आप चिपचिपा सत्र नहीं कर रहे हैं, या यदि आप tomcat / apache शैली का उपयोग कर रहे हैं (परिशिष्ट में ID आईडी के रूप में, राज्य में भंडारण के विपरीत), तो मैं haproxies के एक समूह के सामने ELB का उपयोग करूँगा। ईएलबी में एक हेल्थचेक बनाया गया है, इसलिए आप इसे हैप्रॉक्सी की निगरानी कर सकते हैं और किसी भी डाउन पूल से बाहर ले जा सकते हैं। दिल की धड़कन की विफलता की तुलना में बहुत कम सेट अप करने के लिए।

जहाँ तक परिवर्तनों का प्रचार है, मेरे पास एक महान जवाब नहीं है। कठपुतली प्रारंभिक कॉन्फ़िगरेशन और परिवर्तनों को लागू करने के लिए बहुत अच्छा है, लेकिन नोड्स को जोड़ने / हटाने के लिए आप इसके 30 मिनट के प्रदूषण अंतराल की तुलना में तेजी से प्रतिक्रिया चाहते हैं।

— बेन जेनकेक्स
स्रोत

यह एक अच्छा समाधान (और एक अच्छा सवाल है!) आप अमेज़ॅन एसएनएस का उपयोग एक पुश फैशन में कॉन्फ़िगरेशन परिवर्तनों को फैलाने के लिए कर सकते हैं। आपको हाइपर प्रॉक्सी कॉन्फ़िगरेशन से नोड्स जोड़ने / हटाने के लिए एक अधिसूचना प्रणाली की आवश्यकता है।

— रफीक मनीर

बैकएंड सर्वर के प्रबंधन के लिए एक अन्य विकल्प (जो हैप्रोक्सी को अग्रेषित कर रहा है) प्रत्येक बैकेंड सर्वर या तो सभी हैप्रॉक्सी, या एक कॉन्फ़िगर सर्वर, एक आवधिक पंजीकरण (30 सेकंड या तो) भेजना है। यदि कोई मर जाता है, तो यह जल्दी से अपंजीकृत हो जाता है (और हाइप्रोक्सी को वैसे भी नोटिस करना चाहिए); यदि कोई नया आता है तो यह स्वतः ही रोटेशन में बदल जाता है। यह स्पष्ट रूप से नेटफ्लिक्स क्या करता है।

— बेन जेनकेस

मैंने खुद इसका इस्तेमाल नहीं किया है, लेकिन मैंने बहुत से लोगों को ईसी 2 पर इन प्रकार की समस्याओं को संभालने के लिए कठपुतली का उपयोग करने का उल्लेख किया है

— JamesRyan
स्रोत

हाँ, EC2 पर कठपुतली एक क्लस्टर का प्रबंधन बहुत सरल बनाता है। बस एक माइक्रो उदाहरण बनाएँ और अपने कठपुतली के रूप में उपयोग करें।

— टॉम ओ'कॉनर

हम अपने डेटासेटर्स में कठपुतली का उपयोग करते हैं, लेकिन अभी तक EC2 पर कोशिश नहीं की है। कठपुतली EC2- किसी भी तरह से अवगत है, जैसे कि यह ec2-description-instances या कुछ और का उपयोग करके नोड्स पा सकता है, और उस आउटपुट के आधार पर स्वचालित रूप से कॉन्फ़िगर / पुन: कॉन्फ़िगर कर सकता है? और आप अचानक जाने वाले कठपुतली को कैसे संभालेंगे?

— डॉन मैकस्किल

यह अचानक क्यों चली जाएगी?

— टॉम ओ'कॉनर

यह EC2 के बारे में पता नहीं है, लेकिन आप इसे सेट कर सकते हैं इसलिए जब आप उन्हें शुरू करेंगे तो हस्ताक्षर करने के लिए नए नोड्स को चिह्नित किया जाएगा, और उनका वर्णन करने के लिए एक बाहरी नोड स्क्रिप्ट का उपयोग करें। मैंने SimpleDB (बाहरी नोड्स) और SQS (नए नोड्स के लिए हस्ताक्षर करने के अनुरोध की कतार) के साथ ऐसा करने के लिए कुछ अजगर लिखा; एक ubuntu देव ने S3: ubuntumathiaz.wordpress.com/2010/04/07/…

— बेन

अगर कठपुतली अचानक चली जाती है, तो यह केवल प्रकट रूप से नहीं चलती है, अर्थात यह उस स्थिति में नोड्स को छोड़ देता है जिसमें वे रहते हैं

— बेन जेंक्स 4'10