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

Unbekannte Disk aus vSAN Cluster entfernen

Eine defekte Capacity-Disk wurde aus einem vSAN 7 Cluster entfernt bevor diese logisch aus der Diskgruppe gelöst werden konnte. Das Ergebnis ist ein zurückbleibendes unbekanntes Disk Device in der Diskgruppe, das sich im vSphere-Client nicht mehr entfernen lässt.

In solchen Fällen ist esxcli mitunter das mächtigere Schwert.

Wir verbinden uns per SSH auf den betroffenen vSAN-Knoten.

Datenerfassung

Zunächst prüfen wir alle im Knoten registrierten Disk Devices.

esxcli vsan storage list

Es wird eine detaillierte Liste aller Cache- und Capacity-Devices dieses Hosts ausgegeben.

Ausgabe der Disk Devices (Auszug)

Unter den 24 aktiven Disks befand sich auch das unbekannte Zombie Device. Das einzig verbleibende Merkmal war die vSAN UUID. Mit deren Hilfe kann das Device aus der Konfiguration gelöst werden.

Physisch entferntes Device Relikt in der vSAN Konfiguration

Extraktion

Die UUID des fehlenden unbekannten Devices lautete “52b17786-183b-e85f-f7f3-4befb19f67b0”. Mit dieser Info können wir es aus der Konfiguration entfernen.

esxcli vsan storage remove --uuid 52b17786-183b-e85f-f7f3-4befb19f67b0

Der Vorgang dauert einige Sekunden. Eine erneute Kontrolle mit dem Befehl esxcli vsan storage list zeigte, dass das Device entfernt war.

ESXi Coredump Files verwalten

Zugegeben, das ist kein neues Thema, aber es kostete mich etwas Zeit in einem Kundenprojekt. Da dieser Blog auch als Swap-Partition meines Gehirns fungiert, habe ich es für die Zukunft niedergeschrieben. Wichtig ist die korrekte Abfolge der Schritte, damit die Änderung auch nach einem Bootvorgang erhalten bleibt.

Wofür wird ein Coredump-File benötigt?

Moderne ESXi Installationen ab Version 7 verwenden ein neues Partitions-Layout des Bootdevices. Darin werden auch Coredumps abgelegt. Jedoch nur wenn das Bootmedium kein USB-Flashmedium und keine SD-Card ist. In solchen Fällen wird der Coredump ausgelagert auf einen VMFS-Datenspeicher mit mindestens 32GB Kapazität.

Genau einen solchen Fall fand ich in einer Kundenumgebung vor. Das System wurde von vSphere 6.7 migriert und hatte daher noch das alte Boot-Layout auf einem (damals noch voll unterstützten) SD-Card RAID1. Wir fanden einen Ordner vmkdump mit Files für jeden Host auf einem der gemeinsamen VMFS-Datenspeicher. Dieser (VMFS5) Datenspeicher sollte aufgelöst und durch einen VMFS6 Datenspeicher ersetzt werden. (Randbemerkung des VCI: Es gibt keinen online Migrationspfad von VMFS5 nach VMFS6). 😉 Also mussten die vmkdump Files von dort weg.

Ablauf

Zunächst verschaffen wir uns eine Übersicht der Coredump-Files.

esxcli system coredump file list

Hier werden alle Coredump-Files aller ESXi-Hosts gelistet. Jede Zeile enthält neben dem Pfad auch die Stati Active und Configured (true oder false). Active bedeutet, dass dies das aktuelle Coredumpfile dieses Hosts ist. Wichtig ist, dass der Wert bei Configured ebenfalls den Status ‘true’ hat. Ansonsten übersteht die Einstellung keinen Reboot. Nur das Coredump-File des aktuellen Hosts hat den Status ‘active’. Alle anderen Files gehören zu anderen Hosts und sind daher active=false.

Im Standard wählt der Host den ersten passenden VMFS-Datenspeicher. Das ist nicht unbedingt der erwünschte.

Aktuelles Coredump-File entfernen

Zunächst löschen wir das aktive Coredump-File des Hosts. Wir müssen die Löschung erzwingen, da es als active=true gesetzt ist.

esxcli system coredump file remove --force

Führen wir das list Kommando von oben nochmals aus, so sollte eine Zeile weniger erscheinen.

Neues Coredump File erzeugen

