Décrire les modèles de cluster Azure CycleCloud

Effectué

Azure CycleCloud fournit un déploiement de clusters HPC basé sur des modèles. Par défaut, l’application Azure CycleCloud inclut plusieurs modèles intégrés pour déployer les planificateurs de cluster les plus courants, notamment Slurm, PBSPro, LSF, Grid Engine et HT-Condor. Les dépôts GitHub d’Azure CycleCloud offrent de nombreux projets spécifiques aux planificateurs, que vous pouvez personnaliser et importer dans votre instance Azure CycleCloud. Vous avez également la possibilité d’implémenter un provisionnement basé sur des modèles pour vos propres planificateurs développés en interne en utilisant des plug-ins de mise à l’échelle automatique CycleCloud.

Les modèles facilitent l’implémentation d’un large éventail de fonctionnalités d’Azure CycleCloud, notamment la prise en charge d’images de machine virtuelle personnalisées, de la mise à l’échelle automatique et des machines virtuelles spot. Ils réduisent également la surcharge de travail associée au provisionnement et à la maintenance de plusieurs déploiements de clusters configurés de façon identique, généralement utilisés pour isoler les environnements de production, de développement et de test.

Ces avantages s’alignent sur vos objectifs pour l’implémentation du nouveau cluster résidant dans Azure pour Contoso. Pour optimiser l’étendue de ces avantages, vous décidez d’en savoir plus sur le format et le processus d’implémentation des modèles Azure CycleCloud.

Quel est le format des modèles Azure CycleCloud ?

Les modèles sont des fichiers au format INI qui utilisent la syntaxe déclarative pour décrire la structure et la configuration d’un cluster CycleCloud, notamment les rôles des nœuds du cluster et leurs relations respectives. Les modèles sont constitués de sections nommées, avec des en-têtes désignés par une ou plusieurs paires de crochets. Les sections forment une hiérarchie, qui correspond à la hiérarchie des objets du cluster et de leurs paramètres correspondants. Le nombre de crochets représente un niveau dans cette hiérarchie, qui augmente de façon séquentielle avec chaque niveau.

[cluster]
  [[node, nodearray]]
    [[[volume]]]
    [[[network-interface]]]
    [[[cluster-init]]]
    [[[input-endpoint]]]
    [[[configuration]]]
[environment]
[noderef]
[parameters]
  [[parameters]]
    [[[parameter]]]

La section [cluster] peut contenir une ou plusieurs sections [[node]], qui peuvent contenir plusieurs sections [[[volume]]]. De façon similaire, dans le même modèle, dans la section [cluster], vous pouvez définir une ou plusieurs sections [[nodearray]], chacune avec sa propre [[[configuration]]].

Notes

L’ordre des sections dans le même niveau est arbitraire.

Quelles sont les principales sections d’un modèle ?

Un modèle est constitué des sections principales suivantes :

• Cluster : La section [cluster] contient une définition d’un objet de cluster Azure CycleCloud. Un modèle doit inclure au moins une section [cluster], qui contient une ou plusieurs sections [[node]] et [[nodearray]] décrivant les objets enfants de ce cluster.
• Nœud : Ceci représente une machine virtuelle provisionnée par la plateforme.
• Nodearray : Ceci représente un ou plusieurs groupes de machines virtuelles identiques Azure.

Remarque

Les clusters comprennent des nœuds qui prennent en charge leurs rôles désignés dans le traitement des charges de travail en cluster. Du point de vue de l’implémentation, Azure CycleCloud s’appuie sur Azure Resource Manager pour les provisionner en tant que machines virtuelles Azure individuelles ou en tant que membres d’un groupe de machines virtuelles identiques. Ce dernier représente une collection de machines virtuelles configurées de façon identique et qui, contrairement aux machines virtuelles Azure, prennent en charge la mise à l’échelle horizontale. Azure CycleCloud utilise des groupes de machines virtuelles identiques pour implémenter des groupes de nœuds. La section [[node]] décrit les propriétés des machines virtuelles sous-jacentes provisionnées par la plateforme, qui peuvent être une machine virtuelle Azure autonome ou appartenir à un groupe de machines virtuelles identiques Azure. La section [[nodearray]] décrit un groupe de machines virtuelles identiques Azure.

Notes

Un groupe de nœuds peut être constitué de plusieurs groupes de machines virtuelles identiques Azure, chacun comprenant des machines virtuelles configurées différemment. Cependant, tous les nœuds d’un groupe de nœuds jouent le même rôle dans le cluster, par exemple fournir des ressources à une file d’attente du planificateur de cluster.

• Volume définit un disque managé Azure qui doit être attaché à des nœuds de cluster individuels ou à des nœuds formant un groupe de nœuds. C’est un objet enfant d’un nœud ou d’un objet nodearray.
• Network-interface définit une interface réseau Azure qui doit être attachée à des nœuds de cluster individuels ou à des nœuds formant un groupe de nœuds. C’est un objet enfant d’un nœud ou d’un objet nodearray.
• Configuration définit les propriétés configurables d’un nœud ou d’un groupe de nœuds. C’est un objet enfant d’un nœud ou d’un objet nodearray.
• cluster-init définit les spécifications du projet Azure CycleCloud à appliquer à un nœud de cluster. Un projet est une collection de ressources, qui définit des configurations de nœud sous la forme de spécifications de projet. Quand un nœud démarre, il est automatiquement configuré en traitant ces spécifications. Cluster-init est un objet enfant d’un nœud ou d’un objet nodearray.
• Environment définit un déploiement Azure Resource Manager, qui provisionne ou modifie des ressources Azure à utiliser par le cluster. C’est un objet de plus haut niveau facultatif.
• Noderef référence un nœud dans le modèle pour exprimer des dépendances de ressources. C’est un objet de plus haut niveau facultatif.
• Parameters vous permet de rendre un modèle portable ; vous pouvez ainsi l’utiliser pour le déploiement de plusieurs clusters avec la hiérarchie d’objets correspondante, mais avec des paramètres de configuration différents. C’est un objet de plus haut niveau facultatif, mais vous avez la possibilité de créer une hiérarchie de paramètres imbriqués. Pour chaque paramètre, vous pouvez définir sa valeur par défaut. Les paramètres vous permettent également d’exposer des variables configurables dans un cluster via l’interface web de CycleCloud.

Chaque section contient plusieurs paires clé-valeur qui fournissent des détails de configuration sur l’objet correspondant, représenté par l’en-tête de la section. Par exemple, pour un objet nodearray, ces détails peuvent inclure la clé ImageName avec la valeur désignant l’image de machine virtuelle Azure à utiliser pour ses nœuds ou la clé Azure.MaxScalesetSize dont la valeur spécifie la taille maximale autorisée du groupe de machines virtuelles identiques. De façon similaire, les sections node ou nodearray peuvent inclure une ou plusieurs sections [[[configuration]]].

Comment provisionner un cluster basé sur un modèle ?

Après avoir identifié le modèle que vous prévoyez d’utiliser pour provisionner un cluster Azure CycleCloud, vous pouvez appliquer une des méthodes d’implémentation suivantes :

• Utilisez la CLI d’Azure CycleCloud pour importer le modèle dans votre application Azure CycleCloud, puis utilisez l’interface graphique de l’application pour approvisionner le cluster. Pour déclencher l’importation, exécutez la commande cyclecloud import_template -f <template_file> (où l’espace réservé <template_file> représente le nom du fichier contenant le modèle). Si le modèle contient plusieurs définitions de cluster, spécifiez le nom du cluster que vous voulez importer en le référençant comme valeur du paramètre -c.
• Utilisez la CLI d’Azure CycleCloud pour importer le modèle dans votre application Azure CycleCloud, puis pour approvisionner le cluster. Pour déclencher l’importation, exécutez la commande cyclecloud import_template -t -f <template_file> (où l’espace réservé <template_file> représente le nom du fichier contenant le modèle). Une fois l’importation terminée, exécutez la commande cyclecloud create_cluster. Par exemple, pour créer un cluster nommé lab-cluster à partir d’un modèle importé nommé lab-template, vous exécuterez cyclecloud create_cluster lab-template lab-cluster.
• Utilisez l’interface CLI d’Azure CycleCloud pour provisionner le cluster sans importer explicitement le modèle. Pour déclencher l’importation, exécutez la commande cyclecloud import_cluster.

Quelle que soit la méthode choisie, vous devez fournir les valeurs des paramètres nécessaires lors du provisionnement du cluster. Quand vous utilisez l’interface CLI d’Azure CycleCloud, vous pouvez les fournir en référençant un fichier de paramètres au format JSON.

Notes

Le fichier se compose de paires clé-valeur, où la clé représente le nom du paramètre. Pour vérifier le format d’un cluster existant, utilisez la commande cyclecloud export_parameters <cluster_name> > params.json, où l’espace réservé <cluster_name> représente le nom du cluster existant.

Notes

Avant de déployer un cluster basé sur un modèle importé, vous devez également charger le contenu du projet correspondant dans un coffre Azure CycleCloud. Pour effectuer un chargement, utilisez la commande CLI cyclecloud project upload <locker_name> d’Azure CycleCloud (où l’espace réservé <locker_name> représente le nom du coffre). Pour lister les coffres disponibles, exécutez la commande CLI cyclecloud locker list d’Azure CycleCloud. Le nom du coffre est référencé dans la section [[[cluster-init]]].

Notes

Une des étapes de la configuration d’une installation Azure CycleCloud est la création d’un conteneur d’objets blob dans un compte de stockage Azure. Ce conteneur sert de coffre utilisé par le serveur CycleCloud pour organiser les projets CycleCloud pour les nœuds de cluster. Par la suite, les nœuds des clusters managés par Azure CycleCloud sont configurés pour télécharger des projets CycleCloud à partir de ce coffre dans le cadre de leur processus de démarrage.