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

नमस्कार वाचकहो! गेल्या लेखात, आम्ही AERODISK ENGINE स्टोरेज सिस्टीममध्ये आपत्ती पुनर्प्राप्तीच्या सोप्या साधनांबद्दल बोललो - प्रतिकृती. या लेखात, आम्ही एका अधिक जटिल आणि मनोरंजक विषयावर जाऊ - मेट्रोक्लस्टर, म्हणजे, दोन डेटा केंद्रांसाठी स्वयंचलित आपत्ती संरक्षणाचे साधन, डेटा केंद्रांना सक्रिय-सक्रिय मोडमध्ये कार्य करण्यास अनुमती देते. आम्ही तुम्हाला सांगू, दाखवू, तो तोडून दुरुस्त करू.

नेहमीप्रमाणे, प्रथम सिद्धांत

मेट्रोक्लस्टर हे शहर किंवा प्रदेशातील अनेक साइटवर पसरलेले क्लस्टर आहे. "क्लस्टर" हा शब्द आम्हाला स्पष्टपणे सूचित करतो की कॉम्प्लेक्स स्वयंचलित आहे, म्हणजेच अपयशी झाल्यास क्लस्टर नोड्स स्विच करणे स्वयंचलितपणे होते.

येथेच मेट्रोक्लस्टर आणि नियमित प्रतिकृतीमधील मुख्य फरक आहे. ऑपरेशन्सचे ऑटोमेशन. म्हणजेच, काही घटना (डेटा सेंटर अयशस्वी होणे, तुटलेले चॅनेल इ.) झाल्यास, डेटाची उपलब्धता राखण्यासाठी स्टोरेज सिस्टम स्वतंत्रपणे आवश्यक क्रिया करेल. नियमित प्रतिकृती वापरताना, या क्रिया प्रशासकाद्वारे पूर्णपणे किंवा अंशतः व्यक्तिचलितपणे केल्या जातात.

हे कशासाठी आहे?

विशिष्ट मेट्रोक्लस्टर अंमलबजावणी वापरताना ग्राहक ज्या मुख्य ध्येयाचा पाठपुरावा करतात ते RTO (रिकव्हरी टाइम ऑब्जेक्टिव्ह) कमी करणे हे आहे. म्हणजेच, अयशस्वी झाल्यानंतर आयटी सेवांचा पुनर्प्राप्ती वेळ कमी करणे. आपण नियमित प्रतिकृती वापरल्यास, पुनर्प्राप्ती वेळ मेट्रोक्लस्टरसह पुनर्प्राप्ती वेळेपेक्षा नेहमीच जास्त असेल. का? अगदी साधे. प्रशासकाने त्याच्या डेस्कवर असणे आवश्यक आहे आणि प्रतिकृती व्यक्तिचलितपणे स्विच करणे आवश्यक आहे आणि मेट्रोक्लस्टर हे स्वयंचलितपणे करते.

तुमच्याकडे कर्तव्यावर समर्पित प्रशासक नसेल जो झोपत नाही, खात नाही, धुम्रपान करत नाही किंवा आजारी पडत नाही आणि दिवसाचे 24 तास स्टोरेज सिस्टमची स्थिती पाहतो, तर प्रशासक हे करेल याची खात्री देण्याचा कोणताही मार्ग नाही. अयशस्वी झाल्यास मॅन्युअल स्विचिंगसाठी उपलब्ध असेल.

त्यानुसार, मेट्रोक्लस्टर किंवा प्रशासक कर्तव्य सेवेच्या 99 व्या स्तराचा अमर प्रशासक नसताना आरटीओ सर्व सिस्टीमच्या स्विचिंग वेळेच्या बेरजेइतके असेल आणि त्यानंतर प्रशासकाने काम सुरू करण्याची हमी दिलेली कमाल कालावधी असेल. स्टोरेज सिस्टम आणि संबंधित सिस्टमसह.

अशाप्रकारे, आम्ही स्पष्ट निष्कर्षापर्यंत पोहोचतो की जर RTO साठी तास किंवा दिवसांची आवश्यकता नसून मिनिटांची आवश्यकता असेल तर मेट्रोक्लस्टरचा वापर केला पाहिजे. म्हणजेच, डेटा सेंटरमध्ये सर्वात वाईट बिघाड झाल्यास, आयटी विभागाने व्यवसायाला वेळेत प्रदान करणे आवश्यक आहे. काही मिनिटांत किंवा काही सेकंदात IT-सेवांमध्ये प्रवेश पुनर्संचयित करण्यासाठी.

ते कसे कार्य करते?

खालच्या स्तरावर, मेट्रोक्लस्टर सिंक्रोनस डेटा प्रतिकृतीसाठी एक यंत्रणा वापरते, ज्याचे आम्ही मागील लेखात वर्णन केले आहे (पहा. ссылка). प्रतिकृती सिंक्रोनस असल्याने, त्यासाठीच्या आवश्यकता संबंधित आहेत किंवा त्याऐवजी:

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

या सर्व आवश्यकता निसर्गतः सल्लागार आहेत, म्हणजेच, या आवश्यकता पूर्ण केल्या नाहीत तरीही मेट्रोक्लस्टर कार्य करेल, परंतु आपण हे समजून घेतले पाहिजे की या आवश्यकतांचे पालन न केल्याने होणारे परिणाम दोन्ही स्टोरेज सिस्टमच्या ऑपरेशनमध्ये मंदीसारखे आहेत. मेट्रोक्लस्टर.

तर, स्टोरेज सिस्टममधील डेटा ट्रान्सफर करण्यासाठी सिंक्रोनस प्रतिकृती वापरली जाते आणि प्रतिकृती आपोआप कशी बदलतात आणि सर्वात महत्त्वाचे म्हणजे, स्प्लिट-ब्रेन कसे टाळायचे? हे करण्यासाठी, उच्च स्तरावर, एक अतिरिक्त घटक वापरला जातो - एक मध्यस्थ.

मध्यस्थ कसे कार्य करते आणि त्याचे कार्य काय आहे?

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

आर्बिटर मेट्रोक्लस्टरमधील सर्व स्टोरेज सिस्टीमवर सतत लक्ष ठेवतो आणि एखादी विशिष्ट स्टोरेज सिस्टम अनुपलब्ध असल्यास, क्लस्टरच्या दुसर्‍या सदस्याकडून (“लाइव्ह” स्टोरेज सिस्टमपैकी एक) अनुपलब्धतेची पुष्टी केल्यानंतर, तो प्रतिकृती नियम बदलण्याची प्रक्रिया सुरू करण्याचा निर्णय घेतो. आणि मॅपिंग.

एक अतिशय महत्त्वाचा मुद्दा. मध्यस्थ नेहमी स्टोरेज सिस्टम असलेल्या साइटपेक्षा वेगळ्या साइटवर स्थित असणे आवश्यक आहे, म्हणजे, डेटा सेंटर 1 मध्ये नाही, जिथे स्टोरेज सिस्टम 1 स्थापित आहे किंवा डेटा सेंटर 2 मध्ये नाही, जिथे स्टोरेज सिस्टम 2 स्थापित आहे.

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

आता लवादाच्या कामाच्या तपशिलात जाऊ या.

आर्बिटर अनेक सेवा चालवतात ज्या सतत सर्व स्टोरेज कंट्रोलरचे मतदान करतात. मतदानाचा निकाल मागील (उपलब्ध/अनुपलब्ध) पेक्षा वेगळा असल्यास, तो एका लहान डेटाबेसमध्ये रेकॉर्ड केला जातो, जो आर्बिटरवर देखील कार्य करतो.

लवादाच्या कामाचे तर्क अधिक तपशीलवार पाहू या.

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

पायरी 2. स्विचिंग प्रक्रिया सुरू करा. लवादाच्या लक्षात आले की स्टोरेज सिस्टमपैकी एक अनुपलब्ध आहे, तो “डेड” स्टोरेज सिस्टम खरोखरच मृत आहे याची खात्री करण्यासाठी “लाइव्ह” स्टोरेज सिस्टमला विनंती पाठवतो.

आर्बिटरकडून अशी आज्ञा मिळाल्यानंतर, दुसरी (लाइव्ह) स्टोरेज सिस्टम अतिरिक्तपणे पडलेल्या पहिल्या स्टोरेज सिस्टमची उपलब्धता तपासते आणि ती नसल्यास, लवादाला त्याच्या अंदाजाची पुष्टी पाठवते. स्टोरेज सिस्टम खरंच अनुपलब्ध आहे.

