vSphere-Anforderungen

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

Diese Seite richtet sich an Administratoren und Architekten, die IT-Lösungen und Systemarchitekturen gemäß der Unternehmensstrategie definieren und Richtlinien zu Nutzerberechtigungen erstellen und verwalten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.

Versionskompatibilität

Die vSphere-Anforderungen variieren je nach der verwendeten Version von Google Distributed Cloud. Weitere Informationen finden Sie in der Versionskompatibilitätsmatrix für vollständig unterstützte 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 von Version 7.0
  • 8.0 und höher von Updates der Version 8.0

Wir empfehlen die Verwendung von Version 8.0, Version 7.0 Update 3 oder einem höheren Update von Version 7.0.

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

  • 7.0 Update 3 oder ein späteres Update der Version 7.0
  • 8.0 oder ein späteres Update von Version 8.0

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:

Wenn Sie antiAffinityGroups.enabled auf true setzen, erstellt Google Distributed Cloud DRS-Anti-Affinitätsregeln für Ihre Clusterknoten, sodass sie auf mindestens drei physischen ESXi-Hosts verteilt werden. Auch wenn die DRS-Regeln vorschreiben, dass Clusterknoten auf drei ESXi-Hosts verteilt werden müssen, empfehlen wir dringend, mindestens vier ESXi-Hosts zur Verfügung zu haben. So wird verhindert, dass Sie die Steuerungsebene des 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 verbleibenden beiden 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
Sessions.Validate session
Cns.Searchable
Profilbasierter Speicher.Profilbasierte Speicheransicht 		vCenter-Server rooten Nein
ReadOnly System.Read
System.View
System.Anonymous 		Rechenzentrum
Netzwerk 		Ja
Anthos Berechtigungen in der Anthos-Rolle datastore
Ressourcenpool
VM-Ordner
Netzwerk 		Ja

Berechtigungen in der benutzerdefinierten Anthos-Rolle

Benutzerdefinierte Rollen und Berechtigungen erstellen

Ein Organisationsadministrator kann mit dem govc 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`

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