NetApp Metrocluster

2007 में, फॉरेस्टर कंसल्टिंग एजेंसी ने आईटी के लिए दुर्घटनाओं के जोखिमों का आकलन करने के लिए 250 आईटी विशेषज्ञों का एक सर्वेक्षण किया, उदाहरण के लिए, डेटा सेंटर के अंदर और बाहर, प्राकृतिक दुर्घटनाओं और आपदाओं के जोखिम।

परिणामों को संसाधित करने और प्रकाशित करने के बाद, यह स्पष्ट हो गया कि सामान्य रूप में दोष सहिष्णुता सुनिश्चित करने का सामान्य साधन, उदाहरण के लिए, पारंपरिक "निरर्थक, निरंकुश नियंत्रक और RAID" सभी संभावित विफलताओं के केवल 31% के खिलाफ रक्षा कर सकते हैं।

ग्राफ पर, आप आईटी आपदाओं को भी देखते हैं जैसे कि बिजली की विफलताएं (" - आपकी बिजली का क्या हुआ? - यह झपका । "), सॉफ्टवेयर समस्याएं (" ... और यह बंद हो जाएगा "), मानवीय त्रुटियां (" जैसा कि आपने वॉल्यूम का नाम कहा था। " जिसे आपको अनमाउंट और बैंग करना था? "), नेटवर्क सेटिंग्स एरर (" - और किस इंटरफेस का उपयोग करना है? - eth0 का प्रयास करें। "), साथ ही प्राकृतिक ( और ऐसा नहीं ) कैटेसिल्म, जैसे कि आग , बाढ़ और इतने पर की एक किस्म।

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


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

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

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

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

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

तो क्यों न इन सभी कार्यों को सीधे स्टोरेज कंट्रोलर को ही सौंप दिया जाए? क्यों नहीं एक भंडारण प्रणाली है जो अपने "प्रतिकृति" सरल और "पारदर्शी" अनुप्रयोगों के लिए स्विच करता है?

यह इस सरल विचार से था कि NetApp Metrocluster का जन्म हुआ - वितरित क्लस्टर भंडारण के लिए एक सॉफ्टवेयर और हार्डवेयर समाधान।

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

किसी दुर्घटना या किसी "असामान्य घटना" की स्थिति में, कंट्रोलर "अपने" डेटा तक पहुंचने के अलावा, क्लस्टर पार्टनर के डेटा तक पहुंच प्राप्त करता है और इसके सभी संसाधनों को भी स्थानांतरित करता है, जैसे कि इसके ईथरनेट इंटरफेस के आईपी पते, डब्ल्यूडब्ल्यूपीएन इंटरफेस FC, LUN नाम और "नेटवर्क बॉल", DNS नाम, और इतने पर, ताकि स्विच करने के बाद अनुप्रयोग "पहले की तरह" काम करते रहें, एक अन्य नियंत्रक बस अपना डेटा कार्य करता है।

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

NetApp Metrocluster दो फ्लेवर में आती है। यह तथाकथित स्ट्रेच्च्ड मेट्रोक्लेस्टर है, जिसमें इसके घटकों की अधिकतम पृथक्करण दूरी एक विशेष क्लस्टर इंटरकनेक्ट केबल की अनुमेय लंबाई से निर्धारित होती है, 500 मीटर से अधिक नहीं; और स्विच्ड मेट्रोक्लेस्टर, जिसमें लंबाई केवल लघौल एलडब्ल्यू फाइबर चैनल की अधिकतम लंबाई तक सीमित है, वर्तमान में 100 किमी।
(VMware वेबसाइट की तस्वीर VMware vSphere FT के लिए Metrocluster के उपयोग को दिखाती है, लेकिन इसके स्थान पर कोई अनुप्रयोग हो सकता है)



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

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



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

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

स्पष्टता के लिए, आइए संभावित विफलता परिदृश्यों को देखें।

सबसे आसान विकल्प एक मेजबान विफलता है।
सर्वर को होस्ट 2 पर सर्वर क्लस्टरिंग के माध्यम से उठाया जाता है, और काम करना जारी रखता है, भंडारण के लिए मूल डेटा सेंटर के "कारखाने" के माध्यम से डेटा तक पहुंच प्राप्त कर रहा है 1. (डेटा का मार्ग नीली रेखाओं में दिखाया गया है)



इसके अलावा एक आम कहानी एक भंडारण नियंत्रक विफलता है।
जैसा कि पहले दिखाए गए मामले में, एक्सेस स्विचिंग स्वचालित है।



नाटक बढ़ रहा है। पूरे स्टोरेज के आधे हिस्से की विफलता। ऑपरेटर या मॉनिटरिंग सॉफ्टवेयर क्लस्टर टेकओवर पर निर्णय लेता है, जिसे कुछ सेकंड में एक सिंगल cf टेकओवर कमांड द्वारा किया जाता है और अनुप्रयोगों के लिए पारदर्शी होता है।



तबाही। पूरा डेटा सेंटर होस्ट और स्टोरेज सिस्टम के आधे हिस्से के साथ खो गया है। डेटा तक पहुंच बचाई गई। दूसरा क्लस्टर कंट्रोलर हमेशा की तरह "अपना" डेटा और अपनी वेबसाइट पर उसकी कॉपी से पार्टनर डेटा परोसता है।



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



बेशक, एक पूरे के रूप में समाधान मुश्किल हो जाता है और सस्ता नहीं है (हालांकि एनालॉग से सस्ता)। डेटा डिस्क के दो सेट (वितरित नेटवर्क RAID -1 का एक प्रकार), प्रत्येक साइट पर एक, एक समर्पित आंतरिक एफसी स्विचिंग "फ़ैक्टरी" जिसके माध्यम से "स्टोरेज क्लस्टर" के भीतर संचार और साइटों के बीच पारस्परिक तुल्यकालिक डेटा प्रतिकृति है, लेकिन उन मामलों में जब यह " 31% मामलों में " काम प्रदान करने के लिए आवश्यक है, लेकिन "हमेशा", जब डाउनटाइम या डेटा भ्रष्टाचार की लागत अधिक होती है, तो संगठन बचत नहीं करना पसंद करते हैं।

हालाँकि, स्टोरेज सिस्टम की नई FAS3200 / 6200 श्रृंखला जारी करने के साथ, जिसमें मेट्रो क्लस्टर के आयोजन के लिए लाइसेंस का एक सेट पहले से ही बुनियादी वितरण में शामिल है, इस समाधान के अधिक व्यापक उपयोग की ओर एक कदम उठाया गया है।