Tupperware: फेसबुकको Kubernetes हत्यारा?

Tupperware सँग कुनै पनि स्केलमा क्लस्टरहरूको कुशल र भरपर्दो व्यवस्थापन

आज मा प्रणाली @ स्केल सम्मेलन हामीले Tupperware को परिचय दियौं, हाम्रो क्लस्टर व्यवस्थापन प्रणाली जसले हाम्रा लगभग सबै सेवाहरू चलाउने लाखौं सर्भरहरूमा कन्टेनरहरू अर्केस्ट्रेट गर्छ। हामीले पहिलो पटक २०११ मा Tupperware प्रयोग गर्यौं, र त्यसबेलादेखि हाम्रो पूर्वाधार बढेको छ। १ डाटा सेन्टर सम्पूर्ण सम्म 15 भू-वितरित डाटा केन्द्रहरू। यो सबै समय, Tupperware स्थिर खडा भएन र हामी संग विकसित। हामी तपाइँलाई देखाउने छौँ कि Tupperware ले कसरी पहिलो श्रेणीको क्लस्टर व्यवस्थापन प्रदान गर्दछ, जसमा स्टेटफुल सेवाहरूको लागि सुविधाजनक समर्थन, सबै डेटा केन्द्रहरूको लागि एकल नियन्त्रण प्यानल, र वास्तविक समयमा सेवाहरू बीच क्षमता वितरण गर्ने क्षमता समावेश छ। हामीले हाम्रो पूर्वाधारको विकाससँगै सिकेका पाठहरू पनि साझा गर्नेछौं।

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

क्षमता योजना इन्जिनियरहरूले बजेट र अवरोधहरूमा आधारित टोलीहरूलाई सर्भर क्षमता आवंटित गर्न Tupperware प्रयोग गर्छन्। तिनीहरूले यसलाई सर्भर उपयोग सुधार गर्न पनि प्रयोग गर्छन्। डाटा सेन्टर अपरेटरहरू टुपरवेयरमा जान्छन् कन्टेनरहरूलाई डाटा केन्द्रहरूमा ठीकसँग वितरण गर्न र मर्मतका क्रममा कन्टेनरहरू रोक्न वा सार्न। यसका लागि धन्यवाद, सर्भरहरू, नेटवर्कहरू र उपकरणहरू कायम राख्न न्यूनतम मानव हस्तक्षेप चाहिन्छ।

Tupperware वास्तुकला

Tupperware PRN आर्किटेक्चर हाम्रो डेटा केन्द्रहरूको क्षेत्रहरू मध्ये एक हो। यस क्षेत्रमा नजिकै अवस्थित धेरै डाटा केन्द्र भवनहरू (PRN1 र PRN2) छन्। हामी एउटा कन्ट्रोल प्यानल बनाउने योजना गर्छौं जसले एउटै क्षेत्रमा सबै सर्भरहरू व्यवस्थापन गर्नेछ।

अनुप्रयोग विकासकर्ताहरूले Tupperware कार्यहरूको रूपमा सेवाहरू प्रदान गर्छन्। एउटा कामले धेरै कन्टेनरहरू समावेश गर्दछ, र ती सबै सामान्यतया एउटै अनुप्रयोग कोड चलाउँछन्।

Tupperware कन्टेनरहरू प्रावधान गर्न र तिनीहरूको जीवनचक्र व्यवस्थापन गर्न जिम्मेवार छ। यसले धेरै घटकहरू समावेश गर्दछ:

• Tupperware फ्रन्टएन्डले प्रयोगकर्ता इन्टरफेस, CLI, र अन्य स्वचालन उपकरणहरूको लागि API प्रदान गर्दछ जसको माध्यमबाट तपाइँ Tupperware सँग अन्तरक्रिया गर्न सक्नुहुन्छ। तिनीहरूले Tupperware रोजगार मालिकहरूबाट सम्पूर्ण आन्तरिक संरचना लुकाउँछन्।
• Tupperware Scheduler कन्टेनर र काम जीवनचक्र व्यवस्थापन गर्न जिम्मेवार एक नियन्त्रण प्यानल हो। यो क्षेत्रीय र विश्वव्यापी स्तरहरूमा तैनात गरिएको छ, जहाँ क्षेत्रीय अनुसूचकले एक क्षेत्रमा सर्भरहरू प्रबन्ध गर्दछ र विश्वव्यापी अनुसूचकले विभिन्न क्षेत्रहरूबाट सर्भरहरू प्रबन्ध गर्दछ। अनुसूचक शार्डहरूमा विभाजित छ, र प्रत्येक शार्डले कार्यहरूको सेट प्रबन्ध गर्दछ।
• Tupperware को Scheduler Proxy ले आन्तरिक शार्डिङ लुकाउँछ र Tupperware प्रयोगकर्ताहरूको लागि गिलासको सुविधाजनक एकल फलक प्रदान गर्दछ।
• Tupperware आवंटकले सर्भरहरूमा कन्टेनरहरू असाइन गर्दछ। शेड्युलरले कन्टेनरहरूको रोक्न, सुरु गर्ने, अद्यावधिक गर्ने र फेलओभरलाई ह्यान्डल गर्छ। हाल, एक विनियोजनकर्ताले खण्डहरूमा विभाजित नगरी सम्पूर्ण क्षेत्र व्यवस्थापन गर्न सक्छ। (शब्दावलीमा भिन्नतालाई ध्यान दिनुहोस्। उदाहरणका लागि, Tupperware मा अनुसूचक कन्ट्रोल प्यानलसँग मेल खान्छ। कुबर्नेट्स, र Tupperware आवंटकलाई Kubernetes मा अनुसूचक भनिन्छ।)
• स्रोत दलालले सर्भर र सेवा घटनाहरूको लागि सत्यको स्रोत भण्डार गर्दछ। हामी प्रत्येक डाटा सेन्टरको लागि एउटा स्रोत ब्रोकर चलाउँछौं, र यसले त्यो डाटा केन्द्रमा सर्भरहरूको बारेमा सबै जानकारी भण्डार गर्छ। स्रोत दलाल र क्षमता व्यवस्थापन प्रणाली, वा स्रोत प्रावधान प्रणाली, गतिशील रूपमा निर्णय गर्दछ कि कुन अनुसूचक वितरण कुन सर्भर नियन्त्रण गर्दछ। स्वास्थ्य जाँच सेवाले सर्भरहरूको निगरानी गर्दछ र स्रोत ब्रोकरमा उनीहरूको स्वास्थ्यको बारेमा डाटा भण्डारण गर्दछ। यदि सर्भरमा समस्या छ वा मर्मत आवश्यक छ भने, स्रोत दलालले आवंटक र अनुसूचकलाई कन्टेनरहरू रोक्न वा तिनीहरूलाई अन्य सर्भरहरूमा सार्न बताउँछ।
• Tupperware Agent प्रत्येक सर्भरमा चलिरहेको डेमन हो जसले कन्टेनरहरूको प्रावधान र हटाउने काम गर्छ। अनुप्रयोगहरू कन्टेनर भित्र चल्छन्, जसले तिनीहरूलाई थप अलगाव र पुन: उत्पादन क्षमता दिन्छ। अन गत वर्षको प्रणाली @Scale सम्मेलन हामीले पहिले नै वर्णन गरिसकेका छौं कि कसरी व्यक्तिगत Tupperware कन्टेनरहरू छविहरू, btrfs, cgroupv2 र systemd प्रयोग गरेर सिर्जना गरिन्छ।

Tupperware को विशिष्ट सुविधाहरू

Tupperware धेरै तरिकामा अन्य क्लस्टर व्यवस्थापन प्रणालीहरू जस्तै Kubernetes र मेसोस, तर त्यहाँ पनि भिन्नताहरू छन्:

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

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

राज्य सेवाहरूको लागि निर्मित समर्थन।

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

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

TaskControl इन्टरफेसले स्टेटफुल सेवाहरूलाई डाटा उपलब्धतालाई असर गर्ने निर्णयहरूलाई प्रभाव पार्न अनुमति दिन्छ। यो इन्टरफेस प्रयोग गरेर, अनुसूचकले कन्टेनर सञ्चालन (पुन: सुरु, अद्यावधिक, माइग्रेसन, मर्मत) बारे बाह्य अनुप्रयोगहरूलाई सूचित गर्दछ। स्टेटफुल सेवाले प्रत्येक अपरेसन गर्न सुरक्षित हुँदा Tupperware लाई बताउने नियन्त्रक लागू गर्छ, र यी अपरेसनहरू अदलाबदली गर्न वा अस्थायी रूपमा ढिलाइ गर्न सकिन्छ। माथिको उदाहरणमा, डाटाबेस नियन्त्रकले Tupperware लाई 49 सर्भरहरू मध्ये 50 अद्यावधिक गर्न भन्न सक्छ, तर अहिलेको लागि एक विशिष्ट सर्भर (X) छोड्नुहोस्। नतिजाको रूपमा, यदि कर्नेल अद्यावधिक अवधि बितिन्छ र डाटाबेस अझै पनि समस्याग्रस्त प्रतिकृति पुनर्स्थापना गर्न असमर्थ छ भने, Tupperware ले अझै पनि X सर्भर अपडेट गर्नेछ।

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

डाटा केन्द्रहरूमा सर्भरहरू प्रबन्ध गर्नुहोस्

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

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

सम्पूर्ण विश्वव्यापी प्रणालीलाई समर्थन गर्न स्केलेबल

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

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

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

लोचदार कम्प्युटिङ संग उपयोग दक्षता सुधार गर्नुहोस्

हाम्रो पूर्वाधार जति ठूलो छ, पूर्वाधार लागतहरू अनुकूलन गर्न र लोड कम गर्नका लागि हाम्रा सर्भरहरूलाई प्रभावकारी रूपमा प्रयोग गर्नु त्यति नै महत्त्वपूर्ण छ। सर्भर प्रयोगको दक्षता बढाउन दुई तरिकाहरू छन्:

• लोचदार कम्प्युटिङ - शान्त घण्टामा अनलाइन सेवाहरू मापन गर्नुहोस् र अफलाइन वर्कलोडहरूको लागि स्वतन्त्र सर्भरहरू प्रयोग गर्नुहोस्, जस्तै मेसिन लर्निङ र MapReduce कार्यहरू।
• ओभरलोडिङ - एउटै सर्भरमा अनलाइन सेवाहरू र ब्याच वर्कलोडहरू राख्नुहोस् ताकि ब्याच वर्कलोडहरू कम प्राथमिकतामा चल्छन्।

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


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

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

सिकेका पाठहरू र भविष्यका लागि योजनाहरू

विगत ८ वर्षमा, हामीले Facebook को द्रुत बृद्धिलाई निरन्तरता दिन Tupperware विकास गरिरहेका छौं। हामीले सिकेका कुराहरू साझा गर्छौं र आशा गर्छौं कि यसले अरूलाई द्रुत रूपमा बढ्दो पूर्वाधारहरू व्यवस्थापन गर्न मद्दत गर्नेछ:

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

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

स्रोत: www.habr.com