वेबसाकेट के लिए कुकी आधारित लोड संतुलन?

Question

मेरी स्थिति यह है कि हम वर्तमान में एक ऑनलाइन एप्लिकेशन लिखते हैं जो वेबसाकेट श्रोता के साथ सर्वर पक्ष पर Node.js का उपयोग करता है। हमारे पास दो अलग-अलग हिस्से हैं: कोई पृष्ठ परोसता है और node.js और express + ejs का उपयोग करता है, दूसरा एक पूरी तरह से अलग ऐप है जिसमें केवल websockets के लिए socket.io लाइब्रेरी शामिल है। तो यहां हम websockets भाग की स्केलेबिलिटी के इस मुद्दे पर आते हैं।

एक समाधान जो हमने पाया है वह रेडिस का उपयोग करना और सर्वर के बीच सॉकेट जानकारी साझा करना है, लेकिन आर्किटेक्चर के कारण इसे अन्य जानकारी के भार को साझा करने की आवश्यकता होगी, जो सर्वर पर भारी ओवरहेड बनाने जा रहा है।

इस परिचय के बाद, मेरा सवाल है - क्या वेबसाइकिलों के लिए कुकी आधारित लोड संतुलन का उपयोग करना संभव है? तो आइए कहें कि कुकी सर्वर = सर्वर 1 के साथ उपयोगकर्ता से प्रत्येक कनेक्शन हमेशा सर्वर 1 पर अग्रेषित किया जाएगा और कुकी सर्वर = सर्वर 2 के साथ प्रत्येक कनेक्शन सर्वर 2 के लिए fw होगा और ऐसी कुकी के साथ कनेक्शन कम से कम व्यस्त सर्वर होगा।

अद्यतन: जैसा कि एक 'उत्तर' कहता है - हाँ, मुझे पता है कि यह अस्तित्व में है। बस याद नहीं आया कि नाम चिपचिपा सत्र है। लेकिन सवाल यह है - क्या यह websockets के लिए काम करेगा? क्या कोई संभावित जटिलताएं हैं?

Answer 1

हमें हमारे नोड.जेएस उत्पादन स्टैक में एक समान समस्या दिखाई दे रही थी। हमारे पास वेबस्केट्स का उपयोग करने वाले दो सर्वर हैं जो सामान्य उपयोग के मामलों के लिए काम करते हैं, लेकिन कभी-कभी लोड बैलेंसर दो सर्वरों के बीच इन कनेक्शन को उछाल देगा जो समस्याएं पैदा करेंगे। (हमारे पास बैकएंड पर सत्र कोड है जो इसे ठीक करना चाहिए था, लेकिन इसे ठीक से संभाल नहीं पाया था।)

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

निम्नलिखित में हमारे पास वर्तमान में मौजूद है जो बहुत अच्छी तरह से काम कर रहा है। हम अभी भी हमारे बैकएंड सर्वर के सामने बैराकुडा लोड बैलेंसर्स का उपयोग करते हैं, लेकिन हमारे पास भार संतुलन पर चिपचिपा सत्र सक्षम नहीं हैं। हमारे बैकएंड सर्वर पर, हमारे एप्लिकेशन सर्वर के सामने हैप्रोक्सी है जो वेबसाकेट्स का सही ढंग से समर्थन करता है, और स्टिकी सत्र को 'राउंडबाउट' तरीके से प्रदान कर सकता है।

---

अनुरोध प्रवाह सूची

1. आवक क्लाइंट अनुरोध सक्रिय बैकएंड सर्वर
2. HAProxy के लिए अनुरोध और चेक प्राप्त करता है दोनों में से किसी के लिए प्राथमिक बाराकुडा लोड बैलेंसर
3. लोड बैलेंसर आगे हिट नई 'चिपचिपा कुकी'
4. कुकी के आधार पर, हैप्रोक्सी आगे सही बैकएंड एप्लिकेशन सर्वर पर

---

अनुरोध प्रवाह आरेख

WebSocket Request /--> Barracuda 1 -->\ /--> Host 1 -->\ /--> App 1 
------------------->      -->    --> 
        \--> Barracuda 2 -->/ \--> Host 2 -->/ \--> App 1 

तीर वापस एक अनुरोध है, उस अनुरोध प्रवाह में या तो बात करने के लिए हो जाते हैं यानी करने के लिए आते हैं।

---

HAProxy विन्यास विवरण

backend app_1 
    cookie ha_app_1 insert 
    server host1 10.0.0.101:80011 weight 1 maxconn 1024 cookie host_1 check 
    server host2 10.0.0.102:80011 weight 1 maxconn 1024 cookie host_2 check 

ऊपर विन्यास में:

• cookie ha_app_1 insert वास्तविक कुकी नाम
• cookie host_1 check या cookie host_2 check प्रयोग किया जाता है कुकी मान सेट