Der vSphere Lifecycle Manager (vLCM) ist der Nachfolger des Update Managers (VUM). Der Dienst läuft in der vCenter-Server-Appliance und verwendet die eingebettete PostgreSQL-Datenbank. Damit sind im Vergleich zu den mehr oder weniger komplexen Bereitstellungsszenarien des früheren Update Managers keine zusätzlichen Installationsmaßnahmen notwendig. Konkret hat VMware schon in vSphere 7.0 das Update-Manager-Plug-in, das dem Verwalten des Update Managers dient, durch das Lifecycle-Manager-Plug-in ersetzt. Allerdings sind Verwaltungsvorgänge für den Update Manager auch in vSphere 8 im Lifecycle-Manager-Plug-in verfügbar – gemeinsam mit Funktionen des vLCM.

Der Dienst ist automatisch aktiviert, wie ein Blick in das Menü "Dienste" der vCenter-Managementoberfläche offenbart. Das wiederum bewirkt, dass die vLCM-GUI im vSphere-Client aktiv ist. Im Detail beinhaltet der vLCM alle Funktionen des früheren Update Managers, optimiert sie aber durch das Ergänzen neuer Features und Optionen für die ESXi-Lebenszyklusverwaltung auf Cluster-Ebene. Um die Funktion nutzen zu können, müssen Sie lediglich das zu aktualisierende Objekt im Navigator markieren (Cluster, Host oder VM) und finden dann alle Funktionen im Reiter "Updates".

Im Grunde müssen wir also bei der Beschreibung des Diensts zwei unabhängige Betrachtungen anstellen, nämlich einmal im klassischen Baseline-Betrieb und einmal auf Basis der Cluster-Images. In diesem Artikel betrachten wir die Cluster-Images, weisen aber darauf hin, dass es für beide Betriebsarten gute Gründe gibt.

Cluster-Images standardisieren

Die wichtigste Eigenschaft des vLCM ist das Modell des gewünschten Status (Desired State). Hierbei kommen die Integration mit Hardwareanbietern für Full-Stack-Firmware-Updates, vereinfachte OEM-Image-Anpassungen und automatische Kompatibilitätsprüfungen zum Tragen. Ein solcher Desired State entsteht automatisch, sobald vLCM- und Image-Verwaltung für einen Cluster aktiviert sind. Der gewünschte vLCM-Status eines ESXi-Hosts unterscheidet sich möglicherweise von den Versionen, die aktuell laufen. Weicht ein Host vom gewünschten Zustand ab, wird er korrigiert. Durch das Management von Clustern auf Basis von Images lassen sich ESXi-Hosts in einem vSphere-8-Cluster also besonders komfortabel auf die jeweils im Cluster gewünschte Version standardisieren.

Um einen Cluster mit einem deklarativen Image zu aktivieren, müssen alle Hosts im Cluster auf dem Stand ESXi 7 oder 8 sein, vom selben Anbieter stammen, idealerweise von derselben Marke und dasselbe Modell aufweisen. Ist ein vSphere-Cluster für den Einsatz eines einzelnen Images konfiguriert, ersetzt vLCM die im VUM verwendete Basismethode mit Baselines.

Jedes Cluster-Image enthält dabei bis zu vier Bestandteile, von denen nur das ESXi-Basisimage zwingend ist: Bei diesem handelt es sich wie gewohnt um ein Update, das Softwarekorrekturen und -erweiterungen mitbringt. Ein Basisimage ist ein vollständiges ESXi-Installationspaket, das ausreicht, um einen ESXi-Host zu starten. Es ist das Paket, das VMware in jeder Hauptversion veröffentlicht. Beim Erstellen eines Cluster-Images müssen Sie mindestens das Basisimage mit der vSphere-Version auswählen, darüber hinaus gibt es Hersteller-Add-ons.

Das sind Sets von Komponenten, die OEMs zusammen mit einem ESXi-Image bündeln, um ein benutzerdefiniertes, installierbares ESXi-Image zu erstellen. Zudem lassen sich so optional sogenannte "Komponenten" einbinden, also mit vLCM eingeführte "Entitäten". VMware versteht darunter eine logische Gruppierung von einem oder mehreren VIBs (vSphere Installation Bundles). Schließlich gibt es nun auch Hardware-Support-Pakete mit Firmware und Treibern, die Sie für ein Cluster-Image definieren können. Diese Pakete kapseln eine bestimmte Funktionalität, setzen allerdings entsprechende Hersteller-Plug-ins voraus.

Mit vSphere 8 ist beim Betrieb des vLCM mit Cluster-Image die "Komponente" die kleinste Einheit, die der vLCM zum Installieren von Software von VMware oder Drittanbietern auf ESXi-Hosts verwendet. Dazu sollten Sie sich den Unterschied zwischen vLCM-Images und -Baselines vergegenwärtigen. Dabei ist es hilfreich, sich wiederum die Beziehung zwischen den Basistypen für das Erstellen von Softwarepaketen in Erinnerung zu rufen, die Softwareanbieter nutzen, um Updates zu erstellen und zu versenden.

Beim Update Manager ist das VIB der Basisbaustein für das Erstellen von Installationspaketen für ESXi-Hosts. VMware versteht unter einem VIB ein Softwarepaket, das aus Metadaten und einer binären Nutzlast besteht. Letztere ist die tatsächlich zu installierende Software. Allerdings bietet ein VIB nie eine bestimmte Funktionalität als Ganzes, sondern ist immer nur ein einziges Modul der gewünschten Funktion. Nur im Baseline-Betrieb – also beim Update Manager – ist das VIB die kleinste installierbare Softwareeinheit.

Der Cluster-Image-Betrieb mit dem vLCM verarbeitet keine einzelnen VIBs, sondern immer nur in einem Konstrukt der nächsthöheren Ebene, in diesem Fall der Komponente. Beim Baseline-Betrieb wäre die nächsthöhere Ebene das "Bulletin", eine Gruppierung von einem oder mehreren VIBs, wobei Bulletins selbst innerhalb der Metadaten des VIB definiert sind. Während Sie Bulletins verwenden, um vLCM-Baselines zu erstellen, die Sie dann wie gewohnt an Bestandslistenobjekte anhängen, arbeitet der vLCM im Imagebetrieb mit Komponenten. Im Unterschied zum Bulletin enthält eine Komponente zusätzliche Metadaten, die den Namen und die Version der Komponente angeben. (jp/ln/Thomas Drilling)

Im zweiten Teil der Workshopserie werfen wir einen Blick darauf, wie Sie Images einrichten, prüfen und vLCM an Ihre spezifischen Bedingungen anpassen. Im dritten und letzten Teil erklären wir, wie Sie Cluster-Images modifizieren, dabei Firmware und Treiber einspielen und die Hardwarekompatibilität prüfen.