Guia de decisão das regiões de Azure

Ao desenhar a sua estratégia para migrar para Azure, pode escolher entre muitas regiões de Azure em todo o mundo. Cada região de Azure tem características específicas que tornam essencial a escolha da região correta para os seus recursos Azure. As considerações incluem serviços disponíveis, capacidade, restrições e soberania:

  • Serviços disponíveis: Os serviços Azure que pode implementar em cada região diferem consoante vários fatores. Selecione uma região para o serviço que necessita para a sua carga de trabalho. Para obter mais informações, veja Produtos disponíveis por região.
  • Capacidade: Cada região tem uma capacidade máxima. A capacidade máxima de uma região pode afetar os tipos de subscrições que podem implantar que tipos de serviços e em que circunstâncias. A capacidade regional é diferente de uma quota de subscrição. Se está a planear uma migração de datacenter em larga escala para Azure, talvez queira consultar a sua equipa de campo Azure local ou o seu gestor de conta Azure para confirmar que pode implementar na escala de que necessita.
  • Constrangimentos: São colocados certos constrangimentos à implantação de serviços em determinadas regiões. Por exemplo, algumas regiões estão disponíveis apenas para apoio ou falha. Outras restrições que devem ser observadas são os requisitos de soberania dos dados.
  • Soberania: Certas regiões dedicam-se a entidades soberanas específicas. Embora todas as regiões sejam regiões de Azure, estas regiões soberanas estão isoladas do resto de Azure. Não são necessariamente geridos pela Microsoft, e podem estar restritos a certos tipos de clientes. Estas regiões soberanas são:

Funcionamento em várias regiões geográficas

Uma organização pode operar em várias regiões geográficas para alcançar a resiliência que é essencial para as suas operações. A operação em várias regiões geográficas introduz uma potencial complexidade nas seguintes formas:

  • Distribuição de recursos
  • Perfis de acesso de utilizadores
  • Requisitos de conformidade
  • Resiliência regional

A seleção da região é uma parte fundamental da sua estratégia geral de adoção em nuvem. Comece com considerações de rede.

Considerações de rede

Qualquer implementação de nuvem robusta requer uma rede bem ponderada que tenha em conta as diferenças nas regiões de Azure. Deve ter em conta os seguintes fatores:

  • As regiões do Azure são implementadas em pares. Cada região é emparelhada com outra região na mesma fronteira geopolítica para fornecer resiliência se ocorrer uma falha catastrófica da região. Uma exceção é Brazil South, que é emparelhada com South Central US.

    Considere a implantação em regiões emparelhadas como uma estratégia de resiliência primária e secundária. Aqui estão mais informações a considerar:

    • O Azure Storage suporta o armazenamento geo-redundante (GRS). No Azure Storage GRS, três cópias dos seus dados são armazenadas na sua região primária, e mais três cópias são armazenadas na região emparelhada. Não pode mudar o emparelhamento de armazenamento para GRS.
    • Os serviços que dependem do GRS do Armazenamento do Microsoft Azure podem tirar partido desta capacidade da região emparelhada. As suas aplicações e a sua rede devem estar configuradas para suportar regiões emparelhadas.
    • Se não planeia usar o GRS para suportar as suas necessidades regionais de resiliência, não deve usar a região emparelhada como secundária. Se ocorrer uma falha regional, é exercida uma pressão intensa sobre os recursos na região emparelhada à medida que os recursos migram. Pode evitar essa pressão recuperando-se para um local alternativo e ganhar velocidade durante a sua recuperação.

    Aviso

    Não tente utilizar o Azure Storage GRS para cópias de segurança ou recuperação de máquinas virtuais. Em vez disso, utilize Azure Backup, Azure Site Recovery e Azure geriu discos para suportar a resiliência da sua infraestrutura como uma carga de trabalho de serviço (IaaS).

    Para mais informações, consulte as regiões emparelhadas Azure.

  • O Azure Backup e o Azure Site Recovery funcionam em conjunto com a conceção da rede para facilitar a resiliência regional para as suas necessidades de IaaS e cópia de segurança de dados. Certifique-se de que a rede está otimizada, para que as transferências de dados permaneçam na espinha dorsal da Microsoft, e utilizem o espreitamento de rede virtual, se possível. Algumas organizações maiores que têm implantações globais podem, em vez disso, usar o Azure ExpressRoute Premium para encaminhar o tráfego entre regiões e potencialmente poupar taxas de saída regionais.

  • Os grupos de recursos Azure são específicos das regiões de Azure. Mas os recursos num grupo de recursos abrangem frequentemente várias regiões. Numa falha regional, as operações de controlo dos aviões contra um grupo de recursos falham na região afetada, mas os recursos noutras regiões desse grupo de recursos continuam a funcionar. A resiliência do grupo de recursos por região pode afetar a forma como projeta a sua rede e o seu grupo de recursos.

  • Muitas plataformas como serviços de serviço (PaaS) em suporte do Azure pontos finais de serviço ou Azure Private Link. Ambas estas soluções podem influenciar significativamente a forma como projeta a sua rede, uma vez que considera a resiliência regional, a migração e a governação.

  • Muitos serviços PaaS dependem das suas próprias soluções de resiliência regional. Por exemplo, em implementações para SQL do Azure Database e Azure Cosmos DB, você pode facilmente replicar para mais regiões. Alguns serviços da Azure, como o Azure DNS, não têm dependências regionais. Ao considerar quais os serviços que irá utilizar no seu processo de adoção na nuvem, certifique-se de que compreende claramente as capacidades de failover e as etapas de recuperação que podem ser necessárias para cada serviço Azure que utiliza.

  • Além de se deslocarem para várias regiões para apoiar a recuperação de desastres, muitas organizações optam por implementar um padrão ativo para evitar depender de falhas. Os benefícios da utilização de um padrão ativo incluem o equilíbrio global da carga, o aumento da tolerância à falha e o aumento do desempenho da rede. Para tirar partido deste padrão, as suas aplicações devem apoiar o funcionamento ativo em várias regiões.

