En este capítulo de las series GenAI infrastructure, os mostramos una nueva capacidad que permite a los clientes orquestar clústeres de HyperPod utilizando Amazon Elastic Kubernetes Service (EKS).
Combinando el poder de Kubernetes con el entorno de HyperPod, los usuarios pueden escalar a través de aceleradores de inteligencia artificial (IA), reduciendo el tiempo de entrenamiento de los modelos en un 40%.
Orquestación con Kubernetes
HyperPod ahora permite a los clientes gestionar sus clústeres mediante una interfaz basada en Kubernetes. Esta integración facilita la conmutación entre Slurm y Amazon EKS para optimizar diferentes cargas de trabajo como entrenamiento, fine tuning, experimentación e inferencia. Con el complemento CloudWatch Observability para EKS, los clientes obtienen funcionalidades de monitorización avanzadas, pudiendo observar métricas de CPU, red, disco y otros aspectos del nodo en un solo panel de control.
Arquitectura EKS con Hyperpod
EKS en HyperPod utiliza una asignación 1 a 1 entre un clúster de EKS (que actúa como plano de control de Kubernetes) y un grupo de cómputo de HyperPod (adjunto como un grupo de nodos de trabajo). En esta arquitectura, se utilizan tres VPCs que alojan diferentes tipos de recursos:
VPC de EKS: Un VPC administrado por AWS que aloja el plano de control de EKS. Este VPC no aparece en la cuenta del cliente. Amazon EKS crea un punto de enlace (con alta disponibilidad) para el servidor de la API de Kubernetes administrado, que se utiliza para comunicarse con el clúster (mediante herramientas como
kubectl). El punto de enlace administrado utiliza un Network Load Balancer para equilibrar la carga entre los servidores de la API de Kubernetes.VPC de HyperPod: Un VPC administrado por AWS aloja el cómputo de HyperPod. Este VPC no aparece en la cuenta del cliente. Los nodos se conectan al plano de control de EKS a través de una interfaz de red elástica (ENI) entre cuentas.
VPC de usuario de SageMaker: Un VPC gestionado por el usuario que aloja recursos como Amazon FSx para Lustre, que opcionalmente se asocia con Amazon Simple Storage Service (Amazon S3) mediante una asociación de repositorio de datos, dentro de la cuenta del usuario.
Las ENIs entre cuentas también conectan las instancias de cómputo de HyperPod con otros servicios de AWS en la cuenta del usuario, como Amazon Elastic Container Registry (Amazon ECR) y Amazon CloudWatch.
El siguiente diagrama ilustra la arquitectura general del soporte de Amazon EKS en HyperPod.
Beneficios de utilizar HyperPod con EKS
Entorno Resiliente: La integración proporciona un entorno de entrenamiento más resiliente con verificaciones de health checks, recuperación automática de nodos y capacidades de reanudación de trabajos, lo que permite entrenar modelos fundacionales sin apenas interrupciones.
Observabilidad Mejorada para GPU: Con Amazon CloudWatch Container Insights, los usuarios pueden monitorizar el rendimiento de las aplicaciones y microservicios containerizados, lo que permite una observabilidad end-to-end del clúster.
Herramientas Amigables para Data Scientists: Esta integración incluye un CLI personalizado de HyperPod para la gestión de trabajos, operadores de entrenamiento distribuidos de Kubeflow y compatibilidad con SageMaker Managed MLflow para el seguimiento de experimentos.
Utilización Flexible de Recursos: Los data scientists pueden compartir capacidad de cómputo de manera eficiente entre tareas de entrenamiento e inferencia, optimizando así el uso de recursos.
Cómo empezar con HyperPod en Amazon EKS
Requisitos previos
Antes de desplegar el entorno de cómputo de HyperPod, debes asegurarte de cumplir con los siguientes requisitos:
Clúster de EKS: Puedes asociar el entorno de cómputo de HyperPod a un clúster de EKS existente que cumpla con los requisitos previos. Alternativamente, puedes desplegar un clúster EKS preconfigurado utilizando una plantilla de AWS CloudFormation.
Recursos personalizados: Para ejecutar entrenamientos distribuidos multinodo, es necesario implementar varios recursos y componentes en el clúster de EKS, como controladores de dispositivos, controladores CSI y operadores de entrenamiento. Además, debes desplegar recursos adicionales para el agente de monitorización y las verificaciones de estado (
deep health checks). LosHyperPodHelmChartssimplifican este proceso mediante Helm, uno de los gestores de paquetes más utilizados en Kubernetes. Consulta la guía para desarrolladores para más detalles sobre la instalación.
Configuración del entorno de cómputo de HyperPod
Con los recursos anteriores desplegados correctamente, ya estás listo para crear el entorno de cómputo de HyperPod. La configuración del clúster se especifica en un archivo JSON. A continuación, se muestra un ejemplo de configuración:
cat > cluster-config.json << EOL
{
"ClusterName": "ml-cluster",
"Orchestrator": {
"Eks": {
"ClusterArn": "${EKS_CLUSTER_ARN}"
}
},
"InstanceGroups": [
{
"InstanceGroupName": "worker-group-1",
"InstanceType": "ml.p5.48xlarge",
"InstanceCount": 4,
"LifeCycleConfig": {
"SourceS3Uri": "s3://${BUCKET_NAME}",
"OnCreate": "on_create.sh"
},
"ExecutionRole": "${EXECUTION_ROLE}",
"ThreadsPerCore": 1,
"OnStartDeepHealthChecks": [
"InstanceStress",
"InstanceConnectivity"
]
}
],
"VpcConfig": {
"SecurityGroupIds": [
"$SECURITY_GROUP"
],
"Subnets": [
"$SUBNET_ID"
]
},
"NodeRecovery": "Automatic"
}
EOL
La configuración destaca dos aspectos importantes:
-
"OnStartDeepHealthChecks": ["InstanceStress", "InstanceConnectivity"]– Instruye a HyperPod para que realice verificaciones de health checks cada vez que se agregan nuevas instancias de GPU o Trainium, garantizando la estabilidad del entorno. -
"NodeRecovery": "Automatic"– Habilita la funcionalidad de recuperación automática de nodos de HyperPod para mantener la disponibilidad del clúster en caso de fallos.
Creación del entorno de cómputo de HyperPod
Puedes crear el entorno de cómputo de HyperPod utilizando el siguiente comando de AWS CLI (se requiere la versión 2.17.47 o superior):
aws sagemaker create-cluster --cli-input-json file://cluster-config.json
La respuesta del comando incluye el ARN del nuevo clúster HyperPod:
{
"ClusterArn": "arn:aws:sagemaker:us-east-2:xxxxxxxxxx:cluster/wccy5z4n4m49"
}
Verificación del estado del clúster
Para verificar el estado del clúster, utiliza el siguiente comando:
aws sagemaker list-clusters --output table
Este comando muestra detalles del clúster, como el nombre del clúster, el estado actual y la hora de creación:
-----------------------------------------------------------------------------------------------------------------------
| ListClusters |
+---------------------------------------------------------------------------------------------------------------------+
|| ClusterSummaries ||
|+----------------------------------------------------------------+--------------+----------------+------------------+|
|| ClusterArn | ClusterName | ClusterStatus | CreationTime ||
|+----------------------------------------------------------------+--------------+----------------+------------------+|
|| arn:aws:sagemaker:us-east-2:111111111111:cluster/wccy5z4n4m49 | ml-cluster | Creating | 1723724079.337 ||
|+----------------------------------------------------------------+--------------+----------------+------------------+|
También puedes verificar el estado del clúster a través de la consola de SageMaker. Después de un breve período, deberías observar que el estado de todos los nodos cambia a Running.
Si lo prefieres, lo puedes hacer directamente desde la AWS CLI:
aws sagemaker describe-cluster --cluster-name mi-cluster-hyperpod
Características de Resiliencia de Nodos
Para obtener más detalles sobre las instancias, puedes utilizar el comando kubectl get nodes y examinar las etiquetas (labels) de los nodos. La etiqueta sagemaker.amazonaws.com/node-health-status muestra el estado de salud de cada nodo. Por ejemplo, los nodos con el tipo de instancia ml.m5.2xlarge están etiquetados como Schedulable, lo que indica que han pasado las verificaciones de health checks de HyperPod. Por otro lado, los nodos con el tipo de instancia ml.p5.48xlarge se etiquetan como Unschedulable, indicando que han entrado en el proceso de verificaciones de health check. A continuación, os mostramos un ejemplo:
# kubectl get nodes --show-labels=true
NAME ... LABELS
hyperpod-i-023cfe933b3b34369 ... beta.kubernetes.io/instance-type=ml.m5.2xlarge,sagemaker.amazonaws.com/node-health-status=Schedulable, ...
hyperpod-i-045961b6424401838 ... beta.kubernetes.io/instance-type=ml.p5.48xlarge,sagemaker.amazonaws.com/node-health-status=Unschedulable, ...
hyperpod-i-074b81fdb5bf52e19 ... beta.kubernetes.io/instance-type=ml.p5.48xlarge,sagemaker.amazonaws.com/node-health-status=Unschedulable, ...
hyperpod-i-0ae97710b3033cdb1 ... beta.kubernetes.io/instance-type=ml.m5.2xlarge,sagemaker.amazonaws.com/node-health-status=Schedulable, ...
Verificaciones de Health checks
Si os habéis preguntado dónde se guardan los registros de las verificaciones del estado de salud, los tenéis disponibles en el grupo de registros de CloudWatch en la ruta /aws/sagemaker/Clusters/<nombre_del_cluster>/<id_del_cluster>. Los registros se organizan en flujos con la ruta DeepHealthCheckResults/<id_del_flujo>. Cuando se detecta un problema en estas verificaciones, el registro proporciona detalles específicos, como la ID de la instancia que falló y la razón específica del fallo. Aquí tienes algunos ejemplos:
Ejemplo 1:
{
"level": "error",
"ts": "2024-08-15T21:15:22Z",
"msg": "Se ha detectado FaultyInstance. Reemplace la instancia. Región: us-east-2, Tipo de instancia: p5.48xlarge. ERROR: El ancho de banda es menor que el umbral: Umbral mínimo esperado: 80, Salida de prueba NCCL Bw: 30"
}
Ejemplo 2:
{
"level": "error",
"ts": "2024-08-15T21:15:22Z",
"msg": "Se ha detectado UnknownError. Reemplace la instancia. Región: us-east-2, Tipo de instancia: p5.48xlarge. ERROR: Error detectado en la prueba dcgm"
}
Progreso de las Verificaciones de Health Checks
Podéis verificar el progreso con la etiqueta sagemaker.amazonaws.com/deep-health-check en cada nodo. Los valores posibles son:
-
InProgress– La verificación está en curso. -
Passed– La verificación ha sido superada. -
Failed– La verificación ha fallado.
Si un nodo falla durante las verificaciones, será reemplazado automáticamente. En caso contrario, se marcará con la etiqueta:
sagemaker.amazonaws.com/node-health-status: Schedulable
Puede que quieras reemplazar manualmente un nodo específico en tu clúster. Si es así, puedes hacerlo modificando manualmente la etiqueta correspondiente.
Para obtener la lista completa de etiquetas relacionadas con la resiliencia en Kubernetes, te recomendamos que consultes la documentación de AWS.
Monitorización de Health Checks continua
Incluso después de las verificaciones iniciales, HyperPod ejecuta verificaciones de manera periódica. Para ver los eventos de salud detectados por el agente de monitorización de HyperPod, debéis revisar el flujo de registros en CloudWatch:
-
Nombre de grupo de registros de ejemplo:
/aws/sagemaker/Clusters/<nombre_del_cluster>/<id_del_cluster> -
Nombre de flujo de registros de ejemplo:
SagemakerHealthMonitoringAgent/<nombre_de_tu_grupo_de_nodos>/<id_instancia>
El flujo de registros del agente de monitorización de salud de SageMaker contiene solo eventos de detección relacionados con la salud de cada nodo. Por ejemplo:
Ejemplo 1:
{
"level": "info",
"ts": "2024-09-06T03:15:11Z",
"msg": "NPD detectó un problema ",
"condition type: ": "KernelDeadlock",
"with condition details ": {
"type": "KernelDeadlock",
"status": "False",
"transition": "2024-09-06T03:15:11.539932213Z",
"reason": "KernelHasNoDeadlock",
"message": "El kernel no tiene interbloqueo"
},
"HealthMonitoringAgentDetectionEvent": "HealthEvent"
}
Ejemplo 2:
{
"level": "info",
"ts": "2024-09-06T03:15:11Z",
"msg": "NPD detectó un problema ",
"condition type: ": "NvidiaErrorTerminate",
"with condition details ": {
"type": "NvidiaErrorTerminate",
"status": "False",
"transition": "2024-09-06T03:15:11.539932283Z",
"reason": "NvidiaNoErrorRequiredTerminate",
"message": "Nvidia: no se requiere terminar el proceso"
},
"HealthMonitoringAgentDetectionEvent": "HealthEvent"
}
Cuando el agente de monitorización o las verificaciones detectan un problema en un nodo, este se etiqueta como sagemaker.amazonaws.com/node-health-status=UnschedulablePendingReplace para evitar que se programen nuevos pods en él, y luego se reemplaza o reinicia según sea necesario.
Monitorización de la Salud de los Nodos a Través de CloudWatch Container Insights
Puedes monitorizar el estado de salud de los nodos mediante CloudWatch Container Insights, que ahora ofrece una observabilidad mejorada para Amazon EKS. Container Insights permite recopilar, agregar y resumir métricas y registros de aplicaciones y microservicios containerizados, proporcionando una visibilidad detallada del rendimiento, la salud y el estado de las métricas a nivel de CPU, GPU, Trainium, EFA y sistema de archivos hasta el nivel del contenedor. Para ver la lista completa de métricas rastreadas, consulta la sección de métricas de Amazon EKS y Kubernetes en Container Insights.
La integración de Container Insights con HyperPod también permite verificar el estado de salud individual de los nodos y el número total de nodos programables y no programables, como se muestra en las siguientes capturas de pantalla.
Puedes encontrar la guía de configuración de Container Insights en el taller de Amazon SageMaker HyperPod con soporte para Amazon EKS.
Resiliencia de Trabajos de Entrenamiento con Funcionalidad de Reanudación Automática
Además de las características de resiliencia de la infraestructura, HyperPod incluye la capacidad de reanudación automática utilizando el Kubeflow Training Operator para PyTorch, lo que permite mantener la continuidad de los entrenamientos en caso de interrupciones o fallos. La funcionalidad intenta continuar el trabajo cuando se producen errores transitorios, mientras que la funcionalidad de recuperación automática en HyperPod se encarga de resolver fallos físicos del nodo (reiniciando o reemplazando el nodo según sea necesario) para minimizar el tiempo de inactividad en el entrenamiento.
En esta sección, os mostraremos la capacidad de reanudación automática utilizando un ejemplo de PyTorch con FSDP (Fully Sharded Data Parallel) del repositorio awsome-distributed-training.
Habilitación de la Reanudación Automática
Para habilitar la reanudación automática de trabajos, debes crear un PyTorchJob con el manifiesto fsdp.yaml, que incluye las siguientes anotaciones y nodeSelector:
apiVersion: "kubeflow.org/v1"
kind: PyTorchJob
metadata:
name: fsdpjob
namespace: kubeflow
annotations:
sagemaker.amazonaws.com/enable-job-auto-resume: "true"
sagemaker.amazonaws.com/job-max-retry-count: "2"
spec:
pytorchReplicaSpecs:
Worker:
replicas: 10
restartPolicy: OnFailure
template:
spec:
nodeSelector:
sagemaker.amazonaws.com/node-health-status: Schedulable
Las anotaciones sagemaker.amazonaws.com/enable-job-auto-resume: "true" y sagemaker.amazonaws.com/job-max-retry-count: "2" indican que HyperPod intentará reanudar los trabajos interrumpidos hasta dos veces, y los reasignará a nodos saludables.
El selector de nodos (nodeSelector) utiliza la etiqueta sagemaker.amazonaws.com/node-health-status: Schedulable para asegurar que los trabajos se reasignen únicamente a nodos que hayan pasado las verificaciones de salud básicas y estén disponibles para ejecutar cargas de trabajo.
Envío del Trabajo de Entrenamiento
Envía el trabajo de PyTorch utilizando el siguiente comando de kubectl:
kubectl apply -f fsdp.yaml
Con la funcionalidad de reanudación automática habilitada, si un trabajo falla debido a un fallo de hardware o cualquier problema transitorio durante el entrenamiento, HyperPod inicia el flujo de trabajo de reemplazo de nodos y reinicia el trabajo una vez que los nodos defectuosos se han reemplazado. Puedes verificar el estado del trabajo de reanudación automática describiendo el PyTorchJob con el siguiente comando:
kubectl describe pytorchjob -n kubeflow <nombre_del_trabajo>
Ejemplo de Reanudación Automática en Caso de Fallo de Hardware
Cuando ocurre un fallo de hardware, el trabajo de entrenamiento de Kubeflow se reinicia con el siguiente flujo de eventos:
Hora de inicio: 2024-07-11T05:53:10Z
Capacidad de reanudación automática de trabajo habilitada: 27
Eventos:
Normal: SuccessfulCreateService – Se ha creado el servicio: pt-job-1-worker-0
Normal: SuccessfulCreateService – Se ha creado el servicio: pt-job-1-worker-1
Normal: SuccessfulCreateService – Se ha creado el servicio: pt-job-1-master-0
Warning: PyTorchJobRestarting – El trabajo pt-job-1 se está reiniciando porque 1 réplica del maestro ha fallado.
Normal: SuccessfulCreatePod – Se ha creado el pod: pt-job-1-worker-0
Normal: SuccessfulCreatePod – Se ha creado el pod: pt-job-1-worker-1
Normal: SuccessfulCreatePod – Se ha creado el pod: pt-job-1-master-0
Warning: PyTorchJobRestarting – El trabajo pt-job-1 se está reiniciando porque 1 réplica de un trabajador ha fallado.
Envío de Trabajos Usando el CLI de HyperPod
Cuando envías un trabajo de entrenamiento utilizando la CLI de HyperPod, también puedes solicitar la reanudación automática de la siguiente manera:
hyperpod start-job \
--config-file ./config.yaml \
--auto-resume true \
--max-retry 2
Consulta el archivo config.yaml para la configuración completa. Para ver otras opciones del CLI, consulta la documentación en el repositorio de GitHub correspondiente.
Eliminación del Entorno
Para eliminar tu entorno de HyperPod, puedes usar la consola de SageMaker o el siguiente comando de la AWS CLI:
aws sagemaker delete-cluster --cluster-name <nombre_del_cluster>
La eliminación del clúster puede tardar unos minutos. Puedes confirmar la eliminación verificando que no queden clústeres en la consola de SageMaker.
Conclusiones
Si queréis aprovechar al máximo estas nuevas funcionalidades, os recomendamos explorar las opciones avanzadas de HyperPod y su integración con EKS. Con estas herramientas, puedes optimizar la resiliencia y continuidad de tus trabajos de entrenamiento a gran escala en Kubernetes.
Autores: Este artículo fue desarrollado en colaboración con Elizabeth Fuentes, Manoj Ravi, Adhesh Garg, Tomonori Shimomura, y Anoop Saha. ¡Gracias a todos por su contribución en este blog!
Top comments (0)