Visão geral dos repositórios de dados NFS

À medida que seus dados crescem, talvez seja necessário escalonar o armazenamento das cargas de trabalho do VMware de forma independente dos recursos de computação. Embora o armazenamento vSAN padrão no VMware Engine ofereça alto desempenho para os aplicativos mais exigentes, a adição de capacidade exige a adição de um nó completo, incluindo recursos de computação e rede que talvez não sejam necessários.

Para oferecer mais flexibilidade, o VMware Engine oferece suporte a repositórios de dados NFS (Network File System) externos de serviços como o Filestore e o Google Cloud NetApp Volumes. O uso de um repositório de dados NFS externo é uma maneira econômica de escalonar o armazenamento para aplicativos de nível 2 e 3, backups e cargas de trabalho de arquivamento que não exigem o alto desempenho do vSAN.

Serviços de armazenamento NFS com suporte

É possível usar repositórios de dados NFS externos com os seguintes Google Cloud serviços:

Pré-requisitos gerais para usar repositórios de dados NFS com o VMware Engine

Antes de ativar um volume NFS externo como um Datastore, é necessário atender aos seguintes pré-requisitos:

Requisitos de volume NFS

Os volumes NFS precisam atender aos seguintes requisitos:

  • Localização: o volume NFS (instância do Filestore ou volume do Google Cloud NetApp Volumes) e o cluster do VMware Engine precisam estar na mesma Google Cloud região. O VMware Engine não oferece suporte à ativação de repositórios de dados em regiões diferentes. Para nuvens privadas estendidas, apenas repositórios de dados regionais são aceitos.
  • Protocolo:o VMware Engine oferece suporte apenas à versão 3 do NFS (NFSv3) para uso como um repositório de dados do VMware Engine. O NFSv4.1 não é aceito.
  • Proteção contra exclusão:se você estiver usando o Filestore ou o Google Cloud NetApp Volumes, ative a proteção contra exclusão no volume para evitar exclusão acidental e perda de dados.

Permissões da conta de serviço do VMware Engine

Para criar e ativar um Datastore com suporte do Filestore ou do Google Cloud NetApp Volumes, o VMware Engine usa uma conta de serviço gerenciado pelo Google para acessar recursos NFS. Conceda os seguintes papéis do IAM à conta de serviço (service-PROJECT_NUMBER@gcp-sa-vmwareengine.iam.gserviceaccount.com):

  • roles/compute.networkViewer:necessário para que todos os tipos de Datastore visualizem os peerings de rede. Conceda esse papel no projeto em que o volume NFS reside. Se você usar a VPC compartilhada, conceda esse papel no projeto host.
  • roles/file.viewer:necessário para que os repositórios de dados com suporte do Filestore acessem instâncias do Filestore. Conceda esse papel no projeto em que o Filestore reside.
  • roles/netapp.viewer:necessário para que os repositórios de dados com suporte do Google Cloud NetApp Volumes acessem volumes do Google Cloud NetApp Volumes. Conceda esse papel no projeto em que o Google Cloud NetApp Volumes reside.

Use os comandos a seguir para conceder esses papéis:

Ao conceder o papel roles/compute.networkViewer para uma configuração de VPC compartilhada, substitua o ID do projeto no exemplo pelo ID do projeto host.

Para o Filestore:

gcloud projects add-iam-policy-binding FILESTORE_PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-vmwareengine.iam.gserviceaccount.com \
    --role=roles/file.viewer

gcloud projects add-iam-policy-binding FILESTORE_PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-vmwareengine.iam.gserviceaccount.com \
    --role=roles/compute.networkViewer

Para o Google Cloud NetApp Volumes:

gcloud projects add-iam-policy-binding NETAPP_PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-vmwareengine.iam.gserviceaccount.com \
    --role=roles/netapp.viewer

gcloud projects add-iam-policy-binding NETAPP_PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-vmwareengine.iam.gserviceaccount.com \
    --role=roles/compute.networkViewer

