SageMaker HyperPod meilleures pratiques de configuration du cycle de vie - Amazon SageMaker
Préparez des scripts de cycle de vie pour configurer Slurm sur SageMaker HyperPod

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.

SageMaker HyperPod meilleures pratiques de configuration du cycle de vie

SageMaker HyperPod propose toujours des clusters de up-and-running calcul, hautement personnalisables car vous pouvez écrire des scripts de cycle de vie pour indiquer SageMaker HyperPod comment configurer les ressources du cluster. Les rubriques suivantes présentent les meilleures pratiques pour préparer des scripts de cycle de vie afin de configurer des SageMaker HyperPod clusters avec des outils de gestion de charge de travail open source.

Préparez des scripts de cycle de vie pour configurer Slurm sur SageMaker HyperPod

Les rubriques suivantes expliquent comment préparer des scripts de cycle de vie sur lesquels installer Slurm. SageMaker HyperPod

Aperçu de haut niveau

La procédure suivante est le flux principal du provisionnement d'un HyperPod cluster et de sa configuration avec Slurm. Les étapes sont classées selon une approche ascendante.

  1. Planifiez la manière dont vous souhaitez créer des nœuds Slurm sur un HyperPod cluster. Par exemple, si vous souhaitez configurer deux nœuds Slurm, vous devez configurer deux groupes d'instances dans un HyperPod cluster.

  2. Préparez un provisioning_parameters.json fichier, qui est unFormulaire de configuration pour le provisionnement des nœuds Slurm sur HyperPod. provisioning_parameters.jsondoit contenir les informations de configuration du nœud Slurm à provisionner sur le cluster. HyperPod Cela doit refléter la conception des nœuds Slurm de l'étape 1.

  3. Préparez un ensemble de scripts de cycle de vie pour configurer Slurm HyperPod afin d'installer des packages logiciels et de configurer un environnement dans le cluster adapté à votre cas d'utilisation. Vous devez structurer les scripts de cycle de vie de manière à ce qu'ils s'exécutent collectivement dans un script Python central (lifecycle_script.py), et écrire un script shell point d'entrée (on_create.sh) pour exécuter le script Python. Le script shell entrypoint est ce que vous devez fournir à une demande de création de HyperPod cluster plus tard à l'étape 5.

    Notez également que vous devez écrire les scripts dans lesquels vous vous attendez à ce resource_config.json qu'ils soient générés HyperPod lors de la création du cluster. resource_config.jsoncontient des informations sur les ressources du HyperPod cluster telles que les adresses IP, les types d'instances etARNs, et c'est ce que vous devez utiliser pour configurer Slurm.

  4. Rassemblez tous les fichiers des étapes précédentes dans un dossier.

    └── lifecycle_files // your local folder
    ├── provisioning_parameters.json
    ├── on_create.sh
    ├── lifecycle_script.py
    └── ... // more setup scrips to be fed into lifecycle_script.py

  5. Téléchargez tous les fichiers dans un compartiment S3. Copiez et conservez le chemin du compartiment S3. Notez que vous devez créer un chemin de compartiment S3 en commençant par, sagemaker- car vous devez choisir un chemin IAMrôle pour SageMaker HyperPod attaché avecAWS politique gérée : AmazonSageMakerClusterInstanceRolePolicy, qui n'autorise que les chemins de compartiment Amazon S3 commençant par le préfixesagemaker-. La commande suivante est un exemple de commande permettant de télécharger tous les fichiers dans un compartiment Amazon S3.

    aws s3 cp --recursive ./lifecycle_files s3://sagemaker-hyperpod-lifecycle/src

  6. Préparez une demande HyperPod de création de cluster.

    • Option 1 : Si vous utilisez AWS CLI, rédigez une demande de création de cluster au JSON format (create_cluster.json) en suivant les instructions surCréation d'un nouveau cluster.

    • Option 2 : Si vous utilisez l'interface utilisateur de la SageMaker console, remplissez le formulaire de demande de cluster dans l'interface utilisateur de la HyperPod console en suivant les instructions indiquées à l'adresseCréation d'un SageMaker HyperPod cluster.

    À ce stade, assurez-vous de créer des groupes d'instances dans la même structure que celle que vous avez planifiée aux étapes 1 et 2. Assurez-vous également de spécifier le compartiment S3 à l'étape 5 dans les formulaires de demande.

  7. Soumettez la demande de création de cluster. HyperPod approvisionne un cluster en fonction de la demande, puis crée un resource_config.json fichier dans les instances du HyperPod cluster et configure Slurm sur le cluster exécutant les scripts de cycle de vie.

