Alta disponibilidade por camada de serviço
Para entender as opções de disponibilidade e os recursos no SQL Azure, você precisa entender as camadas de serviço. A camada de serviço selecionada determinará a arquitetura subjacente do banco de dados ou da instância gerenciada que você implantar.
Há dois modelos de compra a serem considerados: DTU e vCore. Esta unidade se concentrará nas camadas de serviço vCore e em suas arquiteturas para alta disponibilidade. Você pode equiparar as camadas Básica e Standard à de Uso geral e a camada Premium à Comercialmente crítica do modelo de DTU.
Uso Geral
Os bancos de dados e as instâncias gerenciadas na camada de serviço de Uso Geral têm a mesma arquitetura de disponibilidade. Usando a figura a seguir como guia, primeiro considere o aplicativo e o anel de controle. O aplicativo se conecta ao nome do servidor, que, por sua vez, se conecta a um GW (gateway), que aponta a conexão do aplicativo para o servidor correto, executado em uma VM. Com Uso Geral, a réplica primária usa um SSD conectado localmente para o tempdb. Os arquivos de dados e de log são armazenados no Armazenamento Premium do Azure, que é um armazenamento com redundância local (várias cópias em uma região). Os arquivos de backup são armazenados no Armazenamento Standard do Azure, que é RA-GRS por padrão. O RA-GRS é um armazenamento com redundância global com cópias em várias regiões.
Conforme discutimos em um módulo anterior neste roteiro de aprendizagem, todo o SQL do Azure é criado com base no Azure Service Fabric, que serve como o backbone do Azure. Se o Azure Service Fabric determinar que um failover precisa ocorrer, o failover será semelhante ao de uma FCI (instância de cluster de failover). O alocador de serviço procurará um nó com capacidade sobressalente e criará uma nova instância de SQL Server. Em seguida, os arquivos do banco de dados serão conectados, a recuperação será executada e os gateways serão atualizados para apontar os aplicativos para o novo nó. Nenhuma rede virtual, ouvinte ou atualização é necessário. Essa funcionalidade é interna.
Comercialmente Crítico
A próxima camada de serviço a ser considerada a Comercialmente Crítica, que geralmente pode atingir os melhores desempenho e disponibilidade entre todas as camadas de serviço do SQL do Azure (Uso Geral, Hiperescala, Comercialmente Crítica). A camada Comercialmente Crítica destina-se a aplicativos críticos que precisam de latência baixa e tempo de inatividade mínimo.
Usar a camada Comercialmente Crítica é semelhante à implantação de um GA (Grupo de Disponibilidade) Always On. Ao contrário da camada de Uso Geral, os arquivos de dados e de log em Comercialmente Crítico são todos executados em um SSD de conexão direta, o que reduz significativamente a latência da rede. (Uso Geral usa o armazenamento remoto.) Neste AG, há três réplicas secundárias. Você pode usar um deles como ponto de extremidade somente leitura (sem custo adicional). Uma transação pode concluir uma confirmação quando pelo menos uma das réplicas secundárias tiver protegido a alteração para o respectivo log de transações.
A escala de leitura com uma das réplicas secundárias oferece suporte à consistência em nível de 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 e gravação. Da mesma maneira, se um aplicativo gravar dados usando uma sessão de leitura/gravação e lê-lo imediatamente usando uma sessão somente leitura, as atualizações mais recentes podem não ficar visíveis imediatamente na réplica. A latência é causada por uma operação refazer assíncrona do log de transações.
Se ocorrer algum tipo de falha e a malha de serviço determinar que é necessário um failover, o failover para uma réplica secundária é rápido, pois a réplica já existe e tem os dados anexados a ela. Em um failover, você não precisa de um ouvinte. O gateway redireciona sua conexão para o primário mesmo após um failover. Essa alternância ocorre rapidamente e, em seguida, a malha de serviço se encarrega da rotação de outra réplica secundária.
Hiperescala
A camada de serviço de Hiperescala só está disponível no Banco de Dados SQL do Azure. Essa camada de serviço tem uma arquitetura exclusiva porque usa níveis de camadas de caches e servidores de página para expandir a capacidade de acessar rapidamente as páginas do banco de dados sem precisar acessar o arquivo diretamente.
Como essa arquitetura usa servidores de páginas emparelhadas, você pode dimensionar horizontalmente para colocar todos os dados em camadas de cache. Essa nova arquitetura também permite que a Hiperescala ofereça suporte a bancos de dados de até 100 TB. Como ela usa instantâneos, backups quase instantâneos de banco de dados podem ocorrer independentemente do tamanho. As restaurações de banco de dados levam minutos, em vez de horas ou dias. Você também pode aumentar ou reduzir em tempo constante para acomodar suas cargas de trabalho.
É interessante observar como o serviço de log foi extraído nessa arquitetura. O serviço de log é usado para alimentar as réplicas e os servidores de página. As transações podem ser confirmadas quando o serviço de log é reforçado na 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 de outras camadas de serviço, você pode determinar se deseja réplicas secundárias. Você pode configurar de zero a quatro réplicas secundárias, todas as quais podem ser usadas para escala de leitura.
Como nas outras camadas de serviço, um failover automático ocorrerá 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 você não tiver réplicas e um failover ocorrer, o cenário será semelhante ao da camada de serviço de Uso Geral: o alocador de serviço primeiro precisa encontrar a capacidade sobressalente. Se você tiver uma ou mais réplicas, a recuperação será mais rápida e mais alinhada à camada de serviço Comercialmente Crítica.
A opção de Comercialmente Crítico mantém o desempenho e a disponibilidade mais altos para cargas de trabalho com gravações de log pequenas que precisam de baixa latência, mas a camada de serviço de Hiperescala 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 até quatro réplicas secundárias para níveis mais altos de escala de leitura. Portanto, você precisará considerar sua carga de trabalho ao escolher entre as duas opções.