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

Ein tieferer Blick in vSphere Rollen und Berechtigungen

Ursprünglich sollte dieser Artikel „Das Rollen Paradoxon“ lauten. Bei längerer Betrachtung kam ich zu dem Schluss, dass es sich hier um kein Paradoxon im eigentlichen Sinne handelt. Das vCenter macht hier nur seine ihm aufgetragene Arbeit.

Berechtigungen unter vSphere sind prinzipiell simpel (so lange wir keine eingeschränkten Berechtigungen verwenden möchten). Wenn wir Mitglied der Administratorengruppe sind und uneingeschränkt auf alle Objekte im Datacenter zugreifen dürfen, sind Privilegien und Rollen schnell erklärt.

Begriffs-Definition

Ein Privileg ist die kleinste Einheit. Es erlaubt die Ausführung einer ganz bestimmten Aktion.

Eine Rolle ist eine Sammlung von Privillegien. Die Administrator-Rolle enthält alle verfügbaren Privilegien. Die No-Access-Rolle enthält dagegen keinerlei Privilegien. „No-Access“ ist hierbei nicht als explizites Verbot zu verstehen, sondern als Fehlen von Berechtigungen. Was zunächst nach einer semantischen Spitzfindigkeit aussehen mag, ist ein wichtiger Unterschied zu anderen Berechtigungskonzepten wie beispielsweise Active-Directory.

Fehlendes Privilleg != Verbot

Eine Berechtigung (Permission) setzt sich immer aus drei Komponenten zusammen: Einem vSphere-Objekt, einer Rolle und einem Benutzer bzw. einer Benutzergruppe. Ein Benutzer (oder eine Gruppe) kann auf unterschiedlichen Objekten unterschiedliche Rollen haben. Berechtigungen auf Objekten können in der Hierarchie optional nach unten vererbt werden.

Das Problem

Interessant wird die Sache wenn ich Rechte global vergebe, diese dann aber auf bestimmten Objekten einschränken möchte.

Beispiel: Die Gruppe der Administratoren soll auf alle Objekte Zugriff haben, mit Ausnahme einiger VMs in einem definierten VM-Ordner. Klingt simpel – ist es aber nicht.

Aufmerksam wurde ich auf die hier beschriebene Problematik durch meinen Kollegen Alexej Prozorov, der in einem Kundeprojekt auf dieses Phänomen stiess. Das Thema war so interessant, dass ich es im Labor nachstellen musste.

„Ein tieferer Blick in vSphere Rollen und Berechtigungen“ 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

VMware Explore EMEA 2023 – Tipps und Tricks

In wenigen Tagen wird die VMware Explore 2023 EMEA in Barcelona auf dem Gelände der Fira Gran Via ihre Tore eröffnen. Für alle, die zum ersten Mal teilnehmen soll dies ein kleiner Leitfaden sein, um sich besser zurechtzufinden. Schon 2018 hatte ich hierfür einen kleinen Survival-Guide zusammengestellt, der weitestgehend noch Gültigkeit hat. Auch wenn die Veranstaltung nun schon zum zweiten Mal unter dem Namen VMware Explore firmiert anstatt der ursprünglichen Bezeichnung VMworld.

Vom Flugplatz zum Hotel

Vom Flugplatz fahren regelmäßig Busse in die Innenstadt. Die Aerobus Linien T1 und T2 starten an Terminal 1 und 2. Beide fahren über Placa Espana bis zur Enstation Placa Catalunya in der Nähe der Altstadt. Die Preise haben sich leicht erhöht, sind aber immer noch eine günstige und schnelle Methode, in die Innenstadt zu kommen. Ein Ticket für Hin- und Rückfahrt kostet 11,65 € pro Person.

Wer nahe der Fira wohnt, kann alternativ auch die Metro L9 nehmen, die vom Flughafen zur Fira fährt.

Zur Fira

Das Netz der öffentlichen Verkehrsmittel in Barcelon ist gut organisiert. Egal wo man wohnt, die nächste Metro Station ist meist nicht weiter als 2 Blocks entfernt. Die Züge fahren in kurzer Taktung. Zielstation ist entweder Europa/Fira mit 10 Minuten Fussweg oder ihr steigt noch einmal um bis zur Station Fira.

Die Verkehrsbetriebe TMB bieten ein 10er Ticket an. 10 Fahrten im ganzen Stadtgebiet für knapp 12€.

Pro Tipp: Fragt bei der Registrierung zur VMware Explore nach einem Metro Ticket. Nur auf Anfrage wurde bisher oben genanntes 10er Ticket an Teilnehmer ausgegeben.

Aktivitäten abseits der VMware Explore

Die VMware Explore wird Euch körperlich fordern. Viele Gespräche, technische Deep Dives, interessante Sessions und vor allem lange Wege. Ihr werdet im Laufe des Tages viele Schritte gehen, um von der Messe (Expo) zu den Vorträgen oder zum Lunch zu kommen. Wer dann noch Energie hat, kann sich ins Abendleben stürzen. Es gibt zahlreiche Parties und vBeers verteilt über die ganze Stadt. Mein Freund und vExpert Kollege Fred Hofer (vBrain.info) hat die wichtigsten Veranstaltungen in seinem Blogbeitrag „VMware Explore 2023 Barcelona – Parties and Gatherings“ gesammelt.

Ganz besonders hervorheben möchte ich das traditionelle vBreakfast am Dienstagmorgen zwischen 7:00 und 8:30 vor der General Session. Hier trifft sich der Teil der Community, der es so früh aus dem Bett schafft. Auch wenn das Event dankenswerterweise von Runecast gesponsort wird, hat das nichts mit einer Werbeveranstaltung gemein. Hier treffen sich Blogger, VMUG-Leader oder einfach nur Community Interessierte. Auch wenn Ihr noch niemanden kennt – danach kennt ihr eine ganze Menge interessanter Leute. Garantiert!

Community

Neben den fachlichen Inhalten der Vorträge geht es natürlich vor allem um Kontakte, Netzwerke und die Pflege von Freundschaften. Ich kannte bei meinem ersten Besuch einer VMworld niemanden. Zu meiner Überraschung wurde ich von gut vernetzten Mitgliedern schnell aufgenommen. Viele dieser ersten Bekanntschaften zähle ich noch heute zu meinem Freundeskreis und freue mich jedes Jahr, diese wiederzutreffen.

Kleidung

Regel Nummer 1: lasst die Business Kleidung im Schrank. Zieht Euch bequeme Schuhe an, mit denen Ihr problemlos einen ganzen Tag umhermarschieren könnt.

Sakko und Hemd erwartet hier niemand. Dagegen sind T-Shirts einer vergangenen VMware- oder VMUG Veranstaltung immer wieder gute Anknüpfpunkte für Gespräche.

Registrierung

Bei der Registrierung zur VMware Explore erhaltet Ihr Euer Messe-Badge, mit welchem Ihr Eintritt zum Messegelände und den gesponsorten Abendveranstaltungen erhaltet.

Die Registrierung ist an jedem Messetag geöffnet. Wer schon früh anreist, kann bereits Sonntags ab 15 Uhr seinen Badge abholen.