vSphere-Anforderungen

Anthos-Cluster auf VMware (GKE On-Prem) werden lokal in einer vSphere-Umgebung ausgeführt. In diesem Dokument werden die Anforderungen für Ihre vSphere-Umgebung beschrieben.

Versionskompatibilität

Die vSphere-Anforderungen variieren je nach der Version von Anthos-Cluster auf VMware, die Sie verwenden. Weitere Informationen finden Sie in der Versionskompatibilitätsmatrix für vollständig unterstützte Versionen und frühere Versionen.

Unterstützte Versionen

vSphere ist die Servervirtualisierungssoftware von VMware. vSphere umfasst ESXi und vCenter Server.

Anthos-Cluster auf VMware unterstützt diese Versionen von ESXi und vCenter Server:

  • 7.0 Update 1 und höher von Version 7.0

Wenn Sie den CSI-Treiber (vSphere Container Storage) oder NFSv3 verwenden möchten, müssen Sie Version 7.0 oder höher und Version 7.0 aktualisieren.

Wenn Sie CSI-Volume-Snapshots erstellen möchten, müssen Sie Version 7.0 oder höher und Version 7.0 aktualisieren.

Erforderliche Lizenzen

Sie benötigen eine der folgenden Lizenzen:

Hardwareanforderungen

Anthos Clusters on VMware wird auf einer Reihe von physischen Hosts ausgeführt, auf denen der ESXi-Hypervisor von VMware ausgeführt wird. Informationen zu den Hardwareanforderungen für ESXi finden Sie unter ESXi-Hardwareanforderungen.

Für Produktionsumgebungen empfehlen wir Folgendes:

  • Aktivieren Sie VMware Distributed Resource Scheduler (DRS).

  • Es müssen mindestens vier ESXi-Hosts für Ihre Cluster-VMs verfügbar sein.

  • Aktivieren Sie Traffic aus Network File Copy (NFC) zwischen ESXi-Hosts, um die Freigabe von Betriebssystemvorlagen zu ermöglichen, wenn Sie Anthos-Cluster auf VMware in verschiedenen vSphere-Clustern oder Ressourcenpools im selben vSphere-Rechenzentrum bereitstellen möchten.

  • Legen Sie antiAffinityGroups.enabled in den Clusterkonfigurationsdateien auf true fest.

Wenn Sie antiAffinityGroups.enabled auf true festlegen, erstellt Anthos-Cluster auf VMware DRS-Anti-Affinitätsregeln für Ihre Clusterknoten, wodurch sie auf mindestens drei physische ESXi-Hosts verteilt werden. Auch wenn die DRS-Regeln voraussetzen müssen, dass Clusterknoten auf drei ESXi-Hosts verteilt sind, empfehlen wir dringend, dass Sie mindestens vier ESXi-Hosts verfügbar haben. Dadurch wird verhindert, dass Sie die Steuerungsebene des Clusters verlieren. Angenommen, Sie haben nur drei ESXi-Hosts und der Knoten Ihrer Steuerungsebene für den Administratorcluster befindet sich auf einem ESXi-Host, der ausfällt. Die DRS-Regel verhindert, dass der Knoten der Steuerungsebene auf einem der beiden verbleibenden ESXi-Hosts platziert wird.

Für die Bewertung und den Proof of Concept können Sie antiAffinityGroups.enabled auf false festlegen und nur einen ESXi-Host verwenden. Weitere Informationen finden Sie unter Minimale Infrastruktur einrichten.

vCenter-Nutzerkontoberechtigungen

Zum Einrichten einer vSphere-Umgebung kann ein Organisationsadministrator ein vCenter-Nutzerkonto mit der Rolle „vCenter Server-Administrator” verwenden. Diese Rolle bietet vollständigen Zugriff auf alle vSphere-Objekte.

Nachdem die vSphere-Umgebung eingerichtet wurde, kann ein Clusteradministrator Administratorcluster und Nutzercluster erstellen. Der Clusteradministrator benötigt nicht alle in der Rolle „vCenter Server-Administrator” bereitgestellten Berechtigungen.

