HOWTO do ChironFS

Atualize as fstab's acrescentando estas 3 linhas:

Agora você pode configurar os serviços de seus servidores de usuário. Siga as instruções específicas dos serviços que você quer configurar, buscando exportar o diretório /virtual para seus usuários e colocando as árvores de documentos de seu webserver abaixo do diretório /virtual .

Para evitar ter um ponto de falha, você deve providenciar backup de hardware de rede, tais como 2 placas de rede para cada servidor, conectado e bridges redundantes.

Finalmente, configure o heartbeat no servidor de usuários para que qualquer falha em um deles seja automaticamente substituído pelo outro servidor.

b) Desktop com Backup em Rede

Se você tem um desktop Linux, FreeBSD ou NetBSD, você pode querer ter um backup de seus arquivos locais em algum servidor de rede. Esta solução se aplica para fazer backups instantâneos para a rede. MAS CUIDADO! ISTO NÃO SUBSTITUI UMA SOLUÇÃO REAL DE BACKUP PORQUE QUALQUER MUDANÇA FEITA EM SEUS ARQUIVOS (ESCRITAS E DELEÇÕES) VAI SE REFLETIR NA RÉPLICA EM REDE. ASSIM, VOCÊ AINDA TEM QUE FAZER SEUS BACKUPS NORMAIS! ESTA SOLUÇÃO SERVE APENAS PARA PROVER UMA MANEIRA DE NÃO PERDER SEUS DADOS RECENTES QUE NÃO ESTEJAM NO SEU BACKUP POR ESTE AINDA NÃO TER SIDO FEITO NO MOMENTO DA FALHA!

Faça o ponto de montagem local para os sistemas de arquivo virtual e real em cada um dos servidores:

Atualize a fstab no fileserver acrescentando estas 2 linhas:

Se o software que você quer usar com o ChironFS tem instruções específicas sobre aumento dos limites de arquivos abertos, ou se você já sabe que vai ter uma grande quantidade de arquivos abertos simultaneamente, você TEM que ler Capítulo 6. Considerações acerca de Hash, descritores de arquivo e ulimit

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. Neste caso, o ChironFS loga o evento (se você montou com a opção recomendada --log). 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.

Neste ponto, você deve estabelecer sua política de monitoramento para ser reportado do evento. Voce pode usar qualquer software, como o logwatch, para este fim. A partir da versão 1.1, o ChironFS oferece outro meio de controlar a saúde do seu sistema de arquivos. Agora você tem a opção de montar um sistema de arquivos semelhante ao /proc para controlar o ChironFS, usando a opção de linha de comando --ctl <PATH> (ou -c <PATH>). O 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. O segundo arquivo, chamado "check_chironfs.sh", é um script shell para ser rodado como um plugin do nagios. Se você decidir usá-lo, não o copie para outro path, pois seu conteúdo muda dinamicamente e não vai funcionar em outro path Assim, suponha que sua fstab seja algo parecido com:

Se você desejar monitorar suas réplicas com o nagios, basta informar o nagios para rodar os scripts localizados em "/var/run/chironctl/_real1/check_chironfs.sh" e "/var/run/chironctl/_real2/check_chironfs.sh".

Você não pode mudar a propriedade nem os bits de permissão dos arquivos/diretórios neste sistema de arquivos. Para configurar quem pode acessá-lo, mude a propriedade do ponto de montagem ANTES de montá-lo. O ChironFS vai utilizar esta propriedade para todos os arquivos e diretórios abaixo dele.

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, supondo que sua fstab seja a mesma acima e a réplica que falhou (e foi desabilitada) seja /real2, use o sistema de arquivos de control para habilitá-la conforme abaixo:

Capítulo 6. Considerações acerca de Hash, descritores de arquivo e ulimit

As funções de hash correntemente sendo usadas são as funções de inteiros de 32 bits de Robert Jenkins tal como encontradas neste documento de Twang, apenas adaptado para linguagem C. As funções de mistura de 64 bits também foram pegas dali.

Em versões anteriores do ChironFS, o tamanho da tabela hash era igual ao parametro file-max do kernel. Agora foi diminuído para minimizar o uso de memória. Isto foi feito sem sacrificar a performance em vista da grande distribuição obtida com estas funções hash.

O parâmetro file-max do kernel é global para todo o sistema operacional e se todo o sistema de arquivos for ChironFSzado e usado um mínimo de duas réplicas, nós precisaríamos apenas 33% da velha tabela. Uma vez que as novas funções de hash têm uma distribuição muito superior e são muito boas até o uso de 80% do espaço dispoonível, eu decidi usar uma alocação proporcional ao file-max, usando a maior potência de 2 que seja inferior a 50% de file-max.

A estatística mostrou uma baixa taxa de colisão para para o uso de 50% da tabela (em torno de 18% de file-max na minha máquina, o que significa que, usando duas réplicas, eu estava usando 54% dos descritores de arquivo do sistema.

Estatísticas

Eu fiz um programa de teste de hash que simula alocações de descritores de arquivo e conta, para cada slot da tabela hash, o total de colisões, diretamente dos cálculos hash ou indiretamente quando, em função de uma colisão prévia, o sistem tentou alocar o próximo endereço e descobriu que este também já estava alocado.

Cada pixel do gráfico abaixo representa um endereço. Os brancos são slots livres, os verdes são alocados mas sem colisão. Os vermelhos são endereços com apenas uma colisão e os pretos são os que têm mais de uma colisão.

Eu teste com três tabelas: pequena, média e grande. A pequena é a que o ChironFS está usando e foi dimensionada para a maior potência de 2 que seja menor que 50% de file-max. A média foi dimensionada para o dobro da pequena. A grande é 4 vezes a média. Os testes foram feitos alocando 50% da pequena, 25% da média e 6,25% da grande. No meu sistema, o file-max é 365718. Então, a tabela pequena tem 128K descritores de arquivo, a média tem 256K e a grande 1M. As alocações totalizaram 64K descritores de arquivo.

Figura 1. Alocações na tabela pequena.

Figura 2. Alocações na tabela Média.

Figura 3. Alocações na tabela grande.

Assim, há uma taxa de colisão aceitável num grande número de arquivos abertos concorrentemente (64k ChironFS descritores de arquivo, usando um mínimo de 2 réplicas, significa 192k (53%) do limite de 360k do file-max).

Mas, a discussão não termina aqui. Após esta explicação acerca do gerenciamento de descritores de arquivo e empurrando eles para os limites, nós devemos considerar como o sistem trata estas coisas.

O ponto é que o parâmetro file-max do kernel é global para todo o sistema operacional. Mas o sistema limita a quantidade de arquivos abertos por processo também. Qunanso você monta o ChironFS, ele vai tentar aumentar os paramêtros do sistema para os valores necessários. Mas, ele vai ter sucesso somente se for executado como root! Se você rodar o ChironFS como usuário sem privilégios você vai ter que aumentar o máximo de arquivos abertos por processo. Como root, edite o arquivo /etc/security/limits.conf se certificando que ele tenha linhas como as abaixo, por exemplo. Ajuste o máximo de arquivos abertos para o usuário "www":

Note que você tem que se relogar para que as mudanças sejam válidas. Se você estivar em um terminal X, você tem que fechar sua sessão X, logar de novo e então abrir seu terminal X.

Atenção! Verifique a documentação do software que você pretende rodar usando o ChironFS. Por exemplo, se a documentação do seu software diz que você precisa de 3000 arquivos abertos e diz a você para mudar a configuração em /etc/security/limits.conf e o usuário que vai montar o ChironFS é um usuário sem privilégios (não root), você tem que configurar os limites deste usuário também, usando a seguinte fórmula: 2 * NF * NR + 6 (2 vezes a quantidade de arquivos vezes a quantidade de réplicas mais 6).

Por exemplo, para poder abrir 30000 arquivos replicados sobre 3 réplicas, você tem que configurar seu /etc/security/limits.conf para 180006 (2 * 30000 * 3 + 6). Então seu /etc/security/limits.conf, para o usuário "someuser", por exemplo, seria algo do tipo:

Enfim, isto é tudo para fazê-lo rodar apropriadamente. Agora, se você está curioso acerca do porquê fazer todos estes cálculos, as razões são:

• 1) cada arquivo aberto por um arquivo no ponto de montagem virtual faz o ChironFS abrir, em cada réplica, um descritor de arquivos é consumido para cada um;
• 2) multiplique tudo por 2 porque o ChironFS usa uma tabela has para armazenar os descritores de arquivo dos sistemas de arquivo reais e ela é dimensionada como uma potência de 2 e então, o ChironFS pega o valor de ulimit, seta todos os bits (o que vai, em quase todos os casos, resultar num valor maior que ulimit) e rotaciona para a direita (divide por 2) e, desta maneira, se pega um ulimit de 90000, ele vai dividir por 3, obtendo 30000, setar todos os bits e rotacionar, obtendo 16383 e sua aplicação vai ser limitada por este númeor, e não 30000. Então, multiplicar por 2 vai fazer o ChironFS terminar com um valor de 32767, o que vai garantir que sua aplicação poderá abrir os 30000 arquivos;
• 3) o 6 é para descritores de arquivos extra reservados para uso do ChironFS, tais como, por exemplo, o arquivo de log.

Capítulo 7. Suporte

Como nós estamos iniciando a publicação deste sistema, muitas coisas ainda têm que ser feitas. Este software é provido "Como está" e, então, envie-me um e-mail (coloque [CHIRONFS] no assunto) e eu vou TENTAR fazer o meu melhor para te dar o suporte. Agora, há uma lista de discussão, então, usuários também dispõem desta forma de solucionar seus problemas também.