जीएसएलबी अवलोकन #

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

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

क्लाउड में आईटी सेवाओं को अपनाने और लागू करने के लिए, भौगोलिक रूप से उच्च उपलब्धता समाधान प्रदान करने हेतु WAN पर आधारित विधि सर्वोत्तम विकल्प है। इसे ही हम ग्लोबल सर्विस लोड बैलेंसिंग या GSLB कहते हैं ।

जीएसएलबी का उपयोग कब करें #

जीएसएलबी सेवा का उपयोग निम्नलिखित उपयोग मामलों के लिए अनुशंसित है:

वे कम्पनियाँ जो WAN के माध्यम से एक से अधिक डेटा सेंटर में अपनी सेवाएँ होस्ट करती हैं।
ऐसी कम्पनियाँ जिन्हें सेवाओं या डेटा केन्द्रों की उच्च उपलब्धता बनाने की आवश्यकता होती है।
इंटरनेट सेवा प्रदाताओं को अपने उपयोगकर्ताओं द्वारा उपयोग के लिए इनबाउंड लोड बैलेंसिंग सेवाएं तैयार करनी होंगी।

निश्चित रूप से, जब दुनिया भर के सर्वरों के बीच उपयोगकर्ताओं और ट्रैफ़िक को बिना किसी विफलता बिंदु के साझा करना आवश्यक हो तो जीएसएलबी सही समाधान है।

जीएसएलबी कैसे काम करता है? #

GSLB , DNS प्रोटोकॉल पर आधारित एक लोड बैलेंसिंग तंत्र है ; यह तेज़ और विश्वसनीय है क्योंकि यह UDP प्रोटोकॉल का उपयोग करता है और क्लाइंट की प्रतिक्रिया लगभग वास्तविक समय में होती है।

एक सामान्य DNS अनुरोध में, उदाहरण के लिए www.zvnlb.net , एक क्लाइंट स्थानीय रूप से कॉन्फ़िगर किए गए DNS सर्वरों (उदाहरण के लिए 8.8.8.8 और 8.8.4.4 ) को DNS अनुरोध रिज़ॉल्यूशन भेजता है और फिर क्लाइंट सिस्टम अनुरोध के विरुद्ध कार्रवाई करने और क्वेरी भेजने के लिए सर्वरों में से एक को यादृच्छिक रूप से चुनता है।

चयनित DNS सर्वर क्लाइंट से अनुरोध प्राप्त करता है (उदाहरण के लिए, www.zvnlb.net का IP पता क्या है?) और स्थानीय रूप से कॉन्फ़िगर किए गए DNS सर्वर यह पता लगाने का प्रयास करते हैं कि zvnlb.net DNS ज़ोन को हल करने के लिए कौन जिम्मेदार है ।

क्लाइंट द्वारा उपयोग किया जाने वाला DNS, इस मामले में 8.8.8.8 या 8.8.4.4 , यह पता लगाता है कि ns1.zvnlb.net और ns2.zvnlb.net, zvnlb.net के लिए ज़ोन रिज़ॉल्यूशन के लिए ज़िम्मेदार हैं, इसलिए वे क्लाइंट द्वारा प्राप्त DNS क्वेरी (उदाहरण के लिए, www.zvnlb.net का IP पता क्या है ?) उनमें से किसी एक को भेज देते हैं।

ns1.zvnlb.net या ns2.zvnlb.net में से कोई एक नेम सर्वर 8.8.8.8 या 8.8.4.4 से DNS क्वेरी प्राप्त करता है और फिर, अनुरोध प्राप्त करने वाला नेम सर्वर होस्ट www.zvnlb.net के लिए उपलब्ध सर्वरों की जाँच करता है और होस्ट www.zvnlb.net के लिए वास्तविक एप्लिकेशन को सेवा प्रदान करने के लिए उपलब्ध एप्लिकेशन सर्वरों की सूची के साथ DNS क्वेरी का जवाब देता है , इस प्रकार यह जानकारी अंततः क्लाइंट को प्राप्त होती है।

अब क्लाइंट DNS क्वेरी में प्राप्त सूची से एप्लिकेशन सर्वरों में से किसी एक का यादृच्छिक रूप से चयन करेगा और सीधे http://www.zvnlb.net एप्लिकेशन को अनुरोध भेजेगा ।

