Tags: OS Deployment, ESXi, Netzwerk, DHCP
Auto-Deploy basiert zum Großteil auf PowerCLI und kann ESXi-Hosts via PXE vom Netzwerk starten. Dabei teilt es dem Host automatisch ein passendes Hypervisor-Image zu, das es von einem zentralen Repository holt. Admins können Regeln definieren, die festlegen, welche Maschinen welches Image erhalten 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 beispielsweise mit, welches Host-Profil und welches Image-Profil für welchen Host bereitzustellen 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 benutzerspezifische Informationen wie zum Beispiel IP-Adressen angegeben und gespeichert werden. Der Vorgang wird auch Host-Anpassung genannt und lässt sich mit Hilfe von Antwortdateien 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-Infrastruktur 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 Festplatten, 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 üblicherweise aus einem SAN oder per NFS-Freigaben 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 bereitzustellen.
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.
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.
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 Konfigurationsdaten (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.
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.
Täglich Know-how für IT-Pros mit unserem Newsletter
Thomas Drilling arbeitet ist seit fast 30 Jahren selbständig in der IT-Welt sowohl als Consultant, als auch als Redakteur, Buchautor und Journalist für viele ehemalige und aktuelle IT-Magazine sowie Blogs.
Aktuell bestätigt sich Thomas schwerpunktmäßig als IT-Trainer für Cloud-Computing in den Bereichen Microsoft Azure, Amazon Web Services und VMware.
Thomas ist zertifizierter Microsoft-Trainer für nahe das gesamte Portfolio an Microsoft Azure Trainings. Thomas ist außerdem zertifizierter Microsoft Azure Solutions Architect Expert sowie VMware Certified Professional und wurde von VMware in den Jahren 2016 bis 2022 mit dem Blogger-Status vExpert ausgezeichnet.
Thomas führt aktuell jeden Monat zwei selbstkonziperte 4-tägigen Grundlagenkurse in Cloud Computing mit Azure durch, die sich inhaltlich bewusst von den Microsft-Kursen abheben und vorzuweise als Bootcamp in eine besonderen Lokation stattfinden. Optional kann aber aber auch remote via Microsoft Teams teilgenommen werden.
Das aktuelle Trainingsprogramm findet sich unter Azure-Trainings. Weitere Informationen und Anmeldung über sein Azure-Blog.
Verwandte Beiträge
Weitere Links