Jak wdrożyć skalowalny, niezawodny klaster haproxy na Amazon EC2?

Potrzebujemy bardziej zaawansowanych funkcji niż zapewnia ELB (głównie kontrola L7), ale nie jest oczywiste, jak radzić sobie z takimi rzeczami, jak bicie serca i wysoka dostępność za pomocą czegoś takiego jak haproxy za pomocą EC2. Istnieje duże prawdopodobieństwo, że potrzebujemy 3 lub więcej haproksy węzłów w klastrze, więc proste bicie serca między dwoma węzłami nie zadziała.

Wydaje się, że dobrym pomysłem byłoby posiadanie warstwy pulsu przed węzłami haproxy, być może przy użyciu IPVS, ale obsługa zmian konfiguracji wraz ze zmianami klastra EC2 (albo przez zamierzone zmiany, takie jak rozszerzenie lub niezamierzone, jak utrata Węzeł EC2) wydaje się nietrywialny.

Najlepiej byłoby, gdyby rozwiązanie obejmowało co najmniej dwie strefy dostępności.

W odpowiedzi na pytania: Nie, sesje nie są lepkie. I tak, będziemy potrzebować SSL, ale teoretycznie może to być całkowicie obsłużone przez inną konfigurację - jesteśmy w stanie skierować ruch SSL w inne miejsce niż ruch inny niż SSL.

OK, sam nigdy nie budowałem rozwiązania równoważenia obciążenia AWS z ruchem na poziomie SmugMug, ale myśląc o teorii i usługach AWS, przychodzi mi na myśl kilka pomysłów.

W pierwotnym pytaniu brakuje kilku rzeczy, które mają wpływ na projekt równoważenia obciążenia:

1. Przyklejone sesje czy nie? Bardzo dobrze jest nie używać sesji lepkiej i po prostu pozwól wszystkim modułom równoważenia obciążenia (LB) korzystać z okrągłego robina (RR) lub losowego wyboru backendu. RR lub losowe wybory zaplecza są proste, skalowalne i zapewniają równomierny rozkład obciążenia we wszystkich okolicznościach.
2. SSL czy nie? To, czy protokół SSL jest używany, czy nie, i jaki procent żądań ma ogólnie wpływ na projekt równoważenia obciążenia. Często lepiej jest zakończyć protokół SSL tak wcześnie, jak to możliwe, aby uprościć obsługę certyfikatów i utrzymać obciążenie procesora SSL z dala od serwerów aplikacji WWW.

Odpowiadam z perspektywy utrzymania wysokiej dostępności samej warstwy równoważącej obciążenie . Utrzymywanie serwerów aplikacji HA jest właśnie wykonywane dzięki sprawdzeniom kondycji wbudowanym w moduł równoważenia obciążenia L7.

OK, kilka pomysłów, które powinny zadziałać:

1) „Sposób AWS”:

• Pierwsza warstwa, z przodu, użyj ELB w trybie L4 (TCP / IP).
• Druga warstwa, użyj instancji EC2 z wybranym modułem równoważenia obciążenia L7 (nginx, HAProxy, Apache itp.).

Korzyści / pomysł: równoważniki obciążenia L7 mogą być dość prostymi EC2 AMI, wszystkie sklonowane z tego samego AMI i przy użyciu tej samej konfiguracji. W ten sposób narzędzia Amazon mogą obsłużyć wszystkie potrzeby HA: ELB monitoruje moduły równoważące obciążenie L7. Jeśli L7 LB zginie lub przestanie odpowiadać, ELB i Cloudwatch wspólnie odradzają nową instancję automatycznie i przenoszą ją do puli ELB.

2) „Okrągły robin DNS ze sposobem monitorowania:”

• Użyj podstawowego okrągłego robota DNS, aby uzyskać gruboziarnisty rozkład obciążenia na kilka adresów IP. Powiedzmy, że publikujesz 3 adresy IP dla swojej witryny.
• Każdy z tych 3 adresów IP to elastyczny adres IP AWS (EIA), powiązany z instancją EC2, z wybranym modułem równoważenia obciążenia L7.
• Jeśli umiera EC2 L7 LB, zgodny użytkownik (przeglądarka) powinien po prostu użyć jednego z pozostałych adresów IP .
• Skonfiguruj zewnętrzny serwer monitorowania. Monitoruj każdy z 3 EIP. Jeśli ktoś przestanie odpowiadać, użyj narzędzi wiersza polecenia AWS i skryptów, aby przenieść EIP do innej instancji EC2.

Korzyści / pomysł: Zgodne programy użytkownika powinny automatycznie przełączyć się na inny adres IP, jeśli przestanie on odpowiadać. Dlatego w przypadku awarii tylko 1/3 użytkowników powinna zostać dotknięta, a większość z nich nie powinna nic zauważyć, ponieważ ich UA po cichu przechodzi na inny adres IP. A twoje zewnętrzne pole monitorowania zauważy, że EIP nie reaguje, i naprawi sytuację w ciągu kilku minut.

3) RR RR dla par serwerów HA:

Zasadniczo jest to własna sugestia Dona dotycząca prostego bicia serca między parą serwerów, ale uproszczona dla wielu adresów IP.

• Korzystając z RR RR DNS, opublikuj kilka adresów IP dla usługi. Zgodnie z powyższym przykładem powiedzmy, że publikujesz 3 adresy IP.
• Każdy z tych adresów IP trafia do pary serwerów EC2, czyli łącznie 6 instancji EC2.
• Każda z tych par używa Heartbeat lub innego rozwiązania HA wraz z narzędziami AWS, aby utrzymać 1 adres IP na żywo, w konfiguracji aktywnej / pasywnej.
• Każda instancja EC2 ma zainstalowany moduł równoważenia obciążenia L7.

Korzyści / pomysł: w całkowicie zwirtualizowanym środowisku AWS nie jest tak łatwo zrozumieć usługi L4 i tryby pracy awaryjnej. Uproszcząc do jednej pary identycznych serwerów utrzymujących przy życiu tylko 1 adres IP, łatwiej jest uzasadnić i przetestować.

Wniosek: Ponownie, nie próbowałem nic z tego w produkcji. Z moich odczuć, opcja pierwsza z ELB w trybie L4 i samodzielnie zarządzane instancje EC2, ponieważ L7 LB wydają się najbardziej dostosowane do ducha platformy AWS i gdzie Amazon najprawdopodobniej zainwestuje i rozszerzy później. To prawdopodobnie byłby mój pierwszy wybór.

Jeśli nie robisz lepkich sesji lub używasz stylu tomcat / apache (dodaj identyfikator węzła do sessionid, w przeciwieństwie do przechowywania stanu w LB), wtedy użyłbym ELB przed grupą haproxies. ELB ma wbudowaną kontrolę zdrowia, dzięki czemu możesz monitorować haproxies i usuwać dowolne z puli. O wiele mniej do skonfigurowania niż przełączanie awaryjne pulsu.

Jeśli chodzi o propagowanie zmian, nie mam świetnej odpowiedzi. Puppet jest świetny do wstępnej konfiguracji i wprowadzania zmian, ale do dodawania / usuwania węzłów zwykle chcesz szybszej odpowiedzi niż 30-minutowy interwał odpytywania.

Sam go nie używałem, ale widziałem wiele osób wspominających używanie marionetki do radzenia sobie z tego rodzaju problemami na EC2