3

Die Nutzung von Veeam Backup & Replication zur Sicherung einer sehr großen Hyper-V Umgebung

Ich bin aktuell in einem Projekt involviert, in dem es um die Gestaltung einer Backup-Infrastruktur mit Veeam Backup & Replication in der aktuellen Version 9 geht. Da es sich um eine ziemlich große Umgebung mit einer großen Anzahl an Hyper-V Hosts handelt möchte ich an dieser Stelle einmal beschreiben, mit welchen Herausforderungen man konfrontiert wird und wie die Wahl der Backup-Software dies beeinflusst.

Daten zur Umgebung

In dem Projekt gibt es ca. 600 Hyper-V Hosts, die mit Hyper-V ausgestattet sind. Die Server haben unterschiedliche Leistungsdaten und unterschiedliche Betriebssysteme. Aktuell ist Hyper-V unter Windows Server 2008 R2 und Windows Server 2012 R2 im Einsatz.

Diese knapp 600 Hosts betreiben in Summe etwas über 8.000 VMs. Diese 8.000 VMs besitzen knapp 12.000 Festplatten-Dateien, in denen die Daten der VMs gespeichert werden. In Summe werden knapp 700 TB an Speicherplatz belegt. Die Hyper-V Hosts sind zu einem Teil in mehreren Failover Clustern zusammengefasst, der andere Teil betreibt die VMs ohne eine Hochverfügbarkeit.

Die Umgebung ist aufgeteilt auf zwei Rechenzentren, um bei einem Ausfall von einem RZ immer noch verfügbar zu sein.

Grundsätzliche Überlegungen zur Planung der Backup-Infrastruktur

Bei der Gestaltung der Backup-Umgebung gibt es mehrere Dinge, die beachtet und in die Planung mit eingezogen werden müssen:

• Wie viele Server müssen gesichert werden?
• In welchem Zeitraum muss das Backup passieren?
• Wie sieht die Anbindung der Server untereinander und zum Backup Server aus?
• Wie oft soll gesichert werden?
• Wie lange sollen die Daten aufbewahrt werden?
• Sollen die Daten zusätzlich repliziert werden?
• Werden strategische Backup-Proxys benötigt, und wenn ja wie viele?
• Wie hoch ist das tägliche Delta der Daten?

Diese und noch weitere Fragen treten während der Planungsphase auf und sollten unbedingt beachtet werden. Zu einigen Punkten kann man meist direkt Aussagen treffen, andere lassen sich nicht oder nur schwer abschätzen. Aber nun mal vor vorne.

Anforderungen des Kunden

Von Seiten des Kunden gibt es die folgenden Anforderungen.

Backup-Zeitfenster

Das Backup der Umgebung soll abends gegen 20 Uhr starten, das Zeitfenster sollte die acht Stunden nicht überschreiten.

Aufbewahrungszeitraum

Die Daten der Sicherungen sollen sieben Tage lang auf dem Platten-Speicher aufbewahrt werden. Für Dateien, die nach diesem Zeitraum benötigt werden, muss auf eine Bandsicherung zurückgegriffen werden.

Redundanz

Damit die Backup-Daten auch bei dem kompletten Ausfall von einem RZ zur Verfügung stehen, werden die Daten jeweils auf die andere Seite übertragen. Dies bedeutet, dass beide Rechenzentren jeweils alle Daten in ihrem Backup gespeichert haben.

 

Hilfe durch den Hersteller

Man könnte nun die aktuell verfügbaren Werte nehmen, in einen Taschenrechner oder eine Excel-Tabelle packen und schauen, ob vielleicht realistische Werte in Bezug auf die Speicherkapazität usw. heraus kommt. Man könnte allerdings auch einfach auf die Möglichkeiten zurückgreifen, die Veeam selbst anbietet.

Restore Point Simulator

Das erste Tool, welches sehr hilfreich ist, ist der Restore Point Simulator, kurz RPS. Dieser ist auf der folgenden Seite zu finden: http://rps.dewin.me/

Im oberen Bereich müssen wir als erstes angeben, in welchem Modus wir arbeiten möchten.

In diesem Fall wählen wir “Reverse Incremental”. Dies bedeutet, dass das letzte Backup immer als volle Datei auf die Platte geschrieben wird und die Änderungen in die Vergangenheit dann in eigene Dateien ausgelagert werden. Vorteil dieser Technik ist, dass das letzte Backup immer als volle Datei besteht und bei einem Restore aus dieser Datei immer eine Datei genutzt wird, nicht eine Kette an Dateien.

