Ich möchte in diesem Beitrag (auch als Vorbereitung für einige folgende Beiträge) einmal auf den Instant Access Restore mit dem Dell EMC NetWorker eingehen. Vom Prinzip her funktionier dieser aber bei allen Backups Tools, welche auf Data Domain aufbauen, ähnlich. Also beim NetWorker gibt es hier z.B. zwischen VBA und vProxy keinen großen Unterschied und auch ein Veeam arbeitet genau so.
Eine Übersicht über die verschiedenen Restore Methoden mit Kurzbeschreibung gibt es hier.
Der Instant Access Restore ist dazu gedacht, eine VM schnell wieder verfügbar zu machen, ohne sie vorher erst restoren zu müssen. D.h. die Data Domain stellt einen VMware Datastore mit allen benötigten Dateien (Konfigurationsdateien, Festplatten der VM) bereit und registriert damit eine neue VM im vCenter, die dann sofort hochgefahren und benutzt werden kann.
Man muss hier jedoch beachten, dass die Data Domain kein High-Performance-Online-Storage ist. Das NFS-Protokoll, über welches die Data Domain den Datastore zur Verfügung stellt, ist auch nicht für hohe Performance geeignet. D.h. man muss mit Performance-Einbußen rechnen. Bei einer kleinen VM mit wenig Last wird man dies vermutlich nicht merken, aber bei einer großen VM mit haufenweise Transaktionen wird sich dies bemerkbar machen.
Beim Instant Access geht es nur darum, die VM möglichst schnell wieder verfügbar zu machen. Der eigentliche ‘Restore’ erfolgt dann nachgelagert mittels VMware Storage vMotion. Damit verschiebt man die VM vom Data Domain Datastore in einen ‘normalen’ Datastore, was allerdings natürlich weitere Last erzeugt und die Performance der VM noch weiter beeinträchtigt.
Nichtsdestotrotz ist der Instant Access eine der am häufigsten genutzen Restore-Methoden, weil die VM eben sofort wieder zur Verfügung steht. Außerdem kann man den Instant Access noch für andere Dinge ge- (oder miss-)brauchen. Darauf werde ich noch in weiteren Beiträgen eingehen.
Eine Information vorab schon einmal: Beim FLR (File Level Recovery) wird ebenfalls ein Instant Access Restore durchgeführt. Der Unterschied zwischen Instant Access und FLR besteht letztendlich darin, dass der Instant Access eine neue VM im vCenter registriert, während der FLR die Platten an die gewünschte Ziel-VM bereitstellt und keine VM registriert.
Die eigentliche Durchführung des Restores kann man im NetWorker VMware Integration Guide nachlesen, daher werde ich hier nicht darauf eingehen.
Mir geht es hier um die technischen Hintergründe.
Hat man in der NMC einen Instant Access Restore gestartet, passiert folgendes:
1) NetWorker sucht sich für den Restore ein passendes DDBoost Device und entnimmt die dort hinterlegten Device access Information. Diese beinhalten neben dem Namen (oder der IP) der Data Domain auch den Pfad auf dem Filesystem der Data Domain.
2) NetWorker versucht einen geeigneten vProxy zu ermitteln oder, falls man einen ausgewählt hat, wird dieser genommen. Die automatische Ermittlung funktioniert leider häufig nicht, wenn man in einem vCenter verschiedene Cluster hat, die voneinander unabhängig sind. In diesem Fall sollte man direkt einen geeigneten vProxy auswählen, um sich Zeitverluste zu ersparen.
3) Nun geht es ans vCenter. NetWorker ermittelt dort den Namen und alle IP-Adressen des ESX-Clusters, den man als Ziel angegeben hat. Leider ist es nicht möglich, explizit einen ESXi-Host auszuwählen. Beim FLR Instant Access werden jedoch die Informationen über den ESX-Host, auf dem die Ziel-VM läuft, gesammelt und nicht von dem, auf dem der vProxy läuft.
4) Die Informationen aus 1) und weitere Informationen (z.B. Saveset ID des gewünschten Backups, Mtree Name auf der DD, usw.) werden an den vProxy übermittelt.
5) Der vProxy kontaktiert die Data Domain unter der in 1) ermittelten IP/Name und teilt dieser mit, dass sie einen VMware Datastore mit einer Kopie dieses Savesets erstellen soll.
6) Die Data Domain führt diese Kopie in einen separaten Bereich durch, nämlich nach: /data/col1/<mtree (meist Backup Server Name)>/Recover-<vProxy-Name>-<ID>
7) Der vProxy kontaktiert die Data Domain und teilt dieser mit, dass sie einen NFS-Export für das Verzeichnis aus 6) mit dem Namen des Verzeichnisses aus 6) an einen der ESXi-Hosts aus 3) erstellen soll. Die Liste der erlaubten NFS-Clients für diesen Export beinhaltet alle IPv4 & IPv6 Adressen von einem der ESXi-Hosts, sodass dieser eine Host auf welchem Weg auch immer an den Share kommt, aber niemand sonst. In der Data Domain GUI (oder auf der CLI) sieht man diesen Export auch bei Protocols -> NFS
8) Nun wird dem vCenter mitgeteilt, dass es einen neuen Datastore anlegen soll. Als Quelle dient der NFS-Share auf der Data Domain und gemountet werden soll er an einen der ESXi-Hosts aus 3)
9) Bei einem normalen Instant Access wird nun die Konfigurationsdatei der VM auf dem Datastore angepasst. Dort werden die Pfade zu den Platten entsprechend geändert, damit sie zu dem NFS-Datastore passen und, falls man einen anderen Namen als den ursprünglichen für die VM gewählt hat, wird dieser natürlich auch angepasst.
Bei einem Instant Access für FLR entfallen die Änderungen an der Konfigurationsdatei. Stattdessen werden die Platten an die Ziel-VM gemountet. Das Betriebssystem in der VM erkennt, dass es jetzt neue Platten gibt und kann damit arbeiten. Quasi so als würde man einen USB-Stick anschließen. Die neuen Platten sieht man bei Windows dann auch im Disk Management und kann diesen z.B. auch Laufwerksbuchstaben zuweisen.
10) Hat man beim Instant Access ausgewählt, dass die VM angeschaltet werden soll, geschieht dies nun.
11) Da der Instant Access primär dazu gedacht ist, einen komplett ausgefallenen Server schnell zu ersetzen, steht dieser nun zur Verfügung.
12) Da der Betrieb auf dem NFS-Share der Data Domain kein Dauerzustand sein kann (und der Share wird auch nach ca. 10 Tagen automatisch gelöscht!), erfolgt der eigentliche ‘Restore’, indem man mit Hilfe des vCenters ein Storage vMotion durchführt und die VM damit in den Ziel-Datastore verschiebt.
13) Sobald der vMotion durch ist, kann man in der NMC den Restore abbrechen (rechts oben auf Cancel) und NetWorker beginnt dann mit den Aufräumarbeiten. Sprich der NFS-Datastore wird unmountet und der NFS-Export auf der Data Domain gelöscht.
Beim FLR geht es nach Schritt 9 anders weiter, aber dies werde ich in einem weiteren Beitrag zu FLR genauer ansprechen.
Wenn man noch die alte VBA nutzt, läuft das alles ein bisschen anders, weil dann nicht der NetWorker Server die treibende Kraft hinter ist, sondern der Avamar Server in der VBA. Aber was die Anbindung der DD an die VMware Infrastruktur angeht, nämlich der NFS-Share-Mount mit dem Datastore an einen ESXi; dies funktioniert identisch zum vProxy.
Seit 2006 bin ich im Data Protection Bereich tätig und habe über die Jahre Erfahrungen mit diversen Produkten sammeln können. Darunter NetBackup, Avamar und natürlich vor allem NetWorker. Mit NetWorker habe ich seit meiner Ausbildung zum Fachinformatiker – Fachrichtung Anwendungsentwicklung – zu tun und habe mich auch auf diesen spezialisiert – vor allem in Kombination mit der Data Domain als Backup Storage. Darüber hinaus programmiere ich gerne in der Sprache Perl, sei es nun beruflich oder privat.