VMware Auto-Deploy: Architektur und Betriebsarten

    VMware Auto-DeployAuto-Deploy basiert zum Groß­teil auf PowerCLI und kann ESXi-Hosts via PXE vom Netz­werk starten. Dabei teilt es dem Host automatisch ein pas­sendes Hyper­visor-Image zu, das es von einem zen­tralen Reposi­tory holt. Admins können Regeln defi­nieren, die fest­legen, welche Ma­schinen welches Image er­halten oder in welchem Cluster sie platziert werden.

    Die Infrastruktur für Auto Deploy benötigt daher folgende Komponenten:

    • Auto-Deploy-Server: verwaltet Server-Images und Hostprofile
    • Auto-Deploy Rules-Engine: kommuniziert mit dem Auto-Deploy-Server und teilt diesem beispiels­weise mit, welches Host-Profil und welches Image-Profil für welchen Host bereit­zustellen ist.
    • Image-Profil: enthält ein spezifisches VIB-Set, mit dem ein bestimmter Host gebootet werden soll. Mit dem Image-Builder lassen sich individuelle Image-Profile erstellen.
    • Host-Profil: enthält die Host-spezifische Konfiguration wie das Storage- oder Netzwerk-Setup. Ein Host-Profil lässt sich mit einem GUI-Werkzeug im Web Client für einen Referenz-Host erstellen und auf andere Server in der Umgebung anwenden. Das erleichtert eine konsistente Host-Konfiguration.
    • Antwort-Datei: Beim Anwenden von Host-Profilen müssen benutzer­spezifische Informationen wie zum Beispiel IP-Adressen angegeben und gespeichert werden. Der Vorgang wird auch Host-Anpassung genannt und lässt sich mit Hilfe von Antwort­dateien automatisieren.

    Betriebsmodi

    Auto-Deploy kennt seit der Version 5.1 neben dem Standardmodus noch zwei weitere Betriebsarten, welche die Abhängigkeit von der Auto-Deploy-Infra­struktur wie Auto-Deploy-Server oder TFTP- und DHCP-Server (PXE-Envrionment) verringern. In der Default-Konfiguration ist der Auto-Deploy-Server ein Dienst auf dem vCenter-Server und auch einen TFTP-Server liefert VMware mit, zumindest wenn man die Linux-Appliance verwendet.

    Standardmodus für Server ohne lokale Disk

    Nutzt der Admin Auto-Deploy so, wie ursprünglich vorgesehen, dann benötigen die beteiligten ESXi-Hosts keine lokalen Fest­platten, weil der Hypervisor überhaupt nicht installiert wird. Vielmehr booten die Hosts bei jedem Neustart aus ihrem Image über das Netz. Shared Storage für die Datastores werden üblicher­weise aus einem SAN oder per NFS-Freihaben angebunden.

    In dieser Betriebsart ist es für Administratoren einfach, eine neue ESXi-Version einzuführen, denn es genügt, beim jeweils nächsten Start ein aktualisiertes Image bereit­zustellen

    Stateless Caching

    Im Modus Stateless Caching kann der Admin im jeweiligen Host-Profil definieren, dass Auto-Deploy das Image auf dem betreffenden Host selbst ablegt, sofern er über lokalen Speicher verfügt. Initial booten wird dieser Host dann zwar immer noch via PXE.

    Ist aber später ein Neustart erforderlich oder gewünscht, dann kann der Host direkt vom lokal abgelegten Abbild booten. Dies tut er auch dann, wenn der Auto-Deploy-Server nicht erreichbar ist. Auf jeden Fall muss das Image nicht neu durch das Regelwerk konfiguriert werden.

    Stateful Installs

    Die dritte Betriebsart Stateful Installs beseitigt die Abhängigkeit von vCenter bzw. vom Auto-Deploy-Server vollends, da das Image hierbei auf herkömmliche Weise installiert wird. Nach dem nächsten Neustart booten die Server direkt vom ihrer lokalen Platte.

    Hierbei operiert Auto-Deploy ähnlich wie die Windows Deployment Services und dient nur dem einmaligen Bereitstellen einer großen Anzahl von ESXi-Hosts.

    Auto-Deploy-Architektur und Workflow

    Der Kern des Automatisierungs-Frameworks von Auto-Deploy basiert wie auch schon der Image-Builder auf PowerCLI, letztendlich handelt es sich dabei um einen Satz von PowerShell-Skripten und Cmdlets. Folgende Abbildung illustriert den prinzipiellen Aufbau der Auto-Deploy-Architektur.

    Die grundlegende Architektur von VMware Auto-Deploy

    Der Auto-Deploy-Server selbst ist ein Web-Service, den etwa das vCenter Server Appliance (vCSA) bereitstellt. Er lässt sich als Dienst im Web Client aktivieren. Im Zentrum der Auto-Deploy-Architektur operiert die so genannte Rules-Engine.

    Mit ihrer Hilfe kann der Admin Regeln erstellen, die unter anderem dafür sorgen, dass ein Host beim PXE-Boot das richtige Image und die für ihn bestimmte Konfiguration in Form eines Host-Profils aus dem gewählten Repository erhält. Ferner regeln Deployment-Rules, dass der jeweilige Host nach dem Booten auch im richtigen Cluster platziert wird.

    Mit Hilfe von Regeln lassen sich spezifische Konfigurationen an bestimmte Hosts zuteilen.

    Die dritte wichtige Komponente im Rahmen des Auto-Deploy-Workflows sind die eben erwähnten Host-Profile. Sie sind ein von VMware mit Version 4.1 eingeführtes Enterprise-Plus-Feature.

    Primär erleichtern Host-Profile ein konsistentes Konfigurieren einer großen Anzahl von ESXi-Hosts. Dabei können sie die Einstellungen eines Referenz-Hosts auf mehrere Server übertragen. Auch dieses Feature wurde von VMware sukzessiv weiter ausgebaut, zuletzt in vSphere 6.5.

    Die Rolle von vCenter

    Der Auto-Deploy-Service selbst läuft wie erwähnt als Dienst auf einem vCenter Server. Da Auto-Deploy außerdem im Idealfall ohne Platten in den beteiligten ESXi-Hosts auskommt, bedarf es zusätzlich eines vCenter-Servers zum Speichern der Running States der beteiligten Hosts. Beide vCenter müssen nicht identisch sein.

    Während ein vCenter die Laufzeit-Stati wie das VM-Inventory, den HA-Status, die Lizenz oder Informationen für das Distributed Power Management (DPM) vorhält, stecken sämtliche Konfigurations­daten (Netzwerk, vSwitches, Storage, Firewall, Zeitserver oder das Admin-Password) im jeweiligen Host-Profil. Dieses wird von demjenigen vCenter verwaltet, auf dem der Auto-Deploy-Service läuft.

    vCenter speichert die Laufzeit-Stati und Konfigurationdaten für Disk-less Hosts, die vom Netz booten.

    Das Image-Profil wiederum enthält das Basis-ESXi-Image, zusätzliche Treiber und CIM-Provider. So stehen mit Hilfe eines (oder mehrerer) vCenter sämtliche Informationen für das Booten von ESXi bereit, auch ohne dass der Host über eine Boot-Disk verfügt. Event-Information und Log-Files können dann ebenfalls von vCenter oder von einem externen Syslog-Service aggregiert werden.

    Im nächsten Teil dieser Reihe befassen wir uns mit der Einrichtung von Auto-Deploy alseingebetteten Dienst auf einem vCenter-Server.

    Keine Kommentare