Współczesny świat biznesu rozwija się z każdą sekundą, co oznacza, że ​​stale rośnie liczba krytycznych danych, które muszą być chronione. W razie katastrofy każda firma musi dysponować zestawem strategii odzyskiwania, aby jak najszybciej chronić i przywracać kluczowe procesy. W związku z tym pojawia się potrzeba zdalnej replikacji, która zakłada wysyłanie krytycznych danych biznesowych poza miejsce pracy w celu niezawodnego przechowywania i szybkiego odzyskiwania.

Zdalna replikacja jest istotną częścią ochrony i odzyskiwania danych. Wcześniej replikacja była najczęściej używana do kopiowania i przechowywania danych aplikacji w lokalizacjach poza siedzibą. Jednak z biegiem czasu technologia ta znacznie się rozszerzyła. Obecnie replikacja umożliwia utworzenie zsynchronizowanej kopii maszyny wirtualnej na zdalnym hoście docelowym. Kopia VM jest nazywana repliką i działa tak jak zwykła maszyna wirtualna dostępna na hoście źródłowym. Repliki VM można przenosić i uruchamiać na dowolnym, sprawnym sprzęcie. Mogą zostać włączone w ciągu kilku sekund w przypadku awarii oryginalnej maszyny wirtualnej. Technologia ta może znacznie zmniejszyć przestoje, a także ograniczyć potencjalne ryzyko biznesowe i straty związane z katastrofą.

Przed uruchomieniem zadania replikacji należy wziąć pod uwagę następujące czynniki:

• Odległość – im większa odległość między lokalizacjami, tym większe opóźnienie.
• Przepustowość – szybkość internetu i połączenie sieciowe powinny być wystarczające, aby zapewnić zaawansowane połączenie dla szybkiego i bezpiecznego transferu danych.
• Szybkość transmisji danych – szybkość transmisji danych powinna być niższa niż dostępna przepustowość, aby nie przeciążać sieci.
• Technologia replikacji – zadania replikacji powinny być uruchamiane równolegle (jednocześnie) w celu efektywnego wykorzystania sieci.

Czynniki te pomagają określić, który typ replikacji jest lepszy, gdy mamy do czynienia z określonym rodzajem katastrofy.

Można wyróżnić dwa główne typy replikacji danych: synchroniczne i asynchroniczne.

W tym przypadku dane są replikowane do dodatkowej lokalizacji zdalnej w tym samym czasie, gdy nowe dane są tworzone lub aktualizowane w głównym centrum danych. Umożliwia to niemal natychmiastową replikację, co pozwala zachować repliki danych zaledwie kilka minut starsze niż materiał źródłowy. Zasadniczo zarówno źródło hosta, jak i źródło docelowe pozostają całkowicie zsynchronizowane, co ma kluczowe znaczenie dla skutecznego przywracania systemu po awarii (DR).

Ze względu na to, że dane są atomowo aktualizowane w wielu lokalizacjach zdalnych, wpływa to na wydajność i dostępność sieci. Operacje atomowe są definiowane jako sekwencja operacji, które muszą być zakończone bez przerwy przed wykonaniem innego zadania. W kontekście synchronicznej replikacji oznacza to, że zapis jest uważany za zakończony tylko wtedy, gdy oba lokalne i zdalne magazyny potwierdzają jego zakończenie. Dlatego gwarantowana jest zerowa utrata danych, ale ogólna wydajność jest spowolniona.

W takim przypadku replikacja nie jest wykonywana w tym samym czasie, co zmiany w pamięci podstawowej. Dane są replikowane tylko we wcześniej określonych przedziałach czasowych (może to być godzina, dzień lub tydzień). Replika może być przechowywana w zdalnej lokalizacji DR, ponieważ nie musi być synchronizowana z pierwotną lokalizacją w czasie rzeczywistym.

Przy replikacji asynchronicznej dane nie są aktualizowane atomowo w wielu lokalizacjach, co oznacza, że ​​aplikacja kontynuuje pisanie danych, które nie są jeszcze w pełni zreplikowane. W związku z tym zapis uznaje się za zakończony, gdy tylko pamięć lokalna go potwierdza.

Replikacja asynchroniczna poprawia wydajność i dostępność sieci bez wpływu na przepustowość. Wynika to z faktu, że repliki nie są aktualizowane w czasie rzeczywistym. Minusem jest to, że w scenariuszu katastrofy strona DR może nie zawierać ostatnio wprowadzonych zmian, więc niektóre krytyczne dane mogą zostać utracone.

Na to pytanie nie ma jednoznacznej odpowiedzi; wybór zależy całkowicie od priorytetów biznesowych. Asynchroniczna replikacja działa najlepiej w przypadku projektów obejmujących duże odległości, którym przydzielony jest minimalny budżet. Jest także odpowiednia dla firm, które mogą sobie pozwolić na częściową utratę danych. Z drugiej strony replikacja synchroniczna jest wykonywana, gdy wymagane jest niezawodne i długoterminowe przechowywanie, a firma nie może pozwolić sobie na utratę krytycznych danych. Jest to przydatne, gdy RTO i RPO są krótkie.

Istnieje jednak pole pośrednie: można używać zarówno synchronicznych, jak i asynchronicznych strategii replikacji na różnych poziomach infrastruktury. Na przykład replikacja synchroniczna może być używana do przesyłania i zabezpieczania danych przez sieć lokalną (LAN), podczas gdy replikacja asynchroniczna wysyła krytyczne dane do zdalnej lokalizacji DR.

Tryb replikacji

Replikacja w NAKIVO Backup&Replication jest zawsze przyrostowa . Pierwsza replikacja kopiuje pełną maszynę wirtualną, ale następujące zadania replikacji będą zapisywać tylko zmiany danych w replice (przyrostach). Ponadto po każdym zadaniu replikacji tworzony jest punkt odzyskiwania odwołujący się do wszystkich bloków danych wymaganych do odtwarzania maszyny wirtualnej. Ten tryb replikacji zapewnia mniejsze obciążenie sieci i oszczędza czas, który w innym przypadku zostałby poświęcony na pełne zadania replikacji.

Zgodne platformy

NAKIVO Backup & Replication oferuje szybkie wdrażanie na różnych platformach sprzętowych i programowych:

• VMware VA. Wstępnie skonfigurowany VMware Virtual Appliance można łatwo pobrać, a następnie zaimportować do VMware vSphere.
• Instalując NAKIVO Backup & Replication bezpośrednio na urządzeniu NAS, można stworzyć własne urządzenie do tworzenia kopii zapasowych VM.
• AWS AMI. Oprogramowanie NAKIVO Backup & Replication można wdrożyć w chmurze Amazon jako wstępnie skonfigurowany obraz Amazon Machine Image (AMI).
• Oprogramowanie NAKIVO Backup & Replication można zainstalować na fizycznej lub wirtualnej maszynie z systemem Linux za pomocą jednego polecenia.
• Oprogramowanie NAKIVO Backup & Replication można zainstalować na fizycznym lub wirtualnym komputerze z systemem Windows za pomocą jednego kliknięcia.

Migawki

Migawka rejestruje stan systemu w określonym momencie. Za pomocą NAKIVO Backup & Replication repliki VM są tworzone za pomocą migawek VM, które służą do pobierania aktualnych danych maszyn wirtualnych. Za każdym razem, gdy wykonywane jest zadanie replikacji, pobierana jest tymczasowa migawka maszyny wirtualnej, zmienione dane są identyfikowane, a wszystkie aktualizacje są dodawane do repliki. Po zakończeniu zadania migawka zostaje usunięta.

Changed block tracking

Oprogramowanie NAKIVO Backup & Replication wykorzystuje VMware CBT (Changed Block Tracking) i Hyper-V RCT (Resilient Change Tracking) do identyfikowania i kopiowania zmian, które zostały wprowadzone w maszynie wirtualnej od czasu ostatniej replikacji. Ta technologia znacząco poprawia szybkość replikacji. Jeśli CBT i RCT są niedostępne, NAKIVO Backup & Replication używa wbudowanej zastrzeżonej metody śledzenia zmian.

Obsługa aplikacji na żywo

NAKIVO Backup & Replication to rozwiązanie obsługujące aplikacje. Maszyny wirtualne są używane do uruchamiania wszelkiego rodzaju aplikacji o znaczeniu krytycznym, takich jak Microsoft Exchange, Active Directory, SQL, SharePoint itp. W przypadku tych programów z częstym wprowadzaniem i generowaniem danych istotne jest zapewnienie, że dane aplikacji są zawsze spójne, szczególnie gdy zadanie replikacji jest uruchomione. Tak więc po utworzeniu migawki aplikacje wewnątrz maszyny wirtualnej przechowują wszystkie transakcje w pamięci, aby nie zakłócać żadnych działających operacji.

Ochrona kontenera

Program NAKIVO Backup & Replication ułatwia ochronę krytycznych maszyn wirtualnych, umożliwiając ich uporządkowanie w kontenerach, takich jak pule zasobów, foldery lub klastry. Cały kontener można dodać do określonego zadania replikacji. Można łatwo dodawać lub usuwać elementy z kontenera, które to zmiany są automatycznie odzwierciedlane w odpowiednich zadaniach replikacji. Funkcja jest elastyczna; można również wykluczyć niektóre maszyny wirtualne z kontenera z zadania replikacji. W takim przypadku cały kontener zostanie objęty ochroną z wyjątkiem wykluczonych maszyn wirtualnych.

Screenshot verification

Ta funkcja umożliwia automatyczne sprawdzenie, czy replikacja maszyn wirtualnych zakończyła się pomyślnie. Zaraz po zakończeniu zadania replikacji sieć w replice jest wyłączona, a replika jest chwilowo włączona, aby wykonać zrzut ekranu. Replika jest następnie wyłączana i powracana do najnowszego punktu odzyskiwania. Użytkownik otrzymuje raport e-mail ze zrzutem ekranu z testowanego systemu operacyjnego.

Grupowanie zadań

NAKIVO Backup & Replication pozwala organizować zadania replikacji w grupy (foldery), aby rozmieścić aplikacje, usługi i lokalizacje w strukturach logicznych. Ponadto akcje zbiorcze można łatwo wykonać dla wszystkich lub wybranych zadań dla grupy.

Automatyczne raporty

Jeśli chcemy być informowani o statusie zadań replikacji, NAKIVO Backup & Replication może powiadomić nas o tym, wysyłając automatyczne raporty e-mailem, według harmonogramu lub na żądanie.

Harmonogram zadań

Program NAKIVO Backup & Replication umożliwia konfigurowanie zadań replikacji uruchamianych na żądanie lub zgodnie z harmonogramem (codziennie, co tydzień, co miesiąc i co rok). Możesz nawet skonfigurować zadania, aby działały według niestandardowego harmonogramu, który odpowiada konkretnym potrzebom biznesowym, np. co 20 minut, co 5 dni lub w pierwszy wtorek każdego miesiąca. Możesz także określić okna czasowe, w których zadanie powinno się rozpoczynać i kończyć.

Etapowa replikacja VM (wysiewanie)

Początkowa (pełna) replikacja większych maszyn wirtualnych może zająć dużo czasu ze względu na ich rozmiar. Aby przyspieszyć proces, NAKIVO Backup & Replication może przeprowadzić etapową replikację maszyn wirtualnych. Ta funkcja umożliwia przeniesienie (“seed”) początkowych replik VM na nośniki wymienne. Następnie repliki te można przetransportować do nowej witryny, gdzie nowe zadanie replikacji jest uruchamiane przy użyciu przesłanych maszyn wirtualnych. Następnie wykonywana jest tylko przyrostowa replikacja.

