Hardware für Virtualisierungsprojekte planen (2)
Bei der Planung der Hardware für ein Virtualisierungsprojekt steht der IT-Verantwortliche vor einem großen Berg an Lösungen, Anbietern und unterschiedlichen Techniken. Neben einem Überblick der Komponentenvielfalt schauen wir auch auf hyperkonvergente Systeme, in denen Virtualisierung und Storage miteinander verschmelzen. In der zweiten Folge beschäftigen wir uns mit RAID-Controller, der passenden Netzwerkgeschwindigkeit und vor allem der richtigen Auswahl der Server.
Klein, aber immens wichtig: RAID-Controller
Achten Sie beim Kauf der Hardware darauf, dass Sie beim Einsatz von SATA- oder SAS-Speicher einen guten Hardware-RAID-Controller mit ausreichend Cache verwenden. Diese Art von Controller besitzt mittlerweile zwischen einem und 8 GByte Cache. Nicht selten finden sich Server, die eine sehr gute Hardware-Ausstattung haben, in denen aber ein Low-End Controller verbaut ist, der mit der anliegenden Leistung vollkommen überfordert ist. Diese kleine Komponente ist ungemein wichtig.
Kommt NVMe-Speicher zum Einsatz, wird dieser in den meisten Fällen direkt auf dem Mainboard als PCIe-Karte oder in einem speziellen Hot-Plug-Cage betrieben, der ebenfalls direkt am Mainboard angebunden ist. In diesem Fall können Sie auf den Betrieb von einem performanten RAID-Controller verzichten, für das Betriebssystem reicht meist ein einfaches Modell aus.
Es ist sogar denkbar, das Betriebssystem vom Hypervisor auf eine PCIe-Karte, auf der zwei M.2-SSDs im RAID1 laufen, zu verlagern. Somit sparen Sie zwei Festplatten beziehungsweise SSDs sowie die dazugehörigen Slots im Server, trotzdem hat das Hypervisor-OS ausreichend Platz für eventuelle Dumps oder Windows, wenn Hyper-V eingesetzt wird.
10 GBit/s hilft viel und muss nicht teuer sein
Ein Hypervisor muss an vielen Stellen mit der Außenwelt kommunizieren: VMs senden und empfangen Daten, es passiert ein Management des Hypervisors, die Systeme müssen aktualisiert werden und in regelmäßigen Abständen erfolgt ein Backup, das in den meisten Fällen per Netzwerk auf ein anderes System gespeichert wird.
Zum aktuellen Zeitpunkt ist die Nutzung von 10 GBit/s im Netzwerk absoluter Standard, in einigen Fällen ist sogar eine noch höhere Bandbreite im Einsatz (dazu später mehr). Achten Sie darauf, dass ausreichend Bandbreite zur Verfügung steht. Das häufige Argument gegen den Einsatz von einer Bandbreite von mehr als 1 GBit/s ist, "dass die Mitarbeiter und Kollegen durch den Einsatz von Terminal Services niemals mehr Bandbreite als 100 MBit/s erzeugen und das die aktuell genutzte GBit-Bandbreite vollkommen ausreichend ist. Durch den Einsatz eines inkrementellen Backupverfahrens liegen die täglichen Änderungen im kleinen GByte-Bereich und eine Sicherung kann in wenigen Minuten durchlaufen. Die einmalige Vollsicherung erfolgt dann am Wochenende, wenn sowieso niemand mit den Systemen arbeitet und danach ist mit einem GBit alles gut."
Dies funktioniert so lange, bis es zu einem Ausfall von einem System oder, noch schlimmer, zu einer (Teil-)Verschlüsselung der Daten durch einen Trojaner kommt. Müssen mehrere TByte Daten über ein 1-GBit-Netzwerk wiederhergestellt werden, kann es unter Umständen mehrere Tage dauern, bis dieser Vorgang abgeschlossen ist. All dies lässt sich im besten Fall um den Faktor zehn beschleunigen, wenn auf 10 GBit/s gesetzt wird. Die Preise für solche Hardware sind in den letzten Jahren signifikant gesunken, sodass der Einsatz nicht unbedingt teuer sein muss.
Ein weiterer Grund für eine hohe Bandbreite ist ein Transfer von Daten zwischen den Hypervisor-Systemen und zum Backupsystem. Sie können mittlerweile sehr einfach virtuelle Maschinen zwischen zwei Hosts verschieben, selbst ohne gemeinsamen Storage. Haben Sie unseren Ratschlag beherzigt und setzen einen Server mit Flash-Speicher ein, können Sie hier mit Schreib- und Leseraten im GByte-Bereich pro Sekunde arbeiten. Ist das Netzwerk hierfür nicht ausgelegt, nützen Ihnen die schnellsten SSDs nichts. Teilweise können Sie auch Hosts direkt miteinander verbinden (ein sogenannter Direct-Connect), so sparen Sie sich weitere Switches. In solch einem Fall könnten Sie auch 25 oder 50 GBit/s einsetzen. Eine Dual-Port-Karte im Enterprise-Bereich liegt zum aktuellen Zeitpunkt bei unter 250 Euro (Mellanox ConnectX-4 Lx).
Beim Einsatz von Hyper-V können Sie bei der Livemigration von VMs zwischen unterschiedlichen Host-Systemen auf SMB3 und RDMA-Techniken zurückgreifen. Hierbei haben wir schon Bandbreiten von bis zu 115 GBit/s beobachtet – der begrenzende Faktor war in diesem Fall der PCIe-Bus. Je schneller Ihre VMs zwischen den Hosts migriert werden können, desto weniger Delta-Daten fallen an, was sich ebenfalls positiv auf die Dauer der Migration auswirkt. Muss ein Server in den Wartungsmodus versetzt werden, der knapp 500 GByte VM-Memory betreibt, dauert dies bei einer 1-GBit/s-Anbindung (ohne die Änderungen während dieser Zeit zu berücksichtigen) knapp 70 Minuten. Allein durch die Nutzung von 10 GBit/s verringert sich dieser Wert um das zehnfache (also knapp 7 Minuten), bei 25 GBit/s sind wir schon bei unter drei Minuten.
Nutzen Sie statt einem einzelnen Port zwei oder mehr, profitieren Sie hier von der SMB3-Multichannel-Funktionalität. Die Daten werden in diesem Fall parallel über alle verfügbaren Ports gesendet, was sich erneut positiv auf die Dauer auswirkt. Dank RDMA-Technologien wird bei diesem Vorgang die CPU des Servers nicht spürbar belastet, da ein Offloading auf die Karten stattfindet. So steht noch ausreichend Leistung für den virtuellen Workload zur Verfügung.
Die richtige Wahl der Server
Für den Betrieb von einer Hypervisor-Landschaft stehen viele unterschiedliche Möglichkeiten, Modelle und Hersteller zur Verfügung. In den letzten Jahren haben sich hier insbesondere drei unterschiedliche Modelle herauskristallisiert: Tower-, Rack- und Blade-Server.
Steht kein Rack-Schrank zur Verfügung, muss dieser entweder angeschafft werden oder Sie setzen bei der Art des Servers auf ein Standmodell. Dies bedeutet nicht zwangsläufig, dass die Systeme schlechter in der Leistung sind, sie brauchen nur häufig mehr Platz und haben teilweise andere Komponenten verbaut. Das große Gehäuse hat teilweise auch den Vorteil, dass Sie mehr Komponenten verbauen können – sowohl intern als auch extern. Je nach Hersteller können Sie diese Tower-Modelle auch mit speziellen Rack-Kits umbauen und trotzdem im Rack betreiben, was sich in Projekten anbietet, die eine hohe Anzahl an internen HDD-Slots benötigen. In den meisten Fällen handelte es sich hier um Backupsysteme, die eine große Menge an Speicherplatz erfordern und wo durch solch ein Modell die Anschaffung eines externen Disk-Gehäuses samt SAS-Anbindung umgangen werden kann. Grundsätzlich ist nichts gegen diese Art von Server einzuwenden, solange sie mit ausreichend Leistung und Kapazität ausgestattet sind und Sie keine Rack-Systeme nutzen können oder wollen.
Der Großteil der Systeme, die im KMU-Umfeld zur Virtualisierung genutzt werden, sind allerdings Rack-Server. Hier sollten Sie sich primär Geräte mit zwei Höheneinheiten (HE) anschauen, da diese den Vorteil haben, dass Sie noch einiges an PCIe-Karten verbauen und nutzen können. Weiterhin fassen diese Systeme eine recht hohe Anzahl an Datenträgern, sodass einem nachträglichen Ausbau nichts im Wege steht.
Kaufen Sie ein professionelles Serversystem, können Sie die Systeme im hinteren Bereich mit einem Kabelarm ausstatten und so eine saubere und geordnete Kabelführung ermöglichen. Dies wird leider häufig nicht gemacht, da es mehr Zeit kostet als die reine Verkabelung ohne Führungsarm. Die investierte Zeit holen Sie aber im Laufe der Jahre mehrfach wieder rein, sofern Sie den Server zu Wartungs- oder Erweiterungszwecken öffnen müssen. Ohne ein vernünftiges Kabelmanagement müssen Sie alle Kabel entfernen und danach wieder korrekt stecken. Hier kann es durchaus vorkommen, dass zum Beispiel Netzwerkkabel in der falschen Reihenfolge gesteckt werden und die Server nach einem erneuten Start nicht online kommen, bis der Fehler behoben wurde. Teilweise werden solche Kabelführungen auch aktiv bei der Luftführung und Kühlung von einem Server eingeplant, sodass wild herumhängende Kabel die ausströmende Luft behindern und es im schlimmsten Fall zu einem Hitzestau kommt.
Vor einigen Jahren gab es um das Thema Blade Server einen regelrechten Hype. Nahezu jeder Hersteller brachte ein oder mehrere Systeme auf den Markt, bei denen mehrere Server in (meist recht kleiner Bauform) in einem größeren Chassis verbaut waren. Die Systeme selbst haben keine eigenen Netzteile, sondern werden im hinteren Bereich durch einen Connector mit allem versorgt, was sie brauchen: Strom, Netzwerk, Fibre Channel und noch einiges mehr.
Die Konzepte sind zum Teil sehr durchdacht, allerdings findet sich diese Form von Server im KMU-Bereich mittlerweile immer weniger. Dies hat unter anderem den Grund, dass solch ein System häufig sehr unflexibel ist, wenn es um das Thema Erweiterung geht. Da die Systeme sehr kompakt gebaut sind, muss der IT-Verantwortliche schon beim Kauf berücksichtigen, welche Technik verbaut wird. Möchten Sie beispielsweise nach drei Jahren die verbauten NICs von 10 auf 25 GBit/s aufrüsten, ist dies meist nicht möglich. Falls doch, sind die Preise für solch einen Umbau sehr hoch, da ein derartiges Vorgehen eigentlich nicht vorgesehen ist.
Es ist allerdings keineswegs so, dass Blades keine Relevanz haben und nicht genutzt werden. Gerade im Enterprise-Bereich finden sich Projekte, bei denen grundsätzlich auf Blades gesetzt wird, da diese über ein einheitliches Management verfügen und sich viele Prozesse vereinheitlichen lassen. Mit einem für den Kunden genau definierten Produkt lassen sich die Hardware-Anforderungen deutlich besser abschätzen als in einer Umgebung, in der die IT-Abteilung auf die unterschiedlichsten Notwendigkeiten reagieren muss.
Neben dem Betrieb eines Servers mit direkter Speicherung der VMs besteht in einem Virtualisierungsprojekt auch immer die Möglichkeit, dass Sie durch zwei oder mehr Server Hochverfügbarkeit erreichen. Durch die Einrichtung eines HA- beziehungsweise Failover-Cluster-Verbunds lassen sich Hardware-Ausfälle zeitnah kompensieren und der Betrieb der virtuellen Server nach kurzer Zeit wieder fortsetzen. Erreicht wird dies dadurch, dass die Hypervisor-Knoten die virtuellen Server zwar ausführen und betreiben, die Daten dieser VMs aber auf einem zentralen Storage liegen. Fällt einer der Hardwareknoten aus, kann ein Partnersystem dies erkennen und die ausgefallenen VMs zeitnah wieder starten. Dies ist möglich, weil grundsätzlich beide Hypervisor einen gemeinsamen Zugriff auf den Storage haben.
Die zentrale Speicherung der Daten führt zu mehreren Punkten, die zu beachten sind. Ein positiver Effekt ist, dass die Server nur noch sehr wenig lokalen Speicherplatz benötigen. Dies reduziert die Anzahl der benötigten Datenträger meist auf zwei bis gar keine, je nach Serveraufbau und Design. Auf der anderen Seite müssen Sie aber auch dafür sorgen, dass die Storage-Hardware den Anforderungen entspricht und die gewünschte Leistung liefern kann.
Die Art der Anbindung hängt stark von Ihrer Hypervisor-Lösung ab. Sie haben hier die Wahl zwischen den "traditionellen" Anbindungen wie Fibre Channel und iSCSI (vereinzelt finden sich auch SAS-basierte Lösungen), auf der anderen Seite stehen Lösungen, die sich von iSCSI, FC und SAS lösen und über (mehr oder weniger gewöhnliches) Ethernet arbeiten.
Besonders hervorzuheben ist hier das SMB3-Protokoll von Microsoft, das seit Windows Server 2012 im Einsatz ist und gepaart mit RDMA-fähigen Netzwerkkarten enorme Bandbreiten zu absolut erschwinglichen Preisen bietet. Schauen Sie sich solche Lösungen einmal unvoreingenommen an oder wenden Sie sich an einen Partner, der sich mit dem Thema gut auskennt. Sie haben mit solch einer Konstellation die Chance, dass Sie sich ein performantes System ins Haus holen, das bei guter Planung auch nach mehreren Jahren noch ausreichend Leistung und Speicherplatz zur Verfügung stellt. Wir kommen im weiteren Verlauf des Artikels auch noch auf das Thema "Hyperconverged Virtualization", hier geht es ebenfalls um genau diese Anforderungen und Lösungsansätze.
Einige Hersteller bieten auch Lösungen an, in denen die Compute-Knoten (Ihr Hypervisor) und der genutzte Storage direkt in einem System verbaut sind. Die Datenträger, die alle Knoten gemeinsam nutzen, sind dann häufig intern per SAS an die Server angebunden und stehen so zentral zur Verfügung. Diese Art von Systemen ist häufig relativ günstig zu bekommen und in den letzten Jahren primär im kleinen SMB-Umfeld recht populär.
Der preisliche Vorteil basiert meist, ähnlich wie bei Blade-Systemen, auf einer beschränkten Upgrade-Möglichkeit der Hardware. Was Sie bei dieser Art von System ebenfalls bedenken sollten ist die Tatsache, dass bei einem Hardwaredefekt möglicherweise das gesamte System ausfällt und die virtuellen Server für mehrere Stunden oder Tage offline sein werden, bis der Fehler behoben ist. Dies ist zwar bei einem professionellen System nicht allzu wahrscheinlich, aber das Risiko und die Folgen müssen Sie trotzdem einkalkulieren.
Im dritten Teil zeigen wir auf, warum hyperkonvergente Systeme auch für KMU die richtige Wahl bei der Virtualisierung sein können. Im ersten Teil des Workshops ging es darum, was Sie beim Herstellersupport beachten sollten und was die Vorteile von identischer Hardware sind.
Autor: Jan Kappen