Recursos zonais e resiliência das zonas

No Azure, um recurso zonal é um recurso que está fixado numa única zona. Como um recurso zonal está numa única zona de disponibilidade, não é resiliente a zonas. Se a zona que contém o recurso tiver um problema, é provável que o recurso sofra tempo de inatividade.

Alguns serviços Azure exigem ou permitem implementar recursos zonais. Pode optar por implantar um recurso zonalmente devido a considerações de latência ou requisitos específicos de serviço. Podes fixar recursos individuais ou conjuntos de recursos relacionados numa única zona.

Este artigo descreve cenários em que poderá optar por implementar recursos zonais em vez de recursos redundantes por zona. Destaca também as considerações e responsabilidades necessárias para garantir que a sua solução se mantém resiliente a falhas de zona.

Tipos de implementação de recursos

No Azure, apenas alguns tipos de implementação proporcionam resiliência de zonas. A tabela seguinte compara três tipos de implementação de recursos e descreve a sua resiliência de zonas, distribuição de zonas, opções de configuração e recomendações.

Para mais informações sobre zonas de disponibilidade e implementações de recursos, consulte Zonas de Disponibilidade.

Cargas de trabalho que combinam recursos redundantes por zona e zonais

Muitas cargas de trabalho combinam recursos redundantes em múltiplas zonas e recursos zonais. Por exemplo, a sua carga de trabalho pode incluir um conjunto de máquinas virtuais zonais (VMs) para o seu nível de base de dados, um servidor web redundante de zona alojado no Azure App Service e um balanceador de carga redundante de zona para enviar tráfego para as suas VMs de base de dados.

Quando combina recursos zonais e redundantes de zona numa carga de trabalho, considere como cada recurso e a solução global se comportam caso uma zona de disponibilidade tenha um problema. Normalmente, os serviços redundantes de zona recuperam automaticamente de falhas de zona com perda mínima ou inexistente de dados, e a Microsoft gere todo o processo. Para recursos zonais, és responsável por configurar o failover automatizado ou por realizar atividades de recuperação manual. Para saber como cada serviço se comporta durante cenários de zona descida, compreender as suas responsabilidades versus responsabilidades da Microsoft e monitorizar a saúde dos serviços durante eventos de zona descida, consulte o guia de fiabilidade do seu serviço.

Quando usar uma implantação zonal

Usa recursos zonais apenas quando houver uma necessidade clara. Razões típicas para uma implementação numa única zona incluem casos em que um recurso deve ser zonal, um serviço está disponível apenas numa zona específica, ou uma carga de trabalho é altamente sensível à latência interzonal.

Recursos que requerem implantações zonais

Alguns serviços Azure apenas suportam implementações zonais e não fornecem implementações redundantes por zona.

As VMs são um recurso zonal. Pode usar conjuntos de escalas de máquinas virtuais para criar conjuntos de VMs. Os Conjuntos de Escala de Máquinas Virtuais podem ser feitos abrangendo zonas, o que significa que as VMs do conjunto estão distribuídas por múltiplas zonas. Os conjuntos de escala são uma boa forma de alcançar resiliência de zonas para muitas cargas de trabalho baseadas em VMs.

Outro exemplo é o Azure NetApp Files, que suporta a implantação de volumes numa única zona. O serviço também oferece uma forma de replicar entre múltiplos volumes zonais.

Alguns serviços oferecem opções disponíveis apenas em zonas específicas. Por exemplo, tipos específicos de VM que utilizam unidades avançadas de processamento gráfico (GPUs) podem estar disponíveis apenas em zonas específicas dentro de uma região, o que significa que não podem ser implementadas em múltiplas zonas. Para verificar quais regiões e zonas oferecem suporte aos tipos de VM necessários, use os seguintes recursos:

• Para verificar os tipos de VM disponíveis em cada região, consulte Produtos disponíveis por região.

• Para verificar os tipos e tamanhos de VM suportados em cada zona de uma região específica, consulte Verificar a disponibilidade de SKU de VM.

Se o tipo de VM de que precisa estiver disponível apenas numa única zona dentro da região que utiliza, pode considerar uma implementação zonal para essa VM e depois encontrar outras formas de tornar a VM resiliente a falhas de zona. Mas deve continuar a garantir que as outras partes da sua solução são resilientes em zonas.

Para mais informações, consulte os serviços Azure que suportam zonas de disponibilidade.

Latência entre zonas

Se tiver uma carga de trabalho invulgarmente sensível à latência, pode usar recursos zonais em vez de recursos redundantes por zona, mesmo que um serviço suporte implementações redundantes por zona.

Uma rede de baixa latência liga zonas de disponibilidade, com uma latência de ida e volta entre zonas tipicamente inferior a dois milissegundos. Para a maioria das cargas de trabalho, a latência entre zonas não é uma preocupação. Os benefícios de resiliência de distribuir recursos entre zonas de disponibilidade são mais importantes do que o impacto mínimo no desempenho de enviar tráfego entre zonas. Mas algumas cargas de trabalho são altamente sensíveis à latência interzonal. Estas cargas de trabalho podem incluir os seguintes cenários:

• Aplicações legadas on-premises: Algumas cargas de trabalho legadas podem conter aplicações que foram originalmente concebidas para um ambiente local. Estas cargas de trabalho assumem que componentes, como bases de dados e outras aplicações e serviços, estão co-localizados no mesmo host ou em proximidade física próxima.

• Replicação síncrona de muito alta escala: Aplicações e bases de dados com estado ocasionalmente realizam um número muito elevado de escritas usando replicação síncrona. Replicação síncrona significa que os dados são escritos em múltiplas réplicas antes de a operação de escrita ser considerada concluída. Distribuir réplicas entre zonas de disponibilidade melhora a resiliência, mas quando se usa replicação síncrona, a latência entre zonas pode aumentar a latência de escrita da carga de trabalho. Este aumento da latência normalmente não é significativo, mas devido à forma como algumas aplicações são desenhadas, pode por vezes tornar-se problemático em grande escala.

Se suspeitar que a latência interzona está a afetar a sua carga de trabalho, teste o seu impacto num ambiente realista seguindo estes passos para a sua carga de trabalho específica:

1. Defina requisitos de desempenho aceitáveis. O tráfego entre zonas adiciona uma pequena quantidade de latência, mas é negligenciável para a maioria das cargas de trabalho. Define como é o desempenho aceitável para a tua carga de trabalho.

2. Execute um teste de desempenho dentro de uma única zona de disponibilidade. Estabeleça um conjunto de métricas de desempenho base.

   Importante

   Teste a sua carga de trabalho, incluindo as suas aplicações, protocolos, configuração e região Azure. Use uma carga realista. Benchmarks e testes sintéticos não são suficientes porque não mostram como a sua solução realmente se comporta.

3. Ativar a replicação entre zonas. Dependendo dos componentes que usares, podes ativar redundância de zonas ou mover réplicas entre zonas.

4. Refazer testes de desempenho. Recolhe as mesmas métricas que recolheu anteriormente.

5. Compare o impacto no desempenho com os seus requisitos. Utilize os seus requisitos e os dados de desempenho para tomar uma decisão informada sobre o equilíbrio entre latência e resiliência face a falhas de zona.

   Se o teste demonstrar que a latência é inaceitavelmente alta para a sua carga de trabalho, considere tomar as seguintes ações:

   • Tenta usar outro conjunto de zonas. Pode haver uma ligeira variabilidade na latência entre diferentes zonas porque podem ter distâncias físicas diferentes umas das outras.

     Sugestão

     Se estiver a testar entre subscrições do Azure, reveja o mapeamento lógico para a zona física para garantir que está a testar os conjuntos de zonas físicas que pretende.

   • Se houver outra região Azure que satisfaça as tuas necessidades gerais de residência de dados e outros fatores, tenta usar várias zonas nessa região.

   • Considere se pode redesenhar a sua aplicação para minimizar a comunicação interzona necessária. Por exemplo, pode ser possível consolidar várias operações de pequenas bases de dados numa única operação. Esta abordagem pode reduzir o impacto da latência na sua carga de trabalho.

   Se nenhuma destas ações ajudar, considere executar a carga de trabalho específica ou os componentes dentro de uma única zona de disponibilidade usando VMs zonais e outros serviços Azure suportados. Depois, assume a responsabilidade de tornar os componentes zonais resilientes a falhas de zona. Consulte o resto deste artigo para compreender as suas responsabilidades e algumas abordagens a considerar.

