TTL के माध्यम से वेटेड राउंड रॉबिन्स - संभव है?

Question

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

;; ANSWER SECTION:
orion.2x.to.        116 IN  A   80.237.201.41
orion.2x.to.        116 IN  A   87.230.54.12
orion.2x.to.        116 IN  A   87.230.100.10
orion.2x.to.        116 IN  A   87.230.51.65

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

हालांकि अगर उपयोगकर्ता का आधार काफी बड़ा है (कई आईएसपी, आदि पर फैलता है) तो यह बहुत अच्छी तरह से संतुलित होता है। उच्चतम से निम्नतम लोड किए गए सर्वर की विसंगतियां शायद ही हर 15% से अधिक हो।

हालाँकि अब मुझे समस्या है कि मैं सिस्टम में अधिक सर्वर शुरू कर रहा हूं, और सभी में समान क्षमता नहीं है।

वर्तमान में मेरे पास केवल 1 जीबीपीएस सर्वर है, लेकिन मैं 100 एमबीपीएस और 10 जीबीपीएस सर्वर के साथ भी काम करना चाहता हूं।

तो मैं जो चाहता हूं, मैं 100 के वजन के साथ 10 जीबीपीएस के साथ एक सर्वर शुरू करना चाहता हूं, 10 के वजन के साथ 1 जीबीपीएस सर्वर और 1 के वजन के साथ 100 एमबीपीएस सर्वर।

मैंने पहले उनसे अधिक ट्रैफ़िक लाने के लिए दो बार सर्वर जोड़े (जो अच्छा काम करता था - बैंडविड्थ लगभग दोगुना हो गया)। लेकिन DNS में 100 Gbps सर्वर को 100 गुना जोड़ना थोड़ा हास्यास्पद है।

इसलिए मैंने TTL का उपयोग करने के बारे में सोचा।

अगर मैं सर्वर को 240 सेकंड TTL और सर्वर B केवल 120 सेकंड (जो कि राउंड रॉबिन के लिए उपयोग करने के लिए न्यूनतम के बारे में है, के रूप में देता है, तो बहुत सारे DNS सर्वर 120 पर सेट होते हैं यदि एक कम TTL निर्दिष्ट किया जाता है (इसलिए मैंने सुना है)। मुझे लगता है कि आदर्श परिदृश्य में ऐसा कुछ होना चाहिए:

First 120 seconds
50% of requests get server A -> keep it for 240 seconds.
50% of requests get server B -> keep it for 120 seconds

Second 120 seconds
50% of requests still  have server A cached -> keep it for another 120 seconds.
25% of requests get server A -> keep it for 240 seconds
25% of requests get server B -> keep it for 120 seconds

Third 120 seconds
25% will get server A (from the 50% of Server A that now expired) -> cache 240 sec
25% will get server B  (from the 50% of Server A  that now expired) -> cache 120 sec
25% will have server A cached for another 120 seconds
12.5% will get server B (from the 25% of server B that now expired) -> cache 120sec
12.5% will get server A (from the 25% of server B that now expired) -> cache 240 sec

Fourth 120 seconds
25% will have server A cached -> cache for another 120 secs
12.5% will get server A (from the 25% of b that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of b that now expired) -> cache 120 secs
12.5% will get server A (from the 25% of a that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of a that now expired) -> cache 120 secs
6.25% will get server A (from the 12.5% of b that now expired) -> cache 240 secs
6.25% will get server B (from the 12.5% of b that now expired) -> cache 120 secs
12.5% will have server A cached -> cache another 120 secs
... I think I lost something at this point, but I think you get the idea...

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

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

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

मेरा प्रश्न अब यह है: क्या DNS रिकॉर्ड्स के टीटीएल विशेषता का उपयोग करके वेट राउंड रॉबिन वितरण के लिए अंगूठे का कोई सर्वोत्तम अभ्यास / तरीके / नियम हैं?

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

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

Comments

उत्तरदाताओं के एक व्यापक स्पेक्ट्रम द्वारा RFC 2181 a 5.2 की एक प्रति के साथ सिर पर हिट होने के लिए तैयार रहें।

— JdeBP

अच्छी तरह से मुझे पता है कि आरआर लोड संतुलन के लिए डिज़ाइन नहीं किया गया था। लेकिन यह बहुत अच्छा काम करता है ... इसलिए ... मुझे एक विकल्प की भी जानकारी नहीं है। निश्चित रूप से वहाँ हैं, लेकिन वे या तो मेरे लिए संभव नहीं हैं या बहुत महंगी या बहुत जटिल हैं

— द शेरिकॉन

@JdeBP हाँ, अच्छा स्थान - RRset MUST में TTL एक ही होना चाहिए।

— अलनीतक 23

Answer 1

सबसे पहले, मैं पूरी तरह से @Alnitak से सहमत हूं कि DNS इस तरह की चीज़ के लिए डिज़ाइन नहीं किया गया है, और सबसे अच्छा अभ्यास यह है कि (DNS) एक गरीब आदमी के लोड बैलेंसर के रूप में DNS का उपयोग न करें।

मेरा सवाल अब यह है ... क्या DNS रिकॉर्ड्स की TTL विशेषता का उपयोग करके वेट राउंड रॉबिन वितरण के लिए अंगूठे का कोई सबसे अच्छा प्रचलन / मिथोस / नियम हैं?

प्रश्न के आधार पर उत्तर देने के लिए, डीएनएस का उपयोग करते हुए बेसिक्स भारित राउंड रॉबिन करने के लिए उपयोग किया जाता है:

• आधिकारिक DNS प्रतिक्रियाओं में रिकॉर्ड की सापेक्ष घटना को समायोजित करें । यानी यदि Server Aट्रैफ़िक का 1/3 होना है और Server B2/3 होना है, तो DNS प्रॉक्सियों के लिए आधिकारिक DNS प्रतिक्रियाओं में से 1/3 में केवल A 'IP' और B' 2/3 ' प्रतिक्रियाओं का केवल IP होता है। (यदि 2 या अधिक सर्वर एक ही 'वेट' साझा करते हैं, तो उन्हें एक प्रतिक्रिया में बंडल किया जा सकता है।)
• एक कम डीएनएस टीटीएल रखें ताकि अन-बैलेंस्ड लोड अपेक्षाकृत जल्दी से ठीक हो जाए। क्योंकि डाउनस्ट्रीम डीएनएस प्रॉक्सि के बहुत ही गैर-सम संख्या वाले क्लाइंट हैं जिनके पीछे आप बार-बार रिकॉर्ड फेरबदल करना चाहते हैं।

अमेज़न की रूट 53 DNS सेवा इस पद्धति का उपयोग करती है ।

बैंडविड्थ (अनुरोध नहीं) की मात्रा ईथरनेट के साथ एक एकल सर्वर से अधिक हो सकती है। इसलिए मुझे एक संतुलन समाधान की आवश्यकता है जो बैंडविड्थ को कई सर्वरों में वितरित करता है।

सही। तो जैसा कि मैं यह समझता हूं, आपके पास कुछ प्रकार के 'सस्ते' डाउनलोड / वीडियो वितरण / बड़ी फ़ाइल डाउनलोड सेवा हैं, जहां कुल सेवा बिटरेट 1 जीबीआईटी से अधिक है।

आपकी सेवा और आपके सर्वर लेआउट की सटीक बारीकियों को जाने बिना, सटीक होना मुश्किल है। लेकिन इस मामले में एक आम समाधान है:

• DNS राउंड रॉबिन दो या अधिक टीसीपी / आईपी या एचटीटीपी स्तर लोड बैलेंसर इंस्टेंसेस के लिए।
• प्रत्येक लोड बैलेंसर उदाहरण अत्यधिक उपलब्ध है (2 समान लोड बैलेंसर्स एक आईपी पते को हमेशा चालू रखने में सहयोग करते हैं)।
• भारित राउंड रॉबिन या बैकएंड सर्वरों के लिए भारित यादृच्छिक कनेक्शन हैंडलिंग का उपयोग करके प्रत्येक लोड बैलेंसर उदाहरण।

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

Answer 2

मेरा सवाल अब यह है ... क्या DNS रिकॉर्ड्स की TTL विशेषता का उपयोग करके वेट राउंड रॉबिन वितरण के लिए अंगूठे का कोई सबसे अच्छा प्रचलन / मिथोस / नियम हैं?

हाँ, सबसे अच्छा अभ्यास यह नहीं है !!

कृपया मेरे बाद दोहराएँ

• डीएनएस लोड बैलेंसिंग के लिए नहीं है
• डीएनएस समाधान प्रदान नहीं करता है
• DNS विफल-ओवर सुविधाएं प्रदान नहीं करता है

DNS एक या एक से अधिक IP पते पर नाम मैप करने के लिए है । आपके द्वारा प्राप्त किसी भी बाद की शेष राशि भाग्य के माध्यम से है, न कि डिजाइन।

Comments

more IP addresses... यह कैसे संतुलन नहीं है? इसके अलावा यही कारण है कि मैंने अपने प्रश्न का उचित परिचय दिया। अगर मैंने ऐसा नहीं किया है तो मैं आपके पोस्ट को COMMENT के रूप में बताऊंगा लेकिन इस तरह मुझे इसे डाउनवोट करना होगा। माबाई यह डिजाइन नहीं है, लेकिन यह बहुत अच्छा काम करता है और सभी विकल्पों के लिए शानदार फायदे प्रदान करता है। और यही कारण है कि google, facebook, amazon आदि जैसी वेबसाइटें भी सोचती हैं और इसका उपयोग करती हैं। हालांकि, टिप्पणी नोट किया। मैं परिदृश्य के बारे में अधिक जानकारी के साथ मेरे सवाल का अद्यतन और कृपया एक विकल्प के संतुलन समाधान @Alnitak सुझाव देने के लिए आप से पूछना

— Shurrican

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

— मैथ्यू इफ

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

— शूरिकान

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

— एल्निटैक

क्या अतिरेक आपके समाधान के लिए महत्वपूर्ण है? IE एक सर्वर नीचे चला जाता है, तो यह उचित रूप से नियंत्रित किया जाता है? क्योंकि अगर यह आरआर-डीएनएस के साथ कीड़े का एक खोल सकता है।

— मैथ्यू इफ

Answer 3

PowerDNS पर एक नज़र डालें । यह आपको एक कस्टम पाइप बैकएंड बनाने की अनुमति देता है। मैंने एक उदाहरण लोड-बैलेंसर DNS बैकएंड को संशोधित किया है जो कि एल्गोरिथ्म का उपयोग करने के लिए पर्ल में लिखा है :: ConsistentHash :: Ketama मॉड्यूल। यह मुझे मनमानी वजन सेट करने देता है जैसे:

my $ketamahe = Algorithm::ConsistentHash::Ketama->new();

# Configure servers and weights
$ketamahe->add_bucket("192.168.1.2", 50);
$ketamahe->add_bucket("192.168.1.25", 50);

और दूसरा:

# multi-colo hash
my $ketamamc = Algorithm::ConsistentHash::Ketama->new();

# Configure servers and weights
$ketamamc->add_bucket("192.168.1.2", 33);
$ketamamc->add_bucket("192.168.1.25", 33);
$ketamamc->add_bucket("192.168.2.2", 17);
$ketamamc->add_bucket("192.168.2.2", 17);

मैंने अपने इच्छित शीर्ष स्तर के डोमेन से एक सबडोमन को एक सबडोमन में जोड़ा है जिसे मैं gslb, या Global Server Load Balancing कहता हूं। वहां से, मैं इस कस्टम डीएनएस सर्वर का आह्वान करता हूं और अपने वांछित वजन के अनुसार ए रिकॉर्ड भेजता हूं।

चंवर की तरह काम करता है। जैसा कि आप सर्वर जोड़ते हैं या वज़न समायोजित करते हैं, केटामा हैश में मौजूदा कॉन्फ़िगरेशन में न्यूनतम व्यवधान की अच्छी संपत्ति है।

मैं जन-पीइट मेन्स द्वारा वैकल्पिक डीएनएस सर्वर को पढ़ने की सलाह देता हूं। उसके पास कई अच्छे विचार हैं और साथ ही उदाहरण कोड भी है।

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

Answer 4

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

यहाँ एक लेख है जो मैंने आरटीडी DNS को भारित करने के लिए PowerDNS में MySQL बैकेंड का उपयोग करने पर लिखा है: http://www.mccartney.ie/wordpress/2008/08/wrr-dns-with-powerdns/

Ripienaar के कुछ रूबी आधारित उदाहरण (PowerDNS पाइप बैकएंड का उपयोग करके) हैं: http://code.google.com/p/ruby-pdns/wiki/RecipeWeightedRoundRobin

Answer 5

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

Comments

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

— शूरिकान

क्षमा करें, मेरा मतलब किसी भी तरह का है, न कि मल्टीकास्ट (मुझे लगता है)

— द शेरिकॉन

यदि बैंडविड्थ समस्या है तो आपको अपने स्विच पर इस + LACP को देखना चाहिए। आप फिर लोडबेलेंसिंग डिवाइस (ओं) में कई 10G कार्ड को बाँध सकते हैं।

— मार्क हैरिगन

मैं इस upvoted क्योंकि यह दिलचस्प है ... लेकिन मैं अपने टोंटी के रूप में स्विच है!

— शूरिकान