हिस्टैक्स क्लाउड माइग्रेशन: बादलों की सवारी

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

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

यह आपको सेवाओं की दोष सहनशीलता में सुधार करने के लिए न केवल डीआर समाधान बनाने की अनुमति देता है, बल्कि लागत बचत बढ़ाने और इस समय किसी विशेष सेवा के लिए सर्वोत्तम समाधान का चयन करने के लिए विभिन्न साइटों और हाइपरस्केलर्स के बीच संसाधनों को तेज़ी से, लचीले ढंग से स्थानांतरित करने की भी अनुमति देता है। शीर्षक चित्र में सूचीबद्ध प्लेटफार्मों के अलावा, कंपनी रूसी क्लाउड प्रदाताओं के साथ भी सक्रिय रूप से सहयोग करती है: Yandex.Cloud, CROC क्लाउड सर्विसेज, Mail.ru और कई अन्य। यह भी ध्यान देने योग्य है कि 2020 में कंपनी ने स्कोल्कोवो में स्थित एक R&D केंद्र खोला। 

बाज़ार में बड़ी संख्या में खिलाड़ियों द्वारा एक समाधान का चुनाव एक अच्छी मूल्य निर्धारण नीति और उत्पाद की उच्च प्रयोज्यता को इंगित करता है, जिसे हमने व्यवहार में परीक्षण करने का निर्णय लिया।

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

पहला कदम हिस्टैक्स एक्यूरा को तैनात करना है, जो सिस्टम का नियंत्रण कक्ष है।

यह टेम्पलेट से प्रकट होता है. किसी कारण से, हमारे मामले में, यह पूरी तरह से सही नहीं था और अनुशंसित 8CPU के बजाय, 16Gb को आधे संसाधनों के साथ तैनात किया गया था। इसलिए, आपको उन्हें बदलना नहीं भूलना चाहिए, अन्यथा वीएम के अंदर का बुनियादी ढांचा, जिस पर सब कुछ बनाया गया है, बस कंटेनरों से शुरू नहीं होगा और पोर्टल अनुपलब्ध होगा। में परिनियोजन आवश्यकताएँ आवश्यक संसाधनों के साथ-साथ सभी सिस्टम घटकों के लिए पोर्ट का विस्तार से वर्णन किया गया है। 

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

समापन बिंदु - हमारे vCenter का IP या FQDN। 
लॉगिन और पासवर्ड - यह स्पष्ट है। 
लक्ष्य ESXi होस्टनाम हमारे क्लस्टर में उन होस्टों में से एक है जिसे दोहराया जाएगा। 
लक्ष्य डेटास्टोर हमारे क्लस्टर के डेटास्टोर्स में से एक है जिसमें प्रतिकृति निष्पादित की जाएगी।
हिस्टैक्स एक्यूरा कंट्रोल पैनल पब्लिक आईपी - वह पता जहां कंट्रोल पैनल उपलब्ध होगा।

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

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

लेकिन वापस तैनाती पर। सबसे पहले, पैनल के प्रारंभिक सेटअप के बाद, हमें अपने सिस्टम में पहला किरायेदार बनाना होगा।

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

एक नया क्लाउड जोड़ने के रूप में, हम प्रारंभिक कॉन्फ़िगरेशन के दौरान समान पैरामीटर निर्दिष्ट करते हैं (हम एक ही होस्ट का उपयोग भी कर सकते हैं), किसी विशेष ग्राहक के लिए आवश्यक डेटास्टोर निर्दिष्ट करते हैं, और अब अतिरिक्त पैरामीटर में हम पहले से ही व्यक्तिगत रूप से निर्दिष्ट कर सकते हैं आवश्यक पूल संसाधन {"resource_pool" :"YOUR_POOL_NAME"} 

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

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

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

अब हमारा ग्राहक स्वतंत्र रूप से पोर्टल का उपयोग कर सकता है। उसे बस पोर्टल से एजेंटों को डाउनलोड करना है और उन्हें अपनी तरफ इंस्टॉल करना है। एजेंट तीन प्रकार के होते हैं: Linux, Windows और VMware।

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

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

इसलिए, एजेंटों को स्थापित करने के बाद, हम Acura पैनल पर वापस जा सकते हैं और अपनी सभी कारों को देख सकते हैं।

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

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

