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