Jako, iż już od paru lat mam przyjemność być Product Owner’em narzędzi wspomagających proces Disaster Recovery (DR) zauważyłem, iż terminy często pojawiające się w tym kontekście jak High Availability (HA) czy Fault Tolerance (FT) są nierzadko ze sobą mylone choćby przez ludzi będących w branży IT wiele lat. Obydwa pojęcia oznaczają zdolność aplikacji do kontynuowania działania, pomimo awarii któregoś z komponentów systemu, jak serwer czy baza danych. Są jednak pomiędzy nimi pewne różnice, które postaram się wyjaśnić poniżej.
High Availability
W przypadku HA mówimy o aplikacji mającej dostępność co najmniej na poziomie 99,99%. Dla lepszego zobrazowania: są to około 53 minuty niedostępności rocznie. Należy zauważyć, iż konkretny procent jest rzeczą umowną. Niektóre źródła definiują systemy HA od 'pięciu dziewiątek' czyli 99,999%. Tak czy inaczej, aby osiągnąć minimalne 'cztery dziewiątki' wymagane jest rozłożenie komponentów aplikacji w przynajmniej dwóch lokalizacjach. Przez lokalizacje mam na myśli Data Center lub Availability Zone posługując się nomenklaturą dostawców usług chmurowych jak Azure czy AWS. Zabezpieczamy się tym samym nie tylko przed awarią pojedynczego komponentu, ale również przed awarią całego Data Center, a takie wbrew pozorom się zdarzają. Rok temu mogliśmy, na przykład, obserwować pożar u francuskiego dostawcy OHVcloud. W systemach HA nie jest jednak wymagane, aby druga lokalizacja była w pełni aktywna. Może funkcjonować w trybie pasywnym, pod warunkiem, iż mamy mechanizm, który automatycznie wykryje niedostępność i wykona przełączenie (ang. failover), na zapasową lokalizację.
Fault Tolerance
W przypadku FT dążymy do uzyskania ciągłej dostępności (100%). Tutaj komponenty muszą być aktywnie rozłożone w minimum dwóch lokalizacjach, najczęściej z wykorzystaniem Load Balancer'a. Co więcej pozostało jedna różnica, która odróżnia system FT od systemu HA. Mianowicie, w razie awarii jednej strony, pozostałe powinny umieć w pełni obsłużyć maksymalny ruch dla aplikacji. Przykładowo: jeżeli do obsłużenia maksymalnego, przewidywanego ruchu potrzebujemy 4 serwery to, żeby mówić o FT powinniśmy w każdej lokalizacji umieścić po 4 serwery lub po 2 serwery w 3 lokalizacjach. W drugiej opcji, normalnie pracuje 6 serwerów, a w przypadku awarii danego Data Center zostają 4 które potrafią obsłużyć maksymalny ruch. Widzimy więc, iż aby spełnić założenia systemu FT potrzebujemy dużej redundancji zasobów, a co za tym idzie ponosimy spore koszty. Trzeba więc solidnie przeliczyć jaki jest biznesowy koszt każdej minuty niedostępności i porównać, czy inwestowanie w taką architekturę jest opłacalne.
Disaster Recovery
Jak do terminów przedstawionych powyżej ma się samo pojęcie Disaster Recovery?
W przypadku High Availability lub Fault Tolerance mówimy o pojedynczej aplikacji lub, co najwyżej, systemie składającym się z kilku aplikacji, które zabezpieczamy przed awarią.
Disaster Recovery nazywamy z kolei kompletny proces mający na celu przełączenie całego Data Center lub jego sporej części z jednej lokalizacji na drugą. Musi więc nastąpić określone zdarzenie, takie jak pożar w Data Center, awaria któregoś z głównych komponentów sieciowych, długotrwała awaria zasilania, itp. Następnie musi zostać podjęta decyzja o przełączeniu np. przez zarząd firmy, a następnie według planu,
realizowane jest samo przełączenie w koordynowany sposób. Czyli w odpowiedniej kolejności przenoszone i weryfikowane są wszystkie aplikacje działające w feralnej lokalizacji.
W przypadku aplikacji HA (w konfiguracji Active-Active) bądź FT nie wykonujemy żadnego przełączenia, ponieważ powielone komponenty są cały czas aktywne w drugiej lokalizacji. W ich przypadku, w ramach procesu DR, wykonywana jest tylko sama weryfikacja. Przełączenie dotyczy więc tylko aplikacji typu Active-Passive, których komponenty nie są domyślnie aktywne w zapasowej lokalizacji, a jedynie ich dane są na bieżąco replikowane.
Mam nadzieje, iż choć trochę przybliżyłem tematykę z obszaru Disaster Recovery. W razie pytań zapraszam do kontaktu!
