Compartilhar via


O que é SDN Multisite?

Aplica-se a: Azure Local, versão 23H2

Aplica-se a: Windows Server 2025

Este artigo fornece uma visão geral do SDN Multisite, incluindo seus benefícios e limitações atuais. Você pode usá-lo como um guia para ajudar a projetar sua topologia de rede e plano de recuperação de desastres.

O SDN Multisite permite expandir os recursos da SDN tradicional implantada em diferentes locais físicos. O SDN Multisite permite conectividade nativa de Camada 2 e Camada 3 em diferentes locais físicos para cargas de trabalho virtualizadas. Neste artigo, todas as referências a sites significam locais físicos.

Para obter informações sobre como gerenciar o SDN Multisite, consulte Gerenciar SDN Multisite para Azure Local.

Para obter informações sobre como gerenciar o SDN Multisite, consulte Gerenciar SDN Multisite para Azure Local.

Benefícios

Aqui estão os benefícios de usar o SDN Multisite:

  • Sistema unificado de gerenciamento de políticas. Com redes virtuais compartilhadas e configurações de política, você pode gerenciar e configurar suas redes multissite de qualquer site.
  • Migração perfeita da carga de trabalho. Migre cargas de trabalho entre sites físicos sem precisar reconfigurar endereços IP ou NSGs (grupos de segurança de rede) preexistentes.
  • Acessibilidade automática a novas VMs. Obtenha acessibilidade automática para VMs (máquinas virtuais) recém-criadas em redes virtuais, juntamente com capacidade de gerenciamento automática para qualquer um de seus NSGs associados em seus locais físicos.

Limitações

O recurso SDN Multisite atualmente tem algumas limitações:

  • Com suporte apenas entre dois sites.
  • Os sites devem estar conectados por meio de uma rede privada, pois o suporte à criptografia para sites conectados pela Internet não é fornecido.
  • Não há suporte para balanceamento de carga interno entre sites.

Emparelhamento multissite

O multissite requer emparelhamento entre sites, que é iniciado como emparelhamento de rede virtual. Uma conexão é iniciada automaticamente em ambos os sites por meio do Windows Admin Center. Depois que uma conexão é estabelecida, o emparelhamento é bem-sucedido. Para obter instruções sobre como estabelecer o emparelhamento, consulte Estabelecer emparelhamento.

O multissite requer emparelhamento entre sites, que é iniciado como emparelhamento de rede virtual. Uma conexão é iniciada automaticamente em ambos os sites por meio do Windows Admin Center. Depois que uma conexão é estabelecida, o emparelhamento se torna bem-sucedido. Para obter instruções sobre como estabelecer o emparelhamento, consulte Estabelecer emparelhamento.

As seções a seguir descrevem as funções de cada site em um ambiente multissite e como os recursos são manipulados e sincronizados entre os sites.

Funções de site primário e secundário

Em um ambiente SDN multissite, um site é designado como primário e o outro como secundário. O site primário lida com a sincronização de recursos. Durante o emparelhamento multissite, o site primário é selecionado automaticamente, o que você pode alterar posteriormente usando Windows Admin Center.

Tratamento de recursos

  • Se o site primário estiver inacessível, os recursos globais e os recursos que exigem validação global ou alocações globais de AC (Endereço do Cliente) não poderão ser atualizados por meio do site secundário. No entanto, outros recursos locais podem ser atualizados por meio do site secundário.

    Exemplos de recursos que precisam de validação global incluem:

    • Pools MAC.
    • Rede lógica/pool de IP.

    Exemplos de alocações globais de CA incluem:

    • Balanceamento de carga interno para sub-rede virtual. Atualmente, não há suporte para isso por meio do Multisite.
    • Conexões de gateway para sub-rede virtual.
  • Se o site secundário estiver inacessível, os recursos poderão ser atualizados por meio do site primário. No entanto, o site secundário pode ter recursos obsoletos até que a conectividade seja restaurada. Depois que a conectividade for restaurada, a sincronização será retomada.

  • Se o site primário ficar inativo, você poderá designar seu site secundário como o novo site primário para executar atualizações em seus grupos de segurança de rede e redes virtuais. No entanto, qualquer sincronização de dados pendente do site primário antigo será perdida. Para resolver esse problema, aplique essas mesmas alterações no novo site primário assim que o site primário antigo estiver online novamente. No entanto, também pode levar a conflitos globais de alocação de CA.

