Partilhar via

Conectividade de zona de aterrissagem de dados entre regiões

  • Artigo

Se você estiver presente em mais de uma região do Azure e precisar hospedar sua plataforma de dados e aplicativos de dados em várias geografias, a conectividade se tornará um pouco mais complicada.

As implantações de várias regiões geralmente têm uma assinatura de hub de conectividade em cada local individual do Azure. Por exemplo, se você tiver serviços em execução no Leste dos EUA e na Europa Ocidental, configurará uma assinatura de hub de conectividade com recursos de rede compartilhados em cada região. Os recursos de rede partilhados incluem:

  • Dispositivos virtuais de rede (como o Firewall do Azure)
  • Gateways do ExpressRoute
  • Gateways de VPN
  • Redes Virtuais de Hub (em uma arquitetura de hub e spoke) ou Hubs vWAN (em uma configuração vWan)

Conectividade entre regiõesFigura 1: Conectividade entre regiões.

Na arquitetura hub-spoke-spoke-hub, as redes virtuais dos hubs de conectividade geralmente são conectadas usando o Global VNet Peering. Para ambientes maiores, uma alternativa comum é usar o ExpressRoute Global Reach. Seja qual for a opção de conectividade escolhida, você pode obter roteamento global e conectividade entre redes spoke em várias geografias. Isso significa que você pode mover dados entre regiões usando dispositivos virtuais de rede, grupos de segurança de rede e tabelas de rotas, já que seu tráfego não é bloqueado em nenhuma das assinaturas de conectividade.

Importante

Este artigo e outros artigos na seção de rede descrevem unidades de negócios cruzadas que compartilham dados. No entanto, esta pode não ser a sua estratégia inicial e que você precisa começar em um nível básico primeiro.

Projete sua rede para que você possa, eventualmente, implementar nossa configuração recomendada entre zonas de aterrissagem de dados. Certifique-se de ter as zonas de aterrissagem de gerenciamento de dados diretamente conectadas às zonas de pouso para governança.

Você pode conectar zonas de aterrissagem de dados entre regiões usando o emparelhamento VNet global direto. Nesta configuração, se continuarmos nosso cenário de exemplo anterior, a máquina virtual na Europa Ocidental acessa diretamente o ponto de extremidade privado da conta de armazenamento do Leste dos EUA, sem depender de nenhuma arquitetura de rede hub and spoke ou vWAN. Os dados são carregados diretamente pela máquina virtual em um ponto de extremidade privado, processados e, em seguida, armazenados novamente na conta de armazenamento na Europa Ocidental.

Gerenciamento de acesso de usuário no Global VNet Peering

Não há prós ou contras específicos para nenhuma das opções de conectividade propostas para zonas de aterrissagem de dados entre regiões.

Sumário: /

Gerenciamento de serviços no Global VNet Peering

O Global VNet Peering não tem nenhum dispositivo virtual de rede que atue como um único ponto de falha ou taxa de transferência de limitação. Os dados não são enviados por meio de seus hubs de conectividade, portanto, você não precisa dimensionar os dispositivos virtuais e gateways dentro dos hubs de conectividade. Essa falta de dimensionamento reduz a sobrecarga de gerenciamento para sua equipe principal da plataforma Azure. Você também não precisa permitir conexões individuais entre regiões. Suas equipes de dados podem acessar dados de zonas de aterrissagem de dados em outras regiões sem ter que esperar por alterações na tabela de rotas.

Neste design de rede, sua equipe central da plataforma Azure não pode mais inspecionar e registrar todo o tráfego usando um firewall de camada 7. No entanto, o cenário de análise em escala de nuvem é uma plataforma coerente que abrange várias assinaturas, o que permite escala e supera limitações no nível da plataforma, portanto, isso não é uma desvantagem. Você pode capturar logs de rede usando os Logs de Fluxo do Grupo de Segurança de Rede. Você pode consolidar e armazenar outros logs de aplicativo e de nível de serviço usando as Configurações de Diagnóstico específicas do serviço.

Você pode capturar todos esses logs em escala usando as definições de Política do Azure para configurações de diagnóstico.

