DNS फेलओवर की सिफारिश क्यों नहीं की जाती है?

Question

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

मेरे लिए ऐसा लगता है कि डीएनएस फेलओवर यहां एकमात्र विफल विकल्प है, लेकिन आम सहमति यह एक अच्छा विकल्प नहीं है। फिर भी DNSmadeeasy.com जैसी सेवाएं इसे प्रदान करती हैं, इसलिए इसमें योग्यता होनी चाहिए। कोई टिप्पणी?

Comments

विषय पर अद्यतन चर्चा के लिए यहां देखें । फेलओवर अब आधुनिक ब्राउज़रों द्वारा स्वचालित रूप से किया जाता है।

— GetFree

Answer 1

'DNS फेलओवर' द्वारा मुझे लगता है कि इसका मतलब है कि DNS राउंड रॉबिन कुछ मॉनीटरिंग के साथ संयुक्त है, यानी DNS होस्टनाम के लिए कई आईपी पते प्रकाशित कर रहा है, और मॉनिटरिंग का पता लगाने पर एक मृत पते को हटा रहा है कि एक सर्वर डाउन है। यह छोटी, कम ट्रैफ़िक वेबसाइटों के लिए व्यावहारिक हो सकता है।

डिज़ाइन के अनुसार, जब आप डीएनएस अनुरोध का जवाब देते हैं तो आप प्रतिक्रिया के लिए टाइम टू लाइव (टीटीएल) भी प्रदान करते हैं। दूसरे शब्दों में, आप अन्य DNS सर्वर और कैश बता रहे हैं "आप इस उत्तर को स्टोर कर सकते हैं और मेरे साथ वापस जाँचने से पहले x मिनट के लिए इसका उपयोग कर सकते हैं"। इस से कमियां आती हैं:

• DNS विफलता के साथ, आपके उपयोगकर्ताओं का एक अज्ञात प्रतिशत आपके DNS डेटा को अलग-अलग मात्रा में TTL के बाईं ओर कैश करेगा। TTL के समाप्त होने तक ये मृत सर्वर से जुड़ सकते हैं। इससे फेलओवर पूरा करने के तेज़ तरीके हैं।
• उपरोक्त के कारण, आप टीटीएल को काफी कम करने के लिए इच्छुक हैं, 5-10 मिनट का कहना है। लेकिन इसे उच्चतर सेट करना एक (बहुत छोटा) प्रदर्शन लाभ देता है, और नेटवर्क ट्रैफ़िक में थोड़ी गड़बड़ होने पर भी आपके DNS प्रसार कार्य को विश्वसनीय ढंग से करने में मदद कर सकता है। इसलिए डीएनएस आधारित फेलओवर का उपयोग उच्च टीटीएल के खिलाफ जाता है, लेकिन उच्च टीटीएल डीएनएस का एक हिस्सा है और उपयोगी हो सकता है।

अच्छे अपटाइम में शामिल होने के अधिक सामान्य तरीके:

• एक ही LAN पर सर्वर को एक साथ रखना।
• अत्यधिक उपलब्ध शक्ति और नेटवर्क विमानों के साथ डेटासेंटर में LAN रखें।
• अलग-अलग सर्वर विफलताओं पर लोड फैलाने और विफल होने के लिए एक HTTP लोड बैलेंसर का उपयोग करें।
• अतिरेक / अपेक्षित अपटाइम के स्तर को आप अपने फायरवॉल, लोड बैलेन्सर और स्विच के लिए प्राप्त करें।
• फुल-डेटासेंटर विफलताओं, और स्विच / डेटाबेस सर्वर / अन्य संसाधन की सामयिक विफलता के लिए संचार रणनीति रखें, जिन्हें आसानी से प्रतिबिंबित नहीं किया जा सकता है।

वेब साइटों की एक बहुत छोटी अल्पसंख्यक डेटा-संस्थापकों के बीच 'भू-संतुलन' के साथ, मल्टी-डेटासेंटर सेटअप का उपयोग करती है।

Comments

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

— सियान

मल्टी-डेटासेंटर सेटअप में किसी भी जोड़ को जोड़ें और यह डेटासेंटर-विफलता प्रमाण बन जाता है।

— पेट्रस