Der folgende Befehl legt ein neues Coredump-File am Zielort an. Falls noch nicht vorhanden wird ein Ordner vmkdump erzeugt und darin das Dumpfile. Wir übergeben den gewünschten Filenamen ohne Endung, da diese (.dumpfile) automatisch erzeugt wird.

esxcli system coredump file add -d <Name | UUID> -f <filename>

Beispiel: Name des Hosts ist “ESX-01” und der VMFS-Datenspeicher hat den Namen “Service”. Der Datenspeicher darf entweder als Anzeigename oder Datastore_UUID übergeben werden.

esxcli system coredump file add -d Service -f ESX-01

Auf dem benannten Datenspeicher wird nun ein Ordner vmkdump erzeugt und darin ein File namens ESX-01.dumpfile. Wir können dies prüfen über das list Kommando.

esxcli system coredump file list

Es erscheint eine neue Zeile mit dem vollen Pfad zum neuen Dumpfile. Der Status ist jedoch noch active=false und configured=false. Es ist sinnvoll diesen kompletten Pfad in die Zwischenablage zu kopieren, denn wir benötigen ihn im nächsten Schritt.

Dumpfile aktivieren

Wir setzen im folgenden Schritt das neu erzeugte Dumpfile aktiv. Somit bleibt die Einstellung auch nach einen Host-Reboot erhalten. Wir übergeben dabei den vollständigen Pfad zum Dumpfile. Hier eignet sich die Kopie aus der Zwischenablage und vermeidet Tippfehler.

esxcli system coredump file set -p <path_to_dumpfile>

Beispiel:

esxcli system coredump file set -p /vmfs/volumes/<UUID>/vmkdump/ESX-01.dumpfile

Ein abschließender List Befehl bestätigt das Ergebnis.

Links

vSAN Cluster Live-Migration in ein neues vCenter

Was kann man tun, wenn die produktive vCenter Server Appliance beschädigt ist und man einen vSAN-Cluster auf eine neue vCenter Appliance übertragen muss?

Im heutigen Beitrag werde ich zeigen, wie man einen laufenden vSAN-Cluster unter vollen Segeln von einer vCenter-Instanz auf ein neues vCenter übertragen kann.

Bei jedem der mit vSAN arbeitet, wird sich bei diesem Gedanken ein flaues Gefühl in der Magengegend verbreiten. Warum sollte man so etwas tun? Wäre es nicht besser, den Cluster komplett in den Wartungsmodus zu fahren? – Prinzipiell, ja. In der Praxis treffen wir aber immer wieder auf Einschränkungen, die in absehbarer Zeit kein Wartungsfenster erlauben.

Normalerweise sind vCenter Server Appliances robuste und wartungsarme Einheiten. Entweder sie funktionieren, oder sie sind völlig zerstört. In letzterem Fall könnte eine neue Appliance bereitgestellt und vom Backup ein Konfiguration-Restore eingespielt werden. Nichts davon traf auf ein kürzlich durchgeführtes Projekt zu. Die VCSA 6.7 funktionierte noch halbwegs, jedoch waren wichtige vSAN-Funktionalitäten im UI nicht mehr verfügbar. Eine erste Idee, das Problem mit einem Upgrade auf vCenter v7 und somit auf eine neue Appliance zu beseitigen scheiterte. Auch eine Cross-vCenter Migration der VMs (XVM) auf einen neuen vSAN-Cluster war nicht möglich, da erstens dieses Feature erst mit Version 7.0 Update 1c integriert wurde und zweitens auch nur zwei neue Ersatzhosts zur Verfügung standen. Zu wenig für einen neuen vSAN-Cluster. Zu allem Überfluss war auch der Quellcluster an seiner Kapazitätsgrenze.

Es gab nur einen Ausweg: Den Cluster stabilisieren und unter voller Last auf ein neues vCenter übertragen.

Zu diesem Thema gibt es einen alten, aber immer noch wertvollen Beitrag von William Lam. Damit, und mit dem VMware KB 2151610 Artikel konnte ich eine Strategie entwickeln, die ich hier skizzieren möchte.

Das Verfahren funktioniert, da ein vSAN-Cluster nach Einrichtung und Konfiguration autonom vom vCenter arbeiten kann. Das vCenter wird lediglich für Monitoring und Konfigurationsänderungen benötigt.

„vSAN Cluster Live-Migration in ein neues vCenter“ weiterlesen