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.

W poprzednim artykule z serii o odzyskiwaniu po awarii pisaliśmy, jak zaplanować odzyskiwanie w swoim środowisku. W tym artykule wyjaśnimy, jak przygotować się do odzyskiwania po awarii, koncentrując się na replikacji maszyn wirtualnych. Po omówieniu roli replikacji maszyn wirtualnych następuje kompletna konfiguracja zadań replikacji za pomocą narzędzia NAKIVO Backup & Replication.

Replikacja maszyn wirtualnych to proces tworzenia identycznej kopii źródłowej maszyny wirtualnej (zwanej “repliką VM”) na innym hoście (host docelowy). Replika VM jest zwykłą maszyną wirtualną, która pozostaje w stanie wyłączonym, dopóki nie jest potrzebna (w tym momencie może być prawie natychmiast uruchomiona na hoście). Replika maszyny wirtualnej nie zużywa zasobów w stanie wyłączonym, podobnie jak w przypadku kopii zapasowej. W przeciwieństwie do kopii zapasowej replika nie jest jednak kompresowana. Replika może być odtworzona w znacznie krótszym czasie. Oprogramowanie NAKIVO Backup & Replication tworzy repliki VM z wieloma punktami odzyskiwania, które reprezentują zwykłe migawki maszyny wirtualnej utworzone podczas wykonywania zadań z powtarzalną replikacją.

Jednym z kluczowych działań związanych z odzyskiwaniem po awarii przy użyciu NAKIVO Backup & Replication jest przełączanie awaryjne VM. Przełączanie awaryjne to działanie polegające na przełączaniu z uszkodzonej maszyny produkcyjnej na zdrową replikę maszyny wirtualnej, która została wcześniej utworzona za pomocą zadania replikacji. Korzystając z przełącznika awaryjnego do repliki, można wykonać szybkie (niemal natychmiastowe) odzyskiwanie maszyny wirtualnej. Jeśli sieci używane przez maszyny wirtualne w witrynie docelowej różnią się od tych w witrynie źródłowej (co w większości przypadków jest prawdopodobne), funkcje mapowania sieciowego i Re-IP zadań NAKIVO Backup & Replication mogą pomóc w automatyzacji sieci VM podczas konfiguracji przełączania awaryjnego maszyny wirtualnej.

Aby zapewnić niezawodną replikację, której wynikiem są repliki VM, które można skutecznie odzyskać, w tym wszystkie aplikacje, należy znać szczegóły procesu. Zobaczmy, jak tworzyć repliki VM w najlepszy możliwy sposób.

Należy wykonać replikację maszyn wirtualnych na poziomie hosta, a nie gościa. Starsze rozwiązania do tworzenia kopii zapasowych i replikacji używają agentów zainstalowanych w gościnnym systemie operacyjnym każdej maszyny wirtualnej. Agenci zużywają zasoby komputerowe, co znacząco wpływa na wydajność. Ponadto muszą być instalowane na każdej maszynie wirtualnej indywidualnie, co jest niewygodne i czasochłonne dla administratora (ów).

System-gość działający na maszynie wirtualnej nie współdziała bezpośrednio z urządzeniami fizycznymi. Warstwa wirtualizacji jest warstwą pośrednią między fizycznym sprzętem, a systemem-gościem. Replikacja powinna być wykonywana na poziomie warstwy wirtualizacji; proces ten nazywa się replikacją na poziomie hosta. Replikacja maszyn wirtualnych na poziomie hosta jest znacznie wydajniejsza. System operacyjny gościa nie jest świadomy procesu replikacji; dane maszyny wirtualnej, w tym dyski wirtualne i inne pliki VM, są replikowane bezpośrednio z magazynu danych podłączonego do hosta.

Aplikacje takie jak serwery baz danych i serwery poczty elektronicznej intensywnie współpracują z pamięcią RAM (Random Access Memory). Jeśli migawka maszyny wirtualnej potrzebna do replikacji została podjęta podczas działania tych aplikacji bez żadnych dodatkowych działań, wówczas efekt byłby podobny do nieoczekiwanej utraty mocy i wyłączenia. Niektóre dane mogą zostać utracone lub uszkodzone. Jest tak, ponieważ niektóre oczekujące transakcje były przechowywane w pamięci RAM w momencie migawki i nie zostały zapisane na dysku. Te transakcje zostaną utracone. Odzyskiwanie bazy danych może być skomplikowanym i czasochłonnym procesem.

Trzeba skorzystać z replikacji obsługującej aplikację, aby uniknąć tego problemu. Podczas korzystania z metod obsługujących aplikacje, aplikacje są zamrożone (wyciszone), a pamięć zostaje przepłukana. Dane nie mogą zostać zapisane na dysku przed zrobieniem migawki. Po wykonaniu migawki spójnej z aplikacją można utworzyć replikę maszyny wirtualnej. Taka replika VM może zostać pomyślnie przywrócona, a aplikacje w niej będą działać prawidłowo.

