Guide pratique pour optimiser des grids HPC

Cadre stratégique et technique basé sur des projets réels.

• Identification des goulots d'étranglement
• Bonnes pratiques en scheduling
• Optimisation des files d'attente
• Monitoring avancé

Un grid HPC qui fonctionne n'est pas pour autant un grid HPC efficace. Dans la banque et l'assurance, les clusters de calcul grossissent pendant des années à force d'ajouter des nœuds et des files d'attente, et il arrive un moment où le coût par tâche augmente, où les fenêtres de clôture se resserrent et où personne ne sait avec certitude où se perd le temps. Ce guide résume le cadre que nous appliquons sur des projets réels de grid sur IBM Spectrum Symphony, TIBCO DataSynapse et clusters hybrides avec extension vers le cloud.

L'ordre compte : mesurer d'abord, planifier ensuite, puis affiner les files d'attente et, seulement à la fin, ajouter de la capacité. Dans la plupart des environnements que nous avons audités, la capacité n'était pas le problème ; la répartition l'était.

1. Identification des goulots d'étranglement

Avant de toucher à la configuration, il faut savoir ce qui freine le grid : le CPU, la mémoire, les entrées/sorties, le réseau ou la logique même des tâches. Les symptômes sont généralement les mêmes (des fenêtres qui s'allongent, des nœuds inactifs pendant que d'autres saturent, des tâches relancées), mais la cause change d'un environnement à l'autre.

• Profiler séparément les tâches les plus longues et les plus fréquentes : elles ne coïncident pas toujours et s'optimisent rarement de la même façon.
• Mesurer l'utilisation réelle par nœud et par file d'attente dans la fenêtre critique, et non la moyenne quotidienne.
• Localiser les dépendances de données (bases de données, fichiers partagés, services externes) qui sérialisent le travail.
• Distinguer le temps de calcul du temps d'attente en file et du temps de transfert des données.

2. Bonnes pratiques de scheduling

L'ordonnanceur décide quelle tâche s'exécute sur quel nœud et à quel moment. Une politique de scheduling mal réglée gaspille de la capacité même quand le matériel est excédentaire : des priorités qui se chevauchent, des réservations que personne n'utilise et des tâches courtes bloquées derrière des tâches longues.

• Définir les priorités à partir du calendrier métier (clôtures, reporting réglementaire) et non de qui demande en premier.
• Regrouper les tâches par profil de ressources pour que l'ordonnanceur puisse les empaqueter sans fragmenter les nœuds.
• Limiter les relances automatiques et consigner leur cause : une relance silencieuse est un problème caché.
• Revoir la politique de préemption : utile pour les pics réglementaires, coûteuse si elle se déclenche tous les jours.

3. Optimisation des files d'attente

Les files d'attente sont l'endroit où s'accumule la dette opérationnelle : créées pour un projet et jamais retirées, elles se chevauchent et finissent par se disputer les mêmes nœuds. Simplifier est presque toujours le premier gain.

• Consolider les files au profil identique et retirer celles qui n'ont reçu aucun travail depuis des semaines.
• Dimensionner les limites par file à partir de la demande mesurée, avec une marge pour les pics connus.
• Séparer les charges interactives des charges batch pour que les premières n'attendent pas derrière les secondes.
• N'étendre vers le cloud que la file qui subit le pic, avec des nœuds qui s'éteignent une fois le travail terminé (cloud bursting).

4. Supervision avancée

Sans métriques continues, chaque optimisation est une opinion. La supervision doit couvrir l'ensemble du grid (files d'attente, nœuds, tâches et données) et être reliée à des alertes qui anticipent le problème, au lieu de le confirmer.

• Séries temporelles d'utilisation, de temps d'attente en file et de taux d'échec par file et par application.
• Alertes fondées sur la tendance (une fenêtre qui s'allonge trois jours de suite) et pas seulement sur un seuil.
• Tableaux de bord partagés entre l'exploitation, les métiers et l'audit : le même chiffre pour tous.
• Traçabilité de chaque exécution (version, paramètres, nœud, durée) comme preuve auprès du superviseur.