Alta Disponibilidade do Evolux (High Availability)

Este documento tem como objetivo explicar o funcionamento do sistema de Alta Disponibilidade (High Availability ou HA) dentro da solução Evolux.

Definição

Um sistema em alta disponibilidade é aquele que utiliza mecanismos de detecção e recuperação de falhas, de forma a manter a solução operacional pelo maior tempo possível.

Manter a solução operacional se refere a capacidade de se manter disponível para o usuário. Caso o usuário não tenha acesso a toda ou parte fundamental da solução, é considerado que está indisponível, sendo o tempo total de indisponibilidade conhecido também pelo termo downtime.

Para entendermos a disponibilidade de uma solução, aplicamos o cálculo:

DISPONIBILIDADE = (Período de tempo - downtime) / Período de tempo (x100) 

Exemplo

Se a disponibilidade da solução é calculada pelo período de 1 ano ou seja, 8.760 horas, e considerando 50 horas de indisponibilidade, faremos o seguinte cálculo:

DISPONIBILIDADE = (8.760 horas - 50 horas*) / 8.760 
DISPONIBILIDADE = 8.710 / 8.760 
DISPONIBILIDADE = 0,9943
DISPONIBILIDADE = 0,9943 x 100 = 99,43% (convertido em porcentagem)

*OBSERVAÇÃO: Se houveram diversas falhas no período, basta somar as falhas 
para se chegar ao tempo total da indisponibilidade (downtime).

O SLA (Service Level Agreement) ou ANS (Acordo de Nível de Serviço) de disponibilidade consiste no acordo de nível de serviço entre a empresa que pretende fornecer a solução e o cliente, em relação ao tempo em que a solução pode ficar indisponível no ambiente, dentro do período acordado. 

O SLA padrão aplicado nos contratos da Evolux é de 99,5% ao ano, excetuando manutenções programadas, problemas na infraestrutura do cliente, ou motivos de força maior, como incêndios, enchentes, furto de equipamentos, dentre outros. 

Redundância

A redundância de estrutura é um dos requisitos para se conseguir alta disponibilidade. Para isso é necessário o uso de ferramentas e sistemas que possam realizar a detecção e recuperação das falhas.

A Evolux usa o DBRD e o Heartbeat.

DRBD (Distributed Replicated Block Device) 

É um módulo do Linux que faz a replicação dos dados (partições de disco) entre servidores interligados através de conexão ethernet.

Cada disco do DRBD é configurado como Primário ou Secundário. Todo dado escrito no disco primário é replicado para o secundário.

O DRBD garante o sincronismo e a integridade dos dados replicados.

Referência: 

https://docs.linbit.com/
https://en.wikipedia.org/wiki/Distributed_Replicated_Block_Device

Heartbeat

O Heartbeat é considerado a peça chave do ambiente de alta disponibilidade pois tem a função de monitorar os servidores em produção e, em caso de falhas, realizar automaticamente os procedimentos para preservar o uptime da solução.

Através da conexão Ethernet, um servidor redundante verifica se o servidor primário está disponível enviando uma mensagem e esperando uma resposta. Se por algum motivo o servidor primário não responder ele será considerado indisponível, então o Heartbeat do servidor secundário realiza o "takeover" e assume os serviços da aplicação além do endereço IP e as partições de disco.

O Evolux utiliza esses dois serviços para o ambiente de alta disponibilidade. Tudo que é gravado no servidor primário é replicado para o secundário via DRBD.

O Heartbeat mantém o monitoramento entre os servidores e em caso de indisponibilidade do primário, o secundário monta as partições e inicia os serviços do Evolux.

Cenários Possíveis 

Servidor primário sem conectividade na rede interna

Usuários na rede interna e externa (se houverem) ficarão sem acesso ao Evolux, mas o servidor secundário não assumirá o controle.

Como a conexão ponto a ponto entre os servidores continua ativa, o servidor secundário continuará recebendo as respostas Heartbeat do servidor primário.

Servidor secundário sem conectividade na rede interna

Usuários na rede interna e externa (se houverem) continuarão com acesso ao Evolux  e o servidor secundário não assumirá o controle. 

Como a conexão ponto a ponto entre os servidores continua ativa, o servidor secundário continuará recebendo as respostas Heartbeat do servidor primário.
             

Solução sem acesso a Internet

Usuários na rede interna continuarão com acesso ao Evolux e usuários na rede externa (se houverem) ficarão sem acesso,  mas o servidor secundário não assumirá o controle.

Como a conexão ponto a ponto entre os servidores continua ativa, o servidor secundário continuará recebendo as respostas Heartbeat do servidor primário.

Servidor primário sem energia elétrica

Usuários na rede interna e externa (se houverem) ficarão sem acesso momentaneamente, o servidor secundário não receberá as respostas Heartbeat e interpretará que o servidor primário esta indisponível. Assumirá primeiramente o IP, depois montará as partições com os diretórios do Evolux e em seguida iniciará todos os serviços do Evolux. Em aproximadamente 5 minutos a aplicação estará novamente disponível e todos os usuários terão novamente acesso a solução.  

Os dois servidores (primário e secundário) sem energia elétrica

Todos os usuários ficarão sem acesso ao Evolux. Quando a energia retornar e os dois servidores iniciarem, o servidor primário assumirá primeiramente o IP, depois montará as partições com os diretórios do Evolux e em seguida iniciará os serviços do Evolux. Em aproximadamente 5 minutos a aplicação estará novamente disponível e todos os usuários terão novamente acesso a solução.  
                       

Retirada do cabo ponto a ponto entre os servidores primário e secundário

O servidor secundário não receberá as respostas do primário então interpretará que ele está indisponível. O servidor secundário assumirá o IP, depois montará as partições com os diretórios do Evolux e em seguida iniciará todos os serviços do Evolux. No entanto, o servidor primário estará disponível para acesso aos usuários e ambos acreditarão que são primárias, comportamento conhecido como split brain.

Isso acarretará resultados indesejáveis como algumas chamadas indo para um servidor e outras chamadas indo para o outro servidor, pois ambos estarão com o mesmo endereço IP na rede respondendo as requisições de acesso. Os dados não serão replicados e poderão ser corrompidos e/ou perdidos.

Para reparar esse estado é necessário realizar uma intervenção manual no servidor secundário, configurando-o novamente para ser secundário e reestabelecer o cabo ponto a ponto entre os servidores.