[DE] PernixData FVP – Backup- und Replizierungs-Integration


In diesem Post möchte ich auf die Backup- & Replizierungs-Integration von FVP eingehen. Um stets die Korrektheit der Daten zu gewährleisten, gibt es Verschiedene Wege wie FVP sich mit den vorhanden Backup- & Replizierungs-Techniken kombinieren lässt.  Grundsätzlich gibt es mehrere Ebene und Wege über welche die Daten einer virtuellen Maschine gesichert, respektive repliziert werden können. Im Folgenden gehe ich auf die einzelnen Varianten ein und die sich FVP in diesem Scenario verhält.

 

Gast Ebene – Mit klassischen Backup Agenten

Starten wir mit der ältesten Variante, die aber noch immer zum Einsatz kommt. In diesem Fall sind noch herkömmliche Backup Agenten in den jeweiligen VMs installiert, über welche die Daten gelesen und über das Netzwerk nach extern zum Ziel transportiert werden.

Um die Korrektheit der Datensicherung sicherzustellen, müssen in diesem Fall keine weiteren Maßnahmen getroffen werden, jedoch besteht die Möglichkeit der Verschmutzung des Cache Inhalts in FVP vorzubeugen. Denn aus Sicht von FVP handelt es sich hierbei um ganz normalen Storage IO der im Normalfall auch in den Cache kopiert werden sollte.

Intelligent I/O Profiling

Dieses Feature erlaubt via PowerShell Flags zu setzen, welche dann entweder keine neuen Read IOs, keine neuen Write IOs oder beide Arten nicht mehr in den Cache promoten (Suspend). In diesem Fall werden die Daten dann an den lokalen Ressourcen vorbeigleitet, solange bis das Flag zurückgesetzt wird (Resume).

  • Suspend-PrnxReadDataPopulation
  • Resume-PrnxReadDataPopulation
  • Suspend-PrnxWriteDataPopulation
  • Resume-PrnxWriteDataPopulation
  • Suspend-PrnxReadWriteDataPopulation
  • Resume-PrnxReadWriteDataPopulation

Damit ist sichergestellt, dass beispielweise ein einfacher Datenbank Dump, keine heißen Daten des Cache verdrängt.

 

VM Ebene – Über das Netzwerk (NBD Protokoll via VMkernel Port des ESXi)

Ein weiter Weg ist es, die VM als Ganzes, also über einen VM Snapshot zu sichern. Dies findet über die so genannte „VMware API for Data Protection“ (VADP) statt. Ein Weg die Daten der VMs auszulesen, führt über den VMKernel (Management) Port des ESXi Hosts. Hier werden die Daten über das „Network Block Device“ (NBD) Protokoll gelesen und zum Ziel transportiert.

Auch hier müssen keine weiteren Schritte unternommen werden, da die Anfragen (logisch gesehen) eine Ebene über der FVP Schicht ankommen und nach unten weitergereicht werden. Somit werden die Anfragen entweder über die klassischen Pfade vom Storage System bedient oder eben auch direkt aus dem Cache von FVP. Somit ist die Korrektheit des sichergestellt und das Backup liest immer die neuesten Daten der VM.

 

VM Ebene – Über das Hot-Add Verfahren

Die zweite Option eine VM zu sichern, ist das „Hot-Add“ Verfahren. Hier wird nach Erstellung des Snapshots die eingefrorene VMDK Datei der virtuellen Maschine in eine Backup Proxy VM eingehängt, welche dann entsprechend darüber die Daten ausließt und über das Netzwerk an das Ziel transportiert.

Hier ist der ersten Punkt, an dem FVP „aktiv“ mit dem Backup interagiert.VADPList

FVP bietet die Option, diese Backup Proxy VM(s) entsprechend als solche zu markieren und ermöglicht dadurch die folgende zwei Punkte:

  • Die Daten der Proxy VMs werden nicht beschleunigt. Dadurch werden auch keine unnötigen Daten in den lokalen Cache aufgenommen und Verschmutzung vermieden
  • Wichtiger ist jedoch, dass die Backup Proxy VMs überwacht werden, ob ein Hot-Add Vorgang stattfinden soll. Wenn ein solcher Versuch erkannt wird, kann dieses verzögert werden um vorab sicherzustellen, dass die zu sichernde VM keine offenen Daten mehr in FVP hat und diese alle erfolgreich zum zentralen Storage System weggeschrieben wurden. Somit wird die Korrektheit der gesicherten Daten sichergestellt.

Grundsätzlich trifft dies auch zu, wenn der Backup Server selbst als virtuelle Maschine läuft, dann kann einfach dieser selbst in die Liste aufgenommen werden. Wichtig ist jedoch, sollten mehrere FVP Cluster zum Einsatz kommen, wird pro FVP Cluster mindestens ein Backup Proxy benötigt, da eine VM immer nur einem FVP Cluster zugeordnet werden kann.

 

VM Ebene – Über direkten SAN Zugriff aka. LAN free Backup

Jetzt zum Klassiker. Hier ist der Backup Server in der Regel ein physikalischer Server, mit direktem Zugriff (FC/iSCSI) zum zentralen Storage System. Es wird zwar auch hier ein VM Snapshot über die VADP API angestoßen, die Daten werden jedoch direkt über das Storage System gelesen und zum Ziel transportiert.

In diesem Scenario gibt es derzeit für FVP keinen direkten Angriffspunkt, um den Start des Backups zu verzögern, um vorab sicherzustellen, das alle Daten zum Storage System geschrieben wurden.

In diesem Scenario kommen dann entsprechende Pre- und Post-Backup Scripts zum Einsatz, welche entsprechend die Koordination übernehmen. Hier muss sichergestellt werden, dass alle betroffenen VMs aus dem Write-Back Modus in den Write-Through Modus versetzt werden und keine Daten mehr ausstehend sind. All dies lässt sich über die entsprechenden PowerShell cmdlets steuern und kontrollieren.

 

Storage Snapshots & Replizierung

Last but not least, gibt es ja noch die klassischen Array basierten Technologien. Diese kommen vornehmlich im NetApp Umfeld zum Einsatz aber auch tendenziell, geprägt durch die Veeam & Commvault Integration in die verschiedensten Storage Arrays, auch bei anderen Herstellern.

Da das Storage nicht drüber Bescheid weiß, dass FVP eine Ebene darüber arbeitet, muss auch hier eine externe Instanz, beispielsweise ein Script dafür Sorge tragen, das vor einem Storage basierten Snapshot bzw. einem Replizierungsvorgang, alle betroffenen virtuelle Maschinen auf den jeweiligen Datastores (LUNs) aus dem Write-Back Modus in den Write-Through Modus versetzt werden. Auch hier muss sichergestellt werden, dass keine Daten mehr ausstehend sind.

FVP die Möglichkeit, sich einen graphischen Überblick über das das Delta zu machen. Die Daten stehen entweder auf VM Ebene, oder auch auf Cluster Ebene zur Verfügung.

WriteBackDestaging

Replizierung via vSCSI Filter wie z.B. Recoverpoint for VM oder Zerto

Diese Variante hatte ich in der ersten Fassung des Posts ausgelassen, daher hier noch eine kleine Ergänzung. Zusätzlich zu den oben beschriebenen Verfahren um Daten für ein Backup oder eine Replizierung auszulesen, gibt es noch die Variante die auf der Ebene des vSCSI Filters ansetzt.

In diesem Fall werden die Write IOs der virtuellen Maschinen bereits eine Ebene über FVP durch einen IO-Splitter dupliziert und zur jeweiligen Replizierungs-Appliance gesendet. Erst im nächsten Schritt gelangen die Write IOs dann in den FVP Layer, wo diese (sofern konfiniert) entsprechend im Write-Back Modus gecached werden.

Das bedeutet, dass dieses Verfahren und die darauf aufbauenden Lösungen zu PernixData FVP kompatibel sind.

Print Friendly

Related Post

It's only fair to share...Tweet about this on TwitterShare on LinkedInEmail this to someone

Leave a comment

Your email address will not be published. Required fields are marked *