Considerações de design para nuvens privadas de geração 2 de Solução VMware no Azure

Este artigo descreve as principais considerações de design para solução VMware no Azure nuvens privadas de Geração 2 (Gen 2). Ele explica os recursos que essa geração traz para ambientes de nuvem privada baseados em VMware, permitindo o acesso para seus aplicativos de infraestrutura local e recursos baseados em Azure. Há várias considerações a serem analisadas antes de configurar sua nuvem privada Solução VMware no Azure Gen 2. Este artigo fornece soluções para casos de uso que você pode encontrar ao usar o tipo de nuvem privada.

Limitações

A funcionalidade a seguir é limitada durante esse tempo. Essas limitações serão levantadas no futuro:

• Você não pode excluir seu Grupo de Recursos, que contém sua nuvem privada. Primeiro, você deve excluir a nuvem privada antes de excluir o grupo de recursos.
• Você só pode implantar 1 nuvem privada por rede virtual Azure.
• Você só pode criar uma nuvem privada por Grupo de Recursos. Não há suporte para várias nuvens privadas em um único Grupo de Recursos.
• Sua nuvem privada e rede virtual para sua nuvem privada devem estar no mesmo Grupo de Recursos.
• Você não pode mover sua nuvem privada de um Grupo de Recursos para outro após a criação da nuvem privada.
• Você não pode mover sua nuvem privada de um locatário para outro depois que a nuvem privada é criada.
• Se você precisar de ExpressRoute FastPath ou Emparelhamento de Rede Virtual Global para sua Nuvem Privada da AVS, crie um Caso de Suporte por meio do portal do Azure.
• Service Endpoints não oferecem suporte para conectividade direta das cargas de trabalho do Solução VMware no Azure.
• Não há suporte para pontos de extremidade privados quando emparelhados globalmente entre regiões conectadas à solução VMware no Azure.
• Há suporte para o vCloud Director usando os pontos de extremidade privados. No entanto, o vCloud Director usando endpoints públicos não é compatível.
• Não há suporte para clusters estendidos vSAN.
• IP público até o Microsoft Edge do VMware NSX para configurar a Internet não é suportado. Você pode encontrar quais opções de Internet têm suporte nas opções de conectividade com a Internet.
• Durante a manutenção não planejada, como falha de hardware em um host, em qualquer um dos quatro primeiros hosts no seu SDDC (Data Center Definido por Software), você poderá enfrentar uma interrupção temporária na conectividade de rede norte-sul para algumas cargas de trabalho, com duração de até 30 segundos. A conectividade Norte-Sul refere-se ao tráfego entre suas workloads VMware da AVS e pontos de extremidade externos além do NSX-T Nível 0 (T0) Edge, como ambientes locais ou serviços do Azure. Essa limitação foi removida em regiões Azure específicas. Confirme se sua região é afetada por essa limitação verificando com Azure Suporte.  
• Os Grupos de Segurança de Rede associados à rede virtual de host de nuvem privada devem ser criados no mesmo grupo de recursos que a nuvem privada e sua rede virtual.
• Referências entre grupos de recursos e entre assinaturas de redes virtuais do cliente para a rede virtual da Solução VMware no Azure não são suportadas por padrão. Isso inclui tipos de recursos como: UDRs (rotas definidas pelo usuário), Planos de Proteção contra DDoS e outros recursos de rede vinculados. Se uma rede virtual do cliente estiver associada a uma dessas referências que reside em um grupo de recursos ou assinatura diferente do Solução VMware no Azure rede virtual, a programação de rede (como propagação de segmento NSX) poderá falhar. Para evitar problemas, os clientes devem garantir que a rede virtual Solução VMware no Azure não esteja conectada aos recursos em outro grupo de recursos ou assinatura. Antes de continuar, remova essas conexões, como planos de proteção contra DDoS, da rede virtual.
  • Para manter sua referência entre grupos de recursos, crie uma atribuição de função de seu grupo de recursos cruzados ou assinatura e dê ao "AzS VIS Prod App" a "Função AVS no VIS da Frota". A atribuição de função permite que você use a referência e tenha sua referência aplicada corretamente ao seu Solução VMware no Azure nuvem privada.
• As implementações de nuvem privada Gen 2 podem falhar se as políticas do Azure impuserem regras rígidas para os grupos de segurança de rede ou tabelas de rotas (por exemplo, convenções de nomenclatura específicas). Essas restrições de política podem bloquear a criação do Grupo de Segurança de Rede e da tabela de rotas do Solução VMware no Azure necessárias durante a implantação. Você deve remover essas políticas da rede virtual Solução VMware no Azure antes de implantar sua nuvem privada. Depois que sua nuvem privada for implantada, essas políticas poderão ser adicionadas novamente à sua nuvem privada Solução VMware no Azure.
• Se você estiver usando DNS privado para sua nuvem privada Solução VMware no Azure Gen 2, usando Custom DNS na rede virtual em que uma nuvem privada do Solução VMware no Azure Gen 2 é implantada não tem suporte. O DNS personalizado interrompe operações de ciclo de vida, como dimensionamento, atualizações e aplicação de patch.
• Se você estiver excluindo sua nuvem privada e alguns recursos criados pelo Solução VMware no Azure não forem removidos, poderá tentar excluir novamente a nuvem privada do Solução VMware no Azure usando a CLI do Azure.
• Solução VMware no Azure Gen 2 usa um Proxy HTTP para distinguir entre o tráfego de rede de gerenciamento e o cliente. Certos endpoints de serviço de nuvem VMware podem não seguir o mesmo caminho de rede ou regras de proxy que o tráfego geral gerenciado pelo vCenter. Os exemplos incluem: "scapi.vmware" e "apigw.vmware". O proxy VAMI rege o acesso geral da Internet de saída do VCenter Server Appliance (VCSA), mas nem todas as interações de ponto de extremidade de serviço fluem por esse proxy. Algumas interações se originam diretamente do navegador do usuário ou de componentes de integração, que, em vez disso, seguem as configurações de proxy da estação de trabalho ou iniciam conexões de forma independente. Como resultado, o tráfego para pontos de extremidade do serviço de nuvem VMware pode ignorar totalmente o proxy VCSA.
• As migrações HCX RAV e Bulk em Gen 2 podem apresentar desempenho mais lento devido a interrupções durante as fases de Sincronização Base e Sincronização Online. Os clientes devem planejar janelas de migração mais longas e agendar ondas adequadamente nesse momento. Para cargas de trabalho adequadas, o vMotion oferece uma opção mais rápida e de baixa sobrecarga quando as condições de host e rede permitem.
• Pareamento de hub virtual (WAN virtual): para estabelecer uma conexão de pareamento entre uma rede virtual Gen-2 e um hub virtual (WAN virtual), o hub virtual deve estar na mesma região da rede virtual Gen-2. Se você precisar emparelhar com um hub virtual em uma região diferente, precisará criar um Caso de Suporte por meio do portal Azure.
• /32 Destino de rota de uma Rede Virtual (VNET) emparelhada: se você estiver anunciando rotas /32 a partir do NSX (como rotas HCX MON ou rotas de encaminhamento de DNS) e precisar de acesso a esse destino /32 a partir de uma rede virtual emparelhada, será necessário abrir um chamado de suporte no portal do Azure. A conectividade com o destino /32 funciona corretamente de dentro da VNET local.
• Anúncio da sub-rede de sincronização entre pares da VNET e associação da Tabela de Rotas do Azure (UDR) – o Solução VMware no Azure Gen 2 utiliza duas arquiteturas internas. A arquitetura atual sincroniza tanto as sub-redes específicas quanto o espaço de endereços mais amplo do Azure para as rotas de segmento ou sub-rede do NSX com redes virtuais do Azure emparelhadas. Como resultado, com a arquitetura atual da Geração 2, talvez seja necessário configurar tabelas de rotas do Azure (UDR) com rotas de sub-rede de segmentos do NSX mais específicas, em vez de usar rotas gerais de espaço de endereçamento para os segmentos de carga de trabalho do Solução VMware no Azure.

