सवाल DNS विफलता क्यों अनुशंसित नहीं है?


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

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


166
2017-08-30 17:57


मूल


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


जवाब:


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

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

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

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

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

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


93
2017-08-30 18:39



मुझे लगता है कि वह विशेष रूप से दो अलग-अलग डेटा केंद्रों (विभिन्न सबनेट्स के बारे में टिप्पणियों को नोट करने) के बीच विफलता का प्रबंधन करने की कोशिश कर रहा है, इसलिए सर्वर को लोड / बैलेंसर्स / अतिरिक्त अनावश्यकता का उपयोग करने से उसकी मदद नहीं होगी (अनावश्यक डेटा केंद्रों के अलावा। लेकिन आप अभी भी इंटरनेट पर बताने की जरूरत है जो अभी भी ऊपर है)। - Cian
बहु-डेटासेंटर सेटअप में कोई भी कोड जोड़ें और यह डेटासेंटर-विफलता प्रमाण बन जाता है। - petrus
किसी भी वस्तु पर विकिपीडिया प्रविष्टि (en.wikipedia.org/wiki/Anycast) DNS रूट सर्वर लचीलापन के संबंध में इस पर चर्चा करता है। - dunxd
डीडीओएस हमले इतने आम हैं कि अब पूरे डेटा सेंटर ऑफलाइन लाए जा सकते हैं (लिनोड लंदन और उनके अन्य डाटासेंटर दिसंबर 2015 से हुआ)। तो एक ही प्रदाता का उपयोग, उसी डेटा सेंटर में अनुशंसित नहीं है। इसलिए विभिन्न प्रदाताओं के साथ कई डेटा केंद्र एक अच्छी रणनीति होगी, जो हमें एक बेहतर विकल्प मौजूद होने तक DNS विफलता पर वापस लाता है। - Laurence Cope
ऐसा क्यों नहीं है कि एक विफलता मौजूद है, क्योंकि जब डिवाइस कम / दोषपूर्ण होता है तो आपको अपनी साइट को लाइव रखने की आवश्यकता होती है? आपका असफलता तब भी अच्छा होगा जब यह उसी नेटवर्क में समान डिवाइस साझा कर रहा हो। रूटर? - user2128576


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

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

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


44
2017-10-20 17:17



सियान का जवाब serverfault.com/a/60562/87017 सीधे आपके विरोधाभास ..... तो कौन सही है? - Pacerier
यह मेरा अनुभव है कि छोटे टीटीएल इंटरनेट पर काम नहीं करते हैं। हो सकता है कि आप DNS सर्वर चला रहे हों जो आरएफसी का सम्मान करते हैं - लेकिन वहां बहुत से सर्वर हैं जो नहीं करते हैं। कृपया यह न मानें कि यह राउंड रॉबिन डीएनएस के खिलाफ एक तर्क है - नीचे भी vmiazzo का जवाब देखें - मैंने आरआर DNS का उपयोग करके व्यस्त साइटों को चलाया है और इसका परीक्षण किया है - यह काम करता है। मुझे सामना करने वाली एकमात्र समस्याएं कुछ जावा आधारित क्लाइंट्स (ब्राउज़र नहीं) के साथ थीं, जो विफलता पर फिर से कनेक्ट करने का प्रयास नहीं करती थीं अकेले चक्रों को आरएसटी पर होस्ट की सूची - symcbean
मैं उन लोगों पर शर्त लगाता हूं जो निगरानी करते हैं कि डीएनएस फेलओवरो महान है और जो लोग इसे चूसते हैं वे समान अनुभव रखते हैं, लेकिन अलग-अलग उम्मीदों के साथ। DNS विफलता निर्बाध नहीं है, लेकिन यह महत्वपूर्ण डाउनटाइम को रोकता है। यदि आपको पूरी तरह से निर्बाध पहुंच की आवश्यकता है (सर्वर विफलता के दौरान भी एक ही अनुरोध खोना नहीं है), तो आपको शायद अधिक परिष्कृत - और महंगी-वास्तुकला की आवश्यकता होगी। यह कई अनुप्रयोगों के लिए एक आवश्यकता नहीं है। - Tom Wilson


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

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


31
2017-08-30 18:27



+1 धीमा और अविश्वसनीय - Chris S
और देखें serverfault.com/q/315199/87017 - Pacerier


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

वैसे भी,

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

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

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

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

धन्यवाद,

वैलेंटिनो

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


19
2017-09-29 10:06



एकाधिक ए रिकॉर्ड में डिज़ाइन किया गया है, लेकिन विफल होने के बजाए लोड संतुलन के लिए। ग्राहक परिणाम को कैश करेंगे, और रिकॉर्ड बदलने के कुछ मिनटों के लिए पूर्ण पूल (टूटा हुआ आईपी सहित) का उपयोग करना जारी रखें। - Cian
तो, क्या लिखा है crypto.stanford.edu/dns/dns-rebinding.pdf अध्याय 3.1 झूठा? << इंटरनेट एक्सप्लोरर 7 पिन 30 मिनट के लिए DNS बाइंडिंग। दुर्भाग्यवश, यदि हमलावर के डोमेन में एकाधिक ए रिकॉर्ड हैं और वर्तमान सर्वर अनुपलब्ध हो जाता है, तो ब्राउज़र एक सेकंड के भीतर एक अलग आईपी पता आज़माएगा। >> - Valentino Miazzo
यहां मेरे सबवेस्टेशन को हटा दिया serverfault.com/questions/69870/... - Valentino Miazzo


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

यह ठीक काम करता है, लेकिन कम से कम तीन subtleties मैं कठिन तरीका सीखा है।

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

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

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

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

यह सस्ता, अच्छी तरह से परीक्षण किया गया है, और "ज्यादातर काम करता है"। तो ज्यादातर चीजों के साथ, आपका लाभ भिन्न हो सकता है।


11
2018-04-12 01:21



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


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

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

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


9
2018-05-25 19:38



"हार्डवेयर जितना प्रभावी हो सकता है" से आपका क्या मतलब है? DNS राउटिंग किस तरह का हार्डवेयर करता है? - mpen
@ रयान, जब आप "यहूदी" कहते हैं तो आपका क्या मतलब है? - Pacerier
उस शब्द के लिए शहरी शब्दकोश सकारात्मक अर्थ के साथ कोई परिभाषा नहीं देता है, मुझे लगता है कि "एक भिखारी का समाधान" एक उपयुक्त अनुवाद हो सकता है। - Jasen


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

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


5
2017-08-07 05:13



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


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

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


4
2017-08-30 21:40



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


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

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


3
2017-10-11 22:11



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