View a markdown version of this page

Aprovisionamiento continuo para mejorar las operaciones del clúster en Amazon EKS - Amazon SageMaker AI

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.

Aprovisionamiento continuo para mejorar las operaciones del clúster en Amazon EKS

SageMaker HyperPod Los clústeres de Amazon creados con la orquestación de Amazon EKS ahora admiten el aprovisionamiento continuo, una nueva capacidad que permite una mayor flexibilidad y eficiencia al ejecutar cargas de trabajo a gran escala AI/ML . El aprovisionamiento continuo le permite empezar a entrenar rápidamente, escalar sin problemas, realizar tareas de mantenimiento sin interrumpir las operaciones y obtener una visión detallada de las operaciones del clúster.

nota

El aprovisionamiento continuo está disponible como configuración opcional para los HyperPod clústeres creados con la orquestación de EKS. Los clústeres creados con la orquestación de Slurm utilizan un modelo de escalado diferente.

Funcionamiento

El sistema de aprovisionamiento continuo presenta una arquitectura de estado deseado que reemplaza el modelo tradicional basado en solicitudes. Esta nueva arquitectura admite operaciones paralelas y sin bloqueo en diferentes niveles de recursos sin afectar a la estabilidad y el rendimiento del sistema. El sistema de aprovisionamiento continuo:

  • Acepta la solicitud: registra el recuento de instancias de destino para cada grupo de instancias.

  • Inicia el aprovisionamiento: comienza a lanzar instancias para cumplir con el recuento objetivo.

    Hace un seguimiento del progreso: supervisa cada intento de lanzamiento de una instancia y registra el estado.

  • Gestiona los errores: reintenta automáticamente los lanzamientos fallidos.

El aprovisionamiento continuo está deshabilitado de forma predeterminada. Para utilizar esta característica, debe configurar --node-provisioning-mode en Continuous.

Con el aprovisionamiento continuo activado, puede iniciar varias operaciones de escalado simultáneamente sin esperar a que se completen las operaciones anteriores. Esto le permite escalar diferentes grupos de instancias en el mismo clúster de forma simultánea y enviar varias solicitudes de escalado al mismo grupo de instancias.

El aprovisionamiento continuo también le permite acceder a una supervisión detallada de los eventos DescribeClusterEventy a una ListClusterEventvisibilidad operativa, así como a una visibilidad operativa.

Medición de uso

HyperPod Los clústeres con aprovisionamiento continuo utilizan la medición a nivel de instancia para proporcionar una facturación precisa que refleje el uso real de los recursos. Este enfoque de medición se diferencia de la facturación tradicional de clústeres, ya que hace un seguimiento de cada instancia de forma independiente.

Facturación por instancia

Con el aprovisionamiento continuo, la facturación comienza y termina en cada instancia en lugar de esperar a que cambie el estado del clúster. A continuación se enumeran los beneficios de este enfoque:

  • Precisión de la facturación: la facturación comienza cuando se inicia la ejecución del script de ciclo de vida. Si el script de ciclo de vida falla, se volverá a intentar aprovisionar la instancia y se le cobrará por el tiempo de ejecución del script de ciclo de vida.

  • Medición independiente: el ciclo de vida de facturación de cada instancia se administra por separado, lo que evita errores de facturación en cascada.

  • Actualizaciones de facturación en tiempo real: la facturación comienza cuando una instancia empieza a ejecutar su script de ciclo de vida y se detiene cuando la instancia entra en un estado de finalización.

Ciclo de vida de facturación

Cada instancia del HyperPod clúster sigue este ciclo de vida de facturación:

  • Inicio de la facturación: cuando la instancia se lanza correctamente y comienza a ejecutar su script de configuración del ciclo de vida.

  • La facturación continúa: durante toda la vida operativa de la instancia.

  • La facturación se detiene: cuando la instancia entra en un estado de finalización, independientemente del motivo de la finalización.

nota

La facturación no se inicia en el caso de las instancias que no se consiguen lanzar. Si el lanzamiento de una instancia falla debido a una falta de capacidad o por otros problemas, no se le cobrará por ese intento fallido. La facturación se calcula por instancia y los costos se agregan y anotan en el Nombre de recurso de Amazon (ARN) de su clúster.

Creación de un clúster con el aprovisionamiento continuo activado

nota

Debe tener un clúster de Amazon EKS existente configurado con una red de VPC y tener instalado el gráfico de Helm necesario. Además, debe preparar un script de configuración del ciclo de vida y cargarlo en un bucket de Amazon S3 al que pueda acceder su rol de ejecución. Para obtener más información, consulte Administración de SageMaker HyperPod clústeres orquestados por Amazon EKS.

La siguiente AWS CLI operación crea un HyperPod clúster con un grupo de instancias y el aprovisionamiento continuo activados.

aws sagemaker create-cluster \ --cluster-name $HP_CLUSTER_NAME \ --orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \ --vpc-config '{ "SecurityGroupIds": ["'$SECURITY_GROUP'"], "Subnets": ["'$SUBNET'"] }' \ --instance-groups '{ "InstanceGroupName": "ig-1", "InstanceType": "ml.c5.2xlarge", "InstanceCount": 2, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create_noop.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'", "ThreadsPerCore": 1, "TrainingPlanArn": "" }' \ --node-provisioning-mode Continuous // Expected Output: { "ClusterArn": "arn:aws:sagemaker:us-west-2:<account-id>:cluster/<cluster-id>" }

Una vez que hayas creado el clúster, puedes usar ListClusterNodeso DescribeClusterNodepara obtener más información sobre los nodos del clúster.

Al llamar a estas operaciones, se devolverá un ClusterInstanceStatusDetailsobjeto con uno de los siguientes valores:

  • Running: el nodo está en buen estado y registrado en el orquestador de clústeres (EKS).

  • Failure: se ha producido un error en el aprovisionamiento del nodo, pero el sistema volverá a intentarlo automáticamente con una nueva instancia de EC2.

  • Pending: el nodo se está aprovisionando o reiniciando.

  • ShuttingDown: La terminación del nodo está en curso. El nodo o bien pasa al estado Failure si se produce algún problema con la terminación o bien se elimina correctamente del clúster.

  • SystemUpdating: El nodo está siendo parcheado por la AMI, ya sea de forma manual o como parte de la aplicación de parches a cronjobs.

  • DeepHealthCheckInProgress: Se están realizando controles de estado exhaustivos (DHCs). Esto puede tardar entre unos minutos y varias horas, según la naturaleza de las pruebas. Los nodos malos se reemplazan y los nodos en buen estado pasan a estar en ejecución.

  • NotFound: Se utiliza como BatchAddClusterNodesrespuesta para indicar que se ha eliminado un nodo durante una reproducción idempotente.

Requisitos mínimos de capacidad () MinCount

La MinCount función te permite especificar la cantidad mínima de instancias que se deben aprovisionar correctamente antes de que un grupo de instancias pase al InService estado. Esta función proporciona un mejor control sobre las operaciones de escalado y ayuda a evitar situaciones en las que los grupos de instancias parcialmente aprovisionados no se puedan usar de manera eficaz para entrenar cargas de trabajo.

importante

MinCount no es una garantía permanente de capacidad mínima. Solo garantiza que el número mínimo de instancias especificado esté disponible cuando el grupo de instancias se forme por primera vezInService. Durante las operaciones normales, como el reemplazo de instancias en mal estado o las actividades de mantenimiento, MinCount pueden producirse breves interrupciones.

¿Cómo funciona MinCount

Cuando creas o actualizas un grupo de instancias con la MinCount opción habilitada, se produce el siguiente comportamiento:

  • Grupos de instancias nuevos: el grupo de instancias permanece en Creating estado hasta que al menos MinCount las instancias se aprovisionen correctamente y estén listas. Una vez que se alcanza este umbral, el grupo de instancias pasa aInService.

  • Grupos de instancias existentes: al actualizar MinCount un grupo de instancias existente, el estado cambia a Updating hasta que se cumpla el nuevo MinCount requisito.

  • Escalado continuo: si TargetCount es superior a MinCount, el sistema de escalado continuo seguirá intentando lanzar instancias adicionales hasta que TargetCount se alcance.

  • Tiempo de espera y reversión: si MinCount no se puede cumplir en un plazo de 3 horas, el sistema restablece automáticamente el grupo de instancias a su último estado válido conocido. Para obtener más información sobre el comportamiento de reversión, consulta Comportamiento de reversión automática.

Estado del grupo de instancias durante las operaciones MinCount

Los grupos de instancias MinCount configurados muestran el siguiente comportamiento de estado:

Creación

Para grupos de instancias nuevos cuando CurrentCount < MinCount. El grupo de instancias permanece en este estado hasta que se cumpla el requisito de capacidad mínima.

Actualización

Para los grupos de instancias existentes, cuando MinCount se modifica y CurrentCount < MinCount. El grupo de instancias permanece en este estado hasta que se cumpla el nuevo requisito de capacidad mínima.

InService

Cuando MinCount ≤ CurrentCount ≤ TargetCount. El grupo de instancias está listo para usarse y todas las operaciones de mutación están desbloqueadas.

Durante nuestro Creating Updating estado, se aplican las siguientes restricciones:

  • Operaciones de mutación como BatchAddClusterNodesBatchDeleteClusterNodes, o UpdateClusterSoftware están bloqueadas

  • Aún puede modificar TargetCount los valores MinCount y corregir los errores de configuración

  • Siempre se permite eliminar clústeres y grupos de instancias

Comportamiento de reversión automática

Si un grupo de instancias no puede llegar al suyo MinCount en un plazo de 3 horas, el sistema inicia automáticamente una reversión para evitar esperas indefinidas:

  • Nuevos grupos de instancias: MinCount y TargetCount se restablecen a (0, 0)

  • Grupos de instancias existentes: MinCount y TargetCount se restauran a sus valores del último InService estado

  • Selección de instancias para su terminación: si las instancias deben cancelarse durante la reversión, el sistema selecciona primero las instancias en mal estado y, a continuación, las que se aprovisionaron más recientemente.

  • Transición de estado: el grupo de instancias pasa inmediatamente al InService estado después de iniciar la reversión, lo que permite que el sistema de escalado continuo administre la capacidad de acuerdo con la configuración de la reversión

El tiempo de espera de 3 horas se restablece cada vez que se actualiza. MinCount Por ejemplo, si actualizas MinCount varias veces, el período de espera comienza desde la actualización más reciente.

MinCount eventos

El sistema emite eventos específicos para ayudarle a realizar un seguimiento de MinCount las operaciones:

  • Capacidad mínima alcanzada: se emite cuando un grupo de instancias alcanza correctamente su capacidad MinCount y pasa a InService

  • Se inicia la reversión: se emite cuando vence el tiempo de espera de 3 horas y comienza la reversión automática

Puede supervisar estos eventos mediante ListClusterEventsel seguimiento del progreso de sus operaciones. MinCount

Uso de la API

MinCount se especifica mediante el MinInstanceCount parámetro en las configuraciones de grupos de instancias:

aws sagemaker create-cluster \ --cluster-name $HP_CLUSTER_NAME \ --orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \ --vpc-config '{ "SecurityGroupIds": ["'$SECURITY_GROUP'"], "Subnets": ["'$SUBNET'"] }' \ --instance-groups '{ "InstanceGroupName": "worker-group", "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 64, "MinInstanceCount": 50, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'" }' \ --node-provisioning-mode Continuous

Consideraciones clave de MinCount uso:

  • MinInstanceCountdebe estar entre 0 y el valor InstanceCount (incluido) del grupo de instancias especificado en CreateClusternuestra UpdateClustersolicitud

  • Si MinInstanceCount se establece en 0 (predeterminado), se conserva el comportamiento de escalado continuo estándar

  • Si se establece MinInstanceCount igual a, se InstanceCount proporciona un comportamiento all-or-nothing de escalado

  • MinCount solo está disponible para clústeres con el NodeProvisioningMode valor establecido en Continuous

Grupos de instancias flexibles

Los grupos de instancias flexibles te permiten especificar varios tipos de instancias dentro de un único grupo de instancias. Esto simplifica la administración de clústeres al reducir la cantidad de grupos de instancias que necesitas crear y administrar, especialmente para las cargas de trabajo de inferencia que utilizan el escalado automático.