La section suivante explique en détail comment organiser les fichiers de configuration et les scripts de cycle de vie de manière à ce qu'ils fonctionnent correctement lors de la création de HyperPod clusters.

Commencez par les scripts de cycle de vie de base fournis par HyperPod

Cette section vous présente tous les composants du processus de base de la configuration de Slurm selon HyperPod une approche descendante. Il commence par la préparation d'une demande de création de HyperPod cluster pour exécuter le CreateClusterAPI, puis explore en profondeur la structure hiérarchique jusqu'aux scripts de cycle de vie. Utilisez les exemples de scripts de cycle de vie fournis dans le GitHub référentiel Awsome Distributed Training. Clonez le référentiel en exécutant la commande suivante.

git clone https://github.com/aws-samples/awsome-distributed-training/

Les scripts de cycle de vie de base pour la configuration d'un cluster Slurm SageMaker HyperPod sont disponibles sur. 1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config

cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config

L'organigramme suivant présente un aperçu détaillé de la manière dont vous devez concevoir les scripts de cycle de vie de base. Les descriptions ci-dessous, le schéma et le guide de procédure expliquent comment ils fonctionnent pendant l' HyperPod CreateClusterAPIappel.

Un organigramme détaillé de la création de HyperPod clusters et de la structure des scripts de cycle de vie.

Figure : organigramme détaillé de la création de HyperPod clusters et de la structure des scripts de cycle de vie. (1) Les flèches en pointillés sont dirigées vers l'endroit où les cases sont « appelées » et indiquent le flux de préparation des fichiers de configuration et des scripts de cycle de vie. Cela commence par la préparation provisioning_parameters.json et le cycle de vie des scripts. Ils sont ensuite codés lifecycle_script.py pour une exécution collective dans l'ordre. Et l'exécution du lifecycle_script.py script est effectuée par le script on_create.sh shell, qui doit être exécuté dans le terminal de l' HyperPod instance. (2) Les flèches continues indiquent le flux principal de création du HyperPod cluster et la manière dont les cases sont « appelées » ou « soumises à ». on_create.shest obligatoire pour la demande de création de cluster, que ce soit dans le formulaire de demande de cluster create_cluster.json ou dans le formulaire Créer une demande de cluster dans l'interface utilisateur de la console. Après avoir soumis la demande, HyperPod exécute le en CreateCluster API fonction des informations de configuration fournies par la demande et des scripts de cycle de vie. (3) La flèche en pointillés indique que la HyperPod plateforme crée des instances resource_config.json dans le cluster lors du provisionnement des ressources du cluster. resource_config.jsoncontient des informations sur les ressources du HyperPod cluster, telles que le clusterARN, les types d'instances et les adresses IP. Il est important de noter que vous devez préparer les scripts de cycle de vie pour attendre le resource_config.json fichier lors de la création du cluster. Pour plus d'informations, consultez le guide de procédure ci-dessous.

Le guide de procédure suivant explique ce qui se passe lors de la création d'un HyperPod cluster et explique comment les scripts de cycle de vie de base sont conçus.

  1. create_cluster.json— Pour soumettre une demande de création de HyperPod cluster, vous devez préparer un fichier de CreateCluster demande au JSON format. Dans cet exemple de bonnes pratiques, nous partons du principe que le fichier de demande est nommécreate_cluster.json. Écrivez create_cluster.json pour approvisionner un HyperPod cluster avec des groupes d'instances. La meilleure pratique consiste à ajouter le même nombre de groupes d'instances que le nombre de nœuds Slurm que vous prévoyez de configurer sur le HyperPod cluster. Assurez-vous de donner des noms distinctifs aux groupes d'instances que vous allez attribuer aux nœuds Slurm que vous prévoyez de configurer.

    Vous devez également spécifier un chemin de compartiment S3 pour stocker l'ensemble de vos fichiers de configuration et de scripts de cycle de vie InstanceGroups.LifeCycleConfig.SourceS3Uri dans le nom du champ du formulaire de CreateCluster demande, et spécifier le nom de fichier d'un script shell de point d'entrée (supposons qu'il est nomméon_create.sh) pour. InstanceGroups.LifeCycleConfig.OnCreate

    Note

    Si vous utilisez le formulaire de soumission de cluster dans l'interface utilisateur de la HyperPod console, la console gère le remplissage et l'envoi de la CreateCluster demande en votre nom, et l'exécute CreateCluster API dans le backend. Dans ce cas, vous n'avez pas besoin de créer create_cluster.json ; assurez-vous plutôt de spécifier les informations de configuration de cluster correctes dans le formulaire de soumission de créer un cluster.

  2. on_create.sh— Pour chaque groupe d'instances, vous devez fournir un script shell point d'entrée, pour exécuter des commandeson_create.sh, exécuter des scripts pour installer des packages logiciels et configurer l'environnement du HyperPod cluster avec Slurm. Les deux éléments que vous devez préparer sont un élément provisioning_parameters.json requis HyperPod pour configurer Slurm et un ensemble de scripts de cycle de vie pour l'installation de progiciels. Ce script doit être écrit pour rechercher et exécuter les fichiers suivants, comme indiqué dans l'exemple de script à l'adresse on_create.sh.

    Note

    Assurez-vous de télécharger l'ensemble complet des scripts de cycle de vie vers l'emplacement S3 que vous spécifiezcreate_cluster.json. Vous devez également le placer provisioning_parameters.json au même endroit.

    1. provisioning_parameters.json— C'est unFormulaire de configuration pour le provisionnement des nœuds Slurm sur HyperPod. Le on_create.sh script trouve ce JSON fichier et définit une variable d'environnement pour identifier le chemin d'accès à celui-ci. Grâce à ce JSON fichier, vous pouvez configurer les nœuds Slurm et les options de stockage telles qu'Amazon FSx pour que Lustre for Slurm communique avec. Dansprovisioning_parameters.json, assurez-vous d'attribuer les groupes d'instances de HyperPod cluster en utilisant les noms que vous avez spécifiés create_cluster.json aux nœuds Slurm de manière appropriée en fonction de la façon dont vous prévoyez de les configurer.

      Le schéma suivant montre un exemple de la façon dont les deux fichiers JSON create_cluster.json de configuration provisioning_parameters.json doivent être écrits pour attribuer des groupes d' HyperPod instances aux nœuds Slurm. Dans cet exemple, nous supposons la configuration de trois nœuds Slurm : le nœud contrôleur (gestion), le nœud de connexion (facultatif) et le nœud de calcul (travailleur).

      Astuce

      Pour vous aider à valider ces deux JSON fichiers, l'équipe du HyperPod service fournit un script de validation, validate-config.py. Pour en savoir plus, consultez Validez les fichiers JSON de configuration avant de créer un cluster Slurm sur HyperPod.

      Comparaison directe entre les fichiers .json.

      Figure : Comparaison directe entre la création create_cluster.json de HyperPod clusters et la configuration provisiong_params.json de Slurm. Le nombre de groupes d'instances create_cluster.json doit correspondre au nombre de nœuds que vous souhaitez configurer en tant que nœuds Slurm. Dans le cas de l'exemple de la figure, trois nœuds Slurm seront configurés sur un HyperPod cluster de trois groupes d'instances. Vous devez attribuer les groupes d'instances du HyperPod cluster aux nœuds Slurm en spécifiant les noms des groupes d'instances en conséquence.

    2. resource_config.json— Lors de la création du cluster, le lifecycle_script.py script est écrit pour s'attendre à ce qu'un resource_config.json fichier soit fourni HyperPod. Ce fichier contient des informations sur le cluster, telles que les types d'instances et les adresses IP.

      Lorsque vous exécutez le CreateClusterAPI, HyperPod crée un fichier de configuration des ressources sur la /opt/ml/config/resource_config.json base du create_cluster.json fichier. Le chemin du fichier est enregistré dans la variable d'environnement nomméeSAGEMAKER_RESOURCE_CONFIG_PATH.

      Important

      Le resource_config.json fichier est généré automatiquement par la HyperPod plateforme, et vous NOT devez le créer. Le code suivant montre un exemple de resource_config.json ce qui serait créé à partir de la création du cluster sur create_cluster.json la base de l'étape précédente, et pour vous aider à comprendre ce qui se passe dans le backend et à quoi resource_config.json ressemblerait une génération automatique.

      {
    "ClusterConfig": {
        "ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde01234yz",
        "ClusterName": "your-hyperpod-cluster"
    },
    "InstanceGroups": [
        {
            "Name": "controller-machine",
            "InstanceType": "ml.c5.xlarge",
            "Instances": [
                {
                    "InstanceName": "controller-machine-1",
                    "AgentIpAddress": "111.222.333.444",
                    "CustomerIpAddress": "111.222.333.444",
                    "InstanceId": "i-12345abcedfg67890"
                }
            ]
        },
        {
            "Name": "login-group",
            "InstanceType": "ml.m5.xlarge",
            "Instances": [
                {
                    "InstanceName": "login-group-1",
                    "AgentIpAddress": "111.222.333.444",
                    "CustomerIpAddress": "111.222.333.444",
                    "InstanceId": "i-12345abcedfg67890"
                }
            ]
        },
        {
            "Name": "compute-nodes",
            "InstanceType": "ml.trn1.32xlarge",
            "Instances": [
                {
                    "InstanceName": "compute-nodes-1",
                    "AgentIpAddress": "111.222.333.444",
                    "CustomerIpAddress": "111.222.333.444",
                    "InstanceId": "i-12345abcedfg67890"
                },
                {
                    "InstanceName": "compute-nodes-2",
                    "AgentIpAddress": "111.222.333.444",
                    "CustomerIpAddress": "111.222.333.444",
                    "InstanceId": "i-12345abcedfg67890"
                },
                {
                    "InstanceName": "compute-nodes-3",
                    "AgentIpAddress": "111.222.333.444",
                    "CustomerIpAddress": "111.222.333.444",
                    "InstanceId": "i-12345abcedfg67890"
                },
                {
                    "InstanceName": "compute-nodes-4",
                    "AgentIpAddress": "111.222.333.444",
                    "CustomerIpAddress": "111.222.333.444",
                    "InstanceId": "i-12345abcedfg67890"
                }
            ]
        }
    ]
}

    3. lifecycle_script.py— Il s'agit du script Python principal qui exécute collectivement les scripts de cycle de vie configurant Slurm sur le HyperPod cluster pendant le provisionnement. Ce script lit provisioning_parameters.json et resource_config.json extrait les chemins spécifiés ou identifiés danson_create.sh, transmet les informations pertinentes à chaque script de cycle de vie, puis exécute les scripts de cycle de vie dans l'ordre.

      Les scripts Lifecycle sont un ensemble de scripts que vous pouvez personnaliser en toute flexibilité pour installer des packages logiciels et configurer les configurations nécessaires ou personnalisées lors de la création du cluster, telles que la configuration de Slurm, la création d'utilisateurs, l'installation de Conda ou Docker. L'exemple de lifecycle_script.pyscript est préparé pour exécuter d'autres scripts de cycle de vie de base dans le référentiel, tels que le lancement de Slurm deamons () start_slurm.sh, le montage d'Amazon FSx pour Lustre (mount_fsx.sh) et la configuration de la comptabilité () et de la comptabilité () de MariaDB. setup_mariadb_accounting.shRDSsetup_rds_accounting.sh Vous pouvez également ajouter d'autres scripts, les regrouper dans le même répertoire et ajouter des lignes de code pour lifecycle_script.py permettre l' HyperPod exécution des scripts. Pour plus d'informations sur les scripts de cycle de vie de base, voir également 3.1 Scripts de cycle de vie dans le GitHub référentiel Awsome Distributed Training.

      Outre les configurations par défaut, d'autres scripts permettant d'installer les logiciels suivants sont disponibles dans le utilsdossier. Le lifecycle_script.py fichier est déjà prêt à inclure des lignes de code pour exécuter les scripts d'installation. Consultez les éléments suivants pour rechercher ces lignes et décommenter pour les activer.

      1. Les lignes de code suivantes concernent l'installation de Docker, Enroot et Pyxis. Ces packages sont nécessaires pour exécuter des conteneurs Docker sur un cluster Slurm.

        Pour activer cette étape d'installation, définissez le enable_docker_enroot_pyxis paramètre sur True dans le config.pyfichier.

        # Install Docker/Enroot/Pyxis