Ustawienia przechowywania i replikacji NAKIVO umożliwiają przechowywanie wielu punktów przywracania przez określony czas. Załóżmy na przykład, że mamy skonfigurowane zadanie replikacji maszyny wirtualnej, które ma być uruchamiane raz dziennie, a 10 punktów odzyskiwania jest przechowywanych. Gdy zadanie replikacji zostanie uruchomione jedenastym razem, najstarszy punkt odzyskiwania zostanie usunięty (ten sprzed 10 dni) i zostanie utworzony nowy punkt przywracania dla dzisiejszej replikacji.

Jeśli jednak chcemy odzyskać starszy stan maszyny wirtualnej, potrzebujemy starszego punktu przywracania, a uproszczona polityka przechowywania opisana powyżej byłaby niewystarczająca. Zasady przechowywania dokumentów Grandfather-Father-Son (GFS) są o wiele bardziej elastyczne i mogą pomóc w tym przypadku. Zasady przechowywania zasobów GFS pozwalają zachować kilka ostatnich punktów przywracania (np. 5 ostatnich codziennych zadań replikacji) oraz jeden punkt przywracania sprzed tygodnia, miesiąca i roku.

Najpierw musimy upewnić się, że VMware Tools lub Hyper-V Integration Services są zainstalowane na dowolnych maszynach wirtualnych, na których chcemy zakończyć awarię. Te pakiety narzędziowe są potrzebne do tworzenia migawek aplikacji obsługujących replikację maszyny wirtualnej. NAKIVO Backup & Replication obsługuje replikację na poziomie hosta obsługującą maszyny wirtualne VMware, maszyny wirtualne Hyper-V i instancje EC2 ze specjalną funkcjonalnością dla MS SQL Server, MS Exchange Server i kontrolera domeny Active Directory. Zastanówmy się, jak utworzyć i skonfigurować zadanie replikacji NAKIVO Backup&Replication, co jest warunkiem wstępnym wykonania przełączania awaryjnego podczas odzyskiwania po awarii.

Zaczynamy od otwarcia interfejsu sieciowego NAKIVO Backup & Replication w przeglądarce. Na ekranie głównym klikamy „Utwórz> Zadanie replikacji VMware vSphere”. Uwaga: Na potrzeby obecnego artykułu wykonywana jest replikacja maszyny wirtualnej VMware. Czynności te byłyby takie same dla zadania replikacji Amazon EC2 lub zadania replikacji Microsoft Hyper-V.

1. Wybieramy jedną lub więcej maszyn wirtualnych, które chcemy powielić. W takim przypadku DC-VM zostanie zreplikowane. Klikamy „Następny”.

2. Wybieramy kontener docelowy i magazyn danych. Host ESXi 10.10.10.56 i lokalny magazyn danych na tym hoście są wybrane w tym przykładzie. Klikamy „Dalej”, aby kontynuować.

3. W tym momencie możemy włączyć mapowanie sieciowe i zdefiniować reguły mapowania sieci dla zadania replikacji. Mapowanie sieci jest przydatne, jeśli sieci używane przez maszyny wirtualne w lokalizacji docelowej (DR) różnią się od sieci witryny źródłowej (co jest bardzo prawdopodobne). Możemy także skonfigurować mapowanie sieciowe później podczas konfigurowania działań awaryjnych lub powrotu po awarii dla zadania Site Recovery. Klikamy „Dalej”.

4. Podobnie jak w przypadku mapowania sieciowego, możemy skonfigurować Re-IP, jeśli adresy IP używane przez maszyny wirtualne w witrynie źródłowej i docelowej są różne. Klikamy „Dalej” by kontynuować.

5. Skonfigurujmy opcje planowania zadań replikacji. Można ustawić zadanie replikacji, które ma być uruchamiane natychmiast po zakończeniu innego zadania, okresowo (np. co 2 godziny lub co 5 dni), codziennie/co tydzień (np. o 14:00 w każdy dzień roboczy lub każdy niedzielny poranek) lub raz w miesiącu/raz w roku. Pulpit nawigacyjny kalendarza może pomóc nam zaplanować pracę dzięki przyjaznemu dla użytkownika graficznemu harmonogramowi. Po skonfigurowaniu harmonogramu według własnego uznania klikamy przycisk „Dalej”.

6. Podczas konfigurowania ustawień przechowywania dla zadania replikacji można postępować zgodnie z zasadami przechowywania GFS. Zaznaczamy odpowiednie pola i wprowadzamy prawidłowe wartości, a następnie klikamy przycisk „Dalej”, gdy wszystko będzie gotowe.

7. Zdefiniujmy opcje zadania replikacji. Na tym etapie można włączyć tryb oprogramowania aplikacji, funkcję ograniczania przepustowości specyficznej dla danego zadania, śledzenie zmienionych bloków maszyn wirtualnych VMware (w przypadku replikacji maszyn wirtualnych Hyper-V można skorzystać z analogowych rozwiązań firmy Microsoft, Resilient Change Tracking) i innych opcji. Po skonfigurowaniu wszystkich opcji klikamy przycisk „Zakończ” lub „Zakończ i Uruchom”.

