Moderne Rechenzentren sind von Natur aus heterogen. Über die Lebensdauer eines Servers hinweg ändern sich die Anforderungen: Eine Maschine, die heute als VMware-ESXi-Host dient, könnte morgen Teil eines Kubernetes-Clusters sein oder eine Bare-Metal-Datenbank beherbergen. Doch die Realität der Provisioning-Prozesse hinkt dieser Flexibilität oft hinterher.
Das ESXi-Silo-Problem
Traditionell wird der VMware-Hypervisor ESXi in einem isolierten Workflow installiert – sei es manuell, über VMware-eigene Tools oder durch maßgeschneiderte Skripte. Sobald der Host einmal eingerichtet ist, endet die Automatisierung meist. Die Maschine ist nun ein "ESXi-Host", und das bleibt sie auch. Hardware-Aktualisierungen oder Rollenänderungen werden als seltene Ausnahmefehler behandelt, nicht als routinehafter Betrieb.
Dieser hostzentrierte Ansatz skaliert schlecht. Er führt zu einer gefährlichen Diskrepanz: Obwohl ESXi-Hosts Teil desselben Hardware-Pools sind wie andere Server, werden sie operativ in einem Silo verwaltet. Gerade vor dem Hintergrund der aktuellen Marktdynamik – Stichwort: Broadcom-Übernahme und Lizenzierungsänderungen bei VMware –, die viele Unternehmen dazu zwingt, ihre Infrastruktur-Abhängigkeiten zu überdenken, wird dieses Silo-Denken zum echten Risiko. Wer flexibel reagieren muss, kann es sich nicht leisten, dass das Umnutzen eines Servers den Einsatz komplett neuer Provisioning-Pfade erfordert.
Der Paradigmenwechsel: Bare Metal als API-gesteuerter Pool
Hier setzt Canonicals MAAS (Metal as a Service) an. Anstatt ESXi als Sonderfall zu behandeln, integriert MAAS den Hypervisor in einen gemeinsamen Bare-Metal-Lebenszyklus. Die Philosophie ist einfach: Physische Server sind ein Pool aus Ressourcen, die zugewiesen, freigegeben und neu bereitgestellt werden können. ESXi wird zu einer von mehreren möglichen "Rollen", die eine Maschine einnehmen kann – vergleichbar mit Linux oder Windows.
MAAS fungiert als hardware- und betriebssystemagnostische Kontrollebene. Der physische Server wird vom "Haustier" (Pet) zum "Nutztier" (Cattle): Er wird über eine API provisioniert, inventarisiert und verwaltet, unabhängig vom Hardware-Hersteller. Zu den Kernfunktionen gehören:
- Automatisiertes Hardware-Lifecycle-Management: MAAS entdeckt Server, inventarisiert sie und provisioniert sie über den BMC (Baseboard Management Controller).
- Infrastructure as Code (IaC): Die gesamte Infrastruktur lässt sich über eine Cloud-ähnliche API steuern und in DevOps-Tools wie Terraform, Ansible oder Juju integrieren.
- Integrierte Hardware-Diagnose: Vor dem Commissioning werden Tests ausgeführt, um sicherzustellen, dass nur fehlerfreie und performante Hardware ausgeliefert wird.
- Netzwerk-Konfiguration auf Bare-Metal-Ebene: Netzwerke (Interfaces, Bonds, VLANs, IP-Allokation) werden zentral in MAAS modelliert und konsistent angewendet – ohne dass VMware-spezifische Netzwerk-Tools für die Grundkonfiguration nötig sind.
Wie läuft das ESXi-Provisioning mit MAAS ab?
Aus Sicht von MAAS ist die Bereitstellung von ESXi kein Sonderfall, sondern folgt dem gleichen deterministischen Lebenszyklus wie jedes andere Betriebssystem:
- Discovery & Commissioning: Neue Server werden automatisch erkannt. Während der Commissioning-Phase inspiziert MAAS CPU, RAM, Storage und Netzwerk-Interfaces. Die Maschine ist zu diesem Zeitpunkt lediglich Hardware, die bereitsteht – kein ESXi-Host.
- Modellierung: Netzwerk und Storage werden zentral in MAAS definiert und bei Bedarf zugewiesen.
- Image-Deployment: ESXi wird als Custom Image in MAAS hochgeladen. Bei der Bereitstellung partitioniert MAAS den Speicher, schreibt das Hypervisor-Image auf die Festplatte und wendet Post-Deployment-Konfigurationen an – etwa die automatische Registrierung beim vCenter.
Kritische Einordnung: Kulturelle Hürden und operativer Mehrwert
Der Ansatz von MAAS ist logisch und für moderne, agile Infrastrukturen überfällig. Er bricht die operativen Mauern zwischen VMware-Admins und dem restlichen Rechenzentrumsbetrieb. Die Tatsache, dass eine Maschine heute ESXi laufen lassen und morgen als Kubernetes-Node dienen kann, ohne dass Provisioning-Prozesse neu erfunden werden müssen, ist ein massiver operativer Vorteil. Das Infrastructure-as-Code-Paradigma wird endlich auch auf die VMware-Welt ausgedehnt.
Allerdings gibt es auch Herausforderungen. Die Kultur in vielen Unternehmen ist tief in traditionellen VMware-Silos verankert. VMware-Administratoren sind es gewohnt, vCenter als die alleinige Wahrheit für ihre Hosts zu betrachten. Die Vorstellung, dass die Bare-Metal-Ebene – und damit die Existenzberechtigung des Hosts – von einem externen System wie MAAS gesteuert wird, erfordert ein Umdenken. Zudem muss die Erstellung und Pflege der ESXi-Custom-Images für MAAS sauber in den eigenen CI/CD-Prozessen integriert werden, um Versionsdrift und Sicherheitslücken zu vermeiden.
Trotz dieser kulturellen und prozessualen Hürden ist die Richtung klar: In einer Welt, in der Hardware-Ressourcen immer teurer und dynamischer verwaltet werden müssen, ist die Isolierung von Hypervisor-Provisioning ein Relikt der Vergangenheit. MAAS bietet einen überzeugenden Weg, ESXi in den allgemeinen Infrastruktur-Code aufzunehmen und Rechenzentren wirklich flexibel zu machen.
Quelle: Ubuntu Blog