एयरोडिस्क इंजन: आपदा प्रतिरोध। भाग 2. मेट्रोक्लस्टर

नमस्ते, हैबर पाठकों! पिछले लेख में, हमने एरोडिस्क इंजन स्टोरेज सिस्टम में आपदा सहनशीलता के एक सरल साधन - प्रतिकृति के बारे में बात की थी। इस लेख में, हम एक अधिक जटिल और दिलचस्प विषय पर चर्चा करेंगे - मेट्रोक्लस्टर, यानी दो डेटा केंद्रों के लिए आपदा सुरक्षा का एक स्वचालित साधन, जो डेटा केंद्रों को सक्रिय-सक्रिय मोड में संचालित करने की अनुमति देता है। हम बताएंगे, दिखाएंगे, तोड़ेंगे और ठीक करेंगे।

हमेशा की तरह, सिद्धांत पहले

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

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

यह क्या करता है?

कुछ मेट्रो क्लस्टर कार्यान्वयन का उपयोग करते समय ग्राहक जो मुख्य लक्ष्य अपनाते हैं, वह है RTO (रिकवरी टाइम ऑब्जेक्टिव) को कम करना। यानी, विफलता के बाद IT सेवाओं को पुनर्स्थापित करने में लगने वाले समय को कम करना। यदि आप नियमित प्रतिकृति का उपयोग करते हैं, तो पुनर्प्राप्ति समय हमेशा मेट्रो क्लस्टर के साथ पुनर्प्राप्ति समय से अधिक होगा। क्यों? यह बहुत सरल है। व्यवस्थापक को कार्यस्थल पर होना चाहिए और प्रतिकृति को मैन्युअल रूप से स्विच करना चाहिए, जबकि मेट्रो क्लस्टर इसे स्वचालित रूप से करता है।

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

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

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

यह कैसे काम करता है?

निचले स्तर पर, मेट्रोक्लस्टर सिंक्रोनस डेटा प्रतिकृति तंत्र का उपयोग करता है जिसका वर्णन हमने पिछले लेख में किया था (देखें लिंक) चूंकि प्रतिकृति समकालिक है, इसलिए इसके लिए आवश्यकताएं उपयुक्त हैं, या अधिक सटीक रूप से:

• फाइबर ऑप्टिक्स भौतिकी के रूप में, 10 गीगाबिट ईथरनेट (या उच्चतर);
• डेटा केंद्रों के बीच की दूरी 40 किलोमीटर से अधिक नहीं है;
• डेटा केंद्रों (भंडारण प्रणालियों के बीच) के बीच ऑप्टिकल चैनल विलंब 5 मिलीसेकंड तक (इष्टतम 2)।

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

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

रेफरी कैसे काम करता है और उसका कार्य क्या है?

मध्यस्थ एक छोटी वर्चुअल मशीन या हार्डवेयर क्लस्टर है जिसे किसी तीसरी साइट (उदाहरण के लिए, कार्यालय में) पर लॉन्च किया जाना चाहिए और ICMP और SSH के माध्यम से स्टोरेज सिस्टम तक पहुँच प्रदान करनी चाहिए। लॉन्च करने के बाद, मध्यस्थ को एक IP सेट करना चाहिए, और फिर स्टोरेज सिस्टम की तरफ से उसका पता निर्दिष्ट करना चाहिए, साथ ही मेट्रो क्लस्टर में भाग लेने वाले रिमोट कंट्रोलर के पते भी। उसके बाद, मध्यस्थ काम करने के लिए तैयार है।

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

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

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

अब आइये रेफरी के कार्य के विवरण पर नजर डालें।

आर्बिट्रेटर पर कई सेवाएँ चल रही हैं, जो लगातार सभी स्टोरेज कंट्रोलर से पोल करती हैं। यदि पोल का परिणाम पिछले वाले से भिन्न होता है (उपलब्ध/अनुपलब्ध), तो इसे एक छोटे डेटाबेस में लिखा जाता है, जो आर्बिट्रेटर पर भी चलता है।

आइये रेफरी के काम के तर्क पर अधिक विस्तार से विचार करें।

चरण 1: अनुपलब्धता का निर्धारण करें. भंडारण प्रणाली की विफलता का घटना-संकेत एक भंडारण प्रणाली के दोनों नियंत्रकों से 5 सेकंड के लिए पिंग की अनुपस्थिति है।

चरण 2. स्विचिंग प्रक्रिया प्रारंभ करें। जब मध्यस्थ को यह पता चलता है कि भंडारण प्रणालियों में से एक अनुपलब्ध है, तो वह "सक्रिय" भंडारण प्रणाली को एक अनुरोध भेजता है ताकि यह सत्यापित किया जा सके कि "मृत" भंडारण प्रणाली वास्तव में मृत है।

मध्यस्थ से ऐसा आदेश प्राप्त करने के बाद, दूसरा (सक्रिय) स्टोरेज सिस्टम पहले विफल स्टोरेज सिस्टम की उपलब्धता की भी जांच करता है और यदि वह उपलब्ध नहीं है, तो मध्यस्थ को अपने अनुमान की पुष्टि भेजता है। स्टोरेज सिस्टम वास्तव में अनुपलब्ध है।

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

अतिरिक्त जाँच की आवश्यकता क्यों है? कोरम के लिए। यानी, क्लस्टर प्रतिभागियों की कुल विषम (3) संख्या के बहुमत को क्लस्टर नोड्स में से किसी एक की विफलता की पुष्टि करनी चाहिए। तभी यह निर्णय बिल्कुल सही होगा। गलत स्विचिंग और तदनुसार, विभाजित मस्तिष्क से बचने के लिए यह आवश्यक है।

चरण 2 में लगभग 5-10 सेकंड का समय लगता है, अतः अनुपलब्धता निर्धारित करने के लिए आवश्यक समय (5 सेकंड) को ध्यान में रखते हुए, क्रैश के 10-15 सेकंड के भीतर, डाउन स्टोरेज सिस्टम से LUN स्वचालित रूप से लाइव स्टोरेज सिस्टम के साथ काम करने के लिए उपलब्ध हो जाएंगे।

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

एक क्षण रुकिए, यदि मेट्रोक्लस्टर के साथ सब कुछ इतना अच्छा है, तो हमें नियमित प्रतिकृतिकरण की आवश्यकता क्यों है?

हकीकत में, सबकुछ इतना सरल नहीं है।

आइए मेट्रो क्लस्टर के फायदे और नुकसान पर विचार करें

इसलिए, हमने महसूस किया कि पारंपरिक प्रतिकृति की तुलना में मेट्रो क्लस्टर के स्पष्ट लाभ ये हैं:

• पूर्ण स्वचालन, जिससे आपदा की स्थिति में न्यूनतम पुनर्प्राप्ति समय सुनिश्चित हो;
• और यह सबकुछ है :-)।

और अब, ध्यान दें, नकारात्मक पहलू:

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

अंततः। जब आपको सचमुच कुछ सेकंड या मिनटों में आरटीओ प्रदान करने की आवश्यकता हो, तो मेट्रोक्लस्टर निश्चित रूप से एक बहुत ही तकनीकी रूप से उन्नत और अच्छा समाधान है। लेकिन अगर ऐसा कोई काम नहीं है, और घंटों में आरटीओ व्यवसाय के लिए ठीक है, तो तोप से गौरैया मारने का कोई मतलब नहीं है। एक नियमित मजदूर-किसान प्रतिकृति पर्याप्त है, क्योंकि एक मेट्रो क्लस्टर अतिरिक्त लागत और आईटी बुनियादी ढांचे की जटिलता का कारण बनेगा।

मेट्रोक्लस्टर योजना

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

स्थानों

जैसा कि ऊपर बताया गया है, मेट्रो क्लस्टर के लिए कम से कम तीन साइटों की आवश्यकता होती है। दो डेटा सेंटर जहां स्टोरेज सिस्टम और संबंधित सिस्टम संचालित होंगे, और एक तीसरी साइट जहां मध्यस्थ काम करेगा।

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

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

जहां तक ​​रेफरी में देरी का सवाल है (अर्थात तीसरी साइट और पहली दो साइटों के बीच), अनुशंसित देरी सीमा 200 मिलीसेकंड तक है, अर्थात इंटरनेट पर एक नियमित कॉर्पोरेट वीपीएन कनेक्शन पर्याप्त होगा।

स्विचिंग और नेटवर्किंग

प्रतिकृति योजना के विपरीत, जहाँ अलग-अलग साइटों से स्टोरेज सिस्टम को कनेक्ट करना ही पर्याप्त है, मेट्रो क्लस्टर योजना के लिए होस्ट को अलग-अलग साइटों पर दोनों स्टोरेज सिस्टम से कनेक्ट करना आवश्यक है। यह स्पष्ट करने के लिए कि अंतर क्या है, दोनों योजनाएँ नीचे दिखाई गई हैं।

जैसा कि आप आरेख से देख सकते हैं, साइट 1 के हमारे होस्ट SAN1 और SAN2 दोनों को देखते हैं। और इसके विपरीत, साइट 2 के होस्ट SAN2 और SAN1 दोनों को देखते हैं। यानी, प्रत्येक होस्ट दोनों SAN को देखता है। मेट्रो क्लस्टर के काम करने के लिए यह एक अनिवार्य शर्त है।

