ESXi 6.5-Patch-Management – Teil 2, Video und Text,

Einrichten und Nutzen von Baselines im vSphere Update Manager

| Autor / Redakteur: Thomas Drilling / Ulrike Ostler

Der „VMware vSphere Update Manager“ ist mit der vSphere-Version 6.5 besser denn je integriert und benötigt keine Windows-Plattform mehr.
Der „VMware vSphere Update Manager“ ist mit der vSphere-Version 6.5 besser denn je integriert und benötigt keine Windows-Plattform mehr. (Bild: Thomas Drilling)

Der „vSphere Update Manager“ (VUM) ist in der aktuellen vSphere-Version 6.5 deutlich einfacher nutzbar, weil er nun besser mit dem neuen virtuellen „vCenter“ und dem Web-Client integriert ist. Nach der erfolgreichen Inbetriebnahme und initialen Konfiguration folgt das Erstellen und Anwenden von so genannten Baselines, mit deren Hilfe der Admin einen oder mehrere Hosts automatisch standardisiert.

VMware stellt Aktualisierungen für seinen „ESXi“-Hypervisor in Form von so genannten VIB-Paketen („vSphere Installation Bundles“ oder früher auch gelegentlich „VMware Infrastructure Bundles“ genannt) zur Verfügung. Im Gegensatz zu einem gewöhnlichen Linux-System stecken also die Dateien, die VMware ESXi letztendlich auf dem Boot-Medium ablegt in signierten und gehärteten VIB-Containern, die jeweils beim Start geladen, entpackt und eingebunden werden.

Solche VIBs können Programme oder Treiber für spezielle Hardware wie Netzwerkkarten oder RAID-Controller enthalten. Daher lassen sich Treiber auch nicht einfach über die Konsole installieren, sondern müssen stets in VIB-Pakete entsprechend verpackt und anschließend über die Kommandozeile installiert werden.

Patch-Quellen verstehen

VIBs stammen entweder von VMware oder von Drittherstellern. Daher sind Updates eines ESXi-Servers immer ein zweistufiger Prozess: Zuerst widmet man sich dem Updaten von ESXi mit Hilfe von VMware-Patches und anschließend den Updates der Hardware-Treiber, sofern man seine Hardware nicht mit einem Custom-ISO betreibt. Bei HP zum Beispiel lassen sich Hardwaretreiber für ESXi über das vibsdepot, Patches für VMware-Produkte selbst hingegen über das VMware patch portal beziehen.

Hier klickt man im Produkt-Dropdown-Menü auf „ESXi (Embedded und Installable)“ und dann auf „Suchen“. Von der Art des Patches (Big-Fix, Update, Extension) hängt dann der „Impact“ des Einspielens des betreffenden Patches ab, wie Reboot oder Maintenance-Modus.

Mit dem vSphere Upate Manager lassen sich die beschriebene Vorgänge soweit automatisieren, dass sich der Admin nach der Inbetriebnahme und Erstkonfiguration nur noch mit Hilfe von Patch-Baselines sicherstellt, dass die im Patch-Repository vorhandenen Patches kategorisiert und Objekt-bezogen (Cluster, Host, VM, VA) angewendet werden.

Der kompletten Prozess der Baseline-Erstellung, des Compliance-Checks und des Anwendens von Patches zeigt folgendes Video.

Was sind Baselines?

Baselines erlauben ein zielgerichtetes Ausliefern von Patches für ausgewählte Objekte wie Hosts, VMs oder VAs. Baselines sind also dem übergeordneten Patch-Repository vorgeschaltet und ermöglichen es, Upgrades oder Patches für einzelne Objekte in einer vSphere-Umgebung gezielt zu steuern und für die Anforderungen des Unternehmens zu vereinheitlichen.

Würde der Admin zu aktualisierende Objekte (Host, VM oder VA) bei jedem Patch-Durchlauf mit dem kompletten Patch-Repository abgleichen, müssten er jeden gewünschten Einzel-Patch explizit auswählen. Große Unternehmen pflegen dagegen häufig eine einheitliche, exakt definierte Patch-Basis pro Abteilung oder Standort.

Außerdem lassen sich Patches mit Baselines einfach auf die Host-Hardware beschränken, für die sie zuvor getestet wurden. Zudem können sich Unternehmen mit Baselines vor unerwünschten Patches schützen. Baselines lassen sich daher für 3 Ebenen klassifizieren.

Ebene 1:
Host-Baselines - VM/VA-Baselines

Ebene 2:
Patch-Baselines - Extension-Baseline - Upgrade-Baselines

Ebene 3:
Fix-Baselines - Dynamic Baselines

Auf Ebene 1 unterscheidet VMware zwischen Patches für Hosts und Solchen für VMs und VAs und pflegt für beide getrennte Download-Repositories, zu finden im Update Manager in der Administrator¬ansicht unter „Verwalten“ auf den beiden Reitern „Host-Baselines“ und „VM/VA-Baselines“. In beiden Sektionen gibt es von VMware vordefinierte Baselines - zwei unter den Host-Baselines und drei bei den VM/VA-Baselines.

Host-Baselines für kritische und nicht kritische Host-Patches
Host-Baselines für kritische und nicht kritische Host-Patches (Bild: Thomas Drilling)

Eigene Baselines erstellen

Zum Erstellen einer neuen Baseline klickt man auf das grüne Plus-Symbol, was den Baseline-Assistenten auf den Plan ruft. Der Admin muss aber nicht zwingend eigene Baselines erstellen und pflegen. In kleinen Umgebungen reichen die bereits definierten Baselines von VMware oft aus.

Der Baseline-Assistent differenziert zudem zwischen „Baselines“ und „Baseline-Gruppen“. Letztere haben nichts mit Benutzer-Gruppen zu tun, sondern fassen mehrere Baselines zusammen. Sie lassen sich aus vorhandenen Einzel-Baselines zusammenbauen und enthalten entweder

  • eine Upgrade-Baseline pro Upgrade-Baseline-Typ
  • eine oder mehrere Patch- und Erweiterungs-Baselines
  • oder eine Kombination aus mehreren Patch- und Erweiterungs-Baselines

Hat sich der Admin im ersten Schritt des Assistenten für das Erstellen einer Host-Baseline oder VM/VA-Baseline entschieden, wählt er im Folgeschritt einen der Baseline-Typen Fest oder Dynamisch aus.

Feste und dynamische Baselines

Feste Baselines enthalten immer einen festen Satz von Patches und verändern sich nach dem Erstellen nicht, auch wenn neue Patches im Repository hinzukommen. Sie eigenen sich zum Beispiel für Unternehmen mit einer homogenen ESXi-Landschaft. Admins können dann leicht ausgewählte und getestete Patches fest in einer eigenen Paketbasis zusammenfassen, die nachher beim Standardisieren der Hosts als (einzige) Quelle herangezogen wird. So lassen sich etwa eigene Baselines für Server von HP, Fujitsu oder Lenovo einer bestimmten Baureihe pflegen.

