Suponha um cenário com um “cluster” de máquinas atendendo um serviço qualquer, como um apache por exemplo. Poderíamos usar “n” ferramentas para manter este cluster em sincronia, porém neste artigo eu gostaria de introduzir o poder de um Software Livre 100% Nacional criado pelo Luis Furquim!
Portanto, para que todas as máquinas fiquem em sincronia, usaremos o ChironFS que é um Sistema de Arquivos Tolerante a Falhas com Replicação de Dados, no qual tive contato em Porto Alegre durante o FISL 9.0.
Você pode fazer da apresentação do mesmo aqui: ChironFS
O ChironFS é um Filesystem virtual que utiliza o FUSE. Funciona sincronizando dados entre dois ou mais diretórios, porém, cada um deste diretório pode ser um ponto de montagem de uma máquina remota. Desta forma, o ChironFS atua como uma camada de abstração, sincronizando, por exemplo, um Debian com ext3 local com um Red Hat usando ReiserFS remotamente, usando NFS, SSHFS ou qualquer outro sistema que trabalhe com pontos de montagem.
No Red Hat Enterprise, infelizmente não existe os pacotes para o fuse e nem para seu módulo do kernel, mas você pode busca-los nos repositórios “dag”
http://dag.wieers.com/rpm/packages/dkms-fuse/
http://dag.wieers.com/rpm/packages/fuse/
Neste caso, as 03 máquinas de front-end exportam o diretório /data/dominios via NFS para que seja possível a montagem remota destes diretórios:
# cat /etc/hosts
192.168.0.1 site-1 site-1.com.br
192.168.0.2 site-2 site-2.com.br
192.168.0.3 site-3 site-3.com.br
# cat /etc/exports
/data/sync/site-1 192.168.0.0/24(async,rw,no_root_squash)
# cat /etc/fstab
nfsd /proc/fs/nfsd nfsd auto,defaults 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs auto,defaults 0 0
site-2:/data/sync/site-2 /data/sync/site-2 nfs soft,timeo=3 0 0
site-3:/data/sync/site-3 /data/sync/site-3 nfs soft,timeo=3 0 0
Portanto:
Site-1: monta a site-2 e a site-3
Site-2: monta a site-1 e a site-3
Site-3: monta a site-1 e a site-2
O ChironFS cuidará para que a escrita feita localmente seja replicada para as outras duas máquinas, configurado desta forma pelo /etc/fstab (atenção, um uma única linha!):
chironfs#/data/sync/site-1=:/data/sync/site-2=:/data/sync/site-3 /data/dominios
fuse allow_other,ctl=/var/run/chironctl,log=/var/log/chironfs.log 0 0
O que quer dizer:
O diretório /data/sync/site-1 (local) deve ser sincronizado com o /data/sync/site-2 (NFS, mais lento) e também com o /data/sync/site-3 (NFS) cada vez que houver escrita em /data/dominios.
Quando houver leitura em /data/domínios, o ChironFS irá dar preferência ao device local, pois é o único que não apresenta os dois pontos (“:”) em sua montagem no /etc/fstab.
Portanto, toda e qualquer escrita no disco que tenha o objetivo de ser sincronizada com as demais máquinas, devem ser feitas diretamente no /data/dominios de qualquer uma das máquinas.
- Monitoramento
O ChironFS a partir da versão 1.1 já vem pronto para ser monitorado pelo Nagios, bastando para isso acrescentar em seu nrpe.cfg:
command[check_site1]=/var/run/chironctl/_data_sync_site-1/check_chironfs.sh
command[check_site2]=/var/run/chironctl/_data_sync_site-2/check_chironfs.sh
command[check_site3]=/var/run/chironctl/_data_sync_site-3/check_chironfs.sh
- Em caso de Problemas
Algumas dicas retiradas do manual oficial: Capítulo 5. Falhas das Réplicas
Toda vez que uma réplica falha, o ChironFS tenta manter seus sistemas rodando. Se a falha ocorrer durante uma operação de leitura, o ChironFS tenta ler de alguma outra réplica e, se conseguir, retorna os dados para o chamador sem gerar erro.
Se a falha ocorrer durante uma operação de escrita, o ChironFS continua tentando escrever nas outras réplicas. Se ao menos uma das réplicas escrever com sucesso, o ChironFS retorna ao chamador sem gerar erro. Mas, desta vez, além de logar o evento, ele desabilita as réplicas que tiverem falhado. Isto significa que não haverá mais leituras ou escritas de/para as réplicas que falharam.
O crontab das máquinas possui um pequeno script para gerar gravação no /data/dominios a fim de tentar detectar quando alguma máquina do “cluster” está fora do ar:
# Verificacao ChironFS
* * * * * /bin/touch /data/dominios/`hostname`; sleep 15; /bin/rm -f /data/dominios/`hostname`
Outra dica importante é “congelar” updates no kernel, pois o ChironFS depende o FUSE que tem um módulo específico para um kernel específico. Portanto, se você atualizar o kernel no RHEL, provavelmente o módulo do fuse não irá mais funcionar e conseqüentemente, o chironfs também não. Para que isso não ocorra acidentalmente:
# cat /etc/yum.conf
[main]
cachedir=/var/cache/yum
distroverpkg=redhat-release
...
exclude=kernel* fuse-kmdl*
Você tem a opção de montar um sistema de arquivos semelhante ao /proc para controlar o ChironFS, que é um sistema de arquivos de controle é composto de um diretório para cada réplica. Seus nomes são o pathname completo da réplica com as barras (“/”) mudadas para caracteres de sublinha.
Cada um deles contém dois arquivos: o primeiro é chamado “status” e contém um número “0″ nas réplicas que estiverem em bom estado ou um número “2″ se a réplica estiver desabilitada e os dados inconsistentes. Basta gravar “0″ ou “2″ neste arquivo para habilitar ou desabilitar a réplica.
Enfim, depois de detectar a falha, corrija a sua causa no servidor de réplica falhado. VOCÊ DEVE PROVER POR SUA CONTA O RESTABELECIMENTO DA CONSISTÊNCIA DOS DADOS NO SERVIDOR DE RÉPLICA QUE FALHOU. EU SUGIRO O USO DO RSYNC PARA ATUALIZAR OS DADOS. ESTE PASSO DEVE SER EFETUADO ANTES DE COLOCAR A RÉPLICA EM ESTADO HABILITADO DE NOVO, CASO CONTRÁRIO, VOCÊ IRÁ CORROMPER SEUS DADOS NAS DEMAIS RÉPLICAS.
Para restabelecer o uso da réplica após o procedimento de recuperação:
# echo 0 > /var/run/chironctl/_data_sync_site-3/status
E acompanhe as mudanças em /var/log/chironfs.log:
2008/08/04 11:35 init: version 1.1.2
2008/08/04 11:44 open+chown failed accessing /data/sync/site-3/site/htdocs/pops/index.html Input/output error
2008/08/04 11:44 disabling replica failed accessing /data/sync/site-3
2008/08/04 11:55 trusting replica /data/sync/site-3 Forced by administrator
Ou simplesmente “reinicie” o ChironFS:
# umount /var/run/chironctl /data/dominios
# mount /data/dominios
A Red Hat, juntamente com a Georgia Tech Mapping Open Source, disponibilizou um estudo conduzido em 75 países. O estudo designado Open Source Index (OSI), pretende medir a atividade mundial do software livre. Foram levados em consideração fatores dos países como políticas em setores como Governo, indústria e comunidade.
)
Entries (RSS)