Reanimacja w centrum danych

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.

Reanimacja w centrum danych

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.


TOP 200