Requisitos do vSphere

O Google Distributed Cloud é executado nas suas instalações num ambiente vSphere. Este documento descreve os requisitos para o seu ambiente vSphere.

Esta página destina-se a administradores e arquitetos que definem soluções de TI e a arquitetura do sistema de acordo com a estratégia da empresa, e criam e gerem políticas relacionadas com autorizações dos utilizadores. Para saber mais sobre as funções comuns e as tarefas de exemplo a que fazemos referência no Google Cloud conteúdo, consulte Funções e tarefas comuns de utilizadores do GKE.

Compatibilidade de versões

Os requisitos do vSphere variam consoante a versão do Google Distributed Cloud que está a usar. Para mais informações, consulte a matriz de compatibilidade de versões para versões totalmente suportadas.

Versões suportadas

vSphere é o software de virtualização de servidores da VMware. O vSphere inclui o ESXi e o vCenter Server.

O Google Distributed Cloud suporta estas versões do ESXi e do vCenter Server

  • 7.0 Update 2 e atualizações posteriores da versão 7.0
  • Atualizações 8.0 e posteriores da versão 8.0

Recomendamos que use a versão 8.0, a versão 7.0 com a atualização 3 ou uma atualização posterior da versão 7.0.

Se quiser criar instantâneos de volumes de CSI, tem de ter uma das seguintes versões:

  • 7.0 Update 3 ou uma atualização posterior da versão 7.0
  • 8.0 ou uma atualização posterior da versão 8.0

Requisitos de licença

Precisa de uma das seguintes licenças:

  • Licença vSphere Enterprise Plus. Juntamente com esta licença, tem de ter uma subscrição de apoio técnico válida.

  • Licença vSphere Standard. Juntamente com esta licença, tem de ter uma subscrição de apoio técnico válida. Com esta licença, não pode ativar os grupos de anti-afinidade. Além disso, não pode especificar o seu próprio conjunto de recursos. Tem de usar o conjunto de recursos predefinido.

Requisitos de hardware

O Google Distributed Cloud é executado num conjunto de anfitriões físicos que executam o hipervisor ESXi da VMware. Para saber mais sobre os requisitos de hardware do ESXi, consulte o artigo Requisitos de hardware do ESXi.

Para ambientes de produção, recomendamos vivamente o seguinte:

Se definir antiAffinityGroups.enabled como true, o Google Distributed Cloud cria regras de antiafinidade do DRS para os nós do cluster, o que faz com que sejam distribuídos por, pelo menos, três anfitriões ESXi físicos. Embora as regras do DRS exijam que os nós do cluster estejam distribuídos por três anfitriões ESXi, recomendamos vivamente que tenha, pelo menos, quatro anfitriões ESXi disponíveis. Isto protege-o contra a perda do plano de controlo do cluster. Por exemplo, suponha que tem apenas três anfitriões ESXi e que o nó do plano de controlo do cluster de administrador está num anfitrião ESXi com falhas. A regra DRS impede que o nó do plano de controlo seja colocado num dos dois anfitriões ESXi restantes.

Para avaliação e prova de conceito, pode definir antiAffinityGroups.enabled como false e usar apenas um anfitrião ESXi. Para mais informações, consulte o artigo Configure uma infraestrutura mínima.

Privilégios da conta de utilizador do vCenter

Para configurar um ambiente vSphere, um administrador da organização pode optar por usar uma conta de utilizador do vCenter que tenha a função de administrador do vCenter Server. Esta função oferece acesso total a todos os objetos do vSphere.

Depois de configurar o ambiente do vSphere, um administrador do cluster pode criar clusters de administrador e clusters de utilizadores. O administrador do cluster não precisa de todos os privilégios fornecidos pela função de administrador do vCenter Server.

Quando um administrador ou um programador de clusters cria um cluster, fornece uma conta de utilizador do vCenter num ficheiro de configuração de credenciais. Recomendamos que a conta de utilizador do vCenter que consta de um ficheiro de configuração de credenciais lhe seja atribuída uma ou mais funções personalizadas que tenham os privilégios mínimos necessários para a criação e a gestão de clusters.

Existem duas abordagens diferentes que um administrador da organização pode adotar:

  • Crie várias funções com diferentes graus de privilégio. Em seguida, crie autorizações que atribuam essas funções limitadas a um utilizador ou um grupo em objetos individuais do vSphere.

  • Crie uma função com todos os privilégios necessários. Em seguida, crie uma autorização global que atribui essa função a um utilizador ou grupo específico em todos os objetos nas suas hierarquias do vSphere.

Recomendamos a primeira abordagem, porque limita o acesso e aumenta a segurança do seu ambiente do vCenter Server. Para mais informações, consulte os artigos Usar funções para atribuir privilégios e Práticas recomendadas para funções e autorizações

Para ver informações sobre como usar a segunda abordagem, consulte o artigo Crie uma autorização global.

A tabela seguinte mostra quatro funções personalizadas que um administrador da organização pode criar. O administrador pode, em seguida, usar as funções personalizadas para atribuir autorizações a objetos vSphere específicos:

Função personalizadaPrivilégiosObjetosPropagar para
objetos secundários?
ClusterEditor System.Read
System.View
System.Anonymous
Host.Inventory.Modify cluster 		cluster Sim
SessionValidator System.Read
System.View
System.Anonymous
Sessions.Validate session
Cns.Searchable
Profile-driven storage.Profile-driven storage view 		Servidor vCenter raiz Não
ReadOnly System.Read
System.View
System.Anonymous 		centro de dados
rede 		Sim
Anthos Privilégios na função do Anthos datastore
resource pool
VM folder
network 		Sim

Privilégios na função personalizada do Anthos

Crie funções e autorizações personalizadas

Um administrador da organização pode usar a ferramenta de linha de comandos govc para criar funções e autorizações personalizadas.

O administrador da organização tem de ter uma conta do vCenter Server com privilégios suficientes para criar funções e autorizações. Por exemplo, uma conta com a função de administrador seria adequada.

Antes de executar govc, defina algumas variáveis de ambiente:

  • Defina GOVC_URL como o URL da sua instância do vCenter Server.

  • Defina GOVC_USERNAME como o nome de utilizador da conta do vCenter Server do administrador da organização.

  • Defina GOVC_PASSWORD como a palavra-passe da conta do vCenter Server do administrador da organização.

Por exemplo:

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

Criar funções personalizadas

Crie as funções personalizadas 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

Crie uma autorização que conceda a função ClusterEditor

Uma autorização usa um par (utilizador, função) e associa-o a um objeto. Quando atribui uma autorização a um objeto, pode especificar se a autorização é propagada a objetos subordinados. Com govc, pode fazê-lo definindo a flag --propagate como true ou false. A predefinição é false.

Crie uma autorização que conceda a função ClusterEditor a um utilizador num objeto de cluster. Esta autorização propaga-se a todos os objetos secundários do objeto de cluster:

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

Substitua o seguinte:

  • ACCOUNT: a conta de utilizador do servidor vCenter à qual está a ser concedida a função

  • CLUSTER_PATH: o caminho do cluster na hierarquia de objetos do vSphere

Por exemplo, o seguinte comando cria uma autorização que associa o par (bob@vsphere.local, ClusterEditor) a my-dc/host/my-cluster. A autorização é propagada a todos os objetos subordinados de my-dc/host/my-cluster:

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

Crie autorizações adicionais

Esta secção apresenta exemplos de criação de autorizações adicionais. Substitua os caminhos dos objetos de exemplo conforme necessário para o seu ambiente.

Crie uma autorização que conceda a função SessionValidator a uma conta no objeto do servidor vCenter raiz. Esta autorização não é propagada a objetos secundários:

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

Crie autorizações que concedam a função ReadOnly a uma conta num objeto de centro de dados e num objeto de rede. Estas autorizações propagam-se aos objetos secundários:

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

Crie autorizações que concedam a função do Anthos a uma conta em quatro objetos: um arquivo de dados, uma pasta de VMs, um conjunto de recursos e uma rede. Estas autorizações propagam-se aos objetos secundários:

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

Crie uma autorização global

Esta secção apresenta uma alternativa à criação de várias funções e várias autorizações. Não recomendamos esta abordagem porque concede um grande conjunto de privilégios em todos os objetos nas suas hierarquias do vSphere.

Se ainda não criou a função personalizada do Anthos, crie-a agora.

Crie uma autorização global:

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

Substitua o seguinte:

Substitua ACCOUNT pela conta de utilizador do vCenter Server à qual está a ser concedida a função

Por exemplo, o comando seguinte cria uma autorização global que concede a função do Anthos a bob@vsphere.local. A autorização propaga-se a todos os objetos nas hierarquias do vSphere:

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

Problemas conhecidos

Consulte o artigo O instalador falha ao criar o disco de dados do vSphere.

O que se segue?

Requisitos de CPU, RAM e armazenamento