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. # Utilisation des modèles de lancement Amazon EC2 avec PCS AWS Dans Amazon EC2, un modèle de lancement peut stocker un ensemble de préférences afin que vous n'ayez pas à les spécifier individuellement lorsque vous lancez des instances. AWS Le PCS intègre des modèles de lancement afin de configurer de manière flexible les groupes de nœuds de calcul. Lorsque vous créez un groupe de nœuds, vous fournissez un modèle de lancement. AWS PCS crée un modèle de lancement dérivé à partir de celui-ci qui inclut des transformations pour garantir son fonctionnement avec le service. Comprendre les options et les considérations à prendre en compte lors de la rédaction d'un modèle de lancement personnalisé peut vous aider à en créer un à utiliser avec AWS PCS. Pour plus d'informations sur les modèles de lancement, consultez Lancer une instance depuis un modèle de [lancement Lancer une instance depuis un modèle de lancement](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html) dans le guide de l'*utilisateur Amazon EC2*. **Topics** + [Vue d'ensemble des modèles de lancement dans AWS PCS](working-with_launch-templates_overview.md) + [Créer un modèle de lancement de base](working-with_launch-templates_create.md) + [Utilisation des données utilisateur Amazon EC2 pour PC AWS](working-with_ec2-user-data.md) + [Réservations de capacité en AWS PCS](working-with_capacity-reservations.md) + [Paramètres utiles du modèle de lancement](working-with_launch-templates_parameters.md) # Vue d'ensemble des modèles de lancement dans AWS PCS Il existe [plus de 30 paramètres disponibles](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RequestLaunchTemplateData.html) que vous pouvez inclure dans un modèle de lancement EC2, contrôlant de nombreux aspects de la configuration des instances. La plupart sont entièrement compatibles avec les AWS PC, à quelques exceptions près. Les paramètres suivants du modèle de lancement EC2 seront ignorés par AWS PCS car ces propriétés doivent être gérées directement par le service : + **Attributs du type d' type/Specify instance** (`InstanceRequirements`) — AWS PCS ne prend pas en charge la sélection d'instance basée sur les attributs. + **Type d'instance** (`InstanceType`) : spécifiez les types d'instances lorsque vous créez un groupe de nœuds. + **Profil d' details/IAM instance avancé** (`IamInstanceProfile`) : vous le fournissez lorsque vous créez ou mettez à jour le groupe de nœuds. + **Résiliation avancée de details/Disable l'API** (`DisableApiTermination`) : le AWS PCS doit contrôler le cycle de vie des instances de groupes de nœuds qu'il lance. + **Advanced details/Disable API stop** (`DisableApiStop`) : le AWS PCS doit contrôler le cycle de vie des instances de groupes de nœuds qu'il lance. + **Avancé details/Stop — Comportement d'hibernation** (`HibernationOptions`) — AWS PCS ne prend pas en charge l'hibernation des instances. + ** details/Elastic GPU avancé** (`ElasticGpuSpecifications`) — Amazon Elastic Graphics a atteint la fin de son cycle de vie le 8 janvier 2024. + ** details/Elastic Inférence avancée** (`ElasticInferenceAccelerators`) — Amazon Elastic Inference n'est plus disponible pour les nouveaux clients. + **AAdvanced details/Specify CPU options/Threadsper core** (`ThreadsPerCore`) — AWS PCS définit le nombre de threads par cœur à 1. Ces paramètres ont des exigences particulières en matière de compatibilité avec le AWS PCS : + **Données utilisateur** (`UserData`) : elles doivent être codées en plusieurs parties. Consultez [Utilisation des données utilisateur Amazon EC2 pour PC AWS](working-with_ec2-user-data.md). + **Images de l'application et du système d'exploitation** (`ImageId`) — Vous pouvez les inclure. Toutefois, si vous spécifiez un ID d'AMI lorsque vous créez ou mettez à jour le groupe de nœuds, il remplacera la valeur du modèle de lancement. L'AMI que vous fournissez doit être compatible avec AWS PCS. Pour plus d'informations, reportez-vous à la section "[Amazon Machine Images (AMIs) pour AWS PC](working-with_ami.md). + **Réseau settings/Firewall (groupes de sécurité)** (`SecurityGroups`) — Il est impossible de définir une liste de noms de groupes de sécurité dans un modèle de lancement AWS PCS. Vous pouvez définir une liste de groupes de sécurité IDs (`SecurityGroupIds`), sauf si vous définissez des interfaces réseau dans le modèle de lancement. Vous devez ensuite spécifier le groupe de sécurité IDs pour chaque interface. Pour de plus amples informations, veuillez consulter [Groupes de sécurité dans AWS PCS](working-with_networking_sg.md). + **Configuration settings/Advanced réseau** (`NetworkInterfaces`) : si vous utilisez des instances EC2 avec une seule carte réseau et que vous n'avez pas besoin de configuration réseau spécialisée, AWS PCS peut configurer la mise en réseau des instances pour vous. Pour configurer plusieurs cartes réseau ou pour activer Elastic Fabric Adapter sur vos instances, utilisez`NetworkInterfaces`. Chaque interface réseau doit contenir une liste de groupes de IDs sécurité`Groups`. Pour de plus amples informations, veuillez consulter [Plusieurs interfaces réseau dans les AWS PCS](working-with_networking_multi-nic.md). + **Détails avancés/réservation de capacité** (`CapacityReservationSpecification`) — Cela peut être défini, mais ne peut pas faire référence à un paramètre spécifique `CapacityReservationId` lorsque vous travaillez avec AWS PCS. Vous pouvez toutefois faire référence à un groupe de réservation de capacité, lorsque ce groupe contient une ou plusieurs réservations de capacité. Pour de plus amples informations, veuillez consulter [Réservations de capacité en AWS PCS](working-with_capacity-reservations.md). # Créer un modèle de lancement de base Vous pouvez créer un modèle de lancement à l'aide du AWS Management Console ou du AWS CLI. ------ #### [ AWS Management Console ] **Pour créer un modèle de lancement** 1. Ouvrez la [ EC2console Amazon](https://console.aws.amazon.com/ec2/home) et sélectionnez **Launch templates**. 1. Choisissez **Créer un modèle de lancement**. 1. Sous **Nom et description du modèle de lancement**, entrez un nom unique et distinctif pour le nom du **modèle de lancement** 1. Sous Paire de clés (connexion) sous Nom de la paire de clés, sélectionnez la paire de clés SSH qui sera utilisée pour se connecter aux EC2 instances gérées par AWS PCS. Cette action est facultative, mais recommandée. 1. Sous **Paramètres réseau**, puis **Pare-feu (groupes de sécurité)**, choisissez les groupes de sécurité à associer à l'interface réseau. Tous les groupes de sécurité du modèle de lancement doivent provenir du VPC de votre cluster AWS PCS. Choisissez au minimum : + Un groupe de sécurité qui permet la communication avec le cluster AWS PCS + Un groupe de sécurité qui permet la communication entre les EC2 instances lancées par AWS PCS + (Facultatif) Un groupe de sécurité qui autorise l'accès SSH entrant aux instances interactives + (Facultatif) Un groupe de sécurité qui permet aux nœuds de calcul d'établir des connexions sortantes vers Internet + (Facultatif) Groupe (s) de sécurité qui autorisent l'accès à des ressources en réseau telles que des systèmes de fichiers partagés ou un serveur de base de données. 1. Votre nouvel identifiant de modèle de lancement sera accessible dans la EC2 console Amazon sous **Modèles de lancement**. L'ID du modèle de lancement contiendra le formulaire`lt-0123456789abcdef01`. **Étape suivante recommandée** + Utilisez le nouveau modèle de lancement pour créer ou mettre à jour un groupe de nœuds de calcul AWS PCS. ------ #### [ AWS CLI ] **Pour créer un modèle de lancement** Créez votre modèle de lancement à l'aide de la commande ci-dessous. + Avant d'exécuter la commande, effectuez les remplacements suivants : 1. Remplacez *region-code* par l' Région AWS endroit où vous travaillez avec AWS PCS 1. *my-launch-template-name*Remplacez-le par un nom pour votre modèle. Il doit être unique au Compte AWS et Région AWS que vous utilisez. 1. Remplacez *my-ssh-key-name* par le nom de votre clé SSH préférée. 1. Remplacez *sg-ExampleID1* et *sg-ExampleID2* par un groupe de sécurité IDs qui autorise la communication entre vos EC2 instances et le planificateur ainsi que la communication entre les EC2 instances. Si vous ne disposez que d'un seul groupe de sécurité qui autorise tout ce trafic, vous pouvez supprimer `sg-ExampleID2` la virgule qui la précède. Vous pouvez également ajouter d'autres groupes de sécurité IDs. Tous les groupes de sécurité que vous incluez dans le modèle de lancement doivent provenir du AWS VPC de votre cluster PCS. ``` aws ec2 create-launch-template --region region-code \ --launch-template-name my-template-name \ --launch-template-data '{"KeyName":"my-ssh-key-name","SecurityGroupIds": ["sg-ExampleID1","sg-ExampleID2"]}' ``` Le texte affiché AWS CLI ressemblera à ce qui suit. L'ID du modèle de lancement se trouve dans`LaunchTemplateId`. ``` { "LaunchTemplate": { "LatestVersionNumber": 1, "LaunchTemplateId": "lt-0123456789abcdef01", "LaunchTemplateName": "my-launch-template-name", "DefaultVersionNumber": 1, "CreatedBy": "arn:aws:iam::123456789012:user/Bob", "CreateTime": "2019-04-30T18:16:06.000Z" } } ``` **Étape suivante recommandée** + Utilisez le nouveau modèle de lancement pour créer ou mettre à jour un groupe de nœuds de calcul AWS PCS. ------ # Utilisation des données utilisateur Amazon EC2 pour PC AWS Vous pouvez fournir des données utilisateur EC2 dans votre modèle de lancement qui `cloud-init` s'exécute lors du lancement de vos instances. Les blocs de données utilisateur avec le type de contenu `cloud-config` s'exécutent avant que l'instance ne s'enregistre auprès de l'API AWS PCS, tandis que les blocs de données utilisateur avec le type de contenu `text/x‑shellscript` s'exécutent une fois l'enregistrement terminé, mais avant le démarrage du démon Slurm. Pour plus d'informations sur les types de contenus, consultez la [documentation sur Cloud-Init](https://cloudinit.readthedocs.io/en/latest/explanation/format.html). nos données utilisateur peuvent exécuter des scénarios de configuration courants, y compris, mais sans s'y limiter, les suivants : + [Inclure des utilisateurs ou des groupes](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups) + [Installation de packages](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages) + [Création de partitions et de systèmes de fichiers](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#create-partitions-and-filesystems) + Montage de systèmes de fichiers réseau Les données utilisateur figurant dans les modèles de lancement doivent être au format d'[archive MIME en plusieurs parties](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive). Cela est dû au fait que vos données utilisateur sont fusionnées avec d'autres données utilisateur AWS PCS requises pour configurer les nœuds de votre groupe de nœuds. Vous pouvez combiner plusieurs blocs de données utilisateur dans un seul fichier MIME multi-part. Un fichier MIME multi-part est constitué des composants suivants : + Le type de contenu et la déclaration de limite : `Content-Type: multipart/mixed; boundary="==BOUNDARY=="` + La déclaration de version MIME : `MIME-Version: 1.0` + Un ou plusieurs blocs de données utilisateur contenant les composants suivants : + La limite d'ouverture qui indique le début d'un bloc de données utilisateur :`--==BOUNDARY==`. Vous devez laisser la ligne avant cette limite vide. + La déclaration du type de contenu pour le bloc : `Content-Type: text/cloud-config; charset="us-ascii"` ou`Content-Type: text/x-shellscript; charset="us-ascii"`. Vous devez laisser la ligne après la déclaration de type de contenu vide. + Le contenu des données utilisateur, tel qu'une liste de commandes ou de `cloud-config` directives du shell. + La limite de fermeture qui indique la fin du fichier MIME en plusieurs parties :. `--==BOUNDARY==--` Vous devez laisser la ligne avant la limite de fermeture vide. **Note** Si vous ajoutez des données utilisateur à un modèle de lancement dans la console Amazon EC2, vous pouvez les coller sous forme de texte brut. Vous pouvez également le télécharger à partir d'un fichier. Si vous utilisez le AWS CLI ou un AWS SDK, vous devez d'abord encoder les données utilisateur en base64 et envoyer cette chaîne comme valeur du `UserData` paramètre lorsque vous appelez [CreateLaunchTemplate](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateLaunchTemplate.html), comme indiqué dans ce fichier JSON. ``` { "LaunchTemplateName": "base64-user-data", "LaunchTemplateData": { "UserData": "ewogICAgIkxhdW5jaFRlbXBsYXRlTmFtZSI6ICJpbmNyZWFzZS1jb250YWluZXItdm9sdW..." } } ``` **Exemples** + [Exemple : installation d'un logiciel à partir d'un référentiel de packages](working-with_ec2-user-data_repo.md) + [Exemple : exécution de scripts à partir d'un compartiment S3](working-with_ec2-user-data_s3.md) + [Exemple : définir des variables d'environnement globales](working-with_ec2-user-data_env.md) + [Utilisation de systèmes de fichiers réseau avec AWS PCS](working-with_file-systems.md) + [Exemple : utilisation d'un système de fichiers EFS comme répertoire de base partagé](working-with_ec2-user-data_efs.md) # Exemple : installation d'un logiciel pour AWS PC à partir d'un référentiel de packages Indiquez ce script comme valeur de `"userData"` dans votre modèle de lancement. Pour de plus amples informations, veuillez consulter [Utilisation des données utilisateur Amazon EC2 pour PC AWS](working-with_ec2-user-data.md). Ce script utilise **cloud-config** pour installer des packages logiciels sur les instances de groupes de nœuds lors du lancement. Pour plus d'informations, consultez les [formats de données utilisateur](https://cloudinit.readthedocs.io/en/latest/explanation/format.html) dans la documentation de *cloud-init*. Cet exemple installe `curl` et. `llvm` **Note** Vos instances doivent être en mesure de se connecter à leurs référentiels de packages configurés. ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==MYBOUNDARY==" --==MYBOUNDARY== Content-Type: text/cloud-config; charset="us-ascii" packages: - python3-devel - rust - golang --==MYBOUNDARY==-- ``` # Exemple : exécution de scripts supplémentaires pour AWS PCS à partir d'un compartiment S3 Indiquez ce script comme valeur de `"userData"` dans votre modèle de lancement. Pour de plus amples informations, veuillez consulter [Utilisation des données utilisateur Amazon EC2 pour PC AWS](working-with_ec2-user-data.md). Le script de données utilisateur suivant utilise **cloud-config** pour importer un script depuis un compartiment S3 et l'exécuter sur des instances de groupes de nœuds lors du lancement. Pour plus d'informations, consultez les [formats de données utilisateur](https://cloudinit.readthedocs.io/en/latest/explanation/format.html) dans la documentation de *cloud-init*. Remplacez les valeurs suivantes par vos propres informations : + *amzn-s3-demo-bucket*— Le nom d'un compartiment S3 que votre compte peut lire. + *object-key*— La clé d'objet S3 du script à importer. Cela inclut le nom du script et son emplacement dans la structure de dossiers du bucket. Par exemple, `scripts/script.sh`. Pour plus d'informations, consultez la section [Organisation des objets dans la console Amazon S3 à l'aide de dossiers](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-folders.html) dans le *guide de l'utilisateur d'Amazon Simple Storage Service*. + *shell*— Le shell Linux à utiliser pour exécuter le script, tel que`bash`. ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==MYBOUNDARY==" --==MYBOUNDARY== Content-Type: text/cloud-config; charset="us-ascii" runcmd: - aws s3 cp s3://amzn-s3-demo-bucket/object-key /tmp/script.sh - /usr/bin/shell /tmp/script.sh --==MYBOUNDARY==-- ``` Le profil d'instance IAM du groupe de nœuds doit avoir accès au bucket. La politique IAM suivante est un exemple pour le bucket dans le script de données utilisateur ci-dessus. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket", "arn:aws:s3:::amzn-s3-demo-bucket/*" ] } ] } ``` ------ # Exemple : définir des variables d'environnement globales pour AWS PCS Indiquez ce script comme valeur de `"userData"` dans votre modèle de lancement. Pour de plus amples informations, veuillez consulter [Utilisation des données utilisateur Amazon EC2 pour PC AWS](working-with_ec2-user-data.md). L'exemple suivant permet `/etc/profile.d` de définir des variables globales sur des instances de groupes de nœuds. ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==MYBOUNDARY==" --==MYBOUNDARY== Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash touch /etc/profile.d/awspcs-userdata-vars.sh echo MY_GLOBAL_VAR1=100 >> /etc/profile.d/awspcs-userdata-vars.sh echo MY_GLOBAL_VAR2=abc >> /etc/profile.d/awspcs-userdata-vars.sh --==MYBOUNDARY==-- ``` # Exemple : utilisation d'un système de fichiers EFS comme répertoire de base partagé pour AWS PCS Indiquez ce script comme valeur de `"userData"` dans votre modèle de lancement. Pour de plus amples informations, veuillez consulter [Utilisation des données utilisateur Amazon EC2 pour PC AWS](working-with_ec2-user-data.md). Cet exemple étend l'exemple de montage EFS [Utilisation de systèmes de fichiers réseau avec AWS PCS](working-with_file-systems.md) pour implémenter un répertoire de base partagé. Le contenu de /home est sauvegardé avant le montage du système de fichiers EFS. Le contenu est ensuite rapidement copié sur place sur le stockage partagé une fois le montage terminé. Remplacez les valeurs suivantes dans ce script par vos propres informations : + */mount-point-directory*— Le chemin d'une instance sur laquelle vous souhaitez monter le système de fichiers EFS. + *filesystem-id*— L'ID du système de fichiers EFS. ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==MYBOUNDARY==" --==MYBOUNDARY== Content-Type: text/cloud-config; charset="us-ascii" packages: - amazon-efs-utils runcmd: - mkdir -p /tmp/home - rsync -a /home/ /tmp/home - echo "filesystem-id:/ /mount-point-directory efs tls,_netdev" >> /etc/fstab - mount -a -t efs defaults - rsync -a --ignore-existing /tmp/home/ /home - rm -rf /tmp/home/ --==MYBOUNDARY==-- ``` # Exemple : activation du SSH sans mot de passe Vous pouvez vous appuyer sur l'exemple du répertoire de base partagé pour implémenter des connexions SSH entre des instances de cluster à l'aide de clés SSH. Pour chaque utilisateur utilisant le système de fichiers d'accueil partagé, exécutez un script semblable au suivant : ``` #!/bin/bash mkdir -p $HOME/.ssh && chmod 700 $HOME/.ssh touch $HOME/.ssh/authorized_keys chmod 600 $HOME/.ssh/authorized_keys if [ ! -f "$HOME/.ssh/id_rsa" ]; then ssh-keygen -t rsa -b 4096 -f $HOME/.ssh/id_rsa -N "" cat ~/.ssh/id_rsa.pub >> $HOME/.ssh/authorized_keys fi ``` **Note** Les instances doivent utiliser un groupe de sécurité qui autorise les connexions SSH entre les nœuds du cluster. # Réservations de capacité en AWS PCS Vous pouvez réserver des EC2 capacités Amazon dans une zone de disponibilité spécifique et pour une durée spécifique à l'aide des réservations de capacité à la demande ou des Amazon EC2 Capacity Blocks for ML afin de vous assurer de disposer de la capacité de calcul nécessaire lorsque vous en avez besoin. **Les réservations de capacité à la demande (ODCRs)** vous permettent de réserver de la capacité de calcul pour vos EC2 instances Amazon dans une zone de disponibilité spécifique, quelle que soit la durée. Vous pouvez créer et annuler des réservations à tout moment, sans engagement à long terme ni paiement initial. ODCRs sont idéales lorsque vous avez besoin de réservations de capacité flexibles que vous pouvez modifier en fonction de l'évolution de vos besoins. Pour plus d'informations, consultez [la section Réservations de capacité à la demande](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) dans le *guide de l'utilisateur d'Amazon Elastic Compute Cloud*. **Amazon EC2 Capacity Blocks for ML** vous permet de réserver des instances de calcul accéléré basées sur un GPU pour une utilisation future, jusqu'à 8 semaines à l'avance. Vous pouvez réserver des blocs de 1 à 64 instances pour des durées allant de 1 jour à 6 mois. Les blocs de capacité sont idéaux pour les charges de travail d'apprentissage automatique qui nécessitent un accès garanti à la capacité du GPU à des moments précis. Pour plus d'informations, consultez [Capacity Blocks for ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) dans le *guide de l'utilisateur d'Amazon Elastic Compute Cloud*. **Topics** + [Utilisation ODCRs avec AWS PCS](capacity-reservations-odcr.md) + [Utilisation des blocs de capacité Amazon EC2 pour le ML avec PCS AWS](capacity-blocks.md) # Utilisation ODCRs avec AWS PCS Vous pouvez choisir la manière dont AWS PCS consomme vos instances réservées. Si vous créez un ODCR **ouvert**, toutes les instances correspondantes lancées par AWS PCS ou d'autres processus sur votre compte sont prises en compte dans la réservation. Avec un ODCR **ciblé**, seules les instances lancées avec l'identifiant de réservation spécifique sont prises en compte dans la réservation. Pour les charges de travail sensibles au facteur temps, les tâches ciblées ODCRs sont plus courantes. Vous pouvez configurer un groupe de nœuds de calcul AWS PCS pour utiliser un ODCR ciblé en l'ajoutant à un modèle de lancement. Voici les étapes à suivre pour ce faire : 1. Créez une réservation de capacité à la demande (ODCR) ciblée à l'aide du guide de l'[utilisateur Amazon EC2 Create a Capacity Reservation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservations-create.html). 1. Associez l'ODCR à un modèle de lancement. Il existe deux manières de procéder : 1. **Association ODCR directe : référencez** l'ID ODCR directement dans le modèle de lancement. Cette approche permet un contrôle strict de la capacité et ne prend pas en charge le remblayage d'instances (si le groupe de nœuds de calcul demande plus d'instances que ce qui est disponible dans l'ODCR, aucune instance supplémentaire ne sera lancée). 1. **Association de groupes de réservation de capacité :** ajoutez l'ODCR à un groupe de réservation de capacité et référencez le groupe dans le modèle de lancement. Cette approche prend en charge le remblayage des instances, ce qui permet à AWS PCS de lancer des instances à la demande supplémentaires si la capacité de réservation est dépassée. 1. Créez ou mettez à jour un groupe de nœuds de calcul AWS PCS pour utiliser le modèle de lancement. Pour plus d'informations, consultez le [guide de l'utilisateur de AWS PCS Compute Node Groups](https://docs.aws.amazon.com/pcs/latest/userguide/working-with_cng.html). 1. Définissez le groupe `purchaseOption` de nœuds de calcul sur`ONDEMAND`. ## Exemple : réserver et utiliser des instances hpc6a.48xlarge avec un ODCR ciblé Cet exemple de commande crée un ODCR ciblé pour 32 instances hpc6a.48xlarge. Pour lancer les instances réservées dans un groupe de placement, ajoutez `--placement-group-arn` à la commande. Vous pouvez définir une date de fin avec `--end-date` et`--end-date-type`, sinon, la réservation se poursuivra jusqu'à ce qu'elle soit annulée manuellement. ``` aws ec2 create-capacity-reservation \ --instance-type hpc6a.48xlarge \ --instance-platform Linux/UNIX \ --availability-zone us-east-2a \ --instance-count 32 \ --instance-match-criteria targeted ``` Le résultat de cette commande sera un ARN pour le nouvel ODCR. L'ID ODCR peut être récupéré à partir de l'ARN `"arn:aws:ec2:us-east-2:123456789012:capacity-reservation/ODCR-ID"` ou à l'aide d'[Amazon DescribeCapacityReservations EC2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeCapacityReservations.html). **Association ODCR directe :** ajoutez l'identifiant ODCR au modèle de lancement. Voici un exemple de modèle de lancement qui fait référence à l'identifiant ODCR. ``` { "CapacityReservationSpecification": { "CapacityReservationTarget": { "CapacityReservationId": "cr-1234567890abcdef1" } } } ``` **Association de groupes de réservation de capacité :** créez un groupe de réservation de capacité et ajoutez-le au modèle de lancement. La commande suivante crée un groupe de réservation de capacité nommé`EXAMPLE-CR-GROUP`. ``` aws resource-groups create-group \ --name EXAMPLE-CR-GROUP \ --configuration \ '{"Type": "AWS::EC2::CapacityReservationPool"}' \ '{"Type": "AWS::ResourceGroups::Generic", "Parameters": [{"Name": "allowed-resource-types", "Values": ["AWS::EC2::CapacityReservation"]}]}' ``` La commande suivante ajoute l'ODCR au groupe de réservation de capacité. ``` aws resource-groups group-resources --group EXAMPLE-CR-GROUP \ --resource-arns arn:aws:ec2:us-east-2:123456789012:capacity-reservation/cr-1234567890abcdef1 ``` Une fois l'ODCR créé et ajouté à un groupe de réservation de capacité, il peut désormais être connecté à un groupe de nœuds de calcul AWS PCS en l'ajoutant à un modèle de lancement. Voici un exemple de modèle de lancement qui fait référence au groupe de réservation de capacité. ``` { "CapacityReservationSpecification": { "CapacityReservationResourceGroupArn": "arn:aws:resource-groups:us-east-2:123456789012:group/EXAMPLE-CR-GROUP" } } ``` Enfin, créez ou mettez à jour un groupe de nœuds de calcul AWS PCS pour utiliser les instances hpc6a.48xlarge et utilisez le modèle de lancement qui fait référence à l'ODCR. Pour un groupe de nœuds statique, définissez les instances minimale et maximale en fonction de la taille de la réservation (32). Pour un groupe de nœuds dynamique, définissez le nombre minimum d'instances sur 0 et le maximum sur la taille d'instance souhaitée. Cet exemple est une implémentation simple d'un ODCR unique configuré pour un groupe de nœuds de calcul. Mais AWS PCS prend en charge de nombreux autres modèles. Par exemple, vous pouvez subdiviser un grand groupe ODCR ou de réservation de capacité entre plusieurs groupes de nœuds de calcul. Vous pouvez également utiliser ODCRs le compte AWS créé et partagé avec le vôtre. Pour plus d'informations, consultez [la section Réservations de capacité à la demande et blocs de capacité pour le ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html) dans le *guide de l'utilisateur d'Amazon Elastic Compute Cloud*. # Utilisation des blocs de capacité Amazon EC2 pour le ML avec PCS AWS Amazon EC2 Capacity Blocks for ML est une option d'achat Amazon EC2 qui vous permet de payer à l'avance pour réserver des instances de calcul accéléré basées sur un GPU à une date et à une heure spécifiques afin de prendre en charge des charges de travail de courte durée. Les instances qui s'exécutent au sein d'un bloc de capacité sont automatiquement placées à proximité les unes des autres dans Amazon EC2 UltraClusters, pour une mise en réseau non bloquante à faible latence, à l'échelle du pétabit. Pour plus d'informations, consultez [Capacity Blocks for ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) dans le *guide de l'utilisateur d'Amazon Elastic Compute Cloud*. Vous pouvez utiliser un modèle de lancement pour que AWS PCS utilise un bloc de capacité lorsqu'il lance des instances pour un groupe de nœuds de calcul. **Note** AWS PCS a introduit le support pour les blocs de capacité depuis la version 24.05 de Slurm. ## Limitations + AWS PCS prend uniquement en charge les blocs de capacité avec les familles d'instances P5en, P5e, P5 et P4d. + Vous ne pouvez associer un groupe de nœuds de calcul qu'à un seul bloc de capacité à la fois. + Vous ne pouvez pas associer un groupe de nœuds de calcul à un groupe de réservation de capacité combinant plusieurs blocs de capacité. + Les blocs de capacité doivent être à `active` l'état `scheduled` ou pour être utilisés avec le AWS PCS. Vous ne pouvez pas utiliser les blocs de capacité dans d'autres États, tels que`payment-failed`. Pour plus d'informations, consultez la section [Afficher les blocs de capacité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-view.html) dans le *guide de l'utilisateur d'Amazon Elastic Compute Cloud*. ## Expiration du bloc de capacité Les blocs de capacité sont limités à une plage de dates et d'heures spécifiques. Lorsqu'un bloc de capacité expire : + Le groupe de nœuds de calcul associé à ce bloc de capacité continue d'exister et reste associé aux mêmes files d'attente. + Toutes les instances du groupe de nœuds de calcul sont mises hors service et les tâches actives risquent d'échouer, selon vos paramètres Slurm. + AWS PCS ne peut pas lancer de nouvelles instances dans le groupe de nœuds de calcul. + Toutes les tâches mises en file d'attente ou récemment soumises restent en attente jusqu'à ce qu'un autre groupe de nœuds de calcul soit attaché à la file d'attente ou que vous mettiez à jour le groupe de nœuds de calcul pour utiliser un nouveau modèle de lancement spécifiant un nouveau bloc de capacité. # Configuration d'un groupe de nœuds de calcul AWS PCS pour utiliser un bloc de capacité **Pour associer un bloc de capacité à un groupe de nœuds de calcul** 1. Créez un modèle de EC2 lancement Amazon pour AWS PCS qui spécifie votre bloc de capacité. Pour plus d'informations sur la création d'un modèle de lancement pour AWS PCS, consultez[Utilisation des modèles de lancement Amazon EC2 avec PCS AWS](working-with_launch-templates.md). Votre modèle de lancement doit inclure : + La valeur `MarketType` de `InstanceMarketOptions` doit être définie sur`capacity-block`. + A `CapacityReservationSpecification` avec un `CapacityReservationId` + Une valeur valide `InstanceType` correspondant au type d'instance du Capacity Block que vous avez acheté. 1. Créez un groupe de nœuds de calcul qui utilise le modèle de lancement. Pour de plus amples informations, veuillez consulter [Création d'un groupe de nœuds de calcul dans AWS PCS](working-with_cng_create.md). Vous pouvez également mettre à jour un groupe de nœuds de calcul existant pour utiliser le modèle de lancement. Pour de plus amples informations, veuillez consulter [Mise à jour d'un groupe de nœuds de calcul AWS PCS](working-with_cng_update.md). Lorsque vous créez ou mettez à jour le groupe de nœuds de calcul : + L'identité IAM que vous utilisez pour créer ou mettre à jour le groupe de nœuds de calcul doit disposer de l'autorisation suivante : ``` ec2:DescribeCapacityReservations ``` Pour de plus amples informations, veuillez consulter [Autorisations minimales pour les AWS PCS](security-min-permissions.md). + Le bloc de capacité doit être à `active` l'état `scheduled` ou. + Définissez le groupe `purchaseOption` de nœuds de calcul sur`CAPACITY_BLOCK`. + La taille `maxInstanceCount` du groupe de nœuds de calcul ne doit pas dépasser la taille du bloc de capacité. + La zone de disponibilité du groupe de nœuds de calcul doit correspondre à l'une des zones de disponibilité de sous-réseau du groupe de nœuds de calcul. **Important** Vous ne pouvez pas modifier le type d'instance d'un groupe de nœuds de calcul lorsque vous le mettez à jour. Vous ne pouvez utiliser un bloc de capacité qu'avec le même type d'instance que le groupe de nœuds de calcul. Si vous souhaitez utiliser un bloc de capacité avec un autre type d'instance, vous devez créer un nouveau groupe de nœuds de calcul. # Questions fréquemment posées sur l'utilisation des blocs de capacité avec les AWS PCS **Je viens de payer un bloc de capacité et j'ai immédiatement essayé de l'utiliser avec un AWS PCS, mais la création d'un groupe de nœuds de calcul a échoué. Que s’est-il passé ?** Votre bloc de capacité n'est peut-être pas dans `active` l'état « `scheduled` or ». Réessayez une fois que le bloc de capacité est `scheduled` ou`active`. **J'utilise un bloc de capacité dans AWS PCS et j'ai acheté une extension avant son expiration. Comment puis-je continuer à l'utiliser dans AWS PCS ?** Vous n'avez rien à faire pour continuer à utiliser le bloc de capacité dans AWS PCS. La date de fin de votre bloc de capacité est mise à jour une fois que le paiement de votre extension a été effectué avec succès. Tant que votre bloc de capacité n'expire pas, le groupe de nœuds de calcul continue de fonctionner. Si le paiement de votre extension échoue, votre bloc de capacité est conservé `active` et le groupe de nœuds de calcul fonctionne jusqu'à ce que le bloc de capacité expire à sa date de fin initiale. **Qu'advient-il de mes tâches en attente et en cours d'exécution si mon bloc de capacité expire ?** Les tâches en file d'attente qui n'ont pas démarré avant l'expiration du bloc de capacité restent en attente jusqu'à ce que vous attachiez un autre groupe de nœuds de calcul à la file d'attente ou que vous mettiez à jour le groupe de nœuds de calcul avec un nouveau bloc de capacité. Vous pouvez toujours ajouter des tâches à la file d'attente. Vos paramètres Slurm ont une incidence sur les tâches actives. Par défaut, les tâches actives sont automatiquement mises en file d'attente, mais elles peuvent comporter des erreurs ou échouer. **Mon bloc de capacité a expiré. Dois-je faire quelque chose ?** Tu n'as rien à faire. Vous pouvez consulter la console Amazon EC2 pour connaître l'état de vos réservations de capacité EC2. Lorsqu'un bloc de capacité expire, le groupe de nœuds de calcul associé à ce bloc de capacité continue d'exister et de gérer les mêmes files d'attente. Le groupe de nœuds de calcul ne possède aucune instance pour exécuter des tâches. Vous pouvez supprimer le groupe de nœuds de calcul ou le dissocier des files d'attente pour empêcher les utilisateurs de soumettre des tâches qui ne seront pas exécutées. **Je souhaite utiliser un nouveau bloc de capacité avec mon groupe de nœuds de calcul AWS PCS. Que dois-je faire ?** Nous vous recommandons de créer un nouveau groupe de nœuds de calcul pour utiliser le nouveau bloc de capacité. Pour de plus amples informations, veuillez consulter [Configuration d'un groupe de nœuds de calcul AWS PCS pour utiliser un bloc de capacité](capacity-blocks-configure-cng.md). **Comment puis-je partager un bloc de capacité entre les clusters et les services ?** Vous pouvez répartir un bloc de capacité sur plusieurs clusters et services. Par exemple, pour diviser un bloc de capacité avec 64 `p5.48xlarge` instances avec 20 nœuds sur PCS-Cluster-1, 16 nœuds sur PCS-Cluster-2 et les nœuds restants pour d'autres services, définissez les deux et sur 20 pour PCS-Cluster-1 `minInstanceCount` et 16 `maxInstanceCount` pour PCS-Cluster-2. **Puis-je utiliser plus d'un bloc de capacité ou une capacité combinée avec un groupe de nœuds de calcul ?** Non Un seul bloc de capacité peut être associé à un seul groupe de nœuds de calcul. AWS Le PCS ne prend pas en charge les groupes de réservation de capacité qui combinent plusieurs blocs de capacité. **Comment savoir quand mes blocs de capacité commencent ou expirent ?** Indépendamment de AWS PCS, Amazon EC2 envoie un `Capacity Block Reservation Delivered` événement EventBridge lorsque la réservation d'un bloc de capacité commence et un `Capacity Block Reservation Expiration Warning` événement 40 minutes avant l'expiration de la réservation du bloc de capacité. Pour plus d'informations, consultez la section [Monitor Capacity Blocks using EventBridge](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-monitor.html) dans le *guide de l'utilisateur d'Amazon Elastic Compute Cloud*. **Comment est-ce que Slurm suit l'état de mon bloc de capacité ?** Vous pouvez courir `sinfo` pour comprendre comment AWS PCS utilise le bloc de capacité. Dans l'exemple de sortie suivant, une file d'attente est associée à un groupe de nœuds de calcul qui exécute 4 instances à partir d'un bloc de `active` capacité. Les nœuds sont dans l'état `idle` Slurm (ils peuvent être utilisés et ne sont pas encore affectés à des tâches). ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST fanout up infinite 4 idle node-fanout-[1-4] ``` Si les nœuds sont plutôt en `maint` état, vous pouvez courir `scontrol show res` pour voir les détails de la réservation Slurm qui contrôle cet état. Dans l'exemple de sortie suivant, le bloc de capacité `scheduled` indique une date de début future. ``` $ scontrol show res ReservationName=node-fanout-scheduled StartTime=2025-10-14T13:09:17 EndTime=2025-10-14T13:11:17 Duration=00:02:00 Nodes=node-fanout-[1-4] NodeCnt=4 CoreCnt=16 Features=(null) PartitionName=(null) Flags=MAINT,SPEC_NODES TRES=cpu=16 Users=root Groups=(null) Accounts=(null) Licenses=(null) State=ACTIVE BurstBuffer=(null) MaxStartDelay=(null) Comment=node-fanout Scheduled ``` **Comment puis-je savoir si les erreurs que je reçois lors du lancement de Capacity sont dues au fait que mon bloc de capacité est partagé ?** Consultez les **réservations de capacité** dans la console Amazon EC2 pour savoir combien d'instances du bloc de capacité sont activement provisionnées. Vérifiez les balises de chaque instance pour savoir quel service ou cluster l'utilise. Par exemple, toutes les instances pour AWS AWS PCS possèdent des balises PCS `aws:pcs:cluster-id = pcs_l0mizqyk5o | aws:pcs:compute-node-group-id = pcs_ic7onkmfqk` qui indiquent à quels clusters et groupes de nœuds de calcul l'instance appartient. Vous pouvez ensuite vérifier si le bloc de capacité est à sa capacité maximale. Vous utilisez `scontrol show nodes` pour vérifier si un nœud Capacity Block d'un cluster AWS PCS déclenche `ReservationCapacityExceeded` : ``` [root@ip-172-16-10-54 ~]# scontrol show nodes test-node-8-gamma-cb-2 NodeName=test-8-gamma-cb-2 CoresPerSocket=1 CPUAlloc=0 CPUEfctv=8 CPUTot=8 CPULoad=0.00 AvailableFeatures=test-8-gamma-cb,gpu ActiveFeatures=test-8-gamma-cb,gpu Gres=gpu:H100:1 NodeAddr=test-8-gamma-cb-2 NodeHostName=test-8-gamma-cb-2 RealMemory=249036 AllocMem=0 FreeMem=N/A Sockets=8 Boards=1 State=IDLE+CLOUD+POWERING_DOWN ThreadsPerCore=1 TmpDisk=0 Weight=1 Owner=N/A MCS_label=N/A Partitions=my-q BootTime=None SlurmdStartTime=None LastBusyTime=Unknown ResumeAfterTime=None CfgTRES=cpu=8,mem=249036M,billing=8 AllocTRES= CurrentWatts=0 AveWatts=0 Reason=Failed to launch backing instance (Error Code: ReservationCapacityExceeded) [root@2025-08-28T15:15:33] ``` **Lorsque plusieurs groupes de nœuds de calcul sont attachés à la même file d'attente, comment puis-je forcer l'exécution d'une tâche sur des instances basées sur Capacity Block ?** Vous pouvez utiliser les fonctionnalités et les contraintes de Slurm pour verrouiller une tâche sur un certain ensemble de nœuds. Nous vous recommandons de ne pas définir de poids Slurm pour chaque groupe de nœuds de calcul, car cela ne fonctionne qu'avec les nœuds qui ne sont pas dans cet état. `maint` # Paramètres utiles du modèle de lancement Cette section décrit certains paramètres du modèle de lancement qui peuvent être largement utiles avec AWS PCS. ## Activez la CloudWatch surveillance détaillée Vous pouvez activer la collecte de CloudWatch métriques à un intervalle plus court à l'aide d'un paramètre de modèle de lancement. ------ #### [ AWS Management Console ] Sur les pages de console permettant de créer ou de modifier des modèles de lancement, cette option se trouve dans la section **Détails avancés**. Définissez la ** CloudWatch surveillance détaillée** sur *Activer.* ------ #### [ YAML ] ``` Monitoring: Enabled: True ``` ------ #### [ JSON ] ``` {"Monitoring": {"Enabled": "True"}} ``` ------ Pour plus d'informations, consultez [Activer ou désactiver la surveillance détaillée de vos instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html) dans le *guide de l'utilisateur Amazon Elastic Compute Cloud pour les instances Linux*. ## Service de métadonnées d'instance, version 2 (IMDS v2) L'utilisation d'IMDS v2 avec des instances EC2 améliore considérablement la sécurité et contribue à atténuer les risques potentiels associés à l'accès aux métadonnées des instances dans AWS les environnements. ------ #### [ AWS Management Console ] Sur les pages de console permettant de créer ou de modifier des modèles de lancement, cette option se trouve dans la section **Détails avancés**. Définissez **les métadonnées accessibles** sur *Activé*, la **version des métadonnées** sur *V2 uniquement (jeton requis)* et la **limite de sauts de réponse des métadonnées** sur *4*. ------ #### [ YAML ] ``` MetadataOptions: HttpEndpoint: enabled HttpTokens: required HttpPutResponseHopLimit: 4 ``` ------ #### [ JSON ] ``` { "MetadataOptions": { "HttpEndpoint": "enabled", "HttpPutResponseHopLimit": 4, "HttpTokens": "required" } } ``` ------ .