if Config.enable_docker_enroot_pyxis:
    ExecuteBashScript("./utils/install_docker.sh").run()
    ExecuteBashScript("./utils/install_enroot_pyxis.sh").run(node_type)

      2. Vous pouvez intégrer votre HyperPod cluster à Amazon Managed Service for Prometheus et à Amazon Managed Grafana pour exporter les mesures relatives au cluster et aux nœuds du cluster vers les tableaux de HyperPod bord Amazon Managed Grafana. Pour exporter des métriques et utiliser le tableau de bord Slurm, le tableau de bord NVIDIA DCGM Exporter et le tableau de bord EFA Metrics sur Amazon Managed Grafana, vous devez installer l'exportateur Slurm pour Prometheus, l'exportateur et l'exportateur de nœuds. NVIDIA DCGM EFA Pour plus d'informations sur l'installation des packages d'exportation et l'utilisation des tableaux de bord Grafana dans un espace de travail Grafana géré par Amazon, consultez. Surveiller les ressources SageMaker HyperPod du cluster

        Pour activer cette étape d'installation, définissez le enable_observability paramètre sur True dans le config.pyfichier.

        # Install metric exporting software and Prometheus for observability
if Config.enable_observability:
    if node_type == SlurmNodeType.COMPUTE_NODE:
        ExecuteBashScript("./utils/install_docker.sh").run()
        ExecuteBashScript("./utils/install_dcgm_exporter.sh").run()
        ExecuteBashScript("./utils/install_efa_node_exporter.sh").run()

    if node_type == SlurmNodeType.HEAD_NODE:
        wait_for_scontrol()
        ExecuteBashScript("./utils/install_docker.sh").run()
        ExecuteBashScript("./utils/install_slurm_exporter.sh").run()
        ExecuteBashScript("./utils/install_prometheus.sh").run()

  3. Assurez-vous de télécharger tous les fichiers de configuration et tous les scripts de configuration de l'étape 2 vers le compartiment S3 que vous avez fourni dans la CreateCluster demande de l'étape 1. Supposons, par exemple, que vous disposiez create_cluster.json des éléments suivants.

    "LifeCycleConfig": { 
    "SourceS3URI": "s3://sagemaker-hyperpod-lifecycle/src",
    "OnCreate": "on_create.sh"
}

    Ensuite, vous "s3://sagemaker-hyperpod-lifecycle/src" devez conteniron_create.sh, lifecycle_script.pyprovisioning_parameters.json, et tous les autres scripts de configuration. Supposons que vous ayez préparé les fichiers dans un dossier local comme suit.

    └── lifecycle_files // your local folder
    ├── provisioning_parameters.json
    ├── on_create.sh
    ├── lifecycle_script.py
    └── ... // more setup scrips to be fed into lifecycle_script.py

    Pour télécharger les fichiers, utilisez la commande S3 comme suit.

    aws s3 cp --recursive ./lifecycle_scripts s3://sagemaker-hyperpod-lifecycle/src

Quelles configurations particulières sont HyperPod gérées dans les fichiers de configuration de Slurm

Lorsque vous créez un cluster Slurm sur HyperPod, l' HyperPod agent configure les gres.conffichiers slurm.confet /opt/slurm/etc/ pour gérer le cluster Slurm en fonction de votre demande de création de cluster et de vos scripts de HyperPod cycle de vie. La liste suivante indique les paramètres spécifiques que l' HyperPod agent gère et remplace.

Important

Nous vous recommandons vivement de ne pas modifier ces paramètres gérés par HyperPod.

  • Dans slurm.conf, HyperPod définit les paramètres de base suivants : ClusterNameSlurmctldHost,PartitionName, etNodeName.

    En outre, pour activer la Reprise automatique fonctionnalité, HyperPod les SchedulerParameters paramètres TaskPlugin et doivent être définis comme suit. L' HyperPod agent définit ces deux paramètres avec les valeurs requises par défaut.

    TaskPlugin=task/none
SchedulerParameters=permit_job_expansion

  • Dans gres.conf, HyperPod gère NodeName les GPU nœuds.

Montez Amazon FSx for Lustre sur votre HyperPod cluster

Pour monter un système de fichiers partagé Amazon FSx for Lustre sur votre HyperPod cluster, configurez ce qui suit.

  1. Utilisez votre AmazonVPC.

    1. Pour que les instances de HyperPod cluster puissent communiquer au sein de votre entrepriseVPC, assurez-vous d'associer des autorisations supplémentaires, conformément IAMrôle pour SageMaker HyperPod aux instructions du IAM rôle pour SageMaker HyperPod.

    2. Danscreate_cluster.json, incluez les VPC informations suivantes.

      "VpcConfig": { 
    "SecurityGroupIds": [ "string" ],
    "Subnets": [ "string" ]
}

      Pour plus de conseils sur la configuration d'AmazonVPC, consultezConfiguration SageMaker HyperPod avec Amazon VPC.

  2. Pour terminer la configuration de Slurm avec Amazon FSx for Lustre, spécifiez le FSx DNS nom Amazon et le nom du FSx montage Amazon provisioning_parameters.json comme indiqué dans la figure de la Commencez par les scripts de cycle de vie de base fournis par HyperPod section. Vous pouvez trouver les FSx informations Amazon depuis la console Amazon FSx for Lustre de votre compte ou en exécutant la commande suivante AWS CLI commande,aws fsx describe-file-systems.

    "fsx_dns_name": "fs-12345678a90b01cde.fsx.us-west-2.amazonaws.com",
