Zapewnienie ciągłości biznesowej przez zastosowanie replikacji danych

Nawet najlepsze systemy backupu mają swoje ograniczenia. Klasyczny backup wykonywany codziennie w nocy lub nawet co kilka godzin nie umożliwia natychmiastowego wznowienia pracy w razie utraty serwera lub nośników.

W przypadku awarii i konieczności odtworzenia środowiska z kopii zapasowej musimy zdawać sobie sprawę, że:

• podczas odtwarzania system nie będzie dostępny dla pracowników / klientów przez kilka godzin;
• po odtworzeniu z kopii zapasowej utracimy dane z ostatnich kilku – kilkunastu godzin pracy;
• dodatkowe czynności związane z porządkami po utracie danych (ocena, co tak naprawdę straciliśmy i jak to odzyskać) zajmą następnych kilka dni.

Planując strategie dla systemów IT w przedsiębiorstwie musimy określić dwa współczynniki charakteryzujące zdolność do zachowania funkcji biznesowych po awarii serwera lub nośników. Są to współczynniki  RTO  - recovery time objective i RPO – recovery point objective.

Chodzi o zadanie dwóch pytań:

• jak długo po awarii system może nie pracować? (RTO)
• ile danych klient ZGADZA SIĘ utracić? (RPO)

O ile na pierwsze pytanie odpowiedź może brzmieć “kilka godzin”, bo przecież wiadomo – informatykowi chwilę odtworzenie danych zajmie, to drugie pytanie może doprowadzić do sytuacji dość kłopotliwej: “Jak to – oferujecie mi TAKI DROGI i podobno nowoczesny system backupów i pytacie się, ile danych zgadzam się utracić?”. No tak, niestety, systemy backupów mają swoje ograniczenia...

Replikacja jako sposób na zmniejszenie RPO

Lekarstwem na niezadowalające wartości współczynników RTO i RPO dla środowisk backupowych jest zastosowanie replikacji. W wielkim skrócie – techniki, która pozwoli nam na posiadanie drugiego zestawu nośników z dokładnie taką samą kopią danych.

Jest kilka technik replikacji –  mogą to być zarówno skomplikowane mechanizmy wbudowane w macierze dyskowe jak i softwarowe nakładki na system operacyjny.

W dalszej części zajmiemy się replikacją programową, która doskonale nadaje się do zabezpieczania całkiem dużych systemów IT, bez konieczności inwestycji w drogie macierze dyskowe. Polega ona na dodaniu do systemu operacyjnego odpowiedniego oprogramowania, które wychwyci operacje zapisu (na poziomie odwołań do systemu plików lub odwołań do dysku) i przekaże do oprogramowania działającego w środowisku zapasowym, które to oprogramowanie wykona te same operacje zapisu na drugim zestawie danych. W przypadku awarii nośników będziemy dysponować drugą kopią danych. W zależności od rodzaju zastosowanej replikacji (synchroniczna lub asynchroniczna) będą to dane z chwili awarii lub najwyżej z kilkudziesięciu sekund ją poprzedzających.

Replikacja synchroniczna

Replikacja synchroniczna redukuje współczynnik RPO do zera. Kopia danych jest zawsze identyczna z oryginałem. System operacyjny serwera głównego uznaje operacje zapisu za zakończoną dopiero wtedy, gdy środowisko zapasowe potwierdzi poprawność zapisu na drugim zestawie nośników. Oczywiście wiążą się z tym pewne ograniczenia – aby proces replikacji nie spowalniał operacji zapisu, opóźnienia pomiędzy serwerem podstawowym a zapasowym muszą być jak najmniejsze. W praktyce oznacza to odległość do 10 km pomiędzy serwerami i konieczność wysokiej klasy dedykowanego łącza o wysokiej przepustowości.

Więcej o replikacji synchronicznej – EMC FullTime AutoStart 

Replikacja asynchroniczna

Replikacja asynchroniczna pozwala na buforowanie danych pomiędzy systemem źródłowym i docelowym. Operacja zapisu nie czeka na potwierdzenie z systemu docelowego – taki proces jest więc niewrażliwy na opóźnienia i co za tym idzie można stosować łącza o mniejszej przepustowości, a odległość pomiędzy ośrodkiem głównym i zapasowym może być dowolnie duża.

Oczywiście w zamian należy liczyć się z kilku – kilkudziesięciosekundowymi opóźnieniami w dosyłaniu danych do środowiska zapasowego. W praktyce opóźnienia takie występują tylko w godzinach największego wykorzystania aplikacji – kiedy ilość przesyłanych danych przekracza przepustowość łącza.

Więcej o replikacji asynchronicznej – EMC FullTime RepliStor 

Środowisko klastrowe “application aware” jako sposób na redukcję RTO

Posiadanie repliki danych na odległym serwerze zabezpiecza przed utratą danych, jednak w przypadku awarii wymagana jest interwencja administratora, który:

• stwierdzi, że mamy do czynienia z awarią;
• przełączy aplikację na serwer zapasowy;
• przełączy dostęp dla klientów końcowych tak, aby używali serwera zapasowego.

W zależności od tego, kiedy nastąpiła awaria i gdzie akurat był administrator, przełączenie aplikacji (ang. FailOver) wraz z potrzebnymi do jej pracy zasobami, może zająć nawet do kilku godzin. Istnieją jednak proste sposoby pozwalające w pełni automatyzować ten proces poprzez:

• aktywne monitorowanie serwera (poprawność pracy i dostępność zasobów dyskowych, sieciowych itp.);
• aktywne monitorowanie aplikacji (obecność procesów, czas odpowiedzi, możliwość zalogowania się);
• automatyczny restart aplikacji w środowisku zapasowym (z aktualną repliką danych) w przypadku awarii serwera głównego;
• automatyczne przekonfigurowanie dostępu dla klientów końcowych (zmiana w DNS, zarządzanie wirtualnym adresem IP).