Po pomyślnym uruchomieniu zadania replikacji mamy gotową replikę maszyny wirtualnej. Możemy teraz przygotować się do odzyskiwania witryny, konfigurując przełączanie awaryjne.

Przygotowanie do odzyskiwania po awarii to bardzo ważny proces. Posiadanie repliki VM jest warunkiem wstępnym automatycznego przełączania awaryjnego, który jest integralną częścią większości przepływów pracy odzyskiwania witryny. Replika VM służy do przełączania awaryjnego po wystąpieniu awarii; obciążenia są przełączane z uszkodzonej maszyny wirtualnej na jej replikę w miejscu DR.

W tym artykule wykorzystaliśmy narzędzie NAKIVO Backup & Replication do tworzenia i utrzymywania replik VM. Dzięki nowej funkcji Site Recovery (wprowadzonej w wersji 8) można tworzyć przepływy pracy w celu szybkiego i prostego odzyskiwania środowiska wirtualnego w przypadku awarii. Te przepływy pracy zazwyczaj obejmują zautomatyzowane przełączanie awaryjne jako kluczowy krok. Teraz, gdy mamy skonfigurowane zadania replikacji dla maszyn wirtualnych o znaczeniu krytycznym, możemy przystąpić do tworzenia zadania Site Recovery. W kolejnym artykule będzie można uzyskać informacje na temat przepływów pracy odzyskiwania witryny i zobaczyć, jak utworzyć zadanie Site Recovery za pomocą odpowiedniej sekwencji działań.

W ramach korzystania z infrastruktury wirtualnej odzyskiwanie po awarii jest procesem odzyskiwania maszyn wirtualnych i usług na nich uruchomionych w lokacji dodatkowej (zwanej witryną “DR” lub witryną odzyskiwania po awarii), gdy witryna produkcyjna jest niedostępna.

NAKIVO Backup & Replication v8.0 zawiera zaawansowaną funkcję Site Recovery, która umożliwia tworzenie zaawansowanych przepływów pracy odzyskiwania i usuwania awarii całej witryny za pomocą zaledwie kilku kliknięć. Przed utworzeniem przepływu pracy należy jednak ocenić konkretne potrzeby związane z odzyskiwaniem w firmie. Ten artykuł, jako pierwszy z serii, omawia wymagane czynności przy planowaniu odzyskiwania i najlepsze praktyki, zanim wnikniemy głębiej w wykorzystanie nowej funkcji Site Recovery NAKIVO.

Najważniejsze sprawdzone metody odzyskiwania po awarii obejmują przeprowadzanie analizy wpływu na biznes, ocenę ryzyka i tworzenie dokumentacji odzyskiwania po awarii.

Business Impact Analysis (lub BIA) obejmuje określenie potencjalnego negatywnego wpływu klęsk żywiołowych lub katastrof spowodowanych przez człowieka na działalność gospodarczą. Maszyny wirtualne wykorzystywane w procesach biznesowych mogą zależeć od siebie i mają różny stopień ważności. W związku z tym awaria jednej maszyny wirtualnej może spowodować pewne opóźnienia i niedogodności, natomiast awaria innej maszyny wirtualnej spowoduje całkowite przerwanie operacji o znaczeniu krytycznym.

Na przykład, jeśli maszyna wirtualna, w której działa moduł do śledzenia błędów, nie działa, firma może działać pomimo pewnych niedogodności dla swoich pracowników. Jeśli jednak maszyna wirtualna z produkcyjnym serwerem baz danych zawiedzie, firma nie mogłaby działać i poniosłaby straty finansowe. Przeprowadzenie BIA pomaga określić priorytet, z jakim maszyny wirtualne muszą być odzyskane i jak długo powinien trwać proces odzyskiwania.

Przed przystąpieniem do jakichkolwiek działań związanych z planowaniem odzyskiwania, należy zebrać odpowiednie dane i statystyki, aby określić, jakie ryzyko jest największe dla firmy. W niektórych regionach prawdopodobieństwo wystąpienia długoterminowej awarii zasilania lub ataku wirusa jest większe niż w przypadku tornada, ale w innych regionach sytuacja jest odwrotna. Dzięki wynikom oceny ryzyka można określić odpowiedni poziom ochrony przed określonymi zagrożeniami i wymyślić środki minimalizujące ryzyko lub łagodzące konsekwencje. Ryzyka nie można całkowicie wyeliminować, ale firma może być lepiej przygotowana na scenariusze katastrof, które są bardziej prawdopodobne.

