SQL Server 2014 – Testes de Failover Parte 2 – Indisponibilidade do SQL Server e dos Discos

Nesta parte 2, veremos mais três testes de failover feitos sobre o mesmo ambiente (SQL Server 2014) utilizado na parte 1, previamente publicada neste mesmo blog. Nesta segunda e última publicação da série, veremos o que acontece quando o serviço do SQL Server fica indisponível, não importando o motivo, e também como o ambiente se comporta em uma eventual queda dos discos onde os bancos de dados de usuário estão armazenados.

Teste 3: Desligar o serviço do SQL Server na máquina primária

Neste terceiro teste, irei desligar o serviço do SQL Server para simular sua queda, o que pode acontecer por N motivos, seja problemas nos bancos de dados de sistema, alguma falha fatal no SQL Server causada por algum dump de memória, entre outras possíveis causas.

Antes da indisponibilidade

Novamente, antes da indisponibilidade, meu ambiente está intacto, da mesma forma que estava ao iniciarmos os dois testes anteriores.

SQL Server shutdown

Vamos desligar o serviço da máquina SQL-AON01, que até então era o servidor primário do meu grupo de disponibilidade.

SQL Server Configuration Manager – SQL-AON01

image

Depois do failover

Automaticamente, ao desligar o serviço do SQL Server na máquina primária, o failover é acionado e a máquina SQL-AON02 assume o grupo de disponibilidade, assim como aconteceu nos testes anteriores.

Failover Cluster Manager

image

Always On Dashboard

image

Conexão read-write através do Virtual Name

image

Observação

Eu gostaria de estender esse teste um pouquinho. Vou restabelecer a máquina primária, iniciando os serviços do SQL Server e do SQL Server Agent. Neste ponto, o AlwaysON deve sincronizar a máquina novamente e restabelecer sua operação normal, mantendo a máquina SQL-AON02 como primária.

image

Agora vou desligar o serviço do SQL Server na máquina SQL-AON02 (atualmente primária do meu grupo de disponibilidade chamado AG01).

image

E não será feito um novo failover. Ao invés disso, o grupo de recursos (lá no Failover Cluster Manager) ficará parcialmente indisponível, mesmo que haja outra máquina totalmente saudável para assumir a responsabilidade pelo serviço.

image

Isso acontece devido a política flexível de failover, recurso introduzido nas versões mais novas do Windows Server. Neste caso, há uma configuração para que o grupo de recursos não faça failover caso aconteça um segundo problema no intervalo de 6 horas. Essa configuração pode ser acessada clicando com o botão direito do mouse no grupo de recursos (role), abrindo a janela de propriedades e verificando os ajustes feitos sob a aba “Failover”, conforme imagem abaixo:

Propriedades da role – Failover Cluster Manager

image

Concluindo: o fato do failover não ser realizado é absolutamente normal. De fato, é o comportamento esperado para essa situação, evitando assim que o grupo de disponibilidade fique fazendo failover incessantemente no caso de inúmeras quedas em um curso período de tempo. Como podemos ver, esse valor pode ser ajustado conforme desejado, no entanto, é uma opção que exige bastante atenção pois altera o comportamento do failover automático.

Conclusão

Se caso o serviço do SQL Server ficar indisponível, o AlwaysON fará o failover e novamente meu downtime será mínimo: aproximadamente 10 segundos (em meu lab).

Teste 4: Remover o disco de dados do banco de dados

No quarto teste, vou remover a unidade lógica onde os dados do banco de dados AdventureWorks2014 está. A ideia é simular uma indisponibilidade no subsistema de disco, como se apenas a unidade lógica dos datafiles no servidor primário apresentasse a falha, deixando a unidade de log intacta, completamente acessível pelo serviço do SQL Server.

Antes da indisponibilidade

Ambiente totalmente funcional, em perfeito estado.

Indisponibilidade do disco

Simplesmente coloquei offline o disco de dados (disk 1 na imagem abaixo).

image

Para o cluster, ainda sim está tudo funcional.

image

Para o Always On, tudo normal também.

image

Mas ao conectar no VN01 (que automaticamente me direcionará a máquina primária) e executar uma query sobre uma tabela que não esteja em cache, receberei um erro informando que há um problema no banco de dados.

image

Neste ponto, tanto o Failover Cluster quanto o AlwaysON não apresentarão nenhum indicativo de problema, muito menos farão failover. Isso acontece porque na versão 2014 do SQL Server, não há detecção a falhas no banco de dados propriamente dito.

Interessante que mesmo no object explorer, o banco de dados continuará exibindo status “synchronized” e estará aparentemente online. Qualquer query que tentar acesso a algum objeto deste banco de dados será sumariamente desconectada do SQL Server.

image

Conclusão

Em uma situação como essa, há a necessidade de intervenção humana para acionar o failover manualmente e habilitar a máquina secundária para assumir a responsabilidade pelo grupo de disponibilidade e consequentemente, pelo nome virtual e pelos bancos de dados.

image

Após o failover ser realizado (em 10 segundos) na máquina secundária, o banco de dados volta a responder as queries normalmente, visto que agora está sobre um servidor que possui toda sua estrutura intacta, com os discos de dados totalmente funcional. Na máquina onde o problema ocorreu, o banco de dados pode apresentar depois do failover o seguinte status: “Not Sinchronizing / Recovery Pending”.

image

Observação

Dependendo de como for restabelecida a máquina secundária, diferentes ações devem ser tomadas para fazer com que o ambiente fique exatamente como antes.

Se apenas os discos voltarem sem necessidade de um restart no servidor, uma das alternativas é remover aquele servidor daquele grupo de disponibilidade, sincronizar manualmente o banco de dados através dos backups de log efetuados na máquina primária (dependendo de quanto tempo ele ficou “fora”) e finalmente adicionar o servidor novamente no AG, selecionando a opção “Join Only”. Vale lembrar que essa é apenas uma possibilidade dentre outras possíveis.

Se durante ou após o troubleshooting o servidor tiver sido reiniciado (também dependendo de quanto tempo ele ficou “fora”) ele pode voltar em processo de sincronização, já sincronizado ou em casos extremos, fazendo com que seja necessário o mesmo processo mencionado anteriormente: a resincronização do banco de dados com o servidor primário.

Teste 5: Remover o disco de log do banco de dados

O quinto e último teste desta série será basicamente idêntico ao teste 4, porém ao invés de removermos o disco de dados, faremos isso com o disco de log do banco AdventureWorks2014.

Antes da indisponibilidade

Assim como todos os testes anteriores, iniciamos com o ambiente estável, os dois nós funcionando normalmente e todos os recursos disponíveis.

Indisponibilidade do disco

Repeti o mesmo procedimento do teste anterior. Resultado: Disco de log offline.

Disk Manager

image

Neste ponto, o que aconteceu? Absolutamente nada… ainda.

O primeiro comando Select executado posteriormente ao problema foi realizado com sucesso, haja vista que o disco de dados ainda está disponível, então independente de a tabela já estar ou não em memória, a leitura dos dados é concluída com sucesso.

Ao executar o primeiro comando que provocasse uma escrita ao log, como é o caso do Update, a conexão do usuário é eliminada e a seguinte mensagem de erro é disparada.

image

Na sequência, o SQL Server identifica que há um problema neste banco de dados e o marca como “Recovery Pending” conforme habitual, porém, o failover automático não é acionado. Neste caso específico e neste momento, o banco de dados está indisponível mesmo tendo uma solução de alta disponibilidade montada para suportá-lo.

Conclusão

Assim como no teste anterior, o acionamento manual do failover também é necessário, visto que o AlwaysON do SQL Server 2014 não possui detecção de falhas a nível de banco de dados, funcionalidade que será uma das novidades do SQL Server 2016.

Uma vez que o failover tenha sido executado, o banco de dados volta a responder as conexões, agora na máquina secundária, enquanto no servidor onde o disco foi removido o status do database passa a ser “Not Sinchronizing / Recovery Pending” novamente.

Adicionalmente, a mesma possível estratégia mencionada no teste 4 também pode ser utilizada na situação descrita neste quinto teste para restabelecer o funcionamento do ambiente.

Conclusão Geral

Nesta publicação realizei e documentei 5 testes de alta disponibilidade considerados básicos sobre uma estrutura de alta disponibilidade montada com a feature AlwaysON do SQL Server 2014. Vimos como o ambiente reagiu a cada uma delas e também como algumas opções possuem influência sobre o comportamento do AlwaysON em caso de uma falha.

Mesmo que tenham sido testes relativamente básicos e simples, podemos concluir que o AlwaysON oferece um excelente nível de proteção, pois mesmo que não haja failover automático em alguns casos – como nos testes 4 e 5 – temos a possibilidade de acionar manualmente o servidor secundário, reduzindo significativamente o downtime e consequentemente, minimizando o impacto disso nos negócios da empresa.

Espero que tenham gostado!

Forte abraço.

Felipe de Assis

https://br.linkedin.com/in/fdassis

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s