Mova recursos do Azure entre regiões

Microsoft Entra
Azure ExpressRoute
Azure Load Balancer
Azure VPN Gateway

Esta solução move os recursos do Azure entre regiões de forma eficiente, segura e perfeita. Veja as principais etapas, considerações e estratégias para planejar e executar uma mudança.

Arquitetura

Diagrama que mostra o fluxo de dados da solução de movimentação de recursos do Azure entre regiões.

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de dados

  • Rede de data center local: uma rede local privada em execução dentro de uma organização para dar suporte aos recursos locais.

  • Circuito ExpressRoute: as conexões ExpressRoute usam uma conexão privada e dedicada por meio de um provedor de conectividade de terceiros. A conexão privada estende uma rede local para o Azure.

  • Roteadores de borda local: roteadores que conectam a rede local ao circuito gerenciado pelo provedor de terceiros. Dependendo de como você provisionou sua conexão, talvez seja necessário fornecer os endereços IP públicos que os roteadores usam.

  • Roteadores de borda da Microsoft: dois roteadores em uma configuração ativa-ativa altamente disponível. Esses roteadores permitem que um provedor de conectividade terceirizado conecte seus circuitos diretamente ao datacenter. Dependendo de como você provisionou sua conexão, talvez seja necessário fornecer os endereços IP públicos que os roteadores usam.

  • Gateway VPN: Usando o serviço de gateway VPN, você pode conectar a rede virtual à rede local.

  • Sub-rede do Ative Directory: a maioria das organizações empresariais tem um ambiente dos Serviços de Domínio Ative Directory (AD DS) no datacenter local. Para facilitar o gerenciamento de ativos movidos para o Azure a partir de sua rede local que depende do AD DS, considere hospedar controladores de domínio do AD DS no Azure em um hub central de Rede Virtual (VNET) que cargas de trabalho dependentes possam acessar.

  • Emparelhamento VNET: Várias VNETs com emparelhamento entre elas. O emparelhamento VNET permite aplicativos de grupo nas respetivas redes virtuais e fornece uma conexão de alta largura de banda de baixa latência.

  • Aplicativos Web multicamadas em execução no ambiente de nuvem: este exemplo de arquitetura é aplicável a muitos setores que precisam implantar aplicativos resilientes de várias camadas na nuvem. Nesse cenário, o aplicativo consiste em três camadas:

    • Camada da Web: a camada superior, incluindo a interface do usuário. Essa camada analisa as interações do usuário e passa as ações para a próxima camada para processamento.
    • Camada de negócios ou aplicativo: processa as interações do usuário e toma decisões lógicas sobre as próximas etapas. Essa camada conecta a camada da Web e a camada de dados.
    • Camada de dados: armazena os dados do aplicativo. Nesse caso, um banco de dados SQL armazena os dados.

  • Balanceador de carga interno: o tráfego de rede do gateway VPN é roteado para o aplicativo em nuvem por meio de um ponto de extremidade ILB (balanceador de carga interno) localizado na sub-rede das camadas do aplicativo.

  • Recursos de plataforma como serviço (PaaS): neste ambiente de exemplo, há alguns serviços PaaS, como o hub IoT do Azure, o Cofre da Chave do Azure e o Serviço de Aplicativo do Azure.

Componentes

A arquitetura de exemplo usa os seguintes componentes:

Detalhes do cenário

Com o crescimento do Microsoft Azure e seu conjunto de regiões em evolução em todo o mundo, os clientes precisam mover implantações de uma região para outra. Mover aplicativos entre regiões é uma atividade que exige um plano bem pensado, para garantir que você mova todos os recursos sem problemas e que os aplicativos estejam ativos e em execução na nova região com o mínimo de tempo de inatividade.

As recomendações e a arquitetura neste exemplo fornecem orientação sobre como mover recursos do Azure de forma eficiente, segura e transparente entre regiões.

Potenciais casos de utilização

Alguns dos principais motivos para mover recursos para uma região diferente incluem os seguintes casos:

  • Alinhar a uma inicialização de região: mova recursos para uma região do Azure recém-introduzida que não estava disponível anteriormente.
  • Alinhar para serviços ou recursos: mova recursos para aproveitar os serviços ou recursos disponíveis em uma região específica.
  • Responder aos desenvolvimentos comerciais: mova os recursos para uma região em resposta às mudanças na empresa, por exemplo, fusões ou aquisições.
  • Aderir para proximidade: mova os recursos para uma região nas proximidades da empresa.

Etapas para mover recursos entre regiões

