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.

Miło nam poinformować, że pojawiła się nowa wersja NAKIVO Backup & Replication 8.0.  Tym samym Nakivo weszło na rynek rozwiązań do odzyskiwaniae danych po awarii dla przedsiębiorstw. Najnowsza wersja zawiera zaawansowaną funkcję Site Recovery, która jest potężnym narzędziem do odzyskiwania danych dla środowisk VMware, Hyper-V i AWS EC2. Funkcja ta umożliwia tworzenie zautomatyzowanych przepływów procesów odzyskiwania, testowanie ich w sposób niezakłócony i wykonanie przełączania awaryjnego za pomocą jednego kliknięcia – wszystko w jednym wygodnym interfejsie webowym. Będzie ona jeszcze dokładnie przez nas badana i zapewne pojawi się w kolejnych artykułach na blogu.

Narzędzie Site Recovery zostało zaprojektowane w celu aranżowania i automatyzowania procesu odzyskiwania danych po awarii maszyny wirtualnej. Funkcja pozwala tworzyć niestandardowe przepływy pracy odzyskiwania (tj. zadania Site Recovery) z zestawu dostępnych działań, w tym:

• Failover – Przełączanie awaryjne maszyn wirtualnych VMware, maszyn wirtualnych Hyper-V i AWS EC2 (można awaryjnie przejść do poprzednio utworzonej repliki)
• Failback – Powrót awaryjny maszyn wirtualnych VMware, maszyn wirtualnych Hyper-V i AWS EC2 (można przenieść obciążenia z powrotem z repliki w witrynie DR do źródłowej maszyny wirtualnej lub instancji po ponownym użyciu głównej lokacji)
• Start – Uruchom instancje VMware VM, Hyper-V VM lub AWS EC2
• Stop – Zatrzymaj instancje VMware VM, Hyper-V VM lub AWS EC2
• Run jobs – Uruchom zadania (możesz uruchomić wszystkie utworzone zadania)
• Stop jobs – Zatrzymaj zadania (możesz zatrzymać zadanie, które już działa)
• Run script – Uruchom skrypt (możesz wykonać dowolny skrypt na komputerach z systemem Linux lub Windows)
• Attach repository – Dołącz repozytorium (możesz dołączyć repozytorium kopii zapasowych)
• Detach repository – Odłącz repozytorium (możesz odłączyć repozytorium, które jest już dołączone)
• Send e-mail – Wyślij e-mail (możesz wysłać wiadomość e-mail powiadamiając zainteresowane strony, jeśli akcja zakończy się pomyślnie lub się nie powiedzie)
• Wait – Poczekaj (możesz odczekać określony czas, zanim przejdziesz do następnej akcji w przepływie pracy zadania)
• Check condition – Sprawdź stan. Przed rozpoczęciem odpowiedniego postępowania można sprawdzić dowolny z następujących warunków:
  • czy istnieje konkretna maszyna wirtualna/wystąpienie
  • czy konkretna maszyna wirtualna/instancja działa
  • czy host jest osiągalny

Akcje można uruchamiać w dowolnej kolejności, która odpowiada aktualnym potrzebom i procedurom odzyskiwania.

Zadanie Site Recovery można uruchomić w trybie testowym lub w trybie produkcyjnym. Głównym celem trybu testowego jest sprawdzenie, czy maszyny wirtualne można odzyskać zgodnie z planem odzyskiwania po awarii w ramach docelowych ram czasowych (RTO). Podczas wykonywania zadania przywracania lokacji w trybie testowym akcje takie jak Start/Stop VM, Failover/Failback i Attach/Detach Repository są przywracane po zakończeniu testu.

Spowoduje to powrót środowiska do stanu początkowego, dzięki czemu będzie ono gotowe do uruchomienia zadania w trybie produkcji, gdy będzie to konieczne. Gdy zadanie przywracania lokacji uruchamiane jest w trybie produkcyjnym, środowisko wirtualne jest odzyskiwane (np. po awarii), a działania nie są odwracane po zakończeniu zadania. Źródłowa maszyna wirtualna może zostać wyłączona, a zadania zmigrowane do replik VM w witrynie DR.

