सवाल एकाधिक डेटा केंद्र और HTTP ट्रैफ़िक: DNS राउंड रॉबिन तत्काल विफलता को आश्वस्त करने का एकमात्र तरीका है?


एक ही डोमेन को इंगित करने वाले एकाधिक ए रिकॉर्ड एक सस्ते लोड संतुलन तकनीक के रूप में DNS राउंड रॉबिन को लागू करने के लिए लगभग विशेष रूप से उपयोग किए जाते हैं।

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

एक लोड बैलेंसर अक्सर बेहतर विकल्प के रूप में सुझाव दिया जाता है।

दोनों दावे पूरी तरह से सच नहीं हैं:

  1. जब यातायात HTTP होता है, तो अधिकांश HTML ब्राउज़र किसी नए DNS लुकअप के बिना, पिछली डाउन डाउन होने पर स्वचालित रूप से अगले ए रिकॉर्ड का प्रयास करने में सक्षम होते हैं। पढ़ना यहां अध्याय 3.1 तथा यहाँ

  2. जब कई डेटा केंद्र शामिल होते हैं, तो DNS आरआर उन पर यातायात वितरित करने का एकमात्र विकल्प है।

तो, क्या यह सच है कि, एकाधिक डेटा केंद्रों और HTTP यातायात के साथ, DNS डेटा आरआर का उपयोग तत्काल विफलता को आश्वस्त करने का एकमात्र तरीका है जब एक डेटा केंद्र नीचे जाता है?

धन्यवाद,

वैलेंटिनो

संपादित करें:

  • बेशक प्रत्येक डेटा सेंटर में हॉट स्पेयर के साथ स्थानीय लोड बैलेंसर होता है।
  • तत्काल विफलता के लिए सत्र एफ़िनिटी बलिदान करना ठीक है।
  • AFAIK एक DNS के लिए डेटा केंद्र का सुझाव देने का एकमात्र तरीका है जो उस डेटा सेंटर से जुड़े आईपी (या आईपी) के साथ जवाब देना है। यदि डेटा सेंटर पहुंच योग्य नहीं है तो उन सभी आईपी भी पहुंच योग्य नहीं हैं। इसका मतलब यह है कि, भले ही स्मार्ट एचटीएमएल ब्राउज़र तुरंत एक और ए रिकॉर्ड करने में सक्षम हों, फिर भी सभी प्रयास विफल हो जाएंगे जब तक कि स्थानीय कैश एंट्री समाप्त नहीं हो जाती है और एक नया DNS लुकअप किया जाता है, नए कामकाजी आईपी लाते हैं (मुझे लगता है कि डीएनएस स्वचालित रूप से एक को सुझाव देता है जब कोई असफल हो तो नया डेटा सेंटर)। तो, "स्मार्ट DNS" तत्काल असफल होने का आश्वासन नहीं दे सकता है।
  • इसके विपरीत एक DNS राउंड-रॉबिन इसे अनुमति देता है। जब एक डेटा केंद्र विफल हो जाता है, तो स्मार्ट HTML ब्राउज़र (उनमें से अधिकतर) तुरंत दूसरे कैश किए गए ए रिकॉर्ड को दूसरे (काम करने वाले) डेटा केंद्र पर कूदने का प्रयास करते हैं। इसलिए, डीएनएस राउंड-रॉबिन सत्र एफ़िनिटी या सबसे कम आरटीटी को आश्वस्त नहीं करता है, लेकिन जब ग्राहक "स्मार्ट" HTML ब्राउज़र होते हैं तो तुरंत विफल होने का आश्वासन देने का एकमात्र तरीका लगता है।

2 संपादित करें:

  • कुछ लोग टीसीपी एनाकास्ट को एक निश्चित समाधान के रूप में सुझाव देते हैं। में इस पेपर (अध्याय 6) समझाया गया है कि एनाकास्ट असफलता बीजीपी अभिसरण से संबंधित है। इस कारण से एनाकास्ट पूरा करने के लिए 15 मिनट से 20 सेकंड तक नियोजित कर सकता है। नेटवर्क पर 20 सेकंड संभव हैं जहां टोपोलॉजी को इसके लिए अनुकूलित किया गया था। शायद सीडीएन ऑपरेटर इतनी तेजी से असफल हो सकते हैं।

