Conhecendo o ChironFS - Tolerante a Falhas com Replicação de Dados
Posted by: Tiago Cruz in Red Hat, FISL9.0, Cluster
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
Entries (RSS)
August 8th, 2008 at 3:22 pm
Olá Tiago
Parabéns pelo post muito bom.
Eu utilizei por enquanto só para testes.
Tu já implementou em algum servidor.
August 8th, 2008 at 4:40 pm
Boa Tarde Marlon,
O post não ficou bom não
Foi escrito às pressas e a concordância não ficou lá essas coisas.
Mas é naquelas: Para bom entendedor, meia palavra bas…
Sim, implementei em servidores que estarão por entrar em produção nas próximas semanas (já estão homologados!)
Abraços
August 8th, 2008 at 10:28 pm
Bem, serei sincero ao inves de carinhoso.
Não gostei do post, nem da solução apresentada. Pra mim, usar o RSYNC ainda eh mais simples e prático do que usar o tal do ChironFS. O post tem como titulo “Tolerante a falhas com replicação de dados”. A parte do replicação de dados eu até posso concordar, mas como que essa solução é tolerante a falhas se quando um nó fica fora do cluster vc tem que fazer um RSYNC antes de torná-lo disponível?? Simplesmente, não faz sentido pra mim!!! Tolerancia a falhas é o sistema tratar a indisponibilidade de um nó de forma transparente e que quando esse nó fique disponível tudo se reestabeleça sem necessidade de intervenções. Se é pra rodar RSYNC toda vez que um nó falhar, prefiro usar RSYNC do começo ao fim. Um shellscript bem básico resolveria com simplicidade e praticidade o que o ChironFS se propõe a fazer, mas não faz e ainda complica. Use GFS, é uma solução muito mais robusta, simples, escalável e está presente no repositório base dos Red Hat like inclusive com grande suporte da comunidade e da própria Red Hat.
August 11th, 2008 at 12:27 am
Daniel,
Bons pontos você apresentou. Concordo que o post está um lixo, mas a ferramenta em si é outra história
O problema o rsync é que ele é unilateral, ou seja, em um cluster com 03 máquinas, uma seria a server a as outras as clients, não podendo haver write nas mesmas. Imagine um blog como esse (wordpress-like) onde o usuário faz upload de uma foto qualquer e o alteon/foundry/lvs balanceia a mesma para a terceira máquina, por exemplo? O rsync não iria pegar isso. Como você resolveria este problema?
Gosto muito do GFS, inclusive tem um post aqui falando sobre o mesmo com DRBD. O problema do DRBD é que ele não é escalável, e o “problema” do GFS é a necessidade de um Storage+Fence descente para ele funcionar bem… se para todo projeto em todas as empresas eu tivesse uma infra dessas eu estaria muito feliz!
Obrigado pelo seu post, espero uma resposta pois agora fiquei curioso em saber como você lida com este probleminha…
Abraços
August 11th, 2008 at 3:07 am
Olá Daniel
Obrigado por manifestar sua opinião. E obrigado pela sinceridade. Não é possível
atender às necessidades dos usuários se eles não disserem o que eles precisam.
Como autor do ChironFS, tenho recebido e-mails no sentido de implementar o
ressincronismo das réplicas falhas automaticamente e a forma como o ressincronismo
será implementado seguirá as sugestões que recebi. Esta é a forma como se
desenvolve o software livre: release early, release often. Os usuários têm a
oportunidade de participar do desenvolvimento do software desde os seus primórdios.
Em conseqüência disto, o software chega às mãos dos usuários antes de serem
implementadas todas as suas funcionalidades. Desta maneira, o desenvolvedor
é “abençoado” com o feedback dos usuários e, com isto, o software atinge a
maturidade mais cedo e, pricipalmente, está melhor adaptado às necessidades
dos usuários. E se assim não fosse, o desenvolvimento do software poderia
caminhar em direção muito diversa dos anseios dos usuários, causando muito
descontentamento e, possivelmente, o fracasso e abandono do projeto. É por
isto que o ChironFS foi publicado antes que fossem implementadas todas as
características desejáveis num software deste tipo. Para que a comunidade
participe de seu desenvolvimento. Em relação a este ponto específico, veja
http://groups.google.com/group/chironfs-forum/browse_thread/thread/9b3031afeeadc5aa .
Outras sugestões me foram enviadas por e-mail, mas são todas muito próximas
a esta.
Com relação à tolerância a falhas, de acordo com a wikipedia
http://pt.wikipedia.org/wiki/Toler%C3%A2ncia_a_falhas_(hardware) , “é a
propriedade que permite que sistemas (em geral, computacionais) continuem
a operar adequadamente mesmo após falhas em alguns de seus componentes”.
Sem entrar a fundo, pode-se dizer que o ChironFS preenche tal requisito.
Isto porque quando uma réplica falha (suponha que um disco rígido ou uma
placa de rede falhe), o ChironFS continua operante, usando as réplicas
que estão operantes. O software de aplicação, que acessa dados no ChironFS,
não receberá nenhum código de erro em virtude desta falha e, portanto,
continuará a operar. A falha é reportada em log e, também, passível de
monitoração via Nagios. Resumindo, apesar da falha no hardware, seu
sistema não vai parar. Agora, se formos mais a fundo, ainda de acordo com
a wikipedia http://pt.wikipedia.org/wiki/Toler%C3%A2ncia_a_falhas_em_software ,
veremos que “As atividades relacionadas à tolerância a falhas podem ser
subdivididas em quatro fases: detecção de erro, confinamento e avaliação
de danos, recuperação de erros e tratamento de falhas”. Desta forma, percebe-se
que o ChironFS implementa as duas primeiras atividades citadas, ficando em
dívida com as demais. Para isto, a solução virá em versões futuras.
Com relação ao uso do rsync, eu ressalto as seguintes diferenças: o rsync
deverá ser executado de “tempos em tempos”, tipicamente via cron. Entre cada
execução, surge uma janela de dessincronia. Ou seja, logo após uma execução do
rsync, à medida que novos dados são gravados na réplica principal, cresce a
dessincronia entre as réplicas. Pensando no pior caso, se a réplica principal
cair instantes antes de uma nova execução do rsync, haverá perda de dados
proporcional ao intervalo de tempo entre as execuções do rsync e, também, à
freqüência de gravações que seu sistema realiza. Além disto, há o problema da
performance do I/O. O rsync, ao ser executado, desconhece as diferenças entre
a fonte e o destino. Desta maneira, ele precisa fazer uma varredura nos dois
sistemas para determinar o que deve ser copiado de um para outro. Isto falando
em duas réplicas. Se você tiver mais de duas réplicas, o rsync terá de ser
executado mais de uma vez, em conseqüência disto, a varredura de leitura na
réplica principal se repetirá. Num sistema usando o ChironFS, a replicação
dos dados é feita em tempo real. No momento que a aplicação executa um write
num arquivo, este write é repetido em cada uma das réplicas. Não há varredura
em busca de diferenças entre as réplicas. Elas são mantidas em sincronia o tempo
todo. E, quanto a janela de dessincronia, você tem uma redução de período para
frações de segundo, já o rsync, disparado pelo cron, terá, no mínimo, um minuto,
que é o intervalo mínimo entre execuções. Mas, muito provavelmente, uma
configuração de rsync via cron irá estabelecer períodos maiores, para evitar que
o sistema esteja eternamente atendendo os pedidos de varredura de disco do rsync.
O uso do rsync em conjunto com o ChironFS se restringe às situações de falha,
que são exceção, não em operação normal. E isto até que seja implementada a
ressincronia automática, dispensando o seu uso.
Espero ter esclarecido todos os pontos que levantaste, mas fico à disposição
caso queiras maior aprofundamento do tema.
Atenciosamente
Luis Otavio
August 12th, 2008 at 6:04 pm
Srs, realmente… excelentes argumentos os que vocês descreveram. Muito esclarecedores. O Luis Otávio teve razão ao dizer que isso é uma das principais vantagens do SL, obter as visões e necessidades de quem vai usar o software e então estabelecer isso como norte para o projeto. Não tive a oportunidade, ainda, de testar a solução ChifronFS mas assim que eu tiver mais memória em minha máquina (em breve), testarei com máquinas virtuais me baseando no ambiente que administro hoje com o rsync.
Descrevendo meu ambiente… tenho 3 servidores TC sincronizados via RSYNC onde 1 é master de 2 e 2 é master de 3, ou seja, a maquina 1 replica para a 2 e a 2 então para a 3. Atualmente supre minhas necessidades pois as 2 outras máquinas são base histórico e failover, sendo somente a 1 a máquina de produção.
Lembrando que baseei minhas opiniões no que pude entender do post e não do software em si, até pq eu não podia falar nada se eu sequer testei.
Valeu pelo esforço em descrever alguns detalhes que ficaram ausentes no post.
Abraços.
August 12th, 2008 at 6:14 pm
Olá Daniel!
Essa é a vantagem do tal do wordpress: A coisa fica completa aqui nos comments…rsrsrs… na época do html não dava para fazer isso :-p é quase como o slashdot: a notícia em si não agrega muito, porém os comentários são fantásticos
O seu ambiente então não requer algo “online” e ainda, se cair a “2″ o sincronismo da “1″ para “3″ não irá existir, certo? E caso haja escrita na “2″ a primeira não fica sabendo e se há escrita na “3″ ninguém fica sabendo, certo?
Ainda bem que o seu ambiente é menos exigente do que o meu, heheheh
Abraços