Cały proces odzyskiwania przeprowadzany za pomocą funkcji Site Recovery powinien składać się z kilku kroków, w tym replikacji maszyn wirtualnych, tworzenia przepływu pracy, testowania przepływu pracy, uruchamiania przełączania awaryjnego, a następnie przywracania do poprzedniego stanu (tj. uruchamiania po awarii). Konkretne podejście będzie jednak zależało od potrzeb klienta.

Posiadanie repliki jest warunkiem wstępnym do działania w trybie failover w ramach Site Recovery. Oprogramowanie NAKIVO Backup&Replication może skutecznie replikować maszyny wirtualne lub instancje, korzystając z podejścia uwzględniającego aplikacje. Należy wybrać, które źródłowe maszyny wirtualne/instancje powinny zostać zreplikowane, a następnie zdefiniować serwer docelowy i magazyn danych dla replik.

Aby utworzyć zadanie Site Recovery, trzeba po prostu skomponować poprawną sekwencję czynności, korzystając z opcji wymienionych powyżej. Na przykład można utworzyć następujący przepływ pracy:

• Przełączanie awaryjne VM1 do repliki w witrynie DR
• Sprawdź stan: Sprawdź, czy VM1 działa. Jeśli VM1 jest uruchomiona, przejdź do następnego kroku
• Poczekaj 5 minut
• Przełączanie awaryjne VM2. Dla celów tego przykładu załóżmy, że VM2 musi działać, aby VM1 działało poprawnie (np. VM1 uruchamia bazę danych SQL, od której zależy VM2)
• Sprawdź stan: Sprawdź, czy działa VM2. Jeśli VM2 działa, przejdź do następnego kroku
• Uruchom skrypt na VM2
• Wyślij wiadomość e-mail: poinformuj personel działu, że przełączenie awaryjne zostało pomyślnie wykonane

Jest to uproszczony przykład, który pozwala zorientować się, w jaki sposób podstawowy przepływ pracy awaryjnej DR VM będzie działał z NAKIVO Backup & Replication. Można tworzyć wiele zadań przywracania lokacji dla różnych sytuacji. Takie podejście sprawia, że ​​odzyskiwanie danych po awarii jest bardziej elastyczne i pomaga szybciej odzyskiwać infrastrukturę wirtualną wraz z usługami, które na niej działają.

Jak opisano powyżej, zadanie przywracania lokacji, które zawiera działania przełączania awaryjnego, może być uruchomione w trybie testowym. Najlepsze praktyki nakazują uruchamianie zadania Site Recovery w trybie testowym zaraz po jego utworzeniu.

W ten sposób mamy gwarancję, że wszystko będzie działać zgodnie z planem i będzie to można odzyskać pomyślnie w odpowiednim czasie. Można zaplanować zadanie przywracania lokacji, aby okresowo działało w trybie testowym. Aby uruchomić zadanie przywracania lokacji w trybie produkcyjnym, należy ręcznie zainicjować zadanie.

Przełączanie awaryjne, to proces przełączania z uszkodzonej maszyny wirtualnej w miejscu produkcji na replikę maszyny wirtualnej w witrynie DR. Przełączanie awaryjne jest jedną z czynności dostępnych dla zadania Site Recovery. Źródłowa maszyna wirtualna VM może być elastycznie wyłączana podczas pracy awaryjnej dzięki funkcji odzyskiwania witryny NAKIVO Backup & Replication.

Opcja VM Power off source może być przydatna, gdy źródłowa maszyna wirtualna jest nadal włączona, ale działa nieprawidłowo po awarii.

Powrót awaryjny, to proces przywracania obciążeń do źródłowej maszyny wirtualnej za pomocą repliki VM, która została użyta do odzyskiwania po awarii. Proces powrotu po awarii jest zasadniczo odwrotnością procesu przełączania awaryjnego. Po przełączeniu awaryjnym do repliki wszystkie zmiany są zapisywane w replice na stronie DR.