अशी पुष्टी मिळाल्यानंतर, लवादाने पडलेल्या स्टोरेज सिस्टमवर सक्रिय (प्राथमिक) प्रतिकृती बदलण्यासाठी आणि मॅपिंग वाढवण्यासाठी रिमोट प्रक्रिया सुरू केली आणि या प्रतिकृती दुय्यम ते प्राथमिक आणि दुय्यम प्रतिकृती बदलण्यासाठी दुसऱ्या स्टोरेज सिस्टमला आदेश पाठवला. मॅपिंग वाढवा. बरं, दुसरी स्टोरेज सिस्टीम, त्यानुसार, या प्रक्रिया पार पाडते, आणि नंतर हरवलेल्या LUN मध्ये प्रवेश प्रदान करते.

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

टाईम स्टेप 2 मध्ये अंदाजे 5 - 10 सेकंद लागतात, अशा प्रकारे, अनुपलब्धता (5 सेकंद) निर्धारित करण्यासाठी लागणारा वेळ लक्षात घेऊन, अपघातानंतर 10 - 15 सेकंदांच्या आत, पडलेल्या स्टोरेज सिस्टममधील LUN थेट सोबत काम करण्यासाठी स्वयंचलितपणे उपलब्ध होतील. स्टोरेज सिस्टम.

हे स्पष्ट आहे की यजमानांसह कनेक्शन गमावू नये म्हणून, तुम्हाला यजमानांवर टाइमआउट्स योग्यरित्या कॉन्फिगर करण्याची देखील काळजी घेणे आवश्यक आहे. शिफारस केलेले कालबाह्य किमान 30 सेकंद आहे. हे आपत्तीच्या वेळी लोड स्विचिंग दरम्यान स्टोरेज सिस्टमशी कनेक्शन तोडण्यापासून होस्टला प्रतिबंधित करेल आणि I/O व्यत्यय नसल्याची खात्री करू शकेल.

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

प्रत्यक्षात, सर्व काही इतके सोपे नाही.

चला मेट्रोक्लस्टरच्या साधक आणि बाधकांचा विचार करूया

तर, आम्हाला समजले की पारंपारिक प्रतिकृतीच्या तुलनेत मेट्रोक्लस्टरचे स्पष्ट फायदे आहेत:

• संपूर्ण ऑटोमेशन, आपत्तीच्या वेळी किमान पुनर्प्राप्ती वेळ सुनिश्चित करणे;
• एवढेच :-).

आणि आता, लक्ष द्या, तोटे:

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

अखेरीस. जेव्हा तुम्हाला काही सेकंदात किंवा मिनिटांत आरटीओ प्रदान करणे आवश्यक असते तेव्हा मेट्रोक्लस्टर हे नक्कीच एक अतिशय तांत्रिकदृष्ट्या प्रगत आणि चांगले उपाय आहे. पण जर असे कोणतेही काम नसेल, आणि व्यवसायासाठी तासांमध्‍ये आरटीओ ठीक असेल, तर चिमण्यांना तोफेतून मारण्यात काही अर्थ नाही. सामान्य कामगार-शेतकरी प्रतिकृती पुरेशी आहे, कारण मेट्रो क्लस्टरमुळे आयटी पायाभूत सुविधांमध्ये अतिरिक्त खर्च आणि गुंतागुंत निर्माण होईल.

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

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

क्रीडांगणे

वर म्हटल्याप्रमाणे, मेट्रोक्लस्टरसाठी किमान तीन साइट्स आवश्यक आहेत. दोन डेटा केंद्रे जिथे स्टोरेज सिस्टीम आणि संबंधित सिस्टीम ऑपरेट करतील, तसेच तिसरी साइट जिथे आर्बिट्रेटर काम करेल.

डेटा केंद्रांमधील शिफारस केलेले अंतर 40 किलोमीटरपेक्षा जास्त नाही. मोठ्या अंतरामुळे अतिरिक्त विलंब होण्याची दाट शक्यता असते, जी मेट्रोक्लस्टरच्या बाबतीत अत्यंत अवांछनीय असते. आम्‍ही तुम्‍हाला आठवण करून देतो की विलंब 5 मिलीसेकंदांपर्यंत असावा, जरी तो 2 च्या आत ठेवण्याचा सल्ला दिला जातो.

नियोजन प्रक्रियेदरम्यान देखील विलंब तपासण्याची शिफारस केली जाते. डेटा केंद्रांदरम्यान ऑप्टिकल फायबर पुरवणारा कोणताही अधिक किंवा कमी प्रौढ प्रदाता गुणवत्ता तपासणीचे आयोजन करू शकतो.

लवादासमोरील विलंबासाठी (म्हणजे तिसरी साइट आणि पहिल्या दोन दरम्यान), शिफारस केलेला विलंब थ्रेशोल्ड 200 मिलीसेकंदांपर्यंत आहे, म्हणजेच इंटरनेटवर नियमित कॉर्पोरेट व्हीपीएन कनेक्शन योग्य आहे.

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

प्रतिकृती योजनेच्या विपरीत, जेथे वेगवेगळ्या साइट्सवरून स्टोरेज सिस्टम कनेक्ट करणे पुरेसे आहे, मेट्रोक्लस्टर स्कीममध्ये वेगवेगळ्या साइट्सवरील दोन्ही स्टोरेज सिस्टमसह होस्ट कनेक्ट करणे आवश्यक आहे. फरक काय आहे हे स्पष्ट करण्यासाठी, दोन्ही योजना खाली दर्शविल्या आहेत.

आकृतीवरून पाहिल्याप्रमाणे, आमची साइट 1 होस्ट स्टोरेज सिस्टम 1 आणि स्टोरेज सिस्टम 2 दोन्हीकडे पाहतात. तसेच, त्याउलट, साइट 2 होस्ट स्टोरेज सिस्टम 2 आणि स्टोरेज सिस्टम 1 दोन्हीकडे पाहतात. म्हणजेच, प्रत्येक होस्ट दोन्ही स्टोरेज सिस्टम पाहतो. मेट्रोक्लस्टरच्या ऑपरेशनसाठी ही एक पूर्व शर्त आहे.

