विषय-सूची
- 1 जीएसएलबी अवलोकन
- 2 जीएसएलबी का उपयोग कब करना है
- 3 GSLB कैसे काम करता है
- 4 डेटा केंद्रों की आपदा वसूली के लिए जीएसएलबी को कॉन्फ़िगर करना
- 5 सक्रिय-सक्रिय डेटा केंद्रों के लिए जीएसएलबी को कॉन्फ़िगर करना
- 6 ज़ेवनेट जीएसएलबी सेवा में एक जोन को सौंपना
- 7 GSLB के लिए एक समर्पित उपक्षेत्र बनाना
- 8 हमारे अपने DNS में होस्ट की ओर इशारा करते हुए एक GSLB सेवा का संदर्भ दिया गया
जीएसएलबी अवलोकन
आजकल, आईटी सेवाओं की उच्च उपलब्धता एक जरूरी है और यही कारण है कि कंपनियों और संगठनों ने एक से अधिक डेटा सेंटर में दुनिया भर में और मेजबान सेवाओं में वितरित कंप्यूटिंग सिस्टम विकसित किए हैं, क्योंकि यह निम्नलिखित लाभ प्रदान करता है:
दोष सहिष्णुता: जब डेटा केंद्र में होस्ट की गई सेवा विफल हो जाती है तो सेवा किसी भी अन्य उपलब्ध साइट पर चली जाती है।
स्वचालित डेटा केंद्र पुनर्प्राप्ति: जब एक डेटा केंद्र विफल हो जाता है तो सेवा किसी अन्य उपलब्ध डेटा केंद्र पर स्वचालित रूप से पुनर्निर्देशित हो जाती है।
भार संतुलन: विलंबता को सुधारने और उपलब्ध सेवा वितरण को तेज़ बनाने के लिए उपलब्ध सभी साइटों के बीच लोड वितरित करके यातायात को अनुकूलित किया जा सकता है।
बेहतर सुस्ती: क्लाइंट एप्लिकेशन ट्रैफ़िक सीधे वास्तविक सर्वर के साथ है, लोड बैलेंसर के माध्यम से सभी एप्लिकेशन डेटा को पारित करने की कोई आवश्यकता नहीं है।
क्लाउड में आईटी सेवाओं को अपनाने और लागू करने के लिए आवश्यक है कि जियो स्थित उच्च उपलब्धता समाधान प्रदान करने के लिए WAN पर आधारित एक विधि सबसे अच्छा विकल्प है। जिसे हम कहते हैं वैश्विक सेवा लोड संतुलन or GSLB.
जीएसएलबी का उपयोग कब करना है
GSLB सेवा को निम्नलिखित उपयोग के मामलों के लिए उपयोग करने की अनुशंसा की जाती है:
वे कंपनियां जो WAN के माध्यम से एक से अधिक डेटा सेंटर में अपनी सेवाओं की मेजबानी करती हैं।
जिन कंपनियों को सेवाओं या डेटा केंद्रों की उच्च उपलब्धता बनाने की आवश्यकता होती है।
इंटरनेट सेवा प्रदाता अपने उपयोगकर्ताओं द्वारा उपयोग किए जाने वाले इनबाउंड लोड संतुलन सेवाओं को बनाने के लिए।
निश्चित रूप से, जब जीएसएलबी की विफलता के बिंदुओं के बिना दुनिया भर के सर्वरों के बीच उपयोगकर्ताओं और ट्रैफ़िक को साझा करना आवश्यक है, तो यह सही समाधान है।
GSLB कैसे काम करता है
GSLB एक लोड संतुलन तंत्र है डीएनएस प्रोटोकॉल, यह तेज़ और विश्वसनीय है क्योंकि यह उपयोग करता है यूडीपी प्रोटोकॉल और क्लाइंट की प्रतिक्रिया लगभग वास्तविक समय में है।
एक सामान्य DNS अनुरोध में, उदाहरण के लिए www.zvnlb.net, एक क्लाइंट स्थानीय कॉन्फ़िगर DNS सर्वरों के लिए DNS अनुरोध रिज़ॉल्यूशन भेजता है (उदाहरण के लिए 8.8.8.8 और 8.8.4.4 ) और फिर क्लाइंट सिस्टम अनुरोध के खिलाफ बनाने और क्वेरी भेजने के लिए रैंडमली एक सर्वर का चयन करता है।
चयनित DNS सर्वर क्लाइंट से अनुरोध प्राप्त करता है (उदाहरण के लिए, आईपी पता क्या है www.zvnlb.net? ) और स्थानीय कॉन्फ़िगर DNS सर्वर यह खोजने की कोशिश करते हैं कि DNS ज़ोन को हल करने के लिए कौन जिम्मेदार है zvnlb.net.
क्लाइंट द्वारा उपयोग किया जाने वाला DNS, 8.8.8.8 or 8.8.4.4 इस मामले में, कि पता लगाता है ns1.zvnlb.net और ns2.zvnlb.net के लिए क्षेत्र प्रस्तावों के जिम्मेदार हैं zvnlb.net इसलिए वे क्लाइंट द्वारा प्राप्त DNS क्वेरी (उदाहरण के लिए, आईपी पता क्या है) भेजते हैं www.zvnlb.net? ) उनमें से एक को।
या तो नाम सर्वरों में से एक ns1.zvnlb.net or ns2.zvnlb.net से DNS क्वेरी प्राप्त करता है 8.8.8.8 or 8.8.4.4 और फिर, नाम सर्वर जो अनुरोध प्राप्त करता है, मेजबान के लिए उपलब्ध सर्वरों की जांच करता है www.zvnlb.net और यह होस्ट के लिए वास्तविक एप्लिकेशन की सेवा के लिए उपलब्ध एप्लिकेशन सर्वरों की सूची के साथ DNS क्वेरी का जवाब देगा www.zvnlb.net, इसलिए यह जानकारी अंततः ग्राहक को प्राप्त होगी।
अब क्लाइंट बेतरतीब ढंग से 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 or ns2.zvnlb.net कुछ वास्तविक सर्वरों के स्वास्थ्य की स्थिति की जाँच करने में किसी भी समस्या का पता लगाता है, तो अनुपलब्ध सर्वर को एक निश्चित समय के लिए निष्क्रिय कर दिया जाएगा और इसका आईपी पता DNS प्रश्नों में तब तक सूचीबद्ध नहीं किया जाएगा जब तक कि यह फिर से उपलब्ध न हो जाए।
निम्नलिखित आरेख GSLB क्षमताओं के साथ वर्णित DNS ट्रैफ़िक को दर्शाता है।
डेटा केंद्रों की आपदा वसूली के लिए जीएसएलबी को कॉन्फ़िगर करना
इस कॉन्फ़िगरेशन को उन सेवाओं के लिए अनुशंसित किया जाता है जिनके लिए आपदा पुनर्प्राप्ति के लिए डेटा केंद्रों की उच्च उपलब्धता की आवश्यकता होती है, इसलिए यदि किसी निश्चित कंपनी की सभी सेवाएँ एक डेटा केंद्र में हैं और ऐसा डेटा केंद्र विफल रहता है, तो सिस्टम सभी प्रभावित सेवाओं को किसी अन्य उपलब्ध डेटा केंद्र में ले जाएगा ।
आपदा रिकवरी के लिए सक्रिय-निष्क्रिय डेटा केंद्र बनाने के लिए जीएसएलबी कॉन्फ़िगरेशन के इस वास्तविक उदाहरण का पालन करें।
हमने अलग-अलग साइटों, फ्रैंकफर्ट में दो डेटा केंद्रों पर दो ज़ेवनेट लोड बैलेंसर तैनात किए हैं 159.89.7.124 और टोरंटो 159.203.12.35 और हमारे पास एक वेब सेवा है जो DNS होस्ट का जवाब देती है www.zvnlb.netमें कॉन्फ़िगर किया गया डाटा सेंटर 1 और डाटा सेंटर 2। इस आर्किटेक्चर का डिज़ाइन सभी क्लाइंट्स को ट्रैफ़िक भेजने की अनुमति देने वाला है डाटा सेंटर 1 लेकिन अगर यह विफल रहता है तो ग्राहकों को पुनर्निर्देशित करता है डाटा सेंटर 2.
इस कॉन्फ़िगरेशन को प्राप्त करने के लिए नीचे दी गई प्रक्रिया का पालन करें।
में Zevenet वेब पैनल से कनेक्ट करें डाटा सेंटर 1 (हमारे मामले के लिए फ्रैंकफर्ट), मुख्य मेनू में क्लिक करें GSLB मॉड्यूल और एक नया बनाएँ खेत, हमारे उदाहरण में कहा जाएगा DNS1-फ्रैंकफर्ट वर्चुअल पोर्ट में 53.
खेत बनने के बाद, कृपया इसे संपादित करें, और टैब पर जाएं जोन और इस मामले में GSLB मॉड्यूल द्वारा प्रबंधित होने जा रहा DNS ज़ोन बनाएं zvnlb.netबनाने के लिए हम तीन प्रमुख सामाजिक अंगों से जुडते हैं
एक बार यह ज़ोन बन जाने के बाद कृपया पहला विन्यास बनाएं जैसा कि नीचे दिखाया गया है:
ध्यान दें कि ns1 और ns2 ज़ोन के लिए DNS रिज़ॉल्यूशन के जिम्मेदार नाम सर्वर हैं zvnlb.net (हमारे मामले में, एक जीएसएलबी सेवा फ्रैंकफर्ट में और दूसरी टोरंटो में)।
फिर, मुख्य मेनू चयन में डेटा सेंटर 2 में Zevenet वेब पैनल से कनेक्ट करें GSLB और एक नया बनाएँ खेत, हमारे मामले में बुलाया जाएगा DNS2-टोरंटो वर्चुअल पोर्ट में 53.
नए जीएसएलबी फार्म को संपादित करें और टैब पर जाएं जोन, इस GSLB सेवा के द्वारा प्रबंधित होने जा रहा DNS ज़ोन यहां बनाएं zvnlb.net के रूप में इस प्रकार है:
एक बार यह नया क्षेत्र बन जाने के बाद कृपया पहला विन्यास इस प्रकार करें:
जैसे GSLB के मामले में डाटा सेंटर 1, नाम सर्वर n1 और n2 दोनों में जीएसएलबी सेवाओं को इंगित करेगा डाटा सेंटर 1 और डाटा सेंटर 2, क्रमशः।
फिर टैब में क्लिक करें सेवाएँ और उदाहरण के लिए, एक नई सेवा बनाएँ webpriority:
चयन कलन विधि विकल्प प्राथमिकता: हमेशा उपलब्ध सबसे बेशकीमती के लिए कनेक्शन और सेवा को निम्नानुसार कॉन्फ़िगर करें:
परिवर्तनों को लागू करने के लिए खेत को पुनः आरंभ करें। यह दोनों डेटा केंद्रों में एक ही GSLB सेवा कॉन्फ़िगरेशन लागू करने के लिए आवश्यक है।
ध्यान दें कि यदि खेत का रखवाला किसी भी स्वास्थ्य जांच को लागू करने के लिए कॉन्फ़िगर नहीं किया गया है, जीएसएलबी सेवा डिफ़ॉल्ट का उपयोग करती है check_tcp सेवा कॉन्फ़िगरेशन में स्वास्थ्य जांच क्षेत्र में परिभाषित टीसीपी पोर्ट।
नई सेवा को सक्षम करने के लिए, बनाए गए क्षेत्र पर जाएं (zvnlb.net हमारे मामले में) और एक नया बनाएँ संसाधन। फिर नया चुनकर इसे बनाएं सर्विस जैसा कि नीचे दिखाया गया है।
अंत में, परिवर्तन सहेजें। इस कॉन्फ़िगरेशन को दोनों डेटा केंद्रों में लागू करना आवश्यक है।
इस बिंदु पर, मेजबान www.zvnlb.net जीएसएलबी मॉड्यूल द्वारा प्रबंधित किया जाता है प्राथमिकता मोड, इसलिए सभी ट्रैफ़िक को भेजा जाएगा डाटा सेंटर 1 और फिर, यदि यह विफल रहता है, तो यातायात उपलब्ध अन्य पर पुनर्निर्देशित किया जाएगा डाटा सेंटर 2.
TTL को 5 में कॉन्फ़िगर किया गया है, यह समाप्ति तिथि की तरह है जिसे DNS रिकॉर्ड पर डाला जाता है। TTL पुनरावर्ती सर्वर या स्थानीय रिज़ॉल्वर को यह बताने का कार्य करता है कि उसे कब तक अपने कैश में रिकॉर्ड रखना चाहिए। तो तेजी से कॉन्फ़िगर किए गए कम मान का पता लगाया जाता है।
इस विधि को लागू करते हुए हम GSLB सेवा के साथ नए नाम सर्वर को शामिल करके आवश्यकतानुसार कई डेटा केंद्र जोड़ सकते हैं।
निम्न DNS अनुरोध के लिए Nameservers कॉन्फ़िगरेशन दिखाता है zvnlb.net और होस्ट के लिए DNS रिज़ॉल्यूशन www.zvnlb.net.
user@client:# host -t ns zvnlb.net zvnlb.net name server ns2.zvnlb.net. zvnlb.net name server ns1.zvnlb.net.
दोनों नेमसर्वर जीएसएलबी खेतों में कॉन्फ़िगर किए गए वर्चुअल आईपी पतों का उपयोग करते हैं।
अब, होस्ट को हल करने के लिए अपने वर्तमान DNS सर्वर का उपयोग करें (उदाहरण के लिए www) इस क्षेत्र में:
user@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.zvnlb.net Address: 188.166.230.211
जैसा कि दिखाया गया है, वर्तमान में मेजबान है 188.166.230.211 में सक्रिय वास्तविक अनुप्रयोग नोड है डाटा सेंटर 1। जैसे ही मेजबान पहुंच योग्य नहीं है (उदाहरण के लिए, http सेवा 188.166.230.211 नीचे है) DNS रिज़ॉल्यूशन बदल जाएगा जैसा कि नीचे दिखाया गया है।
user@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.zvnlb.net Address: 139.59.186.84
जैसे ही एप्लिकेशन सर्वर विफल हो जाता है, DNS रिज़ॉल्यूशन होस्ट को बदल देगा डाटा सेंटर 2। एक बार मेजबान में डाटा सेंटर 1 फेल-बैक स्वचालित रूप से लागू किया जाएगा।
सक्रिय-सक्रिय डेटा केंद्रों के लिए जीएसएलबी को कॉन्फ़िगर करना
मोड प्राथमिकता के साथ उच्च उपलब्धता डिजास्टर रिकवरी सिस्टम के लिए एक अच्छा विकल्प है लेकिन रिकवरी के लिए इसका उपयोग किया जाने वाला बैकअप डेटा सेंटर बहुत अधिक उपयोग नहीं करता है, इसलिए आमतौर पर उपलब्ध डेटा के बीच सभी ट्रैफ़िक को संतुलित करने के लिए यह अधिक कुशल होता है केंद्र।
ऐसे मामलों के लिए, कृपया अपने GSLB सेवा के लिए साझाकरण विधि का उपयोग करें राउंड रॉबिन लोड संतुलन जैसा कि इसे नई सेवा के लिए उदाहरण में दिखाया गया है वेब:
अब, इसे ज़ोन में जोड़ें zvnlb.net और संसाधन कॉन्फ़िगरेशन बदलें www के रूप में इस प्रकार है:
परिवर्तनों को सहेजें और अनुरोध होने पर खेत को पुनः आरंभ करें।
इसका परीक्षण करने के लिए, मेजबान को हल करने का प्रयास करें www.zvnlb.net और आउटपुट ऐसा दिखेगा जैसे इसे दिखाया गया है:
user@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.zvnlb.net Address: 188.166.230.211 Name: www.zvnlb.net Address: 139.59.186.84
ध्यान दें कि DNS रिसॉल्वर डिजास्टर रिकवरी केस की तरह एक के बजाय दोनों एप्लिकेशन सर्वर को लौटाता है।
होस्ट की विफलता के बाद, DNS रिज़ॉल्यूशन स्वचालित रूप से बदल जाएगा। नीचे देखें क्या होता है
root@client:# nslookup www.zvnlb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.zvnlb.net Address: 139.59.186.84
अनुपलब्ध एप्लिकेशन सर्वर डीएनएस प्रतिक्रिया सूची से निष्क्रिय है।
यजमान के रूप में 188.166.230.211 फिर से उपलब्ध है, इसे DNS रिज़ॉल्यूशन में वापस शामिल किया जाएगा।
ज़ेवनेट जीएसएलबी सेवा में एक जोन को सौंपना
एक सार्वजनिक क्षेत्र के मामले में (उदाहरण के लिए zvnlb.net) जो एक जीएसएलबी सेवा को एक नाम सर्वर रिसॉल्वर के रूप में वितरित करता है जिसे ऐसे डोमेन के लिए सार्वजनिक डीएनएस सर्वर द्वारा मान्यता प्राप्त करने की आवश्यकता होती है, फिर आपके डोमेन के रजिस्ट्रार (जैसे नेमशेप, गोड्डाडी या अन्य) में जीएसएलबी सेवा द्वारा उपयोग किए जाने वाले सार्वजनिक आईपी पते को पंजीकृत करना आवश्यक है। । निम्न लिंक बताता है कि डोमेन रजिस्ट्रार प्रक्रिया में GSLB IP को NameServers के रूप में कैसे पंजीकृत किया जाए।
एक HostServer के रूप में एक मेजबान रजिस्टर
दी गई प्रक्रिया का पालन करते हुए आपको पंजीकरण करना होगा ns1.zvnlb.net और ns2.zvnlb.net दिए गए आईपी के साथ।
GSLB के लिए एक समर्पित उपक्षेत्र बनाना
ज़ेनसेट की जीएसएलबी सेवा के लिए डीएनएस रिज़ॉल्यूशन को सौंपना संभव नहीं होने पर, नीचे दिए गए कॉन्फ़िगरेशन को प्रदर्शित किया जा सकता है। निम्नलिखित उदाहरण से पता चलता है कि कैसे निर्माण करना है subzone एसटी zvnlb.net GSLB सेवा में इस नए उपक्षेत्र के NameServers को इंगित करता है।
नोड 1 (उदाहरण के लिए ns1.zvnlb.net आईपी के साथ 162.243.5.109) और नोड 2 (उदाहरण के लिए ns2.zvnlb.net आईपी के साथ 178.62.233.104) Nameservers कॉन्फ़िगर और क्षेत्र के लिए DNS रिज़ॉल्यूशन सेवाओं की पेशकश कर रहे हैं zvnlb.net, यह क्षेत्र एक Bind9 सार्वजनिक DNS सेवा के अंतर्गत है और हम अपने बुनियादी ढांचे के कुछ मेजबानों के लिए GSLB क्षमताओं की पेशकश करना चाहते हैं, इसलिए हमने DNS सबजोन बनाने का फैसला किया cluster.zvnlb.net और 2 GSLB फार्म को DNS Nameservers की तरह कॉन्फ़िगर करें।
हमने अपने डोमेन के लिए सबज़ोन बनाया है cluster.zvnlb.net हमारे Bind9 DNS सर्वर इस प्रकार हैं:
अब सेक्शन को फॉलो करें ज़ेवनेट जीएसएलबी सेवा में एक जोन को सौंपना रखने के लिए 159.89.7.124 और 159.203.12.35 ज़ोन के लिए एक मान्यता प्राप्त नेमसर्वर के रूप में हमारे उदाहरण में cluster.zvnlb.net सार्वजनिक DNS सर्वर द्वारा।
फिर, आप कॉन्फ़िगरेशन लागू कर सकते हैं जैसे डोमेन के लिए समझाया गया है zvnlb.net उपरोक्त अनुभाग में डेटा केंद्रों की आपदा वसूली के लिए जीएसएलबी को कॉन्फ़िगर करना.
हमारे अपने DNS में होस्ट की ओर इशारा करते हुए एक GSLB सेवा का संदर्भ दिया गया
पिछले अनुभागों में हमने एक मेजबान बनाया है जिसका नाम है www.zvnlb.net प्राथमिकता और राउंड रॉबिन मोड में लोड संतुलन, इसलिए हम जीएसएलबी क्षमताओं को दूसरे DNS नेमसेवर को पेश करने के लिए इस कॉन्फ़िगरेशन का पुन: उपयोग कर सकते हैं जो डिफ़ॉल्ट रूप से इस सुविधा का समर्थन नहीं करता है।
इस कॉन्फ़िगरेशन को प्राप्त करने के लिए हमें केवल एक नया बनाना होगा संसाधन DNS ज़ोन में जो जीएसएलबी विकल्पों का समर्थन नहीं करता है (उदाहरण के लिए zevenet.io Bind9 द्वारा प्रबंधित किया गया है) जैसे वैधानिक नाम or CNAME जैसा कि नीचे दिखाया गया है:
एक बार परिवर्तन लागू होने के बाद, www.zevenet.io की ओर इशारा किया जाएगा www.zvnlb.net, लेकिन अगर मेजबान संकल्प www.zvnlb.net तब स्वतः परिवर्तन होता है www.zevenet.io साथ ही बदल जाएगा।
ध्यान दें कि यह उदाहरण एक Bind9 DNS सर्वर में किया गया है लेकिन Canonical नाम या CNAMES DNS होस्ट कॉन्फ़िगरेशन हैं जो किसी DNS सर्वर सेवा कार्यान्वयन द्वारा समर्थित हैं।
यह सरल व्याख्या बताती है कि GSLB सेवा का उपयोग तब भी किया जा सकता है जब हमारी वर्तमान DNS सेवा GSLB क्षमताओं की पेशकश नहीं करती है, बस एक गैर GSLB क्षेत्र में दिए गए होस्ट के संकल्प को Zevenet लोड बैलेंसर में GSLB सेवा में अग्रेषित कर रही है।