4 इंजीनियर, 7000 सर्वर और एक वैश्विक महामारी

नमस्ते, हबर! मैं आपके ध्यान में लेख का अनुवाद प्रस्तुत करता हूँ "4 इंजीनियर, 7000 सर्वर, और एक वैश्विक महामारी" अदीब दाऊ द्वारा।

यदि वह शीर्षक आपकी रीढ़ में हल्की सी सिहरन पैदा नहीं करता है, तो आपको अगले पैराग्राफ पर जाना चाहिए या समर्पित हमारे पृष्ठ पर जाना चाहिए कंपनी में कैरियर - हम बात करना चाहेंगे.

हम कौन हैं

हम 4 पेंगुइनों की एक टीम हैं जिन्हें कोड लिखना और हार्डवेयर के साथ काम करना पसंद है। अपने खाली समय में, हम संयुक्त राज्य भर में 7000 अलग-अलग डेटा केंद्रों में वितरित लिनक्स चलाने वाले 3 से अधिक भौतिक सर्वरों के बेड़े को तैनात करने, बनाए रखने और संचालित करने के लिए जिम्मेदार हैं।

हमें साइटों से 10 किमी दूर, अपने कार्यालय में आराम से ऐसा करने का अवसर मिला, जो भूमध्य सागर पर समुद्र तट से थोड़ी दूरी पर स्थित है।

स्केल की समस्याएं

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

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

अपने डोमेन में महारत हासिल करें

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

इस दृष्टिकोण को अपनाने से हमें कई समस्याओं को सही ढंग से हल करने की अनुमति मिली - उपकरण और स्वचालन बनाकर।

डोमेन चाहिए

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

• केवल प्रासंगिक फ़ील्ड के दृश्य को अनुकूलित करने की क्षमता (सरल)
• ओपन एपीआई (एक्स्टेंसिबल)
• हमारी टीम को ज्ञात (समझा गया)
• हमारे मौजूदा वर्कफ़्लो के साथ एकीकरण (एकीकृत)

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

जीरा में कानबन बोर्ड

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

उपकरण जीवनचक्र डोमेन

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

• फ़ील्ड कर्मियों के साथ संचार का प्रबंधन, सभी सूचनाओं का एकत्रीकरण;
• प्रत्येक पूर्ण और सत्यापित उपकरण रखरखाव कार्य के बाद "वेयरहाउस" डेटा को अपडेट करना।

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

ग्राफाना में गोदाम उपकरण नियंत्रण कक्ष

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

• सिस्टम लॉग एकत्र करता है;
• विक्रेता द्वारा आवश्यक प्रारूप में रिपोर्ट तैयार करता है;
• एपीआई के माध्यम से विक्रेता से एक अनुरोध बनाता है;
• अपनी प्रगति की आगे की ट्रैकिंग के लिए एप्लिकेशन पहचानकर्ता को प्राप्त करता है और संग्रहीत करता है।

एक बार जब हमारा दावा स्वीकार कर लिया जाता है (आमतौर पर व्यावसायिक घंटों के भीतर), तो स्पेयर पार्ट को उपयुक्त डेटा सेंटर में भेज दिया जाता है और कर्मचारियों द्वारा स्वीकार कर लिया जाता है।

जेनकींस कंसोल आउटपुट

संचार डोमेन

हमारे व्यवसाय की तीव्र वृद्धि को बनाए रखने के लिए, जिसके लिए लगातार बढ़ती क्षमता की आवश्यकता होती है, हमें स्थानीय डेटा केंद्रों में तकनीकी विशेषज्ञों के साथ काम करने के तरीके को अपनाना होगा। यदि पहले स्केलिंग का मतलब नए सर्वर खरीदना था, तो एक समेकन परियोजना (कुबेरनेट्स में संक्रमण के आधार पर) के बाद यह पूरी तरह से अलग हो गया। "रैक जोड़ने" से लेकर "सर्वर को पुन: उपयोग करने" तक हमारा विकास।

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

• सादगी;
• स्वायत्तता;
• क्षमता;
• विश्वसनीयता।

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

इसे प्राप्त करने के लिए, हमने प्रत्येक डेटा सेंटर में आईपैड स्थापित किए। सर्वर से कनेक्ट होने के बाद, निम्नलिखित होगा:

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

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

हमारे डेटा केंद्रों में से एक में आईपैड

हार्डवेयर डोमेन

हमारे डेटा सेंटर के बुनियादी ढांचे को विश्वसनीय रूप से बढ़ाने के लिए प्रत्येक घटक में अच्छी दृश्यता की आवश्यकता होती है, उदाहरण के लिए:

• हार्डवेयर विफलता का पता लगाना
• सर्वर स्थितियाँ (सक्रिय, होस्ट किया गया, ज़ोंबी, आदि)
• बिजली की खपत
• प्रक्रिया यंत्र सामग्री संस्करण
• इस संपूर्ण व्यवसाय के लिए विश्लेषण

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

ग्राफाना में ऊर्जा डैशबोर्ड

और फिर सामने आया COVID-19...

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

ट्रैफ़िक में वृद्धि के साथ-साथ COVID-19 के आसपास की गहन मीडिया कवरेज का मतलब है कि हमें तत्काल यह सीखने की ज़रूरत है कि इन दबावों से कैसे निपटा जाए। इसके अलावा, यह सब एक वैश्विक संकट के दौरान करना पड़ा, जब आपूर्ति श्रृंखला बाधित हो गई थी और अधिकांश कर्मचारी घर पर थे।

लेकिन, जैसा कि हमने कहा, हमारा मॉडल पहले से ही मानता है कि:

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

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

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

मूल: tyts

स्रोत: www.habr.com