kentoh - Fotolia

VMware Auto Deploy: Architektur und Arbeitsweise

VMware Auto Deploy eignet sich für das plattenlose Provisionieren und Starten von ESXi-Servern. Gut bei zahlreichen ESXi-Hosts in unterschiedlichen Konfigurationen und Umgebungen.

Mit der seit vSphere 6.5 erstmals vollständigen Integration sämtlicher von Auto Deploy benötigten Komponenten in vCenter-Server und Web Client gelingen Konfiguration und Inbetriebnahme einfacher als je zuvor.

Mit Auto Deploy adressiert VMware vor allem Unternehmen, die eine große Anzahl von ESXi-Hosts in unterschiedlichsten Konfiguration und Umgebungen bereitstellen müssen. Dabei geht es nicht nur um das initiale Deployment. Da in der Standardbetriebsart von Auto Deploy ESXi-Hosts direkt aus einem Image über das Netzwerk starten, bietet sich Auto Deploy auch als Werkzeug für das Patch-Management – zum Beispiel als Ersatz für den Update Manager – an, wenn es dem Admin gelingt, seine Images für jeden einzelnen Host aktuell zu halten.

Auto Deploy dient in erster Linie dazu, ESX-Hosts via PXE vom Netzwerk zu starten, wobei die so genannte Auto Deploy Engine dem jeweiligen Host automatisch ein für ihn passendes Hypervisor-Image zuweist, dass aus zentral vorgehaltenen Image-Profilen generisch erzeugt wird. Die Infrastruktur dazu besteht aus folgenden Komponenten:

  • Der eigentliche Auto Deploy-Server ist – zumindest in der Variante mit Photon-Linux-basierter vCenter-Server-Appliance (vCSA) – ein Dienst auf dem vCenter-Server, der sich einfach im Web Client aktivieren lässt. Seine …
  • … Auto Deploy Rules Engine kommuniziert direkt mit dem Auto-Deploy-Server etwa darüber, welches Host-Profil und welches Image-Profil für welchen Host in welchem Cluster dieser bereitzustellen hat.
  • Ein Image-Profil dient dabei als Paketbasis zum Erstellen eines Start-Images, das eine Host-spezifische Zusammenstellung von VIB-Paketen enthält, mit dem ein bestimmter Host gestartet werden kann.
  • Mit dem Image Builder lassen komfortabel individuelle Image-Profile im Web Client erstellen.
  • Host-Profile wiederrum sind ein für Auto Deploy unabdingbares Enterprise-Plus-Feature. Jedes Host-Profil enthält eine Host-spezifische Konfiguration etwa für das Netzwerk- oder Storage-Setup. Es wird im Web Client von einem ausgewählten Referenz-Host „abgezogen“ und lässt sich dann auf weitere ESXi-Server „anwenden“, um diese dadurch mit einer konsistenten Konfiguration zu versehen, ein Standardisieren des Hosts genannter Prozess.
  • Da beim Anwenden von Host-Profilen auch benutzerspezifische Informationen wie zum Beispiel IP-Adressen angegeben und gespeichert werden, können vorbereitete Antwort-Dateien dabei helfen, auch diesen Prozess automatisieren zu können.

Auto-Deploy-Betriebsarten

Seit der ESXi-Version 5.1 kennt Auto Deploy neben dem Standardmodus (also das plattenlose Starten eines ESXI-Hosts) zwei weitere Betriebsarten, mit denen sich die Abhängigkeit von der Auto-Deploy-Infrastruktur wie Auto-Deploy-Server oder TFTP- und DHCP-Server (PXE-Environment) verringern lässt, wobei vCenter-Server standardmäßig der Auto-Deploy-Server als Dienst und ein PXE-Bootstrap-Image nebst TFTP-Server bereit gestellt werden. Um den DHCP-Server und dessen Konfiguration muss sich der Nutzer selbst kümmern.

