Creazione di un cluster SageMaker HyperPod - Amazon SageMaker AI

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Creazione di un cluster SageMaker HyperPod

Scopri come creare SageMaker HyperPod cluster orchestrati da Amazon EKS utilizzando. AWS CLI

  1. Prima di creare un cluster: SageMaker HyperPod

    1. Assicurati di disporre di un cluster Amazon EKS funzionante. Per istruzioni dettagliate su come configurare un cluster Amazon EKS, consulta Create an Amazon EKS cluster in Amazon EKS User Guide.

    2. Installa il grafico Helm come indicato in Installazione di pacchetti sul cluster Amazon EKS con Helm. Se crei un Creazione di un cluster HyperPod EKS con un gruppo di istanze ristrette (RIG), avrai bisogno di un grafico Helm separato.

  2. Prepara uno script di configurazione del ciclo di vita e caricalo in un bucket Amazon S3, ad esempio s3://amzn-s3-demo-bucket/Lifecycle-scripts/base-config/.

    Per iniziare rapidamente, scarica lo script di esempio on_create.shdal GitHub repository AWS home Distributed Training e caricalo nel bucket S3. Puoi anche includere istruzioni di configurazione aggiuntive, una serie di script di configurazione o comandi da eseguire durante la fase di provisioning del HyperPod cluster.

    Importante

    Se crei un Ruolo IAM per SageMaker HyperPod collegando solo la AmazonSageMakerClusterInstanceRolePolicy gestita, il tuo cluster ha accesso ai bucket Amazon S3 con il prefisso sagemaker- specifico.

    Se crei un gruppo di istanze limitato, non devi scaricare ed eseguire lo script del ciclo di vita. Devi eseguire install_rig_dependencies.sh, invece.

    I prerequisiti per eseguire lo script install_rig_dependencies.sh includono:

    • AWSNode (CNI) e CoredNS devono essere entrambi abilitati. Si tratta di componenti aggiuntivi EKS standard che non sono gestiti dall' SageMaker HyperPod Helm standard, ma possono essere facilmente abilitati nella console EKS alla voce Componenti aggiuntivi.

    • Il grafico SageMaker HyperPod Helm standard deve essere installato prima di eseguire questo script.

    Lo script install_rig_dependencies.sh esegue queste operazioni.

    • aws-node (CNI): nuovo DaemonSet rig-aws-node creato; applicate patch al aws-node esistente per evitare nodi RIG.

    • coredns: Convertito in Daemonset per supportare l'uso di Multi-Rig e RIGs prevenire il sovraccarico.

    • training-operators: aggiornato con le tolleranze di taint dei worker RIG e con nodeAffinity che favorisce le istanze non RIG.

    • Elastic Fabric Adapter (EFA): aggiornato per tollerare il taint dei worker RIG e utilizzare immagini dei container corrette per ogni Regione.

  3. Prepara un file di richiesta CreateClusterAPI in formato JSON. Per ExecutionRole, fornisci l’ARN del ruolo IAM che hai creato con la policy gestita AmazonSageMakerClusterInstanceRolePolicy nella sezione Ruolo IAM per SageMaker HyperPod.

    Nota

    Assicurati che il SageMaker HyperPod cluster sia distribuito all'interno dello stesso Virtual Private Cloud (VPC) del cluster Amazon EKS. Le sottoreti e i gruppi di sicurezza specificati nella configurazione del SageMaker HyperPod cluster devono consentire la connettività di rete e la comunicazione con l'endpoint del server API del cluster Amazon EKS.

    // create_cluster.json { "ClusterName": "string", "InstanceGroups": [{ "InstanceGroupName": "string", "InstanceType": "string", "InstanceCount": number, "LifeCycleConfig": { "SourceS3Uri": "s3://amzn-s3-demo-bucket-sagemaker/lifecycle-script-directory/src/", "OnCreate": "on_create.sh" }, "ExecutionRole": "string", "ThreadsPerCore": number, "OnStartDeepHealthChecks": [ "InstanceStress", "InstanceConnectivity" ] }], "RestrictedInstanceGroups": [ { "EnvironmentConfig": { "FSxLustreConfig": { "PerUnitStorageThroughput": number, "SizeInGiB": number } }, "ExecutionRole": "string", "InstanceCount": number, "InstanceGroupName": "string", "InstanceStorageConfigs": [ { ... } ], "InstanceType": "string", "OnStartDeepHealthChecks": [ "string" ], "OverrideVpcConfig": { "SecurityGroupIds": [ "string" ], "Subnets": [ "string" ] }, "ScheduledUpdateConfig": { "DeploymentConfig": { "AutoRollbackConfiguration": [ { "AlarmName": "string" } ], "RollingUpdatePolicy": { "MaximumBatchSize": { "Type": "string", "Value": number }, "RollbackMaximumBatchSize": { "Type": "string", "Value": number } }, "WaitIntervalInSeconds": number }, "ScheduleExpression": "string" }, "ThreadsPerCore": number, "TrainingPlanArn": "string" } ], "VpcConfig": { "SecurityGroupIds": ["string"], "Subnets": ["string"] }, "Tags": [{ "Key": "string", "Value": "string" }], "Orchestrator": { "Eks": { "ClusterArn": "string", "KubernetesConfig": { "Labels": { "nvidia.com/mig.config": "all-3g.40gb" } } } }, "NodeRecovery": "Automatic" }

    Tieni presente quanto segue durante la configurazione per creare un nuovo SageMaker HyperPod cluster associato a un cluster EKS.

    • Puoi configurare fino a 20 gruppi di istanze nel parametro InstanceGroups.

    • Per Orchestator.Eks.ClusterArn, specifica l’ARN del cluster EKS da utilizzare come orchestratore.

    • Per OnStartDeepHealthChecks, aggiungi InstanceStress e InstanceConnectivity per abilitare Controlli dell’integrità approfonditi.

    • PerNodeRecovery, specificare di Automatic abilitare il ripristino automatico dei nodi. SageMaker HyperPod sostituisce o riavvia le istanze (nodi) quando l'agente di monitoraggio dello stato rileva problemi.

    • Per il Tags parametro, è possibile aggiungere tag personalizzati per la gestione del SageMaker HyperPod cluster come risorsa. AWS Puoi aggiungere tag al cluster con la stessa procedura utilizzata per altri servizi AWS che supportano il tagging. Per ulteriori informazioni generali sul tagging delle risorse AWS, consulta Tagging AWS Resources User Guide.

    • Per il parametro VpcConfig, specifica le informazioni del VPC utilizzato nel cluster EKS. Le sottoreti devono essere private.

    • In alternativaOrchestrator.Eks.KubernetesConfig.Labels, puoi specificare le etichette Kubernetes da applicare ai nodi. Per abilitare il partizionamento della GPU con Multi-Instance GPU (MIG), aggiungi l'etichetta con il profilo MIG desiderato. nvidia.com/mig.config Ad esempio, "nvidia.com/mig.config": "all-3g.40gb" configura tutto con il profilo di partizione 3g.40gb. GPUs Per ulteriori informazioni sul partizionamento GPU e sui profili disponibili, vedere. Utilizzo delle partizioni GPU in Amazon SageMaker HyperPod

  4. Utilizza il comando create-cluster come segue.

    Importante

    Quando esegui il comando create-cluster con il parametro --cli-input-json, devi includere il prefisso file:// prima del percorso completo del file JSON. Questo prefisso è necessario per garantire che AWS CLI riconosca l'input come percorso di file. L’omissione del prefisso file:// genera un errore di analisi del parametro.

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

    Questo dovrebbe restituire l’ARN del nuovo cluster.

    Importante

    Per rimuovere un gruppo di istanze limitato (RIG), puoi utilizzare l’operazione update-cluster. Quando un RIG viene ridimensionato a 0, il file system FSx for Lustre non verrà eliminato. Per rimuovere completamente il file system FSx for Lustre, è necessario rimuovere completamente il RIG.

    La rimozione di un RIG non eliminerà gli artefatti archiviati nel bucket Amazon S3 gestito dal servizio. Tuttavia, è necessario assicurarsi che tutti gli artefatti nel file system FSx for Lustre siano completamente sincronizzati con Amazon S3 prima della rimozione. Ti consigliamo di attendere almeno 30 minuti dopo il completamento del processo per garantire la sincronizzazione completa di tutti gli elementi dal file system FSx for Lustre al bucket Amazon S3 gestito dal servizio.

    Importante

    Quando si utilizza una On-Demand Capacity Reservation (ODCR) onboarding, è necessario mappare il gruppo di istanze allo stesso ID della zona di disponibilità (ID AZ) dell'ODCR impostando una sottorete nell'ID AZ corrispondente. OverrideVpcConfig

    CRITICO: verifica la OverrideVpcConfig configurazione prima dell'implementazione per evitare di incorrere in addebiti duplicati sia per ODCR che per On-Demand Capacity.