Aviso

As regiões de Azure são construções altamente disponíveis. Os acordos a nível de serviços Azure são aplicados aos serviços em funcionamento em regiões específicas. Nunca deve implantar com uma única região dependência de aplicações críticas de missão. Planeie sempre o fracasso regional e pratique medidas de recuperação e mitigação.

Documente a complexidade do seu cenário

Depois de considerar a topologia da rede, determine se é necessária mais documentação e alinhamento de processos. A seguinte abordagem pode ajudá-lo a avaliar potenciais desafios e estabelecer um curso geral de ação:

  • Considere uma implementação de governação e preparação mais robusta.
  • Faça um inventário das geografias afetadas. Compilar uma lista dos países/regiões afetados.
  • Requisitos de soberania dos dados dos documentos. Os países/regiões identificados têm requisitos de conformidade que regem a soberania dos dados?
  • Documente a base de utilizadores. Os colaboradores, parceiros ou clientes do país/região identificado serão afetados pela migração na nuvem?
  • Documente os datacenters e os recursos. Existem ativos no país/região identificado que possam ser incluídos no esforço de migração?
  • Documente os requisitos de disponibilidade e ativação pós-falha das SKUs regionais.

Alinhar alterações ao longo do processo de migração para abordar o inventário inicial. A tabela a seguir mostra cenários de exemplo que podem ajudá-lo a documentar as suas descobertas:

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

Conheça os requisitos de soberania de dados

Em todo o mundo, organizações governamentais começaram a estabelecer regulamentos de soberania de dados e privacidade de dados. Estes tipos de requisitos de conformidade exigem frequentemente a localização num país/região específico para proteger os cidadãos naquele local. Em alguns casos, os dados relativos a clientes, colaboradores ou parceiros devem ser armazenados numa plataforma cloud na mesma região que o utilizador.

Enfrentar este desafio tem sido uma motivação significativa para as migrações em nuvem para organizações que operam à escala global. Para manter o cumprimento da soberania de dados, algumas organizações optaram por implantar ativos de TI duplicados para fornecedores de nuvem na região. Na tabela anterior, o cenário alemão é um bom exemplo. O cenário inclui clientes, parceiros e colaboradores, mas não os atuais consentimentos de TI na Alemanha. Esta organização pode optar por enviar alguns ativos para um datacenter dentro de uma área de regulação da soberania de dados, potencialmente utilizando os centros de dados alemães Azure. Uma compreensão dos dados que são afetados pelos regulamentos regionais de soberania de dados ajudaria a equipa de adoção em nuvem a compreender a melhor abordagem migratória para a organização.

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

Organizações que apoiam utilizadores em vários países/regiões desenvolveram soluções técnicas que abordam o tráfego de utilizadores. Em alguns casos, as soluções envolvem a localização de ativos. Noutros cenários, a organização poderá optar por implementar soluções globais de rede de área ampla (WAN) para abordar bases de utilizadores diferentes através de soluções focadas na rede. Em qualquer dos casos, a estratégia de migração pode ser afetada pelos perfis de utilização de utilizadores diferentes.

Se uma organização apoia colaboradores, parceiros e clientes na Alemanha sem ter atualmente centros de dados na Alemanha, a organização provavelmente implementou uma solução de linha alugada. Este tipo de solução encaminha o tráfego para centros de dados noutros países/regiões. Este encaminhamento existente apresenta um risco significativo para o desempenho observado das aplicações migradas. Injetar mais lúpulo num WAN global estabelecido e afinado pode criar a perceção de aplicações de baixo desempenho após a migração. Encontrar e corrigir estes problemas pode acrescentar atrasos significativos a um projeto.

Em cada um dos seguintes processos, a orientação para abordar esta complexidade está incluída em todos os pré-requisitos e processos de avaliação, migração e otimização. A compreensão dos perfis dos utilizadores em cada país/região é fundamental para gerir adequadamente esta complexidade.

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

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

Decisões de arquitetura: Determinar a região-alvo é um dos primeiros passos no desenho da estratégia de migração. Esta determinação é frequentemente influenciada pela localização dos ativos existentes. Além disso, a disponibilidade de serviços em nuvem e o custo unitário desses serviços podem variar entre regiões. A compreensão de onde os ativos atuais e futuros estão localizados afeta as decisões de arquitetura, e pode influenciar as estimativas orçamentais.

Dependências do Datacenter: Os cenários de exemplo na tabela da complexidade do Documento mostram que provavelmente terá de planear dependências entre vários centros de dados globais. As dependências podem não ser documentadas ou compreendidas claramente em muitas organizações que operam a esta escala. A abordagem da sua organização para avaliar os perfis dos utilizadores ajuda-o a identificar algumas destas dependências na sua organização. A sua equipa também deve explorar mais etapas de avaliação que possam ajudar a mitigar os riscos e complexidades que surgem das dependências.

Implementar uma abordagem geral

A seguinte abordagem utiliza um modelo orientado por dados para abordar as complexidades migratórias globais. Quando o âmbito de uma migração inclui várias regiões, a equipa de adoção em nuvem deve avaliar as seguintes considerações de prontidão:

  • A soberania dos dados pode exigir a localização de alguns ativos, mas muitos ativos podem não ser regidos por esses constrangimentos de conformidade. Coisas como o registo, reporte, encaminhamento de rede, identidade e outros serviços centrais de TI podem ser elegíveis para serem hospedados como serviços partilhados em várias subscrições ou várias regiões. A equipa de adoção em nuvem deve avaliar a soberania dos dados utilizando um modelo de serviço partilhado para esses serviços, tal como delineado na arquitetura de referência para uma topologia falada por hub com serviços partilhados.
  • Quando se está a implementar múltiplas instâncias de ambientes semelhantes, usar uma fábrica de ambiente pode ajudar a criar consistência, melhorar a governação 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 baseados em dados

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

  • Descoberta geral completa: Complete a tabela na complexidade do Documento para avaliar a complexidade da sua estratégia de adoção em nuvem.
  • Analise os perfis dos utilizadores em cada país/região afetado: É importante compreender o encaminhamento geral do utilizador no início do processo de migração. A alteração das linhas de concessão globais e a adição de ligações como o ExpressRoute a um datacenter da cloud pode exigir meses de atrasos de rede. Endereça o encaminhamento do utilizador o mais cedo possível.
  • Complete uma racionalização inicial da propriedade digital: Quando a complexidade é introduzida numa estratégia de migração, deve completar uma racionalização inicial do imóvel digital. Para mais informações, veja o que é uma propriedade digital?
  • Utilizar a marcação para os requisitos de propriedade digital: Estabeleça políticas de marcação para identificar qualquer carga de trabalho afetada pelos requisitos de soberania de dados. As etiquetas exigidas devem começar na racionalização do imobiliário digital e levar para os ativos migrados.
  • Avaliar um modelo de hub-spoke: Os sistemas distribuídos partilham frequentemente dependências comuns. Muitas vezes, pode abordar dependências partilhadas implementando um modelo falador de hub. Embora a implementação de um modelo de hub-spoke esteja fora do alcance do processo de migração, sinalize o modelo para consideração durante futuras iterações dos processos prontos.
  • Priorizar o atraso da migração: Quando são necessárias alterações na rede para apoiar a implementação da produção de uma carga de trabalho que suporte várias regiões, a equipa de estratégia de nuvem deve acompanhar e gerir as escaladas resultantes das mudanças de rede. O maior nível de suporte executivo ajuda a acelerar a mudança, libertando a equipa de estratégia para repriorizar os atrasos e garantir que as cargas de trabalho globais não sejam bloqueadas por mudanças de rede. Priorize as cargas de trabalho globais apenas quando as alterações de rede estiverem terminadas.

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

Avaliar alterações do processo

Quando a sua organização enfrenta complexidades globais de ativos e bases de utilizadores num cenário de migração, deve adicionar algumas atividades-chave para avaliar os seus candidatos à migração. Estas atividades produzem dados para clarificar obstáculos e resultados para utilizadores e ativos globais.

Ação sugerida durante o processo de avaliação

Avaliar as dependências do centro de dados cruzados: As ferramentas de visualização de dependência em Azure Migrate podem ajudá-lo a identificar dependências. Uma das melhores práticas é usar estas ferramentas antes de começar a migração. Quando a complexidade global está envolvida, torna-se um passo necessário no processo de avaliação. Através do agrupamento de dependência, a visualização da dependência pode ajudá-lo a identificar os endereços IP e portas de quaisquer ativos que sejam necessários para suportar a carga de trabalho.

Importante

  • Um perito em matéria de assuntos que tenha uma compreensão da colocação de ativos e esquemas de endereços IP é obrigado a identificar ativos que estão localizados num centro de dados secundário.
  • Avaliar tanto as dependências a jusante como os clientes na visualização para compreender as dependências bidirecionais.

Identificar o impacto global do utilizador: As saídas da análise do perfil de utilizador pré-requisito devem identificar qualquer carga de trabalho afetada pelos perfis globais do utilizador. Quando um candidato à migração está na lista das cargas de trabalho afetadas, o arquiteto da migração deve consultar especialistas em assuntos de networking e operações. Estes especialistas ajudam a validar o encaminhamento de rede e as expectativas de desempenho. No mínimo, a arquitetura deve incluir uma ligação ExpressRoute entre o centro de operações de rede mais próximo e a Azure. A arquitetura de referência para ligações ExpressRoute pode ajudá-lo a configurar as ligações de rede necessárias.

Design para conformidade: As saídas da análise do perfil do utilizador pré-requisito também devem 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 especialistas em matéria de conformidade. Estes especialistas podem ajudar o arquiteto a entender quaisquer requisitos para migração e implantação em várias regiões. Esses requisitos afetam significativamente as estratégias de conceção. As arquiteturas de referência para aplicações web multi-região e aplicações multi-regionion n-tier podem ajudar com o design.

Aviso

Quando estiver a usar a arquitetura de referência para ExpressRoute ou as arquiteturas de referência para aplicações, poderá ser necessário excluir elementos de dados específicos dos processos de replicação para satisfazer os requisitos de soberania de dados. A tarefa de excluir elementos de dados específicos adiciona um passo no processo de promoção.

Alterações no processo de migração

Ao migrar uma aplicação que deve ser implantada em várias regiões, a equipa de adoção em nuvem deve ter em conta mais algumas considerações. As considerações consistem no design do cofre Site Recovery Azure, configuração e design de servidor de processo, desenhos de largura de banda de rede e sincronização de dados.

Ação sugerida durante o processo de migração

Azure Site Recovery design de cofre: Azure Site Recovery é a ferramenta sugerida para replicação nativa em nuvem e sincronização de ativos digitais para Azure. O Site Recovery replica dados sobre o recurso para um cofre do Site Recovery, que está vinculado a uma subscrição específica numa região específica e num datacenter do Azure. Quando se está a replicar ativos numa segunda região, também pode precisar de um segundo cofre Site Recovery.

Configuração e design do servidor de processo: Site Recovery funciona com uma instância local de um servidor de configuração e processo, que está ligado a um único cofre Site Recovery. A configuração significa que poderá ser necessário instalar uma segunda instância destes servidores no datacenter de origem para facilitar a replicação.

Design de largura de banda de rede: Durante a replicação e sincronização contínua, move-se dados binários sobre a rede, desde o datacenter de origem até ao cofre de Site Recovery no centro de dados target Azure. O processo de replicação e sincronização consome largura de banda. Duplicar a carga de trabalho para uma segunda região duplica a quantidade de largura de banda consumida. Se a largura de banda for limitada ou se uma carga de trabalho envolver uma configuração substancial ou deriva de dados, replicar dados para uma segunda região pode interferir com o tempo que leva para completar a migração. Mais importante ainda, estes constrangimentos podem afetar a experiência dos utilizadores ou aplicações que ainda dependem da largura de banda que estava disponível no datacenter de origem.

Sincronização de dados: Muitas vezes, o maior dreno de largura de banda vem da sincronização da plataforma de dados. Tal como definido nas arquiteturas de referência para aplicações web multi-região e aplicações multi-regionion n-tier, a sincronização de dados é frequentemente necessária para manter as aplicações alinhadas. Se manter as aplicações sincronizadas é o estado operacional que pretende para as suas aplicações, é melhor sincronizar a plataforma de dados de origem com cada plataforma cloud. Deve fazer isso antes de migrar a aplicação e os ativos de nível médio.

Recuperação de desastres Azure-to-Azure: Uma opção alternativa pode reduzir ainda mais a complexidade. Se os prazos e a sincronização de dados significar que poderá ter de fazer uma implantação em duas etapas, a recuperação de desastres Azure-to-Azure pode ser uma solução aceitável. No cenário, migra a carga de trabalho para o primeiro datacenter Azure utilizando um único Site Recovery cofre e configuração ou design de servidor de processo. Depois de testar a carga de trabalho, pode recuperar a carga de trabalho para um segundo centro de dados Azure dos ativos migrados. A abordagem reduz o efeito sobre os recursos no datacenter de origem e tira partido de velocidades de transferência mais rápidas e limites elevados de largura de banda entre os datacenters Azure.

Nota

A abordagem de recuperação de desastres Azure-to-Azure pode aumentar os custos de migração a curto prazo através de taxas de largura de banda mais elevadas.

Otimizar e promover as alterações do processo

Ao abordar a complexidade global durante a otimização e promoção, poderá necessitar de esforços idênticos em cada uma das outras regiões. Quando uma única implementação é aceitável, poderá ainda ser necessário replicar testes de negócio e planos de mudança de negócio.

Ação sugerida durante o processo de otimização e promoção

Otimização pré-teste: Os testes iniciais de automatização podem identificar potenciais oportunidades de otimização, como em 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 Azure que escolher podem afetar o desempenho.

Planos de mudança de negócio: Para qualquer cenário de migração complexo, crie um plano de mudança de negócio. A utilização de um plano de mudança de negócios ajuda a garantir uma comunicação clara sobre quaisquer alterações aos processos de negócio e experiências dos utilizadores, e sobre o calendário dos esforços necessários para integrar as alterações. Num esforço global de migração, o plano deve incluir considerações para os utilizadores em cada geografia afetada.

Testes de negócio: Para além de um plano de mudança de negócio, podem ser necessários testes de negócio em cada região. Os testes de negócios em cada região ajudam a garantir um desempenho e a adesão adequados aos padrões de encaminhamento de rede modificados.

Voos de promoção: Muitas vezes, a promoção acontece como uma única atividade, e o tráfego de produção é imediatamente reencaminhado para as cargas de trabalho migradas. Num esforço de lançamento global, deve oferecer promoção em voos, que são coleções predefinidas de utilizadores. A utilização de voos de promoção dá à equipa de estratégia de nuvem e à equipa de adoção em nuvem a oportunidade de observar o desempenho e melhorar o apoio aos utilizadores em cada região. Os voos de promoção são frequentemente controlados ao nível da rede, alterando o encaminhamento de gamas IP específicas, desde os ativos de carga de trabalho de origem para os ativos recém-migrados. Depois de migrar uma recolha especificada de utilizadores, o próximo grupo pode ser reencaminhado.

Otimização de voos: Um dos benefícios da utilização de voos de promoção é que você tem observações mais profundas e uma oportunidade para otimizar os ativos implantados. Após o primeiro voo utilizar com sucesso a produção por um breve período de tempo, pode refinar os ativos migrados quando os procedimentos de operação de TI o suportam.