Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Dans CycleCloud, le terme cluster décrit un groupe d’ordinateurs connectés (nœuds) fonctionnant ensemble en tant que système unique. Les clusters peuvent être imbriqués. Par exemple, un cluster de calcul constitué d’un nœud principal du planificateur de moteur de grille et de nœuds de calcul peut monter un cluster BeeGFS composé de plusieurs métadonnées et serveurs de stockage. Les groupes de calcul et de stockage se regroupent au sein d'un ensemble HPC parent unique.
Nœuds et tableaux de nœuds
Les clusters comprennent fondamentalement des nœuds, chacun effectuant un rôle spécifique dans le système HPC. Les termes nœud et machine virtuelle sont parfois utilisés de manière interchangeable, mais sont sémantiquement séparés dans CycleCloud. Les nœuds qui composent un cluster sont des machines virtuelles sur Azure qui terminent le processus de préparation et de configuration. En d’autres termes, vous créez des machines virtuelles à partir des couches de service d’infrastructure Azure. Après avoir installé le logiciel et effectué les étapes de configuration, les machines virtuelles sont des nœuds d’un cluster HPC.
CycleCloud a deux types de nœuds : les nœuds autonomes et les tableaux de nœuds. Un tableau de nœuds est une collection de nœuds configurés de manière identique. La distinction entre le nœud et le tableau de nœuds suit l'analogie DevOps connue sous le nom de "Pets vs Cattle" (animaux de compagnie vs bétail). Les nœuds autonomes sont construits à partir de machines virtuelles uniques sur Azure. Les tableaux de nœuds sont mappés aux ensembles de machines virtuelles à échelle.
Toutefois, il existe des différences cruciales entre les tableaux de nœuds et les jeux d'échelle de machines virtuelles. Un réseau de nœuds unique peut comprendre plusieurs ensembles de mise à l'échelle de machines virtuelles. Cette configuration permet à un seul tableau de nœuds d’être généré à partir de machines virtuelles de tailles différentes ou même de familles de machines virtuelles différentes. La seule contrainte est que tous les nœuds d’un tableau de nœuds jouent le même rôle dans le cluster. Par exemple, tous les nœuds fournissent des ressources à une file d’attente unique d’un planificateur.
Modèles de cluster
Définissez la topologie ou la façon dont les nœuds sont organisés dans un cluster CycleCloud, dans des modèles de texte. Les modèles définissent les relations entre les nœuds d’un cluster. S’il existe des clusters imbriqués, les modèles définissent la relation parent-enfant des clusters. Les modèles définissent également le rôle de chaque nœud.
Définissez des modèles de cluster au format INI. Utilisez des sections délimitées par des crochets [et ] pour définir des clusters, des nœuds et des tableaux de nœuds. Les éléments de base des fichiers INI sont des assertions de paire clé-valeur qui fournissent les détails de configuration de chaque section. Ces détails de configuration fournissent des informations contextuelles pour créer chaque nœud d’un cluster, par exemple l’image de machine virtuelle pour démarrer la machine virtuelle et le sous-réseau de la machine virtuelle. Pour plus d’informations, consultez les modèles de cluster CycleCloud.
Préparation et configuration des nœuds
CycleCloud provisionne des machines virtuelles à partir d’images de machine virtuelle de base définies dans le modèle de cluster. Grâce à une série d’étapes gérées par l’agent CycleCloud (Jetpack) pendant le processus de démarrage, elle initialise et configure le système d’exploitation sur la machine virtuelle pour le convertir en nœud HPC opérationnel. Ces étapes vont des scripts pour installer et configurer le logiciel de planification, à la configuration du dernier mile pour le montage d’un système de fichiers.
Vous pouvez contrôler la façon dont les nœuds sont personnalisés au démarrage en créant un projet d’init de cluster personnalisé. Un projet contient les scripts et d’autres fichiers nécessaires pour personnaliser un nœud, séparés en spécifications pour les différents types de rôles d’un cluster. Par exemple, un projet pour un planificateur de lots tel que Slurm comprend un minimum de trois spécifications : un pour les nœuds principaux du planificateur, un pour les nœuds de calcul et un autre pour les nœuds de connexion. En savoir plus sur les projets CycleCloud.
Dans la définition du nœud, vous référencez les spécifications qui doivent s’exécuter sur ce nœud. Jetpack utilise ces spécifications au démarrage pour préparer un nœud pour son rôle dans le cluster. Les fichiers de spécification proviennent du compte de stockage Blob de l'utilisateur et sont préparés depuis le serveur d'applications CycleCloud vers le compte de stockage avant que les nœuds ne soient démarrés.
Note
Les spécifications pour les modèles intégrés (comme le type de cluster Slurm) sont stockées dans GitHub. CycleCloud les télécharge automatiquement sur le compte de stockage de l’utilisateur au démarrage du nœud.
Lorsqu’un nœud démarre, Jetpack télécharge les spécifications définies sur le nœud avec la [[[cluster-init]]] section et les traite afin de converger le nœud vers un état de travail (par exemple, pour être un nœud de calcul).
Orchestration des nœuds
Selon le planificateur et les services utilisés dans un cluster, CycleCloud doit parfois orchestrer la phase de préparation des nœuds d’un cluster en coordonnant différents nœuds. Par exemple, certains planificateurs nécessitent que chaque nœud de calcul s’inscrit lui-même auprès du démon du planificateur. Cette exigence signifie que les nœuds de calcul doivent être conscients de l’adresse du nœud principal. Les nœuds de calcul doivent également reconnaître que le nœud principal est entièrement préparé et attend si ce n’est pas le cas.
CycleCloud utilise cet élément de Service Discovery pour les relations serveur-client du système de fichiers.