Praktyki HA/DR (High Availability / Disaster Recovery)

Praktyki HA/DR obejmują grupy dostępności, klastry pracy awaryjnej i regularne testowanie procedur odtwarzania.

Zakres praktyk HA/DR i różnica między dostępnością a odtwarzaniem

Praktyki HA/DR łączą dwa powiązane, ale odrębne obszary utrzymania systemów komputerowych. High Availability, czyli wysoka dostępność, koncentruje się na ograniczeniu przerw w działaniu usługi podczas awarii pojedynczego elementu. Może obejmować nadmiarowe zasilacze, macierze dyskowe, interfejsy sieciowe, węzły usługowe oraz mechanizmy automatycznego przełączania ruchu. Celem HA jest utrzymanie usługi albo skrócenie niedostępności do czasu przejęcia pracy przez zapasowy komponent.

Disaster Recovery, czyli odtwarzanie po awarii, dotyczy sytuacji o większej skali: utraty całego urządzenia, lokalizacji, konfiguracji, danych albo zależności wymaganych do uruchomienia aplikacji. Procedura DR określa, z jakiego źródła przywracane są dane, w jakiej kolejności uruchamia się elementy systemu i jak potwierdza się poprawność działania. Wysoka dostępność nie zastępuje kopii zapasowych, ponieważ automatyczna replikacja może powielić również usunięcie danych, błąd konfiguracji lub uszkodzenie logiczne.

Grupy dostępności, klastry pracy awaryjnej i zależności usług

Grupa dostępności to zestaw współpracujących instancji lub usług, między którymi można przekazywać obsługę obciążenia. W zależności od architektury przełączenie może być automatyczne, półautomatyczne albo ręczne. Wymaga ono nie tylko zapasowego węzła, lecz także mechanizmu wykrywania awarii, oceny stanu usługi oraz wskazania elementu, który ma przejąć rolę aktywną. Sam fakt uruchomienia drugiego komputera nie oznacza jeszcze zapewnienia HA, jeśli nie ma sprawdzonej synchronizacji danych i procedury zmiany punktu dostępu.

Klaster pracy awaryjnej powinien uwzględniać zależności wykraczające poza główną aplikację. Należą do nich między innymi system nazw, sieć, magazyn danych, usługi uwierzytelniania, certyfikaty, harmonogramy zadań i konfiguracja zapory. Awaria jednego procesu może wyglądać inaczej niż utrata łączności z magazynem lub rozbieżność stanu między węzłami. Dlatego monitorowanie powinno obejmować zarówno dostępność hosta, jak i odpowiedź usługi, możliwość zapisu oraz zgodność danych. W przeciwnym razie system może wykonać przełączenie pozorne, podczas którego zapasowy węzeł działa, ale nie jest zdolny do obsługi pełnego procesu.

Projektowanie kopii, odtwarzania i testów awaryjnych

Plan DR powinien wskazywać wymagany punkt odtworzenia oraz dopuszczalną długość przerwy. RPO, czyli Recovery Point Objective, opisuje maksymalną akceptowaną utratę czasu danych, na przykład zakres zmian od ostatniej poprawnej kopii. RTO, czyli Recovery Time Objective, określa zakładany czas przywrócenia usługi do działania. Są to parametry projektowe, a nie gwarancje wynikające z samego posiadania kopii. Ich osiągnięcie zależy od przepustowości nośników, rozmiaru danych, dostępności konfiguracji i czasu potrzebnego na walidację.

Kopia zapasowa powinna być przechowywana w sposób ograniczający ryzyko jednoczesnego uszkodzenia danych produkcyjnych i kopii. W praktyce ocenia się między innymi odseparowanie lokalizacji, możliwość odczytu archiwum, kompletność plików oraz ochronę przed przypadkowym nadpisaniem. Test odtwarzania powinien obejmować nie tylko przywrócenie pojedynczego pliku, lecz także scenariusz uruchomienia usługi na podstawie dokumentacji. Należy sprawdzić kolejność działań, wymagane uprawnienia, dostęp do kluczy i certyfikatów, integralność danych oraz zachowanie aplikacji po przywróceniu.

Walidacja przełączenia i dokumentowanie wyników

Regularny test HA/DR powinien mieć określony zakres, warunki rozpoczęcia, osoby odpowiedzialne i kryteria zakończenia. Podczas próby przełączenia rejestruje się czas wykrycia awarii, moment rozpoczęcia procedury, czas odzyskania dostępu oraz ewentualne błędy. Weryfikacji wymagają także operacje zapisu, odczyt wcześniejszych danych, połączenia klientów i działanie zadań wykonywanych cyklicznie. Po zakończeniu testu trzeba potwierdzić, czy system powrócił do zamierzonego układu oraz czy ponowne przełączenie nie spowoduje utraty zmian.

Dokumentacja powinna opisywać aktualną topologię, role węzłów, źródła kopii, zależności usług, procedurę eskalacji i sposób podejmowania decyzji o przełączeniu. Każda zmiana konfiguracji powinna prowadzić do ponownej oceny planu, ponieważ dodanie komponentu, zmiana magazynu albo modyfikacja reguł sieciowych może unieważnić wcześniejsze założenia. W przypadku urządzeń używanych w domu lub biurze elementy HA/DR mogą być ograniczone, ale nadal warto kontrolować stan nośników, wykonywać kopie konfiguracji i sprawdzać, czy odtworzenie danych jest faktycznie możliwe.