GitHub पर MySQL उच्च उपलब्धता

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

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

रिकॉर्डिंग का समर्थन करने के लिए, एक संगत सुलभ नोड की आवश्यकता होती है - क्लस्टर में मुख्य नोड। हालांकि, ऐसे नोड की पहचान या पता लगाने की क्षमता भी उतनी ही महत्वपूर्ण है।

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

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

उच्च उपलब्धता लक्ष्य

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

उच्च उपलब्धता और सेवा खोज के लिए सही समाधान खोजने के लिए, आपको पहले कुछ विशिष्ट प्रश्नों का उत्तर देना चाहिए। यहाँ एक नमूना सूची है:

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

प्रदर्शित करने के लिए, आइए पहले हम पिछले समाधान पर विचार करें और चर्चा करें कि हमने इसे छोड़ने का फैसला क्यों किया।

खोज के लिए VIP और DNS का उपयोग करने से इनकार करना

पिछले समाधान के भाग के रूप में, हमने उपयोग किया:

• गलती का पता लगाने और विफलता के लिए ऑर्केस्ट्रेटर ;
• मेजबान खोज के लिए वीआईपी और डीएनएस।

उस स्थिति में, ग्राहकों ने अपने नाम से एक रिकॉर्डिंग नोड की खोज की, उदाहरण के लिए, mysql-writer-1.github.net । नाम का उपयोग मुख्य नोड के वर्चुअल आईपी पते (वीआईपी) को निर्धारित करने के लिए किया गया था।

इस प्रकार, एक सामान्य स्थिति में, ग्राहकों को केवल नाम को हल करना होगा और प्राप्त आईपी पते से कनेक्ट करना होगा, जहां मुख्य नोड पहले से ही उनका इंतजार कर रहा था।

निम्नलिखित प्रतिकृति टोपोलॉजी पर विचार करें जो तीन अलग-अलग डेटा केंद्रों को फैलाती है:

मुख्य नोड की विफलता की स्थिति में, एक नया सर्वर को उसके स्थान (प्रतिकृति में से एक) को सौंपा जाना चाहिए।

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

वीआईपी पते साझा किए जाते हैं, डेटाबेस सर्वर स्वयं अनुरोध करते हैं और उनके मालिक होते हैं। VIP प्राप्त करने या जारी करने के लिए, सर्वर को ARP अनुरोध भेजना होगा। नए स्वामी के इस पते पर पहुंचने से पहले वीआईपी के स्वामित्व वाले सर्वर को पहले इसे जारी करना होगा। यह दृष्टिकोण कुछ अवांछनीय परिणामों की ओर जाता है:

• सामान्य मोड में, फेलओवर सिस्टम पहले असफल मुख्य नोड से संपर्क करेगा और वीआईपी जारी करने के लिए अनुरोध करेगा, और फिर वीआईपी असाइनमेंट के लिए अनुरोध के साथ नए मुख्य सर्वर को चालू करेगा। लेकिन क्या होगा यदि पहला मुख्य नोड अनुपलब्ध है या वीआईपी पते को जारी करने के अनुरोध को मना कर देता है? यह देखते हुए कि सर्वर वर्तमान में विफलता की स्थिति में है, यह संभावना नहीं है कि यह समय में एक अनुरोध का जवाब देने में सक्षम होगा या सभी के लिए इसका जवाब देगा।
  
  1. नतीजतन, एक स्थिति उत्पन्न हो सकती है जब दो मेजबान एक ही वीआईपी के अपने अधिकारों का दावा करते हैं। अलग-अलग क्लाइंट इनमें से किसी भी सर्वर से सबसे छोटे नेटवर्क पथ के आधार पर जुड़ सकते हैं।
  2. इस स्थिति में सही संचालन दो स्वतंत्र सर्वरों की बातचीत पर निर्भर करता है, और ऐसा विन्यास अविश्वसनीय है।
• यहां तक ​​कि अगर पहला मुख्य नोड अनुरोधों का जवाब देता है, तो हम मूल्यवान समय बर्बाद करते हैं: जब हम पुराने से संपर्क करते हैं तो नए मुख्य सर्वर पर स्विच नहीं होता है।
• इसके अलावा, वीआईपी के पुनर्मूल्यांकन के मामले में भी, इस बात की कोई गारंटी नहीं है कि पुराने सर्वर पर मौजूदा क्लाइंट कनेक्शन काट दिया जाएगा। फिर, हम दो स्वतंत्र मुख्य नोड्स के साथ एक स्थिति में होने का जोखिम चलाते हैं।

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

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

ये प्रतिबंध हमें एक नए समाधान की खोज शुरू करने के लिए मजबूर करने के लिए पर्याप्त थे, लेकिन हमें निम्नलिखित बातों का भी ध्यान रखना था:

• देरी और लोड विनियमन को मापने के लिए मुख्य नोड्स ने pt-heartbeat माध्यम से स्वतंत्र रूप से पल्स पैकेट को प्रसारित किया। सेवा को नव नियुक्त मुख्य नोड में स्थानांतरित किया जाना था। यदि संभव हो, तो इसे पुराने सर्वर पर अक्षम किया जाना चाहिए था।
• इसी तरह, मुख्य नोड्स ने स्वतंत्र रूप से स्यूडो-जीटीआईडी के संचालन को नियंत्रित किया। नए मुख्य नोड पर इस प्रक्रिया को शुरू करना और पुराने पर रोकना आवश्यक था।
• नया मास्टर नोड लेखन योग्य बन गया। पुराना नोड (यदि संभव हो तो) read_only (केवल पढ़ने के लिए) होना चाहिए।

इन अतिरिक्त कदमों ने समग्र डाउनटाइम में वृद्धि की और विफलता और समस्याओं के अपने अंक जोड़े।

समाधान काम किया, और GitHub ने पृष्ठभूमि में MySQL विफलताओं को सफलतापूर्वक संभाला, लेकिन हम हा के रूप में अपने दृष्टिकोण में सुधार करना चाहते थे:

• विशिष्ट डेटा केंद्रों से स्वतंत्रता सुनिश्चित करना;
• डेटा सेंटर विफलताओं के मामले में संचालन की गारंटी;
• अविश्वसनीय सहयोगी वर्कफ़्लो का त्याग करें
• कुल डाउनटाइम कम करें;
• प्रदर्शन करें, जहां तक ​​संभव हो, बिना नुकसान के असफलता।

गिटहब हा समाधान: ऑर्केस्ट्रेटर, कॉन्सुल, जीएलबी

हमारी नई रणनीति, साथ-साथ सुधार के साथ, ऊपर वर्णित अधिकांश समस्याओं को समाप्त करती है, या उनके परिणामों को कम करती है। हमारे वर्तमान हा प्रणाली में निम्नलिखित तत्व शामिल हैं:

• गलती का पता लगाने और विफलता के लिए ऑर्केस्ट्रेटर । हम कई डेटा केंद्रों के साथ ऑर्केस्ट्रेटर / बेड़ा योजना का उपयोग करते हैं, जैसा कि नीचे दिए गए आंकड़े में दिखाया गया है;
• सेवा खोज के लिए हैशिकॉर्प कंसल ;
• GLB / HAProxy क्लाइंट और रिकॉर्डिंग नोड्स के बीच एक प्रॉक्सी परत के रूप में। GLB निदेशक के लिए स्रोत कोड खुला है;
• नेटवर्क मार्ग के लिए कोई भी प्रौद्योगिकी।

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

सामान्य प्रवाह

एक सामान्य स्थिति में, अनुप्रयोग GLB / HAProxy के माध्यम से रिकॉर्डिंग नोड से कनेक्ट होते हैं।

एप्लिकेशन को मुख्य सर्वर की पहचान नहीं मिलती है। पहले की तरह, वे केवल नाम का उपयोग करते हैं। उदाहरण के लिए, cluster1 लिए मुख्य नोड cluster1 होगा। हालांकि, हमारे वर्तमान कॉन्फ़िगरेशन में, यह नाम किसी भी आईपी पते को हल करता है।