संपादित करें 3: *

  • मैंने कुछ DNS लुक-अप और ट्रैसरआउट (शायद कुछ विशेषज्ञ दोबारा जांच कर सकते हैं) और:
    • टीसीपी एनाकास्ट का उपयोग करने वाला एकमात्र सीडीएन कैशफ़्लि, सीडीएन नेटवर्क्स जैसे अन्य ऑपरेटर और बिटग्रैविटी कैशफली का उपयोग करता है। लगता है कि उनके किनारों को रिवर्स प्रॉक्सी के रूप में उपयोग नहीं किया जा सकता है। इसलिए, उन्हें तत्काल विफलता प्रदान करने के लिए उपयोग नहीं किया जा सकता है।
    • अकामाई और लाइमलाइट भू-जागरूक DNS का उपयोग करते हैं। परंतु! वे एकाधिक ए रिकॉर्ड वापस करते हैं। Traceroutes से लगता है कि लौटा आईपी एक ही डेटा केंद्र पर हैं। इसलिए, मैं एक डेटा केंद्र नीचे जाने पर 100% एसएलए की पेशकश कैसे कर सकता हूं इस पर परेशान हूं।

76
2017-09-30 08:44


मूल


उच्च उपलब्धता के साथ मैंने लगभग तुरंत असफल होने का अनुमान लगाया। एक डेटा केंद्र नीचे जाने पर भी ग्राहक को कोई समस्या नहीं दिखाई देनी चाहिए। मैंने सवाल परिष्कृत किया। - Valentino Miazzo
मैक्ससीडीएन किसी भी टीसीपी का उपयोग करता है और इसके किनारों का उपयोग कैशिंग प्रॉक्सी मोड (सीडीएन उद्योग शब्दावली में "मूल लाने") में किया जा सकता है। - rmalayter
@vmiazzo, आपका पीडीएफ लिंक नीचे है ... क्या आपका मतलब 15 मिनट या 20 सेकंड 15 मिनट तक है? - Pacerier


जवाब:


जब मैं "डीएनएस राउंड रॉबिन" शब्द का उपयोग करता हूं तो आम तौर पर "सस्ता भार संतुलन तकनीक" के अर्थ में इसका मतलब है क्योंकि ओपी इसका वर्णन करता है।

लेकिन वैश्विक उच्च उपलब्धता के लिए DNS का उपयोग करने का एकमात्र तरीका यह नहीं है। ज्यादातर समय, अलग-अलग (प्रौद्योगिकी) पृष्ठभूमि वाले लोगों के लिए यह बहुत मुश्किल है कि वे संवाद कर सकें।

सबसे अच्छा लोड संतुलन तकनीक (यदि पैसा कोई समस्या नहीं है) आमतौर पर माना जाता है:

  1. 'बुद्धिमान' DNS सर्वर का कोई भी वैश्विक नेटवर्क,
  2. और वैश्विक स्तर पर डेटासेंटर फैलाने का एक सेट,
  3. जहां प्रत्येक DNS नोड स्प्लिट क्षितिज DNS लागू करता है,
  4. और कुछ फैशन में 'बुद्धिमान' DNS नोड्स के लिए उपलब्धता और यातायात प्रवाह की निगरानी उपलब्ध है,
  5. ताकि उपयोगकर्ता DNS अनुरोध आईपी Anycast के माध्यम से निकटतम DNS सर्वर पर बहता है,
  6. और इस डीएनएस सर्वर एक कम-टीटीएल एक रिकॉर्ड / रिकॉर्ड के लिए एक रिकॉर्ड का हाथ रखता है निकटतम / सर्वोत्तम डाटा सेंटर इस अंत उपयोगकर्ता के लिए 'बुद्धिमान' विभाजित क्षितिज DNS के माध्यम से।

DNS के लिए किसी भीcast का उपयोग करना आम तौर पर ठीक है, क्योंकि DNS प्रतिक्रियाएं स्टेटलेस और लगभग बहुत कम हैं। इसलिए यदि बीजीपी मार्ग बदलते हैं तो यह एक DNS क्वेरी को बाधित करने की अत्यधिक संभावना नहीं है।

