Oparte na plikach cookie równoważenie obciążenia dla WebSockets?

Question

Moja sytuacja polega na tym, że obecnie piszemy aplikację online, która korzysta z Node.js po stronie serwera z detektorem WebSocket. Mamy dwie różne części: jedna obsługuje strony i używa node.js i express + ejs, druga to zupełnie inna aplikacja, która zawiera tylko bibliotekę socket.io dla websockets. Tak więc, oto kwestia skalowalności części websocket.

Jednym z rozwiązań, które znaleźliśmy, jest użycie informacji redis i współdzielenie gniazd między serwerami, ale ze względu na architekturę będzie wymagać współdzielenia wielu innych informacji, co spowoduje ogromne obciążenie serwerów.

Po tym wstępie moje pytanie brzmi - czy możliwe jest użycie równoważenia obciążenia opartego na plikach cookie na stronach internetowych? Dzięki temu możemy powiedzieć, że każde połączenie użytkownika z serwerem cookie = serwer1 będzie zawsze przekazywane do serwera1, a każde połączenie z serwerem plików cookie = serwer2 będzie fw na serwer2, a połączenie z takim plikiem cookie nie będzie na najmniej obciążonym serwerze.

AKTUALIZACJA: Jak jedna "odpowiedź" mówi - tak, wiem, że to istnieje. Po prostu nie pamiętam, że nazwa to lepka sesja. Ale pytanie brzmi - czy to zadziała dla stron internetowych? Czy są jakieś możliwe komplikacje?

Answer 1

Mamy podobny problem, który pojawia się w naszym stosie produkcyjnym Node.js. Mamy dwa serwery korzystające z WebSockets, które działają w normalnych przypadkach, ale czasami system równoważenia obciążenia odrzuciłby połączenie między dwoma serwerami, co mogłoby spowodować problemy. (Mamy kod sesji na zapleczu, który powinien go naprawić, ale go nie obsłużyliśmy).

Próbowaliśmy umożliwić włączenie Sticky Session na urządzeniu równoważącym obciążenie Barracudy przed tymi serwerami, ale stwierdziliśmy, że zablokuje WebSocket ruchu z powodu jego działania. Nie zbadałem dokładnie, dlaczego, ponieważ niewiele informacji jest dostępnych w Internecie, ale wydaje się, że wynika to z tego, jak system równoważący usuwa nagłówki z żądania HTTP, pobiera plik cookie i przekazuje żądanie do właściwego serwera zaplecza. Ponieważ WebSockets uruchamia się jako HTTP, ale potem uaktualnia, system równoważenia obciążenia nie zauważył różnicy w połączeniu i próbowałby wykonać to samo przetwarzanie HTTP. Spowodowałoby to awarię połączenia WebSocket, odłączenie użytkownika.

Oto, co mamy obecnie w miejscu, które działa bardzo dobrze. Nadal używamy load balancerów Barracuda przed naszymi serwerami zaplecza, ale nie mamy włączonych lepkich sesji w modułach równoważenia obciążenia. Na naszych serwerach zaplecza przed naszym serwerem aplikacji znajduje się HAProxy, który właściwie obsługuje WebSockets i może zapewniać Sticky Sesje w sposób "okrężny".

---

Lista Zapytanie Przepływ

1. przychodzące żądanie klienta uderza Podstawowej Barracuda Load Balancer
2. równoważenia obciążenia do przodu, jeden z aktywnych serwerów backend
3. HAProxy odbiera żądanie i kontroli dla nowy "lepki plik cookie"
4. Na podstawie pliku cookie, HAProxy przekazuje na właściwy serwer aplikacji backendowej

---

Zapytanie Schemat technologiczny

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

Kiedy strzały wrócić do jednego wniosku, co oznacza, że ​​wniosek może płynąć do obu momencie przepływu.

---

HAProxy Konfiguracja Szczegóły

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 

W powyższej konfiguracji:

• cookie ha_app_1 insert jest rzeczywista nazwa pliku cookie używane
• cookie host_1 check lub cookie host_2 check ustawia wartość cookie