"fsx_mountname": "1abcdefg"

Validez les fichiers JSON de configuration avant de créer un cluster Slurm sur HyperPod

Pour valider les fichiers JSON de configuration avant de soumettre une demande de création de cluster, utilisez le script de validation de configuration validate-config.py. Ce script analyse et compare le fichier de configuration de votre HyperPod cluster et JSON le fichier de configuration JSON Slurm, et identifie toute erreur de configuration des ressources entre les deux fichiers et également entre les ressources Amazon, EC2 Amazon VPC et Amazon. FSx Par exemple, pour valider les provisioning_parameters.json fichiers create_cluster.json et de la Commencez par les scripts de cycle de vie de base fournis par HyperPod section, exécutez le script de validation comme suit.

python3 validate-config.py --cluster-config create_cluster.json --provisioning-parameters provisioning_parameters.json

Voici un exemple de résultat d'une validation réussie.

✔️  Validated instance group name worker-group-1 is correct ...
✔️  Validated subnet subnet-012345abcdef67890 ...
✔️  Validated security group sg-012345abcdef67890 ingress rules ...
✔️  Validated security group sg-012345abcdef67890 egress rules ...
✔️  Validated FSx Lustre DNS name fs-012345abcdef67890.fsx.us-east-1.amazonaws.com
✔️  Validated FSx Lustre mount name abcdefgh
✅ Cluster Validation succeeded