Po zidentyfikowaniu zagrożeń i ich potencjalnego wpływu na działalność firmy można lepiej zrozumieć, na czym należy skoncentrować wysiłki w przypadku wystąpienia awarii. Ważne jest, aby dokumentować procedury odzyskiwania, szczegółowo opisując wszystkie niezbędne kroki i środki DR. Przypisywać role i obowiązki członkom zespołu w przypadku katastrofy. Plan odzyskiwania po awarii powinien również obejmować elementy sprzętu i oprogramowania potrzebne do pomyślnego odzyskania. Dokumentacja powinna być regularnie aktualizowana, aby odzwierciedlić wszystkie zmiany dokonane w środowisku.

Proces odzyskiwania jest złożony, obejmuje wiele różnych działań i składników, które można łatwo pominąć, jeśli nie są udokumentowane. Organizacje, które nie opracowały szczegółowych planów odzyskiwania po awarii, częściej doświadczają przestojów i utraty danych. Aby uzyskać szybką reakcję na zdarzenia zakłócające, firma potrzebuje jasnego zrozumienia, od czego zacząć oraz świadomości wszystkich najważniejszych aspektów. W związku z tym odpowiednio opracowana dokumentacja zwiększa szanse na pomyślne odzyskanie danych.

Określenie najważniejszych składników, które muszą zostać odzyskane jako pierwsze, może znacznie skrócić czas odzyskiwania. Nie wszystkie maszyny wirtualne w firmowej infrastrukturze są równie ważne. Maszyny wirtualne, w których mieszczą się krytyczne informacje biznesowe, systemy informatyczne i aplikacje, których działanie jest niezbędne do zapewnienia nieprzerwanego świadczenia usług, powinny być priorytetowe. Należy je jak najszybciej odzyskać. Należy ocenić znaczenie każdego komponentu sprzętowego i oprogramowania w swojej infrastrukturze i uwzględnić najbardziej krytyczne elementy w planie odzyskiwania po awarii.

Recovery Time Objective (RTO) i Recovery Point Objective (RPO) to dwie ważne metryki, które należy również opisać w planie odzyskiwania po awarii. Pierwsza określa, ile czasu firma może poświęcić na odzyskanie środków bez ponoszenia niedopuszczalnych strat finansowych. Ten ostatni określa, ile danych firma może utracić, jeśli nastąpi awaria. Innymi słowy, wartość RPO określa, jak często musi być wykonywana kopia zapasowa lub replikacja.

Różne maszyny wirtualne mogą mieć przypisane różne wartości RTO i RPO. Na przykład rozważmy maszyny wirtualne z systemami finansowymi: długie czasy przywracania są niedopuszczalne, a utrata danych jest wyjątkowo szkodliwa. Tym maszynom wirtualnym należy zatem przypisać możliwie najkrótsze RTO i RPO. Maszyny wirtualne używane do przechowywania zarchiwizowanych dokumentów mogą mieć znacznie dłuższe RTO i RPO.

Zależności i powiązania istnieją między pracownikami, a komponentami IT infrastruktury wirtualnej. Zależności te powinny być starannie ocenione, ponieważ nawet jedno brakujące ogniwo w łańcuchu zależności może prowadzić do druzgocących konsekwencji.

W dowolnej infrastrukturze poszczególne maszyny wirtualne mogą być zależne od oprogramowania lub informacji przechowywanych przez inną maszynę wirtualną, co oznacza, że ​​nie mogą działać oddzielnie lub mogą być uruchamiane losowo. Na przykład maszyna wirtualna z kontrolerem domeny Active Directory musi być uruchomiona, zanim będzie można uruchomić maszynę wirtualną przy użyciu serwera plików korzystającego z uwierzytelniania Active Directory.

Usługi internetowe często polegają na oprogramowaniu zainstalowanym na kilku różnych maszynach wirtualnych. Na przykład może zaistnieć potrzeba wykonania nastęującej sekwencji:

• Maszyna wirtualna z serwerem bazy danych powinna być uruchomiona jako pierwsza.
• Następnie można uruchomić maszynę wirtualną z serwerem aplikacji.
• Dopiero wtedy można uruchomić maszynę wirtualną z serwerem WWW.

Dzięki ustalonemu wcześniej porządkowi odzyskiwania można skrócić jego czas, zapewnić sprawny proces odzyskiwania i wyeliminować ryzyko konfliktów oprogramowania w infrastrukturze w witrynie DR.

Podczas określania łańcucha zależności należy również wziąć pod uwagę personel. Na przykład maszyna wirtualna używana przez dział księgowości może wymagać odzyskania najpierw, jeśli pracownicy innych działów będą zależni od tych operacji finansowych.

Jeżeli chcemy, aby nasi pracownicy pracowali nad planem DR, należy się upewnić, że są tam zainstalowane stanowiska pracy z pełnym wyposażeniem, meblami biurowymi i sprzętem komputerowym, tak aby pracownicy mogli kontynuować swoją pracę w celu wspierania działań biznesowych przy minimalnych przerwach w pracy. Jeśli pracownicy mogą pracować zdalnie z domu lub innego miejsca, należy skonfigurować dostęp do sieci VPN i z wyprzedzeniem udostępnić im konta VPN.