Sincronização de recursos

Quando você habilita o SDN Multisite, nem todos os recursos de cada site são sincronizados em todos os sites. Aqui estão as listas de recursos que estão sincronizados e que permanecem não sincronizados.

  • Recursos sincronizados

    Esses recursos são sincronizados em todos os sites após o estabelecimento do emparelhamento. Você pode atualizar esses recursos de qualquer site, seja ele primário ou secundário. No entanto, o site principal é responsável por garantir que esses recursos sejam aplicados e sincronizados entre os sites. As diretrizes e instruções para gerenciar esses recursos permanecem as mesmas de um ambiente SDN de site único.

  • Recursos sincronizados

    Esses recursos são sincronizados em todos os sites após o estabelecimento do emparelhamento. Você pode atualizar esses recursos de qualquer site, seja ele primário ou secundário. No entanto, o site principal é responsável por garantir que esses recursos sejam aplicados e sincronizados entre os sites. As diretrizes e instruções para gerenciar esses recursos permanecem as mesmas de um ambiente SDN de site único.

  • Recursos não sincronizados

    Esses recursos não são sincronizados depois que o emparelhamento é estabelecido:

    • Políticas de balanceamento de carga.
    • Endereços IP virtuais (VIPs).
    • Políticas de gateway.
    • Redes lógicas. Embora as redes lógicas não sejam sincronizadas entre sites, os pools de IP são verificados quanto à sobreposição e essa sobreposição não é permitida.

    Essas políticas são criadas no site local e, se você quiser as mesmas políticas no outro site, deverá criá-las manualmente lá. Se as VMs de back-end para políticas de balanceamento de carga estiverem localizadas em um único site, a conectividade por SLB funcionará bem sem nenhuma configuração extra. Mas, se você espera que as VMs de back-end sejam movidas de um site para outro, por padrão, a conectividade só funcionará se houver VMs de back-end por trás de um VIP no site local. Se todas as VMs de back-end forem movidas para outro site, a conectividade por meio desse VIP falhará.

Fluxo de tráfego leste-oeste e compartilhamento de sub-rede

O multissite permite que VMs em sites diferentes com SDN implantado se comuniquem pela mesma sub-rede sem precisar configurar conexões de gateway SDN. Isso simplifica a topologia de rede e reduz a necessidade de mais VMs e sub-redes. O caminho de dados entre VMs em sites diferentes depende da infraestrutura física subjacente.

Os cenários a seguir comparam como a comunicação de VM é estabelecida entre dois sites físicos em uma configuração SDN tradicional versus em uma configuração SDN Multisite.

Comunicação VM a VM sem SDN Multisite

Em uma configuração tradicional com SDN implantada em dois sites físicos, você precisa estabelecer uma conexão de gateway L3 ou GRE para comunicação entre sites. Você também precisa fornecer mais sub-redes para seus aplicativos. Por exemplo, se cada site hospedar aplicativos front-end, você alocará intervalos de sub-rede separados, como 10.1/16 e 10.6/16. Além disso, ao configurar uma conexão de gateway, você também precisa alocar mais VMs para suas VMs de gateway e gerenciá-las posteriormente.

Diagrama para mostrar a comunicação de VM para VM entre dois sites físicos em uma configuração de SDN tradicional.

Comunicação de VM para VM com SDN Multisite

Com o SDN Multisite em dois locais físicos, você pode ter conectividade nativa de Camada 2 para comunicação entre sites. Isso permite que você tenha um único intervalo de sub-rede para seus aplicativos que se estendem por ambos os locais, eliminando a necessidade de configurar a conexão de gateway SDN. Por exemplo, conforme ilustrado no diagrama a seguir, os aplicativos front-end em ambos os locais podem usar a mesma sub-rede, como 10.1/16, em vez de manter duas separadas. Com essa configuração, o fluxo de dados de uma VM para outra depende exclusivamente de sua infraestrutura física subjacente, evitando a necessidade de atravessar outra VM de gateway de SDN.

Diagrama para mostrar a comunicação de VM para VM com SDN Multisite.

Balanceadores de carga de software e suas limitações

Atualmente, os Balanceadores de Carga de Software são recursos locais para cada um de seus sites físicos. Isso significa que as políticas e configurações de balanceamento de carga não são sincronizadas entre sites por meio de Multisite. Lembre-se disso ao migrar VMs de um local para outro em uma configuração multissite da SDN.

Balanceamento de carga em SDN Multisite: cenário de exemplo

As seções a seguir explicam o balanceamento de carga em Multissite por meio de um cenário de exemplo, demonstrando sem e com VMs de carga de trabalho migratórias. Suponha que você tenha duas instâncias locais do Azure com SDN Multisite habilitado, cada uma com sua própria infraestrutura de SDN implantada e configurada. Nesse cenário, um cliente deseja acessar a VM1 com o endereço IP 10.0.0.5 e o VIP 11.0.0.5.

Balanceamento de carga no SDN Multisite sem migrar VMs de carga de trabalho

No SDN Multisite, se não houver migração de VM entre locais, os pacotes de dados serão encaminhados normalmente, semelhante à configuração tradicional de SDN. A animação a seguir ilustra o caminho de dados do computador cliente para a VM1 via SLB MUX1 no Cluster 2.

Animação que mostra o balanceamento de carga em um ambiente SDN Multisite sem migrar cargas de trabalho.

Balanceamento de carga no SDN Multisite com a migração de VMs de carga de trabalho

Se você decidir migrar uma VM ou todas as VMs por trás do VIP para o outro site, poderá encontrar situações em que a VM que você está tentando acessar se torna inacessível pelo VIP, dependendo de sua localização. Isso acontece porque os recursos do balanceador de carga são locais para cada instância local do Azure. À medida que as VMs de carga de trabalho se movem, as configurações nos MUXes não são globais, deixando o outro site sem saber das migrações. A animação a seguir ilustrou a migração de VMs do Cluster 2 para o Cluster 1 e como o caminho do pacote de dados falha após a migração.

Animação que mostra o balanceamento de carga em um ambiente SDN Multisite com cargas de trabalho migratórias.

Para contornar essa limitação, você pode usar o balanceador de carga externo que verifica a disponibilidade de VMs de back-end em cada site e roteia o tráfego de acordo. Consulte Usar o balanceador de carga externo em Multissite com a migração de VMs de carga de trabalho.

Usar o balanceador de carga externo em Multisite com a migração de VMs de carga de trabalho

Você pode habilitar um balanceador de carga externo para verificar se há VMs de back-end por trás de um balanceador de carga em um de seus sites. Se não houver VMs de back-end por trás de um balanceador de carga, o VIP do MUX não será anunciado para o balanceador de carga externo e qualquer investigação de integridade enviada falhará. Esse balanceador de carga externo garante a conectividade com cargas de trabalho, mesmo quando as VMs se movem de um site para outro.

Diagrama mostrando o uso de um balanceador local de software externo como uma solução para migrar VMs entre sites em uma configuração multissite.

No entanto, se a implantação de um balanceador de carga externo não for viável, use a solução de balanceamento de carga de software, conforme descrito em Balanceamento de carga no SDN Multisite sem migrar VMs de carga de trabalho, desde que você não tenha nenhuma VM de carga de trabalho migratória.

Gateways e suas limitações

O SDN multissite não sincroniza recursos locais, como conexões de gateway entre sites. Cada site tem suas próprias VMs de gateway e conexões de gateway. Quando uma VM de carga de trabalho é criada ou migrada para um site, ela obtém a configuração do gateway local, como rotas de gateway. Se você criar uma conexão de gateway para uma rede virtual específica em um site, as VMs desse site perderão a conectividade do gateway após a migração para o outro site. Para que as VMs mantenham a conectividade do gateway na migração, você deve configurar uma conexão de gateway separada para a mesma rede virtual no outro site.

Próximas etapas