ऑपरेशन "माइग्रेशन": डेटालाइन क्लाउड पर कैसे जाएं

लगभग 7 वर्ष पहले, सबसे पहली परियोजनाएं सरलतापूर्वक और सीधे हमारे क्लाउड पर स्थानांतरित हो गईं। वर्चुअल मशीन छवियों को FTP सर्वर पर अपलोड किया गया या हार्ड ड्राइव पर वितरित किया गया। फिर, एक विशेष आयात सर्वर के माध्यम से, VM को क्लाउड पर अपलोड किया गया।

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

Veeam बैकअप और प्रतिकृति के साथ माइग्रेशन

Veeam Backup and Replication को सभी लोग बैकअप और प्रतिकृतियां बनाने के उपकरण के रूप में जानते हैं। हम इसका उपयोग अपनी साइटों के बीच माइग्रेशन के लिए और ग्राहकों को निजी वर्चुअलाइजेशन से क्लाउड पर स्थानांतरित करने के लिए करते हैं। क्लाइंट की वर्चुअल मशीनों को हमारे vCenter में प्रतिकृतिकृत किया जाता है, जिसके बाद इंजीनियर उन्हें vCloud Director में जोड़ता है।

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

आमतौर पर, जब ग्राहक के बुनियादी ढांचे पर कोई मशीन बंद की जाती है, तब से लेकर हमारे क्लाउड पर उसे चालू करने तक, आधे घंटे या 15-20 मिनट से अधिक समय नहीं लगता है।

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

मामला एक
ग्राहक के पास VMware पर आधारित अपना स्वयं का वर्चुअल इंफ्रास्ट्रक्चर था - 40 TB क्षमता वाले 30 VMs। जिस उपकरण पर क्लस्टर तैनात किया गया था वह पहले से ही पुराना था, और ग्राहक ने नए उपकरण खरीदने की जहमत न उठाने का निर्णय लिया तथा इसके बजाय सार्वजनिक क्लाउड पर स्थानांतरित हो गया। महत्वपूर्ण प्रणालियों के डाउनटाइम की आवश्यकता एक घंटे से अधिक नहीं थी। उपकरण के रूप में Veeam Replication को चुना गया। एक और लाभ यह था कि ग्राहक का इंटरनेट प्रदाता हमारे डेटा सेंटर में मौजूद था, जिससे एक अच्छा चैनल व्यवस्थित करना संभव हो गया। माइग्रेशन में लगभग एक महीने का समय लगा, तथा वर्चुअल मशीनों के प्रत्येक समूह पर स्विचिंग के दौरान 30 मिनट तक का डाउनटाइम हुआ।

Veeam क्लाउड कनेक्ट के साथ माइग्रेशन

वीम क्लाउड कनेक्ट एक उपकरण है जो आपको वर्चुअल मशीन प्रतिकृति को कॉन्फ़िगर करने और सेवा प्रदाता के क्लाउड में प्रतिकृतियां लॉन्च करने में मदद करता है। अपडेट के बाद 2019 9 में, वर्चुअल मशीनों को सीधे vCloud Director में प्रतिरूपित करना संभव हो गया। एकमात्र आवश्यकता यह है कि क्लाइंट के पास अपना स्वयं का Veeam Backup and Replication संस्करण XNUMX या उच्चतर स्थापित होना चाहिए। संक्षेप में (विस्तृत संस्करण) यहां), तो पूरी प्रक्रिया इस प्रकार दिखाई देगी।

vCloud Director में, आवश्यक संसाधनों और नेटवर्क के साथ एक संगठन बनाया जाता है। Veeam Cloud Connect में, हम एक खाता बनाते हैं, ग्राहक अपने Veeam B&R से उससे जुड़ता है, डेटालाइन प्रदाता और संगठन का चयन करता है, और प्रतिकृति कार्यों को कॉन्फ़िगर करता है। इस तथ्य के अलावा कि इस तरह के माइग्रेशन के साथ डाउनटाइम 15-20 मिनट के भीतर होगा, ग्राहक प्रदाता के तकनीकी समर्थन पर निर्भर नहीं होता है और पूरी प्रक्रिया को स्वतंत्र रूप से प्रबंधित करता है: प्रतिकृति कार्य बनाता है, प्रतिकृति स्वयं बनाता है, मशीनों को बंद करता है और उन्हें नई साइट पर शुरू करता है।