Aby zidentyfikować wszystkie te zależności należy pracować ze swoim personelem i uwzględnić je w opracowywaniu planu odzyskiwania po awarii. W przeciwnym razie cała procedura odzyskiwania może być podatna na niepowodzenie.

Sukces planu DR zależy w dużej mierze od wydajności i możliwości sprzętu znajdującego się w witrynie DR. Należy wziąć pod uwagę kilka czynników. Serwery muszą mieć wystarczającą pojemność procesora, pamięci i dysku, aby utrzymać przeniesione obciążenia. Niska wydajność procesora i niewystarczająca ilość pamięci mogą wpływać na szybkość maszyn wirtualnych, a niewystarczająca szybkość dysku powoduje niską wydajność maszyny wirtualnej. Sieci muszą zapewniać wystarczającą przepustowość dla odzyskanych maszyn wirtualnych do współdziałania ze sobą ze współużytkowaną pamięcią masową oraz z użytkownikami, jeśli to konieczne.

Planowanie jest niezbędnym krokiem do skutecznego odzyskiwania po awarii. Każda firma chce być dobrze przygotowana na katastrofy i może złagodzić jej konsekwencje. Aby to osiągnąć, należy ocenić swoje potrzeby związane z odzyskiwaniem, rozwijając pełne zrozumienie, jakie składniki, kroki i procedury powinny być zawarte w naszym planie odzyskiwania. W tym artykule zostały omówione podstawy takiej oceny, a także najlepsze praktyki dotyczące planowania odzyskiwania po awarii. Kolejny artykuł z tej serii obejmie przygotowanie infrastruktury do odzyskiwania za pomocą narzędzia Site Recovery w NAKIVO Backup & Replication.

Istnieją dwie generacje maszyn wirtualnych Hyper-V – Generacja 1 i Generacja 2. Wybór Generacji jest ważny podczas tworzenia maszyny wirtualnej; zależy on również od systemu operacyjnego gościa, systemu operacyjnego hosta, metod uruchamiania i innych czynników. Maszyny Generacji 2 są nowsze niż maszyny Generacji 1, choć czasami maszyny Generacji 1 mogą być wymagane do użycia. Ten artykuł wyjaśnia różnice między maszynami wirtualnymi Generacji 1 i 2, aby pomóc dokonywać właściwego wyboru i spełniać wymagania klientów.

BIOS

BIOS to podstawowe oprogramowanie systemu wejścia/wyjścia, znajdujące się w kości pamięci na płycie głównej. BIOS jest odpowiedzialny za start maszyny i konfigurację sprzętu. Maszyny wirtualne Gen 1 obsługują starszą architekturę opartą na systemie BIOS i można je ładować z wirtualnych dysków twardych MBR (Master Boot Record). Cyfrowy BIOS z wirtualnym sprzętem jest emulowany przez Hyper-V.

Dyski wirtualne IDE

Maszyny wirtualne Gen 1 mają wirtualny kontroler IDE, który może być używany do uruchamiania maszyny wirtualnej z dysku wirtualnego IDE. Kontrolery wirtualnych SCSI można rozpoznać dopiero po zainstalowaniu usług integracji Hyper-V w systemie gościa na maszynie wirtualnej. System gościa nie może uruchomić się z dysku SCSI.

Emulowany sprzęt

Fizyczny komputer potrzebuje zestawu elementów sprzętowych, aby mógł działać. Wszystkie wymagane komponenty sprzętowe muszą być emulowane, aby maszyna wirtualna działała. Specjalne oprogramowanie, które może imitować zachowanie prawdziwego sprzętu, jest zawarte w Hyper-V; w rezultacie maszyna wirtualna może działać z urządzeniami wirtualnymi. Emulowany sprzęt (identyczny z prawdziwym sprzętem) zawiera sterowniki, które są obsługiwane w większości systemów operacyjnych w celu zapewnienia wysokiej kompatybilności. Wśród wirtualnych urządzeń Gen 1 VM można znaleźć:

• Starsza karta sieciowa
• Wirtualny napęd dyskietek
• Wirtualne porty COM

Ograniczenia sprzętowe maszyn wirtualnych Generacji 1 to:

• 2 kontrolery IDE, z których każdy może dołączyć do 2 napędów IDE
• Maksymalnie 4 kontrolery SCSI i do 64 podłączonych napędów SCSI
• Dysk MBR – 2 TB z 4 partycjami
• Fizyczny napęd DVD może być podłączony do maszyny wirtualnej
• Obsługa gościa x86 i x64

Wsparcie UEFI BIOS. Obsługa GPT. Secure Boot

