Compartilhar via


SQL Server AlwaysOn

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:

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb188.png?w=246&h=65

(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.

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb189.png?w=447&h=85

(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.

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb190.png?w=394&h=179

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

 

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb191.png?w=375&h=183

(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.

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb192.png?w=456&h=247

(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.

 

***** Pré-Requisitos

Para a criação do AlwaysOn, necessitamos de:

 **• **Windows Server 2008 R2 com Hyper-V Instalado.

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb193.png?w=443&h=107

 

**• **1 Máquina Domain Controller Windows Server 2008 R2 – DC com IP estático, com DNS e Dóminio criado.

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb194.png?w=224&h=246


***• ***3 Máquinas SQL Server 2012, com Windows Server 2008 R2, no domínio com framework 3.5 em cada uma sendo todas instância padrão de instalação do SQL Server.


http://luanmorenodba.files.wordpress.com/2012/06/image_thumb195.png?w=500&h=62

Passo 1 – Configuração de uma Virtual Network (Rede Virtual)


No Hyper –V manager clique em Virtual Network Manager,* ***logo após isso crie uma nova Rede Virtual com a opção interna

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb196.png?w=506&h=449

(Figura 6 – Criando a Rede Virtual para acesso das Vm’s criadas no Hyper – V.)

 

Agora, para cada VM criada informe a rede interna.

 

http://luanmorenodba.files.wordpress.com/2012/06/capture_thumb31.png?w=429&h=349

(Figura 7 – Especificando a rede criada para cada Vm.)

Passo 2 – Compartilhando Pasta para Backup


Abra a primeira Vm que foi instalada o SQL Server, crie e compartilhe uma pasta.

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb197.png?w=502&h=310

(Figura 8 – Pasta para compartilhamento.)

 

Botão Direito na pasta, Share this folder – Permissions e adicione o serviço criado do SQL Server no AD de nome* SQLService e Administrator*, todos contas do seu domínio criado.


http://luanmorenodba.files.wordpress.com/2012/06/78049f73-1901-4dfe-869a-e804645b81b9_thumb.png?w=204&h=246

(Figura 9 – Permitindo acesso aos usuários do AD.)

 

Passo 3 – Instalação, Validando e Criando o Failover Cluster em cada Instância

 

Depois das permissões concedidas, necessitamos criar a camada de alta disponibilidade em nível servidor. Se a feature ainda não está instalada realize a instalação da mesma.

 

Esses passos serão realizadas nas 3 máquinas contendo o SQL Server 2012.

 

Instalando…..

***• ***Conecte nas máquinas

***• ***Entre no Server Manager

***• *Dentro do Server Manager botão direito em Feature Node e clique em Add Features.

***• ***Selecione Failover Clustering e clique em next

***• ***Confirme a instação e clique no final em Installation Results


http://luanmorenodba.files.wordpress.com/2012/06/image_thumb198.png?w=589&h=175

(Figura 10 – Selecionando a feature Failover Cluster Manager.)

 

* Realize a validação em somente uma máquina

 

Validando…..

***• ***Conecte na0 máquina

***• ***Expanda *Features *e clique em Failover Cluster Manager

  Em *Management *clique em Validation

***• ***Selecione todas as máquinas de SQL Server

***• ***Clique em Check Names

***• ***Realize todos os testes , confirme as opções selecionadas e depois veja o sumário de configuração

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb199.png?w=445&h=291

(Figura 14.1 – Validando o WFC.)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb200.png?w=371&h=224

(Figura 14.2 – Validando o WFC.)

 

 

Criando…..

***• ***No *Failover Cluster Manager clique em Create a Cluster ***

***• ***Selecione os servidores que formarão parte do cluster, neste caso todos que possuem SQL Server

***• ***Depois de selecionado, entre em *Access Point for Administering the cluster e crie um nome para seu cluster *

***• ***Informe um range no qual ele irá atuar na sua rede.

***• ***Depois finalize a tela e conclua a operação

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb201.png?w=494&h=371

(Figura 14 – Criado e configurado o WFC.)

 

Passo 4 – Preparando o Ambiente


Com nossa alta disponibilidade em nível servidor já disponível, agora podemos começar a preparar o ambiente para o AlwaysOn. Sendo assim, acesse a 1ª máquina do SQL Server, abra o SSMS 2012 – abra uma consulta e execute…

 

1ª  Máquina do SQL Server

 

IF DB_ID(‘Empresas’) IS  NOT NULL
BEGIN
    ALTER DATABASE  Empresas SET  SINGLE_USER WITH  ROLLBACK IMMEDIATE;
    DROP DATABASE  Empresas;
END
GO
  
IF DB_ID(‘Marketing’) IS  NOT NULL
BEGIN
    ALTER DATABASE  Marketing SET  SINGLE_USER WITH  ROLLBACK IMMEDIATE;
    DROP DATABASE  Marketing;
END
GO
  
IF DB_ID(‘Produtos’) IS  NOT NULL
BEGIN
    ALTER DATABASE  Produtos SET  SINGLE_USER WITH  ROLLBACK IMMEDIATE;
    DROP DATABASE  Produtos;
END
GO
  
CREATE DATABASE  Empresas;
GO
ALTER DATABASE  Empresas SET  RECOVERY FULL;
  
  
CREATE DATABASE  Marketing;
GO
ALTER DATABASE  Marketing SET  RECOVERY FULL;
  
  
CREATE DATABASE  Produtos;
GO
ALTER DATABASE  Produtos SET  RECOVERY FULL;
  
go
  
USE Empresas;
GO
IF OBJECT_ID(‘Dados’) IS  NOT NULL
BEGIN
    DROP TABLE  Dados;
END
GO
  
CREATE TABLE  Dados
    (RowID INT  IDENTITY PRIMARY  KEY,
     Col1 INT,
     Col2 CHAR(10) DEFAULT(‘ABC123′),
     Col3 NCHAR(20) DEFAULT(’789XYZ’));
GO
  
DECLARE @StartTime DATETIME = CURRENT_TIMESTAMP;
DECLARE @Loop INT = 1;
  
BEGIN TRANSACTION
WHILE @Loop <= 100000
BEGIN
    INSERT INTO  Dados (Col1) VALUES  (@loop);
    SET @Loop = @Loop + 1;
END
COMMIT TRANSACTION
SELECT DATEDIFF(ms, @StartTime, CURRENT_TIMESTAMP) AS  Table1_Time;
GO
  
UPDATE Dados
SET Col1 = RowID;
GO
  
USE master
GO
  
BACKUP DATABASE  Empresas TO  DISK = N’C:\InfoAlwaysOn\BackupAlwaysOn\Empresas.bak’;
BACKUP DATABASE  Marketing TO  DISK =N’C:\InfoAlwaysOn\BackupAlwaysOn\Marketing.bak’;
BACKUP DATABASE  Produtos TO  DISK = N’C:\InfoAlwaysOn\BackupAlwaysOn\Produtos.bak’;
GO
  
2 ª Máquina do SQL Server
 
IF DB_ID(‘Empresas’) IS  NOT NULL
BEGIN
ALTER DATABASE  Empresas SET  SINGLE_USER WITH  ROLLBACK IMMEDIATE;
DROP DATABASE  Empresas;
END
GO
IF DB_ID(‘Marketing’) IS  NOT NULL
BEGIN
ALTER DATABASE  Marketing SET  SINGLE_USER WITH  ROLLBACK IMMEDIATE;
DROP DATABASE  Marketing;
END
GO
IF DB_ID(‘Produtos’) IS  NOT NULL
BEGIN
ALTER DATABASE  Produtos SET  SINGLE_USER WITH  ROLLBACK IMMEDIATE;
DROP DATABASE  Produtos;
END
GO
3ª Máquina do SQL Server
IF DB_ID(‘Empresas’) IS  NOT NULL
BEGIN
ALTER DATABASE  Empresas SET  SINGLE_USER WITH  ROLLBACK IMMEDIATE;
DROP DATABASE  Empresas;
END
GO
IF DB_ID(‘Marketing’) IS  NOT NULL
BEGIN
ALTER DATABASE  Marketing SET  SINGLE_USER WITH  ROLLBACK IMMEDIATE;
DROP DATABASE  Marketing;
END
GO
IF DB_ID(‘Produtos’) IS  NOT NULL
BEGIN
ALTER DATABASE  Produtos SET  SINGLE_USER WITH  ROLLBACK IMMEDIATE;
DROP DATABASE  Produtos;
END
GO


Se preferir, download –https://skydrive.live.com/#cid=6E894476A77CD2F2&id=6E894476A77CD2F2%21142 nome = AlwaysOn – Instalação Bases e Backup.

 

Nesse script estamos realizando a criação dos bancos de dados, colocando todos como modo de recuperação FULL e depois realizando um backup full.

 

 

Passo 5 – Habilitando o Serviço



Para que possamos realizar a criação do High Availabiliy Group é necessário que realizemos a habilitação do serviço para todas as Vm’s SQL Server.

 

http://luanmorenodba.files.wordpress.com/2012/06/4ed8f888-8df9-4610-94b1-36d9388aa528_thumb.png?w=263&h=277

(Figura 15 – Habilitando o AlwaysOn Availability Group.)

 

http://luanmorenodba.files.wordpress.com/2012/06/b501f9a8-d811-4c5a-9ef1-531d07e1bb8d_thumb.png?w=353&h=113

(Figura 16 – Reinicie todas as instâncias.)

 

Passo 6 – Criando o AlwaysOn Availability Group


Depois do serviço habilitado, abriremos a 1ª Máquina SQL Server e realizaremos a criação do grupo.

 

Primeiramente verifique se o modo de recuperação de todas as bases estão como FULL.

Agora realize o backup de todas as bases de dados em qualquer local ou pasta.

 

Logo após o backup de todas ter sido efetuado clique em – AlwaysOn High Availability – New Availability Group Wizard

http://luanmorenodba.files.wordpress.com/2012/06/untitled_thumb9.png?w=335&h=173

(Figura 17 – Iniciando a instalação e configuração no wizard.)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb202.png?w=471&h=378

(Figura 18 – Introdução para a criação do processo.)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb203.png?w=476&h=360

(Figura 19 – Nome do Grupo.)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb204.png?w=484&h=358

(Figura 20 – Selecionando as bases de dados.)

 

As validações acima são referentes..

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb205.png?w=418&h=70

(Figura 21 – Validações das bases de dados para o grupo.)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb206.png?w=589&h=403

(Figura 22 – Informando a réplica secundária.)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb207.png?w=569&h=442

(Figura 23 – Verificando o Endpoint.)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb208.png?w=574&h=448

(Figura 24 – Preferência durante a execução de um backup assim como sua prioridade .)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb209.png?w=517&h=369

(Figura 25 – Configuração do Listerner para o Grupo, nesse caso não iremos configurá-lo neste instante.)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb210.png?w=488&h=411

(Figura 26 – Local compartilhado que criamos no começo da apresentação, ele servirá para que todos os banco de dados realizem backup neste repositório e assim seja restaurado dentro do grupo.)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb211.png?w=471&h=403

(Figura 27 – Validação de todas as configurações realizadas, o Warning gerado é porque não realizamos a configuração do listener ainda.)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb212.png?w=516&h=429

(Figura 28 – Conclusão da instalação do grupo.)

 

Passo 7 – Criando o Group Listener


Nesse momento iremos realizar a criação de um Listerner para o grupo, ele terá como função realizar um failover automático caso a réplica primária esteja offline.

 

Acesse a 1ª Máquina do SQL Server, Object Explorer – AlwaysOn High Availability – Availability Group – Availability Group Listerner

http://luanmorenodba.files.wordpress.com/2012/06/untitled_thumb10.png?w=312&h=273

(Figura 30 – Adicionando um Listener.)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb213.png?w=389&h=355

(Figura 31 – Nome, incluíndo a porta padrão 1433, porém iremos escolher um IP Estático para o mesmo, após isso conclua a operação. )

 

Com isso teremos um novo servidor que ficará escutando todas as transações entre os servidores do grupo, caso o primário esteja com problema, cabe ao listerner solucioná-lo e realizar o direcionamento para a nova réplica.)

 

Note que o listener aparece no WFC

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb214.png?w=366&h=231

(Figura 32 – Acessando e visualizando informações do listerner no WFC.)

 

Sendo assim podemos acessá-lo assim no SSMS…

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb215.png?w=312&h=227

(Figura 33.1 – Acessando o listener.)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb216.png?w=346&h=111

(Figura 33.2 – Conectado ao listener.)

 

Com isso temos nosso ambiente assim…

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb217.png?w=410&h=444

(Figura 34 – Ambiente configurado para o Availability Group, o servidor principal ou seja a réplica primária é o 1ª SQL Server.)

 

Agora que possuímos um Listener, iremos simular o failover. Para isso acesse o *Failover Cluster Manager – *clique em seu Cluster e – *Move this service or application to another node – *e então clique para mover para o 2ª Máquina do SQL Server.

 

 

http://luanmorenodba.files.wordpress.com/2012/06/untitled_thumb11.png?w=423&h=304

(Figura 35.1 – Movendo para o 2ª SQL Server parte 1.)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb218.png?w=246&h=155

(Figura 35.2 – Movendo para o 2ª SQL Server parte 2.)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb219.png?w=353&h=191

(Figura 35.3 – Movendo para o 2ª SQL Server parte 3.)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb220.png?w=426&h=475

(Figura 36 – 2ª Servidor SQL Server agora é o primário.)

 

Se desejar realizar o Failover pelo SSMS…..

http://luanmorenodba.files.wordpress.com/2012/06/untitled_thumb12.png?w=317&h=272

(Passo 1)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb221.png?w=462&h=306

(Passo 2)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb222.png?w=488&h=389

(Passo 3)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb223.png?w=486&h=366

(Passo 4)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb224.png?w=506&h=366

(Passo 5)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb225.png?w=508&h=356

(Passo 6)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb226.png?w=395&h=422

(Figura 37 – Failover concluído com sucesso.)

 

Passo 8 – Adicionando uma Réplica para o Grupo


Como realizamos a instalação de 3 Instâncias do SQL Server, agora iremos adicionar a 3ª para o grupo de alta disponibilidade.

 

Acesse a 1ª Máquina SQL Server – AlwaysOn High Availability – Availability Groups – Add Replica

http://luanmorenodba.files.wordpress.com/2012/06/untitled_thumb13.png?w=288&h=276

(Passo 1)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb227.png?w=358&h=324

(Passo 2)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb228.png?w=375&h=280

(Passo 3)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb229.png?w=381&h=287

(Passo 4)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb230.png?w=385&h=293

(Passo 5)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb231.png?w=396&h=290

(Passo 6)

 

http://luanmorenodba.files.wordpress.com/2012/06/image_thumb232.png?w=406&h=289

(Passo 7)

 

Depois da segunda réplica adicionada teremos o SSMS da seguinte forma…..

 

http://luanmorenodba.files.wordpress.com/2012/06/capture_thumb32.png?w=382&h=381

(Figura 38 – Availability Group pronto.)

 

 

Conclusão


Acreditamos que esse novo recurso que demorou bastante tempo para ser implementado pelo time de produto, solucione todos os casos e necessidades de HA e DR.

 

Espero que com esse recurso agora possamos reduzir o downtime e maximizar o tempo de um banco de dados em uptime, além de proteger os dados com maior segurança.

 

Vemos claramente que o SQL Server 2012 AlwaysOn provê total integração com os recursos de infra, sendo asim é claro que teremos uma ferramenta cada vez mais robusta.

 

Ajuda

http://www.simple-talk.com/sql/database-administration/sql-server-2012-alwayson/

http://www.brentozar.com/archive/2011/07/how-set-up-sql-server-denali-availability-groups/