हमारे उदाहरण में, फ्रैंकफर्ट में स्थित नेम सर्वर ns1.zvnlb.net और टोरंटो में स्थित नेम सर्वर ns2.zvnlb.net , होस्ट www.zvnlb.net ( हमारे मामले में 192.235.113.3 और 194.23.52.21 ) के वास्तविक एप्लिकेशन की स्वास्थ्य स्थिति की लगातार जाँच करते रहते हैं। यदि ns1.zvnlb.net या ns2.zvnlb.net को किसी वास्तविक सर्वर की स्वास्थ्य स्थिति की जाँच करते समय कोई समस्या मिलती है, तो अनुपलब्ध सर्वर को कुछ समय के लिए निष्क्रिय कर दिया जाएगा और जब तक वह पुनः उपलब्ध नहीं हो जाता, तब तक उसका IP पता DNS क्वेरी में सूचीबद्ध नहीं होगा।

निम्नलिखित आरेख GSLB क्षमताओं के साथ वर्णित DNS ट्रैफ़िक को दर्शाता है।

डेटा केंद्रों की आपदा रिकवरी के लिए GSLB को कॉन्फ़िगर करना #

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

कृपया आपदा रिकवरी के लिए सक्रिय-निष्क्रिय डेटा केंद्र बनाने के लिए GSLB कॉन्फ़िगरेशन के इस वास्तविक उदाहरण का अनुसरण करें।

हमने दो तैनात किए हैं RELIANOID फ्रैंकफर्ट में दो अलग-अलग स्थानों पर स्थित डेटा सेंटरों में लोड बैलेंसर्स 159.89.7.124 और टोरंटो 159.203.12.35 और हमारे पास एक वेब सेवा है जो DNS होस्ट को जवाब देती है www.zvnlb.net, में कॉन्फ़िगर किया गया डेटा सेंटर 1 और डेटा सेंटर 2इस आर्किटेक्चर का डिज़ाइन सभी क्लाइंट ट्रैफ़िक को भेजने की अनुमति देगा डेटा सेंटर 1 लेकिन अगर यह विफल रहता है तो ग्राहकों को पुनर्निर्देशित करता है डेटा सेंटर 2.

इस कॉन्फ़िगरेशन को प्राप्त करने के लिए नीचे दी गई प्रक्रिया का पालन करें।

से कनेक्ट करें RELIANOID वेब पैनल में डेटा सेंटर 1 (हमारे मामले में फ्रैंकफर्ट), मुख्य मेनू में क्लिक करें जीएसएलबी मॉड्यूल और एक नया बनाएँ खेत, हमारे उदाहरण में कहा जाएगा DNS1-फ्रैंकफर्ट आभासी बंदरगाह में 53.

एक बार फ़ार्म बन जाने के बाद, कृपया इसे संपादित करें और ज़ोन टैब पर जाकर DNS ज़ोन बनाएं जिसे GSLB मॉड्यूल द्वारा प्रबंधित किया जाएगा, इस मामले में zvnlb.net , निम्नानुसार:

एक बार यह क्षेत्र बन जाने के बाद कृपया पहला कॉन्फ़िगरेशन बनाएं जैसा कि नीचे दिखाया गया है:

ध्यान दें कि ns1 और ns2 वे नेम सर्वर हैं जो zvnlb.net ज़ोन के लिए DNS रिज़ॉल्यूशन के लिए ज़िम्मेदार हैं (हमारे मामले में, एक GSLB सेवा फ्रैंकफर्ट में और दूसरी टोरंटो में है)।

फिर, से कनेक्ट करें RELIANOID डेटा सेंटर 2 में वेब पैनल, मुख्य मेनू में चयन करें जीएसएलबी और एक नया बनाएँ खेत, हमारे मामले में कहा जाएगा DNS2-टोरंटो आभासी बंदरगाह में 53.

नए GSLB फ़ार्म को संपादित करें और ज़ोन टैब पर जाएं, यहां zvnlb.net के लिए DNS ज़ोन बनाएं जिसे इस GSLB सेवा द्वारा निम्नानुसार प्रबंधित किया जाएगा :

एक बार यह नया क्षेत्र बन जाए तो कृपया पहला कॉन्फ़िगरेशन इस प्रकार करें:

डेटा सेंटर 1 में GSLB के मामले की तरह , नेम सर्वर n1 और n2 क्रमशः डेटा सेंटर 1 और डेटा सेंटर 2 में GSLB सेवाओं की ओर इंगित करेंगे ।

फिर सर्विसेज टैब पर क्लिक करें और एक नई सर्विस बनाएं, उदाहरण के लिए वेबप्रायोरिटी :

एल्गोरिदम विकल्प प्राथमिकता का चयन करें : कनेक्शन हमेशा उपलब्ध उच्चतम प्राथमिकता से जुड़ेंगे और सेवा को निम्नानुसार कॉन्फ़िगर करें:

परिवर्तन लागू करने के लिए फ़ार्म को पुनः प्रारंभ करें। दोनों डेटा केंद्रों में समान GSLB सेवा कॉन्फ़िगरेशन लागू करना आवश्यक है।

ध्यान दें कि यदि फार्म गार्डियन को किसी भी स्वास्थ्य जांच को लागू करने के लिए कॉन्फ़िगर नहीं किया गया है, तो GSLB सेवा सेवा कॉन्फ़िगरेशन में स्वास्थ्य जांच फ़ील्ड में परिभाषित TCP पोर्ट पर डिफ़ॉल्ट check_tcp का उपयोग करती है।

नई सेवा को सक्रिय करने के लिए, बनाए गए ज़ोन ( हमारे मामले में zvnlb.net ) पर जाएं और एक नया संसाधन बनाएं। फिर नीचे दिखाए अनुसार नई सेवा का चयन करके इसे बनाएं।

अंत में, परिवर्तनों को सहेजें। इस कॉन्फ़िगरेशन को दोनों डेटा सेंटर में लागू करना आवश्यक है।

इस समय, होस्ट www.zvnlb.net को GSLB मॉड्यूल द्वारा प्राथमिकता मोड में प्रबंधित किया जाता है, इसलिए सभी ट्रैफ़िक डेटा सेंटर 1 पर भेजा जाएगा और फिर, यदि यह विफल हो जाता है, तो ट्रैफ़िक को दूसरे उपलब्ध डेटा सेंटर 2 पर पुनर्निर्देशित कर दिया जाएगा ।

TTL को 5 पर कॉन्फ़िगर किया गया है, यह एक प्रकार की समाप्ति तिथि है जिसे DNS रिकॉर्ड पर रखा जाता है। TTL रिकर्सिव सर्वर या स्थानीय रिज़ॉल्वर को यह बताने का काम करता है कि उसे अपने कैश में उक्त रिकॉर्ड को कितने समय तक रखना चाहिए। इसलिए कम मूल्य कॉन्फ़िगर करने से परिवर्तनों का पता तेज़ी से चलता है।

इस पद्धति को लागू करके हम GSLB सेवा के साथ नए नाम सर्वर को शामिल करके आवश्यकतानुसार अधिक से अधिक डेटा केंद्र जोड़ सकते हैं।

निम्नलिखित DNS अनुरोध zvnlb.net के लिए नेमसर्वर कॉन्फ़िगरेशन और होस्ट www.zvnlb.net के लिए DNS रिज़ॉल्यूशन को दर्शाता है ।

user@client:# host -t ns zvnlb.net zvnlb.net नाम सर्वर ns2.zvnlb.net. zvnlb.net नाम सर्वर ns1.zvnlb.net.

दोनों नेमसर्वर GSLB फार्म में कॉन्फ़िगर किए गए वर्चुअल IP एड्रेस का उपयोग करते हैं।

अब, इस ज़ोन में किसी होस्ट (उदाहरण के लिए www ) को हल करने के लिए अपने वर्तमान DNS सर्वरों का उपयोग करें :

user@client:# nslookup www.zvnlb.net सर्वर: 8.8.8.8 पता: 8.8.8.8#53 गैर-आधिकारिक उत्तर: नाम: www.zvnlb.net पता: 188.166.230.211

जैसा कि दिखाया गया है, वर्तमान में होस्ट 188.166.230.211 डेटा सेंटर 1 में सक्रिय वास्तविक एप्लिकेशन नोड है । जैसे ही होस्ट पहुंच से बाहर हो जाता है (उदाहरण के लिए, 188.166.230.211 में HTTP सेवा बंद हो जाती है), DNS रिज़ॉल्यूशन नीचे दिखाए अनुसार बदल जाएगा।

