Récemment, un partenaire commercial de Corée du Sud nous a fait part d'un défi intéressant. Bien que l'Open iT ComputeAnalyzer propose des plug-ins et des connecteurs pour mesurer les environnements de calcul distribué, nous avons réalisé qu'il existait un potentiel inexploité.
ComputeAnalyzer se concentre principalement sur le système de calcul en grille et moins sur la durée d'exécution des tâches individuelles. Si cela fonctionne bien pour les travaux par lots qui sont mis en file d'attente pour des processus automatisés, les travaux interactifs sur le serveur IBM LSF sont différents. Ils exigent un retour d'information en temps réel et sont sujets à des oublis et à des pratiques inefficaces lorsque des humains interviennent. C'est exactement ce que le client voulait surveiller.
Alors qu'Open iT se spécialise dans le suivi et l'optimisation des licences, dans ce scénario, l'accent est mis sur les créneaux horaires. Ces créneaux s'ajoutent aux licences si les applications participant aux tâches les utilisent.
Le défi
Nos ingénieurs ont constaté que le client utilisait un autre type de travail - l'exécution de tâches interactives. Leur demande était simple : surveiller le niveau d'activité de ces tâches interactives dans l'environnement informatique en grille LSF et libérer un créneau de travail. Le serveur LSF réattribue alors les créneaux de travail inactifs à d'autres tâches.
Pour répondre aux besoins du client, les ingénieurs d'Open iT ont dû relever un double défi :
- Absence de collecteur de données dans les lancements d'applications en LSF
Dans un environnement Unix, le collecteur de données est conçu pour fonctionner comme un démon lorsqu'un utilisateur accède à une machine. Cette conception devient problématique dans les configurations où des planificateurs de tâches LSF sont utilisés pour lancer des applications.
En effet, les utilisateurs ne se connectent pas directement aux machines hébergeant les applications. Au lieu de cela, ils accèdent au serveur de calcul en grille de la LSF et choisissent l'application qu'ils souhaitent. Le serveur se charge alors d'allouer les ressources à partir d'un pool de tâches disponibles. Les fenêtres de l'application sont alors redirigées vers l'ID d'affichage de l'utilisateur qui a été utilisé lors de la sélection de l'application.
- Blocage de la réallocation par le démon dans les configurations préliminaires
LSF est livré avec une fonction de démarrage de tâches au niveau de la commande. Si nous l'utilisons pour exécuter le collecteur de données, un problème se pose. Le binaire reste actif même après la fermeture de l'application par l'utilisateur. Ce comportement donne l'impression que les emplacements de travail sont toujours utilisés, ce qui empêche LSF de réaffecter les ressources matérielles nécessaires.
Solutions proposées pour une meilleure fonctionnalité
Après avoir examiné les défis posés, notre équipe d'ingénieurs a proposé les solutions raffinées suivantes :
- Intégration du collecteur de données avec LSF_JOB_STARTER
Comme nous l'avons vu précédemment, la variable LSF_JOB_STARTER offre une voie prometteuse pour les clients. Bien que cette approche nécessite l'expertise d'Open iT pour adapter la configuration LSF du client, elle promet une opération plus efficace. En adoptant cette approche, le collecteur de données démarrera de manière transparente avant chaque travail, en s'alignant sur le niveau d'utilisateur et la variable d'affichage corrects.
- Incorporation d'un mécanisme d'autodestruction
Cette fonction d'autodestruction consiste à ajouter de l'intelligence au démon, ce qui lui permet de s'arrêter de manière élégante lorsque c'est nécessaire. Il s'agit donc d'une réponse directe au deuxième défi.
Les ingénieurs ont proposé au client trois façons différentes de configurer la capacité d'auto-terminaison :
- Bind: Cette fonction surveille activement les applications qu'un utilisateur lance habituellement. S'il détecte qu'aucune de ces applications n'est en cours d'exécution, le collecteur de données s'arrête rapidement, libérant ainsi le créneau de travail occupé pour d'autres tâches.
- Queue: Cette fonction recherche activement les activités liées à l'utilisateur. À l'aide d'une liste configurable, elle peut être configurée pour contourner intentionnellement certains processus, les paramètres par défaut excluant généralement Open iT et plusieurs autres tâches liées au système.
- Affichage: Déclenche l'auto-termination si le collecteur de données ne parvient pas à se connecter à l'écran de l'utilisateur désigné.
Succès du mécanisme de liaison
Suite au retour d'information de notre partenaire commercial, notant la prévalence de l'utilisation de ce type de tâches en Corée du Sud, Open iT a donné la priorité au développement pour supporter cet environnement de calcul distribué (grid computing). Après une évaluation rigoureuse de divers scénarios et solutions potentielles, il est apparu clairement que la tâche de liaison était la solution idéale.
Cette approche a permis au client de collecter efficacement des données dans le cadre de sa grille de calcul LSF. Notre partenaire commercial a rapidement confirmé qu'Open iT était désormais entièrement équipé pour optimiser les travaux interactifs en LSF.
Des solutions sur mesure pour une gestion optimale des actifs logiciels
Chez Open iT, notre engagement va au-delà de la simple optimisation des actifs logiciels. Nous sommes fiers de concevoir des capacités et des solutions sur mesure qui s'alignent sur les besoins distincts de nos clients.
Nos ingénieurs chevronnés collaborent avec les services informatiques de nos clients, en veillant à co-créer et à mettre en œuvre des stratégies qui leur permettent d'atteindre leurs objectifs commerciaux et d'amplifier le rendement de leurs licences logicielles.
Contactez dès maintenant un représentant d'Open iT et découvrez comment nous pouvons apporter des avantages similaires à votre organisation.
