वन-क्लाउड - Odnoklassniki में डेटा सेंटर स्तर का OS

अलोहा, लोग! मेरा नाम ओलेग अनास्तासयेव है, मैं प्लेटफ़ॉर्म टीम में ओडनोक्लास्निकी में काम करता हूँ। और मेरे अलावा, Odnoklassniki में बहुत सारे हार्डवेयर काम कर रहे हैं। हमारे पास लगभग 500 रैक वाले चार डेटा सेंटर और 8 हजार से अधिक सर्वर हैं। एक निश्चित बिंदु पर, हमने महसूस किया कि एक नई प्रबंधन प्रणाली की शुरूआत हमें उपकरणों को अधिक कुशलता से लोड करने, पहुंच प्रबंधन की सुविधा प्रदान करने, कंप्यूटिंग संसाधनों के (पुनः) वितरण को स्वचालित करने, नई सेवाओं के लॉन्च में तेजी लाने और प्रतिक्रियाओं में तेजी लाने की अनुमति देगी। बड़े पैमाने पर दुर्घटनाओं के लिए.

इससे क्या हुआ?

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

उपयोगकर्ता के अनुरोध मुख्य पोर्टल के दोनों मोर्चों पर प्राप्त होते हैं www.ok.ru, और अन्य पर, उदाहरण के लिए संगीत एपीआई मोर्चों पर। व्यावसायिक तर्क को संसाधित करने के लिए, वे एप्लिकेशन सर्वर को कॉल करते हैं, जो अनुरोध को संसाधित करते समय, आवश्यक विशिष्ट माइक्रोसर्विसेज को कॉल करता है - वन-ग्राफ (सामाजिक कनेक्शन का ग्राफ), उपयोगकर्ता-कैश (उपयोगकर्ता प्रोफाइल का कैश), आदि।

इनमें से प्रत्येक सेवा कई मशीनों पर तैनात की गई है, और उनमें से प्रत्येक में मॉड्यूल के कामकाज, उनके संचालन और तकनीकी विकास के लिए जिम्मेदार डेवलपर्स हैं। ये सभी सेवाएँ हार्डवेयर सर्वर पर चलती हैं, और हाल तक हमने प्रति सर्वर बिल्कुल एक कार्य लॉन्च किया था, यानी यह एक विशिष्ट कार्य के लिए विशिष्ट था।

ऐसा क्यों? इस दृष्टिकोण के कई फायदे थे:

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

कई प्रतिकृतियों से युक्त एक सेवा को कई सर्वर आवंटित किए जाते हैं - प्रत्येक के लिए एक। फिर सेवा के लिए कंप्यूटिंग संसाधन को बहुत सरलता से आवंटित किया जाता है: सेवा के पास जितने सर्वर हैं, वह संसाधनों की अधिकतम मात्रा का उपभोग कर सकता है। यहां "आसान" का मतलब यह नहीं है कि इसका उपयोग करना आसान है, बल्कि इस अर्थ में कि संसाधन आवंटन मैन्युअल रूप से किया जाता है।

इस दृष्टिकोण ने हमें ऐसा करने की अनुमति भी दी विशेष लौह विन्यास इस सर्वर पर चल रहे किसी कार्य के लिए। यदि कार्य बड़ी मात्रा में डेटा संग्रहीत करता है, तो हम 4 डिस्क वाले चेसिस वाले 38U सर्वर का उपयोग करते हैं। यदि कार्य पूरी तरह से कम्प्यूटेशनल है, तो हम एक सस्ता 1यू सर्वर खरीद सकते हैं। यह कम्प्यूटेशनल रूप से कुशल है. अन्य बातों के अलावा, यह दृष्टिकोण हमें एक अनुकूल सामाजिक नेटवर्क के बराबर लोड के साथ चार गुना कम मशीनों का उपयोग करने की अनुमति देता है।

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

यह महसूस करते हुए कि यह मामला था, हमने यह गणना करने का निर्णय लिया कि हम रैक का उपयोग कितने प्रभावी ढंग से कर रहे हैं।
हमने आर्थिक रूप से उचित सर्वरों में से सबसे शक्तिशाली सर्वर की कीमत ली, गणना की कि हम कितने ऐसे सर्वरों को रैक में रख सकते हैं, पुराने मॉडल "एक सर्वर = एक कार्य" के आधार पर हम उन पर कितने कार्य चलाएंगे और ऐसे कितने सर्वर कार्य उपकरण का उपयोग कर सकते हैं। उन्होंने गिनती की और आँसू बहाये। यह पता चला कि रैक का उपयोग करने में हमारी दक्षता लगभग 11% है। निष्कर्ष स्पष्ट है: हमें डेटा केंद्रों के उपयोग की दक्षता बढ़ाने की आवश्यकता है। ऐसा प्रतीत होता है कि समाधान स्पष्ट है: आपको एक सर्वर पर एक साथ कई कार्य चलाने की आवश्यकता है। लेकिन यहीं से मुश्किलें शुरू होती हैं।

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

लेकिन मुख्य बात यह है कि एक ही मशीन पर चल रहे कार्यों के बीच कोई अलगाव नहीं है। यहां, उदाहरण के लिए, एक ही सर्वर पर एक और कम्प्यूटेशनल एप्लिकेशन लॉन्च होने से पहले और बाद में सर्वर कार्य के औसत प्रतिक्रिया समय का एक ग्राफ है, जिसका पहले से कोई संबंध नहीं है - मुख्य कार्य का प्रतिक्रिया समय काफी बढ़ गया है।

जाहिर है, आपको कार्यों को या तो कंटेनरों में या वर्चुअल मशीनों में चलाने की आवश्यकता है। चूँकि हमारे लगभग सभी कार्य एक ही OS (लिनक्स) के अंतर्गत चलते हैं या उसके लिए अनुकूलित होते हैं, इसलिए हमें कई अलग-अलग ऑपरेटिंग सिस्टमों का समर्थन करने की आवश्यकता नहीं होती है। तदनुसार, वर्चुअलाइजेशन की आवश्यकता नहीं है; अतिरिक्त ओवरहेड के कारण, यह कंटेनरीकरण की तुलना में कम कुशल होगा।

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

साथ ही, डॉकर में एक रेडीमेड रजिस्ट्री और इमेज टैगिंग हमें वर्जनिंग और उत्पादन के लिए कोड वितरित करने के लिए रेडीमेड प्रिमिटिव प्रदान करती है।

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

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

जब आपके पास 8 हजार सर्वर और 8-16 हजार कंटेनर हों तो कंटेनरों को मैन्युअल रूप से वितरित करना कोई विकल्प नहीं है।

इसके अलावा, हम डेवलपर्स को संसाधन आवंटन में अधिक स्वतंत्रता देना चाहते थे ताकि वे प्रशासक की सहायता के बिना, उत्पादन में अपनी सेवाओं की मेजबानी कर सकें। साथ ही, हम नियंत्रण बनाए रखना चाहते थे ताकि कुछ छोटी सेवा हमारे डेटा केंद्रों के सभी संसाधनों का उपभोग न करें।

जाहिर है, हमें एक नियंत्रण परत की आवश्यकता है जो यह स्वचालित रूप से करेगी।

तो हम एक सरल और समझने योग्य चित्र पर आए जिसे सभी आर्किटेक्ट पसंद करते हैं: तीन वर्ग।

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

संसाधनों का आवंटन

आइए अब कई मिनियन के लिए अधिक जटिल संसाधन आवंटन की समस्या को देखें।

एक-क्लाउड में एक कंप्यूटिंग संसाधन है:

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

फिर कुछ सेवा के लिए, उदाहरण के लिए उपयोगकर्ता-कैश के लिए, हम उपभोग किए गए संसाधनों को इस तरह से रिकॉर्ड कर सकते हैं: 400 प्रोसेसर कोर, 2,5 टीबी मेमोरी, दोनों दिशाओं में 50 जीबीआईटी/एस ट्रैफिक, 6 स्पिंडल पर स्थित 100 टीबी एचडीडी स्पेस। या इस तरह अधिक परिचित रूप में:

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

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

आइए घटकों की परस्पर क्रिया के हमारे अत्यधिक सरलीकृत आरेख पर वापस लौटें और इसे अधिक विवरण के साथ फिर से बनाएं - इस तरह:

क्या ध्यान खींचता है:

• वेब फ्रंटएंड और संगीत एक ही एप्लिकेशन सर्वर के अलग-अलग क्लस्टर का उपयोग करते हैं।
• हम उन तार्किक परतों को अलग कर सकते हैं जिनसे ये क्लस्टर संबंधित हैं: फ्रंट, कैश, डेटा स्टोरेज और प्रबंधन परत।
• अग्रभाग विषमांगी है; इसमें विभिन्न कार्यात्मक उपप्रणालियाँ शामिल हैं।
• कैश को उस सबसिस्टम में भी फैलाया जा सकता है जिसका डेटा वे कैश करते हैं।

आइए चित्र को फिर से बनाएं:

बाह! हाँ, हम एक पदानुक्रम देखते हैं! इसका मतलब है कि आप संसाधनों को बड़े टुकड़ों में वितरित कर सकते हैं: कार्यात्मक उपप्रणाली (जैसे चित्र में "संगीत") के अनुरूप इस पदानुक्रम के एक नोड के लिए एक जिम्मेदार डेवलपर को नियुक्त करें, और पदानुक्रम के समान स्तर पर एक कोटा संलग्न करें। यह पदानुक्रम हमें प्रबंधन में आसानी के लिए सेवाओं को अधिक लचीले ढंग से व्यवस्थित करने की भी अनुमति देता है। उदाहरण के लिए, हम सभी वेब को विभाजित करते हैं, क्योंकि यह सर्वरों का एक बहुत बड़ा समूह है, कई छोटे समूहों में, चित्र में समूह 1, समूह 2 के रूप में दिखाया गया है।

अतिरिक्त पंक्तियों को हटाकर, हम अपने चित्र के प्रत्येक नोड को एक सपाट रूप में लिख सकते हैं: ग्रुप1.वेब.फ्रंट, एपीआई.म्यूजिक.फ्रंट, उपयोगकर्ता-कैश.कैश.

इस प्रकार हम "पदानुक्रमित कतार" की अवधारणा पर आते हैं। इसका नाम "group1.web.front" है। इसे संसाधनों और उपयोगकर्ता अधिकारों के लिए एक कोटा सौंपा गया है। हम DevOps के व्यक्ति को कतार में सेवा भेजने का अधिकार देंगे, और ऐसा कर्मचारी कतार में कुछ लॉन्च कर सकता है, और OpsDev के व्यक्ति के पास व्यवस्थापक अधिकार होंगे, और अब वह कतार का प्रबंधन कर सकता है, लोगों को वहां नियुक्त कर सकता है, इन लोगों को अधिकार दें, आदि। इस कतार पर चलने वाली सेवाएँ कतार के कोटा के भीतर चलेंगी। यदि कतार का कंप्यूटिंग कोटा सभी सेवाओं को एक साथ निष्पादित करने के लिए पर्याप्त नहीं है, तो उन्हें क्रमिक रूप से निष्पादित किया जाएगा, इस प्रकार कतार स्वयं बन जाएगी।

आइए सेवाओं पर करीब से नज़र डालें। किसी सेवा का एक पूर्णतः योग्य नाम होता है, जिसमें हमेशा कतार का नाम शामिल होता है। फिर फ्रंट वेब सर्विस का नाम होगा ok-web.group1.web.front. और यह जिस एप्लिकेशन सर्वर सेवा तक पहुंचता है उसे कॉल किया जाएगा ok-app.group1.web.front. प्रत्येक सेवा में एक मेनिफेस्ट होता है, जो विशिष्ट मशीनों पर प्लेसमेंट के लिए सभी आवश्यक जानकारी निर्दिष्ट करता है: यह कार्य कितने संसाधनों का उपभोग करता है, इसके लिए किस कॉन्फ़िगरेशन की आवश्यकता है, कितनी प्रतिकृतियां होनी चाहिए, इस सेवा की विफलताओं से निपटने के लिए गुण। और सेवा को सीधे मशीनों पर रखे जाने के बाद, इसके उदाहरण दिखाई देते हैं। उन्हें भी स्पष्ट रूप से नामित किया गया है - उदाहरण संख्या और सेवा नाम के रूप में: 1.ओके-वेब.ग्रुप1.वेब.फ्रंट, 2.ओके-वेब.ग्रुप1.वेब.फ्रंट,…

यह बहुत सुविधाजनक है: केवल चालू कंटेनर के नाम को देखकर, हम तुरंत बहुत कुछ पता लगा सकते हैं।

आइए अब करीब से देखें कि ये उदाहरण वास्तव में क्या करते हैं: कार्य।

कार्य अलगाव कक्षाएं

ओके में सभी कार्यों (और, शायद, हर जगह) को समूहों में विभाजित किया जा सकता है:

• लघु विलंबता कार्य - उत्पाद. ऐसे कार्यों और सेवाओं के लिए, प्रतिक्रिया विलंब (विलंबता) बहुत महत्वपूर्ण है, प्रत्येक अनुरोध को सिस्टम द्वारा कितनी जल्दी संसाधित किया जाएगा। कार्यों के उदाहरण: वेब फ्रंट, कैश, एप्लिकेशन सर्वर, ओएलटीपी स्टोरेज, आदि।
• गणना समस्याएँ - बैच. यहां, प्रत्येक विशिष्ट अनुरोध की प्रसंस्करण गति महत्वपूर्ण नहीं है। उनके लिए यह महत्वपूर्ण है कि यह कार्य एक निश्चित (लंबे) समयावधि (थ्रूपुट) में कितनी गणनाएँ करेगा। ये MapReduce, Hadoop, मशीन लर्निंग, सांख्यिकी का कोई भी कार्य होगा।
• पृष्ठभूमि कार्य - निष्क्रिय. ऐसे कार्यों के लिए, न तो विलंबता और न ही थ्रूपुट बहुत महत्वपूर्ण है। इसमें विभिन्न परीक्षण, माइग्रेशन, पुनर्गणना और डेटा का एक प्रारूप से दूसरे प्रारूप में रूपांतरण शामिल है। एक ओर, वे गणना के समान हैं, दूसरी ओर, हमारे लिए यह वास्तव में मायने नहीं रखता कि वे कितनी जल्दी पूरी हो जाती हैं।

आइए देखें कि ऐसे कार्य संसाधनों का उपभोग कैसे करते हैं, उदाहरण के लिए, केंद्रीय प्रोसेसर।

अल्प विलंब वाले कार्य। ऐसे कार्य में CPU खपत पैटर्न इसके समान होगा:

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

ऐसे कार्य के लिए न्यूनतम विलंबता की गारंटी के लिए, हमें इसके द्वारा उपभोग किए जाने वाले अधिकतम संसाधनों को लेना होगा और मिनियन (वह मशीन जो कार्य को निष्पादित करेगी) पर आवश्यक संख्या में कोर आरक्षित करना होगा। तब हमारी समस्या का आरक्षण फार्मूला इस प्रकार होगा:

alloc: cpu = 4 (max)

और यदि हमारे पास 16 कोर वाली एक मिनियन मशीन है, तो उस पर ऐसे ठीक चार कार्य रखे जा सकते हैं। हम विशेष रूप से ध्यान देते हैं कि ऐसे कार्यों की औसत प्रोसेसर खपत अक्सर बहुत कम होती है - जो स्पष्ट है, क्योंकि समय का एक महत्वपूर्ण हिस्सा कार्य अनुरोध की प्रतीक्षा करता है और कुछ नहीं करता है।

गणना कार्य. इनका पैटर्न थोड़ा अलग होगा:

ऐसे कार्यों के लिए औसत CPU संसाधन खपत काफी अधिक है। अक्सर हम चाहते हैं कि कोई गणना कार्य एक निश्चित समय में पूरा हो जाए, इसलिए हमें आवश्यक न्यूनतम संख्या में प्रोसेसर आरक्षित करने की आवश्यकता होती है ताकि पूरी गणना स्वीकार्य समय में पूरी हो जाए। इसका आरक्षण फार्मूला इस प्रकार होगा:

alloc: cpu = [1,*)

"कृपया इसे एक मिनियन पर रखें जहां कम से कम एक मुक्त कोर हो, और फिर जितने भी होंगे, यह सब कुछ निगल जाएगा।"

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

लेकिन यह कैसे करें?

सबसे पहले, आइए उत्पाद और उसके आवंटन को देखें: सीपीयू = 4। हमें चार कोर आरक्षित करने की आवश्यकता है। डॉकर रन में यह दो तरीकों से किया जा सकता है:

• विकल्प का उपयोग करना --cpuset=1-4, यानी कार्य के लिए मशीन पर चार विशिष्ट कोर आवंटित करें।
• उपयोग करने के लिए --cpuquota=400_000 --cpuperiod=100_000, प्रोसेसर समय के लिए एक कोटा निर्दिष्ट करें, यानी इंगित करें कि वास्तविक समय के प्रत्येक 100 एमएस कार्य में 400 एमएस से अधिक प्रोसेसर समय की खपत नहीं होती है। वही चार कोर प्राप्त होते हैं।

लेकिन इनमें से कौन सा तरीका उपयुक्त है?

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

आइए जानें कि कोर की न्यूनतम संख्या के आधार पर डॉकर में आरक्षण कैसे किया जाए। बैच कार्यों के लिए कोटा अब लागू नहीं है, क्योंकि अधिकतम को सीमित करने की कोई आवश्यकता नहीं है, यह केवल न्यूनतम की गारंटी देने के लिए पर्याप्त है। और यहां विकल्प बिल्कुल फिट बैठता है docker run --cpushares.

हम इस बात पर सहमत हुए कि यदि किसी बैच को कम से कम एक कोर के लिए गारंटी की आवश्यकता है, तो हम संकेत देते हैं --cpushares=1024, और यदि कम से कम दो कोर हैं, तो हम संकेत देते हैं --cpushares=2048. सीपीयू शेयर किसी भी तरह से प्रोसेसर समय के वितरण में हस्तक्षेप नहीं करते हैं जब तक कि यह पर्याप्त है। इस प्रकार, यदि उत्पाद वर्तमान में अपने सभी चार कोर का उपयोग नहीं कर रहा है, तो बैच कार्यों को सीमित करने के लिए कुछ भी नहीं है, और वे अतिरिक्त प्रोसेसर समय का उपयोग कर सकते हैं। लेकिन ऐसी स्थिति में जहां प्रोसेसर की कमी है, यदि उत्पाद ने अपने सभी चार कोर का उपभोग कर लिया है और अपने कोटा तक पहुंच गया है, तो शेष प्रोसेसर समय आनुपातिक रूप से सीपुशेयर में विभाजित किया जाएगा, यानी तीन मुक्त कोर की स्थिति में, एक होगा 1024 सीपीशेयर वाले कार्य को दिया जाएगा, और शेष दो को 2048 सीपीशेयर वाले कार्य को दिया जाएगा।

लेकिन कोटा और शेयरों का उपयोग करना पर्याप्त नहीं है। हमें यह सुनिश्चित करने की ज़रूरत है कि प्रोसेसर समय आवंटित करते समय कम देरी वाले कार्य को बैच कार्य पर प्राथमिकता मिले। ऐसी प्राथमिकता के बिना, बैच कार्य उस समय प्रोसेसर का सारा समय ले लेगा जब उत्पाद को इसकी आवश्यकता होगी। डॉकर रन में कोई कंटेनर प्राथमिकता विकल्प नहीं हैं, लेकिन लिनक्स सीपीयू शेड्यूलर नीतियां काम में आती हैं। आप इनके बारे में विस्तार से पढ़ सकते हैं यहां, और इस लेख के ढांचे के भीतर हम संक्षेप में उनके बारे में जानेंगे:

• अनुसूची_अन्य
  डिफ़ॉल्ट रूप से, लिनक्स मशीन पर सभी सामान्य उपयोगकर्ता प्रक्रियाएँ प्राप्त होती हैं।
• SCHED_BATCH
  संसाधन-गहन प्रक्रियाओं के लिए डिज़ाइन किया गया। किसी कार्य को प्रोसेसर पर रखते समय, एक तथाकथित सक्रियण दंड पेश किया जाता है: ऐसे कार्य को प्रोसेसर संसाधन प्राप्त होने की संभावना कम होती है यदि इसे वर्तमान में SCHED_OTHER वाले कार्य द्वारा उपयोग किया जा रहा हो
• SCHED_IDLE
  बहुत कम प्राथमिकता वाली एक पृष्ठभूमि प्रक्रिया, यहां तक ​​कि अच्छे -19 से भी कम। हम अपनी ओपन सोर्स लाइब्रेरी का उपयोग करते हैं एक-एनआईओ, कॉल करके कंटेनर शुरू करते समय आवश्यक नीति निर्धारित करने के लिए

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

लेकिन भले ही आप जावा में प्रोग्राम न करें, वही काम chrt कमांड का उपयोग करके किया जा सकता है:

chrt -i 0 $pid

आइए स्पष्टता के लिए अपने सभी अलगाव स्तरों को एक तालिका में संक्षेपित करें:

इन्सुलेशन वर्ग
आवंटन उदाहरण
डॉकर रन विकल्प
शेड्यूल_सेट शेड्यूलर chrt*

ठेस
सीपीयू = 4
--cpuquota=400000 --cpuperiod=100000
अनुसूची_अन्य

बैच
सीपीयू = [1,*)
--cpushares=1024
SCHED_BATCH

निष्क्रिय
सीपीयू= [2, *)
--cpushares=2048
SCHED_IDLE

*यदि आप किसी कंटेनर के अंदर से chrt कर रहे हैं, तो आपको sys_nice क्षमता की आवश्यकता हो सकती है, क्योंकि कंटेनर शुरू करते समय डिफ़ॉल्ट रूप से डॉकर इस क्षमता को हटा देता है।

लेकिन कार्य न केवल प्रोसेसर का उपभोग करते हैं, बल्कि ट्रैफ़िक का भी उपभोग करते हैं, जो प्रोसेसर संसाधनों के गलत आवंटन से भी अधिक नेटवर्क कार्य की विलंबता को प्रभावित करता है। इसलिए, हम स्वाभाविक रूप से ट्रैफ़िक के लिए बिल्कुल वही तस्वीर प्राप्त करना चाहते हैं। अर्थात्, जब कोई उत्पाद कार्य नेटवर्क पर कुछ पैकेट भेजता है, तो हम अधिकतम गति (सूत्र) को सीमित कर देते हैं आवंटन: lan=[*,500mbps) ), किस उत्पाद के साथ ऐसा कर सकते हैं। और बैच के लिए हम केवल न्यूनतम थ्रूपुट की गारंटी देते हैं, लेकिन अधिकतम (सूत्र) को सीमित नहीं करते हैं आवंटन: lan=[10एमबीपीएस,*) ) इस मामले में, उत्पाद ट्रैफ़िक को बैच कार्यों पर प्राथमिकता मिलनी चाहिए।
यहां डॉकर के पास कोई प्रिमिटिव नहीं है जिसका हम उपयोग कर सकें। लेकिन यह हमारी सहायता के लिए आता है लिनक्स यातायात नियंत्रण. अनुशासन की मदद से हम वांछित परिणाम हासिल करने में सफल रहे।' पदानुक्रमित निष्पक्ष सेवा वक्र. इसकी मदद से, हम ट्रैफ़िक के दो वर्गों को अलग करते हैं: उच्च-प्राथमिकता वाला उत्पाद और निम्न-प्राथमिकता वाला बैच/निष्क्रिय। परिणामस्वरूप, आउटगोइंग ट्रैफ़िक के लिए कॉन्फ़िगरेशन इस प्रकार है:

यहां 1:0 एचएसएफसी अनुशासन का "रूट क्यूडिस्क" है; 1:1 - 8 Gbit/s की कुल बैंडविड्थ सीमा के साथ एचएसएफसी चाइल्ड क्लास, जिसके अंतर्गत सभी कंटेनरों की चाइल्ड क्लासें रखी गई हैं; 1:2 - एचएसएफसी चाइल्ड क्लास "डायनामिक" सीमा के साथ सभी बैच और निष्क्रिय कार्यों के लिए सामान्य है, जिसकी चर्चा नीचे की गई है। शेष एचएसएफसी चाइल्ड कक्षाएं वर्तमान में चल रहे उत्पाद कंटेनरों के लिए समर्पित कक्षाएं हैं जिनकी सीमाएं उनके मैनिफ़ेस्ट - 450 और 400 एमबीपीएस के अनुरूप हैं। ट्रैफ़िक फटने के दौरान पैकेट हानि से बचने के लिए, प्रत्येक एचएसएफसी वर्ग को लिनक्स कर्नेल संस्करण के आधार पर एक qdisc कतार fq या fq_codel सौंपा गया है।

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

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

आने वाले और बाहर जाने वाले ट्रैफ़िक के लिए बैंड स्वतंत्र रूप से परिभाषित किए गए हैं। और नए मूल्यों के अनुसार, मिनियनड गैर-प्राथमिकता वर्ग सीमा 1:2 को पुन: कॉन्फ़िगर करता है।

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

हमारे सभी दोस्त वेब и संगीत फिर मोर्चों को उत्पाद के अंतर्गत पदानुक्रम में रखा जाता है। उदाहरण के लिए, बैच के अंतर्गत, आइए सेवा को रखें संगीत सूची, जो समय-समय पर Odnoklassniki पर अपलोड की गई एमपी3 फ़ाइलों के एक सेट से ट्रैक की एक सूची संकलित करता है। निष्क्रियता के अंतर्गत सेवा का एक उदाहरण होगा संगीत ट्रांसफार्मर, जो संगीत की मात्रा के स्तर को सामान्य करता है।

अतिरिक्त पंक्तियों को फिर से हटाकर, हम पूर्ण सेवा नाम के अंत में कार्य अलगाव वर्ग जोड़कर अपने सेवा नाम को बेहतर ढंग से लिख सकते हैं: वेब.फ्रंट.प्रोड, कैटलॉग.संगीत.बैच, ट्रांसफार्मर.संगीत.निष्क्रिय.

और अब, सेवा के नाम को देखते हुए, हम न केवल यह समझते हैं कि यह क्या कार्य करता है, बल्कि इसका अलगाव वर्ग, जिसका अर्थ है इसकी गंभीरता, आदि भी।

सब कुछ बढ़िया है, लेकिन एक कड़वा सच है। एक मशीन पर चल रहे कार्यों को पूरी तरह से अलग करना असंभव है।

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

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

इसके अलावा, हम अब तक केवल टीसीपी ट्रैफ़िक को प्राथमिकता देने की समस्या को हल करने में कामयाब रहे हैं: एचएसएफसी दृष्टिकोण यूडीपी के लिए काम नहीं करता है। और टीसीपी ट्रैफ़िक के मामले में भी, यदि बैच कार्य बहुत अधिक ट्रैफ़िक उत्पन्न करता है, तो इससे उत्पाद कार्य की देरी में लगभग 10% की वृद्धि भी होती है।

दोष सहिष्णुता

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

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

दूसरी संभावित समस्या कंटेनर का गिरना है। और यहां पुनरारंभ नीतियां हमें बचाती हैं, हर कोई उन्हें जानता है, डॉकर स्वयं बहुत अच्छा काम करता है। लगभग सभी उत्पाद कार्यों में हमेशा पुनरारंभ नीति होती है। कभी-कभी हम बैच कार्यों के लिए या उत्पाद कंटेनरों को डीबग करने के लिए on_failure का उपयोग करते हैं।

यदि संपूर्ण मिनियन अनुपलब्ध हो तो आप क्या कर सकते हैं?

जाहिर है, कंटेनर को दूसरी मशीन पर चलाएं। यहां दिलचस्प बात यह है कि कंटेनर को दिए गए आईपी पते का क्या होता है।

हम कंटेनरों को मिनियन मशीनों के समान आईपी पते निर्दिष्ट कर सकते हैं जिन पर ये कंटेनर चलते हैं। फिर, जब कंटेनर को किसी अन्य मशीन पर लॉन्च किया जाता है, तो उसका आईपी पता बदल जाता है, और सभी ग्राहकों को यह समझना चाहिए कि कंटेनर स्थानांतरित हो गया है, और अब उन्हें एक अलग पते पर जाने की आवश्यकता है, जिसके लिए एक अलग सेवा डिस्कवरी सेवा की आवश्यकता होती है।

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

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

