VMware vSphere-8-Umgebungen planen (2)
Schlüsselfertig
Veröffentlicht in Ausgabe 10/2023 - PRAXIS
Dabei schauen wir zunächst auf den Aufbau unseres vSphere-8-Clusters. Das grundsätzliche Design beschrieb der erste Teil der Artikelreihe, nun geht es daran, unsere Infrastruktur im Detail zu planen.
Überlegungen zur Cluster-Konfiguration
In der Regel sind die Hardware, das Cluster-Sizing und die Verfügbarkeitsüberlegung nur die halbe Miete für einen stabilen Betrieb. Die Konfiguration der Cluster und der beteiligten Hosts spielt eine genauso wichtige Rolle. Hier kommt mit vSphere 8.0 Update 1 ein neues Werkzeug zum Tragen: Configuration Profiles. Diese erlauben die Host-Konfiguration auf Cluster-Ebene mittels eines Desired-State-Ansatzes, der vielen schon aus dem Kubernetes-Umfeld geläufig ist.
Die gewünschte Konfiguration (Desired State) können Sie allen vSphere-Hosts in einem Cluster mit einer einzigen Operation zuordnen, wozu Sie einen Referenz-Host als Vorlage zum Einsatz bringen. Der Vorteil gegenüber den bereits aus vorherigen vSphere-Versionen bekannten Host Profiles ist, dass Configuration Profiles auf Cluster-Ebene ansetzen und für einen homogenen Cluster sorgen. Diese Profile haben das JSONFormat, was erlaubt, Sie einfach zu erstellen, zu editieren und zu verwalten. Configuration Profiles können die altbekannten Host-Profiles ersetzen und es ist möglich, bereits bestehende Cluster entsprechend umzustellen.
Dabei schauen wir zunächst auf den Aufbau unseres vSphere-8-Clusters. Das grundsätzliche Design beschrieb der erste Teil der Artikelreihe, nun geht es daran, unsere Infrastruktur im Detail zu planen.
Überlegungen zur Cluster-Konfiguration
In der Regel sind die Hardware, das Cluster-Sizing und die Verfügbarkeitsüberlegung nur die halbe Miete für einen stabilen Betrieb. Die Konfiguration der Cluster und der beteiligten Hosts spielt eine genauso wichtige Rolle. Hier kommt mit vSphere 8.0 Update 1 ein neues Werkzeug zum Tragen: Configuration Profiles. Diese erlauben die Host-Konfiguration auf Cluster-Ebene mittels eines Desired-State-Ansatzes, der vielen schon aus dem Kubernetes-Umfeld geläufig ist.
Die gewünschte Konfiguration (Desired State) können Sie allen vSphere-Hosts in einem Cluster mit einer einzigen Operation zuordnen, wozu Sie einen Referenz-Host als Vorlage zum Einsatz bringen. Der Vorteil gegenüber den bereits aus vorherigen vSphere-Versionen bekannten Host Profiles ist, dass Configuration Profiles auf Cluster-Ebene ansetzen und für einen homogenen Cluster sorgen. Diese Profile haben das JSONFormat, was erlaubt, Sie einfach zu erstellen, zu editieren und zu verwalten. Configuration Profiles können die altbekannten Host-Profiles ersetzen und es ist möglich, bereits bestehende Cluster entsprechend umzustellen.
Aus Betriebssicht ist ein Konfigurationsmanagement auf Cluster-Ebene deutlich zielführender als auf individueller Host-Ebene. Der einzige Wermutstropfen ist, dass Sie den Cluster dafür auf Image-basiertes Lifecycle-Management umstellen und die Baseline-basierte Verwaltung aufgeben müssen.
Strom sparen im Cluster
Die Themen CO2-Fußabdruck, Nachhaltigkeit und Energiesparen sind inzwischen auch in den Rechenzentren angekommen. IT-Verantwortliche können den Energieverbrauch einerseits vorausschauend durch ein vernünftiges, bedarfsgerechtes Sizing der Server und der Cluster steuern, zum anderen kommen natürlich Konfigurationen und Hardwarefähigkeiten auf Host-Ebene wie zum Beispiel Dynamic Power Mode, Speed Stepping und so weiter dazu.
Aber auch im Cluster kann DPM (Distributed Power Management) durchaus zum Energiesparen beitragen, vor allem dort, wo Lasten zyklisch von "High" zu "Low" laufen. DPM setzt einen DRS-Cluster voraus und erlaubt dann, dessen Energieaufnahme dadurch zu reduzieren, dass Hosts je nach Ressourcennutzung aus- und angeschaltet werden. Da ein Host für das Wiederanfahren Zeit braucht, ist dies allerdings kein Weg, quasi in Echtzeit auf Laständerungen zu reagieren. Aber wo beispielsweise an einem Wochenende in einem Virtual-Desktop-Cluster kaum Nutzer arbeiten, führt DPM durchaus zu Einsparungen.
Sizing von CPU und RAM des ESXi-Hosts
Unabhängig von der Größe des Clusters und wie viele davon Sie einsetzen, die Grundlage ist der ESXi-Host. Wie schon erwähnt, hängt die Cluster-Größe auch vom Sizing des einzelnen Hosts ab. Kommen eher 1-U-Server, also Pizzaboxen, zum Einsatz, ist die Kapazität in Sachen CPU, RAM und Erweiterungs-Slots des einzelnen Servers überschaubar und der Cluster fällt wahrscheinlich entsprechend größer aus. Natürlich hängt auch das Server-Sizing vom Workload, also der entsprechenden VM ab, doch die Grundfrage ist sicherlich, ob Sie lieber einen großen oder einen kleinen Server einsetzen.
Hier spielen diverse Faktoren eine Rolle, die wir uns im Detail ansehen wollen. Entscheidend ist das Workload-Profil der VM, deren Größe unser erster Punkt ist. Nehmen wir zwei Extreme als Beispiel: eine große Oracle- oder SAP-HANA-Datenbank und einen Container-Host. Eine SAP-HANA-VM kann leicht eine Größe von 3 bis 6 TByte RAM und 192 bis 384 vCPUs erreichen. Das schreit natürlich nach einem ESXi-Host mit acht Sockets und 6 bis 12 TByte RAM – dennoch finden in diesem Beispiel nur maximal zwei VMs auf dem Host Platz, zumal es kein Oversubscription geben darf.
Eine Container-Host-VM auf der anderen Seite mag 16, 32 oder 64 GByte RAM und 4 bis 16 vCPUs benötigen und Oversubscription der Ressourcen auf dem ESXi-Host stellt meist auch kein Problem dar. Von der kleinen "4 vCPU, 16 GByte RAM"-Variante passen bei einem konservativen 3:1-RAM-Oversubscription-Verhältnis auf unseren Server mit acht Sockets, 384 HyperThreads und 12 TByte RAM sage und schreibe 768 dieser VMs. Das ist schon sehr nahe an der maximal supporteten Obergrenze von 1024 VMs pro Host. Da vSphere 8 aber "nur" 8000 VMs pro Cluster unterstützt [1], ist ein 12-Node-Cluster bei N+2-Redundanz bereits das Ende der Fahnenstange.
Auch der Blast-Radius eines Servers im Fehlerfall ist ein entscheidendes Kriterium. Nehmen wir wieder das zweite Beispiel: Fällt dieser 12-TByte-Server mit 768 VMs aus, stehen 768 Applikationen oder Applikationsbestandteile still und die VMs müssen natürlich an anderer Stelle und dazu noch gleichzeitig neu gestartet werden – was eventuell auch zu Problemen im Storage führen kann (Stichwort "Bootstorm"). Für diese Workloads sind kleinere ESXi-Hosts also deutlich sinnvoller.
Der nächste zu betrachtende Aspekt ist die VM-Performance, die sich in der Regel in drei Teilbereichen festmachen lässt und entsprechende Anforderungen an Host und umgebende Infrastruktur stellt. In Sachen CPU ist die erste Frage, die sich häufig stellt: "Wie viele Cores und welche Taktfrequenz?" Neben der Kostenfrage müssen Sie hier beachten, wie die Workloads aussehen. Profitiert die Applikation eher von einer schnelleren CPU – also höherer Taktfrequenz – oder beherrscht sie sauberes Multithreading und profitiert von einer größeren vCPU-Zahl und damit mehr Cores.
Das Thema Cores ist auch direkt mit dem Thema Hyperthreading verbunden. Generell ist dies eine gute Idee und Sie sollten es anschalten, denn es erlaubt dem CPU-Scheduler im VMkernel des ESXi-Servers mehr Auswahl beim Verteilen der CPU-Requests der VMs und hält die Performance oben. Ist Hyperthreading auf dem Server aktiviert, zeigt er natürlich doppelt so viele logische CPUs wie Cores physikalisch vorhanden sind. Für das Sizing ist aber keinesfalls anzunehmen, dass Hyperthreads die Performance verdoppeln. Der Performancegewinn liegt erfahrungsgemäß zwischen fünf und maximal 25 Prozent und das ist wiederum abhängig vom Applikationstyp, NUMA Alignment, IO-Last et cetera.
Daneben müssen Sie auch den Arbeitsspeicher des Hosts planen. Das RAM ist für viele Applikationen ein entscheidender Faktor, wobei die Größe wichtiger ist als die Taktfrequenzen. Es sei jedoch angemerkt, dass je nach RAM-Ausbau und Mainboard-/Chipset-Typ (alle Slots, alle Channels oder nur zwei Drittel oder gar nur die Hälfte bestückt) durchaus Performanceunterschiede durch Heruntertakten des RAM auftreten können. Hier hilft die Dokumentation des Hardwareherstellers meist weiter.
Eine ausgewogene CPU-zu-Memory-Ratio ist sehr sinnvoll. Ein wertvoller Ansatz ist hier derjenige von Hyperscalern wie Amazon oder Google, nämlich die VMs in drei grobe Kategorien zu unterteilen: "Memory-lastig", "CPU-lastig" und "Ausgeglichen". Dementsprechend lassen sich Hosts dann aufbauen und natürlich in verschiedene Cluster aufteilen.
IT-Administrator Sonderheft "VMware vSphere 8"
Das neue IT-Administrator Sonderheft "VMware vSphere 8 – Virtualisierte Infrastrukturen sicher betreiben" liefert praktisches Know-how zur Verwaltung, Betrieb und Absicherung der Version 8 von vSphere. Daneben widmet sich das Autorenteam zudem den mittlerweile weit über die Servervirtualisierung hinausreichenden Features zur Bereitstellung von Containern, virtualisierten Netzen und der Cloudintegration. Im laufenden Betrieb bringen Data Processing Units und die Hardwareversion 20 grundlegende Neuerungen, die wir ebenso vorstellen wie die zahlreichen Detailupdates etwa bei Hochverfügbarkeit und der Zertifikatsverwaltung. Im Abschnitt zur Systemsicherheit beschreiben die Autoren dann im Detail sichere Architektur und Betrieb von vSphere 8 sowie Maßnahmen zur Datensicherheit. Natürlich kommt auch das Management von VMs und Containern im Sonderheft nicht zu kurz, bevor wir uns den Optionen zur Virtualisierung von Netzwerk und Storage zuwenden. Abgerundet wird das Sonderheft durch praxiserprobte Maßnahmen und Vorgehensweisen beim Troubleshooting und einer Auswahl nützlicher Drittanbieter-Tools. Das Sonderheft ist ab Ende Oktober verfügbar und kostet für Abonnenten des IT-Administrator 24,90 Euro, für Nicht-Abonnenten werden 29,90 Euro fällig.
Auslegen der Netzanbindung
Spielt bei Ihnen allerdings Performance die größte Rolle und CPU-, Memory-, Storage- und Netzwerkperformance-Schwankungen sind nicht tolerierbar, bietet sich noch das Vehikel der Ressourcenreservierungen an. Damit lassen sich für CPU und RAM physische Ressourcen garantieren.
Natürlich verschwenden Sie damit wertvolle Kapazität, jedoch bleibt das Applikationsverhalten so immer gleich und Sie müssen nicht mit RAM- oder CPU-Engpässen rechnen.
Für Netzwerkressourcen bedienen Sie sich hier der "Network-IO-Control"-Funktionalität (NIOC) und können pro Traffic-Typ ebenfalls Reservierungen und Limits anwenden, um beispielsweise VM Traffic nie unter ein bestimmtes Maß fallen zu lassen [2]. Für eine noch granularere Zuordnung zur einzelnen VM, oder genauer gesagt zum einzelnen virtuellen Netzwerkadapter, bietet vSphere 8 die Funktionen des Vorgängers (NIOC v3) an, mit denen Sie pro virtuellem NIC die Bandbreite mittels Shares, Reservierungen und Limits steuern.
All das ergibt natürlich nur Sinn, wenn der Host über genug Netzwerkbandbreite verfügt. Hierzu bieten sich 25-, 40- oder 100-GBit-Adapter an. Meist reichen zwei 25-GBit-NICs völlig aus – selbst beim Einsatz von VMware vSAN und dem assoziierten Replikationsverkehr. Die Erfahrung zeigt, dass Sie zwei 100-GBit-Adapater nur selten ausreizen können, selbst in Kombination verschiedenster Traffic-Typen (VM, iSCSI/NFS, VMotion, Provisioning et cetera). Andererseits bieten zwei 100-GBit-Anschlüsse genug Bandbreite, um auf NIOC zu verzichten und operationellen Aufwand einzusparen. Also eine klassische Abwägung zwischen CAPEX und OPEX.
Storage-Planung
Beim Thema Storage müssen Sie auch wieder mehrere Grundfragen beantworten. Die erste davon ist, ob Sie diesen traditionell oder Policy-basiert aufbauen. Mit "traditionell" ist hier der Ansatz gemeint Datastores via iSCSI, FC oder FCoE, LUNs oder NFS-Shares als Datastore bereitzustellen, auf denen die VM-Daten liegen. In der Regel bestimmt das (externe) Array und die Art der Anbindung (LAN oder FibreChannel, geteilte oder dedizierte Infrastruktur und so weiter) die Performance sowie Verfügbarkeit auf LUN- oder Share-Ebene. Der Wechsel auf eine andere Performance- oder Verfügbarkeitsklasse ist in der Regel nur durch Verschieben auf einen anderen Datastore mittels Storage-vMotion möglich.
Policy-basierter (oder Software-defined) Storage ist in Form von vSAN oder VMware vVols verfügbar. Hier können Sie Policy-Änderungen auf Objektebene wie etwa einer virtuellen Disk im laufenden Betrieb und ohne Verschieben der VM durchführen. Dies ist vor allem in hochautomatisierten Umgebungen sinnvoll beziehungsweise wenn zu erwarten ist, dass sich im VM-Lifecycle die Verfügbarkeits- oder Performanceanforderungen ändern.
Nun gilt es noch zu entscheiden, ob Sie auf HCI (Hyper Converged Infrastructure) oder externen Storage setzen wollen. Wir haben eben schon vSAN erwähnt, das zur Klasse des Hyper Converged Storage gehört. Das Grundprinzip lautet, internen Speicher des Servers (präferiert NVMe oder SSD) zu nutzen und über die Server im Cluster hinweg zu aggregieren und hochverfügbar zu gestalten. Der Vorteil liegt auf der operativen Seite, denn so konfigurieren und verwalten Sie den Speicher als Teil der vSphere-Plattform.
Der Nachteil ist, dass die SSDs oder NVMes im Server Platz finden müssen und Sie für vSAN eine eigene Lizenz benötigen. Da die Replikation der Storage-Objekte und der Zugriff über das vorhandene Ethernet stattfindet, müssen Sie die Bandbreite einkalkulieren und diesen Traffic sollten Sie – wie alle anderen Arten auch – unbedingt über ein eigenes VLAN sauber separieren.
Kommen wir zum traditionellen Storage, der mit zentralisierten Arrays nach wie vor sehr populär ist. Viele Umgebungen nutzen bekannte Technologien wie Fileoder Block-Speicher schon sehr lange, die Admins verfügen über eine entsprechende Erfahrung. Vor allem FibreChannel (FC) steht nach wie vor hoch im Kurs, wenn es um Performance und Verfügbarkeit geht. Die Tatsache, dass FC über eine dedizierte Infrastruktur und nicht das gemeinsame Ethernet läuft, gibt vor allem bei kritischen Applikationen zusätzliche Sicherheit.
Der Nachteil liegt im zusätzlichen Verwaltungsaufwand, denn Sie müssen eine separate Infrastruktur sowie Software für Konfiguration und Replikation betreiben. Auch tiefes Know-how ist erforderlich, denn ein Problem im Array oder ein Konfigurationsfehler lässt eventuell einen ganzen vSphere-Cluster ausfallen.
Verbunden mit traditionellem Storage ist natürlich auch die Frage nach dem Protokoll. Zur Wahl stehen IP basierte Protokolle wie iSCSI und NFS oder das erwähnte FibreChannel. Die Wahl, ob iSCSI oder NFS, ist häufig eine Frage der persönlichen Erfahrungen, doch dem Irrglauben, dass iSCSI schneller ist als NFS, müssen wir an dieser Stelle widersprechen. Generell müssen Sie allerdings beachten, dass iSCSI im Kontext einiger Applikationen wie etwa SAP HANA nicht supportet ist. Hier sollten Sie sich vorher beim Softwarehersteller erkundigen.
Grüne Wiese vs Upgrade
Natürlich sind die hier erwähnten Prinzipien am besten in einer Greenfield-Umgebung, also einer komplett neuen Installation, umzusetzen. Jedoch schadet es nichts, wenn Sie den ein oder anderen Aspekt wie Workload-Domains, Cluster-Aufteilung oder die Umstellung auf Cluster Configuration Profiles auch im Rahmen eines Upgrades überdenken und anpassen.
Der wichtigste Aspekt bei Neuinstallation und Upgrade ist, dass die verwendete Hardware mit vSphere 8 U1 kompatibel ist, was Sie über die VMware Hardware Compatibility List [3] einfach prüfen können. Für ein Upgrade von vSphere 6.7 oder 7.x sieht es etwas anders aus [4], denn hierbei ist die Reihenfolge der Komponenten im Upgrade festgelegt und folgt der Reihenfolge in Bild 3.
Im Rahmen der vSphere+-Lizenzierung findet sich für das Update noch ein verstecktes Highlight. Ist vSphere+ (also die cloudverbundene Variante der Virtualisierungsplattform) aktiv und ein Cloud-Proxy in der lokalen Umgebung installiert, dann können Sie mit vSphere+ und vSphere 8 U1 lokal das vCenter-Update mittels eines einfachen und stabilen "One-Click"-Vorgangs durchführen.
Hier noch ein wichtiger Hinweis: Sollte in der bestehenden Umgebung NSX-T beziehungsweise NSX Datacenter in Version 3.x im Einsatz sein, so müssen Sie NSX zunächst auf die Version 4.x (präferiert 4.1.x) migrieren, bevor Sie mit dem vSphere-8-Update starten können. Denn es besteht keine Kompatibilität zu NSX unter Version 4.
Fazit
Sie sollten beim vSphere-Design aktuellen Standards folgen. Der Aufbau von Domains ist aus Sicherheits-, Verwaltbarkeits- und Performanceaspekten sinnvoll – nicht nur in VMware Cloud Foundation, sondern in jeder vSphere-Infrastruktur. Die Aufteilung der Umgebung in Domains und Cluster erlaubt eine saubere Workload-Zuordnung, steigert die Effizienz und sorgt auch für Energieeinsparungen. Das Update 1 bringt hier zusätzliche, gute Ergänzungen wie Cluster Configuration Profiles ins Spiel und trägt damit zu mehr Effizienz und zur betrieblichen Vereinfachung bei.
(jp)
Link-Codes
[1] Maximalkonfiguration von vSphere 8: https://configmax.esp.vmware.com/guest?vmwareproduct=vSphere&release=vSphere%208.0&categories=2-0,3-0
[2] Distributed Power Management: https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-resource-management/GUID-5E5E349A-4644-4C9C-B434-1C0243EBDC80.html
[3] VMware Hardware Compatibility List: https://www.vmware.com/resources/compatibility/search.php
[4] Leitfaden zum vSphere-8-Upgrade: https://core.vmware.com/resource/upgrading-vsphere-8