Punkty odzyskiwania

Punkt odzyskiwania reprezentuje maszynę wirtualną w określonym momencie, która następnie jest używana do odzyskiwania VM. Za pomocą narzędzia NAKIVO Backup & Replication można przechowywać do 30 punktów odzyskiwania na replikę maszyny wirtualnej. Produkt umożliwia zapisywanie punktów przywracania zgodnie z zasadami przechowywania Grandfather-Father-Son (GFS), jak opisano poniżej. Ta metoda zapewnia, że ​​punkty odzyskiwania repliki VM są zapisywane w witrynie DR z wyznaczonymi częstotliwościami (np. codziennie, co tydzień, co miesiąc i co rok).

• Zachowaj jeden punkt przywracania na tydzień przez X tygodni: Ostatni punkt odzyskiwania każdego tygodnia jest przechowywany przez określoną liczbę tygodni.
• Zachowaj jeden punkt odzyskiwania miesięcznie przez X miesięcy: Ostatni punkt odzyskiwania każdego miesiąca jest przechowywany przez określoną liczbę miesięcy.
• Zachowaj jeden punkt odzyskiwania rocznie przez X lat: Ostatni punkt odzyskiwania każdego roku jest przechowywany przez określoną liczbę lat.
• RTO i RPO

Cel punktu odzyskiwania (RPO) to limit najwcześniejszego momentu, w którym maszyna wirtualna powinna zostać przywrócona podczas DR. W ten sposób określa ilość danych, które można utracić, nie powodując nieuzasadnionych szkód dla Twojej firmy. Replikacja może pomóc w spełnieniu krótszych RPO, ponieważ zadania replikacji można uruchamiać według potrzeb za pomocą niestandardowych harmonogramów ustawionych dla nich.

Replikacja maszyn wirtualnych może również pomóc w osiągnięciu krótkich czasów odzyskiwania (RTO). RTO to określony czas, w którym operacje biznesowe muszą zostać odzyskane po katastrofie. Dzięki replikacji maszynę wirtualną można natychmiast przywrócić, uruchamiając replikę.

Replikacja maszyn wirtualnych może chronić usługi o kluczowym znaczeniu dla biznesu przed wieloma problemami, w tym powodowanymi przez krytyczną utratę VM/awarię maszyny wirtualnej, awarię hosta/magazynu danych lub klęski żywiołowe. Replikacja maszyn wirtualnych jest zwykle używana, gdy projekty działają z danymi wrażliwymi i/lub tolerują utratę danych zerowych. Replikacja jest odpowiednia dla tych przypadków, ponieważ odzyskiwanie VM może być wykonane łatwo i prawie natychmiast po wystąpieniu awarii.

Funkcja replikacji jest używana w następujących przypadkach:

1. Odzyskiwanie po awarii z repliką

Za pomocą NAKIVO Backup & Replication można w znacznym stopniu złagodzić negatywne skutki awarii systemu, takie jak przestoje i utrata dochodów. Dzięki replikacji maszyn wirtualnych możesz niemal natychmiast odzyskać całą maszynę wirtualną za pomocą jej repliki, zapewniając w ten sposób wysoką dostępność usług biznesowych.

2. Przełączanie awaryjne oraz powrót po awarii
   

Kiedy katastrofa pozbawi nas podstawowej bazy danych, firma może zostać poważnie dotknięta – chyba że mamy efektywny plan DR. Tutaj przydatne jest przełączanie awaryjne. Przełączanie awaryjne, to proces przełączania ze źródłowej maszyny wirtualnej na replikę maszyny wirtualnej w celu przeniesienia obciążeń o znaczeniu krytycznym z witryny, której dotyczy problem, do witryny DR.

Po przywróceniu głównej lokacji możesz przełączyć operacje biznesowe z powrotem na oryginalną maszynę wirtualną. Ten proces nazywany jest funkcją powrotu po awarii i umożliwia synchronizację danych między lokacją główną a witryną DR.

3. Odzyskiwanie lokalizacji
   

Za pomocą narzędzia NAKIVO Backup & Replication można tworzyć przepływy pracy (zadania) odzyskiwania lokalizacji, które są łatwymi w konfiguracji niestandardowymi algorytmami do automatyzacji i orkiestracji procesu DR. Ręczna realizacja planu odzyskiwania po awarii może być czasochłonnym i wymagającym dużej ilości zasobów zadaniem. Na szczęście, NAKIVO Backup & Replication pozwala organizować akcje w zadania odzyskiwania lokalizacji, które można uruchomić za pomocą zaledwie kilku kliknięć. Możesz utworzyć specjalne zadania Site Recovery, aby poradzić sobie z dowolnym zdarzeniem DR.

Poniższe działania i warunki można uwzględnić w przepływach pracy odzyskiwania lokalizacji:

• Przełączanie awaryjne maszyn wirtualnych. Przejście do już utworzonej repliki VM.
• Powrót po awarii maszyn wirtualnych. Przeniesienie obciążeń z powrotem z repliki maszyny wirtualnej w witrynie DR do źródłowej maszyny wirtualnej w miejscu produkcji.
• Uruchomienie maszyn wirtualnych. Uruchamiamy jedną lub wiele maszyn wirtualnych.
• Zatrzymanie maszyn wirtualnych. Zatrzymanie jednej lub wielu maszyn wirtualnych.
• Uruchomienie zadań. Uruchomienie zadań ochrony danych (tworzenie kopii zapasowych, replikacja itd.), które już zostały utworzone dla maszyn wirtualnych.
• Zatrzymanie zadań. Zatrzymanie zadań ochrony danych VM, które są uruchomione.
• Uruchomienie skryptu. Uruchomienie własnego skryptu przed lub po zadaniu na komputerze z systemem Windows lub Linux.
• Załączenie repozytorium. Dołączenie repozytorium kopii zapasowych.
• Odłączenie repozytorium. Odłączenie dołączonych repozytorium kopii zapasowych.
• Wysyłanie e-maili. Otrzymywanie powiadomień e-mail z informacją o wynikach po wykonaniu określonej czynności.
• Czekać. Zaczekaj na określony czas przed rozpoczęciem następnej akcji.
• Sprawdź stan. Sprawdź, czy istnieje zasób, czy uruchomiony jest zasób, lub czy adres IP/nazwa hosta są osiągalne przed przejściem do następnej czynności.

Każda firma może paść ofiarą niespodziewanej katastrofy lub awarii systemu, która może zagrozić integralności ważnych dla firmy danych. To sprawia, że ​​posiadanie efektywnego planu DR jest absolutnie niezbędne w nowoczesnym świecie biznesu, gdzie wysoka dostępność i ciągłość biznesowa są najważniejsze.

Replikacja może stać się nieocenionym narzędziem dla DR. Synchroniczne i asynchroniczne strategie replikacji powinny być wdrażane inteligentnie, w zależności od priorytetów i potrzeb biznesowych. Asynchroniczna replikacja to opłacalna strategia, która wymaga mniejszej przepustowości i braku dodatkowego sprzętu. Może być używany do przechowywania mniej wrażliwych danych i przesyłania danych na duże odległości. Chociaż replikacja synchroniczna jest wysoce zależna od połączenia sieciowego i opóźnień, gwarantuje zerową utratę danych i pozwala natychmiastowo przywrócić operacje o znaczeniu krytycznym.

NAKIVO Backup & Replication to szybkie i elastyczne rozwiązanie, które może replikować maszyny wirtualne do jednej lub więcej zdalnych lokalizacji w celu niezawodnego przechowywania. Dzięki rozwiązaniu można po prostu włączyć repliki podczas awarii, unikając w ten sposób utraty przychodów i długotrwałego wyłączania.

Jeśli chodzi o utrzymanie infrastruktury informatycznej organizacji przez 24 godziny na dobę, 7 dni w tygodniu, nadal istnieją pewne niejasności między trzema głównymi terminami używanymi w tej dziedzinie. Te podstawowe pojęcia to: wysoka dostępność (HA – high availability), tolerancja uszkodzeń (FT – fault tolerance) i odzyskiwanie po awarii (DR – disaster recovery). Terminy te są często używane zamiennie, ponieważ na pozór wszystkie mają na celu osiągnięcie ciągłości systemu informatycznego. Ważne jest jednak, aby pamiętać, że każde z tych terminów ma swoje własne specyficzne definicje, metodologie i role.

W tym artykule w praktyce określimy znaczenie wysokiej dostępności, tolerancji uszkodzeń i odzyskiwania po awarii. Sprawdzimy, jak te terminy się pokrywają, a także dlaczego warto je wdrożyć.

Wysoka dostępność jest cechą systemu, który ma na celu zapewnienie uzgodnionego poziomu wydajności operacyjnej, zwykle nieprzerwanego działania, przez okres dłuższy niż normalny.

HA to koncepcja, która przejawia się wyłącznie dzięki technologii. Celem projektu HA jest dostarczenie 99,999% czasu pracy bez przestojów. Niemniej jednak ważne jest, aby podkreślić, że HA nie zapewnia 100% czasu działania, a czas przestoju (do 5,26 minuty/rok) jest akceptowalny.

Cel “pięciu dziewiątek” osiąga się przez wyeliminowanie pojedynczego punktu awarii w systemie. W tym celu można wdrożyć komponenty redundancji i przełączania awaryjnego, które są skonfigurowane do obsługi obciążeń bez interwencji człowieka w przypadku awarii komponentu podstawowego.

W wirtualizacji można zaprojektować wysoką dostępność za pomocą technologii klastrowych. Na przykład, gdy jeden z hostów lub maszyn wirtualnych (VM) w klastrze ulegnie awarii, inna maszyna wirtualna przejmuje i utrzymuje właściwą wydajność systemu.

Przemyślana architektura HA jest ważna dla każdej firmy, która dąży do zminimalizowania przestojów. Według statystyk, w 2017 r. koszt godzinnego przestoju wynosił od 301 do 400 tys. USD dla dużej liczby (24%) przedsiębiorstw na całym świecie. Oznacza to, że nawet dopuszczalna ilość przestojów – 5,26 minut – kosztuje biznes do 35 tysięcy USD.

Oprócz znacznych strat finansowych, przestoje mogą mieć inne poważne konsekwencje, takie jak utrata wydajności, niemożność terminowego dostarczania usług, utrata reputacji firmy i tak dalej. Wysoce dostępne systemy pomagają uniknąć takich scenariuszy poprzez automatyczne rozwiązywanie awarii i na czas.

Posiadanie komponentów redundantnych jest podstawowym warunkiem zapewnienia wysokiej dostępności, jednak posiadanie tych komponentów nie wystarcza, aby system mógł być uważany za wysoce dostępny. System wysoce dostępny to taki, który zawiera zarówno nadmiarowe komponenty i mechanizmy wykrywania awarii, jak i przekierowanie obciążenia. Mogą to być elementy równoważące obciążenie lub hypervisor.

Tolerancja uszkodzeń jest właściwością, która umożliwia systemowi prawidłowe działanie w przypadku awarii niektórych (jednego lub więcej błędów wewnątrz) jego komponentów.

Mówiąc prościej, tolerancja uszkodzeń, to bardziej rygorystyczna wersja wysokiej dostępności. HA skupia się na zapewnieniu minimalnych przestojów, a FT idzie dalej, zapewniając zero przestojów. Jednak w modelu tolerancji uszkodzeń zdolność systemu do zapewnienia wysokiej wydajności w przypadku awarii nie jest priorytetem. W przeciwieństwie, oczekuje się, że system może utrzymać wydajność operacyjną, ale na obniżonym poziomie.

Podobnie jak w przypadku wysokiej dostępności, tolerancja uszkodzeń działa również na zasadzie nadmiarowości. Taka nadmiarowość może zostać osiągnięta poprzez jednoczesne uruchomienie jednej aplikacji na dwóch serwerach, co umożliwia jednemu serwerowi natychmiastowe przejęcie drugiego, jeśli mu się nie powiedzie.

W wirtualizacji nadmiarowość jest osiągana poprzez utrzymywanie i uruchamianie identycznych kopii danej maszyny wirtualnej na osobnym hoście. Wszelkie zmiany lub dane wejściowe, które mają miejsce na podstawowej maszynie wirtualnej, są duplikowane na wtórnej maszynie wirtualnej. W ten sposób, w przypadku uszkodzenia maszyny wirtualnej, tolerancja na awarie jest zapewniona poprzez natychmiastowy transfer obciążeń z jednej maszyny wirtualnej do jej kopii.

Tolerancja uszkodzeń jest niezbędna do wdrożenia, jeśli Nasz system IT nie toleruje żadnych przestojów. Jeśli istnieją krytyczne aplikacje, które wspierają operacje biznesowe, a nawet najmniejszy czas przestoju może przełożyć się na nieodwracalne straty, powinniśmy rozważyć skonfigurowanie swoich komponentów IT z myślą o FT.

System tolerujący uszkodzenia, to system, który obejmuje dwa ściśle połączone elementy, które odzwierciedlają się nawzajem, zapewniając nadmiarowość. W ten sposób, jeśli podstawowy komponent zostanie wyłączony, drugi jest zawsze gotowy do natychmiastowego przejęcia.

Odzyskiwanie awaryjne obejmuje zestaw zasad, narzędzi i procedur umożliwiających odzyskiwanie lub kontynuację infrastruktury i systemów infrastruktury o podstawowym znaczeniu w następstwie katastrofy naturalnej lub wywołanej przez człowieka.

Zwykle DR wymaga posiadania dodatkowej lokalizacji, w której można przywrócić krytyczne dane i obciążenia (całkowicie lub częściowo) w celu wznowienia wystarczającej działalności biznesowej po wystąpieniu zakłócającego zdarzenia. Aby przenieść obciążenia do zdalnej lokalizacji, konieczne jest włączenie odpowiedniego rozwiązania do odtwarzania po awarii. Takie rozwiązanie może w porę zająć się operacją przełączania awaryjnego przy niewielkim lub zerowym wkładzie ze strony użytkownika, co pozwala osiągnąć wyznaczone cele czasu przywracania.

Zwykle DR wymaga posiadania dodatkowej lokalizacji, w której można przywrócić krytyczne dane i obciążenia (całkowicie lub częściowo) w celu wznowienia wystarczającej działalności biznesowej po wystąpieniu zakłócającego zdarzenia. Aby przenieść obciążenia do zdalnej lokalizacji, konieczne jest włączenie odpowiedniego rozwiązania do odtwarzania po awarii. Takie rozwiązanie może w porę zająć się operacją przełączania awaryjnego przy niewielkim lub zerowym wkładzie ze strony użytkownika, co pozwala osiągnąć wyznaczone cele czasu przywracania.

W przeciwieństwie do HA i FT, odzyskiwanie po awarii jest znacznie szerszą i bardziej złożoną koncepcją, która odnosi się do strategii z obszernym zestawem komponentów, w tym: ocena ryzyka, planowanie, analiza zależności, zdalna konfiguracja lokalizacji, szkolenie personelu, testowanie, konfiguracja automatyzacji i tak dalej. Odzyskiwanie po awarii wykracza poza wysoką dostępność i tolerancję uszkodzeń, ale może i powinno uwzględniać te czynniki w jego projekcie technologicznym.

Termin katastrofa odnosi się nie tylko do klęski żywiołowej, ale także do wszelkich zakłóceń, które prowadzą do znaczących przestojów, takich jak ataki cybernetyczne, przerwy w zasilaniu, błędy ludzkie, awarie oprogramowania i inne incydenty. Oznacza to, że takie wydarzenia mogą odbywać się w dowolnym miejscu i czasie, co sprawia, że ​​organizacje wszystkich typów i rozmiarów są potencjalnymi ofiarami. Podczas gdy w większości przypadków katastrofy są niemożliwe do przewidzenia lub uniknięcia, organizacje mogą i powinny podejmować działania w celu wzmocnienia gotowości do odzyskiwania po awarii, a także regularnie optymalizować swoje strategie DR.

NAKIVO Backup & Replication to szybkie, niezawodne i przystępne cenowo rozwiązanie, które łączy w sobie wysoką ochronę danych, a także funkcję odzyskiwania po awarii w jednym pakiecie oprogramowania. Funkcja Site Recovery została zaprojektowana z myślą o prostocie i automatyzacji operacji odzyskiwania po awarii.

Jeśli mamy skonfigurowaną witrynę zdalną, zgodnie z najlepszymi praktykami DR, możemy całkowicie polegać na NAKIVO Backup & Replication jako narzędziu do odzyskiwania po awarii. Funkcja przywracania lokalizacji jest łatwa w obsłudze i konfiguracji, ale umożliwia tworzenie złożonych przepływów pracy odzyskiwania.

Można połączyć do 200 działań w jednym przepływie pracy (zadaniu), aby dopasować się do różnych scenariuszy katastrofy i służyć do różnych celów, w tym: monitorowania, migracji centrów danych, awaryjnego przełączania awaryjnego, planowanego przełączania awaryjnego, powrotu po awarii itd. W razie katastrofy utworzone przepływy pracy można natychmiast wdrożyć, za pomocą jednego kliknięcia, co pozwala firmom osiągnąć jak najkrótszy czas na odzyskanie danych.

Dzięki funkcji Site Recovery możemy przeprowadzać automatyczne, niezakłócone testy DR. W ten sposób możemy upewnić się, że przepływy pracy odzyskiwania lokalizacji są poprawne i odzwierciedlają wszystkie ostatnie zmiany, które miały miejsce w naszej infrastrukturze IT, w celu wykluczenia ewentualnych słabości przed rzeczywistymi trafieniami po katastrofie.

Statystyki pokazują, że większość informatyków uważa nowoczesne rozwiązania DR za nieosiągalne luksusy, a nie niezbędny element w ich strategii ochrony i odzyskiwania danych. NAKIVO dokonało niezawodnego odzyskiwania po awarii, dostępnego dla wielu firm, oferując NAKIVO Backup & Replication z Site Recovery za ułamek kosztów w porównaniu do konkurentów.

Podczas gdy wysoka dostępność i tolerancja na uszkodzenia są wyłącznie technologiczne, odzyskiwanie po awarii obejmuje znacznie więcej niż tylko elementy oprogramowania/sprzętu. HA i FT koncentrują się na rozwiązywaniu pojedynczych awarii w systemie IT. DR przeciwnie, zajmuje się problemami o znacznie większym zasięgu, a także konsekwencjami takich awarii. Włączenie wysokiej dostępności lub tolerancji na uszkodzenia nie może zapewnić ochrony przed katastrofami, ale obie z nich mogą skutecznie uzupełnić strategie odzyskiwania po awarii.

NAKIVO Backup & Replication z Site Recovery to rozwiązanie “pod klucz”, które zapewnia zintegrowaną ochronę przed utratą danych. Włączając rozwiązanie do swojego środowiska, możemy zapewnić szybkie odzyskiwanie danych w wielu witrynach niezależnie od okoliczności.

Site Recovery to nowa zaawansowana funkcja, która została wydana wraz z NAKIVO Backup & Replication 8.0. Dzięki funkcji Site Recovery można łatwo utworzyć plan przywracania po awarii dla danego środowiska i przywrócić maszyny wirtualne przy użyciu odpowiednich obciążeń. W poprzednim artykule dotyczącym Site Recovery analizowaliśmy awaryjne przełączanie VM, które może być użyte jako działanie dla zadania Site Recovery i może przełączyć się ze źródłowej maszyny wirtualnej na replikę maszyny wirtualnej. Dzisiejszy artykuł obejmuje akcję powrotu po awarii (która jest odwróceniem do pracy awaryjnej), rolę powrotu po awarii dla odzyskiwania lokalizacji i sposób wykorzystania działania powrotu po awarii.

Przełączanie awaryjne oznacza przeniesienie obciążeń maszyny źródłowej VM na replikę maszyny wirtualnej, która jest identyczną kopią źródłowej maszyny wirtualnej w odpowiednim momencie. Można to zrobić, ponieważ miejsce produkcji (gdzie zlokalizowana jest źródłowa maszyna wirtualna) zostało naruszone przez jakąś katastrofę lub z wyprzedzeniem, jeśli przewiduje się katastrofę. Replika maszyny wirtualnej zazwyczaj znajduje się w tymczasowej, geograficznie oddzielnej lokalizacji zwanej witryną odzyskiwania po awarii (DR). Kiedy źródłowa maszyna wirtualna przestaje działać, a proces przełączania awaryjnego jest używany, wszystkie zmiany po przełączeniu awaryjnym są zapisywane w replice maszyny wirtualnej, ale nie w źródłowej maszynie wirtualnej. Po utworzeniu kopii zapasowej witryny produkcyjnej i ponownym uruchomieniu źródłowej maszyny wirtualnej zmiany wprowadzone do repliki maszyny wirtualnej od momentu przełączenia awaryjnego muszą zostać przesłane do źródłowej maszyny wirtualnej. W związku z tym dane są ponownie synchronizowane z replikacją wsteczną.

Powrót awaryjny jest procesem przywracania maszyn wirtualnych w ich rzeczywistych stanach do miejsca produkcji z witryny DR i zwracania obciążeń do miejsca produkcji, które pierwotnie sobie z nimi radziło. Ewentualnie można przenieść obciążenia do nowej witryny produkcyjnej z funkcją powrotu po awarii. Zastanówmy się, w jaki sposób dane są przesyłane za pomocą przykładu.

1. Istnieją dwie witryny: strona produkcyjna i strona odzyskiwania po awarii (DR). Maszyna wirtualna jest replikowana z witryny produkcyjnej do witryny DR. Źródłowa maszyna wirtualna znajduje się w miejscu produkcji, podczas gdy jej replika VM znajduje się na stronie odtwarzania po awarii. Dane na dyskach wirtualnych źródłowej maszyny wirtualnej i repliki maszyny wirtualnej są identyczne po replikacji. Po wystąpieniu awarii następuje przełączenie awaryjne na replikę maszyny wirtualnej.

2. Po przeprowadzeniu przełączenia awaryjnego na replikę maszyny wirtualnej zadania zostały przeniesione do witryny odzyskiwania po awarii. Wszelkie dalsze zmiany maszyny wirtualnej (np. transakcje dodane do bazy danych, gdy klienci dokonują zakupów online) są zapisywane na wirtualnym dysku repliki maszyny wirtualnej podczas działania. Niektóre bloki są zapisywane, a niektóre bloki są kasowane. Dysk wirtualny źródłowej maszyny wirtualnej nie uwzględnia tych transakcji.Wszystkie zmiany są zapisywane w replice maszyny wirtualnej po przywróceniu systemu po awarii i przełączeniu awaryjnym.

3. Szkody spowodowane przez katastrofę zostały rozwiązane (lub zagrożenie minęło). Zakład produkcyjny jest znowu funkcjonalny i, odpowiednio, obciążenia muszą zostać zwrócone do miejsca produkcji ze strony DR. Zaktualizowane dane z repliki VM muszą zostać przesłane z powrotem do źródłowej maszyny wirtualnej. Maszyny wirtualne muszą zostać ponownie zsynchronizowane z replikacją wsteczną w ramach procesu powrotu po awarii.

