DRBD

Origem: Wikipédia, a enciclopédia livre.

Nível conceptual do DRBD: Trata-se de um driver intermediário entre o block device virtual (/dev/nb*), o block device real local (/dev/hd*) e os block device's remotos. Todas as transferências são efectuadas pelo protocolo TCP/IP, o que permite uma vasta implementação, inclusivé em máquinas geograficamente afastadas.

DBRD é a acrónimo para o nome inglês Distributed Replicated Block Device. O DRBD consiste num módulo para o kernel de Linux, juntamente com alguns scripts, que oferecem um dispositivo de bloco projectado para disponibilizar dispositivos de armazenamento distribuídos, geralmente utilizado em clusters de alta disponibilidade. Isto é feito espelhando conjuntos de blocos via rede (dedicada). O DRBD funciona, portanto, como um sistema RAID baseado em rede.

[editar] Como trabalha

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 nodo 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 nodos, 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 nodo 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 nodo que falhou retornar, o DRBD, mediante as configurações, devolverá - ou não - o estatuto de primário ao nodo original, após uma sincronização. Em caso negativo, o chamado modo legacy, o nodo 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 nodos 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.

[editar] Características

Fluxo de intercomunicação entre as camadas dos dispositivos Linux: repare-se que o DRBD não tem como notificar o módulo do sistema de ficheiros - mas o oposto ocorre.

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)[KROVICH], e será designado como DRBD/Primary. O(s) restante(s) nó(s) será/serão designado(s) 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.

...

[editar] Situação do projecto

A maioria dos atuais clusters HA (HP,Compaq,...) usam dispositivos de armazenamento compartilhados; estes dispositivos, altamente dispendiosos, permitem ser conectados a mais de um nodo, geralmente através do barramento SCSI compartilhado ou Fibre Channel.

O DRBD usa a mesma semântica de um dispositivo compartilhado, mas não necessita de nenhum hardware específico. Ele trabalha no topo 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 nodo 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 lista de espera. As aplicabilidades seriam múltiplas, como para contextos de larga escala, onde operam sistemas de ficheiros como o GFS, por exemplo.