ट्यूपरवेयर: फेसबुक किलर कुबेरनेट्स?

Tupperware के साथ किसी भी पैमाने पर कुशल और विश्वसनीय क्लस्टर प्रबंधन

आज सिस्टम @Scale सम्मेलन में, हमने Tupperware को पेश किया, हमारी क्लस्टर प्रबंधन प्रणाली जो लाखों सर्वरों पर कंटेनरों को ऑर्केस्ट्रेट करती है, जहाँ लगभग हमारी सभी सेवाएँ काम करती हैं। हमने पहली बार 2011 में Tupperware लॉन्च किया था और तब से हमारा इन्फ्रास्ट्रक्चर 1 डेटा सेंटर से बढ़कर 15 जियो-डिस्ट्रिब्यूटेड डेटा सेंटर बन गया है । यह सब समय ट्यूपरवेयर अभी भी खड़ा नहीं हुआ और हमारे साथ विकसित हुआ। हम आपको बताएंगे कि ट्यूपरवेयर किस स्थिति में प्रथम श्रेणी क्लस्टर प्रबंधन प्रदान करता है, जिसमें राज्य सेवाओं के लिए सुविधाजनक समर्थन, सभी डेटा केंद्रों के लिए एक एकल नियंत्रण कक्ष और वास्तविक समय में सेवाओं के बीच बिजली वितरित करने की क्षमता शामिल है। और हम उन सबक को साझा करेंगे जो हमने सीखा था कि हमारे बुनियादी ढांचे का विकास हुआ।

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

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

टपरवेयर आर्किटेक्चर

आर्किटेक्चर Tupperware PRN हमारे डेटा केंद्रों के क्षेत्रों में से एक है। इस क्षेत्र में आसपास स्थित कई डेटा सेंटर भवन (PRN1 और PRN2) हैं। हम एक नियंत्रण कक्ष बनाने की योजना बनाते हैं जो एक क्षेत्र में सभी सर्वरों का प्रबंधन करेगा।

एप्लिकेशन डेवलपर्स Tupperware नौकरियों के रूप में सेवाएं प्रदान करते हैं। एक कार्य में कई कंटेनर होते हैं, और वे सभी आमतौर पर एक ही एप्लिकेशन कोड निष्पादित करते हैं।

Tupperware कंटेनर प्रोविजनिंग और जीवनचक्र प्रबंधन के लिए जिम्मेदार है। इसमें कई घटक होते हैं:

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

ट्यूपरवेयर की विशिष्ट विशेषताएं

ट्यूपरवेयर अन्य क्लस्टर प्रबंधन प्रणालियों के समान है, जैसे कुबेरनेट और मेसोस, लेकिन कुछ अंतर हैं:

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

हमने एक विशाल वैश्विक साझा सर्वर पार्क में विभिन्न स्टेटलेस और स्टेटफुल एप्लिकेशन का समर्थन करने के लिए इन शांत विशेषताओं को डिज़ाइन किया है।

राज्य सेवाओं के लिए मूल समर्थन।

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

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

टास्ककंट्रोल इंटरफ़ेस स्टेटफुल सेवाओं को डेटा उपलब्धता को प्रभावित करने वाले निर्णयों को प्रभावित करने की अनुमति देता है। इस इंटरफ़ेस का उपयोग करके, शेड्यूलर कंटेनर संचालन (पुनरारंभ, अद्यतन, माइग्रेशन, रखरखाव) के बाहरी अनुप्रयोगों को सूचित करता है। स्टेटफुल सेवा एक नियंत्रक को लागू करती है जो प्रत्येक ऑपरेशन को सुरक्षित रूप से किए जाने पर ट्यूपरवेयर को बताता है, और इन ऑपरेशनों को स्वैप या अस्थायी रूप से देरी हो सकती है। उपरोक्त उदाहरण में, डेटाबेस नियंत्रक ट्यूपरवेयर को 50 सर्वरों में से 49 को अपग्रेड करने का निर्देश दे सकता है, लेकिन अब तक किसी विशिष्ट सर्वर (एक्स) को नहीं छूता है। परिणामस्वरूप, यदि कर्नेल अद्यतन अवधि गुजरती है, और डेटाबेस अभी भी समस्या प्रतिकृति को पुनर्स्थापित नहीं कर सकता है, तो Tupperware अभी भी X सर्वर को अपग्रेड करेगा।

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

डेटा केंद्रों में सर्वर प्रबंधन

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

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

संपूर्ण वैश्विक प्रणाली का समर्थन करने के लिए स्केलिंग

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

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

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

लोचदार कंप्यूटिंग के साथ उपयोग में सुधार

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

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

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

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

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

सबक सीखा और भविष्य की योजनाएं

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

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

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