Korzystanie z funkcji powrotu po awarii wbudowanej w NAKIVO Backup & Replication zapewnia następujące korzyści:

• Dane maszyny wirtualnej pozostają aktualne po przełączeniu z witryny DR do miejsca produkcji.
• Możemy zautomatyzować proces migracji danych i obciążeń z powrotem do miejsca produkcji. Nie ma konieczności usuwania starych maszyn wirtualnych z miejsca produkcji i ręcznego kopiowania danych z każdej repliki maszyny wirtualnej z witryny DR do zakładu produkcyjnego.
• Automatyzacja minimalizuje przestoje podczas migracji obciążeń z witryny DR do miejsca produkcji.

W celu umożliwienia powrotu po awarii, muszą być spełnione następujące warunki:

• Replika maszyny wirtualnej istnieje i znajduje się w stanie pracy awaryjnej (tzn. replika przejęła obciążenie z oryginalnej maszyny wirtualnej).
• Oryginalna wirtualna maszyna źródłowa istnieje lub określono nową lokalizację.

Powrót awaryjny można wykonać w trybie produkcyjnym lub w trybie testowym. Zastanówmy się, jak każdy przypadek działa w szczegółach.

Wykonanie powrotu po awarii wiąże się z następującymi punktami:

• Wyłączanie źródłowej maszyny wirtualnej (jeśli istnieje i jest włączona).
• Tworzenie ochronnej migawki źródłowej maszyny wirtualnej (jeśli źródłowa maszyna wirtualna jest funkcjonalna). Utworzenie tej migawki pozwala przywrócić stan przed awarią źródłowej maszyny wirtualnej w przypadku, gdy niepowodzenie powrotu nie może być wykonane prawidłowo.
• Uruchamianie replikacji przyrostowej (jeśli pierwotna źródłowa maszyna wirtualna jest w trybie online w miejscu produkcji) lub pełnej replikacji (jeśli maszyna wirtualna jest odzyskiwana do nowej witryny produkcyjnej) z repliki maszyny wirtualnej do źródłowej maszyny wirtualnej jednokrotnie.
• Wyłączanie repliki VM (opcjonalnie).
• Ponowne uruchomienie przyrostowej replikacji z repliki VM do źródłowej maszyny wirtualnej. Po tym kroku delta (różnica w danych) między repliką maszyny wirtualnej a źródłową maszyną wirtualną powinna być znacznie mniejsza.
• Łączenie oryginalnej wirtualnej maszyny wirtualnej z nową siecią za pomocą mapowania sieciowego (opcjonalnie).
• Modyfikowanie statycznego adresu IP oryginalnej źródłowej maszyny wirtualnej za pomocą Re-IP (opcjonalnie).
• Włączanie oryginalnej wirtualnej maszyny wirtualnej.

Po zakończeniu powrotu po awarii następuje czyszczenie. Algorytm czyszczenia różni się w zależności od wyniku operacji powrotu po awarii.

Aby wykonać czyszczenie po pomyślnym uruchomieniu, należy wykonać trzy kroki:

• Ochronna migawka jest usuwana z oryginalnej źródłowej maszyny wirtualnej.
• Zadanie replikacji jest rekonfigurowane, aby użyć nowo utworzonej maszyny wirtualnej podstawowej (źródłowej) zamiast starej (opcjonalnie, dotyczy sytuacji, w której nie powiodło się przejście na nową maszynę wirtualną).
• Przełączanie repliki maszyny wirtualnej ze stanu przełączenia awaryjnego (operacyjnego) na stan normalny.

Po pomyślnej operacji powrotu po awarii zarówno źródłowa maszyna wirtualna, jak i replika maszyny wirtualnej istnieją w normalnych stanach.

Jeśli operacja powrotu po awarii nie zostanie pomyślnie wykonana, z dowolnego powodu, wykonywane są trzy inne kroki w celu przywrócenia stanu środowiska do stanu sprzed powrotu po awarii:

• Przywracanie źródłowej maszyny wirtualnej do utworzonej migawki ochronnej.
• Usuwanie ochronnej migawki ze źródłowej maszyny wirtualnej.

Ponowne włączanie repliki VM.

Testowanie po awarii jest wykonywane po uruchomieniu zadania Site Recovery, które obejmuje działanie powrotu po awarii w trybie testowym ręcznie lub gdy zadanie odzyskiwania lokacji działa zgodnie z harmonogramem. Procedura testowego powrotu awaryjnego różni się od procedury powrotu po awarii. Po ponownym uruchomieniu testu wszystkie zmiany w środowisku wirtualnym wykonane przez działanie powrotu po awarii są przywracane do stanu sprzed powrotu po awarii.

Procedura testowego powrotu awaryjnego wygląda następująco:

• Wyłączanie oryginalnej wirtualnej maszyny wirtualnej (jeśli jest funkcjonalna i włączona).
• Tworzenie ochronnej migawki oryginalnej wirtualnej maszyny wirtualnej (jeśli jest funkcjonalna).
• Uruchamianie replikacji przyrostowej (jeśli oryginalna wirtualna maszyna źródłowa istnieje) lub pełna replikacja z repliki maszyny wirtualnej do nowej wirtualnej maszyny źródłowej.
• Podłączanie źródłowej maszyny wirtualnej do odizolowanej sieci (opcjonalnie).
• Modyfikowanie statycznego adresu IP źródłowej maszyny wirtualnej (opcjonalnie).
• Włączanie źródłowej maszyny wirtualnej.

Jak widać, podczas testowego powrotu po awarii replika maszyny wirtualnej służy do obsługi obciążeń roboczych i nie jest wyłączona, co kontrastuje z procedurą powrotu po awarii produkcji. Replikacja z repliki VM do oryginalnej maszyny wirtualnej VM (lub nowej wirtualnej maszyny produkcyjnej) jest wykonywana raz, a nie dwa razy, ponieważ jest to wystarczające do celów testowych. W takim przypadku źródłowa maszyna wirtualna może zostać podłączona do odizolowanej sieci, tak aby nie było żadnych zakłóceń w środowisku produkcyjnym.

Testowe czyszczenie po powrocie po awarii nieznacznie różni się od czyszczenia po powrocie po awarii.

Jeśli źródłowa maszyna wirtualna nie istniała przed uruchomieniem testowego powrotu po awarii:

• Usuwanie źródłowej maszyny wirtualnej.

Jeśli źródłowa maszyna wirtualna istniała już przed uruchomieniem testowego powrotu po awarii:

• Przywracanie źródłowej maszyny wirtualnej do jej stanu po zrobieniu ochronnej migawki.
• Włączanie źródłowej maszyny wirtualnej (jeśli była wyłączona).

Usuwanie ochronnej migawki ze źródłowej maszyny wirtualnej.

Najpierw należy utworzyć zadanie przywracania lokalizacji obejmujące działania przełączania awaryjnego. Proces ten został szczegółowo opisany w poprzednim artykule z serii Site Recovery. Zadanie replikacji i replika maszyny wirtualnej są wymagane do wykonania przełączania awaryjnego. Zadanie przywracania lokalizacji musi zawierać działanie przełączania awaryjnego w celu wykonania powrotu po awarii. Repliki VM muszą znajdować się w stanie przełączania awaryjnego; w związku z tym można wykonać procedurę powrotu po zakończeniu przełączania awaryjnego. Kiedy wszystkie problemy spowodowane przez katastrofę zostaną rozwiązane w miejscu produkcji, możemy przygotować się na powrót do źródłowych maszyn wirtualnych.

Wykorzystajmy przykład instruktażowy, jak wykonać powrót po awarii przy pomocy NAKIVO Backup & Replication. Najpierw upewniamy sięę, że przełączanie awaryjne zostało uruchomione jako część zadania Site Recovery (powinno to już zostać utworzone).

Następnie tworzymy nowe zadanie Site Recovery; akcje powrotu awaryjnego mogą zostać włączone do tego zadania. Na stronie głównej interfejsu sieciowego NAKIVO Backup & Replication klikamy „Utwórz> Site recovery job”

Uruchomiony zostanie Kreator nowego zadania Site Recovery.

1. Działania. W lewym panelu interfejsu „Actions” klikamy opcję „Failback VMware VMs „(platforma VMware jest rozważana w tym przykładzie, ale można również obsługiwać funkcję powrotu po awarii tak samo łatwo w innych środowiskach – Hyper-V lub instancji EC2).

Wybieramy repliki VM, do których ma zostać zastosowana operacja przełączania awaryjnego. Klikamy „Następny”.

Wybieramy lokalizację powrotu po awarii – może to być oryginalna witryna produkcyjna lub nowa lokalizacja. Klikamy „Następny”.

Wybieramy opcje pracy. Zaznaczamy pole wyboru „Wyłączaj repliki VM”, jeśli to konieczne. Klikamy „Zapisz”, gdy będziemy gotowi do kontynuowania.

Po dodaniu akcji powrotu po awarii zadanie przywracania lokalizacji wygląda następująco (zrzut ekranu poniżej). Klikamy „Następny”.

2. Sieci. Zaznaczamy pole wyboru, jeśli chcemy włączyć mapowanie sieciowe dla tego zadania. Klikamy „Następny”.

3. Re-IP. Zaznaczamy pole wyboru, jeśli chcemy włączyć Re-IP dla tego zadania. Klikamy „Następny”.

4. Harmonogram testów. Konfigurujemy opcje planowania, a następnie klikamy przycisk „Dalej”.

5. Opcje. Określamy opcje zadania odzyskiwania lokalizacji i wprowadzamy nazwę zadania. Klikamy przycisk „Zakończ”, aby sfinalizować tworzenie nowego zadania przywracania lokalizacji z funkcją powrotu po awarii.

Teraz możemy uruchomić zadanie Site Recovery, aby wykonać awarię maszyny wirtualnej: po prostu klikamy prawym przyciskiem myszy nazwę zadania Site Recovery, wybieramy „Uruchom zadanie” i wybieramy „Przetestuj zadanie przywracania lokalizacji” lub „Uruchom zadanie odzyskiwania lokalizacji” zgodnie z potrzebami.

Powrót po awarii jest krytycznie ważną czynnością dla większości przepływów pracy odzyskiwania lokalizacji. Wykonuje się go w celu przywrócenia obciążeń do miejsca produkcji, przenosząc zaktualizowane dane z replik VM, które zostały użyte do odzyskiwania po awarii z powrotem do oryginalnych maszyn wirtualnych (lub do nowej maszyny wirtualnej w bardziej stałej lokalizacji). Funkcja powrotu po awarii pozwala zachować bieżące dane maszyny wirtualnej, zautomatyzować proces przesyłania danych i zminimalizować przestoje podczas migracji z witryny DR do miejsca produkcji.

Ten artykuł kończy naszą serię dotyczącą funkcji Site Recovery w NAKIVO Backup & Replication.  Jest to Złożona, ale przyjaznna dla użytkownika funkcja, dzięki której można elastycznie wdrożyć plan odzyskiwania po awarii i chronić środowisko wirtualne przed katastrofami.

