Considerações sobre design de rede para a Solução VMware no Azure
A Solução VMware no Azure oferece um ambiente de nuvem privada VMware que usuários e aplicativos podem acessar a partir de ambientes ou recursos locais e baseados no Azure. Serviços de rede como o Azure ExpressRoute e conexões VPN (rede virtual privada) fornecem a conectividade.
Há várias considerações sobre rede a analisar antes de configurar seu ambiente para a Solução VMware no Azure. Este artigo fornece soluções para casos de uso que você pode encontrar ao usar a Solução VMware no Azure para configurar suas redes.
Compatibilidade da Solução VMware no Azure com a Prefixação do caminho AS
A Solução VMware no Azure possui considerações relacionadas ao uso do AS-Path Prepend nas configurações redundantes do ExpressRoute. Se você estiver executando dois ou mais caminhos do ExpressRoute entre o local e o Azure, considere as seguintes orientações para influenciar o tráfego da Solução VMware no Azure em direção ao seu endereço no local pelo ExpressRoute GlobalReach.
Devido ao roteamento assimétrico, podem ocorrer problemas de conectividade quando a Solução VMware no Azure não observa o AS-Path Prepend e, portanto, usa o roteamento de múltiplos caminhos de custo igual (ECMP) para enviar o tráfego em direção ao seu ambiente pelos dois circuitos ExpressRoute. Esse comportamento pode causar problemas com dispositivos de inspeção de firewall com estado colocados atrás dos circuitos existentes do ExpressRoute.
Pré-requisitos
Quanto ao Prepend as-Path, considere os seguintes pré-requisitos:
- O ponto chave é que você deve acrescentar os números de ASN Públicos para influenciar como a Solução VMware no Azure roteia o tráfego de volta para o local. Se você anexar o uso ASN Privado, a Solução VMware no Azure ignorará o anexo e ocorrerá o comportamento do ECMP mencionado anteriormente. Mesmo que você opere um ASN BGP Privado localmente, ainda é possível configurar seus dispositivos locais para usar um ASN Público ao preparar as rotas de saída para garantir a compatibilidade com a Solução VMware no Azure.
- Crie seu caminho de tráfego nos ASNs Privados após o ASN Público ser honrado pela Solução VMware no Azure. O circuito do ExpressRoute da Solução VMware no Azure não remove as ASNs privadas que existem no caminho depois que o ASN público é processado.
- Ambos ou todos os circuitos estão conectados à Solução VMware no Azure através do Alcance Global do ExpressRoute.
- Os mesmos netblocks estão sendo anunciados de dois ou mais circuitos.
- Você quer usar o Prepend AS-Path para forçar a solução VMware do Azure a preferir um circuito em vez de outro.
- Use os números ASN públicos de 2 bytes ou 4 bytes.
VMs de gerenciamento e rotas padrão do local
Importante
As máquinas virtuais (VMs) de gerenciamento da Solução VMware no Azure não respeitarão uma rota padrão do local para os destinos RFC1918.
Se você estiver roteando de volta para suas redes locais usando apenas uma rota padrão anunciada para o Azure, o tráfego das VMs do vCenter Server e do NSX Manager que estão sendo usadas nos destinos locais com endereços de IP privados não seguirá essa rota.
Para acessar o vCenter Server e o NSX Manager localmente, forneça rotas específicas para permitir que o tráfego tenha um caminho de retorno nessas redes. Por exemplo, anuncie os resumos RFC1918 (10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16).
Rota padrão para a Solução VMware no Azure para inspeção de tráfego da internet
Determinadas implantações exigem a inspeção de todo o tráfego de saída da Solução VMware no Azure em direção à internet. Ainda que seja possível criar as NVAs (Soluções de Virtualização de Rede) na Solução VMware no Azure, há casos de uso em que esses dispositivos que já existem no Azure podem ser aplicados para inspecionar o tráfego da internet da Solução VMware no Azure. Nesse caso, uma rota padrão pode ser injetada a partir da NVA no Azure para atrair o tráfego da Solução VMware no Azure e inspecioná-lo antes de enviá-lo para a internet pública.
O diagrama a seguir descreve uma topologia básica de hub e spoke conectada a uma nuvem da Solução VMware no Azure e a uma rede local por meio do ExpressRoute. O diagrama mostra como a NVA no Azure origina a rota padrão (0.0.0.0/0). O Servidor de Rota do Azure propaga a rota para a Solução VMware no Azure por meio do ExpressRoute.
Importante
A rota padrão anunciada pela NVA será propagada para a rede local. Você precisa adicionar UDRs (rotas definidas pelo usuário) para garantir que o tráfego da Solução VMware no Azure esteja transitando pela NVA.
A comunicação entre a Solução VMware no Azure e a rede local normalmente ocorre no Alcance Global do ExpressRoute, conforme descrito em Emparelhar ambientes locais à Solução VMware no Azure.
Conectividade entre a Solução VMware no Azure e uma rede local
Há dois cenários principais para conectividade entre a Solução VMware no Azure e uma rede local por meio de uma NVA de terceiros:
- As organizações têm um requisito para enviar tráfego entre a Solução VMware no Azure e a rede local por meio de uma NVA (normalmente um firewall).
- O Alcance Global do ExpressRoute não está disponível em uma região específica para interconectar os circuitos do ExpressRoute da Solução VMware no Azure e da rede local.
Há duas topologias que você pode aplicar para atender a todos os requisitos para esses cenários: super-rede e rede virtual de spoke de trânsito.
Importante
A opção preferencial para se conectar à Solução VMware no Azure e ambientes locais é uma conexão direta do Alcance Global do ExpressRoute. Os padrões descritos neste artigo adicionam complexidade ao ambiente.
Topologia de design de super-rede
Se ambos os circuitos do ExpressRoute (para a Solução VMware no Azure e para o local) forem encerrados no mesmo gateway do ExpressRoute, você poderá considerar que o gateway roteará pacotes entre eles. No entanto, um gateway de ExpressRoute não foi projetado para isso. É necessário direcionar o tráfego para uma NVA que possa roteá-lo.
Há dois requisitos para direcionar o tráfego de rede para uma NVA:
O NVA deve anunciar uma super-rede para prefixos da Solução VMware no Azure e prefixos locais.
Você pode usar uma super-rede que inclui prefixos da Solução VMware no Azure e prefixos locais. Ou você pode usar prefixos individuais para a Solução VMware no Azure e prefixos locais (sempre menos específicos que os prefixos reais anunciados no ExpressRoute). Tenha em mente que todos os prefixos de super-rede anunciados para o Servidor de Rota são propagados para a Solução VMware no Azure e no local.
As UDRs na sub-rede de gateway, que correspondem exatamente aos prefixos anunciados da Solução VMware no Azure e no local, causam o tráfego de cabeamento da sub-rede do gateway na NVA.
Essa topologia resulta em alta sobrecarga de gerenciamento para redes grandes que mudam ao longo do tempo. Considere estas limitações:
- Sempre que um segmento de carga de trabalho é criado na Solução VMware no Azure, as UDRs podem precisar ser adicionadas para garantir que o tráfego da Solução VMware no Azure esteja transitando pela NVA.
- Se o ambiente local tiver um grande número de rotas que mudam, a configuração de BGP (Border Gateway Protocol) e de UDR na super-rede pode precisar ser atualizada.
- Como um único gateway do ExpressRoute processa o tráfego de rede em ambas as direções, o desempenho pode ser limitado.
- Há um limite de Rede Virtual do Azure de 400 UDRs.
O diagrama a seguir demonstra como a NVA precisa anunciar prefixos mais genéricos (menos específicos) e que incluem as redes locais e da Solução VMware no Azure. Tenha cuidado com essa abordagem. A NVA pode atrair tráfego que não deveria, já que está anunciando intervalos mais amplos (por exemplo, toda a rede 10.0.0.0/8).
Topologia de rede virtual spoke de trânsito
Observação
Se não for possível anunciar prefixos menos específicos devido aos limites descritos anteriormente, você poderá implementar um design alternativo que usa duas redes virtuais separadas.
Nesta topologia, em vez de propagar rotas menos específicas para atrair tráfego para o gateway do ExpressRoute, duas NVAs diferentes em Redes Virtuais separadas podem trocar rotas entre si. As redes virtuais podem propagar essas rotas para seus respectivos circuitos do ExpressRoute por meio do BGP e do Servidor de Rota do Azure. Cada NVA tem controle total sobre os prefixos que são propagados para cada circuito do ExpressRoute.
O diagrama a seguir demonstra como uma única rota 0.0.0.0/0 é anunciada para a Solução VMware no Azure. Ele também mostra como os prefixos de Solução VMware no Azure individuais são propagados para a rede local.
Importante
Um protocolo de encapsulamento, como VXLAN ou IPsec, é necessário entre as NVAs. O encapsulamento é necessário porque os NICs (adaptadores de rede) da NVA aprenderiam as rotas do Servidor de Rota do Azure com a NVA como próximo salto e criariam um loop de roteamento.
Há uma alternativa ao uso de uma sobreposição. Aplique NICs secundárias na NVA que não aprendem as rotas do Servidor de Rota do Azure. Em seguida, configure os UDRs para que o Azure possa rotear o tráfego para o ambiente remoto por meio desses NICs. Você encontra mais detalhes em Conectividade e topologia de rede de escala empresarial para Solução VMware no Azure.
Essa topologia requer uma configuração inicial complexa. Em seguida, a topologia funciona conforme o esperado com sobrecarga mínima de gerenciamento. As complexidades da configuração incluem:
- Há um custo extra para adicionar outra rede virtual de trânsito que inclui o Servidor de Rota do Azure, um gateway do ExpressRoute e outra NVA. As NVAs também podem precisar usar tamanhos grandes de VM para atender aos requisitos de taxa de transferência.
- Túnel IPSec ou VxLAN é necessário entre os duas NVAs, o que significa que as NVAs também estão no caminho de dados. Dependendo do tipo de NVA que você está usando, isso pode resultar em configuração personalizada e complexa nessas NVAs.
Próximas etapas
Depois de saber mais sobre as considerações de design de rede para a Solução VMware no Azure, considere explorar os seguintes artigos: