मामलों का उपयोग करें या क्या लोड balancers की कमी है

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

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

GET /docs/index.html HTTP/1.1 Host: www.company.com Accept-Language: en-us Accept-Encoding: gzip, deflate 

परिणाम और कैशिंग, और अनुरोधों के बाद के संपीड़न के साथ सर्वर के एक समूह को भेजे जाते हैं

 POST /api/object-put HTTP/1.1 HOST: b2b.company.com X-Auth: 76GDjgtgdfsugs893Hhdjfpsj Content-Type: application/json 

पूरी तरह से अलग नियमों के अनुसार संसाधित।

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

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


चित्र 1

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

1. सर्वर नेटवर्क के लिए डिफ़ॉल्ट गेटवे के रूप में एडीसी;
2. ADC उपभोक्ता पतों को इसके इंटरफ़ेस पतों में प्रसारित करें।

वास्तव में, पहली आवेदन योजना का थोड़ा अधिक यथार्थवादी दृष्टिकोण इस तरह दिखता है, यह वह आधार है जिससे हम शुरू करेंगे:


Fig.2

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

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

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


3 चित्र

इसलिए, हमारे पास एक आधार-डेटा केंद्र है, जो चित्र 2 में दिखाया गया है, आइए विचार करें कि आधार-डेटा केंद्र को विकास में किन समस्याओं को धक्का दे सकता है, मैं विश्लेषण के लिए दो विषय देखता हूं:

1. मान लीजिए कि स्विचिंग सबसिस्टम पूरी तरह से आरक्षित है, आइए इस बारे में न सोचें कि कैसे या क्यों, विषय बहुत व्यापक है। एप्लिकेशन कई सर्वरों पर चलते हैं और ADC का उपयोग करके बैकअप लिए जाते हैं, लेकिन मैं ADC को कैसे आरक्षित कर सकता हूं?
2. यदि विश्लेषण से पता चलता है कि अगला मौसमी शिखर लोड एडीसी की क्षमताओं से अधिक हो सकता है, तो आप निश्चित रूप से स्केलेबिलिटी के बारे में सोचते हैं।

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

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


चित्र 4

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


चित्रा 5

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

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

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

1. क्लस्टर आर्किटेक्चर कभी-कभी इस या उस कार्यक्षमता पर प्रतिबंध लगाता है, कुछ परियोजनाओं में यह मौलिक है, कुछ में यह भविष्य में महत्वपूर्ण हो सकता है, यह सब निर्माता पर निर्भर करता है और प्रत्येक समाधान को व्यक्तिगत रूप से काम करने की आवश्यकता होती है;
2. क्लस्टर अक्सर एक गलती डोमेन होता है, सॉफ्टवेयर में त्रुटियां होंगी।
3. क्लस्टर को इकट्ठा करना आसान है, लेकिन जुदा करना बहुत मुश्किल है। प्रौद्योगिकी में कम गतिशीलता है - आप सिस्टम के कुछ हिस्सों को नियंत्रित नहीं कर सकते।
4. आप अपने निर्माता के तेजस्वी आलिंगन में पड़ जाते हैं।

फिर भी, सकारात्मक बातें हैं:

1. क्लस्टर स्थापित करना आसान है और संचालित करना आसान है।
2. कभी-कभी आप निकट-इष्टतम संसाधन उपयोग की उम्मीद कर सकते हैं।

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


चित्रा 6

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

1. साइटों के बीच चैनलों का उपयोग;
2. ADC पास और दूर के सर्वर पर प्रसंस्करण के लिए भेजे गए अनुरोधों के प्रसंस्करण समय में अंतर।

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

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


चित्र 7

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

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


चित्र 8

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


चित्र 9

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

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

1. प्रत्येक एडीसी के लिए एक सामान्य इंटरफ़ेस पर सर्वर पर अतिरिक्त आईपी पता;
2. प्रत्येक एडीसी के लिए एक अलग 802.1q पर सर्वर पर इंटरफ़ेस आईपी पता;
3. प्रत्येक ADC के लिए सर्वर पर अलग उपरिशायी सुरंग नेटवर्क।

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


चित्र १०

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

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

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

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