Reanimacja w centrum danych

  • Szymon Pomorski,

Krytycznym aspektem Disaster Recovery jest zdolność do uruchomienia aplikacji biznesowych działających na danych zreplikowanych do ośrodka zapasowego. Posiadanie w lokalizacji zapasowej tylko replik danych, bez pracujących na nich aplikacji, jest bezużyteczne. Dlatego uzupełnieniem technologii replikacji danych do ośrodka zapasowego są rozwiązania klastrowe.

Zabezpieczenie ośrodka podstawowego poprzez klaster geograficzny oraz replikację danych

Serwery w klastrze mogą pracować w jednym z dwóch trybów. Pierwszym jest tzw. active/active, w którym na każdym serwerze działa aplikacja, a obciążenie produkcyjne jest równoważone. W drugim trybie, tzw. active/passive, na jednym z serwerów działa aplikacja produkcyjna, a drugi pozostaje w stanie gotowości do przejęcia przetwarzania danych w razie awarii pierwszego. W zależności od wymagań biznesowych i dostępności budżetu, stosuje się jedno lub drugie rozwiązanie. W przypadku klastra geograficznego, węzły klastra mogą znajdować się w odrębnych lokalizacjach, oddalonych od siebie o setki tysięcy kilometrów. Połączenie replikacji z klastrem geograficznym daje najwyższy możliwy stopień zabezpieczenia krytycznych z punktu widzenia biznesu danych i aplikacji. Dodatkowo, w momencie ogłoszenia katastrofy i wydania systemowi komendy następuje pełna automatyzacja procesu przełączenia działalności operacyjnej na ośrodek zapasowy.

Tańszym rozwiązaniem, które również można wykorzystać z technologią replikacji do zabezpieczenia danych, jest dysponowanie w lokalizacji zapasowej odpowiednio przygotowanymi serwerami, z zainstalowanymi najnowszymi wersjami oraz poprawkami systemów operacyjnych i aplikacji w stosunku do lokalizacji podstawowej. Często wykorzystywana jest tu powszechnie goszcząca w centrach danych technologia wirtualizacji serwerów.

Centrum danych gotowe na wszystko?

Po ukończeniu wszystkich etapów pośrednich (analiza krytycznych procesów, ustalenie współczynników RTO i RPO, wybór metod zabezpieczenia poszczególnych klas danych), przychodzi czas na dokładne opisanie procedur postępowania dla poszczególnych systemów IT odpowiedzialnych za przebieg procesów biznesowych organizacji.

Ważne jest, aby tworzony dokument miał jasną i przejrzystą strukturę, był kompletny, a więc obejmował wszelkie wymagane odwołania i załączniki oraz aktualizowaną na bieżąco historię zmian. Każdy etap postępowania powinien być jasno zdefiniowany i wyraźnie określać, kiedy możliwe staje się przejście do kolejnego. Po przygotowaniu dokumentu, powinien on zostać rozesłany do członków zespołu ds. sytuacji kryzysowych oraz zapisany w kilku kopiach na różnych nośnikach (np. klucz USB czy składowanie off-site).

Plan przywracania po awarii powinien zawierać:
Mając przygotowany i rozesłany do pracowników plan przywracania po katastrofie, można rozpocząć weryfikację jego poprawności poprzez przeprowadzenie szczegółowych testów. Jest to jedyna metoda sprawdzenia, czy starannie przygotowany plan spełni wyznaczoną mu rolę, a więc w razie awarii, zadziała i uchroni biznes przed skutkami katastrofy. Strategia testowania powinna być zbliżona do metodologii testowania oprogramowania, a więc powinna określać, jak często przeprowadzać dany rodzaj testu, najpierw sprawdzić pojedyncze komponenty, a następnie kombinację kilku z nich, prowadząc do testu całościowego. Takie podejście łatwo pozwoli wyłapać i poprawić błędy w pojedynczych procedurach.