Compartilhar via

Conectividade de zona de destino de dados em várias regiões

  • Artigo

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

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

  • Dispositivos virtuais de rede (como o Firewall do Azure)
  • Gateways do ExpressRoute
  • Gateways VPN
  • Redes Virtuais do Hub (em uma arquitetura hub e spoke) ou Hubs de vWAN (em uma configuração de 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 Emparelhamento VNet Global. Para ambientes maiores, uma alternativa comum é usar o Alcance Global do ExpressRoute. Seja qual for a opção de conectividade escolhida, você pode obter roteamento global e conectividade entre as redes spoke em várias regiões geográficas. Isso significa que você pode mover dados entre regiões usando soluções de virtualização de rede, grupos de segurança de rede e Tabelas de Rotas, considerando que o tráfego não é bloqueado em nenhuma das assinaturas de conectividade.

Importante

Este artigo e outros artigos na seção de rede descrevem as unidades entre empresas que compartilham dados. No entanto, essa pode não ser sua estratégia inicial e você precisa começar em um nível base primeiro.

Crie a rede de modo que você possa implementar eventualmente nossa configuração recomendada entre zonas de destino de dados. Verifique se você as zonas de destino de gerenciamento de dados estão conectadas diretamente às zonas de destino para governança.

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

Gerenciamento de acesso do usuário no Emparelhamento VNet Global

Não há prós ou contras específicos para qualquer uma das opções propostas de conectividade de zona de destino de dados entre regiões.

Resumo: /

Gerenciamento de serviços no Emparelhamento VNet Global

O Emparelhamento VNet Global não tem soluções de virtualização de rede que atuem como ponto único de falha ou taxa de transferência de limitação. Os dados não são enviados por meio de os hubs de conectividade. Portanto, você não precisa escalar as soluções de virtualização e os gateways nos hubs de conectividade. Essa falta de escala reduz a sobrecarga de gerenciamento para a principal equipe de plataforma do Azure. Você também não precisa permitir conexões entre regiões individuais da lista de permitidos. As equipes de dados podem acessar dados de zonas de destino de dados em outras regiões, sem precisar aguardar alterações na tabela de rotas.

Nesse design de rede, a equipe da plataforma central do 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 de escala de nuvem é uma plataforma coerente que abrange várias assinaturas, o que permite a escala e supera as limitações no nível da plataforma, de modo que isso não é uma desvantagem. Você pode capturar os logs de rede usando os Logs de Fluxo do Grupo de Segurança de Rede. Você pode consolidar e armazenar outros logs de nível de aplicativo e 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 do Azure Policy 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 em um datacenter específico. Portanto, você não tem permissão para transferi-los entre regiões. Você pode contar com grupos de segurança de rede para ajudar a cumprir esse tipo de regra, permitindo que o tráfego se mova apenas em uma direção, do Leste dos EUA para o Oeste da Europa, e não vice-versa. Nos grupos de segurança de rede, você pode garantir que o tráfego proveniente do Leste dos EUA seja negado, enquanto o tráfego proveniente do Oeste da Europa é 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 e, ao mesmo tempo, combinem conjuntos de dados em 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 com base nas Zonas de DNS Privadas do Azure.

Resumo:

Custo do Emparelhamento VNET Global

Observação

Ao acessar um ponto de extremidade privado em uma rede emparelhada, você só será cobrado pelo próprio ponto de extremidade privado e não pelo emparelhamento VNet. Você pode ler a instrução oficial em Perguntas frequentes: como a cobrança funcionará ao acessar um ponto de extremidade privado em uma rede emparelhada?.

Com esse design de rede, você é cobrado pelos pontos de extremidade privados (por hora) e todo o tráfego de entrada e saída enviado através deles. Você também precisa pagar um custo de transferência de dados pelo tráfego entre regiões. No entanto, você NÃO será cobrado por custos de entrada e saída do Emparelhamento VNet Global. Por isso, a opção de Emparelhamento VNet Global tem benefícios de custo notáveis em relação à opção spoke-hub-hub-spoke tradicional descrita posteriormente neste artigo.

Resumo:

Largura de banda e latência no Emparelhamento VNet Global

O impacto na largura de banda e na latência é muito menor no Emparelhamento VNet Global do que na opção spoke-hub-hub-spoke tradicional. O Emparelhamento VNet Global contém um número menor de saltos para troca de dados da zona de destino de dados entre regiões e não tem soluções de virtualização de rede que limitam a taxa de transferência. Os únicos fatores que determinam a largura de banda e a latência que você pode alcançar para o tráfego entre regiões são os limites físicos de nossos datacenters (velocidade dos cabos de fibra óptica, gateways e roteadores).

Resumo:

Resumo do Emparelhamento VNet Global

O Emparelhamento VNet Global entre zonas de destino de dados em diferentes regiões oferece grandes benefícios, especialmente à medida que o tráfego de dados entre regiões aumenta na plataforma de dados. Ele simplifica o gerenciamento de serviços para a principal equipe de plataforma do Azure e beneficia especialmente os casos de uso que exigem baixa latência e largura de banda elevada. Ele também oferece benefícios de custo significativos em relação à opção de design spoke-hub-hub-spoke tradicional.

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

Gerenciamento de Acesso do Usuário no design spoke-hub-hub-spoke tradicional

Não há prós ou contras específicos para qualquer uma das opções propostas de conectividade de zona de destino de dados entre regiões.

Resumo: /

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

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

Embora essa opção de conectividade funcione perfeitamente, se você configurá-la de maneira correta, ela tem desvantagens. O tráfego entre regiões geralmente é negado por padrão e deve ser habilitado caso a caso. Isso significa que um tíquete deve ser enviado à principal equipe de plataforma do Azure para cada requisito de acesso a dados entre regiões, de modo que a equipe possa incluir na lista de permitidos cada conexão específica entre uma máquina virtual e uma conta de armazenamento entre regiões. Esse processo aumenta significativamente a sobrecarga de gerenciamento. Ele também reduz a velocidade das equipes de projeto de dados, pois elas não podem acessar os dados necessários.

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

Você deve monitorar o volume de dados necessário para transferir entre regiões, ao usar essa abordagem de solução. Com o tempo, esse monitoramento pode envolver a movimentação de gigabytes ou terabytes de dados através das instâncias centrais. Como a largura de banda das soluções de virtualização de rede geralmente é limitada a uma taxa de transferência gigabyte de um ou dois dígitos, as soluções podem atuar como um gargalo crítico, limitando o fluxo de tráfego entre regiões e a capacidade de compartilhamento dos ativos de dados. Por isso, os recursos de rede compartilhada podem exigir mecanismos de escala, que geralmente são demorados e caros, e podem afetar outras cargas de trabalho no locatário.

Resumo:

Custo do design spoke-hub-hub-spoke tradicional

Observação

Ao acessar um ponto de extremidade privado em uma rede emparelhada, você só será cobrado pelo próprio ponto de extremidade privado e não pelo emparelhamento VNet. Você pode ler a instrução oficial em Perguntas frequentes: como a cobrança funcionará ao acessar um ponto de extremidade privado em uma rede emparelhada?.

No design spoke-hub-hub-spoke tradicional, você é cobrado pelos pontos de extremidade privados das duas contas de armazenamento (por hora) 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 VNet local e do emparelhamento VNet global entre os hubs de conectividade. No entanto, você não será cobrado pelo primeiro emparelhamento VNet, como explicamos na observação anterior.

As soluções de virtualização de rede centrais também terão um custo considerável, se você escolher esse design de rede. Isso ocorre porque você precisa comprar licenças adicionais para expandir as soluções de acordo com a demanda ou você precisa pagar o encargo por gigabyte processado por elas, como ocorre com o Firewall do Azure.

Resumo:

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

Esse design de rede tem limitações de largura de banda importantes. As soluções de virtualização de rede centrais se tornam gargalos críticos, à medida que a plataforma cresce, o que limita os casos de uso da zona de destino de dados entre regiões e o compartilhamento dos conjuntos de dados. Isso também torna provável que várias cópias dos conjuntos de dados sejam criadas ao longo do tempo. Esse design também afeta muito a latência, que é especialmente crítica para cenários de análise em tempo real, já que os dados percorrem muitos saltos.

Resumo:

Resumo do design spoke-hub-hub-spoke tradicional

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

Conclusão

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

Próximas etapas