सॉफ्टवेयर लोड बैलेंसर को स्केल करने के लिए एक विशिष्ट विधि क्या है?


22

मैं अक्सर ऐप सर्वर के एक समूह के सामने SLB / रिवर्स-प्रॉक्सी के साथ वेब ऐप आर्किटेक्चर देखता हूं।

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

एसएलबी को स्केल करने के लिए अनुशंसित कॉन्फ़िगरेशन क्या है ?

क्या एलबी का समूह / समूह बनाना विशिष्ट है? यदि ऐसा है, तो ग्राहक भार एलबी के समूह के बीच कैसे फैला हुआ है?


z8000, क्या आप कह सकते हैं कि आप किस सॉफ्टवेयर लोड-बैलेंसर का उपयोग कर रहे हैं? इसके अलावा, यदि संभव हो तो लोड-बैलेंसिंग के लिए यह कौन सा एल्गोरिदम / प्रोटोकॉल का उपयोग करता है।
मार्टिन

मेरी प्राथमिकता नहीं है। मैंने प्रश्न को स्पष्ट करने के लिए अद्यतन किया।
z8000

यह मेरे लिए स्पष्ट नहीं है कि एक लोड बैलेंसर आंतरिक रूप से 2 मिलियन लगातार HTTP कनेक्शन क्यों नहीं संभाल सकता है।
Womble

जवाबों:


10

लोड बैलेंसरों को आसानी से अन्य लोड बैलेंसरों द्वारा स्केल नहीं किया जा सकता है क्योंकि चेन पर एक ही लोड बैलेंसर कहीं न कहीं कनेक्शन बनाए रखेगा। उस ने कहा, LVS या HAProxy जैसे बैलेन्स Gbps रेंज में बेतुकी क्षमता रखते हैं। एक बार जब आप एकल लोड बैलेंसर (सॉफ्टवेयर, हार्डवेयर, जो भी हो) की क्षमताओं से परे हो जाते हैं, तो आपको अन्य तकनीकों जैसे कि राउंड रॉबिन डीएनएस में जाने की आवश्यकता होगी।


सही! एकल LB का होना "समस्या" है। मैं सहमत हूँ कि थ्रूपुट आम तौर पर एक समस्या नहीं होगी। लेकिन मैं अन्य संसाधनों जैसे कि रैम के बारे में चिंतित हूं, जो मेरे मामले में सीमित है। रैम से बाहर होने से पहले केवल एक ही SLB पर होस्ट किए जा सकने वाले बहुत सारे कनेक्शन हैं।
z8000

HAProxy प्रति GB RAM के बारे में 20k-60k सक्रिय सत्र को संभाल सकता है। मेरा मानना ​​है कि LVS बहुत कुछ कर सकता है, क्योंकि बनाए रखा गया सत्र डेटा छोटा है। यदि आप रैम से बाहर निकलते हैं, तो इसे या तो अपग्रेड करें या राउंड-रॉबिन डीएनएस सिस्टम द्वारा फ्रंट लोड किए गए एक और लोड बैलेंसर का निर्माण करें।
हैप्पी

1
"लोड बैलेंसरों को आसानी से अन्य लोड बैलेंसरों द्वारा बढ़ाया नहीं जा सकता है" - वास्तव में, एक एएसआईसी आधारित एल 4 लोड बैलेंसर को अक्सर उत्कृष्ट परिणामों के साथ एल 7 एचटीटीपी आधारित लोड बैलेंसरों के एक जोड़े के सामने रखा जा सकता है। सॉफ्टवेयर-केवल कार्यान्वयन के लिए एक ही मूल सिद्धांत लागू होता है, उदाहरण के लिए nignx के सामने Linux LVS।
जेस्पर एम

19

ठीक है, पहले से ही एक स्वीकृत उत्तर है, लेकिन कुछ जोड़ना है .. लोड बैलेंसर टियर स्केल करने के सबसे आम 'शास्त्रीय' तरीके हैं (कोई विशेष क्रम में नहीं):

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

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

  • की एक परत आईपी स्तर लोड बैलेंसर्स HTTP के स्तर लोड बैलेंसर्स की एक परत के सामने । आईपी-लेयर लोड बैलेंसिंग को ASICs / सिलिकॉन में लागू किया जा सकता है, और कुछ चीजों के लिए तेजी से दुष्ट किया जा सकता है। इस प्रकार एक एकल आईपी लोड बैलेंसर जोड़ी अक्सर कई HTTP / HTTPS स्तर लोड बैलेंसरों के साथ 'रख सकती है', और वास्तुकला को अच्छा और सरल रखते हुए बहु-गीगाबिट प्रदर्शन स्तर प्रदान करती है।

उपरोक्त तरीकों से पूरी तरह से गहराई में जाने से बहुत लंबे उत्तर की आवश्यकता होगी। लेकिन सामान्य तौर पर, लोड बैलेंसर टियर को स्केल करना उतना कठिन नहीं है, एप्लिकेशन सर्वर टियर और विशेष रूप से डेटाबेस टियर को स्केल करना कहीं अधिक कठिन है।

चाहे आप एक उपकरण फार्म कारक (F5, सिस्को, A10) या एक सामान्य सर्वर (विंडोज / लिनक्स + सॉफ्टवेयर) को कम चुनते हैं। लोड बैलेंसर परत को स्केल करते समय प्रमुख विचार हैं:

  • राज्य-पूर्ण बनाम स्टेटलेस। क्या आपको पूरी तरह से चिपचिपा सत्रों की आवश्यकता है, या आप बिना रह सकते हैं? राज्य न रखने से सब कुछ सरल हो जाता है।
  • लोड संतुलन के लिए 'हार्डवेयर' (ASICs) बनाम 'सॉफ्टवेयर' (सामान्य प्रयोजन सर्वर)। प्रत्येक के पास अपने पेशेवरों और विपक्ष हैं, ऊपर दिए गए HAProxy सिंहावलोकन दस्तावेज़ देखें।
  • L3 / 4 (IP / TCP / IP) लोड संतुलन बनाम L7 (HTTP) लोड संतुलन। फिर से, पेशेवरों और विपक्ष, HAProxy डॉक्टर एक अच्छा अवलोकन प्रदान करता है।
  • एसएसएल समाप्ति , जहां, वेबनोड पर या लोड बैलेंसर पर।

आमतौर पर, इससे पहले कि आपकी वेबसाइट बहुत बड़ी हो जाए, आपको इस बारे में चिंता करने की ज़रूरत नहीं है - fx nginx के साथ एक एकल आधुनिक सर्वर प्रति सेकंड हजारों सादे HTTP अनुरोधों को संभाल लेगा। तो समय से पहले अनुकूलन मत करो, इससे पहले कि आप के साथ सौदा नहीं है।


आपको वास्तव में DNS आरआर का उपयोग करके प्रत्येक आईपी एड्रेस की अत्यधिक आवश्यकता नहीं है । यदि वे कनेक्ट नहीं कर सकते, तो ब्राउज़र सामान्य रूप से किसी अन्य IP पर वापस गिर जाएगा। लेकिन अगर आपके पास सार्वजनिक वेब सेवाएँ हैं, तो आपको प्रत्येक IP पते के लिए HA की आवश्यकता होगी, क्योंकि कई वेब सेवाएँ लाइब्रेरी स्वचालित रूप से अन्य IP के लिए विफल-ओवर को हैंडल नहीं करेंगी।
ralayter

9

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

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

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

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

पहली रणनीति: एक फ़ायरवॉल के साथ

संभवतः आपके पास कुछ राउटर हैं, जिन पर आपके आईएसपी अपलिंक जुड़े हुए हैं। आपका ISP 2 लिंक (सक्रिय / निष्क्रिय, VRRP का उपयोग करके) प्रदान करता है। अपने राउटर पर, आप वीआरआरपी का भी उपयोग करते हैं, और आप अपने सार्वजनिक नेटवर्क पर जाने वाले ट्रैफ़िक को फ़ायरवॉल पर ले जाते हैं। फ़ायरवॉल ( FW 1और FW 2नीचे) भी सक्रिय / निष्क्रिय हैं और ट्रैफ़िक को फ़िल्टर करेंगे और प्रत्येक फ़्लो को एक स्वस्थ फ्रंटेंड सर्वर (आपके HTTP लोड बैलेंसर्स, FE 1और FE 2नीचे) भेजेंगे ।

      + -------------- + + -------------- +
      | ISP राउटर A | | ISP राऊटर B |
      + -------------- + + -------------- +
             | |
           == # ====================== # == (सार्वजनिक नेटवर्क)
             | |
      + --------------- + + --------------- +
      | आपका राउटर A | | आपका राउटर B |
      + --------------- + + --------------- +
             | |
           == # ===== # ========== # ===== # == (RFC 1918 निजी नेटवर्क)
             | | | |
       + ------ + + ------ + + ------ + + ------ +
       | एफडब्ल्यू 1 | | एफए 1 | | एफए 2 | | एफडब्ल्यू 2 |
       + ------ + + ------ + + ------ + + ------ +

लक्ष्य इस तरह एक प्रवाह दिखना है:

  1. आईएसपी आपके सक्रिय राउटर के लिए आपके आईपी पर जाने वाले ट्रैफ़िक को रूट करता है।
  2. आपका राउटर एक वीआईपी के ट्रैफ़िक को रूट करता है जो RFC 1918 पते का उपयोग करता है । यह वीआईपी सक्रिय फ़ायरवॉल के स्वामित्व में है, जैसे कि VRRP। आप अपने फ़ायरवॉल की जरूरत के लिए OpenBSD का उपयोग करते हैं, तो आप उपयोग कर सकते हैं कार्प , VRRP / HSRP के लिए एक पेटेंट मुक्त विकल्प।
  3. आपका फ़ायरवॉल फ़िल्टर लागू करता है (उदाहरण के लिए "केवल 80 / tcp और 443 / tcp इस विशेष आईपी पते पर जा सकता है")।
  4. आपका फ़ायरवॉल एक राउटर के रूप में भी काम करता है और पैकेट को एक स्वस्थ सीमा तक आगे बढ़ाता है।
  5. आपका सीमांत TCP कनेक्शन को समाप्त करता है।

अब जादू चरण 4 और 5 में होता है, तो आइए अधिक विवरण में देखें कि वे क्या करते हैं।

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

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

gotchas:

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

दूसरी रणनीति: बिना फ़ायरवॉल के

यह रणनीति अधिक कुशल है लेकिन सेटअप करने में कठिन है क्योंकि यह आपके पास राउटर की बारीकियों पर अधिक निर्भर करता है। विचार ऊपर के फ़ायरवॉल को बायपास करने का है और राउटर सभी काम करते हैं जो फायरवॉल कर रहे थे।

आपको उन राउटरों की आवश्यकता होगी जो प्रति-पोर्ट L3 / L4 ACLs, BGP और ECMP और नीति आधारित रूटिंग (PBR) का समर्थन करते हैं। केवल हाई-एंड राउटर इन सुविधाओं का समर्थन करते हैं, और उनके पास अक्सर बीजीपी का उपयोग करने के लिए अतिरिक्त लाइसेंस फीस होती है। यह आमतौर पर हार्डवेयर लोड बैलेंसरों की तुलना में अभी भी सस्ता है, और पैमाने पर भी आसान है। इन हाई-एंड राउटर्स के बारे में अच्छी बात यह है कि वे लाइन-रेट (जैसे वे हमेशा लिंक को अधिकतम कर सकते हैं, यहां तक ​​कि 10GbE इंटरफेस पर भी कर सकते हैं, क्योंकि वे सभी निर्णय ASIC द्वारा हार्डवेयर में किए जाते हैं)।

जिन बंदरगाहों पर आपके ISP अपलिंक हैं, उन ACL को लागू करें जो फ़ायरवॉल पर हुआ करते थे (उदाहरण के लिए "केवल 80 / tcp और 443 / tcp इस विशेष IP पते पर जा सकते हैं")। फिर आपके प्रत्येक सामने वाले ने आपके राउटर के साथ बीजीपी सत्र को बनाए रखा है। आप उत्कृष्ट OpenBGPD का उपयोग कर सकते हैं (यदि आपके फ्रंट ओपनबीएसडी पर हैं) या क्वागा । आपका राउटर उन ट्रैफ़िकों को ECMP करेगा जो स्वस्थ हैं (क्योंकि वे अपने बीजीपी सत्रों को बनाए रख रहे हैं)। रूटर PBR का उपयोग करके ट्रैफ़िक को उचित रूप से बाहर निकाल देगा।

