Rede Spoke-to-spoke

Os padrões de design de rede mais comuns no Azure envolvem a criação de topologias de rede virtual hub-and-spoke em uma ou várias regiões do Azure, opcionalmente conectadas a redes locais por meio da Rota Expressa do Azure ou de túneis de rede virtual privada (VPN) site a site pela Internet pública.

A maioria dos guias de design se concentra no tráfego de aplicativos para essas redes virtuais de usuários em redes internas, locais ou da Internet (o que a indústria normalmente designa tráfego norte-sul, porque geralmente é representado por linhas verticais em diagramas de rede). Este artigo se concentra em vários padrões que estão disponíveis para o tráfego leste-oeste. Ou seja, fluxos de comunicação entre cargas de trabalho implantadas em redes virtuais do Azure, dentro de uma região ou em regiões diferentes.

Certificar-se de que seu design de rede atenda aos requisitos de tráfego leste-oeste é fundamental para fornecer desempenho, escalabilidade e resiliência aos seus aplicativos executados no Azure.

Potenciais casos de utilização

O tráfego falado pode ser importante em vários cenários:

• Diferentes camadas de um único aplicativo estão em redes virtuais separadas. Por exemplo, servidores de rede de perímetro (também conhecidos como servidores DMZ) em uma rede virtual de perímetro se comunicam com serviços de aplicativos em uma rede virtual interna.
• As cargas de trabalho de aplicativos em diferentes ambientes (desenvolvimento, preparação, produção) devem replicar dados entre si.
• Diferentes aplicativos ou microsserviços precisam se comunicar entre si.
• Os bancos de dados precisam replicar dados entre regiões para garantir a continuidade dos negócios em caso de desastre.
• Os usuários estão dentro das redes virtuais do Azure. Por exemplo, eles usam a Área de Trabalho Virtual do Azure.

Padrões e topologias para comunicação interfalada

Há duas topologias principais que você pode usar em designs do Azure que cruzam várias redes virtuais: hub tradicional e spoke e WAN Virtual do Azure. Em um ambiente WAN Virtual, a Microsoft gerencia a rede virtual do hub e tudo dentro dela. Em um ambiente hub-and-spoke tradicional, você gerencia a rede virtual do hub.

WAN virtual e topologias hub-and-spoke são exemplos de arquiteturas em que as cargas de trabalho são executadas em redes virtuais spoke e a conectividade com o local é centralizada em uma rede virtual de hub. Muitos dos conceitos explicados neste artigo se aplicam a designs hub-and-spoke e WAN virtual.

Existem dois padrões principais para conectar redes virtuais faladas entre si:

• Raios diretamente conectados uns aos outros. Emparelhamentos de rede virtual ou túneis VPN são criados entre as redes virtuais spoke para fornecer conectividade direta sem atravessar a rede virtual do hub.
• Os raios comunicam através de um dispositivo de rede. Cada rede virtual spoke tem um emparelhamento para a WAN Virtual ou para uma rede virtual de hub. Um aparelho direciona o tráfego de falado para falado. O dispositivo pode ser gerenciado pela Microsoft (como acontece com a WAN Virtual) ou por você.

Padrão 1: Raios diretamente conectados uns aos outros

As conexões diretas entre raios normalmente oferecem melhor taxa de transferência, latência e escalabilidade do que as conexões que passam por um dispositivo virtual de rede (NVA) em um hub. O envio de tráfego através de NVAs pode adicionar latência ao tráfego se os NVAs estiverem em uma zona de disponibilidade diferente e pelo menos dois emparelhamentos de rede virtual precisarem ser cruzados quando o tráfego for enviado pelo hub. Há várias opções para conectar duas redes virtuais spoke diretamente uma à outra: emparelhamento de rede virtual, Gerenciador de Rede Virtual do Azure e túneis VPN.

• Emparelhamento de rede virtual. As vantagens dos peerings diretos de rede virtual sobre raios são:

  • Menor custo, porque são necessários menos saltos de emparelhamento de rede virtual.
  • Melhor desempenho, porque o tráfego não precisa atravessar nenhum dispositivo de rede que introduza latência ou gargalos potenciais.

  Outros cenários incluem conectividade entre locatários. No entanto, talvez seja necessário inspecionar o tráfego entre redes virtuais faladas, o que pode exigir o envio de tráfego por meio de dispositivos de rede centralizados na rede virtual do hub.

• Azure Virtual Network Manager. Além das vantagens que o emparelhamento de rede virtual oferece, o Azure Virtual Network Manager fornece um serviço de gerenciamento que permite gerenciar ambientes de rede virtual e cria conectividade em escala. Usando o Gerenciador de Rede Virtual do Azure, você pode criar três tipos de topologias entre assinaturas, para redes virtuais novas e existentes:

  • Hub e falou com porta-vozes que não estão conectados uns aos outros.

  • Hub e falou com raios que estão diretamente conectados uns aos outros, sem qualquer salto no meio.

  • Um grupo de malha de redes virtuais que estão interconectadas.

    

    Baixe todos os diagramas do Visio neste artigo.

    Quando você cria uma topologia hub-and-spoke com o Gerenciador de Rede Virtual do Azure na qual os raios são conectados uns aos outros, a conectividade direta entre redes virtuais spoke no mesmo grupo de rede é criada automaticamente bidirecionalmente. Usando o Gerenciador de Rede Virtual do Azure, você pode tornar estática ou dinamicamente as redes virtuais faladas membros de um grupo de rede específico, o que cria automaticamente a conectividade para qualquer rede virtual.

    Você pode criar vários grupos de rede para isolar clusters de redes virtuais spoke da conectividade direta. Cada grupo de rede fornece a mesma região e suporte multirregião para conectividade spoke-to-spoke. Certifique-se de ficar abaixo dos limites máximos para o Azure Virtual Network Manager descritos nas Perguntas frequentes do Azure Virtual Network Manager.

• Túneis VPN conectando redes virtuais. Você pode configurar serviços VPN para conectar diretamente redes virtuais spoke usando gateways VPN da Microsoft ou NVAs VPN de terceiros. A vantagem dessa opção é que as redes virtuais spoke se conectam entre nuvens comerciais e soberanas dentro do mesmo provedor de nuvem ou provedores de conectividade entre nuvens. Além disso, se houver NVAs de rede de longa distância definida por software (SD-WAN) em cada rede virtual falada, essa configuração pode facilitar o uso do plano de controle do provedor de terceiros e do conjunto de recursos para gerenciar a conectividade de rede virtual.

  Essa opção também pode ajudá-lo a atender aos requisitos de conformidade para a criptografia de tráfego entre redes virtuais em um único datacenter do Azure que ainda não são fornecidos pela criptografia MACsec. Mas essa opção vem com seu próprio conjunto de desafios devido aos limites de largura de banda dos túneis IPsec (1,25 Gbps por túnel) e às restrições de design de ter gateways de rede virtual em redes virtuais de hub e spoke: se a rede virtual spoke tiver um gateway de rede virtual, ela não poderá ser conectada à WAN Virtual ou usar o gateway de rede virtual de um hub para se conectar a redes locais.

Padrão 1: Região única

Independentemente da tecnologia que você usa para conectar redes virtuais faladas entre si, as topologias de rede seriam parecidas com esta para uma única região:

Padrão 1: Várias regiões

Os designs que conectam todas as redes virtuais faladas entre si também podem ser estendidos a várias regiões. Nessa topologia, o Gerenciador de Rede Virtual do Azure é ainda mais crítico, para reduzir a sobrecarga administrativa de manter o grande número necessário de conexões.

Quando você conecta diretamente redes virtuais faladas umas às outras em uma topologia totalmente entrelaçada, você precisa considerar o número potencialmente alto de emparelhamentos de rede virtual necessários. O diagrama a seguir ilustra esse problema. Nesse cenário, o Gerenciador de Rede Virtual do Azure é altamente recomendado para que você possa criar automaticamente conexões de rede virtual.

Padrão 2: Raios que se comunicam através de um dispositivo de rede

Em vez de conectar redes virtuais faladas diretamente umas às outras, você pode usar dispositivos de rede para encaminhar o tráfego entre raios. Os dispositivos de rede fornecem serviços de rede adicionais, como inspeção profunda de pacotes e segmentação ou monitoramento de tráfego, mas podem introduzir gargalos de latência e desempenho se não forem dimensionados corretamente. Esses dispositivos normalmente estão localizados em uma rede virtual de hub à qual os raios se conectam. Há várias opções para usar um dispositivo de rede para encaminhar o tráfego entre raios:

• Roteador de hub WAN virtual. Totalmente gerenciada pela Microsoft, a WAN Virtual contém um roteador virtual que atrai tráfego de raios e o encaminha para outra rede virtual conectada à WAN Virtual ou para redes locais via Rota Expressa ou túneis VPN site a site ou ponto a site. O roteador WAN Virtual aumenta e diminui automaticamente, portanto, você só precisa se certificar de que o volume de tráfego entre raios permanece dentro dos limites da WAN Virtual.

• Firewall do Azure. O Firewall do Azure é um dispositivo de rede gerenciado pela Microsoft e pode ser implantado em redes virtuais de hub gerenciadas por você ou em hubs WAN Virtuais. Ele pode encaminhar pacotes IP e também pode inspecioná-los e aplicar regras de segmentação de tráfego definidas em políticas. Ele fornece dimensionamento automático até os limites do Firewall do Azure para que não se torne um gargalo. Observe que o Firewall do Azure fornece recursos de várias regiões prontos para uso somente quando usado com a WAN Virtual. Sem a WAN Virtual, você precisa implementar rotas definidas pelo usuário para alcançar a comunicação inter-regional spoke-to-spoke.

• Dispositivos virtuais de rede de terceiros. Se preferir usar um dispositivo virtual de rede de um parceiro da Microsoft para executar o roteamento e a segmentação de rede, você poderá implantar dispositivos virtuais de rede em uma topologia hub-and-spoke ou WAN virtual. Para obter mais informações, consulte Implantar NVAs ou NVAs altamente disponíveis em um hub WAN virtual. Você precisa ter certeza de que o dispositivo virtual de rede suporta a largura de banda gerada pelas comunicações interfaladas.

• Gateway de VPN do Azure. Você pode usar um gateway de VPN do Azure como um tipo de próximo salto de rota definida pelo usuário, mas a Microsoft não recomenda o uso de gateways de rede virtual VPN para rotear o tráfego falado. Eles são projetados para criptografar o tráfego para sites locais ou usuários de VPN. Por exemplo, não há garantia da largura de banda entre raios que um gateway VPN pode rotear.

• Rota Expressa. Em determinadas configurações, um gateway de Rota Expressa pode anunciar rotas que atraem comunicação falada, enviando tráfego para o roteador de borda da Microsoft, onde é roteado para o destino falado. A Microsoft desencoraja fortemente esse cenário porque introduz latência enviando tráfego para a borda e vice-versa do backbone da Microsoft. Além disso, a Microsoft não recomenda essa abordagem, devido ao ponto único de falha e ao grande raio de explosão. Esse cenário também apresenta vários problemas causados por colocar pressão extra na infraestrutura da Rota Expressa (o gateway e os roteadores físicos). Esta pressão adicional pode causar quedas de pacotes.

Em projetos de rede hub-and-spoke que têm NVAs centralizados, o dispositivo normalmente é colocado no hub. Os emparelhamentos de rede virtual entre redes virtuais hub-and-spoke precisam ser criados manual ou automaticamente com o Azure Virtual Network Manager:

• Emparelhamento manual de rede virtual. Essa abordagem é suficiente quando você tem um número baixo de redes virtuais faladas, mas cria sobrecarga de gerenciamento em escala.

• Azure Virtual Network Manager. Como observado anteriormente, o Azure Virtual Network Manager fornece recursos para gerenciar ambientes de rede virtual e emparelhamentos em escala. As configurações de emparelhamento entre redes virtuais hub-and-spoke são configuradas automaticamente bidirecionalmente para grupos de rede.

  O Azure Virtual Network Manager fornece a capacidade de adicionar estaticamente ou dinamicamente associações de rede virtual spoke a um grupo de rede específico, o que cria automaticamente a conexão de emparelhamento para novos membros. As redes virtuais spoke em grupos de rede podem usar a VPN do hub ou gateways ExpressRoute para conectividade. Certifique-se de ficar abaixo dos limites máximos para o Azure Virtual Network Manager.

Padrão 2: Região única

O diagrama a seguir mostra uma topologia hub-and-spoke de região única que envia tráfego entre raios por meio de um firewall do Azure implantado na rede virtual do hub. O tráfego é encaminhado para o dispositivo centralizado no hub por meio de rotas definidas pelo usuário que são aplicadas às sub-redes faladas.

Em determinadas circunstâncias, pode ser benéfico separar os dispositivos virtuais de rede que lidam com o tráfego falado e o tráfego da Internet para obter escalabilidade. Você pode realizar essa separação ao:

• Ajustando as tabelas de rotas nos raios para enviar endereços privados (aqueles que têm uma rota para prefixos RFC 1918) para um NVA responsável pelo tráfego Azure-to-Azure e Azure-to-on-premises (também chamado de tráfego leste-oeste).
• Ajuste do tráfego de internet (que tem uma rota 0.0.0.0/0) para um segundo NVA. Este NVA é responsável pelo tráfego Azure-to-Internet (também conhecido como tráfego norte-sul).

O diagrama a seguir mostra essa configuração:

Padrão 2: Várias regiões

Você pode estender a mesma configuração para várias regiões. Por exemplo, em um design hub-and-spoke que usa o Firewall do Azure, você deve aplicar tabelas de rotas adicionais às sub-redes do Firewall do Azure em cada hub para os raios na região remota. Essa configuração garante que o tráfego entre regiões possa ser encaminhado entre os firewalls do Azure em cada rede virtual de hub. Em seguida, o tráfego inter-regional entre redes virtuais spoke atravessa ambos os firewalls do Azure. Para obter mais informações, consulte Firewall do Azure para rotear uma topologia multihub e spoke:

A variação de design com firewalls do Azure separados ou dispositivos virtuais de rede para tráfego norte-sul e leste-oeste também é possível em uma topologia hub-and-spoke de várias regiões:

A WAN virtual cria uma topologia semelhante e assume a complexidade de roteamento. Ele faz isso tanto nos hubs (que a Microsoft gerencia) quanto nos spokes (onde as rotas podem ser injetadas e não precisam ser definidas manualmente em tabelas de rotas). Assim, o administrador de rede só precisa conectar as redes virtuais spoke a um hub WAN virtual e não precisa se preocupar em encaminhar o tráfego entre regiões.

Padrões híbridos

Muitas situações exigem uma abordagem híbrida que combina os dois padrões descritos anteriormente. Nessa abordagem, o tráfego entre determinados raios precisa passar por conexões diretas, mas o resto dos raios se comunica por meio de um dispositivo de rede central. Por exemplo, em um ambiente WAN virtual, você pode conectar diretamente dois raios específicos que têm requisitos de alta largura de banda e baixa latência. Outro cenário envolve redes virtuais faladas que fazem parte de um único ambiente. Por exemplo, você pode permitir que uma rede virtual de Desenvolvimento spoke se conecte diretamente a outra rede virtual de Desenvolvimento falado, mas forçar cargas de trabalho de Desenvolvimento e Produção a se comunicarem por meio do dispositivo central.

Outro padrão comum envolve a conexão de raios em uma região por meio de emparelhamentos diretos de rede virtual ou grupos conectados do Azure Virtual Network Manager, mas permitindo que o tráfego inter-regional cruze NVAs. A principal motivação para este modelo é normalmente reduzir o número de peerings de rede virtual na arquitetura. No entanto, em comparação com o primeiro modelo (conectividade direta entre raios), uma desvantagem introduzida neste modelo é mais saltos de emparelhamento de rede virtual para tráfego entre regiões. Esses saltos aumentam os custos devido aos vários pares de rede virtual que são cruzados. Outra desvantagem é a carga extra para os NVAs do hub para enfrentar todo o tráfego inter-regional.

Os mesmos designs são aplicáveis para WAN Virtual. No entanto, uma consideração é que a conectividade direta entre redes virtuais spoke precisa ser configurada manualmente diretamente entre as redes virtuais e não através do recurso WAN Virtual. Atualmente, o Azure Virtual Network Manager não oferece suporte a arquiteturas baseadas em WAN Virtual. Por exemplo:

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

• Jay Li - Brasil | Gerente de Produto Sênior
• Jose Moreno - Brasil | Engenheiro de Clientes Principal
• Alejandra Palacios - Brasil | Engenheiro de Clientes de Infraestrutura do Azure Sênior

Outros contribuidores:

• Mick Alberts - Brasil | Redator Técnico
• Mohamed Hassan - Brasil | Gestor Principal PM
• Andrea Michael - Brasil | Gestor de Programas
• Yasukuni Morishima - Brasil | Engenheiro de Clientes II
• Jithin PP| Engenheiro de Clientes

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

• Cloud Adoption Framework: topologia e conectividade de rede da zona de aterrissagem
• Peering de rede virtual
• Azure Virtual Network Manager
• Virtual WAN
• Azure Firewall
• Conectividade de rede segura no Azure
• Introdução às Redes Virtuais do Azure

Recursos relacionados

• Topologia de rede Hub-spoke no Azure
• Topologia de rede Hub-spoke com WAN Virtual do Azure
• Topologia de rede tradicional do Azure