W poprzednich artykułach z serii o Site Recovery analizowaliśmy planowanie przepływów pracy odzyskiwania lokalizacji, tworzenie zadań Site Recovery z operacjami przełączania awaryjnego oraz testowanie tych zadań. Działania przełączania awaryjnego są integralną częścią większości zadań związanych z odzyskiwaniem lokalizacji. Dzisiejszy artykuł zawiera opis działania przełączania awaryjnego, w tym sposób pracy awaryjnej, rodzaje przełączania awaryjnego i wymagania dotyczące przełączania awaryjnego. Zawiera się w nim również instrukcja konfiguracji i uruchamiania pracy awaryjnej w ramach zadania Site Recovery w NAKIVO Backup & Replication.

W kontekście środowisk zwirtualizowanych przełączanie awaryjne jest procesem przełączania się z wirtualnej maszyny źródłowej (produkcyjnej) na replikę maszyny wirtualnej w celu przenoszenia obciążeń. Replika maszyny wirtualnej to identyczna kopia źródłowej maszyny wirtualnej w odpowiednim momencie. Przełączanie awaryjne pozwala uzyskać wysoką dostępność, co jest cechą opisującą czas pracy maszyn wirtualnych jako procent.

Źródłowa maszyna wirtualna znajduje się w miejscu produkcji, podczas gdy replika maszyny wirtualnej jest często umieszczona w geograficznie oddzielnej lokalizacji odzyskiwania po awarii (DR). Przełączanie awaryjne jest trybem pracy, który sprawia, że ​​systemy o znaczeniu krytycznym są wysoce dostępne dzięki redundancji zapewnianej przez repliki VM.

Istnieją trzy typy przełączania awaryjnego: zaplanowane przełączanie awaryjne, testowe przełączanie awaryjne i awaryjne przełączanie awaryjne. Przyjrzyjmy się każdemu bardziej szczegółowo.

Zaplanowane przełączanie awaryjne – służy do przełączania obciążeń roboczych na replikę maszyny wirtualnej z zerową utratą danych. Tego typu przełączanie awaryjne może być używane proaktywnie, gdy potencjalna katastrofa jest przewidywana lub podejrzewana – na przykład firma elektryczna powiadomiła nas o planowanej awarii zasilania w biurze głównym w poniedziałek lub prognoza pogody ostrzega przed zagrożeniem powodziowym. Replikacja źródłowej maszyny wirtualnej jest wykonywana bezpośrednio przed planowanym przełączeniem awaryjnym w celu utworzenia nowego punktu przywracania.

Testowe przełączanie awaryjne jest używane w celu zapewnienia, że ​​maszyny wirtualne mogą się zepsuć i migracja zadań zakończyła się pomyślnie. Testowe przełączanie awaryjne działa podobnie do planowanego przełączania awaryjnego. Przeprowadzając testowe przełączanie awaryjne, możemy wyszkolić swoich pracowników do wykonywania operacji odzyskiwania po awarii, sprawdzić, czy plan odzyskiwania lokalizacji jest możliwy do wykonania i sprawdzić, ile czasu potrzeba na przeprowadzenie przełączenia awaryjnego.

Awaryjne przełączanie awaryjne jest używane do szybkiego przełączania obciążeń ze źródłowej maszyny wirtualnej na replikę maszyny wirtualnej, jeśli źródłowa maszyna wirtualna przestanie działać. Brak transferu danych. Replikacja nie jest wykonywana w celu dodania nowego punktu przywracania podczas inicjowania awaryjnego przełączania awaryjnego, ponieważ dane na źródłowej maszynie wirtualnej mogą być niespójne w tym momencie (lub maszyna wirtualna może być całkowicie nieosiągalna).

Zastanówmy się, jak wykonać przełączanie awaryjne w ramach zadania Site Recovery. Aby utworzyć działanie przełączania awaryjnego, należy najpierw utworzyć zadanie przywracania lokalizacji. Ze strony głównej NAKIVO Backup & Replication klikamy „Create> Site recovery job”.

1. Działania.W lewym panelu pierwszego ekranu Kreatora Site Recovery można wyświetlić listę czynności, które można uwzględnić w przepływie pracy. Klikamy „Failover VMware VMs”. (W obecnym przykładzie używana jest platforma wirtualizacji VMware, podobnie można wybrać awaryjne maszyny wirtualne Hyper-V lub AWS EC2, jeśli używane jest jedno z tych wirtualnych środowisk.)

Zostanie wyświetlony ekran konfiguracji dla działania przełączania awaryjnego. Z lewego panelu wybieramy replikę maszyny wirtualnej z odpowiedniego zadania replikacji. Ta replika ma być używana do przełączania awaryjnego. Na tym etapie możemy wybrać wiele replik VM. W prawym panelu wybieramy punkt przywracania. Ostatni punkt odzyskiwania jest używany domyślnie. Naciskamy „Next” by kontynuować.

Wybieramy opcje akcji. W razie potrzeby możemy zaznaczyć pole wyboru „Wyłącz zasilanie maszyn wirtualnych” i klikamy przycisk „Zapisz”.

Możemy wykonywać akcje więcej niż raz podczas tworzenia przepływów pracy odzyskiwania lokalizacji. W ten sposób można dodać kolejne działanie przełączania awaryjnego w tym zadaniu funkcji Site Recovery w celu wykonania przełączenia awaryjnego innej maszyny wirtualnej (lub zestawu maszyn wirtualnych) po tych, które zdefiniowano w pierwszym działaniu awaryjnym. Klikamy ponownie „Failover VMware VMs”.

Wybieramy replikę maszyny wirtualnej do przełączania awaryjnego, tak jak w przypadku pierwszego działania awaryjnego. Klikamy „Następny”.

Podobnie jak w przypadku pierwszej akcji, wybieramy opcję przełączania awaryjnego i klikamy przycisk „Dalej”.

To zadanie Site Recovery zawiera teraz dwie akcje. Klikamy „Dalej”, aby kontynuować.

2. Zaznaczamy pole wyboru „Włącz mapowanie sieciowe”, jeśli mamy różne sieci VM w miejscu produkcji i lokalizacji odzyskiwania po awarii (DR). Klikamy „Dalej”, aby kontynuować.
3. Re-IP. Zaznaczamy pole wyboru „Włącz Re-IP”, jeśli różne adresy są używane w sieciach IP w naszej lokalizacji produkcyjnej i DR. Klikamy „Następny”.
4. Harmonogram testów. Konfigurujemy opcję planowania, jeśli chcemy automatycznie przeprowadzać okresowe testy zadań przywracania lokalizacji. Klikamy „Następny”.
5. Opcje. Ustawiamy opcje zadań. Wprowadzamy nazwę dla nowego zadania (w tym przykładzie – zadanie przywracania w miejscu pracy – przełączanie awaryjne). Definiujemy cel czasu przywracania do celów testowych. Klikamy przycisk „Zakończ”, aby sfinalizować konfigurację zadania Site Recovery.

Teraz możemy użyć zadania Site Recovery, jeśli wystąpi awaria i wykonać przełączenie awaryjne na repliki maszyny wirtualnej.

Kiedy maszyny wirtualne ulegają awarii, a obciążenia są migrowane do witryny DR, należy chronić maszyny wirtualne działające w witrynie DR. Dzieje się tak, ponieważ jeśli replika VM uruchomiona po przełączeniu awaryjnym zawiedzie, nie będzie można szybko przywrócić tych danych i obciążeń. Funkcja Site Recovery pozwala na ponowne zabezpieczenie środowiska wirtualnego natychmiast po przywróceniu systemu po awarii.

Aby ponownie zabezpieczyć maszyny wirtualne działające w witrynie DR, należy najpierw zreplikować te maszyny wirtualne w inne bezpieczne miejsce. W ten sposób, jeśli maszyna wirtualna uruchomiona w witrynie DR zawiedzie, możesz szybko przejść do nowej repliki VM. Funkcja Site Recovery umożliwia dodanie działania zadania ”Run job” w istniejącym zadaniu Site Recovery  za pomocą którego można dodać istniejące zadanie replikacji. W ten sposób można skonfigurować zadanie przywracania lokalizacji, tak że po zakończeniu przełączania maszyny wirtualnej replikacja maszyn wirtualnych uruchomionych po przełączeniu awaryjnym jest wykonywana automatycznie, zapewniając odpowiedni poziom ochrony.

Oto przykładowy sposób ponownego zabezpieczenia maszyn wirtualnych za pomocą zadania Site Recovery.

Na stronie głównej interfejsu WWW NAKIVO Backup & Replication klikamy opcję „Utwórz> Zadanie replikacji VMware vSphere”.

1. Wybieramy repliki VM, które są używane jako cele przełączania awaryjnego w witrynie DR, zaznaczając pola obok ich nazw. W bieżącym przykładzie wybraliśmy dwie VM, które zostały użyte do obsługi obciążenia po przełączeniu awaryjnym w zadaniu Site Recovery opisanym powyżej. Klikamy „Następny”.

2. Miejsce docelowe. Wybieramy kontener docelowy (host lub klaster), na którym ma zostać uruchomiona maszyna wirtualna, oraz magazyn danych, w którym można umieścić pliki maszyny wirtualnej. Na potrzeby tego przykładu używamy hosta ESXi 10.10.10.51 i datastore1 (który jest dołączony do tego hosta ESXi). Klikamy „Następny”.

3. Zaznaczamy pole wyboru „Włącz mapowanie sieciowe” – jeśli mamy różne sieci VM w witrynie źródłowej (witryna DR, w której działają maszyny wirtualne, które przeszły przez awarię) i nowa witryna docelowa. Klikamy „Następny”.
4. Re-IP. Zaznaczamy pole wyboru „Włącz Re-IP”, jeśli adresy używane w sieciach różnią się między witryną źródłową (naszą witryną DR) a nową lokalizacją docelową. Klikamy „Następny”.
5. Konfigurujemy harmonogram, jeśli chcemy okresowo uruchamiać zadanie replikacji. Klikamy „Następny”.
6. Definiujemy ustawienia przechowywania. Klikamy „Następny”.
7. Konfigurujemy opcje zadania replikacji, w tym wprowadzenie nazwy zadania. W tym przykładzie zadanie replikacji nosi nazwę „Vmware replication job Re-protection”. Klikamy przycisk „Zakończ”, aby sfinalizować tworzenie zadania replikacji.

Po utworzeniu nowego zadania replikacji można dodać działanie „Uruchom zadanie” do zadania Site Recovery. W ten sposób można automatycznie replikować maszyny wirtualne działające w witrynie DR. Ponieważ pierwotne produkcyjne maszyny wirtualne są teraz w trybie offline, nasze repliki w witrynie DR są teraz jedynymi funkcjonalnymi kopiami, więc jest to ważne dla niezawodnej ochrony danych.

Na stronie głównej interfejsu WWW klikamy prawym przyciskiem myszy nazwę ostatnio utworzonego zadania przywracania lokalizacji. Klikamy „Edytuj” w menu kontekstowym.

Możemy zobaczyć teraz dwie akcje przełączania awaryjnego dodane do zadania Site Recovery opisane wcześniej. Szukamy i klikamy opcję „Uruchom zadania” z listy działań znajdującej się w lewym panelu ekranu  „Działania”  Site Recovery.

Wybieramy odpowiednie zadanie replikacji z listy zadań (tej, którą właśnie utworzyliśmy). Wybieramy opcje akcji jak zwykle i klikamy „Zapisz”.

Dodajemy akcję „Czekaj” między operacją przełączania awaryjnego i zadaniem replikacji. To daje replice maszyny wirtualnej trochę czasu na uruchomienie i załadowanie systemu operacyjnego (nie można zreplikować wyłączonej maszyny wirtualnej). Z listy „Czynności” na lewym panelu klikamy „Czekaj”.

Wybieramy czas oczekiwania – do tych celów wystarcza 5 minut. Wybieramy opcje akcji i klikamy „Zapisz”.

Po dodaniu akcji jest ona dołączana na końcu listy akcji. Klikamy „Przenieś w górę” i przenosimy akcję „Czekaj” z czwartej pozycji na trzecią – musi to nastąpić przed replikacją.

Teraz działania są uporządkowane w odpowiedniej kolejności.

Na koniec zadanie Site Recovery jest gotowe do użycia w celu wykonania przełączania awaryjnego maszyny wirtualnej i automatycznego ponownego zabezpieczenia replik VM używanych do przełączania awaryjnego. Klikamy prawym przyciskiem myszy nazwę zadania Site Recovery na stronie głównej i klikamy polecenie „Uruchom zadanie” w menu kontekstowym.

Będąc ważną częścią odzyskiwania lokalizacji, przejście awaryjne maszyny wirtualnej do repliki to proces przełączania z uszkodzonej źródłowej maszyny wirtualnej na replikę maszyny wirtualnej, która jest dokładną kopią źródłowej maszyny wirtualnej w odpowiednim punkcie czasowym.

Zaawansowana funkcja Site Recovery dodana do NAKIVO Backup & Replication w wersji 8.0 zawiera czynność przełączania awaryjnego. Ta elastyczna funkcja umożliwia tworzenie niestandardowych zadań Site Recovery z różnymi kombinacjami działań w celu ochrony środowiska produkcyjnego. Można również skonfigurować te same zadania do automatycznego ponownego zabezpieczenia środowiska DR po awarii maszyn wirtualnych w miejscu produkcji.

Poprzedni artykuł z naszej serii o odzyskiwaniu lokalizacji wyjaśnił utworzenie logicznego procesu odzyskiwania danych po awarii i podał instrukcję konfiguracji zadania przywracania lokalizacji. Po utworzeniu planu przywracania odzyskiwania danych po awarii i skonfigurowaniu odpowiednich zadań przywracania lokalizacji nie możemy zapomnieć o ich przetestowaniu. Testowanie pomaga upewnić się, że jesteśmy gotowi do odzyskania po wystąpieniu awarii i że wszystkie wybrane komponenty można odzyskać pomyślnie w odpowiednim czasie. NAKIVO Backup & Replication zapewnia opcję testowania dla zadań Site Recovery, tj. można uruchomić dowolne zadanie Site Recovery w trybie testowym.

Testowanie zadania Site Recovery jest ważną częścią przygotowywania do odzyskiwania po awarii. Zwiększa prawdopodobieństwo szybkiego i pomyślnego powrotu w przypadku katastrofy.

Testy są potrzebne następujących powodów:

• Aby upewnić się, że wszystko można odzyskać pomyślnie. Załóżmy, że opracowaliśmy plan odzyskiwania danych po awarii, a następnie odpowiednio skonfigurowaliśmy zadanie przywracania lokalizacji, ale go nie przetestowaliśmy. Może to spowodować następujący scenariusz: gdy nastąpi awaria i nadejdzie czas na uruchomienie zadania odzyskiwania lokalizacji, zadanie się nie powiedzie i nie będzie można odzyskać niektórych maszyn wirtualnych. Wymagałoby to znacznie więcej czasu na przywrócenie funkcjonalności infrastruktury wirtualnej (np. konieczne może być przywrócenie kopii zapasowych i ręczne wdrożenie wprowadzonych zmian). Kiedy testujemy swój plan Site Recovery i odkryjemy, że coś idzie nie tak, możemy rozwiązać problemy, zanim spowodują one poważne problemy w prawdziwym scenariuszu kryzysu.

Aby upewnić się, że wartości RTO mogą zostać spełnione. Zadanie Site Recovery może zakończyć się pomyślnie, ale w czasie przekraczającym wartość docelową RTO (czas odzyskiwania). Może to mieć negatywny wpływ na procesy biznesowe. Testowanie zadania Site Recovery pozwala sprawdzić, czy obciążenia mogą zostać odzyskane w odpowiednich RTO. Test odzyskiwania lokalizacji można uruchomić ręcznie na żądanie lub automatycznie, zgodnie z harmonogramem, co sprawia, że ​​proces jest bezbolesny i oszczędza czas.

Działanie przełączania awaryjnego ma kluczowe znaczenie dla większości przepływów pracy odzyskiwania lokalizacji. Mechanizm wykonywania pracy awaryjnej różni się w zależności od tego, czy zadanie Site Recovery jest uruchamiane w trybie testowym czy produkcyjnym. Podział kroków dla każdego trybu pokazano w poniższej tabeli.

Jak widać, drugi i trzeci punkt różnią się między produkcyjnymi i testowymi przepływami pracy. Wynika to z faktu, że można uruchomić replikację ze źródłowej maszyny wirtualnej w trybie testowym podczas pracy maszyny źródłowej. W większości przypadków, gdy nastąpi awaria, źródłowa maszyna wirtualna przestaje działać, a zatem nie można wykonać replikacji. Sieci połączeń VM można zdefiniować osobno w opcjach mapowania sieciowego dla trybu produkcji i trybu testowego podczas konfigurowania zadania przywracania lokalizacji (patrz poprzedni artykuł na blogu).

Testowanie pracy awaryjnej odbywa się po wykonaniu zadania Site Recovery w trybie testowym. Replika maszyny wirtualnej jest wyłączana i przywracana do stanu sprzed przejścia awaryjnego za pośrednictwem migawki (migawka repliki maszyny wirtualnej jest wykonywana przed wykonaniem czynności przełączania awaryjnego). Replika jest następnie przełączana ze stanu przełączania awaryjnego do stanu normalnego, a replikacja z obiektu źródłowego do repliki jest ponownie włączana.

W celu przeprowadzenia skutecznego testowania zadania Site Recovery należy emulować różne punkty awarii i regularnie sprawdzać plan odzyskiwania danych po awarii.

Emulacja różnych punktów awarii do testowania

Należy symulować sytuacje, w których zawodzą różne komponenty naszego środowiska. Można emulować na przykład awarię sieci, awarię różnych maszyn wirtualnych, awarię wszystkich hostów ESXi, awarię serwera vCenter lub awarię jednego lub więcej urządzeń pamięci masowej. Sprawdzamy, czy nasz plan przywracania po awarii jest możliwy do zrealizowania dla różnych sytuacji, które mogą powstać w racjonalny sposób. Jeśli nie, tworzymy kolejny plan przywracania po awarii, aby pasował do konkretnego scenariusza, który nie jest uwzględniany. W ten sposób możemy mieć plany przywracania po awarii dostosowane do określonych sytuacji.

Regularne testowanie planu odzyskiwania lokalizacji

Infrastruktura może się zmieniać w czasie – niektóre maszyny wirtualne można dodać, niektóre role można migrować z jednej maszyny wirtualnej na drugą, a konfiguracja sieci może zostać zmieniona. Powinnismy regularnie testować plan przywracania lokalizacji, aby sprawdzić, czy działa w twoim obecnym stanie i czy spełnia określone przez nas wartości RTO. Jeśli coś pójdzie nie tak należy go odpowiednio zmodyfikować.

Jak przetestować zadanie Site Recovery w NAKIVO Backup&Replication

Po zapoznaniu się z teorią testowania odzyskiwania lokalizacji można przystąpić do testowania zadania Site Recovery w oprogramowaniu NAKIVO Backup & Replication. Pokrótce omówimy kluczowe punkty funkcjonalności testowania wbudowanej w produkt.

Sprawdzanie działań zawartych w testowaniu

Przejrzyjmy logikę naszych działań dodanych do zadania przywracania witryny. Sprawdzamy, czy działania są uporządkowane w odpowiedniej kolejności i upewniamy się, że nie mogą utworzyć nieskończonej pętli. Możemy edytować opcje zadania przywracania lokalizacji, gdy zadanie nie jest uruchomione: zmieniać kolejność działań, dodawać akcje, usuwać działania lub edytować opcje akcji, jeśli to konieczne.

Sprawdzanie sieci

Sprawdzamy, czy nasza sieć działa poprawnie. Połączenie VPN może być używane między witryną produkcyjną, a witryną odzyskiwania po awarii (DR), ale tego połączenia nie można okresowo rozłączać w stanie normalnym. Sieć na stronie DR musi również działać bez zakłóceń. Sprawdzamy ustawienia Network Mapping i Re-IP, które zostały użyte do skonfigurowania przełączania awaryjnego i powrotu po awarii. Jeśli maszyna wirtualna jest skonfigurowana dla niepoprawnej sieci, połączenie sieciowe może nie zostać ustanowione. To samo dotyczy ustawień IP.

Ustawianie harmonogramu testów

Testowanie zadania Site Recovery można zaplanować w opcjach planowania zadania Site Recovery. Otwieramy interfejs WWW instancji NAKIVO Backup & Replication. W lewym panelu strony głównej klikamy prawym przyciskiem myszy nazwę swojego zadania i klikamy „Edytuj” w menu kontekstowym. W tym menu możemy także zmienić nazwę, wyłączyć, usunąć lub uruchomić zadanie.

Klikamy „Testuj harmonogram” i określamy ustawienia harmonogramu. W przykładzie wykorzystanym dotego artykułu, test pracy Site Recovery będzie uruchamiany w każdy dzień roboczy o 2:00.

Zadanie Site Recovery można uruchomić w trybie testowym ręcznie. Wystarczy przejść do strony głównej produktu, wybrać zadanie odzyskiwania lokalizacji według nazwy, kliknąć „Uruchom zadanie”, a następnie kliknąć „Przetestuj zadanie Site Recovery”.

Ustawiamy RTO i klikamy „Testuj”.

Test zadania Site Recovery jest już uruchomiony. Możemy zobaczyć całkowity pasek postępu i pasek postępu dla każdej działającej akcji. Czekamy na zakończenie testu.

Po zakończeniu testu możemy sprawdzić wyniki. Klikamy nazwę testowanego zadania, dla którego chcemy sprawdzić wyniki. W tym przypadku nasze zadanie przywracania lokalizacji zostało pomyślnie zakończone. Możemy zobaczyć szczegóły w sekcji „Wydarzenia”.

Na poniższym zrzucie ekranu widać również, że inny test zadania Site Recovery nie powiódł się. Czerwona ikona wykrzyknika wskazuje na niepowodzenie. Możemy zapoznać się z sekcją „Zdarzenia”, aby uzyskać szczegółowe informacje o źródle awarii. W tym przypadku czerwony kolor wskazuje, że nie można wysłać e-maila. Sprawdzamy zatem ustawienia sieci, konfigurację działania „Wyślij wiadomość e-mail” i sprawdzamy, czy adres grupy e-mail jest poprawny. Naprawiamy problemy po ich zidentyfikowaniu, a następnie próbujemy ponownie uruchomić test.

Testowanie zadania Site Recovery jest ważnym procesem, który pomaga zapewnić, że plan odzyskiwania lokalizacji działa. Testowanie pozwala również określić, czy maszyny wirtualne można odzyskać wystarczająco szybko, aby spełnić wartości RTO. Zaleca się regularne testowanie odzyskiwania danych po awarii aby upewnić się, że nie wystąpią żadne niespodzianki, gdy nastąpi katastrofa i że nasze środowisko wirtualne może zostać odzyskane zgodnie z planem.

W poprzednich artykułach z tej serii wprowadziliśmy nową funkcję Site Recovery w NAKIVO Backup & Replication v8. Omówione zostało znaczenie planu odzyskiwania danych po awarii, a także przedstawiona została procedura tworzenia zadania replikacji.