किसी भी प्रसारण पर विकिपीडिया प्रविष्टि ( en.wikipedia.org/wiki/Anycast ) DNS रूट सर्वर लचीलापन के संबंध में चर्चा करता है।

— dunxd

DDoS के हमले इतने आम हैं कि अब पूरे डेटा सेंटरों को ऑफलाइन लाया जा सकता है (लिनोड लंदन और उनके अन्य डेटाट्रेस दिसंबर 2015 तक)। तो एक ही प्रदाता का उपयोग करके, एक ही डेटा केंद्र में अनुशंसित नहीं है। इसलिए विभिन्न प्रदाताओं के साथ कई डेटा सेंटर एक अच्छी रणनीति होगी, जो हमें DNS फेलओवर में वापस लाती है जब तक कि बेहतर विकल्प मौजूद न हो।

— लॉरेंस कोप

क्या एक फेलओवर मौजूद नहीं है, क्योंकि किसी डिवाइस के डाउन / दोषपूर्ण होने पर आपको अपनी साइट को लाइव रखने की आवश्यकता है? जब उसी नेटवर्क में समान डिवाइस साझा करने वाले राउटर में आपका फेलओवर कितना अच्छा होगा?

— user2128576

Answer 2

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

DNS फेलओवर के लिए डिज़ाइन नहीं किया गया था - लेकिन इसे TTL के साथ डिज़ाइन किया गया था जो एक ठोस निगरानी प्रणाली के साथ संयोजित होने पर फ़ेलओवर की जरूरतों के लिए आश्चर्यजनक रूप से काम करता है। TTL को बहुत कम सेट किया जा सकता है। मैंने तेजी से डीएनएस फेलओवर आधारित समाधानों को हल्का करने के लिए उत्पादन में 5 सेकंड के टीटीएल का प्रभावी रूप से उपयोग किया है। आपके पास डीएनएस सर्वर को अतिरिक्त लोड से निपटने में सक्षम होना चाहिए - और नाम कट नहीं होगा। हालाँकि, पॉवरड्यून्स बिल को फिट करता है, जब निरर्थक नाम सर्वर पर एक mysql प्रतिकृति डेटाबेस के साथ समर्थित है। आपको एक ठोस वितरित निगरानी प्रणाली की भी आवश्यकता होती है जिसे आप स्वचालित विफलता एकीकरण के लिए भरोसा कर सकते हैं। ज़ैबिक्स मेरे लिए काम करता है - मैं कई वितरित ज़ैबिक्स सिस्टम से आउटेज को लगभग तुरंत सत्यापित कर सकता हूं - फ्लाई पर पॉवरडन्स द्वारा उपयोग किए गए mysql रिकॉर्ड्स को अपडेट करें - आउटेज और ट्रैफ़िक स्पाइक्स के दौरान लगभग तुरंत फ़ेलओवर प्रदान करें।

लेकिन हे - मैंने एक कंपनी बनाई जो बड़ी कंपनियों के लिए काम करने के वर्षों के बाद डीएनएस फेलओवर सेवाएं प्रदान करती है। इसलिए नमक के एक दाने के साथ मेरी राय लें। यदि आप एक आउटेज के दौरान उच्च वॉल्यूम साइटों के कुछ ज़ैबिक्स ट्रैफ़िक ग्राफ़ देखना चाहते हैं - तो अपने लिए यह देखना कि वास्तव में DNS फेलओवर कितना अच्छा काम करता है - मुझे ईमेल करें मैं साझा करने के लिए अधिक खुश हूं।

Comments

Cian का उत्तर serverfault.com/a/60562/87017 सीधे आपके एक के विपरीत है ..... तो कौन सही है?

— पचेरियर

यह मेरा अनुभव है कि छोटी TTLs इंटरनेट पर काम नहीं करती हैं। आप DNS सर्वर चला रहे होंगे जो RFC का सम्मान करते हैं - लेकिन वहाँ बहुत सारे सर्वर हैं जो नहीं करते हैं। कृपया यह न मानें कि यह राउंड रॉबिन डीएनएस के खिलाफ एक तर्क है - नीचे vmiazzo का उत्तर भी देखें - मैंने आरआर डीएनएस का उपयोग करके व्यस्त साइटों को चलाया है और इसका परीक्षण किया है - यह काम करता है। केवल कुछ जावा आधारित क्लाइंट्स (ब्राउज़र नहीं) के साथ मुझे जो समस्याएँ थीं, वे भी असफलता पर फिर से जुड़ने की कोशिश नहीं करते थे, अकेले एक आरएसटी पर मेजबानों की सूची को