Validez le temps d'exécution avant d'exécuter des charges de travail de production sur un cluster Slurm sur HyperPod

Pour vérifier le temps d'exécution avant d'exécuter des charges de travail de production sur un cluster Slurm HyperPod, utilisez le script de validation de l'exécution. hyperpod-precheck.py Ce script vérifie si tous les packages nécessaires à l'exécution de Docker sont installés sur le cluster, si le cluster possède un système de fichiers Lustre correctement monté FSx et un répertoire utilisateur partageant le système de fichiers, et si le démon Slurm est exécuté sur tous les nœuds de calcul.

Pour exécuter le script sur plusieurs nœuds à la fois, utilisez srun comme indiqué dans l'exemple de commande suivant pour exécuter le script sur un cluster Slurm de 8 nœuds.

# The following command runs on 8 nodes
srun -N 8 python3 hyperpod-precheck.py
Note

Pour en savoir plus sur le script de validation, notamment les fonctions de validation d'exécution qu'il fournit et les instructions pour résoudre les problèmes qui ne passent pas les validations, consultez la section Validation de l'exécution avant d'exécuter des charges de travail dans le référentiel Awsome Distributed Training. GitHub

Développez des scripts de cycle de vie de manière interactive sur un nœud de cluster

Cette section explique comment développer des scripts de cycle de vie de manière interactive sans créer et supprimer un HyperPod cluster à plusieurs reprises.

  1. Créez un HyperPod cluster avec les scripts de cycle de vie de base.

  2. Connectez-vous à un nœud de cluster.

  3. Développez un script (configure_xyz.sh) en le modifiant et en l'exécutant à plusieurs reprises sur le nœud.

    1. HyperPod exécute les scripts de cycle de vie en tant qu'utilisateur root. Nous vous recommandons donc de les exécuter en configure_xyz.sh tant qu'utilisateur root pendant le développement afin de vous assurer que le script est testé dans les mêmes conditions lorsqu'il est exécuté par HyperPod.

  4. Intégrez le script en lifecycle_script.py ajoutant une ligne de code similaire à la suivante.

    ExecuteBashScript("./utils/configure_xyz.sh").run()

  5. Téléchargez les scripts de cycle de vie mis à jour dans le compartiment S3 que vous avez initialement utilisé pour télécharger les scripts de cycle de vie de base.

  6. Testez la version intégrée de lifecycle_script.py en créant un nouveau HyperPod cluster.

Mettre à jour un cluster avec des scripts de cycle de vie nouveaux ou mis à jour

Il existe trois méthodes pour mettre à jour le HyperPod logiciel.

  • UpdateClusterSoftwareAPIPour appliquer des correctifs au HyperPod logiciel, les scripts de cycle de vie sont réexécutés sur l'ensemble du groupe d'instances.

  • Il exécute UpdateCluster API uniquement les scripts de cycle de vie pour les nouveaux groupes d'instances.

  • Vous pouvez également exécuter des scripts de cycle de vie directement dans les HyperPod instances.

Considérations

Tenez compte des points suivants lors de l'utilisation SageMaker HyperPod.

  • HyperPod s'exécute SageMaker HyperPod DLAMI sur chaque instance d'un cluster, et AMI possède des progiciels préinstallés conformes aux compatibilités entre eux et HyperPod aux fonctionnalités. Notez que si vous réinstallez l'un des packages préinstallés, vous êtes responsable de l'installation des packages compatibles et notez que certaines HyperPod fonctionnalités risquent de ne pas fonctionner comme prévu.