ENTENDA UM POUCO – DRBD

DRBD significa Distributed Replicated Block Device, e ele serve exatamente para isso, fazer replicação de partições, também chamado as vezes de RAID de rede, é bastante usado em ambiente de cluster como por exemplo dois nodes replicando uma ou mais partições.

Segundo linbit, “a funcionalidade principal do DRBD é implementada por meio de um módulo do kernel Linux. Especificamente, o DRBD constitui um driver para um dispositivo de bloco virtual; portanto, o DRBD está situado próximo à parte inferior da pilha de I/O de um sistema”.

Basicamente o DRBD cria um dispositivo virtual que será conectados entre os nós do cluster como uma partição replicando os dados, esse dispositivo precisa ser formatado com um sistema de arquivo, isso depois de ser criado /dev/drbd0. O tipo desse sistema de arquivo pode ser qualquer um, porém, pode ser aconselhado algum especifico dependendo do modo do recurso. Saiba mais sobre recurso abaixo.

RECURSOS

No DRBD, recurso é o termo coletivo que se refere a todos os aspectos de um conjunto de dados replicados específico. Esses incluem:

Nome do recurso: qualquer nome arbitrário que não contenha espaço em branco ao qual o recurso é referido.

Volumes: qualquer recurso é um grupo de replicação que consiste em um ou mais volumes que compartilham um fluxo de replicação comum. Um volume contém o conjunto de dados replicados e um conjunto de metadados para uso interno do DRBD, são numerados começando com 0, e pode haver até 65.535 volumes em um recurso.

Dispositivo DRBD: dispositivo de bloco virtual gerenciado pelo DRBD, cada dispositivo DRBD corresponde a um volume em um recurso. O dispositivo de bloco associado geralmente é nomeado /dev/drbdX, onde X está o número menor do dispositivo, começando com 0. O DRBD também permite nomes de dispositivos de bloco definidos pelo usuário que, no entanto, devem começar com drbd_.

Você verá quando configurar o DRBD que os recursos geralmente ficam em arquivo com extensão .res. Nesses arquivos teremos informações como nome do dispositivos, nodes,

MODOS DOS RECURSOS

Modo primário único
No modo primário único, um recurso está, a qualquer momento, na função principal em apenas um membro do cluster. Como é garantido que apenas um nó do cluster manipula os dados a qualquer momento, esse modo pode ser usado com qualquer sistema de arquivos convencional (ext3, ext4, XFS etc.).

A implantação do DRBD no modo single-primary é a abordagem para clusters de alta disponibilidade (com capacidade de failover).

Duas coisas precisam ser esclarecidas nesse modo, que confunde muitas vezes:

• Primeiro: você não conseguirá montar a partição do DRBD nos dois nós simultaneamente, irá dar erro no secundário (os dados/informações na partição são sempre sincronizadas entre o nó primário e secundário mas o recurso fica disponível apenas para o primário). Para que consiga montar simultaneamente nos dois nós, eles precisam estar os dois como primário, e este é um outro modo chamado primário duplo explicado mais para frente. O que confunde é que o DRBD por padrão trabalha como modo primário único(ou seja um nó primário e outro secundário).
• Segundo: neste modo primário único caso você tenha montado a partição no primário e este nó fique indisponível a partição não irá aparecer montada “automágicamente” no secundário, para que isso acontece neste modo, você precisa usar uma ferramente a parte como por exemplo heartbeat.

Modo primário duplo
No modo primário duplo, um recurso fica sempre como primário para os nós do cluster. Como o acesso simultâneo aos dados é possível, esse modo requer o uso de um sistema de arquivos em cluster compartilhado que utilize um gerenciador de bloqueios distribuídos. Exemplos incluem GFS e OCFS2 .

A implantação do DRBD no modo duplo primário é a abordagem preferida para clusters de balanceamento de carga que exigem acesso simultâneo a dados de dois nós. Este modo está desativado por padrão e deve ser ativado explicitamente no arquivo de configuração do DRBD.

MODOS DE REPLICAÇÃO

O DRBD suporta três modos de replicação distintos, permitindo três graus de sincronicidade na replicação.

Protocolo A
Protocolo de replicação assíncrona. As operações de gravação local no nó principal são consideradas concluídas assim que a gravação no disco local é concluída e o pacote de replicação é colocado no buffer de envio TCP local. No caso de failover forçado, pode ocorrer perda de dados. Os dados no nó em espera são consistentes após o failover, no entanto, as atualizações mais recentes executadas antes da falha podem ser perdidas. O protocolo A é usado com mais frequência em cenários de replicação de longa distância. Quando usado em combinação com o DRBD Proxy, cria uma solução eficaz de recuperação de desastres.

Protocolo B
Protocolo de replicação síncrona (semi-síncrona) de memória. As operações de gravação local no nó primário são consideradas concluídas assim que a gravação no disco local ocorre e o pacote de replicação atinge o nó do mesmo nível. Normalmente, nenhuma gravação é perdida em caso de failover forçado. No entanto, no caso de falha de energia simultânea nos nós e destruição simultânea e irreversível do armazenamento de dados do primário, as gravações mais recentes concluídas no primário podem ser perdidas.

Protocolo C
Protocolo de replicação síncrona. As operações de gravação local no nó primário são consideradas concluídas somente após a confirmação da gravação local e remota no disco. Como resultado, a perda de um único nó é garantida para não levar a nenhuma perda de dados. A perda de dados é inevitável mesmo com esse protocolo de replicação se os dois nós (ou seus subsistemas de armazenamento) forem irreversivelmente destruídos ao mesmo tempo.

O protocolo de replicação mais comumente usado nas configurações de DRBD é o protocolo C.

A escolha do protocolo de replicação influencia dois fatores de sua implantação: proteção e latência . A taxa de transferência , por outro lado, é amplamente independente do protocolo de replicação selecionado.