Elevada disponibilidade por escalão de serviço
Para compreender as capacidade e opções de disponibilidade no SQL do Azure, precisa de compreender os escalões de serviço. O escalão de serviço selecionado determinará a arquitetura subjacente da base de dados ou da instância gerida que implementar.
Há dois modelos de compra a considerar: DTU e vCore. Esta unidade vai focar-se nos escalões de serviço vCore e nas arquiteturas da elevada disponibilidade. Pode equiparar os escalões Básico e Standard do modelo DTU ao escalão Fins Gerais, e o escalão Premium ao Crítico para a Empresa.
Fins Gerais
As bases de dados e as instâncias geridas no escalão de serviço Fins Gerais têm a mesma arquitetura de disponibilidade. Com a figura abaixo como um guia, considere primeiro a aplicação e a cadência de controlo. O aplicativo se conecta ao nome do servidor, que então se conecta a um gateway (GW), que aponta a conexão do aplicativo para o servidor correto, em execução em uma VM. Com o General Purpose, a réplica principal usa SSD conectado localmente para o tempdb. Os ficheiros de registo e de dados são armazenados no Armazenamento Premium do Azure, que é o armazenamento localmente redundante (várias cópias numa região). Em seguida, os ficheiros de cópia de segurança são armazenados no Armazenamento Standard do Azure, que é o RA-GRS por predefinição. O RA-GRS é um armazenamento globalmente redundante, com cópias em várias regiões.
Conforme abordado num módulo anterior neste percurso de aprendizagem, todo o Azure SQL foi concebido com base no Azure Service Fabric, que serve como estrutura principal do Azure. Se o Azure Service Fabric determinar que é necessário ocorrer uma ativação pós-falha, a ativação pós-falha será semelhante à de uma instância de um cluster de ativação pós-falha (FCI). Os recursos de infraestrutura vão procurar um nó com capacidade livre e acelerar uma nova instância do SQL Server. Os arquivos de banco de dados serão anexados, a recuperação será executada e os gateways serão atualizados para apontar aplicativos para o novo nó. Não precisa de nenhuma rede virtual, serviço de escuta nem atualização. Esta capacidade está incorporada.
Crítico para a Empresa
O próximo escalão de serviço a considerar é o Crítico para a Empresa, que normalmente consegue o maior desempenho e disponibilidade de todos os escalões de serviço do Azure SQL (Fins Gerais, Hyperscale, Crítico para a Empresa). O escalão Crítico para a Empresa destina-se a aplicações críticas para a missão que necessitam de baixa latência e período de indisponibilidade mínimo.
A utilização do escalão Crítico para a Empresa é semelhante à implementação de um grupo de disponibilidade (AG) AlwaysOn em segundo plano. Ao contrário da camada de uso geral, os dados e arquivos de log no Business Critical são todos executados em um SSD de conexão direta, o que reduz significativamente a latência da rede. (O uso geral usa armazenamento remoto.) Neste AG, existem três réplicas secundárias. Você pode usar um deles como um ponto de extremidade somente leitura (sem custo adicional). Uma transação pode concluir uma consolidação quando, pelo menos, uma das réplicas secundárias protegeu a alteração no registo de transações.
A expansão de leitura com uma das réplicas secundárias oferece suporte à consistência no nível da sessão, portanto, se a sessão somente leitura se reconectar após um erro de conexão causado pela indisponibilidade da réplica, ela poderá ser redirecionada para uma réplica que não esteja 100% atualizada com a réplica de leitura-gravação. De igual forma, se uma aplicação escrever dados com uma sessão de leitura-escrita e os ler de imediato com uma sessão só de leitura, as últimas atualizações poderão não estar imediatamente visíveis na réplica. A latência é causada por uma operação de fase de rollforward de registo de transações assíncronas.
Se ocorrer qualquer tipo de falha e a malha de serviço determinar que um failover é necessário, o failover para uma réplica secundária será rápido porque a réplica já existe e tem os dados anexados a ela. Numa ativação pós-falha, não precisa de um serviço de escuta. O gateway redireciona sua conexão para o principal mesmo após um failover. Essa mudança acontece rapidamente e, em seguida, a malha de serviço se encarrega de girar outra réplica secundária.
Hyperscale
A camada de serviço Hyperscale só está disponível no Banco de Dados SQL do Azure. Essa camada de serviço tem uma arquitetura exclusiva porque usa uma camada hierárquica de caches e servidores de página para expandir a capacidade de acessar rapidamente páginas de banco de dados sem precisar acessar o arquivo de dados diretamente.
Uma vez que esta arquitetura utiliza os servidores de página emparelhados, pode dimensionar horizontalmente para colocar todos os dados nas camadas em cache. Esta nova arquitetura também permite que o Hyperscale suporte bases de dados com tamanhos até 100 TB. Dado que utiliza instantâneos, podem ocorrer cópias de segurança de dados praticamente instantâneas, independentemente do tamanho. O restauro da base de dados demora minutos em vez de horas ou dias. Também pode dimensionar vertical ou horizontalmente num intervalo de tempo constante para acomodar as cargas de trabalho.
É interessante notar como o serviço de registo foi retirado nesta arquitetura. O serviço de registo é utilizado para alimentar as réplicas e os servidores de página. As transações podem ser confirmadas quando o serviço de log é endurecido para a zona de destino, portanto, o consumo das alterações por uma réplica de computação secundária não é necessário para uma confirmação. Ao contrário dos outros escalões de serviço, pode determinar se quer réplicas secundárias. Você pode configurar de zero a quatro réplicas secundárias, todas as quais você pode usar para escala de leitura.
Como nas outras camadas de serviço, um failover automático acontecerá se a malha de serviço determinar que é necessário, mas o tempo de recuperação dependerá da existência de réplicas secundárias. Por exemplo, se não tiver réplicas e ocorrer uma ativação pós-falha, o cenário será semelhante ao escalão de serviço Fins Gerais: os recursos de infraestrutura do serviço precisam primeiro encontrar capacidade livre. Se tiver uma ou mais réplicas, a recuperação será mais rápida e mais estreitamente alinhada com o escalão de serviço Crítico para a Empresa.
O Business Critical mantém o mais alto desempenho e disponibilidade para cargas de trabalho com pequenas gravações de log que precisam de baixa latência, mas a camada de serviço Hyperscale permite obter uma taxa de transferência de log mais alta em termos de MB/segundo, fornece os maiores tamanhos de banco de dados e fornece até quatro réplicas secundárias para níveis mais altos de escala de leitura. Portanto, você precisará considerar sua carga de trabalho quando escolher entre os dois.