Requisiti di vSphere

Google Distributed Cloud viene eseguito on-premise in un ambiente vSphere. Questo documento descrive i requisiti per l'ambiente vSphere.

Questa pagina è destinata agli amministratori e agli architetti che definiscono soluzioni IT e architetture di sistema in linea con la strategia aziendale e che creano e gestiscono criteri relativi alle autorizzazioni utente. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Compatibilità delle versioni

I requisiti di vSphere variano a seconda della versione di Google Distributed Cloud in uso. Per ulteriori informazioni, consulta la matrice di compatibilità delle versioni per le versioni completamente supportate.

Versioni supportate

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

Google Distributed Cloud supporta queste versioni di ESXi e vCenter Server

  • Aggiornamento 2 di 7.0 e aggiornamenti successivi della versione 7.0
  • Aggiornamenti 8.0 e successivi della versione 8.0

Ti consigliamo di utilizzare la versione 8.0, 7.0 Update 3 o un aggiornamento successivo della versione 7.0.

Se vuoi creare snapshot dei volumi CSI, devi disporre di una delle seguenti versioni:

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

Requisiti relativi alle licenze

Devi disporre di una delle seguenti licenze:

Requisiti hardware

Google Distributed Cloud viene eseguito su un insieme di host fisici che eseguono l'hypervisor ESXi di VMware. Per informazioni sui requisiti hardware per ESXi, consulta la pagina Requisiti hardware di ESXi.

Per gli ambienti di produzione, ti consigliamo vivamente di:

  • Attiva VMware Distributed Resource Scheduler (DRS).

  • Avere almeno quattro host ESXi disponibili per le VM del cluster.

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

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

Se imposti antiAffinityGroups.enabled su true, Google Distributed Cloud crea regole anti-affinità DRS per i nodi del cluster, in modo da distribuirli in almeno tre host ESXi fisici. Anche se le regole DRS richiedono che i nodi del cluster siano distribuiti su tre host ESXi, ti consigliamo vivamente di avere a disposizione almeno quattro host ESXi. In questo modo, eviterai di perdere il control plane del cluster. Ad esempio, supponi di avere solo tre host ESXi e che il nodo del control plane del cluster di amministrazione si trovi su un host ESXi che non funziona. La regola DRS impedirà il posizionamento del nodo del control plane su uno dei due host ESXi rimanenti.

Per la valutazione e la prova di concetto, puoi impostare antiAffinityGroups.enabled su false e utilizzare un solo host ESXi. Per saperne di più, vedi Configurare l'infrastruttura minima.

Privilegi dell'account utente vCenter

Per configurare un ambiente vSphere, un amministratore dell'organizzazione potrebbe scegliere di utilizzare un account utente vCenter con il ruolo Amministratore vCenter Server. Questo ruolo fornisce l'accesso completo a tutti gli oggetti vSphere.

Una volta configurato l'ambiente vSphere, un amministratore del cluster può creare cluster di amministrazione e cluster utente. L'amministratore del cluster non ha bisogno di tutti i privilegi forniti dal ruolo di amministratore di vCenter Server.

Quando un amministratore o uno sviluppatore di cluster crea un cluster, fornisce un account utente vCenter in un file di configurazione delle credenziali. Ti consigliamo di assegnare all'account utente vCenter elencato in un file di configurazione delle credenziali uno o più ruoli personalizzati con i privilegi minimi richiesti per la creazione e la gestione dei cluster.

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

  • Crea diversi ruoli con vari livelli di privilegio. Quindi crea autorizzazioni che assegnano questi ruoli limitati a un utente o a un gruppo su singoli oggetti vSphere.

  • Crea un ruolo con tutti i privilegi necessari. Poi crea un'autorizzazione globale che assegna questo ruolo a un utente o a un gruppo specifico su tutti gli oggetti nelle gerarchie vSphere.

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

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

La seguente tabella mostra quattro ruoli personalizzati che un amministratore dell'organizzazione può 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.Modify cluster
cluster
SessionValidator System.Read
System.View
System.Anonymous
Sessions.Validate session
Cns.Searchable
Profile-driven storage.Profile-driven storage view
vCenter Server principale No
ReadOnly System.Read
System.View
System.Anonymous
data center
network
Anthos Privilegi nel ruolo Anthos datastore
resource pool
cartella VM
rete

Privilegi nel ruolo personalizzato Anthos

Creare ruoli e autorizzazioni personalizzati

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

L'amministratore dell'organizzazione deve disporre di un account vCenter Server con privilegi sufficienti per creare ruoli e autorizzazioni. Ad esempio, un account con il ruolo Amministratore sarebbe 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 dell'account vCenter Server dell'amministratore dell'organizzazione.

  • Imposta GOVC_PASSWORD sulla password dell'account vCenter Server dell'amministratore dell'organizzazione.

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 accetta una coppia (utente, ruolo) e la associa a un oggetto. Quando assegni un'autorizzazione a un oggetto, puoi specificare se l'autorizzazione si propaga agli oggetti secondari. Con govc, puoi farlo impostando il flag --propagate su true o false. Il valore predefinito è false.

Crea un'autorizzazione che conceda il ruolo ClusterEditor a un utente su un oggetto cluster. Questa autorizzazione viene propagata 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 il ruolo

  • CLUSTER_PATH: il percorso del cluster nella gerarchia degli oggetti vSphere

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 secondari di my-dc/host/my-cluster:

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

Creare autorizzazioni aggiuntive

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

Crea un'autorizzazione che conceda il ruolo SessionValidator a un account nell'oggetto vCenter Server radice. Questa autorizzazione non viene propagata agli oggetti secondari:

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

Crea autorizzazioni che concedano il ruolo ReadOnly a un account su un oggetto data center e un oggetto di rete. Queste autorizzazioni vengono propagate agli oggetti secondari:

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 VM, un pool di risorse e una rete. Queste autorizzazioni vengono propagate 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 più ruoli e più autorizzazioni. Non consigliamo questo approccio perché concede un ampio insieme di privilegi su tutti gli oggetti nelle gerarchie vSphere.

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

Crea un'autorizzazione globale:

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

Sostituisci quanto segue:

Sostituisci ACCOUNT con l'account utente vCenter Server a cui viene concesso il ruolo

Ad esempio, il seguente comando crea un'autorizzazione globale che concede il ruolo Anthos a bob@vsphere.local. L'autorizzazione viene propagata a tutti gli oggetti nelle gerarchie vSphere:

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

Problemi noti

Consulta L'installazione non riesce durante la creazione del disco dati vSphere.

Passaggi successivi

Requisiti di archiviazione, CPU e RAM