Galera, como no momento estou envolvido coincidentemente em dois projetos de alta disponibilidade resolvi escrever alguns artigos sobre o assunto, aqui no Guia DBA mesmo você já encontra alguns artigos sobre o assunto, mas é sempre bom dar uma repaginada e acredito que estes novos artigos venham com muito mas detalhes.
Antes de iniciar os assuntos mas técnicos vou falar um pouco sobre os cenários no qual estou trabalhando, mercado e vantagens para quem hoje quer utilizar está feature que já se encontra em 3 versões do SQL Server.
Para iniciarmos o projeto de High Availability é necessário os recursos listados abaixo para garantir que o ambiente tenha Failover automático. Estes requisitos são necessários caso você utilize o SQL Server na versão 2012 ou superior.
- Redes:
- DHCP reservado
- DNS com AD
- Hardware:
- Switch reservado
- 2 Servidores (No minimo para Ativo – Passivo ou Ativo – Ativo)
- Storage
- 3 Placas de rede
- Recursos de configuração:
- Windows Server Failover Cluster
- DFS NameSpace
- Active Directory
- DNS
- DHCP
- ISCSII Target Microsoft
- Microsoft SQL Server versão 2012 ou superior
Entendendo o Funcionamento do Cluster de Failover do Windows server
Introdução ao AlwaysOn
O AlwaysOn foi inserido na versão do SQL Server 2012 e hoje está presente nas versões do SQL Server 2014 e SQL Server 2016 e é um dos pontos fortes da Microsoft quando se fala em alta disponibilidade.
Logo de início a Microsoft já veio com duas soluções o Availability Group que se resume em grupos de bancos de dados, onde você pode escolher alguns ou todos os bancos de dados que vão participar do AlwaysOn e o Cluster Instance que falando rápido sobre ele é nada mais nada menos que você realizar Failover de toda a sua instancia, ou seja, tudo que compor sua instancia estará dentro do cluster.
Anterior ao Alwayson tínhamos a replicação (não é mais relacionado como alta disponibilidade), Log Shipping (Presente desde a versão do SQL Server 2000 como alta disponibilidade) e Database Mirror (Adicionado no SQL Server 2008 e permite Failover automático).
No lançamento do SQL Server 2012 tivemos esta grande mudança de cenário onde passamos a poder trabalhar não com 2 servidores réplicas, mas agora com 4 servidores, Failover automático, WSFC (Windows Failover Cluster), Adicionar grupos de banco de dados (Availability Group) ou instancia (AlwaysOn Failover Cluster Instance).
Já no lançamento do SQL Server 2014 já tivemos algumas modificações como o dobro de número de réplicas o que garantia ainda mais sua alta disponibilidade conforme mostrado na imagem 1.
Imagem 1 – Downtime de alta disponibilidade
Como já sabíamos a algum tempo o recurso do Database Mirror iria ser retirado e desde o SQL Server 2012 com o lançamento do AlwaysOn está afirmação ficou ainda mais forte devido ao recursos utilizados e o alto nível de alta disponibilidade, ainda é possível utilizar o Database Mirror no SQL Server 2016 mas prepare-se para sua retirada.Outro detalhe importante é que para utilizar o AlwaysOn você tem a necessidade da versão Enterprise do SQL Server e o Database Mirror você ainda conseguia criar com a versão Standard.
Arquitetura
O AlwaysOn até a versão do SQL Server 2014 só poderia ser criado em ambientes que tenham Windows Server Failover Cluster configurado e para isso tínhamos que aplicar algumas regras tanto de configuração dos servidores quando de DR para diminuir problemas.Se você utiliza as versões do SQL Server 2012 ou 2014 e deseja implantar o AlwaysOn você deve considerar as necessidades abaixo:
- Windows Server Failover Cluster (WSFC)
- Storage
- Domínio
- Switch separado para a comunicação
- Configuração de QORUM (Testemunha)
Nesta relação encontra-se somente o que deve ser realizado antes mesmo de iniciar a configuração do SQL Server ou a instalação que pode ser Stand Alone ou com Failover.Em sua arquitetura o Availability Group realiza a mesma operação que o Database Mirror que é a transmissão de Log Record para as réplicas sendo de forma síncrona ou assíncrona.
Synchronous (Síncrona) – Neste cenário todas as operações que ocorrerem no Server ativo terá que ser confirmadas também no servidor(es) passivos em tempo real minimizando a perda de informações.
Assynchronous (Assíncrono) – Neste cenário as operações que ocorrem no Server ativo serão enviadas para o(s) Server(s) passivos mas não em tempo real o que pode ocasionar uma pequena perda de informações.
Para trabalhar com Failover automático é necessário que você tenha no mínimo uma das réplicas como síncrona, já na versão do SQL Server 2016 você pode ter até 3 réplicas em modo síncrono.Trabalhando já com o SQL Server 2016 você ainda pode ter a opção de criar um AlwaysOn que não esteja atrelado ao domínio, ou seja, você não precisa que as duas maquinas (Ativo – Passivo) compartilhem do mesmo domínio, existem ainda algumas desvantagens nesta configuração como não ter uma ferramenta de gerenciamento do Failover Cluster mas já está disponível.
Imagem 2 – AlwaysOn Availabity Group
Na imagem 2 podemos observar um ambiente de Availability Group montado em cima do mesmo domínio como informado acima.Como já informamos ao longo deste artigo o AlwaysOn seja Availability Group ou Failover Instance basicamente é o envio de Log Records em modo síncrono ou assíncrono como podemos ver na Imagem 3 analisar como é realizada está operação.
Imagem 3 – Arquitetura de envio de Log Records da instancia primaria para instancia secundaria.
Como podemos observar tudo começa com instruções confirmadas (Commit) no banco de dados gerando os Log Flush que não vou detalhar neste artigo e este Log Record é capturado e enviado para a instancia secundaria assim atualizando a instancia secundaria com as mesmas informações da instancia primaria.Como já informamos o modo síncrono realiza está operação em tempo real e o modo assíncrono não tem a necessidade de confirmar estás informações em tempo real.
Vantagens da utilização do Availability Group
Vou listar aqui algumas vantagens da utilização do HA em um ambiente de médio porte com recursos de HA e (Disaster Recovery) DR:
- Opção de trabalhar com dois servidores Ativo – Ativo minimizando recursos de I/O, CPU, Memória entre outros.
- Opção de direcionar backup para uma das réplicas ao invés de realizar em produção no server ativo
- Minimizar perda de dados. “Em caso de dois servidores no modo de Failover automático, trabalhando com mais de dois servidores pode-se trabalhar com uma réplica com Failover automático e as demais manual”
- Alta disponibilidade quando se tem um cenário mínimo para utilização do recurso conforme mostrado na imagem 1.
Esta solução veio para trazer o mais alto nível de alta disponibilidade no momento em que não trabalha somente utilizando os recursos do SQL Server mas também com a segurança garantida pelo WSFC que garante Failover dos discos e de tudo que se encontra neles para isso ainda temos que configurar um disco QORUM (testemunha) que no caso de Failover automático não pode ser configurado na instancia ativa e sim na passiva, garantindo que se o server ativo cair ainda teremos a configuração no server 2.Em cenários em que não trabalha com Failover automático podemos manter o QORUM no server ativo e o envio de Log Records de modo síncrono garantindo que o Server 2 estará atualizado.