एक-क्लाउड में, आईपी कंटेनर का अनुसरण करता है, यानी प्रत्येक कार्य उदाहरण का अपना आईपी पता होता है। यह पता "स्थैतिक" है: जब सेवा पहली बार क्लाउड पर भेजी जाती है तो यह प्रत्येक उदाहरण को सौंपा जाता है। यदि किसी सेवा के जीवनकाल के दौरान अलग-अलग संख्या में इंस्टेंस थे, तो अंत में उसे उतने ही आईपी पते सौंपे जाएंगे जितने अधिकतम इंस्टेंस थे।

इसके बाद, ये पते नहीं बदलते हैं: उन्हें एक बार सौंपा जाता है और उत्पादन में सेवा के पूरे जीवन भर मौजूद रहते हैं। आईपी ​​पते पूरे नेटवर्क में कंटेनरों का अनुसरण करते हैं। यदि कंटेनर को किसी अन्य मिनियन में स्थानांतरित किया जाता है, तो पता उसका अनुसरण करेगा।

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

कंटेनरों के पीछे ऐसे आईपी ट्रांसफर को लागू करना गैर-तुच्छ हो सकता है - और हम निम्नलिखित उदाहरण के साथ देखेंगे कि यह कैसे काम करता है:

मान लीजिए कि वन-क्लाउड मास्टर मिनियन एम1 को चलने का आदेश देता है 1.ओके-वेब.ग्रुप1.वेब.फ्रंट.प्रोड पते 1.1.1.1 के साथ। मिनियन पर काम करता है चिड़िया, जो इस पते को विशेष सर्वरों पर विज्ञापित करता है मार्ग परावर्तक. उत्तरार्द्ध में नेटवर्क हार्डवेयर के साथ एक बीजीपी सत्र होता है, जिसमें एम1.1.1.1 पर पते 1 का मार्ग अनुवादित किया जाता है। M1 Linux का उपयोग करके पैकेट को कंटेनर के अंदर रूट करता है। तीन रूट रिफ्लेक्टर सर्वर हैं, क्योंकि यह वन-क्लाउड इंफ्रास्ट्रक्चर का एक बहुत ही महत्वपूर्ण हिस्सा है - उनके बिना, वन-क्लाउड में नेटवर्क काम नहीं करेगा। हम उन्हें एक ही समय में तीनों के विफल होने की संभावना को कम करने के लिए, यदि संभव हो तो डेटा सेंटर के विभिन्न कमरों में स्थित अलग-अलग रैक में रखते हैं।

आइए अब मान लें कि वन-क्लाउड मास्टर और एम1 मिनियन के बीच कनेक्शन टूट गया है। वन-क्लाउड मास्टर अब इस धारणा पर कार्य करेगा कि M1 पूरी तरह से विफल हो गया है। यानी यह एम2 मिनियन को लॉन्च करने का कमांड देगा वेब.ग्रुप1.वेब.फ्रंट.प्रोड उसी पते के साथ 1.1.1.1. अब हमारे पास 1.1.1.1 के लिए नेटवर्क पर दो परस्पर विरोधी मार्ग हैं: एम1 पर और एम2 पर। ऐसे विवादों को हल करने के लिए, हम मल्टी एग्जिट डिस्क्रिमिनेटर का उपयोग करते हैं, जो बीजीपी घोषणा में निर्दिष्ट है। यह एक संख्या है जो विज्ञापित मार्ग का महत्व दर्शाती है। परस्पर विरोधी मार्गों में से, कम MED मान वाले मार्ग का चयन किया जाएगा। वन-क्लाउड मास्टर कंटेनर आईपी पते के अभिन्न अंग के रूप में एमईडी का समर्थन करता है। पहली बार, पता पर्याप्त रूप से बड़े MED = 1 के साथ लिखा गया है। ऐसे आपातकालीन कंटेनर स्थानांतरण की स्थिति में, मास्टर MED को कम कर देता है, और M000 को पहले से ही पते 000 को MED = के साथ विज्ञापित करने का आदेश प्राप्त हो जाएगा। 2। एम1.1.1.1 पर चलने वाला इंस्टेंस वहीं रहेगा, इस मामले में कोई कनेक्शन नहीं है, और उसके आगे के भाग्य में हमें तब तक कोई दिलचस्पी नहीं है जब तक कि मास्टर के साथ कनेक्शन बहाल नहीं हो जाता, जब उसे पुराने टेक की तरह रोक दिया जाएगा।

दुर्घटना

सभी डेटा सेंटर प्रबंधन प्रणालियाँ हमेशा छोटी विफलताओं को स्वीकार्य रूप से संभालती हैं। कंटेनर ओवरफ़्लो लगभग हर जगह सामान्य बात है।

आइए देखें कि हम किसी आपात स्थिति से कैसे निपटते हैं, जैसे डेटा सेंटर के एक या अधिक कमरों में बिजली की विफलता।

