DRBD

Agora, mesmo um sistema com múltiplas interfaces de rede e um sistema de RAID, não está isento a falhar. Algum outro componente da máquina, por exmplo o processador, pode cair, ou meramente o sistema pode travar. Neste caso, temos todos os dados intactos e conexões válidas com a rede, mas é a máquina como um todo que não responde.

A solução evidente é ter uma máquina de reserva para esta situação, mas o que fazer com os dados que ficaram presos no servidor que caiu? A esta altura do texto não vou me dar ao trabalho de sugerir a realocação do disco rigido ou RAID para a outra máquina. O que queremos é uma solução automática.

Existe uma resposta para esta situação em hardware. São os RAID's ou discos rígidos com multiplas conexões. Alguns dispositivos SCSI podem ser conectados a duas máquinas simultaneamente, e há dispositivos com comunicação via Fibre Channel que podem ser conectados a mais de duas.

No entanto o sistema de arquivos só pode ser montado em uma máquina por vez, caso contrário ele acabará por ser corrompido, já que cada sistema guarda em memória um mapeamento do sistema de arquivos que não leva em conta as mudanças efetuadas pelos outros sistemas conectados.

Desta maneira, quando um sistema cai, todos os dados estão disponíveis na extremidade do cabo, sem necessidade de realocação de hardware, basta montar o sistema de arquivos.

Uma alternativa mais barata a esta configuração é manter um ou mais discos em cada máquina que espelham os dados entre os nós do cluster. Para gerenciar isto há um daemon chamado DRBD (Duplicated Redundant Block Device). O DRBD é um módulo que deve ser carregado no kernel e atua em uma camada entre o sistema de arquivos e o driver de disco.

Sua função é interceptar todos os dados transmitidos pelo sistema de arquivos, copiá-los no disco e enviar uma cópia pela rede para o outro nó. Esta transmissão é feita no nível de blocos, portanto é independente do sistema de arquivos. Isto também quer dizer que o sistema de arquivos não pode estar montado em ambos os nós simultaneamente, pois dados seriam colocados no disco, pelo DRBD, sem seu conhecimento, causando desatualização do estado do disco e corrompimento dos dados, conforme ilustrado na figura .

Figura: Failover de DRBD

[width=]img/drbd-failover.eps

O uso do DRBD é portanto bem similar ao de discos com múltiplas conexões, porém tem uma desvantagem. Enquanto ambos os nós estão funcionais, os dados são transmitidos quase instantaneamente, preferencialmente por uma interface dedicada, mas na hora em que o nó primário falha e o secundário assume, o primário, por estar offline, perde a capacidade de sincronização e ao retornar, precisará fazer uma ressincronização completa, o que pode levar diversas horas, conforme o tamanho do disco, demorando sua recuperação e aumentando o tempo de failover⁴.

Notemos também que a sincronização é feita em nível de blocos e, portanto o espaço vazio será sincronizado também. Logo o tempo de sincronização completa de um disco vazio ou cheio não difere.

A vantagem, evidentemente, está no preço do sistema que pode ser montado em cima de hardware comum, em contraposição aos elevados preços de hardware com múltiplas conexões.

Para maior segurança dos dados o DRBD permite uma sincronização completa em uma terceira máquina, mas não permite e uma sincronização em tempo real entre mais de duas máquinas. Segundo os autores do programa esta característica não deve vir a ser implementada devido à complexidade do problema. Contudo, uma terceira máquina mantendo os dados é uma segurança a mais.