Considerações de design para Solução VMware no Azure Generation 2 Private Clouds

Este artigo descreve as principais considerações de design para as nuvens privadas da Solução VMware no Azure Geração 2 (Gen 2). Explica as capacidades que esta geração traz para ambientes de cloud privada baseados em VMware, permitindo o acesso das suas aplicações tanto a partir da infraestrutura local como dos recursos baseados no Azure. Há várias considerações a considerar antes de configurar a sua cloud 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 período. Estas limitações serão levantadas no futuro:

• Não podes eliminar o teu Grupo de Recursos, que contém a tua nuvem privada. Você deve excluir a nuvem privada primeiro antes de excluir o grupo de recursos.
• Só podes implementar 1 cloud privada por Azure rede virtual.
• Você só pode criar 1 nuvem privada por Grupo de Recursos. Múltiplas clouds privadas num único Grupo de Recursos não são suportadas.
• Sua nuvem privada e rede virtual para sua nuvem privada devem estar no mesmo Grupo de Recursos.
• Não pode mover a sua nuvem privada de um grupo de recursos para outro depois de a nuvem privada ser criada.
• Não pode mover a sua nuvem privada de um inquilino para outro depois de a nuvem privada ser criada.
• Se precisar de ExpressRoute FastPath ou Global Rede Virtual Peering para a sua AVS Private Cloud, crie um Caso de Suporte através do portal Azure.
• Endpoints de Serviço não suportam a conectividade direta das cargas de trabalho do Solução VMware no Azure.
• Endpoints Privados quando interligados globalmente entre regiões ligadas à solução Azure VMware não é suportado.
• vCloud Director usando Pontos de Extremidade Privados é suportado. No entanto, o vCloud Director utilizando endereços públicos não é suportado.
• Não há suporte para vSAN Stretched Clusters.
• IP público até ao VMware NSX Microsoft Edge para configurar internet não é suportado. Você pode encontrar quais opções de internet são suportadas em Opções de conectividade com a Internet.
• Durante uma manutenção não planeada – como uma falha no hardware do host – em qualquer um dos primeiros quatro hosts do seu Centro de Dados Definidos por Software (SDDC), pode experienciar uma interrupção temporária North-South da conectividade da rede em algumas cargas de trabalho, podendo durar até 30 segundos. Conectividade Norte-Sul refere-se ao tráfego entre as suas cargas de trabalho AVS VMware e pontos de extremidade externos para além do Edge NSX-T Tier-0 (T0), como serviços Azure ou ambientes no local. Esta limitação foi removida em regiões específicas do Azure. Confirme se a sua região é afetada por esta limitação consultando o Suporte do Azure.  
• 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.
• As referências entre grupos de recursos e entre subscrições das redes virtuais do cliente para a rede virtual do Solução VMware no Azure não são suportadas por predefiniçã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 de cliente estiver associada a uma destas referências que reside num grupo de recursos ou subscrição diferente da rede virtual Solução VMware no Azure, a programação de rede (como a propagação de segmentos NSX) pode falhar. Para evitar problemas, os clientes devem garantir que a rede virtual do Solução VMware no Azure não está ligada a recursos noutro grupo de recursos ou subscrição. Antes de continuar, remova quaisquer dessas ligações, como os Planos de Proteção DDoS, da rede virtual.
  • Para manter a sua referência entre grupos de recursos, crie uma atribuição de função no seu grupo de recursos entre recursos ou na subscrição e atribua à "AzS VIS Prod App" a função "AVS on Fleet VIS Role". A atribuição de função permite-lhe utilizar a referência e fazer com que esta seja corretamente aplicada à sua nuvem privada do Solução VMware no Azure.
• As implementações de cloud privada da Geração 2 podem falhar se as políticas de Azure aplicarem regras rigorosas para Grupos de Segurança de Rede ou tabelas de roteamento (por exemplo, convenções específicas de nomenclatura). Estas restrições de políticas podem bloquear a criação obrigatória do Solução VMware no Azure Network Security Group e a criação de tabelas de roteamento durante a implementação. Deve remover estas políticas da rede virtual do Solução VMware no Azure antes de implementar a sua nuvem privada. Assim que a sua nuvem privada está implementada, estas políticas podem ser adicionadas novamente à sua nuvem privada Solução VMware no Azure.
• Se estiveres a usar DNS Privado para a tua cloud privada de Solução VMware no Azure geração 2, usar Custom DNS na rede virtual onde está implantada uma nuvem privada de Solução VMware no Azure geração 2 não é suportado. O DNS personalizado interrompe as operações do ciclo de vida, como dimensionamento, atualizações e aplicação de patches.
• Se estiveres a eliminar a tua cloud privada e alguns dos recursos criados pelo Solução VMware no Azure não forem removidos, podes tentar eliminar novamente a cloud privada do Solução VMware no Azure com a CLI do Azure.
• O Solução VMware no Azure Gen 2 utiliza um Proxy HTTP para distinguir entre tráfego de cliente e tráfego de rede de gestão. Alguns endpoints do 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. Exemplos incluem: "scapi.vmware" e "apigw.vmware." O proxy VAMI governa o acesso geral à internet de saída do vCenter Server Appliance (VCSA), mas nem todas as interações com endpoints de serviço fluem através deste proxy. Algumas interações originam-se 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 os endpoints do serviço de nuvem VMware pode ignorar totalmente o proxy VCSA.
• As migrações RAV e Bulk do HCX de 2.ª geração podem apresentar um desempenho mais lento devido a interrupções durante as fases de Base Sync e de Online Sync. Os clientes devem planear janelas de migração mais longas e agendar fases em conformidade, por enquanto. Para cargas de trabalho adequadas, o vMotion oferece uma opção mais rápida e de baixo overhead quando as condições do host e da rede o permitem.
• Emparelhamento do hub virtual (WAN virtual): Para estabelecer uma ligação de emparelhamento entre uma rede virtual Gen-2 e um hub virtual (WAN virtual), o hub virtual tem de estar na mesma região que a rede virtual Gen-2. Se precisar de estabelecer emparelhamento com um hub virtual numa região diferente, tem de criar um pedido de suporte através do portal do Azure.
• /32 destino da rota a partir de uma Rede Virtual (VNET) emparelhada: Se estiver a anunciar rotas /32 a partir do NSX (como rotas HCX MON ou rotas do reencaminhador de DNS) e precisar de aceder a esse destino /32 a partir de uma rede virtual emparelhada, terá de abrir um pedido de suporte no portal do Azure. A ligação ao destino /32 funciona corretamente a partir da VNET local.
• Anúncio da sub-rede Peer Sync e associação à Tabela de Rotas do Azure (UDR) – A Solução VMware no Azure Gen 2 utiliza duas arquiteturas internas. A arquitetura atual sincroniza tanto sub-redes específicas como o espaço de endereçamento mais alargado do Azure para rotas de segmentos ou sub-redes do NSX com redes virtuais do Azure em emparelhamento. Como resultado, com a arquitetura atual da Gen 2, poderá ser necessário configurar tabelas de rotas do Azure (UDR) com rotas de sub-redes de segmentos NSX mais específicas, em vez de usar rotas gerais de espaço de endereçamento para segmentos de carga de trabalho do Solução VMware no Azure.

Integrações sem suporte

As seguintes integrações de 1ª e 3ª parte não estão disponíveis:

• Zerto DR

Sub-redes delegadas e grupos de segurança de rede para a geração 2

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

Os clientes podem gerir o acesso a estas sub-redes através dos Grupos de Segurança de Rede (NSGs) que são visíveis no portal Azure ou através do CLI do Azure/PowerShell. Para além dos NSGs geríveis pelo cliente, o AVS aplica NSGs geridos por sistema adicionais a interfaces de gestão críticas. Estes NSGs geridos pelo sistema não são visíveis nem editáveis pelos clientes e existem para garantir que a nuvem privada se mantenha segura por defeito.

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

• O acesso à Internet está desativado para a nuvem privada, a menos que o cliente a habilite explicitamente.
• Apenas o tráfego de gerenciamento necessário é permitido para acessar os serviços da plataforma.

Esta conceção mantém o ambiente AVS seguro e separado por predefinição, permitindo ainda assim que os clientes gerirem e ajustem o acesso à rede de acordo com as suas necessidades.

Considerações sobre roteamento e sub-rede

As nuvens privadas Solução VMware no Azure Gen 2 fornecem um ambiente de cloud privada VMware acessível a utilizadores e aplicações a partir de ambientes ou recursos on-premises e baseados em Azure. A conectividade é assegurada através do Azure Networking padrão. Intervalos de endereços de rede específicos e portas de firewall são necessários para habilitar esses serviços. Esta secção ajuda-o a configurar a sua rede para funcionar com o Solução VMware no Azure.

A cloud privada liga-se à sua rede virtual Azure usando a rede Azure padrão. As clouds privadas do Solução VMware no Azure Gen 2 exigem um bloco de endereçamento de rede CIDR /22 mínimo para sub-redes. Essa rede complementa suas redes locais, portanto, o bloco de endereço não deve se sobrepor aos blocos de endereços usados em outras redes virtuais em sua assinatura e redes locais. As redes de gerenciamento, vMotion e replicação são provisionadas automaticamente dentro desse bloco de endereços como sub-redes dentro de sua rede virtual.

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

• 169.254.0.0/24 - utilizados para a rede de trânsito interno
• 169.254.2.0/23 - utilizado para a rede de trânsito inter-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

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

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

