ESXi Bootmedium – Neue Anforderungen in v8

Die Anforderungen an ESXi Bootmedien haben sich mit ESXi v7 Update3 grundlegend gewandelt. Die Partitionierung wurde verändert und auch die Anforderungen an die Belastbarkeit des Mediums waren gestiegen. Ich hatte darüber in meinem Blogartikel “ESXi Bootmedium – Neuerungen in v7” berichtet.

USB-Bootmedien erwiesen sich als nicht robust genug und wurden daher ab v7U3 nicht mehr unterstützt. Es ist zwar immer noch möglich, ESXi auf ein USB-Medium zu installieren, jedoch muss dann die ESX-OSData Partition auf einen dauerhaften Speicher umgeleitet werden.

Achtung! USB-Medien und SD-Karten sollten nicht für produktive ESXi Installationen verwendet werden!

Erlaubte Ziele für die ESXi Installation

SD-Karten und USB-Medien scheiden als Installationsziel wegen ihrer schlechten Write-Endurance aus. Weiterhin erlaubt und empfohlen sind dagegen magnetische Disks, SSD und SATA-DOM (Disk-on-Module).

SATA-DOM auf Supermicro E300-9D

Neue Anforderungen ab ESXi v8

Mein Homelab lief bisher unter vSAN 7 und damit unter der klassischen OSA-Architektur. Um den Cluster unter der neuen vSAN ESA Architektur zu betreiben, brauchte es vSphere 8 und neue Speichergeräte.

Ich habe die Installation und Hardware-Kompatibilität auf einem 64 GB USB-Medium getestet (nicht empfohlen!). Während der Installation gab es erwartungsgemäße Warnungen bezüglich des USB-Mediums. Dennoch konnte ich erfolgreich die Erkennung der NVMe Devices und das vCenter Deployment testen.

Setup Warnung bei installation auf ein USB-Flashmedium

Nach erfolgreicher Testphase installierte ich ESXi 8U2 auf das SATA-DOM meines Supermicro E300 Servers. Zu meiner Überraschung scheiterte das Setup sehr früh mit der Meldung: “disk device does not support OSDATA“.

RTFM

Die Erklärung hierfür ist simpel: “Read the fine manual!”

Mein 16 GB SATA-DOM von Supermicro war schlicht zu klein.

Der Setup-Guide für ESXi 8 benennt die Anforderungen ganz klar inter dem Punkt “Storage Requirements for ESXi 8.0 Installation or Upgrade“:

For best performance of an ESXi 8.0 installation, use a persistent storage device that is a minimum of 32 GB for boot devices. Upgrading to ESXi 8.0 requires a boot device that is a minimum of 8 GB. When booting from a local disk, SAN or iSCSI LUN, at least a 32 GB disk is required to allow for the creation of system storage volumes, which include a boot partition, boot banks, and a VMFS-L based ESX-OSData volume. The ESX-OSData volume takes on the role of the legacy /scratch partition, locker partition for VMware Tools, and core dump destination.

VMware vSphere product doumentation

Mit anderen Worten: Neuinstallationen benötigen ein Bootmedium von mindestens 32 GB (128 GB empfohlen) und Upgrade von einer ESXi v7 Version benötigt mindestens 8 GB, jedoch muss in dieser Installation die OSData Partition bereits auf einen alternativen Datenträger umgeleitet sein.

Dirty Trick?

Natürlich versuchte ich es mit einem schmutzigen Trick. Ich installierte zunächst erfolgreich ein ESXi 7U3 auf dem 16 GB SATA-DOM und führte danach eine Upgrade Installation auf v8U2 durch. Auch dieser Versuch scheiterte, da in der frischen v7 Installation der OSData Bereich nicht umgeleitet wurde.

Ich möchte keine Installation auf einem USB-Medium durchführen, da ich bereits zu viele Fälle gesehen habe, in denen diese Medien versagt haben. Bleibt eigentlich nur die Investition in ein größeres SATA-DOM.

Ich habe mich für das 64-GB-Modell entschieden, da es ein guter Kompromiss zwischen Mindestanforderungen und Wirtschaftlichkeit ist.

vSAN Health – vSAN Disk Balance

Wer am VMware Customer Experience Improvement Program (CEIP) teilnimmt, kann im Cluster die Skyline-Health Funktion nutzen. In älteren Versionen wurde diese noch vSphere-Health bzw. vSAN-Health genannt. Beide Funktionen sind nun unter dem Namen Skyine-Health vereint. Man kann Skyline-Health im vSphere-Client unter Monitor > vSAN > Skyline Health erreichen.

Beim start meines Homelabs stieß ich heute auf eine Warnung.

Beim Blick in die Details konnte ich sehen, dass die Disk eines Hosts diese Meldung verursachte. Dort stand “Proactive rebalance is needed”.

Normalerweise verteilt ein vSAN Cluster die Lasten automatisch über alle Kapazitäts-Disks. Aus irgendeinem Grund war dies offensichtlich in meinem Cluster nicht der Fall. Skyline-Health gibt hier direkt Hilfestellung dies zu ändern. In den Details der Warnmeldung ist ein Link zu den erweiterten Clustereinstellungen (Bild unten).

Wie hier klar zu sehen ist, war der Cluster nicht für automatische Verteilung konfiguriert.

Man aktiviert die Funktion mit dem Schieberegler. Wenige Minuten später wechselte die Warnung auf Status “Grün”. Wie lange das in Produktivumgebungen dauert, hängt von der Auslastung des Clusters und dem Grad des Ungleichgewichts ab. Dies kann unter Umständen mehrere Minuten bis hin zu Stunden dauern.

Links

VMware KB 2149809 – vSAN proactive rebalance

vSAN Homelab Cluster – Teil 2

Hier geht es zu Teil 1 – Planungsphase

Die Ware ist da

Letzten Dienstag freute ich mich richtig über eine Sendungsbenachrichtigung des Paketboten. Die Hardware ist unterwegs. Jetzt war es an der Zeit die Verkabelung klar zu machen. Ich mag keine Gordischen Knoten aus Patch- und Stromkabeln. Kabel werden beschriftet und mit Klettband gebündelt. Um es einfach zu halten, werde ich das vSAN Netz und Management LAN im ersten Schritt nicht redundant auslegen. Das sind aber immer noch 8 Patchkabel, die es zu verlegen gilt, plus vier Kabel für das iPMI Remotemanagement. Später fand ich heraus, dass das iPMI Interface einen Fallback auf den LAN Port macht, wenn am dedizierten Remotemanagement Port kein Kabel angeschlossen ist. Sehr erfreulich, denn es erspart vier Kabel und Switchports.

Host Hardware

Alle vier Hosts kamen fertig bestückt und hatten zu diesem Zeitpunkt bereits einen Burn-in Test bestanden. Die Servergehäuse sind kompakt und haben ungefähr die Abmessungen einer kleinen Pizzabox. 25,5 cm breit, 4,5 cm hoch und 22,5 cm tief. Aber vor dem Drücken des Startknopfes muss ich eine Blick unter die Haube werfen. 🙂

Beginnen wir mit der Rückseite. Wie man im Bild unten erkennen kann, ist der Server gut mit Anschlüssen ausgestattet. In der unteren linken Ecke ist der 12V Stomanschluss. Das Kabel kann mit einer Überwurfmutter fixiert werden. Dann folgen zwei USB 3.0 Anschlüsse und der iPMI Anschluss darüber. Das iPMI kommt ab Werk mit Videoumleitung (HTML5 oder Java). Dafür ist keine gesonderte Lizenz nötig.

In der Mitte sehen wir 4×1 Gbit (i350) LAN Anschlüsse und vier 10 Gbit (X722) Anschlüsse. Davon sind zwei als SFP+ ausgelegt. In der unteren rechten Ecke ist der VGA Anschluss, der aber Dank Video-Umleitung nicht gebraucht wird. Dennoch ist es gut, einen für Notfälle zur Verfügung zu haben.

„vSAN Homelab Cluster – Teil 2“ weiterlesen

vSAN Homelab Cluster – Teil 1

Planungsphase

Es gehört zu meinem beruflichen Alltag, mich ständig mit neuen Techniken zu befassen und diese zu auf Praxistauglichkeit zu testen. Einige Produkte kann man sicherlich in einer einfachen VMware Workstation VM installieren, andere jedoch erfordern komplexe multi Server Installationen und komplexe Netze. In der Vergangenheit machte ich solche Tests mit sogenannten “nested” vSphere, oder vSAN Clustern. Dabei werden ESXi Hosts in Virtuellen Maschinen installiert. Der Host Datenspeicher ist wiederum eine virtuelle Disk, die auf der Fesplatte der Workstation liegt. Naja, es funktioniert so gut wie es sich anhört. Man braucht jedoch nicht viel Phantasie sich vorzustellen, dass ein vSAN Cluster mit virtuellen Flash Disks, die letztlich auf drehenden SATA Disks liegen, richtig besch****… ähm, nicht wirklich Spass machen.

Für echte Tests benötige ich “echtes Blech”, wie wir in der IT sagen. Ich schaute mich also längere Zeit nach gebrauchten Servern um. Das Problem dabei ist vielschichtig. Zum einen verwenden viele Kunden Ihre Hardware, bis diese im wörtlichen Sinne auseinander fällt, oder aus der VMware HCL altert. Hardware, auf der man nicht die neuesten Produkte betreiben kann ist letztlich nur noch Elektronikschrott. Zum anderen sind Industrie-Standardserver nicht wirklich bürotauglich. Sie konsumieren soviel Strom wie ein Heizlüfter auf Ecstasy und benötigen viel Platz. Nicht gerade die beste Wahl, um sie neben den Schreibtisch zu stellen.

Ich habe eine Weile nach einer kompakten Lösung gesucht. Die Intel NUC Serie schien zunächst ein möglicher Kandidat zu sein. Intel NUC sind in der Homelab-Szene recht beliebt, da sie klein, leise und nicht sehr teuer sind (zumindest im Vergleich zu einem Server). 🙂 Was mich jedoch vom Kauf abgehalten hat, war der Mangel an Netzwerk-Adaptern und die sehr eingeschränkte Erweiterungsmöglichkeit mit SSD für Caching und Kapazität.

Anfang dieses Jahres machte mich jemand auf die Supermicro E300-9D Serie aufmerksam. Diese Mikroserver sahen vielversprechend aus. Immer noch kompakt, aber ausgestattet mit 8 echten LAN-Ports (davon 4 mit 10 GBit) und M.2 Schnittstellen für NVMe Flash-Speicher. William Lam hat einen ausgezeicheten Blogpost zum E300-9D veröffentlicht. Das kleine Schmuckstück kann mit einem SATA DOM Bootmedium und bis zu drei NVMe Disks bestückt werden. Darüber hinaus ist die E300-9D Serie auf der VMware HCL gelistet. Wie cool ist das denn!?

„vSAN Homelab Cluster – Teil 1“ weiterlesen