— चक्रित करते हैं

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

— टॉम विल्सन

Answer 3

DNS विफलता का मुद्दा यह है कि यह कई मामलों में अविश्वसनीय है। कुछ ISP आपके TTLs को अनदेखा कर देंगे, ऐसा तुरंत नहीं होता है, भले ही वे आपके TTL का सम्मान करते हों, और जब आपकी साइट वापस आती है, तो यह सत्र के साथ कुछ अजीबता पैदा कर सकता है जब उपयोगकर्ता का DNS कैश आउट हो जाता है, और वे शीर्षक समाप्त कर देते हैं दूसरे सर्वर पर।

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

Comments

+1 धीमी और अविश्वसनीय

— क्रिस एस

इसके अलावा serverfault.com/q/315199/87017

— पचेरियर

Answer 4

प्रचलित राय यह है कि DNS RR के साथ, जब एक IP नीचे जाता है, तो कुछ क्लाइंट टूटे हुए IP का उपयोग मिनटों तक करना जारी रखेंगे। यह पिछले कुछ सवालों के जवाब में कहा गया था और यह विकिपीडिया पर भी लिखा गया है।

वैसे भी,

http://crypto.stanford.edu/dns/dns-rebinding.pdf बताता है कि यह वर्तमान HTML ब्राउज़रों में से अधिकांश के लिए सच नहीं है। वे सेकंड में अगले आईपी की कोशिश करेंगे।

http://www.tenereillo.com/GSLBPageOfShame.htm और भी मज़बूत लगता है:

एकाधिक ए रिकॉर्ड का उपयोग व्यापार की एक चाल या लोड संतुलन उपकरण विक्रेताओं द्वारा कल्पना की गई विशेषता नहीं है। DNS प्रोटोकॉल को इस कारण से कई ए रिकॉर्ड के समर्थन के साथ डिजाइन किया गया था। ब्राउज़र और प्रॉक्सी और मेल सर्वर जैसे एप्लिकेशन DNS प्रोटोकॉल के उस हिस्से का उपयोग करते हैं।

शायद कुछ विशेषज्ञ टिप्पणी कर सकते हैं और अधिक स्पष्ट विवरण दे सकते हैं कि DNS आरआर उच्च उपलब्धता के लिए अच्छा क्यों नहीं है।

धन्यवाद,

वैलेंटिनो

पुनश्च: टूटी लिंक के लिए खेद है, लेकिन नए उपयोगकर्ता के रूप में, मैं 1 से अधिक पोस्ट नहीं कर सकता

Comments

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

— सियान

तो, crypto.stanford.edu/dns/dns-rebinding.pdf अध्याय 3.1 पर क्या लिखा है ? << इंटरनेट एक्सप्लोरर 7 पिन 30 मिनट के लिए DNS बाइंडिंग करता है। दुर्भाग्य से, यदि हमलावर के डोमेन में एकाधिक ए रिकॉर्ड हैं और वर्तमान सर्वर अनुपलब्ध हो जाता है, तो ब्राउज़र एक सेकंड के भीतर एक अलग आईपी पते की कोशिश करेगा।

— वैलेंटिनो मियाज़ो

यहां मेरा उपसंहार स्थानांतरित किया गया serverfault.com/questions/69870/…

— वैलेंटिनो मियाजाओ

Answer 5

मैंने कई वर्षों के लिए एक उत्पादन मध्यम-तस्करी लेकिन व्यापार-महत्वपूर्ण वेबसाइट (दो भौगोलिक क्षेत्रों में) पर DNS आरआर फेलओवर चलाया।

यह ठीक काम करता है, लेकिन कम से कम तीन सूक्ष्मताएं हैं जो मैंने कठिन तरीके से सीखीं।

