DRBD: O que É e como Lidar com Split Brain Manualmente? – Parte 05

O que é Split Brain no DRBD?

Podemos traduzir split brain do inglês para o português como:

  • Split = dividir
  • brain =  cérebro

É um “cérebro dividido”.

Levando em consideração apnas 2 nodes/computadores no drbd,  split brain acontece quando esses dois nodes se desconectam da rede e ficam como primário(primary) ao mesmo tempo.

O split brain pode ser causado por:

  • Falha humana: é um pouco difícil de acontecer. Para isso alguém teria que configurar o computador X para primário sem ter percebido que o computador Y já é primário e perdeu a conexão via rede com X. Lembrando que enquanto houver conexão de rede entre os nodes o DRBD permitirá apenas um computador como primário. A não ser que “allow-two-primaries yes” seja definido e assim permitindo modo dual-primary.
  • programa gerenciador de cluster: Particularmente penso que um programa que gerencie cluster tenha muito mais probabilidade de criar um cenário de split brain de que um ser humano.

Levando ainda em consideração apenas 2 servidores/nodes fazendo parte do cluster drbd em um ambiente single-primary(onde apenas um node deveria ser primário), ao sofrer split brain cada um desses 2 servidores irá continuar recebendo dados, pois os dois agora estão como primary. Para resolver essa situação um dos servidores terá que perder dados, infelizmente.

 

Nosso Ambiente de Trabalho

Temos 2 servidores com as seguintes características

servidor 01

  • hostname/nome: server01
  • nome do Resource: meuRes

 

servidor 02

  • hostname/nome: server02
  • nome do Resource: meuRes

 

Executei “drbdadm status”  no server01.

elder@server01:~$ sudo drbdadm status
meuRes role:Primary
  disk:UpToDate
  peer role:Secondary
    replication:Established peer-disk:UpToDate

Acima

“meuRes role:Primary” sempre será o computador onde executei o comando “drbdadm status“, nesse caso é o server01. Então, server01 está como primário. Tudo que for salvo nele será replicado para o secundário

“peer role:Secondary” sempre será o outro computador, nesse caso o server02. Então server02 está como secundário. Receberá os dados do primário via replicação.

 

Abaixo, iremos propositadamente causar um split brain

Simulando um Split Brain no DRBD

De propósito, iremos  causar split brain apenas servir de estudo.

No server02, execute “drbdadm disconnect meuRes

elder@server02:~$ sudo drbdadm disconnect meuRes

No server02, execute “drbdadm primary meuRes”

elder@server02:~$ sudo drbdadm primary meuRes

Como o server01 já estava como primário não precisaríamos fazer os comandos acima. Mais iremos repeti-los pois em uma situação real geralmente os servidores envolvidos ficam como o status de standalone(sozinho, separado) e nosso server01 está como WFConnection(Esperando por conexão do server02).

No server01:

elder@server01:~$ sudo drbdadm disconnect meuRes

Execute, nos dois servidores, “cat /proc/drbd” ou “drbdsetup events2 –now” e verá que estão em standalone.

Vamos ver o status do drbd nos dois servidores

No server01

elder@server01:~$ sudo drbdadm status
meuRes role:Primary
  disk:UpToDate
  peer connection:Connecting

No server02

elder@server02:~$ sudo drbdadm  status
meuRes role:Primary
  disk:UpToDate

Perceba que os dois estão como primários

Vamos montar o bloco virtual nos dois servidores  e criar alguns arquivos

No server01

elder@server01:~$ sudo mount -t ext4  /dev/drbd1 /montagens/drbd1/
elder@server01:~$ sudo touch /montagens/drbd1/server01.txt

desmonte

elder@server01:~$ sudo umount /dev/drbd1

No server02 

Repita os passos acima

elder@server02:~$ sudo mount -t ext4 /dev/drbd1 /montagens/drbd1/
elder@server02:~$ sudo touch /montagens/drbd1/server02.txt
elder@server02:~$ sudo umount /dev/drbd1

 

Solucionando o Split Brain

E agora? No cenário acima é fácil resolver esse dilema. Nós criamos apenas um arquivozinho. Mas em cenários reais é praticamente impossível. São situações onde o drbd replica banco de dados ou milhares de arquivos. Vamos supor que estejamos nessa situação e escolhemos por descartar os dados do server02.

Nesse caso, o server02 que foi escolhido para perder seus dados discrepantes é chamado de “vítima do split brain”

No server02, execute

elder@server02:~$ sudo drbdadm disconnect meuRes

O comando acima retornaria falha porque já o usamos acima quando causamos o split brain propositadamente. Mas em situação real seria executado sem erros.

elder@server02:~$ sudo drbdadm secondary  meuRes

Conecte descartado os dados discrepantes(–discard-my-data)

elder@server02:~$ sudo drbdadm connect  --discard-my-data   meuRes

 

No server01,

elder@server01:~$ sudo drbdadm disconnect meuRes

e

elder@server01:~$ sudo drbdadm connect meuRes

veja o status no server01

elder@server01:~$ sudo drbdadm status
meuRes role:Primary
  disk:UpToDate
  peer role:Secondary
    replication:Established peer-disk:UpToDate

monte o bloco virtual do drbd e veja que o único arquivo que permanece é o server01.txt. O server02.txt foi descartado.

elder@server01:~$ sudo mount -t ext4 /dev/drbd1 /montagens/drbd1/
elder@server01:~$ ls /montagens/drbd1/
lost+found  server01.txt

 

Conclusão

Aqui vimos como solucionarmos problema com split brain. Temos que ter o cuidado, analisarmos bem para que não ocorra a perda de dados que não deveriam ser perdidos ao usarmos –discard-my-data na vítima do split brain.

Leitor voraz e um dos administradores do GNU/Linux Brasil no Whatsapp, facebook, youtube e nesse dito site: www.gnulinuxbrasil.com.br

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *