O conceito de Alta Disponibilidade (High Availability, ou simplesmente HA) não deve, e nem pode, ser uma novidade para os administradores de sistemas, principalmente em ambientes computacionais onde a disponibilidade é uma característica crítica. Esse conceito, que não é recente, está sendo amplamente disseminado, alcançando importância diretamente proporcional a influência que os sistemas de computação exercem nas empresas ou entidades que sustentam.

Quando nos referimos a alta disponibilidade nos sistemas Linux, estão na sombra desse relacionamento dois maduros softwares livres que permitem preencher alguns requisitos de sua implementação: o Heartbeat e o DRBD. Ambos os softwares são parte integrante do conhecido projeto Linux-HA, cujo propósito é reunir informações e casos de uso sobre os principais componentes relacionados à alta Disponibilidade no Linux.

Este artigo pretende então definir Alta Disponibilidade e citar os termos estabelecidos às tecnologias envolvidas, além de apresentar uma introdução, através de exemplos, sobre o funcionamento do Heartbeat e do DRBD. Porém, o artigo não se preocupa com os detalhes sobre a instalação e configuração desses softwares.

Alta Disponibilidade

Por definição, um sistema de alta disponibilidade é aquele que utiliza mecanismos de detecção, recuperação e mascaramento de falhas, visando manter o funcionamento dos serviços durante o máximo de tempo possível, inclusive no decurso de manutenções programadas.

Nesse contexto, disponibilidade refere-se a capacidade de um usuário de determinado sistema acessar, incluir ou modificar os dados existentes, assegurando a integridade de quaisquer alterações realizadas em qualquer intevalo de tempo. Caso, por qualquer que seja o motivo, um usuário não tenha acesso a todo ou parte fundamental desse sistema, é dito então que ele está indisponível, sendo o tempo total de indisponibilidade conhecido pelo termo downtime.

Apoiando-se em alguns cálculos básicos, é possível definir os níveis de disponibilidade de um sistema com base no seu downtime mensal e anual. Os resultados estão na tabela abaixo:

Disponibilidade (%)	Downtime/ano	Downtime/mês
95%	18 dias 6:00:00	1 dias 12:00:00
96%	14 dias 14:24:00	1 dias 4:48:00
97%	10 dias 22:48:00	0 dias 21:36:00
98%	7 dias 7:12:00	0 dias 14:24:00
99%	3 dias 15:36:00	0 dias 7:12:00
99,9%	0 dias 8:45:35.99	0 dias 0:43:11.99
99,99%	0 dias 0:52:33.60	0 dias 0:04:19.20
99,999%	0 dias 0:05:15.36	0 dias 0:00:25.92

Tabela de Níveis de Alta Disponibilidade

Para calcular a disponibilidade de um sistema, leva-se em consideração dois parâmetros: O tempo médio entre falhas - Mean Time Between Fail - (MTBF) e o tempo médio de recuperação - Mean Time To Repair - (MTTR), que é o espaço de tempo (médio) que decorre entre a ocorrência da falha e a total recuperação do sistema. Com o conhecimento desses parâmetros, é aplicada a fórmula:

Disponibilidade = MTTF / (MTTF + MTTR)

As soluções que se aproximam de 100% de disponibilidade exigem a redundância da estrutura para evitar a existência de pontos únicos de falha, conhecidos também pela sigla em inglês SPOF (Single Point Of Failure). Um ponto único de falha é simplesmente um recurso do sistema em que, caso falhe, provoca a indisponibilidade de todo o sistema. Óbvia e infelizmente, reduzir os pontos únicos de falha exige custos e adiciona um considerável grau de complexidade na infra-estrutura.

A redundância da estrutura é, portanto, um dos requisitos para se conseguir alta disponibilidade, e deve ser combinada com uma camada de software capaz de monitorar e assumir os serviços de um servidor em produção quando nele ocorrer uma falha. Exatamente essa camada de software é preenchida pelo Heartbeat e o DRBD.

