सॉकेट.यो एक टीसीपी कॉन्फ़िगर किए गए वेबकैकेट पर अमेज़ॅन लोचदार लोड बैलेंसर

Question

मैं ईसी 2 पर Socket.io चलाने वाले नोडजेएस अनुप्रयोग सर्वरों का एक समूह स्थापित करने की योजना बना रहा हूं, और मैं उनके बीच लोड फैलाने के लिए Elastic Load Balancer का उपयोग करना चाहता हूं। मुझे पता है कि ईएलबी बॉक्स के बाहर Websockets का समर्थन नहीं करता है, लेकिन मैं here in Scenario 2 वर्णित सेटअप का उपयोग कर सकता हूं।

the blog post में बताया गया है, हालांकि, मुझे लगता है कि इस सेटअप कोई सत्र आत्मीयता या स्रोत आईपी जानकारी प्रदान करता है नोटिस:

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

क्या सॉकेट.io अभी भी इन परिस्थितियों में काम करेगा? या एसएसएल के साथ लोड बैलेंसर के पीछे सॉकेट.ओ ऐप सर्वर का एक सेट रखने का दूसरा तरीका है?

संपादित करें: टिम कैसवेल इस पहले से ही here करने के बारे में बात करता है। क्या कोई पोस्ट है यह बताते हुए कि इसे कैसे सेट किया जाए? फिर यहां कोई सत्र चिपचिपापन नहीं है, लेकिन चीजें ठीक काम कर रही हैं।

एक तरफ, चिपचिपा सत्र वास्तव में websockets के साथ आवश्यक हैं? क्या सूचना नए और अलग अनुरोधों के रूप में यात्रा करती है या क्या केवल एक अनुरोध + कनेक्शन है जो सभी जानकारी के साथ चलता है?

Answer 1

अब आप हाल ही में एडब्ल्यूएस द्वारा लॉन्च किए गए नए एप्लिकेशन लोड बैलेंसर का उपयोग कर सकते हैं।

एएलबी (एप्लिकेशन लोड बैलेंसर) के साथ ईएलबी (अब क्लासिक लोड बैलेंसर कहा जाता है) को प्रतिस्थापित करें और चिपचिपा सत्र सक्षम करें।

एएलबी वेब सॉकेट का समर्थन करता है। यह काम कर जाना चाहिए।

https://aws.amazon.com/blogs/aws/new-aws-application-load-balancer/

http://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html

Answer 2

जैसा कि मैंने पोस्ट में उल्लेख किया है, हम केवल ईएलबी का उपयोग http-प्रॉक्सी सर्वरों के क्लस्टर में एसएसएल टर्मिनेट और लोड-बैलेंस के लिए करते हैं जो वेबसाइकिलों का समर्थन करते हैं। ईएलबी सीधे वेबसाइकिल सर्वर से बात नहीं करता है। HTTP प्रॉक्सी क्लस्टर सत्र चिपचिपापन सुनिश्चित करने के लिए कनेक्ट करने के लिए सही socket.io सर्वर को देखता है।

Answer 3

सॉकेट.ओसी एक टीसीपी ईएलबी के साथ भी बॉक्स से बाहर काम नहीं करता है क्योंकि यह websockets से कनेक्शन को अपग्रेड करने से पहले दो HTTP अनुरोध करता है।

पहला कनेक्शन प्रोटोकॉल स्थापित करने के लिए उपयोग किया जाता है, क्योंकि socket.io सिर्फ websockets से अधिक का समर्थन करता है।