Po odzyskaniu witryny produkcyjnej należy przenieść tam obciążenia. Źródłowa maszyna wirtualna musi zostać zsynchronizowana z jej repliką maszyny wirtualnej, aby zaktualizować stan maszyny wirtualnej, ponieważ nowe dane (od momentu przełączenia awaryjnego) zostały zapisane tylko w replice maszyny wirtualnej. Operacja powrotu po awarii replikuje dane z repliki maszyny wirtualnej z powrotem do źródłowej maszyny wirtualnej.

Kompleksowa orkiestracja i automatyzacja DR. Site Recovery pozwala wdrażać plany odzyskiwania po awarii przy wysokim poziomie automatyzacji. Można zdefiniować kolejność odzyskiwania VM z uwzględnieniem zależności VM, tak aby po wystąpieniu awarii odzyskiwanie było tak wydajne, jak to tylko możliwe.

Elastyczność w celu dostosowania do potrzeb różnych firm. Mona utworzyć wiele zadań przywracania witryny w zależności od potrzeb. Zestaw dostępnych akcji do włączenia w Site Recovery umożliwia tworzenie różnych przepływów pracy odzyskiwania dostosowanych do różnych sytuacji.

Wbudowany w rozwiązanie do ochrony danych. Site Recovery, to funkcja zawarta w oprogramowaniu NAKIVO Backup & Replication i dostępna wraz z pozostałą częścią kompleksowego zestawu funkcji produktu; nie musisz kupować oddzielnej licencji. Dzięki temu rozwiązaniu wszystkie czynności związane z ochroną danych i odzyskiwaniem danych po awarii są zarządzane z jednej konsoli.

Znaczne oszczędności w porównaniu do innych rozwiązań DR. Program NAKIVO Backup & Replication z wbudowanym narzędziem Site Recovery, to ekonomiczne rozwiązanie. Produkt nadal oferuje użytkownikom przydatne nowe funkcje przy zachowaniu tych samych przystępnych cen – zwłaszcza w porównaniu z konkurencją.

Oprogramowanie NAKIVO Backup & Replication może chronić maszyny wirtualne przed awariami spowodowanymi przez problemy z oprogramowaniem lub awarie sprzętu. Należy jednak wykonać kopię zapasową oprogramowania wykonującego backupy. Tylko wtedy system ochrony danych może zostać przywrócony w najkrótszym czasie i wznowiony w celu ochrony VM. Wśród ciekawych nowych funkcji, NAKIVO Backup & Replication v7.4 zawiera Self-backup, który tworzy kopie zapasowe i odzyskuje własne ustawienia produktu.

Oprogramowanie NAKIVO Backup & Replication można uruchomić na maszynie fizycznej lub wirtualnej. Jest wiele rzeczy, które mogą spowodować awarię obu typów maszyn (awarie sprzętu, awarie systemu, atak wirusa, klęski żywiołowe itp.). Jeśli tak się stanie z maszyną, na której działa NAKIVO Backup & Replication, nowa instalacja produktu może zostać zakończona w ciągu kilku minut – jednak rekonfiguracja wszystkich ustawień od nowa zajmie znacznie więcej czasu. Jest to szczególnie ważne w dużych środowiskach z dużą liczbą maszyn wirtualnych. Nowa funkcja tworzenia kopii zapasowych NAKIVO Backup & Replication pozwala przywrócić konfigurację produktu w ciągu kilku minut.

Self-backup może być używany w następujących sytuacjach:

• Cofanie się do momentu przed wykonaniem niepożądanych zmian. Jeśli ktoś przypadkowo zastosował niepożądane zmiany, możesz z łatwością “przywrócić” poprawną konfigurację z kopii zapasowej.
• Konfigurowanie nowej instancji po awarii. Jeśli maszyna, na której działa produkt, ulegnie awarii, możesz zainstalować nową instancję NAKIVO Backup & Replication na innej działającej maszynie i przywrócić całą konfigurację z Self-backup.

