Diretrizes do VMware HCX MON (Mobility Optimized Networking)
Observação
O VMware HCX Mobility Optimized Networking é oficialmente suportado pelo VMware e pela solução VMware do Azure da 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 é suportado com o uso de um gateway de 3ª parte. Ele só pode ser usado com o gateway T1 conectado diretamente ao gateway T0 sem um dispositivo virtual de rede (NVA). Você pode ser capaz de fazer essa função de configuração, mas nós não suportamos isso.
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 é um recurso corporativo 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 do Azure para 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, presumimos que uma VM do local seja migrada para a Solução VMware do Azure e participe da L2, e o tráfego L3 flui 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 da Solução VMware do Azure) possa chegar até a nuvem privada da Solução VMware do 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 do Azure habilitado com MON deve estar voltando para o local, seja pela Extensão de Rede ou pelo gateway T0 por meio da Rota Expressa, mantendo os fluxos de tráfego simétricos.
Ao escolher o caminho NE, por exemplo, as rotas de política MON precisam abordar 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 diretiva 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 para o gateway T0 conforme o esperado, se a sub-rede de retorno for uma correspondência RFC 1918, o tráfego será forçado sobre o 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, por meio do gateway T0 na Solução VMware do Azure ou somente 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 rotas de diretiva somente se a infraestrutura de rede tiver sido configurada de forma a contabilizar e impedir o tráfego assimétrico.
As rotas de política MON podem ser excluídas sem nenhuma definida. Isso resulta em todo o tráfego de saída sendo 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 sobre o 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 é roteado sobre o T0 e não encapsulado sobre o NE.
Para saber mais sobre as rotas de política, confira Rotas de política de rede otimizadas para mobilidade.