As suas responsabilidades para uma implantação zonal

Um recurso zonal está em risco de interrupção quando a sua zona de disponibilidade sofre uma falha. Quando implementa um recurso zonal, é responsável por tornar a sua carga de trabalho resiliente a falhas ao nível da zona.

Para tornar os recursos zonais resilientes em zonas, considere as seguintes responsabilidades:

• Implementação e configuração de múltiplos recursos: Implementar manualmente recursos zonais separados em diferentes zonas ou regiões. Determine como manter a configuração consistente em cada recurso. Usar infraestrutura como código (IaC) é uma boa prática porque permite a rápida implementação de múltiplos recursos idênticos.

• Encaminhamento e distribuição do tráfego: Deve selecionar um componente de balanceador de carga, garantir que é resiliente em zonas e configurá-lo para enviar tráfego entre os recursos em diferentes zonas. Normalmente, configura-se a política de encaminhamento (como ativo-ativo ou ativo-passivo), as verificações automáticas de integridade e os processos de failover. Para obter mais informações, consulte Opções de balanceamento de carga.

• Replicação ou cópia de segurança de dados: Para recursos com estado, és responsável por proteger os dados que armazenam e garantir que são guardados em segurança em várias zonas. Uma abordagem comum é configurar a replicação para outra instância de serviço numa zona de disponibilidade diferente. Em algumas situações, pode confiar em backups em vez disso. Mas os backups exigem um tempo de recuperação mais longo durante uma falha de zona, o que exige que tenhas um objetivo de tempo de recuperação (RTO) mais elevado. Também resultam em maior perda de dados, o que exige um objetivo de pontos de recuperação (RPO) mais elevado.

• Deteção de falhas de zona e implementação do processo de resposta: Deve determinar como monitorizar a saúde dos recursos zonais, definir as condições que os definem como insalubres e desencadear ações de resposta, como restaurar operações noutra zona ou região.

• Processos de recuperação de zonas: Depois de a zona recuperar, é responsável por quaisquer ações de recuperação necessárias, como fazer a reversão para os recursos na zona principal.

Abordagens comuns para a resiliência na implantação zonal

Para tomar decisões informadas sobre como alcançar a resiliência das zonas para os seus recursos zonais, considere os seguintes fatores:

• Revê toda a tua carga de trabalho. Compreenda como cada componente se comporta durante eventos de zona descida, incluindo recursos redundantes de zona, zonais e não regionais. Use o guia de fiabilidade de cada serviço para aprender como o serviço funciona durante cenários de zona reduzida e como monitorizar a saúde dos serviços para eventos de zona baixa.

• Compreenda a perda de dados permitida durante uma falha de zona. O teu RPO especifica quanto de perda de dados podes aceitar.

  Muitos recursos redundantes de zona Azure fornecem um RPO de zero para falhas de zona, o que significa que não ocorre perda de dados. Normalmente, conseguem este RPO replicando síncronicamente todas as alterações entre zonas.

  Ao planear uma implantação zonal, deve garantir que consegue cumprir os requisitos de RPO da sua carga de trabalho quando uma zona falha.

• Compreenda o tempo de inatividade permitido durante uma falha de zona. O teu RTO especifica quanto tempo de inatividade podes aceitar.

  Os recursos redundantes de zona Azure normalmente fornecem um RTO muito baixo para falhas de zona e normalmente requerem apenas alguns segundos de inatividade.

  É necessário garantir que, ao planear uma implementação zonal, consegue cumprir os requisitos de RTO da sua carga de trabalho. Se tiver um RTO baixo, poderá precisar de recorrer a processos automatizados de deteção e recuperação. Um RTO mais elevado oferece mais flexibilidade para os seus processos de resposta.