Ten artykuł wyjaśnia przepływ prac związanych z odzyskiwaniem danych po awarii. Omówione zostaną różne działania, które można uwzględnić w przepływach pracy związanych z odzyskiwaniem danych po awarii, a także potencjalne sekwencje, w których można je wykorzystać w celu spełnienia wymagań określonych w planie odzyskiwania po awarii.

Przepływ pracy odzyskiwania danych po awarii, to sekwencja czynności wykonywanych w celu zakończenia procesu odzyskiwania po awarii (DR). Zadania odzyskiwania lokalizacji w oprogramowaniu NAKIVO Backup&Replication umożliwiają automatyzację wykonywania obiegu pracy tego zadania. Testowanie zadania przywracania lokalizacji obejmuje wykonanie przepływu pracy w niezakłócającym “trybie testowym” w celu sprawdzenia, czy działa on płynnie i czy cele RTO są spełnione. Zadanie odzyskiwania lokazliacji może być uruchomione w trybie produkcyjnym, gdy jest potrzebny odzysk po awarii.

Akcja zadania odzyskiwania serwisu jest pojedynczym zadaniem zawartym w zadaniu odzyskiwania lokalizacji. W jednym zadaniu można uwzględnić dowolną liczbę działań. Niektóre czynności mogą być wykonywane wiele razy w zależności od logiki użytej do połączenia tych kroków. Każda akcja dodawana do zadania odzyskiwania lokalizacji w NAKIVO Backup&Recovery może być wykonywana tylko w trybie testowym, tylko w trybie produkcyjnym lub w obu trybach (jest to domyślnie używane).

Niektóre działania mogą zależeć od wyniku wykonania innych działań. Oczywiście nie można uruchomić skryptu na maszynie wirtualnej, która jeszcze nie została uruchomiona. Z tego powodu należy określić, w jakiej kolejności będą wykonywane akcje. Podczas tworzenia zadania Site Recovery można dodawać akcje, a następnie przenosić je w górę lub w dół w ramach przepływu pracy, aby zmienić kolejność wykonywania. Można również ustawić zachowanie oczekujące dla większości działań: albo „Czekaj na wykonanie tej akcji”, albo „Natychmiast rozpocznij następną akcję”. Jeśli wybierzemy tę drugą opcję, wiele akcji może być wykonywanych jednocześnie. Na przykład, jeśli nie ma zależności między odpowiednimi maszynami wirtualnymi, można uruchomić jedną akcję przełączania awaryjnego natychmiast po uruchomieniu innej, aby wykonać ją równolegle.

Nowa funkcja Site Recovery pozwala tworzyć złożone zadania odzyskiwania lokalizacji, łącząc akcje i warunki. W przepływie pracy odzyskiwania lokalizaji można uwzględnić dowolne z następujących działań:

• Przełączanie awaryjne – inicjuje przełączanie awaryjne do replik VMware VM, Hyper-V VM lub EC2.
• Powrót awaryjny – zwraca obciążenia z repliki maszyny wirtualnej do źródłowej maszyny wirtualnej. Zmiany wprowadzone w replice maszyny wirtualnej od momentu przełączenia awaryjnego są zapisywane w źródłowej maszynie wirtualnej po wykonaniu operacji powrotu po awarii. Maszyny wirtualne są zsynchronizowane, a źródłowa maszyna wirtualna jest ponownie w rzeczywistym stanie produkcyjnym.
• Start – uruchamia maszyny wirtualne VMware, Hyper-V lub EC2.
• Zatrzymaj – zatrzymuje maszyny wirtualne VMware, maszyny wirtualne Hyper-V, uruchomione instancje EC2.
• Uruchom zadanie – uruchamia zadanie kopii zapasowej, zadanie replikacji, zadanie odzyskiwania lokalizacji, zadanie kopii zapasowej lub zadanie rozruchu Flash VM.
• Zatrzymaj zadania – zatrzymuje zadanie (każde z zadań wymienionych w poprzednim punkcie).
• Uruchom skrypt – uruchamia skrypt na jednym z następujących celów: serwerze z programem Director, zdalnym serwerem systemu Windows, zdalnym serwerem Linux, maszynie VMware VM, maszynie wirtualnej Hyper-V lub instancji EC2.
• Dołącz repozytorium – dołącza repozytorium kopii zapasowych używane przez NAKIVO Backup & Replication do przechowywania kopii zapasowych.
• Odłącz repozytorium – odłącza repozytorium kopii zapasowych.
• Wyślij wiadomość e-mail – wysyła wiadomość e-mail z wiadomością, którą komponujesz do jednego lub więcej zdefiniowanych adresatów.
• Zaczekaj – czeka na wyznaczony okres czasu przed przejściem do następnej akcji.
• Sprawdź warunek – na podstawie danych wejściowych (całość lub część nazwy zasobu) sprawdza jeden z następujących warunków:
  – Zasób istnieje
  – Zasób działa
  –  Adres IP / nazwa hosta jest osiągalny

Można tworzyć elastyczne przepływy pracy odzyskiwania danych po awarii przy użyciu różnych kombinacji tych działań. Zastanówmy się, jak zbudować zadanie odzyskiwania lokalizacji na przykładzie.

Załóżmy, że mamy witrynę główną (produkcyjną) i witrynę DR. Mamy kilka maszyn wirtualnych VMware w miejscu produkcji, w tym:

• DC-VM jest maszyną wirtualną opartą na systemie Windows z kontrolerem domeny Active Directory.
• FS-VM jest maszyną wirtualną opartą na systemie Windows z uruchomionym serwerem plików (protokół SMB służy do udostępniania plików). Usługa Active Directory służy do uwierzytelniania użytkownika. Zrzuty bazy danych Oracle są przechowywane na serwerze plików.
• Ora-DB jest maszyną wirtualną, na której działa baza danych Oracle.

Witryna odzyskiwania po awarii zawiera następujące maszyny wirtualne:

• Repliki DC-VM i repliki FS-VM są replikami maszyn wirtualnych znajdujących się w miejscu produkcji. Mogą być używane jako cele do przełączania awaryjnego.
• DB-VM jest maszyną wirtualną opartą na systemie Linux z zainstalowanym oprogramowaniem Oracle Database, ale nie ma baz danych na tej maszynie wirtualnej.

Baza danych jest zapisywana na poziomie bazy danych do FS-VM w miejscu produkcji (ta kopia zapasowa bazy danych Oracle jest zgodna z aplikacją). FS-VM i DC-VM są replikowane na poziomie hosta do witryny DR za pomocą NAKIVO Backup & Replication.

Po wystąpieniu awarii i opuszczeniu zakładu produkcyjnego komponenty muszą zostać odzyskane w witrynie DR w następujący sposób:

Po pierwsze, przełączanie awryjne DC-VM.

Po uruchomieniu DC-VM, przełączanie awaryjne FS-VM. Trzeba było działać w tej kolejności, ponieważ FS-VM opiera się na DC-VM w celu uwierzytelnienia użytkownika na serwerze plików.

Gdy te dwie maszyny wirtualne są uruchomione, DB-VM może uzyskać dostęp do katalogu współdzielonego na serwerze plików, na którym przechowywany jest zrzut. Teraz można uruchomić DB-VM.

Po uruchomieniu DB-VM uruchamiamy skrypt, który może przywrócić bazę danych z bloku znajdującego się na serwerze plików. Niebieskie strzałki na rysunkach powyżej wskazują zależności. Pamiętaj, że być może będziesz musiał poczekać kilka chwil, zanim usługi zostaną uruchomione na maszynie wirtualnej.

W takiej sytuacji w NAKIVO Backup & Replication tworzone są miejsca pracy związane z odzyskiwaniem danych z zachowaniem następującej logiki:

Działanie 1. Przełączanie awaryjne DC-VM. Przed przejściem do następnego kroku należy poczekać, aż czynność ta zostanie zakończona. Jeśli ta czynność zakończy się niepowodzeniem, zadanie należy zatrzymać.

Działanie 2. Odczekujemy 3 minuty.

Działanie 3. Sprawdzamy stan DC-VM. Sprawdzamy, czy zasób działa. Jeśli tak, kontynuujemy to zadanie. Jeśli nie, zatrzymujemy i nie wykonujemy zadnia przywracania lokalizacji.

Działanie 4. Awaria FS-VM. Przed przejściem do następnej czynności czekamy, aż czynność ta zostanie zakończona. Jeśli zakończy się niepowodzeniem, zadanie należy zatrzymać.

Działanie 5. Odczekujemy3 minuty.

Działanie 6. Sprawdzamy stan FS-VM. Sprawdzamy, czy zasób działa. Jeśli tak, przechodzimy do następnego etapu zadania odzyskiwania danych. Jeśli nie, zatrzymujemy i nie wykonujemy zadania przywracania lokalizacji.

Działanie 7. Uruchamiamy DB-VM. Przed przejściem do następnej czynności czekamy, aż ta czynność zostanie zakończona. Jeśli zakończy się niepowodzeniem, zadanie należy zatrzymać.

Działanie 8. Odczekujemy 5 minut.

Działanie 9. Uruchamiamy skrypt. Rodzaj zadania: VMware VM. VM docelowa: DB-VM. Ścieżka skryptu: /home/oracle/restore_db. sh (podczas dodawania tego kroku należy podać nazwę użytkownika i hasło konta z uprawnieniami wystarczającymi do uruchomienia skryptu).

Zakładamy nowe zadanie odzyskiwania lokalizacji korzystając z planu opisanego powyżej. Na stronie głównej NAKIVO Backup&Recovery klikamy Utwórz > zadanie Site Recovery.

Uruchomiony zostanie Kreator nowego zadania odzyskiwania lokalizacji. W lewym panelu widać działania, które można dodać do zadania odzyskiwania lokalizacji. Wystarczy na nie kliknąć, aby skomponować przepływ pracy.

Uwaga: Maszyny wirtualne VMware są brane pod uwagę w tym przykładzie. Jedno zadanie Site Recovery może obejmować działania dla jednej platformy wirtualizacji (VMware, Hyper-V lub AWS EC2).

Działanie 1.

W lewym panelu kliknij Failover VMware VM.

W lewym panelu wybierz replikę maszyny wirtualnej z już utworzonego zadania replikacji (przeczytaj nasz poprzedni artykuł, aby zapoznać się z informacjami na temat tworzenia zadań replikacji w ramach przygotowań do odzyskania lokalizacji). W naszym procesie pracy pierwszym działaniem jest przełączanie awaryjne na replikę DC-VM. W prawym panelu można wybrać punkt odzyskiwania. Domyślnie używany jest najnowszy punkt odzyskiwania. Kliknamy „Next” (Dalej), aby kontynuować.

Wybieramy opcję przełączania awaryjnego. Możemy też zaznaczyć pole wyboru „Wyłącz zasilanie źródłowych maszyn wirtualnych”; opcja ta może być używana do zapobiegania konfliktom adresów IP, jeśli źródłowe maszyny wirtualne i repliki korzystają z tych samych sieci. W tym przejściu, zgodnie z przedstawioną powyżej logiką przepływu, wybierane są następujące opcje:

• Wykonaj tę czynność: Czynność tę należy wykonać zarówno w trybie testowym, jak i produkcyjnym.
• Zachowanie w oczekiwaniu: Poczekaj, aż akcja zostanie zakończona.
• Usuwanie usterek: Jeśli ta czynność zakończy się niepowodzeniem, zadanie należy zatrzymać i zawiesić.

Klikamy przycisk „Zapisz”, aby zapisać utworzoną akcję.

Działanie 2. W lewym panelu interfejsu „Akcje” klikamy „Czekaj”.

Teraz skonfigurujemy opcję działania „Zaczekaj”. Wybieramy czas oczekiwania (3 minuty są używane do celów tego przeglądu). Może minąć trochę czasu, zanim usługi zostaną uruchomione w replice VM, która została włączona po działaniu awaryjnym. Działanie „Zaczeka” jest w tym przypadku przydatne, ponieważ następujące działanie przełączania awaryjnego w przepływie pracy (przełączenie awaryjne na replikę FS-VM) wymagałoby uruchomienia repliki DC-VM i już działającej z usługami domenowymi Active Directory. Wybieramy opcję akcji, która jest dla pierwszej akcji, i klikamy „Zapisz”.

Nowa akcja zostanie dodana po poprzedniej akcji, na dole listy. Można zmienić kolejność, edytować lub usunąć istniejące działania. Wystarczy najechać myszką na akcję, aby wyświetlić te opcje.

Działanie 3. W lewym panelu interfejsu akcji klikamy przycisk „Sprawdź stan”. W tym miejscu produkt powinien sprawdzić, czy maszyna wirtualna, która uległa awarii w pierwszej akcji, jest uruchomiona.

Skonfigurujemy tę czynność w następujący sposób:

• Wybieramy typ stanu: Zasoby są uruchomione. (Inne opcje to zasoby, adres IP/nazwa hosta jest osiągalna. )
• Wybieramy typ zasobu: VMware VM. (Inne opcje to Hyper-V VM, instancja EC2).
• Wybieramy metodę identyfikacji: Nazwa (drugą opcją jest ID). W ten sposób identyfikujemy daną maszynę wirtualną. Możemy użyć dowolnej części łańcucha maszyny wirtualnej. Tutaj znamy dokładną nazwę, więc użyliśmy funkcji „Equals”.
• Definiujemy łańcuch wyszukiwania: DC-VM-replica.

Ta czynność sprawdza, czy VMware VM o nazwie DC-VM-replica jest uruchomiona. Klikamy przycisk „Zapisz”, aby kontynuować.

Działanie 4. Podobnie jak w przypadku Działania 1, klikamy opcję „Failover VMware VM”.

Ponownie wybieramy replikę maszyny wirtualnej. W tym przypadku wybrana została replika FS-VM. Klikamy przycisk „Dalej”, a następnie wybieramy te same opcje działania przełączania awaryjnego, jakie mamy w Działaniu 1, i klikamy przycisk „Zapisz”.

Działanie 5. Klikamy „Czekaj” i konfigurujemy tę akcję tak samo, jak w przypadku Działania 2. Określony czas ponownie wynosi 3 minuty na potrzeby tego artykułu.

Działanie 6. Klikamy „Sprawdź stan”, aby sprawdzić, czy działa replika VMware VM FS-VM. Przypominamy sobie Działanie 2 i wybieramy te same opcje – z wyjątkiem oczywiście nazwy maszyny wirtualnej.

Działanie 7. Klikamy przycisk „Uruchom maszyny wirtualne Vmware” w lewym panelu interfejsu „Czynności” kreatora nowego zadania Site Recovery.

Wybieramy DB-VM. Ta maszyna wirtualna może zostać uruchomiona, gdy mamy pewność, że działa replika FS-VM. W dolnej części strony wybieramy te same opcje akcji, które pokazane zostały w poprzednich akcjach. Następnie klikamy „Zapisz”.

Działanie 8. Odczekujemy 5 minut. Klikamy przycisk „Zaczekaj” i konfigurujemy tę czynność podobnie jak w przypadku Działania 2 (czas oczekiwania zmieniamy na 5 minut). Powinien to być wystarczający czas na uruchomienie usługi Oracle na DB-VM.

Działanie 9. W interfejsie „Akcje” klikamy „Uruchom skrypt”. Przypomnę, że z opisanego powyżej przepływu pracy wynika że skrypt ten ma na celu odzyskanie bazy danych Oracle na poziomie bazy danych ze zrzutu przechowywanego na replice FS-VM.

Definiujemy opcje skryptu. W tym przypadku:

• Rodzaj zadania: VMware , ‘VM
• VM docelowa: DB-VM
• Ścieżka skryptu: /home/oracle/restore. db. sh.
• Nazwa użytkownika: oracle
• Hasło: (hasło)

Ścieżka skryptu, nazwa użytkownika i hasło mogą się różnić. Nie zapomnijmy upewnić się, że plik skryptu jest wykonywalny i że użytkownik ma wystarczające uprawnienia do uruchomienia skryptu. W tym przykładzie opcje akcji są skonfigurowane tak, jak zwykle. Klikamy przycisk „Zapisz”, gdy będziemy gotowi do kontynuowania.

Teraz możemy zobaczyć konfigurację wszystkich akcji. Klikamy przycisk „Next” (Dalej), aby kontynuować konfigurację zadania Site Recovery za pomocą kreatora.

Jeśli maszyny wirtualne w miejscu produkcji i w miejscu DR są podłączone do różnych sieci, zaznaczamy pole wyboru „Włącz mapowanie sieci”. Klikamy przycisk „Utwórz nowe mapowanie”, w wyskakujących oknach wybieramy sieć źródłową, docelową i sieć używaną do testowania zadań przywracania lokalizacji. Klikamy przycisk „Zapisz”, aby zapisać regułę mapowania sieci, a następnie klikamy przycisk „Dalej”. (Alternatywnie można użyć istniejących reguł mapowania, jeśli zostały one skonfigurowane w innych zadaniach replikacji, przełączania awaryjnego lub przywracania lokalizacji).

Jeśli sieci używane do połączenia z maszyną wirtualną w witrynie źródłowej i docelowej mają różne adresy, należy włączyć funkcję Re-IP, zaznaczając pole wyboru „Włącz Re-IP”. Teraz, gdy funkcja Re-IP jest włączona, tworzymy nową regułę Re-IP, klikając przycisk „Utwórz nową regułę”. Definiujemy ustawienia źródła i celu, a następnie klikamy przycisk „Zapisz”.

Klikamy „Wybierz maszyny wirtualne” i zaznaczamy pola obok maszyn wirtualnych, w których należy użyć Re-IP. Należy podać poświadczenia dla użytkownika z wystarczającymi uprawnieniami do zmiany ustawień sieci w systemie operacyjnym gościa maszyny wirtualnej.

Harmonogram jest włączany tylko w celu wykonywania zadań odzyskiwania lokalizacji w trybie testowym. Umożliwia to sprawdzenie, czy zadanie odzyskiwania lokalizacji może zostać pomyślnie uruchomione w odpowiednich ramach czasowych. Po skonfigurowaniu planowania według potrzeb klikamy przycisk „Dalej”. Szczegółowy przewodnik po testowaniu zadań związanych z odzyskiwaniem lokalizacji zawiera się w kolejnym artykule z tej serii.

Wpisujemy nazwę zadania i cel czasu przywracania (RTO). Klikamy „Zakończ”, gdy konfiguracja została zakończona.

Teraz już wiemy, jak tworzyć i konfigurować zadania odzyskiwania lokalizacji w oparciu o logiczny przepływ pracy za pomocą narzędzia NAKIVO Backup & Replication. Przeczytaj kolejne posty na blogu, aby dowiedzieć się więcej na temat testowania zadań Site Recovery, a także działań związanych z przełączaniem awaryjnym i powrotem po awarii używanych do odzyskiwania lokalizacji.

NAKIVO Backup & Replication v8.1 Beta jest już dostępne do testowania! Z przyjemnością prezentujemy nowe, zaawansowane funkcje, które z pewnością spowodują przeniesienie zarządzania ochroną danych na zupełnie nowy poziom.

Dzięki nowej wersji można zautomatyzować operacje tworzenia kopii zapasowych za pomocą opartej na regułach ochrony danych, uzyskać większą uniwersalność odzyskiwania dzięki funkcji Universal Object Recovery i zainstalować niestandardowy certyfikat SSL w celu zwiększenia bezpieczeństwa.

Przy coraz większej ilości danych, zwirtualizowana infrastruktura staje się większa i bardziej złożona. W związku z tym zarządzanie tymi środowiskami jest coraz trudniejsze i czasochłonne, ponieważ trzeba monitorować każdą zmianę, każdą nową maszynę wirtualną i każdą wykonywaną kopię zapasową.

NAKIVO Backup & Replication v8.1 Beta wprowadza moduł ochrony danych oparty na regułach, który pozwala zautomatyzować i uprościć zarządzanie kopiami zapasowymi maszyny wirtualnej, dzięki czemu ręczne wprowadzanie danych jest niewielkie lub wręcz niemożliwe.

Możemy teraz włączyć zasady oparte na regułach do backupu, kopii backupu lub zadania replikacji i automatycznie dopasować wszystkie odpowiednie maszyny wirtualne lub instancje zawarte w zadaniu. Po utworzeniu zadania program NAKIVO Backup & Replication regularnie skanuje infrastrukturę. Jeśli zostaną znalezione nowe pasujące elementy, proaktywnie je chroni bez konieczności ręcznego dodawania ich do odpowiedniego zadania. Zasady polityk można skonfigurować w zależności od potrzeb; dołączać lub wykluczać maszyny wirtualne na podstawie ich nazwy, rozmiaru, tagu, lokalizacji, stanu zasilania lub dowolnej kombinacji tych parametrów.

Jeśli chodzi o utratę danych, poszczególne pliki i obiekty gubią się lub uszkadzają znacznie częściej niż całe maszyny wirtualne. Zwykle, jeśli chcemy odzyskać określony przedmiot, musimy najpierw odzyskać całą maszynę wirtualną. NAKIVO Backup & Replication v8.1 oferuje rozwiązanie tego problemu poprzez wprowadzenie funkcji Universal Object Recovery.

Dzięki tej funkcji można montować dyski VM z kopii zapasowej do źródłowej maszyny wirtualnej/instancji, innej maszyny wirtualnej/instancji, a nawet serwera fizycznego, a następnie odzyskać obiekt lub plik przy użyciu rodzimych narzędzi aplikacji. Odzyskiwanie można wykonać dla dowolnej aplikacji lub systemu plików i dla szerokiej gamy systemów operacyjnych. Funkcja Universal Object Recovery zwiększa wszechstronność procesu odzyskiwania i pozwala zaoszczędzić znaczną ilość czasu i zasobów, które w innym przypadku zostałyby przeznaczone na odtwarzanie w pełnej skali.

Firma NAKIVO Backup & Replication korzysta z samopodpisanego certyfikatu NAKIVO. Jednak w celu jeszcze większej wydajności i zwiększenia bezpieczeństwa można zainstalować własny certyfikat SSL, korzystając z odpowiedniej opcji w interfejsie konfiguracji. Dzięki temu możemy korzystać z połączeń “https” podczas uzyskiwania dostępu do interfejsu internetowego produktu. Ta niewielka, ale poręczna funkcja wprowadzona w nowej wersji została zaprojektowana w celu zwiększenia bezpieczeństwa i ogólnej użyteczności rozwiązania.

NAKIVO Backup & Replication v8.1 zawiera również niewielkie ulepszenia interfejsu użytkownika. Karty Ogólne, Zapasy, Transportery i Repozytoria zostały ulepszone, aby uzyskać lepszy, bardziej przyjazny dla użytkownika wygląd.

Pobierz NAKIVO Backup & Replication v8.1 Beta, aby wypróbować najnowszą wersję naszego wielokrotnie nagradzanego rozwiązania do ochrony danych i odzyskiwania po awarii w Twoim własnym środowisku.