1) ब्राउजर एक गैर-काम करने वाले आईपी से 30 सेकंड (आखिरी बार मैंने चेक किया) के बाद एक काम करने वाले आईपी से विफल हो जाएगा यदि दोनों को आपके क्लाइंट के लिए उपलब्ध कैशे डीएनएस में सक्रिय माना जाता है। यह मूल रूप से एक अच्छी बात है।

लेकिन "आधे" होने पर आपके उपयोगकर्ता 30 सेकंड प्रतीक्षा करते हैं, यह अस्वीकार्य है, इसलिए आप शायद अपने टीटीएल रिकॉर्ड्स को कुछ मिनटों या कुछ हफ्तों के लिए अपडेट करना चाहेंगे, ताकि आउटेज की स्थिति में, आप तेजी से डाउन सर्वर को हटा सकें अपने DNS से। अन्य लोगों ने अपनी प्रतिक्रियाओं में इसका उल्लेख किया है।

2) यदि आपका एक नेमवेर्सर्स (या पूरी तरह से आपकी दो जिओग्राफी में से एक) नीचे चला जाता है जो आपके राउंड-रॉबिन डोमेन की सेवा कर रहा है, और यदि उनमें से एक प्राथमिक नीचे चला जाता है, तो मैं आपको याद दिलाता हूं कि आप अन्य मुद्दों को चलाने की कोशिश कर सकते हैं। यदि आपने अपना SOA TTL / समाप्ति सेट नहीं किया है तो DNS से ​​नेमसर्वर को नामांकित व्यक्ति के लिए पर्याप्त रूप से कम मूल्य पर भी समाप्त कर दिया है। मैं यहां तकनीकी विवरण गलत हो सकता है, लेकिन केवल एक टीटीएल सेटिंग से अधिक है जिसे आपको विफलता के एकल बिंदुओं के खिलाफ वास्तव में बचाव करने का अधिकार प्राप्त करने की आवश्यकता है।

3) यदि आप वेब एपीआई, आरईएसटी सेवाओं आदि को प्रकाशित करते हैं, तो उन्हें आमतौर पर ब्राउज़रों द्वारा नहीं बुलाया जाता है, और इस तरह मेरी राय में डीएनएस फेलओवर वास्तविक दोष दिखाना शुरू कर देता है। ऐसा इसलिए हो सकता है कि कुछ लोग कहते हैं, जैसा कि आप इसे "अनुशंसित नहीं है" कहते हैं। यहाँ मैं ऐसा क्यों कहता हूं। सबसे पहले, जो एप्लिकेशन उन URL का उपभोग करते हैं वे आमतौर पर ब्राउज़र नहीं होते हैं, इसलिए उनके पास सामान्य ब्राउज़र के 30-सेकंड के विफलता गुण / तर्क की कमी होती है। दूसरा, दूसरी DNS प्रविष्टि को कॉल किया जाता है या नहीं, यहां तक ​​कि DNS को फिर से प्रदूषित किया जाता है, इन API / REST क्लाइंट द्वारा उपयोग की जाने वाली प्रोग्रामिंग भाषाओं में नेटवर्किंग पुस्तकालयों के निम्न-स्तरीय प्रोग्रामिंग विवरणों पर बहुत अधिक निर्भर करता है, साथ ही साथ वे कैसे कहते हैं API / REST क्लाइंट ऐप। (वे कवर के तहत, पुस्तकालय get_addr कॉल करते हैं, और कब? यदि सॉकेट लटका या बंद हो जाता है, तो क्या ऐप नए सॉकेट्स को फिर से खोल देता है? क्या कुछ प्रकार के टाइमआउट लॉजिक हैं? आदि)

यह सस्ता है, अच्छी तरह से परखा हुआ है, और "ज्यादातर काम करता है"। इसलिए अधिकांश चीजों के साथ, आपका लाभ भिन्न हो सकता है।

Comments

एक पुस्तकालय जो एक पते के लिए अन्य RRs पर पुनः प्रयास नहीं करता है वह टूट गया है। डेवलपर्स को getaddrinfo () आदि के लिए मैनुअल पेजों पर इंगित करें

— जैसन

