Grupo de disponibilidade do banco de dados, ou simplesmente DAG, foi um avanço implementado na versão 2010, tem como objetivo manter o Banco de dados com alta disponibilidade.

Alguns conceitos são importantes sabermos antes de prosseguirmos:

  1. Definições

Todos sabemos que, no universo Exchange, DAG significa “Grupo de Disponibilidade de Banco de Dados”.

Banco de dados – Não é o servidor, Ok? Já vi muita gente confundir o Banco de Dados com o Servidor de Mailbox! Quem fica em alta disponibilidade é o Banco de dados, é ele quem alterna entre os vários servidores que fazem parte de uma DAG em caso de “falha”

Grupo – A disponibilidade é o resultado da quantidade e do trabalho em grupo dos servidores de caixa de correio que fazem parte da DAG, esses servidores trabalham sempre em GRUPO.

Disponibilidade – É a palavra onisciente, pode-se dizer que em termos de Microsoft Exchange, do universo Exchange é uma palavra onipresente. Ela esta associada a todos os componentes dos servidores Mailbox no que diz respeito a alta disponibilidade, no entanto essa palavra mágica não é apenas o resultado de esforços técnicos, mas, é resultado de muita matemática por traz do que ela pode prover para os Servidores de Caixa de Correio.

  1. Arquitetura Preferencial recomendada pela Microsoft

Esse modelo é bem parecido com o modelo aplicado aos NameSpace, que você pode lêr sobre clicando aqui, cada database opera em um servidor de caixa de correio não associado e com cópias ativas nos demais servidores que compõem a DAG, são os membros da DAG, a imagem abaixo ilustra bem isso:

Neste exemplo temos 4 servidores de Caixa de Correio, cada servidor tem uma database ativa, são aquelas de AZUL, cada servidor possui copias das databases que estão ativas nos pares, são as databases CINZAS e para finalizar cada servidor possui copias de atraso, são as bases que estão de alaranjado.

Segue a sugestão da Microsoft:

  • Os datacenters sejam simétricos
  • Cada DAG tenha preferencialmente um número PAR (se for Impar, vai funcionar normalmente, o que muda e a métrica do quorum) de Servidores
  • O Servidor de testemunha é utilizado para manutenção do quórum.

Essa é a receita magica da PA, mas, o assunto não é apenas disponibilidade de banco estamos falando de “Disponibilidade” em um contexto muito mais amplo.

Ao projetar uma DAG tenha em mente que existem uma serie de fatores que podem, e vão, influenciar no projeto e na execução do projeto para servidores Exchange.

Alta Disponibilidade não é alta disponibilidade? Alhos não são bugalhos?

Bom, muita calma nesta hora! A maioria dos datacenters não estão trabalhando com alta disponibilidade o que temos são salas cofres abarrotadas de equipamentos de TI funcionando e seus subsistemas possuem alta disponibilidade todos na mesma sala! Ou seja, a alta disponibilidade esta na camada 7 do modelo OSI, mas o que sustenta a camada 7 lá na base trabalha praticamente sozinho (Se essa é a sua realidade, parabéns, é a minha em muitos lugares!)

A disponibilidade é um fator matemático, portanto, devemos levar em consideração todos os fatores que podem gerar indisponibilidade. No caso de uma DAG vários fatores podem levar a interrupção do serviço de correio e não apenas falha catastrófica nos servidores ou na própria DAG.

Disponibilidade nada mais é do que o tempo que um sistema está operável e em condições de funcionamento, ele estará disponível! Alta disponibilidade é a resiliência desse sistema frente a falhas que podem comprometer a disponibilidade.

Pensando Fora da caixinha…

Já deu para perceber que um projeto de DAG não diz respeito apenas aos servidores Exchange, mas, principalmente ao ambientem como um todo.

Continue até o fim que você vai entender!

Nível de Serviço acordado (SLA) X Mundo Real

A PA recomendada pela Microsoft pede mais servidores e mais bancos replicados nestes servidores, em caso de falha o banco pode estar disponível em outro servidor.

Isso tem um motivo que para mim é claro, indisponibilidade gera prejuízo de imagem e financeiro e não queremos isso.

É necessário que um projeto de DAG seja concebido pensando na probabilidade de o pior acontecer, falha geral de todos os componentes, se o pior acontecer é necessário que o tempo de recuperação seja inferior ao tempo previsto em contrato.

Esse cálculo pode ser feito por meio da teoria das probabilidades (TUDO ISSO POR CAUSA DE UMA DAG? Sim! Pense fora da caixinha!)

A teoria das probabilidades é um cálculo matemático para podermos saber a quantidade de tempo que um sistema pode ficar disponível, consequentemente a quantidade de tempo que esse sistema pode ficar indisponível.

A métrica utilizada é a seguinte:

Calcula-se a quantidade de tempo que o sistema está disponível (tempo de atividade) durante algum período, geralmente o SLA e anual, então, calcula-se o ano e divide-se pela duração total do período.

Tempo Médio entre Falhas (TMF)

Tempo Médio para Reparo (TMR) 

Logo, temos a seguinte equação:

A = TMF / (TMF+TMR)

Ou seja, disponibilidade é o resultado do tempo médio de falhas dividido pela soma dele mesmo com o tempo médio de reparo.

