Personnaliser les installations de logiciels

Effectué

Les modèles Azure CycleCloud facilitent la configuration des clusters HPC en faisant abstraction des détails d’implémentation de l’infrastructure sous-jacente, ce qui vous permet de vous concentrer sur la gestion des charges de travail. Cependant, cette charge de travail a généralement plusieurs dépendances liées aux logiciels, qui nécessitent des étapes de personnalisation supplémentaires. Heureusement, Azure CycleCloud fournit également une infrastructure pour implémenter ces étapes via sa prise en charge des tâches d’approvisionnement et de gestion de configuration appliquées directement aux nœuds du cluster.

Vos objectifs incluent le besoin de déployer des images personnalisées et d’utiliser des scripts de configuration développés en interne que vous utilisez dans votre environnement HPC local. Vous voulez déterminer comment vous pouvez utiliser les fonctionnalités d’Azure CycleCloud pour atteindre ces objectifs.

Comment implémenter la gestion de configuration avec Azure CycleCloud ?

Azure CycleCloud offre trois méthodes principales que vous pouvez combiner de façon arbitraire pour personnaliser le système d’exploitation et les logiciels sur les nœuds de cluster en fonction de vos propres exigences ou préférences :

• Images personnalisées
• Projets
• Cloud-Init

Comment utiliser des images personnalisées avec Azure CycleCloud ?

Azure CycleCloud prend en charge les nœuds de cluster exécutant les distributions Linux les plus courantes et, selon le planificateur, Windows Server. Les modèles intégrés sont préconfigurés avec les valeurs par défaut recommandées, mais vous êtes libre de choisir des images de la Place de marché Azure ou de provisionner des nœuds en fonction d’images personnalisées. Cette dernière option peut être préférable si vous voulez réduire le délai associé à la configuration post-déploiement du système d’exploitation et des dépendances supplémentaires de vos charges de travail HPC. Elle peut également être nécessaire pour répondre aux besoins liés à l’activité, à la sécurité ou à la conformité.

Les images personnalisées vous permettent d’avoir un contrôle total sur les logiciels préinstallés et sur la configuration initiale du système d’exploitation. Leur inconvénient principal est la surcharge de travail associée à la gestion de plusieurs images pour s’adapter à différentes combinaisons d’applications et de leurs versions, en particulier dans les scénarios de développement.

Comment utiliser des projets Azure CycleCloud pour l’installation de logiciels ?

Un projet Azure CycleCloud est une collection de fichiers que vous référencez lors de la définition de configurations de nœuds de cluster via des modèles. Les projets ont la structure de répertoires suivante :

\project
      |- project.ini
      |- blobs
      |- templates
      |- specs
      |      | 
      |    default
      |      |- cluster-init
      |            |- scripts
      |            |- files
      |            |- tests
      |      | - chef
      |            |- site-cookbooks
      |            |- data_bag
      |            |- roles

Le fichier project.ini contient les métadonnées du projet, notamment son nom, son étiquette, sa version et son type. Les types pris en charge sont « planificateur » et « application ». Le premier est utilisé pour installer et initialiser des démons de planificateur sur des nœuds principaux et des nœuds de calcul, tandis que le second définit des charges de travail de cluster.

Le répertoire « blobs » contient des objets blob du projet, comme des fichiers binaires pour un projet open source, qui peuvent être redistribués librement, et des objets blob d’utilisateur, qui doivent être exclus de la redistribution du projet en raison de contraintes de licence.

Le répertoire « templates » contient des modèles, tandis que le répertoire « specs » héberge des spécifications qui définissent les configurations à appliquer aux nœuds du cluster cible.

Remarque

Par exemple, un projet Slurm contient au minimum deux spécifications : une pour les nœuds principaux de planificateur et l’autre pour les nœuds de calcul.

Dans le répertoire « specs », il y a deux sous-répertoires nommés cluster-init et custom Chef. « Cluster-init » contient des scripts qui s’exécutent automatiquement sur le nœud cible. Les fichiers de données brutes qui sont copiés vers le nœud cible et des tests qui sont exécutés quand un cluster est démarré en mode test. Le sous-répertoire « custom Chef » contient des fichiers spécifiques à Chef, notamment des fichiers de définition de livre de recettes, de conteneur de données et de rôle. Vous pouvez utiliser les livres de recettes et les recettes de Chef pour la configuration des nœuds. Les spécifications de « cluster-init » sont mappées à des rôles et des livres de recettes Chef.

Remarque

Azure CycleCloud utilise Chef comme outil de gestion de configuration pour la préparation et la configuration de chaque nœud. CycleCloud utilise Chef en mode autonome, qui ne s’appuie pas sur un serveur Chef centralisé. Au lieu de cela, tous les livres de recettes destinés aux nœuds de cluster managés sont téléchargés depuis le coffre lors la phase de démarrage du système d’exploitation. À ce stade, Chef traite la liste des recettes définies dans les spécifications du cluster-init du nœud, en convertissant la machine virtuelle sous-jacente en un nœud HPC opérationnel.

Pour provisionner un cluster basé sur un projet, vous devez charger le contenu du projet dans un coffre Azure CycleCloud. Ensuite, chaque fois que le nœud cible démarre, il télécharge automatiquement les fichiers nécessaires du projet depuis le coffre et traite les spécifications nécessaires.

Comment utiliser cloud-init avec Azure CycleCloud ?

Azure CycleCloud prend en charge cloud-init comme méthode de configuration des nœuds de cluster lors de la phase de démarrage, avant l’application des spécifications relatives au projet. Ceci offre une méthode pratique pour prendre en charge les éventuelles dépendances liées à l’infrastructure ou aux logiciels, comme la configuration des paramètres réseau ou l’application des mises à jour du package de système d’exploitation.

Vous pouvez définir une configuration cloud-init en utilisant un modèle, mais il est possible de faire cela directement à partir de l’interface graphique d’Azure CycleCloud. Lors de la création ou de la modification d’un cluster, vous trouvez les paramètres appropriés sous l’onglet intitulé Cloud-init, où vous pouvez entrer les scripts pour chaque type de nœud.

Notes

Comme cloud-init s’exécute avant les spécifications de projet de CycleCloud, le planificateur et la configuration qu’Azure CycleCloud applique à un nœud peuvent remplacer les modifications apportées via cloud-init. Si vous devez être sûr que vos commandes s’exécutent après l’installation du planificateur, vous devez utiliser à la place les spécifications du projet Azure CycleCloud.