AERODISK इन्जिन: आपदा प्रतिरोध। भाग २. मेट्रोक्लस्टर

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

सामान्य रूपमा, सिद्धान्त पहिले

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

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

यो केको लागि हो?

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

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

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

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

यसले कसरी काम गर्छ?

तल्लो तहमा, मेट्रोक्लस्टरले सिंक्रोनस डेटा प्रतिकृतिको लागि एक संयन्त्र प्रयोग गर्दछ, जुन हामीले अघिल्लो लेखमा वर्णन गरेका थियौं (हेर्नुहोस्। लिङ्क)। प्रतिकृति सिंक्रोनस भएकोले, यसको लागि आवश्यकताहरू अनुरूप छन्, वा बरु:

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

यी सबै आवश्यकताहरू प्रकृतिमा सल्लाहकार हुन्, त्यो हो, मेट्रोक्लस्टरले यी आवश्यकताहरू पूरा नगरे पनि काम गर्नेछ, तर हामीले बुझ्नुपर्छ कि यी आवश्यकताहरूको पालना नगर्ने परिणामहरू दुबै भण्डारण प्रणालीहरूको सञ्चालनमा मन्दी बराबर छन्। मेट्रो क्लस्टर।

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

मध्यस्थले कसरी काम गर्छ र उसको काम के हो?

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

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

एक धेरै महत्त्वपूर्ण बिन्दु। मध्यस्थ सँधै भण्डारण प्रणालीहरू अवस्थित साइटहरू भन्दा फरक साइटमा अवस्थित हुनुपर्छ, त्यो न त डाटा केन्द्र १ मा, जहाँ भण्डारण प्रणाली १ स्थापना गरिएको छ, न त डाटा केन्द्र २ मा, जहाँ भण्डारण प्रणाली २ स्थापना गरिएको छ।

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

अब मध्यस्थको कामको विवरणमा डुबौं।

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

मध्यस्थको कामको तर्कलाई थप विस्तारमा हेरौं।

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

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

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

यस्तो पुष्टिकरण प्राप्त गरेपछि, आर्बिटरले झरेको भण्डारण प्रणालीमा सक्रिय (प्राथमिक) प्रतिकृतिहरू परिवर्तन गर्न र म्यापिङ बढाउनको लागि रिमोट प्रक्रिया सुरु गर्दछ, र यी प्रतिकृतिहरूलाई माध्यमिकबाट प्राथमिक र परिवर्तन गर्न दोस्रो भण्डारण प्रणालीलाई आदेश पठाउँदछ। म्यापिङ बढाउनुहोस्। ठीक छ, दोस्रो भण्डारण प्रणाली, तदनुसार, यी प्रक्रियाहरू प्रदर्शन गर्दछ, र त्यसपछि आफैंबाट हराएको LUNहरूमा पहुँच प्रदान गर्दछ।

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

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

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

एक सेकेन्ड पर्खनुहोस्, यो बाहिर जान्छ कि यदि मेट्रोक्लस्टरको साथ सबै कुरा यति राम्रो छ भने, हामीलाई किन नियमित प्रतिकृति चाहिन्छ?

वास्तवमा, सबै कुरा यति सरल छैन।

मेट्रोक्लस्टरको फाइदा र विपक्षलाई विचार गरौं

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

• पूर्ण स्वचालन, प्रकोपको घटनामा न्यूनतम रिकभरी समय सुनिश्चित गर्दै;
• यति नै :-)।

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

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

अन्ततः। मेट्रोक्लस्टर पक्कै पनि धेरै प्राविधिक रूपमा उन्नत र राम्रो समाधान हो जब तपाईलाई सेकेन्ड वा मिनेटमा RTO उपलब्ध गराउन आवश्यक हुन्छ। तर यदि त्यहाँ त्यस्तो कुनै काम छैन, र घण्टामा RTO व्यवसायको लागि ठीक छ, तब तोपबाट भँगेराहरू हान्नुको कुनै अर्थ छैन। सामान्य कामदार-किसान प्रतिकृति पर्याप्त छ, किनकि मेट्रो क्लस्टरले थप लागत र आईटी पूर्वाधारको जटिलता निम्त्याउनेछ।

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

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

स्थानहरू

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

डाटा केन्द्रहरू बीच सिफारिस गरिएको दूरी 40 किलोमिटर भन्दा बढी छैन। ठूलो दूरीले अतिरिक्त ढिलाइ निम्त्याउने सम्भावना धेरै हुन्छ, जुन मेट्रोक्लस्टरको अवस्थामा अत्यन्तै अवांछनीय हुन्छ। हामी तपाईंलाई सम्झाउने गरौं कि ढिलाइ 5 मिलिसेकेन्ड सम्म हुनुपर्छ, यद्यपि तिनीहरूलाई 2 भित्र राख्न सल्लाह दिइन्छ।

यो योजना प्रक्रिया को समयमा पनि ढिलाइ जाँच गर्न सिफारिस गरिएको छ। डेटा केन्द्रहरू बीच अप्टिकल फाइबर प्रदान गर्ने कुनै पनि कम वा कम परिपक्व प्रदायकहरूले गुणस्तर जाँचलाई चाँडै व्यवस्थित गर्न सक्छन्।

मध्यस्थ अघि ढिलाइको लागि (अर्थात, तेस्रो साइट र पहिलो दुई बीच), सिफारिस गरिएको ढिलाइ थ्रेसहोल्ड 200 मिलिसेकेन्ड सम्म छ, त्यो हो, इन्टरनेटमा नियमित कर्पोरेट VPN जडान उपयुक्त छ।

स्विचिङ र नेटवर्किङ

प्रतिकृति योजनाको विपरीत, जहाँ विभिन्न साइटहरूबाट भण्डारण प्रणालीहरू जडान गर्न पर्याप्त छ, मेट्रोक्लस्टर योजनाले विभिन्न साइटहरूमा दुवै भण्डारण प्रणालीहरूसँग होस्टहरू जडान गर्न आवश्यक छ। फरक के हो भनेर स्पष्ट पार्नको लागि, दुबै योजनाहरू तल देखाइएको छ।

रेखाचित्रबाट देख्न सकिन्छ, हाम्रो साइट 1 होस्टहरूले भण्डारण प्रणाली 1 र भण्डारण प्रणाली 2 दुवैलाई हेर्छन्। साथै, यसको विपरित, साइट 2 होस्टहरूले भण्डारण प्रणाली 2 र भण्डारण प्रणाली 1 दुवैलाई हेर्छन्। त्यो हो, प्रत्येक होस्टले दुबै भण्डारण प्रणालीहरू देख्छ। यो मेट्रोक्लस्टर को सञ्चालन को लागी एक पूर्व शर्त हो।

