Ralentissement incompréhensible lors de l’écriture sur disque

(image « Seagate ST33232A hard disk inner view » par Eric Gaba, Wikimedia Commons user Sting, CC BY-SA 3.0)

Dans la structure dans laquelle je travaille, nous disposons de SAN. Ce sont de « simples » serveurs mais un peu adaptés à nos besoins de stockage :

  • 8 cœurs, pas trop rapides (ce n’est pas nécessaire)
  • entre 8 et 16Go de RAM (on aurait du en prendre beaucoup plus, au prix auquel on l’achète)
  • de 8 disques (pour le plus petit) à 24 disques (pour le plus gros)
  • RAID 1 pour l’OS
  • RAID 5 ou 6 pour les données

L’OS est un Open-E DSS v6. Pourquoi choisir Open-E DSS? Plusieurs raisons :

  1. basé sur GNU/Linux
  2. intègre une interface web relativement correcte
  3. était supporté, à l’époque, par notre revendeur matériel, que nous connaissons bien et qui pouvait nous fournir du conseil si nécessaire
  4. prix abordable
  5. fonctionnalités adaptées à nos besoins

Là n’est pas la question. C’était un très bon choix à l’époque. Va-t’il le rester? C’est une question encore en suspens : par exemple, notre revendeur matériel ne le propose plus.

Puis nous avons commencé à rencontrer des problèmes. De très forts ralentissements lors des écritures sur disque. Nous avons résolu ce problème. Comment? Nous avons le voir.

Symptômes

Comme toujours, lorsque le système d’informations est malade, il faut le traiter de la même manière que le font les médecins(et 2). Quels sont les symptômes?

  • le ralentissement se fait sentir uniquement lors des écritures.
  • Nous n’avons pas ressenti de ralentissement lors des lectures. Est-ce que cette dernière information est pertinente? Pas sûr : la lecture est relativement peu sollicitée.
  • le ralentissement se ressent uniquement lors de l’écriture de gros volumes de données : plusieurs centaines de Mo. Lorsque peu de données sont écrites, aucun ralentissement n’est ressenti.
  • la ralentissement est ressenti (subjectif ; constaté par l’utilisateur) mais aussi mesuré (objectif donc!) :
    • les sauvegardes sur le SAN sont beaucoup beaucoup plus lentes : ceci est mesuré sur les outils de sauvegarde
    • la charge moyenne (load average) monte très fortement lors de l’écriture de gros volumes de données : ceci est mesuré sur les graphiques de supervision mais aussi sur les propres graphiques générés par l’interface Open-E DSS
    • les écritures sur disque sont moins nombreuses qu’auparavant, durant les périodes de forte écriture (les sauvegardes) : ceci est mesuré en comparant les graphiques du nombre d’écritures sur disque « avant » et « après ».
  • le ralentissement est beaucoup plus violent lors des écritures en parallèle. La charge moyenne augmente plus rapidement et plus fortement.
  • chose étonnante : la charge moyenne monte jusqu’à atteindre toujours la même valeur (à peu de chose près) : un peu plus de 60. Cela semble correspondre aux nombres de processus lancés par les services qui lisent/écrivent sur les disques. L’interface web Open-E DSS fournit plusieurs chiffres sur les processus fonctionnant pour chaque service : NFS, SMB/CIFS, … Le total de ces chiffres est cohérent avec la load. Attention : la load n’est pas cohérente avec le nombre de processus total du système, qui lui est autour de 300.
  • la charge des CPU est quasi nulle, depuis le début de l’utilisation du SAN. Un doute est permis sur les valeurs remontées.
  • la charge réseau est moins importante que par le passé.
  • Multiplier le nombre d’écritures en parallèle n’augmente pas le taux d’écriture sur disque ni la charge réseau.
  • pas de mise à jour de l’OS depuis plusieurs semaines.
  • aucune modification sur la configuration du SAN n’a été faite depuis plusieurs semaines.

Diagnostique