In der Standard-Betriebsart von Auto Deploy für ESXi-Server ohne lokale Disks booten die Hosts bei jedem Neustart aus ihrem Image über das Netz und die PXE-Infrastrukur, wobei Shared Storage für die Datastores üblicherweise per SAN oder NAS über das Netzwerk angebunden ist.

Da die Host-Konfiguration in Form eines Host-Profils in diesem Szenario ebenfalls vom vCenter-Server kommt, muss sich der Admin bei dieser Variante lediglich Gedanken darüber machen, wohin gegebenfalls Laufzeitdaten wie zum Beispiel Log-Files und Swap-Files geschrieben werden.

Vom Host-Standard abweichende Konfigurationen (normalerweise lokale Disks/USB) lassen sich über erweiterte Host-Parameter steuern und im Host-Profil referenzieren. Auch ist es in dieser Betriebsart wie oben skizziert einfach, eine neue ESXi-Version einzuführen, indem beim jeweils nächsten Neustart ein aktualisiertes Image referenziert wird.

Im Modus Stateless Caching legt Auto Deploy das individuelle Image auf dem betreffenden Host selbst ab, sofern dieser über lokalen Speicher verfügt. Initial starten wird der Host dann zwar dann nach wie vor über die PXE-Infrastruktur, nach einem Neustart aber kann ein ESXi-Host dann direkt vom lokal abgelegten Abbild booten. Dies macht er auch dann, wenn der Auto-Deploy-Server nicht erreichbar ist. Das Image muss aber nicht bei jedem Start neu durch das Auto Deploy-Regelwerk erstellt und zugewiesen werden.

Im Betriebsmodus Stateful Installs entfällt die Abhängigkeit von vCenter beziehungsweise vom Auto-Deploy-Server vollständig, weil das durch Auto Deploy vorbereitete Image auf herkömmliche Weise installiert wird. Ein Host muss dazu über lokale Platten verfügen, damit er nach der Installation direkt davon booten kann. Die Auto-Deploy-Infrastruktur dient also hier nur als Hilfsmittel zum komfortablen Installieren einer großen Anzahl von ESXi-Hosts.

Die jeweilige Auto Deploy-Betriebsart wird im Host-Profil für den betreffenden Host festgelegt.

Auto-Deploy-Architektur und Workflow

Bei früheren vSphere-Versionen bestanden der Auto-Deploy-Server selbst nebst Rules Engine und der Image Builder aus einem Satz von PowerCLI-Skripten. Wer ein vCenter in der Windows-Version einsetzt, muss nach wie vor auf diese Variante zurückgreifen. Bei der aktuellen Photon-basierten Appliance-Variante VCSA sind alle Komponenten voll in Linux integriert und grafisch im Web Client konfigurierbar.

Während das bei Windows-basierten vCentern und älteren Versionen (< 6.5) nur für Host-Profile der Fall ist, gilt das bei der VCSA-Appliance auch für den Image Builder. Der Auto-Deploy-Server selbst lässt sich hier einfach als Dienst im Web Client aktivieren und starten.

Der Auto-Deploy-Dienst im vSphere Web Client.
Abbildung 1: Der Auto-Deploy-Dienst im vSphere Web Client.

Ohne vCenter ist Auto Deploy – abgesehen davon, dass der Auto Deploy-Server hier selbst als Dienst läuft – nicht nutzbar, da ein vCenter auch Laufzeitinformationen der ESXi-Hosts wie das VM-Inventar, den HA-Status, die Lizenz und Informationen zum DPM und vieles mehr vorhält. Die Konfigurationsdaten der Hosts (Netzwerk, vSwitches, Storage, Firewall, Zeitserver oder das Admin-Password) werden ebenfalls vom vCenter in Form der erwähnten Host-Profile verwaltet, genau genommen auf demjenigen vCenter, auf dem der Auto Deploy-Service läuft.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!

Nächste Schritte

vSphere-Grundlagen: ESXi, vCenter und Shared Storage

vCenter-Umgebungen auf ESXi 6.5 aktualisieren

Konsistente ESXi-Konfiguration mit VMware Host Profiles

Artikel wurde zuletzt im November 2017 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über VMware

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

Close