UEFI (Unified Extensible Firmware Interface) to oprogramowanie niskiego poziomu, które podobnie jak BIOS uruchamia się po włączeniu zasilania komputera przed załadowaniem systemu operacyjnego (OS). Termin “UEFI BIOS” jest również używany w celu lepszego zrozumienia. UEFI to nie tylko wymiana BIOSu, UEFI rozszerza obsługę urządzeń i funkcji. Niektóre z nich to obsługa GPT (GUID Partition Table) i Secure Boot. Schemat partycjonowania GPT pozwala przekroczyć limit dysków 2-TB, dla których maksymalna liczba partycji wynosi 4 dla schematu partycjonowania MBR. Secure Boot, to funkcja, która pozwala chronić przed modyfikowaniem programy ładujące i główne pliki systemowe; odbywa się to poprzez porównanie podpisów cyfrowych, którym musi zaufać producent oryginalnego sprzętu (OEM). Te funkcje są dostępne, ponieważ maszyny wirtualne Hyper-V Gen 2 obsługują system UEFI.

Uruchamianie z wirtualnego dysku SCSI. Natywna obsługa VMBUS

Z wirtualnych dysków SCSI można ładować maszyny wirtualne Generacji 2, ponieważ UEFI obsługuje taką komunikację ze sterownikiem SCSI, podczas gdy system BIOS tego nie robi. Obsługa syntetycznych sterowników VMBUS dla sprzętu syntetycznego podczas rozruchu maszyny wirtualnej pozwala na użycie sterowników SCSI podczas rozruchu. Na przykład maszyny wirtualne Generacji 1 mogą używać starszych sterowników IDE dla emulowanych urządzeń przed zainicjowaniem systemu plików. Usługi integracji Hyper-V muszą być zainstalowane, aby umożliwić kontroler SCSI dla maszyn wirtualnych Generacji 1.

Opcja rozruchu PXE

Zarówno maszyny wirtualne Gen 1, jak i Gen 2 obsługują PXE (pre-boot execution environment), które jest startem sieciowym. Istnieje jednak kilka ręcznych operacji, które należy wykonać, aby umożliwić uruchamianie PXE dla maszyn wirtualnych Generacji 1. Syntetyczna karta sieciowa o wyższej wydajności jest domyślnie dodawana do maszyny wirtualnej Gen 1, ale ten typ karty sieciowej nie obsługuje rozruchu sieciowego maszyn wirtualnych Generacji 1. Najpierw wyłącz maszynę wirtualną, a następnie dodaj emulowaną starszą kartę sieciową. Po wykonaniu tej czynności można użyć rozruchu PXE dla maszyny wirtualnej Gen 1.

Maszyny wirtualne Gen 2 obsługują rozruch sieciowy za pomocą syntetycznej karty sieciowej, ponieważ używają interfejsu UEFI, który może komunikować się z tym typem karty sieciowej. W ten sposób można używać rozruchu PXE dla maszyn wirtualnych Hyper-V Gen 2 bez żadnych dodatkowych sztuczek.

Dyski wirtualne VHDX

Maszyny VM z Gen 2 obsługują tylko format VHDX plików dysków wirtualnych, natomiast maszyny wirtualne Gen 1 obsługują zarówno formaty VHD, jak i VHDX. Format VHDX ma listę zalet, w tym:

• Obsługa bloków 4KB o lepszym wyrównaniu
• Zwiększony limit maksymalnego rozmiaru dysku
• Lepszy opór przed utratą zasilania podczas śledzenia metadanych
• Ogólnie lepsza wydajność wirtualnego dysku VHDX

Kopiowanie plików z hosta Hyper-V do maszyn wirtualnych bez połączenia sieciowego maszyn wirtualnych

Dostępny jest rozszerzony tryb sesji dla maszyn wirtualnych Gen 2, który korzysta z protokołu zdalnego pulpitu. Ta funkcja umożliwia współużytkowanie lokalnych zasobów hosta Hyper-V z maszynami wirtualnymi lub wykonywanie operacji kopiowania/wklejania między hostem, a systemem gościa bez połączenia sieciowego między hostem Hyper-V i maszyną wirtualną gościa. Wymiana plików może odbywać się za pomocą graficznego interfejsu użytkownika (VM Connect) lub PowerShell (Copy-VMFile cmdlet).

Musi zostać spełnionych kilka wymagań:

• Usługi integracji Hyper-V muszą być zainstalowane na maszynie wirtualnej
• Usługa pulpitu zdalnego musi być włączona na maszynie wirtualnej
• Guest OS musi być systemem Windows Server 2012 R2 lub nowszym/Windows 8 lub nowszą wersją systemu Windows

Jak widać, kopiowanie plików staje się wygodniejsze dla maszyn wirtualnych Gen 2. W przypadku maszyn wirtualnych Gen 1 jedynym sposobem kopiowania plików z hosta do systemu-gościa jest kopiowanie plików przez sieć.

Maszyny wirtualne uruchamiają się szybciej

Czas rozruchu maszyny Gen 2 VM jest o około 20% szybszy ze względu na szybszy start UEFI. Instalacja systemu operacyjnego gościa zajmuje nawet 50% mniej czasu. Chociaż podczas regularnego użytkowania ta zaleta może być niezauważalna, może pomóc zaoszczędzić czas, gdy trzeba zainstalować i skonfigurować dużą liczbę nowych maszyn wirtualnych lub skorzystać z infrastruktury Virtual Desktop Infrastructure (VDI).

Mniej urządzeń, sprzęt syntetyczny

W przeszłości systemy operacyjne były wydawane bez świadomości uruchamiania na maszynach wirtualnych. Z tego powodu używana jest emulacja sprzętowa. VM z Gen 1 używają metody emulacji sprzętowej dla maksymalnej kompatybilności. Najnowsze systemy operacyjne są świadome uruchamiania na maszynach wirtualnych i używają VMBus zamiast przeszukiwać starsze kontrolery lub chipsety. Większość urządzeń emulowanych przez Legacy została usunięta dla maszyn VM Gen 2, a zamiast nich zastosowano nowy szybszy sprzęt syntetyczny. Dzięki ściślejszej integracji z hiperwizorem i mniejszej liczbie urządzeń wirtualnych wydajność VM może wzrosnąć.

Wyższe limity procesora i pamięci RAM

Zwiększono maksymalną ilość wirtualnej pamięci RAM i maksymalną liczbę wirtualnych procesorów, które można przypisać do maszyny wirtualnej:

• 1 TB pamięci RAM dla maszyn wirtualnych Generacji 1 i 12 TB pamięci RAM dla maszyn wirtualnych Generacji 2;
• 64 procesory wirtualne dla maszyn wirtualnych Generacji 1 i 240 procesorów wirtualnych dla maszyn wirtualnych Generacji 2.

W ten sposób można używać maszyn wirtualnych Gen 2 do zadań, które zużywają więcej zasobów. Przed utworzeniem maszyny wirtualnej należy sprawdzić, czy wersja systemu operacyjnego hosta obsługuje wymaganą maksymalną ilość pamięci i maksymalną liczbę procesorów wirtualnych. Windows Server 2016 ma wyższe limity niż Windows Server 2012 R2.

Maszyny wirtualne Generacji 2 zostały wydane przez Microsoft z Hyper-V dla Windows Server 2012 R2 i Windows 8.1; dlatego te wersje 64-bitowego systemu Windows (lub późniejszego, w tym autonomicznego Hyper-V Server 2012 R2) są wymagane na hoście Hyper-V do uruchamiania maszyn wirtualnych Gen 2. Systemami operacyjnymi gościa dla maszyn wirtualnych Gen 2 mogą być systemy Windows Server 2012 lub nowsze wersje Windows Server, Windows 8 x64 lub nowsze ze względu na obsługę systemu UEFI 2.3.1 z opcją Secure Boot.

Podsumowując główne zalety używania maszyn wirtualnych Gen 2. Maszyny VM Gen 2 zapewniają:

• Wyższa wydajność (w tym wyższe limity procesora i pamięci)
• Wyższe bezpieczeństwo dzięki Secure Boot i Trusted Platform Module
• Więcej opcji rozruchu, takich jak rozruch PXE z syntetyczną kartą sieciową i rozruch z dysku SCSI
• Bardziej niezawodne wirtualne dyski VHDX o większym maksymalnym rozmiarze dysku
• Brak limitu dyskowego na 2 TB wymaganego wsparcia dla UEFI z GPT

Maszyny VM Gen 2 są zalecane w większości przypadków, szczególnie w nowoczesnych 64-bitowych systemach operacyjnych.

Wyjątki

Istnieją wyjątki, gdy VM Gen1 jest lepszym rozwiązaniem niż VM Gen2:

• Uruchamianie 32-bitowych systemów operacyjnych jest obsługiwane tylko przez maszyny wirtualne Generacji 1
• Korzystanie ze starszych systemów operacyjnych, które nie obsługują UEFI lub nie ma sterowników dla sprzętu syntetycznego (na przykład Windows XP, Windows 7, Windows Server 2008 i niektóre starsze dystrybucje Linuksa powinny być uruchamiane na maszynach wirtualnych Gen 1)
• Jeśli potrzebujesz użyć portów COM i dyskietek wirtualnych w maszynie wirtualnej, użyj maszyny wirtualnej Gen 1 (nie ma obsługi portów COM i dyskietek dla maszyn wirtualnych Gen 2)
• Migracja hosta VM na Hyper-V na podstawie systemu Windows Server 2012, Windows Server 2008 lub chmury Azure, które nie obsługują maszyn wirtualnych Gen 2

Aby utworzyć maszynę wirtualną w interfejsie GUI:

• Pierwszy otwarty menedżer Hyper-V
• Kliknij Akcja> Nowy> Maszyna wirtualna
• Powinien otworzyć się nowy Kreator maszyny wirtualnej
• Podaj nazwę i lokalizację utworzonej maszyny wirtualnej przed kliknięciem przycisku “Dalej”

