भारित लोड बैलेंसिंग और बैकअप सर्वर
भार के आधार पर सर्वरों में ट्रैफ़िक का असमान वितरण कीजिए और ऐसे बैकअप सर्वर जोड़िए, जो केवल प्राथमिक पूल विफल होने पर कार्यभार संभालें।
भारित लोड बैलेंसिंग और बैकअप सर्वर, CoddyKit पर API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) का एक निःशुल्क पाठ है। यह 4 में से 4वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
जब सभी सर्वर समान नहीं होते
वास्तविक अपस्ट्रीम पूल में अक्सर अलग-अलग क्षमता वाली मशीनें मिली-जुली होती हैं। नए 16-कोर सर्वर को पुराने 4-कोर सर्वर जितना ही ट्रैफ़िक नहीं मिलना चाहिए।
Nginx आपको भार के माध्यम से ट्रैफ़िक का झुकाव निर्धारित करने देता है, ताकि अधिक शक्तिशाली सर्वर अधिक अनुरोध संभालें।
weight पैरामीटर
सर्वर में weight=N जोड़ें। डिफ़ॉल्ट वज़न 1 होता है। weight=3 वाले सर्वर को weight=1 वाले सर्वर की तुलना में लगभग तीन गुनी अनुरोध प्राप्त होते हैं।
upstream app {
server 10.0.0.1 weight=3;
server 10.0.0.2 weight=1;
}अनुपात कैसे काम करता है
3 और 1 के वज़न के साथ, हर 4 अनुरोधों में से 3 पहले सर्वर को और 1 दूसरे सर्वर को जाता है। वज़न सापेक्ष होते हैं, इसलिए 6 और 2 से 3 और 1 जैसा ही विभाजन मिलता है।
अन्य एल्गोरिदम के साथ वज़न
वज़न राउंड रॉबिन (डिफ़ॉल्ट) और सबसे कम कनेक्शन वाले एल्गोरिदम के साथ काम करते हैं। ये ip_hash पर लागू नहीं होते, क्योंकि यह केवल क्लाइंट के IP से सर्वर चुनता है।
upstream app {
least_conn;
server 10.0.0.1 weight=5;
server 10.0.0.2 weight=2;
}बैकअप सर्वर का परिचय
backup के रूप में चिह्नित सर्वर को तब तक कोई ट्रैफ़िक नहीं मिलता, जब तक कोई प्राथमिक सर्वर उपलब्ध हो। यह तभी सक्रिय होता है जब सभी प्राथमिक सर्वर बंद हों या उन तक पहुँचा न जा सके।
upstream app {
server 10.0.0.1;
server 10.0.0.2;
server 10.0.0.9 backup;
}बैकअप का उपयोग क्यों करें
बैकअप आपको सुगम वैकल्पिक व्यवस्था देते हैं, जैसे रखरखाव पृष्ठ वाला सर्वर या द्वितीयक डेटा सेंटर, और स्वस्थ संचालन के दौरान उन्हें सामान्य ट्रैफ़िक भेजने की आवश्यकता नहीं होती।
सर्वर को बंद चिह्नित करना
किसी सर्वर को रोटेशन से स्थायी रूप से हटाने के लिए down का उपयोग करें। नियोजित रखरखाव के दौरान लाइन हटाए बिना यह उपयोगी होता है।
upstream app {
server 10.0.0.1;
server 10.0.0.2 down;
}विफलता पहचान पैरामीटर
max_fails यह तय करता है कि कितने विफल प्रयासों के बाद सर्वर को अनुपलब्ध चिह्नित किया जाए, और fail_timeout समय-अवधि तथा सर्वर के रोटेशन से बाहर रहने की अवधि तय करता है।
server 10.0.0.1 max_fails=3 fail_timeout=30s;वज़न और बैकअप को मिलाना
आप प्राथमिक सर्वरों के लिए अलग-अलग वज़न रख सकते हैं और पूरे समूह के लिए एक बैकअप रख सकते हैं। बैकअप तब तक वज़न की अनदेखी करता है, जब तक वही एकमात्र विकल्प न रह जाए।
upstream app {
server 10.0.0.1 weight=4;
server 10.0.0.2 weight=1;
server 10.0.0.9 backup;
}कनेक्शन सीमित करना
max_conns पैरामीटर किसी सर्वर के एक साथ चलने वाले कनेक्शनों की अधिकतम संख्या तय करता है। इससे अधिक वज़न होने पर भी कमज़ोर मशीन सुरक्षित रहती है।
server 10.0.0.2 weight=2 max_conns=100;वितरण का परीक्षण
बहुत से अनुरोध भेजें और प्रत्येक अपस्ट्रीम के लिए अपने अभिगम लॉग जाँचें, ताकि पुष्टि हो सके कि अनुपात वज़न के अनुरूप है। देखे गए CPU उपयोग और विलंबता के आधार पर वज़न समायोजित करें।
for i in $(seq 1 100); do curl -s http://localhost/ > /dev/null; doneत्वरित जाँच
किसी सर्वर को backup चिह्नित किया गया है। उसे अनुरोध कब प्राप्त होंगे?
पुनरावलोकन
आपने ट्रैफ़िक वितरण को बेहतर ढंग से समायोजित करना सीखा:
weight=Nट्रैफ़िक को अधिक शक्तिशाली सर्वरों की ओर झुकाता है- वज़न सापेक्ष होते हैं और राउंड रॉबिन तथा least_conn पर लागू होते हैं
backupसर्वर केवल प्राथमिक सर्वरों के विफल होने पर सक्रिय होते हैंdown,max_failsऔरmax_connsउपलब्धता नियंत्रित करते हैं
इनसे आपको असमान सर्वर समूह पर सटीक नियंत्रण मिलता है।
एआई शिक्षक के साथ API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 12
- पाठ
- 48
अक्सर पूछे जाने वाले प्रश्न
क्या “भारित लोड बैलेंसिंग और बैकअप सर्वर” पाठ निःशुल्क है?
हाँ—“भारित लोड बैलेंसिंग और बैकअप सर्वर” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“भारित लोड बैलेंसिंग और बैकअप सर्वर” में मैं क्या सीखूँगा?
भार के आधार पर सर्वरों में ट्रैफ़िक का असमान वितरण कीजिए और ऐसे बैकअप सर्वर जोड़िए, जो केवल प्राथमिक पूल विफल होने पर कार्यभार संभालें। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 4वाँ पाठ है।
“भारित लोड बैलेंसिंग और बैकअप सर्वर” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- लोड संतुलन एल्गोरिदम
- स्वास्थ्य जाँच और सर्वर निगरानी
- स्टिकी सत्र और सत्र स्थायित्व
- भारित लोड बैलेंसिंग और बैकअप सर्वर