डीआर योजना तैयार करते समय मापदंडों का सेट उस बुनियादी ढांचे के आधार पर भिन्न होगा जिसमें आप स्थानांतरित होंगे। VMware वातावरण के लिए मापदंडों का एक न्यूनतम सेट उपलब्ध है। मशीनों के लिए री-आईपी भी समर्थित नहीं है। इस संबंध में, हम निम्नलिखित बिंदुओं में रुचि रखते हैं: वीएम के विवरण में, "सबनेट" पैरामीटर: "वीएमनेटवर्क", जहां हम वीएम को क्लस्टर में एक विशिष्ट नेटवर्क से बांधते हैं। रैंक - कई वीएम को माइग्रेट करते समय प्रासंगिक; यह उस क्रम को निर्धारित करता है जिसमें उन्हें लॉन्च किया गया है। फ़्लेवर - VM कॉन्फ़िगरेशन का वर्णन करता है, इस मामले में - 1CPU, 2GB RAM। सबनेट अनुभाग में, हम परिभाषित करते हैं कि "सबनेट": "VMNetwork" VMware के "VM नेटवर्क" से संबद्ध है। 

डीआर योजना बनाते समय, विभिन्न डेटास्टोरों में डिस्क को "फैलाने" का कोई तरीका नहीं है। वे उसी डेटास्टोर पर स्थित होंगे जो इस क्लाइंट क्लाउड के लिए परिभाषित किया गया था, और यदि आपके पास विभिन्न वर्गों की डिस्क हैं, तो इससे मशीन शुरू करते समय कुछ कठिनाइयां हो सकती हैं, और वीएम को हिस्टैक्स से शुरू करने और "अलग" करने के बाद, यह भी होगा आवश्यक डेटास्टोर्स के लिए एक अलग माइग्रेशन डिस्क की आवश्यकता होती है। फिर हमें बस अपना डीआर प्लान चलाना होगा और अपनी कारों के उठने का इंतजार करना होगा। P2V/V2V रूपांतरण प्रक्रिया में भी समय लगता है। तीन डिस्क वाली मेरी सबसे बड़ी 100GB परीक्षण मशीन पर, इसमें अधिकतम 10 मिनट लगे।

उसके बाद, आपको चल रहे वीएम, उस पर सेवाओं, डेटा स्थिरता और अन्य जांचों की जांच करनी चाहिए। 

फिर हमारे पास दो विकल्प हैं: 

1. हटाएँ - चल रहे डीआर प्लान को हटाएँ। यह क्रिया बस चल रहे VM को बंद कर देगी। ये प्रतिकृतियां कहीं नहीं जा रही हैं. 
2. अलग करना - Acura से प्रतिकृति कार को फाड़ना, यानी। वास्तव में माइग्रेशन प्रक्रिया को पूरा करें। 

समाधान के पेशेवर: 

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

विपक्ष 

• अपर्याप्त Vmware समर्थन.
• मंच से किरायेदारों के लिए किसी भी कोटा का अभाव। 

मैंने एक फ़ीचर अनुरोध भी किया, जिसे हमने विक्रेता को सौंप दिया:

1. क्लाउड एजेंटों के लिए Acura प्रबंधन कंसोल से उपयोग की निगरानी और तैनाती;
2. किरायेदारों के लिए कोटा की उपलब्धता; 
3. प्रत्येक किरायेदार के लिए एक साथ प्रतिकृतियों की संख्या और गति को सीमित करने की क्षमता; 
4. VMware vCloud निदेशक समर्थन; 
5. संसाधन पूल के लिए समर्थन (परीक्षण के दौरान कार्यान्वित);
6. Acura पैनल में क्लाइंट इंफ्रास्ट्रक्चर से क्रेडेंशियल दर्ज किए बिना, एजेंट से ही VMware एजेंट को कॉन्फ़िगर करने की क्षमता;
7.  डीआर योजना चलाते समय वीएम स्टार्टअप प्रक्रिया का "विज़ुअलाइज़ेशन"। 

एकमात्र चीज़ जिससे मुझे बड़ी शिकायत हुई वह थी दस्तावेज़ीकरण। मुझे वास्तव में "ब्लैक बॉक्स" पसंद नहीं है और मैं तब पसंद करता हूं जब उत्पाद अंदर कैसे काम करता है इसके बारे में विस्तृत दस्तावेज हों। और यदि AWS और OpenStack के लिए उत्पाद का वर्णन कमोबेश किया गया है, तो VMware के लिए बहुत कम दस्तावेज़ीकरण है। 

एक इंस्टॉलेशन गाइड है जो केवल Acura पैनल की तैनाती का वर्णन करता है, और जहां क्लाउड एजेंट की आवश्यकता के बारे में एक शब्द भी नहीं है। उत्पाद विशिष्टताओं का एक पूरा सेट है, जो अच्छा है। ऐसे दस्तावेज़ हैं जो एक उदाहरण के रूप में AWS और ओपनस्टैक का उपयोग करके "से और तक" सेटअप का वर्णन करते हैं (हालाँकि यह मुझे एक ब्लॉग पोस्ट की अधिक याद दिलाता है), और एक बहुत छोटा ज्ञानकोष है। 

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

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

हम एक टीम सदस्य की तलाश कर रहे हैं मॉनिटरिंग सिस्टम के लीड इंजीनियर. हो सकता है यह आप हो?

स्रोत: www.habr.com