Integrar a Solução VMware no Azure em uma arquitetura hub e spoke

  • Artigo

Este artigo fornece recomendações para integrar uma implantação da Solução VMware no Azure em uma arquitetura Hub e Spoke existente ou nova no Azure.

O cenário Hub e Spoke pressupõe um ambiente de nuvem híbrida com cargas de trabalho em:

  • Azure nativo usando serviços de IaaS ou PaaS
  • Solução VMware no Azure
  • vSphere local

Arquitetura

O Hub é uma Rede Virtual do Azure que atua como um ponto central de conectividade para a nuvem privada da Solução VMware no Azure e local. Os Spokes são redes virtuais em pares com o Hub para habilitar a comunicação entre redes virtuais.

O tráfego entre o datacenter local, a nuvem privada da Solução VMware no Azure e o Hub passa por conexões Azure ExpressRoute. As redes virtuais Spoke geralmente contêm cargas de trabalho baseadas em IaaS, mas podem ter serviços de PaaS como o Ambiente do Serviço de Aplicativo, que tem integração direta com a Rede Virtual ou outros serviços de PaaS com Link Privado do Azure habilitado.

Importante

Você pode usar um Gateway de ExpressRoute existente para se conectar à Solução VMware no Azure, desde que ela não exceda o limite de quatro circuitos de ExpressRoute por rede virtual. No entanto, para acessar a Solução VMware no Azure do local por meio do ExpressRoute, você precisa ter o Alcance Global do ExpressRoute, pois o gateway do ExpressRoute não fornece roteamento transitivo entre os circuitos conectados.

O diagrama mostra um exemplo de implantação de Hub e Spoke no Azure conectado à Solução VMware no Azure e local por meio do Alcance Global do ExpressRoute.

Diagrama mostrando a implantação da integração do Hub e Spoke da Solução VMware no Azure.

A arquitetura tem os seguintes componentes principais:

  • Site local: datacenters locais do cliente conectados ao Azure por meio de uma conexão do ExpressRoute.

  • Nuvem privada da Solução VMware no Azure: data center definido por software da Solução VMware no Azure formado por um ou mais clusters vSphere, cada um com no máximo 16 hosts.

  • Gateway do ExpressRoute: habilita a comunicação entre a nuvem privada da Solução VMware no Azure, os serviços compartilhados na rede virtual do Hub e as cargas de trabalho em execução em redes virtuais spoke por meio de uma conexão do ExpressRoute.

  • Alcance Global do ExpressRoute: habilita a conectividade entre a nuvem privada da Solução VMware no Azure e local. A conectividade entre o Solução VMware no Azure e a malha do Azure é somente por meio do Alcance Global do ExpressRoute.

  • Considerações sobre VPN S2S: há suporte para conectividade com a nuvem privada da solução VMware no Azure usando a VPN S2S do Azure, desde que atenda aos requisitos mínimos de rede do VMware HCX.

  • Rede virtual do Hub: atua como o ponto central de conectividade para sua rede local e a nuvem privada da Solução VMware no Azure.

  • Rede virtual spoke

    • Spoke de IaaS: hospeda cargas de trabalho baseadas em IaaS do Azure, incluindo conjuntos de disponibilidade de VM e Conjuntos de Dimensionamento de Máquinas Virtuais, bem como os componentes de rede correspondentes.

    • Spoke de PaaS: hospeda serviços de PaaS do Azure usando o endereçamento privado graças ao Ponto de extremidade privado e ao Link Privado.

  • Firewall do Azure: atua como a peça central para segmentar o tráfego entre os Spokes e a Solução VMware no Azure.

  • Gateway de Aplicativo: expõe e protege aplicativos Web que são executados no IaaS/PaaS do Azure ou em VMs (máquinas virtuais) da Solução VMware no Azure. Ele se integra a outros serviços como o Gerenciamento de API.

Considerações sobre rede e segurança

As conexões do ExpressRoute permitem que o tráfego flua entre o local, a Solução VMware no Azure e a malha de rede do Azure. A Solução VMware no Azure usa o Alcance Global do ExpressRoute para implementar essa conectividade.

Como um gateway de ExpressRoute não fornece roteamento transitivo entre seus circuitos conectados, a conectividade local também deve usar o Alcance Global do ExpressRoute para se comunicar entre o ambiente vSphere local e a Solução VMware no Azure.

  • Fluxo de tráfego do local para a Solução VMware no Azure

    Diagrama mostrando o fluxo de tráfego local para a Solução VMware no Azure.

  • Fluxo de tráfego da Solução VMware no Azure para a VNet do Hub

    Diagrama mostrando o fluxo de tráfego da Solução VMware no Azure para a rede virtual do Hub.

Para obter mais informações sobre conceitos de conectividade e rede da Solução VMware no Azure, consulte a documentação do produto da Solução VMware no Azure.

Segmentação de tráfego

O Firewall do Azure é a peça central da topologia Hub e Spoke, implantada na rede virtual do Hub. Use o Firewall do Azure ou outra NVA (solução de virtualização de rede) com suporte do Azure para estabelecer regras de tráfego e segmentar a comunicação entre os spokes diferentes e as cargas de trabalho da Solução VMware no Azure.

