कसरी त्रुटि-सहिष्णु वेब वास्तुकला Mail.ru क्लाउड समाधान प्लेटफर्ममा लागू हुन्छ

नमस्ते, Habr! म Artem Karamyshev, प्रणाली प्रशासन टोली प्रमुख हुँ Mail.Ru Cloud Solutions (MCS)। हामीले गत वर्षमा धेरै नयाँ उत्पादनहरू लन्च गरेका छौं। हामी सुनिश्चित गर्न चाहन्थ्यौं कि API सेवाहरू सजिलै मापनयोग्य, त्रुटि-सहनशील र प्रयोगकर्ता लोडमा द्रुत वृद्धिको लागि तयार छन्। हाम्रो प्लेटफर्म ओपनस्ट्याकमा लागू गरिएको छ, र म तपाईंलाई दोष-सहिष्णु प्रणाली प्राप्त गर्न हामीले समाधान गर्नुपर्ने कम्पोनेन्ट दोष सहिष्णुता समस्याहरू बताउन चाहन्छु। मलाई लाग्छ कि यो OpenStack मा उत्पादनहरू विकास गर्नेहरूको लागि रोचक हुनेछ।

प्लेटफर्मको समग्र दोष सहिष्णुतामा यसको घटकहरूको लचिलोपन समावेश हुन्छ। त्यसैले हामी बिस्तारै सबै स्तरहरू पार गर्नेछौं जहाँ हामीले जोखिमहरू पहिचान गर्यौं र तिनीहरूलाई बन्द गर्यौं।

यस कथाको भिडियो संस्करण, जसको प्राथमिक स्रोत अपटाइम दिन 4 सम्मेलनमा एक रिपोर्ट थियो, द्वारा आयोजित सुम्मा, तपाईं हेर्न सक्नुहुन्छ Uptime समुदाय YouTube च्यानलमा.

भौतिक वास्तुकला को लचीलापन

MCS क्लाउडको सार्वजनिक भाग अब दुई टियर III डेटा केन्द्रहरूमा आधारित छ, तिनीहरूको बीचमा त्यहाँ यसको आफ्नै डार्क फाइबर छ, भौतिक स्तरमा 200 Gbit/s को थ्रुपुटको साथ, विभिन्न मार्गहरूद्वारा आरक्षित। टियर III ले भौतिक पूर्वाधारको लागि आवश्यक स्तरको दोष सहिष्णुता प्रदान गर्दछ।

गाढा फाइबर दुबै भौतिक र तार्किक स्तरहरूमा आरक्षित छ। च्यानल रिजर्भेसन प्रक्रिया पुनरावृत्ति थियो, समस्याहरू उत्पन्न भयो, र हामी निरन्तर डाटा केन्द्रहरू बीच सञ्चार सुधार गर्दैछौं।

उदाहरणका लागि, केही समय अघि, डाटा केन्द्रहरू मध्ये एक नजिकैको इनारमा काम गर्दा, एक उत्खननकर्ताले पाइप भाँच्यो, र यो पाइप भित्र त्यहाँ एक मुख्य र ब्याकअप अप्टिकल केबल दुवै थियो। डाटा सेन्टरसँगको हाम्रो गल्ती-सहिष्णु सञ्चार च्यानल एक बिन्दुमा, इनारमा कमजोर भयो। तदनुसार, हामीले पूर्वाधारको केही अंश गुमाएका छौं। हामीले निष्कर्ष निकाल्यौं र छेउछाउको इनारमा अतिरिक्त अप्टिक्स स्थापना गर्ने सहित धेरै कार्यहरू गर्यौं।

डाटा केन्द्रहरूमा सञ्चार प्रदायकहरूको उपस्थितिको बिन्दुहरू छन् जसलाई हामीले BGP मार्फत हाम्रो उपसर्गहरू प्रसारण गर्छौं। प्रत्येक नेटवर्क दिशाको लागि, उत्कृष्ट मेट्रिक चयन गरिएको छ, जसले विभिन्न ग्राहकहरूलाई उत्कृष्ट जडान गुणस्तर प्रदान गर्न अनुमति दिन्छ। यदि एक प्रदायक मार्फत सञ्चार कम हुन्छ भने, हामी उपलब्ध प्रदायकहरू मार्फत हाम्रो मार्ग पुन: निर्माण गर्छौं।

