Considerações sobre o design de rede da Solução VMware do Azure
A Solução VMware do Azure oferece um ambiente de nuvem privada VMware que os 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 de rede virtual privada (VPN), fornecem a conectividade.
Há várias considerações de rede a serem analisadas antes de configurar seu ambiente de solução VMware do Azure. Este artigo fornece soluções para casos de uso que você pode encontrar ao usar a Solução VMware do Azure para configurar suas redes.
Compatibilidade da solução VMware do Azure com AS-Path Prepend
A Solução VMware do Azure tem considerações relacionadas ao uso do AS-Path Prepend para configurações redundantes de Rota Expressa. Se você estiver executando dois ou mais caminhos de Rota Expressa entre o local e o Azure, considere as seguintes orientações para influenciar o tráfego da Solução VMware do Azure para seu local local por meio do ExpressRoute GlobalReach.
Devido ao roteamento assimétrico, problemas de conectividade podem ocorrer quando o Azure VMware Solution não observa o AS-Path Prepend e, portanto, usa o roteamento ECMP (equal-cost multipath) para enviar tráfego para seu ambiente em ambos os circuitos de Rota Expressa. Esse comportamento pode causar problemas com dispositivos de inspeção de firewall com monitoração de estado colocados atrás de circuitos de Rota Expressa existentes.
Pré-requisitos
Para AS-Path Prepend, considere os seguintes pré-requisitos:
- O ponto-chave é que você deve preceder os números ASN públicos para influenciar como a Solução VMware do Azure roteia o tráfego de volta para o local. Se você anexar o uso do ASN privado , a Solução VMware do Azure ignorará a suspensão e o comportamento ECMP mencionado anteriormente ocorrerá. Mesmo que você opere um ASN BGP privado local, ainda é possível configurar seus dispositivos locais para utilizar um ASN público quando rotas de saída pendentes, para garantir a compatibilidade com a Solução VMware do Azure.
- Projete seu caminho de tráfego para ASNs privados após o ASN público para ser honrado pela Solução VMware do Azure. O circuito VMware Solution ExpressRoute do Azure não remove nenhum ASNs privado que existam no caminho depois que o ASN público é processado.
- Ambos ou todos os circuitos estão conectados à Solução VMware do Azure por meio do Azure ExpressRoute Global Reach.
- Os mesmos netblocks estão sendo anunciados a partir de dois ou mais circuitos.
- Você deseja usar o AS-Path Prepend para forçar a solução VMware do Azure a preferir um circuito em detrimento de outro.
- Use números ASN públicos de 2 ou 4 bytes.
VMs de gerenciamento e rotas padrão do local
Importante
As máquinas virtuais (VMs) de gerenciamento de soluções VMware do Azure não respeitarão uma rota padrão do local para 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 de VMs do vCenter Server e do NSX Manager que estão sendo usadas para destinos locais com endereços 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 para essas 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 do Azure para inspeção de tráfego na Internet
Determinadas implantações exigem a inspeção de todo o tráfego de saída da Solução VMware do Azure para a Internet. Embora seja possível criar dispositivos virtuais de rede (NVAs) na Solução VMware do Azure, há casos de uso em que esses dispositivos já existem no Azure e podem ser aplicados para inspecionar o tráfego da Internet da Solução VMware do Azure. Nesse caso, uma rota padrão pode ser injetada a partir do NVA no Azure para atrair tráfego da Solução VMware do Azure e inspecionar o tráfego antes que ele saia para a Internet pública.
O diagrama a seguir descreve uma topologia básica de hub-and-spoke conectada a uma nuvem da Solução VMware do Azure e a uma rede local por meio da Rota Expressa. O diagrama mostra como o NVA no Azure origina a rota padrão (0.0.0.0/0). O Azure Route Server propaga a rota para a Solução VMware do Azure por meio da Rota Expressa.
Importante
A rota padrão que o NVA anuncia será propagada para a rede local. Você precisa adicionar rotas definidas pelo usuário (UDRs) para garantir que o tráfego da Solução VMware do Azure esteja transitando pelo NVA.
A comunicação entre a Solução VMware do Azure e a rede local geralmente ocorre por meio do Alcance Global da Rota Expressa, conforme descrito em Ambientes locais pares à Solução VMware do Azure.
Conectividade entre a solução VMware do Azure e uma rede local
Há dois cenários principais para a conectividade entre a Solução VMware do Azure e uma rede local por meio de um NVA de terceiros:
- As organizações têm um requisito para enviar tráfego entre a Solução VMware do Azure e a rede local por meio de um NVA (normalmente um firewall).
- O ExpressRoute Global Reach não está disponível em uma região específica para interconectar os circuitos ExpressRoute da Solução VMware do Azure e a rede local.
Há duas topologias que você pode aplicar para atender a todos os requisitos para esses cenários: supernet e rede virtual de trânsito falado.
Importante
A opção preferida para conectar a Solução VMware do Azure e ambientes locais é uma conexão direta do ExpressRoute Global Reach. Os padrões descritos neste artigo adicionam complexidade ao ambiente.
Topologia de design de super-rede
Se ambos os circuitos de Rota Expressa (para a Solução VMware do Azure e para o local) forem encerrados no mesmo gateway de Rota Expressa, você poderá presumir que o gateway encaminhará pacotes entre eles. No entanto, um gateway de Rota Expressa não foi projetado para fazer isso. Você precisa direcionar o tráfego para um NVA que possa rotear o tráfego.
Há dois requisitos para fixar o tráfego de rede em um NVA:
O NVA deve anunciar uma super-rede para a Solução VMware do Azure e prefixos locais.
Você pode usar uma super-rede que inclua a Solução VMware do Azure e prefixos locais. Ou você pode usar prefixos individuais para a Solução VMware do Azure e no local (sempre menos específicos do que os prefixos reais anunciados pela Rota Expressa). Lembre-se de que todos os prefixos de super-rede anunciados no Route Server são propagados para a Solução VMware do Azure e localmente.
UDRs na sub-rede do gateway, que correspondem exatamente aos prefixos anunciados da Solução VMware do Azure e no local, causam tráfego de hairpin da sub-rede do gateway para o NVA.
Essa topologia resulta em alta sobrecarga de gerenciamento para grandes redes que mudam ao longo do tempo. Considere estas limitações:
- Sempre que um segmento de carga de trabalho é criado na Solução VMware do Azure, talvez seja necessário adicionar UDRs para garantir que o tráfego da Solução VMware do Azure esteja transitando pelo NVA.
- Se o seu ambiente local tiver um grande número de rotas que mudam, o protocolo BGP (Border Gateway Protocol) e a configuração UDR na super-rede talvez precisem ser atualizados.
- Como um único gateway de Rota Expressa 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 o NVA precisa anunciar prefixos que são mais genéricos (menos específicos) e que incluem as redes locais e a Solução VMware do Azure. Tenha cuidado com esta abordagem. O NVA poderia potencialmente atrair tráfego que não deveria, porque está anunciando intervalos mais amplos (por exemplo, toda 10.0.0.0/8 a rede).
Topologia de rede virtual Transit spoke
Nota
Se prefixos de publicidade menos específicos não forem possíveis devido aos limites descritos anteriormente, você poderá implementar um design alternativo que use duas redes virtuais separadas.
Nessa topologia, em vez de propagar rotas menos específicas para atrair tráfego para o gateway da Rota Expressa, dois NVAs diferentes em redes virtuais separadas podem trocar rotas entre si. As redes virtuais podem propagar essas rotas para seus respetivos circuitos de Rota Expressa via BGP e Azure Route Server. Cada NVA tem controle total sobre quais prefixos são propagados para cada circuito de Rota Expressa.
O diagrama a seguir demonstra como uma única 0.0.0.0/0 rota é anunciada para a Solução VMware do Azure. Ele também mostra como os prefixos individuais da Solução VMware do Azure são propagados para a rede local.
Importante
Um protocolo de encapsulamento como VXLAN ou IPsec é necessário entre os NVAs. O encapsulamento é necessário porque o adaptador de rede NVA (NIC) aprenderia as rotas do Servidor de Rotas do Azure com o NVA como o próximo salto e criaria um loop de roteamento.
Há uma alternativa ao uso de uma sobreposição. Aplique NICs secundárias no NVA que não aprendem as rotas do Servidor de Rotas do Azure. Em seguida, configure UDRs para que o Azure possa rotear o tráfego para o ambiente remoto nessas NICs. Você pode encontrar mais detalhes em Topologia de rede de escala empresarial e conectividade para a Solução VMware do Azure.
Essa topologia requer uma configuração inicial complexa. Em seguida, a topologia funciona conforme o esperado com uma sobrecarga de gerenciamento mínima. As complexidades de 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 de Rota Expressa e outro NVA. Os NVAs também podem precisar usar grandes tamanhos de VM para atender aos requisitos de taxa de transferência.
- O túnel IPsec ou VXLAN é necessário entre os dois NVAs, o que significa que os NVAs também estão no caminho de dados. Dependendo do tipo de NVA que você está usando, isso pode resultar em configurações personalizadas e complexas nesses NVAs.
Próximos passos
Depois de aprender sobre as considerações de design de rede para a Solução VMware do Azure, considere explorar os seguintes artigos: