दुई नोड्स को क्लस्टर - शैतान विवरण मा छ

हे हाबर! म तपाईंको ध्यानाकर्षणमा लेखको अनुवाद प्रस्तुत गर्दछु "दुई नोडहरू - शैतान विवरणहरूमा छ" एन्ड्रयू बेखोफ द्वारा।

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

कुनै पनि उच्च उपलब्धता प्रणाली सिर्जना गर्ने पहिलो चरण असफलताको व्यक्तिगत बिन्दुहरू फेला पार्न र हटाउन प्रयास गर्नु हो, प्रायः संक्षिप्त रूपमा SPOF (विफलताको एकल बिन्दु)।

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

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

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

एक प्राकृतिक सुरूवात बिन्दु प्रणाली मा एक भन्दा बढी नोड हुनु हो। यद्यपि, प्रणालीले असफलता पछि जीवित नोडमा सेवाहरू सार्न सक्नु अघि, यसले सामान्यतया यो सुनिश्चित गर्न आवश्यक छ कि सार्न सेवाहरू अन्यत्र सक्रिय छैनन्।

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

त्यसकारण, एकल नोड विफलताको परिणामको रूपमा डेटा भ्रष्टाचार रोक्न - हामी भनिन्छ भन्ने कुरामा भर पर्छौं "पृथक्करण" (फेन्सिङ)।

वियोग को सिद्धान्त

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

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

प्रत्यक्ष र अप्रत्यक्ष दुवै विधिहरू प्रयोग गर्दा कोरमले मद्दत गर्छ।

प्रत्यक्ष वियोग

प्रत्यक्ष पृथकता को मामला मा, हामी नेटवर्क विफलता को घटना मा पृथक दौडहरु लाई रोक्न कोरम को प्रयोग गर्न सक्छौं।

कोरमको अवधारणाको साथ, त्यहाँ प्रणालीमा पर्याप्त जानकारी छ (यसका साथीहरूसँग जडान नगरी पनि) नोडहरू स्वचालित रूपमा थाहा पाउनको लागि कि उनीहरूले विच्छेद र/वा रिकभरी सुरु गर्नुपर्छ।

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

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

दुर्भाग्यवश, IPMI र iLo उपकरणहरूको अपरेटिङ सुविधाहरू उपकरण खरिदको समयमा विरलै विचार गरिन्छ।

अप्रत्यक्ष पृथक्करण

अप्रत्यक्ष डिससोसिएशन प्रबन्ध गर्न कोरम पनि महत्त्वपूर्ण छ; यदि सही तरिकाले गरियो भने, कोरमले बाँचेकाहरूलाई हराएको नोडहरू निश्चित समय पछि सुरक्षित स्थितिमा ट्रान्जिसन हुनेछ भनेर अनुमान गर्न अनुमति दिन सक्छ।

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

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

एउटा मोड छनोट गर्दा समस्या यो हो कि उपलब्धतालाई अधिकतम बनाउने र डेटा हानि रोक्ने कार्यको कुनै पाठ्यक्रम छैन।

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

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

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

कोरम

कोरम राम्रो लाग्छ, हैन?

केवल नकारात्मक पक्ष यो हो कि यसलाई N सदस्यहरूसँग क्लस्टरमा राख्नको लागि, तपाइँसँग तपाइँको बाँकी नोडहरूको N/2+1 बीचको जडान हुन आवश्यक छ। जुन एउटा नोड असफल भएपछि दुई नोड क्लस्टरमा सम्भव छैन।

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

दुई-नोड क्लस्टर कार्य बनाउँदै

कहिलेकाहीँ ग्राहकले तेस्रो नोड खरिद गर्न सक्दैन वा चाहँदैन, र हामी वैकल्पिक खोज्न बाध्य छौं।

विकल्प 1 - डुप्लिकेट विच्छेदन विधि

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

असफलता पछि, बचेकाले पहिलो पटक प्राथमिक विच्छेदन उपकरण (इम्बेडेड iLO वा IPMI) लाई सम्पर्क गर्ने प्रयास गर्दछ। यदि यो सफल भयो भने, रिकभरी सामान्य रूपमा जारी रहन्छ। iLO/IPMI यन्त्र असफल भएमा मात्र PDU पहुँच गरिन्छ; यदि पहुँच सफल भयो भने, रिकभरी जारी रहन सक्छ।

PDU लाई क्लस्टर ट्राफिक भन्दा फरक नेटवर्कमा राख्न निश्चित हुनुहोस्, अन्यथा एकल सञ्जाल विफलताले दुवै छुट्याउने यन्त्रहरूमा पहुँच रोक्नेछ र सेवाहरूको पुनर्स्थापना रोक्नेछ।

यहाँ तपाइँ सोध्न सक्नुहुन्छ - के PDU असफलताको एकल बिन्दु हो? जसको जवाफ पक्कै पनि हो।

यदि यो जोखिम तपाईंको लागि महत्त्वपूर्ण छ भने, तपाईं एक्लै हुनुहुन्न: दुबै नोडहरू दुई PDU मा जडान गर्नुहोस् र क्लस्टरिङ सफ्टवेयरलाई नोडहरू सक्रिय र बन्द गर्दा दुवै प्रयोग गर्न भन्नुहोस्। यदि एउटा PDU मरेमा क्लस्टर अब सक्रिय रहन्छ, र अर्को PDU वा IPMI यन्त्रको दोस्रो असफलता रिकभरी ब्लक गर्न आवश्यक हुनेछ।

विकल्प २ - आर्बिटर थप्दै

केही परिदृश्यहरूमा, जब नक्कल विच्छेदन विधि प्राविधिक रूपमा सम्भव छ, यो राजनीतिक रूपमा गाह्रो छ। धेरै कम्पनीहरू प्रशासकहरू र एप्लिकेसन मालिकहरू बीच केही अलग हुन चाहन्छन्, र सुरक्षा-सचेत नेटवर्क प्रशासकहरू सधैं कसैसँग PDU पहुँच सेटिङहरू साझेदारी गर्न उत्साहित हुँदैनन्।

यस अवस्थामा, सिफारिस गरिएको विकल्प भनेको तटस्थ तेस्रो पक्ष सिर्जना गर्नु हो जसले कोरम गणनालाई पूरक बनाउन सक्छ।

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

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

आर्बिटर र तेस्रो नोड बीचको व्यावहारिक भिन्नता यो हो कि मध्यस्थलाई सञ्चालन गर्न धेरै कम स्रोतहरू चाहिन्छ र सम्भावित रूपमा एक भन्दा बढी क्लस्टर सेवा गर्न सक्छ।

विकल्प 3 - मानव कारक

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

बोनस विकल्प

के मैले उल्लेख गरें कि तपाइँ तेस्रो नोड थप्न सक्नुहुन्छ?

दुई रैक

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

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

छोटो जवाफ हो कि यो सम्भव छैन, र फेरि हामी दुई-नोड मामला मा सबै समस्याहरु संग व्यवहार गर्दैछौं। वा जीवित व्यक्ति:

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

कुनै पनि अवस्थामा, दुई र्याकहरू एक भन्दा राम्रो हुँदैनन्, र नोडहरूले कि त स्वतन्त्र पावर आपूर्तिहरू प्राप्त गर्नुपर्दछ वा तीन (वा धेरै, तपाईंसँग कति नोडहरू छन् भन्ने आधारमा) र्याकहरूमा वितरित हुनुपर्छ।

दुई डाटा केन्द्रहरू

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

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

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

स्रोत: www.habr.com