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

78

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

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

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

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

जब ट्रैफ़िक HTTP होता है, तब अधिकांश HTML ब्राउज़र एक पिछले DNS के बिना, नए DNS लुक-अप के बिना, अगले A रिकॉर्ड को स्वचालित रूप से आज़माने में सक्षम होते हैं। अध्याय 3.1 और यहाँ पढ़ें ।
जब कई डेटा सेंटर शामिल होते हैं, तो DNS आरआर उन पर ट्रैफ़िक वितरित करने का एकमात्र विकल्प होता है।

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

धन्यवाद,

वैलेंटिनो

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

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

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

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

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

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

— वैलेंटिनो मियाजो
स्रोत

उच्च उपलब्धता के साथ मैंने लगभग तुरंत असफल होने का अनुमान लगाया। एक डेटा सेंटर के डाउन होने पर भी ग्राहक को किसी भी समस्या पर ध्यान नहीं देना चाहिए। मैंने प्रश्न को परिष्कृत किया।

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

मैक्ससीडीएन किसी भी टीसीपी का उपयोग करता है और इसके किनारों का उपयोग प्रॉक्सी मोड (सीडीएन उद्योग शब्दावली में "मूल लाने") में किया जा सकता है।

— रैलमाइटर

@vmiazzo, आपका pdf लिंक डाउन है ... क्या आपका मतलब 15 मिनट या 20 सेकंड से 15 मिनट है?

— पचेरियर

34

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

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

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

'इंटेलिजेंट' डीएनएस सर्वरों का एक एनास्टैस्ट वैश्विक नेटवर्क,
और विश्व स्तर पर डेटासेंटर का एक सेट फैला,
जहां प्रत्येक डीएनएस नोड स्प्लिट क्षितिज डीएनएस को लागू करता है,
और उपलब्धता और यातायात प्रवाह की निगरानी कुछ फैशन में 'बुद्धिमान' DNS नोड्स के लिए उपलब्ध है,
ताकि उपयोगकर्ता डीएनएस अनुरोध आईपी एनीकास्ट के माध्यम से निकटतम डीएनएस सर्वर में प्रवाहित हो ,
और यह DNS सर्वर 'बुद्धिमान' स्प्लिट क्षितिज DNS के माध्यम से इस अंत उपयोगकर्ता के लिए निकटतम / सर्वश्रेष्ठ डेटासेंटर के लिए एक कम-टीटीएल ए रिकॉर्ड / सेट ऑफ ए रिकॉर्ड्स को सौंपता है ।

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

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

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

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

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

संपादित करें: Google पेपर "सीडीएन परफॉर्मेंस को ऑप्टिमाइज़ करने के लिए एंड-टू-एंड पाथ इनफार्मेशन से आगे बढ़ रहा है" मुझे सबसे अच्छा एंड-यूज़र प्रदर्शन के लिए वैश्विक भार वितरण में अत्याधुनिक लगता है।

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

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

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

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

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

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

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

— जेस्पर मॉर्टेंसन
स्रोत

मैंने प्रश्न में और स्पष्टीकरण जोड़े। यदि मैं आपकी "सर्वश्रेष्ठ लोड संतुलन तकनीक" (बिंदु 6) को समझता हूं, तो यह 'सर्वश्रेष्ठ' डेटा सेंटर के सिर्फ ए रिकॉर्ड को विज्ञापित करता है। जैसा कि मैंने सवाल में यह समझाने की कोशिश की कि यह क्लाइंट पर तत्काल विफल होने की अनुमति नहीं देता है।

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

@vmiazzo: हां, आपने मुझे सही तरीके से समझा। मैं स्पष्ट करने के लिए अपनी पोस्ट में 2-संपादन जोड़ रहा हूं - लेकिन मूल रूप से मुझे लगता है कि तत्काल विफल हो जाना चाहिए कि आप की तलाश अव्यावहारिक / असंभव है।

— जेस्पर मॉर्टेंसन

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

