[Série] – AlwaysOn – Introdução ao Recurso (Parte1)

Posted on janeiro 22, 2013

2


Introdução

O SQL Server 2012 traz significantes mudanças em relação ao comportamemento de HA e DR dentro do banco de dados. Cada vez mais as organizações precisam estar com suas bases de dados sempre disponíveis e operantes, sendo assim devemos evitar o máximo de downtime de um servidor assim como a perda de dados de uma empresa.

 

HA e DR

O HA = High Availability ou Alta disponibilidade e o DR = Disaster Recovery ou plano de recuperação de disastres, tem como principal objetivo minimizar o impacto do downtime dos servidores de uma empresa. Uma plataforma para ser considerada altamente disponível deve possuir o seguinte cálculo:

 

image

(Figura 1 – Cálculo de Uptime de um servidor.)

 

Ou seja, o resultado desse cálculo gera um valor no qual chamamos de os 9’s, que significa o número anual de minutos que os servidores podem estar em downtime.

image

(Figura 2 – Quantidade de downtime por tempo.)

 

Como solução anterior, no SQL Server 2012 possuíamos a estratégia de failover clustering para proteger toda a instância do banco de dados, junto com Database Mirroring (espelhamento de banco de dados) para cada base de dados, provendo assim um sistema com alta disponibiliade porém não totalmente eficaz e integrado. Porém, para as organizações que desejam mais de um datacenter, a solução é possuir um espelhamento de banco de dados com o log shipping, essa seria outra opção para gerar assim uma alta disponibilidade das informações armazenadas na empresa.

 

image

(Figura 3 – Modo Assíncrono do espelhamento de dados ente servidores em lugares geograficamente diferentes.)

 

image

(Figura 4 – Modo síncrono do espelhamento de dados entre servidores geograficamente iguais e log shipping para servidores de diferentes locais.)

 

Pensando em todos esses problemas e dificuldades que enfrentávamos, o SQL Server 2012 provê uma nova solução chamada AlwaysOn. Esse novo recurso faz com que seja possível realizar a proteção em alto nível como o Failover de diversos bancos de dados, possuir múltiplos secondários dentre outras opções que veremos logo a frente.

 

AlwaysOn Availability Groups

O AlwaysOn Availability Group provê uma alternativa ao espelhamento de banco de dados, esse novo recurso possibilita a abilidade de realizar failover automático ou manual de grupos de bancos de dados, sendo possível possuir até 4 locais secundários.

Essa nova solução provê proteção de todas as informações “sem” perda de dados e é totalmente flexível. A mesma pode ser realizada com armazenamento local ou compartilhado, diferente do Cluster, e ainda possuindo movimento dos dados entre os eles de forma sincróna ou assíncrona. Uma de suas grandes qualidades é o failover entre instâncias assim como reparação de páginas danificadas.

 

image

(Figura 5 – A primeira réplica replicando os dados de forma síncrona para duas réplicas no mesmo datacenter e ainda provendo a réplica 4 que está no servidor secundário a informaçõe de forma assíncrona – Possibilidades do AlwaysON.)

 

Conceitos e Terminologia

Os Availability Groups são criados a partir do Windows Failover Clustering. O primeiro passo a ser configurado é realizar a criação de um Windows Failover Cluster (WFC) ou seja realizar a criação de um grupo de servidores alto disponíveis.

 

Availability Replica Roles

Cada Availability Group ou seja cada grupo contendo diversos bancos de dados, deverá possuir 2 ou mais parceiros que são chamados de Availability Replicas ou seja replicas idênticas, para que assim o failover de uma máquina para outra possa acontecer.

Cada instância do SQL Server no Availability Group é armazenada no Failover Cluster Instance (FCI). Esse recurso provê em nível servidor a alta disponibilidade das máquinas e recursos utilizados. Cada Réplica do Availability Group armazena uma cópia idêntica dos bancos de dados em cada servidor e instância do banco de dados.

Modos de Sincronização de Dados

A movimentação dos dados de uma réplica primária para uma réplica secundária é feita de forma síncrona ou assíncrona.

Utilizando a forma síncrona = Synchronous-Commit Mode

A transação para ser efetivada, deverá ser aceita em ambos servidores, isso significa consideravelmente a latência em rede. Essa opção é recomendada para servidores que compartilham uma rede de alto nível.

Utilizando a forma assíncrona = Assynchronous-Commit Mode

Aceita a transação na primária sem o parceiro ter escrito essa informação ainda em disco. Isso aumenta a performance entre os servidores.

 

Modos de Failover nos Availability Groups

Quando o Availability Group é configurado, possuímos dois modos de comportamento, são eles:

Automatic Failover (Failover Automático)

A Replica usa o modo de sincronização sincróna e assim suporta com que o failover possa ser manual ou automático.

Manual Failover (Failover Manual)

A replica utiliza tanto o modo de sincronização síncrona como assíncrona e assim possui o direito de realizar somente um Failover Manual entre os parceiros.

 

Modos de Conexão no Secondário

O modo de conexão para cada servidor secondário pode ser:

• Dissalow Connections (Não Permitir Conexões) – As réplicas secondárias não permitem que seja realizada nenhuma conexão.

• Allow Only Read-Intent Connections – A réplica permite somente a leitura de conexões que tem a intenção de ler e passam pelo native client do SQL Server.

• Allow all Connections – É permitido qualquer conexão.

 

Availability Group Listener

Esse grupo possibilita uma forma de conexão dos bancos de dados com o Availability Group via uma Virtual Network (Rede Virtual). Quando o Availability Group falha então esse grupo redireciona todas as conexões para o novo servidor que passará a será o primário.