स्थिर सामग्री को संतुलित करने के लिए क्या राउंड-रॉबिन डीएनएस "काफी अच्छा" है?

Question

हमारे पास http://sstatic.net पर साझा की गई, स्थिर सामग्री का एक सेट है जो हम अपनी वेबसाइटों के बीच सेवा करते हैं । दुर्भाग्य से, यह सामग्री वर्तमान में बिल्कुल संतुलित नहीं है - यह एक एकल सर्वर से सेवा की जाती है। यदि उस सर्वर में समस्याएं हैं, तो सभी साइटें जो इस पर भरोसा करती हैं, प्रभावी रूप से नीचे हैं क्योंकि साझा संसाधन आवश्यक साझा जावास्क्रिप्ट लाइब्रेरी और चित्र हैं।

हम एकल सर्वर निर्भरता से बचने के लिए इस सर्वर पर स्थिर सामग्री को संतुलित करने के तरीके देख रहे हैं।

मुझे पता है कि राउंड-रॉबिन डीएनएस सबसे अच्छा है, एक कम अंत (कुछ भी यहूदी बस्ती कह सकते हैं ) समाधान है, लेकिन मैं सोच में मदद नहीं कर सकता - राउंड रॉबिन DNS स्थिर सामग्री के बुनियादी लोड संतुलन के लिए एक "अच्छा पर्याप्त" समाधान है ?

[डीएनएस] [लोड-बैलेंसिंग] टैग में इसकी कुछ चर्चा है , और मैंने इस विषय पर कुछ बेहतरीन पोस्ट पढ़े हैं।

मुझे कई राउंड-रॉबिन ए रिकॉर्ड्स के माध्यम से डीएनएस लोड बैलेंसिंग के सामान्य डाउनसाइड के बारे में पता है:

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

लेकिन, राउंड रॉबिन डीएनएस एक स्टार्टर के रूप में काफी अच्छा है, कुछ भी नहीं से बेहतर है, "जब हम शोध करते हैं और बेहतर विकल्प लागू करते हैं" हमारी स्थैतिक सामग्री के लिए लोड संतुलन का रूप? या DNS राउंड रॉबिन किसी भी परिस्थिति में बहुत बेकार है?

Comments

एक विकल्प नहीं है?

— होईकेम्प

जैसा कि मैंने पोस्ट में कहा, यह इस समाधान के बारे में एक विशिष्ट प्रश्न है - क्या हम विषय पर बने रह सकते हैं?

— जेफ एटवुड

लोड-बैलेंसिंग ( en.wikipedia.org/wiki/Load_balancing_%28computing%29 ) बहुत अलग है तो अतिरेक ( en.wikipedia.org/wiki/Redundancy_%28engineering_29 )। जैसा कि जेफ ने अपने शुरुआती पैराग्राफ में कहा, वह असफलता (अतिरेक) के एकल बिंदु को हटाने के साधन की तलाश में है, न कि वास्तविक भार-संतुलन के लिए। क्या कोई फिर से कर सकता है?

— antony.trupe

@ जफ - बिल्कुल, एक गूंगा लोड बैलेंसर (जो सादे गोल रॉबिन डीएनएस है) अतिरेक नहीं करता है। यदि आप कई साइटों पर संतुलन / अतिरेक के बारे में बात कर रहे हैं तो यह और भी कठिन है।

— अलनीतक

@symcbean मैं RFC 2119 में प्रलेखित शब्दावली शब्दों से पूरी तरह परिचित हूं। आपने कहा कि DNS सर्वर वरीयता सूची को परिभाषित करता है। जब तक आपके पास "वरीयता सूचियों" की कुछ विशेष रूप से विषम परिभाषा नहीं होती है जो कि बस सच नहीं है।

— अलनीतक

Answer 1

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

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

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

आपने पूछा "क्या होगा अगर एक हाइप्रोफाइल मशीन विफल हो जाए?"। यह ऐसा ही है। मैं सभी लोगों को जानता हूं जो लोड संतुलन और उच्च उपलब्धता के लिए हाइप्रोक्स का उपयोग करते हैं, उनकी दो मशीनें हैं और उन पर ucarp, Keepalived या heartbeat चलाने के लिए सुनिश्चित करें कि उनमें से एक हमेशा उपलब्ध है।

यह मदद करता है उम्मीद!

Comments

BTW आप एक लेख में दिलचस्पी ले सकते हैं जो मैंने इन अवधारणाओं पर लगभग 4 साल पहले लिखा था: 1wt.eu/articles/2006_lb (पीडीएफ लें, पृष्ठों के माध्यम से HTML पढ़ना उबाऊ है)।

— विली तरारेउ

-1: "फेल-ओवर प्रदान नहीं करता है" - हाँ यह करता है - और यह इसे केवल उसी स्थान पर लागू करता है जहाँ गैर-उपलब्धता को मज़बूती से निर्धारित किया जा सकता है - क्लाइंट पर।

— सिम्बियन

हर्गिज नहीं। यह काम करेगा अगर DNS ने कैश का उपयोग नहीं किया, लेकिन यह मामला नहीं है और क्लाइंट कैश को ताज़ा करने के लिए मजबूर नहीं कर सकते हैं। किसी भी व्यक्ति से बात करें जो नियमित रूप से DNS प्रविष्टियों को स्विच करता है और वे आपको बताएंगे कि आखिरकार वे 5 मिनट में 80% स्विच का निरीक्षण करते हैं, आमतौर पर 100% के करीब पहुंचने में एक सप्ताह से अधिक समय लगता है। इसलिए DNS फेल-ओवर प्रदान नहीं करता है।

— विली तरारेउ

"अतिरेक के बिना लोड संतुलन" का एक सरल उदाहरण RAID0 है।

— डकैती

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

— यवन

Answer 2

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

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

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

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

यदि एक सर्वर की विफलता की संभावना N है, तो दो सर्वरों के साथ आपकी संभावना 2N है। स्वचालित, तेज़ विफलता के बिना , यह योजना इस संभावना को बढ़ाती है कि आपके कुछ उपयोगकर्ता विफलता का अनुभव करेंगे।

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

Comments

पूरी तरह से बंद विषय, लेकिन हम भी कई HAProxy उदाहरणों की जरूरत की समस्या है पर विफल करने के लिए - क्या अगर HAProxy मशीन विफल रहता है? भविष्य के सवालों का विषय, हालांकि, इस एक के लिए विषय से वास्तव में दूर।

— जेफ एटवुड

+1 - "स्वचालित तरीके से ... यह यहूदी बस्ती विफल हो जाता है। मैन्युअल रूप से यह भी नहीं है।" बड़े बोल्ड अक्षरों में होना चाहिए। DNS राउंड-रॉबिन एक दायित्व बन जाता है यदि आप मशीनों की निगरानी नहीं कर रहे हैं और असफल होने पर उन्हें DNS से ​​निकाल रहे हैं, और ऐसा करने का एकमात्र उचित तरीका एक स्वचालित समाधान के साथ है। DNS राउंड-रॉबिन की तुलना में बहुत बेहतर समाधान हैं।

— इवान एंडरसन

पूरी तरह से सहमत हैं, लेकिन आपके 20% ग्राहक आपको शिकायतों के साथ बुला रहे हैं , उनमें से 100% शिकायतों के साथ कॉल करना बेहतर है ..

— जेफ एटवुड

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

— हेलविक

The best part of true failover is getting to sleep through the night.यह एक स्पष्ट परिभाषा है!

— बेसिल बॉर्क

Answer 3

राउंड रॉबिन डीएनएस वह नहीं है जो लोग सोचते हैं कि यह है। DNS सर्वर सॉफ़्टवेयर के लेखक के रूप में (जैसे, BIND ) हमें ऐसे उपयोगकर्ता मिलते हैं जो आश्चर्यचकित होते हैं कि उनका राउंड रॉबिन योजना के अनुसार काम करना क्यों बंद कर देता है। वे यह नहीं समझते हैं कि 0 सेकंड के TTL के साथ भी कुछ कैशिंग की राशि होगी, क्योंकि कुछ कैश में न्यूनतम समय (अक्सर 30-300 सेकंड) होता है, चाहे जो भी हो।

इसके अलावा, जब आपके AUTH सर्वर राउंड रॉबिन कर सकते हैं, तो इस बात की कोई गारंटी नहीं है कि आप जिन लोगों की परवाह करते हैं - आपके उपयोगकर्ता जो कैशे बोलते हैं - वे करेंगे। संक्षेप में, राउंड रॉबिन क्लाइंट के दृष्टिकोण से किसी भी ऑर्डरिंग की गारंटी नहीं देता है, केवल आपके ऑक्टोर सर्वर कैश को क्या प्रदान करते हैं।

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

