Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Crear un SageMaker HyperPod clúster
Aprenda a crear SageMaker HyperPod clústeres orquestados por Amazon EKS mediante. AWS CLI
-
Antes de crear un SageMaker HyperPod clúster:
-
Asegúrese de disponer de un clúster de Amazon EKS existente y en funcionamiento. Para obtener instrucciones sobre cómo configurar un clúster de Amazon EKS, consulte Creación de un clúster de Amazon EKS en la Guía del usuario de Amazon EKS.
-
Instale el gráfico de Helm, tal y como se indica en Instalación de paquetes en el clúster de Amazon EKS mediante Helm. Si crea un Crear un clúster de HyperPod EKS con un grupo de instancias restringido (RIG), necesitará un gráfico de Helm distinto.
-
-
Prepare un script de configuración del ciclo de vida y cárguelo en un bucket de Amazon S3, como, por ejemplo,
s3://.amzn-s3-demo-bucket/Lifecycle-scripts/base-config/Para empezar rápidamente, descargue el script
on_create.shde muestra del GitHub repositorio de formación distribuida de AWS ome y cárguelo en el bucket de S3. También puede incluir instrucciones de configuración adicionales, una serie de scripts de configuración o comandos para que se ejecuten durante la etapa de aprovisionamiento del HyperPod clúster. importante
Si crea un Función de IAM para SageMaker HyperPod que se asocia únicamente a las
AmazonSageMakerClusterInstanceRolePolicyadministradas, el clúster tendrá acceso a los buckets de Amazon S3 con el prefijo específicosagemaker-.Si crea un grupo de instancias restringido, no tendrá que descargar ni ejecutar el script de ciclo de vida. En su lugar, deberá ejecutar
install_rig_dependencies.sh.Los requisitos previos para ejecutar el script
install_rig_dependencies.shson:-
AWS Tanto Node (CNI) como CoreDNS deben estar habilitados. Se trata de complementos de EKS estándar que no son gestionados por el SageMaker HyperPod Helm estándar, pero que se pueden activar fácilmente en la consola de EKS en la sección Complementos.
-
Se debe instalar el gráfico SageMaker HyperPod Helm estándar antes de ejecutar este script.
El script
install_rig_dependencies.shrealiza las siguientes acciones.-
aws-node(CNI): se ha creado un nuevorig-aws-nodeDaemonset; se ha parcheado elaws-nodeexistente para evitar los nodos RIG. -
coredns: Convertido a Daemonset RIGs para admitir el uso de varios equipos y evitar la sobrecarga. -
training-operators: se ha actualizado con las tolerancias de taint de trabajo de RIG y con nodeAffinity para favorecer las instancias que no son RIG.
-
Elastic Fabric Adapter (EFA): se ha actualizado para tolerar las propiedades taint de trabajo de RIG y utilizar las imágenes de contenedores correctas para cada región.
-
-
Prepare un archivo de solicitud CreateClusterde API en formato JSON. En
ExecutionRole, proporcione el ARN del rol de IAM que ha creado con laAmazonSageMakerClusterInstanceRolePolicyadministrada de la sección Función de IAM para SageMaker HyperPod.nota
Asegúrese de que el SageMaker HyperPod clúster esté implementado en la misma Nube Privada Virtual (VPC) que el clúster de Amazon EKS. Las subredes y los grupos de seguridad especificados en la configuración del SageMaker HyperPod clúster deben permitir la conectividad de red y la comunicación con el punto final del servidor API del clúster de 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" }Tenga en cuenta lo siguiente al configurar la creación de un nuevo SageMaker HyperPod clúster que se asocie a un clúster de EKS.
-
Puede configurar hasta 20 grupos de instancias con el parámetro
InstanceGroups. -
En
Orchestator.Eks.ClusterArn, especifique el ARN del clúster de EKS que desea usar como orquestador. -
En
OnStartDeepHealthChecks, añadaInstanceStressyInstanceConnectivitypara habilitar Comprobaciones de estado exhaustivas. -
Para
NodeRecovery, especifique si deseaAutomatichabilitar la recuperación automática de nodos. SageMaker HyperPod reemplaza o reinicia las instancias (nodos) cuando el agente de supervisión del estado detecta problemas. -
Para el
Tagsparámetro, puede agregar etiquetas personalizadas para administrar el SageMaker HyperPod clúster como un AWS recurso. Puede añadir etiquetas al clúster del mismo modo que las añadiría a otros servicios de AWS que admitan el etiquetado. Para obtener más información sobre el etiquetado de recursos de AWS en general, consulte Tagging AWS Resources User Guide. -
En el parámetro
VpcConfig, especifique la información de la VPC utilizada en el clúster de EKS. Las subredes deben ser privadas. -
Si lo desea
Orchestrator.Eks.KubernetesConfig.Labels, puede especificar las etiquetas de Kubernetes para aplicarlas a los nodos. Para habilitar la partición de la GPU con una GPU de instancias múltiples (MIG), añada lanvidia.com/mig.configetiqueta con el perfil MIG deseado. Por ejemplo,"nvidia.com/mig.config": "all-3g.40gb"configura todo GPUs con el perfil de partición de 3g.40 gb. Para obtener más información sobre la partición de la GPU y los perfiles disponibles, consulte. Uso de particiones de GPU en Amazon SageMaker HyperPod
-
-
Ejecute el comando create-cluster de la siguiente manera.
importante
Al ejecutar el comando
create-clustercon el parámetro--cli-input-json, debe incluir el prefijofile://delante de la ruta completa al archivo JSON. Este prefijo es necesario para garantizar que AWS CLI reconozca la entrada como una ruta de archivo. Si se omite el prefijofile://, se genera un error de análisis de parámetros.aws sagemaker create-cluster \ --cli-input-jsonfile://complete/path/to/create_cluster.jsonEsto debería devolver el ARN del nuevo clúster.
importante
Puede usar la operación update-cluster para eliminar un grupo de instancias restringido (RIG). Cuando un RIG se reduce a 0, el sistema de archivos FSx de Lustre no se eliminará. Para eliminar por completo el FSx sistema de archivos de Lustre, debe eliminar el RIG por completo.
Al eliminar un RIG, no se elimina ningún artefacto almacenado en el bucket de Amazon S3 administrado por el servicio. Sin embargo, debe asegurarse de que todos los artefactos del sistema de archivos de FSx for Lustre estén completamente sincronizados con Amazon S3 antes de eliminarlos. Recomendamos esperar al menos 30 minutos después de finalizar el trabajo para garantizar la sincronización completa de todos los artefactos del sistema de archivos de Lustre con el bucket de Amazon S3 gestionado FSx por el servicio.
importante
Si utilizas una reserva de capacidad bajo demanda (ODCR) integrada, debes asignar tu grupo de instancias al mismo ID de zona de disponibilidad (AZ ID) que la ODCR, configurándolo
OverrideVpcConfigcon una subred en el ID AZ correspondiente.FUNDAMENTAL: Verifica la
OverrideVpcConfigconfiguración antes de la implementación para evitar incurrir en cargos duplicados tanto por la ODCR como por la capacidad bajo demanda.