डेटा सेंटर प्रबंधन प्रणाली के लिए दुर्घटना का क्या मतलब है? सबसे पहले, यह कई मशीनों की एक बार की भारी विफलता है, और नियंत्रण प्रणाली को एक ही समय में कई कंटेनरों को स्थानांतरित करने की आवश्यकता होती है। लेकिन यदि आपदा बहुत बड़े पैमाने पर है, तो ऐसा हो सकता है कि सभी कार्यों को अन्य मिनियन को फिर से आवंटित नहीं किया जा सकता है, क्योंकि डेटा सेंटर की संसाधन क्षमता लोड के 100% से नीचे चली जाती है।

अक्सर दुर्घटनाएँ नियंत्रण परत की विफलता के साथ होती हैं। यह इसके उपकरण की विफलता के कारण हो सकता है, लेकिन अधिक बार इस तथ्य के कारण कि दुर्घटनाओं का परीक्षण नहीं किया जाता है, और बढ़ते भार के कारण नियंत्रण परत स्वयं गिर जाती है।

आप इस सब के बारे में क्या कर सकते हैं?

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

आइए उन सेवाओं के पदानुक्रम पर फिर से नज़र डालें जिनसे हम परिचित हैं और यह तय करने का प्रयास करें कि हम कौन से कार्य पहले चलाना चाहते हैं।

बेशक, ये ऐसी प्रक्रियाएं हैं जो सीधे तौर पर उपयोगकर्ता के अनुरोधों को संसाधित करने में शामिल होती हैं, यानी उत्पाद। हम इसे इसके साथ इंगित करते हैं प्लेसमेंट प्राथमिकता - एक संख्या जिसे कतार को सौंपा जा सकता है। यदि किसी कतार की प्राथमिकता अधिक है, तो उसकी सेवाओं को पहले रखा जाता है।

उत्पाद पर हम उच्च प्राथमिकताएँ निर्दिष्ट करते हैं, 0; बैच पर - थोड़ा कम, 100; निष्क्रिय पर - और भी कम, 200। प्राथमिकताएँ पदानुक्रमिक रूप से लागू की जाती हैं। पदानुक्रम में नीचे के सभी कार्यों की एक समान प्राथमिकता होगी। यदि हम चाहते हैं कि प्रोडक्ट के अंदर कैश को फ्रंटएंड से पहले लॉन्च किया जाए, तो हम कैश = 0 और फ्रंट सबक्यू को प्राथमिकता देते हैं = 1। यदि, उदाहरण के लिए, हम चाहते हैं कि मुख्य पोर्टल को पहले फ्रंट से लॉन्च किया जाए, और केवल म्यूजिक फ्रंट से। तब, तब हम बाद वाले को कम प्राथमिकता दे सकते हैं - 10।

अगली समस्या संसाधनों की कमी है. इसलिए, बड़ी मात्रा में उपकरण, डेटा सेंटर के पूरे हॉल विफल हो गए, और हमने इतनी सारी सेवाओं को फिर से लॉन्च किया कि अब सभी के लिए पर्याप्त संसाधन नहीं हैं। आपको यह तय करना होगा कि मुख्य महत्वपूर्ण सेवाओं को चालू रखने के लिए किन कार्यों का त्याग करना है।

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

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

संपूर्ण डीसी दुर्घटनाएँ

संपूर्ण डेटा सेंटर विफल क्यों हो सकता है? तत्व। अच्छी पोस्ट थी तूफान ने डेटा सेंटर के काम को प्रभावित किया. तत्वों को उन बेघर लोगों के रूप में माना जा सकता है जिन्होंने एक बार मैनिफोल्ड में ऑप्टिक्स को जला दिया था, और डेटा सेंटर का अन्य साइटों से संपर्क पूरी तरह से टूट गया था। विफलता का कारण मानवीय कारक भी हो सकता है: ऑपरेटर ऐसा आदेश जारी करेगा कि पूरा डेटा सेंटर गिर जाएगा। ऐसा किसी बड़े बग के कारण हो सकता है. सामान्य तौर पर, डेटा केंद्रों का ढहना असामान्य नहीं है। ऐसा हमारे साथ हर कुछ महीनों में एक बार होता है।

और यही हम किसी को भी #जीवित ट्वीट करने से रोकने के लिए करते हैं।

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

यह दृष्टिकोण न केवल शारीरिक विफलता से बचाता है, बल्कि ऑपरेटर त्रुटि से भी रक्षा कर सकता है।

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

परिणाम

एक-बादल की विशिष्ट विशेषताएं:

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

सामान्य प्रश्न

हमने रेडीमेड समाधान क्यों नहीं लिया?

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

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

अंतिम पंक्तियाँ पढ़ने वालों को, आपके धैर्य और ध्यान के लिए धन्यवाद!

स्रोत: www.habr.com