Les versions récentes de RHEL / CentOS (EL6) ont apporté des changements intéressants au système de fichiers XFS dont je dépendais fortement depuis plus d'une décennie. J'ai passé une partie de l'été dernier à traquer une situation de fichier épars XFS résultant d'un backport de noyau mal documenté. D'autres ont eu des problèmes de performances malheureux ou un comportement incohérent depuis le passage à EL6.
XFS était mon système de fichiers par défaut pour les données et les partitions de croissance, car il offrait stabilité, évolutivité et une bonne amélioration des performances par rapport aux systèmes de fichiers ext3 par défaut.
Il y a un problème avec XFS sur les systèmes EL6 qui est apparu en novembre 2012. J'ai remarqué que mes serveurs affichaient des charges système anormalement élevées, même lorsqu'ils étaient inactifs. Dans un cas, un système non chargé afficherait une moyenne de charge constante de 3+. Dans d'autres, il y avait une bosse de charge 1+. Le nombre de systèmes de fichiers XFS montés semble influencer la gravité de l'augmentation de la charge.
Le système possède deux systèmes de fichiers XFS actifs. La charge est de +2 après la mise à niveau vers le noyau affecté.
En creusant plus profondément, j'ai trouvé quelques discussions sur la liste de diffusion XFS qui indiquaient une fréquence accrue du xfsaildprocessus assis dans l' état STAT D. Les entrées CentOS Bug Tracker et Red Hat Bugzilla correspondantes décrivent les spécificités du problème et concluent qu'il ne s'agit pas d'un problème de performances; seule une erreur dans le rapport de la charge du système dans les noyaux plus récents que 2.6.32-279.14.1.el6 .
WTF?!?
Dans une situation ponctuelle, je comprends que le rapport de charge peut ne pas être un gros problème. Essayez de gérer cela avec votre NMS et des centaines ou des milliers de serveurs! Cela a été identifié en novembre 2012 dans le noyau 2.6.32-279.14.1.el6 sous EL6.3. Les noyaux 2.6.32-279.19.1.el6 et 2.6.32-279.22.1.el6 ont été publiés au cours des mois suivants (décembre 2012 et février 2013) sans modification de ce comportement. Il y a même eu une nouvelle version mineure du système d'exploitation depuis que ce problème a été identifié. EL6.4 est sorti et est maintenant sur le noyau 2.6.32-358.2.1.el6 , qui présente le même comportement.
J'ai eu une nouvelle file d'attente de génération de système et j'ai dû contourner le problème, soit en verrouillant les versions du noyau dans la version antérieure à novembre 2012 pour EL6.3, soit en n'utilisant tout simplement pas XFS, en optant pour ext4 ou ZFS , avec une grave pénalité de performances pour l'application personnalisée spécifique exécutée au sommet. L'application en question s'appuie fortement sur certains des attributs du système de fichiers XFS pour tenir compte des lacunes dans la conception de l'application.
Derrière le site de la base de connaissances paywalled de Red Hat , une entrée apparaît indiquant:
Une charge moyenne élevée est observée après l'installation du noyau 2.6.32-279.14.1.el6. La moyenne de charge élevée est due au fait que xfsaild passe à l'état D pour chaque périphérique formaté XFS.
Il n'y a actuellement aucune résolution pour ce problème. Il est actuellement suivi via Bugzilla # 883905. Contournement du package du noyau installé vers une version inférieure à 2.6.32-279.14.1.
(sauf déclassement des noyaux pas une option sur RHEL 6.4 ...)
Nous avons donc plus de 4 mois dans ce problème, sans véritable correctif prévu pour les versions du système d'exploitation EL6.3 ou EL6.4. Il y a un correctif proposé pour EL6.5 et un correctif source du noyau disponible ... Mais ma question est:
À quel moment est-il judicieux de s'écarter des noyaux et des packages fournis par le système d'exploitation lorsque le responsable en amont a rompu une fonctionnalité importante?
Red Hat a introduit ce bogue. Ils devraient incorporer un correctif dans un noyau d'errata. L'un des avantages de l'utilisation des systèmes d'exploitation d'entreprise est qu'ils fournissent une cible de plate-forme cohérente et prévisible . Ce bogue a perturbé les systèmes déjà en production pendant un cycle de correctifs et réduit la confiance dans le déploiement de nouveaux systèmes. Bien que je puisse appliquer l'un des correctifs proposés au code source , est-ce évolutif? Il faudrait une certaine vigilance pour rester à jour au fur et à mesure que le système d'exploitation change.
Quelle est la bonne décision ici?
- Nous savons que cela pourrait éventuellement être corrigé, mais pas quand.
- La prise en charge de votre propre noyau dans un écosystème Red Hat a son propre ensemble de mises en garde.
- Quel est l'impact sur l'admissibilité au soutien?
- Dois-je simplement superposer un noyau EL6.3 fonctionnel sur des serveurs EL6.4 nouvellement construits pour obtenir la fonctionnalité XFS appropriée?
- Dois-je simplement attendre que cela soit officiellement résolu?
- Qu'est-ce que cela révèle sur le manque de contrôle que nous avons sur les cycles de publication de Linux d'entreprise?
- Compter sur un système de fichiers XFS depuis si longtemps une erreur de planification / conception?
Modifier:
Ce correctif a été intégré à la dernière version du noyau CentOSPlus ( kernel-2.6.32-358.2.1.el6.centos.plus ). Je teste cela sur mes systèmes CentOS, mais cela n'aide pas beaucoup pour les serveurs basés sur Red Hat.