Componentes VMware de nuvem privada
Uma nuvem privada é um ambiente de pilha VMware isolado (hosts ESXi, vCenter, vSAN e NSX) gerenciado por um servidor vCenter em um domínio de gerenciamento. O Google Cloud VMware Engine implanta nuvens privadas com os seguintes componentes da pilha do VMware:
- VMware ESXi: hipervisor em nós dedicados
- VMware vCenter: gerenciamento centralizado do ambiente particular do Cloud vSphere
- VMware vSAN: plataforma de armazenamento hiperconvergente e definida por software
- Dataware NSX Data Center: software de virtualização e segurança de rede
- VMware HCX: migração de aplicativos e rebalanceamento de carga de trabalho em data centers e nuvens
É possível recuperar as credenciais de login geradas para os componentes da pilha do VMware na página de detalhes da nuvem privada.
Versões do componente VMware
Uma pilha VMware de nuvem privada tem as seguintes versões de software:
| Componente | Versão | Versão licenciada |
|---|---|---|
| ESXi | 7.0 Atualização 3o | vSphere Enterprise Plus |
| vCenter | 7.0 Atualização 3p | vCenter Standard |
| vSAN | 7.0 Atualização 3o | Recursos avançados e selecionados do vSAN Enterprise |
| Data center NSX | 3.2.3.1.hp | Selecione os recursos disponíveis. Consulte a seção NSX Data Center para mais detalhes. |
| HCX | 4.6.2 | Enterprise |
ESXi
Quando você cria uma nuvem privada, o VMware ESXi é instalado nos nós provisionados do Google Cloud VMware Engine. O ESXi fornece o hipervisor para implantar máquinas virtuais (VMs, na sigla em inglês) de carga de trabalho. Os nós fornecem infraestrutura hiper-convergent (computação e armazenamento) e fazem parte do cluster do vSphere na nuvem privada.
Cada nó tem quatro interfaces de redes físicas conectadas à rede subjacente. O VMware Engine cria uma chave distribuída do vSphere (VDS, na sigla em inglês) no vCenter usando essas interfaces de rede físicas como uplinks. As interfaces de rede são configuradas no modo ativo-ativo para alta disponibilidade.
vCenter Server Appliance
O vCenter server appliance (VCSA) fornece as funções de autenticação, gerenciamento e orquestração do VMware Engine. Quando você cria e implanta sua nuvem privada, o VMware Engine implanta uma VCSA com um Controlador de serviços de plataforma (PSC, na sigla em inglês) incorporado no cluster do vSphere. Cada nuvem privada tem a própria VCSA. Adicionar nós a uma nuvem privada adiciona nós ao VCSA.
Logon único do vCenter
O controlador de serviços da plataforma incorporado na VCSA está associado a um Logon único
do vCenter. O nome do domínio é gve.local. Para acessar o vCenter, use o
usuário padrão, CloudOwner@gve.local, que é criado para acessar o
vCenter. Você pode adicionar suas origens de identidade locais/Active Directory para
vCenter.
Armazenamento vSAN
Clusters em nuvens privadas configuraram o armazenamento vSAN totalmente em flash. O armazenamento totalmente em flash é fornecido por SSDs locais. Pelo menos três nós da mesma SKU são necessários para criar um cluster do vSphere com um armazenamento de dados vSAN. Cada nó do cluster do vSphere tem dois grupos de discos. Cada grupo de discos contém um disco de cache e três discos de capacidade.
É possível ativar a eliminação de duplicação e a compactação no repositório de dados vSAN no VMware Engine. Esse serviço ativa a eliminação de duplicação e a compactação do vSAN por padrão quando um novo cluster é criado. Cada cluster na sua nuvem privada contém um repositório de dados vSAN. Se os dados da máquina virtual armazenados não forem adequados para a eficiência do espaço vSAN por duplicação e compactação ou somente por compactação, altere a eficiência do espaço vSAN para a configuração escolhida no repositório de dados vSAN individual.
Além dos recursos do vSAN Advanced, o VMware Engine também fornece acesso à criptografia de dados do vSAN Enterprise para dados em repouso e em trânsito.
Políticas de armazenamento vSAN
Uma política de armazenamento vSAN define as falhas na tolerância (FTT, na sigla em inglês) e o método de tolerância a falhas. É possível criar novas políticas de armazenamento e aplicá-las às VMs. Para cumprir o SLA, é preciso manter 20% de capacidade disponível no armazenamento de dados vSAN.
Em cada cluster do vSphere, há uma política de armazenamento vSAN padrão que se aplica ao armazenamento de dados vSAN. A política de armazenamento determina como provisionar e alocar objetos de armazenamento da VM no armazenamento de dados para garantir um nível de serviço.
A tabela a seguir mostra os parâmetros padrão da política de armazenamento vSAN.
| FTT | Método de tolerância a falhas | Número de nós no cluster do vSphere |
|---|---|---|
| 1 | RAID 1 (espelhamento) Cria 2 cópias |
3 e 4 nós |
| 2 | RAID 1 (espelhamento) Cria três cópias |
5 a 32 nós |
Políticas de armazenamento vSAN compatíveis
A tabela a seguir mostra as políticas de armazenamento vSAN compatíveis e o número mínimo de nós necessários para ativar a política:
| FTT | Método de tolerância a falhas | Número mínimo de nós necessários no cluster do vSphere |
|---|---|---|
| 1 | RAID 1 (espelhamento) | 3 |
| 1 | RAID 5 (codificação de apagamento) | 4 |
| 2 | RAID 1 (espelhamento) | 5 |
| 2 | RAID 6 (codificação de apagamento) | 6 |
| 3 | RAID 1 (espelhamento) | 7 |
Data center NSX
O data center NSX fornece virtualização de rede, microsegmentação e recursos de segurança de rede na nuvem privada. Você pode configurar todos os serviços compatíveis com o NSX Data Center em sua nuvem privada usando NSX.
Recursos disponíveis
A lista a seguir descreve os recursos do NSX-T compatíveis com o VMware Engine, organizados por categoria:
- Switching, DNS, DHCP e IPAM (DDI):
- Supressão de transmissão e aprendizado otimizado para ARP
- Replicação Unicast
- Replicação de front-end
- SpoofGuard
- Gerenciamento de endereços IP
- Bloqueios de IP
- Sub-redes IP
- Pools de IP
- Servidor DHCP IPv4
- Redirecionamento DHCP IPv4
- Vinculações/endereços fixos DHCP IPv4
- Proxy DNS/redirecionamento de DNS IPv4
- Roteamento:
- Rotas nulas
- Roteamento estático
- Roteamento de dispositivos
- Controles de rota do BGP usando mapas de rotas e listas de prefixos
- NAT:
- NAT em roteadores lógicos norte/sul e leste/oeste
- NAT de origem
- NAT de destino
- N:N NAT
- Firewall:
- Firewall de borda
- Firewall distribuído
- Interface comum de usuário do firewall
- Seções de firewall
- Geração de registros de firewall
- Regras de firewall com camada 2 e 3
- Regras com base em tags
- IPFIX distribuído com base em firewall
- Políticas, tags e grupos de firewall:
- Inclusão de tags de objetos/segurança
- Agrupamento centrado na rede
- Agrupamento centrado em carga de trabalho
- Agrupamento com base em IP
- Agrupamento com base em MAC
- VPN:
- VPN de camada 2
- VPN de camada 3 (IPv4)
- Integrações:
- Rede e segurança de contêineres usando somente o Tanzu Kubernetes Grid (TKG)
- Serviço VMware Cloud Director
- VMware Aria Automation
- VMware Aria Operations Aria para registros
- Autenticação e autorização:
- Integração direta do Active Directory com o LDAP
- Autenticação usando OpenLDAP
- Controle de acesso baseado em papéis (RBAC)
- Automação:
- API REST
- SDK do Java
- SDK do Python
- Provedor do Terraform
- Módulos do Ansible
- Especificações da OpenAPI/Swagger e documentação da API gerada automaticamente para a API REST
- Inspeção:
- Espelhamento de portas
- Fluxo de rastreamento
- IPFIX baseado em switch
Limitações do recurso
Alguns recursos do NSX Data Center têm casos de uso de rede e segurança muito específicos. Os clientes que criaram a conta do Google Cloud até 30 de agosto de 2022 podem solicitar acesso aos recursos desses casos de uso entrando em contato com o Cloud Customer Care.
A tabela a seguir descreve esses recursos, os casos de uso correspondentes e as possíveis alternativas:
| Recurso | Caso de uso | Alternativa recomendada | Clientes do Google Cloud até 30 de agosto de 2022 | Clientes do Google Cloud após 30 de agosto de 2022 |
|---|---|---|---|---|
| Multicast da camada 3 | Roteamento de multicast da camada 3 de vários saltos | O multicast da camada 2 é compatível com uma sub-rede NSX-T. Isso permite que todo o tráfego multicast seja entregue a cargas de trabalho na mesma sub-rede NSX-T. | Compatível | Sem suporte |
| Qualidade de Serviço (QoS, na sigla em inglês) | Aplicativo sensível à latência e VoIP em que ocorre o excesso de assinaturas da rede | Nenhuma é necessária, já que o VMware Engine fornece uma arquitetura de rede sem excesso de assinaturas. Além disso, todas as tags QoS que saem de uma nuvem privada são removidas ao entrar na VPC por meio de uma conexão de peering. | Compatível | Sem suporte |
| Armadilhas com protocolo de gerenciamento de rede simples (SNMP, na sigla em inglês) | Protocolo de alerta legado para notificar os usuários sobre eventos | Eventos e alarmes podem ser configurados no NSX-T usando protocolos modernos. | Compatível | Sem suporte |
| Recursos NAT, como NAT sem estado, geração de registros do NAT e NAT64 | Usado para NAT de nível de operadora em grandes implantações de telecomunicações | O NSX-T é compatível com NAT de origem/destino e NAT de N:N em roteadores lógicos norte/sul e leste/oeste. | Compatível | Sem suporte |
| Políticas de rede e segurança baseadas em intents | Usado com o VMware Aria para criar políticas de firewall baseadas em negócios dentro do NSX-T | Os recursos de gateway NSX-T e de firewall distribuído podem ser usados para criar e aplicar políticas de segurança. | Compatível | Sem suporte |
| Grupos baseados em identidade usando o Active Directory | Implantações de VDI em que o usuário conectado a um convidado de VDI específico pode ser detectado e receber um conjunto personalizado de regras de firewall NSX-T | É possível atribuir estações de trabalho específicas a usuários usando o pool de atribuição dedicado. Use tags NSX-T para aplicar regras de firewall específicas por pool. | Compatível | Sem suporte |
| Regras de atributo da camada 7 (ID do app) | Usada em regras de firewall NSX-T | Use os Grupos de serviços NSX-T para definir um conjunto de portas e serviços para referência ao criar uma ou mais regras de firewall. | Compatível | Sem suporte |
| Regras de firewall de camada 2 e 3 sem estado | Usado para firewalls de alta velocidade de nível transportadora em grandes implantações de telecomunicações. | O NSX-T é compatível com as regras de camada 2 e 3 com alto desempenho com estado. | Compatível | Sem suporte |
| Inserção de serviços NSX-T | Usado para automatizar a implantação de serviços de rede de terceiros do Norte/Sul ou Leste/Oeste usando NSX-T para proteger e inspecionar o tráfego. | Para implantações de fornecedores de segurança terceirizados, o VMware Engine recomenda um modelo roteado sobre a inserção de serviços para garantir que os upgrades de serviço de rotina não afetem a disponibilidade da rede. | Entrar em contato com o atendimento ao cliente do Cloud | Sem suporte |
Como usar licenças
O Google Cloud é um parceiro do VMware Cloud. Você pode escolher um tipo de desconto de uso garantido (CUD, na sigla em inglês) que inclui licenças como parte do serviço gerenciado do VMware Engine ou pode usar suas próprias licenças.
Atualizações e upgrades
Esta seção descreve as considerações de atualização e upgrade e as responsabilidades de gerenciamento do ciclo de vida dos componentes de software.
HCX
O VMware Engine processa a instalação inicial, a configuração e o monitoramento do HCX em nuvens privadas. Depois disso, você é responsável pelo gerenciamento do ciclo de vida do HCX Cloud e dos dispositivos de serviço, como o HCX-IX Interconnect.
O VMware fornece atualizações para o HCX Cloud pelo serviço de HCX. É possível fazer upgrade do HCX Manager e implantar dispositivos de serviço do HCX pela interface do HCX Cloud. Para encontrar a data de término da versão de suporte de um produto, consulte a Matriz de ciclo de vida do produto do VMware.
Outros softwares da VMware
O Google é responsável pelo gerenciamento do ciclo de vida do software VMware (ESXi, vCenter, PSC e NSX) na nuvem privada.
As atualizações de software incluem:
- Patches: patches de segurança ou correções de bugs lançados pela VMware
- Atualizações: alteração na versão secundária de um componente da pilha do VMware
- Atualizações: alteração na versão principal de um componente da pilha do VMware
O Google testa um patch de segurança crítico assim que ele fica disponível no VMware. Por SLA, o Google lança o patch de segurança em ambientes de nuvem privada dentro de uma semana.
O Google fornece atualizações trimestrais de manutenção aos componentes de software do VMware. Para uma nova versão principal da versão do software VMware, o Google trabalha com os clientes para coordenar uma janela de manutenção adequada para upgrade.
Cluster do vSphere
Para garantir a alta disponibilidade da nuvem privada, os hosts ESXi são configurados como um cluster. Quando você cria uma nuvem privada, o VMware Engine implanta componentes de gerenciamento do vSphere no primeiro cluster. O VMware Engine cria um pool de recursos para componentes de gerenciamento e implanta todas as VMs de gerenciamento neste pool de recursos.
O primeiro cluster não pode ser excluído para reduzir a nuvem privada. O cluster do
vSphere usa o vSphere HA para fornecer alta disponibilidade às VMs. As falhas de
tolerância (FTT, na sigla em inglês) são baseadas no número de nós disponíveis no cluster. A
fórmula Number of nodes = 2N+1, em que N é o FTT, descreve a
relação entre os nós disponíveis em um cluster e o FTT.
Para cargas de trabalho de produção, use uma nuvem privada que contenha pelo menos três nós.
Nuvens privadas de nó único
Para testes e provas de conceito com VMware Engine, crie uma nuvem privada que contenha somente um nó e cluster. O VMware Engine exclui nuvens privadas que contêm apenas um nó após 60 dias, além de VMs e dados de cargas de trabalho associados.
É possível redimensionar uma nuvem privada de nó único para conter três ou mais nós. Ao fazer isso, o VMware Engine inicia a replicação de dados vSAN e não tenta mais excluir a nuvem privada. Uma nuvem privada precisa conter pelo menos três nós e concluir a replicação de dados vSAN para ser qualificada para cobertura com base no SLA.
Recursos ou operações que exigem mais de um nó não funcionarão com uma nuvem privada de nó único. Por exemplo, não será possível usar o vSphere Distributed Resource Scheduler (DRS) ou a alta disponibilidade (HA, na sigla em inglês).
Limites de clusters do vSphere
A tabela a seguir descreve os limites de cluster do vSphere em nuvens privadas que atendem aos requisitos dos SLAs:
| Recurso | Limite |
|---|---|
| Número mínimo de nós para criar uma nuvem privada (primeiro cluster) | 3 |
| Número mínimo de nós para criar um cluster | 3 |
| Número máximo de nós por cluster | 32 |
| Número máximo de nós por nuvem privada | 96 |
| Número máximo de clusters por nuvem privada | 21 |
Suporte ao sistema operacional convidado
É possível instalar uma VM com qualquer sistema operacional convidado compatível com a VMware para a versão ESXi na nuvem privada. Para uma lista de sistemas operacionais convidados compatíveis, consulte o Guia de compatibilidade do VMware para SO convidado.
Manutenção da infraestrutura do VMware
Ocasionalmente, é necessário fazer alterações na configuração da infraestrutura da VMware. Esses intervalos podem ocorrer a cada um ou dois meses, mas a frequência precisa diminuir com o tempo. Esse tipo de manutenção geralmente pode ser feito sem interromper o uso normal dos serviços.
Durante um intervalo de manutenção do VMware, os seguintes serviços continuam a funcionar sem qualquer efeito:
- Plano de gerenciamento de VMware e aplicativos
- Acesso ao vCenter
- Toda a rede e armazenamento
- Todo o tráfego da nuvem
Armazenamento externo
É possível expandir a capacidade de armazenamento de um cluster do Google Cloud VMware Engine adicionando mais nós. Se preferir, use o armazenamento externo apenas para escalonar o armazenamento. O escalonamento do armazenamento aumenta a capacidade de armazenamento sem aumentar a capacidade de computação do cluster, permitindo escalonar o recurso de maneira independente.
Entre em contato com o Suporte do Google ou com seu representante de vendas para saber mais sobre o uso do armazenamento externo.
A seguir
- Saiba mais sobre atualizações e manutenção de nuvem privada.