Recursos zonais e resiliência de zona

No Azure, um recurso zonal é um recurso fixado em uma única zona. Como um recurso zonal está em uma única zona de disponibilidade, ele não é resiliente à zona. Se a zona que contém o recurso tiver um problema, o recurso provavelmente terá tempo de inatividade.

Alguns serviços do Azure exigem ou permitem que você implante recursos zonais. Você pode optar por implantar um recurso zonalmente devido a considerações de latência ou requisitos de serviço específicos. Você pode fixar recursos individuais ou conjuntos de recursos relacionados a uma única zona.

Este artigo descreve cenários em que você pode optar por implantar recursos zonais em vez de recursos com redundância de zona. Ele também destaca as considerações e responsabilidades necessárias para garantir que sua solução permaneça resiliente a interrupções de zona.

Tipos de implantação de recursos

No Azure, apenas alguns tipos de implantação fornecem resiliência de zona. A tabela a seguir compara três tipos de implantação de recursos e descreve sua resiliência de zona, distribuição de zona, opções de configuração e recomendações.

Para obter mais informações sobre zonas de disponibilidade e implantações de recursos, consulte zonas de disponibilidade.

Cargas de trabalho que combinam recursos com redundância de zona e zonais

Muitas cargas de trabalho combinam recursos com redundância de zona e zonais. Por exemplo, sua carga de trabalho pode incluir um conjunto de VMs (máquinas virtuais zonais) para sua camada de banco de dados, um servidor Web com redundância de zona hospedado no Serviço de Aplicativo do Azure e um balanceador de carga com redundância de zona para enviar tráfego para suas VMs de banco de dados.

Ao combinar recursos zonais e com redundância de zona em uma carga de trabalho, considere como cada recurso e a solução geral se comportam se uma zona de disponibilidade tiver um problema. Normalmente, os serviços com redundância de zona se recuperam automaticamente de interrupções de zona com perda mínima ou sem dados, e a Microsoft gerencia todo o processo. Para recursos zonais, você é responsável por configurar o failover automatizado ou realizar atividades de recuperação manual. Para saber como cada serviço se comporta durante cenários de interrupção de zona, entenda suas responsabilidades em relação às responsabilidades da Microsoft e monitore a integridade dos serviços durante eventos de interrupção de zona, consulte o guia de confiabilidade do seu serviço.

Quando usar uma implantação zonal

Use recursos zonais somente quando houver uma necessidade clara. Os motivos típicos para uma implantação de zona única incluem casos em que um recurso deve ser zonal, um serviço está disponível apenas em uma zona específica ou uma carga de trabalho é altamente sensível à latência entre zonas.

Recursos que exigem implantações zonais

Alguns serviços do Azure dão suporte apenas a implantações zonais e não fornecem implantações com redundância de zona.

As VMs são um recurso zonal. Você pode usar conjuntos de dimensionamento de máquinas virtuais para criar conjuntos de VMs. Conjuntos de Escala de Máquinas Virtuais podem ser configurados para abranger zonas, o que significa que as Máquinas Virtuais no conjunto são distribuídas entre várias zonas. Os conjuntos de dimensionamento são uma boa maneira de obter resiliência de zona para muitas cargas de trabalho baseadas em VM.

Outro exemplo é o Azure NetApp Files, que dá suporte à implantação de volumes em uma única zona. O serviço também fornece uma maneira de replicar entre vários volumes zonais.

Alguns serviços fornecem opções que estão disponíveis apenas em zonas específicas. Por exemplo, tipos de VM específicos que usam GPUs (unidades de processamento de gráficos avançados) podem estar disponíveis apenas em zonas específicas dentro de uma região, o que significa que elas não podem ser implantadas em várias zonas. Para verificar quais regiões e zonas dão 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 com suporte em cada zona de uma região específica, consulte Verificar a disponibilidade de SKU da VM.

Se o tipo de VM que você precisa estiver disponível apenas em uma única zona dentro da região que você usa, você poderá considerar uma implantação zonal para essa VM e encontrar outras maneiras de tornar a VM resiliente a interrupções de zona. Mas você deve continuar a garantir que as outras partes da sua solução sejam resilientes à zona.

Para obter mais informações, consulte os serviços do Azure que dão suporte a zonas de disponibilidade.

Latência entre zonas

Se você tiver uma carga de trabalho extraordinariamente sensível à latência, poderá usar recursos zonais em vez de recursos com redundância de zona, mesmo que um serviço dê suporte a implantações com redundância de zona.

Uma rede de baixa latência conecta zonas de disponibilidade, com latência de ida e volta entre zonas normalmente em 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 da disseminação de recursos entre zonas de disponibilidade são mais importantes do que o impacto mínimo no desempenho do envio de tráfego entre zonas. Mas algumas cargas de trabalho são altamente sensíveis à latência entre zonas. Essas cargas de trabalho podem incluir os seguintes cenários:

• Aplicativos locais herdados: Algumas cargas de trabalho herdadas podem conter aplicativos que foram originalmente projetados para um ambiente local. Essas cargas de trabalho pressupõem que os componentes, como bancos de dados e outros aplicativos e serviços, são colocados no mesmo host ou em proximidade física próxima.