A indisponibilidade é o oposto disso, logo, pense em indisponibilidade no seguinte cálculo.

I = 1 – A = TMF / (TMF+TMR)

Quando se fala de DAG não devemos pensar apenas na disponibilidade é necessário ir além e passar a verificar questões como o SLA do contrato e identificar os fatores que podem afetar a disponibilidade do serviço, entender essas dependências torna a tarefa de projetar um serviço de DAG mais assertivo.

Desta maneira temos agora como entender a regra dos “nove” toda disponibilidade e geralmente gerida pela regra dos “nove” conforme tabela abaixo:

Nível de disponibilidadeValor da disponibilidadeProbabilidade de falhaTempo de inatividade aceito por ano
Dois noves99%1%5256 minutos = 3,65 dias
Três noves99.9%0.1%525,6 minutos = 8,76 horas
Quatro noves99.99%0.01%52,56 minutos
Cinco noves99.999%0.001%5,26 minutos

O Seu ambiente de correio suporta o contrato de serviço que o comercial da empresa assinou?

A DAG e as dependências que afetam sua disponibilidade

Agora que sabemos como calcular a disponibilidade podemos entender melhor como os outros serviços podem afetar a disponibilidade da DAG e desta forma afetar a disponibilidade do correio como um todo.

Vários serviços podem afetar a disponibilidade, não adianta sua DAG está configurada se vários serviços podem “Derruba-la” a qualquer hora, por exemplo:

  • Armazenamento do Banco de dados
  • Hardware que opera o armazenamento
  • Conectividade de rede
  • Host físico, etc

 Todos esses são componentes são críticos e a falha de qualquer um deles significaria perda de serviço, mesmo que o próprio banco de dados estivesse perfeitamente íntegro. 

Ao projetar a DAG pense no seguinte, o servidor Mailbox pode estar disponível como serviço, logo todas as dependências do servidor devem estar disponíveis também.

Para podermos determinar a quantidade de tempo que o servidor mailbox pode ficar indisponível devemos Identificar, catalogar e isolar todos os componentes que tornam o serviço dependente.

As dependências críticas para um determinada servidor Mailbox podem ser identificadas da seguinte forma:

D = Disponibilidade  

  • Disco de banco de dados / subsistema de armazenamento – digamos que sua disponibilidade seja D 1 ;
  • Servidor de caixa de correio (componentes de hardware e software) – diga que sua disponibilidade é D2 ;
  • Conectividade de rede entre clientes e o Servidor Mailbox D3 ;
  • Energia no datacenter onde os servidores e de armazenamento estão localizados – dizer a sua disponibilidade é D4 ;

Essa lista pode ter diversos outros componentes, Active Directory, DNS, Link de Dados, Firewall, etc…

Podemos acrescentar a maturidade dos processos, maturidade operacional, erro humano, operações mal sucedidas…etc… etc… tudo isso pode levar a tempo de inatividade ok?

Existe a independência individual de cada componente, de tal sorte que cada um deles pode afetar a disponibilidade do Servidor Mailbox ou seu Banco de dados, para ser mais claro, todos os componentes devem estar disponíveis para os clientes para que o servidor, a Dag ou o banco de dados também estejam disponíveis.

Por mais que a DAG esteja perfeita, aplicando a teoria das probabilidades a disponibilidade em si e uma combinação de eventos independentes, é um produto das probabilidades individuais de cada evento

D = D1 X D2 X D3 X D4

É importante salientar que, cada valor de disponibilidade individual não pode ser maio que 1 (100%) e a disponibilidade do serviço resultante é simplesmente um produto das disponibilidades individuais, ou seja, o valor da disponibilidade resultante não pode ser maior que o menor resultado das disponibilidades dos componentes

Isso pode ser ilustrado com o exemplo apresentado na tabela a seguir (os números aqui são exemplos, mas bem realistas):

Componente de dependência críticaProbabilidade de falhaValor da disponibilidade
Servidor de caixa de correio e armazenamento5%95%
Servidor de Acesso para Cliente1%99%
Rede0.5%99.5%
Energia0.1%99.9%
Serviço geral (depende de todos os componentes acima)6.51383%95% x 99% x 99,5% x 99,9% = 93,48617%

Neste exemplo hipotético você pode perceber como funciona as dependências! Mesmo um banco de dados que teoricamente está bem protegido, replicado, etc… sua taxa de disponibilidade permanece abaixo de 94%

Conclusão

Mesmo aplicando a arquitetura preferencial da Microsoft para alta disponibilidade não devemos jamais imaginar que estamos totalmente seguros, uma falha pode acontecer a qualquer momento.

Ao projetar uma DAG recomendo que antes de tudo esteja seguro do ambiente tecnológico do cliente, que saiba bem suas dependências e que domine de ponta a ponta cada detalhe das configurações necessárias.

Lembre-se que se o cliente possui muitas dependências de serviço a disponibilidade sempre será afetada para fins de cálculos.

Não siga manual às cegas, aprenda, desenvolva em você uma mente crítica afim de se aprofundar nos detalhes de tudo.

Fazer o que é novo, o que ninguém nunca fez e até fácil! Mas fazer melhor o que todo mundo faz o torna o especialista que está em falta hoje em dia.