Teraz możesz zobaczyć ekran “Określanie generacji”, w którym możesz wybrać generację wirtualnej maszyny (zobacz zrzut ekranu poniżej).

Po wybraniu Generacji kliknij “Dalej” i skonfiguruj inne opcje w kreatorze, aby zakończyć tworzenie maszyny wirtualnej.

Firma Microsoft nie dostarcza narzędzi do konwersji maszyn wirtualnych z jednej generacji na drugą. Na dowód powyższego można zobaczyć ostrzeżenie na powyższym zrzucie ekranu: “Po utworzeniu maszyny wirtualnej nie można zmienić generacji”. Musimy zatem spróbować przewidzieć wszelkie

możliwe przypadki użycia maszyny wirtualnej przed jej utworzeniem, ponieważ późniejsza zmiana generacji maszyn wirtualnych nie jest obsługiwana. Istnieje jednak jedno nieoficjalne narzędzie do konwersji maszyn wirtualnych Gen 1 na maszyny wirtualne Gen 2 o nazwie Convert-VMGeneration. To narzędzie nie modyfikuje źródła Gen1 VM. Podczas procesu konwersji tworzona jest nowa maszyna wirtualna Gen 2 z nowym dyskiem rozruchowym. Możesz używać tego narzędzia na własną odpowiedzialność bez żadnych gwarancji.

Pomimo generowania maszyn wirtualnych, należy je backupować, aby zapobiec utracie danych. NAKIVO Backup & Replication może tworzyć kopie zapasowe obu generacji maszyn wirtualnych Hyper-V i zapewnia następujące funkcje:

• Kopie zapasowe oparte na poziomie hosta. Maszyny wirtualne są archiwizowane na poziomie hiperwizora we wszystkich dyskach wirtualnych i plikach konfiguracyjnych. Nie ma potrzeby instalowania agentów kopii zapasowych na maszynie wirtualnej gościa i tworzenia pustej maszyny wirtualnej w przypadku odzyskiwania. Kopie zapasowe na poziomie hosta zużywają mniej zasobów obliczeniowych niż kopia zapasowa na poziomie gościa.
• Screenshot Verification umożliwia sprawdzenie, czy maszyna wirtualna została pomyślnie utworzona, a system operacyjny gościa może zostać załadowany po odtworzeniu maszyny wirtualnej. Korzystanie z tej funkcji zapobiega sytuacjom, w których utworzono kopię zapasową, ale maszyny wirtualnej nie można uruchomić po odzyskaniu.
• Granularne odzyskiwanie pozwala odzyskać pliki, katalogi, obiekty MS SQL, obiekty MS Exchange i obiekty Active Directory bez odzyskiwania całej maszyny wirtualnej – co oszczędza czas. Pliki można odzyskać z maszyn wirtualnych opartych na systemie Windows i Linux bezpośrednio z kopii zapasowych.

Automatyczne przełączanie awaryjne VM pomaga przywrócić obciążenia w jak najkrótszym czasie, jeśli masz replikę VM utworzoną przy pomocy NAKIVO Backup & Replication. Jeśli źródłowa maszyna wirtualna przechodzi w tryb offline po możliwej awarii, możesz przejść do repliki maszyny wirtualnej, która jest identyczną kopią źródłowej maszyny wirtualnej w odpowiednim momencie. Nie ma potrzeby ręcznej edycji ustawień sieci dla każdej maszyny wirtualnej podczas migracji do witryny odzyskiwania po awarii, której sieci różnią się od witryny źródłowej. Network Mapping i Re-IP automatyzują ten proces podczas tworzenia replikacji lub pracy awaryjnej.

Dzisiejszy artykuł obejmuje dwie generacje maszyn wirtualnych Hyper-V. Maszyny Gen 2 są bardziej progresywne, ponieważ wykorzystują syntetyczne urządzenia wirtualne, system UEFI BIOS, schemat partycjonowania GPT, bezpieczny rozruch, uruchamianie PXE, więcej niezawodnych dysków wirtualnych VHDX i wyższe limity sprzętowe. VM z Gen 2 są preferowane do użytku, ale mogą działać tylko na 64-bitowym systemie operacyjnym.

Jeśli potrzebujesz starszego systemu operacyjnego lub 32-bitowego systemu operacyjnego, użyj maszyn wirtualnych Generacji 1, które mają emulowane urządzenia wirtualne starszego typu, BIOS, obsługę portów COM, wirtualnych dyskietek, wirtualnych kontrolerów IDE i dołączonych fizycznych napędów DVD. Ważne jest, aby spróbować przewidzieć wszystkie możliwe przypadki użycia przed utworzeniem maszyny wirtualnej, ponieważ zmiana generacji wirtualnej maszyny po utworzeniu nie jest obsługiwana. Bez względu na to, którą generację wybierzesz, NAKIVO Backup & Replication może wykonać kopię zapasową maszyn wirtualnych Hyper-V w szybki i niezawodny sposób.