Następujące dane systemowe są archiwizowane, gdy włączona jest funkcja Self-backup:

• Zapasy (w tym wszystkie wirtualne środowiska VMware / Hyper-V / AWS, zarządzane poświadczenia, mapowania sieciowe i reguły Re-IP)
• Repozytoria kopii zapasowych
• Utworzone zadania tworzenia kopii zapasowych, tworzenia kopii zapasowych backupu i replikacji (w tym dane o uruchomionych wcześniejszych zadaniach oraz przyszłych zaplanowanych zadaniach)
• Informacje o transporterach

Self-backup jest domyślnie włączony i wykonywany raz dziennie. Możesz zmienić ustawienia harmonogramu lub ręcznie wykonać zadanie Self-backup na żądanie. Domyślne ustawienia przechowywania (które możesz edytować) to zapisanie ostatnich 5 punktów odzyskiwania.

Self-backup są przechowywane w repozytoriach kopii zapasowych, które są dodawane do ekwipunku. Możesz użyć wszystkich dostępnych repozytoriów do przechowywania kopii zapasowej lub wybrać konkretne repozytoria. Domyślnie funkcja Self-backup zapisuje kopie zapasowe w pierwszych pięciu dostępnych repozytoriach.

Zauważ, że Self-backup nie wymaga konfiguracji; funkcja działa „po wyjęciu z pudełka” z ustawieniami domyślnymi.

Domyślna konfiguracja Self-backup:

• Działa raz dziennie, o 02:00
• Przechowuje ostatnie pięć punktów przywracania
• Korzysta z pierwszych pięciu dostępnych repozytoriów

Te domyślne ustawienia prawdopodobnie pasują do większości użytkowników. Jeśli chcesz dostosować ustawienia Self-backup, skorzystaj z poniższego opisu.

Możesz uzyskać dostęp do ustawień funkcji Self-backup w „Konfiguracja> Ogólne” (kliknij, aby rozwinąć „Self-backup” i zobacz podgląd ustawień). Kliknij „Edytuj”, aby skonfigurować funkcje tworzenia kopii zapasowych.

Otworzy się nowe okno z ustawieniami. Możesz zobaczyć następujące opcje:

• Przeznaczenie. W tej sekcji możesz wybrać repozytoria, które będą używane do przechowywania Self-backup

• Harmonogram. W tej sekcji możesz wybrać swoją strefę czasową, czas rozpoczęcia zadania Self-backup oraz dni tygodnia, w których wykonywana jest kopia zapasowa. Wprowadź czas, wybierz strefę czasową z menu i zaznacz/odznacz odpowiednie pola wyboru dla dni tygodnia.
• Zatrzymywanie. Te ustawienia umożliwiają określenie liczby punktów odzyskiwania przechowywanych w repozytoriach kopii zapasowych. Nowe samodzielne kopie zapasowe zastępują starsze punkty odzyskiwania.

Przejdźmy przez dodawanie i usuwanie repozytoriów, które będą używane do przechowywania Self-backup. Jeśli usuniesz zaznaczenie pola wyboru „Utwórz kopię zapasową konfiguracji systemu do wszystkich repozytoriów”, możesz ręcznie usunąć określone repozytoria. Po prostu wybierz repozytorium, w którym nie chcesz przechowywać kopii zapasowych i kliknij „Usuń”.

Zostanie wyświetlony komunikat z potwierdzeniem.

W tym przykładzie wszystkie repozytoria zostały usunięte z listy Self-backup. Tak więc nie ma już żadnych przedmiotów dostępnych w sekcji „Miejsce docelowe”.

Ponieważ nie ma repozytoriów dla kopii zapasowej, w „Konfiguracja> Ogólne> Self-backup” widać, że funkcja tworzenia kopii zapasowej jest teraz oznaczona jako nieskonfigurowana.

