Linha de base de migração de zonas de disponibilidade do Azure
Este artigo mostra como avaliar a preparação da zona de disponibilidade do aplicativo para fins de migração da zona de não disponibilidade para o suporte à zona de disponibilidade. Orientaremos você pelas etapas necessárias para determinar como você pode aproveitar o suporte à zona de disponibilidade em alinhamento com requisitos regionais e de aplicativo. Para obter mais informações detalhadas sobre zonas de disponibilidade e as regiões que dão suporte a elas, consulte O que são zonas de disponibilidade e regiões do Azure.
Ao criar cargas de trabalho confiáveis, você pode escolher pelo menos uma das seguintes configurações de zona de disponibilidade:
Zonal. Uma configuração zonal fornece uma zona de disponibilidade específica e auto-selecionada.
Redundância de zona. Uma configuração com redundância de zona fornece os recursos que são replicados ou distribuídos entre zonas automaticamente.
Além das duas opções de zona de disponibilidade, zonal e com redundância de zona, o Azure oferece Serviços globais, o que significa que eles estão disponíveis globalmente, independentemente da região. Como esses serviços estão sempre disponíveis entre regiões, eles são resilientes a interrupções regionais e zonais.
Para ver quais serviços do Azure dão suporte a zonas de disponibilidade, consulte o Serviço de zona de disponibilidade e o suporte regional.
Observação
Quando você não seleciona uma configuração de zona para seu recurso, com redundância de zona ou zonal, o recurso e seus subcomponentes não serão resilientes à zona e poderão ficar inativos durante uma interrupção zonal nessa região.
Considerações para migrar para o suporte à zona de disponibilidade
Há várias maneiras possíveis de criar um aplicativo confiável do Azure com zonas de disponibilidade que atendem aos destinos de confiabilidade e SLAs. Siga as etapas abaixo para escolher a abordagem correta para suas necessidades com base nas considerações técnicas e regulatórias, recursos de serviço, residência de dados, requisitos de conformidade e latência.
Etapa 1: verificar se a região do Azure dá suporte a zonas de disponibilidade
Nesta primeira etapa, você precisará validar que a região do Azure selecionada dá suporte a zonas de disponibilidade, bem como aos serviços necessários do Azure para seu aplicativo.
Se sua região der suporte a zonas de disponibilidade, recomendamos que você configure sua carga de trabalho para zonas de disponibilidade. Se sua região não der suporte a zonas de disponibilidade, você precisará usar diretrizes do Azure Resource Mover para migrar para uma região que ofereça suporte à zona de disponibilidade.
Observação
Para alguns serviços, as zonas de disponibilidade só podem ser configuradas durante a implantação. Se você quiser incluir zonas de disponibilidade para serviços existentes, talvez seja necessário reimplantar. Consulte a documentação específica do serviço na Visão geral das diretrizes de migração de zona de disponibilidade para produtos e serviços do Microsoft Azure.
Etapa 2: verificar a disponibilidade de produto e SKU na região do Azure
Nesta etapa, você validará que os serviços e SKUs do Azure necessários estão disponíveis nas zonas de disponibilidade da região do Azure selecionada.
Para verificar o suporte regional dos serviços, confira Produtos disponíveis por região.
Para listar os SKUs de VM disponíveis por zona e região do Azure, consulte Verificar a disponibilidade de SKU da VM.
Se sua região não der suporte aos serviços e SKUs necessários ao seu aplicativo, você precisará voltar para a Etapa 1: verifique a disponibilidade do produto na região do Azure para encontrar uma nova região que dê suporte aos serviços e SKUs necessários ao seu aplicativo. Recomendamos que você configure sua carga de trabalho com redundância de zona.
Para alta disponibilidade zonal de máquinas virtuais IaaS do Azure, use VMSS (Conjuntos de Dimensionamento de Máquinas Virtuais) Flexível para espalhar VMs entre várias zonas de disponibilidade.
Etapa 3: considerar os requisitos do seu aplicativo
Nesta etapa final, você determinará, com base nos requisitos do aplicativo, qual tipo de suporte de zona de disponibilidade é mais adequado para seu aplicativo.
Abaixo estão três perguntas importantes que ajudarão você a escolher a implantação correta da zona de disponibilidade:
Seu aplicativo inclui componentes sensíveis à latência?
As zonas de disponibilidade do Azure na mesma região do Azure são conectadas por uma rede de alto desempenho com uma latência de viagem de ida e volta de menos de 2 ms.
A abordagem recomendada para alcançar alta disponibilidade, se a baixa latência não for um requisito estrito, é configurar sua carga de trabalho com uma implantação com redundância de zona.
Para componentes de aplicativo críticos que exigem proximidade física e baixa latência, como jogos, simulação de engenharia e HFT (negociação de alta frequência), recomendamos que você configure uma implantação zonal. Conjuntos de Dimensionamento de Máquinas Virtuais Flexíveis fornecem computação alinhada à zona juntamente com discos de armazenamento anexados.
O código do aplicativo tem a preparação para lidar com um modelo distribuído?
Para um modelo de microsserviços distribuído e, dependendo do aplicativo, há a possibilidade de troca de dados contínua entre microsserviços nas zonas. Essa troca contínua de dados por meio de APIs pode afetar o desempenho. Para melhorar o desempenho e manter uma arquitetura confiável, você pode escolher a implantação zonal.
Com uma implantação zonal, você deve:
Identificar os recursos ou serviços sensíveis à latência em sua arquitetura.
Confirmar se os serviços ou recursos sensíveis à latência dão suporte à implantação zonal.
Co-localizar os recursos ou serviços sensíveis à latência na mesma zona. Outros serviços em sua arquitetura podem continuar com redundância de zona.
Replicar os serviços zonais sensíveis à latência em várias zonas de disponibilidade para garantir a resiliência da zona.
Realizar balanceamento de carga entre as várias implantações zonais com um balanceador de carga padrão ou global.
Se o serviço do Azure der suporte a zonas de disponibilidade, recomendamos que você use redundância de zona espalhando nós pelas zonas para obter maior proteção contra interrupções zonais e SLA de tempo de atividade.
Para um aplicativo de 3 camadas, é importante entender as camadas de aplicativo, negócios e dados, bem como seu estado (com estado ou sem estado) para arquitetar em alinhamento com as melhores práticas e diretrizes de acordo com o tipo de carga de trabalho.
Para cargas de trabalho especializadas no Azure como os exemplos abaixo, consulte as respectivas diretrizes e práticas recomendadas de arquitetura de zona de destino.
SAP
Área de Trabalho Virtual do Azure
Serviço de Kubernetes do Azure
- Criar um cluster do Serviço de Kubernetes do Azure (AKS) que usa zonas de disponibilidade
- Considerações sobre o gerenciamento de operações do Serviço de Kubernetes do Azure
- Migrar cargas de trabalho do Servidor Flexível do MySQL e do AKS (Serviço de Kubernetes do Azure) para dar suporte à zona de disponibilidade
Oracle
Deseja alcançar a continuidade dos negócios e recuperação de desastres na mesma região do Azure devido aos requisitos de conformidade, residência de dados ou governança?
Para alcançar a continuidade dos negócios e recuperação de desastres na mesma região e quando não houver par regional, recomendamos que você configure sua carga de trabalho com redundância de zona. Uma abordagem de região única também é aplicável a determinados setores que têm requisitos estritos de governança e residência de dados na mesma região do Azure. Para aprender como replicar, fazer failover e failback de máquinas virtuais do Azure de uma zona de disponibilidade para outra na mesma região do Azure, consulte Habilitar a recuperação de desastre de VM do Azure entre zonas de disponibilidade.
Se você precisar de várias regiões ou se sua região do Azure não oferecer suporte a zonas de disponibilidade, recomendamos que você use pares regionais. Pares regionais estão situados a uma distância de cerca de 160 km e oferecem proteção de raio de alcance contra falhas de nível regional, como incêndio, inundações, terremotos e outros desastres naturais ou imprevistos. Para obter mais informações, confira Replicação entre regiões no Azure: continuidade dos negócios e recuperação de desastres.
Observação
Pode haver cenários em que uma combinação de serviços zonais, com redundância de zona e globais funciona melhor para atender aos requisitos técnicos e comerciais.
Outros pontos que devem ser considerados
Para saber mais sobre como testar seus aplicativos quanto à disponibilidade e resiliência, consulte Testar aplicativos para disponibilidade e resiliência.
Cada data center em uma região é atribuído a uma zona física. As zonas físicas são mapeadas para zonas lógicas em sua assinatura do Azure. As assinaturas do Azure são automaticamente atribuídas a esse mapeamento no momento em que uma assinatura é criada. Você pode usar a API REST do ARM dedicada, listLocations e definir a versão da API como 2022-12-01 para listar o mapeamento de zona lógica como zona física para sua assinatura. Essas informações são importantes para componentes críticos do aplicativo que exigem co-localização com recursos do Azure categorizados como Serviços estratégicos que podem não estar disponíveis em todas as zonas físicas.