Explorar as opções de alta disponibilidade e recuperação de desastre
Para prever uma solução para VMs (máquinas virtuais), primeiro é necessário compreender as opções de disponibilidade para implantações baseadas em IaaS.
Infraestrutura como serviço em comparação a plataforma como serviço
Quando se trata de disponibilidade, a escolha entre IaaS e PaaS faz diferença. Com a 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 o grupo responsável pelo SQL Server teria a opção de soluções de HADR (alta disponibilidade e de recuperação de desastres) e bastante controle sobre como essa solução foi configurada.
Com as implantações baseadas em PaaS, como o Banco de Dados SQL do Azure, as soluções de HADR são criadas no 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 no design final da sua solução de HADR.
Recursos de HADR do SQL Server para a máquina virtual do Azure
Com a 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 |
|---|---|
| FCI (instância de cluster de failover) AlwaysOn | Instância |
| AG (grupo de disponibilidade) Always On | Banco de dados |
| Envio de logs | Banco de dados |
Uma instância do SQL Server é a instalação completa de SQL Server (binários, todos os objetos dentro da instância, incluindo itens como logons, trabalhos de SQL Server Agent e bancos de dados). A proteção em nível de 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 aplicativos usam. Há bancos de dados do sistema dos quais 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 os próprios bancos de dados do sistema. Proteção no nível do banco de dados significa que tudo o que estiver no banco de dados ou for capturado no log de transações para um usuário ou banco de dados de aplicativo será contabilizado como parte do recurso de disponibilidade. Tudo o que existe fora do banco de dados ou que não é capturado como parte do log de transações, como trabalhos do SQL Server Agent e servidores vinculados, deve ser processado manualmente para garantir que o servidor de destino possa funcionar como o primário se houver um evento de failover planejado ou não planejado.
FCIs e 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, um Pacemaker.
Instâncias do cluster de failover do AlwaysOn
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 que é diferente daquele dos servidores (ou nós) subjacentes que participam do cluster. O nome e o endereço IP também devem ser diferentes daqueles do mecanismo de cluster subjacente. Os aplicativos e os usuários finais usariam o nome exclusivo da FCI para acesso. Essa abstração permite que os aplicativos não precisem saber em que local a instância está em execução. Uma grande diferença entre as FCIs baseadas no Azure versus as FCIs locais é que, para o Azure, um ILB (balanceador de carga interno) é necessário. 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, quer seja iniciado manualmente ou ocorra devido a um problema, toda a instância é reiniciada em outro nó. Isso significa que o processo de failover é uma parada completa 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 puderem lidar e se recuperar dessa interrupção poderão se reconectar automaticamente.
Na inicialização no outro nó, a instância passa pelo processo de recuperação. A FCI será consistente com o ponto de falha, portanto, tecnicamente, não haverá perda de dados, mas as transações que precisam ser revertidas farão isso como parte da recuperação. Conforme já observado, como essa é uma proteção em nível de instância, tudo o que é necessário (logons, SQL Server Agent trabalhos etc.) já está lá para que as empresas possam continuar como de costume quando os bancos de dados estiverem prontos.
As FCIs exigem uma cópia de um banco de dados, mas esse também é seu ponto único 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 obtido por meio de um compartilhamento de arquivo Premium do Azure, iSCSI, Disco Compartilhado do Azure, Espaços de Armazenamento Diretos (S2D) ou uma solução de terceiros com suporte, como SIOS DataKeeper. As FCIs que usam a edição Standard do SQL Server podem ter até dois nós. As FCIs também exigem o uso do AD DS (Active Directory Domain Services) e de DNS (serviços de nomes de domínio), assim, 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 o envio de logs ou AGs.
Grupos de disponibilidade AlwaysOn
Os AGs foram introduzidos no SQL Server 2012 Edição Enterprise e, do SQL Server 2016 em diante, também estão na Edição Standard. Na Edição Standard, um AG pode conter um banco de dados, enquanto, na Edição Enterprise, um AG pode ter mais de um banco de dados. Embora AGs compartilhem algumas semelhanças com as FCIs, eles são basicamente diferentes.
A principal diferença entre uma FCI e um AG é que o 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. É em uma réplica secundária que a primária envia transações sobre o 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 podem receber transações, mas não podem ser uma cópia totalmente gravável até que a réplica se torne a primária. Um AG na Edição Standard pode ter no máximo duas réplicas (uma primária e outra secundária), enquanto a Edição Enterprise dá suporte a até nove (uma primária e oito secundárias). Uma réplica secundária é inicializada com base em um backup do banco de dados ou 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 para 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 o próprio nome e endereço IP, que são diferentes daqueles de qualquer outro recurso (WSFC, nó etc.). O ouvinte também requer um ILB e passa por uma parada e início. Os aplicativos e os 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. Podem ser feitas conexões diretamente com a instância. Com a Edição Enterprise, as réplicas secundárias na Edição Enterprise também podem ser configuradas para acesso somente leitura, se desejado, e podem ser usadas para outras funcionalidades, como DBCCs (verificações de consistência de banco de dados) e backups.
Os AGs podem ter um tempo de failover mais rápido em comparação a uma FCI, e esse é um dos motivos pelos quais 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 o volume de dados dos bancos de dado na réplica primária for de 1 TB, cada réplica também terá esse volume. Se houver cinco réplicas, isso significa que você precisará de 5 TB de espaço.
Lembre-se de que qualquer objeto existente fora do banco de dados ou que não seja capturado no log de transações do banco de dados deve ser criado e contabilizado manualmente em qualquer outra instância do SQL Server caso a 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 em nível de instância e servidores vinculados. Se você puder usar a autenticação do Windows ou bancos de dados independentes com o AGs, o acesso será simplificado.
Muitas organizações podem enfrentar desafios para implementar arquiteturas altamente disponíveis e podem precisar apenas da alta disponibilidade fornecida pela plataforma do Azure ou usando uma solução de PaaS como a Instância Gerenciada de SQL do Azure. Antes de examinarmos as soluções da plataforma Azure, há outro recurso do SQL Server que você deve conhecer: o envio de logs.
Envio de logs
O envio de logs já 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 desastre, mas também pode ser usado para aprimorar a disponibilidade local.
O envio de log, como AGs, fornece proteção no nível de banco de dados, o que significa que você ainda precisa considerar os trabalhos do SQL Server Agent, os servidores vinculados, os logins no nível da instância etc. O envio de logs não oferece abstração nativamente, assim, a alternância para outro servidor que participa do envio de logs deve poder tolerar uma alteração de nome. Se isso não for possível, há métodos, como um alias DNS, que podem ser configurados 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 passiva. Essa nova cópia do banco de dados é conhecida como um banco de dados secundário. Um processo automatizado incorporado ao SQL Server fará o backup automaticamente do log de transações do banco de dados primário, copiará o backup para o servidor em espera e, por fim, restaurará o backup no modo de espera.
Os recursos de HADR do SQL Server não são as únicas opções para aprimorar a disponibilidade de IaaS. Alguns recursos no Azure também devem ser considerados.