Crie tabelas de rotas para direcionar o tráfego para o Firewall do Azure. Para as redes virtuais Spoke, crie uma rota que defina a rota padrão para a interface interna do Firewall do Azure. Dessa forma, quando uma carga de trabalho na rede virtual precisar acessar o espaço de endereço da Solução VMware no Azure, o firewall poderá avaliá-la e aplicar a regra de tráfego correspondente para permiti-la ou negá-la.

Captura de tela mostrando as tabelas de rotas para direcionar o tráfego para o Firewall do Azure.

Importante

Não há suporte para uma rota com o prefixo de endereço 0.0.0.0/0 na configuração GatewaySubnet.

Defina rotas para redes específicas na tabela de rotas correspondente. Por exemplo, as rotas para alcançar os prefixos de IP de cargas de trabalho e gerenciamento da Solução VMware no Azure a partir das cargas de trabalho spoke e vice-versa.

Captura de tela que mostra as rotas definidas para redes específicas na tabela de rotas correspondente.

Um segundo nível de segmentação de tráfego usando os grupos de segurança de rede dentro dos Spokes e do Hub para criar uma política de tráfego mais granular.

Observação

Tráfego do local para a Solução VMware no Azure: o tráfego entre as cargas de trabalho locais, tanto com base em vSphere quanto em outros, é habilitado pelo Alcance Global, mas o tráfego não passa pelo Firewall do Azure no Hub. Nesse cenário, você deve implementar mecanismos de segmentação de tráfego, seja no local ou na Solução VMware no Azure.

Gateway de Aplicativo

O Gateway de Aplicativo do Azure V1 e v2 foram testados com aplicativos Web executados em VMs da Solução VMware no Azure como um pool de back-end. Atualmente, o Gateway de Aplicativo é o único método com suporte para expor aplicativos Web em execução em VMs da Solução VMware no Azure para a Internet. Ele também pode expor os aplicativos a usuários internos com segurança.

Para obter mais informações, consulte o artigo específico da Solução VMware no Azure no Gateway de Aplicativo.

Diagrama mostrando o segundo nível de segmentação de tráfego usando os Grupos de Segurança de Rede.

Jump box e Azure Bastion

Acesse o ambiente da Solução VMware no Azure com uma jump box, que é uma VM do Windows 10 ou do Windows Server implantada na sub-rede de serviço compartilhada na rede virtual do Hub.

Importante

O Azure Bastion é o serviço recomendado para se conectar à jump box para evitar a exposição da Solução VMware no Azure à Internet. Você não pode usar Azure Bastion para se conectar às VMs da Solução VMware no Azure, pois elas não são objetos IaaS do Azure.

Como uma melhor prática de segurança, implante o serviço Microsoft Azure Bastion na rede virtual do Hub. O Azure Bastion fornece acesso RDP e SSH contínuo a VMs implantadas no Azure sem fornecer endereços IP públicos para esses recursos. Depois de provisionar o serviço Azure Bastion, você poderá acessar a VM selecionada no portal do Azure. Após o estabelecimento da conexão, uma nova guia é aberta, mostrando a área de trabalho da jump box e, nessa área de trabalho, você pode acessar o plano de gerenciamento de nuvem privada da Solução VMware no Azure.

Importante

Não dê um endereço IP público à VM da jump box ou exponha a porta 3389/TCP à Internet pública.

Diagrama mostrando a rede virtual do hub do Azure Bastion.

Considerações sobre a resolução de DNS do Azure

Para a resolução DNS do Azure, há duas opções disponíveis:

  • Use os controladores de domínio implantados no Hub (descritos em Considerações de identidade) como servidores de nome.

  • Implante e configure uma zona privada do DNS do Azure.

A melhor abordagem é combinar ambos para fornecer resolução de nomes confiável para a Solução VMware no Azure, o local e o Azure.

Recomendação geral de design: use o DNS integrado ao Active Directory existente implantado em pelo menos duas VMs do Azure na rede virtual do Hub e configurado nas redes virtuais spoke para usar esses servidores DNS do Azure nas configurações de DNS.

Você pode usar o DNS privado do Azure, em que a zona do DNS privado do Azure é vinculada à rede virtual. Os servidores DNS são usados como resolvedores híbridos com encaminhamento condicional para a Solução VMware no Azure ou o local executando o DNS com o uso da infraestrutura de DNS privado do Azure do cliente.

Para gerenciar automaticamente o ciclo de vida dos registros DNS para as VMs implantadas nas redes virtuais Spoke, habilite o registro automático. Quando habilitado, o número máximo de zonas DNS privadas é apenas um. Se desabilitado, o número máximo será 1000.

Os servidores da Solução VMware no Azure e do local podem ser configurados com encaminhadores condicionais para resolver VMs no Azure para a zona de DNS privado do Azure.

Considerações sobre identidade

Para fins de identidade, a melhor abordagem é implantar pelo menos um controlador de domínio no Hub. Use duas sub-redes de serviço compartilhado no modo distribuído por zona ou um conjunto de disponibilidade de VM. Para obter mais informações sobre como estender seu domínio local Active Directory (AD) para o Azure, consulte Centro de Arquitetura do Azure.

Além disso, implante outro controlador de domínio no lado da Solução VMware no Azure para atuar como identidade e origem do DNS no ambiente vSphere.

Como melhor prática, integre o domínio do AD ao Microsoft Entra ID.