Con grupos de instancias flexibles, puedes: HyperPod

  • Intenta aprovisionar instancias con el primer tipo de instancia de la lista

  • Recurre a los tipos de instancias siguientes si la capacidad no está disponible

  • Termina primero las instancias del tipo de instancia con la prioridad más baja durante la reducción

nota

Los grupos de instancias flexibles solo están disponibles para los clústeres con el valor establecido en. NodeProvisioningMode Continuous InstanceRequirementsLas propiedades InstanceType y las propiedades se excluyen mutuamente: puedes especificar una u otra, pero no ambas.

Crea un clúster con un grupo de instancias flexible

InstanceRequirementsUtilízalo en lugar de InstanceType para crear un grupo de instancias flexible. El orden de los tipos de instancias de la lista determina la prioridad del aprovisionamiento.

aws sagemaker create-cluster \ --cluster-name $HP_CLUSTER_NAME \ --orchestrator 'Eks={ClusterArn='$EKS_CLUSTER_ARN'}' \ --vpc-config '{ "SecurityGroupIds": ["'$SECURITY_GROUP'"], "Subnets": ["'$SUBNET_AZ1'", "'$SUBNET_AZ2'"] }' \ --instance-groups '[{ "InstanceGroupName": "flexible-ig", "InstanceRequirements": { "InstanceTypes": ["ml.p5.48xlarge", "ml.p4d.24xlarge", "ml.g6.48xlarge"] }, "InstanceCount": 10, "LifeCycleConfig": { "SourceS3Uri": "s3://'$BUCKET_NAME'", "OnCreate": "on_create.sh" }, "ExecutionRole": "'$EXECUTION_ROLE'" }]' \ --node-provisioning-mode Continuous

Escalado específico con BatchAddClusterNodes

Si usas grupos de instancias flexibles, puedes usarlos BatchAddClusterNodespara agregar nodos con tipos de instancias y zonas de disponibilidad específicos. Esto resulta especialmente útil cuando el escalado automático de Karpenter determina el tipo de instancia y la zona de disponibilidad óptimos para tu carga de trabajo.

aws sagemaker batch-add-cluster-nodes \ --cluster-name $HP_CLUSTER_NAME \ --nodes-to-add '[ { "InstanceGroupName": "flexible-ig", "IncrementTargetCountBy": 1, "InstanceTypes": ["ml.p5.48xlarge"], "AvailabilityZones": ["us-west-2a"] } ]'

Consulta los detalles de los grupos de instancias flexibles

DescribeClusterUtilízalo para ver los tipos de instancias y el desglose por tipo de tu grupo de instancias flexible. La respuesta incluye:

  • InstanceRequirements— Los tipos de instancias actuales y deseados para el grupo de instancias

  • InstanceTypeDetails— Un per-instance-type desglose que muestra el recuento y la configuración de cada tipo de instancia del grupo

Uso de grupos de instancias flexibles con el escalado automático de Karpenter

Los grupos de instancias flexibles se integran con el escalado automático gestionado HyperPod de Karpenter. Para obtener más información sobre la configuración de Karpenter, consulte. Escalado automático en EKS SageMaker HyperPod Cuando haces referencia a un grupo de instancias flexible en una HyperPodNodeClass configuración, Karpenter automáticamente:

  • Detecta los tipos de instancias compatibles del grupo de instancias flexible

  • Selecciona el tipo de instancia y la zona de disponibilidad óptimos en función de los requisitos y los precios del pod

  • Escala el grupo de instancias flexible mediante BatchAddClusterNodes llamadas segmentadas según el tipo de instancia y la zona de disponibilidad seleccionados

nota

Cuando Karpenter gestiona el escalado, utiliza su propia lógica de selección en función de los requisitos y los precios de los módulos para determinar qué tipo de instancia aprovisionar. Esto difiere de la prioridad de orden de lista que utiliza el aprovisionamiento nativo (como CreateCluster yUpdateCluster), en la que siempre se intenta usar primero el primer tipo de instancia de la lista. HyperPod

Esto elimina la necesidad de crear grupos de instancias independientes para cada tipo de instancia y configurar Karpenter manualmente para que haga referencia a varios grupos.