Replikacja danych przetrwała próbę czasu, zapewniając organizacjom niezawodny sposób ochrony krytycznych informacji przez dziesięciolecia. Replikacja tworzy nadmiarowe kopie ważnych danych, zapewniając ich dostępność i odporność w przypadku katastrof lub awarii systemu. W tym artykule zbadam zawiłości replikacji danych, analizując jej podstawowe komponenty, typy i potencjalne ograniczenia.

Replikacja danych rozpoczyna się od wyboru woluminu źródłowego lub systemu plików, który wymaga ochrony. Ten wolumin źródłowy może być dyskiem wirtualnym, często określanym jako LUN (numer jednostki logicznej), pochodzącym z macierzy pamięci masowej lub menedżera woluminów. Może to być również system plików. Replikacja może odbywać się na poziomie bloków, co jest powszechną praktyką ze względu na jej wydajność, lub na poziomie systemu plików, choć ten drugi jest mniej preferowany ze względu na stosunkowo niższą wydajność.

Po wybraniu źródła należy wybrać inny wolumin lub system plików z innego hosta, który będzie służył jako cel replikacji. Miejmy nadzieję, że będzie on umieszczony w geograficznie oddzielnej lokalizacji - jest to krytyczny aspekt zapewnienia redundancji danych i różnorodności geograficznej.

Organizacje stosują różnorodne systemy replikacji oferowane przez dostawców macierzy dyskowych, dostawców menedżerów wolumenów, dostawców systemów plików i dostawców zewnętrznych. Rozwiązania te stanowią serce procesu replikacji, ułatwiając synchronizację danych między woluminami źródłowymi i docelowymi.

Początkowy etap synchronizacji stanowi podstawę replikacji, zapewniając, że wolumin docelowy odzwierciedla zawartość woluminu źródłowego. Po osiągnięciu tego kamienia milowego, system replikacji pilnie śledzi i propaguje każdą zmianę zachodzącą w woluminie źródłowym do woluminu docelowego. Ta ciągła synchronizacja, zwykle wykonywana na poziomie bloków, zapewnia utrzymanie spójności danych na obu woluminach. To, jak dokładnie wolumin docelowy odzwierciedla wolumin źródłowy, zależy od tego, czy używana jest replikacja synchroniczna czy asynchroniczna.

System replikacji synchronicznej replikuje wszelkie zmiany przed potwierdzeniem tych zmian do aplikacji, która je wprowadziła. (Gdy aplikacja zapisuje blok danych na woluminie, oczekuje na potwierdzenie (ACK) potwierdzające pomyślny zapis na woluminie źródłowym przed przystąpieniem do zapisu kolejnego bloku). Proces ten przypomina dwufazowe zatwierdzenie w świecie baz danych, gdzie zarówno zapis do woluminu źródłowego, jak i kopia tego zapisu do woluminu docelowego są postrzegane jako jedno zdarzenie.

Główną zaletą replikacji synchronicznej jest możliwość zapewnienia wysokiego poziomu ochrony danych. Dzięki stałej synchronizacji woluminów źródłowego i docelowego, ryzyko utraty danych w wyniku katastrofy lub awarii jest znacznie zmniejszone. Istnieje jednak pewien minus: wydajność systemu docelowego i ścieżki replikacji danych może wprowadzać znaczne opóźnienia w dostarczaniu ACK, wpływając na czas odpowiedzi aplikacji.

Przejmujący przykład wpływu replikacji synchronicznej na wydajność pojawił się po tragicznych wydarzeniach z 11 września. W odpowiedzi na podatności ujawnione podczas ataków, amerykańskie organy regulacyjne próbowały nakazać organizacjom finansowym wdrożenie replikacji synchronicznej na odległości przekraczające 300 mil, w celu zwiększenia ochrony danych i możliwości odzyskiwania danych po awarii. Opóźnienia między lokalizacjami uznano jednak za zbyt wysokie, co ostatecznie doprowadziło do porzucenia tych planów.

Z kolei replikacja asynchroniczna przyjmuje bardziej pragmatyczne podejście, odraczając natychmiastową replikację zmian na rzecz kolejkowania ich do późniejszej transmisji. Zapisy są dzielone, a jeden z nich jest wysyłany do systemu replikacji, który dodaje go na koniec kolejki. W zależności od przepustowości i opóźnień, wolumin docelowy może być od kilku sekund az do godzin opóźniony w stosunku do woluminu źródłowego.

Podczas gdy replikacja asynchroniczna oferuje korzystną równowagę między wydajnością a ochroną danych, budzi ona potencjalne obawy. Jedną z kluczowych kwestii jest ryzyko zbyt dużego opóźnienia procesu replikacji, co prowadzi do wyzwań związanych z nadrabianiem stale rosnących zaległości w zakresie zmian. W pewnych okolicznościach niektóre aplikacje mogą obsługiwać koalescencję zapisu, proces, w którym starsze zapisy są porzucane, aby umożliwić systemowi replikacji nadrobienie zaległości. Niemniej jednak do takich praktyk należy podchodzić z ostrożnością, ponieważ mogą one wpływać na spójność danych i opcje odzyskiwania.