Anycast लंबे और राज्यव्यापी HTTP वार्तालापों के लिए कम अनुकूल है, इस प्रकार यह सिस्टम विभाजित क्षितिज DNS का उपयोग करता है। क्लाइंट और सर्वर के बीच एक HTTP सत्र एक डेटासेंटर को रखा जाता है; यह आम तौर पर सत्र तोड़ने के बिना किसी अन्य डेटासेंटर पर असफल नहीं हो सकता है।

जैसा कि मैंने "रिकॉर्ड्स के सेट" के साथ संकेत दिया है, जिसे मैं 'डीएनएस राउंड रॉबिन' कहूंगा, ऊपर दिए गए सेटअप के साथ एक साथ उपयोग किया जा सकता है। यह आम तौर पर प्रत्येक डेटासेंटर में एकाधिक अत्यधिक लोड लोड बैलेंसर्स पर ट्रैफिक लोड फैलाने के लिए उपयोग किया जाता है (ताकि आप बेहतर रिडंडेंसी प्राप्त कर सकें, छोटे / सस्ता लोड बैलेंसर्स का उपयोग कर सकें, एक होस्ट सर्वर सर्वर के यूनिक्स नेटवर्क बफर को जबरदस्त न करें)।

तो, क्या यह सच है कि, कई डेटा केंद्रों के साथ   और HTTP यातायात, DNS आरआर का उपयोग केवल है   उच्च उपलब्धता सुनिश्चित करने के लिए रास्ता?

नहीं, यह सच नहीं है, अगर 'डीएनएस राउंड रॉबिन' से नहीं, तो हम बस एक डोमेन के लिए एकाधिक ए रिकॉर्ड सौंपने का मतलब रखते हैं। लेकिन यह सच है कि किसी भी वैश्विक उच्च उपलब्धता प्रणाली में DNS का चालाक उपयोग एक महत्वपूर्ण घटक है। उपर्युक्त जाने के लिए एक आम (अक्सर सबसे अच्छा) तरीका दिखाता है।

संपादित करें: गूगल पेपर "सीडीएन प्रदर्शन को अनुकूलित करने के लिए एंड-टू-एंड पथ जानकारी से आगे बढ़ना" मुझे लगता है कि मुझे सर्वश्रेष्ठ अंत उपयोगकर्ता प्रदर्शन के लिए वैश्विक लोड वितरण में अत्याधुनिक होना प्रतीत होता है।

2 संपादित करें: मैंने लेख पढ़ा "क्यों DNS आधारित .. जीएसएलबी .. काम नहीं करता" कि ओपी से जुड़ा हुआ है, और यह एक अच्छा अवलोकन है - मैं इसे देखने की सलाह देते हैं। इसे शीर्ष से पढ़ें।

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

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

यह मेरे कदम 1 - 6 से अलग समाधान है। मैं इस पर एक सही उत्तर नहीं दे सकता, मुझे लगता है कि अकामाई या Google की पसंद से एक DNS विशेषज्ञ की आवश्यकता है, क्योंकि इनमें से अधिकतर उबलते हैं व्यावहारिक पता कैसे आज तैनात DNS कैश और ब्राउज़रों की सीमाओं पर। AFAIK, मेरे कदम 1-6 हैं अकामाई अपने DNS के साथ क्या करता है (क्या कोई इसे पुष्टि कर सकता है?)।

मेरी भावना - मोबाइल ब्राउजर पोर्टल (सेल फोन) पर पीएम के रूप में काम करने से आ रही है - यह कि विविधता और स्तर है कुल टूटना वहाँ ब्राउज़र के अविश्वसनीय है। मैं व्यक्तिगत रूप से एक एचए समाधान पर भरोसा नहीं करता जिसके लिए अंतिम उपयोगकर्ता टर्मिनल को 'सही चीज़' करने की आवश्यकता होती है; इस प्रकार मेरा मानना ​​है कि सत्र को तोड़ने के बिना वैश्विक तात्कालिक विफलता आज संभव नहीं है।

