Nachdem im ersten Beitrag die grundlegende Architektur von VCF 9 beschrieben wurde, geht es hier um die Fleet-Ebene selbst, genauer gesagt um die Komponenten, die dem VCF Fleet logisch zugeordnet sind.
VCF Operations
Wie bereits erwähnt, gab es in VCF 5.x für jeden Verwaltungsbereich ein eigenes Tool: SDDC Manager für Lifecycle-Aufgaben, Aria Operations für Monitoring, Aria Automation für Self-Service, Aria Suite Lifecycle für das Management der Aria-Komponenten selbst. Diese Tools waren miteinander integriert, aber nicht wirklich vereinheitlicht. Es gab keine einzige Oberfläche, von der aus alle Aufgaben erledigt werden konnten. Stattdessen musste man wissen, welches Tool für welche Aufgabe vorgesehen sind und sich dementsprechend zwischen den Konsolen bewegen.
Dieses Problem löst VCF Operations in VCF 9. Dabei handelt es sich nicht einfach um eine Umbenennung von Aria Operations, sondern um eine neu konzipierte Konsole, die Lifecycle-Management, Monitoring, Identity, Zertifikate, Passwörter, Lizenzierung und Kostenmanagement unter einer einzigen Oberfläche zusammenführt. Die alte SDDC Manager UI ist deprecated und wird nicht mehr für administrative Aufgaben verwendet.
Eine Bemerkung im Falle eines On-Place-Upgrades (aber nicht als „Rip-and-Replace“, sondern den SDDC Manager) der bestehenden VCF-Deployment. Der SDDC Manager läuft weiterhin als Backend-Appliance und wird im Hintergrund noch von anderen Komponenten genutzt, da bestimmte Aktionen, die man in vCenter auslöst, werden im Hintergrund tatsächlich vom SDDC Manager ausgeführt.
Aus technischer Sicht ist VCF Operations eine virtuelle Appliance bzw. ein Cluster aus mehreren VMs, die in der Management-Domain ausgeführt werden. Im Simple Mode (für LABs oder kleinere Umgebungen) besteht er aus drei Nodes (VMs): Operations Manager, Fleet Management Appliance und Operations Collector. Im High-Availability-Modus sind es fünf Nodes. Es gibt keine separate Kubernetes-Basis, sondern eine klassische VM-Appliance-Architektur. Die alten Aria-Produkte laufen nicht mehr als separate Installationen, sondern als Dienste innerhalb dieser Appliance-Cluster-Architektur.
Lifecycle Management
Eines der aufwendigsten operativen Daueraufgaben in VMware-Umgebungen ist regelmäßige Aktualisierung der Infrastruktur: ESXi-Hosts patchen, vCenter upgraden, NSX aktualisieren. Alles muss dabei in der richtigen Reihenfolge und ohne Produktionsausfall ablaufen. In VCF 9 läuft das über das Lifecycle Management in VCF Operations.
Das Prinzip hat sich gegenüber VCF 5.x konzeptionell nicht verändert: VCF verwaltet weiterhin ein sogenanntes Bill of Materials (BOM), eine definierte Kombination aus Versionen aller Plattformkomponenten, die als untereinander kompatibel und getestet gilt. Es werden nicht einzelne Komponenten nach Belieben aktualisiert, sondern man bewegt sich von einem BOM-Stand zum nächsten. Dadurch werden potenzielle Versionskonflikte verhindert und eine Umgebung, die den Support-Anforderungen entspricht, entsteht.
Die NSX-Aktualisierung wird zusammen mit ESXi-Upgrades ausgeliefert werden, da die NSX-Kernel-Module (VIBs – vSphere Installation Bundles) direkt im ESXi-Image enthalten sind. Dadurch entfallen separate Wartungsfenster für NSX-Host-Upgrade. Außerdem unterstützt VCF 9 auch Live Patching für ESXi, sodass Host-Upgrades ohne Maintenance Mode und ohne Unterbrechung von vMotion möglich sind.
Die Upgrade-Reihenfolge innerhalb einer VCF Instance hat sich leicht verändert: In VCF 9 wird NSX Manager als erstes aktualisiert, nicht mehr als eines der letzten Elemente.
Single Sign-On und Identity Management
Wer mehrere vCenter-Instanzen, NSX Manager sowie die verschiedenen Management-Komponenten einer VCF-Umgebung verwaltet, kennt die administrative „Herausforderung“ – jede Komponente hat ihr eigenes Authentifizierungsmodell. In VCF 5.x hat Enhanced Linked Mode zwar die vCenter-Instanzen zusammenverbunden, aber NSX und die Aria-Produkte mussten separat konfiguriert werden. Es gab zwar SSO in diesen Produkten, aber keine einheitliche Konfiguration. Die Komponente war einzeln mit dem Identity Provider verbunden, was eine separate Konfiguration der Rollen bedeutete.
VCF 9 löst dieses Problem mit dem VCF Identity Broker (VIDB). Der VIDB ist eine neue Komponente, die einmalig mit dem IdP des Unternehmens verbunden wird und danach als zentrale Authentifizierungsquelle für alle VCF-Komponenten dient. Er wird in VCF Operations konfiguriert und mit dem gewünschten Identity Provider verbunden. Unterstützt werden Active Directory, Entra ID, Okta, Ping und alle OIDC- oder SAML2-konformen Dienste. Im nächsten Schritt wird jede VCF-Komponente angewiesen, den VIDB als Authentifizierungsquelle zu nutzen. Danach gibt ein Administrator seine gewohnten Unternehmensanmeldedaten ein und erhält damit Zugang zu VCF Operations, vSphere Client, NSX Manager und VCF Automation, ohne sich bei jeder Komponente separat anmelden zu müssen.
Der Identity Broker kann in zwei Modi bereitgestellt werden: Embedded-Modus und Appliance-Modus.
Der Embedded-Modus läuft innerhalb des Management-Domain-vCenter und benötigt keine zusätzlichen Ressourcen. Er eignet sich eher für kleinere Umgebungen mit einer einzigen VCF Instance.
Der Appliance-Modus installiert den Identity Broker als eigenständigen 3-Node-Cluster und ist für größere Umgebungen oder Fleets mit mehreren Instanzen empfehlenswert. Ein einzelnes externes VIDB-Cluster kann dabei bis zu fünf VCF Instanzen bedienen.
Das bisherige Mittel (ELM – Enhanced Linked Mode), um mehrere vCenter-Instanzen in einer gemeinsamen SSO-Domain zu verbinden, ist in VCF 9 deprecated. Der gleiche Effekt, dass mehrere vCenter-Instanzen einer Fleet in einem einzigen vSphere Client sichtbar sind, wird jetzt über vCenter Groups erreicht. Dies wird in VCF Operations konfiguriert.
Der entscheidende technische Unterschied zum bisherigen Enhanced Linked Mode liegt daran, dass bei ELM alle verbundenen vCenter-Instanzen eine gemeinsame, replizierte SSO-Infrastruktur teilten. Würde es hier beispielsweise zu Replikationsfehlern oder einem Ausfall des Verzeichnisdienstes kommen, waren potenziell alle Instanzen gleichzeitig betroffen (Single Point of Failure). Mit den vCenter Groups sind die Instanzen dagegen technisch autark. Jedes vCenter operiert unabhängig voneinander. Ein lokaler Ausfall oder Wartungsarbeiten an einer Instanz haben keinerlei Auswirkungen auf die Verfügbarkeit und Verwaltung der übrigen vCenter in der Gruppe.
Zertifikatsverwaltung
In den vorherigen Versionen wurde überwiegend mit selbstsignierten Zertifikaten und manuellen Erneuerungsprozessen gearbeitet. VCF Operations hingegen verwaltet die Zertifikatsverwaltung für den gesamten VCF-Stack zentral.
Zertifikate können über mehrere Zertifizierungsstellen erneuert werden: über die integrierte VMware-CA (VMCA), über eine Microsoft-CA oder über eine OpenSSL-CA. Außerdem ist der Import extern signierter Zertifikate möglich. Der Ablauf dafür ist standardisiert: VCF Operations generiert einen Certificate Signing Request (CSR), der an die unternehmenseigene PKI übergeben wird. Das dort signierte Zertifikat wird anschließend in VCF Operations importiert und auf alle betroffenen Komponenten verteilt. Über ablaufende Zertifikate werden Administratoren direkt in VCF Operations informiert. Dies geschieht ohne zusätzliche Konfiguration. Im Vergleich zu früheren Versionen, bei denen das entsprechende Monitoring manuell eingerichtet werden musste.
Passwortverwaltung
Ähnlich wie bei Zertifikaten war das Rotieren von Komponentenpasswörtern in VMware-Umgebungen bisher ein manueller und fehleranfälliger Prozess. Dabei geht es nicht um AD-Service-Accounts, sondern um die internen Passwörter. Das sind die Passwörter, mit denen VCF-Komponenten miteinander kommunizieren. Zum Beispiel das Passwort, mit dem der SDDC Manager auf vCenter zugreift oder das Passwort, mit dem der NSX Manager auf ESXi-Hosts zugreift. Wenn ein solches Passwort zwischen zwei Komponenten nicht synchron war, führte das zu Verbindungsfehlern.
VCF Operations führt ein zentrales Passwort-Dashboard ein, das den Status aller Komponentenpasswörter auf einen Blick zeigt. Rotationen können manuell oder nach Zeitplan ausgelöst werden.
Lizenzierung
Die Lizenzierung in VCF 9 wurde deutlich vereinfacht. In VCF 5.x erhielt jede Komponente (z.B. vCenter, ESXi, NSX oder vSAN) einen eigenen 25-stelligen Lizenzschlüssel, der separat eingetragen und verwaltet werden musste. Das führte bei größeren Deployments zu einem erheblichen administrativen Aufwand.
In VCF 9 gibt es eine einzige Lizenzdatei pro VCF Operations Instanz, die alle Komponenten des gesamten Stacks abdeckt, wie z.B. ESXi-Cores, vSAN-Kapazität in TiB sowie Advanced Services wie Private AI Foundation. VCF Operations übernimmt die Verteilung und das Tracking der Lizenznutzung inklusive Usage Reports, die alle 180 Tage an Broadcom übermittelt werden. In mit dem Internet verbundenen Umgebungen geschieht dies automatisch. In Air-Gapped-Umgebungen wird der Report als Datei exportiert und muss anschließend manuell in das Broadcom-Lizenzportal hochgeladen werden. Ein initialer Internetzugang zur Aktivierung ist nicht erforderlich, da die Lizenzdateien weiterhin heruntergeladen werden können.
Kostenmanagement
Als letzten Punkt in diesem Überblick über die VCF Operations Komponenten ist nur für die Cloud Kunden oder Cloud Service Provider interessant. Mit den Funktionen „Showback” und „Chargeback” bietet VCF Operations die Möglichkeit, den Infrastrukturverbrauch einzelner Teams oder Applikationen zu erfassen und mit definierbaren Preismodellen zu verknüpfen.
VCF Automation
Wie aus der obigen Erklärung bereits ersichtlich ist, fokussiert sich VCF Operations auf die Infrastruktur-Administration. VCF Automation richtet sich an eine andere Zielgruppe: Entwickler, Platform Engineers und Applikationsteams, die Infrastruktur selbst provisionieren wollen, ohne jedes Mal ein Ticket öffnen zu müssen.
In VCF 5.x war Aria Automation für diese Funktionalität zuständig. VCF Automation in VCF 9 ist der direkte Nachfolger, allerdings wurde die Architektur neu strukturiert. Der entscheidende Unterschied liegt in der tiefen Integration in den VCF-Stack. Früher fungierten Aria-Komponenten eher als „Aufsatz“. Um diese Neustrukturierung besser zu verstehen, ist es hilfreich, zunächst die grundlegenden Rollen zu kennen, die das Modell umfasst.
Auf der einen Seite steht die IT-Abteilung als Provider. Sie administriert VCF Automation und hat im Wesentlichen folgende Aufgaben: Kapazitäten bereitstellen, Quotas definieren, den Self-Service-Katalog befüllen. Diese Seite ist immer vorhanden und wird als „Provider Organization” bezeichnet. Sie bildet das Fundament der Private Cloud.
Auf der anderen Seite stehen die Consumer, also die Teams, die aus diesem Self-Service-Katalog bestellen. Genau hier liegt die architektonische Neuerung in VCF 9. Es gibt jetzt zwei unterschiedliche Organisationstypen für Consumer, die verschiedene Anwendungsfälle abdecken:
Die VM Apps Organization entspricht im Wesentlichen dem bekannten Aria Automation 8.x Modell. Dieses richtet sich an Teams, die primär virtuelle Maschinen, Netzwerke und Storage-Volumes benötigen, um „traditionelle“ Anwendungen in einer isolierten, klassischen Umgebung zu betreiben.
Die All Apps Organization (oder All Apps) ist neu in VCF 9 und geht deutlich weiter, indem sie eine einheitliche Plattform für „Cloud Native“ Workloads bietet. Sie basiert auf Kubernetes-APIs und ist auf dem vSphere Supervisor aufgebaut. Hier können Entwickler sowohl virtuelle Maschinen als auch Kubernetes-Cluster bereitstellen. Dieser Organisationstyp löst die technologische Trennung zwischen klassischer IT und moderner App-Entwicklung auf. Jede All Apps Organization bekommt dabei ihr eigenes NSX-Projekt mit isoliertem VPC, welches direkt für eine saubere Mandantentrennung auf Netzwerkebene sorgt.
Beide Organisationstypen können gleichzeitig in derselben VCF-Umgebung existieren. Diese Koexistenz ermöglicht es der IT-Abteilung, sowohl klassische, VM-basierte Anwendungen als auch moderne, containerbasierte Microservices auf einer einzigen, konsolidierten Infrastruktur-Plattform zu betreiben.
Im Vorfeld müssen nur die Rahmenbedingungen definiert werden: welche Ressourcen zur Verfügung stehen, welche Quotas gelten welche Sicherheits- sowie Compliance-Richtlinien greifen müssen. Die eigentliche Provisionierung wird dem jeweiligen Applikationsteam überlassen und lässt sich ebenfalls direkt in bestehende CI/CD-Pipelines integrieren.
Technisch gesehen wird VCF Automation ähnlich wie VCF Operations als virtuelle Appliance in der Management-Domain bereitgestellt: im Simple-Mode als einzelne VM und im High-Availability-Modus als 3-Knoten-Cluster.
VCF Operations HCX
VCF Operations HCX ist das dritte Werkzeug auf Fleet-Ebene und das einzige, das optional ist und separat lizenziert wird. Es existiert bereits seit VCF 5.x als Add-on, wurde in VCF 9 aber tiefer in den Stack integriert. HCX steht für „Hybrid Cloud Extension” und deckt einen spezifischen Bedarf ab: die Migration von Workloads zwischen verschiedenen Umgebungen. Beispielsweise zwischen Rechenzentren, von älteren vSphere-Infrastrukturen in VCF, zwischen On-Premises- und Public-Cloud-Umgebungen oder bei einem Hardware-Refresh mit laufenden Workloads.
Anstelle der bisherigen getrennten Appliances für Quelle und Ziel gibt es in VCF 9 nur noch einen einheitlichen HCX-Manager, der an beiden Standorten installiert wird. Die Lizenzierung und das SSO teilt HCX mit dem Rest der Plattform.
Während der Migration baut HCX einen verschlüsselten Tunnel zwischen den Standorten auf und streckt das Quellnetzwerk mittels Layer-2-Extension zum Ziel. Dabei behalten die VMs ihre IP-Adressen und laufende Verbindungen bleiben erhalten. Je nach gewählter Migrationsmethode läuft die Migration entweder vollständig im Hintergrund durch oder es kommt lediglich zu einer kurzen Unterbrechung von wenigen Sekunden.