VMware vSphere Auto-Deploy: Voraussetzungen und Vorbereitungen


    Tags: , , , ,

    Layout der Infrastruktur für vSphere Auto-DeployAuto-Deploy setzt eine rela­tiv kom­plexe Infra­struk­tur aus vCenter, TFTP- und DHCP-Server voraus, um ESXi über das Netz zu booten oder zu instal­lieren. Daher sind erst mehrere Voraus­setz­ungen zu prüfen und Vorbe­rei­tungen zu treffen. Das Setup wurde mit vSphere 6.5 einfacher.

    Vor dem Einrichten von Auto-Deploy muss der vSphere-Admin einige Voraussetzungen klären bzw. schaffen, um ESXi erfolgreich auf die Hosts übertragen zu können. Diese betreffen die Hardware, die Netzwerk- und Speicher­konfiguration sowie das Logging:

    • Sämtliche Hosts, die via Auto-Deploy betankt werden sollen, müssen den VMware Hardware-Anforderungen für ESXi genügen.

      Tipp: Besitzen Server noch ein Legacy-BIOS, dann muss der Auto-Deploy-Server eine IPv4-Adresse besitzen, da Legacy-BIOS-Firmware nur via IPv4 von PXE booten kann. UEFI-Firmware hingegen kommt auch mit IPv6 und PXE zurecht.
    • Hosts müssen eine Netzwerk­verbindung zum vCenter-Server aufbauen können. Dazu gehört, dass die erforderlichen Ports für die Kommunikation mit vCenter (902) und dem Plattform Services Controller (PSC) erreichbar sind, was in der Standard-Konfiguration der Fall ist.

      Tipp: Sämtliche von einem ESXi-Host standardmäßig benötigten und bei einer Standard-Installation geöffneten Ports findet man in diesem Dokument. Ähnliches gilt auch für den vCenter-Server. Dessen Standard-Ports findet man hier oder etwas übersichtlicher in diesem Dokument. So benötigt Auto-Deploy selbst TCP-6501 für den Auto-Deploy-Service und TCP-6502 für das Auto-Deploy-Management.
    • Bei Verwendung von VLANs ist eine funktionale Ende-zu-Ende-Kommunikation zu gewährleisten. Der zuständige DHCP-Server muss also auch dann via Broadcasts erreichbar sein, wenn er in einem VLAN-Segment steht. Die ESXi-Portgruppen auf den beteiligten vSwitches müssen mit der richtigen VLAN-ID versehen sein und es ist darauf zu achten, dass der Firmware-Treiber für das Taggen der Ethernet-Frames auf den ESXi-Hosts mit der gleichen VLAN-IDs konfiguriert ist.
      Dies lässt sich ja nach verwendeter Netzwerk-Hardware manuell im BIOS/UEFI des Hosts oder im BIOS der PXE-fähigen Netzwerkkarte einstellen, sofern sie es unterstützt. Andernfalls helfen möglicherweise Native VLANs. Insgesamt ist die Konfiguration von PXE-Boot mit VLANs nicht ohne Fallstricke. Auf der anderen Seite handelt es sich hierbei um ein durchaus gängiges Szenario.
    • Zudem ist wie bei jeder PXE-basierten Bereitstellungs­methode an eine Sicherung des Netzwerks zu denken. vSphere Auto-Deploy überträgt die Daten zwar über SSL, die Authentizität des Clients oder des vSphere Auto-Deploy-Servers wird aber beim Start des PXE-Start­vorgangs nicht überprüft.
    • Der vSphere Auto-Deploy-Server verwendet das Repository zum Speichern von Regeln/Regelsätzen, VIBs und Image-Profilen, welche in den Policies angegeben werden. VMware empfiehlt als Best Practice 2 GB Speicherplatz. Dies reicht für vier Image-Profile und eine Reserve. Jedes Image-Profil benötigt ungefähr 350 MB.
    • Der vSphere-Admin benötigt auch Administrator­rechte auf dem zuständigen DHCP-Server oder dem Scope, der das Netzwerk­segment verwaltet, aus dem die Hosts starten.
    • Schließlich benötigt man einen Remote-Syslog-Server, beispielsweise vRealize LogInsight for vCenter, wenn Auto-Deploy in seiner ursprünglichen Betriebsart mit plattenlosen Hosts zum Einsatz kommen soll. Das Verteilen einer Remote-Syslog-Konfiguration kann mit Hilfe von Host-Profilen erfolgen.
      Alternativ kann hierfür der vSphere Syslog Collector verwendet werden. Dabei handelt es sich um einen Dienst von vCenter, der über den Web Client im Menü Administration aktiviert werden kann. Er bietet eine einheitliche Architektur für die System­protokollierung.

    Starten des Auto-Deploy-Dienstes

    Seit vSphere 6.5 lässt sich Auto-Deploy wahlweise GUI-basiert im Web Client oder mit Hilfe von PowerCLI-Cmdlets verwalten. Im letzteren Fall ist vorher sicherzustellen, dass mindestens das .NET Framework 4.5 oder 4.5.x und Windows PowerShell 3.0 auf dem Windows-PC installiert sind, von dem aus das Auto-Deploy-Setup gesteuert wird. Läuft vCenter auf einem Windows Server, kann PowerCLI auch auf diesem installiert werden.

    Der Dienst für Auto-Deploy lässt sich im vSphere Web Client starten

    Das Aktivieren des Auto-Deploy-Dienstes und ggf. der GUI für Image-Builder in vCenter ist nur ein Schritt im Auto-Deploy-Setup, das wir vollständig im nächsten Teil beschreiben und das seit vSphere 6.5 recht einfach zu bewerkstelligen ist.

    Hierzu navigiert man im Web Client zu Administration, dort in den Bereich System Configuration und klickt dann auf Services. Hier lassen sich die einzelnen vCenter-Dienste komfortabel starten oder beenden.

    Das weitere Vorgehen unterscheidet sich bei einem Windows-basierten vCenter und der vCSA geringfügig. Bei der Windows-Variante ist der Auto-Deploy-Dienst standardmäßig deaktiviert (Disabled). Der Admin muss also zunächst den Starttyp bearbeiten und wahlweise auf Manual oder Automatic stellen, bevor er den Dienst mit dem grünen Startsymbol oben rechts neben dem Dienstnamen oder direkt über das Kontextmenü des Dienstes starten kann.

    Nach dem Starten des Diestes steht in vSphere 6.5 eine GUI für Image Builder zur Verfügung.

    Bei vCenter Server Appliance (vCSA), die in Version 6.5 auf Photon basiert, ist der vSphere Auto-Deploy-Dienst per Default Manual. Ähnliches gilt für den in Version 6.5 optional aktivierbaren Image-Builder-Dienst. Der ist in der Windows-Version deaktiviert und in vCSA auf Manual gesetzt. Auch er lässt sich in Version 6.5 komfortabel über den Web Client starten.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Thomas Drilling
    Thomas Drilling arbeitet seit mehr als 20 Jahren selb­ständig als Redakteur und Autor für viele ehe­malige und aktuelle IT-Magazine sowie Blogs. Thomas ist zudem Buch­autor und IT-Consultant. Seit 5 Jahren ist Thomas neben seiner journa­listischen Tätig­keit haupt­beruflicher, selb­ständiger IT-Trainer für VMware und Microsoft.

    Seine Themen­schwer­punkte sind Virtua­lisierung und Cloud Com­puting, speziell VMware, Amazon Web Services, Google Cloud und Microsoft Azure. Thomas ist zerti­fi­zierter VMware Professional, Advanced Professional und wurde von VMware in den Jahren 2016, 2017, 2018, 2019 und 2020 mit dem Blogger-Status vExpert ausge­zeichnet.

    Thomas ist außerdem zertifi­zierter AWS Solu­tions Archi­tect, Sysops Engineer und Devops Engineer sowie Microsoft Certified Azure Admini­strator.

    Thomas führt aktuell jeden zwei­ten Mon­tag einen 4-tägigen Grund­lagenkurs in Cloud Computing mit AWS via Zoom-Meeting durch. Weitere Infor­mationen und Anmel­dung über sein AWS-Blog.

    Ähnliche Beiträge

    Weitere Links