DR w środowisku hybrydowym

DR w środowisku hybrydowym to strategia przywracania działania systemu łącząca infrastrukturę lokalną z zasobami chmurowymi.

Architektura DR łącząca centrum lokalne z chmurą

DR, czyli disaster recovery, w środowisku hybrydowym oznacza zaplanowane odtworzenie usług informatycznych po awarii z wykorzystaniem dwóch różnych obszarów infrastruktury: zasobów utrzymywanych lokalnie oraz zasobów dostawcy chmurowego. Infrastruktura lokalna może obejmować serwery fizyczne, macierze dyskowe, urządzenia sieciowe i lokalne systemy uwierzytelniania, natomiast chmura zapewnia dodatkową lokalizację dla kopii danych, replik maszyn wirtualnych albo gotowych komponentów zapasowych. Sama obecność danych w chmurze nie jest jeszcze kompletną strategią DR. Konieczne jest określenie, które usługi mają zostać odtworzone, w jakiej kolejności i przy użyciu jakich zależności.

W modelu hybrydowym podstawowe środowisko może działać w serwerowni organizacji, a chmura pełni funkcję lokalizacji zapasowej. Możliwy jest również układ odwrotny, w którym część aplikacji działa stale w chmurze, a systemy lokalne zapewniają dostęp do urządzeń, plików lub usług wymagających obecności w siedzibie. Projekt powinien uwzględniać przepustowość łączy, opóźnienia sieciowe, sposób szyfrowania transmisji, dostępność systemu DNS, synchronizację czasu oraz działanie usług tożsamości. Awaria jednego elementu, takiego jak łącze internetowe, nie może uniemożliwiać uruchomienia pozostałych komponentów planu.

RPO, RTO i sposób replikacji danych

Najważniejsze parametry planu DR to RPO i RTO. RPO, czyli recovery point objective, określa maksymalną dopuszczalną utratę danych wyrażoną jako przedział czasu. Jeżeli przyjęto RPO wynoszące jedną godzinę, rozwiązanie powinno umożliwiać odtworzenie danych z punktu nie starszego niż jedna godzina, o ile zapewniają to rzeczywiste kopie lub repliki. RTO, czyli recovery time objective, określa maksymalny akceptowany czas przywracania usługi. RTO nie jest tym samym co czas potrzebny na skopiowanie plików, ponieważ obejmuje również uruchomienie systemów, odtworzenie konfiguracji, sprawdzenie zależności i przywrócenie dostępu użytkowników.

Dane mogą być chronione przez kopie zapasowe, replikację synchroniczną albo replikację asynchroniczną. Kopia zapasowa zapisuje odrębny punkt odtworzenia, natomiast replikacja utrzymuje dodatkową kopię systemu lub danych w innym miejscu. Replikacja synchroniczna wymaga potwierdzenia zapisu po stronie dodatkowej lokalizacji, dlatego jest wrażliwa na opóźnienia i jakość połączenia. Replikacja asynchroniczna pozwala ograniczyć wpływ odległości i opóźnień, ale między zapisem lokalnym a zapisem w chmurze może powstać opóźnienie powodujące utratę najnowszych zmian. W każdym wariancie należy osobno chronić konfigurację, klucze szyfrujące, dane aplikacyjne oraz informacje niezbędne do odtworzenia systemu.

Przełączenie usług i kolejność odtwarzania

Plan DR powinien opisywać zarówno scenariusz failover, czyli przełączenia na lokalizację zapasową, jak i failback, czyli powrotu do środowiska podstawowego po usunięciu awarii. Przełączenie nie ogranicza się do uruchomienia serwera. Najpierw trzeba zapewnić dostęp do sieci, systemu tożsamości i usług DNS, następnie uruchomić warstwę danych, a dopiero później aplikacje korzystające z tych danych. Systemy zależne od kolejek komunikatów, certyfikatów, współdzielonych plików lub zewnętrznych interfejsów API powinny być uwzględnione w tej samej procedurze. Pominięcie jednej zależności może doprowadzić do sytuacji, w której serwer odpowiada technicznie, ale aplikacja nie realizuje poprawnie operacji.

W środowisku hybrydowym szczególnej uwagi wymaga zmiana adresacji i trasowania. Po awarii może być konieczne przełączenie rekordów DNS, zmian konfiguracji zapory sieciowej, reguł dostępu albo punktów końcowych aplikacji. Należy określić, jak długo rekordy mogą pozostawać w pamięciach podręcznych dzięki wartości TTL oraz jak użytkownicy i systemy automatyczne wykryją zmianę lokalizacji usługi. Jeżeli działanie zależy od połączenia między siecią lokalną a chmurą, plan powinien zawierać procedurę odtworzenia tunelu VPN lub dedykowanego połączenia oraz sposób weryfikacji, że dostęp nie jest tylko pozornie aktywny.

Testowanie planu i kontrola spójności odtworzenia

Nieprzetestowany plan DR jest jedynie dokumentacją założeń. Test powinien odbywać się w kontrolowanym zakresie i obejmować odtworzenie danych, uruchomienie usług, logowanie użytkownika, wykonanie przykładowych operacji oraz sprawdzenie komunikacji z systemami zależnymi. Warto rozdzielić test kopii zapasowej od testu pełnego przełączenia. Pierwszy pokazuje, czy dane można odczytać, drugi sprawdza, czy organizacja potrafi uruchomić działający system w lokalizacji zapasowej. Wyniki należy porównać z wymaganiami RPO i RTO, a każde odstępstwo opisać wraz z działaniem korygującym.

Kontrola powinna obejmować także ochronę przed uszkodzeniem lub zaszyfrowaniem danych w środowisku podstawowym. Przydatne są kopie przechowywane w sposób odseparowany od systemu produkcyjnego, wersjonowanie oraz ograniczenie uprawnień do usuwania i modyfikowania kopii. Po odtworzeniu trzeba sprawdzić integralność baz danych, zgodność konfiguracji, poprawność certyfikatów i działanie zadań automatycznych. Dokumentacja powinna wskazywać właścicieli poszczególnych etapów, dane kontaktowe, kryteria rozpoczęcia failover oraz warunki bezpiecznego failback. Regularne przeglądy są potrzebne, ponieważ zmiana aplikacji, adresacji, dostawcy chmurowego lub sposobu uwierzytelniania może unieważnić wcześniejsze założenia.