Explore opções de alta disponibilidade e recuperação de desastres

15 minutos

Para visualizar uma solução para máquinas virtuais (VMs), você deve primeiro entender as opções de disponibilidade para implantações baseadas em IaaS.

Infraestrutura como serviço versus plataforma como serviço

Quando se trata de disponibilidade, a escolha de IaaS ou PaaS faz a diferença. Com IaaS, você tem uma máquina virtual, o que significa que há um sistema operacional com uma instalação do SQL Server. O administrador ou grupo responsável pelo SQL Server teria uma escolha de soluções de alta disponibilidade e recuperação de desastres (HADR) e um grande controle sobre como essa solução foi configurada.

Com implantações baseadas em PaaS, como o Banco de Dados SQL do Azure, as soluções HADR são incorporadas ao recurso e, muitas vezes, só precisam ser habilitadas. Há opções mínimas que podem ser configuradas.

Devido a essas diferenças, a escolha de IaaS ou PaaS pode influenciar o design final da sua solução HADR.

Recursos HADR do SQL Server para a Máquina Virtual do Azure

Ao usar IaaS, você pode usar os recursos fornecidos pelo SQL Server para aumentar a disponibilidade. Em alguns casos, eles podem ser combinados com recursos no nível do Azure para aumentar ainda mais a disponibilidade.

Os recursos disponíveis no SQL Server são mostrados na tabela abaixo

Nome do recurso	Protege
Instância de cluster de failover (FCI) Always On	Instância
Grupo de disponibilidade Always On (AG)	Base de Dados
Envio de Registos	Base de Dados

Uma instância do SQL Server é a instalação completa do SQL Server (binários, todos os objetos dentro da instância, incluindo itens como logons, trabalhos do SQL Server Agent e bancos de dados). A proteção no nível da instância significa que toda a instância é contabilizada no recurso de disponibilidade.

Um banco de dados no SQL Server contém os dados que os usuários finais e os aplicativos usam. Há bancos de dados do sistema nos quais o SQL Server depende, bem como bancos de dados criados para uso por usuários finais e aplicativos. Uma instância do SQL Server sempre tem seus próprios bancos de dados do sistema. Proteção no nível de banco de dados significa que tudo o que está no banco de dados ou é capturado no log de transações de um banco de dados de usuário ou aplicativo é contabilizado como parte do recurso de disponibilidade. Qualquer coisa que exista fora do banco de dados ou que não seja capturada como parte do log de transações, como trabalhos do SQL Server Agent e servidores vinculados, deve ser tratada manualmente para garantir que o servidor de destino possa funcionar como o principal se houver um evento de failover planejado ou não planejado.

Tanto as FCIs quanto as AGs exigem um mecanismo de cluster subjacente. Para implantações do SQL Server em execução no Windows Server, é um WSFC (Cluster de Failover do Windows Server) e para Linux é Pacemaker.

Instâncias de cluster de failover sempre ativas

Uma FCI é configurada quando o SQL Server é instalado. Uma instância autônoma do SQL Server não pode ser convertida em uma FCI. A FCI recebe um nome exclusivo, bem como um endereço IP diferente dos servidores subjacentes, ou nós, que participam do cluster. O nome e o endereço IP também devem ser diferentes do mecanismo de cluster subjacente. Aplicativos e usuários finais usariam o nome exclusivo da FCI para acesso. Essa abstração permite que os aplicativos não precisem saber onde a instância está sendo executada. Uma grande diferença entre FCIs baseadas no Azure versus FCIs locais é que, para o Azure, é necessário um ILB (balanceador de carga interno). O ILB é usado para ajudar a garantir que aplicativos e usuários finais possam se conectar ao nome exclusivo da FCI.

Quando uma FCI faz failover para outro nó de um cluster, seja ele iniciado manualmente ou devido a um problema, toda a instância é reiniciada em outro nó. Isso significa que o processo de failover é um ponto final e um início do SQL Server. Todos os aplicativos ou usuários finais conectados à FCI serão desconectados durante o failover e somente os aplicativos que podem lidar e se recuperar dessa interrupção podem se reconectar automaticamente.

Ao iniciar no outro nó, a instância passa pelo processo de recuperação. A FCI será consistente até o ponto de falha, portanto, tecnicamente, não haverá perda de dados, mas quaisquer transações que precisem ser revertidas o farão como parte da recuperação. Como observado acima, como se trata de proteção em nível de instância, tudo o que é necessário (logons, trabalhos do SQL Server Agent etc.) já está lá para que os negócios possam continuar normalmente assim que os bancos de dados estiverem prontos.

As FCIs exigem uma cópia de um banco de dados, mas esse também é seu único ponto de falha. Para garantir que outro nó possa acessar o banco de dados, as FCIs exigem alguma forma de armazenamento compartilhado. Para arquiteturas baseadas no Windows Server, isso pode ser feito por meio de um Compartilhamento de Arquivos Premium do Azure, iSCSI, Disco Compartilhado do Azure, Espaços de Armazenamento Diretos (S2D) ou uma solução de terceiros com suporte, como o SIOS DataKeeper. As FCIs que usam o Standard Edition do SQL Server podem ter até dois nós. As FCIs também exigem o uso dos Serviços de Domínio Ative Directory (AD DS) e dos Serviços de Nomes de Domínio (DNS), o que significa que o AD DS e o DNS devem ser implementados em algum lugar no Azure para que uma FCI funcione.

