Fügen Sie einen vSphere-Cluster zur bestehenden Virtualisierungsfarm hinzu, bauen ein ganz neues virtuelles Rechenzentrum auf VMware-Basis auf oder planen ein größeres Update Ihrer bestehenden vSphere-Umgebung, lohnt es sich, den physischen Unterbau der Virtualisierung genau anzuschauen. Zu den wichtigsten Punkten gehören dabei die Konfigurationseinstellungen der Hardware, oft salopp als "BIOS-Einstellungen" bezeichnet. Dabei booten heutzutage die meisten Server nicht mehr im BIOS-, sondern im UEFI-Modus.

Es gibt jedoch generell eine Fülle von Einstellungen, mit denen Sie das Verhalten der Hardware (CPU, RAM, Storage, Netzwerk) beeinflussen und die sich nicht ohne einen Neustart verändern lassen. Die verfügbaren Settings unterscheiden sich sehr stark je nach Serverhersteller, Modellreihe und Generation. Die möglichen Stellschrauben genau unter die Lupe zu nehmen, lohnt sich also selbst dann, wenn Sie bereits Erfahrung mit dem Servertyp in einer früheren Generation haben.

In größeren Umgebungen sind Server oft in ein zentrales Hardwaremanagement eingebunden (beispielsweise OneView bei HPE oder OpenManage bei DELL). Diese Werkzeuge ermöglichen eine zentrale Konfiguration der Hardware. So können IT-Verantwortliche neu hinzukommende Server mit dem gleichen Satz an Hardwarekonfigurationen versehen wie die Bestandsserver, ohne dass sie bei jeder Maschine einzeln Hand anlegen müssen. In einer solchen Umgebung ist es kontraproduktiv, Einstellungen an einzelnen Servern per Hand vorzunehmen, denn dadurch würde eine Diskrepanz zwischen zentral gespeicherten Profilen und tatsächlichen Konfigurationen entstehen.

Als erste Maßnahme sollten Sie stets dafür sorgen, dass das BIOS und auch die sonstige Firmware Ihrer Hosts auf dem aktuellen Stand sind. Dabei lohnt sich ein Blick in die VMware-Compatibility-Datenbank, denn die Support-Aussage von VMware für jeden Hardwaretyp bezieht sich auf bestimmte Firmware-Versionen. Viele Servermodelle verfügen über "Workload-Profile", also eine Möglichkeit, schnell verschiedene Systemparameter auf Werte einzustellen, die einem bestimmten Einsatzzweck des Servers (Rechenleistung, Antwortzeit, Energieeffizienz et cetera) entsprechen. Gehört Ihr Servertyp dazu, sollten Sie das Workload-Profil, das Ihren Wünschen am ehesten entspricht, zuerst wählen und alle weiteren Einstellungen ausgehend von diesem Profil vornehmen.

Wir betrachten nun die wichtigsten Einstellungen, die sich auf das Verhalten Ihres Hardwareservers in seiner Rolle als ESXi-Host auswirken. Als Erstes sind die "Virtualization Features" zu nennen, die aktiviert sein müssen, damit der Typ 1-Hypervisor ESXi seinen Dienst verrichten kann. Auf Intel-Systemen ist das Feature "Virtualization Technology" (VT) für die Implementierung der "Secure Virtual Machine" zuständig, die das Ausführen von 64-Bit-Gastbetriebssystemen erlaubt. Auf den aktuellen Chipset- und CPU-Generationen heißt die grundlegende Funktion "VT-x", wobei das x für "x86" steht. Weitere im Artikel [1] beschriebene Virtualisierungsfunktionen sind VT-D (exklusives Durchreichen von PCI-Geräten an virtuelle Maschinen) und VT-C, meist als SR-IOV in den BIOS-Menüs abgebildet (Virtualisierung von Gerätefunktionen). Eine ähnliche Auswahl von Virtualisierungsfunktionen, die ebenfalls über das BIOS steuerbar sind, bietet auch AMD [2] – interessanterweise ist VMware dort nicht als "Virtualisierungspartner" aufgeführt.