— एवरी पायने

@JesperMortensen, जब आप 'बुद्धिमान' DNS कहते हैं, तो क्या आपका मतलब विभाजन-क्षितिज DNS है? या क्या आपका मतलब कुछ और है ( स्रोत आईपी से परे कारकों के आधार पर निर्णय लेना )?

— पचेरियर

18

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

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

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

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

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

— एल्निटैक
स्रोत

सवाल पर एनीकट फेलओवर के बारे में कुछ जानकारी जोड़ी। मूल रूप से भी TCP Anycast एक सही समाधान नहीं है।

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

@vmiazzo टीसीपी एनीकास्ट - वास्तव में, इसलिए अस्थिरता को नियमित करने के बारे में मेरे जवाब में नोट और यह टीसीपी को कैसे प्रभावित करता है।

— अलनीतक

6

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

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

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

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

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

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

— जेआरजी
स्रोत

मैंने उत्तर में और स्पष्टीकरण जोड़े। DNS "लोड बैलेंसर्स" IMHO का उपयोग करने का आपका सुझाव तत्काल विफल होने की अनुमति नहीं देता है। बीजीपी के बारे में, क्या आप एनीकास्ट टीसीपी समाधान का उल्लेख करते हैं?

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

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

— 22

मुझे आपकी शंका समझ में आती है। वैसे भी, जैसा कि आप यहाँ पढ़ सकते हैं crypto.stanford.edu/dns/dns-rebinding.pdf वर्तमान HTML ब्राउज़र में से अधिकांश पहले से ही "स्मार्ट" हैं।

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

5

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

सीडीएन ने अपना नेटवर्क कैसे चलाया:

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

या

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

फिलहाल मेरे लिए समाधान कार्य निम्नलिखित हैं: - 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

अंतिम प्रवेश बिंदु अमेज़ॅन क्लाउड पर एक रिवर्स प्रॉक्सी को इंगित करता है, जो समझदारी से उपलब्ध सर्वर से गुजरता है (या रखरखाव पृष्ठ के तहत प्रदान करता है)

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

— रयान्टो वाहयुदी
स्रोत

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

— कॉलिनम

3

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

2

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

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

— rkthkr
स्रोत

बिल्कुल, लेकिन आप ऐसा नहीं कर सकते हैं किराए के सर्वर के साथ, आपको अपना नेटवर्क चाहिए।

— जुलिएन टारटारिन

सवाल पर एनीकट फेलओवर के बारे में कुछ जानकारी जोड़ी। मूल रूप से भी TCP Anycast एक सही समाधान नहीं है।

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

2

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

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

यह महान काम करता है, और जो लोग दावा करते हैं कि यह बहुत सारी समस्याओं का कारण बनता है उन्हें नहीं पता कि वे किस बारे में बात कर रहे हैं। इसके लिए सिर्फ सही डिजाइन की जरूरत होती है।

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

मैं 1986 से HA के साथ काम कर रहा हूं। मैंने फेलओवर सिस्टम बनाने के लिए व्यापक प्रशिक्षण लिया और मैं फेलओवर का प्रशंसक नहीं हूं।

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

— बूढ़ा आदमी
स्रोत

1

एक अन्य बहुत ही सरल विकल्प का उपयोग DNS A या CNAME रिकॉर्ड में TTL (आपकी आवश्यकताओं के अनुसार कितना कम निर्भर करता है) का उपयोग करें और इस रिकॉर्ड को अपडेट करें कि किस IP का उपयोग किया जाएगा।

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

— एलजी।
स्रोत

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

— बजे वैलेंटाइनो मियाज़ो सेप

1

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

— Twirrim
स्रोत

2

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

— जेम्सरयन

1

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

-1

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

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

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

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

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

1

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

— pQd

एकल डिवाइस के माध्यम से पारित करने के लिए एकल आईपी के लिए पूर्ण रूप से आवश्यक नहीं है।

— सैंडमैन 4