View a markdown version of this page

Provisionnement continu pour des opérations de cluster améliorées avec Slurm - Amazon SageMaker AI
Comment ça marcheProvisionnement basé sur les prioritésGestion des défaillances du contrôleurConditions préalablesComptage d’utilisationCréation d’un cluster avec le provisionnement continu activéGestion de la configuration de Slurm

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.

Provisionnement continu pour des opérations de cluster améliorées avec Slurm

SageMaker HyperPod Les clusters Amazon créés avec l'orchestration de Slurm prennent désormais en charge le provisionnement continu, une fonctionnalité qui permet une flexibilité et une efficacité accrues lors de l'exécution de charges de travail à grande échelle. AI/ML Le provisionnement continu vous permet de démarrer l’entraînement rapidement, de procéder facilement à une mise à l’échelle, d’effectuer la maintenance sans interrompre les opérations et de bénéficier d’une visibilité granulaire sur les opérations du cluster.

Note

Le provisionnement continu est disponible en tant que configuration optionnelle pour les nouveaux HyperPod clusters créés avec l'orchestration de Slurm. Les clusters existants utilisant le modèle de dimensionnement précédent ne peuvent pas être migrés vers le provisionnement continu pour le moment.

Comment ça marche

Le système de provisionnement continu introduit une architecture à l'état souhaité qui remplace le modèle de dimensionnement traditionnel all-or-nothing. Dans le modèle précédent, si un groupe d'instances ne pouvait pas être entièrement provisionné, l'opération complète de création ou de mise à jour du cluster échouait et était annulée. Avec le provisionnement continu, le système accepte une capacité partielle et continue de provisionner les instances restantes de manière asynchrone.

Le système de provisionnement continu :

  • Accepte la demande : enregistre le nombre d'instances cibles pour chaque groupe d'instances.

  • Lance le provisionnement : commence à lancer des instances pour tous les groupes d'instances en parallèle.

  • Provisionne d'abord les nœuds prioritaires : le cluster InService passe à un nœud contrôleur (et un nœud de connexion, si un groupe d'instances de connexion est spécifié) a été correctement provisionné.

  • Suit la progression : surveille chaque tentative de lancement d'instance et enregistre le statut.

  • Gère les échecs : retente automatiquement les lancements échoués pour les nœuds de travail de manière asynchrone.

Le provisionnement continu est désactivé par défaut. Pour utiliser cette fonctionnalité, définissez ce NodeProvisioningMode paramètre Continuous dans votre CreateCluster demande.

Lorsque le provisionnement continu est activé, vous pouvez lancer plusieurs opérations de mise à l’échelle simultanément sans attendre la fin des opérations précédentes. Cela vous permet de mettre à l’échelle simultanément différents groupes d’instances dans le même cluster et de soumettre plusieurs demandes de mise à l’échelle au même groupe d’instances.

Provisionnement basé sur les priorités

Les clusters Slurm nécessitent un nœud contrôleur pour être opérationnel avant que les nœuds de travail puissent enregistrer et accepter des tâches. Le provisionnement continu gère cela automatiquement grâce à un provisionnement basé sur les priorités :

  1. Le groupe d'instances du contrôleur est approvisionné en premier.

  2. Une fois qu'un nœud de contrôleur est sain, les nœuds de connexion et les nœuds de travail commencent à s'approvisionner en parallèle.

  3. Le cluster passe InService lorsqu'un nœud de contrôleur est actif et qu'un nœud de connexion est actif (si un groupe d'instances de connexion est spécifié). Si aucun groupe d'instances de connexion n'est spécifié, le cluster passe InService en cluster dès que le nœud contrôleur est provisionné.

  4. Les nœuds de travail qui ne peuvent pas être approvisionnés immédiatement en raison de contraintes de capacité entrent dans une boucle de réessai asynchrone et sont automatiquement ajoutés au cluster Slurm dès qu'ils sont disponibles.

Gestion des défaillances du contrôleur

Lors de la création du cluster, si le nœud du contrôleur ne parvient pas à se provisionner, le comportement dépend du fait que l'erreur est réessayable ou non réessayable.

Erreurs réessayables (par exemple, instance défectueuse ou défaillances transitoires) :

  • HyperPod remplace en permanence l'instance et tente à nouveau de le provisionner jusqu'à ce que le contrôleur apparaisse.

  • Les nœuds de travail et de connexion qui ont déjà été provisionnés restent disponibles, mais le cluster n'est pas transféré InService tant que le contrôleur n'est pas sain.

Erreurs non réessayables (par exemple, absence de capacité disponible pour le type d'instance du contrôleur ou échec du script de cycle de vie) :

  • Le cluster est marqué commeFailed.

  • Vous êtes informé de la raison de l'échec et devez prendre des mesures correctives, telles que le choix d'un autre type d'instance, la correction des scripts de cycle de vie ou une nouvelle tentative dans une autre zone de disponibilité.

Conditions préalables

Le provisionnement continu nécessite que les paramètres de provisionnement de Slurm (types de nœuds, noms de partitions) soient fournis via la charge utile de l'API dans le champ de chaque groupe d'instances. SlurmConfig Les clusters qui s'appuient sur l'ancien provisioning_parameters.json fichier d'Amazon S3 ne sont pas compatibles avec le provisionnement continu.

Note

Les fonctionnalités suivantes ne sont actuellement pas prises en charge avec le provisionnement continu sur les clusters Slurm : migration des clusters existants, configuration de nœuds à plusieurs têtes via la topologie Slurm basée sur l'API, et. SlurmConfigStrategy Le provisionnement continu fonctionne exclusivement en mode fusion pour la slurm.conf gestion.

Comptage d’utilisation

HyperPod les clusters dotés d'un provisionnement continu utilisent des mesures au niveau de l'instance pour fournir une facturation précise qui reflète l'utilisation réelle des ressources. Cette approche des mesures diffère de la facturation traditionnelle au niveau du cluster, car elle permet de suivre chaque instance indépendamment.

Facturation au niveau de l’instance

Avec le provisionnement continu, la facturation commence et s’arrête au niveau de l’instance individuelle au lieu d’attendre les changements d’état au niveau du cluster. Cette approche présente les avantages suivants :

  • Exactitude précise de la facturation : la facturation commence lorsque l’exécution du script de cycle de vie commence. Si le script de cycle de vie échoue, le provisionnement de l'instance sera réessayé et vous serez facturé pour la durée d'exécution du script de cycle de vie.

  • Mesure indépendante : le cycle de vie de facturation de chaque instance est géré séparément, ce qui permet d'éviter les erreurs de facturation en cascade.

  • Mises à jour de facturation en temps réel : la facturation commence lorsqu'une instance commence à exécuter son script de configuration du cycle de vie et s'arrête lorsque l'instance entre dans un état de terminaison.

Cycle de vie de facturation

Chaque instance de votre HyperPod cluster suit le cycle de facturation suivant :

  • La facturation commence : lorsque l'instance démarre avec succès et commence à exécuter son script de configuration du cycle de vie.

  • La facturation continue : pendant toute la durée de vie opérationnelle de l'instance.

  • Arrêt de la facturation : lorsque l'instance entre dans un état de terminaison, quelle que soit la raison de la résiliation.

Note

La facturation ne démarre pas pour les instances qui ne démarrent pas. Si le lancement d’une instance échoue en raison d’une capacité insuffisante ou d’autres problèmes, cette tentative infructueuse ne vous est pas facturée. La facturation est calculée au niveau de l’instance et les coûts sont agrégés et signalés sous l’Amazon Resource Name (ARN) de votre cluster.

Création d’un cluster avec le provisionnement continu activé

Note

Préparez un script de configuration du cycle de vie et chargez-le dans un compartiment Amazon S3 auquel votre rôle d'exécution peut accéder. Pour de plus amples informations, veuillez consulter SageMaker HyperPod Opérations du cluster Slurm.

Préparez un fichier de demande d'CreateClusterAPI au format JSON. Définissez Continuous et fournissez NodeProvisioningMode les informations topologiques de Slurm dans le champ de chaque groupe d'instances. SlurmConfig

// create_cluster.json
{
    "ClusterName": "my-training-cluster",
    "NodeProvisioningMode": "Continuous",
    "Orchestrator": {
        "Slurm": {}
    },
    "InstanceGroups": [
        {
            "InstanceGroupName": "controller-group",
            "InstanceType": "ml.m5.xlarge",
            "InstanceCount": 1,
            "LifeCycleConfig": {
                "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
                "OnCreate": "on_create.sh"
            },
            "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
            "SlurmConfig": {
                "NodeType": "Controller"
            }
        },
        {
            "InstanceGroupName": "login-group",
            "InstanceType": "ml.m5.xlarge",
            "InstanceCount": 1,
            "LifeCycleConfig": {
                "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
                "OnCreate": "on_create.sh"
            },
            "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
            "SlurmConfig": {
                "NodeType": "Login"
            }
        },
        {
            "InstanceGroupName": "worker-gpu-a",
            "InstanceType": "ml.p5.48xlarge",
            "InstanceCount": 16,
            "LifeCycleConfig": {
                "SourceS3Uri": "s3://amzn-s3-demo-bucket/lifecycle-scripts/src/",
                "OnCreate": "on_create.sh"
            },
            "ExecutionRole": "arn:aws:iam::111122223333:role/iam-role-for-cluster",
            "SlurmConfig": {
                "NodeType": "Compute",
                "PartitionNames": ["gpu-training"]
            }
        }
    ],
    "VpcConfig": {
        "SecurityGroupIds": ["sg-12345678"],
        "Subnets": ["subnet-12345678"]
    }
}

Exécutez la create-cluster commande pour envoyer la demande.

aws sagemaker create-cluster \
    --cli-input-json file://complete/path/to/create_cluster.json

Cela renvoie l'ARN du nouveau cluster.

{
    "ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde12345"
}

Gestion de la configuration de Slurm

Le provisionnement continu fonctionne exclusivement en mode fusion pour la gestion des slurm.conf partitions. En mode fusion, HyperPod applique les modifications de configuration de sa partition de manière additive à celles que vous avez modifiées. slurm.conf HyperPod met uniquement à jour les sections relatives à la partition de slurm.conf (telles que les entrées de nom de partition et de nom de nœud) ; les autres paramètres de configuration de Slurm ne sont pas modifiés. Autrement dit :

  • Vos modifications manuelles slurm.conf sont conservées.

  • Il n'y a pas de détection automatique de la dérive ni de résolution des conflits entre vos modifications et HyperPod l'état attendu.

Le SlurmConfigStrategy paramètre (Managed,Merge,Overwrite) n'est pas pris en charge avec le provisionnement continu. La transmission d'une SlurmConfigStrategy valeur entraîne une erreur d'API.