Odtwarzanie maszyny wirtualnej lub fizycznej z backupu może zająć wiele czasu, w zależności od jej wielkości, sposobu przechowywania oraz mechanizmu odtwarzania wykorzystywanego w oprogramowaniu. W niektórych przypadkach nie chcemy lub nie możemy sobie pozwolić na takie opóźnienie. Przykładowo może to być sytuacja, gdy maszyna wirtualna ulega uszkodzeniu, a nie korzystamy z replikacji lub replika nie zawiera informacji których potrzebujemy, natomiast innym przykładem może być konieczność przeprowadzenia testów aktualizacji zanim zaaplikujemy ją na maszyny produkcyjne. Właśnie do zaadresowania tych potrzeb stworzona została funkcja Flash VM Boot (odtwarzania natychmiastowego) w Nakivo Backup & Replication.
Jak działa odtwarzanie natychmiastowe?
Porównamy dwa przypadki: pełne odtwarzanie maszyny wirtualnej z backupu oraz odtwarzanie natychmiastowe, zanim to zrobimy odpowiemy sobie jednak na pytanie jak to działa. Funkcja odtwarzania natychmiastowego pozwala uruchamiać maszyny wirtualne bezpośrednio z repozytoriów backupu bez konieczności ich przywracania. Brzmi niewiarygodnie, poniżej znajdziecie poszczególne etapy działania tego mechanizmu:
- NAKIVO tworzy obiekt, maszynę wirtualną na docelowym hoście ESXi
- Następnie przygotowuje w repozytorium dyski dla konkretnego punktu przywracania i udostępnia je do podłączenia
- W kolejnym kroku dyski są podłączane jako target iSCSI do nowo utworzonej maszyny
- NAKIVO uruchamia nowo utworzoną maszynę
W całym procesie pomijamy czasochłonny etap kopiowania danych w postaci odtworzonych dysków w danym punkcie przywracania na datastore hosta, dlatego nazywamy to odtwarzaniem natychmiastowym.
Odtwarzanie pełne kontra Flash VM Boot
Konfiguracja testowa
Do testu wykorzystamy 2 maszyny wirtualne: pierwsza to Windows Server 2016 z dwoma dyskami o łącznej wielkości 80 GB, druga to Ubuntu 16.04, z dwoma dyskami o łącznej wielkości 540 GB.
Wykonujemy backup obu maszyn, w rezultacie uzyskujemy obrazy o wielkości 7.4 GB dla maszyny z Windows oraz 140.6 GB dla maszyny z Ubuntu. Mniejsza wielkość wynika z zastosowanych mechanizmów deduplikacji i kompresji. Deduplikacja polega na porównywaniu bloków backupowanych maszyn z blokami danych już znajdującymi się w repozytorium (na podstawie sum kontrolnych), duplikaty są usuwane, natomiast dla bloków unikalnych tworzone są wskaźniki wykorzystywane do późniejszego odzyskania danego punktu przywracania. Deduplikacja jest tym bardziej efektywna im więcej mamy danych o tej samej charakterystyce, np. gdy backupujemy maszyny z tym samym systemem operacyjnym. Więcej o tym mechanizmie możecie przeczytać tutaj.
Oprócz deduplikacji, NAKIVO w celu redukcji ilości danych poddaje je procesowi kompresji, której stopień jest konfigurowalny per repozytorium, wybrać możemy stopień bardziej efektywny ale zajmujący więcej czasu i zasobów lub mniej efektywny ale działający szybciej.
Maszyna mniejsza
Maszyna większa
Odtwarzanie pełne, wyniki testu.
Aby eksperyment był wiarygodny, maszyny odtwarzaliśmy do tego samego hosta ESXi oraz zastosowaliśmy te same ustawienia. Poniżej wyniki.
Mniejsza maszyna została odtworzona w czasie poniżej 7 minut.
Odtwarzanie większej maszyny zajęło godzinę.
Odtwarzanie natychmiastowe, wyniki testu.
Następnie utworzyliśmy zadanie Flash VM Boot dla każdej z maszyn, przy okazji tworzenie takiego zadania jest proste:
1. W interfejsie NAKIVO wybierz zakładkę Recover.
2. Wskaż opcję Flash VM Boot.
3. W pierwszym kroku kreatora odtwarzania wybierz istniejący backup oraz punkt przywracania.
4. Następnie wskaż środowisko, do którego maszyna będzie odtwarzana, docelowego hosta, datastore oraz interfejsy sieciowe. Zauważ, że możesz wskazać nawet różne datastore dla poszczególnych dysków, jeżeli maszyna ma ich więcej niż jeden.
5. Na kroku Schedule możesz określić harmonogram, kiedy ma nastąpić odtworzenie lub zdecydować się na odtwarzanie na żądanie.
6. Krok Options pozwala edytować nazwę zadania, nazwę odtwarzanej maszyny, zdecydować, czy ma zostać uruchomiona po zakończeniu zadania, a także czy należy przypisać jej nowe adresy MAC (aby nie kolidowała z maszyną produkcyjną, jeżeli tamta nadal jest uruchomiona).
Po wybraniu przycisku Finish&Run proces Flash VM Boot rozpocznie się.
Poniżej przedstawiamy wyniki dla naszego testu.
Maszyna mniejsza
Maszyna większa
Zrzuty ekranu zostały wykonane zaraz po tym jak maszyny zostały odtworzone i uruchomione w vSphere. Jak można zauważyć, cały proces zajął tylko 20 sekund dla każdej z maszyn i obie były w pełni funkcjonalne.
Dane testowe zostały zawarte również w poniższej tabeli:
| # | System VM | Dyski | Ilość danych po backupie | Czas dla Flash VM Boot | Czas dla pełnego odtworzenia |
Stosunek czasów odtwarzania (pełnego odtworzenia do Flash VM Boot) |
| Większa maszyna | Ubuntu 16.04 | 2 dyski, 540 GB, thick provisioning | 140.6 GB | 20 s | 1 h | 177:1 |
| Mniejsza maszyna | Windows Server 2016 | 2 dyski, 80 GB, thick provisioning | 7.4 GB | 20 s | 7 m | 11:1 |
Powyższe wyniki nie powinny pozostawić wątpliwości, że funkcja Flash VM Boot to nie gadżet, a niezbędna funkcjonalność, która może pomóc nam niemal natychmiastowo przywrócić do działania uszkodzoną maszynę lub pozwolić przetestować nowe aktualizacje bez konieczności tworzenia pełnych kopii istniejących maszyn.
Co dalej?
Jeżeli odzyskujemy maszynę typowo do celów testowych, to wystarczy zakończyć zadanie z poziomu interfejsu Nakivo Backup & Replication. To działanie usunie dane oraz zmiany wprowadzone do odtworzonej tymczasowo maszyny.
Jeżeli chcesz maszynę pozostawić na stałe, możesz przenieść ją korzystając np. z mechanizmów Vmware vMotion.
Podsumowanie
Flash VM Boot to dobry wybór, jeżeli planujesz przetestować wgranie patchy czy aktualizacji przed ich zastosowaniem na produkcji lub odtworzyć natychmiastowo maszynę w razie jej awarii. Jeżeli jednak będziecie mieli do czynienia z katastrofą, w której trzeba odtworzyć wiele maszyn, rekomendujemy bliżej przyjrzeć się mechanizmom Site Recovery oraz replikacji (o których pisaliśmy tutaj), tak aby niezbędne zasoby w razie potrzeby czekały bezpiecznie na uruchomienie w zapasowym środowisku.
Źródło: https://www.nakivo.com/blog/instant-vm-recovery-from-backup/