Nun müssten wir weitere Einstellungen konfigurieren, welche die Größe des Backups beeinflussen.

Die Größe des Backups ist hier mit 700TB angegeben, welche von der Seite automatisch in GB umgewandelt wird. Die Anzahl der Retention Points ist aktuell sieben, dieser Wert könnte bei Bedarf angepasst werden. Bei einem Backup täglich haben wir so ein Backup der letzten sieben Tage auf der Platte liegen. Die Change Rate der Umgebung wird mit 5% kalkuliert, dies ist bei solch einer großen Umgebung laut dem Hersteller häufig eine realistische Zahl. Die Komprimierung wird mit 50% angegeben, dies ist ein Wert, der laut Veeam und auch laut unserer Erfahrung fast immer übertroffen wird. Rechnen wir mit 50%, haben wir final noch Luft nach oben, z.B. bei der Anzahl der Retention Points. Das Backup-Intervall liegt bei täglich, und wir rechnen ein Wachstum über fünf Jahre von 3% mit ein. 3% klingt erst einmal wenig, sind bei 700 TB aber auch knapp 20 TB an Datenzuwachs. Dieser Wert könnte natürlich auch noch angepasst werden.

Nun können wir noch weitere “Full Backups” mit aufnehmen. Dies wird in unserem Fall nicht benötigt.

Als Ergebnis kommt nun der folgende Wert raus:

Dies bedeutet, dass der Backup-Speicherplatz trotz einer Aufbewahrungsdauer von sieben Tagen kleiner sein kann als die aktuellen Datenbestände groß sind.

Mit diesen Werten lässt sich nun spielen, es können größere Zeiträume berechnet werden, die Komprimierung kann angepasst werden usw. Der Rechner ist sehr gut gemacht, fragt viele relevante Daten ab und zeigt die vermutlich benötigte Größe an Speicherplatz an. Je genauer die Werte Ihrer Umgebung passen, desto näher sind Sie am aktuellen Bedarf. Leider ist es häufig so, dass das genaue Wachstum der Daten pro Jahr nicht bekannt ist und hier auf Erfahrungswerte von Veeam selbst zurückgegriffen werden muss.

Veeam Virtual Architect

Eine zweite sehr gute Hilfe ist der Veeam Virtual Architect. Dies ist ebenfalls eine Webseite, die man mit Daten füttern kann und die dann Werte zum Design der Umgebung auswirft. Der Architect ist unter dem folgenden Link zu finden: http://rps.dewin.me/VirtualArchitect/

Als erstes kommt direkt eine Warnung, dass es sich bei dem Rechner aktuell noch um eine Testversion handelt. Nach einem Klick auf die Warnung erwartet uns die erste Seite, die uns nach einigen Eckdaten fragt.

Hier können wir die 4000 VMs eintragen, die momentan in einem RZ vorhanden sind. Das Backup-Fenster liegt bei 8 Stunden, die VMs haben durchschnittlich 1,5 Festplatten-Dateien. Es wird eine zusätzliche Kopie geben (RZ-übergreifend auf die andere Seite) und aktuell sind noch keine Tape-Laufwerke verfügbar oder eingeplant.

Im nächsten Fenster können wir weitere Einstellungen vornehmen, die das Ergebnis beeinflussen.

In diesem Aufbau ist es geplant, dass wir nicht mit Veeam Proxy-Systemen arbeiten, sondern das wir ein On-Host-Backup fahren. Durch die große Menge an Hyper-V Hosts (ca. 300 pro RZ) stehen ausreichend CPU-Kapazitäten zur Verfügung, um die Last des Backups auf diese zu verteilen. Durchschnittlich werden 100 VMs pro Backup-Job gesichert, dieser Wert ist eine Konfiguration, die wahrscheinlich in fast jedem Setup anders ist. In Summe haben wir 20 Repositories, welche für die Annahme der Daten zur Verfügung stehen. Wir bedienen uns hier einer Neuerung in Version 9 der Backup-Software: Dem Scale-Out Repository. Hierbei wird über die einzelnen Repositories noch einmal eine weitere logische Schicht gelegt. Dies hat den Vorteil, dass alle Jobs nur mit einem einzigen Ziel arbeiten, dieses im Hintergrund aber problemlos erweitert oder verkleinert werden kann.