निस्सन्देह, प्रत्येक होस्टलाई अर्को डाटा केन्द्रमा अप्टिकल कर्डसँग जडान गर्न आवश्यक छैन; कुनै पोर्ट वा कर्डहरू पर्याप्त हुनेछैन। यी सबै जडानहरू इथरनेट 10G+ वा FibreChannel 8G+ स्विचहरू मार्फत गरिनुपर्छ (FC IO का लागि होस्टहरू र भण्डारण प्रणालीहरू जडान गर्नका लागि मात्र हो, प्रतिकृति च्यानल हाल IP (Ethernet 10G+) मार्फत मात्र उपलब्ध छ।

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

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

हामी यहाँ होस्ट स्रोतहरू पहुँच गर्न सबनेटहरू विचार गर्दैनौं, किनकि तिनीहरू कार्यहरूमा अत्यधिक निर्भर छन्।

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

आर्बिटर कन्फिगरेसन

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

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

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

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

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

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

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

माथिका आवश्यकताहरूलाई विचार गर्दै, हामी निम्न सामान्य समाधान वास्तुकला पाउँछौं।

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

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

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

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

मेट्रो क्लस्टर स्थापना गर्दै

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

प्रतिकृतिको लागि भर्चुअल आईपीहरू (VIPs) कन्फिगर गर्दा, तपाईंले VIP प्रकार चयन गर्नुपर्छ - मेट्रोक्लस्टरको लागि।

हामीले दुई LUN को लागि दुई प्रतिकृति लिङ्कहरू सिर्जना गर्यौं र तिनीहरूलाई दुई भण्डारण प्रणालीहरूमा वितरित गर्यौं: LUN TEST प्राथमिक भण्डारण प्रणाली 1 (METRO लिङ्क), LUN TEST2 प्राथमिक भण्डारण प्रणाली 2 को लागि (METRO2 लिङ्क)।

तिनीहरूका लागि, हामीले दुई समान लक्ष्यहरू कन्फिगर गर्यौं (हाम्रो अवस्थामा iSCSI, तर FC पनि समर्थित छ, सेटअप तर्क समान छ)।

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

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

प्रतिकृति जडानहरूको लागि, प्रत्येक भण्डारण प्रणालीमा म्यापिङहरू बनाइएका थिए।

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

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

हामीले मल्टिपाथ सेट अप गर्यौं र होस्टलाई प्रस्तुत गर्यौं।

एक मध्यस्थ स्थापना गर्दै

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

खण्डमा रिमोट प्रतिकृति>> मेट्रोक्लस्टर (कुनै पनि नियन्त्रकमा)>> "कन्फिगर" बटन।

हामी आर्बिटरको आईपी प्रविष्ट गर्छौं, साथै दुई रिमोट भण्डारण नियन्त्रकहरूको नियन्त्रण इन्टरफेसहरू।

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

हामी जाँच गर्छौं कि सबै सेवाहरू चलिरहेका छन्।

यसले मेट्रोक्लस्टर सेटअप पूरा गर्दछ।

क्र्यास परीक्षण

हाम्रो मामलामा क्र्यास परीक्षण एकदम सरल र छिटो हुनेछ, किनकि प्रतिकृति कार्यक्षमता (स्विचिङ, स्थिरता, आदि) मा छलफल गरिएको थियो। अन्तिम लेख। तसर्थ, मेट्रोक्लस्टरको विश्वसनीयता परीक्षण गर्न, यो हाम्रो लागि असफलता पत्ता लगाउने, स्विचिङ र रेकर्डिङ घाटाहरूको अनुपस्थिति (I/O रोकिन्छ) को स्वचालन जाँच गर्न पर्याप्त छ।

यसो गर्नको लागि, हामी एउटा भण्डारण प्रणालीको पूर्ण विफलतालाई यसको दुवै नियन्त्रकहरूलाई शारीरिक रूपमा बन्द गरेर, LUN मा ठूलो फाइल प्रतिलिपि गर्न थालेपछि, जुन अर्को भण्डारण प्रणालीमा सक्रिय हुनुपर्छ।

एउटा भण्डारण प्रणाली असक्षम गर्नुहोस्। दोस्रो भण्डारण प्रणालीमा हामी लगहरूमा अलर्टहरू र सन्देशहरू देख्छौं कि छिमेकी प्रणालीसँग जडान हराएको छ। यदि SMTP वा SNMP निगरानी मार्फत सूचनाहरू कन्फिगर गरिएको छ भने, प्रशासकले सम्बन्धित सूचनाहरू प्राप्त गर्नेछ।

ठीक १० सेकेन्ड पछि (दुवै स्क्रिनसटहरूमा देखिने), METRO प्रतिकृति जडान (असफल भण्डारण प्रणालीमा प्राथमिक थियो) स्वचालित रूपमा कार्यरत भण्डारण प्रणालीमा प्राथमिक भयो। अवस्थित म्यापिङ प्रयोग गरेर, LUN TEST होस्टको लागि उपलब्ध रह्यो, रेकर्डिङ थोरै घट्यो (प्रतिज्ञा गरिएको 10 प्रतिशत भित्र), तर अवरोध भएन।

परीक्षण सफलतापूर्वक सम्पन्न भयो।

सारांश

AERODISK इन्जिन N-श्रृङ्खला भण्डारण प्रणालीहरूमा मेट्रोक्लस्टरको हालको कार्यान्वयनले आईटी सेवाहरूको लागि डाउनटाइम हटाउन वा न्यूनीकरण गर्न र न्यूनतम श्रम लागतको साथ तिनीहरूको सञ्चालन 24/7/365 सुनिश्चित गर्न आवश्यक पर्ने समस्याहरू समाधान गर्न पूर्ण रूपमा अनुमति दिन्छ।

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

धन्यवाद, हामी उत्पादक छलफलको लागि तत्पर छौं।

स्रोत: www.habr.com