मामला एक
ग्राहक का बुनियादी ढांचा, जहां से माइग्रेशन की योजना बनाई गई थी, बेलारूस में स्थित था। यह देखते हुए कि इंटरनेट चैनल 90 Mbit/sec था, कुल 27 TB वॉल्यूम वाले 100 VMs का परिवहन करना आवश्यक था। यदि आप बैकअप बनाकर तुरंत हमारे क्लाउड पर अपलोड कर दें, तो कुछ VMs के लिए इसमें कई दिन लग जाएंगे। इस दौरान, VM पर बड़ा डेल्टा विकसित हो गया होगा, और इससे मशीनों के प्रदर्शन पर नकारात्मक प्रभाव पड़ सकता था या इससे भी बदतर, डेटास्टोर पर स्थान समाप्त हो गया होगा। हमने निम्न प्रकार कार्य किया: सबसे पहले, ग्राहक ने एक स्थानीय पूर्ण बैकअप बनाया और उसकी एक प्रतिलिपि Veeam Cloud Connect के माध्यम से हमारे क्लाउड पर स्थानांतरित कर दी। फिर मैंने वृद्धि को क्लाउड पर स्थानांतरित कर दिया। मूल वर्चुअल मशीन चलती रही। VM को बंद करने के बाद, क्लाइंट ने एक और वृद्धि की और इसे क्लाउड पर भी स्थानांतरित कर दिया। हमारी ओर से, हमने पूर्ण बैकअप से एक वर्चुअल मशीन तैनात की, और फिर इसमें दो वृद्धियां कीं। इस योजना से अंततः हमें अपनी साइट पर स्विच करते समय डाउनटाइम को 2 घंटे तक कम करने में मदद मिली।

VMware vCloud उपलब्धता के साथ माइग्रेशन

इस वर्ष मार्च में, VMware ने vCloud Availability 3.0 जारी किया, जो वर्चुअल मशीनों को विभिन्न क्लाउड (vCloud Director – vCloud Director) के बीच और निजी क्लाइंट वर्चुअलाइजेशन स्टैंड से क्लाउड (vCenter – vCloud Director) में माइग्रेट करने की अनुमति देता है। मुख्य सुविधा vCloud Director इंटरफ़ेस के साथ एकीकरण है। इससे प्रतिकृति प्रबंधन प्रक्रिया बहुत सरल हो जाती है और स्विचओवर के दौरान डाउनटाइम न्यूनतम हो जाता है।

इस उपकरण का उपयोग करके, हमने अपने एक ग्राहक को मॉस्को क्लाउड से सेंट पीटर्सबर्ग स्थित क्लाउड पर स्थानांतरित किया। कुल 18 टीबी क्षमता वाली 14 वर्चुअल मशीनों का परिवहन करना आवश्यक था। सेंट पीटर्सबर्ग क्लाउड में ग्राहक के लिए एक संगठन बनाया गया और आवश्यक नेटवर्क व्यवस्थित किए गए। इसके बाद, vCloud Director इंटरफ़ेस से, ग्राहक vCloud उपलब्धता सेटिंग्स पर गया, प्रतिकृति कार्य बनाए, और उसके लिए सुविधाजनक समय पर, सेंट पीटर्सबर्ग साइट पर स्विच किया। स्विचिंग के दौरान डाउनटाइम 12 मिनट का था।

सेंट पीटर्सबर्ग और मॉस्को में डेटालाइन क्लाउड के बीच माइग्रेशन योजना।

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

निजी स्थापना से क्लाउड तक वर्चुअल मशीनों के स्थानांतरण की योजना।

VMware vCloud उपलब्धता के कई अन्य उपयोग मामले हैं, हम जल्द ही एक अलग लेख में उनके बारे में बात करेंगे।

प्रवास की तैयारी

किसी उपकरण का चयन करने और वास्तव में माइग्रेशन शुरू करने के लिए, आपको निम्नलिखित बिंदुओं पर निर्णय लेना होगा:

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

मामला एक
एक ग्राहक के SAP सिस्टम को एक यूरोपीय प्रदाता से स्थानांतरित करना आवश्यक था: 34 TB क्षमता वाले 54 VMs। ग्राहक को हमारे क्लाउड में संसाधन आवंटित किये गये। हमारे और यूरोपीय प्रदाता की बुनियादी संरचना के बीच एक नेटवर्क कनेक्शन स्थापित किया गया। आवश्यक कॉन्फ़िगरेशन लागू करके अनुप्रयोग सर्वरों को पुनः तैनात किया गया। हमारे क्लाउड में बैकअप लोड करके बड़े डेटाबेस को माइग्रेट किया गया। इसके बाद, हमारे और स्रोत साइटों पर डेटाबेस के बीच प्रतिकृति को कॉन्फ़िगर किया गया। तय समय पर, हमने अपने क्लाउड में डेटाबेस पर स्विच कर लिया।

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

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

इस डेटा के आधार पर, आप एक उपकरण का चयन कर सकते हैं और माइग्रेशन शुरू कर सकते हैं। आगे क्या हुआ, यहाँ बताया गया है।

1. नेटवर्क कनेक्टिविटी स्थापित करना. हम अपने क्लाउड और ग्राहक के बुनियादी ढांचे के बीच नेटवर्क कनेक्टिविटी का आयोजन करते हैं। वर्चुअल मशीनों की प्रतिलिपि इस नेटवर्क पर बनाई जाएगी। यदि Veeam Backup and Replication का उपयोग किया जाता है, तो यह एक समर्पित चैनल है, कभी-कभी यह एक VPN चैनल भी होता है। यदि वीम क्लाउड कनेक्ट है, तो सब कुछ इंटरनेट या उसी समर्पित चैनल के माध्यम से होता है।

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

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

मेरे पास बस इतना ही है। प्रश्न पूछें और टिप्पणियों में हमें अपने प्रवासन अनुभव के बारे में बताएं।

स्रोत: www.habr.com