user@client:# nslookup www.zvnlb.net सर्वर: 8.8.8.8 पता: 8.8.8.8#53 गैर-आधिकारिक उत्तर: नाम: www.zvnlb.net पता: 139.59.186.84

जैसे ही एप्लिकेशन सर्वर विफल होता है, DNS रिजॉल्यूशन होस्ट को डेटा सेंटर 2 में बदल देगा। डेटा सेंटर 1 में होस्ट के फिर से चालू होते ही फेलबैक स्वचालित रूप से लागू हो जाएगा।

सक्रिय-सक्रिय डेटा केंद्रों के लिए GSLB को कॉन्फ़िगर करना #

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

ऐसे मामलों के लिए, कृपया अपनी GSLB सेवा के लिए राउंड रॉबिन लोड बैलेंसिंग नामक शेयरिंग विधि का उपयोग करें, जैसा कि वेब नामक नई सेवा के उदाहरण में दिखाया गया है :

अब, इसे zvnlb.net ज़ोन में जोड़ें और संसाधन कॉन्फ़िगरेशन www को निम्नानुसार बदलें:

परिवर्तनों को सहेजें और अनुरोध होने पर फ़ार्म को पुनः प्रारंभ करें।

इसे टेस्ट करने के लिए, होस्ट www.zvnlb.net को रिजॉल्व करने का प्रयास करें और आउटपुट नीचे दिखाए गए चित्र जैसा दिखेगा:

user@client:# nslookup www.zvnlb.net सर्वर: 8.8.8.8 पता: 8.8.8.8#53 गैर-आधिकारिक उत्तर: नाम: www.zvnlb.net पता: 188.166.230.211 नाम: www.zvnlb.net पता: 139.59.186.84

ध्यान दें कि DNS रिज़ॉल्वर, डिजास्टर रिकवरी मामले की तरह एक के बजाय दोनों अनुप्रयोग सर्वर लौटाता है।

होस्ट में कोई विफलता होने पर, DNS रिज़ॉल्यूशन अपने आप बदल जाएगा। नीचे देखें कि क्या होता है।

root@client:# nslookup www.zvnlb.net सर्वर: 8.8.8.8 पता: 8.8.8.8#53 गैर-आधिकारिक उत्तर: नाम: www.zvnlb.net पता: 139.59.186.84

अनुपलब्ध अनुप्रयोग सर्वर को DNS प्रतिक्रिया सूची से निष्क्रिय कर दिया जाता है।

जैसे ही होस्ट 188.166.230.211 फिर से उपलब्ध होगा, इसे DNS रिजॉल्यूशन में वापस शामिल कर लिया जाएगा।

किसी क्षेत्र का प्रतिनिधित्व करना RELIANOID जीएसएलबी सेवा #

यदि कोई सार्वजनिक डोमेन (उदाहरण के लिए zvnlb.net ) GSLB सेवा को नेम सर्वर रिजॉल्वर के रूप में प्रदान करता है और उस डोमेन के लिए सार्वजनिक DNS सर्वरों द्वारा पहचाना जाना आवश्यक है, तो GSLB सेवा द्वारा उपयोग किए जाने वाले सार्वजनिक IP पते को अपने डोमेन के रजिस्ट्रार (जैसे NameCheap, Goddady या अन्य) में पंजीकृत करना आवश्यक है। निम्नलिखित लिंक डोमेन रजिस्ट्रार प्रक्रिया में GSLB IP को नेम सर्वर के रूप में पंजीकृत करने का तरीका बताता है।

होस्ट को नेमसर्वर के रूप में पंजीकृत करें

दी गई प्रक्रिया का पालन करते हुए आपको ns1.zvnlb.net और ns2.zvnlb.net को दिए गए आईपी पतों के साथ पंजीकृत करना होगा।

जीएसएलबी के लिए एक समर्पित उपक्षेत्र बनाना #

यदि DNS समाधान को GSLB सेवा को सौंपना संभव न हो, तो RELIANOID, नीचे बताई गई कॉन्फ़िगरेशन का इस्तेमाल किया जा सकता है। निम्न उदाहरण दिखाता है कि कैसे एक कॉन्फ़िगरेशन बनाया जाता है उपक्षेत्र एसटी zvnlb.net जो GSLB सेवा में इस नए उपक्षेत्र के नेमसर्वर की ओर संकेत करता है।

नोड 1 (उदाहरण के लिए ns1.zvnlb.net जिसका IP पता 162.243.5.109 है ) और नोड 2 (उदाहरण के लिए ns2.zvnlb.net जिसका IP पता 178.62.233.104 है) नेमसर्वर के रूप में कॉन्फ़िगर किए गए हैं और zvnlb.net ज़ोन के लिए DNS रिज़ॉल्यूशन सेवाएं प्रदान करते हैं । यह ज़ोन Bind9 सार्वजनिक DNS सेवा के अंतर्गत है और हम अपने इंफ्रास्ट्रक्चर के कुछ होस्ट के लिए GSLB क्षमताएं प्रदान करना चाहते हैं, इसलिए हमने DNS सबज़ोन cluster.zvnlb.net बनाने और इस उद्देश्य के लिए 2 GSLB फ़ार्म को DNS नेमसर्वर के रूप में कॉन्फ़िगर करने का निर्णय लिया।

हमने अपने Bind9 DNS सर्वरों में अपने डोमेन cluster.zvnlb.net के लिए निम्न प्रकार से सबज़ोन बनाया है :

अब अनुभाग का अनुसरण करें किसी क्षेत्र का प्रतिनिधित्व करना RELIANOID जीएसएलबी सेवा रखने के लिए 159.89.7.124 और 159.203.12.35 हमारे उदाहरण में ज़ोन के लिए एक मान्यता प्राप्त नेमसर्वर के रूप में cluster.zvnlb.net सार्वजनिक DNS सर्वर द्वारा.

फिर, आप zvnlb.net डोमेन के लिए बताए गए तरीके से कॉन्फ़िगरेशन लागू कर सकते हैं, जैसा कि ऊपर "डेटा केंद्रों की आपदा रिकवरी के लिए GSLB को कॉन्फ़िगर करना" अनुभाग में बताया गया है ।

हमारे अपने DNS में किसी होस्ट को GSLB सेवा से संदर्भित करना #

पिछले अनुभागों में हमने प्राथमिकता और राउंड रॉबिन मोड में लोड बैलेंसिंग के लिए www.zvnlb.net नामक एक होस्ट बनाया है , इसलिए हम इस कॉन्फ़िगरेशन का पुन: उपयोग करके किसी अन्य DNS नेमसर्वर को GSLB क्षमताएं प्रदान कर सकते हैं जो डिफ़ॉल्ट रूप से इस सुविधा का समर्थन नहीं करता है।

इस कॉन्फ़िगरेशन को प्राप्त करने के लिए हमें केवल DNS ज़ोन में एक नया संसाधन बनाना होगा जो GSLB विकल्पों का समर्थन नहीं करता है (उदाहरण के लिए relianoid.io को Bind9 द्वारा प्रबंधित किया जाता है) जैसे कि एक कैनोनिकल नाम या CNAME जैसा कि नीचे दिखाया गया है:

एक बार परिवर्तन लागू हो जाने पर, www.relianoid.io www.zvnlb.net की ओर इंगित करेगा , लेकिन यदि www.zvnlb.net का होस्ट रिज़ॉल्यूशन बदलता है तो www.relianoid.io भी स्वचालित रूप से बदल जाएगा।

ध्यान दें कि यह उदाहरण Bind9 DNS सर्वर में किया गया है, लेकिन कैनोनिकल नाम या CNAMES DNS होस्ट कॉन्फ़िगरेशन हैं जो किसी भी DNS सर्वर सेवा कार्यान्वयन द्वारा समर्थित हैं।

यह सरल व्याख्या दर्शाती है कि यदि हमारी वर्तमान DNS सेवा GSLB क्षमताएं प्रदान नहीं करती है, तब भी GSLB सेवा का उपयोग किया जा सकता है, केवल गैर GSLB क्षेत्र में दिए गए होस्ट के रिज़ॉल्यूशन को GSLB सेवा में अग्रेषित करना होता है। RELIANOID भार संतुलन।