Introdução HA e DRAlwaysOn Availability GroupsConceitos e Terminologia Availability Replica RolesModos de Sincronização de Dados • Utilizando a forma síncrona = Synchronous-Commit Mode• Utilizando a forma assíncrona = Assynchronous-Commit ModeModos de Failover nos Availability Groups • Automatic Failover (Failover Automático)• Manual Failover (Failover Manual)Modos de Conexão no Secondário • Dissalow Connections (Não Permitir Conexões)• Allow Only Read-Intent Connections• Allow all ConnectionsAvailability Group Listener***** Pré-Requisitos Passo 1 – Configuração de uma Virtual Network (Rede Virtual)Passo 2 – Compartilhando Pasta para BackupPasso 3 – Instalação, Validando e Criando o Failover Cluster em cada Instância Instalando…..Validando…..Criando…..Passo 4 – Preparando o AmbientePasso 5 – Habilitando o ServiçoPasso 6 – Criando o AlwaysOn Availability GroupPasso 7 – Criando o Group ListenerPasso 8 – Adicionando uma Réplica para o GrupoConclusãoAjuda
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.
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:
(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.
(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.
(Figura 3 – Modo Assíncrono do espelhamento de dados ente servidores em lugares geograficamente diferentes.)
(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.
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.
(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.)
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.
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.
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.
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.
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.
Quando o Availability Group é configurado, possuímos dois modos de comportamento, são eles:
A Replica usa o modo de sincronização sincróna e assim suporta com que o failover possa ser manual ou automático.
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.
O modo de conexão para cada servidor secondário pode ser:
As réplicas secondárias não permitem que seja realizada nenhuma conexão.
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.
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.
Para a criação do AlwaysOn, necessitamos de:
• Windows Server 2008 R2 com Hyper-V Instalado.
• 1 Máquina Domain Controller Windows Server 2008 R2 – DC com IP estático, com DNS e Dóminio criado.
• 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.
No Hyper –V manager clique em Virtual Network Manager, logo após isso crie uma nova Rede Virtual com a opção interna
(Figura 6 – Criando a Rede Virtual para acesso das Vm’s criadas no Hyper – V.)
Agora, para cada VM criada informe a rede interna.
(Figura 7 – Especificando a rede criada para cada Vm.)
Abra a primeira Vm que foi instalada o SQL Server, crie e compartilhe uma pasta.
(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.
(Figura 9 – Permitindo acesso aos usuários do AD.)
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.
• 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
(Figura 10 – Selecionando a feature Failover Cluster Manager.)
* Realize a validação em somente uma máquina
• 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
(Figura 14.1 – Validando o WFC.)
(Figura 14.2 – Validando o WFC.)
• 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
(Figura 14 – Criado e configurado o WFC.)
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
ALTER DATABASE Marketing SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE Marketing;
IF DB_ID(‘Produtos’) IS NOT NULL
ALTER DATABASE Produtos SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE Produtos;
CREATE DATABASE Empresas;
ALTER DATABASE Empresas SET RECOVERY FULL;
CREATE DATABASE Marketing;
ALTER DATABASE Marketing SET RECOVERY FULL;
CREATE DATABASE Produtos;
ALTER DATABASE Produtos SET RECOVERY FULL;
go
USE Empresas;
IF OBJECT_ID(‘Dados’) IS NOT NULL
DROP TABLE Dados;
CREATE TABLE Dados
(RowID INT IDENTITY PRIMARY KEY,
Col1 INT,
Col2 CHAR(10) DEFAULT(‘ABC123′),
Col3 NCHAR(20) DEFAULT(’789XYZ’));
DECLARE @StartTime DATETIME = CURRENT_TIMESTAMP;
DECLARE @Loop INT = 1;
BEGIN TRANSACTION
WHILE @Loop <= 100000
INSERT INTO Dados (Col1) VALUES (@loop);
SET @Loop = @Loop + 1;
COMMIT TRANSACTION
SELECT DATEDIFF(ms, @StartTime, CURRENT_TIMESTAMP) AS Table1_Time;
UPDATE Dados
SET Col1 = RowID;
USE master
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’;
2 ª Máquina do SQL Server
3ª Máquina do SQL Server
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.
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.
(Figura 15 – Habilitando o AlwaysOn Availability Group.)
(Figura 16 – Reinicie todas as instâncias.)
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
(Figura 17 – Iniciando a instalação e configuração no wizard.)
(Figura 18 – Introdução para a criação do processo.)
(Figura 19 – Nome do Grupo.)
(Figura 20 – Selecionando as bases de dados.)
As validações acima são referentes..
(Figura 21 – Validações das bases de dados para o grupo.)
(Figura 22 – Informando a réplica secundária.)
(Figura 23 – Verificando o Endpoint.)
(Figura 24 – Preferência durante a execução de um backup assim como sua prioridade .)
(Figura 25 – Configuração do Listerner para o Grupo, nesse caso não iremos configurá-lo neste instante.)
(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.)
(Figura 27 – Validação de todas as configurações realizadas, o Warning gerado é porque não realizamos a configuração do listener ainda.)
(Figura 28 – Conclusão da instalação do grupo.)
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
(Figura 30 – Adicionando um Listener.)
(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
(Figura 32 – Acessando e visualizando informações do listerner no WFC.)
Sendo assim podemos acessá-lo assim no SSMS…
(Figura 33.1 – Acessando o listener.)
(Figura 33.2 – Conectado ao listener.)
Com isso temos nosso ambiente assim…
(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.
(Figura 35.1 – Movendo para o 2ª SQL Server parte 1.)
(Figura 35.2 – Movendo para o 2ª SQL Server parte 2.)
(Figura 35.3 – Movendo para o 2ª SQL Server parte 3.)
(Figura 36 – 2ª Servidor SQL Server agora é o primário.)
Se desejar realizar o Failover pelo SSMS…..
(Passo 1)
(Passo 2)
(Passo 3)
(Passo 4)
(Passo 5)
(Passo 6)
(Figura 37 – Failover concluído com sucesso.)
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
(Passo 7)
Depois da segunda réplica adicionada teremos o SSMS da seguinte forma…..
(Figura 38 – Availability Group pronto.)
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.
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/