Jak zautomatyzować przełączanie awaryjne na EC2?

13

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).

amazon-ec2 failover heartbeat amazon-elastic-ip scalr Yang
źródło

Odpowiedzi:

5

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.

Jesper M.
źródło
3
Znamy zestaw funkcji AWS, a także ich ograniczenia. Przykładowo, dostęp do ELB jest uzyskiwany za pośrednictwem RR CNAME, które nie mogą współistnieć z RR SOA, a tym samym nie mogą obsługiwać TLD, a ponadto nie mogą być dostępne przez statyczne adresy IP - frustracje szeroko powtarzają się na forach. Weźmy drugi przykład, tak, RDS to MySQL, który jest ogromnym ograniczeniem. Tak, jesteśmy zainteresowani automatyzacją przełączania awaryjnego naszych własnych typów maszyn. Tak, wdrożenie chmury prywatnej jest dla nas istotne. Tak, jestem po prostu ciekawa. Itd.
Yang,
2
@Yang: Powinieneś był bardziej ostrożnie sformułować swoje pytanie i zaoszczędzić mi trudu wpisania mojej odpowiedzi. Nie ma jednego uniwersalnego rozwiązania dla HA; zależy to od danej usługi, sposobu utrzymywania stanu, właściwości przełączania awaryjnego protokołu itp. Masz rację co do ograniczeń / trudności w korzystaniu z typowych narzędzi HA na poziomie IP w EC2. Ale nie ma jednej odpowiedzi, która miałaby zastosowanie do „HA w AWS”.
Jesper M,
0

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.

Suman
źródło
0

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.

Barak
źródło
0

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.

Deweloper
źródło
0

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.

Amir Mehler
źródło
-1

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

Chris S.
źródło
3
Z powodu różnych ograniczeń ELB? Ponieważ wymaga CNAME i nie może obsługiwać zarówno foo.com, jak i www.foo.com? Ponieważ chcę zaimplementować niestandardową logikę planowania? Ponieważ jestem ciekawy, jak samodzielnie zaimplementowałbyś ELB w klastrze niewiarygodnych maszyn wirtualnych? Wybierz swój.
Yang,
@ Yang, robisz to tak samo, jak gdyby były serwerami w twoim centrum danych. Nie ma zasadniczej różnicy, nie ma magicznego sosu, który czyni z niego środowisko chmurowe.
Chris S,