Diretrizes do HCX MON (Mobility Optimized Networking) da VMware
Observação
O VMware HCX Mobility Optimized Networking é oficialmente compatível com o VMware e o Azure VMware Solution do HCX versão 4.1.0.
Importante
Antes de habilitar o HCX MON, leia as limitações e configurações sem suporte abaixo:
Configurações de origem sem suporte para o HCX NE
Limitações para qualquer implantação do HCX, incluindo o MON
O VMware HCX Mobility Optimized Networking (MON) não é compatível com o uso de um gateway de terceiros. Ele só pode ser usado com o gateway T1 conectado diretamente ao gateway T0 sem uma NVA (solução de virtualização de rede). Você pode fazer essa configuração funcionar, mas não oferecemos suporte a ela.
O HCX MON é um recurso opcional que você pode habilitar ao usar as NE (extensões de rede) do HCX. O MON fornece o roteamento de tráfego ideal em determinados cenários para impedir o tromboning de rede entre os recursos locais e baseados em nuvem em redes estendidas.
Como o MON é uma funcionalidade corporativa do recurso NE, certifique-se de habilitar o VMware HCX Enterprise por meio do portal do Azure.
Durante todo o ciclo de migração, o MON otimiza a mobilidade de aplicativos para:
Otimizar para VM (máquina virtual) para comunicação L2 de VM ao usar redes estendidas
Otimizar e evitar fluxos de tráfego assimétrico entre o local, a solução VMware no Azure e o Azure
Neste artigo, saiba mais sobre os casos de uso específicos da Solução VMware no Azure para o MON.
Otimizar fluxos de tráfego entre segmentos padrão e estendidos no lado da nuvem privada
Nesse cenário, a VM1 é migrada para a nuvem usando a NE, que fornece a latência ideal de VM para VM. Como resultado, a VM1 precisa de baixa latência para a VM3 no segmento local da Solução VMware no Azure. Migramos o gateway da VM1 do local para a Solução VMware no Azure (nuvem) para garantir ao tráfego (linha azul) o caminho ideal. Se o gateway permanecer no local (linha vermelha), você observará um efeito de tromboning e de aumento de latência.
Observação
Quando você habilita o MON sem migrar o gateway de VM para o lado da nuvem, ele não garante o caminho ideal para o fluxo de tráfego. Ele também não permite a avaliação de rotas de política.
Otimizar e evitar fluxos de tráfego assimétricos
Nesse cenário, supomos que uma VM local seja migrada para a Solução VMware no Azure e participe da L2, e o tráfego L3 flua de volta para o local para acessar os serviços. Também presumimos que alguma comunicação de VM do Azure (na rede virtual conectada à Solução VMware no Azure) possa acessar a nuvem privada da Solução VMware no Azure.
Importante
O ponto principal aqui é planejar cuidadosamente e evitar fluxos de tráfego assimétricos.
Por padrão, e sem usar MON, uma VM na Solução VMware no Azure em uma rede estendida sem MON pode se comunicar de volta com o local usando o caminho preferencial do ExpressRoute. Com base nos casos de uso do cliente, deve-se avaliar como uma VM em um segmento estendido da Solução VMware no Azure habilitado com MON deve estar voltando para o local, seja pela Extensão de Rede ou pelo gateway T0 por meio do ExpressRoute, mantendo os fluxos de tráfego simétricos.
Se escolher o caminho NE, por exemplo, as rotas de política MON precisam endereçar especificamente a sub-rede no lado local; caso contrário, a rota padrão 0.0.0.0/0 será usada. As rotas de política podem ser encontradas no segmento NE, selecionando avançado.
Por padrão, todos os endereços IP RFC 1918 são incluídos na definição de rotas de política MON.
Isso resulta em todo o tráfego de saída RFC 1918 sendo encapsulado pelo caminho NE e todo o tráfego público e de Internet sendo roteado para o gateway T0.
As rotas de política são avaliadas somente quando o gateway da VM é migrado para a nuvem. O efeito dessa configuração é que todas as sub-redes correspondentes do destino são encapsuladas pelo dispositivo NE. Se não forem correspondidas, elas serão roteadas pelo gateway T0.
Observação
A consideração especial para usar MON na Solução VMware no Azure é fornecer as rotas /32 anunciadas por BGP para seus pares. Isso inclui o local e o Azure por meio da conexão do ExpressRoute. Por exemplo, uma VM no Azure aprende o caminho para uma VM da Solução VMware no Azure em um segmento da Solução VMware no Azure habilitado para o MON. Depois que o tráfego de retorno é enviado de volta ao gateway T0 conforme esperado, se a sub-rede de retorno for uma correspondência RFC 1918, o tráfego será forçado pelo NE em vez do T0. Em seguida, faz a saída do ExpressRoute para o Azure no lado local. Isso pode causar confusão em firewalls com estado no meio e o comportamento de roteamento assimétrico. Também é uma boa ideia determinar como as VMs em segmentos NE MON precisarão acessar a Internet, seja por meio do gateway T0 na Solução VMware no Azure ou apenas por meio do NE de volta ao local. Em geral, todas as rotas de política padrão devem ser removidas para evitar tráfego assimétrico. Habilite as rotas de política somente se a infraestrutura de rede tiver sido configurada de forma a levar em conta e impedir o tráfego assimétrico.
As rotas de política MON podem ser excluídas sem nenhuma definida. Isso faz com que todo o tráfego de saída seja roteado para o gateway T0.
As rotas de política MON podem ser atualizadas com uma rota padrão (0.0.0.0/0). Isso resulta em todo o tráfego de saída sendo encapsulado no caminho NE.
Conforme descrito nos diagramas acima, a importância é corresponder uma rota de política a cada sub-rede necessária. Caso contrário, o tráfego será roteado pelo T0 e não encapsulado pelo NE.
Para saber mais sobre as rotas de política, confira Rotas de política de rede otimizadas para mobilidade.