As rotas NSX Gen-2 do Solução VMware no Azure são integradas no Azure através da utilização do espaço de endereços e da sua atribuição como IPs secundários na sub-rede "avs-network-infra-gw", criada pelo sistema, permitindo uma conectividade contínua entre o Azure e as cargas de trabalho dos clientes do AVS. Quando o NSX Tier-0 anuncia uma rota com base nas definições do utilizador — como criar segmentos, adicionar rotas estáticas ou usar máquinas virtuais HCX MON — o plano de controlo do Solução VMware no Azure verifica se o prefixo de rota existe no espaço de endereçamento da rede virtual. Caso isso não aconteça, cria o espaço de endereçamento e adiciona o prefixo da rota como endereços IP secundários na sub-rede "avs-network-infra-gw". Para as rotas /32 anunciadas no 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 a destinos com /32 no Solução VMware no Azure.

A par da atualização do espaço de endereçamento e das sub-redes para as rotas NSX, há lógica interna de que os clientes devem estar cientes, especialmente no que diz respeito aos limites de escala suportados quando são utilizadas máscaras de sub-rede mais baixas. Para mais informações sobre o aspeto de escalabilidade, consulte Arquitetura de encaminhamento para o Solução VMware no Azure Gen 2

Considerações sobre a associação da Azure Route Table (UDR)

O Solução VMware no Azure Gen-2 inclui duas arquiteturas internas, com ligeiras variações. Algumas das nuvens privadas iniciais Gen-2 utilizam a arquitetura interna inicial. Estes são atualizados para a arquitetura atual através de manutenção programada, coordenada com o cliente. No entanto, há alterações no comportamento da arquitetura atual, em comparação com a arquitetura inicial, que podem afetar certas considerações de design de rede, conforme descrito abaixo.

Nuvens privadas iniciais de 2ª geração:

• O Azure VNET tem duas subredes base de gateway chamadas "avs-nsx-gw" e não tem a sub-rede "avs-network-infra-gw" como na arquitetura atual.
• Todas as sub-redes de segmento do AVS NSX são configuradas na sub-rede "avs-nsx-gw" como endereços IPv4 adicionais para ligar o Azure às cargas de trabalho no NSX.
• A tabela de roteamento (UDR) ou o Azure NSG para tráfego do AVS para o Azure VNET e além (por exemplo, on-premises) precisam de ser aplicados à sub-rede "avs-nsx-gw".

Cloud privada atual de segunda geração:

Certifica-te de que prestas atenção a esta mudança de comportamento.

• O Azure VNET teria sub-redes adicionais com prefixo "avs-network-infra-gw" juntamente com duas sub-redes base de gateway com o nome "avs-nsx-gw", tal como na arquitetura inicial.
• Todas as sub-redes de segmentos NSX do AVS estão agora programadas sob esta sub-rede como endereço IPv4 secundário para ligar o Azure às cargas de trabalho NSX. Isto não altera a conectividade da rede dos clientes.
• O peering VNET anuncia tanto o espaço de endereçamento como as sub-redes para a VNET peered, o que difere da arquitetura inicial ou da sincronização nativa VNET do Azure, onde apenas o espaço de endereçamento está sincronizado.

Considerações de Design devido a alterações na arquitetura interna da Gen-2

• Os clientes observam rotas efetivas adicionais para as sub-redes do AVS na VNET emparelhada devido a uma alteração no comportamento de sincronização do emparelhamento da VNET.
• Se um cliente usar uma tabela de rotas do Azure (UDR) para enviar tráfego do local para o AVS através de um firewall ou dispositivo virtual de rede, deve atualizar o UDR para usar rotas específicas de sub-redes NSX em vez do amplo intervalo de endereços de supernet usado anteriormente. Isto é necessário para impedir que o tráfego destinado ao AVS tome rotas de sub-redes VNET mais específicas, contornando o firewall pretendido, devido ao comportamento mais longo da correspondência de prefixos do encaminhamento Azure. Caso contrário, isto pode resultar em encaminhamento assimétrico, podendo causar problemas de conectividade.
• No entanto, a tabela de rotas (UDR) ou o NSG do Azure para o tráfego do AVS para a VNET do Azure e mais além (por exemplo, para o ambiente no local) continuaria a ser aplicada às sub-redes "avs-nsx-gw", e não às "avs-network-infra-gw." Os clientes não devem usar a tabela de rotas (UDR) na sub-rede "avs-network-infra-gw", mesmo que as subredes de segmentos NSX estejam configuradas como IPs secundários.

Próximos passos

• Comece a configurar o seu principal de serviço Solução VMware no Azure como pré-requisito. Para saber como, consulte o quickstart Enabling Solução VMware no Azure service principal.

• Siga um tutorial para Criação de uma Azure VMware Gen 2 Private Cloud