यदि प्रदायक असफल भयो भने, हामी स्वचालित रूपमा अर्कोमा स्विच गर्छौं। डेटा केन्द्रहरू मध्ये एकको विफलताको अवस्थामा, हामीसँग दोस्रो डाटा केन्द्रमा हाम्रा सेवाहरूको मिरर प्रतिलिपि छ, जसले सम्पूर्ण भार लिन्छ।

भौतिक पूर्वाधारको लचकता

हामीले अनुप्रयोग-स्तर गल्ती सहिष्णुताको लागि के प्रयोग गर्छौं

हाम्रो सेवा धेरै ओपनसोर्स कम्पोनेन्टहरूमा निर्मित छ।

ExaBGP BGP-आधारित डायनामिक रूटिङ प्रोटोकल प्रयोग गरेर धेरै प्रकार्यहरू लागू गर्ने सेवा हो। हामी यसलाई सक्रिय रूपमा हाम्रो ह्वाइटलिस्ट गरिएका IP ठेगानाहरू विज्ञापन गर्न प्रयोग गर्छौं जसको माध्यमबाट प्रयोगकर्ताहरूले API पहुँच गर्छन्।

HAProxy एक उच्च-लोड ब्यालेन्सर हो जसले तपाईंलाई OSI मोडेलको विभिन्न स्तरहरूमा धेरै लचिलो ट्राफिक सन्तुलन नियमहरू कन्फिगर गर्न अनुमति दिन्छ। हामी यसलाई सबै सेवाहरूको अगाडि सन्तुलन गर्न प्रयोग गर्छौं: डाटाबेस, सन्देश ब्रोकरहरू, API सेवाहरू, वेब सेवाहरू, हाम्रा आन्तरिक परियोजनाहरू - सबै कुरा HAProxy पछाडि छ।

API अनुप्रयोग - पाइथनमा लेखिएको वेब अनुप्रयोग, जसको साथ प्रयोगकर्ताले आफ्नो पूर्वाधार र सेवा व्यवस्थापन गर्दछ।

कार्यकर्ता आवेदन (यसपछि मात्र कार्यकर्ता) - OpenStack सेवाहरूमा, यो एक पूर्वाधार डेमन हो जसले तपाईंलाई पूर्वाधारमा API आदेशहरू प्रसारण गर्न अनुमति दिन्छ। उदाहरणका लागि, डिस्क सिर्जना कार्यकर्तामा हुन्छ, र सिर्जना अनुरोध अनुप्रयोग API मा हुन्छ।

मानक OpenStack अनुप्रयोग वास्तुकला

OpenStack को लागि विकसित गरिएका धेरैजसो सेवाहरूले एकल प्रतिमान पछ्याउने प्रयास गर्छन्। सेवामा सामान्यतया २ भागहरू हुन्छन्: एपीआई र कार्यकर्ताहरू (ब्याकएन्ड निष्पादकहरू)। नियमको रूपमा, एपीआई पाइथनमा एक WSGI अनुप्रयोग हो, जुन या त स्वतन्त्र प्रक्रिया (डेमन) को रूपमा सुरू गरिएको छ, वा तयार-निर्मित Nginx वा Apache वेब सर्भर प्रयोग गरेर। API ले प्रयोगकर्ताको अनुरोधलाई प्रशोधन गर्छ र कार्यान्वयनको लागि कार्यकर्ता अनुप्रयोगलाई थप निर्देशनहरू पास गर्दछ। स्थानान्तरण सन्देश ब्रोकर प्रयोग गरेर हुन्छ, सामान्यतया RabbitMQ, अरूहरू कमजोर रूपमा समर्थित छन्। जब सन्देशहरू ब्रोकरमा पुग्छन्, तिनीहरू कामदारहरूद्वारा प्रशोधन हुन्छन् र आवश्यक भएमा, जवाफ फर्काउँछन्।

यो प्रतिमानले असफलताको पृथक साझा बिन्दुहरू समावेश गर्दछ: RabbitMQ र डाटाबेस। तर RabbitMQ एक सेवा भित्र अलग छ र, सिद्धान्तमा, प्रत्येक सेवाको लागि व्यक्तिगत हुन सक्छ। त्यसैले MCS मा हामी यी सेवाहरूलाई सकेसम्म अलग गर्छौं प्रत्येक व्यक्तिगत परियोजनाको लागि हामी छुट्टै डाटाबेस, छुट्टै RabbitMQ बनाउँछौं। यो दृष्टिकोण राम्रो छ किनभने केहि कमजोर बिन्दुहरूमा दुर्घटनाको घटनामा, सम्पूर्ण सेवा बिग्रिएको छैन, तर यसको अंश मात्र।

कार्यकर्ता अनुप्रयोगहरूको संख्या असीमित छ, त्यसैले API ले प्रदर्शन र गल्ती सहिष्णुता बढाउनको लागि ब्यालेन्सरहरू पछाडि तेर्सो रूपमा मापन गर्न सक्छ।

API र कार्यकर्ताहरू बीच जटिल क्रमिक कार्यहरू हुँदा केही सेवाहरूलाई सेवा भित्र समन्वय आवश्यक हुन्छ। यस अवस्थामा, एकल समन्वय केन्द्र प्रयोग गरिन्छ, क्लस्टर प्रणाली जस्तै Redis, Memcache, etcd, जसले एक कार्यकर्तालाई यो कार्य उसलाई दिइएको छ भनेर अर्कोलाई बताउन अनुमति दिन्छ ("कृपया यसलाई नलिनुहोस्")। हामी आदि प्रयोग गर्छौं। नियमको रूपमा, कर्मचारीहरूले सक्रिय रूपमा डाटाबेससँग सञ्चार गर्छन्, त्यहाँबाट जानकारी लेख्छन् र पढ्छन्। हामी mariadb लाई डेटाबेसको रूपमा प्रयोग गर्छौं, जुन मल्टिमास्टर क्लस्टरमा अवस्थित छ।

यो क्लासिक एकल सेवा सामान्यतया OpenStack को लागि स्वीकार गरिएको तरिकामा व्यवस्थित गरिएको छ। यसलाई एक बन्द प्रणालीको रूपमा मान्न सकिन्छ, जसको लागि स्केलिंग र दोष सहिष्णुताका विधिहरू एकदम स्पष्ट छन्। उदाहरण को लागी, एपीआई दोष सहिष्णुता को लागी, यो तिनीहरूको अगाडि ब्यालेन्सर राख्न पर्याप्त छ। स्केलिंग कार्यकर्ताहरूको संख्या बढाएर हासिल गरिन्छ।

सम्पूर्ण योजनामा ​​कमजोर बिन्दु RabbitMQ र MariaDB हो। तिनीहरूको वास्तुकला एक अलग लेखको योग्य छ यस लेखमा म एपीआई दोष सहिष्णुतामा ध्यान केन्द्रित गर्न चाहन्छु।

ओपनस्ट्याक अनुप्रयोग वास्तुकला। क्लाउड प्लेटफर्मको सन्तुलन र दोष सहिष्णुता

ExaBGP प्रयोग गरेर HAProxy ब्यालेन्सरलाई दोष-सहिष्णु बनाउँदै

हाम्रा API हरू मापनयोग्य, छिटो र गल्ती-सहिष्णु बनाउन, हामीले तिनीहरूको अगाडि लोड ब्यालेन्सर राख्छौं। हामीले HAProxy रोज्यौं। मेरो विचारमा, यसमा हाम्रो कार्यको लागि सबै आवश्यक विशेषताहरू छन्: धेरै OSI स्तरहरूमा सन्तुलन, व्यवस्थापन इन्टरफेस, लचिलोपन र स्केलेबिलिटी, ठूलो संख्यामा सन्तुलन विधिहरू, सत्र तालिकाहरूको लागि समर्थन।

समाधान गर्न आवश्यक पहिलो समस्या ब्यालेन्सरको दोष सहिष्णुता थियो। केवल ब्यालेन्सर स्थापना गर्नाले पनि असफलताको बिन्दु सिर्जना गर्दछ: ब्यालेन्सर ब्रेक हुन्छ र सेवा क्र्यास हुन्छ। यो हुनबाट रोक्नको लागि, हामीले ExaBGP सँग संयोजनमा HAProxy प्रयोग गर्यौं।

ExaBGP ले तपाईंलाई सेवाको अवस्था जाँच गर्नको लागि संयन्त्र लागू गर्न अनुमति दिन्छ। हामीले HAProxy को कार्यक्षमता जाँच गर्न यो संयन्त्र प्रयोग गर्यौं र, समस्या भएमा, BGP बाट HAProxy सेवा असक्षम पार्नुहोस्।

ExaBGP+HAProxy योजना

