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