Mon instinct me dit : « cela vient très probablement des disques. Possiblement des cartes réseaux ou des câbles réseaux ou du switch de stockage mais avec un gros doute. Ou d’un bug sur Open-E DSS ». Comment identifier l’origine précise de notre ralentissement? En regardant les outils d’administration de la carte RAID :

  • rien dans l’outil de supervision : pas d’alerte
  • rien dans la page d’accueil de l’interface d’administration de la carte RAID
  • rien dans le détail du statut de chaque disque physique : tous fonctionnent correctement
  • pas de reconstruction RAID qui échouerait constamment et qui recommencerait depuis le début

Bon, ça ne vient pas de la carte RAID ni des disques.. Alors? Cherchons du côté réseau :

  • câbles réseaux en excellent état, bien branchés, pas de perturbation
  • interfaces réseaux utilisées à 30/40% de leur capacité depuis le début, rien de significatif
  • switch qui s’ennuie fortement : charge CPU quasi nulle, pas de pics, peu d’interfaces utilisées par rapport au nombre total, rien dans les logs, …

Aïe : si cela vient d’un bug sur Open-E, nous allons souffrir.

Tiens, étonnant. Un premier SAN a rencontré ce problème. Puis quelques semaines après, un autre. Puis quelques semaines plus tard, encore un autre. Au 3e, je reçois en même temps un mail d’Open-E : « migrer vers la toute dernière version d’Open-E DSS, plus géniale, plus mieux, plus performante, N% de remise immédiate si vous achetez avant la fin de l’année afin que je puisse remplir mes objectifs de vente et dire à mes actionnaires que j’ai fait une bonne année ». Quelques jours auparavant, j’ai vu un reportage sur l’obsolescence programmée… Une idée germe dans ma tête… Je m’y refuse : ce serait beaucoup trop gros. D’autres l’auraient constatée, beaucoup plus vite que moi, vu notre cas d’utilisation relativement léger. Impossible! Mais qu’il est difficile de retirer cette idée de ma tête!!!

« Check the logs Luke »

(à faire avec une voix d’outre-tombe, lorsque vous avez un sabre laser à la main)

Merci maman. Grâce à toi, j’ai retenu la phrase : « il y en a toujours plus dans deux cerveaux que dans un seul ». La vérification de toutes les logs fournies par le SAN m’a été conseillée par… mon alternant. Mon padawan et mon mon maître Jedi! J’ai toujours considéré qu’on était plus fort à plusieurs que tout seul. Et que ce n’est pas parce que je suis plus expérimenté et avec un plus grand diplôme et plus svelte et plus beau et plus musclé et avec un plus gros… heu.. C.V. que tu n’as pas une petite leçon à recevoir par un « padawan » (c’est dit amicalement). Bien m’en a pris.

J’ai donc récupéré toutes les logs du SAN et j’ai tout regardé. J’insiste sur « toutes les logs » : le SAN fournit dans son interface une liste de messages dans une sous-partie appelée « Logs ». Non seulement cette partie de l’interface est vraiment pourrie mais en plus, bien peu de messages sont affichés.

À la recherche du message perdu

Récupérer toutes les logs prend déjà 5 bonnes minutes. Le fichier compressé contenant toutes les logs prend plusieurs dizaines de Mo. Faites le calcul pour les fichiers non compressés. Estimez ensuite le temps pour parcourir toutes les logs, méticuleusement, afin identifier un message qui pourrait vous mettre sur une piste. Après 2 heures, je décide de changer de tactique : si on ne comprend pas pourquoi le patient fait une crise cardiaque, faisons en sorte qu’il en ai une pour pouvoir exactement constater ce qui se passe à ce moment là! Un tactique préconisée par Dr House. Non ,ce n’est pas grave si le SAN fait une crise cardiaque, je suis là pour le choquer… Au cas où… Bref, merci Dr House!

  1. mettons en place tous les indicateurs « temps réel » qui vont nous aider dans le diagnostique
  2. saturons le SAN pendant 5 minutes
  3. regardons tous les indicateurs évolués pendant ce temps
  4. récupérons les logs
  5. analysons uniquement les 7 dernières minutes (prendre plus large, au cas où).

Message obscure identifié au fin fond d’un fichier de log improbable : « les disques sont trop lents, je ralentis l’écriture ». Bien entendu, le message était en anglais et un peu moins clair. C’est donc confirmé : le problème vient des « disques ». Il faut creuser de ce côté.

