Für ein Veeam Projekt mit den Anforderungen an permanente optimale Performance der VMware vSphere und Storage Infrastruktur habe ich mich auf die Suche nach der effizientesten Möglichkeit des Veeam Backups gemacht. Schnell hat sich bei meinen Tests herausgestellt, dass das Veeam NetApp Backup from Storage Snapshot das beste Verfahren ist um die Anforderungen zu erfüllen.
Was bedeutet in diesem Kontext effizient:
- Geringster Einfluss auf die Produktionsumgebung
- Zusätzliche Kosten dabei jedoch vermeiden
Rahmenbedingungen der Infrastruktur:
- VMware vSphere 6.5
- NFS Datastores
- NetApp ONTAP 9
- Veeam Backup & Replication 9.5
- Komplett entkoppeltes NFS Netzwerk
Effizientes Veeam NetApp Backup from Storage Snapshot Design
Dem NetApp and Veeam Backup & Replication 9.5: Configuration Guide and Best Practices von Stefan Renner lassen sich bereits sehr viele mögliche Aufbauten eines hoch effizienten NetApp Backups mit Veeam entnehmen. Die Premium Lösung ist dabei natürlich die NetApp Integration von SnapMirror / SnapVault und der Sicherung vom Secondary Storage. Mit diesem Verfahren wird definitiv die Produktionsumgebung am geringsten belastet aber leider auch zusätzliche Kosten durch ein weiteres NetApp Cluster und natürlich die Mehrdaten auf der Secondary Site verursacht. Daher muss mein Design leider ohne SnapMirror / SnapVault auskommen, soll aber dennoch möglichst effizient sein.
Zusätzlich zu den ohnehin vorhandenen Netzen LAN und NFS setzt dieser Aufbau ein weiteres Netzwerk für das Backup voraus. Über das Backup Netzwerk sollen dann die Daten vom Backup Proxy per Direct Storage Access abgezogen werden.
Damit das Design so auch Sinn macht müssen natürlich für Backup, NFS und LAN auch dedizierte Interfaces verwendet werden. Die SVM auf der die VMware Datastores liegen hat also ein Interface im Backup und eines im NFS Netzwerk.
Ablauf Veeam NetApp Backup from Storage Snapshot:
- Veeam veranlasst Erstellung VMware VM Snapshot, wenn notwendig
- Veeam veranlasst Erstellung NetApp Volume Snapshot
- Veeam veranlasst Löschen VMware VM Snapshot, wenn notwendig
- NetApp stellt Read-Only Zugriff für NetApp Volume Snapshot bereit
- Veeam Proxy sichert NetApp Snapshot Daten mit dem eignen NFS Client
- Veeam veranlasst Löschung NetApp Volume Snapshot
Wie man dem Ablauf entnehmen kann, bleibt der VMware VM Snapshot nur sehr kurz vorhanden im Vergleich zu dem Hot-Add oder Netzwerk Transfer Modus. Dadurch wird natürlich die Dauer des Snapshot Konsolidierung enorm verkürzt. Verbunden mit dem Transfer über das Dedizierte Backup Interface wird somit die Beeinflussung der Produktionsumgebung auf ein Minimum reduziert, es bleibt nur noch die Last auf dem Filer selbst.
Nachteil dieses Konzepts:
- Restore wird per Network Mode durchgeführt
- Wenn eine VM einen SnapShot hat wird das Backup per Network Mode durchgeführt
Man könnte durch zusätzliche Backup Proxys für Virtual Appliance Mode den Traffic durch die Firewall im Falle eines Fallback z.B. wegen eines VM SnapShot reduzieren. Dafür müssten die weiteren Backup Proxys zwar im Backup Netz angebunden sein aber auf der gleichen vSphere Plattform wie die zu sichernden VMs laufen.
Der Restore wird aber trotz des zusätzlichen Fallback Proxy im Network Mode durchgeführt. Der (aktuell) einzige Weg das zu umgehen ist, den Direct NFS Proxy direkt im NFS Netzwerk zu platzieren.
Veeam NetApp Backup from Storage Snapshot Konfiguration
Für dieses Backup Verfahrens müssen wir drei Komponenten betrachten, die NetApp SVM Konfiguration, das Veeam Setup und den vSphere Aufbau.
NetApp SVM Konfiguration
Die NetApp SVM muss für den Zweck der VMware NFS Datastore Bereitstellung nur ein Interface in dem NFS Netzwerk haben. Um das aufgezeigte Konzept umzusetzen muss ein weiteres hinzugefügt werden.
Das Interface svm-nfs_data stellt in dem Testaufbau das NFS Netzwerk dar und svm-nfs_backup somit das Backup Netzwerk. Die beiden Interfaces haben auch, wie eingangs erwähnt, getrennte Ethernet Ports. Damit der ESXi-Zugriff ebenso wie das Read-Only Backup funktionieren muss eine Export-Policy für beide Netze (hier einzelne Hosts) erstellt werden.
Veeam Setup
Der wichtigste Schritt, um die Storage Integration zu ermöglichen, ist die Einbindung des NetApp Clusters. Die Management Kommunikation läuft hier zwischen Veeam Backup & Replication Server und Cluster IP ab. Der Direct NFS Proxy kommt also noch nicht in Spiel, auch wenn er in der Konfiguration von mir schon angegeben wird damit der Scan der Volumes bereits darüber läuft.
Es wäre auch ohne Probleme möglich die benötigten Export-Rules automatisch erzeugen zu lassen. Ich habe diese aber bereits vorab erzeugt.
Als kleine Optimierung schließe ich noch alle Root-Volumes vom Scan aus.
Mit dem Veeam PowerShell SnapIn lassen sich noch ein paar mehr Details abfragen:
PS C:\> (Get-NetAppHost).NaOptions
ConnectionOptions : Veeam.Backup.SanPlugin.NetApp.CDomNaHostConnectionOptions
DomContainer : Veeam.Backup.Common.CDomContainer
HostType : NaCluster
IsMetroClusterEnabled : False
MetroClusterPartner :
IsMetroClusterAlive : False
IsHAPairEnabled : False
VolumesRescanMode : ExceptExcluded
SelectedSanProtocols : NFS
CreateNfsExportRulesAutomatically : False
IsRescanProxyAutoSelect : False
HAPairPartner :
IsNeedToShowRetentionForSnapMirror : False
License : FlexClone, SnapRestore, Fcp, Iscsi, Nfs, SnapVaultPrimary, SnapVaultSecondary,
SnapMirror
IsVFilerLicensed : False
IsFlexCloneLicensed : True
IsSnapRestoreLicensed : True
IsFcpLicensed : True
IsIscsiLicensed : True
IsNfsLicensed : True
IsSnapVaultPrimary : True
IsSnapVaultSecondary : True
IsSnapMirror : True
IsHAPairLicensed : False
Speziell die vorhandenen Lizenzen sind sehr interessant. Diese sagen eventuell etwas über den Restore-Prozess aus, dazu ist aber ebenfalls mehr im NetApp and Veeam Backup & Replication 9.5: Configuration Guide and Best Practices von Stefan Renner zu finden.
Die nächste Komponente auf der Liste ist der Direct NFS Proxy. Dieser hat im Gegensatz zu einem Hot-Add Proxy keine direkte Abhängigkeit zu den zu sichernden VMs. Kann also damit auch in einem Komplett anderen vCenter oder gar physikalisch laufen.
Die Festlegung des Preferred Backup Network ist optional in dem hier aufgezeigten Aufbau. Wichtig wäre diese Einstellung dann, wenn der Proxy oder mehrere Proxies über unterschiedliche Netze auf die SVM zugreifen könnten
Zusätzlich hatte ich einen weiteren Hot-Add Proxy für einen Fallback für den Fall, dass ein VM Snapshot vor dem Backup vorhanden ist erwähnt.
PS C:\> (Get-VBRViProxy -Name Veeam-02.lab.local).Options TransportMode : San FailoverToNetwork : True UseSsl : False IsAutoVddkMode : True IsAutoDetectDisks : False MaxTasksCount : 2 IsAutoDetectAffinityRepositories : True PS C:\> (Get-VBRViProxy -Name Veeam-03.lab.local).Options TransportMode : HotAdd FailoverToNetwork : True UseSsl : False IsAutoVddkMode : True IsAutoDetectDisks : True MaxTasksCount : 1 IsAutoDetectAffinityRepositories : True
Zu guter letzt muss natürlich auch in den Backup Jobs die Storage Integration aktiviert sein um alle Vorteile dieses Verfahrens auszunutzen.
Ist diese Option nicht aktiviert aber der Aufbau dennoch so, dass ein Veeam NetApp Backup from Storage Snapshot möglich wäre, wird ohne einen Storage Snapshot der Abzug der Daten über den NetApp Filer per NFS erfolgen (Vielen Dank noch mal für die Klarstellung an Niels Engelen!).
Log Eintrag ohne Storage Integration:
Using backup proxy Veeam-02.lab.local for disk Festplatte 1 [nfs]
Log Eintrag mit Storage Integration:
Using backup proxy Veeam-02.lab.local for retrieving Festplatte 1 data from storage snapshot
vSphere Aufbau
Der vSphere Aufbau ist für meinen Test mehr als minimalistisch. Es handelt sich um einen einzelnen ESXi Host mit einem NetApp NFS 3 Datastore. Auf diesem Host läuft neben den Test VMs noch der erwähnte Hot-Add Proxy.
Aber auch im produktiven Umfeld müsste man einen gängigen vSphere Aufbau im Normalfall nicht anpassen um das Veeam NetApp Backup from Storage Snapshot zu nutzen. Für alle Details zu einem VMware NFS Aufbau mit NetApp kann ich den NetApp TR-4597 – VMware vSphere with ONTAP sehr empfehlen
No Responses