आधी आग जो कभी नहीं लगी: हम नए डेटा सेंटर में कैसे चले गए

दो क्रॉसिंग एक आग के बराबर हैं।
(लोक ज्ञान)

इसके बजाय अग्रदूत

एक प्रसिद्ध हृदय सर्जन एक कार सेवा में आता है और मरम्मत के लिए अपनी कार सौंपता है। इस अवसर पर कार्यशाला में काम करने वाले एक मैकेनिक ने डॉक्टर को बुलाया और उनसे एक सवाल पूछा:

- डॉक्टर! वास्तव में, हम एक ही काम कर रहे हैं: मैं कारों के "दिल" को बाहर निकालता हूं, उनमें से वाल्व निकालता हूं, नए में डालता हूं। और मैं पूरे इंजन को बदल सकता हूं। एक तरह से या किसी अन्य, मेरे काम के बाद, कार एक नए "दिल" के साथ रहना जारी रखती है। लेकिन आप फावड़े से पैसे जमा करते हैं, और मुझे अपने काम के लिए एक पैसा मिलता है। ऐसा क्यों!

जिस पर डॉक्टर ने उचित टिप्पणी की:

- और तुम, प्रिय, एक काम कर रहे इंजन का एक बड़ा ओवरहाल बनाने की कोशिश करो!

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

गर्मी की छुट्टियों का समय है, अधिकांश वेबमास्टर्स के लिए सबसे "शांत" अवधि: सर्वर का एक असाधारण अनुसूचित "रिबूट" माना जाता है।

हम गर्मियों के लिए इंतजार कर रहे थे - और अपने नए डेटा सेंटर में चले गए!

कार्य

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

निम्न डेटा के आधार पर स्थानांतरण नियोजन किया गया था:

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

समाधान

विभिन्न तरीकों से हमारे सामने कार्य को हल करना संभव था, जिनमें से प्रत्येक का सावधानीपूर्वक विश्लेषण किया गया था। समाधान के तीन मुख्य समूहों की पहचान की गई।

सरल, सस्ता, अनाड़ी

सबसे सरल समाधान इस तरह दिखेगा:

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

पेशेवरों:

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

विपक्ष:

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

इस तरह के स्थानांतरण परिदृश्य के फायदे की मात्रात्मक प्रबलता इसके minuses की भौतिकता को पछाड़ नहीं सकती थी, और उन्होंने विकल्प को स्वीकार नहीं किया।

समय लेने वाली, महंगी, सुरुचिपूर्ण

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

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

पेशेवरों:

• कम डाउनटाइम साइट्स। कई लोगों के लिए, यह कदम पूरी तरह से किसी का ध्यान नहीं गया होगा।

विपक्ष:

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

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

महत्वपूर्ण

सेवाओं के प्रावधान में विराम की अवधि निर्धारित करने वाले कारकों का विश्लेषण करने के बाद, हमने एक समाधान विकसित किया है, जिसे हम दिल से गर्व करते हैं।

तकनीकी कारक

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

संगठनात्मक कारक

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

नए डेटा सेंटर में उपकरणों के भौतिक हस्तांतरण के पूरा होने पर, हमें केवल पुराने डेटा सेंटर में नेटवर्क को "भुगतान" करना था और हमारे नेटवर्क के रूटिंग में परिवर्तन करना था, जो सफलतापूर्वक किया गया था। साइट के काम में ब्रेक से, नोटिस नहीं करना संभव था। उन लोगों के लिए, जिन्होंने तकनीकी कारणों से, फिर भी उस पर ध्यान नहीं दिया, साइट की दृश्यता 10 मिनट से अधिक नहीं के लिए "गायब" हो गई।

किए गए निर्णय के minuses और व्यवहार में, केवल महत्वपूर्ण श्रमशीलता और कुछ ओवरहेड लागत को नोट किया जाना चाहिए (उदाहरण के लिए, एक नई तकनीकी साइट के लिए "बफर" उपकरण की खरीद)। लेकिन इन क्षणों ने प्रक्रिया के गुणात्मक पक्ष को प्रभावित नहीं किया, इसलिए, वे स्वीकार्य हो गए।

संगठनात्मक निष्कर्ष

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