A easy and fast way to backup FlashArray with Rubrik - Part 2: backup and restore deep dive

Aktualisiert: Jan 27

[Autoren: Marco Hieronymus und Marcel Düssil]


Im Zuge dieser Blog Serie entschlossen wir uns, den Inhalt auf zwei Beiträge zu verteilen. Der erste Teil der Serie legte den Fokus auf die notwendigen Konfigurationen innerhalb Rubrik, VMware und Pure Storage. Dieser Beitrag hingegen soll Backup- und Restorevorgänge beinhalten und gibt hier tief technische Einblicke.


Technical overview


Grundsätzlich gilt "jeder kocht nur mit heißem Wasser", egal ob CommVault, Cohesity, Veritas, Veeam, ArcServe, EMC Avamar, EMC NetWorker, IBM TSM ... nutzt auch Rubrik die vorgegebene Schnittstelle für Backups virtueller Maschinen des Hypervisors. Jedes Backuptool nutzt bei VMware vSphere die vStorage API for Data Protection (kurz VADP). VADP ist Nachfolger von VMware Consolidated Backup (VCB) und ist seit vSphere 4 gängiger Standard zur Sicherung von vSphere. Gemeinsam mit Changed Block Tracking (CBT) ist VADP eine bewährte Methode für inkrementelle und schnelle Datensicherung.

Im Zuge meiner Recherchen fand ich eine interessante Gegenüberstellung von VADP und VCB. Wie ich finde, ist es äußerst interessant, was heute mit den Funktionen von VADP Selbstverständlichkeit sind und mit VCB nur bedingt oder nicht möglich war.

Quelle: VMware Knowledge Base

Hyper-V arbeitet für Backups selbstverständlich mit Volumenschattenkopien/Volume Shadow Copy (VSS) und nicht VADP. Hier bietet jeder Hypervisortyp-/hersteller (Nutanix AHV, Citrix XenServer, ...) seine eigen entwickelte Mechanismen und Schnittstellen.


An dieser Stelle will ich also klar sagen: Rubrik hat den Markt beim Backup-/Restoreprozess nicht revolutioniert und das Rad neu erfunden. In meinen Augen liegt die Kunst in der Userexperience und in der Arbeit mit den Tools. Es gibt das ein oder andere Produkt, welches intuitiv von jedermann zu nutzen ist, wobei andere wiederum komplexer und weniger einfach in der Bedienung sind.


Also dürfte ich bei nachfolgendem technischen Einblick für jedes Backuptool mit VADP sprechen.


Rubriks Backupworkflow


(1) Verbindung zum vCenter und initiieren des Backupjobs.

(2) Ausführen Pre-Backup Script innerhalb der VM auf dem Hypervisor, um die Applikation in einen konsistenten Zustand zu versetzen.

(3) Erstellen eines VMware Snapshot. Siehe Abschnitt weiter unten: How Snapshots work.

(4) Über die Pure Storage REST API wird ein Storagesnapshot des Datastores und dem darunterliegenden Volume auf der Pure erstellt. Die Datastores können auch auf mehrere physische Arrays verteilt werden (setzt Anbindung aller Arrays auf der Rubrik voraus).

(5) Entfernen des VMware Snapshots.

(6) Ausführen eines Post-Snap Scripts in der VM.

(7) Mounten des Volumesnapshots an den ESXi Server. Im Hintergrund wird ein neues Volume aus dem in Schritt (4) erzeugten Volumesnapshot erzeugt. Auf den ESXi HBA wird ein Rescan durchgeführt, um das neue Volume zu discovern. Das neue Volume wird dann an den Host präsentiert und gemountet. Aus dem Volume wird anschließend ein Datastore erstellt. Wichtig: die erzeugten Storagevolumes und der Datastore sind nur temporär vorhanden.

(8) Erstellen einer Proxy VM. Die temporäre Proxy VM basiert auf den Ressourcen wie das Original (Template), wobei die Proxy VM auf jedem ESXi Server mit Netzwerkanbindung zu den Arrays platziert werden kann. Die erstellte Proxy VM ist ausgeschaltet und es ist kein Networking konfiguriert. Der in Schritt (7) erzeugte Datastore wird nun an die Proxy VM verbunden.

(9) Abgreifen der Daten aus der Proxy VM. Hierbei kommt VMware CBT zum Einsatz, um so nur geänderte Blöcke zur letzten Sicherung zu übertragen.

(10) Bereinigung Proxy VM.

(11) Unmounten der temporären Datastores/Volumes.

(12) Bereinigen der Array Volumes/Snapshots.

(13) Ausführen Post-Backup Script (falls konfiguriert).


Die Praxis


Backup


Es gibt selbstverständlich auch bei Rubrik die Möglichkeit einen sofortigen Snapshot "on demand" zu erstellen. Diese Operation kann man auf einzelne VM-Objekte, Gruppen und SLA-Pläne ausführen. Nachfolgend erstellen wir einen Snapshot auf unsere SLA Domain.

Wie wir sehen können, existierte der VMware Snapshot für gerade einmal 6 Sekunden und wurde instant wieder aufgelöst. Somit ist die Größe des Delta-Files minimalst.

Gewachsene Delta-Files können bei hochfrequenten Systemen signifikante Auswirkungen haben. Ein Beispiel wäre, das Redo-/Löschvorgänge für Snapshots dazu führen können, dass Zeitüberschreitungen für die Systeme/Clients eintreten. Außerdem könnten Sicherungen auch bei der Stilllegung während Snapshot-Vorgängen fehlschlagen.


How Snapshots work


Beim Auslösen eines Snapshots wird idealerweise das Gastbetriebssystem stillgelegt. Sollte die virtuelle Maschine bei der Erstellung des Snapshots eingeschaltet sein, werden VMware Tools verwendet, um das Dateisystem auf der virtuellen Maschine stillzulegen. Das Stilllegen eines Dateisystems ist ein Prozess, bei dem die Daten auf der Festplatte eines physischen oder virtuellen Computers in einen für Sicherungen geeigneten Zustand versetzt werden. Zu diesem Prozess zählen Vorgänge wie das Leeren von geänderten Puffern aus dem In-Memory-Cache des Betriebssystems auf die Festplatte.


Wenn ein Snapshot erstellt wird, besteht er aus den folgenden Dateien: -.vmdk und --delta.vmdk.

Eine Sammlung von obigen Snapshot-Dateien für jede virtuelle Festplatte ist zum Zeitpunkt des Snapshots mit der virtuellen Maschine verbunden. Diese Dateien werden als untergeordnete Festplatten, Redo-Protokolle oder Delta-Links/-Files bezeichnet. Die untergeordneten Festplatten können später für zukünftige untergeordnete Festplatten als übergeordnete Festplatten betrachtet werden. Von der ursprünglichen übergeordneten Festplatte aus stellt jede untergeordnete Festplatte ein Redo-Protokoll dar, dass vom derzeitigen Zustand der virtuellen Festplatte aus Schritt für Schritt zurück auf das Original verweist.

Hinweis: Wenn die virtuelle Festplatte größer als 2TB ist, hat die Redo-Protokolldatei das Format --sesparse.vmdk.vmsd.

Diese .vmsd-Datei ist eine Datenbank mit den Snapshot-Informationen der virtuellen Maschine und die primäre Informationsquelle für den Snapshot-Manager. Die Datei enthält Zeileneinträge, welche die Beziehungen zwischen Snapshots und den untergeordneten Festplatten für jeden Snapshot definieren.

Snapshot.vmsn


Eine .vmsn-Datei enthält die aktuelle Konfiguration und optional den aktiven Zustand der virtuellen Maschine. Wenn der Arbeitsspeicherzustand der virtuellen Maschine erfasst wird, kann der Zustand einer eingeschalteten virtuellen Maschine wiederhergestellt werden. Mit anderen als Arbeitsspeicher-Snapshots (Stichwort: crash-consistent) kann nur der Zustand einer ausgeschalteten virtuellen Maschine wiederhergestellt werden. Die Erstellung von Arbeitsspeicher-Snapshots dauert länger als ein "einfacher" Snapshot.

Wie funktionieren Snapshots?


Anhand der VMware-API können Produkte von VMware und Dritten Vorgänge mit virtuellen Maschinen und deren Snapshots ausführen.


Nachfolgend eine Aufstellung der häufigen Vorgänge, die mithilfe der API mit virtuellen Maschinen und Snapshots ausgeführt werden können:


CreateSnapshot: Erstellt einen neuen Snapshot einer virtuellen Maschine. Damit wird auch der aktuelle Snapshot aktualisiert.


RemoveSnapshot: Entfernt einen Snapshot und löscht alle zugeordneten Speicher.


RemoveAllSnapshots: Entfernt alle Snapshots, die einer virtuellen Maschine zugeordnet sind. Wenn einer virtuellen Maschine keine Snapshots zugeordnet sind, gibt dieser Vorgang einfach eine Erfolgsmeldung zurück.


RevertToSnapshot: Ändert den Ausführungszustand einer virtuellen Maschine in den Zustand dieses Snapshots. Dies ist äquivalent mit der Option „Gehe zu“ des Snapshot-Managers, wenn die vSphere/VI-Client-GUI verwendet wird.


Consolidate: Führt die Hierarchie von Redo-Protokollenzusammen. Diese Option ist in vSphere 5.0 und neuer verfügbar.

Eine Anforderung zum Erstellen, Entfernen oder Wiederherstellen eines Snapshots für eine virtuelle Maschine wird vom Client über die VMware-API an den Server gesendet. Die Anforderung wird an den VMware ESX-Host weitergeleitet, der derzeit die virtuelle Maschine hostet.

Wenn der Snapshot die Arbeitsspeicheroption umfasst, schreibt der ESX-Host den Arbeitsspeicher der virtuellen Maschine auf die Festplatte.

Hinweis: Die virtuelle Maschine ist während der Dauer des Arbeitsspeicher-Schreibvorgangs eingefroren. Die Dauer der Einfrierung kann nicht im Voraus bestimmt werden und hängt von der Leistung der betreffenden Festplatte und der Größe des geschriebenen Arbeitsspeichers ab.

Wenn der Snapshot die Stilllegungsoption umfasst, fordert der ESX-Host das Gastbetriebssystem auf, die Festplatten anhand von VMware Tools stillzulegen.

In Abhängigkeit vom Gastbetriebssystem kann der Stilllegungsvorgang vom Synchronisierungstreiber, dem vmsync-Modul oder dem VSS-Dienst (Volume Shadow Copy) von Microsoft ausgeführt werden.

Während einer Snapshot-Entfernung kann der Vorgang sehr lange dauern, wenn die untergeordneten Festplatten groß sind. Dies kann zu Fehlermeldungen wegen Zeitüberschreitung durch VirtualCenter oder den VMware Infrastructure Client führen.


Hier an dieser Stelle kommen uns die Vorteile von Backups auf Basis von Storage-Snapshots zu Gute.


Parallel können wir auf der Pure beobachten, dass der Storage-Snapshot entsprechend den Attributen des Ursprungsvolume angelegt wurde. Wichtig an dieser Stelle die Storagekapazität wird durch die Datenreduktion nicht vollständig konsumiert.

Das erzeugte Volume wird dann entsprechend als vSphere Datastore gemountet und für die Anbindung an die Proxy VM vorbereitet. Das Activity Log zeigt hier den laufenden aktiven Prozess.

Wir können hier erkennen, dass keine "guest credentials" hinterlegt wurden. Dies wäre für die Erstellung einer Applikationskonsistenz (Sicherung des Arbeitsspeichers) zwingend notwendig. Wir erstellen also somit ein crashkonsistentes Backup und die Sicherung wird an der Stelle auch nicht fehlschlagen. Dies müsste man bei entsprechenden Systemen wie z. B. Datenbanken beachten. Hier ist es wichtig eine entsprechende Konsistenz herzustellen, da es bei der Wiederherstellung eine Korruption nicht ausgeschlossen ist.

Nach dem HBA-Rescan am ESX-Host wird das entsprechende Volume mit einer neuen Signatur versehen und als Datastore registriert. Die oben genannte Proxy VM direkt anschließend mit den entsprechenden vDisks aus dem Clone-Volumedatastore erzeugt und das eigentliche Backup aus der Proxy-VM erstellt.

Hinweis: es ist an dieser Stelle auch möglich, einen dedizierten ESX als Host für Proxy-VMs anzugen und so ggf. den Backupload auch nochmal von den Produktiv-Hosts zu nehmen.

Nach dem Backup erfolgt die umgehende Bereinigung (unregister/delete) der Proxy-VM und des Datastores. Auch hier ist wieder jeder Schritt im Activity Log entsprechend zu tracken.