• Compreenda o custo. Os recursos zonais são normalmente faturados individualmente, por isso a implementação de múltiplos recursos zonais pode aumentar o custo dos seus recursos.

Desenhar uma implantação zonal para resiliência

Ao desenhar a sua implementação zonal para resiliência, considere se está a usar zonas de disponibilidade para alcançar alta disponibilidade ou recuperação em caso de desastre. A distinção entre estes conceitos baseia-se nos requisitos do seu RTO e RPO.

Se tiver um baixo RTO e um baixo requisito de RPO, deverá tratar as zonas de disponibilidade como uma estrutura de alta disponibilidade. Mas se o seu RTO e RPO forem mais elevados, pode optar por tratar as zonas de disponibilidade como uma estrutura de recuperação de desastres . Para mais informações, consulte Continuidade do Negócio, alta disponibilidade e recuperação em caso de desastres. O seu nível de carga de trabalho pode ajudá-lo a determinar os seus requisitos e ações necessárias.

Design para alta disponibilidade

Considere implementar a sua própria arquitetura altamente disponível em várias zonas. Uma arquitetura altamente disponível requer replicação automática e frequente de dados entre os componentes implantados em múltiplas zonas, e failover automático entre esses componentes caso ocorra uma falha de uma zona.

Certas aplicações que implementas em VMs zonais oferecem suporte de alta disponibilidade incorporado, por exemplo, por serem conscientes da existência de réplicas. Por exemplo, se usar SQL Server em VMs Azure, os grupos de disponibilidade fornecem capacidades de encaminhamento de tráfego e failover. Podes escolher se queres usar replicação síncrona ou assíncrona. Para mais informações, consulte Continuidade do Negócio, alta disponibilidade e recuperação de desastres para SQL Server em VMs Azure.

Projeto para recuperação de desastres

A recuperação de desastres difere da alta disponibilidade porque maiores tempos de inatividade e perda de dados são aceitáveis num cenário de desastre. O RTO e o RPO são normalmente medidos em horas ou mais.

Um plano de recuperação de desastres ajuda-o a preparar-se para diferentes cenários e define como responder utilizando uma combinação de processos automáticos e manuais.

As seguintes abordagens de recuperação de desastres podem ajudar quando planeia uma implantação zonal:

• Azure Site Recovery zone-to-zone disaster recovery: Esta abordagem é útil quando se precisa de replicação assíncrona ao nível do disco entre VMs em diferentes zonas. Para mais informações, consulte Ativar a recuperação de desastres de VM Azure entre zonas de disponibilidade.

• Recuperação de Desastres entre Regiões: A recuperação de desastres entre regiões é suportada por Centros de Recuperação e depende da replicação assíncrona. Esta abordagem permite-te fazer failover para uma zona noutra região Azure em vez de outra zona na tua região principal. Para mais informações, consulte Replicar VMs Azure para outra região Azure.

• Recuperação de desastres baseada em backup: Se a sua solução puder tolerar um RTO elevado e um RPO elevado, considere usar backups como estratégia de recuperação de desastres. Se a zona sofrer uma falha, pode então restaurar backups noutra zona ou região. Também precisa de considerar se pré-cria os outros recursos Azure na sua solução, ou se os cria durante o processo de failover.

  Numa arquitetura zonal, muitas vezes és responsável por armazenar e replicar esses backups.

  O Azure Backup é um serviço de backup gerido amplamente utilizado. Suporta backups redundantes por zona e backups geo-replicados entre regiões Azure emparelhadas. Algumas aplicações, como o SQL Server em VMs Azure, também incluem funcionalidades de backup específicas de aplicação incorporadas.

Próximo passo

• Recomendações para a utilização de zonas e regiões de disponibilidade no Azure Well-Architected Framework