• Replicação síncrona em escala muito alta: Aplicativos com estado e bancos de dados ocasionalmente realizam um número muito grande de gravações usando replicação síncrona. A replicação síncrona significa que os dados são gravados em várias réplicas antes que a operação de gravação seja considerada concluída. Distribuir réplicas entre zonas de disponibilidade melhora a resiliência, mas quando você usa a replicação síncrona, a latência entre zonas pode aumentar a latência de gravação da carga de trabalho. Essa latência aumentada geralmente não é significativa, mas devido à forma como alguns aplicativos são projetados, às vezes pode se tornar problemático em alta escala.

Se você suspeitar que a latência entre zonas está afetando sua carga de trabalho, teste seu impacto em um ambiente realista seguindo estas etapas para sua carga de trabalho específica:

1. Definir requisitos de desempenho aceitáveis. O tráfego entre zonas adiciona uma pequena quantidade de latência, mas é insignificante para a maioria das cargas de trabalho. Defina como é um desempenho aceitável para seu trabalho.

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

   Importante

   Teste sua carga de trabalho, incluindo aplicativos, protocolos, configuração e região do Azure. Use uma carga realista. Parâmetros de comparação e testes sintéticos não são suficientes porque não mostram como sua solução realmente se comporta.

3. Habilitar a replicação entre zonas. Dependendo dos componentes usados, você pode habilitar a redundância de zona ou mover réplicas entre zonas.

4. Execute novamente testes de desempenho. Colete as mesmas métricas coletadas anteriormente.

5. Compare o impacto no desempenho em relação aos seus requisitos. Use seus requisitos e os dados de desempenho para tomar uma decisão informada sobre a compensação entre latência e resiliência para interrupções de zona.

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

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

     Dica

     Se você testar em diferentes assinaturas do Azure, revise o mapeamento de zona lógica para zona física para garantir que estejam sendo testados os conjuntos de zonas físicas que você espera.

   • Se houver outra região do Azure que atenda às suas necessidades gerais de residência de dados e outros fatores, tente usar várias zonas nessa região.

   • Considere se você pode reprojetar seu aplicativo para minimizar a comunicação entre zonas necessária. Por exemplo, você pode consolidar várias pequenas operações de banco de dados em uma única operação. Essa abordagem pode reduzir o impacto da latência em sua carga de trabalho.

   Se nenhuma dessas ações ajudar, considere executar a carga de trabalho ou componentes específicos em uma única zona de disponibilidade usando VMs zonais e outros serviços do Azure com suporte. Em seguida, você assume a responsabilidade de tornar os componentes zonais resilientes a interrupções de zona. Examine o restante deste artigo para entender suas responsabilidades e algumas abordagens a serem consideradas.

Suas responsabilidades para uma implantação zonal

Um recurso zonal corre o risco de tempo de inatividade quando sua zona de disponibilidade enfrenta uma interrupção. Ao implantar um recurso zonal, você é responsável por tornar sua carga de trabalho resiliente a falhas no nível da zona.

Para tornar os recursos zonais resilientes à zona, considere as seguintes responsabilidades:

• Implantação e configuração de vários recursos: Implante recursos zonais separados manualmente em diferentes zonas ou regiões. Determine como manter a configuração consistente em cada recurso. Usar a IaC (infraestrutura como código) é uma prática recomendada porque permite a implantação rápida de vários recursos idênticos.

• Roteamento e distribuição de tráfego: Você deve selecionar um componente do balanceador de carga, garantir que ele seja resiliente à zona e configurá-lo para enviar tráfego entre os recursos em zonas diferentes. Normalmente, você configura a política de roteamento (como ativo-ativo ou ativo-passivo), verificações de integridade automatizadas e processos de failover. Para obter mais informações, consulte opções de balanceamento de carga.

• Replicação ou backup de dados: Para recursos com estado, você é responsável por proteger os dados que eles armazenam e garantir que eles sejam mantidos com segurança em várias zonas. Uma abordagem comum é configurar a replicação para outra instância de serviço em uma zona de disponibilidade diferente. Em algumas situações, você pode contar com backups. Mas os backups exigem um tempo de recuperação mais longo durante uma falha de zona, o que exige que você tenha um RTO (objetivo de tempo de recuperação) mais alto. Eles também resultam em mais perda de dados, o que requer um RPO (objetivo de ponto de recuperação) maior.

• Detecção de falhas de zona e implementação do processo de resposta: Você deve determinar como monitorar a integridade dos recursos zonais, definir as condições que os marcam como não íntegros e disparar ações de resposta, como restaurar operações em outra zona ou região.

• Processos de recuperação de zona: após a recuperação da zona, você será responsável por todas as ações de recuperação exigidas, como realizar failback para recursos na zona primária.

Abordagens comuns para resiliência de implantação zonal

Para tomar decisões informadas sobre como obter resiliência de zona para seus recursos zonais, considere os seguintes fatores:

• Examine toda a carga de trabalho. Entenda como cada componente se comporta durante eventos de degradação de zona, incluindo recursos com redundância de zona, zonados e não regionais. Use o guia de confiabilidade de cada serviço para saber como o serviço funciona durante cenários de zona suspensa e como monitorar a integridade dos serviços para eventos de zona suspensa.

• Entenda a perda de dados permitida durante uma falha de zona. O RPO especifica a quantidade de perda de dados que você pode aceitar.

  Muitos recursos com redundância de zona do Azure fornecem um RPO de zero para falhas de zona, o que significa que não ocorre nenhuma perda de dados. Normalmente, eles conseguem esse RPO replicando de forma síncrona todas as alterações entre zonas.

  Ao planejar uma implantação zonal, você deve garantir que possa atender aos requisitos de RPO da carga de trabalho quando uma zona falhar.

• Entenda o tempo de inatividade permitido durante uma falha de zona. O RTO especifica quanto tempo de inatividade você pode aceitar.

  Os recursos com redundância de zona do Azure normalmente fornecem um RTO muito baixo para falhas de zona e geralmente exigem apenas alguns segundos de tempo de inatividade.

  Ao planejar uma implantação zonal, você deve garantir que possa atender aos requisitos de RTO da carga de trabalho. Se você tiver um RTO baixo, talvez seja necessário contar com processos automatizados de detecção e recuperação. Um RTO mais alto fornece mais flexibilidade para seus processos de resposta.

• Entenda o custo. Os recursos zonais normalmente são cobrados individualmente, portanto, a implantação de vários recursos zonais pode aumentar o custo do recurso.

Criar uma implantação zonal para resiliência

Ao projetar sua implantação zonal para resiliência, considere se você está usando zonas de disponibilidade para obter alta disponibilidade ou recuperação de desastre. A distinção entre esses conceitos baseia-se em seus requisitos de RTO e RPO.

Se você tiver um RTO baixo e um requisito de RPO baixo, precisará tratar as zonas de disponibilidade como um constructo de alta disponibilidade . Mas se o RTO e o RPO forem mais altos, você poderá optar por tratar as zonas de disponibilidade como um constructo de recuperação de desastre . Para obter mais informações, consulte Continuidade dos negócios, alta disponibilidade e recuperação de desastres. Sua camada de carga de trabalho pode ajudá-lo a determinar seus requisitos e ações necessárias.

Projeto para alta disponibilidade

Considere implantar sua própria arquitetura altamente disponível em várias zonas. Uma arquitetura altamente disponível requer replicação de dados automatizada e frequente entre componentes implantados em várias zonas e failover automático entre esses componentes em caso de falha de uma zona.

Alguns aplicativos que você implanta em VMs zonais fornecem suporte interno de alta disponibilidade, como por serem sensíveis a réplicas. Por exemplo, se você usar o SQL Server em VMs do Azure, os grupos de disponibilidade fornecerão recursos de roteamento e failover de tráfego. Você pode selecionar se deseja usar a replicação síncrona ou assíncrona. Para obter mais informações, consulte Continuidade dos negócios, alta disponibilidade e recuperação de desastre para SQL Server em VMs do Azure.

Design para a recuperação de desastres

A recuperação de desastre difere da alta disponibilidade porque um tempo de inatividade maior e a perda de dados são aceitáveis em um cenário de desastre. RTO e RPO normalmente são medidos em horas ou mais.

Um plano de recuperação de desastre ajuda você a se preparar para diferentes cenários e define como responder usando uma combinação de processos automatizados e manuais.

As seguintes abordagens de recuperação de desastre podem ajudar ao planejar uma implantação zonal:

• Recuperação de desastre zona a zona do Azure Site Recovery: Essa abordagem é útil quando você precisa de replicação assíncrona no nível do disco entre VMs em zonas diferentes. Para obter mais informações, consulte Habilitar a recuperação de desastre de VM do Azure entre zonas de disponibilidade.

• Recuperação de desastre região a região do Site Recovery: O Site Recovery dá suporte à recuperação de desastre região a região e depende da replicação assíncrona. Essa abordagem permite que você faça failover para uma zona em outra região do Azure em vez de outra zona em sua região primária. Para obter mais informações, consulte Replicar VMs do Azure para outra região do Azure.

• Recuperação de desastre baseada em backup: Se sua solução puder tolerar um RTO alto e um RPO alto, considere o uso de backups como uma estratégia de recuperação de desastre. Se a zona sofrer uma interrupção, você poderá restaurar backups em outra zona ou região. Você também precisa considerar se pré-cria os outros recursos do Azure em sua solução ou se os cria durante o processo de failover.

  Em uma arquitetura zonal, você geralmente é responsável por armazenar e replicar esses backups.

  O Backup do Azure é um serviço de backup gerenciado amplamente usado. Ele dá suporte a backups com redundância de zona e backups replicados geograficamente em regiões emparelhadas do Azure. Alguns aplicativos, como o SQL Server em VMs do Azure, também incluem recursos internos de backup específicos do aplicativo.

Próxima etapa

• Recomendações para usar zonas e regiões de disponibilidade no Azure Well-Architected Framework