1. हामी आवश्यक सफ्टवेयर, ExaBGP र HAProxy, तीनवटा सर्भरमा स्थापना गर्छौं।
2. हामी प्रत्येक सर्भरमा लुपब्याक इन्टरफेस सिर्जना गर्छौं।
3. सबै तीन सर्भरहरूमा हामी यस इन्टरफेसमा एउटै सेतो IP ठेगाना प्रदान गर्छौं।
4. सेतो IP ठेगाना ExaBGP मार्फत इन्टरनेटमा विज्ञापन गरिएको छ।

सबै तीन सर्भरहरूबाट एउटै आईपी ठेगानाको विज्ञापन गरेर त्रुटि सहिष्णुता प्राप्त गरिन्छ। नेटवर्कको दृष्टिकोणबाट, एउटै ठेगाना तीन फरक अर्को हप्सबाट पहुँचयोग्य छ। राउटरले तीन समान मार्गहरू देख्छ, तिनीहरूको आफ्नै मेट्रिकको आधारमा उच्चतम प्राथमिकता चयन गर्दछ (यो सामान्यतया एउटै विकल्प हो), र ट्राफिक सर्भरहरू मध्ये एउटामा मात्र जान्छ।

HAProxy को सञ्चालन वा सर्भर विफलता संग समस्या को मामला मा, ExaBGP ले मार्ग घोषणा गर्न रोक्छ, र ट्राफिक सजिलै संग अर्को सर्भर मा स्विच गर्दछ।

यसरी, हामीले ब्यालेन्सरको गल्ती सहनशीलता हासिल गर्यौं।

HAProxy ब्यालेन्सरहरूको दोष सहिष्णुता

योजना अपूर्ण सावित भयो: हामीले HAProxy कसरी रिजर्भ गर्ने भनेर सिक्यौं, तर सेवाहरूमा लोड कसरी वितरण गर्ने भनेर सिकेका छैनौं। त्यसकारण, हामीले यो योजनालाई थोरै विस्तार गर्यौं: हामी धेरै सेतो आईपी ठेगानाहरू बीच सन्तुलन गर्न अगाडि बढ्यौं।

DNS प्लस BGP मा आधारित सन्तुलन

हाम्रो HAProxy को लागि लोड सन्तुलन को मुद्दा अनसुलझे रहन्छ। यद्यपि, यो एकदम सरल रूपमा समाधान गर्न सकिन्छ, हामीले यहाँ गरेका छौं।

तीन सर्भरहरू सन्तुलन गर्न तपाईंलाई 3 सेतो IP ठेगानाहरू र राम्रो पुरानो DNS चाहिन्छ। यी प्रत्येक ठेगानाहरू प्रत्येक HAProxy को लुपब्याक इन्टरफेसमा निर्धारण गरिन्छ र इन्टरनेटमा विज्ञापन गरिन्छ।

OpenStack मा, स्रोतहरू प्रबन्ध गर्न, सेवा डाइरेक्टरी प्रयोग गरिन्छ, जसले विशेष सेवाको अन्तिम बिन्दु API निर्दिष्ट गर्दछ। यस डाइरेक्टरीमा हामी डोमेन नाम दर्ता गर्छौं - public.infra.mail.ru, जुन DNS मार्फत तीन फरक IP ठेगानाहरूद्वारा समाधान गरिन्छ। नतिजाको रूपमा, हामीले DNS मार्फत तीन ठेगानाहरू बीच लोड वितरण पाउँछौं।

तर सेतो आईपी ठेगानाहरू घोषणा गर्दा हामी सर्भर चयन प्राथमिकताहरू नियन्त्रण गर्दैनौं, यो अझै सन्तुलन छैन। सामान्यतया, IP ठेगाना वरिष्ठताको आधारमा एउटा मात्र सर्भर चयन गरिनेछ, र अन्य दुई निष्क्रिय हुनेछन् किनभने BGP मा कुनै मेट्रिक्स निर्दिष्ट गरिएको छैन।

हामीले ExaBGP मार्फत विभिन्न मेट्रिक्सका साथ रुटहरू पठाउन थाल्यौं। प्रत्येक ब्यालेन्सरले सबै तीनवटा सेतो आईपी ठेगानाहरू विज्ञापन गर्दछ, तर तिनीहरूमध्ये एउटा, यो ब्यालेन्सरको लागि मुख्य, न्यूनतम मेट्रिकको साथ विज्ञापन गरिएको छ। त्यसोभए सबै तीन ब्यालेन्सरहरू सञ्चालनमा हुँदा, पहिलो आईपी ठेगानामा कलहरू पहिलो ब्यालेन्सरमा जान्छन्, दोस्रोलाई दोस्रोमा कलहरू हुन्छन्, र तेस्रो देखि तेस्रोमा कलहरू हुन्छन्।

एक ब्यालेन्सर खस्दा के हुन्छ? यदि कुनै ब्यालेन्सर असफल भयो भने, यसको मुख्य ठेगाना अझै पनि अन्य दुईबाट विज्ञापित गरिन्छ, र ट्राफिक तिनीहरू बीच पुन: वितरण गरिन्छ। यसरी, हामी प्रयोगकर्तालाई DNS मार्फत एकै पटक धेरै IP ठेगानाहरू दिन्छौं। DNS र विभिन्न मेट्रिक्स द्वारा सन्तुलन गरेर, हामी सबै तीन ब्यालेन्सरहरूमा लोडको समान वितरण प्राप्त गर्छौं। र एकै समयमा हामी गल्ती सहिष्णुता गुमाउँदैनौं।

DNS + BGP मा आधारित HAProxy सन्तुलन

ExaBGP र HAProxy बीच अन्तरक्रिया

त्यसोभए, हामीले मार्गहरूको घोषणा रोक्नको आधारमा सर्भर छोडेको अवस्थामा त्रुटि सहनशीलता लागू गर्यौं। तर HAProxy सर्भर विफलता बाहेक अन्य कारणहरूको लागि बन्द गर्न सक्छ: प्रशासन त्रुटिहरू, सेवा भित्र विफलता। हामी यी मामिलाहरूमा पनि लोड अन्तर्गत भाँचिएको ब्यालेन्सर हटाउन चाहन्छौं, र हामीलाई फरक संयन्त्र चाहिन्छ।

तसर्थ, अघिल्लो योजनालाई विस्तार गर्दै, हामीले ExaBGP र HAProxy बीच मुटुको धड्कन लागू गर्यौं। यो ExaBGP र HAProxy बीचको अन्तरक्रियाको सफ्टवेयर कार्यान्वयन हो, जब ExaBGP ले अनुप्रयोगहरूको स्थिति जाँच गर्न अनुकूलन लिपिहरू प्रयोग गर्दछ।

यो गर्नको लागि, तपाईंले ExaBGP कन्फिगरमा स्वास्थ्य जाँचकर्ता कन्फिगर गर्न आवश्यक छ, जसले HAProxy को स्थिति जाँच गर्न सक्छ। हाम्रो अवस्थामा, हामीले HAProxy मा स्वास्थ्य ब्याकइन्ड कन्फिगर गर्यौं, र ExaBGP पक्षबाट हामी साधारण GET अनुरोधको साथ जाँच गर्छौं। यदि घोषणा बन्द हुन्छ भने, तब HAProxy ले काम गरिरहेको छैन र यसलाई विज्ञापन गर्न आवश्यक छैन।

HAProxy स्वास्थ्य जाँच

HAProxy Peers: सत्र सिंक्रोनाइजेसन

गर्नु पर्ने अर्को कुरा सत्रहरू सिङ्क्रोनाइज गर्नु थियो। वितरित ब्यालेन्सरहरू मार्फत काम गर्दा, ग्राहक सत्रहरूको बारेमा जानकारीको भण्डारण व्यवस्थित गर्न गाह्रो हुन्छ। तर HAProxy केही ब्यालेन्सरहरू मध्ये एक हो जसले Peers कार्यक्षमताका कारण यो गर्न सक्छ - विभिन्न HAProxy प्रक्रियाहरू बीच सत्र तालिकाहरू स्थानान्तरण गर्ने क्षमता।

त्यहाँ विभिन्न सन्तुलन विधिहरू छन्: सरल जस्तै राउन्ड रोबिन, र विस्तारित, जब ग्राहकको सत्र सम्झिन्छ, र प्रत्येक पटक ऊ पहिले जस्तै समान सर्भरमा समाप्त हुन्छ। हामी दोस्रो विकल्प कार्यान्वयन गर्न चाहन्छौं।

HAProxy ले यस मेकानिजमको क्लाइन्ट सत्रहरू बचत गर्न स्टिक-टेबलहरू प्रयोग गर्दछ। तिनीहरूले ग्राहकको मूल आईपी ठेगाना, चयन गरिएको लक्ष्य ठेगाना (ब्याकएन्ड) र केही सेवा जानकारी बचत गर्छन्। सामान्यतया, स्टिक टेबलहरू स्रोत-IP + गन्तव्य-IP जोडी भण्डारण गर्न प्रयोग गरिन्छ, जुन विशेष गरी अनुप्रयोगहरूको लागि उपयोगी हुन्छ जसले अर्को ब्यालेन्सरमा स्विच गर्दा प्रयोगकर्ता सत्र सन्दर्भ स्थानान्तरण गर्न सक्दैन, उदाहरणका लागि, राउन्डरोबिन ब्यालेन्सिङ मोडमा।

यदि स्टिक टेबललाई विभिन्न HAProxy प्रक्रियाहरू (कुन बीचमा सन्तुलन हुन्छ) बीचमा सार्न सिकाइन्छ भने, हाम्रा ब्यालेन्सरहरूले स्टिक टेबलहरूको एउटा पूलसँग काम गर्न सक्षम हुनेछन्। यदि ब्यालेन्सरहरू मध्ये एक असफल भएमा ग्राहकको सञ्जाललाई निर्बाध रूपमा स्विच गर्न सम्भव बनाउँदछ;

उचित सञ्चालनको लागि, ब्यालेन्सरको स्रोत आईपी ठेगानाको समस्या जसबाट सत्र स्थापना गरिएको थियो समाधान गर्नुपर्छ। हाम्रो अवस्थामा, यो लुपब्याक इन्टरफेसमा एक गतिशील ठेगाना हो।

साथीहरूको सही काम निश्चित परिस्थितिहरूमा मात्र प्राप्त हुन्छ। अर्थात्, TCP टाइमआउट पर्याप्त मात्रामा ठुलो हुनुपर्छ वा TCP सत्र समाप्त हुन समय नपरोस् भनेर स्विचिङ पर्याप्त छिटो हुनुपर्छ। यद्यपि, यसले सिमलेस स्विचिङको लागि अनुमति दिन्छ।

IaaS मा हामीसँग उही प्रविधि प्रयोग गरेर निर्माण गरिएको सेवा छ। यो ओपनस्ट्याकको लागि सेवाको रूपमा ब्यालेन्सर लोड गर्नुहोस्जसलाई अक्टोभिया भनिन्छ। यो दुई HAProxy प्रक्रियाहरूमा आधारित छ र प्रारम्भमा साथीहरूको लागि समर्थन समावेश गर्दछ। उनीहरूले यस सेवामा आफूलाई उत्कृष्ट साबित गरेका छन्।

चित्रले योजनाबद्ध रूपमा तीन HAProxy उदाहरणहरू बीच पियर टेबलहरूको आन्दोलन देखाउँछ, यसलाई कसरी कन्फिगर गर्न सकिन्छ भन्ने बारे एउटा कन्फिगर प्रस्ताव गरिएको छ:

HAProxy Peers (सत्र सिंक्रोनाइजेसन)

यदि तपाइँ एउटै योजना लागू गर्नुहुन्छ भने, यसको सञ्चालन सावधानीपूर्वक परीक्षण गरिनु पर्छ। यो एक तथ्य होइन कि यो समय को 100% उस्तै तरिका मा काम गर्नेछ। तर कम्तिमा तपाईले स्टिक तालिकाहरू गुमाउनुहुने छैन जब तपाईलाई ग्राहकको स्रोत आईपी सम्झना आवश्यक छ।

एउटै ग्राहकबाट एक साथ अनुरोधहरूको संख्या सीमित गर्दै

हाम्रा API हरू सहित सार्वजनिक रूपमा उपलब्ध कुनै पनि सेवाहरू अनुरोधहरूको हिमपातको विषय हुन सक्छन्। तिनीहरूका कारणहरू पूर्णतया फरक हुन सक्छन्, प्रयोगकर्ता त्रुटिहरू देखि लक्षित आक्रमणहरूमा। हामी आवधिक रूपमा IP ठेगानाहरू द्वारा DDoSed हुन्छौं। ग्राहकहरूले प्रायः तिनीहरूको स्क्रिप्टहरूमा गल्ती गर्छन् र हामीलाई mini-DDoSs दिन्छन्।

एक तरिका वा अर्को, थप सुरक्षा प्रदान गर्नुपर्छ। स्पष्ट समाधान भनेको API अनुरोधहरूको संख्या सीमित गर्नु हो र दुर्भावनापूर्ण अनुरोधहरू प्रशोधन गर्दै CPU समय बर्बाद नगर्नु हो।

त्यस्ता प्रतिबन्धहरू लागू गर्न, हामी समान स्टिक तालिकाहरू प्रयोग गरेर HAProxy को आधारमा संगठित दर सीमाहरू प्रयोग गर्छौं। सेट अप सीमा एकदम सरल छ र तपाईंलाई API मा अनुरोधहरूको संख्या द्वारा प्रयोगकर्ता सीमित गर्न अनुमति दिन्छ। एल्गोरिदमले स्रोत आईपी सम्झन्छ जसबाट अनुरोधहरू गरिन्छ र एक प्रयोगकर्ताबाट एक साथ अनुरोधहरूको संख्या सीमित गर्दछ। निस्सन्देह, हामीले प्रत्येक सेवाको लागि औसत API लोड प्रोफाइल गणना गर्यौं र ≈ १० गुणा यो मानको सीमा सेट गर्‍यौं। हामी स्थितिलाई नजिकबाट निगरानी गर्न जारी राख्छौं र हाम्रो औंला नाडीमा राख्छौं।

यो व्यवहारमा कस्तो देखिन्छ? हामीसँग ग्राहकहरू छन् जसले हाम्रा अटोस्केलिंग API हरू सधैं प्रयोग गर्छन्। तिनीहरू बिहान करिब दुई देखि तीन सय भर्चुअल मेसिनहरू बनाउँछन् र बेलुका मेटाउँछन्। ओपनस्ट्याकका लागि, PaaS सेवाहरूसँग भर्चुअल मेसिन सिर्जना गर्न, कम्तिमा 1000 API अनुरोधहरू आवश्यक पर्दछ, किनकि सेवाहरू बीचको अन्तरक्रिया पनि API मार्फत हुन्छ।

कार्यहरूको यस्तो स्थानान्तरणले एकदम ठूलो भार निम्त्याउँछ। हामीले यो भार मूल्याङ्कन गर्‍यौं, दैनिक चुचुराहरू सङ्कलन गर्‍यौं, तिनीहरूलाई दश गुणा बढायौं, र यो हाम्रो दर सीमा भयो। हामी हाम्रो औंला नाडीमा राख्छौं। हामी प्रायः बटहरू र स्क्यानरहरू देख्छौं जसले हामीसँग चलाउन सकिने कुनै CGA स्क्रिप्टहरू छन् कि छैनन् भनेर हेर्न कोसिस गर्ने प्रयास गर्छौं, हामीले तिनीहरूलाई सक्रिय रूपमा काट्छौं।

प्रयोगकर्ताहरूलाई ध्यान नदिई कसरी तपाइँको कोडबेस अपडेट गर्ने

हामी कोड डिप्लोइमेन्ट प्रक्रियाको स्तरमा गल्ती सहिष्णुता पनि लागू गर्छौं। रोलआउटको क्रममा त्रुटिहरू हुन सक्छन्, तर सेवा उपलब्धतामा तिनीहरूको प्रभावलाई कम गर्न सकिन्छ।

हामी हाम्रा सेवाहरू निरन्तर अपडेट गर्छौं र प्रयोगकर्ताहरूलाई असर नगरी कोडबेस अद्यावधिक गरिएको छ भनी सुनिश्चित गर्नुपर्छ। हामीले HAProxy को व्यवस्थापन क्षमताहरू र हाम्रा सेवाहरूमा ग्रेसफुल शटडाउनको कार्यान्वयन प्रयोग गरेर यो समस्या समाधान गर्न व्यवस्थित गर्यौं।

यो समस्या समाधान गर्न, ब्यालेन्सरको नियन्त्रण र सेवाहरूको "सही" बन्द सुनिश्चित गर्न आवश्यक थियो:

• HAProxy को अवस्थामा, नियन्त्रण तथ्याङ्क फाइल मार्फत गरिन्छ, जुन अनिवार्य रूपमा सकेट हो र HAProxy कन्फिगरेसनमा परिभाषित गरिएको छ। तपाइँ यसलाई stdio मार्फत आदेश पठाउन सक्नुहुन्छ। तर हाम्रो मुख्य कन्फिगरेसन नियन्त्रण उपकरण उत्तरदायी छ, त्यसैले यसमा HAProxy प्रबन्ध गर्नको लागि निर्मित मोड्युल छ। जसलाई हामी सक्रिय रूपमा प्रयोग गर्छौं।
• हाम्रा धेरैजसो एपीआई र इन्जिन सेवाहरूले आकर्षक बन्द प्रविधिहरूलाई समर्थन गर्दछ: बन्द गर्दा, तिनीहरू हालको कार्य पूरा हुनको लागि पर्खन्छन्, यो HTTP अनुरोध वा केही सेवा कार्य हो। कामदारको हकमा पनि त्यस्तै हुन्छ । यसलाई सबै कार्यहरू थाहा छ जुन यो गरिरहेको छ र समाप्त हुन्छ जब यो सफलतापूर्वक सबै पूरा हुन्छ।

यी दुई बिन्दुहरूलाई धन्यवाद, हाम्रो तैनातीको लागि सुरक्षित एल्गोरिथ्म यस्तो देखिन्छ।

1. विकासकर्ताले कोडको नयाँ प्याकेज भेला गर्छ (हाम्रो लागि यो RPM हो), यसलाई डेभ वातावरणमा परीक्षण गर्छ, स्टेजमा परीक्षण गर्छ, र स्टेज रिपोजिटरीमा छोड्छ।
2. विकासकर्ताले "कलाकृतिहरू" को सबैभन्दा विस्तृत विवरणको साथ प्रयोगको लागि कार्य सेट गर्दछ: नयाँ प्याकेजको संस्करण, नयाँ कार्यक्षमताको विवरण र आवश्यक भएमा प्रयोगको बारेमा अन्य विवरणहरू।
3. प्रणाली प्रशासकले अद्यावधिक सुरु गर्छ। उत्तरदायी प्लेबुक लन्च गर्दछ, जसले बारीमा निम्न गर्छ:
   • स्टेज रिपोजिटरीबाट प्याकेज लिन्छ र उत्पादन भण्डारमा प्याकेजको संस्करण अद्यावधिक गर्न प्रयोग गर्दछ।
   • अद्यावधिक गरिएको सेवाको ब्याकएन्डहरूको सूची कम्पाइल गर्दछ।
   • HAProxy मा अद्यावधिक हुने पहिलो सेवा बन्द गर्छ र यसको प्रक्रियाहरू चल्ने समाप्त हुनको लागि पर्खन्छ। सुन्दर बन्दको लागि धन्यवाद, हामी विश्वस्त छौं कि सबै हालका ग्राहक अनुरोधहरू सफलतापूर्वक पूरा हुनेछन्।
   • API र कार्यकर्ताहरू पूर्ण रूपमा बन्द भएपछि, र HAProxy बन्द भएपछि, कोड अपडेट हुन्छ।
   • उत्तरदायी रन सेवाहरू।
   • प्रत्येक सेवाको लागि, निश्चित "ह्यान्डलहरू" तानिन्छन्, जसले पूर्व-परिभाषित कुञ्जी परीक्षणहरूको संख्यामा एकाइ परीक्षण गर्दछ। नयाँ कोडको आधारभूत जाँच हुन्छ।
   • यदि अघिल्लो चरणमा कुनै त्रुटि फेला परेन भने, ब्याकइन्ड सक्रिय हुन्छ।
   • अर्को ब्याकइन्डमा जाऔं।
4. सबै ब्याकएन्डहरू अद्यावधिक भएपछि, कार्यात्मक परीक्षणहरू सुरु हुन्छन्। यदि तिनीहरू हराइरहेका छन् भने, त्यसपछि विकासकर्ताले सिर्जना गरेको कुनै पनि नयाँ प्रकार्यता हेर्छ।

यसले डिप्लोइमेन्ट पूरा गर्छ।

सेवा अद्यावधिक चक्र

यदि हामीसँग एक नियम नभएको भए यो योजनाले काम गर्दैन। हामी युद्धमा पुरानो र नयाँ संस्करण दुवै समर्थन गर्छौं। अग्रिममा, सफ्टवेयर विकासको चरणमा, यो राखिएको छ कि सेवा डेटाबेसमा परिवर्तनहरू भए पनि, तिनीहरूले अघिल्लो कोड तोड्ने छैनन्। नतिजाको रूपमा, कोड आधार बिस्तारै अद्यावधिक गरिएको छ।

निष्कर्षमा

गल्ती-सहिष्णु WEB वास्तुकलाको बारेमा मेरो आफ्नै विचारहरू साझा गर्दै, म एक पटक फेरि यसको मुख्य बुँदाहरू नोट गर्न चाहन्छु:

• शारीरिक दोष सहिष्णुता;
• नेटवर्क गल्ती सहिष्णुता (ब्यालेन्सर, BGP);
• प्रयोग र विकसित सफ्टवेयर को दोष सहिष्णुता।

सबैलाई स्थिर अपटाइम!

स्रोत: www.habr.com