Backup from Storage Snapshots – BfSS
Nur ein einziger Grund für die Aktivierung von BfSS
BfSS läßt sich als eine optionale Funktion beschreiben, die für primäre Sicherungsaufträge zur Verfügung steht.
Wie Sie wahrscheinlich wissen, muss jeder primäre Backup-Auftrag auf jeder virtuellen Maschine zunächst einen VMWARE-Snapshot erstellen, bevor er gesichert werden kann. Dies ist aus zwei Gründen erforderlich. Erstens, um den genauen Zeitpunkt zu definieren, zu dem ein Backup erstellt werden soll. Darüber hinaus sollten wir beim Backup laufender Systeme in der Lage sein, anwendungsspezifische Prozesse zu starten, bevor wir den VMWARE-Snapshot erstellen. So kann VSS innerhalb von Windows-Workloads ausgelöst oder die Verarbeitung des Transaktionsprotokolls angestoßen werden.
Während der Sicherung läuft die VM weiter und ohne Verwendung von BfSS landet jeder Schreibzugriff in der Deltadatei des Snapshots. Solange eine VM während des Veeam-Backups nicht sehr viele Änderungen erzeugt, ist dies problemlos. Aber bei großen VMs oder VMs, die mit vielen Änderungen während des Backuplaufs zu kämpfen haben, können Probleme auftreten. Die Deltadateien eines Snapshots werden dann groß und das lösen des Snapshots nach dem Backup kann Minuten oder sogar Stunden dauern. Während dieses “Snapshot-Commit” leidet dar Cluster unter einer verminderten Leistung des Speichersystems. Grund sind die zusätzlichen IOPS die durch den Vorgang erzeugt werden. Im schlimmsten Fall leidet die VM dabei unter einem so genannten “Stun”. Dabei sind dann das Betriebssystem und die darin enthaltene Anwendung für einige Sekunden nicht mehr funktional. Benutzer verlieren den Zugriff auf ihre Server-Anwendungen. Die Netzwerkkonnektivität zur VM kann für einige Zeit verloren gehen.
BfSS ist die Lösung für dieses Szenario. Durch einfaches Aktivieren in den Job-Einstellungen löst Veeam einen Snapshot innerhalb des Speichersystems mit seiner eigenen Snapshot-Technologie aus, direkt nachdem der VMWARE-Snapshot vorliegt. Damit wird der VMWARE-Snapshot mit seinem definierten Zustand für die VM(s) für das Backup konserviert. Wenn der Storage-Snapshot vorhanden ist, können wir den VMWARE-Snapshot sofort “committen”, da wir ihn nicht mehr benötigen.
(Quelle: https://www.veeam.com/blog/datacore-sansymphony-plugin.html)
Da der VMWARE-Snapshot im Fall der BfSS eine viel kürzere Lebensdauer hatte, kann er in den meisten Fällen wesentlich schneller und ohne Probleme aufgelöst werden. Er enthält viel weniger Änderungen im Vegleich zur klassischen Variante ohne BfSS.
Was macht Storage-Snapshots gegenüber VMWARE-Snapshots für Backups überlegen?
Warum dauert es im Vergleich zu einem VMWARE-Snapshot viel weniger Zeit, einen Speicher-Snapshot loszuwerden? Selbst dann, wenn er sehr viele Änderungen enthält?
Die Antwort ist, dass übliche Enterprise-Speichersysteme im Vergleich zu einem VMWARE-Snapshot über eine “invertierte” Snapshot-Methode verfügen. Bei der VMWARE-Methode wird jede Änderung in eine separate Deltadatei geschrieben, die anschließend beim Löschen des Snapshots aufwendig wieder in die Hauptdaten eingemischt werden muss. Daher spricht man auch eher von einem “Commit” des Snapshots als von einer Löschung. Speichersysteme hingegen machen ein “copy-on-first-write” auf gesnappte LUNs. Das bedeutet, dass sie immer direkt in den Hauptdatensatz schreiben, aber den alten Zustand eines Blocks in einen Änderungspuffer kopieren, bevor sie ihn überschreiben. Das Löschen eines Snapshots bedeutet jetzt nur noch das Verwerfen des Änderungspuffers. Der Hauptdatensatz enthält bereits die aktuellste Version. Es findet kein Commit statt – der Snapshot wird tatsächlich einfach gelöscht.
Automatisches Mounten der DataCore-Snapshot(s) an den Veeam-Proxy
Es gibt auch einen großen Unterschied in Bezug auf den Veeam Proxy, der für die Sicherung verwendet wird. Wenn Sie mit Ihren Proxies bereits Legacy (nicht BfSS) Direct-Storage-Access-Backups durchführen, unabhängig davon, ob FC oder iSCSI verwendet wird, müssen Sie Ihre produktiven LUNs zuvor permanent an Ihre Proxies mounten. Ihr Veeam-Proxy muss die LUNs die ganze Zeit “sehen”, um die Daten der VMs während des Backups abrufen zu können.
Im Kombination mit BfSS holen wir keine Daten mehr von den produktiven VMFS-LUNs ab. Vielmehr müssen wir uns Zugriff auf den Speicher-Snapshot verschaffen, der speziell für das Backup generiert wurde und vorher nicht vorhanden war. In diesem Fall muss sich Veeam also darum kümmern, diesen Snapshot in den Proxy einzubinden und ihn nach Beendigung des Backups und vor dem Löschen des Speicher-Snapshots wieder zu entfernen. Daher zeigt die Plattenverwaltung Ihres Windows-Proxy-Servers während eines Backups nur zusätzliche “unbekannte” VMFS-LUNs an und nicht die ganze Zeit. Sie müssen natürlich trotzdem sicherstellen, dass ein Mounten eines Snapshots generell möglich ist. So müssen z.B. FC-Verbindungen und Zonierung im Vorfeld sichergestellt werden.
Aktivieren von BfSS und Einstellen der Optionen pro Job
BfSS wird durch ein einzelnes Kontrollkästchen im Menü “Integration” der erweiterten Speichereinstellungen für Jobs aktiviert.
Mit zwei zusätzlichen Optionen kann der Prozess weiter verfeinert werden. Schauen wir uns die Details hinter diesen Optionen an.
Ein Storage-Snapshot trägt im Gegensatz zu einem VMWARE-Snapshot nicht nur eine einzelne VM, sondern immer alle VMs, die einen Footprint auf der gesnappten LUN haben. Daher können und sollten wir mehr als eine einzelne VM in jeden Storage-Snapshot aufnehmen, um den gesamten Prozess zu beschleunigen. Es ist jedoch ratsam, nicht zu viele VMs mit einem VMWARE-Snapshot zur gleichen Zeit zu haben. Daher können wir die Anzahl der VMs, die mit einem einzigen Storage-Snapshot gesichert werden, begrenzen. Wenn Sie mehr VMs im Job haben als die gewählte Anzahl, fügt Veeam die gewählte Anzahl von VMs zu einem einzigen Storage-Snapshot hinzu. Nachdem diese VMs vollständig gesichert sind, wird der Speicher-Snapshot gelöscht und die nächste Gruppe von VMs wird für den nächsten Speicher-Snapshot in ihrer Gruppe VMWARE-gesichert.
Die einzige Besonderheit, die Sie im Ergebnis sehen werden, ist, dass der Zeitpunkt des Backups alias VMWARE-Snapshot für einen Satz von VMs sehr nahe beieinander liegt und dann eine Lücke zum nächsten Satz entsteht.
Mit “Failover to standard backup” können Sie Veeam anweisen, die VMs im Job trotzdem zu sichern, selbst wenn der Speicher-Snapshot-Prozess fehlschlägt oder die LUNs nicht ordnungsgemäß gemountet werden. Dieses Failover könnte immer noch ein Direct-Storage-Access-Backup sein – nur eben ohne BfSS – vorausgesetzt, Sie haben die produktiven LUNs ebenfalls dauerhaft auf den Proxy gemappt. Andernfalls würden Sie auf einen anderen Modus (Hot-Add oder NBD) zurückfallen, was sich vermutlich negativ auf die Backup-Performance auswirkt.
Warum BfSS nicht schneller und nicht immer besser ist als der direkte Speicherzugriff allein, aber warum ich es trotzdem toll finde
Ein weit verbreiteter Irrglaube in Bezug auf BfSS ist, dass das Backup schneller ist als mit Direct-Storage-Access. Dies ist nicht der Fall, da der Datenpfad in beiden Fällen derselbe ist. Der einzige Unterschied besteht in der kürzeren Lebensdauer des VMWARE-Snapshots und den geringeren Auswirkungen auf Ihre Produktionsauslastungen. Ihre Backup-Fenster bleiben gleich.
Jobs mit vielen kleinen VMs mit sehr wenigen Änderungen könnten sich mit BfSS sogar negativ auf die Gesamtlaufzeit auswirken. Das Zusammenfassen von VMWARE-Snapshots und dem zusätzlichen Speicher-Snapshot bringt zusätzlichen Overhead mit sich, der nur bei bestimmten Arbeitslasten gerechtfertigt werden kann. Meiner Erfahrung nach benötigt ein durchschnittlicher Kunde am Ende etwa 10 % der Workloads in BfSS-Jobs, während der Rest in älteren Direct-Storage-Access-Jobs verbleibt.
In dem in den Screenshots gezeigten Beispiel können Sie sehen, wie drei VMs zusammen in einem einzigen Speicher-Snapshot gesichert werden.
Viele VMs in einem einzigen Speicher-Snapshot
Bevor der Storage-Snapshot erstellt wird, muss jede VM einzeln mit einem VMWARE-Snapshot fixiert werden. Wenn alle drei ihren Snapshot fertig haben, wird der Storage-Snapshot erstellt, und die VMWARE-Snapshots werden sofort wieder committed. Die Lebensdauer des VMWARE-Snapshots beträgt in unserem Beispiel für den Server “Themis”, einem Microsoft Exchange Server, nur 8 Sekunden. Der Commit des Snapshots dauert nur 4 Sekunden. Hier sollten keine Auswirkungen auf die Benutzer zu erwarten sein.
Ohne BfSS leidet dasselbe System unter Snapshot-Commit-Zeiten von etwa 60 Sekunden. Ich habe schon Snapshot-Commit-Zeiten nach einem regulären Veeam-Backup von sehr großen und aktiven Exchange-Datenbankservern mit mehr als 2.000 Benutzern von mehr als 10 Minuten gesehen. Diese würden in hohem Maße vom BfSS profitieren.