किसी भी प्रौद्योगिकी के लिए धन्यवाद, नाम को कहीं भी उसी आईपी पते पर हल किया जाता है, लेकिन क्लाइंट के स्थान को देखते हुए ट्रैफ़िक को अलग तरीके से निर्देशित किया जाता है। विशेष रूप से, GLB के कई उदाहरण, हमारे अत्यधिक उपलब्ध लोड बैलेंसर, हमारे प्रत्येक डेटा सेंटर में तैनात हैं। mysql-writer-1.github.net पर mysql-writer-1.github.net हमेशा स्थानीय डेटा सेंटर के GLB क्लस्टर में रूट किया जाता है। इसके कारण, सभी ग्राहकों को स्थानीय प्रॉक्सी द्वारा सेवा दी जाती है।

हम HAProxy के शीर्ष पर GLB चलाते हैं। हमारा HAProxy सर्वर पूल लिखता है : प्रत्येक MySQL क्लस्टर के लिए। इसके अलावा, प्रत्येक पूल में केवल एक सर्वर (क्लस्टर का मुख्य नोड) होता है। सभी डेटा केंद्रों में सभी GLB / HAProxy इंस्टेंसेस में एक ही पूल होते हैं, और वे सभी इन पूल में एक ही सर्वर को इंगित करते हैं। इस प्रकार, यदि आवेदन डेटाबेस पर mysql-writer-1.github.net पर डेटा लिखना चाहता है, तो इससे कोई फर्क नहीं पड़ता कि यह किस GLB सर्वर से जुड़ता है। या तो मामले में, वास्तविक मुख्य क्लस्टर नोड क्लस्टर 1 पर पुनर्निर्देशित किया जाएगा।

अनुप्रयोगों के लिए, खोज GLB पर समाप्त होती है, और पुनः खोज आवश्यक नहीं है। यह GLB ट्रैफ़िक को सही जगह पर पुनर्निर्देशित करता है।

जीएलबी को कहां से सर्वर की सूची के बारे में जानकारी मिलती है? हम GLB में परिवर्तन कैसे करते हैं?

कौंसल के माध्यम से खोज

कौंसल सेवा को व्यापक रूप से सेवा खोज समाधान के रूप में जाना जाता है, और यह डीएनएस कार्यों पर भी काम करता है। हालांकि, हमारे मामले में, हम इसे प्रमुख मूल्यों (KV) के अत्यधिक सुलभ भंडारण के रूप में उपयोग करते हैं।

कंसुल में केवी भंडार में, हम मुख्य क्लस्टर नोड्स की पहचान दर्ज करते हैं। प्रत्येक क्लस्टर के लिए, संबंधित मुख्य नोड के डेटा को इंगित करने वाले KV रिकॉर्ड्स का एक सेट होता है: इसका fqdn , port, ipv4 और ipv6 एड्रेस।

प्रत्येक GLB / HAProxy नोड एक कॉन्सल-टेम्पलेट लॉन्च करता है, एक सेवा जो कॉन्सल डेटा में परिवर्तन को ट्रैक करती है (हमारे मामले में, मुख्य नोड्स के डेटा में परिवर्तन)। कंसोल consul-template एक कॉन्फ़िगरेशन फ़ाइल बनाती है और सेटिंग्स बदलते समय HAProxy को पुनः लोड कर सकती है।

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

हमने प्रत्येक डेटा सेंटर में कॉन्सुल इंस्टेंस को तैनात किया है, और प्रत्येक उदाहरण उच्च उपलब्धता प्रदान करता है। हालांकि, ये उदाहरण एक-दूसरे से स्वतंत्र हैं। वे किसी भी डेटा का आदान-प्रदान नहीं करते हैं।

कॉन्सल को परिवर्तनों के बारे में जानकारी कहां से मिलती है और इसे डेटा केंद्रों के बीच कैसे वितरित किया जाता है?

ऑर्केस्ट्रेटर / बेड़ा

हम orchestrator/raft योजना का उपयोग करते हैं: orchestrator नोड्स एक दूसरे के साथ आम सहमति से संवाद करते हैं। प्रत्येक डेटा सेंटर में, हमारे पास एक या दो orchestrator नोड होते हैं।

orchestrator विफलताओं का पता लगाने के लिए जिम्मेदार है, MySQL विफलता, और परिवर्तित मास्टर नोड डेटा को कॉन्सुल में स्थानांतरित करना। फ़ेलओवर का प्रबंधन एकल orchestrator/raft होस्ट द्वारा किया जाता है, लेकिन परिवर्तन , समाचार कि क्लस्टर अब एक नया मास्टर है, सभी orchestrator नोड्स का उपयोग raft तंत्र का उपयोग करके किया जाता है।

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

