Chronologiquement, le travail a commencé par une exploration exhaustive des fonctionnalités du produit. Cette expertise a permis de mettre en place une formation interne, initialement auprès d’un groupe de travail restreint, puis dans un deuxième temps à toute personne du CC.

Parallèlement, un premier cluster dit de développement été configuré afin de permettre la mise au point des ‘hooks’ d’adaptation à nos besoins. La gestion des tokens AFS, la régulation des flux de jobs, le contrôle de l’espace disque consommé, le traitement des jobs parallèles, l’adaptation à la grille de calcul (computing element) sont quelques uns des chantiers que nous avons dû traiter. Le mot « chantier » exprime bien l’investissement que chaque point a nécessité au regard des services impliqués et impactés. En effet, la mise en œuvre d’un nouveau système de batch consiste aussi à trouver le meilleur équilibre entre les méthodes de travail existantes et validées au cours du temps et de nouvelles possibilités offertes par le produit.

Au cours de l’automne 2010, un nouveau cluster dit de pré-production a été installé. Il intégrait les premières adaptations réalisées. La finalité de ce cluster était de permettre à des utilisateurs volontaires d’adapter leur production de calculs au nouveau système. L’intérêt était de bénéficier de leur retour d’expérience pour valider nos choix et adaptations réalisées. Leur aide a été très précieuse et nous les remercions vivement pour leur implication.

Au delà des adaptations fonctionnelles, nous avons entrepris de nombreux tests. Une première phase, démarrée en octobre 2010, avait pour but de définir les contours de notre installation (serveurs, base de données, système de fichiers, réseau, etc) et d’affiner notre compréhension du produit. Ces essais nous ont aussi permis de confirmer notre intuition quant à la qualité du logiciel, comme le montre l’exemple suivant (fig 1).

Evolution de la vitesse de soumission (qsub) en fonction du nombre de jobs soumis.

Au delà des chiffres, toujours impressionnant, noter l’excellent comportement en fonction de la charge, indicateur d’une bonne implémentation du logiciel.

Une deuxième phase de tests a été conduite au cours du premier trimestre 2011. Elle avait pour but de valider la configuration et de prédire, aussi précisément que possible, le comportement du produit avec une charge de traitement la plus proche de la production réelle. Parmi les essais réalisés, nous avons soumis l’intégralité de la « machinerie batch » à un flux de jobs intensif et permanent avec plus de 50.000 jobs traités /heure, sur une période de 72h (fig 2).

Un des nombreux tests de charges, exécuté sur le cluster définitif (futur cluster de production) et ayant pour objet de vérifier le comportement global du système soumis à un flux intensif de jobs.

Pour mémoire, en production nous traitons en moyenne 13,000 jobs simultanément pour un flux d’environ 100,000 jobs /jour, les chiffres de ce test vont bien au delà.

Ces essais n’ont révélé ni dysfonctionnement, ni point de contention, que ce soit du coté des serveurs, que de celui des codes d’adaptation à nos spécificités. Avec Grid Engine, nous pourrons aborder sereinement les demandes de calcul toujours croissantes. Pour mémoire, nous traitons actuellement 13.000 jobs simultanément et un flux d’environ 100.000 jobs/jour. Mais la mise en production imminente de la nouvelle salle machine va largement amplifier ces chiffres, et bien que le système de batch actuel, BQS, affiche un excellent comportement, il convient, en informatique comme ailleurs, de toujours garder une longueur d’avance sur les demandes des utilisateurs.

L’ouverture en production du cluster Grid Engine est prévue au cours du mois de mai 2011, avec comme objectif le basculement complet de BQS vers Grid Engine avant la fin de l’année. Ainsi 2011 s’achèverait par l’arrêt définitif de notre système de batch historique, après 18 ans de « bons et loyaux services » : Bonne retraite BQS !

Bernard CHAMBON