DRBD
DRBD é a acrónimo para o nome inglês Distributed Replicated Block Device. O DRBD consiste num módulo para o núcleo 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. Isto é feito espelhando conjuntos de blocos via rede (dedicada). O DRBD funciona, portanto, como um sistema RAID baseado em rede.
Como trabalha
[editar | editar código-fonte]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 modo 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.
Características
[editar | editar código-fonte]
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ó.
- Em versões anteriores a 8 em sistemas de arquivos que não suportam clusterização como por exemplo o EXT3, 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.
- Com a utilização do DRBD e um sistema de arquivos com suporte a cluster como por exemplo o OCFS2 da Oracle, pode-se ter os 2 nós montados em leitura e escrita.
...
Situação do projeto
[editar | editar código-fonte]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.
Ligações externas
[editar | editar código-fonte]
- «Site oficial» (em inglês)