GET /socket.io/1/?t=1360136617252 HTTP/1.1 
User-Agent: node-XMLHttpRequest 
Accept: */* 
Host: localhost:9999 
Connection: keep-alive 

HTTP/1.1 200 OK 
Content-Type: text/plain 
Date: Wed, 06 Feb 2013 07:43:37 GMT 
Connection: keep-alive 
Transfer-Encoding: chunked 

47 
xX_HbcG1DN_nufWddblv:60:60:websocket,htmlfile,xhr-polling,jsonp-polling 
0 

दूसरा अनुरोध वास्तव में कनेक्शन के उन्नयन के लिए प्रयोग किया जाता है:

GET /socket.io/1/websocket/xX_HbcG1DN_nufWddblv HTTP/1.1 
Connection: Upgrade 
Upgrade: websocket 
Sec-WebSocket-Version: 13 
Sec-WebSocket-Key: MTMtMTM2MDEzNjYxNzMxOA== 
Host: localhost:9999 

HTTP/1.1 101 Switching Protocols 
Upgrade: websocket 
Connection: Upgrade 
Sec-WebSocket-Accept: 249I3zzVp0SzEn0Te2RLp0iS/z0= 

ऊपर दिए गए उदाहरण देख सकते हैं xX_HbcG1DN_nufWddblv अनुरोधों के बीच एक साझा महत्वपूर्ण है। यही समस्या है। ईएलबी राउंड-रॉबिन रूटिंग करते हैं, जिसका मतलब है कि अपग्रेड अनुरोध प्रारंभिक वार्ता में भाग लेने से पहले सर्वर को हिट करता है। इस प्रकार, सर्वर को पता नहीं है कि ग्राहक कौन है।

इन-मेमोरी स्टेटफुल डेटा डेटा-बैलेंसिंग का दुश्मन है। शुक्र है, socket.io इसके बजाय डेटा स्टोर करने के लिए Redis का उपयोग करने का समर्थन करता है। यदि आप अपने सर्वर को कई सर्वरों के साथ साझा करते हैं, तो वे अनिवार्य रूप से सभी ग्राहकों के सत्र साझा करते हैं।

रेडिस की स्थापना के विवरण के लिए socket.io wiki page देखें।

Answer 4

जब आप एक बादल एक लोड संतुलन/रिवर्स प्रॉक्सी, राउटर आदि है कि में एक सर्वर चलाने के लिए, आपको उसे कॉन्फ़िगर करना ठीक से काम करने की जरूरत है, खासकर जब आप सर्वर को स्केल कई उदाहरणों का उपयोग करने के लिए।

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

जब आप क्लाउड वातावरण में अपना ऐप स्केल करते हैं, तो लोड बैलेंसर (क्लाउड फाउंड्री के मामले में Nginx) खत्म हो जाएगा, और अनुरोध सॉकेट.ओ को तोड़ने के कारण विभिन्न उदाहरणों पर भेजे जाएंगे।

ऐसी स्थितियों में सहायता के लिए, लोड बैलेंसर्स में 'चिपचिपा सत्र' उर्फ ​​'सत्र एफ़िनिटी' नामक एक सुविधा है। मुख्य विचार यह है कि यदि यह प्रॉपर्टी सेट की गई है, तो पहले लोड-संतुलित अनुरोध के बाद, निम्नलिखित सभी अनुरोध एक ही सर्वर इंस्टेंस पर जाएंगे।

क्लाउड फाउंड्री में, कुकी-आधारित चिपचिपा सत्र कुकी jsessionid सेट करने वाले ऐप्स के लिए सक्षम हैं।

नोट: jsessionid कुकी नाम आमतौर पर जावा/स्प्रिंग अनुप्रयोगों में सत्रों को ट्रैक करने के लिए उपयोग किया जाता है। क्लाउड फाउंड्री बस सभी ढांचे के लिए चिपचिपा सत्र कुकी के रूप में इसे गोद ले रहा है।

तो, सभी ऐप्स को socket.io काम करने के लिए jsessionid नाम के साथ एक कुकी सेट करने की आवश्यकता है।

app.use (कुकीपार्सर); app.use (express.session ({store: sessionStore, key: 'jsessionid', गुप्त: 'आपका रहस्य यहाँ}});

एक्सप्रेस नाम jsessionid के साथ एक सत्र कुकी सेट:

तो ये कदम हैं। जब socket.io कनेक्ट होता है, तो वह उसी कुकी का उपयोग करता है और लोड बैलेंसर हिट करता है लोड बैलेंसर हमेशा उसी सर्वर पर रूट करता है जिसे कुकी सेट किया गया था। यदि आप एप्लिकेशन लोड बैलेंसर का उपयोग कर रहे हैं तो स्टिकी सत्र सेटिंग्स लक्ष्य पर है समूह स्तर