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 do ExpressRoute do Azure ou túneis de VPN (rede virtual privada) 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 o setor 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 aplicativos executados no Azure.

Possíveis casos de uso

O tráfego Spoke-to-spoke 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 da 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 ambientes diferentes (Desenvolvimento, Preparo, 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 entre sons

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

As topologias WAN virtual e hub-and-spoke são exemplos de arquiteturas nas quais 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 de hub-and-spoke e WAN virtual.

Há dois padrões principais para conectar redes virtuais spoke entre si:

• Spokes conectados diretamente 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 hub.
• Spokes que se comunicam por meio de um dispositivo de rede. Cada rede virtual spoke tem um emparelhamento com a WAN virtual ou com uma rede virtual hub. Um dispositivo encaminha o tráfego de spoke para spoke. O dispositivo pode ser gerenciado pela Microsoft (como com uma WAN Virtual) ou por você.

Padrão 1: spokes conectados diretamente uns aos outros

As conexões diretas entre spokes geralmente oferecem melhor taxa de transferência, latência e escalabilidade do que as conexões que passam por um NVA (dispositivo virtual de rede) em um hub. O envio de tráfego por meio 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 uma à outra diretamente: emparelhamento de rede virtual, Gerenciador de Rede Virtual do Azure e túneis VPN.

• Emparelhamento de rede virtual. As vantagens dos emparelhamentos diretos de rede virtual sobre os spokes são:

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

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

• Gerenciador de Rede Virtual do Azure. Além das vantagens que o emparelhamento de rede virtual oferece, o Gerenciador de Rede Virtual do Azure 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, tanto para redes virtuais novas quanto existentes:

  • Hub and spoke com spokes que não estão conectados entre si.

  • Hub e spoke com spokes que estão diretamente conectados uns aos outros, sem nenhum salto no meio.

  • Um grupo em malha de redes virtuais 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 spokes são conectados uns aos outros, a conectividade direta entre redes virtuais spoke no mesmo grupo de rede é criado automaticamente de forma bidirecional. Usando o Gerenciador de Rede Virtual do Azure, você pode tornar as redes virtuais spoke, de forma estática ou dinâmica, 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 a várias regiões para conectividade spoke-to-spoke. Fique abaixo dos limites máximos para o Gerenciador de Rede Virtual do Azure descritos nas Perguntas frequentes do Gerenciador de Rede Virtual do Azure.

• Túneis VPN conectando redes virtuais. Você pode configurar serviços VPN para conectar diretamente redes virtuais spoke usando gateways de VPN da Microsoft ou NVAs de 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 spoke, essa configuração poderá facilitar o uso do plano de controle e do conjunto de recursos do provedor de terceiros para gerenciar a conectividade de rede virtual.

  Essa opção também pode ajudar você 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-and-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 entre si, as topologias de rede teriam a seguinte aparência para uma única região:

Padrão 1: várias regiões

Os designs que conectam todas as redes virtuais spoke 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 spoke umas às outras em uma topologia totalmente interligada, é necessário 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 recomendável para que você possa criar automaticamente conexões de rede virtual.

Padrão 2: os spokes se comunicam por meio de um dispositivo de rede

Em vez de conectar redes virtuais spoke diretamente entre si, você pode usar dispositivos de rede para encaminhar o tráfego entre spokes. 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 geralmente estão localizados em uma rede virtual de hub à qual os spokes se conectam. Há várias opções para usar um dispositivo de rede para encaminhar o tráfego entre spokes:

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

• Azure Firewall. Azure Firewall é um dispositivo de rede gerenciado pela Microsoft e pode ser implantado em redes virtuais de hub que você gerencia ou em hubs de WAN Virtual. 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 prontos para várias regiões somente quando usado com a WAN Virtual. Sem a WAN Virtual, você precisa implementar rotas definidas pelo usuário para obter comunicação spoke-to-spoke entre regiões.

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

• 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 de VPN para rotear tráfego spoke-to-spoke. 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 spokes que um gateway de VPN pode rotear.

• ExpressRoute. Em determinadas configurações, um gateway de ExpressRoute pode anunciar rotas que atraem comunicação spoke-to-spoke, enviando tráfego para o roteador de borda da Microsoft, onde é roteado para o spoke de destino. 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 único ponto de falha e ao grande raio de explosão. Esse cenário também apresenta vários problemas causados pela pressão extra sobre a infraestrutura do ExpressRoute (o gateway e os roteadores físicos). Essa 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 manualmente ou automaticamente com o Gerenciador de Rede Virtual do Azure:

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

• Gerenciador de Rede Virtual do Azure. Como observado anteriormente, o Gerenciador de Rede Virtual do Azure 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 Gerenciador de Rede Virtual do Azure fornece a capacidade de adicionar estática 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 os gateways de hub, VPN ou ExpressRoute para conectividade. Certifique-se de permanecer abaixo dos limites máximos para o Gerenciador de Rede Virtual do Azure.

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 spokes por meio de um firewall do Azure implantado na rede virtual de 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 spoke.

Em determinadas circunstâncias, pode ser benéfico separar os dispositivos virtuais de rede que lidam com o tráfego spoke-to-spoke e da Internet para obter escalabilidade. É possível realizar essa separação desta forma:

• Ajustando as tabelas de rotas nos spokes para enviar endereços privados (aqueles que têm uma rota para prefixos RFC 1918) para um NVA responsável pelo tráfego do Azure para o Azure e do Azure para o local (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. Esse NVA é responsável pelo tráfego do Azure para a Internet (também conhecido como tráfego norte-sul).

O seguinte diagrama 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 spokes 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. 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 de hub-and-spoke de várias regiões:

A WAN virtual cria uma topologia semelhante e assume a complexidade do 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 com o encaminhamento de tráfego entre regiões.

Padrões híbridos

Muitas situações exigem uma abordagem híbrida que combine os dois padrões descritos anteriormente. Nessa abordagem, o tráfego entre certos spokes precisa passar por conexões diretas, mas o restante dos spokes se comunica por meio de um dispositivo de rede central. Por exemplo, em um ambiente de WAN Virtual, você pode conectar diretamente dois spokes específicos que têm requisitos de alta largura de banda e baixa latência. Outro cenário envolve redes virtuais 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 spoke, mas forçar as cargas de trabalho de Desenvolvimento e Produção a se comunicarem por meio do dispositivo central.

Outro padrão comum envolve conectar spokes em uma região por meio de emparelhamentos diretos de rede virtual ou grupos conectados do Gerenciador de Rede Virtual do Azure, mas permitindo que o tráfego entre regiões cruze NVAs. A principal motivação para esse modelo normalmente é reduzir o número de emparelhamentos de rede virtual na arquitetura. No entanto, em comparação ao primeiro modelo (conectividade direta entre spokes), 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 emparelhamentos de rede virtual que são cruzados. Outra desvantagem é a carga extra para os NVAs do hub para fazer frente a todo o tráfego entre regiões.

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 por meio do recurso de WAN Virtual. No momento, o Gerenciador de Rede Virtual do Azure não oferece suporte a arquiteturas baseadas na WAN Virtual. Por exemplo:

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

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

Outros colaboradores:

• Mick Alberts | Escritor Técnico
• Mohamed Hassan | Gerente de PM Principal
• Andrea Michael | Gerente de Programas
• Yasukuni Morishima | Engenheiro de Clientes II
• Jithin PP | Engenheiro de Clientes

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

Próximas etapas

• Cloud Adoption Framework: topologia e conectividade de rede da zona de destino
• Emparelhamento de rede virtual
• Gerenciador de Rede Virtual do Azure
• WAN Virtual
• Firewall do Azure
• 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 a WAN Virtual do Azure
• Topologia de rede do Azure tradicional