Em alguns cenários, você precisa limitar devido a implicações regulatórias ou legais. Por exemplo, você pode ter uma regulamentação local que exija que determinados conjuntos de dados permaneçam dentro de um datacenter de partículas, portanto, você não tem permissão para transferi-los entre regiões. Você pode confiar em grupos de segurança de rede para ajudá-lo a cumprir esse tipo de regra, permitindo apenas que o tráfego se mova em uma direção do Leste dos EUA para a Europa Ocidental e não vice-versa. Dentro de seus grupos de segurança de rede, você pode garantir que o tráfego originado do Leste dos EUA seja negado, enquanto o tráfego originado da Europa Ocidental seja permitido.

Essa abordagem de solução não afeta a largura de banda e a latência e permite que os clientes permaneçam em conformidade enquanto ainda combinam conjuntos de dados de várias regiões. Essa opção também não tem impacto na arquitetura DNS e permite que você use uma solução nativa do Azure baseada em Zonas DNS Privadas do Azure.

Sumário:

Custo global de emparelhamento de redes virtuais

Nota

Ao acessar um ponto de extremidade privado em uma rede emparelhada, você só será cobrado pelo ponto de extremidade privado em si e não pelo emparelhamento de VNet. Você pode ler a declaração oficial em FAQ: Como funcionará o faturamento ao acessar um endpoint privado a partir de uma rede emparelhada?.

Com este design de rede, você é cobrado por seus pontos de extremidade privados (por hora) e todo o tráfego de entrada e saída enviado através deles. Você também tem que pagar um custo de transferência de dados para o tráfego entre regiões. No entanto, NÃO será cobrado nenhum custo de entrada e saída do Global VNet Peering. Por isso, a opção Global VNet Peering tem benefícios de custo notáveis na opção tradicional spoke-hub-hub-spoke descrita mais adiante neste artigo.

Sumário:

Largura de banda e latência no Global VNet Peering

O impacto na largura de banda e latência é muito menor no Global VNet Peering do que na opção tradicional spoke-hub-hub-spoke. O Global VNet Peering contém um número menor de saltos para troca de dados entre regiões da zona de aterrissagem de dados e não tem dispositivos virtuais de rede limitando a taxa de transferência. As únicas coisas que ditam a largura de banda e latência que você pode alcançar para o tráfego entre regiões são os limites físicos de nossos datacenters (velocidade de cabos de fibra ótica, gateways e roteadores).

Sumário:

Resumo do emparelhamento de rede virtual global

O emparelhamento global de redes virtuais entre zonas de aterrissagem de dados em diferentes regiões oferece enormes benefícios, especialmente à medida que o tráfego de dados entre regiões aumenta em sua plataforma de dados. Ele simplifica o gerenciamento de serviços para sua equipe principal da plataforma Azure e, especialmente, beneficia casos de uso que exigem baixa latência e alta largura de banda. Ele também oferece benefícios de custo significativos em relação à opção tradicional de design spoke-hub-hub-spoke.

Sua outra opção para transferências de dados entre regiões é o design tradicional spoke-hub-hub-spoke. Em nosso cenário de exemplo, se uma máquina virtual na zona de aterrissagem de dados A hospedada na Europa Ocidental carregar um conjunto de dados armazenado em uma conta de armazenamento da zona de aterrissagem de dados B hospedada no Leste dos EUA, os dados atravessarão dois emparelhamentos VNet locais (conectividade entre hub e raios), um Emparelhamento Global de VNet (conectividade entre hubs) e dois Gateways ou dispositivos virtuais de rede antes de serem carregados pela máquina virtual e, em seguida, movidos de volta para a conta de armazenamento local.

Gerenciamento de acesso de usuário no design tradicional spoke-hub-hub-spoke

Não há prós ou contras específicos para nenhuma das opções de conectividade propostas para zonas de aterrissagem de dados entre regiões.

Sumário: /

Gerenciamento de serviços no design tradicional spoke-hub-hub-spoke

Essa abordagem de solução é bem conhecida e consistente com outros padrões de conectividade entre regiões, o que facilita sua adoção e implementação. Ele também não tem impacto na arquitetura DNS e permite que você use uma solução nativa do Azure baseada em Zonas DNS Privadas do Azure.

