Amazon SageMaker HyperPod brinda a los equipos de aprendizaje automático (ML) acceso a grandes conjuntos de procesamiento acelerado para entrenar y ajustar los modelos. Cuando varios equipos comparten un clúster, la configuración técnica suele ser sencilla. La parte más difícil es la gobernanza. Debes decidir qué equipos pueden usar el clúster, cuánta capacidad tiene cada equipo, qué ocurre cuando la carga de trabajo de un equipo compite con la de otro y quién es responsable cuando el uso se desvía de la política. Amazon SageMaker Unified Studio añade otra consideración: puede conectar un clúster de HyperPod de SageMaker a un proyecto para que los miembros del equipo puedan lanzar cargas de trabajo desde el espacio de trabajo del proyecto. Esta comodidad es valiosa, pero cuando varios equipos comparten la visibilidad del mismo clúster, los controles que determinan quién puede hacer cada cosa se vuelven aún más importantes. En este artículo, mostramos cómo administrar SageMaker HyperPod a través de SageMaker Unified Studio y, al mismo tiempo, conservar los controles de gobierno subyacentes. Cubrimos los cuatro niveles de control: organización, proyecto, clúster y carga de trabajo. También explicamos cómo diseñar políticas de identidad, capacidad y observabilidad en todos ellos. Al final, dispondrá de un modelo repetible para ofrecer la computación HyperPod aprobada de SageMaker a los equipos de aprendizaje automático en el contexto de sus proyectos y, al mismo tiempo, mantener las operaciones del clúster en

Amazon SageMaker HyperPod es una capacidad de Amazon SageMaker AI. Amazon SageMaker Unified Studio es el entorno de desarrollo de datos e inteligencia artificial en el que los equipos crean con sus datos y herramientas. Con SageMaker Unified Studio, puede conectar un proyecto a un clúster de SageMaker HyperPod existente. A continuación, los miembros pueden iniciar cargas de trabajo de aprendizaje automático, revisar la información del clúster y de las tareas y abrir un flujo de trabajo de JupyterLab. Continúa administrando los clústeres a través de las API e interfaces de inteligencia artificial de Amazon SageMaker

Esta separación proporciona a los equipos de infraestructura un modelo operativo útil. Puede administrar la infraestructura de clústeres mediante procesos de operaciones en la nube establecidos. Al mismo tiempo, puedes presentar la computación aprobada a los equipos de aprendizaje automático en el contexto de su proyecto. En esta publicación, describimos cómo puede diseñar los límites de la infraestructura, controlar el acceso, asignar capacidad compartida y utilizar SageMaker HyperPod de forma coherente a través de SageMaker

Comprenda los límites administrativos

Un entorno bien gobernado separa la administración organizacional, el acceso a los proyectos y las operaciones de los clústeres. Cada capa responde a una pregunta diferente y usa un control diferente. En la siguiente tabla se resume cada límite, sus controles principales y su finalidad administrativa

Trate estos controles como capas. Una conexión con SageMaker HyperPod agrega un clúster aprobado a un proyecto. No reemplaza los controles de AWS Identity and Access Management (IAM), Amazon Elastic Kubernetes Service (Amazon EKS) o Slurm del clúster. Revise en conjunto el rol del proyecto, el rol de acceso a la conexión, las entradas de acceso a EKS y los controles de RBAC o Slurm, la identidad de la carga de trabajo, los datos y las políticas clave del AWS Key Management Service (AWS KMS), la política de red, las restricciones de visualización de tareas y la política del programador. Haga que el clúster esté disponible solo

Estos controles forman cuatro capas, como se muestra en la siguiente figura.

Figura 1: Los cuatro niveles de control: organización, proyecto, clúster y carga de trabajo. Cada capa responde a una pregunta diferente y usa un control diferente, por lo que debes revisar cada una según sus propios límites.