Dynamische Baselines aktualisieren ihren Inhalt mit der Verfügbarkeit neuer Patches im Repository sowie anhand von Kriterien automatisch, die der Admins selbst festlegt. Dynamische Baselines eigenen sich beispielsweise für das Patchen einzelner Test-Hosts, die ´ohne Rücksicht auf Verluste` stets auf dem aktuellen Patch-Level gehalten werden sollen.

Bei dynamischen Baselines lassen sich im Folgeschritt Kriterien festlegen, die zum Beispiel bestimmen, dass nur Patches eines bestimmten Anbieters, einer bestimmte Kategorie (Security, Bugfix), eines bestimmten Schweregrads (Critical, Important) oder einer bestimmten Produktlinie (vSphere 6.0. 6.5) berücksichtigt werden.

Das Erstellen dynamischer Baselines
Das Erstellen dynamischer Baselines (Bild: Thomas Drilling)

Zudem können Admins die Auswahl auf Patches begrenzen, die in einem bestimmten Zeitraum erschienen sind. Auf der anderen Seite beschleunigt ein Verzicht auf das Filtern den Patch-Vorbereitungsprozess. Lässt ein Admin nämlich in der Baseline „Alle“ Patches zu, findet er beim späteren Compliance-Check ohnehin heraus, welche Patches überhaupt anwendbar sind.

Einzelne Patches lassen sich dann immer noch beim Standardisieren bestätigen oder auslassen. Darüber hinaus können Administratoren einzelne Patches auch im nächsten Schritt „Auszuschließende Pakete“ direkt aus der Baseline entfernen.

Ergänzend zum beschriebenen Vorgehen lassen sich auch anderen Baseline-Typen erstellen, wie eine reine „Erweiterungs-Baseline“. Diese enthält dann nur zusätzliche Software für ESXi-Hosts, die entweder von VMware- oder Drittanbietern stammt.

Host-Upgrade-Baselines

Möchten der Admin jedoch einen oder mehrere ESXi-Hosts einem Upgrade unterziehen, etwa von der vSphere-Version 6.0 auf 6.5, erstellt er im ersten Schritt des Baseline-Assistenten eine „Host-Upgrade-Baseline“. Im Folgeschritt „ESXi-Images“ wählt er dann das gewünschte ESXi-Image aus, das er vorher im Reiter „Verwalten“ im Tab „ESXi-Image“s hochgeladen haben muss.

Auf diese Weise ist es beispielsweise einfach möglich, eine große Anzahl von ESXi-Hosts mit einem Upgrade zu vesrsehen, indem man diese gegen eine solche Host-Upgrade-Baseline standardisiert. Individualisierte ESXi-Image-Profile lassen sich zuvor mit dem Image Builder erzeugen.

Ähnlich funktionieren auch VM/VA-Baselines. Diese dienen vor Allem dazu, auf einfache Weise die VMware Tools und die Hardware-Version ausgewählter VMs oder virtueller Appliance zu aktualisieren.

Compliance-Check und Standardisierung

Sind die gewünschten Baselines eingerichtet, lassen sich Hosts oder VMs/VA auf Übereinstimmung mit vorher definierten Baselines prüfen und der Host (oder die VM) bei Nichtübereinstimmung standardisieren, also die betreffenden Patches einspielen. Zum Standardisieren eines Hosts muss er diesem die gewünschte Baseline „anhängen“.

In einfachsten Fall verwendet man eine der von VMware vordefinierten Baselines für kritische Host-Patches und oder nicht kritische Host-Patches. Oberhalb der Ansicht für angehängte Baselines findet sich bei Bedarf auch ein das Symbol, um die Baseline wieder zu trennen.

Haben Admins Baselines angehängt, können sie jede davon markieren und dann im Fensterbereich „Übersicht“ alle prinzipiell anwendbaren Patches sehen. Den eigentlichen Compliance-Check leitet man dann bei markierter Baseline mit einem Klick auf die Schaltfläche „Auf Updates prüfen“ ein.

Im Dialog „Prüfen“ können dann zwischen „Patches und Erweiterungen“ oder „Upgrades“ entschieden werden. Die Spalte „Übereinstimmungsstatus“ zeigt dann nach kurzer Zeit das Ergebnis.

Die Übereinstimmungsansicht prüftt z. B. Host, ob diese auf dem Patch-Level der angehängten Baselines sind.
Die Übereinstimmungsansicht prüftt z. B. Host, ob diese auf dem Patch-Level der angehängten Baselines sind. (Bild: Thomas Drilling)

Liefert der Compliance-Check für eine oder mehrere Baselines das Ergebnis „Nicht übereinstimmend“ besteht Handlungsbedarf. Hierbei können sich Admins zwischen „Patches bereitstellen“ (Staging) und „Standardisieren“ (Remediation) entscheiden. D

Das Standardisieren schließt das Bereitstellen ein, sofern dies noch nicht passiert ist. Wer mag, kann aber beide Vorgänge auch trennen, wobei „Bereitstellen“ die gewünschten Pakete zunächst auf den oder die Host(s) überträgt, was schlimmstenfalls nur Netzlast erzeugt

Patches einspielen

Das Standardisieren hingegen kann je nach Patch-Art „Auswirkungen“ (Impacts) haben. Durch das Einspielen der Patches (Standardisieren) leitet ebenfalls ein Assistent. Hierbei wählen Administratoren zuerst die gewünschten Baselines und danach Zielobjekt, zum Beispiel einen ESXi-Host, aus.

Danach bestimmen sie gegebenenfalls die gewünschten Einzel-Patches und einen Zeitplan zum Ausführen der Aktionen. In dem für ein erfolgreiches Standardisieren entscheidenden Schritt 5 des Standardisierungs-Assistenten können Administratoren dann eine Reihe von Einstellungen für den Wartungsmodus angeben, in den eine Standardisierung den Host meistens schalten wird, wie sich an der Spalte „Auswirkung“ erkennen lässt. Hierbei müssen laufenden VMs heruntergefahren oder per vMotion migriert werden.

Das Einspielen der Patches wird ebenfalls durch einen Assistenten geführt.
Das Einspielen der Patches wird ebenfalls durch einen Assistenten geführt. (Bild: Thomas Drilling)

Um dadurch entstehende Ausfallzeiten zu verkürzen, ist im Listenfeld „VM-Betriebszustand“ wählbar, dass betroffene VMs zuvor ausgeschaltet oder angehalten werden. Sollte das Anfahren des Wartungsmodus fehlschlagen, können Admins noch festlegen, wie oft VUM erneut versuchen soll, den Host in den Wartungsmodus zu befördern und wie lange er vor jedem Neuversuch warten soll.

Allerdings können Administratoren auch jederzeit die zu standardisierenden Hosts manuell in den Wartungsmodus schicken. Ferner ist es ratsam und im Schritt 6 des Standardisierungs-Assistenten möglich, Cluster-Feature wie DPM, HA Admission Control oder FT für die Dauer der Standardisierung abzuschalten. Nach Abschluss des Assistenten wird VUM den Host gegebenenfalls selbst mehrfach in den Wartungsmodus schicken oder neu starten, wenn dies zum Einspielen der Patches notwendig sein sollte.

*Über den Autor

Thomas Drilling ist freier Autor und IT-Berater. Auf DataCenter-Insider schreibt er seinen eigenen Blog: „Drillings Open-Source-Eck“.

Was meinen Sie zu diesem Thema?

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44702257 / Virtualisierung)