Gniazda sieciowe równoważące obciążenie

Mam pytanie dotyczące ładowania gniazd sieciowych.

Mam serwer obsługujący gniazda sieciowe. Przeglądarki łączą się z moją witryną i każda z nich otwiera gniazdo sieciowe www.mydomain.com. W ten sposób moja aplikacja społecznościowa może przesyłać wiadomości do klientów.

Tradycyjnie, używając tylko żądań HTTP, zwiększałbym skalę, dodając drugi serwer i moduł równoważenia obciążenia przed dwoma serwerami internetowymi.

W przypadku gniazd sieciowych połączenie musi być bezpośrednio z serwerem WWW, a nie z load balancerem, ponieważ jeśli maszyna ma fizyczny limit powiedzmy 64k otwartych portów, a klienci łączyli się z load balancerem, to nie mogłem obsługiwać ponad 64 tys. jednoczesnych użytkowników.

Więc jak ja -

1. sprawić, aby klient łączył się bezpośrednio z serwerem WWW (zamiast z systemem równoważenia obciążenia), gdy strona się ładuje? Czy po prostu ładuję JavaScript z węzła, a moduły równoważenia obciążenia (lub cokolwiek innego) losowo modyfikują adres URL skryptu za każdym razem, gdy strona jest początkowo żądana?

2. poradzić sobie z falowaniem startu? Przeglądarka zauważy, że połączenie jest zamykane po wyłączeniu serwera WWW. Potrafię napisać kod JavaScript, aby spróbować ponownie otworzyć połączenie, ale węzeł zniknie na chwilę. Więc myślę, że musiałbym wrócić do modułu równoważenia obciążenia, aby zapytać o adres następnego węzła do użycia?

3. Zastanawiałem się, czy moduły równoważenia obciążenia wysyłają przekierowanie przy początkowym żądaniu, tak aby przeglądarka początkowo żądała www.mydomain.comi była przekierowywana www34.mydomain.com. Działa to całkiem dobrze, dopóki węzeł nie ulegnie awarii - a witryny takie jak Facebook tego nie robią. Jak oni to robią?

Umieść moduł równoważenia obciążenia L3, który dystrybuuje pakiety IP na podstawie skrótu źródłowego portu IP do farmy serwerów WebSocket. Ponieważ balanser L3 nie utrzymuje stanu (używając zhaszowanego portu IP źródła), będzie skalował się do prędkości okablowania na sprzęcie niższej klasy (powiedzmy 10GbE). Ponieważ dystrybucja jest deterministyczna (przy użyciu skrótu źródłowego IP-port), będzie działać z TCP (a tym samym z WebSocket).

Należy również zauważyć, że sztywny limit 64 kB dotyczy tylko wychodzącego protokołu TCP / IP dla danego (źródłowego) adresu IP. Nie dotyczy przychodzącego protokołu TCP / IP. Przetestowaliśmy Autobahn (wysokowydajny serwer WebSocket) z 200 tys. Aktywnych połączeń na 2-rdzeniowej maszynie wirtualnej z 4 GB pamięci RAM.

Należy również zauważyć, że można wykonać równoważenie obciążenia L7 na ścieżce HTTP ogłoszonej podczas wstępnego uzgadniania protokołu WebSocket. W takim przypadku moduł równoważenia obciążenia musi zachować stan (która para źródłowego adresu IP-port będzie kierowana do którego węzła zaplecza). Prawdopodobnie skaluje się do milionów połączeń, ale przy przyzwoitej konfiguracji.

Zastrzeżenie: Jestem oryginalnym autorem Autobahn i pracuję dla Tavendo.

Zauważ, że jeśli logika twojego serwera websocket działa na nodejs z socket.io, możesz powiedzieć socket.io, aby używał współdzielonego magazynu kluczy / wartości redis do synchronizacji. W ten sposób nie musisz nawet przejmować się równoważeniem obciążenia, zdarzenia będą się rozprzestrzeniać między instancjami serwera.

var io = require('socket.io')(3000);
var redis = require('socket.io-redis'); 
io.adapter(redis({ host: 'localhost', port: 6379 }));

Zobacz: http://socket.io/docs/using-multiple-nodes/

Ale w pewnym momencie Redis może stać się wąskim gardłem ...

Równoważenie obciążenia w warstwie 7 można również osiągnąć dzięki inspekcji i „funkcjom routingu”

Zobacz „Jak sprawdzać i wyrównywać obciążenie ruchu WebSockets za pomocą Stingray Traffic Manager oraz, w razie potrzeby, jak zarządzać ruchem WebSockets i HTTP odbieranym na tym samym adresie IP i porcie”. https://splash.riverbed.com/docs/DOC-1451