Requisiti di vSphere

Google Distributed Cloud viene eseguito on-premise in vSphere completamente gestito di Google Cloud. Questo documento descrive i requisiti per il tuo ambiente vSphere.

Compatibilità delle versioni

I requisiti di vSphere variano a seconda della versione di Google Distributed Cloud che stai utilizzando. Per ulteriori informazioni, consulta la versione di compatibilità versioni completamente supportate e versioni precedenti.

Versioni supportate

vSphere è il software di virtualizzazione del server di VMware. vSphere include ESXi e Server vCenter.

Google Distributed Cloud supporta queste versioni ESXi e Server vCenter

  • 7.0 Update 2 e successivi aggiornamenti della versione 7.0
  • 8.0 e aggiornamenti successivi della versione 8.0

Consigliamo di utilizzare 8.0 o 7.0 Update 3 o un aggiornamento successivo della versione 7.0.

Se vuoi creare snapshot di volumi CSI, devi avere uno dei le seguenti versioni:

  • 7.0 Update 3 o un aggiornamento successivo della versione 7.0
  • 8.0 o un aggiornamento successivo della versione 8.0

Requisiti relativi alle licenze

È necessaria una delle seguenti licenze:

Requisiti hardware

Google Distributed Cloud viene eseguito su un insieme di host fisici che eseguono VMware Hypervisor ESXi. Per informazioni sui requisiti hardware per ESXi, vedi Requisiti hardware ESXi.

Per gli ambienti di produzione, consigliamo vivamente quanto segue:

  • Attiva VMware Distributed Resource Scheduler (DRS).

  • Fai in modo che siano disponibili almeno quattro host ESXi per le VM del tuo cluster.

  • Se prevedi di eseguire il deployment di Cluster Anthos su VMware su diversi cluster o pool di risorse vSphere all'interno dello stesso data center vSphere, attiva il traffico Network File Copy (NFC) tra gli host ESXi per consentire la condivisione dei modelli di sistema operativo.

  • Imposta antiAffinityGroups.enabled su true nei file di configurazione del cluster.

Se imposti antiAffinityGroups.enabled su true, Google Distributed Cloud crea regole di anti-affinità DRS per i nodi del cluster, distribuiti su almeno tre host ESXi fisici. Anche se le regole DRS che i nodi dei cluster siano distribuiti su tre host ESXi, ti consigliamo di avere almeno quattro host ESXi. Questo ti protegge di perdere il piano di controllo del cluster. Ad esempio, supponiamo che tu abbia tre host ESXi e il cluster di amministrazione il nodo del piano di controllo si trova su un host ESXi in cui si verifica un errore. La regola DRS impedirà di essere posizionato su uno dei restanti due host ESXi.

Per la valutazione e il proof of concept, puoi impostare antiAffinityGroups.enabled su false e utilizzare un solo host ESXi. Per ulteriori informazioni, vedi Configura l'infrastruttura minima.

Privilegi per l'account utente vCenter

Per configurare un ambiente vSphere, un amministratore dell'organizzazione potrebbe decidere di utilizza un account utente vCenter con Ruolo Amministratore server vCenter. Questo ruolo fornisce l'accesso completo a tutti gli oggetti vSphere.

Dopo aver configurato l'ambiente vSphere, un amministratore del cluster può creare cluster di amministrazione e cluster utente. L'amministratore del cluster non ha bisogno di i privilegi forniti dal ruolo Amministratore server vCenter.

Quando un amministratore o uno sviluppatore crea un cluster, fornisce una account utente vCenter in un file di configurazione credenziali. Consigliamo di usare l'account utente vCenter elencato nelle credenziali al file di configurazione vengono assegnati uno o più ruoli personalizzati che hanno il minimo privilegi necessaria per la creazione e la gestione del cluster.

Un amministratore dell'organizzazione può adottare due approcci diversi:

  • Creare diversi ruoli con diversi gradi di privilegio. Poi crea autorizzazioni che assegnano questi ruoli limitati a un utente o un gruppo singoli oggetti vSphere.

  • Crea un ruolo con tutti i privilegi necessari. Quindi crea un autorizzazione globale che assegna quel ruolo a un particolare utente o gruppo su tutte degli oggetti nelle tue gerarchie vSphere.

Consigliamo il primo approccio, perché limita l'accesso e aumenta la sicurezza dell'ambiente vCenter Server. Per ulteriori informazioni, vedi Utilizzare i ruoli per assegnare privilegi e Best practice per ruoli e autorizzazioni

Per informazioni sull'utilizzo del secondo approccio, consulta Crea un'autorizzazione globale.

La tabella seguente mostra quattro ruoli personalizzati che un amministratore dell'organizzazione possono creare. L'amministratore può quindi utilizzare i ruoli personalizzati per assegnare autorizzazioni su oggetti vSphere specifici:

Ruolo personalizzatoPrivilegiOggettiPropagare agli
oggetti secondari?
ClusterEditor System.Read
System.View
System.Anonymous
Host.Inventory.Modifica cluster 		cluster Sì
SessionValidator System.Read
System.View
System.Anonymous
Sessioni.Convalida sessione
Cns.Ricercabile
Archiviazione basata sul profilo.Visualizzazione archiviazione basata sul profilo 		Server vCenter radice No
ReadOnly System.Read
System.View
System.Anonymous 		data center
rete 		Sì
Anthos Privilegi nel ruolo Anthos datastore
pool di risorse
Cartella VM
rete 		Sì

Privilegi nel ruolo personalizzato Anthos

Crea ruoli e autorizzazioni personalizzati

Un amministratore dell'organizzazione può utilizzare govc a strumento a riga di comando per creare ruoli e autorizzazioni personalizzati.

L'amministratore dell'organizzazione deve disporre di un account vCenter Server che abbia sufficiente privilegi per la creazione di ruoli e autorizzazioni. Ad esempio, un account con Ruolo di amministratore appropriato.

Prima di eseguire govc, imposta alcune variabili di ambiente:

  • Imposta GOVC_URL sull'URL della tua istanza di vCenter Server.

  • Imposta GOVC_USERNAME sul nome utente del vCenter dell'amministratore dell'organizzazione Account server.

  • Imposta GOVC_PASSWORD sulla password del vCenter dell'amministratore dell'organizzazione Account server.

Ad esempio:

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

Creazione di ruoli personalizzati

Crea i ruoli personalizzati ClusterEditor, SessionValidator e 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

Crea un'autorizzazione che conceda il ruolo ClusterEditor

Un'autorizzazione prende una coppia (utente, ruolo) e la associa a un oggetto. Quando assegni un'autorizzazione su un oggetto, puoi specificare se l'autorizzazione si propaga agli oggetti figlio. Con govc, puoi farlo impostando il valore --propagate a true o false. Il valore predefinito è false.

Crea un'autorizzazione che conceda il ruolo ClusterEditor a un utente su un cluster . Questa autorizzazione si propaga a tutti gli oggetti secondari dell'oggetto cluster:

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

Sostituisci quanto segue:

  • ACCOUNT: l'account utente vCenter Server a cui viene concesso ruolo

  • CLUSTER_PATH: il percorso del cluster nell'oggetto vSphere gerarchia

Ad esempio, il seguente comando crea un'autorizzazione che associa la coppia (bob@vSphere.local, ClusterEditor con my-dc/host/my-cluster. L'autorizzazione si propaga a tutti gli oggetti figlio di my-dc/host/my-cluster:

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

Crea autorizzazioni aggiuntive

Questa sezione fornisce esempi della creazione di autorizzazioni aggiuntive. Sostituisci di percorsi degli oggetti di esempio in base alle esigenze del tuo ambiente.

Crea un'autorizzazione che conceda il ruolo SessionValidator a un account sull'oggetto vCenter Server principale. Questa autorizzazione non si propaga agli oggetti secondari:

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

Creare autorizzazioni che concedono il ruolo di sola lettura a un account su un un oggetto data center e un oggetto di rete. Queste autorizzazioni si propagano all'account secondario oggetti:

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

Crea autorizzazioni che concedono il ruolo Anthos a un account su quattro oggetti: un datastore, una cartella di VM, un pool di risorse e una rete. Questi le autorizzazioni si propagano agli oggetti secondari:

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

Crea un'autorizzazione globale

Questa sezione offre un'alternativa alla creazione di vari ruoli e autorizzazioni aggiuntive. Sconsigliamo di utilizzare questo approccio perché garantisce un gran numero di privilegiati su tutti gli oggetti nelle gerarchie vSphere.

Se non hai ancora creato il ruolo personalizzato Anthos, crealo subito.

Crea un'autorizzazione globale:

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

Sostituisci quanto segue:

Sostituisci ACCOUNT con l'account utente vCenter Server attualmente in corso ha concesso il ruolo

Ad esempio, il comando seguente crea un'autorizzazione globale che concede il token Ruolo Anthos a bob@vSphere.local. L'autorizzazione si propaga a tutti gli oggetti in le tue gerarchie vSphere:

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

Problemi noti

Consulta Il programma di installazione non va a buon fine durante la creazione del disco dati vSphere.

Passaggi successivi

Requisiti di CPU, RAM e spazio di archiviazione