Heartbeat

O Heartbeat pode ser considerado o núcleo do ambiente de alta disponibilidade, pois é sua a responsabilidade de monitorar os servidores em produção e, em caso de falha, realizar automaticamente os procedimentos para preservar o funcionamento do sistema como um todo.

Através de um meio de comunicação, que pode ser Ethernet ou Serial, um servidor redundante verifica a disponibilidade do servidor em produção enviando-lhe uma mensagem e exigindo a resposta. Essa checagem é feita entre as duas instâncias do Heartbeat instaladas nos dois servidores. Se por algum motivo o servidor em produção não responder, ele será considerado indisponível, e então o Heartbeat do servidor redundante automaticamente providencia a configuração e inicilialização dos serviços locais, além de outros recursos, como o endereço IP, partições de disco, etc.

Para dispensar mais explicações em torno do funcionamento do Heartbeat, será ilustrado um diagrama envolvendo dois servidores: webserver1 (produção) e webserver1-bkp (redundante). Ambos configurados com o Heartbeat para prover alta disponibilidade de um serviço Web (Apache):

No diagrama acima, o endereço IP 9.8.7.3 é um IP virtual gerenciado pelo Heartbeat. É justamente por esse IP que os clientes tem acesso ao serviço Web (Apache) do servidor em produção. Os endereços IPs 9.8.7.1 e 9.8.7.2 são fixos e usados apenas para permitir o gerenciamento remoto, independente de qual servidor estiver com o IP virtual configurado.

Ainda com base no diagrama, é possível narrar com minúcia os passos de funcionamento do Heartbeat:

• O Heartbeat do webserver1-bkp envia uma mensagem para o webserver1 através de uma conexão serial, usando um cabo serial cruzado que conecta os dois servidores.
• Caso o webserver1 não envie uma resposta, automaticamente o Heartbeat do webserver1-bkp inicia o serviço Apache e configura o IP 9.8.7.3, passando a funcionar como o servidor em produção.
• Quando o webserver1 estiver novamente disponível, o Heartbeat desse servidor envia um pacote alertando sobre sua disponibilidade para o webserver1-bkp, pela mesma comunicação serial.
• O webserver1-bkp então pára o serviço Apache e libera o IP 9.8.7.3, configurado anteriormente. Logo em seguida, ele envia uma mensagem para o webserver1, alertando-o sobre a possibilidade dele assumir novamente os serviços.
• O webserver1 inicia o Apache e configura novamente o IP 9.8.7.3, voltando assim a situação original.

Um ponto importante de observação é que o próprio Heartbeat controla a inicilialização de determinados serviços e recursos dos servidores, como o Apache e o endereço IP virtual. Logo, eles não devem ser configurados para inicializar durante o boot do sistema operacional, apenas no Heartbeat.

Assumindo o controle total dos serviços e recursos do ambiente de alta disponibilidade, o Heartbeat evita qualquer tipo de conflito que possa afetar o correto funcionamento do sistema. Entretanto, não é seu objetivo garantir a sincronia e a integridade dos dados entre os servidores. Para conseguir isso, o Heartbeat tem que agir em conjunto com algum software que se encarregue de manter os mesmos arquivos do servidor em produção também no servidor redundante. Essa será justamente a função do DRBD.

DRBD

O DRBD (Distributed Replicated Block Device) consiste em um módulo para o kernel Linux que faz o espelhamento dos dados de um dispositivo de bloco (partições de disco) entre diferentes servidores, interligados geralmente através de uma

DRBD e Heartbeatrede Ethernet. Para quem já é familiarizado com o conceito de RAID, o DRBD pode ser muito bem explicado como sendo um RAID-1 via rede.

Cada dispositivo de bloco envolvido na configuração do DRBD tem um estado, que pode ser primário ou secundário. Todas as operações de escrita feitas no primário são replicadas para o secundário, sendo que o protocolo padrão de replicação garante a sincronia e a integridade dos dados replicados. Quanto as operações de leitura, elas são sempre realizadas localmente.

Atualmente na versão 8.0, o DRBD suporta uma configuração com dois dispositivos primários (Dual-primary mode), permitindo, além da alta disponibilidade, o balanceamento de carga através da distribuição das operações de leitura e escrita. Esse modo de operação exige a utilização de um sistema de arquivos distribuído (GFS e OCFS2 são alguns exemplos), o que torna sua implementação um pouco complexa. Entretanto, a tradicional configuração primário/secundário é o suficiente para construir um ambiente de alta disponibilidade.

O Heartbeat fornece scripts para controlar partições DRBD de acordo com a disponibilidade dos servidores. Em um ambiente integrado, o servidor em produção faz a replicação dos arquivos para um servidor redundante através do DRBD. O servidor redundante, por sua vez, faz o monitoramento do servidor em produção usando o Heartbeat. Em caso de indisponibilidade, ele automaticamente monta o dispositivo DRBD para leitura e escrita e inicia os demais serviços, mantendo o sistema em perfeito funcionamento e com os arquivos atualizados. Nessa situação, o Heartbeat configura o dispositivo DRBD do servidor redundante para primário.

Quando o servidor em produção ficar novamente disponível, o Heartbeat desse servidor assume a responsabilidade de iniciar os serviços, sincronizar as partições DRBD e configurá-lo novamente como primário, fechando o ciclo.

E baseando-se nessas informações apresentadas sobre DRBD, o diagrama dos servidores web em um ambiente de alta disponibilidade - já mencionado anteriormente - pode ser complementado da seguinte forma:

Nesse novo diagrama, todos os arquivos dos Web Sites, armazenados debaixo de /var/www em webserver1, são replicados para o webserver1-bkp através do DRBD. A integração com o Heartbeat permite preservar as modificações nos arquivos desse diretório durante uma indisponibilidade do servidor em produção, tornando mais completo o ambiente de alta disponibilidade.

Considerações finais

Os pacotes pré-compilados do Heatbeat e DRBD estão disponíveis para várias distribuições Linux, como o Debian, Fedora, Red Hat (CentOS), Ubuntu e SuSE, portanto, a instalação deles é tipicamente descomplicada com o uso de ferramentas de gerenciamento de pacotes, como, por exemplo, o apt-get, yum e urpmi. Em relação aos procedimentos de configuração, é possível encontrar muita documentação espalhada na Internet para diversos casos de uso, além da ótima documentação presente nos próprios pacotes de instalação.

Em meio a algumas soluções proprietárias para construir um ambiente de alta disponibilidade, o Heartbeat e o DRBD conseguem juntos excelentes resultados para sistemas Linux, e sem absolutamente nenhum custo por se tratarem de softwares livres. A maturidade desses softwares atingiu um certo nível que venceu determinadas desconfianças presentes no rigoroso mercado corporativo.

Logicamente o Heartbeat não se submete ao que foi apresentado no artigo. Ele permite a integração com diversos outros recursos além do DRBD. É comum encontrá-lo também em soluções de alta disponibilidade para servidores NFS, ou integrado com o ldirectord (Linux Director Daemon), usado para fazer balanceamento de carga. A sua estrutura modular, combinada com a flexibilidade do Linux, limita o uso do Heartbeat exclusivamente a criatividade do administrador de sistemas.

Referências

Conectiva (17-11-2003). Guia do Servidor Conectiva Linux. Conectiva. Acessado em 29-01-2008.
Wikipédia (01-01-2008). Sistema de alta disponibilidade. Acessado em 30-01-2008.
Shaikh, Hidayatullah (12-10-2004). High-availability middleware on Linux. IBM DeveloperWorks. Acessado em 04-02-2008.