Gniazda sieciowe równoważące obciążenia - AWS Elastic Loadbalancer

Question

Mam pytanie dotyczące sposobu ładowania balansowych gniazd internetowych za pomocą elastycznego systemu równoważenia obciążenia AWS.

Mam 2 wystąpienia EC2 za elastycznym równoważnikiem obciążenia AWS.

Po każdym logowaniu użytkownika, sesja użytkownika zostanie nawiązana z jednym z serwerów, na przykład z instancją EC21. Teraz wszystkie żądania od tego samego użytkownika będą kierowane do instancji EC21.

Teraz mam inne żądanie bezstanowe pochodzące z innego systemu. To żądanie będzie zawierało identyfikator użytkownika. To żądanie może skończyć się na instancji EC22. Mamy wysłać powiadomienie do użytkownika na podstawie ID użytkownika w żądaniu.

Teraz

1) Załóżmy, sesja użytkownika z Instance1 EC2, ale zgłoszenie jest pochodząca z Instance2 EC2. Nie jestem pewien, jak powiadomić przeglądarkę użytkownika w tym przypadku.

2) Czy istnieją ograniczenia dotyczące połączenia z Internetem, takie jak 64K i jak radzić sobie z wieloma serwerami, ponieważ użytkownik przechodzi przez moduł równoważenia obciążenia.

Dzięki

Answer 1

1. Trzeba będzie coś innego, aby powiadomić stronie serwera websocket w przeglądarce użytkownika o zdarzeniu pochodzących z innego systemu. Istnieje kilka rozwiązań opartych na subskrypcji, które mogą pomóc, ale bez znajomości szczegółów trudno jest ustalić, które rozwiązanie pasuje najlepiej. Redis jest ogólnie dobrą odpowiedzią, a Elasticache go obsługuje.

2. Znalazłem to w odniesieniu do limitów AWS ELB za: http://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_elastic_load_balancer Ale żaden z nich nie wydaje się być związane z Twoim pytaniem.

Answer 2

Żądania dotyczące stron internetowych rozpoczynają się od komunikacji HTTP przed przekazaniem do stron internetowych. Teoretycznie, jeśli w początkowym żądaniu HTTP można umieścić plik cookie, wówczas funkcje sesji klejącej ELB umożliwiłyby skierowanie stron internetowych do określonych instancji EC2. Jednak twój klient sieci Web może tego nie obsługiwać.

Preferowanym rozwiązaniem byłoby uczynienie instancji EC2 bezstanowymi. Przechowuj dane sesji websocket w AWS Elasticache (albo Redis albo Memcached), a następnie połączenia przychodzące będą miały dostęp do sesji niezależnie od tego, która instancja EC2 jest używana.

Zaletą tego rozwiązania jest usunięcie zależności od poszczególnych instancji EC2, a aplikacja skaluje i lepiej radzi sobie z awariami.

Jeśli ELB ma zbyt wiele połączeń przychodzących, powinien skalować się automatycznie. Chociaż nie mogę znaleźć odniesienia do tego. ELB są stosunkowo powolne w skali - minuty, a nie sekundy, jeśli spodziewasz się gwałtownych wzrostów natężenia ruchu, wtedy AWS może "wstępnie ogrzać" więcej zasobów ELB dla ciebie. Odbywa się to za pośrednictwem żądań wsparcia.

Należy również uwzględnić limit czasu połączenia ELB. Domyślnie jest to 60 sekund, można go zwiększyć za pomocą konsoli lub interfejsu API AWS. Twoja aplikacja musi wysłać co najmniej 1 bajt ruchu przed upływem limitu czasu lub ELB zrzuci połączenie.

Answer 3

Niedawno musiałem podłączyć haczyki crossbar.io za pomocą ALB.Zasadniczo istnieją dwie rzeczy do rozważenia. 1) Musisz ustawić lepkość na 1 dzień na atrybutach grupy docelowej. 2) Potrzebujesz czegoś na tym samym porcie, który zwraca stronę statyczną, jeśli połączenie nie jest uaktualnione, lub osobnego portu obsługującego statyczną stronę sieci Web z niestandardową kontrolą kondycji określającą port w grupie docelowej. Przejdź do ALB przez ELB, ALB mają wsparcie dla ws: // i wss: //, brakuje im jedynie kontroli stanu przez websockets.