In der Aufgabenkonsole von vSphere können wir sehen, dass der ganze Prozess (trotz der unzähligen Einschränkungen und der mangelnden Performance der Testumgebung) innerhalb von 4 Minuten vollständig abgeschlossen wurde.

Die Rubrik GUI reportet uns nach Abschluss der Datensicherung auch umgebend den "Latest Snapshot" in der Übersicht, sowie in der Kalenderübersicht. Sehr charmant und übersichtlich gelöst.

Unser Backupjob ist hiermit abgeschlossen.


Restore


Ein großer Mehrwert von Rubrik ist hier eine schnelle Indexierung der Files in einer Art Google-Search Datenbank. Somit können Files innerhalb der Appliance schnell anhand von Schlagwörtern gesucht und gefunden werden.

Beim Restore haben wir selbstverständlich mehrere Möglichkeiten:

  • Mount Virtual Machine: es ist möglich eine VM ohne Restore direkt aus dem Backup anzustarten. Hier wird ein NFS-Datastore in die virtuelle Umgebung gemountet und das System (ohne Guest-VM-Anpassung) angestartet. Alle Änderung nach dem Trennen des Mounts werden wieder verworfen. Hierbei kommt uns spürbar die Rechenleistung der Rubrik Nodes zu Gute.

  • Mount Virtual Disks: ähnlich der vorangegangenen Option ist es auch möglich, einzelne virtuelle Festplatte bereitzustellen, um so z. B. Gastsystem-Inhalte zu extrahieren.

  • Instantly Recover: Wiederanstarten der VM auf dem Rubrik Cluster mit vollständiger Netzwerkkonnektivität.

  • Export: der Export ermöglicht es an dieser Stelle eine Wiederherstellung auf den Hypervisordatastore durchzuführen.

  • Recover Files: hierbei geht es wohl um die am Häufigsten eingesetzte Variante Daten wiederherzustellen. Glücklicherweise werden meist nur Gast-OS-Dateirestores benötigt. Mit Recover Files können granular auf dem Ursprungsziel oder per Download einzelne Dateien wiederhergestellt werden.

Wir zeigen entsprechend in der Serie nachfolgend Instantly Recover, Mount Virtual Disks und Recover Files.

Recover Files


Die Wiederherstellung einzelner Files kann per selbsterklärenden Wizard durchgeführt werden. Hier gibt es an der Stelle nicht sonderlich viel zu sagen. Die Gast-Files werden aus dem Backup entsprechend extrahiert und als Download bereitgestellt.


Instantly Recover & Mount Virtual Disks


Nehmen wir an, eine kritische Geschäftsanwendung, die in einer VM läuft, ist defekt. Dieser Ausfall wirkt sich weitgehend auf alle Ihre Anwender aus. Mit Rubrik können Sie eine sofortige Wiederherstellung ohne Datenverlust durchführen. Wählen Sie einfach Ihren neuesten Schutzpunkt (Snapshot) und führen Sie ein Live-Mount mit nur wenigen Klicks aus.


Rubrik wird dann alle relevanten Hot Blocks in SSD übertragen und diese VM in Ihrer VMware-Umgebung präsentieren, wodurch die Maschine innerhalb von Sekunden eingeschaltet wird. Und ja, selbst wenn Ihre Geschäftsanwendung mehrere Terabyte groß ist, dauert dieser Vorgang nur wenige Sekunden.


Instantly Recover


Beim Instant Recover muss man nur den Host für den Mount angeben. Im Hintergrund wird dann automatisch die Maschine mit dem Ursprungsnamen + Zeitstempel des Snapshots + aufsteigende Numme der VM registriert. Die "defekte" bzw. alte Maschine wird abgeschaltet und umbenannt.


Mount Virtual Disk


Für einen vDisk Mount sind ein paar Mehr "Klicks" notwendig. Zuerst müssen wir die jeweilige vDisk für den Mount selektieren, eine Mount-VM auswählen (ja!: wir mounten hier an einen Veeam Server - this works! ) und danach legt der Mount direkt los.



Innerhalb vSphere können wir nun einen Datastore (NFS-Mount von Rubrik) sehen, welcher eine vDisk an die Mount-VM präsentiert.

Im Gast-OS (PURE-VEEAMVBR-1) können wir über die Datenträgerverwaltung dieses Volume initialisieren, einen Laufwerksbuchstaben zuweisen und direkt auf die Dateien über den Explorer zugreifen.

Das Unmounten der vDisk erfolgt dann wieder über die Rubrik GUI. Ich musste zuvor den Datenträger innerhalb von Windows nicht zwingend auf offline setzen, der Vorgang lief auch hier ohne Probleme durch.

Man kann selbstverständlich per vSphere Boardmittel und Storage vMotion die Daten aus dem NFS-Datastore direkt in einen persistenten Produktivspeicher/-datastore verschieben.

Die Option "Remove local entry after Storage vMotion" würde hier die Konfiguration (also den Mount) entsprechend an dieser Stelle konfigurationsseitig aufräumen.


Pure Storage Auditing


Ich hoffe die Pure's Auditing Funktionen für ausgeführte Operationen und Sessions sind bereits bekannt. Falls nein, sollte man sich dies unbedingt einmal ansehen. Man findet diese in der GUI unter System > Users, sowie auch in der CLI über pureaudit. Hier werden alle Eingriffe und Logins am System geloggt und können für Konfigurationstracking, Loginvorgänge wie auch beim Troubleshooting entsprechend herangezogen werden.

Das war es auch an dieser Stelle zum Thema Pure Storage und Rubrik Integration. Wir hoffen die Einfachheit und vor allem das Potenzial und den Nutzen beider Lösungen kamen in den Beiträgen gut rüber.


Abschließend gibt es an der Stelle noch zu sagen: es bleibt spannend - wir werden zeitnah auch über die Integration mit Pure's Objektspeicher aka FlashBlade und Rubrik entsprechend berichten.


Danksagung


Diese Blogserie entsteht in Zusammenarbeit mit meinem besten Freund und Rubrik-Spezialisten Marco Hieronymus [XING | LinkedIn]. .

Marco und ich kennen uns bereits seit einiger Zeit. Uns verbindet neben der Freundschaft auch unser Beruf. Marco besitzt unter anderem jahrelanges Expertenwissen in den Bereichen VMware, Nutanix, DELL EMC VxRail/Networking, Aruba/Cisco Switching und Rubrik. Er hat einige Zertifizierungen in seinen Fachbereichen vorzuweisen. Im Lauf seiner Karriere war Marco nicht nur im Systemhaus, sondern auch bereits ein paar Jahre als Endkunde bei der regionalen Tageszeitung in Regensburg angestellt. Im Zuge meiner Ausbildung war es mir unter anderem durch Marco's Hilfe möglich meine Facharbeit mit Bravour abzulegen.


An dieser Stelle nochmal besten Dank für deine Unterstützung und Zeit - Marco.


Weitere Infos - Links


Sämtliche offiziell veröffentlichten Einstellungsmöglichkeiten in der GUI, aber auch CLI können über die "on-board" User Guides der Pure Storage Systeme nachgelesen werden.


Im Purity Hauptmenü hierzu auf "Help" klicken.



Der User Guide ist wie das Hauptmenü gegliedert und kann von Ebene zu Ebene geöffnet werden. Eine Suchfunktion ist auch integriert - hier kann mit Schlagworten gesucht werden.



WEB: Pure Storage (Pure1) Supportportal - Ticketsystem und Unterstützung *(erfordert registrierte FlashSysteme)


TEL: Pure Storage Telefonsupport: GER - (+49) (0)800 7239467; INTERNATIONAL - (+1) 650 7294088


WEB: Pure Storage Community


WEB: Pure Storage OFFICIAL Blog



Der Blog lebt von Fragen, Wünschen und Anregungen...jeder Kommentar ist -lich willkommen. Über Feedback bin ich sehr dankbar.

0 Ansichten
SIGN UP AND STAY UPDATED!

LINKS

>> purestorage.com - Pure Storage official site

>> virtualhome.blog - focused on veeam & virtualization topics by Falko Banaszak

MAIL:

|

TEL:

|

 Amberg, Bayern, Deutschland

LOC:

© 2019 by PUREFLASH.blog

  • Twitter Marcel Düssil PUREFLASH.blog
  • LinkedIn Marcel Düssil
  • Xing Marcel Düssil
  • PUREFLASH.blog official YouTube