भौगोलिक रूप से वितरित मारियाडीबी क्लस्टर कैसे डिजाइन करें

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

इस सेटअप को प्राप्त करने की मुख्य चुनौती डेटाबेस को इस तरह से डिजाइन करना है जिससे नेटवर्क विभाजन से संबंधित मुद्दों की संभावना कम हो।

MariaDB क्लस्टर कई कारणों से ऐसा वातावरण बनाने के लिए एक अच्छा विकल्प हो सकता है। हम यहां उन पर चर्चा करना चाहेंगे और इस बारे में भी कुछ बात करेंगे कि ऐसा वातावरण कैसा दिख सकता है।

जियो-वितरित वातावरण के लिए MariaDB क्लस्टर का उपयोग क्यों करें?

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

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

तीसरा, खंड। डिफ़ॉल्ट रूप से मारियाडीबी क्लस्टर सभी संचार के लिए उपयोग करता है और प्रत्येक राइटसेट नोड द्वारा क्लस्टर में अन्य सभी नोड्स को भेजा जाता है। सेगमेंट का उपयोग करके इस व्यवहार को बदला जा सकता है। सेगमेंट उपयोगकर्ताओं को कई भागों में मारियाडीबी क्लस्टर्स को विभाजित करने की अनुमति देते हैं। प्रत्येक खंड में कई नोड हो सकते हैं और यह उनमें से एक को रिले नोड के रूप में चुनता है। इस तरह के नोड्स अन्य खंडों से राइटसेट प्राप्त करते हैं और उन्हें मारियाडीबी नोड्स में स्थानीय रूप से खंड में पुनर्वितरित करते हैं। परिणामस्वरूप, जैसा कि आप ऊपर दिए गए चित्र में देख सकते हैं, WAN पर जाने वाले प्रतिकृति ट्रैफ़िक को तीन गुना कम करना संभव है - WAN पर प्रतिकृति स्ट्रीम के केवल दो "प्रतिकृति" भेजे जा रहे हैं:एक प्रति डेटासेंटर प्रति दास एक की तुलना में अतुल्यकालिक प्रतिकृति में।

अंत में, जहां मारियाडीबी क्लस्टर वास्तव में चमकता है वह है नेटवर्क विभाजन का प्रबंधन। मारियाडीबी क्लस्टर क्लस्टर में नोड्स की स्थिति की लगातार निगरानी करता है। प्रत्येक नोड अपने साथियों के साथ जुड़ने और क्लस्टर की स्थिति का आदान-प्रदान करने का प्रयास करता है। यदि नोड्स का एक सबसेट पहुंच योग्य नहीं है, तो मारियाडीबी संचार को रिले करने का प्रयास करता है ताकि यदि उन नोड्स तक पहुंचने का कोई तरीका है, तो वे पहुंच जाएंगे।

उपरोक्त आरेख में एक उदाहरण देखा जा सकता है:DC 1 ने कनेक्टिविटी खो दी DC2 के साथ लेकिन DC2 और DC3 कनेक्ट हो सकते हैं। इस मामले में DC3 में एक नोड का उपयोग DC1 से DC2 तक डेटा रिले करने के लिए किया जाएगा ताकि यह सुनिश्चित हो सके कि इंट्रा-क्लस्टर संचार को बनाए रखा जा सकता है।

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

जैसा कि ऊपर दिए गए चित्र में देखा जा सकता है, DC1 में नेटवर्क संचार का आंशिक नुकसान होता है और प्रभावित नोड को क्लस्टर से हटा दिया जाता है, यह सुनिश्चित करते हुए कि एप्लिकेशन पुराने डेटा तक नहीं पहुंच पाएगा।

यह बड़े पैमाने पर भी सच है। DC1 ने अपना सारा संचार काट दिया। नतीजतन, पूरे डेटासेंटर को क्लस्टर से हटा दिया गया है और इसका कोई भी नोड ट्रैफ़िक की सेवा नहीं करेगा। बाकी क्लस्टर ने बहुमत बनाए रखा (9 में से 6 नोड उपलब्ध हैं) और इसने DC 2 और DC3 के बीच कनेक्शन रखने के लिए खुद को फिर से कॉन्फ़िगर किया। ऊपर दिए गए आरेख में हमने माना कि लेखक DC2 में नोड को हिट करता है, लेकिन कृपया ध्यान रखें कि MariaDB कई लेखकों के साथ चलने में सक्षम है।

भौगोलिक रूप से वितरित MariaDB क्लस्टर डिज़ाइन करना

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

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

हम मैक्सस्केल को लोडबैलेंसर के रूप में उपयोग करेंगे। MaxScale को प्रत्येक डेटासेंटर में स्थानीय रूप से तैनात किया जाएगा। यह यातायात को केवल स्थानीय नोड्स तक ही रूट करेगा। रिमोट नोड्स को हमेशा मैन्युअल रूप से जोड़ा जा सकता है और हम उन मामलों की व्याख्या करेंगे जहां यह एक अच्छा समाधान हो सकता है। अनुप्रयोगों को राउंड-रॉबिन एल्गोरिथम का उपयोग करके स्थानीय मैक्सस्केल नोड्स में से किसी एक से कनेक्ट करने के लिए कॉन्फ़िगर किया जा सकता है। हम ट्रैफिक को सिंगल मैक्सस्केल नोड की ओर रूट करने के लिए Keepalived और Virtual IP का भी उपयोग कर सकते हैं, जब तक कि एक सिंगल मैक्सस्केल नोड सभी ट्रैफिक को संभालने में सक्षम होगा।

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

उपरोक्त आरेख परिवेश का संस्करण दिखाता है, जहां MaxScale प्रॉक्सी फ़ार्म बनाता है - समान कॉन्फ़िगरेशन वाले सभी प्रॉक्सी नोड्स, Keepalived का उपयोग करके संतुलित लोड करें, या सभी MaxScale नोड्स में एप्लिकेशन से केवल राउंड रॉबिन। MaxScale को स्थानीय डेटासेंटर में सभी MariaDB नोड्स में कार्यभार वितरित करने के लिए कॉन्फ़िगर किया गया है। उन नोड्स में से एक को लिखने के लिए नोड के रूप में चुना जाएगा जबकि चयन सभी नोड्स में वितरित किए जाएंगे। डेटासेंटर में एक समर्पित लेखक नोड होने से संभावित प्रमाणन संघर्षों की संख्या को कम करने में मदद मिलती है, जिससे आमतौर पर बेहतर प्रदर्शन होता है। इसे और कम करने के लिए हमें WAN कनेक्शन पर ट्रैफिक भेजना शुरू करना होगा, जो आदर्श नहीं है क्योंकि बैंडविड्थ उपयोग में काफी वृद्धि होगी। अभी, सेगमेंट के साथ, डेटासेंटर में राइटसेट की केवल दो प्रतियां भेजी जा रही हैं - एक प्रति डीसी।

निष्कर्ष

जैसा कि आप देख सकते हैं, मारियाडीबी क्लस्टर का उपयोग आसानी से भू-वितरित क्लस्टर बनाने के लिए किया जा सकता है जो दुनिया भर में भी काम कर सकता है। सीमित कारक नेटवर्क विलंबता होगा। यदि यह बहुत अधिक है, तो आपको एसिंक्रोनस प्रतिकृति का उपयोग करके जुड़े अलग मारियाडीबी क्लस्टर का उपयोग करने पर विचार करना पड़ सकता है।