शोधन

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

नमूना relaydविन्यास

Https://calomel.org/relayd.html पर HOWTO भी देखें

vip = "1.2.3.4" # आपका सार्वजनिक आईपी पता
               # (आप एक से अधिक हो सकते हैं, लेकिन इसकी आवश्यकता नहीं है)
FE1 = "10.1.2.101"
Fe2 = "10.1.2.102"
Fe3 = "10.1.2.103"
fe4 = "10.1.2.104" # आपके सामने कोई भी संख्या हो सकती है।
int_if = "em0"
तालिका <fe> {$ fe1 पुन: प्रयास 2, $ fe2 पुन: प्रयास 2, $ fe3 पुन: प्रयास 2, $ fe4 पुन: प्रयास करें 2}
तालिका <fallback> {127.0.0.1}

पुनर्निर्देशित वेबट्रैफ़िक {
        $ vip पोर्ट 80 पर सुनें
        सत्र का समय 60
        <fe> चेक http "/healthcheck.html" डाइजेस्ट "(healthcheck.html का sha1sum)" इंटरफ़ेस $ int_if
}

2

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


दूसरे शब्दों में बड़े पैमाने अप ? इस तरह के एलबी को अभी भी कुछ नंबरों (आदि) पर अधिकतम किया जाएगा। फिर क्या? यह वास्तव में मेरा सवाल है। धन्यवाद!
z8000

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

क्या आपका मतलब आंतरिक RRDNS है? नीट, मैंने ऐसा नहीं सोचा था। पुन: खुले कनेक्शन ... मैं एक ऐप के लिए विकल्प तलाश रहा हूं, जो समय के साथ जुड़े हुए ग्राहकों को अपडेट भेजने की आवश्यकता है क्योंकि बैकएंड पर कहीं न कहीं घटनाएं होती हैं। मैं एक कस्टम टीसीपी सर्वर या एक SLB के पीछे खुले HTTP कनेक्शन के बहुत सारे के बीच फटा हुआ हूं। आपकी टिप्पणीयों के लिए धन्यवाद।
z8000

मुझे लगता है कि यह बाहरी आरआरडीएनएस होगा। उदाहरण के लिए, Twitter.com RRDNS का उपयोग कई बड़े एलबी में से एक को हल करने और अनुरोधों को वितरित करने के लिए करेगा जो तब सर्वर पर लोड वितरित करेगा।
रॉबर्ट

हाँ रॉबर्ट, आप सही हैं, उदाहरण के लिए हम साइट-दर-साइट आरआर करने के लिए सिस्को जीएसएस बक्से का उपयोग करते हैं।
चॉपर 3

1

शायद जवाब भेजने के लिए लगातार इतने सारे खुले कनेक्शन रखने के बजाय, अपने आवेदन को इस तरह से कोडित करें ताकि ग्राहक समय-समय पर आपके सर्वर को समय-समय पर आवश्यक रूप से प्रदूषित कर सकें?

क्या आप जो कुछ भी कर रहे हैं उसे वास्तव में इस बहुत मिलीसेकंड की प्रतिक्रिया की आवश्यकता है या क्या एक ग्राहक अगले मतदान अवधि तक 15/20 सेकंड इंतजार कर सकता है?


0

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

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


आप कार्प के बारे में क्या दावा करते हैं कि यह कैसे काम करता है, मैं नहीं जानता कि कहां से शुरू करना है! IPVS का उल्लेख करने के लिए + -0।
3molo

@ 3molo ... है ना? net.inet.carp.arpbalance at linux.com/archive/feed/35482 "..CARP स्रोत-हैश को एक अनुरोध के मूल आईपी को देखें। हैश का उपयोग तब अनुरोध को संभालने के लिए उपलब्ध पूल से एक वर्चुअल होस्ट का चयन करने के लिए किया जाता है। । "
पॉल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.