proyectos de SageMaker Unified Studio son límites de colaboración. No son límites de seguridad estrictos durante el tiempo de ejecución. Mantenga el clúster de HyperPod, el planificador y la escasa capacidad del acelerador de SageMaker en una sola cuenta de capacidad designada. Los usuarios y conjuntos de datos aprobados pueden permanecer en la misma cuenta o en cuentas de consumidor y de datos independientes. AWS documenta la compatibilidad con varias cuentas para la gestión de tareas de SageMaker HyperPod en los clústeres de Amazon EKS. Si bien las reservas de capacidad bajo demanda se pueden compartir entre cuentas, centralice la propiedad de los clústeres de HyperPod de SageMaker y la administración de la capacidad en la cuenta de capacidad. Utilice el acceso multicuenta aprobado en lugar de convertir cada cuenta de consumidor en un administrador de capacidad

• Para Amazon EKS, utilice un espacio de nombres por inquilino junto con RBAC, cuentas de servicio por inquilino y funciones de identidad de EKS Pod, políticas de red de denegación predeterminada y permisos de AWS KMS y de almacenamiento específicos para el inquilino. En el caso de Slurm, utilice la contabilidad de Slurm con cuentas y asociaciones jerárquicas, políticas de calidad de servicio (QoS), políticas de prioridad y reparto equitativo y particiones. Usa también los permisos de identidad y archivos del sistema operativo, los controles de red y
las rutas de datos específicas de los inquilinos.
• Utilice las políticas de recursos y funciones de IAM, en lugar de limitarse a la pertenencia a un proyecto, para controlar el acceso a los buckets, las claves de AWS KMS, los secretos, los registros de contenedores y otros servicios de datos de Amazon Simple Storage Service (Amazon S3). Utilice políticas de proyectos y unidades de dominio para la colaboración
y la delegación. En
• el caso de los clústeres de Amazon EKS, utilice la gestión de tareas de HyperPod de SageMaker, incluidas las cuotas, las clases prioritarias, los préstamos y préstamos y la preferencia, para compartir equitativamente el grupo de aceleradores centrales. En el caso de los clústeres de Slurm, utilice particiones nativas, controles de calidad de servicio (QoS), prioridad, distribución equitativa y preferencia. Slurm no ofrece el mismo modelo de préstamo y préstamo. Estos controles de programación determinan cuándo se procesa una carga de trabajo autorizada. No otorgan acceso al espacio de nombres ni a los datos
.

Para lograr un mayor aislamiento dentro de un clúster, utilice nodos o grupos de nodos dedicados y controles de admisión cuando corresponda. Utilice un clúster o una cuenta independientes cuando los requisitos legales, reglamentarios o de seguridad lo exijanAislamiento de la infraestructura roja. El acceso de los consumidores entre cuentas puede preservar la propiedad a nivel de cuenta sin duplicar el clúster central de HyperPod de SageMaker. Dentro de la cuenta de capacidad, utilice los perfiles de los proyectos y las unidades de dominio con políticas de autorización de proyectos para delegar la creación y la propiedad de los

La siguiente figura muestra la capacidad centralizada con controles de carga de trabajo, identidad, datos, red y visibilidad específicos del inquilino.

Figura 2: Capacidad centralizada de SageMaker HyperPod. El clúster y el planificador permanecen en una sola cuenta de capacidad. Cada inquilino recibe controles de carga de trabajo, identidad, datos, red y visibilidad de las tareas. Los requisitos de aislamiento estricto utilizan

una infraestructura dedicada.

La figura 3 muestra cómo se conectan esos límites cuando SageMaker Unified Studio expone a los miembros del proyecto los cálculos aprobados de SageMaker HyperPod.

Figura 3: Modelo de administración recomendado de SageMaker HyperPod. SageMaker Unified Studio rige el contexto de colaboración, mientras que la identidad del clúster, la autorización de la carga de trabajo, la política del programador y los controles operativos permanecen

separados.

Utilice SageMaker Unified Studio cuando la pertenencia a un proyecto, el acceso a los datos, las herramientas de desarrollo y la computación necesiten un contexto común. Para los cambios en los clústeres y la automatización repetible, sigue usando las API de IA de SageMaker, la infraestructura como código y las herramientas de orquestación. Para ver las implementaciones e integraciones de referencia, consulte el sitio sobre IA en SageMaker HyperPod