Comments

और कुछ DNS सर्वर (या कंट्रोल पैनल) आपको 7200 का एक टीटीएल देने के लिए कॉन्फ़िगर किए गए हैं, भले ही आपने इसे सेट किया हो - कुछ बड़ी होस्टिंग कंपनियां इस IIRC को करती हैं।

— gbjbaanb

Answer 4

मैंने पहले भी कई बार कहा है, और मैं इसे फिर से कहूंगा - यदि समाधान समस्या है, तो डीएनएस ट्रिक्स का जवाब नहीं है ।

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

इसलिए मौलिक नियम यह है कि सच्चे लचीलेपन के लिए आईपी मार्ग स्तर की प्रवंचना की आवश्यकता होती है । लोड-बैलेंसर उपकरण, या ओएसपीएफ "समान लागत बहु-पथ", या यहां तक ​​कि वीआरआरपी का उपयोग करें।

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

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

Answer 5

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

BTW: मैं साधारण लोड वितरण समाधान के रूप में DNS राउंड रॉबिन को अधिक देखता हूं।

Comments

उफ़, मेरा पोस्ट करने से पहले आपका जवाब नहीं देखा, इसलिए आप पर +1 ताकि सच्चाई सामने आए!

— यवन

Answer 6

मुझे इस धागे के लिए देर हो चुकी है, इसलिए मेरा जवाब शायद सबसे नीचे अकेला हो जाएगा, उपेक्षित, सूंघ सूंघ।

सबसे पहले, सवाल का सही जवाब सवाल का जवाब देना नहीं है, बल्कि यह कहना है:

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

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

सवाल

राउंड रॉबिन डीएनएस एक स्टार्टर के रूप में काफी अच्छा है, कुछ भी नहीं से बेहतर है, "जब हम शोध करते हैं और बेहतर विकल्प लागू करते हैं" हमारे स्थिर सामग्री के लिए लोड संतुलन का रूप?

के बीच, कहते हैं, 2 या 3 स्थिर वेब सर्वर? हां, यह कुछ भी नहीं से बेहतर है, क्योंकि DNS प्रदाता हैं जो DNS राउंड रॉबिन को सर्वर स्वास्थ्य जांच के साथ एकीकृत करेंगे , और अस्थायी रूप से डीएनएस रिकॉर्ड से मृत सर्वरों को हटा देंगे। तो इस तरह से आपको सभ्य भार वितरण और कुछ उच्च उपलब्धता मिलती है ; और इसे स्थापित करने में 5 मिनट से भी कम समय लगता है।

लेकिन इस धागे में दूसरों द्वारा उल्लिखित केव्स लागू होते हैं:

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

अन्य उपाय

HAProxy शानदार है, लेकिन चूंकि स्टैक ओवरफ्लो Microsoft प्रौद्योगिकी स्टैक पर है, शायद Microsoft लोड संतुलन और उच्च उपलब्धता टूल का उपयोग करने से कम व्यवस्थापक ओवरहेड होगा। नेटवर्क लोड संतुलन समस्या के एक हिस्से का ख्याल रखता है, और Microsoft के पास वास्तव में एक L7 HTTP रिवर्स प्रॉक्सी / लोड बैलेंसर है।

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

Answer 7

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

1) राउंड रॉबिन के लिए उपयोग किए जाने वाले DNS रिकॉर्ड्स पर TTL कम होना चाहिए - लेकिन शून्य नहीं। टीटीएल को शून्य पर रखने से मुख्य रास्ता टूट जाता है जो लचीलापन प्रदान करता है।

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

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

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

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

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

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

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

DNS राउंड रॉबिन में दो उत्कृष्ट विशेषता है जो इसे बहुत व्यापक परिदृश्यों में प्रभावी बनाता है - सबसे पहले यह मुफ़्त है, और दूसरी बात यह है कि यह लगभग भौगोलिक रूप से आपके क्लाइंट बेस के रूप में फैला हुआ है।

यह एक नई 'विफलता की इकाई' का परिचय नहीं देता है जो अन्य सभी 'चतुर' सिस्टम करते हैं। ऐसे कोई घटक नहीं हैं जो अंतर-जुड़े तत्वों के पूरे भार पर एक सामान्य और एक साथ विफलता का अनुभव कर सकते हैं।

'चतुर' सिस्टम महान हैं और एक सहज संतुलन बनाने और तंत्र पर विफल होने के लिए समन्वय करने और प्रदान करने के लिए अद्भुत तंत्र का परिचय देते हैं, लेकिन अंततः बहुत ही आसान तरीके जो वे सहज ज्ञान प्रदान करने के लिए उपयोग करते हैं, वे हैं अकिलीस एड़ी - अतिरिक्त जटिल चीज जो गलत हो सकती है, और जब यह होता है, तो विफलता प्रणाली का एक सहज अनुभव प्रदान करेगा।

तो हाँ, DNS राउंड रॉबिन निश्चित रूप से आपके पहले चरण के लिए एक ही स्थान पर आपके सभी स्थिर सामग्री को होस्ट करने से परे "अच्छा पर्याप्त" है।

Comments

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

— पुरानी फिजियो

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

— यवन

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

— जेरेम बी

Answer 8

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

इसलिए, यदि आपके पास विस्टा, विंडोज 7 और विंडोज 2008 उपयोगकर्ताओं की महत्वपूर्ण संख्या है, तो आप अपने ersatz लोड बैलेंसिंग समाधान में अपनी नियोजित सोच के प्रति असंगत व्यवहार को खोजने जा रहे हैं।

Comments

आह, धन्यवाद, उत्कृष्ट, मैं इस लिंक की तलाश में था - मैंने इस बारे में सुना था लेकिन संदर्भ नहीं मिल सका!

— जेफ एटवुड

Answer 9

मैंने हमेशा लोड-बैलेंसर के रूप में लंबे टीटीएल के साथ राउंड-रॉबिन डीएनएस का उपयोग किया है। यह ब्राउज़रों के साथ HTTP / HTTPS सेवाओं के लिए वास्तव में ठीक काम करता है ।

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

जब ब्राउज़र को एक सर्वर से उत्तर नहीं मिलता है, तो यह स्वचालित रूप से अगले आईपी को कॉल करेगा, और फिर इसके साथ चिपकेगा (जब तक यह नीचे नहीं है ... और फिर एक और कोशिश करता है)।

2007 में वापस, मैंने निम्नलिखित परीक्षण किया है:

• मेरी वेबसाइट पर एक iframe जोड़ें, जैसे कि एक राउंड-रॉबिन प्रविष्टि की ओर इशारा करते हुए http://roundrobin.test:10080/ping.php
• पृष्ठ को 3 PHP सॉकेट द्वारा परोसा गया, 3 अंतर IP पर सुनकर, सभी पोर्ट 10080 पर (मैं पोर्ट 80 पर परीक्षण नहीं कर सकता था, क्योंकि मेरी वेबसाइट उस पर चल रही थी)
• एक सॉकेट ( ए कहो ) यह जांचने के लिए था कि ब्राउज़र 10080 पोर्ट पर कनेक्ट हो सकता है (क्योंकि कई कंपनियां केवल मानक पोर्ट की अनुमति देती हैं)
• अन्य दो सॉकेट ( बी और सी कहते हैं ) को मक्खी पर सक्षम या अक्षम किया जा सकता है।

मैंने इसे एक घंटा चलने दिया, बहुत सारा डेटा था। परिणाम यह था कि सॉकेट ए पर हिट के 99.5% के लिए , मैं सॉकेट बी या सी पर हिट था (मैं एक ही समय में इन दोनों को अक्षम नहीं करता था, निश्चित रूप से)। ब्राउज़र्स थे: iPhone, क्रोम, ओपेरा, MSIE 6/7/8, ब्लैकबेरी, फ़ायरफ़ॉक्स 3 / 3.5 ... तो यह भी नहीं कि-संगत ब्राउज़र इसे सही तरीके से संभाल रहे थे!

आज तक, मैंने इसे फिर से कभी नहीं परखा, लेकिन शायद मैं एक दिन एक नया परीक्षण स्थापित करूंगा या जीथब पर कोड जारी कर दूंगा ताकि अन्य इसका परीक्षण कर सकें।

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

इसलिए यदि आप ब्राउज़रों के साथ काम कर रहे हैं, तो राउंड-रॉबिन डीएनएस का उपयोग करें, या तो स्थिर या गतिशील सामग्री के लिए, आप ज्यादातर ठीक रहेंगे। सर्वर एक लेन-देन के बीच में भी नीचे जा सकते हैं, और यहां तक ​​कि सबसे अच्छे लोड-बैलेंसर के साथ भी आप इस तरह के मामले को संभाल नहीं सकते हैं। गतिशील सामग्री के लिए, आपको अपने सत्र / डेटाबेस / फ़ाइलों को समकालिक बनाना होगा, अन्यथा आप इसे संभाल नहीं पाएंगे (लेकिन यह वास्तविक लोड-बैलेंसर के साथ भी सही है)।

अतिरिक्त नोट: आप अपने स्वयं के आईपी का उपयोग करके व्यवहार का परीक्षण कर सकते हैं iptables। उदाहरण के लिए, HTTP ट्रैफ़िक के लिए अपने फ़ायरवॉल नियम से पहले, जोड़ें:

iptables -A INPUT -p tcp --dport 80 --source 12.34.56.78 -j REJECT

( 12.34.56.78जाहिर तौर पर आपका आईपी कहां है)

उपयोग न करें DROP, क्योंकि यह फ़िल्टर किए गए पोर्ट को छोड़ देता है , और आपका ब्राउज़र टाइमआउट तक इंतजार करेगा। तो अब, आप एक सर्वर या दूसरे को सक्षम या अक्षम कर सकते हैं। सबसे स्पष्ट परीक्षण सर्वर ए को अक्षम करना है, पृष्ठ को लोड करना है, फिर सर्वर ए को सक्षम करना और सर्वर बी को अक्षम करना है। जब आप पृष्ठ को फिर से लोड करेंगे, तो आपको ब्राउज़र से थोड़ा इंतजार करना होगा, फिर यह सर्वर से लोड होगा एक बार फिर। क्रोम में, आप नेटवर्क पैनल में अनुरोध को देखकर सर्वर के आईपी की पुष्टि कर सकते हैं। के Generalटैब में Headers, आप एक नकली हेडर देखेंगे जिसका नाम है Remote Address:। यह वह आईपी है जहां से आपको जवाब मिला है।

इसलिए, यदि आपको एक सर्वर पर रखरखाव मोड में जाने की आवश्यकता है, तो बस HTTP / HTTPS ट्रैफ़िक को एक iptables REJECTनियम से अक्षम करें , सभी अनुरोध अन्य सर्वर पर जाएंगे (एक छोटे से इंतजार के साथ, उपयोगकर्ताओं के लिए लगभग ध्यान देने योग्य नहीं)।

Answer 10

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

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

Comments

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

— gbjbaanb

yeap मुझे पता है कि NLB क्या करता है। मैं DNS आरआर पर सिफारिश कर रहा हूं क्योंकि सर्वर की विफलता आधे उपयोगकर्ताओं को अपंग नहीं करेगी।

— इक्वेलवा

@gbjbaanb या दूसरा रास्ता, NLB लेयर में राउंड रॉबिन 2 है। DNS आधारित राउंड रॉबिन (या निर्भर करता है) लेयर 7 पर है

— Alnitak

Answer 11

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

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

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

आपके पास S3 में डुप्लिकेट स्टैटिक कंटेंट के साथ सिंगल सर्वर भी हो सकता है और जब आपका प्राइमरी डाउन हो जाता है तो S3 CNAME पर स्विच कर सकते हैं। आप एक ही देरी से कई सर्वर लागत के बिना समाप्त कर देंगे।

Answer 12

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

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

मुझे यकीन है कि मैं 100% हा समाधान का प्रचार नहीं कर रहा हूं, लेकिन मैं मतदान करूंगा, लेकिन यह वह नहीं है जो आपने पूछा था। यह एक समाधान बनाम प्रयास के रूप में आप जो स्वीकार करने को तैयार हैं, वह नीचे आता है।

Answer 13

यदि आप लोड संतुलन के लिए आरआर डीएनएस का उपयोग कर रहे हैं, तो यह ठीक होगा, लेकिन आप नहीं हैं। आप इसका उपयोग अनावश्यक सर्वर को सक्षम करने के लिए कर रहे हैं, जिस स्थिति में यह ठीक नहीं है।

