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

25

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.

Don MacAskill
źródło
Badam, jak przeprowadzać instalacje kanarkowe przy powoli rosnącym odsetku ruchu trafiającego do nowej wersji oprogramowania, i jestem bardzo ciekawy, gdzie to się skończyło. Czy skończyłeś z jakąś sugestią Jespera?
Iain

Odpowiedzi:

14

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.

Jesper M.
źródło
1
Tak więc uwielbiam podejście nr 1, to kierunek, w którym się pochylałem, ale wciąż jest kilka interesujących błędów - nie mniej ważne jest to, że ELB nie radzi sobie z porażką całej AZ (coś, co już się zdarzyło ). Łatwe, ale na szczęście „rozwiązanie” polega na skonfigurowaniu haproxies za ELB skonfigurowanym do przekraczania AZ (być może z klastrem zapasowym w innym AZ), więc jeśli przynajmniej jeden haproxy jest w każdym AZ, powinniśmy być w porządku. Ale to tylko naśladuje, a nie eliminuje problem. Wszelkie pomysły dotyczące tego problemu?
Don MacAskill,
@Don MacAskill: Wiem, że AWS miał kilka przestojów na dużą skalę, ale radzenie sobie z AWS na poziomie wyższym niż AZ jest trudne. Przejście do frontonu w trybie multi-AZ może łatwo być pierwszym krokiem w kierunku działania całego stosu w trybie multi-AZ, i to jest cały czajnik węży ...
Jesper M
@Don MacAskill: Jedną z opcji byłoby rozpoznawanie geograficzne DNS, takie jak DynDNS Dynect -> ELB + L7 LB w jednym AZ, a inne ELB + L7 w trybie gotowości w innym AZ. (Dynect jest nie tylko świadomy geograficznie, ale także ma pewne kontrole kondycji.) DynDNS ma świetne wyniki w zakresie dostępności, ale mimo to dodanie DNS z rozpoznaniem geograficznym jest kolejnym SPOF. To, czy Dynect + równoważenie obciążenia w 2 AZ ma lepszy długoterminowy czas pracy niż tylko jeden AWS AZ, nie jest dla mnie jasne. Zobacz to, co mam na myśli, mówiąc o wielu bazach danych AZ: dev.bizo.com/2010/05/improving-global-application.html
Jesper M
@ Don MacAskill: Jeszcze jedna rzecz - pamiętaj, że jedno wystąpienie ELB może obejmować wiele AZ. Nie może obejmować wszystkich regionów EC2 . Ale jeśli użycie ELB do L7 LB w dwóch AZ w tym samym regionie jest dopuszczalne, byłoby to zdecydowanie najprostsze ... Napisałeś: „ELB nie radzi sobie bardzo dobrze z uszkodzeniem całego AZ”, być może wiesz już więcej niż Ja robię.
Jesper M,
Tak, jeśli ELB obejmuje wiele AZ i ma jakąś awarię, w której nie może dostać się do żadnego z węzłów zaplecza w AZ (są przeciążone, nie działają, zwracają 503s, cokolwiek), użytkownicy końcowi widzą te błędy - nie robi tego t zmienić trasę do innych AZ. Mam nadzieję, że to zaplanowane, ale już raz nas ugryzło.
Don MacAskill,
2

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.

Ben Jencks
źródło
1
To dobre rozwiązanie (i dobre pytanie!) Za pomocą usługi Amazon SNS można propagować zmiany konfiguracji w trybie wypychania. Potrzebujesz systemu powiadomień do dodawania / usuwania węzłów z konfiguracji haproxy.
Rafiq Maniar,
Inną opcją zarządzania serwerami zaplecza (tymi, na które przesyła haproxy), jest wysyłanie przez każdy serwer zaplecza wszystkich haproxies lub serwera konfiguracji, okresowej rejestracji (około 30 sekund). Jeśli ktoś umrze, szybko się wyrejestrowuje (a haproxy i tak powinien to zauważyć); jeśli pojawi się nowy, automatycznie zaczyna się obracać. Najwyraźniej właśnie to robi Netflix.
Ben Jencks,
1

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

JamesRyan
źródło
Tak, Puppet na EC2 sprawia, że ​​zarządzanie klastrem jest bardzo proste. Po prostu utwórz mikro wystąpienie i użyj go jako swojego nauczyciela marionetek.
Tom O'Connor,
1
Używamy marionetki w naszych centrach danych, ale jeszcze nie próbowaliśmy na EC2. Czy marionetka EC2 jest w jakiś sposób świadoma, że ​​może znaleźć węzły za pomocą instancji ec2-opisz-instancji lub coś w tym stylu i zautomatyzować konfigurację / rekonfigurację na podstawie tego wyniku? A jak poradzisz sobie z nagłym odejściem nauczyciela lalek?
Don MacAskill,
Dlaczego miałoby to nagle zniknąć?
Tom O'Connor,
Nie obsługuje EC2, ale możesz go skonfigurować, aby nowe węzły były oznaczone do podpisania podczas ich uruchamiania, i użyj zewnętrznego skryptu węzłów, aby je opisać. Napisałem trochę Pythona, aby to zrobić z SimpleDB (węzły zewnętrzne) i SQS (kolejka żądań podpisania dla nowych węzłów); programista ubuntu napisał skrypty przy użyciu S3: ubuntumathiaz.wordpress.com/2010/04/07/…
Ben Jencks
Jeśli nauczyciel marionetek nagle odejdzie, po prostu nie uruchamia manifestu, tzn. Pozostawia węzły w jakimkolwiek stanie, w jakim się znajdują.
Ben Jencks