Tome decisiones sobre la infraestructura antes de conectar un clúster

Antes de aprobar una conexión, documente la cuenta de capacidad, cualquier cuenta de consumidor o de datos, la región de AWS, las rutas de red, las identidades, los propietarios, los límites de la carga de trabajo y los requisitos de aislamiento. Si necesita ayuda para crear un clúster, consulte la documentación de Amazon SageMaker HyperPod o el sitio sobre la IA en SageMaker

Identidades administrativas y de carga de trabajo independientes. Mantenga la distinción de SageMaker HyperPod entre los administradores de clústeres y los usuarios científicos de datos al crear funciones de proyecto y de acceso. Un rol orientado a un proyecto no debe recibir permisos del ciclo de vida del clúster únicamente porque sus usuarios ejecuten cargas de trabajo. Consulte AWS Identity and Access Management para SageMaker HyperPod para

Trate las redes como un control de extremo a extremo. Restrinja el acceso de los puntos finales de la API de Kubernetes de Amazon EKS a las rutas de red administrativas aprobadas, controle la entrada y la salida de los pods y compruebe que el proyecto, la función de conexión, la función de carga de trabajo y la red de clústeres solo admitan las rutas de datos previstas.

Por ejemplo, configure el acceso privado al punto final de la API de Amazon EKS y permítalo solo desde subredes de administración o carga de trabajo aprobadas. Aplique una política de red de Kubernetes de denegación predeterminada y permita explícitamente las rutas de salida y de servicio a servicio requeridas. Utilice puntos de enlace de nube privada virtual (VPC) para servicios como Amazon S3, Amazon Elastic Container Registry (Amazon ECR) y Amazon CloudWatch, cuando proceda, y asigne a cada inquilino una función

Cree una conexiónbajo contrato. Un contrato de conexión es un registro de gobierno gestionado por el cliente, como una página wiki, un ticket, un registro de catálogo de servicios o un archivo al que se hace un seguimiento en un repositorio de infraestructura como código. No es una función de la plataforma. Registre la siguiente información para cada conexión de proyecto a clúster aprobada

• Propietario de la empresa, propietario de las operaciones y propietario de los costos.
• Unidad de dominio y proyecto de SageMaker Unified Studio.
• Cuenta de clúster, región, nombre y orquestador.
• El rol del proyecto y el rol de acceso del nombre de recurso de Amazon (ARN) utilizados por la conexión.
• Tipos de carga de trabajo y clasificación de datos aprobados.
• Espacios de nombres de EKS o ámbito de acceso a Slurm.
• Propietario de la política de programación y de la excepción.
• Expectativas de monitoreo, soporte y desmantelamiento.

Este contrato otorga a los revisores un registro para evaluar y aprobar la ruta de acceso completa.

Controle la identidad y la visibilidad de las tareas

Controle tanto las acciones como la visibilidad. La configuración incorrecta de los nombres de las tareas, los espacios de nombres, las solicitudes de recursos y los patrones de uso puede revelar información sobre el trabajo de otro equipo

Utilice grupos en lugar de subvenciones individuales para la pertenencia a un proyecto y el acceso a los clústeres siempre que sea posible. Revisa cada rol según sus propios límites en lugar de crear un rol amplio que abarque el dominio, el proyecto, el clúster y la política de carga

El siguiente flujo de trabajo muestra cómo separar lo que un usuario puede ver de lo que puede hacer.

Figura 4: Gobernar la identidad y la visibilidad de las tareas. Asigne el acceso a través de grupos, limite cada rol hasta sus límites, restrinja la visibilidad de las tareas y separe la capacidad de ver el trabajo de la capacidad de actuar en consecuencia.

Revisa la visibilidad predeterminada de las tareas antes de incorporar a los usuarios. La documentación de SageMaker HyperPod en SageMaker AI Studio explica que los usuarios de SageMaker AI Studio pueden ver todas las tareas del clúster de Amazon EKS de forma predeterminada. En el caso de los clústeres de Slurm, todos los usuarios de SageMaker AI Studio pueden ver las tareas disponibles, administrarlas e interactuar con ellas. Configure las restricciones de visualización de tareas antes de incorporar a varios equipos: consulte Restringir la vista de tareas en Studio para clústeres de EKS para Amazon EKS y Restringir la vista de tareas en Studio para clústeres de Slurm para Slurm. La pertenencia a un proyecto no es un límite de seguridad a nivel de clúster

el caso de los clústeres de Amazon EKS, asigne a cada equipo un espacio de nombres y permisos de RBAC aprobados, y asigne cada cuenta de servicio de carga de trabajo a una función de IAM específica del inquilino. Para acceder a los datos entre cuentas, asocie la cuenta de servicio a una función de EKS Pod Identity en la cuenta de capacidad (clúster) y defina una función de IAM objetivo en la asociación (TargetRolearn). A continuación, EKS Pod Identity asume automáticamente la función multicuenta, por lo que el código de la aplicación no necesita llamar a AssumeRole. El rol objetivo reside en la cuenta de consumidor o de datos. Mantenga la visibilidad de solo lectura separada de los permisos para crear, actualizar o eliminar cargas de trabajo. Para los clústeres de Slurm, defina controles equivalentes de visibilidad de usuario, cuenta, partición, sistema de archivos y tareas

Por ejemplo, la siguiente función de RBAC de Kubernetes otorga a un equipo acceso de solo lectura a los trabajos solo en su propio espacio de nombres. Se requiere un rol independiente para crear o eliminar cargas de trabajo, lo que separa la palabra «ver» de la palabra «actuar»

Versión de API: rbac.authorization.k8s.io/v1
tipo: Rol
metadatos:
 espacio de nombres: team-research
 nombre: research-job-viewer
