vSphere-Anforderungen

Google Distributed Cloud wird lokal in einer vSphere ausgeführt. In diesem Dokument werden die Anforderungen für Ihre vSphere-Umgebung beschrieben.

Versionskompatibilität

Die vSphere-Anforderungen variieren je nach verwendeter Version von Google Distributed Cloud. 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.

Google Distributed Cloud unterstützt diese Versionen von ESXi und vCenter Server

  • 7.0 Update 2 und höher, Updates von Version 7.0
  • Updates für Version 8.0 und höher

Wir empfehlen die Verwendung von Version 8.0 oder 7.0 Update 3 oder einer höheren Version der Version 7.0.

Wenn Sie CSI-Volume-Snapshots erstellen möchten, benötigen Sie eine der folgenden Versionen:

  • 7.0 Update 3 oder eine neuere Version der Version 7.0
  • Update auf Version 8.0 oder höher

Erforderliche Lizenzen

Sie benötigen eine der folgenden Lizenzen:

Hardwareanforderungen

Google Distributed Cloud 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 dringend Folgendes:

  • Aktivieren Sie VMware Distributed Resource Scheduler (DRS).

  • Halten Sie mindestens vier ESXi-Hosts für Ihre Cluster-VMs bereit.

  • Aktivieren Sie Network File Copy (NFC)-Traffic 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 setzen, erstellt Google Distributed Cloud DRS-Anti-Affinitätsregeln für Ihre Clusterknoten, wodurch diese auf mindestens drei physische ESXi-Hosts verteilt werden. Obwohl die DRS-Regeln erfordern, dass Clusterknoten auf drei ESXi-Hosts verteilt sind, empfehlen wir dringend, mindestens vier ESXi-Hosts verfügbar zu haben. Dadurch wird verhindert, dass Sie die Steuerungsebene Ihres Clusters verlieren. Angenommen, Sie haben nur drei ESXi-Hosts und der Knoten der Steuerungsebene Ihres Administratorclusters 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.

Zur Evaluierung und zum 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 Yes
SessionValidator System.Read
System.View
System.Anonym
Sitzungen.Sitzung validieren
Cns.Searchable
Profilgesteuerter Speicher.Profilgesteuerte Speicheransicht 		vCenter-Server rooten Nein
ReadOnly System.Read
System.View
System.Anonymous 		Rechenzentrum
Netzwerk 		Yes
Anthos Berechtigungen in der Anthos-Rolle datastore
Ressourcenpool
VM-Ordner
Netzwerk 		Yes

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 Sessions.ValidateSession 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`

Ersetzen Sie Folgendes:

  • 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

Ersetzen Sie Folgendes:

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