Backup i replikacja

Wirtualizacja serwerów wymusiła wprowadzenie nowych technologii w systemach backupu. Rozwój w tym obszarze napędzają również wymagania dotyczące wysokiej dostępności danych.

Ochrona danych to nie jest ulubiony temat działów IT, ale od backupu nie uciekniemy. IT musi działać według strategii, która uwzględnia ochronę danych, określa, jakie są potrzeby w tym obszarze i co należy zrobić, aby je zaspokoić. Ważna jest ocena kosztów tych działań oraz kosztów ryzyka, jeśli potrzeby nie zostałyby zrealizowane. Ponieważ backup nie tworzy wartości biznesowej, należy wybierać takie rozwiązania, które z jednej strony zapewnią wymagane bezpieczeństwo danych, a z drugiej będą jak najmniej uciążliwe dla IT.

Deduplikacja

Z tworzeniem kopii zapasowych główny problem polega na tym, że szybko rośnie ilość danych, a jednocześnie kurczą się okna backupu. Praktycznym rozwiązaniem tego problemu ograniczenie danych, które trafiają do kopii zapasowych. Spośród różnych technologii największy potencjał w tym obszarze daje deduplikacja. Może być realizowana przez system backupu lub macierz dyskową. Deduplikacja ma pozytywny wpływ na zarządzanie i koszty przechowywania danych. To, m.in. za jej sprawą coraz częściej wykorzystuje się dyski twarde zamiast taśm do przechowywania kopii zapasowych.

Zobacz również:

  • Ransomware zagraża ochronie zdrowia

Algortymy deduplikacji są stale udoskonalane. Na rynek trafiły już rozwiązania, w których ten mechanizm działa strefowo. Potrafi rozpoznać w kopiowanych danych obiekty podobne do obiektów, które wystąpiły wcześniej. To zwiększa ilość wykrywanych, powtarzających się informacji.

Niestety deduplikację nie zawsze da się zastosować. Najpoważniejszym problemem są bazy danych używane do obsługi aplikacji biznesowych. Bazy te rozrastają się i zrobienie ich kopii w kurczącym się oknie backupowym jest trudne. Dlatego stosuje się takie technologie backupu, jak multistreaming czy multiplexing, co skraca czas kopiowania danych. Jednakże mechanizmy deduplikacji nie potrafią przetwarzać takiej wielostrumieniowej transmisji. W efekcie następuje niekontrolowany przyrost danych w dużych, korporacyjnych systemach backupu. Z bazami danych jest również ten kłopot, że przechowują dane w małych segmentach (mniejszych niż 8 KB), co również obniża skuteczność deduplikacji.

Backup maszyn wirtualnych

Serwery wirtualne wymagają specyficznego podejścia do kwestii tworzenia ich kopii zapasowych. Dlatego dużą popularność zdobyły systemy backupu dedykowane do tego typu środowisk. Jedną z głównych różnic między tradycyjnym systemem backupu a tym służącym do ochrony maszyn wirtualnych jest brak agenta backupu. W środowisku wirtualnym funkcje realizowane przez agentów zostały przeniesione na poziom hypervisora, co przynosi kilka korzyści. Przede wszystkim poprawia wydajność. Jeśli w każdej maszynie działałby agent backupu, to przy kilku czy kilkunastu agentach (po jednym w każdej wirtualce) na jednym serwerze fizycznym spadek wydajności byłby znaczący. W świecie fizycznym ten problem jest mniej istotny, ponieważ rzadko fizyczny serwer pracuje przy pełnym wykorzystaniu zasobów. Zaplanowanie zadań backupu nie stanowi więc aż tak dużego wyzwania.

Brak agentów upraszcza również zarządzanie, ponieważ eliminuje konieczność nadzorowania wielu niezależnych zadań backupowych, co w dynamicznym, wirtualnym środowisku mogłoby się stać koszmarem administratora. Nie występuje również problem licencjonowania backupu per agent.

W przypadku rozwiązania bezagentowego operacjami backupu zajmuje się zewnętrzny serwer, który może kopiować dane bezpośrednio z macierzy. Takie podejście eliminuje obciążenie serwerów produkcyjnych, pozwala uniknąć problemów z dostępnością aplikacji i zasadniczo upraszcza zarządzanie. Redukuje również obciążenie sieci i systemów wejścia/wyjścia macierzy, ponieważ funkcje takie jak deduplikacja czy szyfrowanie są realizowane poza chronioną maszyną.

Rozwiązanie backupowe komunikuje się bezpośrednio z platformą wirtualną przez interfejs API, co umożliwia odczytanie danych na poziomie bloków, śledzenie zmienionych bloków czy wykorzystanie innych funkcji redukujących czas wykonania backupu, zmniejszających obciążenie CPU czy wymagania dotyczące przestrzeni dyskowej.

Rozwiązania bezagentowe sprawdzają się również podczas przywracania maszyn wirtualnych, przykładowo użytkownik może odzyskać wybrane pliki czy foldery po podpięciu pliku dysku maszyny wirtualnej. Jednak backup na poziomie aplikacji, wymagający aktywnego zastosowania oprogramowania Microsoft SQL, Active Directory, serwera Exchange czy bazodanowego wymaga specjalnego traktowania. W takich sytuacjach użytkownicy mają trzy opcje do wyboru. Pierwszą jest hybrydowe rozwiązanie, zakładające backup z wykorzystaniem agenta i bez agenta. Bezagentowo tworzy się kopię całej maszyny wirtualnej oraz przechowywanych w niej plików. Natomiast agent backupu jest wykorzystywany do kopiowania określonych zestawów danych. Oba typy backupu są tworzone stosunkowo szybko. Pewne opóźnienie pojawia się przy odzyskiwania, jeśli zachodzi konieczność podpięcia (mount) obrazu maszyny wirtualnej do działającego systemu.

Konsolidacja backupu

Wraz z popularyzacją wirtualizacji serwerów firmy zaczęły używać specjalizowanych, bezagentowych rozwiązań do backupu maszyn wirtualnych. Nad prostotą korzystania z pojedynczego systemu obejmującego całego środowisko IT przeważyła chęć lepszego zabezpieczenia wirtualnych serwerów. Systemy backupu ściśle zintegrowane z hypervisorem i warstwą zarządzającą środowiskiem wirtualnym ujawniły swoje niewątpliwe zalety i cieszą się dużym zainteresowaniem. Takie narzędzia mają dostęp do informacji o maszynach wirtualnych i serwerach fizycznych. Potrafią diametralnie skrócić czas backupu i ilość danych do skopiowania.

Wirtualizacja zmieniła nie tylko produkty, ale również strategię backupu. Zamiast skupiać się na ochronie systemów fizycznych, obecnie promuje się ochronę usług. Zadania backupowe muszą być bardziej związane z zapewnieniem ciągłości biznesowej, zamiast koncentrować się na ochronie określonego komponentu infrastruktury. Aby zbliżyć się do tego celu, jest potrzebne globalne, bardziej scentralizowane zarządzanie ochroną danych powiązane z oczekiwaniami biznesu w obszarze SLA. Chodzi o to, aby zapewnić ochronę aplikacjom bądź usługom biznesowym.

W pakiecie

W centrach danych rośnie zainteresowanie kompletnymi systemami backupu składającymi się z oprogramowania i sprzętu dostarczanego przez jednego producenta. Zaletą takiego podejścia jest optymalizacja wydajności całego rozwiązania oraz uniknięcie ewentualnych problemów z kompatybilnością pomiędzy sprzętem i oprogramowaniem. Upraszcza się zarządzanie i wdrożenie. Upraszczają się również kwestie związane z pomocą techniczną, ponieważ za całość odpowiada jeden dostawca.

Replikacja to nie backup

Replikacja do zdalnych lokalizacji czy konfiguracje RAID to również techniki ochrony danych. Zabezpieczają one przed skutkami awarii sprzętu czy klęskami żywiołowymi. 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 te zmienione bloki. Zostaną one zapisane w systemie zapasowym w miejscu starszej wersji tych 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.

Jednak te technologie nie zastąpią backupu, ponieważ nie chronią przed błędami operatora (np. przypadkowym skasowaniem pliku) czy działaniem szkodliwego oprogramowanie. Wprowadzone w ten sposób zmiany są bowiem szybko powielone w przypadku replikacji. Taki problem nie występuje w kopiach zapasowych, które umożliwią powrót do stanu plików z określonego punktu w czasie. Dobrym pomysłem jest przechowywanie kopi zapasowych w miejscu oddalonym od systemów produkcyjnych, co chroni przed pożarami czy klęskami żywiołowymi. Tak naprawdę warto wziąć pod uwagę takie rozwiązanie w organizacji każdej wielkości i w każdej branży. Jeśli nie ma takiej możliwości, warto przynajmniej trzymać backup w innym pomieszczeniu.

Synchronicznie i asynchronicznie

Są dwie podstawowe metody replikacji: synchroniczna i asynchroniczna. Obie pozwalają na bieżąco tworzyć kopie systemów produkcyjnych. W efekcie nie trzeba uruchamiać procedury przywracania, gdy dojdzie do awarii. Zamiast tego następuje przełączenia lokalizacji zapasowej w tryb produkcyjny. Wybór metody zależy przede wszystkim od tego, jaką aplikację chce się zabezpieczyć. Replikacja synchroniczna tworzy kopie zapasowe 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ę. 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-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.

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 obejmowałyby 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.

Replikacja - najlepsze 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 nie kontrolowanie 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 swoje negatywne konsekwencje w postaci znacznego 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.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200