Podczas gdy poprzednie sekcje koncentrowały się głównie na replikacji na poziomie bloków, podobna koncepcja rozciąga się na koncepcję replikacji bazy danych. Tutaj nacisk przenosi się z replikacji na poziomie bloku na replikację poszczególnych transakcji między bazami danych. Podobnie jak w przypadku innych form replikacji, replikacja bazy danych jest zwykle wykonywana asynchronicznie, co podkreśla jej użyteczność w zabezpieczaniu ważnych rekordów bazy danych.

Replikacja od dawna jest metodą wybieraną przez organizacje starające się chronić aplikacje o znaczeniu krytycznym, ze względu na jej zdolność do szybkiego i skutecznego odzyskiwania danych. Rzeczywiście, możliwości synchronizacji danych w czasie rzeczywistym sprawiają, że jest to niezbędne narzędzie do zapewnienia dostępności danych w sytuacjach kryzysowych. Należy jednak pamiętać, że replikacja, gdy jest stosowana w izolacji, wiąże się z nieodłącznymi ograniczeniami.

Być może najbardziej rażącym ograniczeniem jest brak przycisku "wstecz" w tradycyjnych systemach replikacji. W przypadku błędów ludzkich, takich jak przypadkowe usunięcie lub uszkodzenie danych (lub ataki ransomware), replikacja będzie wiernie propagować te działania do woluminu docelowego, prowadząc do nieodwracalnej utraty danych.

W związku z tym poleganie wyłącznie na replikacji w celu ochrony danych nie jest zgodne z wypróbowaną i sprawdzoną zasadą 3-2-1: trzy kopie danych na dwóch różnych nośnikach, z jedną kopią znajdującą się poza siedzibą firmy. Może się wydawać, że jest to zgodne z tą zasadą, jednak ponieważ pojedyncze działanie może usunąć wszystkie kopie, nie jest to zgodne z aspektem "2" polegającym na umieszczeniu różnych kopii na nośnikach o różnych profilach ryzyka.

Kolejna kwestia dotyczy potencjalnego narzutu wydajności wprowadzanego przez replikację. W przypadku łączenia regularnych kopii zapasowych z replikacją danych, dane są skutecznie kopiowane dwukrotnie, co ma wpływ na wydajność. Ten czynnik może być uważany za nieistotny w izolacji, ale może się kumulować, gdy w grę wchodzą inne uwarunkowania.

Replikacja danych jest cenionym mechanizmem ochrony danych, umożliwiającym organizacjom tworzenie kopii istotnych danych w czasie rzeczywistym, zwiększając ich odporność i ciągłość. Niemniej jednak, gdy zagłębiamy się w jej zawiłości, odkrywamy jej ograniczenia i istotną rolę, jaką odgrywa w szerszym gobelinie kompleksowej ochrony danych.

Chociaż replikacja doskonale sprawdza się w zapewnianiu natychmiastowej dostępności danych, nie można na niej polegać wyłącznie w celu ochrony przed błędami ludzkimi, uszkodzeniem danych, cyberatakami lub utratą wielu kopii. Dlatego też kluczowe znaczenie ma uzupełnienie replikacji o kompleksowe strategie tworzenia kopii zapasowych danych, przestrzeganie zasady 3-2-1 i uwzględnienie możliwości tworzenia wersji. (Migawki są doskonałym przykładem narzędzia towarzyszącego, które może zwiększyć wartość replikacji).

Przyjmując holistyczne podejście do ochrony danych, łącząc moc replikacji danych z solidnymi praktykami tworzenia kopii zapasowych, organizacje mogą pewnie poruszać się po cyfrowym krajobrazie, chroniąc swój najcenniejszy zasób: dane. Podkreślając synergię między replikacją w czasie rzeczywistym a dobrze ustrukturyzowanymi kopiami zapasowymi, firmy mogą śmiało stawić czoła stale zmieniającym się wyzwaniom związanym z ochroną danych i zapewnić odporność swoich operacji.

Artykuł pochodzi z Networkworld.com

W. Curtis Preston - znany jako Mr. Backup - jest ekspertem w dziedzinie tworzenia kopii zapasowych, pamięci masowych i odzyskiwania danych, pracującym w tym obszarze od 1993 roku. Był użytkownikiem końcowym, konsultantem, analitykiem, menedżerem produktu i ewangelistą technicznym.

Napisał książki na ten temat: Backup & Recovery, Using SANs and NAS oraz Unix Backup & Recovery.