होस्टिंग प्रदाताओं के बीच ग्राहकों का सामूहिक प्रवासन: हम एक औद्योगिक पैमाने पर एन्ट्रापी के साथ संघर्ष कर रहे हैं

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

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

• विभिन्न बिलिंग पैनलों का उपयोग किया जाता है;
• विभिन्न होस्टिंग कंट्रोल पैनल का उपयोग किया जाता है;
• विभिन्न सेटिंग्स के साथ पीएचपी / अन्य दुभाषियों के विभिन्न संस्करण;
• विभिन्न स्क्रिप्ट लॉन्च मोड (fastcgi बनाम mod_something);
• विभिन्न वेब सर्वर सेटिंग्स;
• वेब सर्वर को सक्षम करने के लिए अलग योजना (फ्रंटएंड के साथ / बिना);
• सुरक्षा नीति में विभिन्न सेटिंग्स और अंतर;
• सिस्टम में साइटों और बाहरी उपयोगिताओं के लिए अलग-अलग रास्ते;
• विभिन्न मेल सर्वर और मेल भेजने वाली योजनाएं (पोर्ट 25 बनाम सेंडमेल कॉल भेजना)।

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

वास्तविक जीवन से विभिन्न संभावित "असंगतताएं" भी हैं, छोटे होस्टिंग प्रदाताओं की क्षमताओं को ध्यान में रखते हुए:

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

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

वास्तव में, इस मामले में, आपको तीन समस्याओं को हल करने की आवश्यकता है :

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

इस समीक्षा लेख में मैं यह बताने की कोशिश करूंगा कि ये कार्य कैसे REG.RU में हल किए जाते हैं।
आमतौर पर एक प्रक्रिया में कई तकनीकी, संगठनात्मक और सूचनात्मक चरण होते हैं :

1. आगामी हस्तांतरण के बारे में ग्राहकों की अधिसूचना:
क) हॉस्टल की वेबसाइट पर समाचार;
ख) REG.RU वेबसाइट पर समाचार;
ग) प्रेस रिलीज;
घ) आगामी हस्तांतरण के बारे में ग्राहकों को न्यूज़लैटर;
d) 1-2 सप्ताह रोकें। ऐसा इसलिए किया जाता है ताकि जो लोग स्थानांतरित नहीं होना चाहते हैं वे इसकी घोषणा कर सकें या किसी अन्य होस्टिंग प्रदाता को अपने दम पर स्विच कर सकें।

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

2. हस्तांतरण के लिए तकनीकी तैयारी।
2.1। स्थानांतरण के लिए ग्राहकों और सेवाओं का एक डेटाबेस संकलित करना:
a) हम बिलिंग पैनल से एकल प्रारूप डेटा पढ़ते हैं और लाते हैं (जिनमें से कई हो सकते हैं);
बी) हम अन्य स्रोतों (बिलिंग के बिना ग्राहक) से डेटा एकत्र करते हैं;
ग) समाप्त हो गई होस्टिंग के बीच, लेकिन अभी तक शारीरिक रूप से हटाए नहीं गए हैं, हम ग्राहकों को अलग करते हैं जो वास्तव में अब होस्टिंग का उपयोग नहीं करते हैं और जो इसे स्थानांतरित करने के लिए कोई मतलब नहीं है, सबसे अधिक संभावना है कि वे होस्टिंग का विस्तार नहीं करेंगे।
हम, कह सकते हैं, आईपी होस्टिंग के लिए डोमेन प्रतिनिधिमंडल की जाँच करें, लेकिन यह इतना आसान नहीं है - ऐसी स्थितियाँ हैं:

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

तो, आदर्श रूप से - आपको लॉग देखने के लिए यह देखने की आवश्यकता है कि क्या साइट पर कोई वास्तविक दौरा था / हैं।

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

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

मंच का उद्देश्य बिलिंग डेटाबेस में सभी ग्राहकों और उनकी सेवाओं के बारे में जानकारी जोड़ना है।

2.3। ग्राहकों के भौतिक प्रवास / सर्वर विभाजन के लिए तैयारी:
क) हम उन खातों की पूरी और "अंतिम" सूची संकलित करते हैं जिन्हें माइग्रेट करने की आवश्यकता होती है;
बी) हम पहले से बनाई गई सूची में क्रम में चीजें डालते हैं (हम कह सकते हैं कि हम होस्टिंग पर आदेश में चीजें डालते हैं, जहां से हम खाते स्थानांतरित करते हैं): हम देखते हैं कि दो या अधिक सर्वर पर समान उपयोगकर्ता या www- डोमेन हैं या नहीं। यदि कोई हो, तो हम इसे अर्ध-स्वचालित और मैनुअल मोड में हल करते हैं और अतिरिक्त को हटा देते हैं;
ग) हम उपयोगकर्ताओं की पूरी सूची को उन समूहों में विभाजित करते हैं जो निम्नलिखित शर्तों को पूरा करते हैं:

• एक समूह में n उपयोगकर्ताओं से अधिक नहीं होना चाहिए;
• एक समूह में, उपयोग किए जाने वाले संसाधनों की कुल सीमा पार नहीं होनी चाहिए;
• पुराने सर्वरों से ट्रैफ़िक के बाद के प्रॉक्सी को नए लोगों की सुविधा के लिए (जो कि स्थानांतरण के बाद चालू हो जाएगा), यह भी सलाह दी जाती है कि खातों को एक स्रोत सर्वर से अलग-अलग समूहों में विभाजित न करें।