Integrações sem suporte

As seguintes integrações próprias e de terceiros não estão disponíveis:

• Dr. Zerto

Sub-redes delegadas e grupos de segurança de rede para Gen 2

Quando uma nuvem privada do Solução VMware no Azure (AVS) Gen 2 é implantada, Azure cria automaticamente várias sub-redes delegadas na rede virtual de host da nuvem privada. Essas sub-redes são usadas para isolar e proteger os componentes de gerenciamento da nuvem privada.

Os clientes podem gerenciar o acesso a essas sub-redes usando NSGs (Grupos de Segurança de Rede) visíveis no portal do Azure ou por meio do CLI do Azure/PowerShell. Além dos NSGs gerenciáveis pelo cliente, a AVS aplica NSGs extra gerenciados pelo sistema a interfaces de gerenciamento críticas. Esses NSGs gerenciados pelo sistema não são visíveis ou editáveis pelos clientes e existem para garantir que a nuvem privada permaneça segura por padrão.

Como parte da postura de segurança padrão:

• O acesso à Internet está desabilitado para a nuvem privada, a menos que o cliente o habilite explicitamente.
• Somente o tráfego de gerenciamento necessário tem permissão para acessar os serviços de plataforma.

Esse design mantém o ambiente da AVS seguro e separado por padrão, ao mesmo tempo em que permite que os clientes gerenciem e ajustem o acesso à rede para atender às suas necessidades.

Considerações sobre o roteamento e a sub-rede

As nuvens privadas Gen 2 do Solução VMware no Azure fornecem um ambiente de nuvem privada VMware acessível a usuários e aplicativos de ambientes ou recursos locais e baseados no Azure. A conectividade é fornecida por meio da rede de Azure padrão. Portas de firewall e intervalos de endereços de rede específicos são necessários para habilitar esses serviços. Esta seção ajuda você a configurar sua rede para trabalhar com Solução VMware no Azure.

A nuvem privada se conecta à sua rede virtual Azure usando a rede de Azure padrão. As nuvens privadas da Solução VMware no Azure Gen 2 necessitam de pelo menos /22 blocos de endereços de rede CIDR para sub-redes. Esta rede complementa as suas redes no local, pelo que o bloco de endereços não deve se sobrepor aos blocos de endereços utilizados em outras redes virtuais nas suas redes de assinatura e no local. As redes de gerenciamento, vMotion e replicação são provisionadas automaticamente nesse bloco de endereço como sub-redes em sua rede virtual.

Evite usar o seguinte esquema ip reservado para uso do VMware NSX:

• 169.254.0.0/24 – Usado para a rede de trânsito interna
• 169.254.2.0/23 – Usado para a rede de trânsito entre VRF
• 100.64.0.0/16 – Usado para conectar gateways T1 e T0 internamente
• 100.73.x.x – usado pela rede de gerenciamento da Microsoft

O exemplo /22 bloco de endereços de rede CIDR 10.31.0.0/22 é dividido nas seguintes sub-redes:

Programação de rotas do NSX na Rede Virtual do Azure

As rotas NSX Gen-2 do Solução VMware no Azure são integradas ao Azure por meio do uso do espaço de endereços e da atribuição dessas rotas como IPs secundários na sub-rede "avs-network-infra-gw", criada pelo sistema, permitindo conectividade contínua entre as cargas de trabalho dos clientes no Azure e no AVS. Quando o NSX Tier-0 anuncia uma rota com base nas configurações do usuário, como a criação de segmentos, a adição de rotas estáticas ou o uso de máquinas virtuais HCX MON, o plano de controle do Solução VMware no Azure verifica se o prefixo da rota existe no espaço de endereços da rede virtual. Caso contrário, ele criará o espaço de endereço e adicionará o prefixo de rota como IPs secundários na sub-rede "avs-network-infra-gw". Para rotas /32 anunciadas do Tier-0, como as rotas HCX MON, os IPs secundários não são configurados, mas o plano de dados é configurado internamente para garantir a conectividade com destinos /32 no Solução VMware no Azure.

Além da atualização do espaço de endereçamento e da sub-rede para as rotas NSX, há uma lógica interna da qual os clientes devem estar cientes, especialmente em relação à escala suportada quando são usadas máscaras de sub-rede menores. Para obter mais informações sobre o aspecto de escala, consulte Route architecture for Solução VMware no Azure Gen 2

Considerações sobre a associação da tabela de rotas do Azure (UDR)

Solução VMware no Azure Gen-2 inclui duas arquiteturas internas, com leve variação. Algumas das nuvens privadas gen-2 iniciais usam a arquitetura interna inicial. Eles são atualizados para a arquitetura atual por meio da manutenção agendada, coordenada com o cliente. No entanto, há uma alteração no comportamento com a arquitetura atual, em comparação com a arquitetura inicial, que pode afetar determinadas considerações de design de rede, conforme descrito abaixo.

Nuvens privadas Gen-2 iniciais:

• A VNET do Azure tem duas sub-redes de gateway básicas chamadas "avs-nsx-gw" e não possui a sub-rede "avs-network-infra-gw", como ocorre na arquitetura atual.
• Todas as sub-redes dos segmentos NSX do AVS são configuradas na sub-rede "avs-nsx-gw" como endereços IPv4 adicionais para conectar o Azure às cargas de trabalho do NSX.
• A tabela de rotas (UDR) ou o NSG do Azure para o tráfego do AVS para a VNet do Azure e além dela (por exemplo, no ambiente local/on-premises) deve ser aplicada à sub-rede "avs-nsx-gw".

Nuvens privadas gen-2 atuais:

Lembre-se de tomar nota dessa alteração no comportamento.

• A VNET do Azure teria uma sub-rede adicional com o prefixo "avs-network-infra-gw", além de duas sub-redes base de gateway denominadas "avs-nsx-gw", como na arquitetura inicial.
• Todas as sub-redes do segmento NSX da AVS agora são programadas nessa sub-rede como endereço IPv4 secundário para conectar Azure a cargas de trabalho NSX. Isso não altera a conectividade de rede do cliente.
• O emparelhamento de VNET anuncia tanto o espaço de endereços quanto as sub-redes para a VNET emparelhada, o que difere da arquitetura inicial ou da sincronização nativa de VNET do Azure, em que apenas o espaço de endereços é sincronizado.

Considerações de design devido a alterações na arquitetura interna do Gen-2

• Os clientes observam rotas efetivas adicionais para sub-redes AVS dentro da VNET emparelhada devido à alteração no comportamento de sincronização de pares da VNET.
• Se um cliente usa uma UDR (tabela de rotas) Azure para enviar tráfego do local para a AVS por meio de um firewall ou dispositivo virtual de rede, ele deve atualizar a UDR para usar rotas de sub-rede NSX específicas em vez do amplo intervalo de endereços de super-rede usado antes. Isso é necessário para impedir que o tráfego destinado ao AVS siga rotas de sub-rede de VNET mais específicas, ignorando o firewall desejado, devido ao comportamento de roteamento do Azure de correspondência do prefixo mais longo. Caso contrário, isso pode resultar em roteamento assimétrico, potencialmente causando problemas de conectividade.
• No entanto, a tabela de rotas (UDR) ou o NSG do Azure para o tráfego de AVS para a VNET do Azure e para além dela (por exemplo, no ambiente local) ainda seria aplicada às sub-redes "avs-nsx-gw", e não a "avs-network-infra-gw". Os clientes não devem usar a UDR (tabela de rotas) na sub-rede "avs-network-infra-gw", mesmo que as sub-redes do segmento NSX estejam configuradas lá como IPs secundários.

Próximas etapas

• Comece a configurar a entidade de serviço da Solução VMware no Azure como um pré-requisito. Para aprender como, consulte o guia de início rápido sobre Habilitação do principal de serviço do Solução VMware no Azure.

• Siga um tutorial para Criando uma nuvem privada Azure VMware Gen 2