Wenn ein Clusteradministrator oder Entwickler einen Cluster erstellt, stellt er in einer Konfigurationsdatei für Anmeldedaten ein vCenter-Nutzerkonto bereit. Wir empfehlen, dem in einer Konfigurationsdatei für Anmeldedaten aufgeführten vCenter-Nutzerkonto mindestens ein oder mehrere benutzerdefinierte Rollen zuzuweisen, die die für die Cluster-Erstellung und -Verwaltung erforderlichen Mindestberechtigungen haben.

Ein Organisationsadministrator kann zwei verschiedene Ansätze verfolgen:

  • Sie können mehrere Rollen mit unterschiedlichen Berechtigungen erstellen. Erstellen Sie dann Berechtigungen, die einem Nutzer oder einer Gruppe einzelner vSphere-Objekte die eingeschränkten Rollen zuweisen.

  • Erstellen Sie eine Rolle mit allen erforderlichen Berechtigungen. Erstellen Sie dann eine globale Berechtigung, die diese Rolle einem bestimmten Nutzer oder einer Gruppe auf allen Objekten in Ihren vSphere-Hierarchien zuweist.

Wir empfehlen den ersten Ansatz, da er den Zugriff begrenzt und die Sicherheit Ihrer vCenter Server-Umgebung erhöht. Weitere Informationen finden Sie unter Rollen zum Zuweisen von Berechtigungen verwenden und Best Practices für Rollen und Berechtigungen.

Informationen zur Verwendung des zweiten Ansatzes finden Sie unter Globale Berechtigung erstellen.

Die folgende Tabelle zeigt vier benutzerdefinierte Rollen, die ein Organisationsadministrator erstellen kann. Der Administrator kann dann die benutzerdefinierten Rollen verwenden, um Berechtigungen für bestimmte vSphere-Objekte zuzuweisen:

Benutzerdefinierte RolleBerechtigungenObjekteAn
untergeordnete Objekte weitergeben?
ClusterEditor System.Read
System.View
System.Anonymous
Host.Inventory.Modify cluster 		Cluster Ja
SessionValidator System.Read
System.View
System.Anonymous
Sitzungen.Sitzung überprüfen
Cns.Searchable
Profilgesteuerter Speicher.Profilgesteuerte Speicheransicht 		vCenter-Server rooten Nein
ReadOnly System.Read
System.View
System.Anonymous 		Rechenzentrum
Netzwerk 		Ja
Anthos Berechtigungen in der Anthos-Rolle Datenspeicher
Ressourcenpool
VM-Ordner
Netzwerk 		Ja

Berechtigungen in der benutzerdefinierten Anthos-Rolle

Benutzerdefinierte Rollen und Berechtigungen erstellen

Ein Organisationsadministrator kann mit dem govc-Befehlszeilentool benutzerdefinierte Rollen und Berechtigungen erstellen.

Der Administrator der Organisation muss ein vCenter Server-Konto haben, das über ausreichende Berechtigungen zum Erstellen von Rollen und Berechtigungen verfügt. Ein Konto mit der Rolle „Administrator” wäre beispielsweise angemessen.

Legen Sie vor dem Ausführen von govc einige Umgebungsvariablen fest:

  • Legen Sie die GOVC_URL auf die URL Ihrer vCenter-Server-Instanz fest.

  • Legen Sie den GOVC_USERNAME auf den Nutzernamen des vCenter Server-Kontos des Organisationsadministrators fest.

  • Legen Sie das GOVC_PASSWORD auf das Passwort des vCenter Server-Kontos des Organisationsadministrators fest.

Beispiel:

export GOVC_URL=vc-01.example
export GOVC_USERNAME=alice@vsphere.local
export GOVC_PASSWORD=8ODQYHo2Yl@

Benutzerdefinierte Rollen erstellen

Erstellen Sie die benutzerdefinierten Rollen „ClusterEditor”, „SessionValidator” und „ReadOnly”:

govc role.create ClusterEditor System.Read System.View System.Anonymous Host.Inventory.EditCluster
govc role.create SessionValidator System.Read System.View System.Anonymous Session.ValidateSessions Cns.Searchable StorageProfile.View
govc role.create ReadOnly System.Read System.View System.Anonymous

Berechtigung erstellen, die die Rolle „Clusterbearbeiter” gewährt

Bei Berechtigungen wird ein Objekt (Nutzer, Rolle) mit einem Objekt verknüpft. Wenn Sie eine Berechtigung für ein Objekt zuweisen, können Sie angeben, ob die Berechtigung an untergeordnete Objekte weitergegeben wird. Bei govc setzen Sie das Flag --propagate entweder auf true oder false. Der Standardwert ist false.

Erstellen Sie eine Berechtigung, mit der einem Nutzer für ein Clusterobjekt die Rolle „Clusterbearbeiter” zugewiesen wird. Diese Berechtigung wird an alle untergeordneten Objekte des Clusterobjekts weitergegeben:

govc permissions.set -principal ACCOUNT \
 -role ClusterEditor -propagate=true CLUSTER_PATH`

Dabei gilt:

  • ACCOUNT: Das vCenter Server-Nutzerkonto, dem die Rolle zugewiesen wird

  • CLUSTER_PATH: Pfad des Clusters in der vSphere-Objekthierarchie

Der folgende Befehl erstellt beispielsweise eine Berechtigung, die das Paar (bob@vsphere.local, ClusterEditor mit my-dc/host/my-cluster) verknüpft. Die Berechtigung wird an alle untergeordneten Objekte von „my-dc/host/my-cluster” weitergegeben:

govc permissions.set -principal bob@vsphere.local \
    -role ClusterEditor -propagate=true my-dc/host/my-cluster

Zusätzliche Berechtigungen erstellen

Dieser Abschnitt enthält Beispiele zum Erstellen zusätzlicher Berechtigungen. Ersetzen Sie die Beispielobjektpfade nach Ihrer Umgebung.

Erstellen Sie eine Berechtigung, die einem Konto im Root-vCenter-Serverobjekt die Rolle „SessionValidator” zuweist. Diese Berechtigung wird nicht für untergeordnete Objekte weitergegeben:

govc permissions.set -principal ACCOUNT \
    -role SessionValidator -propagate=false

Erstellen Sie Berechtigungen, die einem Konto für ein Rechenzentrumsobjekt und ein Netzwerkobjekt die Rolle „ReadOnly” zuweisen. Diese Berechtigungen werden an untergeordnete Objekte weitergegeben:

govc permissions.set -principal ACCOUNT \
    -role ReadOnly -propagate=true \
    /my-dc \
    /my-dc/network/my-net

Erstellen Sie Berechtigungen, die einem Konto die Rolle Anthos für vier Objekte zuweisen: einen Datenspeicher, einen VM-Ordner, einen Ressourcenpool und ein Netzwerk. Diese Berechtigungen werden an untergeordnete Objekte weitergegeben:

govc permissions.set -principal ACCOUNT -role Anthos -propagate=true \
    /my-dc/datastore/my-ds  \
    /my-dc/vm/my-folder \
    /my-dc/host/my-cluster/Resources/my-rp \
    /my-dc/network/my-net

Globale Berechtigung erstellen

Dieser Abschnitt bietet eine Alternative zum Erstellen mehrerer Rollen und Berechtigungen. Wir empfehlen diesen Ansatz nicht, da er eine große Anzahl von Berechtigungen für alle Objekte in Ihren vSphere-Hierarchien gewährt.

Wenn Sie die benutzerdefinierte Anthos-Rolle noch nicht erstellt haben, erstellen Sie sie jetzt.

Erstellen Sie eine globale Berechtigung:

govc permissions.set -principal ACCOUNT \
 -role Anthos -propagate=true

Dabei gilt:

Ersetzen Sie ACCOUNT durch das vCenter Server-Nutzerkonto, dem die Rolle zugewiesen wird.

Mit dem folgenden Befehl wird beispielsweise eine globale Berechtigung erstellt, die bob@vsphere.local die Anthos-Rolle zuweist. Diese Berechtigung gilt dann für alle Objekte in Ihren vSphere-Hierarchien:

govc permissions.set -principal bob@vsphere.local -role Anthos -propagate=true

Bekannte Probleme

Siehe Installationsprogramm schlägt beim Erstellen eines vSphere-Datenlaufwerks fehl.

Nächste Schritte

CPU-, RAM- und Speicherbedarf