बेशक, प्रत्येक होस्ट को ऑप्टिकल केबल के साथ दूसरे डेटा सेंटर में खींचने की कोई ज़रूरत नहीं है, कोई पोर्ट या केबल पर्याप्त नहीं होगा। ये सभी कनेक्शन ईथरनेट 10G+ या फाइबर चैनल 8G+ स्विच (FC केवल IO के लिए होस्ट और स्टोरेज सिस्टम को जोड़ने के लिए, प्रतिकृति चैनल वर्तमान में केवल IP (ईथरनेट 10G+) के माध्यम से उपलब्ध है) के माध्यम से किए जाने चाहिए।

अब नेटवर्क टोपोलॉजी के बारे में कुछ शब्द। एक महत्वपूर्ण बिंदु सबनेट का सही कॉन्फ़िगरेशन है। निम्नलिखित प्रकार के ट्रैफ़िक के लिए तुरंत कई सबनेट परिभाषित करना आवश्यक है:

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

हम यहां होस्ट संसाधनों तक पहुंचने के लिए सबनेट पर विचार नहीं करते हैं, क्योंकि वे अत्यधिक कार्य-निर्भर होते हैं।

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

आर्बिटर कॉन्फ़िगरेशन

मध्यस्थ को ICMP और SSH प्रोटोकॉल के माध्यम से सभी स्टोरेज सिस्टम प्रबंधन इंटरफेस तक पहुंच प्रदान की जानी चाहिए। आपको मध्यस्थ की गलती सहनशीलता के बारे में भी सोचना चाहिए। यहाँ एक बारीक़ अंतर है।

रेफरी का लचीलापन बहुत वांछनीय है, लेकिन ज़रूरी नहीं है। अगर रेफरी गलत समय पर क्रैश हो जाए तो क्या होगा?

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

इससे क्या निष्कर्ष निकलता है? यदि आपको वास्तव में न्यूनतम RTO सुनिश्चित करने की आवश्यकता है, तो आपको मध्यस्थ की गलती सहनशीलता सुनिश्चित करने की आवश्यकता है। इसके लिए दो विकल्प हैं:

• एक दोष-सहिष्णु हाइपरवाइजर पर एक मध्यस्थ के साथ एक वर्चुअल मशीन लॉन्च करें, सौभाग्य से सभी वयस्क हाइपरवाइजर दोष सहिष्णुता का समर्थन करते हैं;
• यदि तीसरी साइट पर (एक पारंपरिक कार्यालय में) एक सामान्य क्लस्टर स्थापित करने में बहुत आलस्य है और कोई मौजूदा हाइपरवाइजर क्लस्टर नहीं है, तो हमने मध्यस्थ का एक हार्डवेयर संस्करण प्रदान किया है, जिसे 2U बॉक्स में कार्यान्वित किया जाता है जिसमें दो नियमित x-86 सर्वर संचालित होते हैं और जो स्थानीय विफलता से बच सकते हैं।

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

समाधान वास्तुकला

उपरोक्त आवश्यकताओं को ध्यान में रखते हुए, हम निम्नलिखित सामान्य समाधान संरचना प्राप्त करते हैं।

गंभीर ओवरलोड से बचने के लिए LUN को दोनों साइटों पर समान रूप से वितरित किया जाना चाहिए। साथ ही, दोनों डेटा सेंटर में आकार निर्धारित करते समय, न केवल वॉल्यूम को दोगुना करना आवश्यक है (जो दो स्टोरेज सिस्टम पर एक साथ डेटा स्टोर करने के लिए आवश्यक है), बल्कि डेटा सेंटर में से किसी एक की विफलता की स्थिति में एप्लिकेशन की गिरावट को रोकने के लिए IOPS और MB/s में प्रदर्शन को भी दोगुना करना आवश्यक है।

अलग से, हम ध्यान देते हैं कि आकार निर्धारण के उचित दृष्टिकोण के साथ (अर्थात, बशर्ते कि हमने IOPS और MB/s के लिए उचित ऊपरी सीमाएं प्रदान की हों, साथ ही आवश्यक CPU और RAM संसाधन भी), यदि मेट्रो क्लस्टर में से कोई एक भंडारण प्रणाली विफल हो जाती है, तो एक भंडारण प्रणाली पर अस्थायी संचालन की स्थिति में प्रदर्शन में कोई गंभीर गिरावट नहीं होगी।

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

सक्षम आकार निर्धारण की सहायता से, ऐसी परिस्थितियाँ सुनिश्चित करना संभव है जिसके अंतर्गत संपूर्ण संग्रहण प्रणाली की विफलता उपयोगकर्ताओं को बिल्कुल भी महसूस न हो। लेकिन हम एक बार फिर दोहराते हैं, इसके लिए बहुत सावधानीपूर्वक आकार निर्धारण की आवश्यकता होती है, जिसके लिए, वैसे, आप हमसे निःशुल्क संपर्क कर सकते हैं :-)।

मेट्रो क्लस्टर की स्थापना

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

किसी प्रतिकृति के लिए वर्चुअल आईपी (वीआईपी) कॉन्फ़िगर करते समय, आपको मेट्रो क्लस्टर के लिए वीआईपी प्रकार का चयन करना चाहिए।

हमने दो LUN के लिए दो प्रतिकृति लिंक बनाए और उन्हें दो भंडारण प्रणालियों में वितरित किया: भंडारण प्रणाली 1 पर LUN TEST प्राथमिक (METRO लिंक), भंडारण प्रणाली 2 के लिए LUN TEST2 प्राथमिक (METRO2 लिंक)।

उनके लिए, हमने दो समान लक्ष्यों को कॉन्फ़िगर किया (हमारे मामले में, iSCSI, लेकिन FC भी समर्थित है, कॉन्फ़िगरेशन तर्क समान है)।

एसएचडी1:

एसएचडी2:

प्रतिकृति लिंक के लिए, प्रत्येक भंडारण प्रणाली पर मैपिंग बनाई गई।

एसएचडी1:

एसएचडी2:

हमने मल्टीपाथ को कॉन्फ़िगर किया और इसे होस्ट के सामने प्रस्तुत किया।

मध्यस्थ की स्थापना

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

रिमोट प्रतिकृति अनुभाग में >> मेट्रोक्लस्टर (किसी भी नियंत्रक पर) >> "कॉन्फ़िगर करें" बटन।

हम मध्यस्थ का आईपी, साथ ही दो दूरस्थ भंडारण प्रणाली नियंत्रकों के नियंत्रण इंटरफेस दर्ज करते हैं।

इसके बाद, आपको सभी सेवाओं को सक्षम करना होगा ("सभी को पुनः आरंभ करें" बटन)। भविष्य में पुनः कॉन्फ़िगरेशन के मामले में, सेटिंग्स को प्रभावी करने के लिए सेवाओं को पुनः आरंभ करना होगा।

हम जांच करते हैं कि सभी सेवाएं चल रही हैं।

इससे मेट्रो क्लस्टर की स्थापना पूरी हो जाती है।

क्रैश टेस्ट

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

ऐसा करने के लिए, हम एक भंडारण प्रणाली की पूर्ण विफलता का अनुकरण करते हैं, इसके दोनों नियंत्रकों को भौतिक रूप से बंद कर देते हैं, सबसे पहले LUN में एक बड़ी फाइल की प्रतिलिपि बनाना शुरू करते हैं, जिसे अन्य भंडारण प्रणाली पर सक्रिय किया जाना चाहिए।

हम एक स्टोरेज सिस्टम को बंद कर देते हैं। दूसरे स्टोरेज सिस्टम पर हम लॉग में अलर्ट और संदेश देखते हैं कि पड़ोसी सिस्टम से कनेक्शन टूट गया है। यदि SMTP या SNMP मॉनिटरिंग नोटिफिकेशन कॉन्फ़िगर किए गए हैं, तो एडमिनिस्ट्रेटर को संबंधित नोटिफिकेशन प्राप्त होंगे।

ठीक 10 सेकंड बाद (दोनों स्क्रीनशॉट में दिखाई दे रहा है), मेट्रो प्रतिकृति लिंक (जो विफल स्टोरेज सिस्टम पर प्राथमिक था) स्वचालित रूप से काम कर रहे स्टोरेज सिस्टम पर प्राथमिक बन गया। मौजूदा मैपिंग का उपयोग करते हुए, LUN TEST होस्ट के लिए उपलब्ध रहा, लेखन थोड़ा कम हुआ (वादा किए गए 10 प्रतिशत के भीतर), लेकिन बाधित नहीं हुआ।

परीक्षण सफलतापूर्वक पूरा हो गया।

बुलाने

एरोडिस्क इंजन एन-सीरीज भंडारण प्रणालियों में मेट्रोक्लस्टर का वर्तमान कार्यान्वयन उन समस्याओं को पूरी तरह से हल करने की अनुमति देता है जहां आईटी सेवाओं के डाउनटाइम को खत्म करना या कम करना आवश्यक है और न्यूनतम श्रम लागत के साथ 24/7/365 मोड में उनका संचालन सुनिश्चित करना है।

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

धन्यवाद, हम एक उपयोगी चर्चा की आशा करते हैं।

स्रोत: www.habr.com