Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Slurm Workload Manager (`slurm`)
## Taille et mise à jour de la capacité du cluster
La capacité du cluster est définie par le nombre de nœuds de calcul que le cluster peut dimensionner. Les nœuds de calcul sont soutenus par des instances Amazon EC2 définies dans les ressources de calcul de la AWS ParallelCluster configuration`(Scheduling/SlurmQueues/`ComputeResources`)`, et sont organisés en files d'attente `(Scheduling/SlurmQueues)` qui mappent 1:1 aux partitions. Slurm
Au sein d'une ressource de calcul, il est possible de configurer le nombre minimum de nœuds de calcul (instances) qui doivent toujours continuer à fonctionner dans le cluster (`MinCount`), ainsi que le nombre maximum d'instances que la ressource de calcul peut atteindre ([`MaxCount`3](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)).
Au moment de la création du cluster, ou lors d'une mise à jour du cluster, AWS ParallelCluster lance autant d'instances Amazon EC2 que configuré `MinCount` pour chaque ressource de calcul (`Scheduling/SlurmQueues/ ComputeResources`) définie dans le cluster. Les instances lancées pour couvrir le nombre minimal de nœuds pour les ressources de calcul du cluster sont appelées ***nœuds statiques**.* Une fois démarrés, les nœuds statiques sont censés être persistants dans le cluster et le système ne les arrête pas, sauf si un événement ou une condition spécifique se produit. Ces événements incluent, par exemple, l'échec des tests de Slurm santé d'Amazon EC2 et le changement de l'état du Slurm nœud en DRAIN ou DOWN.
Les instances Amazon EC2, de l'ordre de 1 `1` à `‘MaxCount - MinCount’` (`MaxCount `*moins*)` MinCount)`, lancées à la demande pour faire face à l'augmentation de la charge du cluster, sont appelées nœuds ***dynamiques***. Leur nature est éphémère, ils sont lancés pour exécuter des tâches en attente et sont interrompus une fois qu'ils restent inactifs pendant une période définie `Scheduling/SlurmSettings/ScaledownIdletime` dans la configuration du cluster (par défaut : 10 minutes).
Les nœuds statiques et les nœuds dynamiques sont conformes au schéma de dénomination suivant :
+ Nœuds statiques `-st--` où ` = 1..ComputeResource/MinCount`
+ Nœuds dynamiques `-dy--` où ` = 1..(ComputeResource/MaxCount - ComputeResource/MinCount)`
Par exemple, étant donné la AWS ParallelCluster configuration suivante :
```
Scheduling:
Scheduler: Slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 150
```
Les nœuds suivants seront définis dans Slurm
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
Lorsqu'une ressource de calcul l'est`MinCount == MaxCount`, tous les nœuds de calcul correspondants seront statiques et toutes les instances seront lancées au creation/update moment du cluster et maintenues opérationnelles. Par exemple :
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 100
```
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Mise à jour des capacités du cluster
La mise à jour de la capacité du cluster inclut l'ajout ou la suppression de files d'attente, de ressources de calcul ou la modification `MinCount/MaxCount` d'une ressource de calcul. À partir de AWS ParallelCluster la version 3.9.0, la réduction de la taille d'une file d'attente nécessite que le parc de calcul soit arrêté ou [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)défini sur TERMINATE avant qu'une mise à jour du cluster n'ait lieu. Il n'est pas nécessaire d'arrêter le parc informatique ou de le [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)configurer sur TERMINATE lorsque :
+ Ajouter de nouvelles files d'attente à la planification/ [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)
+ Ajouter de nouvelles ressources de calcul `Scheduling/SlurmQueues/ComputeResources` à une file d'attente
+ Augmenter la valeur `MaxCount` d'une ressource de calcul
+ Augmentation MinCount d'une ressource de calcul et augmentation MaxCount de la même ressource de calcul d'au moins la même quantité
## Considérations et restrictions
Cette section vise à décrire tous les facteurs, contraintes ou limitations importants à prendre en compte lors du redimensionnement de la capacité du cluster.
+ Lors de la suppression d'une file d'attente de `Scheduling/SlurmQueues` tous les nœuds de calcul portant un nom`-*`, statique ou dynamique, seront supprimés de la Slurm configuration et les instances Amazon EC2 correspondantes seront résiliées.
+ Lorsque vous supprimez une ressource `Scheduling/SlurmQueues/ComputeResources` de calcul d'une file d'attente, tous les nœuds de calcul portant un nom`-*--*`, qu'ils soient statiques ou dynamiques, sont supprimés de la Slurm configuration et les instances Amazon EC2 correspondantes sont mises hors service.
Lorsque vous modifiez le `MinCount` paramètre d'une ressource de calcul, nous pouvons distinguer deux scénarios différents, s'il `MaxCount` est maintenu égal à `MinCount` (capacité statique uniquement) et s'il `MaxCount` est supérieur à `MinCount` (capacité statique et dynamique mixte).
### Changements de capacité avec des nœuds statiques uniquement
+ Si`MinCount == MaxCount`, lors de l'augmentation `MinCount` (et`MaxCount`), le cluster est configuré en étendant le nombre de nœuds statiques à la nouvelle valeur de `MinCount` `-st--` et que le système continue d'essayer de lancer des instances Amazon EC2 pour atteindre la nouvelle capacité statique requise.
+ Si`MinCount == MaxCount`, lors de la diminution `MinCount` (et`MaxCount`) du montant N, le cluster est configuré en supprimant les N derniers nœuds statiques `-st--...]` et le système met fin aux instances Amazon EC2 correspondantes.
+ État initial `MinCount = MaxCount = 100`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Mise à jour `-30` sur `MinCount` et `MaxCount: MinCount = MaxCount = 70`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
### Changements de capacité avec des nœuds mixtes
Si`MinCount < MaxCount`, lors d'une augmentation `MinCount` d'un montant N (en supposant que `MaxCount` cela restera inchangé), le cluster sera configuré en étendant le nombre de nœuds statiques à la nouvelle valeur de `MinCount` (`old_MinCount + N`) : `-st--` et le système continuera d'essayer de lancer des instances Amazon EC2 pour atteindre la nouvelle capacité statique requise. De plus, pour respecter la `MaxCount` capacité de la ressource de calcul, la configuration du cluster est mise à jour en *supprimant les N derniers nœuds dynamiques* : `-dy--[...]` et le système mettra fin aux instances Amazon EC2 correspondantes.
+ État initial : `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Mettre à jour \$130 vers `MinCount : MinCount = 130 (MaxCount = 150)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Si`MinCount < MaxCount`, lors de l'augmentation `MinCount` et `MaxCount` de la même quantité N, le cluster est configuré en étendant le nombre de nœuds statiques à la nouvelle valeur de `MinCount` (`old_MinCount + N`) : `-st--` et le système continuera d'essayer de lancer des instances Amazon EC2 pour atteindre la nouvelle capacité statique requise. De plus, aucune modification ne sera apportée au nombre de nœuds dynamiques pour honorer le nouveau
Valeur `MaxCount`.
+ État initial : `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Mettre à jour \$130 vers `MinCount : MinCount = 130 (MaxCount = 180)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Si`MinCount < MaxCount`, lors de la diminution `MinCount` du montant N (en supposant qu'il `MaxCount` restera inchangé), le cluster sera configuré en supprimant les N derniers nœuds statiques (nœuds statiques) `-st--[...` et le système mettra fin aux instances Amazon EC2 correspondantes. De plus, pour respecter la `MaxCount` capacité de la ressource de calcul, la configuration du cluster est mise à jour en augmentant le nombre de nœuds dynamiques afin de combler le vide. `MaxCount - new_MinCount: -dy--[1..]` Dans ce cas, comme il s'agit de nœuds dynamiques, aucune nouvelle instance Amazon EC2 ne sera lancée à moins que le planificateur n'ait des tâches en attente sur les nouveaux nœuds.
+ État initial : `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Mise à jour -30 le `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-80]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Si`MinCount < MaxCount`, lors de la diminution `MinCount` et `MaxCount` de la même quantité N, le cluster sera configuré en supprimant les N derniers nœuds statiques `-st--...]` et le système mettra fin aux instances Amazon EC2 correspondantes.
De plus, aucune modification ne sera apportée au nombre de nœuds dynamiques pour respecter la nouvelle `MaxCount` valeur.
+ État initial : `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Mise à jour -30 le `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Si`MinCount < MaxCount`, lors de la diminution `MaxCount` du montant N (en supposant `MinCount` qu'il reste inchangé), le cluster est configuré en supprimant les N derniers nœuds dynamiques `-dy--]` et le système arrête les instances Amazon EC2 correspondantes dans le cas où elles étaient en cours d'exécution. Aucun impact n'est attendu sur les nœuds statiques.
+ État initial : `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Mise à jour -30 le `MaxCount : MinCount = 100 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Impacts sur les emplois
Dans tous les cas où des nœuds sont supprimés et des instances Amazon EC2 résiliées, une tâche sbatch exécutée sur les nœuds supprimés sera remise en file d'attente, sauf si aucun autre nœud ne répond aux exigences de la tâche. Dans ce dernier cas, la tâche échoue avec le statut NODE\$1FAIL, disparaît de la file d'attente et doit être soumise à nouveau manuellement.
Si vous prévoyez d'effectuer une mise à jour de redimensionnement du cluster, vous pouvez empêcher les tâches de s'exécuter sur les nœuds qui seront supprimés lors de la mise à jour planifiée. Cela est possible en configurant les nœuds à supprimer lors de la maintenance. Sachez que le fait de configurer un nœud en maintenance n'aura aucune incidence sur les tâches qui sont déjà en cours d'exécution sur le nœud.
Supposons qu'avec la mise à jour prévue pour le redimensionnement du cluster, vous allez supprimer le `qeueu-st-computeresource-[9-10` [nœud]. Vous pouvez créer une Slurm réservation à l'aide de la commande suivante
```
sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10]
```
Cela créera une Slurm réservation nommée `maint_for_update` sur les nœuds`qeueu-st-computeresource-[9-10]`. À partir du moment où la réservation est créée, aucune autre tâche ne peut être exécutée sur les nœuds`qeueu-st-computeresource-[9-10]`. Sachez que la réservation n'empêchera pas l'attribution éventuelle de tâches sur les nœuds`qeueu-st-computeresource-[9-10]`.
Après la mise à jour du redimensionnement du cluster, si la Slurm réservation a été définie uniquement sur les nœuds supprimés lors de la mise à jour du redimensionnement, la réservation de maintenance sera automatiquement supprimée. Si vous avez plutôt créé une Slurm réservation sur les nœuds qui sont toujours présents après la mise à jour du redimensionnement du cluster, nous souhaiterons peut-être supprimer la réservation de maintenance sur les nœuds une fois la mise à jour du redimensionnement effectuée, à l'aide de la commande suivante
```
sudo -i scontrol delete ReservationName=maint_for_update
```
[Pour plus de détails sur la Slurm réservation, consultez le document officiel de SchedMD ici.](https://slurm.schedmd.com/reservations.html)
## Processus de mise à jour du cluster en cas de modification de capacité
Lors d'un changement de configuration du planificateur, les étapes suivantes sont exécutées pendant le processus de mise à jour du cluster :
+ Arrêtez AWS ParallelCluster `clustermgtd (supervisorctl stop clustermgtd)`
+ Générer une configuration de Slurm partitions mise à jour depuis AWS ParallelCluster la configuration
+ Redémarrage `slurmctld` (effectué via la recette du service Chef)
+ Vérifier le `slurmctld` statut `(systemctl is-active --quiet slurmctld.service)`
+ Recharger la configuration Slurm `(scontrol reconfigure)`
+ Démarrage de `clustermgtd (supervisorctl start clustermgtd)`
Pour plus d’informations sur Slurm, consultez [https://slurm.schedmd.com](https://slurm.schedmd.com). Pour les téléchargements, voir [https://github.com/SchedMD/slurm/tags](https://github.com/SchedMD/slurm/tags). Pour le code source, voir [https://github.com/SchedMD/slurm](https://github.com/SchedMD/slurm).
## Versions de cluster et de SLURM prises en charge
Le tableau suivant répertorie les Slurm versions AWS ParallelCluster et prises en AWS charge.
| AWS ParallelCluster version (s) | Version Slurm prise en charge |
| --- | --- |
| 3,13,0 | 24/05/07 |
| 3.12.0 | 23,1,110 |
| 3.11.0 | 23,1,110 |
| 3,9.2, 3,9.3, 3.10.0 | 23,11.7 |
| 3.9.0, 3.9.1 | 23,11.4 |
| 3.8.0 | 23,02,7 |
| 3.7.2 | 23,02,6 |
| 3.7.1 | 23,02,5 |
| 3.7.0 | 23,02,4 |
| 3.6.0, 3.6.1 | 23,02,2 |
| 3.5.0, 3.5.1 | 22,05,8 |
| 3.4.0, 3.4.1 | 22,05,7 |
| 3.3.0, 3.3.1 | 22,05,5 |
| 3.1.4, 3.1.5, 3.2.0, 3.2.1 | 21.08.8-2 |
| 3.1.2, 3.1.3 | 21,08,6 |
| 3.1.1 | 21,08,5 |
| 3.0.0 | 20,11,8 |
**Topics**
+ [
## Taille et mise à jour de la capacité du cluster
](#cluster-capacity-size-and-update)
+ [
## Mise à jour des capacités du cluster
](#cluster-capacity-update)
+ [
## Considérations et restrictions
](#considerations-limitations)
+ [
## Impacts sur les emplois
](#impacts-on-jobs)
+ [
## Processus de mise à jour du cluster en cas de modification de capacité
](#cluster-update-process)
+ [
## Versions de cluster et de SLURM prises en charge
](#cluster-slurm-version-table)
+ [
# Configuration de plusieurs files d'attente
](configuration-of-multiple-queues-v3.md)
+ [
# Slurmguide pour le mode de file d'attente multiple
](multiple-queue-mode-slurm-user-guide-v3.md)
+ [
# Slurm mode protégé par cluster
](slurm-protected-mode-v3.md)
+ [
# Slurmbasculement rapide d'une capacité insuffisante du cluster
](slurm-short-capacity-fail-mode-v3.md)
+ [
# Slurm planification basée sur la mémoire
](slurm-mem-based-scheduling-v3.md)
+ [
# Allocation de plusieurs types d'instances avec Slurm
](slurm-multiple-instance-allocation-v3.md)
+ [
# Mise à l'échelle du cluster pour les nœuds dynamiques
](scheduler-node-allocation-v3.md)
+ [
# Slurmcomptabilité avec AWS ParallelCluster
](slurm-accounting-v3.md)
+ [
# Slurm personnalisation de la configuration
](slurm-configuration-settings-v3.md)
+ [
# Slurm et `prolog` `epilog`
](slurm-prolog-epilog-v3.md)
+ [
# Taille et mise à jour de la capacité du cluster
](slurm-cluster-capacity-size-and-update.md)
# Configuration de plusieurs files d'attente
Avec AWS ParallelCluster la version 3, vous pouvez configurer plusieurs files d'attente en définissant le [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler)à `slurm` et en spécifiant plusieurs files d'attente [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) dans le fichier de configuration. Dans ce mode, différents types d'instances coexistent dans les nœuds de calcul spécifiés dans la [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) section du fichier de configuration. [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)avec différents types d'instances sont redimensionnés à la hausse ou à la baisse selon les besoins du[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues).
Les *files d'attente multiples au sein d'*un même cluster sont généralement préférées à plusieurs clusters lorsque les charges de travail partagent la même infrastructure et les mêmes ressources sous-jacentes (telles que le stockage partagé, le réseau ou les nœuds de connexion). Si les charges de travail ont des besoins de calcul, de stockage et de mise en réseau similaires, l'utilisation de plusieurs files d'attente au sein d'un même cluster est plus efficace car elle permet le partage des ressources et évite les doublons inutiles. Cette approche simplifie la gestion et réduit les frais généraux, tout en permettant une planification des tâches et une allocation des ressources efficaces. D'autre part, plusieurs *clusters* doivent être utilisés lorsqu'il existe de fortes exigences en matière de sécurité, de données ou d'isolation opérationnelle entre les charges de travail. Par exemple, si vous devez gérer et exploiter les charges de travail de manière indépendante, avec des plannings, des cycles de mise à jour ou des politiques d'accès différents, plusieurs clusters sont plus appropriés.
**Quotas de ressources de calcul et files d'attente du cluster**
| Ressource | Quota |
| --- | --- |
| [`Slurm queues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) | 50 files d'attente par cluster |
| [`Compute resources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) | 50 ressources de calcul par file d'attente 50 ressources de calcul par cluster |
**Nombre de nœuds**
Chaque ressource de calcul [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)d'une file d'attente doit avoir un [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name)caractère unique [`InstanceType`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-InstanceType), [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount), et [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount). [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)et [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)ont des valeurs par défaut qui définissent la plage d'instances d'une ressource de calcul dans [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)une file d'attente. Vous pouvez également spécifier vos propres valeurs pour [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)et [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount). Chaque ressource de calcul [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)est composée de nœuds statiques numérotés de 1 à la valeur de [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)et de nœuds dynamiques numérotés de la valeur de [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)à la valeur de [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount).
**Exemple de configuration**
Voici un exemple de section de [planification](Scheduling-v3.md) pour un fichier de configuration de cluster. Dans cette configuration, deux files d'attente sont nommées `queue1` `queue2` et chacune d'entre elles possède un nom [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)spécifié. [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- InstanceType: c5.xlarge
MaxCount: 5
Name: c5xlarge
- InstanceType: c4.xlarge
MaxCount: 5
Name: c4xlarge
- Name: queue2
ComputeResources:
- InstanceType: c5.xlarge
MaxCount: 5
Name: c5xlarge
```
**Noms d'hôtes**
Les instances lancées dans le parc informatique sont attribuées dynamiquement. Les noms d'hôtes sont générés pour chaque nœud. Par défaut AWS ParallelCluster , le format du nom d'hôte sera le suivant :
`$HOSTNAME=$QUEUE-$STATDYN-$COMPUTE_RESOURCE-$NODENUM`
+ `$QUEUE`est le nom de la file d'attente. Par exemple, si la [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)section comporte une entrée [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Name)définie sur « `queue-name` », alors « `$QUEUE` » est « `queue-name` ».
+ `$STATDYN`est `st` destiné aux nœuds statiques ou `dy` aux nœuds dynamiques.
+ `$COMPUTE_RESOURCE`est le [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name)de la ressource de [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)calcul correspondant à ce nœud.
+ `$NODENUM`est le numéro du nœud. `$NODENUM`est compris entre un (1) et la valeur de [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)pour les nœuds statiques et entre un (1) et [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)- [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)pour les nœuds dynamiques.
Dans l'exemple de fichier de configuration ci-dessus, un nœud donné `queue1` et une ressource de calcul `c5xlarge` ont un nom d'hôte :`queue1-dy-c5xlarge-1`.
Les noms d'hôte et les noms de domaine complets (FQDN) sont créés à l'aide des zones hébergées Amazon Route 53. Le FQDN est`$HOSTNAME.$CLUSTERNAME.pcluster`, où `$CLUSTERNAME` est le nom du cluster.
Notez que le même format sera également utilisé pour les noms de Slurm nœuds.
Les utilisateurs peuvent choisir d'utiliser le EC2 nom d'hôte Amazon par défaut de l'instance alimentant le nœud de calcul au lieu du format de nom d'hôte par défaut utilisé par AWS ParallelCluster. Cela peut être fait en réglant le [`UseEc2Hostnames`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames)paramètre sur true. Toutefois, les noms de Slurm nœuds continueront d'utiliser le AWS ParallelCluster format par défaut.
# Slurmguide pour le mode de file d'attente multiple
Ici, vous pouvez apprendre comment Slurm gérer AWS ParallelCluster les nœuds de file d'attente (partition) et comment surveiller l'état des files d'attente et des nœuds.
## Présentation de
L'architecture de mise à l'échelle est basée sur le [guide Slurm de planification cloud](https://slurm.schedmd.com/elastic_computing.html) et le plugin d'économie d'énergie. Pour plus d'informations sur le plug-in d'économie d'énergie, consultez le [Guide d'économie d'Slurménergie](https://slurm.schedmd.com/power_save.html). Dans l'architecture, les ressources susceptibles d'être mises à disposition pour un cluster sont généralement prédéfinies dans la Slurm configuration sous forme de nœuds cloud.
## Cycle de vie des nœuds cloud
Tout au long de leur cycle de vie, les nœuds cloud entrent dans plusieurs des états suivants`POWER_SAVING`, `POWER_UP` voire dans tous les cas :, `ALLOCATED` (`alloc`), () et `POWER_DOWN` (`pow_dn`). `pow_up` Dans certains cas, un nœud de cloud peut entrer dans `OFFLINE` cet état. La liste suivante détaille plusieurs aspects de ces états dans le cycle de vie des nœuds de cloud.
+ **Un nœud dans un `POWER_SAVING` état** apparaît avec un `~` suffixe (par exemple`idle~`) dans`sinfo`. Dans cet état, aucune instance EC2 ne sauvegarde le nœud. Cependant, Slurm vous pouvez toujours allouer des tâches au nœud.
+ **Un nœud en transition vers un `POWER_UP` état** apparaît avec un `#` suffixe (par exemple`idle#`) dans. `sinfo` Un nœud passe automatiquement à un `POWER_UP` état lorsqu'il Slurm alloue une tâche à un nœud dans un `POWER_SAVING` état.
Vous pouvez également faire passer les nœuds à l'`POWER_UP`état manuellement en tant qu'utilisateur `su` root à l'aide de la commande suivante :
```
$ scontrol update nodename=nodename state=power_up
```
À ce stade, le `ResumeProgram` est invoqué, les instances EC2 sont lancées et configurées, et le nœud passe à l'`POWER_UP`état.
+ **Un nœud actuellement disponible** apparaît sans suffixe (par exemple`idle`) dans`sinfo`. Une fois le nœud configuré et rejoint le cluster, il devient disponible pour exécuter des tâches. À ce stade, le nœud est correctement configuré et prêt à être utilisé.
En règle générale, nous recommandons que le nombre d'instances Amazon EC2 soit identique au nombre de nœuds disponibles. Dans la plupart des cas, les nœuds statiques sont disponibles après la création du cluster.
+ **Un nœud en transition vers un `POWER_DOWN` état apparaît avec un** `%` suffixe (par exemple`idle%`) dans. `sinfo` Les nœuds dynamiques entrent automatiquement dans l'`POWER_DOWN`état suivant [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime). En revanche, dans la plupart des cas, les nœuds statiques ne sont pas hors tension. Cependant, vous pouvez placer les nœuds dans l'`POWER_DOWN`état manuellement en tant qu'utilisateur `su` root à l'aide de la commande suivante :
```
$ scontrol update nodename=nodename state=down reason="manual draining"
```
Dans cet état, les instances associées à un nœud sont résiliées, et le nœud est remis à son `POWER_SAVING` état et peut être utilisé ultérieurement [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime).
Le [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)paramètre est enregistré dans le `SuspendTimeout` paramètre Slurm de configuration.
+ **Un nœud hors ligne apparaît** avec un `*` suffixe (par exemple`down*`) dans`sinfo`. Un nœud est déconnecté si le Slurm contrôleur ne parvient pas à le contacter ou si les nœuds statiques sont désactivés et que les instances de support sont interrompues.
Examinez les états des nœuds illustrés dans l'`sinfo`exemple suivant.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 4 idle~ efa-dy-efacompute1-[1-4]
efa up infinite 1 idle efa-st-efacompute1-1
gpu up infinite 1 idle% gpu-dy-gpucompute1-1
gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10]
ondemand up infinite 2 mix# ondemand-dy-ondemandcompute1-[1-2]
ondemand up infinite 18 idle~ ondemand-dy-ondemandcompute1-[3-10],ondemand-dy-ondemandcompute2-[1-10]
spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
spot* up infinite 2 idle spot-st-spotcompute2-[1-2]
```
Les `efa-st-efacompute1-1` nœuds `spot-st-spotcompute2-[1-2]` et ont déjà des instances de sauvegarde configurées et peuvent être utilisées. Les `ondemand-dy-ondemandcompute1-[1-2]` nœuds sont en bon `POWER_UP` état et devraient être disponibles d'ici quelques minutes. Le `gpu-dy-gpucompute1-1` nœud est dans l'`POWER_DOWN`état, et il passe à `POWER_SAVING` l'état par la suite [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)(10 minutes par défaut).
Tous les autres nœuds sont dans un `POWER_SAVING` état sans qu'aucune instance EC2 ne les soutienne.
## Utilisation d'un nœud disponible
Un nœud disponible est soutenu par une instance Amazon EC2. Par défaut, le nom du nœud peut être utilisé pour accéder directement à l'instance en SSH (par exemple`ssh efa-st-efacompute1-1`). L'adresse IP privée de l'instance peut être récupérée à l'aide de la commande :
```
$ scontrol show nodes nodename
```
Vérifiez l'adresse IP dans le `NodeAddr` champ renvoyé.
Pour les nœuds qui ne sont pas disponibles, le `NodeAddr` champ ne doit pas pointer vers une instance Amazon EC2 en cours d'exécution. Il doit plutôt être identique au nom du nœud.
## État des offres d'emploi et soumission
Dans la plupart des cas, les tâches soumises sont immédiatement allouées aux nœuds du système ou mises en attente si tous les nœuds sont alloués.
Si les nœuds alloués à une tâche incluent des nœuds dans un `POWER_SAVING` état, la tâche commence par un `CF` `CONFIGURING` état ou. À ce stade, la tâche attend que les nœuds de l'`POWER_SAVING`état passent à l'`POWER_UP`état et soient disponibles.
Une fois que tous les nœuds alloués à une tâche sont disponibles, la tâche passe à l'état `RUNNING` (`R`).
Par défaut, toutes les tâches sont soumises à la file d'attente par défaut (connue sous le nom de partition inSlurm). Cela est indiqué par un `*` suffixe après le nom de la file d'attente. Vous pouvez sélectionner une file d'attente à l'aide de l'option de soumission des `-p` tâches.
Tous les nœuds sont configurés avec les fonctionnalités suivantes, qui peuvent être utilisées dans les commandes de soumission de tâches :
+ Un type d'instance (par exemple`c5.xlarge`)
+ Un type de nœud (il s'agit de l'un `dynamic` ou `static` de l'autre)
Vous pouvez voir les fonctionnalités d'un nœud en particulier à l'aide de la commande :
```
$ scontrol show nodes nodename
```
Au retour, consultez la `AvailableFeatures` liste.
Tenez compte de l'état initial du cluster, que vous pouvez consulter en exécutant la `sinfo` commande.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 4 idle~ efa-dy-efacompute1-[1-4]
efa up infinite 1 idle efa-st-efacompute1-1
gpu up infinite 10 idle~ gpu-dy-gpucompute1-[1-10]
ondemand up infinite 20 idle~ ondemand-dy-ondemandcompute1-[1-10],ondemand-dy-ondemandcompute2-[1-10]
spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
spot* up infinite 2 idle spot-st-spotcompute2-[1-2]
```
Notez qu'il s'`spot`agit de la file d'attente par défaut. Il est indiqué par le `*` suffixe.
Soumettez une tâche à un nœud statique de la file d'attente par défaut (`spot`).
```
$ sbatch --wrap "sleep 300" -N 1 -C static
```
Soumettez une tâche à un nœud dynamique de la `EFA` file d'attente.
```
$ sbatch --wrap "sleep 300" -p efa -C dynamic
```
Soumettez une tâche à huit (8) `c5.2xlarge` nœuds et à deux (2) `t2.xlarge` nœuds de la `ondemand` file d'attente.
```
$ sbatch --wrap "sleep 300" -p ondemand -N 10 -C "[c5.2xlarge*8&t2.xlarge*2]"
```
Soumettez une tâche à un nœud GPU de la `gpu` file d'attente.
```
$ sbatch --wrap "sleep 300" -p gpu -G 1
```
Examinez l'état des tâches à l'aide de la `squeue` commande.
```
$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
12 ondemand wrap ubuntu CF 0:36 10 ondemand-dy-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2]
13 gpu wrap ubuntu CF 0:05 1 gpu-dy-gpucompute1-1
7 spot wrap ubuntu R 2:48 1 spot-st-spotcompute2-1
8 efa wrap ubuntu R 0:39 1 efa-dy-efacompute1-1
```
Les tâches 7 et 8 (dans les `efa` files d'attente `spot` et) sont déjà en cours d'exécution (`R`). Les jobs 12 et 13 sont toujours en cours de configuration (`CF`), probablement en attente de la disponibilité des instances.
```
# Nodes states corresponds to state of running jobs
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 3 idle~ efa-dy-efacompute1-[2-4]
efa up infinite 1 mix efa-dy-efacompute1-1
efa up infinite 1 idle efa-st-efacompute1-1
gpu up infinite 1 mix~ gpu-dy-gpucompute1-1
gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10]
ondemand up infinite 10 mix# ondemand-dy-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2]
ondemand up infinite 10 idle~ ondemand-dy-ondemandcompute1-[9-10],ondemand-dy-ondemandcompute2-[3-10]
spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
spot* up infinite 1 mix spot-st-spotcompute2-1
spot* up infinite 1 idle spot-st-spotcompute2-2
```
## État et fonctionnalités du nœud
Dans la plupart des cas, les états des nœuds sont entièrement gérés AWS ParallelCluster conformément aux processus spécifiques du cycle de vie des nœuds de cloud décrits plus haut dans cette rubrique.
Toutefois, remplace ou arrête AWS ParallelCluster également les nœuds défectueux dans les `DRAINED` états `DOWN` et les nœuds dont les instances de sauvegarde sont défectueuses. Pour de plus amples informations, veuillez consulter [`clustermgtd`](processes-v3.md#clustermgtd-v3).
## États de partition
AWS ParallelCluster prend en charge les états de partition suivants. Une Slurm partition est une file d'attente dans AWS ParallelCluster.
+ `UP`: indique que la partition est dans un état actif. Il s'agit de l'état par défaut d'une partition. Dans cet état, tous les nœuds de la partition sont actifs et peuvent être utilisés.
+ `INACTIVE`: indique que la partition est inactive. Dans cet état, toutes les instances qui soutiennent les nœuds d'une partition inactive sont arrêtées. Les nouvelles instances ne sont pas lancées pour les nœuds d'une partition inactive.
## cluster update-compute-fleet
+ **Arrêt du parc informatique** : lorsque la commande suivante est exécutée, toutes les partitions passent à l'`INACTIVE`état, et AWS ParallelCluster les processus les maintiennent dans `INACTIVE` cet état.
```
$ pcluster update-compute-fleet --cluster-name testSlurm \
--region eu-west-1 --status STOP_REQUESTED
```
+ **Démarrage du parc informatique** : lorsque la commande suivante est exécutée, toutes les partitions passent initialement à l'`UP`état. Cependant, AWS ParallelCluster les processus ne maintiennent pas la partition dans un `UP` état. Vous devez modifier l'état des partitions manuellement. Tous les nœuds statiques sont disponibles au bout de quelques minutes. Notez que le fait de définir une partition sur `UP` n'augmente aucune capacité dynamique.
```
$ pcluster update-compute-fleet --cluster-name testSlurm \
--region eu-west-1 --status START_REQUESTED
```
Lorsqu'il `update-compute-fleet` est exécuté, vous pouvez vérifier l'état du cluster en exécutant la `pcluster describe-compute-fleet` commande et en vérifiant le`Status`. La liste suivante répertorie les états possibles :
+ `STOP_REQUESTED`: La demande d'arrêt du parc informatique est envoyée au cluster.
+ `STOPPING`: Le `pcluster` processus arrête actuellement le parc informatique.
+ `STOPPED`: le `pcluster` processus a terminé le processus d'arrêt, toutes les partitions sont en `INACTIVE` état et toutes les instances de calcul sont terminées.
+ `START_REQUESTED`: La demande de démarrage de la flotte de calcul est envoyée au cluster.
+ `STARTING`: le `pcluster` processus est en train de démarrer le cluster.
+ `RUNNING`: le `pcluster` processus de démarrage est terminé, toutes les partitions sont en `UP` état et les nœuds statiques sont disponibles au bout de quelques minutes.
+ `PROTECTED`: Cet état indique que certaines partitions présentent des échecs d'amorçage constants. Les partitions concernées sont inactives. Examinez le problème, puis lancez-vous `update-compute-fleet` pour réactiver le parc.
## Contrôle manuel des files d'attente
Dans certains cas, vous souhaiterez peut-être contrôler manuellement les nœuds ou la file d'attente (appelée partition dansSlurm) d'un cluster. Vous pouvez gérer les nœuds d'un cluster à l'aide des procédures courantes suivantes à l'aide de la `scontrol` commande.
+ **Allumez les nœuds dynamiques en `POWER_SAVING` état**
Exécutez la commande en tant qu'utilisateur `su` root :
```
$ scontrol update nodename=nodename state=power_up
```
Vous pouvez également soumettre une `sleep 1` tâche fictive demandant un certain nombre de nœuds, puis vous en servir Slurm pour alimenter le nombre de nœuds requis.
+ **Éteignez les nœuds dynamiques avant [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)**
Nous vous recommandons de définir les nœuds dynamiques en `DOWN` tant qu'utilisateur `su` root à l'aide de la commande suivante :
```
$ scontrol update nodename=nodename state=down reason="manually draining"
```
AWS ParallelCluster arrête et réinitialise automatiquement les nœuds dynamiques tombés en panne.
En général, il est déconseillé de définir les nœuds sur `POWER_DOWN` directement à l'aide de la `scontrol update nodename=nodename state=power_down` commande. Cela est dû au fait que le processus de mise hors tension est AWS ParallelCluster automatiquement géré.
+ **Désactiver une file d'attente (partition) ou arrêter tous les nœuds statiques d'une partition spécifique**
Définissez une file d'attente spécifique en `INACTIVE` tant qu'utilisateur `su` root à l'aide de la commande :
```
$ scontrol update partition=queuename state=inactive
```
Cela met fin à toutes les instances qui soutiennent les nœuds de la partition.
+ **Activer une file d'attente (partition)**
Définissez une file d'attente spécifique pour `UP` un utilisateur `su` root à l'aide de la commande :
```
$ scontrol update partition=queuename state=up
```
## Comportement de dimensionnement et ajustements
**Voici un exemple du flux de travail de dimensionnement normal :**
+ Le planificateur reçoit une tâche qui nécessite deux nœuds.
+ Le planificateur fait passer deux nœuds à un `POWER_UP` état et appelle `ResumeProgram` avec les noms des nœuds (par exemple`queue1-dy-spotcompute1-[1-2]`).
+ `ResumeProgram`lance deux instances Amazon EC2 et attribue les adresses IP privées et les noms d'hôte de`queue1-dy-spotcompute1-[1-2]`, en attendant `ResumeTimeout` (la période par défaut est de 30 minutes) avant de réinitialiser les nœuds.
+ Les instances sont configurées et rejoignent le cluster. Une tâche commence à s'exécuter sur des instances.
+ La tâche se termine et s'arrête.
+ Une fois la configuration `SuspendTime` expirée (qui est définie sur [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)), le planificateur définit l'état des instances. `POWER_SAVING` Le planificateur passe ensuite `queue1-dy-spotcompute1-[1-2]` à l'`POWER_DOWN`état et appelle `SuspendProgram` avec les noms des nœuds.
+ `SuspendProgram`est appelé pour deux nœuds. Les nœuds restent dans `POWER_DOWN` cet état, par exemple en restant `idle%` pendant un `SuspendTimeout` (la période par défaut est de 120 secondes (2 minutes)). Après avoir `clustermgtd` détecté que les nœuds sont hors tension, il met fin aux instances de sauvegarde. Ensuite, il passe `queue1-dy-spotcompute1-[1-2]` à l'état inactif et réinitialise l'adresse IP privée et le nom d'hôte afin qu'il soit prêt à être redémarré pour de futures tâches.
**Si les choses tournent mal et qu'une instance pour un nœud particulier ne peut pas être lancée pour une raison quelconque, voici ce qui se passe :**
+ Le planificateur reçoit une tâche qui nécessite deux nœuds.
+ Le planificateur fait passer deux nœuds éclatants dans le cloud à l'`POWER_UP`état et appelle `ResumeProgram` avec les noms de nœuds (par exemple). `queue1-dy-spotcompute1-[1-2]`
+ `ResumeProgram`lance une (1) seule instance Amazon EC2 et la configure`queue1-dy-spotcompute1-1`, avec une (1) instance`queue1-dy-spotcompute1-2`, en échouant au lancement.
+ `queue1-dy-spotcompute1-1`n'est pas concerné et se connecte après avoir atteint l'`POWER_UP`État.
+ `queue1-dy-spotcompute1-2`passe à l'`POWER_DOWN`état, et la tâche est automatiquement mise en attente car elle Slurm détecte une défaillance du nœud.
+ `queue1-dy-spotcompute1-2`devient disponible après `SuspendTimeout` (la valeur par défaut est de 120 secondes (2 minutes)). Entre-temps, la tâche est mise en attente et peut commencer à s'exécuter sur un autre nœud.
+ Le processus ci-dessus se répète jusqu'à ce que la tâche puisse s'exécuter sur un nœud disponible sans qu'une défaillance se produise.
**Deux paramètres de chronométrage peuvent être ajustés si nécessaire :**
+ **`ResumeTimeout`(la valeur par défaut est de 30 minutes)** : `ResumeTimeout` contrôle le temps d'Slurmattente avant de faire passer le nœud à l'état inactif.
+ Il peut être utile de procéder à une extension `ResumeTimeout` si le processus pre/post d'installation prend presque autant de temps.
+ `ResumeTimeout`est également le temps d' AWS ParallelCluster attente maximal avant de remplacer ou de réinitialiser un nœud en cas de problème. Les nœuds de calcul s'arrêtent automatiquement en cas d'erreur lors du lancement ou de la configuration. AWS ParallelCluster les processus remplacent un nœud lors de la détection d'une instance interrompue.
+ **`SuspendTimeout`(la valeur par défaut est de 120 secondes (2 minutes))** : `SuspendTimeout` contrôle la rapidité avec laquelle les nœuds sont réinsérés dans le système et sont prêts à être réutilisés.
+ Une valeur plus courte `SuspendTimeout` signifie que les nœuds sont réinitialisés plus rapidement et Slurm peuvent essayer de lancer des instances plus fréquemment.
+ Une valeur plus longue `SuspendTimeout` signifie que les nœuds défaillants sont réinitialisés plus lentement. En attendant, Slurm essaie d'utiliser d'autres nœuds. Si cela `SuspendTimeout` dure plus de quelques minutes, Slurm essaie de parcourir tous les nœuds du système. Un délai plus long `SuspendTimeout` peut être bénéfique pour les systèmes à grande échelle (plus de 1 000 nœuds) afin de réduire le stress Slurm lorsqu'ils tentent fréquemment de remettre en file d'attente des tâches défaillantes.
+ Notez que `SuspendTimeout` cela ne fait pas référence au temps d' AWS ParallelCluster attente pour mettre fin à une instance de sauvegarde pour un nœud. Les instances de sauvegarde pour `POWER_DOWN` les nœuds sont immédiatement résiliées. Le processus de terminaison est généralement terminé en quelques minutes. Cependant, pendant ce temps, le nœud reste dans `POWER_DOWN` cet état et n'est pas disponible pour le planificateur.
## Logs pour l'architecture
La liste suivante contient les journaux clés. Le nom du flux de journal utilisé avec Amazon CloudWatch Logs est au format `{hostname}.{instance_id}.{logIdentifier}` *logIdentifier* suivant lequel suivent les noms des journaux.
+ `ResumeProgram`: `/var/log/parallelcluster/slurm_resume.log` (`slurm_resume`)
+ `SuspendProgram`: `/var/log/parallelcluster/slurm_suspend.log` (`slurm_suspend`)
+ `clustermgtd`: `/var/log/parallelcluster/clustermgtd.log` (`clustermgtd`)
+ `computemgtd`: `/var/log/parallelcluster/computemgtd.log` (`computemgtd`)
+ `slurmctld`: `/var/log/slurmctld.log` (`slurmctld`)
+ `slurmd`: `/var/log/slurmd.log` (`slurmd`)
## Problèmes courants et procédure de débogage :
**Nœuds qui n'ont pas réussi à démarrer, à démarrer ou à rejoindre le cluster**
+ Nœuds dynamiques :
+ Consultez le `ResumeProgram` journal pour voir s'il `ResumeProgram` a été appelé avec le nœud. Si ce n'est pas le cas, consultez le `slurmctld` journal pour déterminer si vous avez Slurm essayé `ResumeProgram` d'appeler le nœud. Notez que des autorisations incorrectes `ResumeProgram` peuvent entraîner son échec silencieux.
+ S'`ResumeProgram`il est appelé, vérifiez si une instance a été lancée pour le nœud. Si l'instance n'a pas été lancée, un message d'erreur clair devrait s'afficher expliquant pourquoi l'instance n'a pas pu être lancée.
+ Si une instance a été lancée, il se peut qu'il y ait eu un problème pendant le processus de démarrage. Trouvez l'adresse IP privée et l'ID d'instance correspondants dans le `ResumeProgram` journal et consultez les journaux de démarrage correspondants pour l'instance spécifique dans CloudWatch Logs.
+ Nœuds statiques :
+ Consultez le `clustermgtd` journal pour voir si des instances ont été lancées pour le nœud. Si les instances ne se sont pas lancées, des erreurs claires devraient apparaître quant à la raison pour laquelle elles n'ont pas pu être lancées.
+ Si une instance a été lancée, le processus d'amorçage présente un problème. Trouvez l'adresse IP privée et l'ID d'instance correspondants dans le `clustermgtd` journal et consultez les journaux de démarrage correspondants pour l'instance spécifique dans CloudWatch Logs.
**Nœuds remplacés ou interrompus de manière inattendue, et défaillances de nœuds**
+ Nœuds de replaced/terminated manière inattendue :
+ Dans la plupart des cas, `clustermgtd` gère toutes les actions de maintenance des nœuds. Pour vérifier si un nœud a été `clustermgtd` remplacé ou résilié, consultez le `clustermgtd` journal.
+ En cas de `clustermgtd` remplacement ou de résiliation du nœud, un message doit apparaître indiquant le motif de l'action. Si la raison est liée au planificateur (par exemple, le nœud l'était`DOWN`), consultez le `slurmctld` journal pour plus de détails. Si la raison est liée à Amazon EC2, utilisez des outils tels qu'Amazon CloudWatch ou la console Amazon EC2, la CLI ou les kits SDK pour vérifier le statut ou les journaux de cette instance. Par exemple, vous pouvez vérifier si l'instance a connu des événements planifiés ou si les vérifications de l'état de santé d'Amazon EC2 ont échoué.
+ Si le nœud `clustermgtd` n'a pas été résilié, vérifiez s'il `computemgtd` a été résilié ou si EC2 a mis fin à l'instance pour récupérer une instance Spot.
+ Défaillances des nœuds :
+ Dans la plupart des cas, les tâches sont automatiquement mises en file d'attente en cas de défaillance d'un nœud. Consultez le `slurmctld` journal pour savoir pourquoi une tâche ou un nœud a échoué et évaluez la situation à partir de là.
**Défaillance lors du remplacement ou de l'arrêt d'instances, défaillance lors de la mise hors tension des nœuds**
+ En général, `clustermgtd` gère toutes les actions de fermeture d'instance attendues. Consultez le `clustermgtd` journal pour savoir pourquoi il n'a pas réussi à remplacer ou à mettre fin à un nœud.
+ En cas d'échec de nœuds dynamiques [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime), consultez le `SuspendProgram` journal pour voir si `slurmctld` les processus ont effectué des appels avec le nœud spécifique comme argument. Remarque `SuspendProgram` n'effectue en fait aucune action spécifique. Au contraire, il ne se connecte que lorsqu'il est appelé. Toutes les fermetures et `NodeAddr` réinitialisations d'instances sont terminées par`clustermgtd`. Slurmfait passer les nœuds vers les `IDLE` nœuds suivants`SuspendTimeout`.
**Autres problèmes :**
+ AWS ParallelCluster ne prend pas de décisions relatives à l'attribution des tâches ou à la mise à l'échelle. Il essaie uniquement de lancer, d'arrêter et de maintenir les ressources conformément Slurm aux instructions.
Pour les problèmes liés à l'allocation des tâches, à l'allocation des nœuds et à la décision de dimensionnement, consultez le `slurmctld` journal pour détecter les erreurs.
# Slurm mode protégé par cluster
Lorsqu'un cluster s'exécute avec le mode protégé activé, il AWS ParallelCluster surveille et suit les défaillances de démarrage des nœuds de calcul lors du lancement des nœuds de calcul. Il le fait pour détecter si ces défaillances se produisent en continu.
Si les éléments suivants sont détectés dans une file d'attente (partition), le cluster passe à l'état protégé :
1. Les défaillances consécutives du bootstrap du nœud de calcul se produisent continuellement en l'absence de lancement réussi du nœud de calcul.
1. Le nombre de défaillances atteint un seuil prédéfini.
Une fois que le cluster est devenu protégé, AWS ParallelCluster désactive les files d'attente présentant des défaillances égales ou supérieures au seuil prédéfini.
Slurm le mode protégé par cluster a été ajouté dans AWS ParallelCluster la version 3.0.0.
Vous pouvez utiliser le mode protégé pour réduire le temps et les ressources consacrés au cycle de défaillance du bootstrap des nœuds de calcul.
## Paramètre du mode protégé
**`protected_failure_count`**
`protected_failure_count`indique le nombre de défaillances consécutives dans une file d'attente (partition) qui active le statut de protection du cluster.
La valeur par défaut `protected_failure_count` est 10 et le mode protégé est activé.
S'il `protected_failure_count` est supérieur à zéro, le mode protégé est activé.
S'`protected_failure_count`il est inférieur ou égal à zéro, le mode protégé est désactivé.
Vous pouvez modifier la `protected_failure_count` valeur en ajoutant le paramètre dans le fichier de `clustermgtd` configuration situé `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` dans le`HeadNode`.
Vous pouvez mettre à jour ce paramètre à tout moment et vous n'avez pas besoin d'arrêter le parc informatique pour le faire. Si un lancement réussit dans une file d'attente avant que le nombre d'échecs n'atteigne`protected_failure_count`, le nombre d'échecs est remis à zéro.
## Vérifier l'état du cluster dans l'état protégé
Lorsqu'un cluster est protégé, vous pouvez vérifier l'état du parc informatique et l'état des nœuds.
### Calculer l'état du parc
L'état du parc informatique est celui `PROTECTED` d'un cluster fonctionnant en état protégé.
```
$ pcluster describe-compute-fleet --cluster-name --region
{
"status": "PROTECTED",
"lastStatusUpdatedTime": "2022-04-22T00:31:24.000Z"
}
```
### État du nœud
Pour savoir quelles files d'attente (partitions) présentent des défaillances de démarrage ayant activé le statut protégé, connectez-vous au cluster et exécutez la `sinfo` commande. Les partitions présentant des défaillances de bootstrap égales ou supérieures `protected_failure_count` sont dans `INACTIVE` cet état. Les partitions ne présentant pas d'échec du bootstrap égal ou supérieur `protected_failure_count` sont dans l'`UP`état et fonctionnent comme prévu.
`PROTECTED`le statut n'a aucun impact sur les tâches en cours d'exécution. Si des tâches sont exécutées sur une partition présentant des échecs de démarrage égaux ou supérieurs`protected_failure_count`, la partition est définie sur une `INACTIVE` fois les tâches en cours d'exécution terminées.
Examinez les états des nœuds illustrés dans l'exemple suivant.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* inact infinite 10 down% queue1-dy-c5xlarge-[1-10]
queue1* inact infinite 3490 idle~ queue1-dy-c5xlarge-[11-3500]
queue2 up infinite 10 idle~ queue2-dy-c5xlarge-[1-10]
```
`queue1`La partition est `INACTIVE` due au fait que 10 défaillances consécutives du bootstrap du nœud de calcul ont été détectées.
Les instances situées derrière les nœuds ont `queue1-dy-c5xlarge-[1-10]` été lancées mais n'ont pas réussi à rejoindre le cluster en raison d'un état défectueux.
Le cluster est protégé.
La partition `queue2` n'est pas affectée par les échecs de bootstrap dans`queue1`. Il est dans l'`UP`état et peut toujours exécuter des tâches.
## Comment désactiver le statut protégé
Une fois l'erreur de démarrage résolue, vous pouvez exécuter la commande suivante pour sortir le cluster de son statut protégé.
```
$ pcluster update-compute-fleet --cluster-name \
--region \
--status START_REQUESTED
```
## Défaillances du bootstrap qui activent le statut protégé
Les erreurs de démarrage qui activent le statut protégé sont subdivisées en trois types suivants. Pour identifier le type et le problème, vous pouvez vérifier si des journaux AWS ParallelCluster ont été générés. Si des journaux ont été générés, vous pouvez vérifier les détails des erreurs. Pour de plus amples informations, veuillez consulter [Récupération et conservation des journaux](troubleshooting-v3-get-logs.md).
1. **Erreur de démarrage qui provoque l'arrêt automatique d'une instance**.
Une instance échoue au début du processus de démarrage, par exemple une instance qui s'arrête automatiquement en raison d'erreurs dans le script [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)\$1 [`CustomActions`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions)\$1 [`OnNodeStart`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart)\$1. [`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured)
Pour les nœuds dynamiques, recherchez les erreurs similaires aux suivantes :
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
Pour les nœuds statiques, recherchez dans le `clustermgtd` journal (`/var/log/parallelcluster/clustermgtd`) les erreurs similaires aux suivantes :
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
1. **Nœuds `resume_timeout` ou `node_replacement_timeout` expirations**.
Une instance ne peut pas rejoindre le cluster au sein du `resume_timeout` (pour les nœuds dynamiques) ou `node_replacement_timeout` (pour les nœuds statiques). Il ne s'arrête pas automatiquement avant le délai imparti. Par exemple, le réseau n'est pas configuré correctement pour le cluster et le nœud est défini sur l'`DOWN`état par Slurm une fois le délai expiré.
Pour les nœuds dynamiques, recherchez les erreurs similaires aux suivantes :
```
Node bootstrap error: Resume timeout expires for node
```
Pour les nœuds statiques, recherchez dans le `clustermgtd` journal (`/var/log/parallelcluster/clustermgtd`) les erreurs similaires aux suivantes :
```
Node bootstrap error: Replacement timeout expires for node ... in replacement.
```
1. Le **contrôle de santé des nœuds échoue**.
Une instance située derrière le nœud échoue à un bilan de EC2 santé Amazon ou à un contrôle d'état d'un événement planifié, et les nœuds sont traités comme des nœuds de défaillance du bootstrap. Dans ce cas, l'instance se termine pour une raison indépendante de la volonté de AWS ParallelCluster.
Recherchez dans le `clustermgtd` journal (`/var/log/parallelcluster/clustermgtd`) les erreurs similaires aux suivantes :
```
Node bootstrap error: Node %s failed during bootstrap when performing health check.
```
1. **Défaillance des nœuds de calcul Slurm enregistrement**.
L'enregistrement du `slurmd` daemon auprès du Slurm control daemon (`slurmctld`) échoue et fait passer l'état du nœud de calcul à `INVALID_REG` cet état. Configuration incorrecte Slurm les nœuds de calcul peuvent provoquer cette erreur, par exemple les nœuds calculés configurés avec des erreurs de spécification des nœuds de [`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)calcul.
Consultez le fichier `slurmctld` journal (`/var/log/slurmctld.log`) du nœud principal ou le fichier `slurmd` journal (`/var/log/slurmd.log`) du nœud de calcul défaillant pour détecter des erreurs similaires aux suivantes :
```
Setting node %s to INVAL with reason: ...
```
## Comment déboguer le mode protégé
Si votre cluster est protégé et s'il a AWS ParallelCluster généré des `clustermgtd` journaux à partir des nœuds de calcul problématiques `HeadNode` et des `cloud-init-output` journaux à partir de nœuds de calcul, vous pouvez consulter les journaux pour obtenir des informations détaillées sur les erreurs. Pour plus d'informations sur la façon de récupérer les journaux, consultez[Récupération et conservation des journaux](troubleshooting-v3-get-logs.md).
**`clustermgtd`log (`/var/log/parallelcluster/clustermgtd`) sur le nœud principal**
Les messages du journal indiquent quelles partitions présentent des échecs d'amorçage et le nombre d'échecs d'amorçage correspondant.
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - INFO - Partitions
bootstrap failure count: {'queue1': 2}, cluster will be set into protected mode if protected failure count reach threshold.
```
Dans le `clustermgtd` journal, recherchez le `Found the following bootstrap failure nodes` nœud qui n'a pas pu démarrer.
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - WARNING -
Found the following bootstrap failure nodes: (x2) ['queue1-st-c5large-1(192.168.110.155)', 'broken-st-c5large-2(192.168.65.215)']
```
Dans le `clustermgtd` journal, recherchez `Node bootstrap error` la raison de l'échec.
```
[slurm_plugin.clustermgtd:_is_node_bootstrap_failure] - WARNING - Node bootstrap error:
Node broken-st-c5large-2(192.168.65.215) is currently in replacement and no backing instance
```
**`cloud-init-output`log (`/var/log/cloud-init-output.log`) sur les nœuds de calcul**
Après avoir obtenu l'adresse IP privée du nœud de défaillance du bootstrap dans le `clustermgtd` journal, vous pouvez trouver le journal du nœud de calcul correspondant en vous connectant au nœud de calcul ou en suivant les instructions [Récupération et conservation des journaux](troubleshooting-v3-get-logs.md) pour récupérer les journaux. Dans la plupart des cas, le `/var/log/cloud-init-output` journal du nœud problématique indique l'étape à l'origine de l'échec du bootstrap du nœud de calcul.
# Slurmbasculement rapide d'une capacité insuffisante du cluster
À partir de AWS ParallelCluster la version 3.2.0, les clusters s'exécutent avec le mode de basculement rapide en cas de capacité insuffisante activé par défaut. Cela permet de réduire le temps passé à essayer à nouveau de mettre une tâche en file d'attente lorsque des erreurs liées à une capacité insuffisante d'Amazon EC2 sont détectées. Cela est particulièrement efficace lorsque vous configurez votre file d'attente avec plusieurs ressources de calcul utilisant différents types d'instances.
**Amazon EC2 a détecté des défaillances de capacité insuffisantes :**
+ `InsufficientInstanceCapacity`
+ `InsufficientHostCapacity`
+ `InsufficientReservedInstanceCapacity`
+ `MaxSpotInstanceCountExceeded`
+ `SpotMaxPriceTooLow`: Activé si le prix de la demande Spot est inférieur au prix minimum requis pour le traitement des demandes Spot.
+ `Unsupported`: Activé avec l'utilisation d'un type d'instance qui n'est pas pris en charge dans un environnement spécifique Région AWS.
En mode de défaillance rapide en cas d'insuffisance de capacité, si une erreur de capacité insuffisante est détectée lorsqu'une tâche est affectée à un [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`compute resource`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources), procédez comme suit AWS ParallelCluster :
1. Il met la ressource de calcul à l'état désactivé (`DOWN`) pendant une période prédéfinie.
1. Il est utilisé `POWER_DOWN_FORCE` pour annuler les tâches du nœud défaillant sur les ressources de calcul et pour suspendre le nœud défaillant. Il place le nœud défaillant à l'`POWER_DOWN (!)`état `IDLE` et, ensuite, à`POWERING_DOWN (%)`.
1. Il confie la tâche à une autre ressource de calcul.
Les nœuds statiques et sous tension de la ressource de calcul désactivée ne sont pas affectés. Les tâches peuvent être effectuées sur ces nœuds.
Ce cycle se répète jusqu'à ce que la tâche soit correctement assignée à un ou plusieurs nœuds de ressources informatiques. Pour plus d'informations sur les états des nœuds, consultez le[Slurmguide pour le mode de file d'attente multiple](multiple-queue-mode-slurm-user-guide-v3.md).
Si aucune ressource de calcul n'est trouvée pour exécuter la tâche, la tâche est réglée sur l'`PENDING`état jusqu'à ce que la période prédéfinie soit écoulée. Dans ce cas, vous pouvez modifier la période prédéfinie comme décrit dans la section suivante.
## Paramètre de temporisation de capacité insuffisant
**`insufficient_capacity_timeout`**
`insufficient_capacity_timeout`indique la durée (en secondes) pendant laquelle la ressource de calcul est maintenue dans l'état désactivé (`down`) lorsqu'une erreur de capacité insuffisante est détectée.
Par défaut, `insufficient_capacity_timeout` est activé.
La valeur par défaut `insufficient_capacity_timeout` est de 600 secondes (10 minutes).
Si la `insufficient_capacity_timeout` valeur est inférieure ou égale à zéro, le mode de défaillance rapide en cas d'insuffisance de capacité est désactivé.
Vous pouvez modifier la `insufficient_capacity_timeout` valeur en ajoutant le paramètre dans le fichier de `clustermgtd` configuration situé `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` dans le`HeadNode`.
Le paramètre peut être mis à jour à tout moment sans arrêter le parc informatique.
Par exemple :
+ `insufficient_capacity_timeout=600`:
Si une erreur de capacité insuffisante est détectée, la ressource de calcul est définie sur Disabled (`DOWN`). Au bout de 10 minutes, son nœud défaillant passe à l'état `idle~` (`POWER_SAVING`).
+ `insufficient_capacity_timeout=60`:
Si une erreur de capacité insuffisante est détectée, la ressource de calcul est désactivée (`DOWN`). Au bout d'une minute, son nœud défaillant est réglé sur `idle~` cet état.
+ `insufficient_capacity_timeout=0`:
Le mode de défaillance rapide en cas d'insuffisance de capacité est désactivé. La ressource de calcul n'est pas désactivée.
**Note**
Il peut s'écouler jusqu'à une minute entre le moment où les nœuds tombent en panne en raison d'erreurs de capacité insuffisante et le moment où le démon de gestion du cluster détecte les défaillances des nœuds. Cela est dû au fait que le démon de gestion du cluster vérifie les défaillances de capacité insuffisante des nœuds et définit les ressources de calcul à intervalles `down` d'une minute.
## État du mode de basculement rapide en cas de capacité insuffisante
Lorsqu'un cluster est en mode de basculement rapide en capacité insuffisante, vous pouvez vérifier son état et l'état de ses nœuds.
### États des nœuds
Lorsqu'une tâche est soumise à un nœud dynamique de ressources informatiques et qu'une erreur de capacité insuffisante est détectée, le nœud est placé dans `down#` cet état avec raison.
```
(Code:InsufficientInstanceCapacity)Failure when resuming nodes.
```
Ensuite, les nœuds éteints (nœuds en `idle~` état) sont définis `down~` avec raison.
```
(Code:InsufficientInstanceCapacity)Temporarily disabling node due to insufficient capacity.
```
La tâche est mise en file d'attente vers les autres ressources de calcul de la file d'attente.
Les nœuds statiques des ressources de calcul et les nœuds qui `UP` ne sont pas affectés par le mode de basculement rapide en capacité insuffisante.
Examinez les états des nœuds illustrés dans l'exemple suivant.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 30 idle~ queue1-dy-c-1-[1-15],queue1-dy-c-2-[1-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
Nous soumettons à queue1 une tâche qui nécessite un nœud.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 1 down# queue1-dy-c-1-1
queue1* up infinite 15 idle~ queue1-dy-c-2-[1-15]
queue1* up infinite 14 down~ queue1-dy-c-1-[2-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
`queue1-dy-c-1-1`Le nœud est lancé pour exécuter la tâche. Cependant, l'instance n'a pas pu être lancée en raison d'une erreur de capacité insuffisante. `queue1-dy-c-1-1`Le nœud est défini sur`down`. Le nœud dynamique hors tension au sein de la ressource de calcul (`queue2-dy-c-1`) est défini sur`down`.
Vous pouvez vérifier la raison du nœud avec`scontrol show nodes`.
```
$ scontrol show nodes queue1-dy-c-1-1
NodeName=broken-dy-c-2-1 Arch=x86_64 CoresPerSocket=1
CPUAlloc=0 CPUTot=96 CPULoad=0.00
...
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
Reason=(Code:InsufficientInstanceCapacity)Failure when resuming nodes [root@2022-03-10T22:17:50]
$ scontrol show nodes queue1-dy-c-1-2
NodeName=broken-dy-c-2-1 Arch=x86_64 CoresPerSocket=1
CPUAlloc=0 CPUTot=96 CPULoad=0.00
...
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
Reason=(Code:InsufficientInstanceCapacity)Temporarily disabling node due to insufficient capacity [root@2022-03-10T22:17:50]
```
La tâche est mise en file d'attente vers un autre type d'instance dans les ressources de calcul de la file d'attente.
Une fois ce `insufficient_capacity_timeout` délai écoulé, les nœuds de la ressource de calcul sont remis à l'`idle~`état.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 30 idle~ queue1-dy-c-1-[1-15],queue1-dy-c-2-[1-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
Une fois que les nœuds de la ressource de calcul se sont `insufficient_capacity_timeout` écoulés et que leur `idle~` état est rétabli, le Slurm planificateur leur attribue une priorité inférieure. Le planificateur continue de sélectionner des nœuds parmi d'autres ressources de calcul de file d'attente avec des pondérations plus élevées, sauf si l'une des situations suivantes se produit :
+ Les exigences de soumission d'une tâche correspondent à la ressource de calcul récupérée.
+ Aucune autre ressource de calcul n'est disponible car elle est à pleine capacité.
+ `slurmctld`est redémarré.
+ Le parc AWS ParallelCluster informatique est arrêté et démarre pour mettre hors tension et alimenter tous les nœuds.
### Journaux connexes
Les journaux relatifs aux erreurs de capacité insuffisante et au mode de basculement rapide en cas d'insuffisance de capacité se trouvent dans Slurm le `resume` journal et dans le `clustermgtd` journal du nœud principal.
**Slurm `resume` (`/var/log/parallelcluster/slurm_resume.log`)**
Messages d'erreur lorsqu'un nœud ne parvient pas à démarrer en raison d'une capacité insuffisante.
```
[slurm_plugin.instance_manager:_launch_ec2_instances] - ERROR - Failed RunInstances request: dcd0c252-90d4-44a7-9c79-ef740f7ecd87
[slurm_plugin.instance_manager:add_instances_for_nodes] - ERROR - Encountered exception when launching instances for nodes (x1) ['queue1-dy-c-1-1']: An error occurred
(InsufficientInstanceCapacity) when calling the RunInstances operation (reached max retries: 1): We currently do not have sufficient p4d.24xlarge capacity in the
Availability Zone you requested (us-west-2b). Our system will be working on provisioning additional capacity. You can currently get p4d.24xlarge capacity by not
specifying an Availability Zone in your request or choosing us-west-2a, us-west-2c.
```
**Slurm `clustermgtd` (`/var/log/parallelcluster/clustermgtd`)**
La ressource de calcul c-1 de la file d'attente 1 est désactivée en raison d'une capacité insuffisante.
```
[slurm_plugin.clustermgtd:_reset_timeout_expired_compute_resources] - INFO - The following compute resources are in down state
due to insufficient capacity: {'queue1': {'c-1': ComputeResourceFailureEvent(timestamp=datetime.datetime(2022, 4, 14, 23, 0, 4, 769380, tzinfo=datetime.timezone.utc),
error_code='InsufficientInstanceCapacity')}}, compute resources are reset after insufficient capacity timeout (600 seconds) expired
```
Une fois le délai d'expiration de la capacité insuffisante expiré, la ressource de calcul est réinitialisée et les nœuds des ressources de calcul sont définis sur. `idle~`
```
[root:_reset_insufficient_capacity_timeout_expired_nodes] - INFO - Reset the following compute resources because insufficient capacity
timeout expired: {'queue1': ['c-1']}
```
# Slurm planification basée sur la mémoire
À partir de la version 3.2.0, prend en charge AWS ParallelCluster Slurm planification basée sur la mémoire avec le paramètre de configuration [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[`EnableMemoryBasedScheduling`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-EnableMemoryBasedScheduling)cluster.
**Note**
À partir de AWS ParallelCluster la version 3.7.0, elle `EnableMemoryBasedScheduling` peut être activée si vous configurez plusieurs types d'[instances dans Instances](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances).
Pour AWS ParallelCluster les versions 3.2.0 à 3.6. *x*, ne `EnableMemoryBasedScheduling` peut pas être activé si vous configurez plusieurs types d'[instances dans Instances](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances).
**Avertissement**
Lorsque vous spécifiez plusieurs types d'instances dans un Slurm ressource de calcul en file d'attente `EnableMemoryBasedScheduling` activée, la `RealMemory` valeur est la quantité minimale de mémoire mise à la disposition de tous les types d'instances. Cela peut entraîner d'importantes quantités de mémoire inutilisées si vous spécifiez des types d'instances dotés de capacités de mémoire très différentes.
Avec`EnableMemoryBasedScheduling: true`, le Slurm le planificateur suit la quantité de mémoire requise par chaque tâche sur chaque nœud. Ensuite, le Slurm Le planificateur utilise ces informations pour planifier plusieurs tâches sur le même nœud de calcul. La quantité totale de mémoire requise par les tâches sur un nœud ne peut pas être supérieure à la mémoire disponible du nœud. Le planificateur empêche une tâche d'utiliser plus de mémoire que ce qui a été demandé lors de la soumission de la tâche.
Avec`EnableMemoryBasedScheduling: false`, les tâches peuvent se disputer la mémoire sur un nœud partagé et provoquer des échecs et `out-of-memory` des événements.
**Avertissement**
Slurm utilise une notation de puissance 2 pour ses étiquettes, telles que MB ou GB. Lisez ces étiquettes sous la forme MiB et GiB, respectivement.
## Slurm configuration et planification basée sur la mémoire
Avec`EnableMemoryBasedScheduling: true`, Slurm définit ce qui suit Slurm paramètres de configuration :
+ [https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory](https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory) dans le `slurm.conf`. Cette option configure la mémoire des nœuds comme une ressource consommable dans Slurm.
+ [https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace](https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace)dans le Slurm `cgroup.conf`. Avec cette option, l'accès à la mémoire d'une tâche est limité à la quantité de mémoire demandée lors de son envoi.
**Note**
Plusieurs autres Slurm les paramètres de configuration peuvent avoir un impact sur le comportement du Slurm planificateur et gestionnaire de ressources lorsque ces deux options sont définies. Pour de plus amples informations, veuillez consulter le [.Slurm De la documentation](https://slurm.schedmd.com/documentation.html).
## Slurm planificateur et planification basée sur la mémoire
**`EnableMemoryBasedScheduling: false`(par défaut)**
Par défaut, `EnableMemoryBasedScheduling` est défini sur false. Lorsque c'est faux, Slurm n'inclut pas la mémoire en tant que ressource dans son algorithme de planification et ne suit pas la mémoire utilisée par les tâches. Les utilisateurs peuvent spécifier l'`--mem MEM_PER_NODE`option permettant de définir la quantité minimale de mémoire par nœud requise par une tâche. Cela oblige le planificateur à choisir des nœuds avec une `RealMemory` valeur d'au moins égale à `MEM_PER_NODE` lors de la planification de la tâche.
Supposons, par exemple, qu'un utilisateur soumette deux tâches avec`--mem=5GB`. Si les ressources demandées telles que CPUs ou GPUs sont disponibles, les tâches peuvent être exécutées simultanément sur un nœud doté de 8 GiB de mémoire. Les deux tâches ne sont pas planifiées sur des nœuds de calcul de moins de 5 GiB de. `RealMemory`
**Avertissement**
Lorsque la planification basée sur la mémoire est désactivée, Slurm ne suit pas la quantité de mémoire utilisée par les tâches. Les tâches exécutées sur le même nœud peuvent se faire concurrence pour les ressources de mémoire et entraîner l'échec de l'autre tâche.
Lorsque la planification basée sur la mémoire est désactivée, nous recommandons aux utilisateurs de ne pas spécifier les options [https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu)ou [https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu). Ces options peuvent entraîner un comportement différent de celui décrit dans le [Slurm De la documentation](https://slurm.schedmd.com/documentation.html).
**`EnableMemoryBasedScheduling: true`**
Lorsque `EnableMemoryBasedScheduling` ce paramètre est défini sur true, Slurm suit l'utilisation de la mémoire de chaque tâche et empêche les tâches d'utiliser plus de mémoire que ce qui est demandé avec les options de `--mem` soumission.
Dans l'exemple précédent, un utilisateur soumet deux tâches avec`--mem=5GB`. Les tâches ne peuvent pas être exécutées en même temps sur un nœud doté de 8 GiB de mémoire. Cela est dû au fait que la quantité totale de mémoire requise est supérieure à la mémoire disponible sur le nœud.
Lorsque la planification basée sur la mémoire est activée `--mem-per-cpu` et que vous vous `--mem-per-gpu` comportez conformément à ce qui est décrit dans le Slurm . Par exemple, une tâche est soumise avec`--ntasks-per-node=2 -c 1 --mem-per-cpu=2GB`. Dans ce cas, Slurm attribue à la tâche un total de 4 GiB pour chaque nœud.
**Avertissement**
Lorsque la planification basée sur la mémoire est activée, nous recommandons aux utilisateurs d'inclure une `--mem` spécification lors de la soumission d'une tâche. Avec la valeur par défaut Slurm configuration incluse avec AWS ParallelCluster, si aucune option de mémoire n'est incluse (`--mem`,`--mem-per-cpu`, ou`--mem-per-gpu`), Slurm affecte la totalité de la mémoire des nœuds alloués à la tâche, même si elle ne demande qu'une partie des autres ressources, telles que CPUs ou GPUs. Cela empêche efficacement le partage de nœuds tant que la tâche n'est pas terminée, car aucune mémoire n'est disponible pour les autres tâches. Cela se produit parce que Slurm définit la mémoire par nœud pour la tâche comme [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode)si aucune spécification de mémoire n'est fournie au moment de la soumission de la tâche. La valeur par défaut de ce paramètre est 0 et indique un accès illimité à la mémoire d'un nœud.
Si plusieurs types de ressources informatiques avec différentes quantités de mémoire sont disponibles dans la même file d'attente, une tâche soumise sans options de mémoire peut se voir attribuer différentes quantités de mémoire sur différents nœuds. Cela dépend des nœuds que le planificateur met à la disposition de la tâche. Les utilisateurs peuvent définir une valeur personnalisée pour les options, telles que `DefMemPerNode` ou [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU), au niveau du cluster ou de la partition dans Slurm des fichiers de configuration pour empêcher ce comportement.
## Slurm RealMemory et AWS ParallelCluster SchedulableMemory
Avec le plugin Slurm configuration fournie avec AWS ParallelCluster, Slurm est interprété [RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory)comme étant la quantité de mémoire par nœud disponible pour les tâches. À partir de la version 3.2.0, la valeur par défaut AWS ParallelCluster est `RealMemory` fixée à 95 % de la mémoire répertoriée dans les [types d' EC2 instance Amazon](https://aws.amazon.com/ec2/instance-types) et renvoyée par l' EC2 API [DescribeInstanceTypes](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTypes.html)Amazon.
Lorsque la planification basée sur la mémoire est désactivée, Slurm le planificateur est utilisé `RealMemory` pour filtrer les nœuds lorsque les utilisateurs soumettent une tâche avec `--mem` une valeur spécifiée.
Lorsque la planification basée sur la mémoire est activée, Slurm le planificateur est interprété `RealMemory` comme étant la quantité maximale de mémoire disponible pour les tâches exécutées sur le nœud de calcul.
Le paramètre par défaut n'est peut-être pas optimal pour tous les types d'instances :
+ Ce paramètre peut être supérieur à la quantité de mémoire à laquelle les nœuds peuvent réellement accéder. Cela peut se produire lorsque les nœuds de calcul sont de petits types d'instances.
+ Ce paramètre peut être inférieur à la quantité de mémoire à laquelle les nœuds peuvent réellement accéder. Cela peut se produire lorsque les nœuds de calcul sont des types d'instances de grande taille et peuvent entraîner une quantité importante de mémoire inutilisée.
Vous pouvez utiliser [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`SchedulableMemory`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-SchedulableMemory)pour affiner la valeur de `RealMemory` configure by AWS ParallelCluster pour les nœuds de calcul. Pour remplacer la valeur par défaut, définissez une valeur personnalisée `SchedulableMemory` spécifiquement adaptée à la configuration de votre cluster.
Pour vérifier la mémoire réellement disponible d'un nœud de calcul, exécutez la `/opt/slurm/sbin/slurmd -C` commande sur le nœud. Cette commande renvoie la configuration matérielle du nœud, y compris la [https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory)valeur. Pour de plus amples informations, veuillez consulter [https://slurm.schedmd.com/slurmd.html#OPT_-C](https://slurm.schedmd.com/slurmd.html#OPT_-C).
Assurez-vous que les processus du système d'exploitation du nœud de calcul disposent de suffisamment de mémoire. Pour ce faire, limitez la mémoire disponible pour les tâches en définissant `SchedulableMemory` une valeur inférieure à la `RealMemory` valeur renvoyée par la `slurmd -C` commande.
# Allocation de plusieurs types d'instances avec Slurm
À partir de AWS ParallelCluster la version 3.3.0, vous pouvez configurer votre cluster pour qu'il alloue à partir de l'ensemble de types d'instances définis d'une ressource de calcul. L'allocation peut être basée sur des stratégies de faible coût ou de capacité optimale de la EC2 flotte Amazon.
Cet ensemble de types d'instances définis doit tous avoir le même nombre de v CPUs ou, si le multithreading est désactivé, le même nombre de cœurs. De plus, cet ensemble de types d'instances doit comporter le même nombre d'accélérateurs du même fabricant. Si [`Efa`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa)/[`Enabled`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa-Enabled)est défini sur`true`, les instances doivent être compatibles avec l'EFA. Pour plus d'informations et pour connaître les exigences, consultez [`Scheduling`[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)](Scheduling-v3.md)//[`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy)et [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances).
Vous pouvez [`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy)choisir `lowest-price` ou `capacity-optimized` en fonction de votre [CapacityType](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CapacityType)configuration.
Dans [`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances), vous pouvez configurer un ensemble de types d'instances.
**Note**
À partir de AWS ParallelCluster la version 3.7.0, elle `EnableMemoryBasedScheduling` peut être activée si vous configurez plusieurs types d'[instances dans Instances](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances).
Pour AWS ParallelCluster les versions 3.2.0 à 3.6. *x*, ne `EnableMemoryBasedScheduling` peut pas être activé si vous configurez plusieurs types d'[instances dans Instances](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances).
Les exemples suivants montrent comment interroger les types d'instances pour vCPUs, le support EFA et l'architecture.
Requête InstanceTypes avec architecture 96 v CPUs et x86\$164.
```
$ aws ec2 describe-instance-types --region region-id \
--filters "Name=vcpu-info.default-vcpus,Values=96" "Name=processor-info.supported-architecture,Values=x86_64" \
--query "sort_by(InstanceTypes[*].{InstanceType:InstanceType,MemoryMiB:MemoryInfo.SizeInMiB,CurrentGeneration:CurrentGeneration,VCpus:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Architecture:ProcessorInfo.SupportedArchitectures[0],MaxNetworkCards:NetworkInfo.MaximumNetworkCards,EfaSupported:NetworkInfo.EfaSupported,GpuCount:GpuInfo.Gpus[0].Count,GpuManufacturer:GpuInfo.Gpus[0].Manufacturer}, &InstanceType)" \
--output table
```
Requête InstanceTypes avec 64 cœurs, support EFA et architecture arm64.
```
$ aws ec2 describe-instance-types --region region-id \
--filters "Name=vcpu-info.default-cores,Values=64" "Name=processor-info.supported-architecture,Values=arm64" "Name=network-info.efa-supported,Values=true" --query "sort_by(InstanceTypes[*].{InstanceType:InstanceType,MemoryMiB:MemoryInfo.SizeInMiB,CurrentGeneration:CurrentGeneration,VCpus:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Architecture:ProcessorInfo.SupportedArchitectures[0],MaxNetworkCards:NetworkInfo.MaximumNetworkCards,EfaSupported:NetworkInfo.EfaSupported,GpuCount:GpuInfo.Gpus[0].Count,GpuManufacturer:GpuInfo.Gpus[0].Manufacturer}, &InstanceType)" \
--output table
```
L'exemple d'extrait de configuration de cluster suivant montre comment vous pouvez les utiliser. InstanceType and AllocationStrategy propriétés.
```
...
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue-1
CapacityType: ONDEMAND
AllocationStrategy: lowest-price
...
ComputeResources:
- Name: computeresource1
Instances:
- InstanceType: r6g.2xlarge
- InstanceType: m6g.2xlarge
- InstanceType: c6g.2xlarge
MinCount: 0
MaxCount: 500
- Name: computeresource2
Instances:
- InstanceType: m6g.12xlarge
- InstanceType: x2gd.12xlarge
MinCount: 0
MaxCount: 500
...
```
# Mise à l'échelle du cluster pour les nœuds dynamiques
ParallelCluster les méthodes Slurm de supports pour dimensionner dynamiquement les clusters en utilisant Slurm le plugin d'économie d'énergie. Pour plus d'informations, consultez le [guide de planification dans le cloud](https://slurm.schedmd.com/elastic_computing.html) et le [guide d'économie d'Slurménergie](https://slurm.schedmd.com/power_save.html) dans la Slurm documentation. Les rubriques suivantes décrivent les Slurm stratégies pour chaque version.
**Topics**
+ [
# Slurmstratégies d'allocation dynamique de nœuds dans la version 3.8.0
](scheduler-node-allocation-v3-3.8.0.md)
+ [
# Slurmstratégies d'allocation dynamique de nœuds dans la version 3.7.x
](scheduler-dynamic-node-allocation-v3-3.7.x.md)
+ [
# Slurmstratégies d'allocation dynamique de nœuds dans les versions 3.6.x et antérieures
](scheduler-dynamic-node-allocation-v3-3.6.x.md)
# Slurmstratégies d'allocation dynamique de nœuds dans la version 3.8.0
À partir de ParallelCluster la version 3.8.0, ParallelCluster utilise **la reprise au niveau** du **travail ou le dimensionnement au niveau** du travail comme stratégie d'allocation dynamique de nœuds par défaut pour dimensionner le cluster : ParallelCluster augmente le cluster en fonction des exigences de chaque tâche, du nombre de nœuds alloués à la tâche et des nœuds devant être repris. ParallelCluster obtient ces informations à partir de la variable d'environnement SLURM\$1RESUME\$1FILE.
Le dimensionnement pour les nœuds dynamiques est un processus en deux étapes, qui implique le lancement des instances EC2 et l'attribution des instances Amazon EC2 lancées aux Slurm nœuds. Chacune de ces deux étapes peut être réalisée en utilisant une **all-or-nothing**logique basée sur **le meilleur effort**.
Pour le lancement des instances Amazon EC2 :
+ **all-or-nothing**appelle l'API de lancement Amazon EC2 avec une cible minimale égale à la capacité cible totale
+ **best-effort** appelle le lancement de l'API Amazon EC2 avec une cible minimale égale à 1 et une capacité cible totale égale à la capacité demandée
Pour l'attribution des instances Amazon EC2 aux Slurm nœuds :
+ **all-or-nothing**attribue des instances Amazon EC2 Slurm à des nœuds uniquement s'il est possible d'attribuer une instance Amazon EC2 à chaque nœud demandé
+ **tout est fait pour** attribuer les instances Amazon EC2 Slurm aux nœuds, même si tous les nœuds demandés ne sont pas couverts par la capacité des instances Amazon EC2
Les combinaisons possibles des stratégies ci-dessus se traduisent par les stratégies de ParallelCluster lancement.
**Example** [ ScalingStrategy](Scheduling-v3.md#yaml-Scheduling-ScalingStrategy)
**all-or-nothing**mise à l'échelle :
Cette stratégie implique de AWS ParallelCluster lancer un appel d'API d'instance de lancement Amazon EC2 pour chaque tâche, ce qui nécessite le lancement réussi de toutes les instances nécessaires au lancement des nœuds de calcul demandés. Cela garantit que le cluster évolue uniquement lorsque la capacité requise par tâche est disponible, évitant ainsi de laisser des instances inactives à la fin du processus de dimensionnement.
La stratégie utilise une **all-or-nothing**logique pour le lancement des instances Amazon EC2 pour chaque tâche et une **all-or-nothing**logique pour l'attribution des instances Amazon EC2 aux nœuds. Slurm
Les groupes de stratégie lancent les demandes par lots, un pour chaque ressource de calcul demandée et jusqu'à 500 nœuds chacun. Pour les demandes couvrant plusieurs ressources informatiques ou dépassant 500 nœuds, traite plusieurs lots de ParallelCluster manière séquentielle.
La défaillance du lot d'une ressource unique entraîne l'arrêt de toutes les capacités inutilisées associées, garantissant ainsi qu'aucune instance inactive ne sera laissée à la fin du processus de dimensionnement.
Limitations
+ Le temps nécessaire à la mise à l'échelle est directement proportionnel au nombre de tâches soumises par exécution du programme de Slurm CV.
+ L'opération de dimensionnement est limitée par la limite du compte de RunInstances ressources, fixée à 1 000 instances par défaut. Cette limitation est conforme aux politiques AWS de limitation des API EC2. Pour plus de détails, consultez la documentation relative à la limitation des API [Amazon](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html) EC2
+ Lorsque vous soumettez une tâche dans une ressource de calcul avec un seul type d'instance, dans une file d'attente qui couvre plusieurs zones de disponibilité, l'appel d'API de lancement **all-or-nothing**EC2 ne réussit que si toute la capacité peut être fournie dans une seule zone de disponibilité.
+ Lorsque vous soumettez une tâche dans une ressource de calcul comportant plusieurs types d'instances, dans une file d'attente avec une seule zone de disponibilité, l'appel d'API de lancement **all-or-nothing**Amazon EC2 ne réussit que si toute la capacité peut être fournie par un seul type d'instance.
+ Lorsque vous soumettez une tâche dans une ressource de calcul comportant plusieurs types d'instances, dans une file d'attente couvrant plusieurs zones de disponibilité, l'appel d'API de lancement **all-or-nothing**Amazon EC2 n'est pas pris en charge et ParallelCluster effectue plutôt un **dimensionnement optimal.**
**greedy-all-or-nothing**mise à l'échelle :
Cette variante de la all-or-nothing stratégie garantit toujours que le cluster évolue uniquement lorsque la capacité requise par tâche est disponible, évitant ainsi les instances inactives à la fin du processus de dimensionnement, mais elle implique de ParallelCluster lancer un appel d'API d'instance de lancement Amazon EC2 qui vise une capacité cible minimale de 1, dans le but de maximiser le nombre de nœuds lancés jusqu'à la capacité demandée. La stratégie utilise une logique basée sur le meilleur effort pour le lancement des instances EC2 pour toutes les tâches, ainsi que la **all-or-nothing**logique d'attribution des instances Amazon EC2 Slurm aux nœuds pour chaque tâche.
Les groupes de stratégie lancent les demandes par lots, un pour chaque ressource de calcul demandée et jusqu'à 500 nœuds chacun. Pour les demandes couvrant plusieurs ressources informatiques ou dépassant 500 nœuds, traite plusieurs lots de ParellelCluster manière séquentielle.
Cela garantit qu'aucune instance inactive ne sera laissée à la fin du processus de dimensionnement, en maximisant le débit au prix d'un surdimensionnement temporaire pendant le processus de dimensionnement.
Limitations
+ Un surdimensionnement temporaire est possible, ce qui entraîne des coûts supplémentaires pour les instances qui passent à l'état actif avant la fin du dimensionnement.
+ La même limite d'instance que dans la all-or-nothing stratégie s'applique, sous réserve de AWS la limite du compte de RunInstances ressources.
mise **à l'**échelle optimale :
Cette stratégie appelle l'API de l'instance de lancement Amazon EC2 en ciblant une capacité minimale de 1 et en visant à atteindre la capacité totale demandée au prix de laisser les instances inactives après l'exécution du processus de dimensionnement si toutes les capacités demandées ne sont pas disponibles. La stratégie utilise une logique du meilleur effort pour le lancement des instances Amazon EC2 pour toutes les tâches, ainsi que la logique du meilleur effort pour **l'**attribution des instances Amazon EC2 aux nœuds Slurm pour chaque tâche.
Les groupes de stratégie lancent les demandes par lots, un pour chaque ressource de calcul demandée et jusqu'à 500 nœuds chacun. Pour les demandes couvrant plusieurs ressources informatiques ou dépassant 500 nœuds, traite plusieurs lots de ParallelCluster manière séquentielle.
Cette stratégie permet une mise à l'échelle bien au-delà de la limite par défaut de 1 000 instances lors de l'exécution de plusieurs processus de dimensionnement, au prix d'instances inactives au cours des différents processus de dimensionnement.
Limitations
+ Instances inactives possibles à la fin du processus de dimensionnement, dans le cas où il n'est pas possible d'allouer tous les nœuds demandés par les tâches.
L'exemple suivant montre le comportement de la mise à l'échelle des nœuds dynamiques à l'aide des différentes **stratégies de ParallelCluster lancement**. Supposons que vous ayez soumis deux tâches demandant 20 nœuds chacune, pour un total de 40 nœuds du même type, mais que seules 30 instances Amazon EC2 soient disponibles pour couvrir la capacité demandée sur EC2.
**all-or-nothing**mise à l'échelle :
+ Pour la première tâche, une API d'instance de lancement ** all-or-nothing**Amazon EC2 est appelée, demandant 20 instances. Un appel réussi entraîne le lancement de 20 instances
+ **all-or-nothing **l'attribution des 20 instances lancées aux Slurm nœuds pour la première tâche est réussie
+ Une autre API d'instance de lancement **all-or-nothing**Amazon EC2 est appelée, demandant 20 instances pour la deuxième tâche. L'appel n'aboutit pas, car il n'y a de capacité que pour 10 autres instances. Aucune instance n'est lancée pour le moment
**greedy-all-or-nothing**mise à l'échelle :
+ Une **API d'**instance de lancement Amazon EC2 est appelée, demandant 40 instances, ce qui correspond à la capacité totale demandée par toutes les tâches. Cela se traduit par le lancement de 30 instances
+ Une **all-or-nothing**affectation de 20 des instances lancées aux Slurm nœuds pour la première tâche est réussie
+ Une autre **all-or-nothing**attribution des instances lancées restantes aux Slurm nœuds pour la deuxième tâche est tentée, mais comme il n'y a que 10 instances disponibles sur un total de 20 demandées par la tâche, l'attribution échoue
+ Les 10 instances lancées non assignées sont résiliées
mise **à l'**échelle optimale :
+ Une **API d'**instance de lancement Amazon EC2 est appelée, demandant 40 instances, ce qui correspond à la capacité totale demandée par toutes les tâches. Cela se traduit par le lancement de 30 instances.
+ Une **affectation optimale** de 20 des instances lancées à des Slurm nœuds pour la première tâche est réussie.
+ Une autre **affectation optimale** des 10 instances lancées restantes aux Slurm nœuds pour la deuxième tâche est couronnée de succès, même si la capacité totale demandée était de 20. Mais comme la tâche demandait les 20 nœuds et qu'il était possible d'attribuer des instances Amazon EC2 à seulement 10 d'entre eux, la tâche ne peut pas démarrer et les instances restent inactives, jusqu'à ce que la capacité soit trouvée suffisante pour démarrer les 10 instances manquantes lors d'un appel ultérieur du processus de dimensionnement, ou que le planificateur planifie la tâche sur d'autres nœuds de calcul déjà en cours d'exécution.
# Slurmstratégies d'allocation dynamique de nœuds dans la version 3.7.x
ParallelCluster utilise deux types de stratégies d'allocation dynamique de nœuds pour dimensionner le cluster :
+
**Allocation basée sur les informations de nœud demandées disponibles :**
+ Reprise **de tous les nœuds ou mise** à l'échelle de la **liste des nœuds** :
ParallelCluster augmente le cluster en fonction uniquement des noms Slurm de liste de nœuds demandés lors Slurm de son `ResumeProgram` exécution. Il alloue les ressources de calcul aux nœuds uniquement par nom de nœud. La liste des noms de nœuds peut couvrir plusieurs tâches.
+ **CV au niveau du poste** ou mise à l'échelle du **poste** :
ParallelCluster fait évoluer le cluster en fonction des exigences de chaque tâche, du nombre actuel de nœuds alloués à la tâche et des nœuds devant être réactivés. ParallelCluster obtient ces informations à partir de la variable d'`SLURM_RESUME_FILE`environnement.
+
**Allocation avec une stratégie de lancement d'Amazon EC2 :**
+ Mise **à l'**échelle optimale :
ParallelCluster augmente le cluster en utilisant un appel d'API d'instance de lancement Amazon EC2 avec une capacité cible minimale égale à 1, pour lancer certaines instances, mais pas nécessairement toutes, nécessaires pour prendre en charge les nœuds demandés.
+ **Une ll-or-nothing** mise à l'échelle :
ParallelCluster augmente le cluster en utilisant un appel d'API d'instance de lancement Amazon EC2 qui ne réussit que si toutes les instances nécessaires pour prendre en charge les nœuds demandés sont lancées. Dans ce cas, il appelle l'API de l'instance de lancement Amazon EC2 avec une capacité cible minimale égale à la capacité totale demandée.
Par défaut, ParallelCluster utilise le dimensionnement **des listes** de nœuds avec une stratégie **de lancement optimale** d'Amazon EC2 pour lancer certaines instances, mais pas nécessairement toutes, nécessaires pour prendre en charge les nœuds demandés. Il essaie de fournir autant de capacité que possible pour répondre à la charge de travail soumise.
**À partir de ParallelCluster la version 3.7.0, ParallelCluster utilise le dimensionnement **au niveau** des tâches avec une stratégie de lancement **all-or-nothing**EC2 pour les tâches soumises en mode exclusif.** Lorsque vous soumettez une tâche en mode exclusif, la tâche dispose d'un accès exclusif aux nœuds qui lui sont alloués. Pour plus d'informations, consultez [EXCLUSIVE](https://slurm.schedmd.com/slurm.conf.html#OPT_EXCLUSIVE) dans la Slurm documentation.
Pour soumettre une offre d'emploi en mode exclusif :
+ Passez le drapeau exclusif lorsque vous soumettez une Slurm tâche au cluster. Par exemple, `sbatch ... --exclusive`.
OU
+ Soumettez une tâche à une file d'attente de cluster configurée avec la valeur [`JobExclusiveAllocation`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-JobExclusiveAllocation)définie sur`true`.
Lorsque vous soumettez une offre d'emploi en mode exclusif :
+ ParallelCluster traite actuellement par lots les demandes de lancement pour inclure jusqu'à 500 nœuds. Si une tâche demande plus de 500 nœuds, ParallelCluster effectue une demande de **all-or-nothing**lancement pour chaque ensemble de 500 nœuds et une demande de lancement supplémentaire pour le reste des nœuds.
+ Si l'allocation de nœuds se fait dans une seule ressource de calcul, ParallelCluster effectue une demande de **all-or-nothing**lancement pour chaque ensemble de 500 nœuds et une demande de lancement supplémentaire pour le reste des nœuds. Si une demande de lancement échoue, ParallelCluster met fin à la capacité inutilisée créée par toutes les demandes de lancement.
+ Si l'allocation de nœuds couvre plusieurs ressources de calcul, vous ParallelCluster devez effectuer une demande de **all-or-nothing**lancement pour chaque ressource de calcul. Ces demandes sont également groupées. Si une demande de lancement échoue pour l'une des ressources de calcul, ParallelCluster met fin à la capacité inutilisée créée par toutes les demandes de lancement de ressources de calcul.
mise **à l'échelle au niveau** des tâches avec limites connues de la stratégie de **all-or-nothing**lancement :
+ Lorsque vous soumettez une tâche dans une ressource de calcul avec un seul type d'instance, dans une file d'attente qui couvre plusieurs zones de disponibilité, l'appel d'API de lancement **all-or-nothing**EC2 ne réussit que si toute la capacité peut être fournie dans une seule zone de disponibilité.
+ Lorsque vous soumettez une tâche dans une ressource de calcul comportant plusieurs types d'instances, dans une file d'attente avec une seule zone de disponibilité, l'appel d'API de lancement **all-or-nothing**Amazon EC2 ne réussit que si toute la capacité peut être fournie par un seul type d'instance.
+ Lorsque vous soumettez une tâche dans une ressource de calcul comportant plusieurs types d'instances, dans une file d'attente couvrant plusieurs zones de disponibilité, l'appel d'API de lancement **all-or-nothing**Amazon EC2 n'est pas pris en charge et ParallelCluster effectue plutôt un **dimensionnement optimal.**
# Slurmstratégies d'allocation dynamique de nœuds dans les versions 3.6.x et antérieures
AWS ParallelCluster utilise un seul type de stratégie d'allocation dynamique de nœuds pour dimensionner le cluster :
+ Allocation basée sur les informations de nœud demandées disponibles :
+ Reprise de **tous les nœuds** **ou dimensionnement de la liste** de nœuds ParallelCluster : augmente le cluster en fonction des noms de liste Slurm de nœuds demandés lors Slurm de son exécution. `ResumeProgram` Il alloue les ressources de calcul aux nœuds uniquement par nom de nœud. La liste des noms de nœuds peut couvrir plusieurs tâches.
+ Allocation avec une stratégie de lancement d'Amazon EC2 :
+ **Mise à** l' ParallelCluster échelle optimale : augmentez le cluster en utilisant un appel d'API d'instance de lancement Amazon EC2 avec une capacité cible minimale égale à 1, pour lancer certaines instances, mais pas nécessairement toutes, nécessaires pour prendre en charge les nœuds demandés.
ParallelCluster utilise le dimensionnement **des listes de nœuds** dans le cadre d'**une** stratégie de lancement optimale d'Amazon EC2 pour lancer certaines instances, mais pas nécessairement toutes, nécessaires pour prendre en charge les nœuds demandés. Il essaie de fournir autant de capacité que possible pour répondre à la charge de travail soumise.
Limitations
+ Instances inactives possibles à la fin du processus de dimensionnement, dans le cas où il n'est pas possible d'allouer tous les nœuds demandés par les tâches.
# Slurmcomptabilité avec AWS ParallelCluster
À partir de la version 3.3.0, AWS ParallelCluster prend en charge la Slurm comptabilité avec le paramètre de configuration du cluster [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database).
À partir de la version 3.10.0, AWS ParallelCluster prend en charge la Slurm comptabilité avec un Slurmdbd externe avec le paramètre de configuration du cluster/. [SlurmSettings[ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd)](Scheduling-v3.md#Scheduling-v3-SlurmSettings) L'utilisation d'un Slurmdbd externe est recommandée si plusieurs clusters partagent la même base de données.
Avec la Slurm comptabilité, vous pouvez intégrer une base de données comptable externe pour effectuer les opérations suivantes :
+ Gérez les utilisateurs du cluster ou les groupes d'utilisateurs et les autres entités. Grâce à cette fonctionnalité, vous pouvez utiliser Slurm les fonctionnalités les plus avancées, telles que l'application des limites de ressources, le partage équitable et. QOSs
+ Collectez et enregistrez des données de travail, telles que l'utilisateur qui a exécuté le travail, la durée du travail et les ressources qu'il utilise. Vous pouvez consulter les données enregistrées à l'aide de l'`sacct`utilitaire.
**Note**
AWS ParallelCluster prend en charge Slurm la comptabilisation des [serveurs de base de données MySQL Slurm pris](https://slurm.schedmd.com/accounting.html#mysql-configuration) en charge.
## Utilisation de la Slurm comptabilité à l'aide d'un outil externe Slurmdbd dans les AWS ParallelCluster versions 3.10.0 et ultérieures
Avant de configurer la gestion des Slurm comptes, vous devez disposer d'un serveur de Slurmdbd base de données externe existant, qui se connecte à un serveur de base de données externe existant.
Pour configurer cela, définissez les éléments suivants :
+ L'adresse du Slurmdbd serveur externe dans [ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd)/[Host](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ExternalSlurmdbd-Host). Le serveur doit exister et être accessible depuis le nœud principal.
+ La touche munge permettant de communiquer avec le Slurmdbd serveur externe. [MungeKeySecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-MungeKeySecretArn)
Pour suivre un didacticiel étape par étape, voir[Création d'un cluster avec un module externe Slurmdbd comptabilité](external-slurmdb-accounting.md).
**Note**
Vous êtes responsable de la gestion des entités comptables Slurm de la base de données.
L'architecture de la fonctionnalité de SlurmDB support AWS ParallelCluster externe permet à plusieurs clusters de partager SlurmDB la même base de données.
![\[\]](http://docs.aws.amazon.com/fr_fr/parallelcluster/latest/ug/images/External_Slurmdbd_Architecture_ASG.png)
**Avertissement**
Le trafic entre AWS ParallelCluster et l'extérieur n'SlurmDBest pas crypté. Il est recommandé d'exécuter le cluster et l'interface externe SlurmDB sur un réseau sécurisé.
## Utilisation de la Slurm comptabilité à l'aide du nœud principal Slurmdbd dans les AWS ParallelCluster versions 3.3.0 et ultérieures
Avant de configurer la gestion des Slurm comptes, vous devez disposer d'un serveur de base de données externe existant et d'une base de données utilisant `mysql` le protocole.
Pour configurer la Slurm comptabilité avec AWS ParallelCluster, vous devez définir les éléments suivants :
+ L'URI du serveur de base de données externe dans [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[Uri](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-Uri). Le serveur doit exister et être accessible depuis le nœud principal.
+ Informations d'identification pour accéder à la base de données externe définies dans [Base de données](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn)et [Base de données](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[UserName](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-UserName). AWS ParallelCluster utilise ces informations pour configurer la comptabilité au Slurm niveau et le `slurmdbd` service sur le nœud principal. `slurmdbd`est le daemon qui gère les communications entre le cluster et le serveur de base de données.
Pour suivre un didacticiel étape par étape, voir[Création d'un cluster avec Slurm comptabilité](tutorials_07_slurm-accounting-v3.md).
**Note**
AWS ParallelCluster exécute un bootstrap de base de données de Slurm comptabilité en définissant l'utilisateur du cluster par défaut comme administrateur de base de données dans la Slurm base de données. AWS ParallelCluster n'ajoute aucun autre utilisateur à la base de données de comptabilité. Le client est responsable de la gestion des entités comptables de la Slurm base de données.
AWS ParallelCluster [https://slurm.schedmd.com/slurmdbd.html](https://slurm.schedmd.com/slurmdbd.html)se configure pour garantir qu'un cluster possède sa propre Slurm base de données sur le serveur de base de données. Le même serveur de base de données peut être utilisé sur plusieurs clusters, mais chaque cluster possède sa propre base de données distincte. AWS ParallelCluster utilise le nom du cluster pour définir le nom de la base de données dans le [https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageLoc](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageLoc)paramètre du fichier de `slurmdbd` configuration. Considérez la situation suivante. Une base de données présente sur le serveur de base de données inclut un nom de cluster qui ne correspond pas à un nom de cluster actif. Dans ce cas, vous pouvez créer un nouveau cluster portant ce nom de cluster pour le mapper à cette base de données. Slurmréutilise la base de données pour le nouveau cluster.
**Avertissement**
Il est déconseillé de configurer plusieurs clusters pour utiliser la même base de données à la fois. Cela peut entraîner des problèmes de performances ou même des situations de blocage de la base de données.
Si la gestion des Slurm comptes est activée sur le nœud principal d'un cluster, nous vous recommandons d'utiliser un type d'instance doté d'un processeur puissant, de davantage de mémoire et d'une bande passante réseau plus importante. Slurmla comptabilité peut alourdir la charge sur le nœud principal du cluster.
Dans l'architecture actuelle de la fonctionnalité de AWS ParallelCluster Slurm comptabilité, chaque cluster possède sa propre instance du `slurmdbd` démon, comme le montrent les exemples de configuration du schéma suivant.
![\[\]](http://docs.aws.amazon.com/fr_fr/parallelcluster/latest/ug/images/slurm-acct-arch.png)
Si vous ajoutez des fonctionnalités personnalisées de Slurm multi-clusters ou de fédération à votre environnement de cluster, tous les clusters doivent faire référence à la même `slurmdbd` instance. Pour cette alternative, nous vous recommandons d'activer la gestion des AWS ParallelCluster Slurm comptes sur un cluster et de configurer manuellement les autres clusters pour `slurmdbd` qu'ils se connectent à ceux hébergés sur le premier cluster.
Si vous utilisez des AWS ParallelCluster versions antérieures à la version 3.3.0, reportez-vous à la méthode alternative pour implémenter la Slurm comptabilité décrite dans ce billet de [blog sur le HPC](https://aws.amazon.com/blogs/compute/enabling-job-accounting-for-hpc-with-aws-parallelcluster-and-amazon-rds/).
## Slurmconsidérations comptables
### Base de données et cluster sur différents VPCs
Pour activer la Slurm comptabilité, un serveur de base de données est nécessaire pour servir de backend pour les opérations de lecture et d'écriture effectuées par le `slurmdbd` démon. Avant que le cluster ne soit créé ou mis à jour pour activer la Slurm comptabilité, le nœud principal doit pouvoir accéder au serveur de base de données.
Si vous devez déployer le serveur de base de données sur un VPC autre que celui utilisé par le cluster, tenez compte des points suivants :
+ Pour permettre la communication entre le `slurmdbd` côté cluster et le serveur de base de données, vous devez configurer la connectivité entre les deux VPCs. Pour plus d'informations, consultez [VPC Peering dans le guide de l'utilisateur d'](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)*Amazon Virtual Private Cloud*.
+ Vous devez créer le groupe de sécurité que vous souhaitez associer au nœud principal sur le VPC du cluster. Une fois que les deux VPCs ont été comparés, la liaison croisée entre les groupes de sécurité côté base de données et côté cluster est disponible. Pour plus d'informations, consultez les [règles des groupes de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules) dans le *guide de l'utilisateur d'Amazon Virtual Private Cloud*.
### Configuration du chiffrement TLS entre `slurmdbd` et le serveur de base de données
Avec la configuration de Slurm comptabilité par défaut qui AWS ParallelCluster fournit, `slurmdbd` établit une connexion cryptée TLS avec le serveur de base de données, si celui-ci prend en charge le chiffrement TLS. AWS les services de base de données tels qu'Amazon RDS Amazon Aurora prennent en charge le chiffrement TLS par défaut.
Vous pouvez exiger des connexions sécurisées côté serveur en définissant le `require_secure_transport` paramètre sur le serveur de base de données. Ceci est configuré dans le CloudFormation modèle fourni.
Conformément aux meilleures pratiques de sécurité, nous vous recommandons d'activer également la vérification de l'identité du serveur sur le `slurmdbd` client. Pour ce faire, configurez le [StorageParameters](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageParameters)dans le`slurmdbd.conf`. Téléchargez le certificat CA du serveur sur le nœud principal du cluster. Définissez ensuite l'option [SSL\$1CA](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_SSL_CA) `StorageParameters` in `slurmdbd.conf` sur le chemin du certificat CA du serveur sur le nœud principal. Cela permet de vérifier l'identité du serveur sur le `slurmdbd` côté. Après avoir apporté ces modifications, redémarrez le `slurmdbd` service pour rétablir la connectivité au serveur de base de données avec la vérification d'identité activée.
### Mise à jour des identifiants de base de données
Pour mettre à jour les valeurs [de Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[UserName](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-UserName)or [PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn), vous devez d'abord arrêter le parc informatique. Supposons que la valeur secrète stockée dans le AWS Secrets Manager secret soit modifiée et que son ARN ne soit pas modifié. Dans ce cas, le cluster ne met pas automatiquement à jour le mot de passe de la base de données à la nouvelle valeur. Pour mettre à jour le cluster en fonction de la nouvelle valeur secrète, exécutez la commande suivante depuis le nœud principal.
```
$ sudo /opt/parallelcluster/scripts/slurm/update_slurm_database_password.sh
```
**Avertissement**
Pour éviter de perdre des données comptables, nous vous recommandons de ne modifier le mot de passe de la base de données que lorsque le parc informatique est arrêté.
### Surveillance des bases de données
Nous vous recommandons d'activer les fonctionnalités de surveillance des services de AWS base de données. Pour plus d'informations, consultez la documentation de [surveillance Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) ou [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/MonitoringAurora.html).
# Slurm personnalisation de la configuration
À partir de AWS ParallelCluster la version 3.6.0, vous pouvez personnaliser `slurm.conf` Slurm configuration dans une configuration de AWS ParallelCluster cluster.
Dans la configuration du cluster, vous pouvez personnaliser Slurm paramètres de configuration à l'aide des paramètres de configuration de cluster suivants :
+ Personnalisation Slurm paramètres pour l'ensemble du cluster en utilisant le paramètre [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettings)ou le [`CustomSlurmSettingsIncludeFile`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettingsIncludeFile)paramètre. AWS ParallelCluster échoue si vous spécifiez les deux.
+ Personnalisation Slurm paramètres d'une file d'attente en utilisant [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomSlurmSettings)(mappé à Slurm cloisons).
+ Personnalisation Slurm paramètres d'une ressource de calcul en utilisant [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)(mappé à Slurm nœuds).
## Slurm configuration, personnalisation, limites et considérations lors de l'utilisation AWS ParallelCluster
+ Pour `CustomSlurmSettingsIncludeFile` les paramètres `CustomSlurmSettings` et les paramètres, vous pouvez uniquement spécifier et mettre à jour les `slurm.conf` paramètres inclus dans [Slurm version ](slurm-workload-manager-v3.md) prise en charge par la AWS ParallelCluster version que vous utilisez pour configurer un cluster.
+ Si vous spécifiez une option personnalisée Slurm configure l'un des `CustomSlurmSettings` paramètres, AWS ParallelCluster effectue des contrôles de validation et empêche le réglage ou la mise à jour Slurm paramètres de configuration qui entrent en conflit avec AWS ParallelCluster la logique. Le Slurm les paramètres de configuration connus pour entrer en conflit AWS ParallelCluster sont identifiés dans les listes de refus. Les listes de refus peuvent changer dans les AWS ParallelCluster versions futures si d'autres Slurm des fonctionnalités sont ajoutées. Pour de plus amples informations, veuillez consulter [Inscrit sur la liste Deny Slurm paramètres de configuration pour `CustomSlurmSettings`](#slurm-configuration-denylists-v3).
+ AWS ParallelCluster vérifie uniquement si un paramètre figure dans une liste de refus. AWS ParallelCluster ne valide pas votre personnalisation Slurm syntaxe ou sémantique des paramètres de configuration. Vous êtes responsable de la validation de votre personnalisation Slurm paramètres de configuration. Personnalisation non valide Slurm les paramètres de configuration peuvent provoquer Slurm défaillances de daemon pouvant entraîner des échecs de création et de mise à jour de clusters.
+ Si vous spécifiez une option personnalisée Slurm configurations dans`CustomSlurmSettingsIncludeFile`, AWS ParallelCluster n'effectue aucune validation.
+ Vous pouvez mettre à jour `CustomSlurmSettings` et ce, `CustomSlurmSettingsIncludeFile` sans arrêter ni démarrer le parc informatique. Dans ce cas, AWS ParallelCluster redémarre le `slurmctld` daemon et exécute la `scontrol reconfigure` commande.
Momentanée Slurm les paramètres de configuration peuvent nécessiter différentes opérations avant qu'une modification ne soit enregistrée dans l'ensemble du cluster. Par exemple, ils peuvent nécessiter le redémarrage de tous les démons du cluster. Vous êtes responsable de vérifier si les AWS ParallelCluster opérations sont suffisantes pour propager votre personnalisation Slurm réglages des paramètres de configuration lors des mises à jour. Si vous estimez que AWS ParallelCluster les opérations ne sont pas suffisantes, il est de votre responsabilité de fournir les actions supplémentaires nécessaires pour propager les paramètres mis à jour, conformément aux recommandations du [Slurm documentation](https://slurm.schedmd.com/documentation.html).
## Inscrit sur la liste Deny Slurm paramètres de configuration pour `CustomSlurmSettings`
Les tableaux suivants répertorient les paramètres avec les AWS ParallelCluster versions qui refusent leur utilisation, à partir de la version 3.6.0. `CustomSlurmSettings`n'est pas pris en charge pour AWS ParallelCluster les versions antérieures à la version 3.6.0.
**Paramètres refusés au niveau du cluster :**
| Slurm paramètre | Listé par DENY dans les versions AWS ParallelCluster |
| --- | --- |
| CommunicationParameters | 3.6.0 |
| Epilogue | 3.6.0 |
| GresTypes | 3.6.0 |
| LaunchParameters | 3.6.0 |
| Prologue | 3.6.0 |
| ReconfigFlags | 3.6.0 |
| ResumeFailProgram | 3.6.0 |
| ResumeProgram | 3.6.0 |
| ResumeTimeout | 3.6.0 |
| SlurmctldHost | 3.6.0 |
| SlurmctldLogFile | 3.6.0 |
| SlurmctldParameters | 3.6.0 |
| SlurmdLogfile | 3.6.0 |
| SlurmUser | 3.6.0 |
| SuspendExcNodes | 3.6.0 |
| SuspendProgram | 3.6.0 |
| SuspendTime | 3.6.0 |
| TaskPlugin | 3.6.0 |
| TreeWidth | 3.6.0 |
**Refuser les paramètres listés au niveau du cluster lorsque le natif [Slurm l'intégration de la comptabilité](slurm-accounting-v3.md) est configurée dans la configuration du cluster :**
| Slurm paramètre | Listé par DENY dans les versions AWS ParallelCluster |
| --- | --- |
| AccountingStorageType | 3.6.0 |
| AccountingStorageHost | 3.6.0 |
| AccountingStoragePort | 3.6.0 |
| AccountingStorageUser | 3.6.0 |
| JobAcctGatherType | 3.6.0 |
**Paramètres refusés au niveau de la file d'attente (partition) pour les files d'attente gérées par : AWS ParallelCluster**
| Slurm paramètre | Listé par DENY dans les versions AWS ParallelCluster |
| --- | --- |
| Nœuds | 3.6.0 |
| PartitionName | 3.6.0 |
| ResumeTimeout | 3.6.0 |
| État | 3.6.0 |
| SuspendTime | 3.6.0 |
**Paramètres listés par refus au niveau de la ressource de calcul (nœud) pour les ressources de calcul gérées par : AWS ParallelCluster**
| Slurm paramètre | Répertorié dans la AWS ParallelCluster version et les versions ultérieures |
| --- | --- |
| CPUs | 3.6.0 |
| Fonctionnalités | 3.6.0 |
| Gres | 3.6.0 |
| NodeAddr | 3.6.0 |
| NodeHostname | 3.6.0 |
| NodeName | 3.6.0 |
| Weight | 3.7.0 |
# Slurm et `prolog` `epilog`
À partir de AWS ParallelCluster la version 3.6.0, la Slurm configuration déployée AWS ParallelCluster inclut les paramètres de `Epilog` configuration `Prolog` et :
```
# PROLOG AND EPILOG
Prolog=/opt/slurm/etc/scripts/prolog.d/*
Epilog=/opt/slurm/etc/scripts/epilog.d/*
SchedulerParameters=nohold_on_prolog_fail
BatchStartTimeout=180
```
Pour plus d'informations, consultez le [guide Prolog et Epilog](https://slurm.schedmd.com/prolog_epilog.html) dans la Slurm documentation.
AWS ParallelCluster inclut les scripts prolog et epilog suivants :
+ `90_plcuster_health_check_manager`(dans le `Prolog` dossier)
+ `90_pcluster_noop`(dans le `Epilog` dossier)
**Note**
Le `Epilog` dossier `Prolog` et doit contenir au moins un fichier.
Vous pouvez utiliser vos propres scripts `prolog` ou vos propres `epilog` scripts en les ajoutant aux `Epilog` dossiers `Prolog` et correspondants.
**Avertissement**
Slurmexécute tous les scripts des dossiers, dans l'ordre alphabétique inverse.
La durée d'exécution des `epilog` scripts `prolog` et a un impact sur le temps nécessaire à l'exécution d'une tâche. Mettez à jour le paramètre `BatchStartTimeout` de configuration lors de l'exécution de plusieurs `prolog` scripts ou de longue durée. La valeur par défaut est de 3 minutes.
Si vous utilisez `prolog` des `epilog` scripts personnalisés, localisez-les dans les `Epilog` dossiers `Prolog` et correspondants. Nous vous recommandons de conserver le `90_plcuster_health_check_manager` script qui s'exécute avant chaque script personnalisé. Pour de plus amples informations, veuillez consulter [Slurm personnalisation de la configuration](slurm-configuration-settings-v3.md).
# Taille et mise à jour de la capacité du cluster
La capacité du cluster est définie par le nombre de nœuds de calcul que le cluster peut dimensionner. Les nœuds de calcul sont soutenus par EC2 des instances Amazon définies dans les ressources de calcul de la AWS ParallelCluster configuration `(Scheduling/SlurmQueues/ ComputeResources)` et sont organisés en files d'attente `(Scheduling/SlurmQueues)` mappées 1:1 à Slurm cloisons.
Au sein d'une ressource de calcul, il est possible de configurer le nombre minimum de nœuds de calcul (instances) qui doivent toujours continuer à fonctionner dans le cluster (`MinCount`), ainsi que le nombre maximum d'instances que la ressource de calcul peut atteindre ([`MaxCount`3](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)).
Au moment de la création du cluster, ou lors d'une mise à jour du cluster, AWS ParallelCluster lance autant d' EC2 instances Amazon que cela est configuré `MinCount` pour chaque ressource de calcul (`Scheduling/SlurmQueues/ ComputeResources`) définie dans le cluster. Les instances lancées pour couvrir le nombre minimal de nœuds pour une ressource de calcul dans le cluster sont appelées ***nœuds statiques**.* Une fois démarrés, les nœuds statiques sont censés être persistants dans le cluster et le système ne les arrête pas, sauf si un événement ou une condition spécifique se produit. Ces événements incluent, par exemple, l'échec de Slurm ou les EC2 bilans de santé d'Amazon et la modification du Slurm statut du nœud : DRAIN ou DOWN.
Les EC2 instances Amazon, de l'ordre de deux `1` à `‘MaxCount - MinCount’` (`MaxCount `*moins*)` MinCount)`, lancées à la demande pour faire face à l'augmentation de la charge du cluster, sont appelées ***nœuds dynamiques***. Leur nature est éphémère, ils sont lancés pour exécuter des tâches en attente et sont interrompus une fois qu'ils restent inactifs pendant une période définie `Scheduling/SlurmSettings/ScaledownIdletime` dans la configuration du cluster (par défaut : 10 minutes).
Les nœuds statiques et les nœuds dynamiques sont conformes au schéma de dénomination suivant :
+ Nœuds statiques `-st--` où ` = 1..ComputeResource/MinCount`
+ Nœuds dynamiques `-dy--` où ` = 1..(ComputeResource/MaxCount - ComputeResource/MinCount)`
Par exemple, étant donné la AWS ParallelCluster configuration suivante :
```
Scheduling:
Scheduler: Slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 150
```
Les nœuds suivants seront définis dans Slurm
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
Lorsqu'une ressource de calcul l'est`MinCount == MaxCount`, tous les nœuds de calcul correspondants seront statiques et toutes les instances seront lancées au moment de la création/de la mise à jour du cluster et maintenues opérationnelles. Par exemple :
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 100
```
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Mise à jour des capacités du cluster
La mise à jour de la capacité du cluster inclut l'ajout ou la suppression de files d'attente, de ressources de calcul ou la modification `MinCount/MaxCount` d'une ressource de calcul. À partir de AWS ParallelCluster la version 3.9.0, la réduction de la taille d'une file d'attente nécessite que le parc de calcul soit arrêté ou [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)défini sur TERMINATE avant qu'une mise à jour du cluster n'ait lieu. Il n'est pas nécessaire d'arrêter le parc informatique ou de le [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)configurer sur TERMINATE lorsque :
+ Ajouter de nouvelles files d'attente à la planification/ [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)
+ Ajouter de nouvelles ressources de calcul `Scheduling/SlurmQueues/ComputeResources` à une file d'attente
+ Augmenter la valeur `MaxCount` d'une ressource de calcul
+ Augmentation MinCount d'une ressource de calcul et augmentation MaxCount de la même ressource de calcul d'au moins la même quantité
## Considérations et restrictions
Cette section vise à décrire tous les facteurs, contraintes ou limitations importants à prendre en compte lors du redimensionnement de la capacité du cluster.
+ Lorsque vous supprimez une file d'attente de `Scheduling/SlurmQueues` tous les nœuds de calcul dont le nom `-*` est à la fois statique et dynamique, elle sera supprimée du Slurm configuration et les EC2 instances Amazon correspondantes seront résiliées.
+ Lorsque vous supprimez une ressource `Scheduling/SlurmQueues/ComputeResources` de calcul d'une file d'attente, tous les nœuds de calcul portant un nom`-*--*`, qu'ils soient statiques ou dynamiques, seront supprimés du Slurm configuration et les EC2 instances Amazon correspondantes seront résiliées.
Lorsque vous modifiez le `MinCount` paramètre d'une ressource de calcul, nous pouvons distinguer deux scénarios différents, s'il `MaxCount` est maintenu égal à `MinCount` (capacité statique uniquement) et s'il `MaxCount` est supérieur à `MinCount` (capacité statique et dynamique mixte).
### Changements de capacité avec des nœuds statiques uniquement
+ Si`MinCount == MaxCount`, lors de l'augmentation `MinCount` (et`MaxCount`), le cluster est configuré en étendant le nombre de nœuds statiques à la nouvelle valeur de `MinCount` `-st--` et que le système continue d'essayer de lancer des EC2 instances Amazon pour atteindre la nouvelle capacité statique requise.
+ Si`MinCount == MaxCount`, lors de la diminution `MinCount` (et`MaxCount`) du montant N, le cluster est configuré en supprimant les N derniers nœuds statiques `-st--...]` et le système met fin aux EC2 instances Amazon correspondantes.
+ État initial `MinCount = MaxCount = 100`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Mise à jour `-30` sur `MinCount` et `MaxCount: MinCount = MaxCount = 70`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
### Changements de capacité avec des nœuds mixtes
Si`MinCount < MaxCount`, lors d'une augmentation `MinCount` d'un montant N (en supposant que `MaxCount` cela restera inchangé), le cluster sera configuré en étendant le nombre de nœuds statiques à la nouvelle valeur de `MinCount` (`old_MinCount + N`) : `-st--` et le système continuera d'essayer de lancer des EC2 instances Amazon pour atteindre la nouvelle capacité statique requise. De plus, pour respecter la `MaxCount` capacité de la ressource de calcul, la configuration du cluster est mise à jour en *supprimant les N derniers nœuds dynamiques* : `-dy--[...]` et le système mettra fin aux EC2 instances Amazon correspondantes.
+ État initial : `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Mettre à jour \$130 vers `MinCount : MinCount = 130 (MaxCount = 150)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Si`MinCount < MaxCount`, lors de l'augmentation `MinCount` et `MaxCount` de la même quantité N, le cluster sera configuré en étendant le nombre de nœuds statiques à la nouvelle valeur de `MinCount` (`old_MinCount + N`) : `-st--` et le système continuera à essayer de lancer des EC2 instances Amazon pour atteindre la nouvelle capacité statique requise. De plus, aucune modification ne sera apportée au nombre de nœuds dynamiques pour honorer le nouveau
Valeur `MaxCount`.
+ État initial : `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Mettre à jour \$130 vers `MinCount : MinCount = 130 (MaxCount = 180)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
Si`MinCount < MaxCount`, lors `MinCount` de la diminution du montant N (en supposant qu'il `MaxCount` restera inchangé), le cluster sera configuré en supprimant les N derniers nœuds statiques (nœuds statiques) `-st--[...` et le système mettra fin aux EC2 instances Amazon correspondantes. De plus, pour respecter la `MaxCount` capacité de la ressource de calcul, la configuration du cluster est mise à jour en augmentant le nombre de nœuds dynamiques afin de combler le vide. `MaxCount - new_MinCount: -dy--[1..]` Dans ce cas, comme il s'agit de nœuds dynamiques, aucune nouvelle EC2 instance Amazon ne sera lancée à moins que le planificateur n'ait des tâches en attente sur les nouveaux nœuds.
+ État initial : `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Mise à jour -30 le `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-80]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Si`MinCount < MaxCount`, lors de la diminution `MinCount` et `MaxCount` de la même quantité N, le cluster sera configuré en supprimant les N derniers nœuds statiques `-st--...]` et le système mettra fin aux EC2 instances Amazon correspondantes.
De plus, aucune modification ne sera apportée au nombre de nœuds dynamiques pour respecter la nouvelle `MaxCount` valeur.
+ État initial : `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Mise à jour -30 le `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
Si`MinCount < MaxCount`, lors de la diminution `MaxCount` du montant N (en supposant `MinCount` qu'il reste inchangé), le cluster est configuré en supprimant les N derniers nœuds dynamiques `-dy--]` et le système arrête les EC2 instances Amazon correspondantes dans le cas où elles étaient en cours d'exécution. Aucun impact n'est attendu sur les nœuds statiques.
+ État initial : `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ Mise à jour -30 le `MaxCount : MinCount = 100 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## Impacts sur les emplois
Dans tous les cas où des nœuds sont supprimés et des EC2 instances Amazon résiliées, une tâche sbatch exécutée sur les nœuds supprimés sera remise en file d'attente, sauf si aucun autre nœud ne répond aux exigences de la tâche. Dans ce dernier cas, la tâche échoue avec le statut NODE\$1FAIL et disparaît de la file d'attente, et elle doit être soumise à nouveau manuellement.
Si vous prévoyez d'effectuer une mise à jour de redimensionnement du cluster, vous pouvez empêcher les tâches de s'exécuter sur les nœuds qui seront supprimés lors de la mise à jour planifiée. Cela est possible en configurant les nœuds à supprimer lors de la maintenance. Sachez que le fait de configurer un nœud en maintenance n'aura aucune incidence sur les tâches qui sont déjà en cours d'exécution sur le nœud.
Supposons qu'avec la mise à jour prévue pour le redimensionnement du cluster, vous allez supprimer le `qeueu-st-computeresource-[9-10` [nœud]. Vous pouvez créer un Slurm réservation avec la commande suivante
```
sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10]
```
Cela créera un Slurm réservation nommée `maint_for_update` sur les nœuds`qeueu-st-computeresource-[9-10]`. À partir du moment où la réservation est créée, aucune autre tâche ne peut être exécutée sur les nœuds`qeueu-st-computeresource-[9-10]`. Sachez que la réservation n'empêchera pas l'attribution éventuelle de tâches sur les nœuds`qeueu-st-computeresource-[9-10]`.
Après la mise à jour du redimensionnement du cluster, si Slurm la réservation a été définie uniquement sur les nœuds qui ont été supprimés lors de la mise à jour du redimensionnement, la réservation de maintenance sera automatiquement supprimée. Si au contraire vous aviez créé un Slurm réservation sur les nœuds toujours présents après la mise à jour du redimensionnement du cluster, nous souhaiterons peut-être supprimer la réservation de maintenance sur les nœuds une fois la mise à jour du redimensionnement effectuée, à l'aide de la commande suivante
```
sudo -i scontrol delete ReservationName=maint_for_update
```
Pour plus de détails sur Slurm [réservation, voir le document officiel de SchedMD ici.](https://slurm.schedmd.com/reservations.html)
## Processus de mise à jour du cluster en cas de modification de capacité
Lors d'un changement de configuration du planificateur, les étapes suivantes sont exécutées pendant le processus de mise à jour du cluster :
+ Arrêtez AWS ParallelCluster `clustermgtd (supervisorctl stop clustermgtd)`
+ Générer des mises à Slurm configuration des partitions à partir de AWS ParallelCluster la configuration
+ Redémarrage `slurmctld` (effectué via la recette du service Chef)
+ Vérifier le `slurmctld` statut `(systemctl is-active --quiet slurmctld.service)`
+ Reload (Recharger) Slurm configuration `(scontrol reconfigure)`
+ Démarrage de `clustermgtd (supervisorctl start clustermgtd)`