अर्थात, प्रत्येक होस्टला ऑप्टिकल कॉर्डने दुसऱ्या डेटा सेंटरशी जोडण्याची गरज नाही; कोणतेही पोर्ट किंवा कॉर्ड पुरेसे नसतील. हे सर्व कनेक्शन इथरनेट 10G+ किंवा FibreChannel 8G+ स्विचेसद्वारे केले जाणे आवश्यक आहे (FC फक्त IO साठी होस्ट आणि स्टोरेज सिस्टम कनेक्ट करण्यासाठी आहे, प्रतिकृती चॅनेल सध्या फक्त IP (Ethernet 10G+) द्वारे उपलब्ध आहे.

आता नेटवर्क टोपोलॉजीबद्दल काही शब्द. एक महत्त्वाचा मुद्दा म्हणजे सबनेटचे योग्य कॉन्फिगरेशन. खालील प्रकारच्या रहदारीसाठी अनेक सबनेट त्वरित परिभाषित करणे आवश्यक आहे:

• रेप्लिकेशन सबनेट ज्यावर डेटा स्टोरेज सिस्टम्स दरम्यान सिंक्रोनाइझ केला जाईल. त्यापैकी बरेच असू शकतात, या प्रकरणात काही फरक पडत नाही, हे सर्व सध्याच्या (आधीपासून लागू केलेल्या) नेटवर्क टोपोलॉजीवर अवलंबून आहे. जर त्यापैकी दोन असतील, तर स्पष्टपणे त्यांच्या दरम्यान राउटिंग कॉन्फिगर करणे आवश्यक आहे;
• स्टोरेज सबनेट ज्याद्वारे होस्ट स्टोरेज स्त्रोतांमध्ये प्रवेश करतील (जर ते iSCSI असेल). प्रत्येक डेटा सेंटरमध्ये असे एक सबनेट असावे;
• कंट्रोल सबनेट्स, म्हणजे, तीन साइट्सवर तीन राउटेबल सबनेट्स ज्यामधून स्टोरेज सिस्टम व्यवस्थापित केले जातात आणि आर्बिटर देखील तिथे स्थित आहे.

आम्ही येथे होस्ट संसाधनांमध्ये प्रवेश करण्यासाठी सबनेटचा विचार करत नाही, कारण ते कार्यांवर खूप अवलंबून असतात.

वेगवेगळ्या सबनेटमध्ये भिन्न रहदारी विभक्त करणे अत्यंत महत्वाचे आहे (प्रतिकृती I/O मधून वेगळे करणे विशेषतः महत्वाचे आहे), कारण जर तुम्ही सर्व रहदारी एका "जाड" सबनेटमध्ये मिसळली, तर ही रहदारी व्यवस्थापित करणे अशक्य होईल, आणि दोन डेटा सेंटर्सच्या परिस्थितीमुळे हे अजूनही भिन्न नेटवर्क टक्कर पर्यायांना कारणीभूत ठरू शकते. आम्ही या लेखाच्या चौकटीत या समस्येचा सखोल अभ्यास करणार नाही, कारण आपण नेटवर्क उपकरणे उत्पादकांच्या संसाधनांवर डेटा सेंटर दरम्यान पसरलेल्या नेटवर्कची योजना करण्याबद्दल वाचू शकता, जिथे याचे तपशीलवार वर्णन केले आहे.

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

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

आर्बिटर फेलओव्हर अत्यंत इष्ट आहे, परंतु आवश्यक नाही. रेफरी चुकीच्या वेळी क्रॅश झाल्यास काय होईल?

• सामान्य मोडमध्ये मेट्रोक्लस्टरचे ऑपरेशन बदलणार नाही, कारण सामान्य मोडमध्ये मेट्रोक्लस्टरच्या ऑपरेशनवर arbtir चा पूर्णपणे कोणताही परिणाम होत नाही (त्याचे कार्य डेटा सेंटर दरम्यान लोड वेळेवर स्विच करणे आहे)
• शिवाय, जर मध्यस्थ एका कारणास्तव किंवा दुसर्‍या कारणास्तव पडतो आणि डेटा सेंटरमध्ये अपघात झाला तर "झोपला" तर कोणतेही स्विचिंग होणार नाही, कारण आवश्यक स्विचिंग कमांड देण्यासाठी आणि कोरम आयोजित करण्यासाठी कोणीही नसेल. या प्रकरणात, मेट्रोक्लस्टर प्रतिकृतीसह नियमित योजनेत बदलेल, जी आपत्तीच्या वेळी मॅन्युअली स्विच करावी लागेल, ज्यामुळे आरटीओवर परिणाम होईल.

यातून पुढे काय? तुम्‍हाला खरच किमान आरटीओची खात्री करण्‍याची आवश्‍यकता असल्‍यास, तुम्‍हाला आर्बिटर दोष-सहिष्णु असल्‍याची खात्री करणे आवश्‍यक आहे. यासाठी दोन पर्याय आहेत:

• फॉल्ट-टोलरंट हायपरवाइजरवर आर्बिटरसह व्हर्च्युअल मशीन लाँच करा, सुदैवाने सर्व प्रौढ हायपरवाइजर फॉल्ट टॉलरन्सला समर्थन देतात;
• जर तिसऱ्या साइटवर (पारंपारिक कार्यालयात) तुम्ही सामान्य क्लस्टर स्थापित करण्यात खूप आळशी असाल आणि तेथे कोणतेही हायपरव्होझर क्लस्टर नसेल, तर आम्ही आर्बिटरची हार्डवेअर आवृत्ती प्रदान केली आहे, जी 2U बॉक्समध्ये बनविली आहे ज्यामध्ये दोन सामान्य x-86 सर्व्हर कार्य करतात आणि जे स्थानिक अपयश टिकू शकतात.

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

समाधान आर्किटेक्चर

वरील आवश्यकता लक्षात घेऊन, आम्हाला खालील सामान्य समाधान आर्किटेक्चर मिळते.

गंभीर ओव्हरलोड टाळण्यासाठी LUN दोन साइटवर समान रीतीने वितरित केले जावे. त्याच वेळी, दोन्ही डेटा सेंटर्समध्ये आकारमान करताना, तुम्ही केवळ दुप्पट व्हॉल्यूम (जे एकाच वेळी दोन स्टोरेज सिस्टमवर डेटा संग्रहित करण्यासाठी आवश्यक आहे) समाविष्ट केले पाहिजे, परंतु IOPS आणि MB/s मध्ये अनुप्रयोगाची ऱ्हास टाळण्यासाठी दुप्पट कार्यप्रदर्शन देखील समाविष्ट केले पाहिजे. डेटा केंद्रांपैकी एकाच्या अपयशाची घटना. ov.

स्वतंत्रपणे, आम्ही लक्षात घेतो की आकारमानाच्या योग्य दृष्टिकोनासह (म्हणजे, आम्ही IOPS आणि MB/s च्या योग्य वरच्या मर्यादा, तसेच आवश्यक CPU आणि RAM संसाधने प्रदान केली आहेत), जर स्टोरेज सिस्टमपैकी एक मेट्रो क्लस्टर अयशस्वी झाले, एका स्टोरेज सिस्टमवर तात्पुरत्या कामाच्या परिस्थितीत कामगिरीमध्ये गंभीर घट होणार नाही.

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

सक्षम आकाराच्या मदतीने, आपण अशा परिस्थितीची खात्री करू शकता ज्या अंतर्गत वापरकर्त्यांना संपूर्ण स्टोरेज सिस्टमचे अपयश अजिबात जाणवणार नाही. परंतु आम्ही पुन्हा एकदा पुनरावृत्ती करतो, यासाठी खूप काळजीपूर्वक आकार देणे आवश्यक आहे, ज्यासाठी, आपण आमच्याशी विनामूल्य संपर्क साधू शकता :-).

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