यह भी महत्वपूर्ण है कि क्रोम और फ़ायरफ़ॉक्स जैसे ब्राउज़र टीटीएल का सम्मान नहीं करते हैं, लेकिन कुछ सेकंड ( फ़ायरफ़ॉक्स संदर्भ , क्रोम संदर्भ और अन्य ) निर्दिष्ट करने पर भी उन्हें कम से कम 1 मिनट का समय दें । मुझे लगता है कि यह बुरा है क्योंकि TTL से अधिक समय तक कैचिंग करना युक्ति के खिलाफ है।

— nh2

Answer 6

ऐसे लोगों का एक समूह है जो फेलओवर के लिए हमारा (Dyn) इस्तेमाल करते हैं। यही कारण है कि साइटें या तो स्टेटस पेज कर सकती हैं, जब उनका डाउनटाइम होता है (ट्विटर की फेल व्हेल जैसी चीजों के बारे में सोचें) ... या बस टीटीएल पर आधारित ट्रैफिक को रीरूट करें। कुछ लोग सोच सकते हैं कि DNS फेलओवर यहूदी बस्ती है ... लेकिन हमने शुरुआत से ही अपने नेटवर्क को फेलओवर के साथ डिजाइन किया है ... ताकि यह हार्डवेयर के साथ-साथ काम भी करे। मुझे यकीन नहीं है कि डीएमई यह कैसे करता है, लेकिन हमारे पास हमारे निकटतम निकटतम पॉसपॉन्ड के 17 में से 3 हैं जो आपके सर्वर को निकटतम स्थान से मॉनिटर करते हैं। जब यह तीन में से दो से पता चलता है कि यह नीचे है, हम बस दूसरे आईपी के लिए यातायात को फिर से जोड़ते हैं। केवल डाउनटाइम उन लोगों के लिए है जो उस टीटीएल अंतराल के शेष के लिए अनुरोध पर थे।

कुछ लोग एक ही बार में दोनों सर्वरों का उपयोग करना पसंद करते हैं ... और उस स्थिति में एक राउंड रॉबिन लोड बैलेंसिंग ... या जियो आधारित लोड संतुलन जैसे कुछ कर सकते हैं। उन लोगों के लिए जो वास्तव में प्रदर्शन के बारे में परवाह करते हैं ... हमारे वास्तविक समय ट्रैफ़िक प्रबंधक प्रत्येक सर्वर की निगरानी करेंगे ... और यदि कोई धीमा है ... तो अपने होस्टनाम में लिंक किए गए आईपी के आधार पर सबसे तेज़ ट्रैफ़िक को फिर से चलाएँ। फिर से ... यह हमारे यूआई / एपीआई / पोर्टल में आपके द्वारा डाले गए मूल्यों के आधार पर काम करता है।

मुझे लगता है कि मेरी बात यह है ... हम उद्देश्य पर असफल dns इंजीनियर। जबकि मूल रूप से बनाए जाने के दौरान DNS को फेलओवर के लिए नहीं बनाया गया था ... हमारे DNS नेटवर्क को इसे गेट गो से लागू करने के लिए डिज़ाइन किया गया था। यह आमतौर पर हार्डवेयर के रूप में प्रभावी हो सकता है..जबकि मूल्यह्रास या हार्डवेयर की लागत। आशा है कि मुझे राज में प्लग करने के लिए ध्वनि की कमी नहीं है ... बहुत सारी अन्य कंपनियां हैं जो ऐसा करती हैं ... मैं सिर्फ हमारी टीम के दृष्टिकोण से बोल रहा हूं। उम्मीद है की यह मदद करेगा...

Comments

"हार्डवेयर के समान प्रभावी हो सकता है" से आपका क्या अभिप्राय है? DNS रूटिंग किस तरह का हार्डवेयर है?

— मपेन २

@ रेयान, जब आप "यहूदी बस्ती" कहते हैं, तो आपका क्या मतलब है?

— पचेरियर

उस शब्द के लिए शहरी शब्दकोश सकारात्मक अर्थ के साथ कोई परिभाषा नहीं देता है, मैं मानता हूं कि "एक भिखारी का समाधान" एक उपयुक्त अनुवाद हो सकता है।

— जसन

Answer 7

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

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

Comments

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

— मार्को डेमायो

Answer 8

विकल्प एक BGP आधारित विफलता प्रणाली है। इसे स्थापित करना आसान नहीं है, लेकिन यह बुलेट प्रूफ होना चाहिए। साइट ए को एक स्थान पर सेट करें, एक स्थानीय बी पते के साथ दूसरी जगह साइट बी, फिर एक वर्ग सी या आईपी के अन्य ब्लॉक प्राप्त करें जो पोर्टेबल हैं और पोर्टेबल आईपी से स्थानीय आईपी के लिए पुनर्निर्देशन स्थापित करें।

नुकसान होते हैं, लेकिन यदि आपको नियंत्रण के उस स्तर की आवश्यकता है तो यह DNS आधारित समाधानों से बेहतर है।

Comments

हालांकि BGP आधारित समाधान सभी के लिए उपलब्ध नहीं हैं। और DNS के मुकाबले विशेष रूप से भयानक तरीके से तोड़ना बहुत आसान है। स्विंग और राउंडअबाउट, मुझे लगता है।

— सियान

Answer 9

मल्टी डेटा-सेंटर फेलओवर का एक विकल्प अपने उपयोगकर्ताओं को प्रशिक्षित करना है। हम अपने ग्राहकों को विज्ञापन देते हैं कि हम कई शहरों में और अपने साइनअप ईमेल में कई सर्वर प्रदान करते हैं और इसमें प्रत्येक "सर्वर" से सीधे लिंक शामिल होते हैं ताकि उपयोगकर्ताओं को पता चल सके कि एक सर्वर डाउन है तो वे दूसरे सर्वर से लिंक का उपयोग कर सकते हैं।

यह केवल कई डोमेन नामों को बनाए रखने के द्वारा DNS विफलता का मुद्दा पूरी तरह से बायपास करता है। जो उपयोगकर्ता www.company.com या company.com पर जाते हैं और लॉग इन करते हैं, उन्हें server1.company.com या server2.company.com पर निर्देशित किया जाता है और यदि वे नोटिस करते हैं कि उनमें से किसी एक या दूसरे का उपयोग करके बेहतर प्रदर्शन प्राप्त करने का विकल्प है। । यदि कोई नीचे जाता है तो उपयोगकर्ताओं को दूसरे सर्वर पर जाने के लिए प्रशिक्षित किया जाता है।

Comments

अपने उपयोगकर्ताओं को इस तरह से प्रशिक्षित करना ... क्या यह उन्हें फ़िश होने के लिए अधिक उत्तरदायी नहीं बनाता है?

— पचेरियर

Answer 10

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

मैंने पाया है कि स्थानीय (LAN आधारित) लोड संतुलन, GSLB और क्लाउड आधारित ज़ोन होस्टिंग का संयोजन DNS लोड बैलेंसिंग से जुड़े कुछ मुद्दों को बंद करने के लिए काफी अच्छी तरह से काम कर रहा है।

Answer 11

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

यदि आप अपटाइम पर असीमित बजट के साथ एक बहुराष्ट्रीय निगम हैं, तो हाँ, हार्डवेयर जीएसएलबी लोड बैलेंसर्स और टियर 1 डेटासेंटर महान है, लेकिन आपके DNS को अभी भी तेज और रॉक सॉलिड होने की आवश्यकता है। जैसा कि आप में से बहुत से लोग जानते हैं, DNS डोमेन नाम के अलावा अन्य किसी भी बुनियादी ढाँचे का एक महत्वपूर्ण पहलू है, यह सबसे निम्न स्तर की सेवा है जो आपकी ऑनलाइन उपस्थिति के हर दूसरे हिस्से पर सवारी करती है। एक ठोस डोमेन रजिस्ट्रार के साथ शुरू करना, DNS सिर्फ उतना ही महत्वपूर्ण है जितना कि आपके डोमेन को समाप्त होने देना। DNS नीचे जाता है, इसका मतलब है कि आपके संगठन का पूरा ऑनलाइन पहलू भी नीचे है!