Możesz łatwo dodać repozytorium kopii zapasowej do Self-backup. Edytuj ustawienia Self-backup – kliknij „Dodaj repozytorium backupu” i wybierz repozytorium, którego chcesz użyć, zaznaczając pole wyboru. Zwróć uwagę, że tylko repozytoria, które zostały już dodane w konfiguracji produktu (Konfiguracja> Repozytoria) są widoczne jako opcje na liście ustawień Self-backup.

Teraz skonfigurowane są ustawienia Self-backup. Jeśli chcesz natychmiast go uruchomić, kliknij przycisk „Uruchom Self-backup” teraz.

Pokażmy teraz, jak odzyskać konfigurację NAKIVO Backup & Replication z Self-backup przechowywanego w repozytorium. Przejdź do opcji „Konfiguracja> Repozytoria”, wybierz jedno z repozytoriów, które zawiera kopię zapasową, kliknij opcję „Self-backup”, a następnie kliknij „Odzyskaj”.

Następnie wybierz punkt przywracania i kliknij przycisk „Przywróć”.

Zaczekaj, aż przywrócona zostanie konfiguracja systemu.

Po zakończeniu przywracania funkcji Self-backup pojawi się komunikat o powodzeniu.

W trybie Multi-Tenant każdy izolowany najemca może korzystać z Self-backup, aby wykonać kopię zapasową swoich izolowanych ustawień NAKIVO Backup & Replication w celach odzyskiwania. W ten sposób najemcy mogą korzystać z funkcji Self-backup w trybie Multi-Tenant w taki sam sposób, w jaki zwykli użytkownicy mogą korzystać z Self-backup w trybie instalacji z jednym najemcą. Globalny administrator instalacji na wielu najemcach może eksportować lub importować dowolną konfigurację do migracji systemu.

Korzystanie z Self-backup oszczędza czas, ponieważ nie trzeba konfigurować ustawień produktu od zera po czystej instalacji po awarii lub migracji. Posiadanie skonfigurowanej instancji NAKIVO Backup & Replication dostępnej przez cały czas chroni maszyny wirtualne, zapewniając, że nie zostaną utracone zadania tworzenia kopii zapasowych lub replikacji. Nie zapomnij wykonać kopii zapasowej oprogramowania do tworzenia backupu  i poprawić niezawodność ochrony środowiska wirtualnego.

NAKIVO ponownie wprowadza nową i ulepszoną wersję naszego flagowego oprogramowania do ochrony danych! Najnowsza wersja z aktualizacjami i ulepszeniami jest już dostępna do pobrania. Nowe funkcje obejmują obsługę vSphere 6.7, Advanced Bandwidth Throttling, Cross-Platform Recovery i kompatybilność z dwoma nowymi urządzeniami pamięci masowej. Poznaj NAKIVO Backup & Replication v7.5!

NAKIVO nieustannie udoskonala i dodaje nowe funkcje do NAKIVO Backup & Replication, ale są również zaangażowani w zapewnienie zgodności z najnowszymi aktualizacjami wdrożonymi przez wiodących dostawców wirtualizacji. Dlatego NAKIVO Backup & Replication jest jednym z pierwszych rozwiązań ochrony danych VM oferujących wsparcie dla nowego VMware vSphere 6.7. Teraz klienci mogą być pewni, że ich ulepszone środowiska wirtualne są chronione przy użyciu NAKIVO Backup & Replication v7.5.

Osoby korzystające z oprogramowania NAKIVO Backup & Replication v7.4 powinny znać Bandwidth Throttling – funkcję, która pozwala ustawić ograniczenia prędkości transferu danych dla każdego zadania. W wersji 7.5 funkcja ta została dodatkowo ulepszona dla większej wygody i elastyczności.

Odtąd użytkownicy mogą nie tylko ustawiać limity na podstawie poszczególnych zadań, ale także tworzyć reguły globalne. Globalne reguły są stosowane w określonych okresach; zadania, które są uruchomione, nie mogą przekroczyć ustawionego limitu globalnego. W ten sposób można na przykład zagwarantować, że aplikacje o krytycznym znaczeniu dla biznesu będą miały wystarczającą przepustowość do prawidłowego działania podczas wykonywania kopii zapasowych w godzinach pracy.