मेट्रोक्लस्टर सेट करणे हे नियमित प्रतिकृती सेट करण्यासारखेच आहे, ज्याचे आम्ही वर्णन केले आहे मागील लेख. म्हणून, फक्त फरकांवर लक्ष केंद्रित करूया. आम्ही वरील आर्किटेक्चरच्या आधारे प्रयोगशाळेत एक बेंच स्थापित केला आहे, फक्त कमीत कमी आवृत्तीमध्ये: 10G इथरनेटद्वारे कनेक्ट केलेल्या दोन स्टोरेज सिस्टम, दोन 10G स्विचेस आणि एक होस्ट जो 10G पोर्टसह दोन्ही स्टोरेज सिस्टमवर स्विचमधून पाहतो. मध्यस्थ आभासी मशीनवर चालते.

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

आम्ही दोन LUN साठी दोन प्रतिकृती दुवे तयार केले आणि ते दोन स्टोरेज सिस्टममध्ये वितरित केले: स्टोरेज सिस्टम 1 वर LUN TEST प्राथमिक (METRO लिंक), LUN TEST2 प्राथमिक स्टोरेज सिस्टम 2 (METRO2 लिंक).

त्यांच्यासाठी, आम्ही दोन समान लक्ष्ये कॉन्फिगर केली आहेत (आमच्या बाबतीत iSCSI, परंतु FC देखील समर्थित आहे, सेटअप तर्क समान आहे).

स्टोरेज सिस्टम 1:

स्टोरेज सिस्टम 2:

प्रतिकृती कनेक्शनसाठी, प्रत्येक स्टोरेज सिस्टमवर मॅपिंग केले गेले.

स्टोरेज सिस्टम 1:

स्टोरेज सिस्टम 2:

आम्ही मल्टीपाथ सेट केले आणि ते होस्टला सादर केले.

लवादाची स्थापना करणे

तुम्हाला आर्बिटरबरोबरच काही विशेष करण्याची गरज नाही; तुम्हाला फक्त तिसऱ्या साइटवर ते सक्षम करणे आवश्यक आहे, त्याला एक IP द्या आणि ICMP आणि SSH द्वारे प्रवेश कॉन्फिगर करा. सेटअप स्वतः स्टोरेज सिस्टममधून केले जाते. या प्रकरणात, मेट्रोक्लस्टरमधील कोणत्याही स्टोरेज कंट्रोलरवर एकदा आर्बिटर कॉन्फिगर करणे पुरेसे आहे; या सेटिंग्ज स्वयंचलितपणे सर्व नियंत्रकांना वितरित केल्या जातील.

रिमोट रिप्लिकेशन>> मेट्रोक्लस्टर (कोणत्याही कंट्रोलरवर)>> "कॉन्फिगर" बटण या विभागात.

आम्ही आर्बिटरचा आयपी, तसेच दोन रिमोट स्टोरेज कंट्रोलरचे कंट्रोल इंटरफेस प्रविष्ट करतो.

