linbit<\/a>, “a funcionalidade principal do DRBD \u00e9 implementada por meio de um m\u00f3dulo do kernel Linux. Especificamente, o DRBD constitui um driver para um dispositivo de bloco virtual; portanto, o DRBD est\u00e1 situado pr\u00f3ximo \u00e0 parte inferior da pilha de I\/O de um sistema”.<\/p>\n\n\nBasicamente o DRBD cria um dispositivo virtual que ser\u00e1 conectados entre os n\u00f3s do cluster como uma parti\u00e7\u00e3o 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\u00e9m, pode ser aconselhado algum especifico dependendo do modo do recurso. Saiba mais sobre recurso abaixo.<\/p>\n\n\n
RECURSOS<\/h3>\n\n\n
No DRBD, recurso \u00e9 o termo coletivo que se refere a todos os aspectos de um conjunto de dados replicados espec\u00edfico. Esses incluem:<\/p>\n\n\n
Nome do recurso<\/strong>: qualquer nome arbitr\u00e1rio que n\u00e3o contenha espa\u00e7o em branco ao qual o recurso \u00e9 referido.<\/p>\n\n\nVolumes<\/strong>: qualquer recurso \u00e9 um grupo de replica\u00e7\u00e3o que consiste em um ou mais volumes que compartilham um fluxo de replica\u00e7\u00e3o comum. Um volume cont\u00e9m o conjunto de dados replicados e um conjunto de metadados para uso interno do DRBD, s\u00e3o numerados come\u00e7ando com 0, e pode haver at\u00e9 65.535 volumes em um recurso.<\/p>\n\n\nDispositivo DRBD<\/strong>: dispositivo de bloco virtual gerenciado pelo DRBD, cada dispositivo DRBD corresponde a um volume em um recurso. O dispositivo de bloco associado geralmente \u00e9 nomeado \/dev\/drbdX, onde X est\u00e1 o n\u00famero menor do dispositivo, come\u00e7ando com 0. O DRBD tamb\u00e9m permite nomes de dispositivos de bloco definidos pelo usu\u00e1rio que, no entanto, devem come\u00e7ar com drbd_.<\/p>\n\n\nVoc\u00ea ver\u00e1 quando configurar o DRBD que os recursos geralmente ficam em arquivo com extens\u00e3o .res. Nesses arquivos teremos informa\u00e7\u00f5es como nome do dispositivos, nodes, <\/p>\n\n\n
MODOS DOS RECURSOS<\/h3>\n\n\n
Modo prim\u00e1rio \u00fanico<\/strong>
No modo prim\u00e1rio \u00fanico, um recurso est\u00e1, a qualquer momento, na fun\u00e7\u00e3o principal em apenas um membro do cluster. Como \u00e9 garantido que apenas um n\u00f3 do cluster manipula os dados a qualquer momento, esse modo pode ser usado com qualquer sistema de arquivos convencional (ext3, ext4, XFS etc.).<\/p>\n\n\nA implanta\u00e7\u00e3o do DRBD no modo single-primary \u00e9 a abordagem para clusters de alta disponibilidade (com capacidade de failover).<\/p>\n\n\n
Duas coisas precisam ser esclarecidas nesse modo, que confunde muitas vezes:<\/p>\n\n\n
- Primeiro<\/strong>: voc\u00ea n\u00e3o<\/strong> conseguir\u00e1 montar a parti\u00e7\u00e3o do DRBD nos dois n\u00f3s simultaneamente, ir\u00e1 dar erro no secund\u00e1rio (os dados\/informa\u00e7\u00f5es na parti\u00e7\u00e3o s\u00e3o sempre sincronizadas entre o n\u00f3 prim\u00e1rio e secund\u00e1rio mas o recurso fica dispon\u00edvel apenas para o prim\u00e1rio). Para que consiga montar simultaneamente nos dois n\u00f3s, eles precisam estar os dois como prim\u00e1rio, e este \u00e9 um outro modo chamado prim\u00e1rio duplo <\/strong>explicado mais para frente. O que confunde \u00e9 que o DRBD por padr\u00e3o trabalha como modo prim\u00e1rio \u00fanico(ou seja um n\u00f3 prim\u00e1rio e outro secund\u00e1rio).<\/li>
- Segundo<\/strong>: neste modo prim\u00e1rio \u00fanico caso voc\u00ea tenha montado a parti\u00e7\u00e3o no prim\u00e1rio e este n\u00f3 fique indispon\u00edvel a parti\u00e7\u00e3o n\u00e3o ir\u00e1 aparecer montada “autom\u00e1gicamente” no secund\u00e1rio, para que isso acontece neste modo, voc\u00ea precisa usar uma ferramente a parte como por exemplo heartbeat<\/strong>.<\/li><\/ul>\n\n\n
Modo prim\u00e1rio duplo<\/strong>
No modo prim\u00e1rio duplo, um recurso fica sempre como prim\u00e1rio para os n\u00f3s do cluster. Como o acesso simult\u00e2neo aos dados \u00e9 poss\u00edvel, esse modo requer o uso de um sistema de arquivos em cluster compartilhado que utilize um gerenciador de bloqueios distribu\u00eddos. Exemplos incluem GFS e OCFS2 .<\/p>\n\n\nA implanta\u00e7\u00e3o do DRBD no modo duplo prim\u00e1rio \u00e9 a abordagem preferida para clusters de balanceamento de carga que exigem acesso simult\u00e2neo a dados de dois n\u00f3s. Este modo est\u00e1 desativado por padr\u00e3o <\/strong>e deve ser ativado explicitamente no arquivo de configura\u00e7\u00e3o do DRBD.<\/p>\n\n\nMODOS DE REPLICA\u00c7\u00c3O<\/h3>\n\n\n
O DRBD suporta tr\u00eas modos de replica\u00e7\u00e3o distintos, permitindo tr\u00eas graus de sincronicidade na replica\u00e7\u00e3o.<\/p>\n\n\n
Protocolo A<\/strong>
Protocolo de replica\u00e7\u00e3o ass\u00edncrona. As opera\u00e7\u00f5es de grava\u00e7\u00e3o local no n\u00f3 principal s\u00e3o consideradas conclu\u00eddas assim que a grava\u00e7\u00e3o no disco local \u00e9 conclu\u00edda e o pacote de replica\u00e7\u00e3o \u00e9 colocado no buffer de envio TCP local. No caso de failover for\u00e7ado, pode ocorrer perda de dados. Os dados no n\u00f3 em espera s\u00e3o consistentes ap\u00f3s o failover, no entanto, as atualiza\u00e7\u00f5es mais recentes executadas antes da falha podem ser perdidas. O protocolo A \u00e9 usado com mais frequ\u00eancia em cen\u00e1rios de replica\u00e7\u00e3o de longa dist\u00e2ncia. Quando usado em combina\u00e7\u00e3o com o DRBD Proxy, cria uma solu\u00e7\u00e3o eficaz de recupera\u00e7\u00e3o de desastres. <\/p>\n\n\nProtocolo B<\/strong>
Protocolo de replica\u00e7\u00e3o s\u00edncrona (semi-s\u00edncrona) de mem\u00f3ria. As opera\u00e7\u00f5es de grava\u00e7\u00e3o local no n\u00f3 prim\u00e1rio s\u00e3o consideradas conclu\u00eddas assim que a grava\u00e7\u00e3o no disco local ocorre e o pacote de replica\u00e7\u00e3o atinge o n\u00f3 do mesmo n\u00edvel. Normalmente, nenhuma grava\u00e7\u00e3o \u00e9 perdida em caso de failover for\u00e7ado. No entanto, no caso de falha de energia simult\u00e2nea nos n\u00f3s e destrui\u00e7\u00e3o simult\u00e2nea e irrevers\u00edvel do armazenamento de dados do prim\u00e1rio, as grava\u00e7\u00f5es mais recentes conclu\u00eddas no prim\u00e1rio podem ser perdidas.<\/p>\n\n\nProtocolo C<\/strong>
Protocolo de replica\u00e7\u00e3o s\u00edncrona. As opera\u00e7\u00f5es de grava\u00e7\u00e3o local no n\u00f3 prim\u00e1rio s\u00e3o consideradas conclu\u00eddas somente ap\u00f3s a confirma\u00e7\u00e3o da grava\u00e7\u00e3o local e remota no disco. Como resultado, a perda de um \u00fanico n\u00f3 \u00e9 garantida para n\u00e3o levar a nenhuma perda de dados. A perda de dados \u00e9 inevit\u00e1vel mesmo com esse protocolo de replica\u00e7\u00e3o se os dois n\u00f3s (ou seus subsistemas de armazenamento) forem irreversivelmente destru\u00eddos ao mesmo tempo.<\/p>\n\n\nO protocolo de replica\u00e7\u00e3o mais comumente usado nas configura\u00e7\u00f5es de DRBD \u00e9 o protocolo C.<\/p>\n\n\n
A escolha do protocolo de replica\u00e7\u00e3o influencia dois fatores de sua implanta\u00e7\u00e3o: prote\u00e7\u00e3o e lat\u00eancia . A taxa de transfer\u00eancia , por outro lado, \u00e9 amplamente independente do protocolo de replica\u00e7\u00e3o selecionado.<\/p>\n","protected":false},"excerpt":{"rendered":"
DRBD significa Distributed Replicated Block Device, e ele serve exatamente para isso, fazer replica\u00e7\u00e3o de parti\u00e7\u00f5es, tamb\u00e9m chamado as vezes de RAID de rede, \u00e9 bastante usado em ambiente de cluster como por exemplo dois nodes replicando uma ou mais parti\u00e7\u00f5es. Segundo linbit, “a funcionalidade principal do DRBD \u00e9 implementada por meio de um m\u00f3dulo […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[23,6],"tags":[45,54],"_links":{"self":[{"href":"https:\/\/bfnetworks.com.br\/wp-json\/wp\/v2\/posts\/1350"}],"collection":[{"href":"https:\/\/bfnetworks.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bfnetworks.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bfnetworks.com.br\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/bfnetworks.com.br\/wp-json\/wp\/v2\/comments?post=1350"}],"version-history":[{"count":1,"href":"https:\/\/bfnetworks.com.br\/wp-json\/wp\/v2\/posts\/1350\/revisions"}],"predecessor-version":[{"id":1852,"href":"https:\/\/bfnetworks.com.br\/wp-json\/wp\/v2\/posts\/1350\/revisions\/1852"}],"wp:attachment":[{"href":"https:\/\/bfnetworks.com.br\/wp-json\/wp\/v2\/media?parent=1350"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bfnetworks.com.br\/wp-json\/wp\/v2\/categories?post=1350"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bfnetworks.com.br\/wp-json\/wp\/v2\/tags?post=1350"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}