SQL Server 2014 – Testes de Failover Parte 1 – Indisponibilidade do Servidor e da Rede

Olá pessoal, tudo bom?

Neste série composta de 2 posts apresentarei 5 testes de failover simples e básicos que podem ser feitos sobre um ambiente SQL Server 2014 com AlwaysON implantado. O objetivo é compartilhar alguns dos cenários mais comuns onde uma indisponibilidade possa acontecer e apresentar o resultado de cada um na estrutura aqui utilizada.

Descrição do ambiente

Meu laboratório é composto por duas máquinas: SQL-AON01 e SQL-AON02, ambas com Windows Server 2012 R2, parte do mesmo domínio e cada uma delas tendo uma instância standalone do SQL Server 2014 instalada e totalmente funcional. Por fim, os dois servidores virtuais estão configurados em cluster.

Ainda na contextualização do cenário: cada servidor possui 3 unidades lógicas: C, E e F, onde estão binários do Windows e do SQL Server, datafiles e também os log files, respectivamente nas 3 unidades mencionadas anteriormente. Fiz o restore do banco de dados AdventureWorks2014 conforme a responsabilidade de cada disco (dados e logs nas unidades E e F) e criei um grupo de disponibilidade envolvendo as duas máquinas para acomodar esse BD.

O grupo de disponibilidade foi criado com as seguintes configurações:

  • Nome do grupo de disponibilidade: AG01
  • Nome do listener: VN01 (192.168.0.13)
  • Modo de disponibilidade: Synchronous (nas duas máquinas)
  • Modo de failover: Automatic (nas duas máquinas)
  • Conexões permitidas: Allow all connections (nas duas máquinas)
  • Réplica acessível pra leitura: Read-intent only (nas duas máquinas)
  • Prefências de backup: Prefer Seconday (default)

Tendo o ambiente descrito, que comecem os jogos! =D

Observação

Antes de começar os testes, gostaria de antecipar que, sempre que eu mencionar “máquina primária” estarei falando da máquina responsável pela escrita e leitura do Always On mesmo, ou seja, o servidor onde o recurso do Cluster está executando naquele momento. Por exemplo, na ilustração abaixo, a máquina SQL-AON01 é meu servidor primário.

image

 

Teste 1: Desligar o servidor primário

Bom, este teste contempla o cenário mais comum: a máquina primária sofrer uma indisponibilidade. Isso pode acontecer por N motivos, como por exemplo, uma falha de hardware, queda de energia, faxineira tropeçando na tomada, enfim, o que sua imaginação puder imaginar, quando se fala em problema, o infinito parece ser o limite.

Com as configurações do meu ambiente, em uma eventual queda da máquina primária, a máquina secundária (lembrando que o modo de failover foi configurado como automático) irá assumir automaticamente a responsabilidade pelo nome virtual (VN01) e responderá as solicitações recebidas através dele.

Antes da indisponibilidade:

Hyper-V

image

Failover Cluster Manager

image

Object Explorer

image

AlwaysON Dashboard

image

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

image

Server shutdown

Ao detectar a indisponibilidade da máquina primária, o serviço de cluster deve acionar instantaneamente a outra máquina, tornando-a o servidor responsável pelo recurso. Este processo no AlwaysON é normalmente mais rápido do que é feito no Failover Cluster porque não há recursos compartilhados entre as máquinas para serem movidos entre elas, como eram as unidades lógicas (discos) onde os bancos de dados ficavam armazenados.

Failover Cluster Manager

image

Depois do failover

Depois do failover o ambiente deve responder normalmente na máquina que assumiu a responsabilidade pelo nome virtual (VN01) e assim permitir que as aplicações se conectem normalmente aos bancos de dados gerenciados pelo AlwaysON.

Lembrando que o SQL Server, ao realizar o failover do grupo de disponibilidade, não mantém as conexões que já estavam abertas e em execução na máquina que ficou indisponível. O SQL Server fará rollback das atividades feitas e que ainda não foram confirmadas (commit) por essas conexões, assim como dará um erro de conexão ao usuário assim que ele tentar executar um novo comando caso não haja o devido tratamento na aplicação.

Hyper-V

image

Failover Cluster Manager

image

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

image

Conexão aberta antes do failover

image

Conclusão

Teste 1: ok. Certo? Indisponibilidade total: aproximadamente 10 segundos.

 

Teste 2: Remover a conexão de rede da máquina primária

O próximo teste simulará uma falha de comunicação entre as duas máquinas, problema que pode ocorrer quando, por exemplo, se a placa de rede responsável pelo heartbeat do cluster falhe, deixando assim os servidores sem comunicação um com o outro. Esse problema também acontecer caso os ambientes estiverem em localizações diferentes e todos os links (supondo que haja redundância) falhem simultâneamente.

Antes da indisponibilidade

Novamente, antes de iniciar este teste, o meu ambiente se apresenta totalmente funcional, exatamente como foi ilustrado nas imagens apresentadas no teste 1: as duas máquinas se comunicando normalmente, AlwaysON completamente saudável, máquina SQL-AON01 respondendo como primária e nome virtual VN01 apontando pra ela.

Antes de iniciar este teste, eu gostaria de destacar a configuração de votos existente no cluster para evitar que um problema chamado “split brain” aconteça. Esse sistema de votação entre as máquinas existe para que, caso aconteça uma falha de comunicação entre dois ou mais grupos diferentes de servidores, o cluster possa ativar apenas um dos “lados”, evitando que tenhamos um cérebro dividido, ou seja, dois lados respondendo pelo mesmo recurso.

image

Falta de conectividade

Para simular a falha de comunicação, vou apenas “desconectar o cabo de rede” do servidor removendo a conexão da placa de rede virtual.

Hyper-V

image

Assim que desconectada a placa de rede do switch virtual do Hyper-V, o failover se inicia e a máquina (ou o grupo de servidores) que dispunha de mais votos na coluna “current value” assume o controle do grupo de disponibilidade do AlwaysON. Em meu lab, como é a máquina SQL-AON02 que possui a maioria dos votos (1 contra 0) ela assume o recurso. Se houvessem mais servidores no meu cluster, aquele “lado” que tivesse mais votos seria o responsável pelos grupos de disponibilidade (desde que ele faça parte do AG).

Depois do failover

Após o failover, as duas máquinas ainda estão ligadas. A máquina SQL-AON01, que teve a conexão de rede interrompida ainda responde a conexões feitas através de outras interfaces de rede, caso existam e permitam que isso aconteça. Já a máquina SQL-AON02 assume a responsabilidade pelo grupo de disponibilidade e passa a responder pelo nome virtual VN01.

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

image

Conclusão

Teste 2: também ok. Indisponibilidade de pouco mais de 10 segundos. Este pequeno acréscimo de tempo é devido ao tempo da máquina SQL-AON02 assegurar que a máquina SQL-AON01 está indisponível pra ela ou se foi apenas uma intermitência rápida de rede.

Fim da Parte 1

Os outros 3 testes desta publicação poderão ser encontrados na parte 2.

Forte abraço.

Felipe de Assis

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

Anúncios

Um comentário sobre “SQL Server 2014 – Testes de Failover Parte 1 – Indisponibilidade do Servidor e da Rede

  1. Pingback: SQL Server 2014 – Testes de Failover Parte 2 – Indisponibilidade do SQL Server e dos Discos | Felipe de Assis

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