VMware vSphere strukturieren: Datacenter, Cluster, Resource Pools, Ordner

In der Praxis wäre es jedoch ungünstig, wenn die gesamte Ausstattung der versammelten ESXi-Server in einer flachen Struktur verwaltet werden müsste. Damit stünde die Gesamtkapazität für alle Anwendungen und Benutzer zur Verfügung, und die Zugriffsrechte ließen sich nur global regeln. Aus diesem Grund kennt vSphere mehrere logische Einheiten, um die Bestandslisten zu untergliedern.

Sie fassen die Objekte in Teilbereiche zusammen, die sich besser verwalten lassen. Sie erleichtern das Auffinden von VMs, Hosts, Speichersystemen sowie von Netzwerken. Zudem vereinfachen sie das Monitoring, weil sich Alarme an die jeweiligen Ebenen binden lassen, und Ereignisse abhängig vom Ort in der Hierarchie spezifische Aktionen auslösen. Administratoren können Rechte für Objekte in einem Container an ausgewählte Benutzer und Gruppen vergeben.

Datacenter

Richtet man einen neuen vCenter-Server ein und beginnt mit der Organisation der Bestandsliste, dann besteht üblicherweise der erste Schritt darin, ein Datacenter ("Datencenter" in der lokalisierten Version) anzulegen. Es dient als primärer und somit als übergeordneter Container für alle Objekte, darunter Hosts, VMs, Cluster oder Resource-Pools, lässt sich aber bei Bedarf selbst aber in Ordner aufnehmen.

VMware vCenter erlaubt das Anlegen mehrerer Datacenter, wobei diese keines­wegs die tatsächlichen physikalischen Rechenzentren abbilden müssen. Die Ausrichtung von Datencentern an Netztopologien und an Speicher­ver­bindungen ist insgesamt jedoch plausibel, weil sie den Kontext für vMotion definieren und eine Live Migration von VMs zwischen Datencentern nicht möglich ist (diese Einschränkung fällt erst mit vSphere 6.0).

Datacenter bilden indes nicht nur die Grenze für vMotion, sondern dienen auch als Namensraum für einige darin enthaltene Objekttypen. So dürfen innerhalb eines Datacenter keine zwei virtuellen Netze oder Datastores mit dem gleichen Namen existieren. Dennoch ist von identischen Bezeichnungen in verschiedenen Datacenters abzuraten, weil sie beim Verschieben von VMs zu Nebeneffekten führen können, beispielsweise wenn sie an ein gleichnamiges Netz angebunden werden, das aber einem anderen physikalischen Segment angehört.

Cluster

VMware beschreibt einen Cluster ganz allgemein als Gruppe von Hosts mit gemeinsamen Ressourcen, die als eine Einheit verwaltet wird. Fügt man einen ESXi-Server zu einem Cluster hinzu, dann geht er mit seiner gesamten Ausstattung in diesem Cluster auf. Dieser umfasst somit die gesamte Rechenleistung und das ganze RAM der physischen x86-Server, wobei sie sich im selben Netzwerk befinden und dieselben Speicher-Arrays gemeinsam nutzen. Ordnet der Administrator dem Cluster eine VM zu, dann erhält sie automatisch die benötigten Ressourcen aus dessen Bestand.

Die wichtigsten Funktionen eines Clusters sind generell die Gewährleistung von hoher Verfügbarkeit und die dynamische Lastenverteilung. Bei VMware sind dafür HA (High Availability) und DRS (Dynamic Resource Scheduler) zuständig. Sie lassen sich nur auf Cluster-Ebene aktivieren, so dass diese Features nicht über die Grenzen eines solchen Host-Verbunds hinaus wirksam sind.

Beim Anlegen eines neuen Clusters im vSphere Web Client erscheinen HA und DRS als Optionen, die per Voreinstellung deaktiviert sind. HA startet VMs automatisch neu auf einem anderen Knoten des Clusters, falls sie durch den Defekt eines Hosts nicht mehr verfügbar sind. HA platziert einen Agent auf allen Hosts des Clusters, um über den Ausfall eines Servers informiert zu werden.

DRS überwacht den Ressourcenverbrauch der aktiven virtuellen Maschinen und die Auslastung der Hosts in einem Cluster. Unter Berücksichtigung von Policies für die Platzierung von VMs verschiebt sie DRS mit Hilfe von vMotion auf andere Knoten im Rechnerverbund. Eng verbunden mit DRS ist DPM (Distributed Power Management), das Hosts ohne aktive VMs in den Energiesparmodus versetzt.

Neben HA und DRS werden drei weitere Features auf Cluster-Ebene konfiguriert. Es handelt sich dabei um FT (Fault Tolerance), EVC (Enhanced vMotion Compatibility) und vSAN (Virtual SAN).

Während HA nach Defekten an einem Host dessen VMs auf einem anderen Server neu startet, geht FT darüber hinaus, indem es Ausfallsicherheit garantieren soll. Zu diesem Zweck läuft parallel zur Original-VM eine weitere Instanz im Gleichschritt auf einem anderen Server. Fällt ein Host aus, kann FT sofort zur zweiten aktiven VM umschalten. Eine wesentliche Einschränkung besteht bis dato darin, dass FT nur VMs mit einer vCPU und damit kein vSMP unterstützt. Diese überwindet vSphere 6.0, indem es FT für VMs mit bis zu 4 vCPUs erlaubt.

EVC soll dagegen sicherstellen, dass sich VMs per vMotion zwischen Hosts migrieren lassen, wenn diese nicht über identische Prozessoren verfügen. Dieses Features stellt den kleinsten gemeinsamen Nenner zwischen neueren und älteren CPUs her, indem die Server eines Clusters abhängig von den verwendeten Baselines einen identischen Funktionsumfang präsentieren. Eine Kompatibilität zwischen Chips verschiedener Hersteller wie Intel und AMD kann EVC aber nicht erzielen.

Bei vSAN schließlich handelt es sich um eine Neuerung von vSphere 5.5, die lokalen Speicher von ESXi-Hosts zu einem Shared Storage zusammenfasst (siehe dazu: Server-Laufwerke als Shared Storage nutzen).

Resource Pools

Resource Pools sind ein weiterer Mechanismus, um die von vSphere verwaltete Rechenleistung sowie den Arbeitsspeicher zu segmentieren. Sie eignen sich besonders dafür, um das virtualisierte Rechenzentrum auf die Unternehmensstruktur abzubilden. Beispielsweise kann man damit einen bestimmten Teil der verfügbaren Ressourcen einzelnen Abteilungen oder sonstigen Organisationseinheiten zuteilen.

Ein Resource Pool partitioniert entweder die Kapazität eines Clusters oder eines einzelnen Hosts und reserviert so die benötigte Leistung für bestimmte Anwendungen. Wenn ein Host einem Cluster angehört, dann lässt sich auf ihm kein Resource Pool einrichten, sondern nur über den Umweg des Server-Verbunds. Pools dürfen auch verschachtelt werden, so dass sie nicht nur CPU-Leistung und RAM eines Clusters bzw. eines Hosts, sondern auch eines anderen Resource Pools beanspruchen können.

Resource Pools verhalten sich dynamisch, so dass sie nicht permanent die für sie reservierten Kapazitäten blockieren. Vielmehr können diese von anderen Workloads genutzt werden, wenn die Anwendungen des Resource Pools die ihnen zugeordnete Leistung nicht benötigen.

Die Partitionierung von Hosts und Cluster erfolgt zudem nicht statisch, so dass den Resource Pools während der Laufzeit ihrer VMs Rechenleistung und RAM hinzugefügt oder entzogen werden können. Allerdings erfolgt die anschließende Umschichtung der Ressourcen nicht abrupt, um nicht andere Applikationen zu beeinträchtigen.

Ordner

Bei Ordnern handelt es sich um administrative Einheiten, die einer besseren Übersichtlichkeit dienen, indem sie vSphere-Ressourcen etwa nach Funktion oder Standort strukturieren. Darüber hinaus erlauben Ordner die Vergabe von Rechten auf alle darin enthaltene Objekte.

Die wesentliche Einschränkung dieser Art von Container besteht darin, dass sie nur Objekte des gleichen Typs aufnehmen können. Daher muss man sich beim Anlegen eines neuen Ordners im vSphere Web Client zwischen den 4 Typen Host und Cluster, Netzwerk, Speicher sowie VM und Vorlagen entscheiden.

Ordner kann man in der Gesamtstruktur an verschiedenen Positionen einhängen. Erstellt man sie direkt unterhalb eines vCenter Servers, dann dürfen sie nur Datacenter enthalten. Legt man dagegen einen Ordner unterhalb eines Datacenters an, dann hat man die Wahl zwischen den genannten 4 Typen.

Schließlich besteht auch noch die Möglichkeit, Ordner zu verschachteln. In diesem Fall gilt für den Elternordner wieder die Regel, dass er nur Objekte des gleichen Typs aufnehmen darf. Wenn er zum Beispiel VMs enthält, dann dürfen alle Sub-Folder ebenfalls nur VMs umfassen. Daher entfällt die Auswahl zwischen den 4 Ordnertypen, wenn der übergeordnete Container eines neuen Ordners ebenfalls ein Ordner ist.