DR para serviços PaaS

A recuperação de desastre para serviços IaaS (VMs) normalmente envolve o Azure Recuperação de Site para replicar todo o SO e os discos de dados para uma região secundária. Os serviços PaaS têm modelos de DR diferentes porque a infraestrutura subjacente é gerenciada pela Microsoft. Para PaaS, o DR geralmente é configurado na camada de dados — os dados são replicados para uma região secundária enquanto a própria plataforma é iniciada automaticamente.

O Banco de Dados SQL do Azure fornece alta disponibilidade integrada no nível de zona dentro de uma única região. Para DR entre regiões, ele oferece duas funcionalidades principais: replicação geográfica ativa (bancos de dados secundários legíveis em até quatro outras regiões) e grupos de failover automático (failover automatizado com um único ponto de extremidade de escuta). Esses recursos são configurados no nível do banco de dados ou do servidor, sem a necessidade do Azure Recuperação de Site.

Os grupos de failover automático adicionam automação e um único ponto de extremidade de conexão à replicação geográfica. Você configura um grupo no servidor primário, adiciona o servidor secundário e define um período de tolerância — o tempo que o Azure aguarda a recuperação do primário antes de acionar o failover automático. As aplicações se conectam ao ponto de extremidade de escuta (por exemplo, mygroup.database.windows.net) e são redirecionadas automaticamente após o failover, sem alterar as cadeias de conexão.

A replicação geográfica do Banco de Dados SQL do Azure é assíncrona — as transações são confirmadas no primário e depois replicadas para o secundário. Isso significa que há uma pequena defasagem de replicação, normalmente inferior a 5 segundos em condições normais. Portanto, o RPO da replicação geográfica do SQL é de aproximadamente 5 segundos na maioria dos cenários, o que a torna adequada para cargas de trabalho de Nível 1 e Nível 2 que exigem perda de dados muito baixa.

Todos os níveis do Banco de Dados SQL do Azure incluem backups automatizados: backups completos semanais, backups diferenciais a cada 12 horas e backups do log de transações a cada 5 a 12 minutos. Isso possibilita a Restauração pontual (PITR) — restaurar o banco de dados para qualquer segundo dentro do período de retenção (7 a 35 dias para Standard/General Purpose e até 35 dias para Business Critical). O PITR é útil para recuperar dados excluídos ou corrompidos acidentalmente.

O Azure Cosmos DB com gravações em várias regiões fornece um RPO próximo de zero para aplicações globais. Todas as regiões configuradas podem aceitar operações de gravação simultaneamente, e o Cosmos DB sincroniza os dados automaticamente usando seu protocolo de replicação proprietário. Se uma região falhar, o tráfego será roteado automaticamente para as regiões saudáveis restantes, sem necessidade de failover manual — alcançando RTO e RPO próximos de zero.

O próprio Serviço de Aplicativo do Azure não mantém estado (o código da aplicação é implantado a partir do controle do código-fonte ou de um arquivo ZIP). Para DR, o foco está na camada de dados (banco de dados e armazenamento de blobs). O Serviço de Aplicativo pode ser reimplantado rapidamente em uma região secundária por meio de um pipeline de CI/CD. No entanto, você deve garantir que seu domínio personalizado, seus certificados TLS e suas configurações do aplicativo sejam replicados ou transformados em scripts para que possam ser recriados rapidamente na região secundária.

O Armazenamento de Blobs do Azure com Armazenamento com redundância geográfica (GRS) replica automaticamente os dados para uma região secundária a centenas de quilômetros de distância. Os dados são replicados de forma assíncrona (o RPO normalmente é inferior a 15 minutos). O GRS com acesso de leitura (RA-GRS) permite ler a partir do ponto de extremidade secundário mesmo antes do acionamento do failover, o que é útil para cargas de trabalho de análise e geração de relatórios durante uma interrupção na região primária.

As Azure Functions não mantêm estado por design, o que facilita sua reimplantação. Para DR, implante o mesmo aplicativo de funções em uma região secundária e use o Traffic Manager para encaminhar os acionadores HTTP entre as regiões. Para acionadores não HTTP (Service Bus, Event Grid), configure a origem das mensagens para distribuí-las entre as duas regiões ou faça com que a região secundária consulte a mesma origem. O estado das funções em Durable Functions é armazenado no Armazenamento do Azure — certifique-se de que esse armazenamento use GRS.

Use a replicação geográfica ativa quando precisar de um controle detalhado — por exemplo, direcionar o tráfego de leitura para uma réplica secundária por motivos de desempenho ou gerenciar várias réplicas secundárias em regiões diferentes de forma independente. Use grupos de failover automático quando quiser simplicidade: um único ponto de extremidade de escuta, failover automático conforme um temporizador e orquestração integrada do processo de failover, sem intervenção manual.

A DR em PaaS costuma ser mais barata do que a DR baseada em VM por vários motivos. A replicação geográfica do SQL Database cobra apenas pelo armazenamento e pela computação da réplica secundária; você não paga por uma licença completa do sistema operacional de uma VM. O Azure Cosmos DB cobra pelas RUs provisionadas em cada região. O Azure Storage GRS acrescenta aproximadamente o dobro do custo de armazenamento. Em contrapartida, as VMs replicadas pelo ASR exigem custos completos de computação, armazenamento e licenciamento na região secundária.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) apresentados nesta lição.

Nesta lição, você aprendeu que: a DR em PaaS se concentra na camada de dados, e não na replicação de VMs; os grupos de failover automático do Azure SQL fornecem um único ponto de extremidade de escuta com failover automatizado; e as gravações em várias regiões do Cosmos DB oferecem RTO e RPO próximos de zero para aplicações globais. Em seguida, vamos explorar as estruturas de conformidade do Azure e o modelo de responsabilidade compartilhada.