Substitua:

  • FILESTORE_PROJECT_ID: o ID do projeto em que a instância do Filestore reside.
  • NETAPP_PROJECT_ID: o ID do projeto em que o volume do Google Cloud NetApp Volumes reside.
  • PROJECT_NUMBER: o número do projeto em que o VMware Engine está ativado.

Requisitos da sub-rede de serviço

É necessário ter uma sub-rede de serviço dedicada com um intervalo CIDR exclusivo alocado para o tráfego NFS entre hosts ESXi e o volume NFS. Configure a sub-rede de serviço da seguinte maneira:

  • É necessário configurar um intervalo CIDR para a sub-rede de serviço que tenha endereços IP suficientes para atribuir um a cada nó na nuvem privada.
  • Só é possível usar a sub-rede de serviço para o tráfego de repositório de dados NFS, mas é possível conectar a mesma sub-rede a vários repositórios de dados NFS diferentes.
  • Adicione a alocação CIDR reservada para a sub-rede de serviço à lista de clientes permitidos ou à política de exportação do volume NFS. Para o Filestore, adicione uma regra de controle de acesso para o intervalo CIDR da sub-rede de serviço. Para o Google Cloud NetApp Volumes, adicione o CIDR à seção Clientes permitidos das regras de exportação do volume.

O gateway NSX-T e as regras de firewall distribuídas não se aplicam a sub-redes de serviço.

Requisitos de conexão de rede

Uma conexão ativa precisa existir entre a rede VPC do volume NFS e a rede do VMware Engine (VEN, na sigla em inglês) da nuvem privada em que você vai ativar o Datastore. As cobranças de rede resultantes do acesso ao armazenamento dentro de uma região não se aplicam ao usar o Filestore com o acesso privado a serviços (PSA, na sigla em inglês).

Ao se conectar a serviços de arquivos de rede, use um dos seguintes métodos de conexão, dependendo do tipo de VEN da nuvem privada:

  • VEN padrão:as nuvens privadas criadas em um VEN padrão usam o peering de rede VPC para se conectar a serviços de arquivos de rede, como o Filestore (usando o PSA) ou o Google Cloud NetApp Volumes.
  • VEN legada:as nuvens privadas que operam em um VEN legada exigem uma conexão privada para se conectar a serviços de arquivos de rede. Se você excluir uma conexão privada enquanto um repositório de dados NFS estiver em uso, o acesso ao Datastore será interrompido. Portanto, não exclua uma conexão privada enquanto um repositório de dados NFS estiver ativado e em uso.

Interoperabilidade com o ciclo de vida da nuvem privada

Os repositórios de dados NFS gerenciados pela API VMware Engine permanecem persistentes em eventos de ciclo de vida da nuvem privada das seguintes maneiras:

  • Expansão e contração de clusters:se você adicionar nós a um cluster com repositórios de dados NFS ativados, o VMware Engine vai ativar automaticamente esses repositórios de dados nos novos nós. Se você remover nós ao contrair um cluster, os endereços IP vmknic serão liberados.
  • Reinicialização do nó:a configuração do repositório de dados NFS em um nó é persistente e permanece intacta após uma reinicialização do nó.
  • Upgrades de software:os repositórios de dados NFS ativados em hosts não são afetados por upgrades de componentes ESXi, vCenter e NSX-T.

Migração de ativações de repositórios de dados NFS legados

Se você criou repositórios de dados NFS no VMware Engine antes de 1º de janeiro de 2026, está usando o modelo legado. Para fazer a transição para o modelo aceito e recomendado, entre em contato com o Cloud Customer Care para iniciar o processo de migração.

Problemas conhecidos

A seguir estão os problemas conhecidos com repositórios de dados NFS externos:

  • Durante a exclusão temporária da nuvem privada, o caminho de rede para o Datastore é interrompido.
  • Depois que o peering de rede VPC é estabelecido, a propagação de rotas para nós do vSphere pode levar até 20 minutos.

A seguir