डीएनएस फेलओवर का उपयोग करते समय, अन्य महत्वपूर्ण पहलू सर्वर मॉनिटरिंग (हमेशा कई जियो स्थानों से जांच करने के लिए और हमेशा एकाधिक (कम से कम 3) झूठी सकारात्मकता से बचने के लिए जाँच होनी चाहिए) और डीएनएस रिकॉर्ड को ठीक से प्रबंधित करने में विफलता का पता चलता है। कम टीटीएल और फेलओवर के साथ कुछ विकल्प इसे एक सहज प्रक्रिया बना सकते हैं, और यदि आप एक sys व्यवस्थापक हैं, तो रात के मध्य में एक पेजर तक जागने से बिल्ली को पीटता है।

कुल मिलाकर, DNS फेलओवर वास्तव में काम करता है और बहुत सस्ती हो सकती है। हमसे या अधिकांश प्रबंधित DNS प्रदाताओं से अधिकांश मामलों में आपको हार्डवेयर विकल्पों की लागत के एक अंश के लिए सर्वर मॉनिटरिंग और विफलता के साथ-साथ Anycast DNS मिलेगा।

तो असली जवाब हां है, यह काम करता है, लेकिन क्या यह हर किसी और हर बजट के लिए है? शायद नहीं, लेकिन जब तक आप इसे आज़माते हैं और अपने लिए परीक्षण करते हैं, तब तक इसे अनदेखा करना मुश्किल है, अगर आप एक सीमित आईटी बजट के साथ एक छोटे से मध्यम व्यवसाय के लिए हैं, जो सबसे अच्छा समय चाहता है।

Answer 12

"और आप अपने उत्पादन के अधिकांश वातावरण के लिए इसका उपयोग क्यों कर रहे हैं (हालांकि यह कुछ भी नहीं से बेहतर है)।"

वास्तव में, "कुछ नहीं से बेहतर" बेहतर रूप से "एकमात्र विकल्प" के रूप में व्यक्त किया जाता है, जब प्रस्तुतियाँ भौगोलिक रूप से विविध होती हैं। हार्डवेयर लोड बैलेंसर उपस्थिति के एक बिंदु के लिए महान हैं, लेकिन उपस्थिति का एक बिंदु भी विफलता का एकल बिंदु है।

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

डीएनएस आधारित फेलओवर एक निश्चित मात्रा में विलंबता से ग्रस्त है। इसके आसपास कोई रास्ता नहीं है। लेकिन, बहु-पॉप परिदृश्य में फेलओवर प्रबंधन के लिए यह अभी भी एकमात्र व्यवहार्य दृष्टिकोण है। एकमात्र विकल्प के रूप में, यह "कुछ नहीं से बेहतर" से कहीं अधिक है।

Answer 13

आज अच्छे वैश्विक लोड बैलेंसर्स जो उस टेक्निक का उपयोग करके काम करते हैं और बहुत अच्छी तरह से काम करते हैं। उदाहरण के लिए जाँच करें Azure ट्रैफ़िक मैनेजर https://azure.microsoft.com/en-us/services/traffic-manager/

Answer 14

यदि आप अधिक जानकारी प्राप्त करना चाहते हैं, तो एप्लिकेशन नोट्स को यहां पढ़ें

http://edgedirector.com

वे कवर करते हैं: विफलता, वैश्विक भार संतुलन, और संबंधित मामलों का एक मेजबान।

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

संक्षिप्त उत्तर: यह काम करता है, लेकिन आपको सीमाओं को समझना होगा।

Answer 15

मेरा मानना ​​है कि फेलओवर के विचार का उद्देश्य क्लस्टरिंग था, लेकिन क्योंकि यह एकल को भी चला सकता था, फिर भी एक-से-एक उपलब्धता में इसे संचालित करना संभव हो गया।

Answer 16

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

एक अन्य विकल्प, आपके पर्यावरण पर निर्भर करता है, अपनी अतिरेक जरूरतों को पूरा करने के लिए IPSLA, PBR और FHRP के साथ संयोजन का उपयोग करना है।

Comments

"यह वास्तव में संभावना नहीं है कि ईसी 2, या एचपी, या आईबीएम नीचे जाएंगे" - इस "संभावनाहीन" चीज ने हमें कई बार काट लिया है। सब फेल।

— टेलोंक्स

यदि ऐसा होता तो "संभावनाहीन" लोग असफल नहीं होते यहां फेलओवर सिस्टम की मांग करते हैं।

— मार्को डेमायो