आईटी सिस्टम को माइग्रेट करना कोई आसान काम नहीं है। लेकिन विशेष कठिनाई वह स्थिति है जब आपको न केवल पुराने लोहे से नए पर स्विच करने की आवश्यकता होती है, बल्कि मौजूदा उपकरणों पर एक नए ऑपरेटिंग सिस्टम में जाने के लिए, और उत्पादक डेटा को माइग्रेट किए बिना। ऐसा ही एक कदम लगभग एक साल तक चला, जिसमें से अधिकांश ने तैयारी की।
क्लाइंट के पास अलग-अलग शहरों में दो साइटें हैं, और प्रत्येक में दो कनेक्टेड डेटा स्टोरेज सिस्टम हैं। अंतर्निहित प्रतिकृति टूल का उपयोग करके एक भंडारण प्रणाली से सूचना दूसरे को भेजी जाती है। प्रबंधन बाहरी बैकअप सिस्टम का उपयोग करके किया जाता है। एक शहर में, दो NetApp 3250 सिस्टम स्थापित हैं, दूसरे में - मुख्य NetApp 6220 और बैकअप NetApp 3250। क्लाइंट भविष्य में इस परिसर का विस्तार करने, डिस्क जोड़ने और नियंत्रकों को अपग्रेड करने की योजना बना रहा है।
अंजीर। 1 भंडारण प्रणालियों और आईबीएस के संपर्क की योजनाऔर मुख्य समस्या इसके साथ जुड़ी हुई है - समर्थन का अंत। संग्रहण प्रणाली पर स्थापित डेटा ONTAP 8.2 7-मोड ऑपरेटिंग सिस्टम के लिए, कुछ वर्षों से कोई बड़ा अपडेट नहीं हुआ है, और महत्वपूर्ण त्रुटि सुधारों की रिहाई 2021 में बंद हो जाएगी। नई ड्राइव और नियंत्रक विरासत ऑपरेटिंग सिस्टम के साथ संगत नहीं हैं।
समाधान इन संग्रहण नियंत्रकों के लिए अंतिम समर्थित एक के रूप में ONTAP 9.1 क्लस्टर सिस्टम में संक्रमण है। इसके मुख्य लाभ हैं:
- एकल दोष-सहिष्णु क्लस्टर में संयोजन करके क्षैतिज स्केलिंग, जो आपको उत्पादक भंडारण और SRK पर आधारित एकल प्रणाली बनाने की अनुमति देगा।
- कंट्रोलर, डिस्क के साथ-साथ स्टोरेज सिस्टम के अंदर डेटा ले जाने और बिना एप्लिकेशन को एक्सेस किए रोक के बीच लोड बैलेंसिंग।
- उनके काम में बाधा और सेवा में रुकावट के बिना डेटा स्टोरेज सिस्टम के हार्डवेयर और सॉफ्टवेयर का रखरखाव।
- तृतीय-पक्ष भंडारण प्रणालियों सहित विभिन्न प्रकार के नियंत्रकों और डिस्क सहित विषम क्लस्टर विन्यास बनाने की क्षमता, उनकी डिस्क क्षमता के वर्चुअलाइजेशन के लिए लाइसेंस के उपयोग के अधीन है।
- कुलियों के लिए SSD को कैश लेयर के रूप में उपयोग करने की क्षमता।
- डेटा संघनन तंत्र (संपीडन और डिडुप्लीकेशन) का अनुकूलित ऑपरेशन।
7 मोड से क्लस्टर मोड में माइग्रेट करने के लिए 3 विकल्प हैं:
- Netapp 7-मोड ट्रांज़िशन टूल (7MTT) और कॉपी-आधारित संक्रमण (CBT) का उपयोग करके डेटा प्रतिकृति के साथ माइग्रेट करना। इसके लिए, स्नैप डिस्क के आधार पर एक छोटे डिस्क स्थान और चरणबद्ध प्रतिकृति के साथ एक दूसरी भंडारण प्रणाली की आवश्यकता होती है। प्रत्येक सेवा के लिए, स्विचिंग को एक निश्चित समय पर समन्वित और निष्पादित किया जाता है।
हमारे ग्राहकों में से एक पर, हमने पहले ही मेट्रो क्लस्टर पर इस प्रक्रिया को किया था। बड़ी संख्या में वॉल्यूम के कारण, LUN (> 400) और विवरण, डाउनटाइम्स आदि का लंबा समन्वय। प्रशिक्षण को छोड़कर प्रवास में लगभग 3 महीने लगे। - नेटप 7-मोड ट्रांज़िशन टूल (7MTT) और कॉपी-फ्री ट्रांज़िशन (CFT) का उपयोग करके मूविंग डेटा के बिना माइग्रेट करें। ऐसा करने के लिए, आपको न्यूनतम संख्या में डिस्क के साथ दूसरी भंडारण प्रणाली की आवश्यकता होती है, जो प्रारंभिक तैयारी के बाद उत्पादक डिस्क सबसिस्टम को स्विच करेगी। सभी सेवाओं के लिए, एक बड़े डाउनटाइम पर सहमति है।
- होस्ट टूल का उपयोग करके डेटा की प्रतिलिपि बनाने के साथ माइग्रेशन। यह किसी भी निर्माताओं के भंडारण प्रणालियों के बीच पारंपरिक प्रवास पथ है।
चूंकि मौजूदा भंडारण प्रणालियां अभी भी विक्रेता के समर्थन में थीं, और निकट भविष्य में नियंत्रकों का प्रदर्शन पर्याप्त था, इसलिए नए नियंत्रकों की खरीद के लिए बजट आवंटित नहीं किया गया था। इस संबंध में, 7MTT CFT का उपयोग करके नियंत्रकों को क्लस्टर मोड में स्थानांतरित करने का निर्णय लिया गया। मुख्य आवश्यकताओं में से एक भंडारण प्रणालियों के संचालन में ध्यान देने योग्य रुकावटों की अनुपस्थिति थी: अधिकांश प्रणालियों को कार्यदिवसों पर आसानी से काम करना चाहिए। इसलिए, सप्ताहांत के लिए एक उत्पादक भंडारण प्रणाली पर प्रवासन का मुख्य कार्य निर्धारित किया गया था।
तैयारी चरण भंडारण प्रणाली से जानकारी के संग्रह और प्रारंभिक जांच के संचालन के साथ शुरू हुआ। विशेष नेटएप 7MTT सॉफ्टवेयर अलर्ट की एक सूची बनाता है जो माइग्रेशन में हस्तक्षेप कर सकता है या इसे पूरा करने में विफल हो सकता है। उदाहरण के लिए, सिस्टम में से एक के लिए, इस सूची में 200 से अधिक आइटम शामिल थे। ओएस के नवीनतम समर्थित संस्करणों में सभी प्रणालियों को अपडेट करना, नियंत्रकों, डिस्क अलमारियों और स्वयं डिस्क के फर्मवेयर को अपडेट करना आवश्यक था। इसके अलावा, नए ऑपरेटिंग सिस्टम में ऑपरेशन का एक अलग तर्क है, जिसमें भंडारण प्रणालियों के बीच अतिरिक्त आईपी पते और कनेक्शन की आवश्यकता होती है।
स्टॉप फ़ैक्टर को बहुत तेज़ी से खोजा गया - क्लाइंट ने ऐसी तकनीक का इस्तेमाल किया जो पूरी मात्रा प्रतिकृति पर आधारित नहीं थी, लेकिन qtree प्रतिकृति पर (एक उपधारा जिसमें पहुंच, वॉल्यूम, आदि प्रतिबंध लागू होते हैं) और नए OS में ऐसे SnapVault रिश्तों को स्थानांतरित करना असंभव है । नतीजतन, काम शुरू करने से पहले, सभी प्रतिकृति प्रतियों को पूरी तरह से हटाने के लिए आवश्यक होगा। यह सुनिश्चित करने के लिए कि इस कदम के बाद क्लाइंट को बैकअप के बिना नहीं छोड़ा गया था, संपूर्ण वॉल्यूम प्रतिकृति पर आधारित बैकअप माइग्रेशन से पहले शुरू किया गया था। SnapMirror का उपयोग करते हुए, पुराने लोगों के बगल में नए बैकअप बनाए गए थे, और चार हफ्तों के दौरान परिवर्तन का एक लॉग जमा हुआ था। और अगर किसी एक साइट पर इसके लिए पर्याप्त जगह थी, तो दूसरे स्थान पर सीमित था, धीरे-धीरे किसी एक वॉल्यूम की प्रतियां बनाना आवश्यक था। चार हफ्तों के बाद, पुराने रिश्तों को हटा दिया गया और नए लोगों को बनाया गया। एक काफी लंबी, चरणबद्ध प्रक्रिया, जिसमें एक साइट के मामले में लगभग 1.5 महीने लगते हैं, और दूसरे में 3 से अधिक। इसके अलावा, मैं यह नोट करना चाहता हूं कि स्नैपचैट संबंध को रोकने की प्रक्रिया लक्ष्य qtree को हटाने के साथ है और इसकी निष्पादन गति दृढ़ता से फाइलों की संख्या और इसके आकार पर कुछ हद तक निर्भर करती है। उदाहरण के लिए, 4 मिलियन फाइलों के साथ क्यूट्री और 500GB का आकार 24 घंटों के भीतर हटा दिया गया था।
इस प्रक्रिया में, विभिन्न कठिनाइयाँ उत्पन्न हुईं। क्लाइंट सिस्टम पर परिवर्तन करने की प्रक्रियाओं के नौकरशाहीकरण ने काम के समन्वय की शर्तों को बढ़ा दिया। सौभाग्य से, हम तकनीकी मुद्दों को सीधे हल करने के लिए सहमत हुए, एक उच्च स्तर पर चर्चा करते हुए केवल महत्वपूर्ण, "वैचारिक" मुद्दों, जैसे कि एक कार्य योजना पर सहमत होना और प्रवास के लिए विशिष्ट तिथियां चुनना।
अस्थायी भंडारण के उपयोग के कारण कठिनाइयाँ हुईं। 7MTT के मार्गदर्शन में, हमने आवश्यकताओं और पूर्व-जांच के अनुसार दोनों भंडारण प्रणालियों को कॉन्फ़िगर किया। फिर उन्होंने पुराने भंडारण को बंद कर दिया और डिस्क अलमारियों को नए से जोड़ा। फिर से सब कुछ चेक किया। NetApp सॉफ्टवेयर के दृष्टिकोण से, माइग्रेशन प्रक्रिया पूरी हो गई है और सभी
शैंपेन के पीछे फैल
गए हैं । लेकिन अगला कदम पुराने क्लाइंट नियंत्रकों के लिए सब कुछ वापस करना था। तथ्य यह है कि इस तरह के एक संक्रमण - नए नियंत्रकों से पुराने वाले तक - आधिकारिक तौर पर समर्थित नहीं है। वापस स्विच करने के बाद, ओएस त्रुटियों में डालना शुरू कर दिया और क्लस्टर के साथ समस्याओं के बारे में शिकायत की। शोध के बाद, मुझे पता चला कि समस्या इस तथ्य के कारण है कि क्लस्टर अचानक स्विच्ड मोड पर चला गया था और स्विचलेस वापस नहीं लौटना चाहता था। त्रुटि को ठीक करने में लंबा समय लगा। क्लस्टर लॉन्च के साथ समस्याओं को हल किया गया था कि स्टार्ट-अप पर मुकाबला नेटवर्क के लिए केबल कनेक्ट न करें, एक केबल पर इंट्रा-क्लस्टर नेटवर्क हटा दिया गया था, फिर दूसरा जोड़ा गया था। वैसे, यह याद रखना चाहिए कि ओएस के पुराने नियंत्रकों और पुराने संस्करणों पर, इंट्रा-क्लस्टर नेटवर्क को केवल एडेप्टर की सीमित सीमा के कुछ बंदरगाहों पर उठाया जा सकता है, उदाहरण के लिए, FAS3250 पर यह e1a और e2a है (ग्राहक को 10GB ईथरनेट कार्ड खरीदना था)।
उन्होंने दूसरी साइट पर काम करने के लिए अतिरिक्त समय रखा, कम से कम कुछ समस्याओं से बचने की उम्मीद की, लेकिन इससे मदद नहीं मिली - ऑपरेटिंग सिस्टम ने अप्रत्याशित व्यवहार किया। चार्ट को दो बार स्थानांतरित किया गया था। पहले मामले में, जब हम FAS3250 के साथ काम कर रहे थे, तो ग्राहक के नेटवर्क इन्फ्रास्ट्रक्चर की हाल ही में बदली गई सेटिंग्स में त्रुटि के कारण 24/7 का संचालन करने वाले कॉम्बैट सिस्टम को माइग्रेट करना संभव नहीं था (हालांकि काम शुरू होने से एक सप्ताह पहले माइग्रेशन का परीक्षण करते समय, सब कुछ उड़ गया)। vMotion ने रिमोट स्टोरेज सिस्टम से 1 एमबीपीएस से कम की गति से वर्चुअल मशीनों की नकल की।
माइग्रेशन के दौरान, क्लाइंट ने आर्किटेक्चर को आंशिक रूप से बदल दिया। उनके VMware vSphere बुनियादी ढांचे को वितरित किए गए वॉल्यूम पहले NFS ईथरनेट पर जारी किए गए थे। क्लाइंट ने उन्हें रिड्यूस किया और वे फाइबर चैनल में चले गए। माइग्रेशन प्रक्रिया के दौरान, यह पता चला कि LUN ने अपनी आईडी को पूरी तरह से बदल दिया है और, तदनुसार, VMware ने नए LUN को देखा, जिन्हें पुराने डेटा के साथ संबोधित किया गया था, और उन्हें स्थायी रूप से कनेक्ट करने से इनकार कर दिया था। परिणामस्वरूप, VMware विशेषज्ञों की मदद के लिए धन्यवाद, चल रहे आधार पर कंसोल के माध्यम से इन LUN को कनेक्ट करना संभव था, यह दर्शाता है कि यह पुराने डेटास्टोर्स का स्नैपशॉट है। फिर मुझे VMware होस्ट को रिबूट करना पड़ा। नतीजतन, वे आभासी मशीनों को देखने और आभासी बुनियादी ढांचे को बढ़ाने में कामयाब रहे। और अगर क्लाइंट एनएफएस का उपयोग करना जारी रखता है, तो ऐसी समस्या उत्पन्न नहीं होगी - आईपी पते और डीएनएस नाम पहले की तरह ही बने रहे।
कार्य योजना सीधे प्रवास के दिनों में:
शुक्रवार: भंडारण प्रणालियों और IBS के साथ काम करते हैं
- उन्होंने SnapVault और SnapMirror के बीच सभी संबंधों को रोक दिया, अस्थायी भंडारण को बंद कर दिया और जांच की कि सिस्टम प्रवास के लिए तैयार हैं। हमने प्रतिलिपि मुक्त संक्रमण पद्धति का उपयोग करके भंडारण को 7MTT में स्थानांतरित करने की प्रक्रिया शुरू की। अस्थायी नियंत्रक के लिए पुन: कनेक्टेड डिस्क डिस्क रेजिमेंट।
- 7MTT में स्थानांतरित, SRK के स्टोरेज सिस्टम के डिस्क अलमारियों में प्रतिस्थापन नियंत्रकों के रूट वॉल्यूम को माइग्रेट किया गया। हमने नए ईथरनेट एडेप्टर स्थापित किए, SRK स्टोरेज सिस्टम लॉन्च किया, कॉन्फ़िगरेशन को मिटाया, और HTTP छवि को नेटवर्क से HTTP सर्वर पर डाउनलोड किया। हमने फर्मवेयर और ओएस के नए संस्करण स्थापित किए (इस स्तर पर नेटवर्क पर छवि को डाउनलोड करने के साथ अस्पष्टीकृत समस्याएं थीं। अंत में, यह सीधे लैपटॉप से डाउनलोड किया गया था)।
- हमने क्लस्टर में नियंत्रकों को पुराने लोगों के साथ बदल दिया और युद्ध डिस्क अलमारियों को स्टोरेज सिस्टम से अपग्रेड करके स्टोरेज सिस्टम का उपयोग करके जोड़ा। हमने क्लस्टर को पुनर्स्थापित किया, नेटवर्क इंटरफेस को पुन: कॉन्फ़िगर किया (मुझे क्लस्टर के गलत संचालन से जुड़ी समस्याओं को हल करना था) और लाइसेंस कुंजी स्थापित की।
शनिवार: मुख्य भंडारण के साथ काम करें
- हमने अस्थायी डिस्क अलमारियों को अस्थायी भंडारण से जोड़ा और इसे फिर से सेट किया।
- महत्वपूर्ण वर्चुअल मशीन VMware vMotion का उपयोग करके एक दूरस्थ डेटा केंद्र में भंडारण के लिए माइग्रेट हुई।
- CFT पद्धति का उपयोग करते हुए प्रमुख भंडारण प्रणालियों को 7MTT में माइग्रेट किया गया था। उन्होंने मुख्य मुकाबला भंडारण को बंद कर दिया, इसकी डिस्क अलमारियों को नियंत्रक से जोड़ा और ओएस मेटाडेटा को 7MTT में बदल दिया। स्वैप नियंत्रकों का रूट वॉल्यूम SRK स्टोरेज सिस्टम के डिस्क अलमारियों में चला गया।
- हमने नए ईथरनेट एडेप्टर इंस्टॉल किए और डिस्क स्टोरेज में बैटल स्टोरेज को लॉन्च किया, सेटिंग्स को मिटाया और फिर HTTP सर्वर से नेटवर्क पर डाउनलोड किया। नए फर्मवेयर और ओएस संस्करण स्थापित किए। हमने क्लस्टर में नियंत्रकों को प्रतिस्थापित किया, लड़ाकू डिस्क अलमारियों को मूविंग स्टोरेज प्रक्रिया द्वारा अपग्रेड करके स्टोरेज सिस्टम से जोड़ा।
- क्लस्टर को पुन: कॉन्फ़िगर किया गया, नेटवर्क इंटरफ़ेस (कनेक्टेड नेटवर्क इंटरफेस के कारण गलत तरीके से काम करने वाले क्लस्टर के साथ छेड़छाड़)। स्थापित लाइसेंस कुंजी।
- हमने VMware सर्वर में स्टोरेज कनेक्शन को बहाल किया, सैन नेटवर्क में ज़ोनिंग को बदला, LUN की मैपिंग को कॉन्फ़िगर किया, एफसी एक्सेस के साथ काम करने के लिए वॉल्यूम को एक अलग SVM में स्थानांतरित किया। ईएसएक्सआई से जुड़े लुन। इस तथ्य के कारण कि एलयूएन आईडी बदल गया है, डेटास्टोर्स स्वचालित मोड में नहीं दिखाई दिए, मुझे लगातार ईएसएक्सआई सर्वर को फिर से चालू करना पड़ा और लंक को एस्किंली के माध्यम से कमांड से कनेक्ट करना पड़ा।
- पुन: कॉन्फ़िगर किए गए युद्ध इंटरफ़ेस, नाम बदलकर CIFS सर्वर और CIFS गेंदों और NFS निर्यात तक पहुंच प्राप्त की।
रविवार: IBS सॉफ्टवेयर की समस्या का समाधान और स्थापना
- वर्चुअल मशीनें स्टोरेज सिस्टम से युद्धक स्टोरेज सिस्टम की ओर वापस चली गईं।
- हमने लिनक्स होस्ट से रिकॉर्डिंग मोड में फ़ोल्डर तक पहुंचने के साथ समस्या को हल किया। हमने Netapp onCommand Unified Manager 7.3 निगरानी सॉफ़्टवेयर के नवीनतम संस्करण को तैनात किया और दोनों स्टोरेज सिस्टम को इससे जोड़ा।
- हमने यूनिफाइड मैनेजर सॉफ्टवेयर का उपयोग करते हुए इकाइयों पर वर्तमान लोड पर डेटा का विश्लेषण किया, एसएसडी का उपयोग करके हमने कैशिंग परत को मौजूदा डिस्क इकाइयों (फ्लैश / स्टोरेज पूल) से जोड़ा।
- उन्होंने वैकल्पिक भंडारण प्रणाली को बंद कर दिया, क्लस्टर लिंक (क्लस्टर पियरिंग, एसवीएम पियरिंग) बनाए ताकि प्रतिकृति का उपयोग किया जा सके। हमने मुख्य डेटा और मौजूदा वॉल्यूम के आधार पर SRK स्टोरेज (जो SnapMirror 7 मोड रिलेशनशिप में इस्तेमाल किए गए थे) के बीच नए डेटा बनाए और बदले हुए डेटा के रीकंस्ट्रक्शन के साथ SnapMirror रिलेशनशिप में बदल दिए।
- हम दोनों स्टोरेज सिस्टम को कॉमवाइट तकनीकी समर्थन का उपयोग करते हुए नेटवाप एसआरसी सॉफ्टवेयर में नेटवा ओपन रिप्लेसमेंट मोड से जोड़ते हैं, यह अलग तरीके से काम नहीं करता है, हालांकि हमने निर्देशों के अनुसार सब कुछ किया। SRK के स्टोरेज सिस्टम और स्टोरेज सिस्टम से ऑटोसुपोर्ट लॉग भेजना कॉन्फ़िगर किया गया।
सोमवार: पीस
- भंडारण प्रणाली के मुख्य उत्पादक भंडारण और भंडारण प्रणालियों के संचालन का सत्यापन। संभावित समस्याओं और खराबी का समाधान करना।
- अस्थायी उपकरणों को डिस्कनेक्ट और डिस्क्राइब करना।
प्रवासन में केवल दो दिन लगे। यह कदम सफल रहा, सभी ग्राहक डेटा सुरक्षित और मजबूत है। बैकअप प्रबंधन प्रणाली और मौजूदा SRK सॉफ्टवेयर के साथ एकीकरण को भी संरक्षित किया गया था। यदि आपने पहले OnCommand Unified Manager के साथ Commvault बंडल का उपयोग किया था, तो क्लस्टर मोड में स्विच करने के बाद, इसे CommAult को सीधे स्टोरेज नियंत्रकों से जोड़ने के लिए Netapp ओपन प्रतिकृति के पक्ष में छोड़ने का निर्णय लिया गया था।
इस माइग्रेशन के परिणामों के आधार पर मैं जो मुख्य सिफारिशें दे सकता हूं: नियंत्रकों को बदलने के साथ 7 मोड से क्लस्टर मोड पर स्विच करें। यदि आप अभी भी दूसरे नियंत्रकों को स्थानांतरित करने की योजना बना रहे हैं, जैसा कि ऊपर वर्णित मामले में है, तो आपको विभिन्न समस्याओं को हल करने के लिए पर्याप्त समय की योजना बनाने की आवश्यकता है जो पुराने नियंत्रकों पर वापस जाने पर आवश्यक रूप से उत्पन्न होंगी। 7MTT CFT का उपयोग करके मूविंग डेटा के बिना माइग्रेशन का उपयोग करना पूरी तरह से सुरक्षित प्रक्रिया है, यदि पेशेवरों द्वारा भरोसा किया जाता है।
इस प्रवास के दौरान उपयोग किए जाने वाले उपयोगी गाइड:
दिमित्री कोस्ट्रीकोव, स्टोरेज सिस्टम के अग्रणी डिजाइन इंजीनियर
कंप्यूटर कॉम्प्लेक्स के लिए डिज़ाइन सेंटर "जेट इन्फोसिस्टम्स"