Der nächste wichtige Wert ist "Boot Time Optimizations": Obwohl ein Host mitunter Wochen oder sogar Monate ohne Neustart laufen kann, haben Admins ein großes Interesse daran, dass ein Reboot möglichst schnell abläuft. In diesem BIOS-Abschnitt haben Sie die Möglichkeit, einige Prüfungen und Optimierungen während der Bootsequenz abzuschalten. Allerdings kann sich ein zu rigoroses Beschleunigen des Bootvorgangs negativ auf die Stabilität des Servers auswirken, zum Beispiel wenn wichtige Hardwarechecks entfallen. Mit dem Feature "Boot Order" legen Sie – je nachdem, ob Sie einen lokalen Datenträger, eine LUN auf einem SAN als Bootdisk oder PXE für AutoDeploy zum Starten Ihres ESXi verwenden – das gewählte Bootmedium auf Platz 1 in der Bootreihenfolge.

Unter "Processor and Memory Options" nehmen Sie normalerweise für einen klassischen Virtualisierungshost keine besonderen Einstellungen vor. Doch für Work-loads, die eine vollständige Konsistenz des Arbeitsspeichers erfordern, ist hier beispielsweise die Spiegelung der RAM-Bausteine einstellbar. Eine Funktion, von der Sie im ESXi-Betrieb definitiv die Finger lassen sollten, ist das bedarfsgesteuerte temporäre Abschalten nicht verwendeter CPU-Kerne, das einige Chipsätze anbieten. Und auch die permanente Deaktivierung von CPU-Kernen sollte nur in absoluten Ausnahmefällen zum Einsatz kommen. Meist sorgen Lizenzgründe dafür, dass Admins die Anzahl der Kerne pro Sockel künstlich reduzieren und hier Hand anlegen.

Die aus ESXi-Sicht wichtigste Einstellung, die Sie im BIOS vornehmen können und in der Regel auch müssen, ist das Energieprofil des Servers und vor allem der CPU. Die Zeiten des Turbo-

Mode-Schalters am Computer sind schon lange vorbei. Prozessoren haben heute die Fähigkeit, ihre Taktfrequenz abhängig von der Rechenlast anzupassen und sich sogar selbst in den Schlaf zu versetzen, falls das ausgeführte Betriebssystem länger inaktiv ist. Und die Motherboards verfügen über Schnittstellen, die es dem Betriebssystem erlauben, die Energiefunktionen nach eigenen Algorithmen zu steuern.

Im Sinne der Green IT und der Klimaneutralität der Rechenzentren erscheint es IT-Verantwortlichen oft attraktiv, diese Energiesparfunktionen auch im Server- und speziell im Virtualisierungsbereich einzusetzen. Schließlich verbraucht eine aktuelle Intel-Xeon-Gold-CPU je nach Modell zwischen 140 und 235 Watt, was im Durchschnitt für einen Zwei-Wege-Server 9 kWh pro Tag und über 3 MWh pro Jahr allein für die CPUs ergibt.

Beim Betrieb virtualisierter Rechenzentren bleibt all das leider eine schöne Theorie: Das "ESXi Performance Best Practices"-Whitepaper [3] empfiehlt, die Steuerung der Energieoptionen dem ESXi-Hypervisor zu übertragen, und verweist weiter auf den "ESXi Resource Management Guide", um die richtige Richtlinie für Ihren speziellen Einsatz zu wählen. Diese Konstellation erwartet auch die "VMware Health Check Analyzer"-Appliance, falls Sie Ihre vSphere-Infrastruktur einem Hersteller-Healthcheck unterziehen.

Die Erfahrung aus dem Betrieb und dem Performance-Troubleshooting von virtualisierten Rechenzentren spricht jedoch eine andere Sprache. In Umgebungen mit hoher Dichte und Auslastung von virtuellen Maschinen muss das Power-Profil der Hosts auf "High Performance" stehen, um optimale Ergebnisse zu erzielen. Bei aktuellen Servern führender Hersteller kann die Einstellung im BIOS auf "OS Controlled" lauten und in ESXi auf "High Performance". Auf der sicheren Seite sind Sie jedoch, wenn Sie das "High Performance"-Profil bereits im BIOS festlegen. In diesem Fall laufen Ihre CPUs mit der maximalen Taktfrequenz und liefern stetig die Rechenleistung aus, die für den Betrieb Ihrer VMs notwendig ist.

Sind Sie gehalten, Energie in Ihrem virtualisierten RZ zu sparen, können Sie dies mit dem Herunterfahren einzelner Hosts erreichen, wenn – beispielsweise nach Feierabend – der Anspruch and die Leistung sinkt. Besonders gravierend ist dieser Effekt in Clustern, die VDI-Maschinen oder Terminalserver beherbergen und deren Leistungsaufnahme daher linear mit der Anzahl der aktuell angemeldeten Benutzer skaliert. VMware bietet für diesen Anwendungsfall bereits seit vSphere 3 das "Distributed Power Management" (DPM), das bei sinkender Last die VMs mittels DRS auf wenige Hosts im Cluster konsolidiert und die überschüssigen Hosts herunterfährt.

Um die Hosts bei steigender Last wieder hochzufahren, war ursprünglich das standardmäßige Wake-On-LAN (WoL) vorgesehen – eine weitere Funktion, die Sie bei Bedarf im BIOS einstellen müssen. Seit vSphere 4 unterstützt DPM die weitaus komfortablere IPMI-Schnittstelle, mit der alle kompatiblen Server ausgestattet sind. Dabei kommuniziert Ihr vCenter direkt mit dem Hardwaremanagement des einzuschaltenden Servers (iLO, iDRAC, iRMC und so weiter). Hierfür ist ein entsprechend autorisiertes Benutzerkonto erforderlich. Dieses können Sie über das zentrale Servermanagement oder lokal auf jedem Host einzeln hinzufügen und berechtigen.

 Die für das Einschalten eines Servers über IPMI notwendigen Berechtigungen sind von Hersteller zu Hersteller unterschiedlich. In manchen Konstellationen muss der entsprechende Benutzer volle Administratorrechte auf der Hardware-Verwaltungsschnittstelle bekommen.

Leider stößt DPM genau in dem Bereich auf seine Grenzen, wo die größten Energieeinsparungen zu erwarten sind: bei hyperkonvergenten Clustern mit VDI-Workloads. Durch die Notwendigkeit, Daten im vSAN in hinreichender Güte vorzuhalten, lassen sich nicht so viele Hosts gleichzeitig herunterfahren, wie für eine signifikante Energieeinsparung nötig wäre. Hier bleibt Ihnen nur die Möglichkeit, mittels Orchestrierung die Energierichtlinie der Hosts nach Feierabend anzupassen, sodass die Energiesparfunktionen der Hardware zum Einsatz kommen. Ein solches Konstrukt müssen Sie unbedingt ausgiebig testen und im Betrieb genau beobachten, damit das Nutzererlebnis der VDI-Nutzer nicht beeinträchtigt wird.

Bereits seit vielen CPU-Generationen verfügen Intel-Prozessoren über das Hyperthreading-Feature (HT), womit dem Betriebssystem doppelt so viele CPU-Kerne angeboten werden wie in der CPU physisch vorhanden sind. Nach anfangs recht widersprüchlichen Empfehlungen ist VMware zwischenzeitlich zur Ansicht gelangt, dass Hyperthreading auch in der Virtualisierung ein wichtiges Feature ist, das die Flexibilität der CPU-Zuweisung erhöht und so die Gesamtperformance deutlich steigert.

Die im Januar 2018 veröffentlichten Sicherheitslücken "Spectre" und "Meltdown" sowie deren Nachfolger "Zombieload" und "L1TF-VMM", die von der Hyperthreading-Implementierung Gebrauch machen, befeuerten die Diskussion über Hyperthreading erneut. Die Behandlung dieser Sicherheitslücken erfolgt inzwischen auf drei Ebenen:

- In der CPU selbst: Aktuelle Intel-CPUs sind nicht mehr gegenüber bekannten Implementierungen von Spectre und Meltdown anfällig. Falls Sie noch ältere CPUs (Baujahr 2017 oder älter) im Einsatz haben, müssen Sie davon ausgehen, dass diese betroffen sind.

- In der BIOS-Firmware: Die meisten Mainboard-Hersteller haben inzwischen Microcode-Updates veröffentlicht, die zumindest die bekannten Sicherheitslücken neutralisieren.

