Requisitos do vSphere

O Google Distributed Cloud é executado no local em um ambiente vSphere. Neste documento, descrevemos os requisitos do seu ambiente do vSphere.

Esta página é destinada a administradores e arquitetos que definem soluções de TI e arquitetura de sistemas de acordo com estratégias corporativas e criam e gerenciam políticas relacionadas a permissões dos usuários. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud, consulte Tarefas e papéis de usuário comuns do GKE Enterprise.

Compatibilidade de versões

Os requisitos do vSphere variam de acordo com a versão do Google Distributed Cloud que você está usando. Para mais informações, consulte a matriz de compatibilidade de versões para versões totalmente compatíveis.

Versões compatíveis

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

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

  • 7.0 Atualização 2 e atualizações mais recentes da versão 7.0
  • 8.0 e atualizações mais recentes da versão 8.0

Recomendamos usar a versão 8.0 ou 7.0 (atualização 3) ou uma atualização mais recente da versão 7.0.

Se você quiser criar instantâneos de volume CSI, será necessário ter uma das seguintes versões:

  • 7.0 Atualização 3 ou uma atualização mais recente da versão 7.0
  • 8.0 ou uma atualização mais recente da versão 8.0

Requisitos de licença

Você precisa ter uma destas licenças:

Requisitos de hardware

O Google Distributed Cloud é executado em um conjunto de hosts físicos que executam o hipervisor ESXi da VMware. Para saber mais sobre os requisitos de hardware do ESXi, acesse Requisitos de hardware do ESXi.

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

Se você definir antiAffinityGroups.enabled como true, o Google Distributed Cloud vai criar regras de antiafinidade do DRS para os nós do cluster, fazendo com que eles sejam propagados por pelo menos três hosts ESXi físicos. Mesmo que as regras do DRS exijam que os nós de cluster sejam propagados por três hosts ESXi, recomendamos que pelo menos quatro hosts ESXi estejam disponíveis. Isso protege o plano de controle do cluster contra perda. Por exemplo, suponha que haja apenas três hosts ESXi e que o nó do plano de controle do cluster de administrador esteja em um host ESXi que falha. A regra do DRS vai impedir que o nó do plano de controle seja colocado em um dos dois hosts ESXi restantes.

Para avaliação e prova de conceito, é possível definir antiAffinityGroups.enabled como false e usar apenas um host ESXi. Para mais informações, consulte Configurar infraestrutura mínima.

Privilégios da conta de usuário do vCenter

Para configurar um ambiente do vSphere, um administrador da organização pode optar por usar uma conta de usuário do vCenter que tenha o papel de administrador do vCenter Server. Este papel fornece acesso total a todos os objetos do vSphere.

Após a configuração do ambiente do vSphere, um administrador de cluster pode criar clusters de administrador e de usuário. O administrador do cluster não precisa de todos os privilégios fornecidos pelo papel de Administrador do vCenter Server.

Quando um administrador ou desenvolvedor de cluster cria um cluster, ele fornece uma conta de usuário do vCenter em um arquivo de configuração de credenciais. Recomendamos que a conta de usuário do vCenter listada em um arquivo de configuração de credenciais seja atribuída a um ou mais papéis personalizados que tenham os privilégios mínimos exigidos para a criação e o gerenciamento de clusters.

O administrador da organização pode seguir duas abordagens diferentes:

  • Criar vários papéis com diferentes graus de privilégio. Em seguida, criar permissões que atribuam esses papéis limitados a um usuário ou grupo em objetos individuais do vSphere.

  • Criar um papel que tenha todos os privilégios necessários. Em seguida, criar uma permissão global que atribua esse papel a um usuário ou grupo específico em todos os objetos nas hierarquias do vSphere.

Recomendamos a primeira abordagem, porque ela limita o acesso e aumenta a segurança do ambiente do vCenter Server. Para mais informações, consulte Como usar papéis para atribuir privilégios e Práticas recomendadas para papéis e permissões

Para informações sobre como usar a segunda abordagem, consulte Criar uma permissão global.

A tabela a seguir mostra quatro papéis personalizados que um administrador da organização pode criar. Em seguida, o administrador pode usar os papéis personalizados para atribuir permissões em objetos específicos do vSphere:

Função personalizadaPrivilégiosObjetosPropagar para
objetos filhos?
ClusterEditor System.Read
System.View
System.Anonymous
Host.Inventory.Modificar cluster 		cluster Sim
SessionValidator System.Read
System.View
System.anonymous
Sessão Sessions.Validate
Cns.Searchable
Armazenamento orientado por perfis.Visualização de armazenamento orientado por perfis 		Servidor vCenter raiz Não
ReadOnly System.Read
System.View
System.Anonymous 		data center
rede 		Sim
Anthos Privilégios no papel do Anthos datastore
pool de recursos
pasta da VM
rede 		Sim

Privilégios na função personalizada do Anthos

Criar funções e permissões personalizadas

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

O administrador da organização precisa ter uma conta do vCenter Server que tenha privilégios suficientes para criar funções e permissões. Por exemplo, uma conta que tem o papel de administrador é 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 usuário da conta do vCenter Server do administrador da organização.

  • Defina GOVC_PASSWORD como a senha 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 permissão que conceda o papel ClusterEditor

Uma permissão pega um par (usuário, papel) e o associa a um objeto. Ao atribuir uma permissão a um objeto, é possível especificar se ela será propagada para objetos filhos. Com govc, você faz isso definindo a sinalização --propagate como true ou false. O padrão é false.

Crie uma permissão que conceda o papel ClusterEditor a um usuário em um objeto de cluster. Essa permissão é propagada para todos os objetos filhos do objeto de cluster:

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

Substitua:

  • ACCOUNT: a conta de usuário do vCenter Server que está recebendo o papel

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

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

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

Criar permissões adicionais

Esta seção fornece exemplos de criação de permissões adicionais. Substitua os caminhos de objeto de exemplo conforme necessário para seu ambiente.

Crie uma permissão que conceda o papel SessionValidator a uma conta no objeto raiz do vCenter Server. Essa permissão não se propaga a objetos filhos:

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

Crie permissões que concedam o papel ReadOnly a uma conta em um objeto de data center e um objeto de rede. Essas permissões se propagam a objetos filhos:

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

Crie permissões que concedam o papel do Anthos a uma conta em quatro objetos: um datastore, uma pasta de VM, um pool de recursos e uma rede. Essas permissões são propagadas a objetos filhos:

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

Criar uma permissão global

Nesta seção, você verá uma alternativa à criação de vários papéis e várias permissões. Não recomendamos essa abordagem porque ela concede um grande conjunto de privilégios em todos os objetos nas hierarquias do vSphere.

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

Criar uma permissão global:

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

Substitua:

Substitua ACCOUNT pela conta de usuário do vCenter Server que está recebendo o papel

Por exemplo, o comando a seguir cria uma permissão global que concede o papel do Anthos a bob@vsphere.local. A permissão é propagada a todos os objetos nas hierarquias do vSphere:

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

Problemas conhecidos

Consulte O instalador falha ao criar o vSphere datadisk.

A seguir

Requisitos de CPU, RAM e armazenamento