संपूर्ण धारा का सामान्य दृष्टिकोण

यदि मास्टर नोड विफल रहता है:

• orchestrator नोड्स विफलताओं का पता लगाते हैं;
• orchestrator/raft मास्टर वसूली शुरू करता है। एक नया मास्टर नोड सौंपा गया है;
• orchestrator/raft योजना मुख्य नोड के परिवर्तन पर डेटा को स्थानांतरित करता है, जो raft क्लस्टर के सभी नोड्स में होता है;
• orchestrator/raft प्रत्येक उदाहरण में नोड परिवर्तन के बारे में एक सूचना प्राप्त होती है और कौंसुल में स्थानीय केवी भंडारण के लिए नए मास्टर नोड की पहचान लिखता है;
• प्रत्येक GLB / HAProxy उदाहरण पर, consul-template सेवा लॉन्च की जाती है, जो Consul में KV रिपॉजिटरी में परिवर्तन की निगरानी करती है, HAProxy को पुन: कॉन्फ़िगर और पुनः आरंभ करती है;
• क्लाइंट ट्रैफ़िक को नए मास्टर नोड में पुनर्निर्देशित किया जाता है।

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

इसके अलावा:

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

अतिरिक्त जानकारी

प्रवाह को स्थिर करने के लिए, हम निम्नलिखित तरीके भी लागू करते हैं:

• HAProxy hard-stop-after पैरामीटर बहुत छोटे मान पर सेट है। जब लेखन पूल में नए सर्वर के साथ HAProxy रिबूट होता है, तो सर्वर स्वचालित रूप से पुराने मास्टर नोड के सभी मौजूदा कनेक्शन को समाप्त कर देता है।
  
  1. hard-stop-after पैरामीटर सेट करना आपको क्लाइंट से किसी भी कार्रवाई के लिए इंतजार नहीं करने की अनुमति देता है, इसके अलावा, क्लस्टर में दो मुख्य नोड्स की संभावित घटना के नकारात्मक परिणामों को कम से कम किया जाता है। यह समझना महत्वपूर्ण है कि यहां कोई जादू नहीं है, और किसी भी मामले में, पुराने संबंधों को तोड़ने से पहले कुछ समय गुजरता है। लेकिन समय का एक बिंदु है जिसके बाद हम अप्रिय आश्चर्य की प्रतीक्षा करना बंद कर सकते हैं।
• हमें कॉन्सल सेवा की निरंतर उपलब्धता की आवश्यकता नहीं है। वास्तव में, हमें यह केवल असफलता के दौरान उपलब्ध होने की आवश्यकता है। यदि कॉन्सुल सेवा जवाब नहीं दे रही है, तो जीएलबी नवीनतम ज्ञात मूल्यों के साथ काम करना जारी रखता है और कठोर उपाय नहीं करता है।
• GLB को नए असाइन किए गए मास्टर नोड की पहचान को सत्यापित करने के लिए कॉन्फ़िगर किया गया है। हमारे संदर्भ के प्रति संवेदनशील MySQL पूल के साथ , यह पुष्टि करने के लिए एक चेक किया जाता है कि सर्वर वास्तव में लिखने योग्य है। यदि हम गलती से कौंसुल में मुख्य नोड की पहचान को हटा देते हैं, तो कोई समस्या नहीं होगी, एक खाली रिकॉर्ड को नजरअंदाज कर दिया जाएगा। यदि हम ग़लती से किसी अन्य सर्वर (मुख्य नहीं) का नाम लिखते हैं, तो इस मामले में यह ठीक है: जीएलबी इसे अपडेट नहीं करेगा और अंतिम वैध स्थिति के साथ काम करना जारी रखेगा।

निम्नलिखित अनुभागों में, हम मुद्दों को देखते हैं और उच्च उपलब्धता के लक्ष्यों का विश्लेषण करते हैं।

ऑर्केस्ट्रेटर / बेड़ा के साथ क्रैश का पता लगाना

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

orchestrator/raft सर्किटरी भी डाटा सेंटर (डेटा सेंटर बाड़) के पूर्ण नेटवर्क अलगाव की स्थितियों का सामना करता है। डेटा सेंटर का नेटवर्क अलगाव भ्रम पैदा कर सकता है: डेटा सेंटर के अंदर सर्वर एक दूसरे के साथ संवाद कर सकते हैं। कैसे समझा जाए कि कौन वास्तव में अलग-थलग है - किसी दिए गए डेटा केंद्र या अन्य सभी डेटा केंद्रों के अंदर सर्वर?

orchestrator/raft योजना में, orchestrator/raft मास्टर विफलता है। नोड नेता बन जाता है, जिसे समूह (कोरम) में बहुमत का समर्थन प्राप्त होता है। हमने orchestrator नोड को इस तरह से तैनात किया है कि कोई एकल डेटा केंद्र बहुमत प्रदान नहीं कर सकता है, जबकि कोई भी n-1 डेटा केंद्र इसे प्रदान कर सकता है।

डेटा सेंटर के पूर्ण नेटवर्क अलगाव के मामले में, इस केंद्र में orchestrator नोड्स को अन्य डेटा केंद्रों में समान नोड्स से काट दिया जाता है। परिणामस्वरूप, एक पृथक डेटा सेंटर में orchestrator नोड्स एक raft क्लस्टर में अग्रणी नहीं बन सकता है। यदि ऐसा नोड मास्टर था, तो यह स्थिति खो देता है। एक नया होस्ट अन्य डेटा केंद्रों में से एक नोड को सौंपा जाएगा। इस नेता के पास अन्य सभी डेटा केंद्रों का समर्थन होगा जो एक दूसरे के साथ बातचीत कर सकते हैं।

इस तरह, orchestrator मास्टर हमेशा नेटवर्क-पृथक डेटा सेंटर के बाहर रहेगा। यदि मास्टर नोड एक पृथक डेटा केंद्र में स्थित था, तो orchestrator उपलब्ध डेटा केंद्रों में से एक के सर्वर के साथ इसे प्रतिस्थापित करने के लिए एक विफलता शुरू करता है। हम उपलब्ध डेटा केंद्रों के कोरम को निर्णय सौंपकर डेटा सेंटर अलगाव के प्रभाव को कम करते हैं।

तेज़ अधिसूचना

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

जब orchestrator शुरू होता है, तो यह सर्वरों के एक समूह पर विचार करता है, जिनमें से एक को मुख्य के रूप में सौंपा जा सकता है। प्रतिकृति नियमों, सिफारिशों और सीमाओं को देखते हुए, वह कार्रवाई के सर्वोत्तम पाठ्यक्रम के बारे में सूचित निर्णय लेने में सक्षम है।

निम्नलिखित संकेतों के अनुसार, वह यह भी समझ सकता है कि एक सुलभ सर्वर मुख्य नियुक्ति के लिए एक आदर्श उम्मीदवार है :

• कुछ भी सर्वर को ऊंचा होने से रोकता है (और शायद उपयोगकर्ता इस सर्वर की सिफारिश करता है);
• यह उम्मीद की जाती है कि सर्वर प्रतिकृतियों के रूप में अन्य सभी सर्वरों का उपयोग करने में सक्षम होगा।

इस मामले में, orchestrator सबसे पहले सर्वर को लिखने योग्य बनाता है और तुरंत इसकी स्थिति में वृद्धि की घोषणा करता है (हमारे मामले में, यह कंसल में केवी भंडार को रिकॉर्ड लिखता है)। orchestrator , .

, , GLB , , . : !

MySQL , . : , , , .

, . , , . , , , .

: 500 . . ( ), .

( ) . , .

, . , , . , , , .

, / pt-heartbeat / , . , pt-heartbeat , read_only , .

pt-heartbeat , . . . , pt-heartbeat .

orchestrator

orchestrator :

• Pseudo-GTID;
• , ;
• ( read_only ), .

, . , , , . orchestrator .

- , , . , -, .

, .

, , , - . . STONITH . , , , «» - . , , .

: Consul , . . , , , , .

orchestrator/GLB/Consul :

• ;
• ;
• ;
• ;
• , ( );
• ;
• 10-13 .
  
  1. 20 , — 25 .

निष्कर्ष

«// » , , . . , .