vSphere-7-Umgebungen planen
Auf dem Reißbrett
Veröffentlicht in Ausgabe 02/2021 - SCHWERPUNKT
Die Neuerungen in vSphere 7 gegenüber seinem Vorgänger sind nicht revolutionär, vielmehr ist die in einem gesättigten Marktsegment führende Technologie weiter gereift, öffnet sich dem Cloudgedanken und integriert das für viele Unternehmen so wichtige Container-Management. Dennoch sind in fast allen Bereichen kleine, aber wichtige Neuerungen enthalten, die eine Neubewertung der bisherigen Virtualisierungsstrategie angebracht erscheinen lassen. Bevor vSphere 7 in Ihrem IT-Budget und anschließend im Rechenzentrum Einzug hält, sollten Sie also, mit einem Whiteboard bewaffnet, Ihre Serverplattform kritisch unter die Lupe nehmen, um das Beste aus der neuen Generation der VMware-Virtualisierung herauszuholen.
Workloads identifizieren
Am Anfang der Planung eines virtualisierten Rechenzentrums steht immer die Betrachtung der abzubildenden Work-loads. Die Analyse muss nicht besonders detailliert sein, schließlich wird am Ende ohnehin eine Wachstumsreserve hinzugerechnet, die nicht präzise vorhersagbar ist. Der wichtigste erste Schritt ist vielmehr die Aufteilung der zu virtualisierenden Server und Anwendungen in "Blasen" oder Konfigurationsklassen, die ähnliche Merkmale aufweisen und von den anderen Klassen physisch getrennt werden müssen. Die Aufteilungskriterien können sehr unterschiedlich sein und aus technischen oder regulatorischen Rahmenbedingungen resultieren. Die wichtigsten Aspekte wollen wir daher nun betrachten.
Das erste Kriterium bilden die Sicherheitszonen. Viele Unternehmen und Organisationen haben Richtlinien, die eine strikte Trennung zwischen LAN, privater und öffentlicher DMZ vorschreiben. In diesem Fall sind separate Hosts, Cluster oder in manchen Fällen sogar vCenter nicht zu vermeiden. Seltener kommt eine solche Trennung als Ergebnis der Einführung von administrativen Tiers vor.
Die Neuerungen in vSphere 7 gegenüber seinem Vorgänger sind nicht revolutionär, vielmehr ist die in einem gesättigten Marktsegment führende Technologie weiter gereift, öffnet sich dem Cloudgedanken und integriert das für viele Unternehmen so wichtige Container-Management. Dennoch sind in fast allen Bereichen kleine, aber wichtige Neuerungen enthalten, die eine Neubewertung der bisherigen Virtualisierungsstrategie angebracht erscheinen lassen. Bevor vSphere 7 in Ihrem IT-Budget und anschließend im Rechenzentrum Einzug hält, sollten Sie also, mit einem Whiteboard bewaffnet, Ihre Serverplattform kritisch unter die Lupe nehmen, um das Beste aus der neuen Generation der VMware-Virtualisierung herauszuholen.
Workloads identifizieren
Am Anfang der Planung eines virtualisierten Rechenzentrums steht immer die Betrachtung der abzubildenden Work-loads. Die Analyse muss nicht besonders detailliert sein, schließlich wird am Ende ohnehin eine Wachstumsreserve hinzugerechnet, die nicht präzise vorhersagbar ist. Der wichtigste erste Schritt ist vielmehr die Aufteilung der zu virtualisierenden Server und Anwendungen in "Blasen" oder Konfigurationsklassen, die ähnliche Merkmale aufweisen und von den anderen Klassen physisch getrennt werden müssen. Die Aufteilungskriterien können sehr unterschiedlich sein und aus technischen oder regulatorischen Rahmenbedingungen resultieren. Die wichtigsten Aspekte wollen wir daher nun betrachten.
Das erste Kriterium bilden die Sicherheitszonen. Viele Unternehmen und Organisationen haben Richtlinien, die eine strikte Trennung zwischen LAN, privater und öffentlicher DMZ vorschreiben. In diesem Fall sind separate Hosts, Cluster oder in manchen Fällen sogar vCenter nicht zu vermeiden. Seltener kommt eine solche Trennung als Ergebnis der Einführung von administrativen Tiers vor.
Als Zweites sollten Sie Abhängigkeiten berücksichtigen: Oft gehört zur geplanten RZ-Topologie ein "Management-Cluster", in dem Workloads laufen, von denen weitere Systeme abhängen. Oft sind vCenter-Appliances, DNS-Server oder Quorum-Witness-Server für produktive Cluster in dieser Konfigurationsklasse untergebracht.
Auch die Lizenzierung ist ein wichtiger Faktor, da Softwareprodukte wie Microsoft SQL Server oder Oracle Database, die pro CPU-Kern lizenziert sind und dennoch eine VM-Mobilität erfordern, oft zu separaten Clustern für diese Technologien führen. Seit der Einführung von "shared nothing vMotion" in vSphere 5 ist die Diskussion über den Umfang der Lizenzierung nicht sofort durch separate Cluster erledigt. Doch ist es in der Regel bei einem Lizenzaudit eine gute Ausgangsposition, wenn die auditierte Organisation alles Notwendige unternommen hat, um wenigstens das automatische Verschieben einer VM auf nicht lizenzierte Hosts zu verhindern.
Bleibt schließlich noch das Leistungsprofil, denn unterschiedliche virtuelle Workloads erfordern unterschiedliche Hardware in den Hosts. Frontend-lastige Anwendungen wie Terminalserver und VDI profitieren von mehr CPU-Kernen, auch wenn sie jeweils nicht so hoch getaktet sind, und benötigen oft separate GPU-Beschleunigerkarten. Systeme für die Verarbeitung von hochsensitiven Transaktionen werden oft durch redundanten oder sogar stromunabhängigen Arbeitsspeicher abgesichert. Server auf dem Perimeter benötigen oft Anschluss an viele unterschiedliche, physisch voneinander separate Netzwerke, was zu mehr Netzwerkkarten führt als bei einem typischen "Arbeitspferd" im Inneren des Rechenzentrums.
Die gesamte weitere Dimensionierungs- und Hochverfügbarkeitsbetrachtung müssen Sie pro Konfigurationsklasse führen und dabei beachten, dass sowohl die Anforderungen als auch die Möglichkeiten der Hochverfügbarkeit von Klasse zu Klasse variieren können. So bringt es beispielsweise wenig Vorteile, einen Perimeter-Cluster über vier vorhandene Rechenzentren zu verteilen, wenn nur zwei von ihnen über die notwendigen Internet-Breakouts verfügen. Es kann aber durchaus sinnvoll sein, das Quorum für solch einen Cluster in einem Rechenzentrum zu platzieren, das am Cluster nicht teilnimmt, sofern die private Anbindung zwischen den einzelnen Rechenzentren robust genug dafür ist. Auch die pro Konfigurationsklasse benötigte vSphere-Edition kann unterschiedlich ausfallen – nicht jedes Einsatzszenario erfordert gleich die Enterprise-Plus-Features.
Sie können Ihre bestehende vSphere-Infrastruktur auch ohne Änderungen an der Topologie auf vSphere 7 upgraden, wenn Ihre Hosts, Storage und Netzwerk für die neue Version freigegeben sind. Allerdings bietet ein großes Upgrade immer eine Chance, die Umgebung zu optimieren. Diese Möglichkeit sollten Sie nicht versäumen.
Gut geschätzt ist halb gewonnen
Steht für jede einzelne Konfigurationsklasse die Auswahl der zu virtualisierenden Workloads fest, müssen Sie die zu erwartende Arbeitslast in dieser Blase quantifizieren. Die primären Faktoren, die Sie evaluieren müssen, sind CPU, Arbeitsspeicher und benötigte Festplattengröße. Für eine feinere Planung im nächsten Schritt ist es außerdem wichtig zu wissen, welche Netzwerkbandbreite und Festplattenperfor-mance von den VMs in der zukünftigen Umgebung benötigt wird.
Migrieren Sie die Workloads von einer früheren vSphere-Version, können Sie die Leistungsdaten optimalerweise dort erheben. Falls Ihnen weder vRealize Operations noch ein anderes dediziertes Performance-Monitoring-System zur Verfügung steht, können Sie zum Beispiel auf VMware Skyline [1] zurückgreifen. In gemischten Umgebungen aus vSphere, physischen Servern und anderen Hypervisor-Plattformen helfen Tools wie das Microsoft Assessment and Planning Toolkit [2] oder VeeamONE [3], einen Überblick über die benötigten Ressourcen zu gewinnen.
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.
Bedenken Sie bei der Auswertung der erhobenen Daten, dass die Tools zur Performance-Analyse bei dem zu erwartenden CPU-Verbrauch keine Informationen zum Multithreading-Verhalten der Work-loads liefern. Hat beispielsweise ein SQL-Server mit 16 physischen CPU-Kernen bei einer Langzeitbetrachtung 6 GHz verbraucht, bedeutet dies noch lange nicht, dass Sie diesen Server mit drei auf jeweils 2 GHz getakteten vCPUs glücklich machen können. Um diesen Umstand zu berücksichtigen, existieren mehrere Ansätze. Folgende Möglichkeit der Modellierung hat sich in der Vergangenheit gut bewährt:
- Sie kalkulieren den Bedarf in "Slots", die etwa der halben Taktrate der zukünftig eingesetzten CPUs entsprechen, also 1,3 GHz bei 2,6 GHz-Kernen (Intel Gold 6142) oder 1,8 GHz bei 3,6 GHz-Kernen (Intel Platinum 8156).
- Jeder Workload, dessen Multithreading-Verhalten bekannt ist, erhält so viele Slots, wie er Threads braucht. Ist darüber hinaus auch der tatsächliche Bedarf an CPU-Zyklen bekannt und liegt er höher als die Summe der aus dem Multithreading errechneten Slots, ist die Anzahl der Slots entsprechend zu erhöhen.
- Alle anderen Workloads, für die sich nur der "Bruttobedarf" an CPU-Leistung ermitteln lässt, erhalten so viele Slots, dass dieser Bedarf gedeckt werden kann. Verbraucht also ein zu virtualisierendes physisches System laut Erhebung 5 GHz, fließt es mit vier 1,3 GHz-Slots oder mit drei 1,8 GHz-Slots in die Berechnung ein.
- Für Systeme, deren Bedarf nicht bekannt ist, müssen Sie eine Schätzung aus Erfahrung treffen. Ein Windows-2008-R2-Server, der eine wenig anspruchsvolle Rolle, wie etwa als KMS-Server, ausführte, konnte noch mit einem Thread berechnet werden. Moderne Server-2016- oder 2019-Systeme müssen Sie mit mindestens zwei Slots in Ihre Berechnung aufnehmen.
Als Ergebnis erhalten Sie pro Konfigurationsklasse zwei Kennzahlen: die Anzahl der Slots und die gesamte erforderliche CPU-Bandbreite. Diese benötigen Sie bei der Dimensionierung von ESXi-Hosts und deren Aufteilung in Cluster.
Ähnliche Überlegungen müssen Sie auch bei der Dimensionierung des benötigten Arbeitsspeichers anstellen. Viele Systeme verhalten sich unterschiedlich, je nachdem, wieviel RAM sie "sehen", auch wenn sie nur einen kleinen Teil davon tatsächlich im Betrieb belegen. Damit Cluster-Funktionen wie HA und DRS korrekt funktionieren, sollten Sie die Überbuchung des Arbeitsspeichers kritisch betrachten und bei der Dimensionierung Ihrer Hosts und Cluster möglichst nicht verwenden.
Storage für virtuelle Maschinen planen
Eine sehr wichtige Entscheidung für Ihr zukünftiges vSphere-7-Rechenzentrum betrifft die Bereitstellung des für Ihre VMs benötigten Festplattenspeichers. Software-defined Storage (vSAN) von VMware ist inzwischen absolut ausgereift und kann auch für anspruchsvolle Work-loads zum Einsatz kommen. Mit der Version 7 kann ein vSphere-Cluster sogar für andere Systeme Speicher bereitstellen – sowohl blockbasiert über iSCSI als auch filebasiert in Form von NFS (v3 oder v4.1) oder SMB. Das macht die hyperkonvergente Option bei der Planung Ihres vSphere-Storage sehr attraktiv.
Setzt Ihre Organisation hingegen auf ein klassisches SAN und hat kürzlich eine weitere Investition in diesem Bereich getätigt, kann natürlich auch Ihre vSphere-Infrastruktur davon profitieren. Schauen Sie frühzeitig im VMware Compatibility Guide [4] nach, ob die verwendeten Storage-Systeme und Fabric-Switche eine Zulassung für vSphere 7 erhalten haben. Die Entscheidung für das Storage-Bereitstellungskonzept hat direkte Auswirkungen auf die weitere Planung.
Einige Faktoren helfen bei der Entscheidung für vSAN oder für ein klassisches SAN. Zunächst sollten Sie die Art und Konfiguration der vSphere-Server betrachten: vSAN-Knoten benötigen lokale Festplatten und passende Host-Bus-Adapter. Daher weisen diese Server in der Regel einen 2HE-Formfaktor auf. Gegenüber den sonst als Virtualisierungs-Host üblichen "Pizzaboxen" oder Blades weist solch ein Cluster einen deutlich höheren Platzbedarf im Rechenzentrum auf. Auch benötigen diese Hosts schnelle 10-/25-GBit/s-Netzwerkkarten und entsprechende Switch-Ports extra für den vSAN-Traffic, dafür aber keine Fibre-Channel-HBAs und keine Ports auf den Fabric-Switchen.
In Sachen Hochverfügbarkeit gelten für vSAN zum Teil andere Regeln als für herkömmliche vSphere-Cluster. So braucht ein Zwei-Knoten-Cluster oder ein Stretched-Cluster mit vSAN zwingend einen ESXi-Host als Quorum. Für Stretched-Cluster gelten sehr strenge Vorgaben in Bezug auf die Netzwerklatenz zwischen den Rechenzentrumsstandorten. Auch die Konfiguration der vSAN-Fault-Domains hat in einem herkömmlichen Compute-Cluster keine Entsprechung.
Bei der Planung von Compute-Ressourcen sollten Sie berücksichtigen, dass die vSAN-Funktionalität CPU und RAM auf jedem beteiligten Host verbraucht. Diese Ressourcen stehen virtualisierten Workloads nicht zur Verfügung. Der Speicherbedarf lässt sich nach einer Formel errechnen [5] und kann durchaus Werte von 40 bis 50 GByte erreichen. Bei der CPU gilt die Faustregel, dass 10 Prozent der verfügbaren Kapazität für vSAN reserviert bleiben müssen. Dieser Wert erhöht sich auf 15 bis 20 Prozent, wenn das vSAN stark überbucht ist und daher Komprimierung und Deduplizierung aktiviert werden müssen.
Abseits der Technik finden sich schließlich noch Kosten und "Politik": vSAN ist ein zu vSphere separates Produkt und kostet Geld. Auch sind vSAN-Knoten teurer als klassische Compute-Hosts ohne Festplatten. Dies kann zu Problemen führen, wenn Server und Storage aus separaten Budgets beschafft werden. Auch ein vom Storage-Team befürchteter Kontrollverlust über die Zuteilung von Festplattenplatz kann Gegenwind für vSAN bedeuten. Hier müssen Sie als Virtualisierungsarchitekt rechtzeitig gegensteuern und alle betroffenen Abteilungen mit an Bord nehmen.
Die Entscheidung "hyperkonvergent oder klassisch" muss nicht für das gesamte virtualisierte Rechenzentrum gleich ausfallen. Ist für ein vSphere-Cluster für SQL-Server die Anbindung an das bestehende Fibre-Channel-SAN Pflicht, weil die dortigen VMs mit physischen Servern geclustert werden müssen, kann ein Management- oder DMZ-Cluster dennoch auf vSAN setzen und so komplett autark von der restlichen Infrastruktur funktionieren.
Auch vSphere-Cluster für Desktopvirtualisierung können von vSAN profitieren, insbesondere wenn es sich bei der eingesetzten VDI-Lösung um das VMware-eigene Horizon View handelt. Hier ist sogar eine vSAN-Lizenz in den höheren Editionen des Produkts enthalten.
Einige der obigen Überlegungen müssen Sie auch dann anstellen, wenn Sie den Einsatz der anderen Komponente des "Software-defined Datacenter" von VMware planen – also der Netzwerkvirtualisierung NSX. Auch hier haben Sie es mit einem zusätzlichen Produkt zu tun, das eigene Lizenzkosten mitbringt und Ressourcen auf den ESXi-Hosts für sich beansprucht.
Langfristige Aspekte der RZ-Ausstattung
Je nachdem, wie Sie die Abschreibung von Servern oder deren Leasing in Ihrer Organisation handhaben, müssen Sie Ihre vSphere-Umgebung auf drei bis sieben Jahre vorausplanen. Auch wenn niemand sagen kann, wie sich die Welt im Allgemeinen und Ihr Betrieb im Speziellen in dieser Zeit verändert, steht dennoch fest, dass der Bedarf an Virtualisierungsleistung in Ihrem Rechenzentrum kontinuierlich steigen wird. Um diesem Wachstum zu begegnen, gibt es drei grundlegend unterschiedliche Strategien:
- Sie prognostizieren das gesamte Wachstum über den geplanten Lebenszyklus der Infrastruktur und legen die Dimensionierung Ihres Rechenzentrums von Anfang an entsprechend aus. Damit erreicht es theoretisch erst zum Ende der Abschreibungsfrist seine maximale Auslastung. Dafür müssen Sie innerhalb dieser Frist keine zusätzlichen Investitionen tätigen.
- Sie planen die Skalierung in größeren Blöcken. Solch ein Block kann zum Beispiel einen kompletten Vier-Knoten-Cluster, zusätzliche Festplatten-Shelves für das SAN und entsprechende Erweiterungsbaugruppen für Netzwerk- und Fabric-Switche beinhalten. Ist die maximale Nennkapazität der Anlage erreicht, wird ein ganzer Block angeschafft. Dies ist ein aufwendiger Vorgang, in den neben der Beschaffung auch Netzwerk- und Storage-Teams involviert sind.
- Sie legen die Infrastruktur so aus, dass sie in kleineren Einheiten nahtlos skaliert. Das ist insbesondere bei Einsatz von vSAN möglich. Dafür müssen Sie die Zusicherung des Managements haben, dass die Beschaffung benötigter Erweiterungen zeitnah erfolgt.
Aber Achtung: Planen Sie vSAN als Basis für die Skalierung Ihrer Plattform, müssen Sie die Besonderheiten der Lizenzierung dieses Produkts beachten. vSAN wird pro physischer CPU lizenziert, es lässt sich jedoch immer nur eine Lizenz pro Cluster zuweisen. Sie müssen also später in der Lage sein, zusätzlich erworbene Lizenzen mit den bereits vorhandenen zusammenzuführen. Bei OEM-Lizenzen, die Sie über Ihre Server-Lieferanten beziehen, ist das nicht immer ohne Probleme möglich. Klären Sie diese Frage also möglichst im Vorfeld.
Das kleine Cluster-Einmaleins
Ist der prognostizierte Bedarf an Compute- und Storage-Leistung pro Konfigurationsklasse bekannt, können Sie sich an die Dimensionierung der Hosts und Cluster machen. Dabei müssen Sie das geforderte Maß an Verfügbarkeit für die VMs in der jeweiligen Konfigurationsklasse berücksichtigen. Hier gibt es einige gängige Szenarien, welche davon zu Ihrem Rechenzentrum passen, hängt von der Art der virtualisierten Workloads und von der geographischen Verteilung Ihrer RZ-Standorte ab.
Eine gängige Forderung im Rechenzentrumsdesign ist die "N+2-Redundanz": Bei Wartung eines Hosts muss der unerwartete Ausfall eines weiteren Hosts tolerierbar sein, ohne dass dies die Leistung der virtualisierten Workloads beeinträchtigt. Haben Sie eine Anforderung dieser Art zu erfüllen, spielt die Clustergröße (Anzahl der Hosts im Cluster) eine entscheidende Rolle. Mit vSphere 7 kann ein Cluster bis zu 96 Knoten enthalten – bis zu 64, wenn vSAN im Cluster läuft. Vorherige Generationen konnten immerhin 64 Knoten pro Cluster unterstützen, ob mit oder ohne vSAN.
Dennoch designen Virtualisierungsarchitekten häufig kleinere Cluster und verschwenden damit massiv Hardwareressourcen. Nehmen wir an, die Workloads erfordern rein rechnerisch sieben Hosts für eine optimale Performance. Die N+2-Redundanz können Sie in diesem Fall mit neun Hosts erfüllen, indem Sie sie zu einem einzigen Cluster zusammenfassen. Bauen Sie hingegen das Rechenzentrum in Form von Vier-Knoten-Clustern auf, steht bei N+2-Redundanz in jedem dieser Cluster lediglich die Hälfte der Ressourcen für die produktiven Workloads zur Verfügung, und Sie benötigen vier Cluster, also 16 Hosts.
Gegen große Cluster wird manchmal das Argument angeführt, dass die Anzahl eingeschalteter VMs pro Cluster begrenzt ist. Allerdings liegt diese Grenze bei vSphere 7 – wie bei der vorherigen Generation – bei 8000 VMs, mit vSAN bei 6400 VMs [5]. Wir sprechen also über eine Packungsdichte von 100 VMs pro Host im vSAN (103 bei N+2-Redundanz) beziehungsweise von 83 VMs pro Host mit herkömmlicher Storage-Technologie (85 bei N+2-Redundanz). In der Praxis wird diese Grenze bei der Servervirtualisierung fast nie erreicht. Selbst bei VDI sind dreistellige Packungsdichten sehr selten und bringen deutliche Performance-Einbußen mit sich. Dennoch sollten Sie in Bezug auf die aktuell betrachtete Konfigurationsklasse auch die maximale Anzahl an VMs im Blick haben.
Fazit
Nicht nur die Neueinführung von vSphere 7 erfordert gründliche Planung, sondern auch der Umstieg verlangt vom IT-Verantwortlichen große Aufmerksamkeit in der Konzeption desselben. In Teil 2 dieses Artikels setzen wir die Vorbereitungen für vSphere-7-Cluster fort, stellen Überlegungen zur Georedundanz an und widmen uns der Hardware-Ausstattung des ESXi-Hosts. So präpariert sollte Ihnen der Umstieg leichtfallen.
(jp)
Link-Codes
[1] VMware Skyline: https://www.vmware.com/de/support/services/skyline.html
[2] Microsoft Assessment and Planning Toolkit: https://www.microsoft.com/en-us/download/details.aspx?id=7826/
[4] VMware Compatibility Guide: https://www.vmware.com/resources/compatibility/
[5] VMware Konfigurations-Maximalwerte: https://configmax.vmware.com/