von Redaktion IT-A…
Lesezeit
2 Minuten
Seite 2 - Virtualisierungsprojekte planen (2)
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 [3] von Microsoft oder andere IO-Tools passieren – oder Ihr Hersteller bietet direkt solch eine Lösung an.
Microsoft hat beispielsweise mit der VMFleet [4] 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.
Seite 2: Hypervisor festlegen oder wechseln
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.
jp/ln/Jan Kappen
[3] https://gallery.technet.microsoft.com/DiskSpd-a-robust-storage-6cd2f223
[4] https://github.com/Microsoft/diskspd/tree/master/Frameworks/VMFleet
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 [3] von Microsoft oder andere IO-Tools passieren – oder Ihr Hersteller bietet direkt solch eine Lösung an.
Microsoft hat beispielsweise mit der VMFleet [4] 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.
Seite 2: Hypervisor festlegen oder wechseln
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.
| << Vorherige Seite | Seite 2 von 2 |
jp/ln/Jan Kappen
[3] https://gallery.technet.microsoft.com/DiskSpd-a-robust-storage-6cd2f223
[4] https://github.com/Microsoft/diskspd/tree/master/Frameworks/VMFleet
