Alta Disponibilidade

Um sistema de alta disponibilidade é um sistema informático resistente a falhas de software e energia, cujo objectivo é manter os serviços disponibilizados o máximo de tempo possível.

Cada vez mais é necessário garantir a disponibilidade de um serviço, mas sendo que muitos componentes dos sistemas de informação actuais contêm partes mecânicas, a fiabilidade destes é relativamente insuficiente se o serviço for crítico. Para garantir a ausência de interrupções de serviço é necessário, muitas vezes, dispor de hardware redundante que entre em funcionamento automaticamente aquando da falha de um dos componentes em utilização. Quanto mais redundância existir, menores serão os SPOF (Single Point Of Failure), e menor será a probabilidade de interrupções no serviço. Até há poucos anos tais sistemas eram muito dispendiosos, e tem-se vindo a intensificar uma procura em soluções alternativas. Surgem então os sistemas construídos com hardware acessível (clusters), altamente escaláveis e de custo mínimo.

Geralmente, quanto maior a disponibilidade, maior a redundância e custo das soluções dependendo do tipo de serviço que se pretende disponibilizar. Por exemplo, um operador de telecomunicações quererá certamente o mais elevado a fim de poder garantir um elevado nível de disponibilidade, sob pena de perder os seus clientes caso o sistema sofra falhas constantes. No entanto, uma empresa com horário de trabalho normal poderá considerar que 90% de disponibilidade serão suficientes. A tolerância a falhas consiste, basicamente, em ter hardware redundante que entra em funcionamento automaticamente após a detecção de falha do hardware principal. Independentemente da solução adoptada, existe sempre um tempo médio de recuperação (MTTR - Mean Time To Recover), que é o espaço de tempo (médio) que decorre entre a ocorrência da falha e a total recuperação do sistema ao seu estado operacional.

Heartbeat

O projecto Linux-HA (High-Availability Linux) incide na pesquisa e implementação de soluções de alta disponibilidade (clustering) para GNU/Linux, FreeBSD, OpenBSD, Solaris e Mac OS X. A principal componente deste projecto, em evolução, é o heartbeat que funciona como gestor do cluster e dos seus recursos. Como o nome indica, a sinalização da presença (ou ausência) de contacto com os nós do cluster faz-se mediante o envio de pequenos pacotes dirigidos a todos os nós do cluster, cuja confirmação de recepção por parte de cada nó indica o seu estado.

DRBD

O DRBD consiste num módulo para o kernel de Linux que, juntamente com alguns scripts, oferece um dispositivo de bloco projectado para disponibilizar dispositivos de armazenamento distribuídos, geralmente utilizado em clusters de alta disponibilidade. Isso é feito replicando conjunto de blocos via rede (dedicada). O DRBD funciona, portanto, como um sistema RAID baseado em rede.

Cada dispositivo envolvido (tratados localmente como partições) tem um estatuto, que pode ser primário ou secundário. O DRBD cria, em todos os nós, um vínculo entre um dispositivo virtual (/dev/nbX) e uma partição local, inacessível directamente. Toda a escrita é realizada no nó primário, que irá transferir os dados para o "dispositivo de bloco do nível mais baixo" (a partição) e propagá-los para os restantes nós, de estatuto "secundário". O secundário simplesmente transfere os dados no "dispositivo de bloco do nível mais baixo". As leituras são sempre realizadas localmente. Se o nó primário falhar, o DRBD permutará o dispositivo secundário para primário e as transferências passarão a ocorrer no sentido oposto. Note-se que o DRBD não trabalha ao nível do sistema de ficheiros, mas sim ao nível de blocos do disco rígido. Em sistemas de ficheiros que não disponibilizam journaling, deverá seguir-se à transição primário-secundário uma verificação da consistência do sistema de ficheiros; em Linux, significa correr o fsck. Se o nó que falhou retornar, o DRBD, mediante as configurações, devolverá – ou não – o estatuto de primário ao nó original, após uma sincronização. Em caso negativo, o chamado modo legacy, o nó que detém o estatuto de primário irá conservá-lo até o serviço ser encerrado nessa máquina. Apesar do DRBD possuir o seu próprio modo de determinar qual dos nós deverá ser primário, a sincronização com o sistema genérico não é trivial. Para reduzir estas dificuldades, é frequente utilizar-se um gestor de cluster, como o heartbeat, para tratar das transições de estatuto. Aliada a essa transição - e daí a dificuldade em coordenar ambos sistemas - o gestor de cluster deverá montar o sistema de ficheiros na nova máquina que captou o estatuto de primário.

Note-se, no entanto, que: Se as partições não forem do mesmo tamanho, o dispositivo DRBD irá automaticamente assumir-se como sendo do tamanho mínimo entre as partições envolvidas – o que permite alguma flexibilidade relativamente aos discos disponíveis em cada nó. Apenas um dos nós pode ter acesso de leitura e escrita (ReadWrite^?, R/W), e será designado como DRBD/Primary. Os restantes nós serão designados como DRBD/Secondary. Embora o nó DRBD/Secondary possa montar o dispositivo (apenas) em modo ReadOnly^? (R/O), é praticamente inútil, dado que as actualizações ocorrem apenas num sentido (do Primary para o Secondary) e a camada que gere block device's não dispõe de nenhuma forma de notificar alterações na camada que gere o sistema de ficheiros embutido.

A maioria dos actuais clusters HA (HP,Compaq,...) usam dispositivos de armazenamento partilhados; estes dispositivos, altamente dispendiosos, permitem ser ligados a mais de um nó, geralmente através do barramento SCSI compartilhado ou Fibre Channel. O DRBD usa a mesma filosofia de um dispositivo partilhado, mas não necessita de hardware específico. Trabalha em cima de redes IP, que são de implementação generalizada e de baixo custo, comparativamente aos sistemas dedicados de armazenamento (como Storage Area Networks). Actualmente o DRBD garante acesso de leitura-escrita apenas num nó de cada vez, o que é suficiente para o fail-over típico de um cluster HA. A equipa mantém, no entanto, até à estabilização do módulo, essa funcionalidade em roadmap, estando já em fase de testes. As aplicações seriam múltiplas, em contextos de larga escala, onde operam sistemas de ficheiros como o GFS, por exemplo.