- Im Hypervisor: VMware hat bereits für vSphere 5.5 einen alternativen Scheduler ("Side Channel aware Scheduler"; SCA) veröffentlicht, der die Auswirkungen von Spectre & Co. auf Kosten von einem Teil der Performance stark begrenzt.

Mit vSphere 6.7U2 stellte VMware eine neue Version (SCAv2) vor, deren Einfluss auf die Performance deutlich kleiner ist. Der Preis dafür ist der etwas schwächere Schutz – der unerlaubte Zugriff auf Prozessdaten innerhalb einer VM wird vom SCAv2 nicht verhindert. Die Sicherheitslücke und ihre Behandlung durch Aktivieren von SCA sind im Knowledge-Base-Artikel [4] beschrieben.

Sollten Sie nach der Analyse Ihrer spezifischen Bedrohungslage beschließen, auf Nummer sicher zu gehen und Hyperthreading abzuschalten, können Sie dies nur im BIOS tun. Die Änderung des Hyperthreading-Status erfordert zwingend einen Neustart.

Bisher haben wir die BIOS-Einstellungen betrachtet, die das Verhalten der zentralen Einrichtungen des Servers wie Mainboard, CPU oder RAM beeinflussen. Nicht weniger wichtig sind Konfigurationen der im Server verbauten Peripherie. Viele dieser Einstellungen sind nur im Bootvorgang über die BIOS-Oberfläche möglich, für andere wiederum stellen die Hersteller ein ESXCLI-Plug-in oder ein separates Managementwerkzeug innerhalb des ESXi-Servers zur Verfügung.

Eine der ersten Konfigurationen, die Sie noch vor der Installation des Hypervisors vornehmen müssen, betreffen den Storage-Controller und die logischen Vol-umes. Für das Boot-Laufwerk ist eine RAID1-Redundanz üblich. Dieses Spiegel-Volume müssen Sie natürlich erzeugen, bevor Sie ESXi darauf installieren. Planen Sie eine vSAN-Konfiguration, müssen Sie sicherstellen, dass der Storage-Controller, an den die Festplatten angeschlossen sind, keinerlei RAID-ähnliche Intelligenz aktiviert hat und die Platten direkt an das Betriebssystem durchreicht.

Falls in Ihrer Umgebung alle Server und somit auch die ESXi-Hosts vom SAN booten, müssen Sie die erforderliche Konfiguration des Storage Adapters ebenfalls vor der Installation vornehmen. Hält sich die am einzelnen Server vorzunehmende Konfiguration eines Fibre-Channel-HBA normalerweise in Grenzen, so ist die Konfiguration eines iSCSI-HBA um einiges komplexer und schließt die IP-Konfiguration des Adapters, der Portaladresse und der CHAP-Authentifizierung sowie weitere iSCSI-spezifischen Einstellungen mit ein.

Ein weiterer Anwendungsfall, der einen direkten Eingriff in die Hardwarekonfiguration der Systemperipherie erfordert, betrifft das Link Layer Discovery Protocol (LLDP). ESXi unterstützt dieses zwar nativ, jedoch haben einige Netzwerkkarten (beispielsweise Intel X710-basierende Adapter von HPE) einen in der Firmware integrierten LLDP-Agenten, der die LLDP-Frames selbst auswertet und nicht an den Hypervisor weitergibt. Obwohl die von Intel veröffentlichte ESXCLI-Erweiterung für die Verwaltung von Netzwerkkarten [5] einen Befehl zur Deaktivierung von LLDP im Treiber unterstützt, ist es in den meisten Fällen dennoch erforderlich, LLDP auf der Karte selbst zu deaktivieren.

Das BIOS eines Servers, der für den Einsatz als ESXi-Host vorgesehen ist, beinhaltet viele Einstellungen, die für die Performance und Betriebsstabilität der Umgebung entscheidend sind. Um diese Konfigurationen ber viele Hosts hinweg zu vereinheitlichen, sollten Sie das BIOS stets aktuell halten, Workload-Profile einsetzen und Ihre Server in eine zentrale Hardwareverwaltung integrieren. Bei den Energiesparfunktionen müssen Sie sicherstellen, dass die CPUs Ihrer Hosts zumindest im Hochbetrieb auf maximale Performance eingestellt sind. Nur so steht die erwartete Leistung Ihrer Server- und Desktop-VMs auch tatsächlich zur Verfügung.