Como seus requisitos podem diferir da arquitetura de exemplo, use as seguintes recomendações como ponto de partida:

  1. Verifique os pré-requisitos para a mudança.

    • Tempo de inatividade planejado: planeje a mudança de região como uma atividade de manutenção com tempo de inatividade programado para minimizar o impacto no cliente.

    • Limites e cota de assinatura do Azure: verifique se sua assinatura tem recursos suficientes para dar suporte ao tipo de recurso específico. Por exemplo, certifique-se de que a região de destino ofereça suporte a máquinas virtuais com tamanhos que correspondam às máquinas virtuais na sua região de origem. Entre em contato com o suporte para habilitar a cota necessária, se necessário. Para saber mais, consulte Limites de assinatura, cotas e restrições de serviço e assinatura do Azure.

    • Permissões da conta: se criou uma conta gratuita do Azure, é o administrador da sua subscrição. Se você não for o administrador da assinatura, trabalhe com o administrador para atribuir as permissões necessárias para mover os recursos. Verifique se sua assinatura do Azure permite que você crie o recurso necessário na região de destino.

    • Identificação de recursos: identifique e categorize seus recursos com base no tipo de recurso necessário para exportar um modelo do Azure Resource Manager ou para iniciar a replicação usando várias tecnologias. Para cada um dos tipos de recursos que você deseja mover, as etapas podem ser diferentes. Consulte Movendo recursos do Azure entre regiões para identificar as etapas correspondentes para cada um dos tipos de recursos.

  2. Mova os componentes de rede.

    • Grupos de Segurança de Rede: Não é possível mover grupos de segurança de rede de uma região para outra. No entanto, você pode usar um modelo ARM para exportar as regras de configuração e segurança existentes de um grupo de segurança de rede. Em seguida, você pode preparar o recurso em outra região exportando o grupo para um modelo, modificando os parâmetros para corresponder à região de destino e, em seguida, implantando o modelo na nova região.

    • Rede Virtual: Você pode usar um modelo do Azure Resource Manager para concluir a movimentação da rede virtual para outra região. Exporte a rede virtual para um modelo, modifique os parâmetros para corresponder à região de destino e implante o modelo na nova região.

    • Emparelhamento de rede virtual: o emparelhamento VNET não será recriado e os pares VNET falharão se ainda estiverem presentes no modelo. Antes de exportar o modelo, remova todos os pares VNET. Você pode restabelecê-los após a mudança da rede virtual.

    • Endereços IP públicos: como os IPs públicos do Azure são específicos da região, não é possível movê-los de uma região para outra. No entanto, você pode usar um modelo ARM para exportar as regras de configuração e segurança existentes de um grupo de segurança de rede. Em seguida, você pode preparar o recurso em outra região exportando o grupo para um modelo, modificando os parâmetros para corresponder à região de destino e, em seguida, implantando o modelo na nova região.

  3. Mova os componentes do aplicativo.

  4. Mover os serviços PaaS: os serviços PaaS têm suas próprias etapas específicas para orquestrar a mudança. Para encontrar as informações mais recentes na lista de serviços suportados, consulte Suporte para mover recursos do Azure entre regiões.

  5. Mover a infraestrutura local: para garantir que você tenha a região de origem completa recriada na região de destino, restabeleça e configure seus componentes locais como eram antes e conecte-os à rede do Azure.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Considere os seguintes pontos ao fazer uma mudança interregional:

  • Seu plano de migração entre regiões deve levar em conta a infraestrutura complexa. Os ambientes de infraestrutura modernos geralmente se estendem pela infraestrutura local até a nuvem. Alguns até têm um nível extra de complexidade, com uma estratégia multicloud contendo implantações privadas ou públicas.

  • Mova tipos de recursos juntos. Ao combinar a movimentação de tipos de recursos semelhantes (por exemplo, 50 máquinas virtuais ou 20 bancos de dados SQL), você pode planejar a etapa de preparação da sua mudança mais facilmente e garantir que as operações de longa execução sejam concluídas juntas, o que ajuda a reduzir o tempo de inatividade.

  • Mova todos os recursos dentro de um aplicativo juntos. Você pode selecionar os recursos de um aplicativo e tentar movê-los juntos em um conjunto, para garantir que você seja capaz de exibir o aplicativo na região de destino de maneira orquestrada.

  • Certifique-se de cobrir suas necessidades de capacidade. A capacidade de verificar a capacidade ou a cota está disponível na região de destino para dar suporte ao crescimento atual e potencial dos negócios antes da mudança real.

  • Deve haver um impacto mínimo ou nulo nos aplicativos ou na infraestrutura críticos para os negócios atuais na região de origem enquanto a mudança está em andamento.

  • Para garantir a continuidade dos negócios, você deve ter um ambiente funcional em funcionamento na região de destino com o menor tempo de inatividade possível.

  • A capacidade de validar a migração antes do compromisso final para o lado de destino é crítica, especialmente se você oferecer suporte a cargas de trabalho de Nível 0, Nível 1 no setor de Serviços Financeiros (FSI) ou verticais de cuidados de saúde.

  • Certifique-se de fazer a devida diligência testando e validando as configurações originais, a conectividade, a configuração de segurança adequada, as políticas, a replicação de dados e as conexões de banco de dados antes de confirmar a mudança para a região de destino.

  • Depois de mover os recursos para o destino, verifique se a configuração final está em execução fazendo alterações finais como:

    • Altere a configuração de DNS para apontar para um novo IP.
    • Exclua recursos na região de origem para evitar cobrança dupla e evitar problemas devido à existência de dois conjuntos de dados separados que se sobrepõem no escopo e na configuração.
    • Exclua todos os recursos auxiliares criados para a mudança. Por exemplo, exclua todas as contas de armazenamento que foram usadas para transferência intermediária.

Próximos passos