d) हम स्रोत सर्वर की सेटिंग और गंतव्य सर्वर पर सेटिंग्स और अधिकारों के साथ स्रोत पर अनुमत अधिकारों की पुष्टि करते हैं।

मंच का लक्ष्य गंतव्य सर्वरों के बीच ग्राहकों को वितरित करना है, सभी प्रतिबंधों और बारीकियों को ध्यान में रखना।

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

• एन अक्षर से कम नाम वाले डेटाबेस;
• डेटाबेस जैसे sql, mysql, new, user आदि नामों के साथ डेटाबेस, जो डेटाबेस नेमस्पेस में भ्रम का परिचय देते हैं।

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

मंच का लक्ष्य "होस्टिंग" होस्टिंग पैनल के डेटाबेस में सभी आवश्यक खातों और उनकी सेटिंग्स बनाना है।

3. भौतिक साइट स्थानांतरण:
अगले सर्वर पर स्थानांतरण के लिए ग्राहकों के प्रत्येक समूह के लिए:
क) एक समूह के लिए एक स्वचालित प्रवास तंत्र लॉन्च;
ख) एक नए वातावरण के लिए साइट कॉन्फ़िगरेशन को स्वचालित रूप से पुन: कॉन्फ़िगर करने के लिए एक स्वचालित स्क्रिप्ट चलाएँ:

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

डी) हम स्थानांतरण के बाद साइटों के मुख्य पृष्ठों के परीक्षण के लिए मशीन शुरू करते हैं: मशीन यह देखती है कि सभी साइटों के मुख्य पृष्ठों की HTTP स्थिति नहीं बदली गई है;
ग) इसके अलावा, हम एक मैनुअल जांच करते हैं - हम इस समूह के www- डोमेन की सूची होस्टिंग सहायता / परीक्षण सेवा को देते हैं;
ई) हम पाए गए कीड़े को ठीक करते हैं;
च) हम हस्तांतरित समूह के डोमेन के लिए हमें समीप लाने में सक्षम करते हैं, हम स्रोत पर इस समूह के ग्राहकों को रोकते हैं।

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

4. स्थानांतरण के बाद कार्रवाई:
a) हम ग्राहकों को उनके नए विवरणों के साथ बिलिंग / कंट्रोल पैनल और नई होस्टिंग की सुविधाओं तक पहुंच के लिए सूचना भेजते हैं, जिन पर ध्यान दिया जाना चाहिए।
बी) हस्तांतरण की शुद्धता का अंतिम नियंत्रण, त्रुटियों का सुधार;
c) DNS सर्वरों को स्वचालित रूप से हमारे लिए परिवर्तित करें (उन डोमेन के लिए जो हमारे नियंत्रण में हैं);
डी) हम अपने स्वयं के डीएनएस के साथ ग्राहकों को मेलिंग करते हैं ताकि डीएनएस को हमारे (हमारी पहुंच से बाहर के डोमेन के लिए) बदलने का अनुरोध किया जा सके।

मंच का लक्ष्य DNS को नए आईपी में बदलना और ग्राहकों को सभी आवश्यक सूचनाएं भेजना है।

इस तरह के एक बड़े पैमाने पर क्लाइंट ट्रांसफर के नवीनतम उदाहरणों में Hostingjoomla.ru के साथ सहयोग है, जिसके परिणामस्वरूप 500 से अधिक क्लाइंट (750+ www-डोमेन) कई पुराने सर्वरों से नए वाले में ट्रांसफर हुए। साथ ही, अराजकता का मुकाबला करने के लिए बहुत काम किया गया था (इस काम के तत्वों को ऊपर सूचीबद्ध किया गया था)।

परिणामस्वरूप, सभी को प्रतिष्ठित लाभ मिला:

• RedSoft वेब स्टूडियो (जो Hostingjoomla.ru प्रोजेक्ट का मालिक है), CMS जूमला पर आधारित परियोजनाओं को लॉन्च करने में विशेषज्ञता प्राप्त है; एक विशेष ऑपरेटर को होस्टिंग सेवाएं सौंपता है और अपने ग्राहकों के प्रोजेक्ट के लिए अधिक स्थिर मंच पर भरोसा करते हुए, अपने मुख्य व्यवसाय पर पूरी तरह से ध्यान केंद्रित करने का अवसर प्राप्त करता है;
• ग्राहकों को एक बेहतर और अधिक स्थिर होस्टिंग सेवा मिली जीत की कीमत पर, उच्च गुणवत्ता वाले तकनीकी समर्थन और विकल्पों की एक बड़ी संख्या और अतिरिक्त सेवाओं (समर्पित आईपी पते, एसएसएल प्रमाणपत्र, 200 से अधिक क्षेत्रों में डोमेन, आदि) जो हो सकते हैं। "एक खिड़की" (REG.RU में एक खाता) के प्रारूप में आदेश;
• REG.RU कंपनी को दीर्घकालिक सहयोग के उद्देश्य से नए वफादार ग्राहक प्राप्त हुए, क्योंकि एक दिन की साइटें शायद ही कभी वेब स्टूडियो स्टूडियो छोड़ती हैं;
• REG.RU इंजीनियरों ने अतिरिक्त अनुभव बिंदु प्राप्त किए और स्वचालित स्क्रिप्ट के सेट का एक और पुनःपूर्ति, स्थानांतरण से जुड़ी कठिन परिस्थितियों को हल करने की अनुमति देता है।

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

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