Versões recentes do RHEL / CentOS (EL6) trouxeram algumas mudanças interessantes no sistema de arquivos XFS , das quais dependi bastante por mais de uma década. Passei parte do verão passado perseguindo uma situação de arquivo esparso do XFS resultante de um backport do kernel mal documentado. Outros tiveram problemas de desempenho ou comportamento inconsistente desde a mudança para o EL6.
O XFS era meu sistema de arquivos padrão para partições de dados e crescimento, pois oferecia estabilidade, escalabilidade e um bom desempenho ao longo dos sistemas de arquivos ext3 padrão.
Há um problema com o XFS nos sistemas EL6 que surgiu em novembro de 2012. Percebi que meus servidores estavam exibindo cargas de sistema anormalmente altas, mesmo quando ociosas. Em um caso, um sistema descarregado mostraria uma média de carga constante de 3 ou mais. Em outros, houve um aumento de carga superior a 1. O número de sistemas de arquivos XFS montados pareceu influenciar a gravidade do aumento de carga.
O sistema possui dois sistemas de arquivos XFS ativos. A carga é +2 após a atualização para o kernel afetado.
Indo mais fundo, eu encontrei alguns tópicos sobre a lista de discussão XFS que apontava para um aumento da frequência do xfsaildprocesso sentado no STAT D Estado. As entradas correspondentes do CentOS Bug Tracker e Red Hat Bugzilla descrevem as especificidades do problema e concluem que este não é um problema de desempenho; apenas um erro no relatório de carga do sistema em kernels anteriores a 2.6.32-279.14.1.el6 .
WTF?!?
Em uma situação pontual, entendo que o relatório de carga pode não ser muito importante. Tente gerenciar isso com o seu NMS e centenas ou milhares de servidores! Isso foi identificado em novembro de 2012 no kernel 2.6.32-279.14.1.el6 no EL6.3. Os kernels 2.6.32-279.19.1.el6 e 2.6.32-279.22.1.el6 foram lançados nos meses subsequentes (dezembro de 2012 e fevereiro de 2013) sem nenhuma alteração nesse comportamento. Houve até uma nova versão menor do sistema operacional desde que esse problema foi identificado. O EL6.4 foi lançado e agora está no kernel 2.6.32-358.2.1.el6 , que exibe o mesmo comportamento.
Eu tive uma nova fila de compilação do sistema e tive que solucionar o problema, bloqueando as versões do kernel na versão anterior a novembro de 2012 para EL6.3 ou simplesmente não usando o XFS, optando pelo ext4 ou ZFS , com uma severa penalidade de desempenho para o aplicativo personalizado específico em execução no topo. O aplicativo em questão depende muito de alguns dos atributos do sistema de arquivos XFS para explicar as deficiências no design do aplicativo.
Indo para o site de base de conhecimento paywalled da Red Hat , uma entrada aparece informando:
Alta média de carga é observada após a instalação do kernel 2.6.32-279.14.1.el6. A alta média de carga é causada pelo xfsaild entrando no estado D para cada dispositivo formatado em XFS.
No momento, não há resolução para esse problema. Atualmente, ele está sendo rastreado via Bugzilla # 883905. Solução alternativa Faça o downgrade do pacote do kernel instalado para uma versão inferior a 2.6.32-279.14.1.
(exceto fazer o downgrade de kernels não é uma opção no RHEL 6.4 ...)
Portanto, estamos com mais de 4 meses nesse problema, sem nenhuma correção real planejada para as versões do sistema operacional EL6.3 ou EL6.4. Existe uma correção proposta para o EL6.5 e um patch de fonte do kernel disponível ... Mas minha pergunta é:
Em que ponto faz sentido afastar-se dos kernels e pacotes fornecidos pelo SO quando o mantenedor upstream quebrou um recurso importante?
A Red Hat introduziu esse bug. Eles devem incorporar uma correção em um kernel de errata. Uma das vantagens do uso de sistemas operacionais empresariais é que eles fornecem um destino de plataforma consistente e previsível . Esse bug interrompeu os sistemas que já estavam em produção durante um ciclo de correção e reduziu a confiança na implantação de novos sistemas. Embora eu possa aplicar um dos patches propostos ao código-fonte , quão escalável é isso? Exigiria alguma vigilância para se manter atualizado conforme o sistema operacional muda.
Qual é o passo certo aqui?
- Sabemos que isso pode ser corrigido, mas não quando.
- O suporte ao seu próprio kernel em um ecossistema Red Hat tem seu próprio conjunto de advertências.
- Qual o impacto na elegibilidade do suporte?
- Devo apenas sobrepor um kernel EL6.3 em funcionamento nos servidores EL6.4 recém-criados para obter a funcionalidade XFS adequada?
- Devo apenas esperar até que isso seja consertado oficialmente?
- O que isso diz sobre a falta de controle que temos sobre os ciclos de lançamento do Linux corporativo?
- Confiar em um sistema de arquivos XFS por tanto tempo foi um erro de planejamento / design?
Editar:
Este emplastro foi incorporada no mais recente CentOSPlus libertação do kernel ( kernel-2.6.32-358.2.1.el6.centos.plus ). Estou testando isso nos meus sistemas CentOS, mas isso não ajuda muito nos servidores baseados no Red Hat.