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.

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!

NAKIVO jest rozwiązaniem do backupu maszyn wirtualnych działających w środowiskach VMware, Hyper-V oraz Amazon EC2. Podczas konferencji Poland VMUG UserCon 2018 w Warszawie mieliśmy okazję zaprezentować NAKIVO zainstalowane na QNAP, a więc atrakcyjne cenowo (i funkcjonalnie!) rozwiązanie backup appliance.

Nasz zestaw wzbudził niemałe zainteresowanie. Zobaczmy więc, które funkcje były dla uczestników najciekawsze.

Większość odwiedzających stanowisko NAKIVO nie zwracała w pierwszej chwili uwagi na to, jak Nakivo jest zainstalowane – wszyscy zakładali, że zainstalowaliśmy je wewnątrz którejś z maszyn wirtualnych.

Dopiero po krótkiej rozmowie, gdy okazywało się, że NAKIVO działa jako natywna aplikacja w QNAP, zainteresowanie rosło. Dlaczego?

NAKIVO nie wymaga dedykowanej platformy sprzętowej lub systemowej do instalacji. Tak naprawdę możemy utworzyć serwer backupu na dowolnej maszynie z systemem Linux lub Windows, ale także zainstalować aplikację na NAS QNAP, które rozwiązanie szczególnie polecamy.

My pokazaliśmy połączenie NAKIVO x QNAP TVS-882-i5-16G. Takie połączenie daje nam sporo możliwości – cały proces backupu, kompresji, deduplikacji obciąża tylko naszego NAS’a, a nie środowisko produkcyjne. A dodatkowo zachowujemy całą funkcjonalność urządzenia – NAKIVO działa na QNAP równolegle z innymi aplikacjami czy usługami.

Więcej o instalacji NAKIVO na QNAP możesz poczytać w tym artykule (https://makeittogether.pl/konfiguracja-backupu-maszyn-wirtualnych-na-nakivo-qnap-i-vmware-exsi/)

Deduplikacja pozwala na ograniczenie wielkości backupu poprzez wykluczanie z backupu bloków, które już w nim istnieją. W ten sposób możemy zminimalizować ilość danych przechowywanych w repozytorium, szczególnie wtedy, gdy backupujemy wiele maszyn wirtualnych o podobnej zawartości (np. utworzonych z jednego template).

NAKIVO Backup & Replication automatycznie wykorzystuje deduplikację podczas tworzenia każdego z backupów w ramach całego repozytorium backupu.

Oznacza to, że niezależnie do tego, czy backupujemy maszyny wirtualne z VMware, Hyper-V czy instancje AWS EC2, deduplikacja pozwoli wykluczyć powtarzające się bloki.

Funkcja, która pozwala sprawdzić, czy maszyny zostały poprawnie zbackupowane, ale przede wszystkim daje możliwość Disaster Recovery – maszyna wirtualna może być uruchomiona na wskazanym serwerze ESXi bezpośrednio z backupu, z pominięciem procesu przywracania czy kopiowania plików.

Dzięki temu w ciągu zaledwie kilku minut wcześniej uszkodzony/utracony system może znowu pracować i udostępniać swoje funkcje dla użytkowników. Dodatkowo NAKIVO pozwala na późniejszą migrację takiej maszyny do środowiska produkcyjnego z pominięciem wykonywania dodatkowego backupu.

Uwaga – maszyna wirtualna w trybie Flash VM Boot jest uruchamiana z backupu skompresowanego i zdeduplikowanego, więc na potrzeby tej funkcji nie musimy tworzyć osobnych kopii bezpieczeństwa.

Funkcja Flash VM Boot wykorzystywana jest też przez mechanizm Screenshot Verification.

Zwykle backup weryfikowany jest w najprostszy sposób, czyli za pośrednictwem sum kontrolnych. Ma to oczywiście swoje zalety, jednak nie sprawdza jednej istotnej kwestii, czyli działania samego systemu.

Jeśli np. system zostanie uszkodzony w wyniku problemów z systemem plików czy np. szyfrowania przez ransomware, backup może wykonać się poprawnie, sumy kontrolne będą się zgadzały, jednak dane/system będą uszkodzone.

NAKIVO postępuje inaczej. Po wykonaniu backupu maszyna jest uruchamiana we wskazanym środowisku, po czym odczekuje wskazany przez administratora czas (np. 3 minuty) i wykonuje zrzut ekranu w konsoli takiej maszyny.

Taki zrzut jest wysyłany później mailem do Administratora. W ten sposób administrator ma pewność, że w razie problemów, będzie w stanie przywrócić z backupu działający system.

Więcej o tej opcji możesz poczytać tutaj: https://www.nakivo.com/features/screenshot-verification/

Replikacja! Jak sama nazwa oprogramowania wskazuje (NAKIVO Backup&Replication), producent kładzie bardzo duży nacisk na możliwości replikacji danych.

Pierwsza opcja to oczywiście replikacja samego backupu (plików) do zewnętrznych repozytoriów (udział sieciowy off-site, drugi serwer backupu NAKIVO, ale też chmura AMAZON czy MS Azure).

Pozwala to ochronić pliki backupu na wypadek np. awarii storage w lokalizacji głównej.

Druga, znacznie ciekawsza opcja pozwala na zachowanie ciągłości działania. Jest to opcja replikacji maszyn wirtualnych do innych hypervisorów. W ten sposób możemy skonfigurować tworzenie kopii całych maszyn wirtualnych do osobnego środowiska lub do lokalizacji off-site.

Taka replika jest tworzona z pominięciem wykonywania backupy (osobne zadania), dzięki czemu nie wymaga dodatkowej przestrzeni dyskowej i jest wykonywana szybciej.

Replika zapisywana jest w datastore docelowego środowiska, dzięki czemu w razie potrzeby uruchomienia takiej maszyny wirtualnej, może ona działać już docelowo w tym środowisku.

Co ważne, w przypadku potrzeby uruchomienia maszyny, zachowujemy do 30 punktów przywracania, co oznacza, że nawet w przypadku zreplikowana uszkodzonej maszyny, możemy uruchomić jej wcześniejszą wersję.

NAKIVO ma bardzo prosty sposób licencjonowania, gdzie mamy dwie główne wersje – wersję PRO i wersję ENTERPRISE.

Różnica pomiędzy nimi jest niewielka – integracja z AD, API http czy opcje multi-tenancy. Oznacza to, że wszystkie powyższe opcje są dostępne zawsze w cenie rozwiązania. Nie musimy dokupować licencji na kolejne gigabajty danych czy możliwość granularnego przywracania danych czy zawartości MSQL czy MS Exchange.

Więcej o rodzajach dostępnych licencji i tym, co zawierają, możesz poczytać tutaj: https://www.nakivo.com/how-to-buy/vmware-hyper-v-pricing/

Oczywiście NAKIVO Backup & Replication posiada ogrom innych funkcji. Poznać je można na stronie producenta: https://www.nakivo.com/vmware-backup/