TTE – iSCSI Kernelport mit PowerCLI konfigurieren

Dies ist ein Post aus der Reihe „Teach the Expert“ (TTE).

Wenn Ihr nach einer einfachen Möglichkeit sucht, die iSCSI-Kernelport-Konfiguration auf dem VMware ESXi-Host zu bearbeiten, ist PowerCLI die ideale Lösung. In diesem Beitrag erfahrt Ihr, wie Ihr PowerCLI zur Konfiguration des iSCSI-Kernelports verwendet und wie Ihr den iSCSI-Kernelport aktiviert oder deaktiviert. Wir werden auch einige Beispiele für die Verwendung von PowerCLI zur Konfiguration von iSCSI-Kernelport-Einstellungen geben. Also, fangen wir an!

1. März 202413. März 2024

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.

17. Februar 202429. Dezember 2024

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.