Die Veeam Availability Suite v9, die noch in diesem Jahr auf den Markt kommt, bietet neben zahlreichen neuen und spannenden Features auch zusätzliche Erweiterungen für Enterprise-Umgebungen. Solche Umgebungen zeichnen sich in der Regel durch zwei typische Herausforderungen aus, die es zu bewältigen gilt: die Skalierbarkeit und das Management von mehreren entfernten Standorten und Außenstellen (ROBO).
Zu den leistungsstarken Funktionen unserer Software gehört unter anderem die Interaktion mit dem Gastbetriebssystem der gesicherten virtuellen Maschinen, die eine effektive Sicherung und Wiederherstellung ermöglicht. Die Lösung arbeitet vollständig ohne Agenten. Bei Backup-Jobs kommt stattdessen auf allen virtuellen Maschinen mit „Application Aware Image Processing“ ein temporärer Runtime-Prozess zum Einsatz. Dieser Prozess übernimmt die Orchestrierung der VSS-Verarbeitung, die Ausführung anwendungsspezifischer Backup-Schritte wie die Truncation von Protokollen und die Indizierung des Gastdateisystems.
In bisherigen Versionen erfolgte die gesamte Interaktion mit den Gastsystemen über den Backup-Server. Dabei implementierte die zentrale Backup-Management-Konsole den Prozess für diese Interaktion direkt auf allen gesicherten VMs (entweder über das Netzwerk direkt im Gastbetriebssystem oder bei Gastsystemen in nicht verbundenen Netzwerken mittels VIX API über eine Hostverbindung). Zwar hat diese Vorgehensweise stets hervorragend funktioniert, doch mit zunehmender Größe und Komplexität der gesicherten Umgebungen wurden zwei Einschränkungen offensichtlich.
Zum einen die mangelnde Skalierbarkeit: Das Management der Gastprozesse erfolgt auf dem Backup-Server. Aufgrund der deutlichen Zunahme an gesicherten VMs in einer typischen Kundenumgebung entwickelten sich die Ressourcen auf dem Backup-Server immer mehr zum Engpass. Dadurch wurde die Anzahl der gleichzeitig möglichen Interaktionen mit Gastsystemen beschränkt, weil zu viele gleichzeitige Interaktionen zu einem Timeout von Jobs führen können.
Die zweite Einschränkung hängt in gewisser Weise mit der ersten zusammen. Größere Unternehmen verfügen meist auch über mehrere Außenstellen mit lokalen virtualisierten Umgebungen für die Mitarbeiter vor Ort. In solchen Szenarios wird der VBR-Server in der Regel in der Zentrale bereitgestellt und die Interaktion mit Gastsystemen muss über eine – oft langsame – WAN-Verbindung erfolgen.
Selbst wenn ein Remote-Proxy und ein Remote-Repository in der Außenstelle dafür sorgen, dass der Datenverkehr für Backup und Wiederherstellung über das lokale Netzwerk läuft, muss der Datenverkehr für die Interaktion mit den Gastsystemen dennoch über das WAN geleitet werden. Dies führt in solchen Umgebungen zu den oben genannten Problemen infolge einer mangelnden Skalierbarkeit.
Zur Verbesserung der Performance wird in v9 ein Proxy für die Interaktion mit dem Gastsystem bereitgestellt. Diese virtuelle Rolle kann jedem gemanagten Windows-Server zugewiesen werden (einschließlich der bereits vorhandenen Proxy- und Repository-Server). Der Remote-Backup-Proxy in einer Außenstelle eignet sich in der Regel hervorragend für diese Aufgabe, da er die geringste Entfernung zu den gesicherten virtuellen Maschinen hat.
Sobald ein Proxy für die Interaktion mit Gastsystemen eingerichtet ist, sendet der Backup-Server nur noch Steuerbefehle über die WAN-Verbindung. Der Prozess für die Interaktion mit Gastsystemen wird vom „lokalen“ Proxy auf die VMs geladen. Dadurch wird der Verkehr über die langsame Verbindung deutlich reduziert und folglich auch die Last auf dem VBR-Server verringert. Und da ein einzelner Backup-Server mehrere Proxies für die Interaktion mit Gastsystemen steuern kann, verbessert sich die Skalierbarkeit erheblich. Als Beispiel soll uns hier ein Unternehmen mit 500 externen Standorten dienen. Dieses Unternehmen kann nun den Backup-Proxy an jedem Standort so konfigurieren, dass er auch als Proxy für die Interaktion mit Gastsystemen fungiert und dabei vom zentralen Backup-Server gesteuert wird. Natürlich können in einem großen Rechenzentrum auch mehrere Proxies für die Interaktion mit Gastsystemen eingerichtet werden, um die Performance und Skalierbarkeit weiter zu verbessern.
Diese Funktion bietet noch einen weiteren Vorteil, der auf den ersten Blick nicht ersichtlich ist: Sie ermöglicht den Zugriff auf das Gastbetriebssystem, wenn die netzwerklose Verarbeitung über VIX nicht möglich ist – beispielsweise dann, wenn aus Sicherheitsgründen kein Benutzerkonto mit umfangreichen Rechten für die Interaktion mit Gastsystemen bereitgestellt werden kann. Grundsätzlich können Sie nun sowohl einen Windows-Rechner mit unterschiedlichen Netzwerkkarten im Produktiv- als auch im Backup-Netzwerk als Proxy für die Interaktion mit Gastsystemen konfigurieren, der die Kommunikation vom Backup-Netzwerk an das Produktivnetzwerk „weiterleitet“.
Wie immer sind Backups jedoch nur die halbe Miete. Wenn die Daten sicher in einem Repository gespeichert sind, müssen sie von dort unter Umständen für eine Wiederherstellung abgerufen werden. Auch hier gilt für unser Szenario eines Unternehmens mit Außenstellen, dass die Wiederherstellung auf Dateiebene über den zentralen Backup-Server erfolgen muss, auf dem die Backup-Dateien direkt gemountet werden.
Selbst wenn sich das Backup-Repository innerhalb der virtualisierten Umgebung der Außenstelle befindet, müssen die Daten während der direkten Wiederherstellung zweimal über die langsame WAN-Verbindung übertragen werden – zuerst beim Abruf vom Backup-Server und dann erneut bei der Übertragung an die virtuelle Maschine in der Außenstelle. Zur Umgehung dieses Problems wurde bislang häufig der Assistent Multi-OS File Level Restore (FLR) verwendet, mit dem eine FLR-Hilfs-Appliance in der Umgebung der Außenstelle gestartet wurde. Diese Methode ist jedoch ebenfalls mit gewissen Nachteilen verbunden.
v9 schafft hier Abhilfe mit einer neuen Einstellung, die das Bereitstellen eines Mount-Servers für jedes Backup-Repository ermöglicht. Im Wesentlichen lässt sich damit jeder mit Veeam gemanagte Windows-Server als FLR-Bereitstellungspunkt für Veeam-Backups konfigurieren. Und natürlich ist es die ideale Lösung, wenn ein bereits vorhandenes Windows-basiertes Repository in einer Außenstelle auch als Mount-Host verwendet werden kann!
Dank dieser neuen virtuellen Rolle sendet der zentrale VBR-Server nun nur noch Steuerbefehle über die WAN-Verbindung, während das Remote-Backup von dem „lokalen“ Mount-Server als Grundlage für die direkte Wiederherstellung der erforderlichen Dateien der virtuellen Maschine bereitgestellt wird. Die gesamte Datenübertragung erfolgt damit innerhalb der Umgebung der Außenstelle.
Eine weitere wichtige Neuerung in diesem Zusammenhang ist die eigenständige Konsole von v9. Ja, Sie haben richtig gelesen: Endlich gibt es die lang ersehnte Veeam Backup & Replication-Konsole, die Veeam-Administratoren separat vom Backup-Server beispielsweise auf ihrer Workstation installieren können und die das Remote-Management des Backup-Servers über das Netzwerk ermöglicht. Nie wieder RDP-Sitzungen oder frustrierte Anwender, die sich beim gleichzeitigen Zugriff auf den Backup-Server gegenseitig behindern – nun kann jeder Anwender und Administrator seine eigene Konsole installieren. Das Interessante an dieser Konsole ist, dass sie in komplexen Wiederherstellungsszenarios auch die Rolle des Mount-Servers übernehmen kann, beispielsweise wenn Backups lokal bereitgestellt werden müssen (etwa für die Veeam Explorer). Diese Funktion ist in ROBO-Szenarios äußerst hilfreich.
Doch das ist noch längst nicht alles! Wie Sie bereits in v8 feststellen konnten, ist es unser erklärtes Ziel, für Unternehmen aller Größen die beste Bandunterstützung auf dem Markt zu bieten. In v9 gibt es deshalb zahlreiche Erweiterungen zur Unterstützung der Bandsicherung, auf die unsere Enterprise-Kunden schon lange gewartet haben. Ich werde hier nur die wichtigsten dieser Erweiterungen vorstellen, kann Ihnen jedoch versichern, dass es noch viele weitere Verbesserungen gibt!
Die in meinen Augen wichtigste Erweiterung ist die Möglichkeit, einen Medienpool zu erstellen, der nicht an eine einzelne physische Bibliothek gebunden ist, sondern mehrere Bibliotheken umfassen kann. Dieser „globale Medienpool“ dient als Hauptziel für Bandsicherungs-Jobs und ermöglicht sowohl eine bessere Performance als auch ein einfacheres Management.
Wird einem Bandsicherungs-Job ein solcher globaler Medienpool zugewiesen, kann der Job in der für das Failover festgelegten Reihenfolge auf mehrere Bibliotheken oder eigenständige Laufwerke zugreifen und bei einem Failover-Ereignis eine der verfügbaren Bibliotheken nutzen. Ein solches Ereignis tritt beispielsweise ein, wenn in einer Bibliothek keine freien Medien mehr vorhanden oder alle Bandlaufwerke belegt sind. Mit einem globalen Medienpool kann der Bandsicherungs-Job zu einer anderen Bibliothek wechseln, in der freie Medien oder Bandlaufwerke verfügbar sind.
v9 hält noch weitere interessante Features parat, die eine höhere Performance bei der Bandsicherung ermöglichen. Unter anderem wird nun endlich die lang ersehnte Parallelverarbeitung zwischen mehreren Bandlaufwerken unterstützt. Früher mussten hierfür mehrere Medienpools und Bandsicherungs-Jobs eingerichtet werden, was die Komplexität zusätzlich erhöhte. Mit v9 wird die Parallelverarbeitung nun direkt unterstützt!
Mit dieser einfachen, aber dennoch leistungsstarken Option können Sie Bandsicherungs-Jobs, denen derselbe Medienpool zugewiesen ist, gleichzeitig ausführen oder die Archivierung der Quell-Backup-Dateien auf mehrere Laufwerke verteilen.
Eine wichtige Neuerung gibt es auch bei der Rotation von Bandmedien. Sicher werden viele von Ihnen hocherfreut sein, dass es in v9 eine neue Art von Medienpool gibt: einen speziellen GFS-Medienpool für vollständige Backups. Zwar konnte auch hier in v8 durch den Einsatz mehrerer Medienpools im Wesentlichen dasselbe Ergebnis erzielt werden, doch v9 macht die Sache nun wesentlich einfacher, da das damit verbundene komplexe Management entfällt.
Vielleicht kennen Sie den GFS-Rotationsmechanismus (Grandfather-Father-Son, Großvater-Vater-Sohn) für Backup-Copy-Jobs bereits aus v8 – v9 verwendet dasselbe Konzept, das relativ einfach zu verstehen ist. Wenn für einen Backup-auf-Band-Job der GFS-Medienpool als Ziel für ein vollständiges Backup ausgewählt wird, werden die entsprechenden Bänder gemäß den Aufbewahrungsrichtlinien für eine bestimmte Anzahl von Wochen, Monaten, Quartalen oder auch Jahren aufbewahrt.
Mit einem GFS-Medienpool werden für eine längere Aufbewahrung weniger Bänder benötigt. Für ein GFS-Rotationsschema, mit dem vollständige Backups vier Jahre lang aufbewahrt werden sollen, werden beispielsweise nur 19 Bänder benötigt: 4 für die wöchentliche Sicherung, 12 für die monatliche Sicherung und 3 für die jährliche Sicherung. Für die kurzfristige Aufbewahrung vollständiger Backups und für inkrementelle Backups können nach wie vor einfache Medienpools genutzt werden. Sie können somit den Medienpool wählen, der für Ihr gewünschtes Datenaufbewahrungsszenario am besten geeignet ist.
Wie Sie allein in diesem Blogbeitrag feststellen konnten, hat die künftige v9 eine ganze Reihe wichtiger Erweiterungen zu bieten, die speziell auf die Bedürfnisse von großen Unternehmen zugeschnitten sind. Und dabei haben wir mit der Vorstellung dieser Erweiterungen gerade erst begonnen – das spannendste Feature von v9 für große Unternehmen verraten wir erst später. Ich hoffe, dass diese Vorschau Ihnen gezeigt hat, dass wir die Wünsche unserer Enterprise-Kunden sehr ernst nehmen und unablässig an der Weiterentwicklung unserer Produkte arbeiten, damit diese die Anforderungen von Unternehmen zu 100 % unterstützen und durch einfache Skalierung auch in wachsenden Umgebungen eine kontinuierliche Availability ermöglichen.
