Componentes VMware de nuvem privada
Uma nuvem privada é uma pilha VMware isolada (anfitriões ESXi, vCenter, vSAN e NSX) gerida por um vCenter Server num domínio de gestão. O Google Cloud VMware Engine implementa nuvens privadas com os seguintes componentes da pilha VMware:
- VMware ESXi: hipervisor em nós dedicados
- VMware vCenter: gestão centralizada do ambiente vSphere da nuvem privada
- VMware vSAN: plataforma de armazenamento hiperconvergente definida por software
- VMware NSX Data Center: software de segurança e virtualização de rede
- VMware HCX: migração de aplicações e reequilíbrio de cargas de trabalho em centros de dados e nuvens
Pode obter credenciais de início de sessão geradas para componentes da pilha VMware na página de detalhes da nuvem privada.
Versões dos componentes VMware
Uma pilha do VMware na nuvem privada tem as seguintes versões de software:
Componente | Versão | Versão licenciada |
---|---|---|
ESXi | Atualização 8.0 3f | VMware Cloud Foundation |
vCenter | Atualização 8.0 3e | VMware Cloud Foundation |
vSAN | 8.0 Update 3 | VMware Cloud Foundation |
NSX Data Center | 4.2.2.1 | VMware Cloud Foundation |
HCX | 4.10.3 | VMware Cloud Foundation |
Aria | 8.16 | VMware Cloud Foundation |
1O VMware Engine implementa uma versão do HCX disponibilizada à Google Cloud pela VMware. Atualize o HCX após a criação da nuvem privada para obter a versão mais recente do HCX para o seu ambiente.
ESXi
Quando cria uma nuvem privada, o VMware ESXi é instalado nos nós do Google Cloud VMware Engine aprovisionados. O ESXi fornece o hipervisor para implementar máquinas virtuais (VMs) de carga de trabalho. Os nós fornecem uma infraestrutura hiperconvergente (computação e armazenamento) e fazem parte do cluster do vSphere na sua nuvem privada.
Cada nó tem quatro interfaces de rede físicas ligadas à rede subjacente. O VMware Engine cria um comutador distribuído do vSphere (VDS) no vCenter através destas interfaces de rede físicas como ligações de carregamento. As interfaces de rede estão configuradas no modo ativo para elevada disponibilidade.
vCenter Server Appliance
O vCenter Server Appliance (VCSA) fornece as funções de autenticação, gestão e orquestração para o VMware Engine. Quando cria e implementa a sua nuvem privada, o VMware Engine implementa um VCSA com um Platform Services Controller (PSC) incorporado no cluster do vSphere. Cada nuvem privada tem o seu próprio VCSA. A adição de nós a uma nuvem privada adiciona nós ao VCSA.
Início de sessão único do vCenter
O controlador de serviços da plataforma incorporado no VCSA está associado a um vCenter
Single Sign-On. O nome do domínio é gve.local
. Para aceder ao vCenter, use o utilizador predefinido, CloudOwner@gve.local
, que é criado para si para aceder ao vCenter. Pode adicionar as suas origens de identidade no local/Active Directory para o vCenter.
Armazenamento vSAN
Os clusters em nuvens privadas têm armazenamento vSAN totalmente configurado com tecnologia all-flash. O armazenamento totalmente flash é fornecido por SSDs locais. São necessários, pelo menos, três nós do mesmo SKU para criar um cluster do vSphere com um arquivo de dados do 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.
Pode ativar a remoção de duplicados e a compressão no arquivo de dados vSAN no VMware Engine. Este serviço ativa a desduplicação e a compressão do vSAN por predefinição quando é criado um novo cluster. Cada cluster na sua nuvem privada contém um arquivo de dados do vSAN. Se os dados da máquina virtual armazenados não forem adequados para a eficiência do espaço do vSAN através da eliminação de duplicados e da compressão ou apenas através da compressão, pode alterar a eficiência do espaço do vSAN para a configuração escolhida no arquivo de dados do vSAN individual.
Além das funcionalidades avançadas do vSAN, o VMware Engine também oferece acesso à encriptação de dados do vSAN Enterprise para dados inativos e dados em trânsito.
Políticas de armazenamento do vSAN
Uma política de armazenamento vSAN define as Falhas a tolerar (FTT) e o Método de tolerância a falhas. Pode criar novas políticas de armazenamento e aplicá-las às VMs. Para manter o SLA, tem de manter uma capacidade disponível de 20% no arquivo de dados do vSAN.
Em cada cluster do vSphere, existe uma política de armazenamento do vSAN predefinida que se aplica ao armazenamento de dados do vSAN. A política de armazenamento determina como aprovisionar e atribuir objetos de armazenamento de VMs no arquivo de dados para garantir um nível de serviço.
A tabela seguinte mostra os parâmetros da política de armazenamento do vSAN predefinidos:
FTT | Método de tolerância a falhas | Número de nós no cluster do vSphere |
---|---|---|
1 | RAID 1 (duplicação) Cria 2 cópias |
3 e 4 nós |
2 | RAID 1 (duplicação) Cria 3 cópias |
5 a 32 nós |
Políticas de armazenamento vSAN suportadas
A tabela seguinte mostra as políticas de armazenamento do vSAN suportadas 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 eliminação) | 4 |
2 | RAID 1 (espelhamento) | 5 |
2 | RAID 6 (codificação de eliminação) | 6 |
3 | RAID 1 (espelhamento) | 7 |
NSX Data Center
O NSX Data Center oferece capacidades de virtualização de rede, microsegmentação e segurança de rede na sua nuvem privada. Pode configurar serviços suportados pelo NSX Data Center na sua nuvem privada através do NSX.
Funcionalidades disponíveis
A lista seguinte descreve as funcionalidades do NSX suportadas pelo VMware Engine, organizadas por categoria:
- Comutação, DNS, DHCP e IPAM (DDI):
- Aprendizagem de ARP otimizada e supressão de transmissões
- Replicação unicast
- Replicação de cabeçalho
- SpoofGuard
- Gestão de endereços IP
- Blocos de IP
- Sub-redes IP
- Conjuntos de IPs
- Servidor DHCP IPv4
- Transmissão de DHCP IPv4
- Associações estáticas/endereços fixos de DHCP IPv4
- Relé de DNS IPv4/proxy de DNS
- Encaminhamento:
- Encaminhamentos nulos
- Encaminhamento estático
- Encaminhamento de dispositivos
- Controlos de rotas BGP através de mapas de rotas e listas de prefixos
- NAT:
- NAT em routers lógicos norte/sul e este/oeste
- NAT de origem
- NAT de destino
- N:N NAT
- Firewall:
- Firewall de perímetro
- Firewall distribuída
- Interface do utilizador da firewall comum
- Secções da firewall
- Registo de firewall
- Regras de firewall com estado da camada 2 e da camada 3
- Regras baseadas em etiquetas
- IPFIX baseado em firewall distribuído
- Políticas de firewall, etiquetas e grupos:
- Etiquetagem de objetos/etiquetas de segurança
- Agrupamento centrado na rede
- Agrupamento centrado na carga de trabalho
- Agrupamento com base no IP
- Agrupamento baseado em MAC
- VPN:
- VPN de camada 2
- VPN de camada 3 (IPv4)
- Integrações:
- Redes e segurança de contentores apenas com o Tanzu Kubernetes Grid (TKG)
- Serviço VMware Cloud Director
- VMware Aria Automation
- VMware Aria Operations for Logs
- Autenticação e autorização:
- Integração direta do Active Directory através do LDAP
- Autenticação com o OpenLDAP
- Controlo de acesso baseado em funções (CABF)
- Automatização:
- API REST
- SDK Java
- SDK Python
- Fornecedor do Terraform
- Módulos do Ansible
- Especificações da OpenAPI/Swagger e documentação da API gerada automaticamente para a API REST
- Inspection:
- Espelhamento de porta
- Traceflow
- IPFIX baseado em comutador
Limitações de funcionalidades
Algumas funcionalidades do NSX Data Center têm exemplos de utilização de rede e segurança muito específicos. Os clientes que criaram a respetiva Google Cloud conta a 30 de agosto de 2022 ou antes podem pedir acesso a funcionalidades para esses exemplos de utilização contactando o apoio técnico ao cliente da Google Cloud.
A tabela seguinte descreve essas funcionalidades, os respetivos exemplos de utilização e alternativas potenciais:
Funcionalidade | Exemplo de utilização | Alternativa recomendada | Google Cloud clientes antes ou até 30 de agosto de 2022 | Google Cloud clientes após 30 de agosto de 2022 |
---|---|---|---|---|
Multicast de camada 3 | Encaminhamento multicast de camada 3 de vários saltos | A transmissão múltipla da camada 2 é suportada numa sub-rede do NSX. Isto permite que todo o tráfego de multicast seja entregue a cargas de trabalho na mesma sub-rede do NSX. | Suportado | Não suportado |
Qualidade de Serviço (QoS) | VoIP e aplicação sensível à latência onde ocorre a subscrição excessiva da rede | Não é necessário nenhum, uma vez que o VMware Engine oferece uma arquitetura de rede não sobreinscrita. Além disso, todas as etiquetas de QoS que saiam de uma nuvem privada são removidas quando entram na VPC através de uma ligação de intercâmbio. | Suportado | Não suportado |
Armadilhas do Protocolo de gestão de redes simples (SNMP) | Protocolo de alerta antigo para notificar os utilizadores de eventos | Os eventos e os alarmes podem ser configurados no NSX através de protocolos modernos. | Suportado | Não suportado |
Funcionalidades de NAT, como NAT sem estado, registo de NAT e NAT64 | Usado para NAT de nível de operadora em implementações de telecomunicações de grande escala | O NSX suporta NAT de origem/destino e NAT N:N em routers lógicos norte/sul e leste/oeste. | Suportado | Não suportado |
Políticas de segurança e rede baseadas na intenção | Usado em conjunto com o VMware Aria para criar políticas de firewall baseadas na empresa no NSX | As funcionalidades do gateway NSX e da firewall distribuída podem ser usadas para criar e aplicar políticas de segurança. | Suportado | Não suportado |
Grupos baseados na identidade que usam o Active Directory | Implementações de VDI em que o utilizador com sessão iniciada num convidado de VDI específico pode ser detetado e receber um conjunto personalizado de regras de firewall do NSX | Os utilizadores podem ser atribuídos a estações de trabalho específicas através do conjunto de atribuições dedicadas. Use etiquetas NSX para aplicar regras de firewall específicas por conjunto. | Suportado | Não suportado |
Regras de atributo da camada 7 (ID da app) | Usado em regras de firewall do NSX | Use grupos de serviços NSX para definir um conjunto de portas e serviços para referência quando criar uma ou mais regras de firewall. | Suportado | Não suportado |
Regras de firewall sem estado da camada 2 e da camada 3 | Usado para firewalls de alta velocidade de nível de operadora em implementações de telecomunicações de grande escala | O NSX suporta regras de camada 2 e camada 3 de elevado desempenho com estado. | Suportado | Não suportado |
Inserção de serviços NSX | Usado para automatizar a implementação norte/sul ou leste/oeste de serviços de rede de terceiros através da utilização do NSX para proteger e inspecionar o tráfego | Para implementações de fornecedores de segurança de terceiros, o VMware Engine recomenda um modelo encaminhado em vez da inserção de serviços para garantir que as atualizações de serviços de rotina não afetam a disponibilidade da rede. | Contacte o apoio ao cliente do Google Cloud | Não suportado |
Usar licenças
Google Cloud é um parceiro do VMware Cloud. Pode escolher um tipo de desconto por utilização garantida (DUG) que inclua licenças como parte do serviço VMware Engine gerido ou pode optar por trazer as suas próprias licenças.
Atualizações
Esta secção descreve as considerações de atualização e upgrade, bem como as responsabilidades de gestão do ciclo de vida dos componentes de software.
HCX
O VMware Engine processa a instalação, a configuração e a monitorização iniciais do HCX em nuvens privadas. Depois disso, é responsável pela gestão do ciclo de vida do HCX Cloud e dos dispositivos de serviço, como o HCX-IX Interconnect.
A VMware fornece atualizações para o HCX Cloud através do respetivo serviço HCX. Pode atualizar o HCX Manager e os dispositivos de serviço HCX implementados a partir da interface do HCX Cloud. Para encontrar a data de fim do apoio técnico de uma versão de produto, consulte a matriz do ciclo de vida do produto VMware.
Outro software VMware
A Google é responsável pela gestão 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 erros lançados pela VMware
- Atualizações: alteração da versão secundária de um componente da pilha VMware
- Atualizações: alteração da versão principal de um componente do conjunto de ferramentas VMware
A Google testa uma correção de segurança crítica assim que esta fica disponível na VMware. De acordo com o SLA, a Google implementa a correção de segurança em ambientes de nuvem privada no prazo de uma semana.
A Google fornece atualizações de manutenção trimestrais aos componentes de software da VMware. Para uma nova versão principal do software VMware, a Google trabalha com os clientes para coordenar um período de manutenção adequado para a atualização.
Cluster do vSphere
Para garantir a elevada disponibilidade da nuvem privada, os anfitriões ESXi estão configurados como um cluster. Quando cria uma nuvem privada, o VMware Engine implementa os componentes de gestão do vSphere no primeiro cluster. O VMware Engine cria um conjunto de recursos para componentes de gestão e implementa todas as VMs de gestão neste conjunto de recursos.
Não é possível eliminar o primeiro cluster para reduzir a nuvem privada. O cluster do vSphere usa o vSphere HA para oferecer alta disponibilidade para VMs. As falhas a tolerar (FTT) baseiam-se 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 num cluster e o FTT.
Para cargas de trabalho de produção, use uma nuvem privada que contenha, pelo menos, 3 nós.
Nuvens privadas de nó único
Para testes e provas de conceito com o VMware Engine, pode criar uma nuvem privada que contenha apenas um único nó e cluster. O VMware Engine elimina nuvens privadas que contêm apenas 1 nó após 60 dias, juntamente com todas as VMs e dados de carga de trabalho associados.
Pode redimensionar uma nuvem privada de nó único para conter 3 ou mais nós. Quando o faz, o VMware Engine inicia a replicação de dados do vSAN e deixa de tentar eliminar a nuvem privada. Uma nuvem privada tem de conter, pelo menos, 3 nós e replicar os dados do vSAN para ser elegível para cobertura com base no SLA.
As funcionalidades ou as operações que requerem mais de 1 nó não funcionam com uma nuvem privada de um único nó. Por exemplo, não pode usar o vSphere Distributed Resource Scheduler (DRS) nem a elevada disponibilidade (HA).
Limites de clusters do vSphere
A tabela seguinte descreve os limites do cluster do vSphere em nuvens privadas padrão que cumprem os requisitos do ANS:
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 |
A tabela seguinte descreve os limites de clusters do vSphere em nuvens privadas expandidas:
Recurso | Limite |
---|---|
Número mínimo de nós para criar uma nuvem privada expandida (primeiro cluster) | 6 |
Número mínimo de nós para criar um cluster expandido | 6 |
Número máximo de nós por cluster expandido | 30 |
Número máximo de nós por nuvem privada expandida | 96 |
Número máximo de clusters por nuvem privada expandida | 16 |
Apoio técnico a sistemas operativos convidados
Pode instalar uma VM com qualquer sistema operativo convidado suportado pelo VMware para a versão ESXi na sua nuvem privada. Para ver uma lista dos sistemas operativos convidados suportados, consulte o guia de compatibilidade do VMware para o SO convidado.
Manutenção da infraestrutura VMware
Ocasionalmente, é necessário fazer alterações à configuração da infraestrutura do VMware. Estes intervalos podem ocorrer a cada 1 a 2 meses, mas espera-se que a frequência diminua ao longo do tempo. Normalmente, este tipo de manutenção pode ser feito sem interromper a utilização normal dos serviços.
Durante um intervalo de manutenção da VMware, os seguintes serviços continuam a funcionar sem qualquer efeito:
- Aplicações e plano de gestão do VMware
- Acesso ao vCenter
- Todas as redes e armazenamento
- Todo o tráfego na nuvem
Armazenamento externo
Pode expandir a capacidade de armazenamento de um cluster do Google Cloud VMware Engine adicionando mais nós. Em alternativa, pode usar o armazenamento externo se quiser apenas dimensionar o armazenamento. A expansão do armazenamento aumenta a capacidade de armazenamento sem aumentar a capacidade de computação do cluster, o que lhe permite expandir o seu recurso de forma independente.
Contacte o Apoio técnico da Google ou o seu representante de vendas para mais informações sobre a utilização do armazenamento externo.
O que se segue?
- Saiba mais sobre a manutenção e as atualizações da nuvem privada.