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


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

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

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

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

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

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

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


60
2018-01-09 03:01


मूल


HAProxy एक विकल्प नहीं है? - Howiecamp
जैसा कि मैंने पोस्ट में कहा था, यह एक विशिष्ट सवाल है इस समाधान - क्या हम विषय पर रह सकते हैं? - Jeff Atwood
भार संतुलन(en.wikipedia.org/wiki/Load_balancing_%28computing%29) तो बहुत अलग है तो अनावश्यकता (en.wikipedia.org/wiki/Redundancy_%28engineering%29)। जैसा कि जेफ ने अपने शुरुआती अनुच्छेद में कहा था, वह असफलता (अनावश्यकता) के एक बिंदु को हटाने का साधन ढूंढ रहा है, वास्तविक भार संतुलन नहीं। क्या कोई पीछे हट सकता है? - antony.trupe
@jeff - बिल्कुल, एक गूंगा लोड बैलेंसर (जो सादा राउंड रॉबिन डीएनएस है) अनावश्यकता नहीं करता है। यदि आप कई साइटों पर संतुलन / अनावश्यकता के बारे में बात कर रहे हैं तो यह भी कठिन है। - Alnitak
@ सिमकबीन मैं आरएफसी 2119 में प्रलेखित शब्दावली शब्दों से घनिष्ठ परिचित हूं। आपने कहा कि DNS सर्वर वरीयता सूची को परिभाषित करता है। जब तक कि आपके पास "वरीयता सूची" की कुछ विशेष रूप से अजीब परिभाषा न हो जो कि सच नहीं है। - Alnitak


जवाब:


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

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

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

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

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


56
2018-01-09 11:17



बीटीडब्ल्यू आपको इन अवधारणाओं पर 4 साल पहले लिखे गए एक लेख में रूचि हो सकती है: 1wt.eu/articles/2006_lb (पीडीएफ लें, पृष्ठों के माध्यम से एचटीएमएल पढ़ना उबाऊ है)। - Willy Tarreau
-1: "असफलता प्रदान नहीं करता है" - हाँ यह करता है - और यह एकमात्र जगह पर लागू होता है जहां ग्राहक द्वारा विश्वसनीय रूप से निर्धारित नहीं किया जा सकता है। - symcbean
हर्गिज नहीं। यह काम करेगा यदि DNS ने कैश का उपयोग नहीं किया है, लेकिन यह मामला नहीं है और ग्राहक कैश को रीफ्रेश करने के लिए मजबूर नहीं कर सकते हैं। किसी भी व्यक्ति से बात करें जो नियमित रूप से DNS प्रविष्टियों को स्विच करता है और वे आपको बताएंगे कि यदि वे 5 मिनट में 80% स्विच देखते हैं, तो आमतौर पर 100% तक पहुंचने में एक सप्ताह से अधिक समय लगता है। तो DNS विफलता प्रदान नहीं करता है। - Willy Tarreau
"बिना रिडंडेंसी के लोड लोडिंग" का एक साधारण उदाहरण RAID0 है। - robbyt
विली आप अपडेट करने के लिए उम्र लेने वाले DNS रिकॉर्ड्स के लिए सही हैं। लेकिन ब्राउज़रों के साथ आरआर-डीएनएस ब्राउज़र स्तर पर संभाला जाता है, दूसरे आईपी एक दूसरे के बाद परीक्षण करता है अगर DNS द्वारा भेजा गया पहला दिखाई देता है। इस मामले में, आप कभी भी अपने DNS रिकॉर्ड्स को नहीं बदलते हैं, इसलिए प्रतीक्षा करने के लिए कोई अपडेट नहीं है। - Yvan


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

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

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

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

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

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


19
2018-01-09 03:09



पूरी तरह से ऑफ-विषय, लेकिन हमें असफल होने के लिए कई HAProxy उदाहरणों की आवश्यकता होने की समस्या भी है - क्या होगा यदि हैप्रोक्सी मशीन विफल हो जाए? भविष्य के प्रश्नों का विषय, हालांकि, इस के लिए वास्तव में विषय बंद करें। - Jeff Atwood
+1 - "एक स्वचालित तरीके से ... यह यहूदी फेलओवर बन जाता है। मैन्युअल रूप से यह भी नहीं है।" बड़े बोल्ड अक्षरों में होना चाहिए। डीएनएस राउंड-रॉबिन एक बन जाता है देयता यदि आप मशीनों की निगरानी नहीं कर रहे हैं और उन्हें विफल होने पर DNS से ​​हटा रहे हैं, और ऐसा करने का एकमात्र उचित तरीका एक स्वचालित समाधान के साथ है। DNS राउंड-रॉबिन की तुलना में बहुत बेहतर समाधान हैं। - Evan Anderson
पूरी तरह से सहमत हैं, लेकिन आपके 20% ग्राहक आपको शिकायतों के साथ बुलाते हैं है उनमें से 100% से बेहतर शिकायतों के साथ बुलावा .. - Jeff Atwood
मुख्य बिंदु (मेरे लिए) कि Schof जेफ के सवाल का जवाब देने में बनाता है कि तेजी से विफलता के बिना राउंड रॉबिन का मतलब है कि समय के साथ आपके पास इसके बिना अधिक ग्राहक प्रभावित होते हैं लेकिन प्रत्येक (अधिक बार) घटना सभी के बजाय ग्राहकों का केवल एक सबसेट प्रभावित करती है। चाहे यह "बेहतर" है या नहीं, परिदृश्य पर निर्भर करता है लेकिन ज्यादातर मामलों में मैं कहूंगा कि यह नहीं है। - Helvick
The best part of true failover is getting to sleep through the night. यह एक स्पष्ट परिभाषा है! - Basil Bourque


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

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

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


14
2018-01-09 10:51



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


मैंने इसे कई बार पहले कहा है, और मैं इसे फिर से कहूंगा - यदि लचीलापन समस्या है तो DNS चालें हैं नहीं उत्तर

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

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

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

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


14
2018-01-09 08:55





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

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


7
2018-04-29 09:28



ओह, मेरा पोस्ट करने से पहले आपका जवाब नहीं देखा, इसलिए तुम्हारा +1 ताकि सत्य निकल जाए! - Yvan


विंडोज विस्टा और विंडोज 7 राउंड रॉबिन के लिए अलग-अलग क्लाइंट समर्थन लागू करें क्योंकि उन्होंने IPv6 पते चयन को आईपीवी 4 में बैकपोर्ट किया था। (आरएफसी 3484)

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


4
2018-01-09 13:55



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


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

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

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

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

सवाल

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

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

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

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

अन्य समाधान

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

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


4
2018-02-03 02:56





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

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

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

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

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

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

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

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

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

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

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

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

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


4
2017-08-13 13:25



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


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

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


1
2018-01-09 03:08



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


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

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

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

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


1
2018-01-09 03:24





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

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

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


1
2018-01-09 05:14