एल 7 संतुलन में बार-बार अनुरोध का उपयोग करके ग्राहक को प्रतिक्रिया की संभावना बढ़ाने के लिए मत भूलना

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

HTTP ट्रैफ़िक को संतुलित करने का सारांश

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

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

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

एप्लिकेशन सर्वर का निष्क्रिय सत्यापन और उत्पादन सर्वर के पूल से इसका बहिष्कार

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

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



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

HTTP और TCP त्रुटियों की सूची, जिसमें सर्वर निम्नलिखित सर्वर का उपयोग करता है, प्रॉक्सी_next_upstream निर्देश में निर्दिष्ट है।

डिफ़ॉल्ट रूप से, nginx केवल अगले एप्लिकेशन सर्वर पर idempotent HTTP विधियों के साथ अनुरोध करता है।

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

अंत में, एप्लिकेशन सर्वर प्रतिक्रिया क्लाइंट को वापस लौटा दी जाती है , जहां प्रॉक्सी_नेक्स्ट_अपस्ट्रीम_ट्रीज स्वीकार्य प्रयास काउंटर समाप्त होता है ।

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



एप्लिकेशन सर्वरों की निष्क्रिय स्वास्थ्य जांच निर्देशों द्वारा नियंत्रित की जाती है, उदाहरण के लिए, उनके मूल्यों के लिए निम्न विकल्पों के साथ:

upstream backend { server app01:80 weight=1 max_fails=5 fail_timeout=100s; server app02:80 weight=1 max_fails=5 fail_timeout=100s; } server { location / { proxy_pass http://backend; proxy_next_upstream timeout http_500; proxy_next_upstream_tries 1; ... } ... } 

2 जुलाई, 2019 तक , प्रलेखन ने स्थापित किया कि max_fails पैरामीटर उस सर्वर के साथ काम करने के असफल प्रयासों की संख्या निर्धारित करता है जो विफल_टाइम पैरामीटर द्वारा निर्दिष्ट समय के भीतर होने चाहिए।

Fail_timeout पैरामीटर उस समय को सेट करता है, जिसके दौरान सर्वर के साथ काम करने के लिए असफल प्रयासों की निर्दिष्ट संख्या सर्वर के लिए अनुपलब्ध मानी जानी चाहिए; और जिस समय के दौरान सर्वर अनुपलब्ध माना जाएगा।

दिए गए उदाहरण में, कॉन्फ़िगरेशन फ़ाइल का हिस्सा, बैलेंसर 100 सेकंड के भीतर 5 विफल कॉल पकड़ने के लिए कॉन्फ़िगर किया गया है।

एप्लिकेशन सर्वर को प्रोडक्शन सर्वर पूल में वापस करना

प्रलेखन से निम्नानुसार, विफलता_टाइम के बाद का बैलेंसर सर्वर को निष्क्रिय नहीं मान सकता। लेकिन, दुर्भाग्य से, प्रलेखन स्पष्ट रूप से स्थापित नहीं करता है कि सर्वर के प्रदर्शन का मूल्यांकन कैसे किया जाता है।

एक प्रयोग के बिना, कोई केवल यह मान सकता है कि राज्य की जांच के लिए तंत्र पहले वर्णित के समान है।

उम्मीदें और वास्तविकता

प्रस्तुत कॉन्फ़िगरेशन में, बैलेंसर से निम्न व्यवहार अपेक्षित है:

1. जब तक बैलेंसर उत्पादन सर्वर के पूल से एप्लिकेशन सर्वर नंबर 2 को बाहर नहीं करता, तब तक क्लाइंट अनुरोधों को इसमें भेजा जाएगा।
2. एप्लिकेशन सर्वर नंबर 2 से 500 त्रुटि के साथ लौटाए गए अनुरोधों को अगले एप्लिकेशन सर्वर पर भेज दिया जाएगा, और क्लाइंट को सकारात्मक प्रतिक्रियाएं प्राप्त होंगी।
3. जैसे ही बैलेंसर को 100 सेकंड के भीतर कोड 500 के साथ 5 प्रतिक्रियाएं मिलती हैं, यह उत्पादन सर्वर के पूल से एप्लिकेशन सर्वर नंबर 2 को बाहर कर देगा। 100 सेकंड विंडो के बाद सभी अनुरोधों को अतिरिक्त समय के बिना शेष काम कर रहे एप्लिकेशन सर्वर पर तुरंत भेजा जाएगा।
4. 100 सेकंड के बाद, किसी तरह, बैलेंसर को एप्लिकेशन सर्वर के प्रदर्शन का मूल्यांकन करना होगा और इसे उत्पादन सर्वर के पूल में वापस करना होगा।

बैलेंसर की पत्रिकाओं के अनुसार, इन-तरह के परीक्षणों का संचालन करने के बाद, यह स्थापित किया गया था कि कथन संख्या 3 काम नहीं करता है। जैसे ही max_fails पैरामीटर पर स्थिति पूरी होती है , बैलेंसर एक निष्क्रिय सर्वर को बाहर कर देता है। इस प्रकार, एक विफल सर्वर को 100 सेकंड के बीतने की प्रतीक्षा किए बिना सेवा से बाहर रखा गया है। Fail_timeout पैरामीटर त्रुटि संचय समय की केवल ऊपरी सीमा की भूमिका निभाता है।

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

क्या याद आ रही है?

1. Nginx / 1.17.0 में लागू किया गया एल्गोरिथम कार्यशील सर्वर पूल में लौटने से पहले सर्वर के प्रदर्शन की जांच करने का सबसे उचित तरीका नहीं हो सकता है। कम से कम, वर्तमान दस्तावेज़ के अनुसार, 1 अनुरोध अपेक्षित नहीं है, लेकिन अधिकतम_फॉल्स में निर्दिष्ट राशि।
2. राज्य चेक एल्गोरिथ्म अनुरोधों की गति को ध्यान में नहीं रखता है। यह जितना बड़ा होता है, असफल प्रयासों के साथ स्पेक्ट्रम उतना ही मजबूत होता है, और एप्लिकेशन सर्वर काम करने वाले सर्वर पूल से भी जल्दी निकल जाता है। मुझे लगता है कि यह उन अनुप्रयोगों को प्रतिकूल रूप से प्रभावित कर सकता है जो खुद को "कम समय के थक्के" में त्रुटियों का उत्पादन करने की अनुमति देते हैं। उदाहरण के लिए, कचरा इकट्ठा करते समय।

मैं आपसे पूछना चाहता था कि क्या सर्वर स्वास्थ्य जांच एल्गोरिदम से कोई व्यावहारिक लाभ है, जो विफल प्रयासों की गति को मापता है?