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 na Internet (o que o setor normalmente designa o tráfego norte-sul, porque geralmente é representado por linhas verticais em diagramas de rede). Este artigo se concentra em vários padrões 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 DMZ) em uma rede virtual de perímetro se comunicam com os 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 autogerenciado e spoke e WAN Virtual do Azure. Em um ambiente de WAN Virtual, a Microsoft gerencia as redes virtuais do hub e tudo dentro delas. Em um ambiente de hub e spoke autogerenciado, você gerencia a rede virtual do hub.
A WAN virtual e topologias de hub e spoke autogerenciadas são exemplos de arquiteturas nas quais as cargas de trabalho executadas em redes virtuais spoke e conectividade com o local são centralizadas em uma rede virtual de hub. Muitos dos conceitos explicados neste artigo se aplicam a designs de HUB e SPOKE autogerenciados 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 em relação aos 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.
Emparelhamento de sub-rede. Semelhante ao emparelhamento de rede virtual, mas o emparelhamento de sub-rede permite mais granularidade especificando quais sub-redes em ambos os lados do emparelhamento têm permissão para conversar entre si.
Gerenciador de Rede Virtual do Azure. Além das vantagens oferecidas pelo emparelhamento de rede virtual, o Gerenciador de Rede Virtual do Azure fornece um serviço de gerenciamento que permite gerenciar ambientes de rede virtual e criar 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 entre si, 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 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. Mantenha-se abaixo dos limites máximos do 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 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 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 foi fornecido 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 1a: 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 1b: 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.
Observação
Quando você conecta redes virtuais spoke diretamente, em uma região ou em várias regiões, considere fazer isso para redes virtuais spoke no mesmo ambiente. Por exemplo, conecte uma rede virtual de desenvolvimento spoke com outra rede virtual de Desenvolvimento spoke. Mas evite conectar uma rede virtual de Desenvolvimento spoke com uma rede virtual de Produção spoke.
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 wan virtual é escalado e reduzido automaticamente, portanto, você só precisa garantir que o volume de tráfego entre spokes permaneça 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 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 ele 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 ou NVAs altamente disponíveisem 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. Esses dispositivos 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. Às vezes, esse padrão é conhecido como hairpinning do ExpressRoute e precisa ser habilitado explicitamente seguindo as instruções em Habilitar ou desabilitar a VNet para VNet ou VNet para o tráfego wan virtual por meio do ExpressRoute. 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 designs de rede de hub e spoke autogerenciados com 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 manuais de rede virtual ou emparelhamentos de sub-rede. 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. Conforme 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 estatica 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 VPN ou ExpressRoute do hub para conectividade. Mantenha-se abaixo dos limites máximos do Gerenciador de Rede Virtual do Azure.
Padrão 2a: 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 uma NVA responsável pelo tráfego local do Azure para o Azure e do Azure-to-on(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. Essa 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:
Observação
O firewall do Azure requer que apenas um recurso do Firewall do Azure possa ser implantado em uma rede virtual. Portanto, uma rede virtual de hub separada é necessária para recursos adicionais do Firewall do Azure. Para cenários de NVA, você pode usar uma única rede virtual de hub para implantações de NVA adicionais.
Padrão 2b: várias regiões
Você pode estender a mesma configuração para várias regiões. Por exemplo, em um design de hub e spoke autogerenciado 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 o Firewall do Azure para rotear uma topologia de vários hubs 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:
Observação
O firewall do Azure requer que apenas um recurso do Firewall do Azure possa ser implantado em uma rede virtual. Portanto, uma rede virtual de hub separada é necessária para recursos adicionais do Firewall do Azure. Para cenários de NVA, você pode usar uma única rede virtual de hub para implantações de NVA adicionais.
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 mistos
Algumas situações podem exigir uma abordagem híbrida que combine os dois padrões descritos anteriormente. Nesse caso, o tráfego entre determinados 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 a conexão de spokes em uma região por meio de emparelhamentos de rede virtual direta ou grupos conectados do Gerenciador de Rede Virtual do Azure, mas permitir que o tráfego inter regional 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:
Observação
Para abordagens mistas, é importante entender que a conectividade direta por meio do emparelhamento de rede virtual propaga rotas do sistema para suas redes virtuais de conexão que geralmente são mais específicas do que as rotas personalizadas configuradas por meio de tabelas de rotas. Portanto, o caminho de emparelhamento de rede virtual é preferencial em relação às rotas personalizadas que seguem a seleção de rota de correspondência de prefixo mais longa.
No entanto, em cenários menos comuns, se houver uma rota do sistema e uma rota personalizada definida pelo usuário com o mesmo prefixo de endereço, a rota definida pelo usuário terá precedência sobre as rotas do sistema (criadas automaticamente pelo emparelhamento de rede virtual). Esse comportamento resulta em tráfego de rede virtual spoke-to-spoke atravessando a rede virtual de hub, mesmo se houver uma conexão direta por meio de emparelhamento.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Principais autores:
- Jay Li | Gerente de Produto Sênior
- José Moreno | Engenheiro de cliente principal
- Alejandra Palacios | Engenheiro sênior de clientes de infraestrutura do Azure
Outros colaboradores:
- Mick Alberts | Gravador Técnico
- Mohamed Hassan | Gerente de PM principal
- Andrea Michael | Gerenciador de Programas
- Yasukuni Morishima | Engenheiro do Cliente 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
- Azure Firewall
- Conectividade de rede segura no Azure
- Introdução às Redes Virtuais do Azure