Mail.ru क्लाउड सोल्यूशन्स प्लॅटफॉर्ममध्ये दोष-सहिष्णु वेब आर्किटेक्चर कसे लागू केले जाते

हॅलो, हॅब्र! मी Artem Karamyshev आहे, प्रणाली प्रशासन संघ प्रमुख Mail.Ru Cloud Solutions (MCS). गेल्या वर्षभरात आमच्याकडे अनेक नवीन उत्पादने लाँच झाली आहेत. API सेवा सहजपणे वाढवता येण्याजोग्या, दोष-सहिष्णु आणि वापरकर्त्याच्या लोडमध्ये जलद वाढीसाठी सज्ज आहेत याची आम्हाला खात्री करायची होती. आमचे प्लॅटफॉर्म OpenStack वर लागू केले गेले आहे, आणि मी तुम्हाला सांगू इच्छितो की दोष-सहिष्णु प्रणाली मिळविण्यासाठी आम्हाला कोणत्या घटक दोष सहिष्णुतेच्या समस्या सोडवाव्या लागल्या. मला वाटते जे OpenStack वर उत्पादने विकसित करतात त्यांच्यासाठी हे मनोरंजक असेल.

प्लॅटफॉर्मच्या एकूण दोष सहिष्णुतेमध्ये त्याच्या घटकांची लवचिकता असते. त्यामुळे आम्ही हळूहळू त्या सर्व स्तरांवर जाऊ ज्यात आम्ही धोके ओळखले आणि ते बंद केले.

या कथेची व्हिडिओ आवृत्ती, ज्याचा प्राथमिक स्त्रोत अपटाइम डे 4 कॉन्फरन्सचा अहवाल होता, ज्याने आयोजित केले होते सुम्मा, आपण पाहू शकता Uptime समुदाय YouTube चॅनेलवर.

भौतिक आर्किटेक्चरची लवचिकता

MCS क्लाउडचा सार्वजनिक भाग आता दोन टियर III डेटा सेंटर्सवर आधारित आहे, त्यांच्यामध्ये 200 Gbit/s च्या थ्रूपुटसह वेगवेगळ्या मार्गांद्वारे भौतिक स्तरावर आरक्षित केलेले स्वतःचे गडद फायबर आहे. टियर III भौतिक पायाभूत सुविधांसाठी आवश्यक प्रमाणात दोष सहिष्णुता प्रदान करते.

गडद फायबर भौतिक आणि तार्किक दोन्ही स्तरांवर आरक्षित आहे. चॅनेल आरक्षण प्रक्रिया पुनरावृत्ती होते, समस्या उद्भवल्या आणि आम्ही डेटा केंद्रांमधील संप्रेषण सतत सुधारत आहोत.

उदाहरणार्थ, काही काळापूर्वी, एका डेटा केंद्राजवळील विहिरीत काम करत असताना, एका उत्खननकर्त्याने एक पाईप तोडला आणि या पाईपच्या आत एक मुख्य आणि बॅकअप ऑप्टिकल केबल दोन्ही होती. डेटा सेंटरसह आमचे दोष-सहिष्णु संप्रेषण चॅनेल एका क्षणी, विहिरीत असुरक्षित असल्याचे दिसून आले. त्यानुसार आम्ही पायाभूत सुविधांचा काही भाग गमावला आहे. आम्ही निष्कर्ष काढले आणि शेजारच्या विहिरीमध्ये अतिरिक्त ऑप्टिक्स स्थापित करण्यासह अनेक क्रिया केल्या.

डेटा सेंटर्समध्ये संप्रेषण पुरवठादारांच्या उपस्थितीचे बिंदू आहेत ज्यांना आम्ही आमचा उपसर्ग BGP द्वारे प्रसारित करतो. प्रत्येक नेटवर्क दिशानिर्देशासाठी, सर्वोत्तम मेट्रिक निवडले जाते, जे भिन्न क्लायंटना सर्वोत्तम कनेक्शन गुणवत्ता प्रदान करण्यास अनुमती देते. एका प्रदात्याद्वारे संप्रेषण कमी झाल्यास, आम्ही उपलब्ध प्रदात्यांद्वारे आमचे मार्ग पुन्हा तयार करतो.

प्रदाता अयशस्वी झाल्यास, आम्ही आपोआप पुढीलकडे स्विच करतो. एका डेटा सेंटरमध्ये बिघाड झाल्यास, आमच्याकडे दुसऱ्या डेटा सेंटरमध्ये आमच्या सेवांची मिरर कॉपी असते, जी संपूर्ण भार घेते.

भौतिक पायाभूत सुविधांची लवचिकता

अनुप्रयोग-स्तरीय दोष सहिष्णुतेसाठी आम्ही काय वापरतो

आमची सेवा अनेक ओपनसोर्स घटकांवर आधारित आहे.

ExaBGP ही सेवा आहे जी BGP-आधारित डायनॅमिक राउटिंग प्रोटोकॉल वापरून अनेक कार्ये लागू करते. आमच्या श्वेतसूचीबद्ध IP पत्त्यांची जाहिरात करण्यासाठी आम्ही त्याचा सक्रियपणे वापर करतो ज्याद्वारे वापरकर्ते API मध्ये प्रवेश करतात.

हाप्रोक्सी हा एक उच्च-लोड बॅलन्सर आहे जो तुम्हाला OSI मॉडेलच्या विविध स्तरांवर अतिशय लवचिक रहदारी संतुलन नियम कॉन्फिगर करण्याची परवानगी देतो. आम्ही ते सर्व सेवांसमोर समतोल राखण्यासाठी वापरतो: डेटाबेस, संदेश दलाल, API सेवा, वेब सेवा, आमचे अंतर्गत प्रकल्प - सर्वकाही HAProxy च्या मागे आहे.

API अनुप्रयोग — python मध्ये लिहिलेले वेब ऍप्लिकेशन, ज्याद्वारे वापरकर्ता त्याच्या पायाभूत सुविधा आणि सेवा व्यवस्थापित करतो.

कामगार अर्ज (यापुढे फक्त कार्यकर्ता) - ओपनस्टॅक सेवांमध्ये, हा एक इन्फ्रास्ट्रक्चर डिमन आहे जो तुम्हाला एपीआय कमांड्स इन्फ्रास्ट्रक्चरवर प्रसारित करण्याची परवानगी देतो. उदाहरणार्थ, डिस्क निर्माण कार्यकर्त्यामध्ये होते आणि निर्मिती विनंती अनुप्रयोग API मध्ये होते.

मानक ओपनस्टॅक ऍप्लिकेशन आर्किटेक्चर

OpenStack साठी विकसित केलेल्या बर्‍याच सेवा एकाच पॅराडाइमचे अनुसरण करण्याचा प्रयत्न करतात. सेवेमध्ये सहसा 2 भाग असतात: API आणि कामगार (बॅकएंड एक्झिक्युटर्स). नियमानुसार, एपीआय हा पायथॉनमधील डब्ल्यूएसजीआय ऍप्लिकेशन आहे, जो एकतर स्वतंत्र प्रक्रिया (डेमन) किंवा रेडीमेड Nginx किंवा Apache वेब सर्व्हर वापरून लॉन्च केला जातो. API वापरकर्त्याच्या विनंतीवर प्रक्रिया करते आणि कार्यान्वित करण्यासाठी पुढील सूचना कार्यकर्ता अनुप्रयोगास देते. ट्रान्सफर मेसेज ब्रोकर वापरून होते, सहसा RabbitMQ, इतर खराब समर्थित आहेत. जेव्हा संदेश ब्रोकरपर्यंत पोहोचतात, तेव्हा कामगारांद्वारे त्यावर प्रक्रिया केली जाते आणि आवश्यक असल्यास, प्रतिसाद परत केला जातो.

या पॅराडाइममध्ये अयशस्वी होण्याचे पृथक सामान्य मुद्दे समाविष्ट आहेत: RabbitMQ आणि डेटाबेस. परंतु RabbitMQ एका सेवेमध्ये वेगळे केले जाते आणि सिद्धांततः, प्रत्येक सेवेसाठी वैयक्तिक असू शकते. म्हणून MCS वर आम्ही या सेवा शक्य तितक्या वेगळ्या करतो; प्रत्येक वैयक्तिक प्रकल्पासाठी आम्ही वेगळा डेटाबेस तयार करतो, एक वेगळा RabbitMQ. हा दृष्टीकोन चांगला आहे कारण काही असुरक्षित बिंदूंवर अपघात झाल्यास, संपूर्ण सेवा खंडित होत नाही, परंतु त्याचा फक्त एक भाग आहे.

कार्यकर्ता अनुप्रयोगांची संख्या अमर्यादित आहे, त्यामुळे कार्यप्रदर्शन आणि दोष सहिष्णुता वाढवण्यासाठी API बॅलन्सर्सच्या मागे क्षैतिजरित्या सहजपणे स्केल करू शकते.

जेव्हा API आणि कामगार यांच्यात जटिल अनुक्रमिक ऑपरेशन्स होतात तेव्हा काही सेवांना सेवेमध्ये समन्वय आवश्यक असतो. या प्रकरणात, एकल समन्वय केंद्र वापरले जाते, रेडिस, मेमकेश, इ.डी. सारखी क्लस्टर प्रणाली, जी एका कार्यकर्त्याला दुसर्‍याला सांगू देते की हे कार्य त्याच्याकडे सोपवले आहे ("कृपया ते घेऊ नका"). आम्ही etcd वापरतो. नियमानुसार, कामगार डेटाबेससह सक्रियपणे संवाद साधतात, तेथून माहिती लिहितात आणि वाचतात. आम्ही mariadb ला डेटाबेस म्हणून वापरतो, जो मल्टीमास्टर क्लस्टरमध्ये असतो.

ही क्लासिक एकल सेवा सामान्यतः OpenStack साठी स्वीकारल्या जाणार्‍या पद्धतीने आयोजित केली जाते. हे एक बंद प्रणाली म्हणून मानले जाऊ शकते, ज्यासाठी स्केलिंग आणि दोष सहिष्णुतेच्या पद्धती अगदी स्पष्ट आहेत. उदाहरणार्थ, एपीआय फॉल्ट टॉलरन्ससाठी, त्यांच्यासमोर बॅलन्सर ठेवणे पुरेसे आहे. स्केलिंग कामगारांची संख्या वाढवून साध्य केले जाते.

संपूर्ण योजनेतील कमकुवत बिंदू म्हणजे RabbitMQ आणि MariaDB. त्यांचे आर्किटेक्चर स्वतंत्र लेखास पात्र आहे. या लेखात मला API दोष सहिष्णुतेवर लक्ष केंद्रित करायचे आहे.

ओपनस्टॅक ऍप्लिकेशन आर्किटेक्चर. क्लाउड प्लॅटफॉर्मचे संतुलन आणि दोष सहिष्णुता

ExaBGP वापरून HAProxy बॅलन्सर दोष-सहिष्णु बनवणे

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

पहिली समस्या ज्याचे निराकरण करणे आवश्यक होते ती म्हणजे बॅलन्सरची दोष सहनशीलता. फक्त बॅलन्सर स्थापित केल्याने देखील बिघाडाचा मुद्दा निर्माण होतो: बॅलन्सर तुटतो आणि सेवा क्रॅश होते. हे होण्यापासून रोखण्यासाठी, आम्ही ExaBGP सह HAProxy चा वापर केला.

ExaBGP तुम्हाला सेवेची स्थिती तपासण्यासाठी यंत्रणा कार्यान्वित करण्याची परवानगी देते. आम्ही ही यंत्रणा HAProxy ची कार्यक्षमता तपासण्यासाठी वापरली आणि समस्या असल्यास, BGP कडून HAProxy सेवा अक्षम करू.

ExaBGP+HAProxy योजना

1. आम्ही आवश्यक सॉफ्टवेअर, ExaBGP आणि HAProxy, तीन सर्व्हरवर स्थापित करतो.
2. आम्ही प्रत्येक सर्व्हरवर लूपबॅक इंटरफेस तयार करतो.
3. सर्व तीन सर्व्हरवर आम्ही या इंटरफेसला समान पांढरा IP पत्ता नियुक्त करतो.
4. एक पांढरा IP पत्ता ExaBGP द्वारे इंटरनेटवर जाहिरात केला जातो.

सर्व तीन सर्व्हरवरून समान IP पत्त्याची जाहिरात करून दोष सहिष्णुता प्राप्त केली जाते. नेटवर्कच्या दृष्टिकोनातून, समान पत्ता तीन वेगवेगळ्या पुढील हॉप्समधून प्रवेश करण्यायोग्य आहे. राउटर तीन समान मार्ग पाहतो, त्याच्या स्वतःच्या मेट्रिकच्या आधारे त्यातील सर्वोच्च प्राधान्य निवडतो (हा सहसा समान पर्याय असतो) आणि रहदारी फक्त एका सर्व्हरवर जाते.

HAProxy च्या ऑपरेशनमध्ये किंवा सर्व्हरमध्ये बिघाड झाल्यास, ExaBGP मार्गाची घोषणा करणे थांबवते आणि वाहतूक सुरळीतपणे दुसर्‍या सर्व्हरवर स्विच करते.

अशा प्रकारे, आम्ही बॅलन्सरची दोष सहिष्णुता प्राप्त केली.

HAProxy बॅलन्सर्सची दोष सहिष्णुता

योजना अपूर्ण असल्याचे दिसून आले: आम्ही HAProxy कसे आरक्षित करावे हे शिकलो, परंतु सेवांमध्ये लोड कसे वितरित करावे हे शिकलो नाही. म्हणून, आम्ही या योजनेचा थोडा विस्तार केला: आम्ही अनेक पांढर्‍या IP पत्त्यांमध्ये संतुलन राखण्यासाठी पुढे गेलो.

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

आमच्या HAProxy साठी लोड बॅलन्सिंगचा प्रश्न अद्याप निराकरण झालेला नाही. तथापि, हे अगदी सोप्या पद्धतीने सोडवले जाऊ शकते, जसे आम्ही येथे केले.

तीन सर्व्हर संतुलित करण्यासाठी तुम्हाला 3 पांढरे IP पत्ते आणि चांगले जुने DNS आवश्यक असतील. यापैकी प्रत्येक पत्ता प्रत्येक HAProxy च्या लूपबॅक इंटरफेसवर निर्धारित केला जातो आणि इंटरनेटवर जाहिरात केली जाते.

OpenStack मध्ये, संसाधने व्यवस्थापित करण्यासाठी, सेवा निर्देशिका वापरली जाते, जी विशिष्ट सेवेचे एंडपॉइंट API निर्दिष्ट करते. या निर्देशिकेत आम्ही एक डोमेन नाव नोंदणी करतो - public.infra.mail.ru, ज्याचे निराकरण DNS द्वारे तीन वेगवेगळ्या IP पत्त्यांद्वारे केले जाते. परिणामी, आम्हाला DNS द्वारे तीन पत्त्यांमध्ये लोड वितरण मिळते.

परंतु पांढरे IP पत्ते घोषित करताना आम्ही सर्व्हर निवड प्राधान्यक्रम नियंत्रित करत नाही, हे अद्याप संतुलित नाही. सामान्यतः, IP पत्त्याच्या ज्येष्ठतेवर आधारित फक्त एक सर्व्हर निवडला जाईल, आणि इतर दोन निष्क्रिय असतील कारण BGP मध्ये कोणतेही मेट्रिक्स निर्दिष्ट केलेले नाहीत.

आम्ही ExaBGP द्वारे वेगवेगळ्या मेट्रिक्ससह मार्ग पाठवण्यास सुरुवात केली. प्रत्येक बॅलन्सर सर्व तीन पांढर्‍या IP पत्त्यांची जाहिरात करतो, परंतु त्यापैकी एक, या बॅलन्सरसाठी मुख्य, किमान मेट्रिकसह जाहिरात केली जाते. त्यामुळे तिन्ही बॅलन्सर चालू असताना, पहिल्या आयपी अॅड्रेसवरील कॉल पहिल्या बॅलन्सरवर जातात, दुसऱ्याला दुसऱ्याला कॉल करतात आणि तिसऱ्या ते तिसऱ्याला कॉल करतात.

बॅलन्सर्सपैकी एक पडल्यावर काय होते? कोणताही बॅलन्सर अयशस्वी झाल्यास, त्याचा मुख्य पत्ता अद्याप इतर दोनमधून जाहिरात केला जातो आणि त्यांच्यामध्ये रहदारी पुन्हा वितरित केली जाते. अशा प्रकारे, आम्ही वापरकर्त्याला DNS द्वारे एकाच वेळी अनेक IP पत्ते देतो. DNS आणि भिन्न मेट्रिक्सद्वारे समतोल साधून, आम्हाला तिन्ही बॅलन्सरमध्ये लोडचे समान वितरण मिळते. आणि त्याच वेळी आपण दोष सहनशीलता गमावत नाही.

DNS + BGP वर आधारित HAProxy संतुलित करणे

ExaBGP आणि HAProxy मधील परस्परसंवाद

त्यामुळे, आम्ही मार्गांची घोषणा थांबविण्यावर आधारित सर्व्हर सोडल्यास फॉल्ट टॉलरन्स लागू करतो. परंतु HAProxy सर्व्हरच्या अपयशाव्यतिरिक्त इतर कारणांमुळे बंद होऊ शकते: प्रशासनातील त्रुटी, सेवेतील अपयश. आम्हाला या प्रकरणांमध्ये देखील लोड अंतर्गत तुटलेला बॅलन्सर काढायचा आहे आणि आम्हाला वेगळ्या यंत्रणेची आवश्यकता आहे.

म्हणून, मागील योजनेचा विस्तार करून, आम्ही ExaBGP आणि HAProxy दरम्यान हृदयाचे ठोके लागू केले. हे ExaBGP आणि HAProxy मधील परस्परसंवादाचे सॉफ्टवेअर अंमलबजावणी आहे, जेव्हा ExaBGP अनुप्रयोगांची स्थिती तपासण्यासाठी सानुकूल स्क्रिप्ट वापरते.

हे करण्यासाठी, तुम्हाला ExaBGP कॉन्फिगरमध्ये आरोग्य तपासक कॉन्फिगर करणे आवश्यक आहे, जे HAProxy ची स्थिती तपासू शकते. आमच्या बाबतीत, आम्ही HAProxy मध्ये हेल्थ बॅकएंड कॉन्फिगर केले आहे आणि ExaBGP बाजूने आम्ही एक साधी GET विनंती तपासतो. जर घोषणा होणे थांबले, तर HAProxy बहुधा काम करत नाही आणि त्याची जाहिरात करण्याची गरज नाही.

HAProxy आरोग्य तपासणी

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

पुढील गोष्ट म्हणजे सत्रे समक्रमित करणे. वितरित बॅलन्सरद्वारे कार्य करताना, क्लायंट सत्रांबद्दल माहितीचे संचयन आयोजित करणे कठीण आहे. परंतु HAProxy हे काही बॅलन्सर्सपैकी एक आहे जे पीअर्स कार्यक्षमतेमुळे हे करू शकतात - वेगवेगळ्या HAProxy प्रक्रियांमध्ये सत्र सारणी हस्तांतरित करण्याची क्षमता.

विविध संतुलन पद्धती आहेत: सोप्या जसे की गोल-रॉबिन, आणि विस्तारित, जेव्हा क्लायंटचे सत्र लक्षात ठेवले जाते आणि प्रत्येक वेळी तो पूर्वीप्रमाणेच सर्व्हरवर संपतो. आम्हाला दुसरा पर्याय अंमलात आणायचा होता.

HAProxy या यंत्रणेची क्लायंट सत्रे जतन करण्यासाठी स्टिक-टेबल वापरते. ते क्लायंटचा मूळ IP पत्ता, निवडलेला लक्ष्य पत्ता (बॅकएंड) आणि काही सेवा माहिती जतन करतात. सामान्यतः, स्टिक टेबल्सचा वापर स्त्रोत-IP + गंतव्य-IP जोडी संचयित करण्यासाठी केला जातो, जे विशेषतः अशा अनुप्रयोगांसाठी उपयुक्त आहे जे दुसर्‍या बॅलन्सरवर स्विच करताना वापरकर्ता सत्र संदर्भ हस्तांतरित करू शकत नाहीत, उदाहरणार्थ, RoundRobin बॅलन्सिंग मोडमध्ये.

जर स्टिक टेबलला वेगवेगळ्या HAProxy प्रक्रियांमध्ये (ज्यामध्ये संतुलन होते) हलवायला शिकवले असेल, तर आमचे बॅलन्सर स्टिक टेबलच्या एका पूलसह कार्य करण्यास सक्षम असतील. हे बॅलन्सरपैकी एक अयशस्वी झाल्यास क्लायंटचे नेटवर्क अखंडपणे स्विच करणे शक्य करेल; क्लायंट सत्रांसह कार्य पूर्वी निवडलेल्या समान बॅकएंडवर सुरू राहील.

योग्य ऑपरेशनसाठी, बॅलन्सरच्या स्त्रोत आयपी पत्त्याची समस्या ज्यामधून सत्र स्थापित केले गेले होते त्याचे निराकरण करणे आवश्यक आहे. आमच्या बाबतीत, हा लूपबॅक इंटरफेसवरील डायनॅमिक पत्ता आहे.

समवयस्कांचे योग्य कार्य केवळ विशिष्ट परिस्थितीतच साध्य केले जाते. म्हणजेच, TCP टाइमआउट पुरेसे मोठे असणे आवश्यक आहे किंवा स्विचिंग पुरेसे जलद असणे आवश्यक आहे जेणेकरून TCP सत्र समाप्त होण्यास वेळ नसेल. तथापि, ते अखंड स्विचिंगसाठी परवानगी देते.

IaaS मध्ये आमच्याकडे समान तंत्रज्ञान वापरून तयार केलेली सेवा आहे. या OpenStack साठी सेवा म्हणून बॅलन्सर लोड करा, ज्याला ऑक्टाव्हिया म्हणतात. हे दोन HAProxy प्रक्रियांवर आधारित आहे आणि सुरुवातीला समवयस्कांसाठी समर्थन समाविष्ट करते. त्यांनी या सेवेत स्वतःला उत्कृष्ट सिद्ध केले आहे.

चित्र योजनाबद्धपणे तीन HAProxy उदाहरणांमधील पीअर टेबलची हालचाल दर्शवते, हे कसे कॉन्फिगर केले जाऊ शकते यावर एक कॉन्फिगर प्रस्तावित आहे:

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

आपण समान योजना अंमलात आणल्यास, त्याच्या ऑपरेशनची काळजीपूर्वक चाचणी करणे आवश्यक आहे. हे 100% वेळेत त्याच प्रकारे कार्य करेल हे तथ्य नाही. परंतु जेव्हा तुम्हाला क्लायंटचा स्त्रोत आयपी लक्षात ठेवण्याची आवश्यकता असेल तेव्हा तुम्ही स्टिक टेबल गमावणार नाही.

एकाच क्लायंटकडून एकाचवेळी येणाऱ्या विनंत्यांची संख्या मर्यादित करणे

आमच्या API सह सार्वजनिकरीत्या उपलब्ध असलेल्या कोणत्याही सेवा, विनंत्यांच्या हिमस्खलनाच्या अधीन असू शकतात. त्यांची कारणे पूर्णपणे भिन्न असू शकतात, वापरकर्ता त्रुटींपासून लक्ष्यित हल्ल्यांपर्यंत. आम्ही वेळोवेळी IP पत्त्यांद्वारे DDoSed आहोत. क्लायंट अनेकदा त्यांच्या स्क्रिप्टमध्ये चुका करतात आणि आम्हाला मिनी-डीडीओएस देतात.

एक मार्ग किंवा दुसरा, अतिरिक्त संरक्षण प्रदान करणे आवश्यक आहे. एपीआय विनंत्यांची संख्या मर्यादित करणे आणि दुर्भावनापूर्ण विनंत्यांवर प्रक्रिया करण्यात CPU वेळ वाया घालवणे हा स्पष्ट उपाय आहे.

अशा निर्बंधांची अंमलबजावणी करण्यासाठी, आम्ही समान स्टिक टेबल वापरून, HAProxy च्या आधारावर आयोजित केलेल्या दर मर्यादा वापरतो. मर्यादा सेट करणे अगदी सोपे आहे आणि तुम्हाला API च्या विनंत्यांच्या संख्येनुसार वापरकर्त्याला मर्यादित करण्याची अनुमती देते. अल्गोरिदम स्त्रोत आयपी लक्षात ठेवतो ज्यावरून विनंत्या केल्या जातात आणि एका वापरकर्त्याकडून एकाचवेळी विनंत्यांची संख्या मर्यादित करते. अर्थात, आम्ही प्रत्येक सेवेसाठी सरासरी API लोड प्रोफाइलची गणना केली आणि या मूल्याच्या 10 पट ≈ मर्यादा सेट केली. आम्ही परिस्थितीचे बारकाईने निरीक्षण करणे सुरू ठेवतो आणि नाडीवर बोट ठेवतो.

हे सराव मध्ये कसे दिसते? आमच्याकडे असे ग्राहक आहेत जे आमचे ऑटोस्केलिंग API नेहमी वापरतात. ते सकाळी अंदाजे दोन ते तीनशे व्हर्च्युअल मशीन तयार करतात आणि संध्याकाळी हटवतात. OpenStack साठी, PaaS सेवांसह व्हर्च्युअल मशीन तयार करण्यासाठी किमान 1000 API विनंत्या आवश्यक आहेत, कारण सेवांमधील परस्परसंवाद API द्वारे देखील होतो.

कार्यांच्या अशा हस्तांतरणामुळे बर्‍यापैकी मोठा भार होतो. आम्ही या भाराचे मूल्यांकन केले, दैनंदिन शिखरे गोळा केली, ती दहापट वाढवली आणि ही आमची दर मर्यादा बनली. आपण नाडीवर बोट ठेवतो. आम्ही अनेकदा बॉट्स आणि स्कॅनर पाहतो जे आमच्याकडे चालवता येतील अशा CGA स्क्रिप्ट्स आहेत की नाही हे पाहण्याचा प्रयत्न करत आहेत, आम्ही त्यांना सक्रियपणे कापत आहोत.

वापरकर्त्यांच्या लक्षात न येता तुमचा कोडबेस कसा अपडेट करायचा

आम्ही कोड उपयोजन प्रक्रियेच्या स्तरावर दोष सहिष्णुता देखील लागू करतो. रोलआउट्स दरम्यान त्रुटी असू शकतात, परंतु सेवा उपलब्धतेवर त्यांचा प्रभाव कमी केला जाऊ शकतो.

आम्ही आमच्या सेवा सतत अद्यतनित करतो आणि वापरकर्त्यांना प्रभावित न करता कोडबेस अद्यतनित केला आहे याची खात्री करणे आवश्यक आहे. HAProxy च्या व्यवस्थापन क्षमता आणि आमच्या सेवांमध्ये Graceful Shutdown च्या अंमलबजावणीचा वापर करून आम्ही ही समस्या सोडवण्यात व्यवस्थापित केले.

या समस्येचे निराकरण करण्यासाठी, बॅलन्सरचे नियंत्रण आणि सेवांचे "योग्य" शटडाउन सुनिश्चित करणे आवश्यक होते:

• HAProxy च्या बाबतीत, नियंत्रण आकडेवारी फाइलद्वारे केले जाते, जे मूलत: एक सॉकेट आहे आणि HAProxy कॉन्फिगरेशनमध्ये परिभाषित केले आहे. तुम्ही त्याला stdio द्वारे कमांड पाठवू शकता. परंतु आमचे मुख्य कॉन्फिगरेशन नियंत्रण साधन उत्तरदायी आहे, म्हणून त्यात HAProxy व्यवस्थापित करण्यासाठी अंगभूत मॉड्यूल आहे. जे आम्ही सक्रियपणे वापरतो.
• आमच्या बर्‍याच API आणि इंजिन सेवा आकर्षक शटडाउन तंत्रज्ञानास समर्थन देतात: बंद करताना, ते सध्याचे कार्य पूर्ण होण्याची प्रतीक्षा करतात, मग ती HTTP विनंती असो किंवा काही सेवा कार्य. कामगाराच्या बाबतीतही असेच घडते. तो करत असलेली सर्व कामे त्याला माहीत असते आणि ती यशस्वीपणे पूर्ण झाल्यावर ती संपते.

या दोन मुद्यांमुळे धन्यवाद, आमच्या उपयोजनासाठी सुरक्षित अल्गोरिदम असे दिसते.

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

हे उपयोजन पूर्ण करते.

सेवा अद्यतन चक्र

आमच्याकडे एकच नियम नसेल तर ही योजना चालणार नाही. आम्ही युद्धात जुन्या आणि नवीन दोन्ही आवृत्त्यांचे समर्थन करतो. आगाऊ, सॉफ्टवेअर डेव्हलपमेंटच्या टप्प्यावर, हे ठेवले आहे की सेवा डेटाबेसमध्ये बदल असले तरीही ते मागील कोड खंडित करणार नाहीत. परिणामी, कोड बेस हळूहळू अद्यतनित केला जातो.

निष्कर्ष

दोष-सहिष्णु WEB आर्किटेक्चरबद्दल माझे स्वतःचे विचार सामायिक करताना, मी पुन्हा एकदा त्याचे मुख्य मुद्दे लक्षात घेऊ इच्छितो:

• शारीरिक दोष सहिष्णुता;
• नेटवर्क दोष सहिष्णुता (संतुलन, बीजीपी);
• वापरलेल्या आणि विकसित केलेल्या सॉफ्टवेअरची दोष सहिष्णुता.

प्रत्येकजण स्थिर अपटाइम!

स्त्रोत: www.habr.com