Orientação do VMware HCX Mobility Optimized Networking (MON)

Nota

O VMware HCX Mobility Optimized Networking é oficialmente suportado pela VMware e pela Azure VMware Solution da HCX versão 4.1.0.

Importante

Antes de ativar o HCX MON, leia as limitações abaixo e as configurações não suportadas:

Configurações de origem não suportadas para HCX NE

Limitações para qualquer implantação de HCX, incluindo MON

O VMware HCX Mobility Optimized Networking (MON) não é suportado com o uso de um gateway de terceiros 3rd. Ele só pode ser usado com o gateway T1 diretamente conectado ao gateway T0 sem um dispositivo virtual de rede (NVA). Poderá conseguir fazer esta função de configuração, mas não a suportamos.

HCX Mobility Optimized Networking (MON) é um recurso opcional para habilitar ao usar HCX Network Extensions (NE). O MON fornece roteamento de tráfego ideal em determinados cenários para evitar 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:

• Otimizando a comunicação entre máquina virtual (VM) e VM L2 ao usar redes estendidas

• Otimizando e evitando fluxos de tráfego assimétricos entre o local, a Solução VMware do Azure e o Azure

Neste artigo, saiba mais sobre os casos de uso específicos da Solução VMware do Azure para MON.

Otimize os fluxos de tráfego entre segmentos padrão e estendidos no lado da nuvem privada

Nesse cenário, o VM1 é migrado para a nuvem usando o NE, que fornece latência ideal de VM para VM. Como resultado, o VM1 precisa de baixa latência para o VM3 no segmento local da Solução VMware do Azure. Migramos o gateway VM1 do local para a Solução VMware do Azure (nuvem) para garantir um caminho ideal para o tráfego (linha azul). Se o gateway permanecer no local (linha vermelha), observa-se um efeito tromboning e maior latência.

Nota

Quando você habilita o MON sem migrar o gateway de VM para o lado da nuvem, ele não garante um caminho ideal para o fluxo de tráfego. Também não permite a avaliação de rotas políticas.

Otimize e evite fluxos de tráfego assimétricos

Nesse cenário, assumimos que uma VM local é migrada para a Solução VMware do Azure e participa da L2 e o tráfego L3 flui de volta para os serviços locais para acessar. Também assumimos que alguma comunicação de VM do Azure (na rede virtual conectada da Solução VMware do Azure) possa chegar à nuvem privada da Solução VMware do Azure.

Importante

O ponto principal aqui é planejar e evitar fluxos de tráfego assimétricos com cuidado.

Por padrão e sem usar MON, uma VM na Solução VMware do Azure em uma rede estendida sem MON pode se comunicar de volta ao local usando o caminho preferencial da Rota Expressa. 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.

Se escolher o caminho NE, por exemplo, as rotas de política MON terão que 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 política MON.

Isso resulta em todo o tráfego de saída do 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 se o gateway de VM for migrado para a nuvem. O efeito dessa configuração é que todas as sub-redes correspondentes para o destino são encapsuladas no dispositivo NE. Se não corresponderem, eles são roteados através do gateway T0.

Nota

Uma consideração especial para usar MON no Azure VMware Solution é fornecer as rotas /32 anunciadas por BGP a seus pares; isso inclui o local e o Azure pela conexão ExpressRoute. Por exemplo, uma VM no Azure aprende o caminho para uma VM da Solução VMware do Azure em um segmento habilitado para MON da Solução VMware do Azure. Quando 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, sai pela Rota Expressa de volta para o Azure no lado local. Isso pode causar confusão para firewalls com monitoração de estado no meio e comportamento de roteamento assimétrico. Também é uma boa ideia determinar como as VMs nos segmentos NE MON precisarão acessar a Internet, seja 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. Só habilite rotas de política se a infraestrutura de rede tiver sido configurada de forma a contabilizar e evitar tráfego assimétrico.

As rotas da 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 da 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 tunelado sobre o caminho NE.

Conforme descrito nos diagramas acima, a importância é corresponder uma rota de política para cada sub-rede necessária. Caso contrário, o tráfego é encaminhado sobre o T0 e não sobre o túnel sobre o NE.

Para saber mais sobre rotas de política, consulte Rotas de política de rede otimizadas para mobilidade.