Embora essa opção de conectividade funcione perfeitamente se você configurá-la corretamente, ela tem desvantagens. O tráfego entre regiões é frequentemente negado por predefinição e tem de ser ativado caso a caso. Isso significa que um tíquete deve ser enviado à sua equipe principal da plataforma Azure para cada requisito de acesso a dados entre regiões necessário para que sua equipe possa permitir a lista de cada conexão específica entre uma máquina virtual e uma conta de armazenamento entre regiões. Esse processo aumenta significativamente as despesas gerais de gerenciamento. Também torna as equipas de projeto de dados mais lentas, porque não conseguem aceder aos dados de que necessitam.

Você também deve observar que, nessa opção, os hubs de conectividade atuam como pontos únicos de falha. No dispositivo virtual de rede ou no tempo de inatividade do gateway, a conectividade e as plataformas de dados correspondentes falham. Você também tem um alto risco de configurar rotas incorretamente nos hubs de conectividade. Essa configuração incorreta pode causar um tempo de inatividade mais sério em sua plataforma de dados e levar a uma série de falhas dependentes de fluxo de trabalho e produtos de dados.

Você deve monitorar a quantidade de dados que precisa transferir entre regiões ao usar essa abordagem de solução. Com o tempo, esse monitoramento pode envolver gigabytes ou terabytes de dados se movendo pelas instâncias centrais. Como a largura de banda dos dispositivos virtuais de rede geralmente é limitada a uma taxa de transferência de gigabytes de um ou dois dígitos, os dispositivos podem atuar como um gargalo crítico limitando o fluxo de tráfego entre regiões e a compartilhabilidade de seus ativos de dados. Por isso, seus recursos de rede compartilhados podem exigir mecanismos de dimensionamento, que geralmente são demorados e caros, e podem afetar outras cargas de trabalho em seu locatário.

Sumário:

Custo de design tradicional Spoke-Hub-Hub-Spoke

Nota

Ao acessar um ponto de extremidade privado em uma rede emparelhada, você só será cobrado pelo ponto de extremidade privado em si e não pelo emparelhamento VNet. Você pode ler a declaração oficial em FAQ: Como funcionará o faturamento ao acessar um endpoint privado a partir de uma rede emparelhada?.

No design tradicional spoke-hub-hub-spoke, são cobrados os pontos de extremidade privados (por hora) das suas duas contas de armazenamento e todo o tráfego de entrada e saída enviado através deles. Você também é cobrado pelo tráfego de entrada e saída de um emparelhamento de VNet local e pelo emparelhamento global de VNet entre seus hubs de conectividade. No entanto, você não será cobrado pelo primeiro emparelhamento de VNet, como explicamos na nota anterior.

Seus dispositivos virtuais de rede central também serão um custo significativo se você escolher esse design de rede. Isso ocorre porque você precisa comprar licenças extras para dimensionar os dispositivos com base na demanda ou pagar a cobrança por gigabyte processado por eles, como acontece com o Firewall do Azure.

Sumário:

Largura de banda e latência no design tradicional spoke-hub-hub-spoke

Este design de rede tem sérias limitações de largura de banda. Seus dispositivos virtuais de rede central tornam-se gargalos críticos à medida que sua plataforma cresce, o que limita os casos de uso da zona de aterrissagem de dados entre regiões e o compartilhamento de seus conjuntos de dados. Isso também torna provável que várias cópias de seus conjuntos de dados sejam criadas ao longo do tempo. Esse design também afeta fortemente a latência, o que é especialmente crítico para cenários de análise em tempo real, já que seus dados atravessam muitos saltos.

Sumário:

Resumo do design tradicional spoke-hub-hub-spoke

O design spoke-hub-hub-spoke é bem conhecido e estabelecido em muitas organizações, o que facilita o estabelecimento em um ambiente existente. No entanto, ele tem desvantagens significativas para gerenciamento de serviços, custo, largura de banda e latência. Esses problemas são especialmente percetíveis à medida que o número de casos de uso entre regiões cresce.

Conclusão

O Global VNet Peering tem muitas vantagens em relação ao design tradicional spoke-hub-hub-spoke, pois é econômico, facilmente gerenciado e oferece conectividade confiável entre regiões. Embora o design tradicional spoke-hub-hub-spoke possa ser uma opção viável enquanto o volume de dados e a necessidade de troca de dados entre regiões é baixo, recomendamos que você use a abordagem Global VNet Peering à medida que a quantidade de dados que você precisa trocar entre regiões cresce.

Próximos passos