Usando o Windows Server 2016 ou posterior, as FCIs podem usar a Réplica de Armazenamento para criar uma solução nativa de recuperação de desastres para FCIs sem precisar usar outro recurso, como envio de logs ou AGs.

Grupos de Disponibilidade AlwaysOn

Os AGs foram introduzidos no SQL Server 2012 Enterprise Edition e, a partir do SQL Server 2016, também estão no Standard Edition. Na Standard Edition, uma AG pode conter uma base de dados, enquanto na Enterprise Edition, uma AG pode ter mais do que uma base de dados. Embora as AG partilhem algumas semelhanças com as FCI, na maioria dos aspetos são diferentes.

A maior diferença entre uma FCI e uma AG é que as AGs fornecem proteção no nível do banco de dados. A réplica primária é a instância que participa de um AG que contém os bancos de dados de leitura/gravação. Uma réplica secundária é onde o primário envia transações pelo transporte de log para mantê-lo sincronizado. A movimentação de dados entre uma réplica primária pode ser síncrona ou assíncrona. Os bancos de dados em qualquer réplica secundária estão em um estado de carregamento, o que significa que eles podem receber transações, mas não podem ser uma cópia totalmente gravável até que essa réplica se torne a principal. Um AG na Standard Edition pode ter no máximo duas réplicas (uma primária, uma secundária), enquanto a Enterprise Edition suporta até nove (uma primária, oito secundárias). Uma réplica secundária é inicializada a partir de um backup do banco de dados ou, a partir do SQL Server 2016, você pode usar um recurso chamado 'propagação automática'. A propagação automática usa o transporte de fluxo de log para transmitir o backup para a réplica secundária de cada banco de dados do grupo de disponibilidade usando os pontos de extremidade configurados.

Um AG fornece abstração com o ouvinte. O ouvinte funciona como o nome exclusivo atribuído a uma FCI e tem seu próprio nome e endereço IP que é diferente de qualquer outra coisa (WSFC, nó, etc.). O ouvinte também requer um ILB e passa por uma parada e início. Aplicativos e usuários finais podem usar o ouvinte para se conectar, mas ao contrário de uma FCI, se desejado, o ouvinte não precisa ser usado. Conexões diretamente com a instância podem ocorrer. Com o Enterprise Edition, as réplicas secundárias no Enterprise Edition também podem ser configuradas para acesso somente leitura, se desejado, e podem ser usadas para outras funcionalidades, como verificações de consistência de banco de dados (DBCCs) e backups.

Os AGs podem ter um tempo de failover mais rápido em comparação com uma FCI, o que é uma razão pela qual eles são atraentes. Embora os AGs não exijam armazenamento compartilhado, cada réplica tem uma cópia dos dados, o que aumenta o número total de cópias do banco de dados e os custos gerais de armazenamento. O armazenamento é local para cada réplica. Por exemplo, se a pegada de dados dos bancos de dados na réplica primária for de 1 TB, cada réplica também terá o mesmo. Se houver cinco réplicas, isso significa que você precisa de 5 TB de espaço.

Lembre-se de que qualquer objeto que exista fora do banco de dados ou não seja capturado no log de transações do banco de dados deve ser criado manualmente e contabilizado em qualquer outra instância do SQL Server, caso essa instância precise se tornar a nova réplica primária. Exemplos de objetos pelos quais você seria responsável incluem trabalhos do SQL Server Agent, logons no nível da instância e servidores vinculados. Se você puder usar a autenticação do Windows ou usar bancos de dados contidos com AGs, isso simplificará o acesso.

Muitas organizações podem enfrentar desafios para implementar arquiteturas altamente disponíveis e podem precisar apenas da alta disponibilidade fornecida pela plataforma Azure ou usando uma solução PaaS como a Instância Gerenciada SQL do Azure. Antes de examinarmos as soluções da plataforma Azure, há um outro recurso do SQL Server que você deve conhecer: envio de logs.

Envio de registos

O envio de logs existe desde os primórdios do SQL Server. O recurso é baseado em backup, cópia e restauração e é um dos métodos mais simples de obter HADR para SQL Server. O envio de logs é usado principalmente para recuperação de desastres, mas também pode ser usado para melhorar a disponibilidade local.

O envio de logs, como AGs, fornece proteção no nível do banco de dados, o que significa que você ainda precisa levar em conta os trabalhos do SQL Server Agent, servidores vinculados, logons no nível da instância, etc. Não há abstração fornecida nativamente pelo envio de logs, portanto, uma mudança para outro servidor que participe do envio de logs deve ser capaz de tolerar uma alteração de nome. Se isso não for possível, existem métodos como um alias DNS, que pode ser configurado na camada de rede para tentar mitigar os problemas de alteração de nome.

O mecanismo de envio de logs é simples: primeiro, faça um backup completo do banco de dados de origem no servidor primário, restaure-o em um estado de carregamento (STANDBY ou NORECOVERY) em outra instância conhecida como servidor secundário ou espera ativa. Essa nova cópia do banco de dados é conhecida como banco de dados secundário. Um processo automatizado integrado ao SQL Server fará o backup automático do log de transações do banco de dados primário, copiará o backup para o servidor em espera e, finalmente, restaurará o backup no modo de espera.