vSphere-7-Umgebungen planen (2)
Richtfest
Veröffentlicht in Ausgabe 03/2021 - PRAXIS
Die Cluster-Arithmetik ändert sich dramatisch, wenn Sie Ihr Rechenzentrum über mehrere Standorte (Brandabschnitte oder georedundant verteilte RZ-Standorte) bereitstellen müssen. Die typische Anforderung an die Redundanz der vSphere-Plattform lautet in einem solchen Fall "Standort+1". Bei Wartung oder Ausfall eines Standorts muss also ein zusätzlicher Host ausfallen dürfen, ohne dass dies die Leistung der VMs dauerhaft beeinträchtigt. Bei zwei Standorten und gleichmäßiger Verteilung der Cluster-Knoten ist es erforderlich, dass weniger als die Hälfte der Hosts die gesamte Leistung erbringen können.
Im Beispiel aus dem ersten Teil des Artikels mit den VM-Workloads, die sieben Hosts auslasten, müssen an jedem der zwei Standorte acht Hosts vorhanden sein, insgesamt würde das Cluster also 16 Knoten umfassen. Bei drei RZ-Standorten müssten zwei Standorte die acht benötigten Hosts (sieben für die VMs und einen für den Ausfall) stellen. Das Cluster würde also mit 12 Knoten auskommen.
Umfasst eine Konfigurationsklasse sehr viele (oder sehr große) zu virtualisierende Workloads, kann es passieren, dass Sie innerhalb einer Konfigurationsklasse auch dann mehrere Cluster benötigen, wenn Ihr Design generell zu großen Clustern tendiert.
Die Cluster-Arithmetik ändert sich dramatisch, wenn Sie Ihr Rechenzentrum über mehrere Standorte (Brandabschnitte oder georedundant verteilte RZ-Standorte) bereitstellen müssen. Die typische Anforderung an die Redundanz der vSphere-Plattform lautet in einem solchen Fall "Standort+1". Bei Wartung oder Ausfall eines Standorts muss also ein zusätzlicher Host ausfallen dürfen, ohne dass dies die Leistung der VMs dauerhaft beeinträchtigt. Bei zwei Standorten und gleichmäßiger Verteilung der Cluster-Knoten ist es erforderlich, dass weniger als die Hälfte der Hosts die gesamte Leistung erbringen können.
Im Beispiel aus dem ersten Teil des Artikels mit den VM-Workloads, die sieben Hosts auslasten, müssen an jedem der zwei Standorte acht Hosts vorhanden sein, insgesamt würde das Cluster also 16 Knoten umfassen. Bei drei RZ-Standorten müssten zwei Standorte die acht benötigten Hosts (sieben für die VMs und einen für den Ausfall) stellen. Das Cluster würde also mit 12 Knoten auskommen.
Umfasst eine Konfigurationsklasse sehr viele (oder sehr große) zu virtualisierende Workloads, kann es passieren, dass Sie innerhalb einer Konfigurationsklasse auch dann mehrere Cluster benötigen, wenn Ihr Design generell zu großen Clustern tendiert.
Falls Sie in solche Größenordnungen kommen, sollten Sie auch andere Grenzwerte überprüfen, die VMware für die vSphere-Produkte definiert hat. Dafür hat der Hersteller ein übersichtliches Werkzeug im Internet veröffentlicht [1].
Die obigen Rechenbeispiele gehen der Einfachheit halber davon aus, dass der Typ und die Anzahl der physischen CPUs pro Host bereits feststehen. Wir werden diese Festlegung in einem nächsten Schritt vornehmen.
Redundanzen für mehrere Standorte planen
Gilt es, Anforderungen zu erfüllen, die Standortredundanzen beinhalten, müssen Sie sehr sorgfältig für den Fall planen, dass nicht die Server eines Standorts, sondern lediglich die Standortverbindungen ausfallen. In diesem Fall muss die "Isolations-Erkennung" erreichen, dass der korrekte Standort sich selbst als "nicht betroffen" einstuft und alle VMs in diesem Standort starten. Dafür bedient sich vSphere HA zweier Mechanismen:
Die Heartbeat-Datastores (gemeinsam genutzte Datastores) beinhalten einige kleine Dateien, die die Hosts jeweils mit Sperren versehen. Damit kann jeder Host feststellen, welche anderen Hosts noch Zugriff auf die Dateien der VMs haben – und ob er selbst die Datastores noch erreichen kann. Da in einem mehrere Standorte überspannenden Cluster die Datastores jedoch üblicherweise auf jeden Standort repliziert werden, ist diese Erkennung nicht besonders zuverlässig. Sie sollten also, falls möglich, Heartbeat-Datastores wählen, die nur in einem Standort existieren. Legen Sie im Zweifel solche nicht gespiegelten Datastores extra für das Heartbeat an.
Der zweite Mechanismus bedient sich der Isolationsadressen: Erhält ein Host keinen Heartbeat von anderen Hosts und vor allem vom HA-Master, prüft er per ICMP die Erreichbarkeit des Default-Gateways seines Managementnetzwerks und betrachtet sich als isoliert, falls er diesen nicht erreicht. Ist das Managementnetzwerk über alle Standorte auf Layer 2 verteilt, ist dies bereits ein ganz guter Indikator für die Isolation. Verfügt hingegen jeder Standort über ein eigenes Managementsubnetz und ist das Gateway demnach an jedem Standort lokal, müssen Sie im vCenter zusätzliche Isolationsadressen eintragen, deren Nichterreichbarkeit ein Hinweis auf die Isolation ist.
Das Standardwerk über Verhaltensalgorithmen und die Optimierung von vSphere-Clustering ist bereits seit vielen vSphere-Generationen das "vSphere Clustering Deep Dive" von Frank Denneman, Duncan Epping und Niels Hagoort. Die letzte veröffentlichte Version behandelt vSphere 6.7, eine auf 7.x aktualisierte Fassung befindet sich in Vorbereitung. Sie können das Buch über den regulären Handel beziehen oder kostenfrei als eBook herunterladen [1]. Dieses exzellente Werk und die offizielle Dokumentation des Herstellers sollten Sie unbedingt konsultieren, wenn Sie ein Rechenzentrum über mehrere Standorte planen und umsetzen müssen.
Host-Design mit CPU und RAM
Steht die Topologie Ihrer Cluster in der jeweiligen Konfigurationsklasse fest, können Sie die Hosts dimensionieren, die diese Cluster bilden. Als Erstes bestimmen Sie den Typ der zu verwendenden CPU. Dafür müssen Sie zunächst einmal zusammen mit Ihrem IT-Sicherheitsbeauftragten das Thema "Spectre-Sicherheitslücke" bewerten und für jede Konfigurationsklasse eine Entscheidung darüber treffen, wie damit umzugehen ist.
Auch unter vSphere 7 sind ESXi-Hosts mit den meisten Intel- und zahlreichen AMD-Prozessoren potenziell anfällig für die als "Spectre" bekannt gewordene Sicherheitslücke. Die Serverhersteller haben inzwischen Updates für BIOS und Microcode veröffentlicht, jedoch bieten sie keine Garantie, dass sich die anfälligen CPU-Algorithmen nicht durch Schadcode in einer VM angreifen lassen. VMware hat dafür Anpassungen am CPU-Scheduler vorgenommen, die es für die Version 6.5 veröffentlicht hat und die auch in der aktuellen Version 7.1 enthalten sind.
Die "Hammer-Methode" zur Umgehung der Spectre-Lücke besteht freilich darin, Hyperthreading auf Hardware-Ebene abzuschalten. Damit vergeben Sie jedoch einen Großteil der Effizienz und Flexibilität Ihrer vSphere-Umgebung in Bezug auf die CPU-Auslastung, denn Ihre VMs müssen mit den CPU-Kernen auskommen, die physisch in den Prozessoren vorhanden sind. Die Alternativen, geordnet nach dem Schutzbedarf der in Ihren VMs verarbeiteten Daten, liefert die Tabelle "Einsatz von HyperThreading in vSphere 7".
| Einsatz von HyperThreading in vSphere 7 | |||
| HyperThreading | Scheduler | Schutz | Einfluss auf die Leistung |
| Deaktiviert | Default: Mitigation ignoriert MitigationIntraVM ignoriert | Höchster | Sehr hoch, je nach Last |
| Aktiv | SCAS-v1:Mitigation = true MitigationIntraVM = true | Hoch (zwischen Prozessen in VM) | Hoch (bis 30 Prozent) |
| Aktiv | SCAS-v2: Mitigation = true MitigationIntraVM = false | Mittel (zwischen VMs auf gleichem Host) | Niedrig (weniger als 10 Prozent) |
| Aktiv | Default: Mitigation = false MitigationIntraVM ignoriert | Niedrig | Kein Einfluss |
Eine ausführliche Beschreibung der Handlungsalternativen und der Entscheidungswege beim Scheduler zeigt [2]. Die Quantifizierung des tatsächlichen Einflusses auf die Performance ist schwierig und keine exakte Wissenschaft. Allerdings informieren die Eigenschaften des Hosts bei der Wahl des SCAS-v1-Schedulers nur über die physischen Kerne, was das Potential hat, diverse Skripte und Tools zu "verwirren", die das Maß an Überbuchung und somit den CPU-Ressourcenbedarf des Hosts bestimmen. Die Ergebnisse solcher Auswertungen sind in diesem Fall mit gesunder Skepsis zu betrachten.
IT-Administrator Sonderheft vSphere 7
Das erste Sonderheft des IT-Administrator 2021 "VMware vSphere 7: Server, Netze und Storage virtualisieren" liefert auf 180 Seiten Know-how zur Planung, Verwaltung und Absicherung der neuen vSphere-Version. Nach einer Übersicht der Lizenzformen und Gedanken zum Sizing der vSphere-Landschaft widmet sich das Autorenteam ausführlich Fragen der Migration. Neben vSphere-7-Pre-Upgrade-Checks und dem Vorgehen bei der Migration zeigt das Sonderheft auch, wie die Infrastruktur zu gestalten ist, um Werkzeuge wie den Recovery Manager oder NSX optimal mit der neuen Version zu betreiben. Anschließend wenden wir uns ausführlich der Hochverfügbarkeit und der Steuerung der Umgebung mit Profilen zu.Im Abschnitt zur Systemsicherheit beschreiben die Autoren dann im Detail eine sichere Architektur und Betrieb von vSphere 7 sowie Maßnahmen zur Datensicherheit. Natürlich bekommt auch das Management von VMs und Containern im Sonderheft einen Platz, bevor wir uns den Optionen zur Virtualisierung von Netzwerk und Storage zuwenden.Abgerundet wird das Sonderheft durch Themen zur Cloudintegration von vSphere und dessen Einsatz in der Hybrid Cloud sowie zu praxiserprobten Maßnahmen und Vorgehensweisen beim Troubleshooting. Stößt der Admin bei einem dieser Themen auf die Grenzen des Machbaren, helfen die freien und kommerziellen Tools weiter, die das Sonderheft vSphere 7 vorstellt.Das Sonderheft ist ab Anfang April 2021 verfügbar und kostet für Abonnenten des IT-Adminstrator 24,90 Euro, für Nicht-Abonnenten werden 29,90 Euro fällig.
Ein weiterer wichtiger Parameter ist der Grad an CPU-Überbuchung (Overcommitment), den Sie in Ihrer Virtualisierungsumgebung zulassen wollen. Dies sind die gesamten vCPUs, die Sie für eine Konfigurationsklasse von Workloads vergeben müssen, geteilt durch CPU-Kerne, die für diese Workloads physisch zur Verfügung stehen.
Der Überbuchungsgrad ist eine Zahl, die größer oder gleich eins ist, in gut laufenden Umgebungen bewegt sie sich meistens im Bereich von 1,3 bis 1,7. Werte über zwei sind aber auch keine Seltenheit. Ein gutes Gefühl für den optimalen Wert können Sie nur entwickeln, wenn Sie die betroffenen Work-loads bereits länger virtualisiert betreiben (nicht unbedingt unter vSphere) und die CPU-Auslastung dabei im Auge behalten. Ist Hyperthreading aktiviert, sind in Bezug auf das Overcommitment die virtuellen CPU-Kerne zu berechnen.
Anzahl der CPU-Kerne berechnen
Haben Sie den aus Security-Sicht passenden Scheduler ausgewählt und den Überbuchungsgrad bestimmt, können Sie den Bedarf an tatsächlichen CPU-Kernen errechnen. Nehmen Sie hierfür die anfangs bestimmte Anzahl der "halben CPU-Slots" und wandeln Sie diese in tatsächliche CPU-Kerne im Bezug zum erstgenannten Scheduler wie nachfolgend gezeigt um:
- HT deaktiviert: Nslots * 1,5 / OCPU
- SCAS-v1: Nslots * 0,8 / OCPU
- SCAS-v2: Nslots * 0,6 / OCPU
- Kein Spectre-Schutz: Nslots * 0,5 intel/ OCPU
Hier ist "Nslots" die Gesamtzahl der für die Workloads benötigten Slots und OCPU der Überbuchungsgrad. Haben Sie für die Workloads zum Beispiel 1000 Slots zu je 1,3 GHz geschätzt, benötigen Sie bei der Verwendung von SCAS-v2 und einem tolerierten Überbuchungsgrad von 1,5 insgesamt 400 CPU-Kerne mit einer Taktrate von 2,6 GHz für diese Workloads.
Kommt vSAN zum Einsatz, schlagen Sie 10 Prozent auf diese Zahl auf, beim Einsatz von NSX noch einmal 5 Prozent. Wenn also in der beispielhaft betrachteten Konfigurationsklasse vSAN eingeplant ist, benötigen Sie 440 Kerne. Jeder Host benötigt zwei (Hyperthreading-)CPU-Kerne für seinen eigenen Betrieb. In unserem Beispiel ist Hyperthreading aktiviert, wir überlassen also einen physischen CPU-Kern dem ESXi-Hypervisor. Fassen wir die benötigten Hosts zu einem Cluster mit N+2-Redundanz zusammen, ergibt sich die Berechnung
(Nsockets * Ncores - 1) * (Nhosts - 2) = 440
Setzen Sie Dual-Socket-Server mit IntelGold-6142-CPUs (16 Kerne mit 2,60 GHz) ein, errechnet sich, leicht abgerundet:
Nhosts = 440 / (2 * 16 - 1) + 2 = 16
Mit diesem Prozessortyp benötigen Sie also 16 Hosts im Cluster. Mit einer Silver-4112-CPU mit vier Kernen kommen Sie auf 65 Hosts und können kein einzelnes vSAN-Cluster mehr bauen, während Sie bei einer Platinum-8168-CPU bereits mit 12 Hosts auskommen. Ist also beispielsweise bekannt, dass die Workloads keine besonders hohen Anforderungen an die Festplatten-I/O stellen, kann sich der Einsatz teurerer Prozessoren lohnen, um die Anzahl der Hosts zu reduzieren.
Dabei müssen Sie aber beachten, dass das Lizenzmodell von vSphere eine Änderung in Bezug auf die Anzahl der CPU-Cores erfahren hat [3]. Die Lizenzierung erfolgt zwar wie bisher pro CPU-Sockel, jedoch deckt eine Lizenz maximal 32 Kerne in diesem Sockel ab. Haben Sie sich für CPUs mit mehr als 32 Kernen entschieden, müssen Sie für jeden Prozessor eine zweite vSphere-Lizenz der gewählten Leistungsstufe zuweisen.
Haben Sie die Anzahl der Hosts aus CPU-Sicht ermittelt, können Sie sich der RAM-Dimensionierung zuwenden. Auch hier sollten Sie den Bedarf von vSAN [4] und des Hosts selbst (4 GByte) berücksichtigen. Benötigen unsere beispielhaften Workloads mit 1000 CPU-Slots insgesamt 5 TByte RAM und müssen diese, wie in der ersten Berechnungsvariante ermittelt, auf 14 Cluster-Knoten ausgeführt werden, liegt der RAM-Bedarf Ihrer VMs bei 366 GByte pro Host. Falls die gewählte vSAN-Konfiguration 40 GByte benötigt, haben Ihre ESXi-Hosts einen Bedarf von 410 GByte.
Diese müssen Sie nach Vorgaben Ihres Serverherstellers soweit aufrunden, dass eine Speicherbelegung mit maximal erreichbarer Taktrate erzielt wird. In unserem Beispiel landen Sie vermutlich bei 512 GByte RAM pro Host, womit noch einige Luft nach oben ist. Möchten Sie RAM sparen, wird die nächstkleinere optimale Konfiguration bei 384 GByte liegen und somit ein leichtes Memory Overcommitment eintreten.
ESXi 7 besser nicht auf Speicherkarten installieren
Falls Sie bisher gewohnt waren, Ihren Hypervisor auf einer dedizierten Festplatte oder gar einem RAID1-Verbund zu installieren, können Sie diese Praxis auch in der neuen Version uneingeschränkt beibehalten. Sind Sie hingegen Verfechter der ESXi-Installation auf SD-Karten oder USB-Sticks, sollten Sie diese Vorgehensweise spätestens mit der Bestellung neuer Server für vSphere dringend überdenken.
Obwohl Sie nach wie vor eine 8-GByte-Speicherkarte für Ihre ESXi-Installation verwenden können, funktioniert der so installierte Hypervisor nicht optimal, insbesondere in Bezug auf die Arbeitsspeicheroptimierung. Sie sollten die Speicherkarte lieber mit einer lokalen SSD-Festplatte von mindestens 32 GByte kombinieren oder ganz durch eine solche Festplatte ersetzen. Die von VMware empfohlenen Konstellationen für die Installationslaufwerke zeigt [5].
Eine großzügige Festplattenzuweisung wird belohnt, wenn Sie viele Drittherstellertreiber und -tools im Hypervisor installieren müssen. NSX, nVIDIA-GRID-Karten, einige RAID- und Fibre-Channel-Adapter sowie Server allgemein bringen zum Teil umfangreiche Tools mit. In den vergangenen vSphere-Versionen haben solche Installationen die auf 256 MByte dimensionierte Bootbank gesprengt. Auch wenn es Ihnen gelungen ist, durch das Entfernen nicht genutzter VIBs ausreichend Platz für benötigte Pakete freizuräumen, wurden Ihre Bemühungen spätestens beim nächsten Update der Servertreiber zunichtegemacht. Mit ESXi 7 ist damit Schluss, sofern Sie dem Hypervisor eine ordentlich bemessene Festplatte spendieren.
Ist die Festplatte 142 GByte oder größer, stellt das System alles über 138 GByte als neuen Datastore zur Verfügung. Falls die verwendete SSD nicht besonders hochwertig und eine schnelle Zerstörung der Zellen durch intensives Schreiben zu befürchten ist, sollten Sie diesen Datastore unverzüglich nach der Installation entfernen.
Migration frühzeitig planen
Planen Sie die Migration auf vSphere 7 als Teil der Bereitstellung der neuen Version in Ihre betrieblichen Abläufe ein. Je nachdem, wie gravierend die Änderungen an der Architektur Ihrer Virtualisierungsplattform ausfallen, können Sie ein Upgrade durchführen, eine Koexistenz innerhalb einer vCenter-Instanz oder einen Side-by-Side-Betrieb mit Inter-vCenter-Migration der VMs vorsehen.
Der Aufbau einer vSphere-7-Umgebung beginnt mit dem vCenter, das Sie noch auf einem alten vSphere-Cluster bereitstellen und später umziehen können. Das vCenter 7.x unterstützt nur eine Bereitstellungsart: die virtuelle Appliance (VCSA) mit einem eingebetteten Platform Services Controller (PSC). Das Windows-vCenter mit einer SQL-Datenbank ist mit vSphere 7 Geschichte. Falls Sie von einer VCSA-Architektur mit Distributed PSC kommen, wird der PSC durch den Upgrade-Assistenten auf die neue vCenter-7-Appliance konsolidiert.
Auch vom Windows-vCenter kommend ist die Migration mittels Upgrade-Assistent möglich und unterstützt. Es gelten allerdings strikte Voraussetzungen im Hinblick auf den Versions- und Patchstand des Ursprungs-vCenters. Sie müssen also möglicherweise Ihr bestehendes vCenter zuerst innerhalb seiner Version aktualisieren, bevor Sie auf Version 7.x migrieren können.
Falls Sie historische Daten (Konfigurationsänderungen und Leistungsdaten) von einem bestehenden vCenter-System übernehmen möchten, stehen Ihnen zwei Verfahren zur Verfügung:
- Übernahme während des Upgrades: Diese ist in allen Konstellationen möglich, kann aber bei hohen Datenvolumen lange dauern. In dieser Zeit steht die vCenter-Funktionalität nicht zur Verfügung.
- Übernahme nach dem Upgrade: Dies geschieht, während das neue vCenter 7.x bereits die vSphere-Umgebung verwaltet. Allerdings ist diese Art der Übernahme ausschließlich aus der externen SQL-Datenbank eines Windows-vCenters möglich. Nachträgliche Datenübernahme aus der Embedded-PostgreSQL-Datenbank wird weder unter Windows noch aus einer VCSA unterstützt.
Fazit
Der Umstieg auf VMware vSphere 7 kann ein einfaches Upgrade sein oder mit einem kompletten Redesign Ihrer Virtualisierungsplattform einhergehen. In jedem Fall ist es notwendig, dass Sie sich mit den Neuerungen der neuen Version vertraut machen und diese beim Design sowie der Planung der Migration berücksichtigen. Nur so werden Sie im nächsten Lebenszyklus Ihrer Umgebung für eine optimale Performance und Resilienz Ihrer virtuellen Workloads sorgen können.
(jp)
Link-Codes
[1] vSphere 6.7 Clustering Deep Dive eBook: https://www.rubrik.com/en/resources/white-papers/19/clustering-deep-dive-ebook/
[2] Auswahl eines vSphere-Schedulers: https://blogs.vmware.com/vsphere/2019/05/which-vsphere-cpu-scheduler-to-choose.html/
[3] VMware-Update zum CPU-Lizenzmodell: https://www.vmware.com/company/news/updates/cpu-pricing-model-update-feb-2020.html/
[4] vSAN-Speicherbedarf: https://kb.vmware.com/s/article/2113954/
[5] ESXi-7-Systemvoraussetzungen: https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.esxi.upgrade.doc/GUID-DEB8086A-306B-4239-BF76-E354679202FC.html