VMware vSphere-8-Umgebungen planen (1)
Optimal aufgebaut
Veröffentlicht in Ausgabe 09/2023 - PRAXIS
Seit seiner Einführung vor rund 20 Jahren hat sich das vSphere-Ökosystem kontinuierlich weiterentwickelt, dennoch bleiben Verfügbarkeit, Verwaltbarkeit, Performance und Sicherheit die vier grundlegenden Anforderungen an eine leistungsfähige vSphere-Architektur. Je nach Einsatzzweck und Exposition kann einer dieser Pfeiler natürlich dominieren – so liegt aktuell bei vielen Unternehmen der Fokus verstärkt auf Sicherheit – jedoch sollten IT-Verantwortliche die anderen beim Design der Umgebung nie vernachlässigen.
Grundlage des Designs
Für das Design einer vSphere-Umgebung stellte VMware in der Vergangenheit den Ansatz der "VMware Validated Designs" [1] bereit. Dieser ist zwar noch im Netz verfügbar, wird vom Hersteller aber nicht mehr offiziell unterstützt. Die logische Fortsetzung dieser Richtlinien lässt sich aus "VMware Cloud Foundation" (VCF) herleiten.
Dabei handelt es sich um ein integriertes Softwarepaket, das die Bereitstellung und Verwaltung einer kompletten Hybrid-Cloud-Infrastruktur ermöglicht. VCF soll hier nicht das eigentliche Thema sein, sondern der architektonische Ansatz dahinter. Denn dieser stellt aktuell die beste Hilfestellung dar, um ein Best-Practices-Design aufzubauen. Dieses ermöglicht IT-Verantwortlichen, ein standardisierbares und damit für diverse Anwendungsfälle wiederholbares und anpassungsfähiges Architekturmuster und eine daraus resultierende Plattform zu bauen. Eine solche Umgebung ist in der Lage, verschiedenste Workloads mit deren Performance-, Sicherheits- und Skalierungsanforderungen abzubilden. VCF berücksichtigt dabei Industriestandards und VMwares Erfahrungen aus tausenden Kundeninstallationen.
Seit seiner Einführung vor rund 20 Jahren hat sich das vSphere-Ökosystem kontinuierlich weiterentwickelt, dennoch bleiben Verfügbarkeit, Verwaltbarkeit, Performance und Sicherheit die vier grundlegenden Anforderungen an eine leistungsfähige vSphere-Architektur. Je nach Einsatzzweck und Exposition kann einer dieser Pfeiler natürlich dominieren – so liegt aktuell bei vielen Unternehmen der Fokus verstärkt auf Sicherheit – jedoch sollten IT-Verantwortliche die anderen beim Design der Umgebung nie vernachlässigen.
Grundlage des Designs
Für das Design einer vSphere-Umgebung stellte VMware in der Vergangenheit den Ansatz der "VMware Validated Designs" [1] bereit. Dieser ist zwar noch im Netz verfügbar, wird vom Hersteller aber nicht mehr offiziell unterstützt. Die logische Fortsetzung dieser Richtlinien lässt sich aus "VMware Cloud Foundation" (VCF) herleiten.
Dabei handelt es sich um ein integriertes Softwarepaket, das die Bereitstellung und Verwaltung einer kompletten Hybrid-Cloud-Infrastruktur ermöglicht. VCF soll hier nicht das eigentliche Thema sein, sondern der architektonische Ansatz dahinter. Denn dieser stellt aktuell die beste Hilfestellung dar, um ein Best-Practices-Design aufzubauen. Dieses ermöglicht IT-Verantwortlichen, ein standardisierbares und damit für diverse Anwendungsfälle wiederholbares und anpassungsfähiges Architekturmuster und eine daraus resultierende Plattform zu bauen. Eine solche Umgebung ist in der Lage, verschiedenste Workloads mit deren Performance-, Sicherheits- und Skalierungsanforderungen abzubilden. VCF berücksichtigt dabei Industriestandards und VMwares Erfahrungen aus tausenden Kundeninstallationen.
VMware Cloud Foundation ist sehr restriktiv in Bezug auf das Design und auch die supporteten Architekturausprägungen. Jedoch lassen sich auch für Nicht-VCF-Umgebungen viele Best Practices, Designmuster und Architekturideen ableiten, die in jeder vSphere-Umgebung sinnvoll sind. In den folgenden Betrachtungen werden Sie jedoch von VCF kaum noch etwas lesen – stattdessen referenzieren wir auf vSphere mit seinen verschiedenen Designebenen:
- High-Level-Design
- RZ-Layout
- Workload-Domain und Cluster
- VM-Anforderungen
- Host-Design
- vSphere-Update
Mit Workload-Domains Umgebungen gestalten
Als oberstes Designziel definieren wir, dass wir Workloads mit den bestmöglichen SLAs betreiben möchten. Grundsätzlich gibt es in jeder vSphere-Umgebung zwei wesentliche Workload-Typen zu unterscheiden: die Managementkomponenten und die regulären Workloads, also Applikationen, die das Kerngeschäft unterstützen. Die physische oder logische Trennung des Managements von anderen Workloads reduziert das Risiko von Störungen oder Sicherheitsverletzungen. Ein unerwarteter Fehler oder eine Überlastung in den regulären Workloads kann somit die vSphere-Administration nicht beeinträchtigen, was zu einer besseren Stabilität und mehr Kontrolle führt. Aus dem VCF-Konzept leitet sich hier der Aufbau einer Management-Domain und zusätzlich einer oder mehrerer Workload-Domains als Best Practice ab. Eine solche Domain kann wieder- um mehrere Cluster enthalten, ein Beispiel zeigt Bild 1.
Das Domain-Konzept aus VCF auf vSphere-Umgebungen zu übertragen ist sehr sinnvoll, denn eine Domain ist eine isolierte und skalierbare Einheit, die Ressourcen und Services für spezifische Workloads bereitstellt. Es handelt sich also um eine logische oder physische Abgrenzung innerhalb der VMware-Infrastruktur. In Bild 1 ist die Management-Domain physisch abgetrennt, um die Sicherheit der Management-Workloads zu erhöhen.
Eine Workload-Domain stellt ebenfalls eine physische und/oder logische Trennung dar, die auf unterschiedlichen Anforderungen basiert. Als Erstes ist hier die organisatorische Struktur zu betrachten, die Themen wie Mandantentrennung, Administratoren-, Nutzer- und Automationszugriffe et cetera beinhaltet. Dazu erhält jede Workload-Domain ihr eigenes vCenter und so sind Sie innerhalb einer Workload-Domain in der Lage, Ressourcen und Services optimal zu konfigurieren und zu verwalten, um die spezifischen Bedürfnisse Ihrer Workloads zu erfüllen.
Der zweite wichtige Punkt in der Work-load-Domain sind Sicherheitsrichtlinien. So ist in Bild 1 beispielsweise die Netzwerktrennung durch eine unabhängige NSX-Installation realisiert. Workload-Domains stellen in der Regel auch Sicherheitsbereiche dar, das heißt, häufig kommt hier ein dediziertes NSX oder physisch getrennte Netzwerke (Airgapping) zum Einsatz. Eine physische Trennung ist auch heute häufig noch das Mittel der Wahl für eine DMZ.
Die dritte und letzte Überlegung gilt den Performanceanforderungen. Hierbei liefern die Workload-Domains Flexibilität und Skalierbarkeit, da sich unterschiedliche Domains für unterschiedliche Work-load-Typen optimieren lassen. So stellen beispielsweise VDI-Umgebungen ganz andere Anforderungen als klassische Serveranwendungen. Eine weitergehende Unterteilung von Workload-Domains in unterschiedliche Cluster erlaubt zudem eine zusätzliche Verfeinerung oder die weitergehende Trennung von Applikationen. Je genauer Sie die Anforderungen der abzubildenden Workloads (virtuelle Maschinen und Applikationen) kennen, desto besser lassen sich Workload-Domains und die zugehörigen Cluster auslegen, um den unterschiedlichen Anforderungen Rechnung zu tragen.
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.
Verfügbarkeit der Workloads planen
In erster Näherung lässt sich sagen, dass in den meisten Umgebungen zwei Cluster-Typen sinnvoll sind: General-Purpose-Cluster für reguläre Anwendungen (Webserver, viele Applikationsserver) und High-Performance-Cluster für latenzsensitive Datenbanken, performancehungrige Applikationen oder besonders große virtuelle Maschinen. Darüber hinaus lässt sich diese Unterteilung natürlich beliebig weiter treiben – Cluster für Container, AI/ML mit GPU-Hardware, In-Memory-Datenbanken und so weiter.
Wir gehen später noch genauer auf das Cluster-Design ein, vorher ist jedoch noch die Frage nach der Resilienz der Gesamtumgebung von sehr hoher Bedeutung. Grundsätzlich können wir dabei zwei Architekturansätze unterscheiden, die auf der Anzahl der Rechenzentren basiert: Gibt es ein Rechenzentrum beziehungsweise Standort oder mehr? Ein wichtiger Begriff aus dem Cloudkontext ist dabei die "Availability Zone" (AZ). Diese beschreibt in der Regel einen in sich geschlossenen Standort, wir können ihn also näherungsweise mit dem Begriff "Rechenzentrum" oder "Serverraum" gleichsetzen. AZs sind räumlich getrennt, aber üblicherweise innerhalb von Campus- oder Metro-Distanzen angesiedelt, um die Roundtrip-Latenz gering zu halten. Meist basieren diese Maximallatenzen auf den Anforderungen eines synchronen Storage-Zugriffs. Bei VMware vSAN liegt diese Latenz für eine gestreckte Installation beispielsweise bei 5 ms [2].
Für ein Maximum an Verfügbarkeit sind zwei Availability Zones der präferierte Ansatz. Selbst wenn erst eine AZ existiert oder aufgebaut wird, sollte deren Design idealerweise eine künftige Erweiterung auf eine zweite AZ berücksichtigen. Als Beispiel sei hier die Situation genannt, dass das Managementnetzwerk für ESXi und vCenter auf Layer 2 über beide AZs gestreckt werden muss (Bild 2).
Gemäß Best Practices sollten Sie die Management-Domain verlängern, sobald auch nur eine Workload-Domain gestreckt sein soll, damit sowohl Management als auch Workloads gleiche Verfügbarkeit gewährleisten können (Bild 3). Der duale AZ-Ansatz gewährleistet dennoch hohe Flexibilität, denn nicht alles muss zwangsweise gestreckt sein. Ein Kombination aus gestreckten und nicht-gestreckten Domains (Bild 4) kann unterschiedliche Verfügbarkeits- und Kostenansätze adressieren.
Workload-Domains pro AZ anstelle von gestreckten Workload-Domains ergeben vor allem dann Sinn, wenn:
- Hochverfügbarkeit/Replikation auf Applikationsebene gewährleistet ist.
- Durchschnittliche Verfügbarkeit erforderlich ist .
- Test-/Entwicklungsumgebungen aufgesetzt werden.
Obwohl natürlich eine gestreckte Umgebung eine sehr hohe Verfügbarkeit gewährleistet, sollten Sie keinesfalls vergessen, dass ein Stretching auch doppelt so teuer ist, da Sie durch die zweite AZ zweimal so viel Hardware und Lizenzen benötigen, die nutzbare Kapazität aber dennoch nur der einer AZ entspricht. Cluster müssen Sie entsprechend über beide Availability Zones aufteilen und konfigurieren. Und natürlich muss die Speicherumgebung dieses – häufig auch als Metro-Storage-Clustering bezeichnet – ebenfalls unterstützen.
Produktiv können Workloads auf beiden Seiten einer gestreckten Umgebung laufen, bei einem Failover muss aber immer sichergestellt sein, dass Workloads auch auf der überlebenden Seite automatisch starten (können). Das heißt, es darf keine lokalen Abhängigkeiten wie CD- oder ISO-Mounts et cetera geben. Zudem müssen Sie die Regeln des VMware DRS (Distributed Ressource Scheduling Cluster) wie Anti-Affinitäts- und Host-zu-VM-Richtlinien entsprechend konfigurieren und regelmäßig überprüfen.
Und was in der Praxis oft vergessen wird, ist die Tatsache, dass ein dualer AZ-Ansatz in der Regel nicht zwei, sondern drei Standorte beziehungsweise AZs benötigt. Denn für viele Komponenten wie zum Beispiel vSAN oder Datenbank-Clustering ist in einem 2-Standort Setup üblicherweise ein Quorum (oder ein Witness) erforderlich. Dieses sollte eben nicht in einer der beiden AZs, sondern idealerweise in einem dritten unabhängigen Standort laufen (Bild 5). Meist kann dieser deutlich kleiner ausfallen und auch deutlich höhere Latenzen verkraften, also ist hier mitunter auch die Platzierung in einer Public Cloud denkbar, sollte kein eigener dritter Standort vorhanden sein. Für VMware vSAN und seine Witness-Appliance ist etwa eine Platzierung im Clouddienst "VMware Cloud on AWS" möglich [3].
Anforderungen des Cluster-Designs
Innerhalb einer Workload-Domain können ein bis mehrere Cluster existieren, wie Bild 6 veranschaulicht. Die Frage ist nun aber, wie viele Cluster Sie in einer Workload-Domain platzieren sollten. Das hängt von einigen Faktoren ab, die wir im Folgenden betrachten. Der erste Aspekt sind Sicherheitsanforderungen: Müssen Sie Workloads (VMs) physisch voneinander trennen, wird häufig der Cluster (inklusive der Storage-Anbindung) als Demarkationslinie gesehen, was logischerweise mehr Cluster erfordert. Ein Beispiel hierfür ist eine Compliance-Anforderung hinsichtlich PCI (Payment Card Industry), bei der Sie entsprechende VMs nicht mit denen anderer Nutzer oder Nicht-PCI-Workloads auf demselben Cluster und Storage mischen dürfen. Obwohl sich dies in einer virtualisierten Welt auch mittels sicherer logischer Trennung realisieren lässt, ist die physische Trennung noch ein häufig gesehenes Muster.
Die zweite Überlegung umfasst die Charakteristika Ihrer Workloads. Existieren verschiedene Performanceanforderungen und extrem unterschiedliche VM-Größen (zum Beispiel 16-GByte-VMs am einen und 6-TByte-VMs am anderen Ende der Größenskala), ergibt eine Trennung in separate Cluster durchaus Sinn im Hinblick auf die initiale Platzierung oder VMotion-Zeiten. Auch in Sachen Performanceanforderungen, die neben CPU und RAM auch das Netzwerk und den Storage sowie deren Latenzen umfassen, sollten Sie auf dedizierte Cluster setzen, um Performance-SLAs einzuhalten.
Einplanen sollten Sie zudem einen "Blast Radius" für Fehlkonfigurationen. Denn aus operativer Sicht müssen Sie früher oder später auch an Upgrades und Updates denken und dafür sind mehrere kleine statt eines großen Clusters hilfreich. Denn erstens ist im Fall eines Konfigurations- oder Treiberfehlers der Blast Radius auf einen von mehreren Clustern beschränkt und zweitens verwendet vSphere 8 präferiert den vSphere Lifecycle Manager und Cluster-Images. Damit ist nicht mehr der einzelne Host, sondern der Cluster das kleinste Objekt für ein orchestriertes Update und mehrere kleinere Cluster bieten hier wiederum mehr Flexibilität.
Zwei weitere wichtige Aspekte beim Cluster-Design sind Kapazität und Kapazitätsverschnitt, die Auswirkungen auf die Effizienz der Umgebung haben. Die Grundidee hinter einem Cluster ist natürlich die Hochverfügbarkeit (realisiert über den vSphere-HA-Cluster). Dafür stellen Sie entweder dedizierte Failover-Hosts oder umgerechnet einen entsprechenden Prozentsatz der Clusterkapazität zur Verfügung.
Nehmen wir die typischen N+1- und N+2-Hochverfügbarkeitsansätze (also ein oder zwei Failover-Hosts beziehungsweise deren Kapazität) und betrachten verschiedene Clustergrößen mit jeweils N+1 und N+2 in der Tabelle 1 auf dieser Seite. Diese zeigt Ihnen, dass der Kapazitätsverschnitt durch Failover-Ressourcen bei kleinen Clustern besonders hoch ist. Im Bereich von 16 bis 32 Hosts liegen Sie mit ein oder zwei Failover-Hosts immer im Bereich um 90 Prozent der nutzbaren Kapazität. vSphere 8 erlaubt im Übrigen eine maximale Cluster-Größe von 96 Hosts [4]. Unabhängig von der Host-Größe (dazu später mehr) ergibt es bei größeren Clustern eventuell Sinn, die Redundanz auf N+3 oder N+4 zu erhöhen.
Wie die Tabelle zeigt, ist die nutzbare Kapazität in 64- und 96-Host-Clustern selbst mit N+4 immer noch jenseits der 90-Prozent-Marke. Die tatsächliche Cluster-Größe müssen Sie mit den oben genannten Aspekten von Fall zu Fall definieren. Häufig ergeben sich in der Praxis Cluster-Größen automatisch aus der Anzahl der Workloads und der zu Grunde liegenden Host-Größe.
| Abzug Failover-Hosts | Nutzbare Kapazität in Prozent | |||
| Anzahl Hosts im Cluster | N+1 | N+2 | N+1 | N+2 |
|---|---|---|---|---|
4 |
1 |
2 |
75,0 |
50,0 |
8 |
1 |
2 |
87,5 |
75,0 |
16 |
1 |
2 |
93,8 |
87,5 |
32 |
1 |
2 |
96,9 |
93,8 |
64 |
1 |
2 |
98,4 |
96,9 |
96 |
1 |
2 |
99,0 |
97,9 |
| N+3 | N+4 | N+3 | N+4 | |
64 |
3 |
4 |
95,3 |
93,8 |
96 |
3 |
4 |
97,9 |
95,8 |
vSphere-Clustergrößen und nutzbare Kapazitäten
Daneben spielen jedoch weitere Faktoren beim Cluster-Design eine wichtige Rolle. Eine Grundregel lautet: Setzen Sie in einem Cluster immer gleiche oder gleichartige Hosts ein! Denken wir an eine Cloud, ist der Cluster die kleinste funktionale Einheit im Clouddesign und der einzelne Server die kleinste Austauscheinheit (FRA; Field Replaceable Unit). Im Fehlerfall wird also idealerweise der gesamte Server und nicht einzelne Komponenten ersetzt. Daher sollten Sie alle Server identisch ausstatten – nicht nur im Hinblick auf Netzwerkkarten, SmartNICs, GPUs, Disks/NVMe und so weiter, sondern auch im Hinblick auf RAM und den Prozessor.
Denn eine saubere Verfügbarkeitskalkulation (N+1, N+2, …) richtet sich entweder nach der standardisierten Host-Größe oder sollte in einem heterogenen Cluster den größten Host als Grundlage heranziehen. Neben einer komplizierteren Failover-Kalkulation sind aber auch Schwierigkeiten beim Lastausgleich (DRS Cluster) in einem heterogen ausgestatteten Cluster prognostizierbar. Setzen Sie daher auf gleiche Host-Größen und -ausstattung.
Zuvor haben wir bereits den Lifecycle Manager und die Cluster-Images angesprochen. Ein einheitlicher Hardwaretyp im Cluster erleichtert auch das Lifecycle-Management, da Sie mit den Cluster-Images auch Treiber und Firmware aktualisieren und dies selbstredend bei gleicher Hardwarebasis problemfrei funktioniert und damit den Betrieb Ihrer Umgebung massiv erleichtert.
Ein bekanntes Problem beim Hardwaretausch nach längerer Zeit ist, dass eventuell der Servertyp, aber nicht mehr die identische Hardware beim Hersteller verfügbar ist. Um diesen Fall abzudecken und einen neueren Server desselben Modells in einen bestehenden Cluster einzuführen, empfiehlt sich der EVC-Modus (Enhanced VMotion Compatibility). Diesen sollten Sie bereits beim Erstellen des Clusters einschalten. Das Pro und Contra von EVC können wir hier nicht ausführlich diskutieren – für Reparaturen und Austausch ist der Modus aber auf jeden Fall sinnvoll und auch nicht mit Nachteilen verbunden.
Ein weiterer Aspekt des Cluster-Sizing ist das Wachstum. In der Praxis bauen Sie ja keinen großen Cluster auf, auf dem kaum Workloads laufen, sondern der Bedarf nach Erweiterung der Umgebung ergibt sich meist im Laufe der Zeit. Bei Erweiterungen in kleinen Schritten gelten die Regeln aus dem vorhergehenden Abschnitt (Host-Größen, EVC-Modus). Daneben sollten Sie aber auch in der Gesamtumgebung dafür geplant haben mit freien IP-Adressen, Switchports und so weiter. Bei einem umfangreichen Ausbau ist der angesprochene Cloudansatz mit Erweiterung durch zusätzliche Cluster statt zusätzlicher Hosts für existierende Cluster durchaus sinnvoll.
Fazit
Wir haben gesehen, wie nützlich die Workload-Domains für die Planung und das Sizing einer vSphere-8-Infrastruktur sind. Und nachdem wir auf dieser Basis unseren Cluster dimensioniert haben, widmet sich Teil 2 dieser Workshopreihe den Details der Ausstattung wie Hardware, Storage und Netzanbindung.
(jp)
Link-Codes
[1] VMware Validated Designs (nicht mehr aktuell und offiziell supported): https://docs.vmware.com/en/VMware-Validated-Design/index.html
[2] Leitfaden vSAN Stretched Cluster: https://core.vmware.com/resource/vsan-stretched-cluster-guide
[3] vSAN Witness Appliance in VMC on AWS: https://blogs.vmware.com/virtualblocks/2018/09/27/vsan-witness-appliance-in-vmware-cloud-on-aws/
[4] Maximalkonfiguration von vSphere 8: https://configmax.esp.vmware.com/guest?vmwareproduct=vSphere&release=vSphere%208.0&categories=2-0,3-0