AERODISK इंजन: प्रलय। भाग 2. मेट्रोक्लेस्टर

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

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

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

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

यह किस लिए है?

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

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

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

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

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

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

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

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

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

आर्बिटर कैसे काम करता है और उसका कार्य क्या है?

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

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

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

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

अब मध्यस्थ के विवरण में गोता लगाएँ

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

मध्यस्थ के तर्क पर अधिक विस्तार से विचार करें।

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

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

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

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

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

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

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

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

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

मेट्रो क्लस्टर के पेशेवरों और विपक्षों पर विचार करें

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

• पूर्ण स्वचालन एक आपदा की स्थिति में न्यूनतम वसूली समय प्रदान करता है;
• और यह :-) है।

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

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

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

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

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

खेल का मैदान

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

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

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

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

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

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

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

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

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

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

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

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

रेफरी विन्यास

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

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

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

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

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

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

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

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

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

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

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

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

मेट्रो क्लस्टर सेटअप

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

प्रतिकृति के लिए वर्चुअल IP (VIP) सेट करते समय, मेट्रो क्लस्टर के लिए VIP प्रकार का चयन करें।

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

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

SKHD1:

SKHD2:

प्रतिकृति कनेक्शन के लिए, उन्होंने प्रत्येक स्टोरेज सिस्टम पर मैपिंग की।

SKHD1:

SKHD2:

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

मध्यस्थ को कॉन्फ़िगर करें

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

रिमोट रिप्लेसमेंट में >> मेट्रोक्लास्टर सेक्शन (किसी भी कंट्रोलर पर) >> कॉन्फ़िगर बटन।

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

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

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

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

क्रैश टेस्ट

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

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

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

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

टेस्ट सफलतापूर्वक पूरा हुआ।

संक्षेप में देना

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

, , , … , , . , , , .

, .