No artigo anterior 001 conhecemos sobre o DRBD e falamos sobre sua atuação como primário e secundário.
Veja abaixo que os discos são espelhados via rede.
Não é recomendado conectar os dois nós(computadores) no switch juntamente com demais computadores da rede!
Conforme a imagem acima, use uma placa de rede dedicada para o DRBD em cada pc e conectado diretamente ao outro nó do DRBD da rede. Deixe outra porta de rede separada para se conectar no switch da sua lan local.
Usaremos a palavra cluster para referir ao grupo de servidores com DRBD instalado e atuando. Em nosso caso há um cluster com dois nós(peers) ou computadores apenas. Então, quando falarmos em cluster DRBD estaremos falando do grupo, do todo.
Tipos de Atuação do DRBD
Aqui descrevemos os tipos de papéis, atuação que o DRBD pode fazer. Algumas dessas atuações serão importantes para a maioria dos usuários, algumas serão relevantes apenas em cenários de implantação muito específicos.
DRBD em Modo primário único(Single-primary mode)
No modo primário único, um resource está, a qualquer momento, na função primária 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 e assim por diante).
DRBD em Modo primário Duplo(Dual-primary Mode)
No modo primário duplo, um recurso pode estar na função primária em dois nós por vez. Como o acesso simultâneo aos dados é possível, esse modo geralmente requer o uso de um sistema de arquivos de cluster compartilhado que usa um gerenciador de bloqueio distribuído. Exemplos incluem GFS e OCFS2.
A implantação do DRBD no modo primário duplo é a abordagem preferida para clusters de balanceamento de carga(load balance) que exigem acesso simultâneo a dados de dois nós, por exemplo, ambientes de virtualização com necessidade de migração ao vivo. Este modo é desativado por padrão e deve ser ativado editando o arquivo de configuração do DRBD.
Modo de Replicação do DRBD
O DRBD suporta três modos de replicação:
- Protocol A
- Protocol B
- Protocol C
Protocol vem de protocolo 🙂
É bom saber de antemão que o protocolo mais usado é o C. Vamos ver sobre cada um deles.
A escolha do protocolo de replicação influencia em 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.
Protocol A
Protocolo de replicação assíncrona. A replicação é chamada de assíncrona porque quando salvarmos alguma arquivo no disco local do servidor primário o DRBD dará como tido êxito, sucesso nessa operação. Ele não esperará o arquivo ser gravado no outro servidor(nó) da rede.
As operações de gravação local no nó primário são consideradas concluídas assim que a gravação do disco local for concluída e o pacote de replicação tiver sido colocado no buffer de envio TCP local. Em caso de failover forçado, pode ocorrer perda de dados. Os dados no nó de espera são consistentes após o failover; no entanto, as atualizações mais recentes executadas antes do failover 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, torna-se uma solução eficaz de recuperação de desastres.
Protocol 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 do disco local ocorrer e o pacote de replicação atingir o nó de mesmo nível. Normalmente, nenhuma gravação é perdida em caso de failover forçado. No entanto, em caso de falha de energia simultânea em ambos os 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.
Protocol 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(s) gravação(ões) do disco local e remoto. Como resultado, é garantido que a perda de um único nó não levará a nenhuma perda de dados. A perda de dados é, obviamente, inevitável mesmo com este protocolo de replicação se todos os nós (respectivos de seus subsistemas de armazenamento) forem irreversivelmente destruídos ao mesmo tempo.
De longe, o protocolo de replicação mais comumente usado em configurações de DRBD é o protocolo C.
Auto-Promote e “drbdadm primary”
Falamos no artigo anterior que,
Alterar a função do resource de secondary para primary é chamado de promotion(promoção), enquanto a operação inversa é chamada de demotion(rebaixamento).
categoriaoutros
Antes do DRBD 9, a promoção de um resource era feita com o comando drbdadm primary. Com o DRBD 9, o DRBD promoverá automaticamente um resource como primário quando a opção de auto-promote(promoção automática) estiver habilitada e um de seus volumes for montado ou aberto para gravação. Assim que todos os volumes forem desmontados ou fechados, a função do recurso volta a ser secundária.
O auto-promote só terá êxito se o estado do cluster permitir, ou seja, se um comando drbdadm primary digitado diretamente também for bem-sucedido. Caso contrário, a montagem ou abertura do dispositivo falha como era antes do DRBD 9.