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

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ão envolve as seguintes etapas de alto nível:

• Revise as principais diretrizes de seleção de região do Azure para entender como selecionar regiões do Azure que atendam aos seus requisitos.
• Faça um inventário e documente o estado atual do seu ambiente.
• Implemente uma abordagem geral para sua migração, incluindo se deseja executar em uma única região, usar várias zonas de disponibilidade ou usar várias regiões.
• Avalie as alterações de processo que podem ser necessárias.
• Planejar 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 suas regiões de zona de aterrissagem para oferecer suporte a abordagens de várias regiões.

Observação

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.

Documentar a complexidade do cenário

Determine se o cenário requer documentação e alinhamento de processos. A abordagem a seguir pode ajudar a avaliar os possíveis desafios e estabelecer um curso geral de ação:

• Considere uma prontidão e uma implementação de governança mais robustas.
• 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?
• Documentar datacenters e ativos. O esforço de migração inclui algum ativo no país ou região identificados?
• 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 requisitos específicos de soberania ou residência de dados podem influenciar sua escolha de regiões do Azure.

Durante todo o 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.

Region	País/região	Funcionários locais	Usuários externos locais	Datacenters e ativos locais	Requisitos de soberania de dados
América do Norte	Estados Unidos	Yes	Parceiros e clientes	Sim	Não
América do Norte	Canadá	Não	Clientes	Sim	Yes
Europa	Alemanha	Yes	Parceiros e clientes	Não – Apenas rede	Yes
Pacífico Asiático	Coreia do Sul	Yes	Parceiros	Sim	Não

Por que a localização dos usuários é 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 WAN (rede de longa distância) globais, para abordar bases de usuários diferentes por meio de soluções com foco 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. Esse roteamento existente apresenta um risco significativo para o desempenho percebido dos aplicativos migrados. Injetar mais saltos em uma WAN global estabelecida e ajustada pode criar a percepção de aplicativos com desempenho abaixo do esperado após a migração. Encontrar e corrigir esses problemas pode adicionar atrasos significativos a um projeto.

Cada uma das seções a seguir inclui orientações para lidar com 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.

Por que a localização dos datacenters é relevante?

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 muitas vezes influencia essa determinação. Além disso, a disponibilidade dos serviços de nuvem e o custo unitário desses serviços podem variar entre as 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 Documentar a complexidade do seu 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 organização para avaliar perfis de usuário ajuda a identificar algumas dessas dependências na organização. Sua equipe também deve explorar mais etapas de avaliação que possam ajudar a mitigar os riscos e as complexidades decorrentes das dependências.

Implementar uma abordagem geral

A abordagem a seguir usa um modelo controlado por dados para resolver as complexidades de migração global. Se o escopo da migração incluir várias regiões, a equipe de adoção da nuvem deverá avaliar as seguintes considerações de prontidã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 de várias regiões.

• Avaliar a soberania dos dados: a soberania dos 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 estar 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 uma estrutura geral 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 governança para empresas complexas estabelece uma abordagem que cria um ambiente dimensionado em várias regiões.

Pré-requisitos controlados 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:

• Concluir a descoberta geral: preencha a tabela em Complexidade do documento para avaliar a complexidade da estratégia de adoção de nuvem.

• Analise os perfis de usuário para cada país ou região afetado: é importante entender o roteamento geral de usuários no início do processo de migração. Alterar linhas de locação globais e adicionar conexões como o Azure ExpressRoute a um datacenter de nuvem pode resultar em meses de atrasos de rede. Resolva o roteamento do usuário o quanto antes no processo.

• Conclua uma racionalização inicial de propriedade digital: se você introduzir complexidade em uma estratégia de migração, conclua uma racionalização inicial de propriedade digital. Para obter mais informações, consulte O que é uma propriedade digital?.

• Usar marcação para requisitos de patrimônio digital: estabeleça as políticas de marcação para identificar as cargas de trabalho afetadas pelos requisitos de soberania de dados. Garantir que as tags necessárias comecem na racionalização do patrimônio digital e sigam para os ativos migrados.

• Avaliar um modelo hub e 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 e spoke esteja fora do escopo do processo de migração, sinalize o modelo para consideração durante futuras iterações dos processos prontos.

• Priorizar 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 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 as cargas de trabalho globais. Priorize as cargas de trabalho globais somente quando as alterações de rede forem concluídas.

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

Avaliar alterações no processo

Se o cenário de migração envolver complexidades globais de ativos e 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ências no Azure Migrate podem ajudá-lo a identificar dependências. Use essas ferramentas antes de iniciar 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 o posicionamento de ativos e os esquemas de endereço IP para identificar ativos localizados em um datacenter secundário.
• Avalie dependências downstream e clientes na visualização para entender 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 de rede e de desempenho. No mínimo, a arquitetura deve incluir uma conexão do ExpressRoute entre o centro de operações de rede mais próximo e o Azure. A arquitetura de referência para conexões do ExpressRoute pode ajudar 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 PMEs de conformidade. Esses especialistas podem ajudar o arquiteto a entender os requisitos de migração e implantação em várias regiões. Esses requisitos afetam significativamente as estratégias de design. As seguintes arquiteturas de referência podem ajudar com o design:

• Aplicativos Web com redundância de zona
• Aplicativos Web de várias regiões
• Aplicativos de n camadas de várias regiões
• Modelos de carga de trabalho para uma zona de aterrissagem soberana

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.

Mudanças no processo de migração

Se você migrar um aplicativo que deve ser implantado em várias regiões, a equipe de adoção da 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 os designs de largura de banda de rede e a sincronização de dados.

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

Design do cofre da Recuperação de Site: a Recuperação de Site é a ferramenta sugerida para replicação nativa da nuvem e sincronização de ativos digitais com o Azure. A Recuperação de Site replica dados sobre cada ativo para um cofre de Recuperação de Site. Esse 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, talvez também precise de um segundo cofre da Recuperação de Site.

Configuração e design do servidor de processo: a Recuperação de Site funciona com uma instância local de um servidor de configuração e processo vinculado a um único cofre da Recuperação de Site. 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 da Recuperação de Site 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, a replicação de dados para uma segunda região pode interferir no tempo necessário para concluir a migração. Mais importante, 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 várias camadas de várias regiões.

Se manter os aplicativos sincronizados for o estado operacional desejado para os 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 da camada intermediária.

Recuperação de desastres do Azure para 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 sincronização de dados e linha do tempo, 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 design de servidor de configuração e processo. Depois de testar a carga de trabalho, você pode recuperá-la para um segundo data center 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 velocidades de transferência rápidas e os altos limites de largura de banda entre os datacenters do Azure.

Observação

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 cobranças mais altas de largura de banda de saída.

Alterações no processo de liberação

À medida que você lida com a complexidade global durante a otimização e a promoção, talvez seja necessário esforços idênticos em cada região implantada. Se você usar uma única região, talvez ainda precise replicar os planos de teste e alteração de negócios.

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

Otimização pré-teste: o teste de automação inicial pode identificar possíveis oportunidades de otimização, como ocorre com os esforços de migração. Para cargas de trabalho globais, teste de maneira independente a carga de trabalho em cada região. Pequenas alterações de configuração em sua rede ou no datacenter do Azure escolhido podem afetar o desempenho.

Planos de alteração de negócios: crie um plano de alteração 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 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 momento dos esforços necessários para integrar as mudanças. Em uma iniciativa de migração global, o plano deve incluir considerações para usuários em cada região geográfica afetada.

Teste de negócios: cada região também pode exigir testes de negócios. O teste de negócios ajuda a garantir o desempenho adequado e a aderência a padrões de roteamento de rede modificados.

Voos de promoção: 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 entregar promoções em coleções predefinidas de usuários chamadas voos. Os voos de promoção 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 de promoção 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 voo: Um benefício dos voos promocionais é que eles oferecem observações mais profundas e uma oportunidade de otimizar os ativos implantados. Depois que a primeira versão de pré-lançamento usar com sucesso a produção por um breve período, você poderá refinar os ativos migrados quando os procedimentos de operação de TI permitirem.