Indo além com a disponibilidade
O Banco de Dados SQL do Azure e a Instância Gerenciada de SQL do Azure fornecem excelentes opções de disponibilidade por padrão nas várias camadas de serviço. Há algumas coisas adicionais que você pode fazer para aumentar ou modificar a disponibilidade de seus bancos de dados/instâncias. Você poderá ver diretamente o impacto sobre o SLA (contrato de nível de serviço). Nesta unidade, você verá como é possível ir além de várias opções de disponibilidade no SQL do Azure.
Zonas de Disponibilidade
Na camada Comercialmente crítica no Banco de Dados SQL do Azure, você poderá aceitar (sem valor adicional) uma configuração com redundância de zona se sua região der suporte a isso. Em um alto nível, o AG (grupo de disponibilidade) Always On executado por trás de bancos de dados Comercialmente Críticos e instâncias gerenciadas é implantado em três Zonas de Disponibilidade em uma região. Uma zona de disponibilidade é basicamente um datacenter separado em uma determinada região. Sempre há uma separação física entre Zonas de Disponibilidade. Essa funcionalidade protege contra falhas catastróficas que podem ocorrer a um datacenter em uma região.
Do ponto de vista do desempenho, pode haver um pequeno aumento na latência da rede, já que seu AG agora está distribuído entre datacenters com alguma distância entre eles. Por esse motivo, as Zonas de Disponibilidade não estão ativadas por padrão. Você pode optar por usar o que é comumente chamado de implantação "Multi-AZ" ou "Single-AZ". Configurar essa opção é tão simples quanto adicionar um parâmetro a um comando da CLI do Azure/PowerShell ou verificar uma caixa no portal do Microsoft Azure.
As Zonas de Disponibilidade são relativamente novas no SQL do Azure, de modo que estão disponíveis atualmente apenas em determinadas regiões e camadas de serviço. Ao longo do tempo, é provável que essa funcionalidade tenha suporte em mais regiões e potencialmente em mais camadas de serviço. Por exemplo, recentemente a camada de Uso Geral do Banco de Dados SQL do Azure liberou uma versão prévia da implantação de vários AZ.
SLA do SQL do Azure
O SQL do Azure mantém um SLA (Contrato de Nível de Serviço) que fornece suporte financeiro para o compromisso de alcançar e manter os Níveis de Serviço. Se o Nível de Serviço não for alcançado e mantido conforme descrito no SLA, você poderá estar qualificado para um crédito equivalente a uma parte de seus valores de serviço mensais.
No momento, você pode obter a disponibilidade mais alta (99,995%) de uma implantação Comercialmente Crítica do Banco de Dados SQL do Azure que tem Zonas de Disponibilidade configuradas. A camada Comercialmente Crítica é a única opção no setor que fornece SLAs de RPO e RTO de 5 a 30 segundos, respectivamente.
- O RPO significa objeto de ponto de recuperação. Representa a quantidade de dados que você está potencialmente disposto a perder em um cenário de pior caso.
- RTO significa objetivo de tempo de recuperação. Ele representa quanto tempo leva para fazer o backup e voltar a executar em caso de desastre.
Para Uso Geral ou implantações do Comercialmente Crítico de zona única do Banco de Dados SQL do Azure ou da Instância Gerenciada de SQL do Azure, o SLA é de 99,99%.
O SLA da camada de Hiperescala depende do número de réplicas. Lembre-se de que você escolhe quantas réplicas há em hiperescala. Se você não tiver nenhuma, o comportamento de failover será mais parecido com o Uso Geral. Se você tiver réplicas, o comportamento de failover será mais parecido com o Comercialmente Crítico. Aqui estão os SLAs com base no número de réplicas:
- 0 réplicas: 99,5%
- 1 réplica: 99,9%
- 2 ou mais réplicas: 99,99%
Replicação geográfica e grupos de failover automático
Depois de escolher uma camada de serviço (e considerar Zonas de Disponibilidade conforme aplicável), você pode considerar algumas outras opções para obter a escala de leitura ou a capacidade de fazer failover para outra região: replicação geográfica e grupos de failover automático. No SQL Server local, a configuração de qualquer uma dessas opções é algo que exigiria muito planejamento, coordenação e tempo.
A nuvem, especificamente o SQL do Azure, facilitou esse processo. Para a replicação geográfica e os grupos de failover automático, você pode concluir a configuração com alguns cliques no portal do Azure ou alguns comandos no PowerShell ou na CLI do Azure.
Aqui estão algumas considerações para ajudar você a decidir se o melhor para seu cenário é o uso da replicação geográfica ou dos grupos de failover automático:
| Recursos | Replicação geográfica | Grupos de failover |
|---|---|---|
| failover automático | Não | Sim |
| Fazer failover de vários bancos de dados simultaneamente | Não | Sim |
| O usuário precisa atualizar a cadeia de conexão após o failover | Sim | Não |
| Suporte à Instância Gerenciada de SQL | Não | Sim |
| Pode estar na mesma região que o primário | Sim | Não |
| Várias réplicas | Sim | Não |
| Dá suporte à escala de leitura | Sim | Sim |