अपना HA टोपोलॉजी चुनना
डेटाबेस के साथ उच्च उपलब्धता बनाए रखने के कई तरीके हैं। आप मेजबान उपलब्धता को प्रबंधित करने के लिए वर्चुअल आईपी (वीआरआरपी) का उपयोग कर सकते हैं, आप अपने एप्लिकेशन को कॉन्फ़िगर करने के लिए ज़ूकीपर और आदि जैसे संसाधन प्रबंधकों का उपयोग कर सकते हैं या सभी उपलब्ध मेजबानों पर कार्यभार वितरित करने के लिए लोड बैलेंसर्स/प्रॉक्सी का उपयोग कर सकते हैं।
वर्चुअल आईपी को या तो उन्हें प्रबंधित करने के लिए एक एप्लिकेशन की आवश्यकता होती है (एमएचए, ऑर्केस्ट्रेटर), कुछ स्क्रिप्टिंग (कीपलीव्ड, पेसमेकर / कोरोसिंक) या एक इंजीनियर को मैन्युअल रूप से विफल होने के लिए और प्रक्रिया में निर्णय लेना जटिल हो सकता है। वर्चुअल आईपी फेलओवर एक होस्ट से आईपी एड्रेस को हटाकर, दूसरे को असाइन करके और एक मुफ्त एआरपी प्रतिक्रिया भेजने के लिए आर्पिंग का उपयोग करके एक सीधी और सरल प्रक्रिया है। सिद्धांत रूप में एक वर्चुअल आईपी को एक सेकंड में स्थानांतरित किया जा सकता है लेकिन फेलओवर प्रबंधन एप्लिकेशन को यह सुनिश्चित होने में कुछ सेकंड लगेंगे कि होस्ट विफल हो गया है और उसके अनुसार कार्य करता है। वास्तव में यह कहीं 10 से 30 सेकंड के बीच होना चाहिए। वर्चुअल आईपी की एक और सीमा यह है कि कुछ क्लाउड प्रदाता आपको अपने स्वयं के वर्चुअल आईपी को प्रबंधित करने या उन्हें बिल्कुल भी असाइन करने की अनुमति नहीं देते हैं। उदा., Google आपको उनके कंप्यूट नोड्स पर ऐसा करने की अनुमति नहीं देता है।
ज़ूकीपर और एटीसीडी जैसे संसाधन प्रबंधक आपके डेटाबेस की निगरानी कर सकते हैं और (पुनः) एक मेजबान के विफल होने या एक दास को मास्टर करने के लिए आपके अनुप्रयोगों को कॉन्फ़िगर कर सकते हैं। सामान्य तौर पर यह एक अच्छा विचार है लेकिन ज़ूकीपर और आदि के साथ अपने चेक को लागू करना एक जटिल कार्य है।
एक लोड बैलेंसर या प्रॉक्सी एप्लिकेशन और डेटाबेस होस्ट के बीच में बैठेगा और पारदर्शी रूप से काम करेगा जैसे कि क्लाइंट सीधे डेटाबेस होस्ट से कनेक्ट होगा। वर्चुअल आईपी और संसाधन प्रबंधकों की तरह, लोड बैलेंसर्स और प्रॉक्सी को भी मेजबानों की निगरानी करने और एक होस्ट के डाउन होने पर ट्रैफ़िक को पुनर्निर्देशित करने की आवश्यकता होती है। ClusterControl दो प्रॉक्सी का समर्थन करता है:HAProxy और ProxySQL और दोनों MySQL मास्टर-स्लेव प्रतिकृति और गैलेरा क्लस्टर के लिए समर्थित हैं। HAProxy और ProxySQL दोनों के अपने-अपने उपयोग के मामले हैं, हम उनका वर्णन इस पोस्ट में भी करेंगे।
आपको लोड बैलेंसर की आवश्यकता क्यों है?
सिद्धांत रूप में आपको लोड बैलेंसर की आवश्यकता नहीं है, लेकिन व्यवहार में आप एक को पसंद करेंगे। हम इसका कारण बताएंगे।
यदि आपके पास वर्चुअल आईपी सेटअप है, तो आपको बस अपने आवेदन को सही (वर्चुअल) आईपी पते पर इंगित करना है और सब कुछ ठीक कनेक्शन के अनुसार होना चाहिए। लेकिन मान लीजिए कि आपने पठन प्रतिकृतियों की संख्या को बढ़ा दिया है, तो हो सकता है कि आप रखरखाव या उपलब्धता कारणों से उनमें से प्रत्येक के लिए वर्चुअल आईपी प्रदान करना चाहें। यह वर्चुअल आईपी का एक बहुत बड़ा पूल बन सकता है जिसे आपको प्रबंधित करना होगा। यदि उन पढ़ी गई प्रतिकृतियों में से एक में विफलता थी, तो आपको वर्चुअल आईपी को किसी अन्य होस्ट को फिर से असाइन करने की आवश्यकता है अन्यथा आपका एप्लिकेशन या तो एक होस्ट से कनेक्ट हो जाएगा जो नीचे है या सबसे खराब स्थिति में, पुराने डेटा के साथ एक लैगिंग सर्वर। इसलिए वर्चुअल आईपी को प्रबंधित करने वाले एप्लिकेशन में प्रतिकृति स्थिति को बनाए रखना आवश्यक है।
गैलेरा के लिए भी एक समान चुनौती है:सिद्धांत रूप में आप अपने एप्लिकेशन कॉन्फ़िगरेशन में जितने चाहें उतने होस्ट जोड़ सकते हैं और एक को यादृच्छिक रूप से चुन सकते हैं। यह होस्ट के डाउन होने पर भी यही समस्या उत्पन्न होती है:आप किसी अनुपलब्ध होस्ट से कनेक्ट हो सकते हैं। गैलेरा में आशावादी लॉकिंग के कारण पढ़ने और लिखने के लिए सभी मेजबानों का उपयोग करने से भी रोलबैक हो सकता है। यदि दो कनेक्शन एक ही समय में एक ही पंक्ति में लिखने का प्रयास करते हैं, तो उनमें से एक को रोल बैक प्राप्त होगा। यदि आपके कार्यभार में ऐसे समवर्ती अद्यतन हैं, तो यह सलाह दी जाती है कि लिखने के लिए गैलेरा में केवल एक नोड का उपयोग करें। इसलिए आप एक ऐसा प्रबंधक चाहते हैं जो आपके डेटाबेस क्लस्टर की आंतरिक स्थिति पर नज़र रखे।
HAProxy और ProxySQL दोनों आपको MySQL/MariaDB डेटाबेस होस्ट की निगरानी करने और आपके क्लस्टर और इसकी टोपोलॉजी की स्थिति बनाए रखने के लिए कार्यक्षमता प्रदान करेंगे। प्रतिकृति सेटअप के लिए, यदि एक दास प्रतिकृति नीचे है, तो HAProxy और ProxySQL दोनों दूसरे होस्ट के कनेक्शन को पुनर्वितरित कर सकते हैं। लेकिन अगर एक प्रतिकृति मास्टर डाउन है, तो HAProxy कनेक्शन को अस्वीकार कर देगा और ProxySQL क्लाइंट को एक उचित त्रुटि देगा। गैलेरा सेटअप के लिए, दोनों लोड बैलेंसर गैलेरा क्लस्टर से एक मास्टर नोड का चुनाव कर सकते हैं और केवल उस विशिष्ट नोड को राइट ऑपरेशन भेज सकते हैं।
सतह पर HAProxy और ProxySQL समान समाधान प्रतीत हो सकते हैं, लेकिन वे सुविधाओं और कनेक्शन और प्रश्नों को वितरित करने के तरीके में बहुत भिन्न हैं। HAProxy कम से कम कनेक्शन, स्रोत, रैंडम और राउंड-रॉबिन जैसे कई संतुलन एल्गोरिदम का समर्थन करता है, जबकि ProxySQL वजन-आधारित राउंड-रॉबिन एल्गोरिथ्म (समान वजन का मतलब समान वितरण) का उपयोग करके कनेक्शन वितरित करता है। चूंकि ProxySQL एक बुद्धिमान प्रॉक्सी है, इसलिए यह डेटाबेस से अवगत है और आपके प्रश्नों का विश्लेषण करने में भी सक्षम है। ProxySQL क्वेरी नियमों के आधार पर रीड/राइट स्प्लिटिंग करने में सक्षम है जहां आप अपने क्लस्टर में निर्दिष्ट दास या मास्टर को प्रश्नों को अग्रेषित कर सकते हैं। ProxySQL में कार्यभार के बारे में वास्तविक समय, गहन सांख्यिकी पीढ़ी के साथ क्वेरी पुनर्लेखन, कैशिंग और क्वेरी फ़ायरवॉल जैसी अतिरिक्त कार्यक्षमता शामिल है।
इस विषय पर पर्याप्त पृष्ठभूमि जानकारी होनी चाहिए, तो आइए देखें कि आप MySQL प्रतिकृति और गैलेरा टोपोलॉजी के लिए लोड बैलेंसर दोनों को कैसे तैनात कर सकते हैं।
HAProxy परिनियोजित करना
गैलेरा क्लस्टर पर HAProxy को तैनात करने के लिए ClusterControl का उपयोग करना आसान है:संबंधित क्लस्टर पर जाएं और "लोड बैलेंसर जोड़ें" चुनें:
और आप होस्ट पता जोड़कर और कॉन्फ़िगरेशन में शामिल किए जाने वाले सर्वर इंस्टेंस का चयन करके एक HAProxy इंस्टेंस को परिनियोजित करने में सक्षम होंगे:
डिफ़ॉल्ट रूप से HAProxy इंस्टेंस को कम से कम कनेक्शन प्राप्त करने वाले सर्वर इंस्टेंस को कनेक्शन भेजने के लिए कॉन्फ़िगर किया जाएगा, लेकिन आप उस नीति को राउंड रॉबिन या स्रोत में बदल सकते हैं।
उन्नत सेटिंग्स के तहत आप कनेक्शन के लिए एक आईपी श्रेणी को श्वेतसूची में डालकर टाइमआउट, अधिकतम मात्रा में कनेक्शन सेट कर सकते हैं और यहां तक कि प्रॉक्सी को सुरक्षित भी कर सकते हैं।
उस क्लस्टर के नोड टैब के अंतर्गत, HAProxy नोड दिखाई देगा:
अब आपका गैलेरा क्लस्टर पोर्ट 3307 पर नए तैनात HAProxy नोड के माध्यम से भी उपलब्ध है। HAProxy IP से अपने एप्लिकेशन को एक्सेस देना न भूलें, क्योंकि अब ट्रैफ़िक एप्लिकेशन होस्ट के बजाय प्रॉक्सी से आ रहा होगा। साथ ही, अपने एप्लिकेशन कनेक्शन को HAProxy नोड से इंगित करना न भूलें।
अब मान लीजिए कि एक सर्वर इंस्टेंस नीचे चला जाएगा, HAProxy इसे कुछ ही सेकंड में नोटिस करेगा और इस इंस्टेंस पर ट्रैफ़िक भेजना बंद कर देगा:
दो अन्य नोड्स अभी भी ठीक हैं और ट्रैफिक प्राप्त करते रहेंगे। यह क्लाइंट को अंतर देखे बिना अत्यधिक उपलब्ध क्लस्टर को बरकरार रखता है।
माध्यमिक HAProxy नोड परिनियोजित करना
अब जब हमने क्लाइंट से HAProxy तक डेटाबेस कनेक्शन पर उच्च उपलब्धता बनाए रखने की जिम्मेदारी ले ली है, तो क्या होगा यदि प्रॉक्सी नोड मर जाता है? इसका उत्तर एक और HAProxy इंस्टेंस बनाना और Keepalived द्वारा नियंत्रित वर्चुअल IP का उपयोग करना है जैसा कि इस आरेख में दिखाया गया है:
डेटाबेस नोड्स पर वर्चुअल आईपी का उपयोग करने की तुलना में लाभ यह है कि MySQL के लिए तर्क प्रॉक्सी स्तर पर है और प्रॉक्सी के लिए विफलता सरल है।
तो चलिए एक सेकेंडरी HAProxy नोड को तैनात करते हैं:
द्वितीयक HAProxy नोड को परिनियोजित करने के बाद, हमें Keepalived जोड़ने की आवश्यकता है:
और Keepalived जोड़े जाने के बाद, आपके नोड्स का अवलोकन इस तरह दिखेगा:
तो अब अपने एप्लिकेशन कनेक्शन को सीधे HAProxy नोड पर इंगित करने के बजाय आपको उन्हें वर्चुअल आईपी पर इंगित करना होगा।
यहां उदाहरण में, हमने HAProxy को चलाने के लिए अलग-अलग होस्ट का उपयोग किया है, लेकिन आप उन्हें मौजूदा सर्वर इंस्टेंस में भी आसानी से जोड़ सकते हैं। HAProxy अधिक ओवरहेड नहीं लाता है, हालांकि आपको यह ध्यान रखना चाहिए कि सर्वर के विफल होने की स्थिति में, आप डेटाबेस नोड और प्रॉक्सी दोनों को खो देंगे।
ProxySQL परिनियोजित करना
ProxySQL को आपके क्लस्टर में परिनियोजित करना HAProxy के समान तरीके से किया जाता है:ProxySQL टैब के अंतर्गत क्लस्टर सूची में "लोड बैलेंसर जोड़ें"।
परिनियोजन विज़ार्ड में, निर्दिष्ट करें कि ProxySQL कहाँ स्थापित किया जाएगा, प्रशासन उपयोगकर्ता/पासवर्ड, निगरानी उपयोगकर्ता/पासवर्ड MySQL बैकएंड से कनेक्ट करने के लिए। ClusterControl से, आप या तो एप्लिकेशन द्वारा उपयोग किए जाने के लिए एक नया उपयोगकर्ता बना सकते हैं (उपयोगकर्ता MySQL और ProxySQL दोनों पर बनाया जाएगा) या मौजूदा डेटाबेस उपयोगकर्ताओं का उपयोग करें (उपयोगकर्ता केवल ProxySQL पर बनाया जाएगा)। सेट करें कि आप निहित लेनदेन का उपयोग कर रहे हैं या नहीं। मूल रूप से, यदि आप नया लेनदेन बनाने के लिए SET autocommit=0 का उपयोग नहीं करते हैं, तो ClusterControl रीड/राइट स्प्लिट को कॉन्फ़िगर करेगा।
ProxySQL के परिनियोजित होने के बाद, यह Nodes टैब के अंतर्गत उपलब्ध होगा:
ProxySQL नोड ओवरव्यू को खोलने पर आपको ProxySQL मॉनिटरिंग और मैनेजमेंट इंटरफ़ेस दिखाई देगा, इसलिए अब नोड पर ProxySQL में लॉग इन करने का कोई कारण नहीं है। ClusterControl में अधिकांश ProxySQL महत्वपूर्ण आँकड़े जैसे मेमोरी उपयोग, क्वेरी कैश, क्वेरी प्रोसेसर और इसी तरह के साथ-साथ अन्य मीट्रिक जैसे होस्टग्रुप, बैकएंड सर्वर, क्वेरी नियम हिट, शीर्ष क्वेरी और ProxySQL चर शामिल हैं। ProxySQL प्रबंधन पहलू में, आप सीधे UI से क्वेरी नियम, बैकएंड सर्वर, उपयोगकर्ता, कॉन्फ़िगरेशन और शेड्यूलर प्रबंधित कर सकते हैं।
हमारे ProxySQL ट्यूटोरियल पेज को देखें, जिसमें ProxySQL के साथ MySQL और MariaDB के लिए डेटाबेस लोड बैलेंसिंग करने के तरीके के बारे में विस्तार से बताया गया है।
Garbd परिनियोजित करना
गैलेरा एक प्राथमिक घटक का चयन करने के लिए कोरम-आधारित एल्गोरिदम लागू करता है जिसके माध्यम से यह स्थिरता को लागू करता है। प्राथमिक घटक को बहुमत (50% + 1 नोड) की आवश्यकता होती है, इसलिए 2 नोड प्रणाली में, विभाजित मस्तिष्क के परिणामस्वरूप बहुमत नहीं होगा। सौभाग्य से, एक गारबड (गैलेरा आर्बिट्रेटर डेमन) जोड़ना संभव है, जो एक हल्का स्टेटलेस डेमॉन है जो विषम नोड के रूप में कार्य कर सकता है। गैलेरा आर्बिट्रेटर को जोड़कर अतिरिक्त लाभ यह है कि अब आप अपने क्लस्टर में केवल दो नोड्स के साथ काम कर सकते हैं।
यदि ClusterControl को पता चलता है कि आपके Galera क्लस्टर में सम संख्या में नोड्स हैं, तो आपको क्लस्टर को विषम संख्या में नोड्स तक विस्तारित करने के लिए ClusterControl द्वारा चेतावनी/सलाह दी जाएगी:
गारबड को परिनियोजित करने के लिए बुद्धिमानी से होस्ट चुनें, क्योंकि यह सभी प्रतिकृति डेटा प्राप्त करेगा। सुनिश्चित करें कि नेटवर्क ट्रैफ़िक को संभाल सकता है और पर्याप्त सुरक्षित है। आप गारबड को परिनियोजित करने के लिए HAProxy या ProxySQL होस्ट में से किसी एक को चुन सकते हैं, जैसा कि नीचे दिए गए उदाहरण में है:
ध्यान दें कि ClusterControl 1.5.1 से शुरू होकर, पैकेज विरोध के जोखिम के कारण garbd को उसी होस्ट पर ClusterControl के रूप में स्थापित नहीं किया जा सकता है।
गारबड स्थापित करने के बाद, आप देखेंगे कि यह आपके दो गैलेरा नोड्स के बगल में दिखाई देगा:
अंतिम विचार
हमने आपको दिखाया कि कैसे अपने MySQL मास्टर-स्लेव और गैलेरा क्लस्टर सेटअप को अधिक मजबूत बनाया जाए और HAProxy और ProxySQL का उपयोग करके उच्च उपलब्धता बनाए रखी जाए। इसके अलावा गारबड एक अच्छा डेमॉन है जो आपके गैलेरा क्लस्टर में अतिरिक्त तीसरे नोड को बचा सकता है।
यह ClusterControl के परिनियोजन पक्ष को अंतिम रूप देता है। अपने अगले ब्लॉग में, हम आपको दिखाएंगे कि समूहों का उपयोग करके और उपयोगकर्ताओं को कुछ भूमिकाएँ सौंपकर अपने संगठन के भीतर ClusterControl को कैसे एकीकृत किया जाए।
