Teach-The-Expert: vSAN Diskgruppen Verwaltung auf der CLI

Im Rahmen meiner Trainer-Tätigkeit kommen in den Kursen immer wieder Fragestellungen zu Themen die im Kurs nur am Rande oder gar nicht abgehandelt werden. Diese Artikelserie gibt angehenden IT-Experten Hilfsmittel für den täglichen Gebrauch an die Hand.

Intro – Was sind Diskgruppen?

VMware vSAN OSA (original storage architecture) organisiert den vSAN-Datenspeicher in Diskgruppen (DG). Jeder vSAN-Knoten kann bis zu 5 Diskgruppen enthalten. Jede dieser Diskgruppen besteht aus genau einem Cache-Device (SSD) und mindestens einem bis maximal 7 Capacity-Devices pro Gruppe. Diese dürfen entweder magnetische Disks oder SSD sein, jedoch keine Mischung aus beiden. Wir unterscheiden in Cache-Tier und Capacity-Tier.

Die Verwaltung der Diskgruppen kann anschaulich über das graphische Userinterface GUI erfolgen. Es gibt jedoch Situationen in den das Diskgruppen Managemenent auf der CLI notwendig oder zweckmäßiger ist.

UUID

Jedes Disk Device eines vSAN Clusters (OSA) hat eine eindeutige und einzigartige Kennung (universal unique identifier, UUID).

Wir können alle Devices eines vSAN Knotens auf der CLI auflisten mit dem Kommando:

esxcli vsan storage list

Die Menge an Information ist möglicherweise etwas zu viel des Guten und wir möchten nur die Zeilen mit UUID anzeigen lassen.

esxcli vsan storage list | grep UUID

Wir erhalten eine Liste aller Disk-Devices im vSAN-Knoten. Zusätzlich erhalten wir auch die UUID der Diskgruppe, welcher das Device zugeordnet ist.

Schaut man sich die Ausgabe etwas genauer an, so fällt auf dass es einige Devices gibt, deren UUID identisch mit der UUID der Diskgroup ist. Ist dies ein Widerspruch zur Aussage, die UUID sei einzigartig? Nein. Es handelt sich hier um Cache-Devices. Jede Diskgruppe in vSAN OSA besteht aus genau einem Cache Device. Die Diskgruppe übernimmt hierbei die UUID ihres Cache-Devices. Wir können also auf diese Art schnell ein Cache Device von einem Capacity Device unterscheiden.

„Teach-The-Expert: vSAN Diskgruppen Verwaltung auf der CLI“ weiterlesen

Fehler beim vCLS Retreat Mode führt zum Verlust aller Privilegien

Mit Einführung von vSphere 7.0 Update 1 erschienen in vSphere-Clustern erstmals die vSphere Cluster Services VMs (vCLS). Damit wurden Cluster Funktionen wie z.B. Distributed Resource Scheduler (DRS) und andere erstmals unabhängig von der Verfügbarkeit der vCenter Server Appliance (VCSA). Letztere stellt im Cluster immer noch einen Single-Point-of-Failure dar. Durch Auslagerung der DRS Funktion in die redundanten vCLS Maschinen wurde ein höheres Maß an Resilienz erreicht.

Retreat Mode

Der vSphere-Administrator hat nur wenig Einfluss auf die Bereitstellung dieser VMs. Gelegentlich ist es jedoch notwendig, diese VMs von einem Datastore zu entfernen wenn dieser beispielsweise in den Wartungsmodus versetzt werden soll. Dafür gibt es eine Prozedur, um den Cluster in den sogenannten Retreat-Mode zu setzen. Dabei werden temporäre erweiterte Einstellungen gesetzt, die zur Löschung der vCLS VMs durch den Cluster führen.

Laut Prozedur von VMware muss für die Aktivierung des Retreat Modes die Domain ID ermittelt werden. Die Domain ID ist der numerische Wert zwischen ‘domain-c’ und dem folgenden Doppelpunkt. Im Beispiel aus meinem Labor ist es der Wert 8, aber die Zahl kann durchaus auch vierstellig sein.

Die Domain ID muss dann in den Advanced Settings des vCenters übergeben werden.

config.vcls.clusters.domain-c8.enabled = false
Korrekte Settings für den Retreat Mode.

Admin Fehler beim Retreat Mode

Nach Aktivierung des Retreat-Modes auf einem vSAN-Cluster hatten Administratoren sämtliche Privilegien auf alle Objekte im vSphere-Client verloren.

Eine Überprüfung der Dienste zeigte, dass der vCenter Server Daemon (vpxd) nicht gestartet war.

„Fehler beim vCLS Retreat Mode führt zum Verlust aller Privilegien“ weiterlesen

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 8 Update 2 – Neuerungen auf technischer Ebene

Anfang des Monats hatte ich die Gelegenheit, am VMware Exclusive Blogger Early Access Program teilzunehmen. Hier teilen VMware-Experten Neuigkeiten und kommende Funktionen für Produkte vor dem eigentlichen Veröffentlichungsdatum.
Ich möchte an dieser Stelle Pete Kohler und John Nicholson für das Feature-Briefing zum Release von vSAN 8 Update 2 danken. Mein weiterer Dank gilt Heather Haley vom globalen Kommunikationsteam von VMware und Corey Romero für die Unterstützung bei der Umsetzung.

[Dieser Blogpost unterlag einer Sperre bis zum 22. August 5:00 PDT (14:00 CEST)]

VMware vSAN 8 Update 2 bietet eine Reihe von neuen Funktionen und Verbesserungen in Bezug auf Flexibilität, Leistung und Benutzerfreundlichkeit.

Neue ESA Features auf einen Blick

  • vSAN ESA storage-only Cluster mit vSAN Max
  • VMware Cloud Foundation Support für vSAN ESA in VCF 5.1
  • vSAN File Services ab sofort auch in vSAN ESA verfügbar
  • Neue ESA Ready Node Konfigurationen für kleine Umgebungen
  • Unterstützung für eine neue Klasse leseintensiver Speichergeräte
  • Automatische korrektur der Speicherrrichtlinien
  • ESA Prescriptive Device Claim
  • Verbesserungen bei Stretched- and 2-Knoten-Clustern
  • Bis zu 500 VMs pro Host (im Vergleich zu bisher 200)
„vSAN 8 Update 2 – Neuerungen auf technischer Ebene“ weiterlesen