Replikacja to koncepcja zakładająca kopiowanie danych, gdy zachodzą w nich zmiany. Przykładowo, jeśli w pliku zostaną zapisane nowe informacje obejmujące kilka bloków w systemie plików, replikacja skopiuje do systemu zapasowego tylko zmienione bloki. Zostaną one zapisane w systemie zapasowym w miejscu starszej wersji bloków (nastąpi tzw. nadpisanie). W ten sposób ma się stale aktualną kopię systemów produkcyjnych. W organizacjach wykorzystujących taśmy i tradycyjne metody backupu często okazuje się, że trudno jest osiągnąć czasy krótsze niż wymagane okienko przywracania (RTO, Recovery Time Objective). Wtedy dobrym rozwiązaniem jest przejście na replikację w procedurach disaster recovery, przynajmniej dla najważniejszych aplikacji.

Synchronicznie i asynchronicznie

Zasadniczo stosuje się dwie metody replikacji: synchroniczną i asynchroniczną. Obie pozwalają na bieżąco tworzyć kopię systemu produkcyjnego w zapasowej lokalizacji. W efekcie nie trzeba uruchamiać procedury przywracania, gdy dojdzie do awarii. Zamiast tego następuje przełączenie lokalizacji zapasowej w tryb produkcyjny. Wybór zależy głównie od tego, jaką aplikację chce się zabezpieczyć. Każda z metod ma swoje zalety. Replikacja synchroniczna tworzy kopię zapasową na bieżąco. Nie wysyła potwierdzenia zapisu do aplikacji, dopóki kopiowane dane nie zostaną zapisane w systemie zapasowym. To daje pewność, że system zapasowy zawsze przechowuje aktualną kopię.

Zobacz również:

• IBM Security QRadar SIEM pomoże zarządzić globalną strukturą odpowiedzialną za bezpieczeństwo

Takie podejście ma też wadę: powoduje opóźnienia w działaniu chronionej aplikacji. Tym większe, im więcej czasu zajmuje komunikacja między lokalizacją produkcyjną i zapasową (tzw. Rount Trip Time). Jeśli spowolnienie działania aplikacji nie wchodzi w grę, należy wybrać replikację asynchroniczną. W tym przypadku aplikacja otrzymuje informację o ukończeniu zapisu, natomiast dane są kopiowane asynchronicznie do lokalizacji zapasowej.

Problem z replikacją asynchroniczną polega na tym, że w zależności od tego, jak intensywnie działa aplikacja i jak wydajne są łącza między lokalizacjami, kopia może być opóźniona o sekundy czy nawet godziny w stosunku do systemu produkcyjnego. Gdy dojdzie do awarii, skutkiem będzie m.in. utrata danych z tego okienka czasowego. Jest to kompromis między tym, ile organizacja może stracić danych, a tym, jak szybko musi działać chroniona aplikacja.

Ogólnie, replikację synchroniczną stosuje się, gdy replika jest tworzona w obrębie sieci lokalnej lub blisko niej (do kilku czy kilkunastu kilometrów). Jeśli odległość między lokalizacjami jest większa niż kilkanaście kilometrów, najczęściej uruchamia się replikację asynchroniczną, w przeciwnym razie negatywny wpływ na szybkość działania aplikacji byłby zbyt duży.

Alternatywa dla disaster recovery

Wybór metody replikacji dla procedur disaster recovery zależy głównie od jednego czynnika: odległości między ośrodkami obliczeniowymi. Prawdziwa strategia disaster recovery zakłada, że ośrodek produkcyjny i zapasowy powinny znajdować się na tyle daleko od siebie, żeby nie znaleźć się w zasięgu jednej klęski żywiołowej. W Polsce poza powodziami nie występują klęski żywiołowe, które obejmują duże obszary. Można więc pokusić się o umiejscowienie obu ośrodków w niewielkiej odległości od siebie i zastosowanie replikacji synchronicznej.

Jeśli nie chcemy kusić losu i wybierzemy odległą lokalizacją zapasową, jedynym sensownym wyborem jest replikacja asynchroniczna. Przy większych odległościach nawet taka replikacja może sprawiać problemy, które rozwiązuje się, stosując różne techniki akceleracji. Przykładowo, ogranicza się liczbę komunikatów wymienianych między lokalizacjami poprzez agregację zapytań. Techniki te są na tyle rozwinięte, że nawet przy dużych odległościach transfer odbywa się wydajnie.

Dlatego replikację asynchroniczną można uznać za realną alternatywę dla innych metod disaster recovery. W miejsce replikacji można również zaproponować rozwiązania CDP (Continuous Data Protection). Różnią się one tym, że tworząc replikę, CDP rejestruje historię wprowadzanych zmian, co pozwala cofnąć się do kopii danych z określonego momentu w przeszłości.

Dobre praktyki

Podstawową kwestią w przypadku replikacji jest regularne monitorowanie tego procesu. Największym błędem, jaki popełniają działy IT, jest początkowe skonfigurowanie replikacji i niekontrolowanie później, jak ten proces przebiega.

Jest wiele sposobów tworzenia repliki. Może to być replikacja wykorzystująca dwie kompatybilne macierze, replikacja sprzętowa bądź realizowana przez oprogramowanie działające na chronionych serwerach. Jeśli w organizacji możliwe jest wykorzystanie każdej z tych technik, należy wybrać jedną, a przynajmniej wybrać rozwiązania któregoś z powszechnie znanych producentów. Wybierając ofertę danej firmy, należy sprawdzić, jakie możliwości w zakresie monitorowania, raportowania i alertowania o błędach mają jej produkty.

Wdrożenie replikacji jest kosztowne. Żeby taki projekt stał się bardziej przystępny, wiele osób wykorzystuje w lokalizacji zapasowej starszy system wycofany z produkcji bądź kupuje tańszą macierz SATA, mając w lokalizacji produkcyjnej sieć SAN. Niestety, ma to negatywne konsekwencje w postaci dużego spadku wydajności. W przypadku replikacji głównym czynnikiem decydującym o szybkości wykonywania tego procesu są właśnie macierze dyskowe, a przejście z interfejsu FiberChannel na SATA powoduje znaczny jej spadek.