Virtualisierungsprojekte planen (2)

Es sollte gelebte Praxis sein, ein Virtualisierungsprojekt immer mit einer Planungsphase zu beginnen. Dabei werden die Anforderungen gesammelt und nach möglichen Lösungen Ausschau gehalten. Wir zeigen, welche Daten und Anforderungen in Sachen Hypervisor, VMs, Hardware und Backup notwendig dafür sind. Hier spielen technische Gegebenheiten ebenso eine Rolle wie organisatorische. Im zweiten Teil skizzieren wir, wie Sie Cluster-Server sowie Einzelsysteme planen und den Hypervisor festlegen oder wechseln.

Cluster-Server planen

Die Anzahl der Server, die zum Einsatz kommt, wird durch die gewünschte Redundanz beeinflusst. Für einen Failover-Cluster benötigen Sie als Minimum zwei Systeme. Zwei Server führen allerdings auch dazu, dass ein System komplett ohne Redundanz läuft, sobald sich das zweite System im Wartungsmodus befindet. Halten Sie sich an einen regelmäßigen Wartungsplan, ist dies mindestens einmal im Monat der Fall. Stürzt ein Hypervisor ab, während sich der zweite Server in einer geplanten Maintenance befindet, ist die gesamte Infrastruktur nicht verfügbar. Setzen Sie hingegen drei oder mehr Server ein, wird der Ausfall zeitnah durch das dritte System abgefangen.

Soll ein Failover-Cluster über mehr als einen Raum gespannt werden, ist dies ebenfalls bei der Anzahl der Hypervisoren zu berücksichtigen. Erst ab vier Systemen haben Sie sowohl über die Räume hinweg als auch innerhalb von jeweils einem Raum eine Redundanz. Dies wirkt sich aber auch preislich auf die Anzahl und Fähigkeiten der Netzwerk- und Storage-Komponenten aus und führt oft zu einer deutlichen Erhöhung der Kosten gegenüber dem Betrieb in einem Raum.

Beachten Sie beim Aufbau einer HA-Lösung an zwei Standorten, dass Sie in jedem Standort ebenfalls eine Redundanz in Bezug auf die Stromversorgung, das Netzwerk und die Storage-Anbindung einrichten. Bei den meisten Lösungen benötigen Sie zusätzlich noch einen dritten Standort, an dem das Quorum für die beiden anderen Standorte läuft. Dies ist bei einem Hyper-V-Failover-Cluster Pflicht, da es sonst zu massiven Problemen kommen kann.

Wird die gesamte Kommunikation zwischen den beiden Räumen getrennt (Stichwort Bagger), entscheidet das Quorum, welcher der beiden Standorte die Mehrheit bekommt und den Betrieb weiterführt. Haben Sie kein Quorum (oder das Quorum befindet sich in einem der beiden Standorte, was wir in der Praxis durchaus öfter beobachten), gehen entweder beide Räume offline oder beide Räume starten alle Systeme und Sie betreiben Ihre gesamte IT doppelt. Um dies zu vermeiden, brauchen Sie einen Partner, der die Fallstricke und Abhängigkeiten in solch einem Aufbau kennt und meistern kann.

Der Test eines solchen Aufbaus vor einer eigentlichen Inbetriebnahme ist auch sehr wichtig. Uns ist bei Unternehmen oft die Situation begegnet, in denen uns der HA-Aufbau stolz präsentiert und gezeigt wurde – fragten wir dann aber nach dem Ergebnis des Ausfalltests, war die häufige Antwort, dass das alles nie real getestet wurde. Dies führt dazu, dass die entsprechenden IT-Verantwortlichen annehmen, dass es problemlos weitergeht – ohne darüber wirkliche Gewissheit zu haben.

Ausprägung der Einzelsysteme planen

Kommen wir noch einmal kurz zurück auf die Anzahl und Ausstattung der eingesetzten Serversysteme. Hier geht es darum, einen guten Mittelwert zwischen Menge und Größe der Server zu finden. Der Kauf von vielen "kleinen" Systemen ist wirtschaftlich genauso unsinnig wie der Kauf von zwei voll ausgebauten Systemen. Bei voll ausgebauten Servern steigt der Preis teilweise exponentiell an (unter anderem wegen den sehr teuren RAM-Modulen in der maximalen Kapazität), weiterhin stehen bei einem Ausfall oder einer Wartung nur noch die Hälfte aller Ressourcen zur Verfügung.

Viele kleine Systeme hingegen sind vielleicht in der Anschaffung günstiger, verbrauchen aber auch mehr Strom, führen zu einem größeren Wartungsaufwand und benötigen mehr Lizenzen. Da die Systeme zum Teil auch nicht wirklich klein sind, müssen Sie je nach Größe der Räume auch den Platz berücksichtigen. Betreiben Sie die Systeme in einem professionellen Rechenzentrum an einem Internetknoten wie etwa Frankfurt, Düsseldorf oder Berlin, werden Sie hier in den meisten Fällen neben Strom und Internetanbindung auch noch die Fläche bezahlen, die Ihre Server nutzen.

Hypervisor festlegen oder wechseln

Während der Projektphase sollten Sie sich auch die Frage stellen, ob der aktuell genutzte Hypervisor noch die richtige Wahl ist oder ob es eventuell Alternativen gibt. Haben Sie im ersten Schritt die Zahlen und Anforderungen der aktuellen Infrastruktur gesammelt, können Sie nun schauen, welche Lösungen die für Sie richtig ist.

Wir möchten allerdings an dieser Stelle einen Wechsel des Hypervisors nicht als generelle Aufgabe oder Tätigkeit ins Spiel bringen. Wir haben viele Projekte begleitet, bei denen ein Update beziehungsweise Upgrade der bestehenden Lösung auf die aktuelle Version erfolgte. Dies ist bei jedem Hypervisor einfacher als die Migration auf ein anderes Produkt. Die genutzten VM-Formate bleiben größtenteils gleich, das Wissen über die Administration ist in vielen Fällen vollständig oder in großen Teilen vorhanden und es erfolgt keine harte Migration zu einem anderen Produkt.

Manchmal kann so ein Wechsel aber auch sinnvoll sein oder muss sogar erfolgen. Die vorhandene VM-Infrastruktur zu migrieren und gegebenenfalls zu konvertieren, ist natürlich dann erforderlich, wenn Unternehmen zum Beispiel aus Kostengründen von VMware nach Hyper-V migrieren.

Andere denkbare Situationen für einen Wechseln ist der Ersatz von Xen oder etwa der Betrieb von ausschließlich Linux-Systemen und damit die Migration zu einer KVM-Variante. Und nicht selten ist es schlicht und ergreifend auch eine politische Entscheidung, den Hypervisor zu wechseln.

Es gibt aber auch konkrete technische Gründe zu wechseln: So bietet Hyper-V beziehungsweise Microsoft mit SMB3 seit 2012 ein Protokoll, das auch im Jahr 2019 in puncto Performance, Bandbreite und einer extrem geringen CPU-Belastung absolut Spitzenreiter ist gegenüber den traditionellen Protokollen wie iSCSI, Fibre Channel oder SAS.

Neben den technischen Vorteilen ist der Betrieb von SMB3 sehr günstig, da Sie mit Ethernet-Karten und -Switches arbeiten. Gerade im Vergleich zu Fibre Channel bezahlen Sie hier nur die reine Hardware sowie den Support, nicht nochmal jeden einzelnen Port. Entscheiden Sie sich für den Einsatz von SMB3, muss es zwangsläufig Hyper-V sein, da kein anderer Hypervisor mit diesem Protokoll arbeiten kann.

Egal für welche Lösung Sie sich entscheiden, Sie sollte technisch sinnvoll sein und Ihnen einen Mehrwert bringen. Kommunizieren Sie dies auch intern deutlich, denn wir haben mehr als ein Projekt begleitet, bei dem "politisch" eine Lösung gesetzt wurde, die aber technisch nicht die beste Grundlade darstellte.

Verträge, Abhängigkeiten und Baselines

In einigen Firmen bestehen Verträge, in denen genau definiert ist, wie lange ein System maximal ausfallen darf oder wie lange ein gewisser Ablauf (zum Beispiel die Wiederherstellung von Dateien, Postfächern oder ähnliches) maximal dauern darf. Eine tiefere Betrachtung dieses Themas sprengt den Rahmen dieses Artikels, wir empfehlen Ihnen an dieser Stelle dringend, dass Sie diese Abhängigkeiten sehr genau im Projekt berücksichtigen und die gestellten Anforderungen auch validieren und dokumentieren.

Haben Sie den Aufbau am Ende des Projekts vollständig installiert und betriebsbereit, empfiehlt sich die Erstellung einer Performance-Baseline. Versuchen Sie, die Systeme unter große Last zu setzen. Dies kann entweder per Hand durch diverse Tools wie Dskspd [https://gallery.technet.microsoft.com/DiskSpd-a-robust-storage-6cd2f223] von Microsoft oder andere IO-Tools passieren – oder Ihr Hersteller bietet direkt solch eine Lösung an.

Microsoft hat beispielsweise mit der VMFleet [https://github.com/Microsoft/diskspd/tree/master/Frameworks/VMFleet] eine Ansammlung von PowerShell-Skripten veröffentlicht, mit denen ein Failover-Cluster unter Storage Spaces Direct (S2D) zur maximalen Belastungsgrenze getrieben werden kann. Dies führt dazu, dass Ihnen ein mehrstündiger Betrieb der Software zeigt, dass die Systeme auch bei extremer Belastung immer noch stabil laufen und nicht nach kurzer Zeit einen Ausfall haben.

Ein weiterer Vorteil eines solchen Tests ist, dass Sie eine klar definierte Baseline der zu erwartenden Performance bekommen. Wenn Sie nach zwei Jahren einen spürbaren Einbruch der Leistung beobachten, dies aber mit nichts außer Ihrer Erinnerung vergleichen können, ist dies schlecht. Haben Sie nach der Installation und vor der produktiven Inbetriebnahme solch eine Baseline erzeugt, können Sie sehr genau nachweisen, dass es ein Problem gibt.

Im dritten Teil erklären wir, warum ein wirkungsvolles Backupkonzept auch bei Virtualisierung so wichtig ist. Im ersten Teil des Workshops ging es darum, wie Sie zuerst einmal Ihre Anforderungen bestimmen und auf was Sie bei der passenden Hardware achten sollten.

Autor: Jan Kappen

</div>