DRBD: Como Gerenciar Troca de Disco Danificado? – Parte 06

Sabemos que o DRBD cria um bloco virtual acima do disco. Esse bloco geralmente aparece como /dev/drbd1 ou /dev/drbd2 etc. Podemos formatar e colocar qualquer sistema de arquivos(ext4, ntfs, zfs, xfs…) que desejarmos nesse  bloco virtual.

Na imagem vemos que o disco fica abaixo do drbd(aqui falamos de bloco virtual e não do módulo drbd no kernel). Dizemos que o disco está em uma camada de baixo nível e o drbd(bloco virtual) em uma camada superior.

 

 

É bom salientar que é bem comum operações em discos serem chamadas pelas siglas I/O. i/o vem de input/output ou entrada/saída. Outro termo bastante usado é leitura/escrita.

Esse bloco virtual representa um disco(HD, SSD…); mas, e quando um dos discos, em um dos servidores, danificar?

 

Opção on-io-error

Na seção “common” do arquivo de configuração “/etc/drbd.d/global_common.conf”  podemos colocar uma das opções:

  • on-io-error  detach: Essa opção já é a padrão e recomendada. Na ocorrência de uma falha em um dos discos o node/servidor se solta/desvincula do disco e passa para o modo diskless(sem disco).
  • on-io-error pass-on: Não é o recomendado a fazer. O erro do disco(camada de baixo nível) seria repassado para o bloco virtual(nível superior). o bloco, por exemplo, poderia ser remontado somente como leitura, não aceitando salvar(escrita) dados.
  • on-io-error call-local-io-error: Chama o comando que colocarmos em “local-io-error”  da seção handlers.

 

Obs.: Podemos colocar a opção “on-io-error” tanto dentro de “global_common.conf”, e isso afetará qualquer resource, quanto dentro das configurações de um resource específico. Antes também existia a opção “on-io-error panic”.

Como “on-io-error detach” é a opção recomendada e o comportamento padrão, então não iremos alterar nada, nenhum arquivo.

Detach significa desanexar, desprender, soltar, desvincular, desatar…. Após um disco apresentar defeito ele será de desanexado e o resource ficará em modo “diskless”.

 

Nosso Ambiente de Trabalho

Temos 2 servidores com as seguintes características

servidor 01

  • hostname/nome: server01
  • nome do Resource: meuRes
  • disco: /dev/sdb1
  • device /dev/drbd1;

 

servidor 02

  • hostname/nome: server02
  • nome do Resource: meuRes
  • disco: /dev/sdb1
  • device /dev/drbd1;

 

 

 

Simulando Defeito no Disco /dev/sdb1 do server01

 

  • Vejamos o status atual do server01
elder@server01:~$ sudo drbdadm status
meuRes role:Primary
  disk:UpToDate
  peer role:Secondary
    replication:Established peer-disk:UpToDate

Olhando acima vemos que:

disk:UpToDate: O disco sdb1 no server01 está ok

peer-disk:UpToDate: O disco sdb1 no server02 está ok

 

Uma coisa importante para saber é que, sempre, “peer” irá se referir ao outro servidor. “peer” significa par, ou seja, “o outro par” do servidor; ou parceiro.

  • Com o server01 ligado, retirei(puxei os cabos 🙂 ) o disco sdb1 do server01 para simularmos o erro. Vejamos agora que o status está como diskless
    elder@server01:~$ sudo  drbdadm status
    meuRes role:Primary
      disk:Diskless
      peer role:Secondary
        replication:Established peer-disk:UpToDate

    Acima ocorreu o comportamento padrão: “on-io-error  detach”. O disco defeituoso foi desanexado(detach) e o status passou a ser diskless(sem disco).

    Lembre-se que o disco “queimado” pertence ao server01 que está como primário.

    O server01 parou de funcionar? Nããããão. Ele continua funcionando! Como é possível funcionar sem disco? Funciona da seguinte forma: com “on-io-error  detach” o DRBD acaba mascarando o erro de I/O no server01 e começa a procurar, via rede, o bloco correspondente ao danificado do server01 no server02. A partir do momento em que o bloco correspondente ao server01 no server02 é encontrado então o DRBD marca o server01 como diskless e passa a transferir toda operação de escrita e leitura, I/O, feita no server01 para o server02. Tudo isso via rede. Haverá lentidão, perda de performance! Mas tudo irá continuar a funcionar.
    Quando digo que o DRBD mascara a falha de disco estou querendo dizer que o DRBD esconde o problema para que o bloco virtual(/dev/drbd1) não perceba que seu disco foi para o beleléu, morreu. O DRBD faz o /dev/drbd1 pensar que está tudo ok e começa a usar, via rede, o disco /dev/sdb1 que está no server02.

Se por acaso o disco defeituoso estivesse no servidor secundário não haveria necessidade de mascarar o erro já que somente o drbd como primário que opera lendo e escrevendo arquivos(I/O).

Trocando o Disco Defeituoso

Se o seu servidor suporta  hot swap(troca quente) você poderá retirar o disco danificado e inserir o novo sem precisar desligar o servidor. Caso contrário, desligue o server01 e insira o disco novo.

Já com o disco novo inserido no server01, verifique como ele está identificado. Para isso vamos executar o comando “lsblk”

elder@server01:~$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
.......
sdc      8:32   0  500M  0 disk 
└─sdc1   8:33   0  499M  0 part 
......
drbd1  147:1    0  499M  0 disk /montagens/drbd1

O disco defeituoso era identificado como /dev/sdb1 e agora o novo está como sendo /dev/sdc1.

Se o disco novo estivesse com o mesmo nome do antigo(/dev/sdb1) só precisaríamos executar o comando “drbdadm create-md meuRes”.

 

Alterando o Arquivo /etc/drbd.d/meuRes.res nos dois servidores

Obs.: a etapa abaixo apenas é necessária se o nome do disco foi alterado. Em nosso exemplo o sdb passou a ser sdc.

Tanto no server01 quanto no server02, deixei o arquivo  /etc/drbd.d/meuRes.res como abaixo.

resource meuRes { 
  on server01 { 
    device /dev/drbd1; 
    disk /dev/sdc1;
    address 10.1.1.31:7789; 
    meta-disk internal;
 } 
  on server02 { 
    device /dev/drbd1;
    disk /dev/sdb1;
     address 10.1.1.32:7789;
     meta-disk internal; 
 } 
}

Acima, em “on server01″, troquei o sdb1 por sdc1

feito a alteração execute “drbdadm adjust meuRes” nos dois servidores para que o DRBD perceba as alterações

no server01

elder@server01:~$ sudo drbdadm adjust meuRes

no server02

elder@server02:~$ sudo drbdadm adjust meuRes

 

Execute drbdadm create-md meuRes

Agora iremos criar o metadado para o novo disco

apenas no server01 execute

elder@server01:~$ sudo drbdadm create-md meuRes

apenas no server01 execute o comando “drbdadm attach meuRes” para anexarmos o disco

elder@server01:~$ sudo drbdadm attach  meuRes

 

Vendo o status

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

 

Conclusão

O DRBD ajuda muito com a continuidade do trabalho em desviar operações de escrita e leitura para o outro node(peer) ao termos um disco danificado.

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 *