Vamos instalar o drbd8.
# aptitude install drbd8-modules-2.6-686 drbd8-utils ocfs2-tools ocfs2-tools-dev ocfs2console -y
Após instalarmos o nosso drbd vamos carregar os módulos necessários.
# modprobe cn
# modprobe drbd
Vamos ao arquivo de configuração do drbd, este arquivo fica localizado em
/etc/drbd.conf.
# vim /etc/drbd.conf
#/etc/drbd.conf
# Opções Globais
# Geralmente no início do arquivo. Poucas opções são definidas nesta seção.
#
global {
usage-count yes; # Gerar status da atualização do sistema de DRBD.
}
#
# Opções comuns a mais de um recurso, quando houver. No caso de existir opções
# definidas internamente ao recurso, elas irão sobrepor as opções comuns.
common {
protocol C; # Método de replicação. Neste caso, replicação síncrona.
}
### ocfs2 usando 02 primários
resource r1 {
net {
# Permitir/habilitar dois servidores primários.
allow-two-primaries; #Permite habilitar dois servidores primários
after-sb-0pri discard-younger-primary;
after-sb-1pri consensus;
after-sb-2pri disconnect;
}
startup {
# Iniciar os dois servidores como primários, por padrão.
become-primary-on both;
}
syncer {
rate 600M; #Para placas de rede de 10/100 utilizar 10M
}
on debian {
device /dev/drbd1; # Nome do dispositivo de DRBD
disk /dev/hda11; # Dispositivo de baixo nível utilizado a partição
address 192.168.0.1:7789; # IP:porta de conexão
meta-disk internal; # Armazenamento das informações de dados é feito
# dentro do dispositivo de baixo nível.
}
on debian2 {
device /dev/drbd1;
disk /dev/hda11;
address 192.168.0.2:7789;
meta-disk internal;
}
}
Como pode ser visto, o arquivo está todo comentado e de fácil entendimento.
O arquivo pode ser mantido como padrão para configuração de outros servidores com DRBD + OCFS, somente mudando a seguinte parte do arquivo:
on debian {
device /dev/drbd1; # Nome do dispositivo de DRBD
disk /dev/hda11; # Dispositivo de baixo nível utilizado
address 192.168.0.1:7789; # IP:porta de conexão
meta-disk internal; # Armazenamento das informações de dados é feito
# dentro do dispositivo de baixo nível.
}
on debian2 {
device /dev/drbd1;
disk /dev/hda11;
address 192.168.0.2:7789;
meta-disk internal;
}
}
Vamos agora criar os dispositivos do drbd.
Obs.: Se você não criou a partição para os nosso teste, pode fazer isso utilizando o cfdisk para criar a partição hda11. Ex.:
# cfdisk /dev/hda
Escolha o espaço livre e crie uma partição de 2 GB para efetuarmos testes e mande gravar.
Para um ambiente de produção a partição vai depender do volume de dados. Este nosso artigo é somente um exemplo para a um ambiente de produção e análise do que vai ser necessário, por isso utilize Itil e cobit se possível para obter um bom planejamento e execução.
Esses comandos que eu vou passar tem que ser executados nos dois servidores (comando a comando). Vamos zerar o dispositivo para ter certeza que não vai dar nem um problema.
# dd if=/dev/zero of=/dev/hda11 bs=1M count=128
Pronto, a nossa partição está zerada.
Execute este comando nos dois servidores antes de passar para o próximo comando.
# drbdadm -- --discard-my-data connect r1
Onde r1 é o nome do nosso dispositivo, que no arquivo de configuração do drbd está como resource r1.
Execute este comando nos dois servidores antes de passar para o próximo comando.
# drbdadm create-md r1
Execute este comando nos dois servidores antes de passar para o próximo comando.
# drbdadm attach r1
Execute este comando nos dois servidores antes de passar para o próximo comando.
# drbdadm connect r1
Pronto, agora podemos iniciar o drbd, inicie-o nos dois servidores com o seguinte comando:
# /etc/init.d/drbd start
Podemos observar como está a situação do nosso dispositivo drbd com o seguinte comando.
# cat /proc/drbd
Se em "Connected st" estiver como Primary/Primary, está tudo ok, porém se estiver como Secondary/Secondary temos que forçar os dispositivos a passarem para primary e temos mais uma situação quanto ao dispositivo Unknown, normalmente é quando um dos servidores não está operante por problemas de rede ou de configuração do arquivo do drbd. Então muita atenção a esses detalhes.
Vamos levar em consideração que só estamos com o problema que os dois servidores estão como secondary, resolvemos com o seguinte comando. Este comando tem que ser rodado nos dois servidores.
# drbdadm -- --overwrite-data-of-peer primary r1
Agora é só esperar eles sincronizarem os dados, isso depende da placa de rede, da velocidade do disco e do tamanho do disco, fora os processos do drbd, se você notar muita lentidão em algum desses fatores, veja se não é bom fazer algum upgrade.
Para acompanhar a sincronização pode utilizar o seguinte comando:
# watch cat /proc/drbd
Para sair é só pressionar CTRL+C.
Quando terminar a sincronização vai aparecer depois de Primary/Primary em ds:Inconsistent/Inconsistent como:
cs:Connected st:Primary/Primary ds:UpToDate/UpToDate
Pronto, já temos um raid1 via rede.
Então para que o OCFS2?
Como comentei no começo do artigo, esse é um dos sistemas de arquivos que podemos ter dois master escrevendo no sistema de arquivos no DRBD, somente o Primary poderia escrever, então se o primary parasse teríamos que montar a partição do que estava como secondary e usar o comando para mudar ele para primary para daí sim ele poder escrever.
Com o OCFS2 os 2 podem escrever simultaneamente, por isso que eu peguei o servidor de email para tratarmos por que o que me adianta eu ter 2 servidores de email sem as caixas de mensagens iguais? Poderíamos utilizar o rsync para ir atualizando mais, dependendo do volume isso poderia se tornar inviável e teria que ser agendando de tempos em tempos.
Ex.: O seu servidor de email caiu e o secundário fazia o rsync das caixas de entrada a cada 30 minutos e o seu chefe está com uma mensagem para fechar um contrato muito importante nesse servidor que caiu e a mensagem chegou a cerca de 2 minutos, o rsync não sincronizou e o seu chefe vai jogar a culpa em quem? E pior, deu pau o HD desse servidor, e agora?
Em uma empresa que recebe 100 emails por dia isso é um pequeno erro.
Mas em uma empresa que recebe cerca de 100 mil emails por dia ou mais, isso seria uma catástrofe e a sua cabeça iria rolar. Para não acontecer isso teríamos o DRBD+OCFS2 trabalhando em conjunto, essa solução poderia ser trocada por um STORAGE, mas um STORAGE não está muito barato e a maioria das empresas nem pensa em comprar um equipamento desses, então o ADM que tem que se virar, por isso que estou escrevendo este artigo. Igualmente eu muitos outros ADMs estão precisando de uma solução de alta disponibilidade dessas e sem gastar muito.
Vamos lá para o OCFS2.
Lembra que instalamos o ocfs2console? Então vamos precisar dele e você tem as mesmas opções do haclient de exportar o ocfs2console via ssh ou o que você preferir, oo utilizar o putty que é o que eu uso.
De acordo com a documentação oficial da Oracle, é altamente recomendado que o arquivo que vem por padrão em /etc/ocfs2/cluster.conf seja renomeado e que a configuração seja feita via console gráfico.
Então chame o ocfs2console:
# ocfs2console &
Após aparecer a tela do ocfs2console clique em Cluster/Configure Nodes. A configuração dos nomes das máquinas deve ser exatamente igual ao hostname das mesmas.
Clique em Adicionar na tela que aparece e digite o nome da máquina como explicado acima. Digite o endereço IP no campo logo abaixo. E a porta pode deixar como o padrão 7777. Clique em ok.
Agora faça o mesmo processo para incluir o segundo nodo. Clique em Adicionar na tela que aparece, digite o nome da máquina como explicado acima. Digite o endereço IP no campo logo abaixo. E a porta pode deixar como o padrão 7777. Clique em ok.
Agora clique em aplicar.
E pode clicar agora em fechar.
Agora no servidor aonde você exportou a tela de configuração do ocfs2console, vá ao diretório /etc/ocfs2
e vamos fazer uma cópia deste arquivo para o segundo servidor.
# rsync -Hxpagouvt cluster.conf 192.168.0.2:/etc/ocfs2/
Pronto, já temos a configuração nos dois servidores.
Precisamos de mais um ajuste.
No debian temos que editar o arquivo
/etc/default/o2cb e ativá-lo.
Aonde que se encontra essa linha mude para true:
O2CB_ENABLED=false
# vim /etc/default/o2cb
[...]
O2CB_ENABLED=true
[...]
Pronto, agora podemos iniciar o serviço.
# /etc/init.d/o2cb stop
# /etc/init.d/o2cb start
Se der algum erro verifique os logs para ver se não é erro de sintaxe no /etc/default/o2cb.
Se não deu erro ótimo, vamos continuar.
Agora vamos formatar as nossas partições com o sistema de arquivos OCFS2.
Vamos criar um diretório chamado /ocfs2 nos dois servidores que precisaremos deles logo.
# mkdir /ocfs2
Acesse novamente o console do ocfs2.
# ocfs2console &
Vá em Tasks/Format... vai abrir uma nova tela, nela vão informar os devices, no nosso caso o /dev/drbd1. Em Label coloque o nome que achar mais conveniente, como Cluster ou Oracle.
Em cluster size deixe com 128k, que é o volume de armazenamento de dados, em geral em Number of node slots coloque 2, que é o nosso número de nodos. Em block size 4k.
E é só clicar em Ok.
É só esperar formatar.
Agora vamos montar a nossa partição.
No console temos um botão de mount, clique nele. Vai aparecer uma tela pedindo o ponto de montagem e as opções.
Em ponto de montagem selecione a partição que criamos /ocfs2 e em options coloque como defaults e clique em ok.
Acesse o outro servidor e monte na mão a outra partição com:
# mount.ocfs2 /dev/drbd1 /ocfs2
Utilize o "df -Th" para ver as partições e os tamanhos ou o comando mount. Eu prefiro o "df -Th", pois dá para ver a partição, o ponto de montagem, o sistema de arquivos em forma mais legível que o mount.
# df -Th
/dev/drbd1 ocfs2 2G 45M 2G 2% /ocfs2
Para efetuar testes entre na partição /ocfs2 e crie um arquivo ou um diretório e vá no outro servidor e adicione mais um e confira se os dois servidores conseguem acessar estes arquivos ou diretórios.
Ex.: Em um dos servidores faça o seguinte:
# mkdir /ocfs2/teste
Criamos um diretório chamado teste, agora vão ao outro servidor e vamos criar um arquivo dentro deste diretório teste.
No outro servidor:
# touch /ocfs2/teste/tudook
Note que temos acesso nos dois servidores ao mesmo arquivo, que é o nosso propósito e melhor, podemos criar e excluir simultaneamente os arquivos e diretórios.
Isso é bom demais!
Agora que já temos tudo certo vamos colocar esta partição para ser montada na inicialização do sistema.
Vamos editar o arquivo
/etc/fstab
# vim /etc/fstab
[...]
/dev/drbd1 /ocfs2 _netdev,defaults 0 0
Pronto, criamos uma entrada no arquivo de montagem na inicialização do sistema, este parâmetro que coloquei _netdev é para ser montada a partição depois que subir a rede, pois não adianta ele tentar montar sem rede pois senão de que vai adiantar o /ocfs2, ele vai ser uma partição local como um /var ou /etc.
Agora vamos acertar um problema que achei na inicialização, no Debian
GNU/Linux por padrão o drbd inicializa depois do ocfs2, isso está errado pois o que o ocfs2 vai gerenciar se o dispositivo do drbd não esta ativo?
Então vamos arrumar isso.
Faça isso nos 2 servidores.
# mv /etc/rc2.d/S70drbd /etc/rcS.d/S50drbd
Agora vamos ver se ficou tudo certo :
# ls /etc/rcS.d/
S50drbd
S55bootmisc.sh
S55urandom
S60o2cb
S65ocfs2
Note que agora o drbd vai inicializar antes do o2cb e do o2cfs, que são quem gerenciam o ocfs2.
Agora vai tudo funcionar corretamente.
Para fazer um teste reinicialize os dois servidores e veja se o /ocfs2 vai inicializar normalmente.
Se estiver tudo certo não vai dar nem um problema.
Se der algum problema tente identificar nos arquivos de log do sistema como o comando "dmesg" e os arquivos /var/log/syslog e /var/log/messages.