Scott Tiger Tech Blog

Blog technologiczny firmy Scott Tiger S.A.

Archiwum dla Czerwiec 21st, 2017

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

Autor: Piotr Karpiuk o 21. czerwca 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).

Czytaj więcej »

Tags:
Napisany w AWS, Cloud computing | Brak komentarzy »