यानंतर, तुम्हाला सर्व सेवा सक्षम करणे आवश्यक आहे (“सर्व काही रीस्टार्ट करा” बटण). भविष्यात पुन्हा कॉन्फिगर केल्यास, सेटिंग्ज प्रभावी होण्यासाठी सेवा रीस्टार्ट करणे आवश्यक आहे.

आम्ही तपासतो की सर्व सेवा चालू आहेत.

हे मेट्रोक्लस्टर सेटअप पूर्ण करते.

क्रॅश चाचणी

आमच्या बाबतीत क्रॅश चाचणी अगदी सोपी आणि जलद असेल, कारण प्रतिकृती कार्यक्षमता (स्विचिंग, सातत्य इ.) मध्ये चर्चा केली गेली होती. शेवटचा लेख. म्हणून, मेट्रोक्लस्टरच्या विश्वासार्हतेची चाचणी घेण्यासाठी, अपयश शोधणे, स्विच करणे आणि रेकॉर्डिंग नुकसान (I/O थांबणे) च्या अनुपस्थितीचे ऑटोमेशन तपासणे आमच्यासाठी पुरेसे आहे.

हे करण्यासाठी, आम्ही एका स्टोरेज सिस्टमच्या पूर्ण अपयशाचे अनुकरण करतो त्याचे दोन्ही कंट्रोलर भौतिकरित्या बंद करून, प्रथम मोठ्या फाइलची LUN वर कॉपी करणे सुरू केले, जी इतर स्टोरेज सिस्टमवर सक्रिय करणे आवश्यक आहे.

एक स्टोरेज सिस्टम अक्षम करा. दुसऱ्या स्टोरेज सिस्टीमवर आम्हाला लॉगमध्ये अलर्ट आणि संदेश दिसतात की शेजारच्या सिस्टमशी कनेक्शन तुटले आहे. SMTP किंवा SNMP मॉनिटरिंगद्वारे सूचना कॉन्फिगर केल्या असल्यास, प्रशासकास संबंधित सूचना प्राप्त होतील.

अगदी 10 सेकंदांनंतर (दोन्ही स्क्रीनशॉटमध्ये दृश्यमान), METRO प्रतिकृती कनेक्शन (जो अयशस्वी स्टोरेज सिस्टमवर प्राथमिक होता) स्वयंचलितपणे कार्यरत स्टोरेज सिस्टमवर प्राथमिक बनला. विद्यमान मॅपिंग वापरून, LUN चाचणी होस्टसाठी उपलब्ध राहिली, रेकॉर्डिंग थोडे कमी झाले (वचन दिलेल्या 10 टक्क्यांच्या आत), परंतु व्यत्यय आला नाही.

चाचणी यशस्वीरित्या पूर्ण झाली.

सारांश

AERODISK Engine N-Series स्टोरेज सिस्टीममधील मेट्रोक्लस्टरची सध्याची अंमलबजावणी IT सेवांसाठी डाउनटाइम दूर करणे किंवा कमी करणे आणि किमान श्रम खर्चासह त्यांचे ऑपरेशन 24/7/365 सुनिश्चित करणे आवश्यक असलेल्या समस्यांचे निराकरण करण्यास पूर्णपणे परवानगी देते.

आपण अर्थातच असे म्हणू शकतो की हे सर्व सिद्धांत, आदर्श प्रयोगशाळेची परिस्थिती आणि असेच बरेच काही आहे... परंतु आमच्याकडे अनेक कार्यान्वित प्रकल्प आहेत ज्यात आम्ही आपत्ती-लवचिकता कार्यक्षमतेची अंमलबजावणी केली आहे आणि प्रणाली उत्तम प्रकारे कार्य करतात. आपत्ती-प्रूफ कॉन्फिगरेशनमध्ये फक्त दोन स्टोरेज सिस्टीम वापरणार्‍या आमच्या बर्‍यापैकी सुप्रसिद्ध ग्राहकांपैकी एकाने या प्रकल्पाविषयी माहिती प्रकाशित करण्यास आधीच सहमती दर्शवली आहे, त्यामुळे पुढील भागात आम्ही लढाऊ अंमलबजावणीबद्दल बोलू.

धन्यवाद, आम्ही फलदायी चर्चेची अपेक्षा करतो.

स्त्रोत: www.habr.com