Tiens… C’est quoi déjà une BBU?

Revenons sur les outils d’administration de la carte RAID. Tiens, je ne suis pas allé dans ce menu. C’est quoi déjà une BBU? Ha… La Battery Backup Unit est morte. Mais pourquoi la carte RAID ralentit? C’est quoi déjà une BBU?

Révisons les bases sur les cartes RAID

Une carte RAID ne fait pas que gérer le RAID. Elle met en cache, dans sa mémoire vive, les données les plus utilisées et les instructions d’écriture. Lorsqu’il y a beaucoup d’écritures simultanées, le cache permet d’optimiser celles-ci en :

  1. les plaçant en cache et en informant tout de suite l’OS que l’écriture est réalisée sur disque alors qu’elle ne l’est pas
  2. en agrégeant les écritures sur disques pour les réaliser en une seule opération contenant plusieurs écritures (plutôt que plusieurs petites opérations d’écriture), chaque opération nécessitant un délai important pour communiquer avec le disque
  3. en réorganisant l’ordre des écritures s’il n’y a pas de conflit, là encore pour optimiser les écritures.

Les algorithmes sont évidemment plus complexes, mais le but de l’article n’est pas de présenter ce sujet précis.

Comme les données sont stockées en mémoire vive et ne sont pas écrites sur le disque, une panne d’alimentation électrique peut amener à une perte des données alors que l’OS est persuadé d’avoir écrit les données sur les disques. Très gênant! Pour éviter cela, une mini-batterie (la BBU) est associée à la carte RAID : lors d’une panne électrique sur le serveur, la carte RAID est toujours alimentée par cette mini-batterie.

Si la batterie est morte? Cela dépend de la configuration de la carte RAID. Vous pouvez choisir dans la configuration entre :

  1. sécurité : si pas de batterie, alors chaque opération d’écriture doit être faite immédiatement, quitte à perdre en performance.
  2. performance : on optimise le plus possible, quitte à perdre des données lors d’une panne électrique.
  3. équilibrée : savant mélange entre optimisation et sécurité.

Nos cartes RAID étaient toutes configurées en mode « sécurité ». Les BBU respectives de nos SAN sont mortes les unes après les autres. D’où les ralentissements.

 Ce que nous avons loupé

La panne de la BBU est passée inaperçue pendant une durée relativement longue. Comment faire pour que cela ne se reproduise plus? La réponse est toujours la même : superviser la BBU! Évidemment! Cela n’avait pas été fait car :

  • la sonde de supervision ne le permet pas (oui : changer la sonde ; merci la GPL)
  • l’interface d’administration n’affiche pas de manière évidente la panne en page d’accueil
  • l’interface d’administration n’affiche pas de manière évidente la panne sur les autres pages, sur lesquelles la panne a un impact certain
  • l’outil d’administration en ligne de commande n’affiche, là aussi, pas d’information suffisamment claire
  • le manque de formation (je n’ai jamais appris quoi que ce soit sur les cartes RAID durant mes 5 années de formation, en dehors d’une présentation par un collègue étudiant qui avait voulu faire ça, de lui-même, presque contre l’avis de nos professeurs qui jugeaient cela peu pertinent)
  • le manque d’auto-formation : il est évident que ce n’est qu’après cette panne que j’ai recherché plus d’informations sur les cartes RAID. Dommage!

Il ne reste plus qu’à faire ce travail de révision pour :

  • les SAN
  • les versions de RAID
  • les filesystem
  • le protocole ISCSI
  • le protocole NFS
  • le protocole SMB
  • la sécurisation de ses protocoles
  • la réplication de données inter-SAN
  • les snapshots du SAN

Une fois ceci fait, nous pourrons passer aux autres sujets :

  • DNS, DNSSEC
  • IPv4
  • IPv6
  • DHCP
  • plan d’adressage
  • les parefeux
  • la virtualisation
  • les onduleurs (watt? VA? puissance? online?)

La vie est belle : tellement de choses à apprendre, à approfondir, en si peu de temps!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *