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 Slurm Orchestration 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.

Comment ça marche

Le système de provisionnement continu introduit une architecture à état souhaité qui remplace le modèle de mise à l'échelle traditionnel du tout ou rien. 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 :

Le provisionnement continu est désactivé par défaut. Pour utiliser cette fonctionnalité, NodeProvisioningMode définissez-la sur 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.

Priority-based approvisionnement

Les clusters Slurm nécessitent qu'un nœud contrôleur soit 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 :

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 varie selon que l'erreur peut être réessayée ou non.

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

Non-retryable erreurs (par exemple, aucune capacité disponible pour le type d'instance de contrôleur ou échec du script du cycle de vie) :

Conditions préalables

Le provisionnement continu nécessite que les paramètres de provisionnement de Slurm (types de nœuds, noms de partition) 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.

Comptage d’utilisation

HyperPod les clusters dotés d'un provisionnement continu utilisent des compteurs 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.

Instance-level facturation

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 :

Cycle de vie de facturation

Chaque instance de votre HyperPod cluster suit ce cycle de vie de facturation :

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

Préparez un fichier de demande d'CreateClusterAPI au format JSON. Définissez Continuous et fournissez NodeProvisioningMode les informations de topologie 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 soumettre 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 en plus de celles que vous avez modifiées. slurm.conf HyperPod met uniquement à jour les sections relatives aux partitions 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 :

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.

Exigences de capacité minimale (MinCount)

MinCount Cette fonctionnalité vous permet de spécifier le nombre minimum d'instances qui doivent être correctement provisionnées avant qu'un groupe d'instances ne passe au InService statut. Cette fonctionnalité permet de mieux contrôler les opérations de dimensionnement et permet d'éviter les scénarios dans lesquels des groupes d'instances partiellement provisionnés ne peuvent pas être utilisés efficacement pour les charges de travail de formation.

Comment MinCount fonctionne

Lorsque vous créez ou mettez à jour un groupe d'instances avec MinCount activé, le comportement suivant se produit :

État du groupe d'instances pendant MinCount les opérations

Les groupes d'instances MinCount configurés présentent le comportement d'état suivant :

Pendant Creating ou pendant le Updating statut, les restrictions suivantes s'appliquent :

Comportement de restauration automatique

Si un groupe d'instances ne peut pas atteindre le sien MinCount dans les 3 heures, le système lance automatiquement un rollback pour éviter une attente indéfinie :

Le délai d'expiration de 3 heures est réinitialisé à chaque MinCount mise à jour. Par exemple, si vous effectuez MinCount plusieurs mises à jour, le délai d'expiration recommence à partir de la dernière mise à jour.

MinCount événements

Le système émet des événements spécifiques pour vous aider à suivre les MinCount opérations :

Vous pouvez surveiller ces événements ListClusterEvents pour suivre la progression de vos MinCount opérations.

Utilisation de l'API

MinCount est spécifié à l'aide du MinInstanceCount paramètre dans les configurations de groupes d'instances :

aws sagemaker create-cluster \
--cluster-name $HP_CLUSTER_NAME \
--instance-groups '[
    {
      "InstanceGroupName": "controller-machine",
      "InstanceType": "ml.c5.xlarge",
      "InstanceCount": 1,
      "SlurmConfig": {"NodeType": "Controller"},
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://'$BUCKET_NAME'",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "'$EXECUTION_ROLE'",
      "ThreadsPerCore": 2
    },
    {
      "InstanceGroupName": "my-login-group",
      "InstanceType": "ml.c5.xlarge",
      "InstanceCount": 1,
      "SlurmConfig": {"NodeType": "Login"},
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://'$BUCKET_NAME'",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "'$EXECUTION_ROLE'",
      "ThreadsPerCore": 1
    },
    {
      "InstanceGroupName": "worker-group-1",
      "InstanceType": "ml.c5.xlarge",
      "MinInstanceCount": 1,
      "InstanceCount": 2,
      "SlurmConfig": {
        "NodeType": "Compute",
        "PartitionNames": ["p1"]
      },
      "LifeCycleConfig": {
        "SourceS3Uri": "s3://'$BUCKET_NAME'",
        "OnCreate": "on_create.sh"
      },
      "ExecutionRole": "'$EXECUTION_ROLE'",
      "ThreadsPerCore": 1
    }
  ]' \
  --vpc-config '{
    "SecurityGroupIds": ["'$SECURITY_GROUP'"],
    "Subnets": ["'$SUBNET'"]
  }' \
  --node-provisioning-mode Continuous

Principales considérations relatives à MinCount l'utilisation :