reglas:
 - APIGroups: ["lote"]
 recursos: ["trabajos"]
 verbos: ["obtener», «listar», «ver"]
 - Grupos de API: ["kubeflow.org"]
 recursos: ["pytorchjobs"]
 verbos: ["obtener», «listar», «ver"

Traduzca las prioridades empresariales en políticas de programación

En el caso de los clústeres de Amazon EKS, aplique la gobernanza de tareas solo después de haber establecido los controles de acceso a la identidad y la carga de trabajo.

La siguiente figura separa las dos decisiones que esto implica.

Figura 5: Mantenga separadas las políticas de autorización y programación. Las ACL RBAC o Slurm de EKS determinan si un usuario puede enviar una carga de trabajo. El gobierno de tareas de SageMaker HyperPod para Amazon EKS o los controles de programación nativos de Slurm

determinan cuándo recibe el procesamiento.

Documente la capacidad garantizada y compartida, las clases prioritarias y si un equipo puede usar la asignación inactiva de otro equipo. Asigna un propietario a cada excepción. La gestión de tareas también se aplica a los espacios HyperPod de SageMaker (entornos independientes de JupyterLab o de edición de código que se ejecutan directamente en el clúster), por lo que debe incluir estas cargas de trabajo de desarrollo interactivo

Por ejemplo, en un clúster de Amazon EKS, puede conceder al equipo de formación en producción una asignación garantizada del 60 por ciento con una clase de alta prioridad, dejar que el equipo de investigación tome prestada la capacidad inactiva con una prioridad inferior y permitir que se le dé prioridad a esa capacidad prestada cuando el equipo de producción envíe el trabajo. Asigne un propietario para que apruebe cualquier excepción a esta política, de modo que las solicitudes únicas no se conviertan en la norma de forma discreta

Mantén separadas la política de autorización y la de programación. Las ACL RBAC o Slurm de EKS determinan si un usuario puede enviar una carga de trabajo. El gobierno de tareas de SageMaker HyperPod para Amazon EKS, o los controles de programación nativos de Slurm, determinan cuándo se procesa esa carga de trabajo autorizada. El uso de la cuota del planificador como control de acceso o los controles de autorización como política de programación produce un comportamiento poco claro y dificulta

En el post Prácticas recomendadas para la gobernanza de las tareas de Amazon SageMaker HyperPod, se explican las ponderaciones equitativas, las cuotas, los préstamos y préstamos, las clases prioritarias y los escenarios de asignación comunes. En el caso de los clústeres de Amazon EKS, utilice esos patrones al definir la política de asignación. Para los clústeres de Slurm, utilice el esquema nativosegún los controles descritos anteriormente.

Utilice la observabilidad como un circuito de retroalimentación sobre la gobernanza

Con SageMaker Unified Studio, puede ver los detalles del clúster de SageMaker HyperPod para ver las tareas, las métricas, los ajustes y los metadatos. En el caso de los clústeres de Amazon EKS, las métricas de gobierno de las tareas incluyen las vistas de hardware, equipos y tareas. Estas vistas le ayudan a comparar la intención de la política con el consumo real.

Trate la observabilidad como un bucle, como se muestra en la siguiente figura.

Figura 6: La observabilidad como ciclo de retroalimentación de la gobernanza. Supervise las señales, compárelas con la intención de la política, decida una respuesta y ajuste la política y las asignaciones, asignando un propietario y una respuesta a cada

señal.

Defina un propietario y una respuesta para cada señal que supervise. Los siguientes ejemplos convierten los datos del panel de control en decisiones administrativas.

Para los clústeres de Amazon EKS, la tabla de tareas muestra las tareas de Kubeflow (PyTorch, MPI y TensorFlow) y las tareas de PyTorch se muestran de forma predeterminada. Es posible que las cargas de trabajo enviadas mediante otros mecanismos no aparezcan allí. En el caso de los clústeres de Slurm, las tablas de tareas muestran los trabajos en la cola del programador actual, mientras que la contabilidad de Slurm proporciona datos históricos de los trabajos mediante herramientas como sacct. Defina dónde puede obtener los datos históricos de las tareas

El complemento Amazon CloudWatch Observability EKS es necesario para las vistas de métricas documentadas. El complemento tiene sus propios requisitos previos: la versión 2.4.0 o posterior y la política de IAM de CloudwatchAgentServerPolicy asociada a la función de nodo de trabajo de Kubernetes. Las métricas de Kueue, que proporcionan las vistas de gobierno de las tareas, pueden generar cargos por las métricas de CloudWatch una vez finalizada la capa gratuita. Consulte la documentación del panel de control de SageMaker HyperPod para conocer las consideraciones actuales sobre la configuración y los precios

Revise las conexiones a lo largo de su ciclo de vida

Establezca un cronograma de revisión para cada conexión. Defina también revisiones basadas en eventos para determinar los cambios en la propiedad del proyecto, las funciones de acceso, la cuenta o la región, la capacidad del clúster, la versión del orquestador, la clasificación de los datos o la cobertura de supervisión. Usa el contrato de conexión para registrar cada decisión

La siguiente figura muestra las etapas del ciclo de vida.

Figura 7: El ciclo de vida de la conexión. Apruebe una conexión con un contrato de conexión registrado, utilícela y supervise, revísela según un cronograma y según los eventos definidos y, a continuación, renuévela o revoque

.

Automatice el inventario y la recopilación de pruebas para reducir el trabajo manual, pero mantenga la aprobación de los administradores responsables. Revoca las conexiones que ya no tengan un propósito empresarial o un propietario responsable

Conclusión

Con Amazon SageMaker Unified Studio, los equipos de aprendizaje automático pueden seguir un camino centrado en el proyecto para obtener el procesamiento aprobado de SageMaker HyperPod, mientras que los equipos de infraestructura conservan el control del clúster centralizado. Comience con un clúster que no sea de producción y un proyecto de prueba. Configure la identidad de la carga de trabajo, el espacio de nombres o el ámbito de Slurm, los permisos de datos, la política de red, las restricciones de visualización de tareas y el gobierno de las tareas para Amazon EKS o los controles de programación nativos para Slurm antes de añadir miembros. Instale el complemento EKS de Amazon CloudWatch Observability para que las vistas de métricas se rellenen y registre la aprobación completa en el contrato de conexión. Utilice funciones multicuenta para las cuentas de consumidores aprobadas y utilice una infraestructura dedicada cuando sea necesario aislarlas por completo. Siga el procedimiento de conexión del HyperPod de SageMaker para

Acerca de los autores