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/