मुझे लगता है कि ऊपर दिए गए मेरे चरण 1-6 सबसे अच्छे हैं जो कमोडिटी तकनीक के साथ उपलब्ध हैं। इस समाधान में तत्काल विफल नहीं है।

मैं अकामाई, Google इत्यादि के उन DNS विशेषज्ञों में से एक के लिए प्यार करता हूं और मुझे गलत साबित करता हूं। :-)


34
2017-09-30 10:56



मैंने सवाल में और स्पष्टीकरण जोड़े। अगर मैं आपकी "सर्वश्रेष्ठ लोड संतुलन तकनीक" (बिंदु 6) को समझता हूं, तो यह केवल 'सर्वश्रेष्ठ' डेटा केंद्र के ए रिकॉर्ड का विज्ञापन करता है। जैसा कि मैंने इस प्रश्न में व्याख्या करने की कोशिश की है, यह ग्राहक पर त्वरित विफलता की अनुमति नहीं देता है। - Valentino Miazzo
@vmiazzo: हाँ, तुमने मुझे सही ढंग से समझा। मैं स्पष्टीकरण के लिए अपनी पोस्ट में दूसरा संपादन जोड़ रहा हूं - लेकिन मूल रूप से मुझे लगता है कि तत्काल विफल होने पर आप अव्यवहारिक / असंभव हैं। - Jesper Mortensen
मुझे दिलचस्प लगता है कि किसी ने भी दो दृष्टिकोणों को एक साथ जोड़ने का सुझाव दिया है। आदर्श नहीं होने पर, जब चीजें सही तरीके से काम करती हैं, तो यह उचित गति प्रदान करेगी, और जब वे नहीं करते हैं तो अतिरिक्त लचीलापन होगा। जुर्माना एक बड़ी देरी होगी क्योंकि ग्राहक एक एनाकास्ट-आधारित DNS पते से दूसरे में स्विच किए जाते हैं। - Avery Payne
@ जेस्परमोर्टेन्सन, जब आप 'बुद्धिमान' DNS कहते हैं, तो क्या आपका मतलब विभाजन-क्षितिज DNS है? या आप कुछ और मतलब है (कारकों के आधार पर निर्णय लेना परे स्रोत आईपी)? - Pacerier


आपका सवाल यह है: "क्या DNS राउंड रॉबिन तुरंत विफल होने का आश्वासन देने का एकमात्र तरीका है?"

जवाब है: "डीएनएस राउंड रॉबिन है कभी नहीँ तुरंत असफल होने का आश्वासन देने का सही तरीका "।

(कम से कम अपने आप पर नहीं)

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

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


18
2017-09-30 16:04



प्रश्न पर Anycast विफलता के बारे में कुछ जानकारी जोड़ा गया। असल में टीसीपी एनाकास्ट भी एक आदर्श समाधान नहीं है। - Valentino Miazzo
@vmiazzo फिर टीसीपी Anycast - वास्तव में, इसलिए अस्थिर अस्थिरता के बारे में मेरे जवाब में नोट और यह कैसे टीसीपी को प्रभावित करता है। - Alnitak


तो, क्या यह सच है कि, एकाधिक डेटा केंद्रों और HTTP यातायात के साथ, डीएनएस आरआर का उपयोग उच्च उपलब्धता को आश्वस्त करने का एकमात्र तरीका है?

स्पष्ट रूप से यह एक झूठा दावा है - आपको केवल Google, अकामाई, याहू को देखने के लिए है कि वे राउंड-रॉबिन [*] प्रतिक्रियाओं का उपयोग अपने एकमात्र समाधान के रूप में नहीं कर रहे हैं (कुछ इसे अन्य दृष्टिकोणों के साथ-साथ भाग में भी उपयोग कर सकते हैं ।)

कई संभावित विकल्प हैं, लेकिन यह वास्तव में निर्भर करता है कि आपके द्वारा चुनी गई अन्य सेवाओं / एप्लिकेशन के साथ आपके पास कौन सी अन्य बाधाएं हैं।

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

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

[* मैं "राउंड-रॉबिन" का उपयोग करने जा रहा हूं, क्योंकि DNS शब्दावली में 'आरआर' का अर्थ है "संसाधन रिकॉर्ड"।]


6
2017-09-30 09:47



मैंने जवाब में और स्पष्टीकरण जोड़े। DNS "लोड बैलेंसर्स" IMHO का उपयोग करने के लिए आपका सुझाव तुरंत विफल होने की अनुमति नहीं देता है। बीजीपी के बारे में, क्या आप एनाकास्ट टीसीपी समाधान का उल्लेख करते हैं? - Valentino Miazzo
मैं किसी अन्य पर किसी भी विशेष समाधान का सुझाव नहीं दे रहा हूं - मैं कह रहा हूं कि आपको अपनी समस्या के लिए सही समाधान चुनना होगा (जिसे आपने वास्तव में अपने प्रश्न में नहीं बताया है) और आपकी बाधाएं (डीआईटीटीओ) DNS राउंड-रॉबिन करता है DNS LB से अधिक किसी भी तत्काल विफलता प्रदान न करें, क्योंकि ब्राउज़र को "सही चीज़" करने की गारंटी नहीं है (मुख्य रूप से क्योंकि "सही चीज़" को सख्ती से परिभाषित या निर्धारित नहीं किया जाता है। मुझे विश्वास नहीं है कि पर्याप्त "स्मार्ट एचटीएमएल ब्राउज़र ", अब भी - मैं जेस्पर से सहमत हूं कि वे उन पर भरोसा करने के लिए अपने व्यवहार में बहुत भिन्न हैं।) - jrg
मैं आपकी संदेह को समझता हूं। वैसे भी, जैसा कि आप यहां पढ़ सकते हैं crypto.stanford.edu/dns/dns-rebinding.pdf वर्तमान एचटीएमएल ब्राउज़र में से अधिकांश पहले से ही "स्मार्ट" हैं। - Valentino Miazzo


आपके लिए बहुत अच्छा अवलोकन vmiazzo +1 !! मैं बिल्कुल ठीक हूं जहां आप हैं .. इन सीडीएन ने अपना जादू कैसे किया है।

सीडीएन अपने नेटवर्क को चलाने के तरीके पर मेरा अनुमान है:

  • निकटतम डेटा सेंटर प्राप्त करने के लिए Anycast DNS (जेस्पर मोर्टेंसन द्वारा उल्लिखित) का उपयोग करें
  • वे एक चलाते हैं स्थानीय नेटवर्क जो विभिन्न डेटा सेंटर में फैला है जो उन्हें कुछ करने की अनुमति देता है कार्प विभिन्न मेजबान केंद्रों में अपने मेजबानों पर

या

इस समय समाधान मेरे लिए काम करते हैं: - डीएनएस एकाधिक आईपी वापस, उदाहरण के लिए:

www -> CNAME www1 , www1 A -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1 
www -> CNAME www3 , www3 A -> 123.123.123.1 
                    www3 A -> 8.4.56.7 <--- reverse proxy
  • अमेज़ॅन क्लाउड पर एक रिवर्स प्रॉक्सी पर अंतिम प्रविष्टि बिंदु, जो बुद्धिमानी से उपलब्ध सर्वर पर पास हो जाता है (या रखरखाव पृष्ठ के तहत प्रदान करता है)

रिवर्स प्रॉक्सी अभी भी हिट हो जाता है लेकिन मुख्य रूप से भारी के रूप में भारी है।


5
2017-12-14 08:15



ग्राहकों द्वारा प्राप्त किए जाने वाले कई DNS रिकॉर्ड्स का ऑर्डर जानबूझकर यादृच्छिक रूप से किया जाता है, इसलिए आपकी रिवर्स प्रॉक्सी शायद 1/6 वें समय (1/3 का 1//2) हिट हो रही है। यह 6 ए रिकॉर्ड होने से बेहतर या अलग कैसे है? - ColinM


क्यों आरएफसी 2782 (http, imap, ... जैसी सेवाओं के लिए एमएक्स / प्राथमिकता के रूप में लागू) किसी भी प्रकार के ब्राउज़र में लागू नहीं किया गया है? चीजें आसान होंगी ... मोज़िला में दस साल के लिए खोला गया एक बग है !!! क्योंकि यह वाणिज्यिक लोड-बैलेंसर के उद्योग का अंत होगा ??? मैं इसके बारे में बहुत निराश हूँ।


3
2018-04-16 15:05





2 - आप इसे साथ कर सकते हैं एनीकास्ट का उपयोग करते हुए Quagga

(यहां तक ​​कि अगर कुछ जानकारी है कि एसीकास्ट टीसीपी के साथ बुरा है तो कैशफ़ली जैसे कई बड़ी कंपनियां इसका उपयोग कर रही हैं)


2
2017-09-30 09:08



बिल्कुल, लेकिन आप किराए पर सर्वर के साथ ऐसा नहीं कर सकते हैं, आपको अपने नेटवर्क की आवश्यकता है। - Julien Tartarin
प्रश्न पर Anycast विफलता के बारे में कुछ जानकारी जोड़ा गया। असल में टीसीपी एनाकास्ट भी एक आदर्श समाधान नहीं है। - Valentino Miazzo


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

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

यह बहुत अच्छा काम करता है, और जो लोग दावा करते हैं कि इससे कई समस्याएं होती हैं, वे नहीं जानते कि वे किस बारे में बात कर रहे हैं। यह सिर्फ सही डिजाइन की आवश्यकता है।

विफलता बेकार है। सबसे अच्छा एचए हर समय सभी संसाधनों का उपयोग करता है।

मैं 1 9 86 से एचए के साथ काम कर रहा हूं। मैं फेलओवर सिस्टम बनाने के लिए व्यापक प्रशिक्षण के माध्यम से गया और मैं फेलओवर के सभी प्रशंसक नहीं हूं।

इसके अलावा, आरआर लोड वितरित करने के लिए काम करता है, भले ही सक्रिय रूप से निष्क्रिय रूप से निष्क्रिय हो। हमारे सर्वर लॉग स्पष्ट रूप से प्रत्येक सर्वर पर यातायात के उचित प्रतिशत को दिखाते हैं - कारण के भीतर।


2
2017-07-19 14:34





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

हमारे पास 2 आईएसपी और कई सार्वजनिक सेवाएं हैं और हम इस विधि को 3 साल से उच्च उपलब्धता के लिए सफलतापूर्वक उपयोग कर रहे हैं।


1
2017-09-30 09:19



मैंने सवाल में और स्पष्टीकरण जोड़े। कई HTML ब्राउज़र DNS TTL (DNS पिनिंग) को अनदेखा करते हैं, प्रश्न में जुड़े पेपर को देखें। जब डेटा केंद्र नीचे जाता है तो DNS कॉन्फ़िगरेशन को क्लाइंट पर त्वरित विफलता की अनुमति नहीं देता है। - Valentino Miazzo


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


1
2017-09-30 14:44



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


टीसीपी एनाकास्ट वास्तव में बहुत स्थिर है और कम से कम कैशफ़ली (2002 से), प्रोलैक्सिक और बिटग्रैविटी द्वारा उपयोग किया जाता है। टीसीपी एनाकास्ट पर एक अच्छी प्रस्तुति नैनोग 37 पर की गई थी: http://198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf


1
2018-05-15 06:07





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

तो पूर्ण अनावश्यकता के लिए, यह आवश्यक है। यही कारण है कि Google इसे करता है, या कोई और जो निरंतर सेवा उपलब्धता का आश्वासन देना चाहता है।

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

यदि आपके पास एकाधिक ए रिकॉर्ड सेटअप नहीं हैं, तो आप डाउनटाइम के लिए पूछ रहे हैं ...

लोड विधि संतुलन के लिए इस विधि को स्पष्ट रूप से भरोसा नहीं किया जा सकता है।


-1
2018-06-02 23:39



क्या? एकाधिक एक recoerds विफलता के एक बिंदु को खत्म नहीं करते हैं! यह समस्याओं के लिए पूछ रहा है। यदि आप एकाधिक डेटासेंटर के बीच त्वरित रूप से विफल होना चाहते हैं तो आप एक डेटासेंटर या रूटिंग ट्रिक्स के भीतर वर्चुअल 'फ़्लोटिंग' आईपी का उपयोग करते हैं। - pQd
सिंगल डिवाइस के माध्यम से एकल आईपी के लिए निरंतर आवश्यक नहीं है। - Sandman4