Ir mais longe com a disponibilidade
A Base de Dados SQL do Azure e o Azure SQL Managed Instance proporcionam ótimas opções de disponibilidade por predefinição nos vários escalões de serviço. Existem algumas coisas adicionais que pode fazer para aumentar ou modificar a disponibilidade das bases de dados/instâncias. Poderá ver diretamente o impacto no contrato de nível de serviço (SLA). Nesta unidade, verá como pode ir mais longe com as várias opções de disponibilidade no Azure SQL.
Zonas de Disponibilidade
No escalão Crítico para a Empresa da Base de Dados SQL do Azure, pode optar (sem qualquer custo adicional) por uma configuração de redundância de zona, caso seja suportado pela sua região. A um nível elevado, o grupo de disponibilidade (AG) AlwaysOn que é executado por detrás das bases de dados e das instâncias geridas do escalão Crítico para a Empresa é implementado em três Zonas de Disponibilidade numa região. Uma Zona de Disponibilidade é basicamente um datacenter separado numa determinada região. Existe sempre uma separação física entre as Zonas de Disponibilidade. Esta função protege de falhas catastróficas que podem ocorrer num datacenter numa determinada região.
Do ponto de vista do desempenho, pode existir um pequeno aumento na latência da rede, dado que o AG está agora repartido por datacenters com alguma distância entre eles. Por este motivo, as Zonas de Disponibilidade não estão ativadas por predefinição. Pode optar por utilizar o que é vulgarmente chamado de uma implementação “Multi-Az” ou “Single-Az”. Configurar essa opção é tão simples quanto adicionar um parâmetro a um comando da CLI do PowerShell/Azure ou marcar uma caixa no portal do Azure.
As Zonas de Disponibilidade são relativamente novas no Azure SQL, pelo que atualmente só estão disponíveis em certos escalões de serviço e regiões. Com o tempo, esta funcionalidade será provavelmente suportada em mais regiões e possivelmente mais escalões de serviço. Por exemplo, recentemente, o escalão Fins Gerais da Base de Dados SQL do Azure lançou uma pré-visualização da implementação multi-az.
SLA do Azure SQL
O Azure SQL mantém um contrato de nível de serviço (SLA), que proporciona apoio financeiro ao compromisso de atingir e manter os níveis de serviço. Se o nível de serviço não for atingido e mantido conforme descrito no SLA, poderá ser elegível para um crédito para uma parte das taxas de serviço mensais.
Atualmente, pode conseguir a disponibilidade mais elevada (99,995%) com uma implementação do escalão Crítico para a Empresa da Base de Dados SQL do Azure com Zonas de Disponibilidade configuradas. A camada Crítica de Negócios é a única opção no setor que fornece SLAs de RPO e RTO de 5 a 30 segundos, respectivamente.
- RPO significa objetivo do ponto de recuperação. Representa a quantidade de dados que está, potencialmente, disposto a perder no pior cenário possível.
- RTO significa objetivo de tempo de recuperação. Representa o tempo que demorará a ser feita a cópia de segurança novamente se ocorrer um desastre.
Para implementações Críticas para a Empresa numa única zona ou para Fins Gerais da Base de Dados SQL do Azure ou do Azure SQL Managed Instance, o SLA é de 99,99%.
O SLA do escalão Hyperscale depende do número de réplicas. Lembre-se de que escolhe quantas réplicas tem no Hyperscale. Se não tiver nenhuma, o comportamento de ativação pós-falha será mais parecido com o do escalão Fins Gerais. Se tiver réplicas, o comportamento de ativação pós-falha será mais parecido com o do escalão Crítico para a Empresa. Estes sã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%
Georreplicação e grupos de ativação pós-falha automática
Após escolher um escalão de serviço (e considerar as Zonas de Disponibilidade, conforme aplicável), pode considerar outras opções para obter escalamento horizontal de leituras ou a possibilidade de efetuar a ativação pós-falha para outra região: georreplicação e grupos de ativação pós-falha automática. No SQL Server no local, a configuração de qualquer uma destas opções é algo que precisaria de muito planeamento, coordenação e tempo.
A nuvem — e o Azure SQL especificamente — facilitou esse processo. Tanto para a georreplicação como para os grupos de ativação pós-falha automática, pode fazer a configuração com apenas alguns cliques no portal do Azure ou alguns comandos no PowerShell/CLI do Azure.
Existem algumas considerações para o ajudar a decidir se a georreplicação ou os grupos de ativação pós-falha automática são os melhores para o seu cenário:
| Funcionalidades | Georreplicação | Grupos de ativação pós-falha |
|---|---|---|
| Ativação pós-falha automática | Não | Sim |
| Efetuar ativação pós-falha em várias bases de dados simultaneamente | Não | Sim |
| O utilizador deve atualizar a cadeia de ligação após a ativação pós-falha | Sim | No |
| Suporte ao SQL Managed Instance | Não | Sim |
| Pode estar na mesma região que a primária | Sim | No |
| Várias réplicas | Sim | No |
| Suporta o escalamento horizontal de leituras | Sim | Sim |