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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

एक मध्यस्थ कैसे कार्य करता है और उसका कार्य क्या है?

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

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

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

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

आइए अब मध्यस्थ के कार्य के विवरण में उतरें।

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

आइए मध्यस्थ के कार्य के तर्क को अधिक विस्तार से देखें।

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

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

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

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

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

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

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

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

हकीकत में सबकुछ इतना आसान नहीं है.

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

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

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

और अब, ध्यान, विपक्ष:

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

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

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

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

स्थानों

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

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

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

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

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

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

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

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

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

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

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

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

मध्यस्थ विन्यास

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

आर्बिटर फेलओवर अत्यधिक वांछनीय है, लेकिन आवश्यक नहीं है। यदि रेफरी गलत समय पर क्रैश हो जाए तो क्या होगा?

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

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

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

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

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

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

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

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

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

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

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

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

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

हमने दो LUN के लिए दो प्रतिकृति लिंक बनाए और उन्हें दो स्टोरेज सिस्टम में वितरित किया: स्टोरेज सिस्टम 1 पर LUN टेस्ट प्राइमरी (METRO लिंक), स्टोरेज सिस्टम 2 के लिए LUN TEST2 प्राइमरी (METRO2 लिंक)।

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

भंडारण प्रणाली1:

भंडारण प्रणाली2:

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

भंडारण प्रणाली1:

भंडारण प्रणाली2:

हमने मल्टीपाथ स्थापित किया और इसे मेजबान के सामने प्रस्तुत किया।

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

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

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

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

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

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

यह मेट्रोक्लस्टर सेटअप को पूरा करता है।

क्रैश टेस्ट

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

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

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

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

परीक्षण सफलतापूर्वक पूरा हुआ.

बुलाने

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

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

धन्यवाद, हम सार्थक चर्चा की आशा करते हैं।

स्रोत: www.habr.com