Wenn nun alle Einstellungen überprüft oder eingestellt wurden, kann die letzte Seite des Rechners aufgerufen werden.

Diese zeigt eine Übersicht über die benötigten Ressourcen für die einzelnen Veeam-Server. Wir sehen hier, dass der eigentliche Veeam Server (in dem die Logik steckt und auf dem Sie ihre Backup-Jobs konfigurieren usw.) 3 CPU-Kerne und 12 GB RAM benötigt. Der Datenbank-Server braucht etwas mehr an Leistung, hier werden Minimum 6 CPU-Kerne und 11 GB RAM fällig.

In Summe gibt es nun 66 Jobs, verteilt über die 302 Server. Es stehen somit 302 Cores zur Verfügung, und bei der Nutzung von 2 GB RAM pro Backup Proxy-Agent (der Agent auf den Hyper-V Hosts) sind insgesamt 604 GB RAM verfügbar.

Die unteren Werte in grün zeigen, ob diese Konfiguration noch im Rahmen liegt oder ob hier etwas angepasst werden muss. Da in unserem Fall alles grün ist, sollte man sich die Werte zwar nochmal anschauen und überlegen, ob sie im Rahmen liegt, grundsätzlich scheint hier aber erst einmal zu passen.

 

Die Backup-Infrastruktur

An diesem Punkt kommen wir zu dem Teil, von dem ich persönlich am meisten begeistert bin. Es geht hierbei um die Lösung, wie wir die folgenden Kriterien erfüllen können:

• Speicherung der Backup-Daten während dem Zeitfenster von acht Stunden
• Redundanz der Backup-Systeme
• Skalierbarkeit nach oben (und nach unten, was aber i.d.R. nie auftritt)
• Performance während einem Restore der Daten

Der Backup-Speicher

Laut unserer Rechnung benötigen wir für das gesamte Backup der Infrastruktur knapp 700 TB an Speicherplatz. Theoretisch wären dies somit knapp 350 TB pro RZ, allerdings wollen wir die Backup-Daten ja jeweils in das andere RZ bewegen, um im Desasterfall alle Daten in einem Standort zu haben.

Die von uns genutzte Lösung ist ein Scale-Out File Server an jedem Standort. Dies bietet uns in vielen Bereichen extrem gute und viele Möglichkeiten.

Die Hardware

Wir beginnen strategisch mit zwei Scale-Out File Server Knoten, die im Failover Cluster betrieben werden und die erste Stufe der Hochverfügbarkeit darstellen. Fällt ein System aus, kann der andere den gesamten Betrieb aufrecht erhalten. An dieser Stelle könnten wir sogar auf mehr als zwei Knoten gehen, wenn dies erforderlich ist. Drei Server z.B. bieten immer noch eine HA, wenn ein System zu Wartungszwecken nicht zur Verfügung steht.

An diesen Failover Cluster schließen wir nun vier JBODs mit einer Kapazität von 60 Datenträgern an. Drei wären natürlich auch möglich, allerdings können wir so beim Aufbau direkt die Datenträger über vier JBODs verteilen. Kommt es später zu einer Erweiterung der Datenträger, wären nicht alle neuen Datenträger im vierten Enclosure, welches dann erst hinzugefügt worden ist. In die Gehäuse kommen 6 TB große Nearline SAS Festplatten, die 8 TB Modelle sind aktuell noch zu teuer bei einem Vergleich von Preis pro GB. Aktuell sind maximal 80 Datenträger pro Pool empfohlen bei einer Gesamtsumme von vier Pools (Storage Spaces Frequently Asked Questions (FAQ): What are the recommended configuration limits?). Bei der Nutzung von Double Parity und zwei Hot Spare-Datenträgern pro Pool kommen wir somit auf die folgenden Mengen an Festplatten:

675 TB müssen zur Speicherung der Backup-Daten vorhanden sein. Mit ein bisschen Plus für Management (und weil es sich einfacher rechnen lässt) gehen wir von 700 TB Speicherplatz aus. 6 TB große Festplatten speichern ca. 5,52 TB netto, rechnen wir mit 5,5 TB.

