Disaster recovery w Azure (1) - teoria

2022-08-17

Chciałbym niniejszym zainicjować cykl wpisów o disaster recovery w Azure, czyli tych wszystkich rozwiązaniach, które oferuje nam chmura od Microsoftu, a które mogą nas uchronić przed pewnymi poważnymi problemami. Pomysł jest taki, że najpierw opiszę ogólnie, co kryje się pod tym terminem i jakie są możliwe rodzaje owych katastrof, a w kolejnych odcinkach będę się przyglądał konkrentym rodzajom zasobów na Azure i sprawdzał, jakie są oferowane “siatki bezpieczeństwa”.

Co może pójść nie tak?

Zaczynając od początku, podstawowym pojęciem jest business continuity, czyli zapewnienie ciągłości “biznesu” (systemu, aplikacji etc.), na wypadek nieprzewidzianego zdarzenia, zaburzającego tę ciągłość. Pamiętajmy więc, że tutaj chodzi o to, żeby “przetrwać” po katastrofie, niż żeby do niej nie dopuścić (inna sprawa, że np. pewnym katastrofom zapobiec nie możemy, bo są od nas niezależne). Można więc powiedzieć, że procedury disaster recovery i wszystkie zabiegi z tym związane są swoistym ubezpieczeniem na życie - nie zapobiegają wprost katastrofie bądź awarii, ale ułatwiają dalsze funkcjonowanie; tak samo jak ubezpieczenie na życie zdrowia (ani tym bardziej życia) ubezpieczonemu nie przywróci, ale wypłacone środki mogą pomóc w życiu po katastrofie.

Jeśli mówimy o systemach IT, a zwłaszcza zasobach w chmurze, to w zasadzie możemy mieć dwa rodzaje “katastrof”:

  • niedostępność serwisów chmurowych, czyli nieprzewidziana awaria po stronie Azure’a spowodowana dowolnym czynnikiem: katastrofą naturalną, błędem ludzkim itp.,
  • “czynnik ludzki” - błąd ludzki “naszego” pracownika bądź wroga działalność włamywacza, powodująca np. usunięcie bazy danych.

“Czynnik ludzki” może spowodować:

  • utratę i/lub uszkodzenie danych,
  • niedostępność naszej aplikacji (serwisu) na skutek błędnej konfiguracji.

Natomiast jeśli chodzi o niedostępność serwisów chmurowych, to sam Microsoft wyróżnia trzy poziomy awarii:

  1. Lokalna - dotyczy danego serwera bądź serwerów.
  2. Strefowa - dotyczy całego data center.
  3. Regionalna - dotyczy całego regionu.

Te poziomy wynikają z architektury infrastruktury chmurowej, dokładniej zanurkujemy w temat trochę niżej.

RPO vs RTO

Gdy mowa o business continuity bądź disaster recovery, często pojawiają się dwa terminy: RPO i RTO. Wyjaśnijmy je pokrótce.

RPO - recovery point objective - to jest najdłuższy odcinek czasu (liczony wstecz od momentu awarii), dla którego utrata danych jest możliwa. Łopatologicznie: jeśli w Wordzie mamy auto-save co 5 minut, to maksymalnie 5 minut pracy możemy stracić. RTO - recovery time objective - to jest czas, liczony od momentu awarii, w którym aplikacja/serwis wraca do normalnego funkcjonowania. W przykładzie z Wordem: jeśli awaria skończyła się bluescreenem, to RTO będzie równy czasowi potrzebnemu na restart komputera, włączenie Worda i wybranie opcji odzyskiwania plików.

Gdy będziemy rozważać różne mechanizmy disaster recovery, te dwa terminy będą się przewijać - i one pozwalają ocenić, ile daje nam konkretny mechanizm, zwłaszcza w porównaniu z pozostałymi opcjami.

Architektura infrastruktury Azure

Aby nie powtarzać tego przy omawianiu kolejnych zasobów, warto rzucić okiem, jak wysokopoziomowo zorganizowana jest infrastruktura chmury Azure. Pomijając najniższy poziom konkrentych serwerów lub ich grup - podstawową jednostką jest centrum danych. Jedno lub kilka centrów danych tworzą strefę (availability zone). Z kolei 3 availability zones razem tworzą region. Regiony zaś mają swoje “siostrzane” regiony (powiedzmy najbliższego sąsiada), z którego mogą korzystać np. do tworzenia backupów odpornych na awarię oryginalnego regionu. Oczywiście geografia i szczegóły rozmieszczenia centrów danych i stref mają znaczenie: z jednej strony muszą być położone na tyle blisko, aby zapewniać najmniejsze opóźnienia sieciowe (np. availability zones muszą mieć opóźnienie poniżej 2ms w obie strony), a z drugiej - być jednak niezależne np. jeśli chodzi o źródło energii bądź narażenie na katastrofy naturalne. (Ciekawe, jak to będzie rozwiązane podczas budowy regionu Poland Central - która przecież właśnie trwa - czy można tak na oko przyjąć, że np. jedna zone’a będzie zasilana z Ostrołęki, a druga - z Kozienic? :D)


Robert Skarżycki - zdjęcie profilowe

Pisanina, której autorem jest Robert Skarżycki - programista .NET, mąż szczęśliwej żony, rodzic
moje bio
mój Twitter
mój LinkedIn
moje szkolenia i warsztaty

© 2022, Built with Gatsby & passion