Servidores - SQL Server always on

Luan Moreno

Janeiro 2014

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:

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

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.

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

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

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.

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

Passo 2 – Compartilhando Pasta para Backup

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

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

(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

(Figura 14.1 – Validando o WFC.)

(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

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

    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

    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

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.

(Figura 15 – Habilitando o AlwaysOn Availability Group.)

(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 terem sido efetuados 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.)

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

(Figura 30 – Adicionando um Listener.) Insert Caption

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

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

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.

(Passo 1)

(Passo 2)

(Passo 3)

(Passo 4)

(Passo 5)

(Passo 6)

(Passo 7)

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

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

| Home | Artigos Técnicos | Comunidade