700 TB Speicherplatz durch 5,5 TB Speicherplatz pro Festplatte ergeben 128 Festplatten. Bei einer Aufteilung auf vier Storage Pools wären dies 32 Festplatten pro Pool ohne Datensicherheit und Reserven. Zur Nutzung von Dual Parity werden pro Pool zwei weitere Datenträger benötigt, dazu kommen jeweils zwei weitere Hot Spare Datenträger. Dies wären 32 Festplatten zur Speicherung plus zwei für die Double Parity plus zwei Hot Spare Datenträger = 36 Festplatten pro Pool = 144 Festplatten in Summe.

Die Management Server

Die Veeam-Infrastruktur in Form von Management und Datenbank Server muss ebenfalls hochverfügbar betrieben werden. Aus diesem Grund wird pro RZ ein eigenes Hyper-V Failover Cluster aufgebaut, welches aus zwei Hardware Knoten besteht. Diese Server betreiben die gesamte Veeam-Infrastruktur virtuell. Dies hat den Vorteil, dass die Systeme bei Bedarf “mal eben” innerhalb des Failover Clusters geschwenkt werden können, falls eine Wartung der Hardware-Systeme ansteht. Zusätzlich ist so eine Sicherung der Management-Server möglich, diese werden dann über Kreuz aus dem anderen RZ abgeholt und gesichert. Alle Daten der VMs werden auf dem Scale-Out File Server gespeichert. Da dieser nur für Hyper-V und SQL Server Datenbanken zugelassen ist, müssen alle Veeam-Systeme virtuell laufen.

Weitere Optimierungen

Bei der Anbindung der Hyper-V Hosts an die Storage-Infrastruktur werden ausschließlich RDMA-Netzwerkkarten eingesetzt. Dies hat den Vorteil, dass die CPU-Belastung der Systeme sehr gering ist, da alles über die Netzwerkkarten selbst abgerechnet wird. Weiterhin können hier Bandbreiten von 40 Gb/s redundant gefahren werden, durch die Nutzung von SMB Multichannel ist zusätzlich eine Nutzung mehrerer Karten gleichzeitig möglich.

Die Umgebung als Skizze

Damit das hier geschriebene etwas besser greifbar wird, hier eine Skizze der Umgebung:

Die beiden Seiten links und rechts zeigen die beiden Rechenzentren, zwischen denen eine Replikation stattfindet.

Ein ganz großer Vorteil dieser Lösung ist die Skalierbarkeit nach oben. Wird mehr Speicherplatz benötigt, können weitere Festplatten hinzugefügt werden. Wird eine höhere Performance benötigt bei dem Speichern der Backup-Daten, können weitere virtuelle Repository-Server installiert und konfiguriert werden. Diese Server kosten keine weitere Veeam-Lizenz, da ausschließlich Hyper-V Hosts lizenziert werden müssen. Kommen Windows Server Lizenzen in der Datacenter Edition zum Einsatz, fallen hier ebenfalls keine weitere Lizenzkosten an. Wäre die Performance der Hyper-V Hosts im Management Cluster ausgereizt, könnten hier zusätzliche Hardware-Server angeschafft werden und zu dem bestehenden Failover Cluster hinzugefügt werden. Dies würde die maximale Menge an Arbeitsspeicher, CPU-Ressourcen und Netzwerk-Bandbreite weiter erhöhen.

Die Abbildung dieser Umgebung mit dem Data Protection Manager

In einem zweiten Projekt haben wir solch eine große Umgebung mit Hilfe des Data Protection Managers (DPM) gesichert. Hier steht ebenfalls ein Scale-Out File Server zur Verfügung, welcher knapp 900 TB an Brutto-Speicherplatz bereitstellt. Mehrere DPM-Server in virtueller Form werden genutzt, um innerhalb des definierten Zeitfensters die VM-Daten zu sichern. Das Verfahren ist gegenüber Veeam ähnlich, außer das bei der DPM-Variante der System Center Configuration Manager (SCCM) genutzt wird, um alle DPM-Server gemeinsam und über eine Konsole ansteuern zu können.

 

Wenn Sie bei dem Aufbau, der Planung oder der Erweiterung Ihrer Umgebung Unterstützung brauchen, stehen wir Ihnen gerne zur Verfügung. Rufen Sie uns an oder schreiben Sie uns eine Mail, wir stehen gerne zur Verfügung.