Notes
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.
Dans la section configuration de chaque nœud, vous définissez des spécifications cluster-init. Le démarrage de machines virtuelles utilise ces spécifications pour se préparer à un rôle spécifique dans le cluster. CycleCloud utilise Chef comme plateforme d’automatisation de l’infrastructure pour préparer et configurer chaque nœud. Chaque spécification init de cluster est mappée à un ou plusieurs rôles Chef et/ou recettes de livre de recettes qui doivent être exécutées sur la machine virtuelle de démarrage.
CycleCloud utilise Chef en mode autonome qui ne repose pas sur un serveur Chef centralisé. Au lieu de cela, l’ensemble entier des livres de cuisine Chef nécessaires pour préparer chaque machine virtuelle est téléchargé à partir d’un compte de stockage Azure appartenant à l’utilisateur pendant la phase de démarrage de la machine virtuelle. Cet ensemble de livres de recettes est mis en cache à partir du serveur d’applications CycleCloud dans le compte de stockage pendant la phase de création du cluster.
Après avoir téléchargé ces livres de recettes, Chef traite la liste des recettes définies dans les spécifications de cluster-init du nœud. Il déclenche une phase de préparation et de configuration qui convertit la machine virtuelle en nœud HPC opérationnel.
Vous créez des spécifications en tant que collections logiques appelées projets. Par exemple, un projet pour un planificateur de lots tel que Slurm comprend un minimum de deux spécifications : une pour les nœuds principaux du planificateur et l’autre pour les nœuds de calcul. En savoir plus sur les projets CycleCloud.
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.