Selecionar regiões do Azure para uma migração

Artigo
04/11/2024

Ao migrar um ambiente existente para o Azure, você precisa selecionar uma região do Azure ou um conjunto de regiões para hospedar os componentes migrados. A seleção de regiões envolve as seguintes etapas de alto nível:

Analise as diretrizes principais de seleção de região do Azure para entender como selecionar regiões do Azure que atendam às suas necessidades.
Inventarie e documente o estado atual do seu ambiente.
Implemente uma abordagem geral para sua migração, incluindo se deve ser executado em uma única região, usar várias zonas de disponibilidade ou usar várias regiões.
Avalie as alterações de processo que possam ser necessárias.
Planeje um processo de migração.
Otimizar e promover mudanças de processos.

Este artigo fornece orientação sobre como escolher regiões do Azure que atendam às suas necessidades de migração. Se ainda não o fez, talvez seja necessário estender as regiões da zona de desembarque para dar suporte a abordagens de várias regiões.

Nota

Este artigo aborda considerações específicas para migrações de carga de trabalho. Você também deve entender os princípios gerais para selecionar regiões do Azure para qualquer organização ou carga de trabalho. Para obter mais informações, consulte Selecionar regiões do Azure.

Documente a complexidade do cenário

Determine se o cenário requer documentação e alinhamento de processos. A abordagem a seguir pode ajudá-lo a avaliar desafios potenciais e estabelecer um curso de ação geral:

Considerar uma prontidão mais robusta e uma implementação de governança.
Inventariar as geografias afetadas. Compile uma lista dos países ou regiões afetados.
Documente a base de usuários. A migração para a nuvem afetará funcionários, parceiros ou clientes no país ou região identificados?
Documente datacenters e ativos. O esforço de migração inclui algum ativo no país ou região identificado?
Documente a disponibilidade da versão regional do produto e os requisitos de failover.
Documente seus requisitos de resiliência para determinar se as zonas de disponibilidade são necessárias. Normalmente, você considera os requisitos de resiliência para todo o cenário, não para regiões individuais.
Documente seus requisitos de soberania e requisitos de residência de dados. As cargas de trabalho que têm soberania específica ou requisitos de residência de dados podem influenciar a sua escolha de regiões do Azure.

Ao longo do processo de migração, considere como alinhar as alterações em seus vários cenários e inventários. A tabela a seguir mostra um exemplo de como documentar vários cenários.

País/Região	País/Região	Funcionários locais	Utilizadores externos locais	Datacenters ou ativos locais	Requisitos de soberania de dados
América do Norte	Estados Unidos da América	Sim	Parceiros e clientes	Sim	No
América do Norte	Canadá	Não	Clientes	Sim	Sim
Europa	Alemanha	Sim	Parceiros e clientes	Não - apenas rede	Sim
Ásia-Pacífico	Coreia do Sul	Sim	Parceiros	Sim	No

Porque é que a localização dos utilizadores é relevante?

As organizações que oferecem suporte a usuários em vários países ou regiões desenvolvem soluções técnicas que abordam o tráfego de usuários. Em alguns casos, as soluções envolvem a localização de ativos. Em outros cenários, a organização pode optar por implementar soluções de rede de longa distância (WAN) global para lidar com bases de usuários díspares por meio de soluções focadas na rede. Em ambos os casos, os perfis de uso de usuários diferentes podem afetar a estratégia de migração.

Por exemplo, se uma organização oferece suporte a funcionários, parceiros e clientes na Alemanha, mas atualmente não tem datacenters na Alemanha, a organização provavelmente implementa uma solução de linha alugada. Esse tipo de solução roteia o tráfego para datacenters em outros países ou regiões. Este encaminhamento existente apresenta um risco significativo para o desempenho observado das aplicações migradas. Injetar mais lúpulo em uma WAN global estabelecida e ajustada pode criar a perceção de aplicativos com baixo desempenho após a migração. Encontrar e corrigir estes problemas pode acrescentar atrasos significativos a um projeto.

Cada uma das seções a seguir inclui orientações para abordar essa complexidade em pré-requisitos e processos de avaliação, migração e otimização. Entender os perfis de usuário em cada país ou região é fundamental para gerenciar adequadamente essa complexidade.

Qual a relevância da localização dos datacenters finais?

A localização dos datacenters existentes pode afetar uma estratégia de migração. Considere os seguintes fatores:

Decisões de arquitetura: uma das primeiras etapas no design da estratégia de migração é determinar a região de destino. A localização dos ativos existentes influencia frequentemente esta determinação. Além disso, a disponibilidade de serviços em nuvem e o custo unitário desses serviços podem variar entre regiões. Os requisitos de residência de dados, incluindo os requisitos de soberania, também podem influenciar a decisão de arquitetura. Entender onde os ativos atuais e futuros estão localizados afeta as decisões de arquitetura e pode influenciar as estimativas de orçamento.

Dependências do datacenter: na tabela da seção Documente a complexidade do cenário, os cenários de exemplo mostram que você provavelmente precisa planejar dependências entre vários datacenters globais. As organizações que operam nessa escala podem não documentar ou entender claramente essas dependências. A abordagem da sua organização para avaliar perfis de utilizador ajuda-o a identificar algumas destas dependências na sua organização. Sua equipe também deve explorar mais etapas de avaliação que podem ajudar a mitigar os riscos e complexidades decorrentes das dependências.

Aplicar uma abordagem geral

A abordagem a seguir usa um modelo orientado por dados para abordar as complexidades da migração global. Se o escopo da migração incluir várias regiões, a equipe de adoção de nuvem deverá avaliar as seguintes considerações de preparação:

Determine se você pode atender aos seus requisitos de negócios: use várias zonas de disponibilidade para determinar os requisitos de alta disponibilidade, resiliência, desempenho e custo. Se esses requisitos não forem atendidos, considere se você precisa de uma abordagem multirregional.
Avaliar a soberania de dados: a soberania de dados pode exigir a localização de alguns ativos, mas muitos ativos não são regidos por essas restrições de conformidade. Serviços como registro, relatórios, roteamento de rede, identidade e outros serviços centrais de TI podem ser qualificados para serem hospedados como serviços compartilhados em várias assinaturas ou regiões. Avalie a soberania de dados usando um modelo de serviço compartilhado para esses serviços. Para obter um esboço dessa abordagem, consulte a arquitetura de referência para uma topologia hub-spoke com serviços compartilhados.
Garantir que seu ambiente seja dimensionado: se você implantar várias instâncias de ambientes semelhantes, poderá estabelecer uma equipe dedicada para as migrações do ambiente para ajudar a criar consistência, melhorar a governança e acelerar a implantação. O guia de governação para empresas complexas estabelece uma abordagem que cria um ambiente que é dimensionado em várias regiões.

Pré-requisitos orientados por dados

Quando sua equipe estiver confortável com a abordagem de linha de base e a prontidão estiver alinhada, considere estes pré-requisitos orientados por dados:

Descoberta geral completa: preencha a tabela em Complexidade do documento para avaliar a complexidade da sua estratégia de adoção da nuvem.
Analise perfis de usuário para cada país ou região afetado: é importante entender o roteamento geral do usuário no início do processo de migração. Alterar linhas de leasing globais e adicionar conexões como o Azure ExpressRoute a um datacenter na nuvem pode resultar em meses de atrasos na rede. Aborde o roteamento do usuário o mais cedo possível no processo.
Conclua uma racionalização inicial de patrimônio digital: se você introduzir complexidade em uma estratégia de migração, conclua uma racionalização inicial de patrimônio digital. Para obter mais informações, consulte O que é um patrimônio digital?.
Use a marcação para requisitos de propriedade digital: estabeleça políticas de marcação para identificar qualquer carga de trabalho afetada pelos requisitos de soberania de dados. Certifique-se de que as tags necessárias comecem na racionalização do patrimônio digital e se realizem até os ativos migrados.
Avalie um modelo hub-spoke: os sistemas distribuídos geralmente compartilham dependências comuns. Muitas vezes, você pode resolver dependências compartilhadas implementando um modelo hub-spoke. Embora a implementação de um modelo hub-spoke esteja fora do escopo do processo de migração, sinalize o modelo para consideração durante futuras iterações dos processos prontos.
Priorize a lista de pendências de migração: se você precisar de alterações de rede para dar suporte à implantação de produção de uma carga de trabalho que ofereça suporte a várias regiões, a equipe de estratégia de nuvem deverá acompanhar e gerenciar os escalonamentos resultantes das alterações de rede. Esse nível mais alto de suporte executivo ajuda a acelerar a mudança, liberando a equipe de estratégia para repriorizar a lista de pendências e garantir que as alterações na rede não bloqueiem cargas de trabalho globais. Priorize cargas de trabalho globais somente quando as alterações de rede forem concluídas.

Esses pré-requisitos ajudam a estabelecer processos que podem abordar a complexidade durante a execução da estratégia de migração.

Avaliar alterações do processo

Se o seu cenário de migração envolver complexidades globais de ativos e da base de usuários, adicione atividades-chave para avaliar seus candidatos à migração. Essas atividades produzem dados para ajudá-lo a esclarecer obstáculos e resultados para usuários e ativos globais.

Ações sugeridas durante o processo de avaliação

Avaliar dependências entre datacenters: as ferramentas de análise de dependência no Azure Migrate podem ajudá-lo a identificar dependências. Use essas ferramentas antes de começar a migração. Se o seu cenário envolve complexidade global, avaliar dependências é uma etapa necessária no processo de avaliação. Você pode usar o agrupamento de dependências para visualizar dependências e identificar os endereços IP e as portas de quaisquer ativos necessários para dar suporte à carga de trabalho.

Importante

Você precisa de um especialista no assunto (SME) que entenda a colocação de ativos e esquemas de endereço IP para identificar ativos localizados em um datacenter secundário.
Avalie as dependências downstream e os clientes na visualização para entender as dependências bidirecionais.

Identificar o impacto global do usuário: a saída da análise de perfil de usuário de pré-requisito deve identificar qualquer carga de trabalho afetada por perfis de usuário globais. Se um candidato à migração estiver na lista de cargas de trabalho afetadas, o arquiteto de migração deverá consultar as PMEs de redes e operações. Esses especialistas ajudam a validar as expectativas de roteamento e desempenho da rede. No mínimo, a arquitetura deve incluir uma conexão de Rota Expressa entre o centro de operações de rede mais próximo e o Azure. A arquitetura de referência para conexões de Rota Expressa pode ajudá-lo a configurar as conexões de rede necessárias.

Design para conformidade: a saída da análise de perfil de usuário de pré-requisito também deve identificar qualquer carga de trabalho afetada pelos requisitos de soberania de dados. Durante as atividades de arquitetura do processo de avaliação, o arquiteto designado deve consultar as PME responsáveis pela conformidade. Esses especialistas podem ajudar o arquiteto a entender quaisquer requisitos de migração e implantação em várias regiões. Esses requisitos afetam significativamente as estratégias de conceção. As seguintes arquiteturas de referência podem ajudar com o design:

Aviso

Se você usar a arquitetura de referência para ExpressRoute ou as arquiteturas de referência para aplicativos, talvez seja necessário excluir elementos de dados específicos dos processos de replicação para atender aos requisitos de soberania de dados. A tarefa de excluir elementos de dados específicos adiciona uma etapa ao processo de promoção.

Alterações no processo de migração

Se você migrar um aplicativo que deve ser implantado em várias regiões, a equipe de adoção de nuvem deverá levar em conta mais algumas considerações. O design dos cofres do Azure Site Recovery e os servidores de configuração e processo são duas dessas considerações. Duas outras considerações são projetos de largura de banda de rede e sincronização de dados.

Ações sugeridas durante o processo de migração

Design do cofre do Site Recovery: o Site Recovery é a ferramenta sugerida para replicação nativa da nuvem e sincronização de ativos digitais com o Azure. O Site Recovery replica dados sobre cada ativo para um cofre do Site Recovery. Este cofre está vinculado a uma assinatura específica em uma região específica e no datacenter do Azure. Se você replicar ativos para uma segunda região, também poderá precisar de um segundo cofre de Recuperação de Site.

Configuração e design do servidor de processo: o Site Recovery funciona com uma instância local de um servidor de configuração e processo vinculado a um único cofre do Site Recovery. Ao usar essa configuração, talvez seja necessário instalar segundas instâncias desses servidores no datacenter de origem para facilitar a replicação.

Design de largura de banda de rede: durante a replicação e a sincronização contínua, você move dados binários pela rede do datacenter de origem para o cofre do Site Recovery no datacenter do Azure de destino. O processo de replicação e sincronização consome largura de banda. A duplicação da carga de trabalho para uma segunda região dobra a quantidade de largura de banda consumida.

Em alguns cenários, a largura de banda é limitada. Em outros, uma carga de trabalho envolve configuração substancial ou desvio de dados. Nesses casos, replicar dados para uma segunda região pode interferir no tempo necessário para concluir a migração. Mais importante ainda, essas restrições podem afetar a experiência de usuários ou aplicativos que ainda dependem da largura de banda disponível no datacenter de origem.

Sincronização de dados: O maior dreno de largura de banda geralmente vem da sincronização da plataforma de dados. Se você implantar em várias zonas de disponibilidade, poderá usar serviços de dados com redundância de zona que sincronizam automaticamente seus dados em várias zonas de disponibilidade. A implantação em várias regiões geralmente requer sincronização de dados para manter os aplicativos alinhados. Essa abordagem é definida nas arquiteturas de referência para aplicativos Web de várias regiões e aplicativos de n camadas de várias regiões.

Se manter os aplicativos sincronizados for o estado operacional desejado para seus aplicativos, convém sincronizar a plataforma de dados de origem com cada plataforma de nuvem. Execute essa sincronização antes de migrar o aplicativo e os ativos de camada intermediária.

Recuperação de desastres do Azure para o Azure: uma opção alternativa pode reduzir ainda mais a complexidade. Se você usar uma implantação em duas etapas para atender às necessidades de linha do tempo e sincronização de dados, a recuperação de desastres do Azure para o Azure pode ser uma solução aceitável. Nesse cenário, você migra a carga de trabalho para o primeiro datacenter do Azure usando um único cofre do Site Recovery e o design do servidor de configuração e processo. Depois de testar a carga de trabalho, você pode recuperá-la para um segundo datacenter do Azure a partir dos ativos migrados.

Essa abordagem reduz o efeito sobre os recursos no datacenter de origem. A recuperação de desastres do Azure para o Azure também aproveita as rápidas velocidades de transferência e os altos limites de largura de banda entre os datacenters do Azure.

Nota

A abordagem de recuperação de desastres do Azure para o Azure pode aumentar os custos de migração de curto prazo por meio de taxas mais altas de largura de banda de saída.

Alterações no processo de liberação

Ao abordar a complexidade global durante a otimização e a promoção, você pode exigir esforços idênticos em cada região para a qual implanta. Se você usar uma única região, ainda precisará replicar testes de negócios e planos de mudança de negócios.

Ações sugeridas durante o processo de liberação

Otimização pré-teste: Os testes iniciais de automação podem identificar potenciais oportunidades de otimização, como acontece com qualquer esforço de migração. Para cargas de trabalho globais, teste independentemente a carga de trabalho em cada região. Pequenas alterações de configuração na sua rede ou no datacenter do Azure escolhido podem afetar o desempenho.

Planos de mudança de negócios: crie um plano de mudança de negócios para qualquer cenário de migração complexo. Um plano de mudança de negócios ajuda a garantir uma comunicação clara sobre as alterações nos processos de negócios e nas experiências do usuário. O plano também ajuda a garantir uma comunicação clara sobre o calendário dos esforços necessários para integrar as mudanças. Em um esforço de migração global, o plano deve incluir considerações para os usuários em cada geografia afetada.

Testes de negócios: cada região também pode exigir testes de negócios. Os testes de negócios ajudam a garantir o desempenho adequado e a aderência aos padrões de roteamento de rede modificados.

Voos promocionais: a promoção geralmente acontece como uma única atividade e o tráfego de produção é imediatamente redirecionado para as cargas de trabalho migradas. Em um esforço de lançamento global, você deve oferecer promoção em coleções predefinidas de usuários chamadas voos. Os voos promocionais dão à equipe de estratégia de nuvem e à equipe de adoção de nuvem a oportunidade de observar o desempenho e melhorar o suporte aos usuários em cada região. Você pode controlar voos promocionais no nível de rede. Especificamente, você pode alterar o roteamento de intervalos de IP específicos dos ativos de carga de trabalho de origem para os ativos recém-migrados. Depois de migrar uma coleção especificada de usuários, você pode redirecionar o próximo grupo.

Otimização de voos: Um benefício dos voos promocionais é que eles oferecem observações mais profundas e uma oportunidade de otimizar os ativos implantados. Depois que o primeiro voo usa com êxito a produção por um breve período, você pode refinar os ativos migrados quando os procedimentos de operação de TI o suportarem.