जैसा कि पिछले पोस्ट में कहा गया था, आपको दिल की धड़कन का पता लगाने और इसे तब तक रोकना होगा जब तक कि यह वापस न आ जाए।

अच्छी खबर दिल की धड़कन वास्तव में सस्ते में उपलब्ध है, या तो स्विच में या विंडोज में।

अन्य ओएस के बारे में पता नहीं है, लेकिन मुझे लगता है कि यह वहाँ भी है।

Answer 14

मेरा सुझाव है कि आप अपने प्रत्येक सर्वर (आपके द्वारा उपयोग किए जाने वाले स्थिर IP के अलावा, कहते हैं, ssh) के लिए एक अतिरिक्त IP पता प्रदान करते हैं, और आप इसे DNS पूल में ले जाते हैं। और फिर आप सर्वर के विफल होने की स्थिति में इन IP पतों को बदलने के लिए कुछ सॉफ़्टवेयर का उपयोग करते हैं। उदाहरण के लिए, दिल की धड़कन या CARP ऐसा कर सकते हैं, लेकिन वहाँ अन्य समाधान हैं।

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

Answer 15

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

हालांकि, इस तरह के समाधान में कुछ छोटे मुद्दे होंगे। लोड संतुलन कहीं भी एकदम सही नहीं होगा और यदि आप मैन्युअल हस्तक्षेप पर भरोसा कर रहे हैं तो आपके पास कुछ आगंतुकों के लिए आउटेज हो सकते हैं।

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

Answer 16

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

Answer 17

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

नकारात्मक पक्ष: आपको कम से कम 4 सर्वर (2 सर्वर x 2 समूह) की आवश्यकता होती है।

Schof के जवाब पर जेफ की टिप्पणी का जवाब देना, क्या HAProxy सर्वर के बीच DNS राउंड-रॉबिन का एक तरीका है?

Answer 18

इसका बहुत सीमांत उपयोग है, जब तक आप एक वास्तविक समाधान डालते हैं, तब तक आपको प्राप्त करने के लिए पर्याप्त है। जैसा कि आप कहते हैं, TTL को काफी कम सेट करना होगा। हालांकि इसका साइड इफ़ेक्ट है, हालाँकि समस्या होने पर DNS से ​​एक समस्याग्रस्त मशीन को बाहर निकालना। कहते हैं कि आपके पास SvrA, SvrB और SvrC है जो आपकी सामग्री को सौंपते हैं और SvrA नीचे चला जाता है। आप इसे डीएनएस से बाहर निकालते हैं और आपके कम टीटीएल द्वारा परिभाषित छोटी समय अवधि के बाद, रिज़ॉल्वर एक अलग सर्वर (SvrB या SvrC) का पता लगाएंगे जो कि ऊपर हैं। आप SvrA को ऑनलाइन वापस प्राप्त करते हैं और इसे DNS में वापस डालते हैं। कुछ लोगों के लिए एक छोटा डाउनटाइम, दूसरों के लिए कोई नहीं। महान नहीं, लेकिन काम करने योग्य। अधिक स्थिर सर्वर आप मिक्स में डालते हैं कम संभावना है कि आपके पास उपयोगकर्ताओं के बहुमत समूह होंगे।

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

Comments

सामग्री 100% स्थिर है, इसलिए लोड नगण्य है - एक सर्वर पर भी। यह ज्यादातर बैंडविड्थ है।

— जेफ एटवुड

सभी एक ही पाइप से?

— स्किलमैन

TTL उस समय सबसे अधिक उपयोग किया जाता है जब आप जिस तरह से DNS से ​​टकराएंगे। प्रत्येक DNS वही करेगा जो उसका व्यवस्थापक चाहता है। और उनमें से ज्यादातर 5 मिनट के एक टीटीएल की अनुमति नहीं देंगे, जिसका अर्थ है कि DNS स्रोत से डेटा को हर 5 मिनट में पुनः लोड करना ... बिना किसी वैध कारण के DNS सर्वर को आउट करने का सबसे अच्छा तरीका। और आप «सीमांत उपयोग» के साथ गलत हैं, Google इसका उपयोग अपने सभी खोज सर्वरों के लिए करता है ... और मुझे वास्तव में संदेह है कि वे ऐसा करने वाले केवल हैं। आरआर-डीएनएस महान है, जब आप जानते हैं कि यह क्या करता है।

— यवन