Jak zautomatyzować przełączanie awaryjne na EC2?

Z ludzi zarządzających własnymi klastrami (tj. Nie używających / nie płacących za Amazon Autoscale, Rightscale, Scalr itp.), W jaki sposób zarządzasz swoimi instancjami na EC2 i radzisz sobie (np.) Z przełączaniem awaryjnym? Zastanawiam się, czy większość ludzi kończy pisanie własnych skryptów przeciwko interfejsowi API EC2, jak podejrzewam.

Takie jest z pewnością nasze podejście: zbuduj własnego demona monitorowania / restartowania opartego na Python Boto, który działa poza witryną, nasłuchując zachowań UDP z naszych instancji. W przypadku awarii wykonujemy migawki woluminów, rejestrujemy obrazy, uruchamiamy nowe wystąpienia, usuwamy stare woluminy i tak dalej.

Za każdym razem, gdy hakujemy nasze skrypty, myślę, że muszą istnieć narzędzia open source, które już rozwiązują te problemy i które nie mają ograniczeń (powiedzmy) Scalr, ale zawsze wracam z Google z pustymi rękami. (Rzeczy takie jak Scalr są dość ograniczone w obsługiwanym zestawie / wersjach / konfiguracjach oprogramowania i mają wyspecjalizowane i IMO kłopotliwe sposoby manipulowania tymi ustawieniami.)

Ponadto ekosystem Linux-HA / Pacemaker (Heartbeat, ldirectord itp.) Brzmi, jakby nie był tak naprawdę odpowiedni dla EC2 . (Ale potem znalazłem to - choć nie jestem pewien, że to naprawdę rozwiązanie wysokiej jakości).

Cóż, nie chcę po prostu powiedzieć oczywistości, ale ogólną ideą jest przeniesienie tej złożoności na usługi zarządzane przez Amazon.

Na froncie użyłbyś Amazon Elastic Load Balancing (ELB), aby zapewnić wysoce dostępne równoważenie obciążenia. Z tyłu używasz Amazon Relational Database Service (hostowany MySQL), SimpleDB i S3 do przechowywania. Wszystkie z nich są zarządzane przez Amazon i zawierają pewną obsługę wysokiej dostępności / przełączania awaryjnego.

Zwykle pozostawia to serwery aplikacji WWW i wszelkie mniej popularne typy serwerów, których możesz używać (serwery renderujące, samodzielnie zainstalowane magazyny danych NoSQL itp.).

Serwery aplikacji internetowych są zwykle obsługiwane wystarczająco dobrze, dzięki kontroli poprawności wbudowanej w ELB. Możesz zaakceptować niewielki spadek wydajności, gdy jeden serwer WWW nie działa, lub konsekwentnie dostarczać serwer +1 więcej, niż potrzebujesz. Lub jeśli twoja konfiguracja jest prosta, to kiedy serwer aplikacji internetowej zawiedzie, ELB wraz z Cloudwatch może automatycznie odrodzić nowy serwer aplikacji internetowych.

Własne serwery niestandardowe to inna sprawa. W tym przypadku to prawda, że ​​jesteś sam i będziesz musiał zadowolić się wbudowanymi metodami aplikacji lub skleić taśmą coś z niestandardowymi skryptami / narzędziami typu open source HA.

Zakup rozwiązania Rightscale może być zbyt drogie. Ale tańsze narzędzia Amazon, takie jak ELB, podstawowe ostrzeżenia CloudWatch (teraz bezpłatne dla rozdzielczości 5 minut) lub AutoScale są tego warte, jeśli potrzebujesz wysokiej dostępności.

RightScale zawiera kilka świetnych artykułów na temat automatyzacji przełączania awaryjnego na EC2. Podczas gdy większość z nich pokazuje, jak to zrobić za pomocą samej RightScale, zasady są ogólne i prawdopodobnie są pomocne dla każdego, kto myśli o tym, jak skonfigurować architekturę przełączania awaryjnego na EC2.

Opisane przez Ciebie problemy (HA, monitorowanie niestandardowych serwerów, usługi „tapingu”) są zazwyczaj obsługiwane przez dostawcę PaaS. Skale praw i Skalr zostały już wspomniane w poprzedniej odpowiedzi i istnieją dodatkowe dobre opcje (zobacz tutaj kilka opcji PaaS:

/programming/9542784/looking-for-paas-providers-recommendations )

Zastanów się, który z dostawców najlepiej odpowiada potrzebom.

Termin powiadomienia: Pracuję dla cloudify, dostawcy PaaS typu open source.

Niedawno napisałem post na naszym blogu inżynieryjnym o tym, jak używać ELB w połączeniu z Auto Scaling, aby osiągnąć automatyczne przełączanie awaryjne dla dowolnej aplikacji. Obejmuje to, w jaki sposób można użyć kontroli poprawności ELB do pingowania stanu aplikacji i wyzwalania akcji automatycznego skalowania.

Instalujesz puls na obu serwerach. Podłączasz elastyczny adres IP do „aktywnego” serwera. Skonfigurujesz skrypt, aby wykonać przełączenie awaryjne, inicjując żądanie interfejsu API w celu uzyskania elastycznego adresu IP. Gdy tylko serwer „rezerwowy” uzyska elastyczny adres IP ( zajmuje około 30-60 sekund) może być master / active.

Nie mam tu konkretnych szczegółów.

Amazon już zapewnia Elastyczne równoważenie obciążenia ... Po co wymyślać koło?