Scott Tiger Tech Blog

Blog technologiczny firmy Scott Tiger S.A.

Odporność na awarie i odtwarzanie po awarii w chmurze AWS

Autor: Piotr Karpiuk o środa 21. Czerwiec 2017

Odporność na awarie

Podstawą odporności aplikacji chmurowej na awarie jest przygotowanie własnych obrazów instancji EC2 (AMI), aby być w stanie szybko uruchomić nową instancję maszyny wirtualnej. Praktykuje się nawet trzymanie w odwodzie gotowej uruchomionej instancji zapasowej (ang. spare instance) aby wprowadzenie jej do aplikacji sprowadzało się tylko do przemapowania elastycznego adresu IP.

Jeśli instancje wchodzące w skład aplikacji są bezstanowe i systematycznie podmieniane na nowsze wersje, aplikacja cały czas się odświeża.

Autoskalowanie zwykle jest używane celem dostosowania architektury sieciowej do bieżącego zapotrzebowania na zasoby, ale jak najbardziej możemy wykorzystać je do automatycznego, zaplanowanego podmieniania instancji po upływie określonego czasu, aby zapobiec chociażby wyciekom pamięci i innego rodzaju przejawom degradacji.

Pomimo tego że wolumeny EBS przechowują dane w sposób redundantny (dzięki czemu są co najmniej 20-krotnie mniej awaryjne niż przeciętny dysk twardy na rynku), łatwo jest zrobić ich migawkę (ang. snapshot) przechowywaną w S3, na podstawie której łatwo utworzyć nowy wolumen EBS.

Na szkielet odpornej na awarie aplikacji rozproszonej dobrze się nadaje usługa SQS, czyli kolejka komunikatów. Każda kolejka ma przypisany URL, przez co może być dostępna spoza chmury, o ile pozwalają na to uprawnienia (Access Control List, ACL). SQS świetnie się nadaje do rozrzucania zadań pomiędzy instancje, zwłaszcza w połączeniu z autoskalowaniem, które dopasowuje liczbę instancji do ilości zadań zalegających w kolejce. Nawet jeśli zdarzy się że wszystkie instancje przetwarzające padną, kolejka przechowuje komunikaty do 4 dni.

Usługa S3 szczególnie dobrze nadaje się do przechowywania obiektów binarnych i choć sama jest skalowalna i odporna na awarię, to może też dobrze zabezpieczać przed błędami dewelopera – dzięki włączeniu wersjonowania dla wybranych kubełków można łatwo odzyskać nieopatrznie skasowane obiekty.

Usługa RDS (relacyjnych baz danych) domyślnie tworzy backupy danych i logów każdej bazy. Na żądanie można robić migawki całych instancji RDS, co pozwala później uruchomić z takiej migawki instancję aby np. odtworzyć przypadkowo usunięte przez administratora dane. Dodatkową opcją jest tworzenie synchronicznej rezerwowej repliki bazy danych w osobnej strefie dostępności (ang. availability zone, AZ).

AWS Storage Gateway to usługa która pozwala bezpiecznie i wydajnie podmontować usługi AWS przechowujące dane do lokalnej infrastruktury sieciowej klienta. Dostępne są trzy rodzaje konfiguracji:

  • Cached volumes – wszystkie dane są przechowywane na S3, a dodatkowo często używane dane są przechowywane w lokalnym cache’u.
  • Stored volumes – wszystkie dane są przechowywane lokalnie, a do S3 wykonywane są asynchroniczne backupy dla automatycznie zaplanowanych punktów w czasie.
  • Virtual tape library (VTL) – wygląda to jak nielimitowana kolekcja wirtualnych taśm dostępnych za pośrednictwem przemysłowego standardu iSCSI. Taśmy można składować w wirtualnej bibliotece umiejscowionej w S3 (ang. virtual tape library, VTL) lub (taniej) na wirtualnej półce w Glacierze (ang. virtual tape shelf, VTS).

Odtwarzanie po awarii

RTO (ang. Recovery time objective)
Czas w jakim należy przywrócić procesy po wystąpieniu awarii. Przykładowo, jeśli RTO wynosi 2h a awaria wydarzyła się o godzinie 12 w południe, odtwarzanie danych po awarii powinno zakończyć się nie później niż o godzinie 14.
RPO (ang. Recovery point objective)
Akceptowalny poziom utraty danych wyrażony w czasie. Przykładowo, jeśli RPO wynosi 1h a awaria wydarzyła się o godzinie 12 w południe, dane zostaną odtworzone co najmniej do godziny 11.
Przełączenie awaryjne (ang. failover)
Przekierowanie ruchu użytkowników na środowisko zapasowe w razie awarii środowiska głównego
Powrót po awarii (ang. failback)
Operacja odwrotna do przełączenia awaryjnego
Dzień gry (ang. game day)
Dzień, w którym intencjonalnie psujemy środowisko główne aby wymusić przełączenie awaryjne i przetestować je.

Scenariusze odtwarzania po awarii

Na poniższym obrazku przedstawiono kilka tradycyjnych technik odtwarzania po awariach, uporządkowanych według tego jak szybko system może zostać przywrócony do stanu użyteczności.

Środowisko chmurowe jest wygodne dla implementacji wszelkich technik odtwarzania po awariach, ponieważ płacimy tu tylko za te zasoby które wykorzystujemy, a przydział nowych zasobów (np. gdy nastąpi awaria środowiska głównego) liczony jest w minutach.

Pilot light

Technika pilot light odnosi się do scenariusza, w którym w chmurze cały czas działa minimalna wersja środowiska rezerwowego. Nazwa pochodzi ze świata grzejników gazowych – w takim grzejniku cały czas obecny jest płomyk, który w chwili włączenia ogrzewania przemienia się w docelowy duży płomień.

Typowa implementacja tego wzorca to postawienie w chmurze AWS repliki bazy danych (kluczowy komponent aplikacji), a w razie potrzeby środowisko rozszerza się o instancje EC2 uruchomione na podstawie gotowych obrazów AMI. Ponieważ skalowanie jest łatwe do przeprowadzenia w chmurze AWS, „płomyk” może być małą instancją, która w razie potrzeby może zostać dość szybko przeskalowana w górę. Najlepiej jednak w ogólności w miarę możliwości wdrożyć skalowanie poziome tam gdzie to tylko możliwe.

Warm standby

Ta technika jest nieco bardziej rozbudowaną wersją poprzedniej. Mamy tu do czynienia z przeskalowaną w dół w pełni funkcjonalną wersją aplikacji działającą w chmurze, zdatną do testów ale wymagającą przeskalowania do przyjęcia prawdziwych użytkowników.

Literatura

Share and Enjoy:
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Śledzik
  • Blip
  • Blogger.com
  • Gadu-Gadu Live
  • LinkedIn
  • MySpace
  • Wykop

Zostaw komentarz

XHTML: Możesz użyć następujących tagów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>