Teraz dzięki zaktualizowanej wersji oprogramowania NAKIVO Backup & Replication można zapomnieć o niedogodnościach i problemach związanych z używaniem wielu platform wirtualizacyjnych w produkcji. Oprócz tradycyjnego odzyskiwania z kopii zapasowych i replik można odzyskiwać dane maszyn wirtualnych na różnych platformach bez konieczności powiązania z konkretnym hyperwizorem.

Dzięki NAKIVO Backup & Replication v7.5 i nowej funkcji Cross-Platform Recovery nie ma potrzeby stosowania wielu rozwiązań do ochrony danych. Użytkownicy mogą łatwo eksportować wirtualne dane z kopii zapasowych VMware i Hyper-V do formatów VMDK, VHD lub VHDX w celu odtworzenia na wybranym hoście.

Ta funkcja może być również używana do innych celów ochrony danych. Na przykład dzięki funkcji wieloplatformowego odzyskiwania można przejść z jednej platformy wirtualizacyjnej na drugą, przenosząc dane maszyny wirtualnej między nimi. Ta funkcja jest również przydatna do celów długoterminowego archiwizowania danych kopii zapasowej maszyny wirtualnej. Wyeksportuj i zapisz dane wirtualne w wybranym formacie, aby mieć pewność, że za pomocą innego oprogramowania do wirtualizacji można odzyskać dane z pliku nawet za dziesięć lat.

NAKIVO Backup & Replication v7.5 teraz działa bezproblemowo wraz z EMC Data Domain Boost poprzez integrację z wtyczką BoostFS. Urządzenia Dell EMC DD Boost cieszą się dobrą renomą dzięki funkcji deduplikacji po stronie źródłowej, która umożliwia zmniejszenie rozmiaru kopii zapasowej w proporcjach do 17: 1.

Przy stale rosnącej ilości danych istotne jest zoptymalizowanie zużycia przestrzeni dyskowej, wzmocnienie ochrony danych i odciążenie sieci produkcyjnych. Oprogramowanie NAKIVO do tworzenia kopii zapasowych i replikacji oraz domena danych Dell EMC może rozwiązać te problemy. Podczas gdy NAKIVO Backup & Replication zajmuje się procedurami ochrony danych, EMC DD Boost może zwiększyć szybkość tworzenia kopii zapasowych nawet o 50% i zmniejszyć rozmiar kopii zapasowych nawet o 94%.

Lista obsługiwanych urządzeń NAS do bezpośredniej instalacji NAKIVO Backup & Replication stale rośnie. Poprzednia wersja oprogramowania zawierała rodzime pakiety instalacyjne dla serwerów Asustor, QNAP, Synology i Western Digital NAS. Od teraz, NAKIVO Backup & Replication można również zainstalować na urządzeniach NETGEAR ReadyNAS.

Łącząc zalety dwóch produktów – najlepszego oprogramowania ochrony danych VM i niezawodnego serwera NAS firmy NETGEAR – tworzy on urządzenie do tworzenia kopii zapasowych VM z kilkoma korzyściami. NAKIVO Backup & Replication obsługuje szeroką gamę urządzeń NETGEAR ReadyNAS, od modeli klasy podstawowej do najwyższej klasy. Jeśli posiadasz już urządzenie ReadyNAS w jednej z obsługiwanych konfiguracji, możesz z łatwością przekształcić je w wszechstronne rozwiązanie ochrony danych VM, które obejmuje sprzęt do backupu, oprogramowanie, pamięć masową, wbudowaną globalną deduplikację danych i funkcję tworzenia kopii zapasowych na chmurę.

Pobierz pełną wersję darmowej wersji próbnej NAKIVO Backup & Replication v7.5, aby wypróbować wszystkie nowe funkcje we własnym środowisku wirtualnym!