Las GPU son un recurso precioso; Ambos son cortos en suministro y mucho más costosos que las CPU tradicionales. También son altamente adaptables a muchos casos de uso diferentes. Las organizaciones que construyen o adoptan la IA generativa usan GPU para ejecutar simulaciones, ejecutar inferencia (tanto para uso interno como externo), construyen cargas de trabajo de agente y ejecutan experimentos de científicos de datos. Las cargas de trabajo van desde experimentos efímeros de una sola IS-GPU dirigida por científicos hasta largas ejecuciones de pre-entrenamiento continuo de nodos. Muchas organizaciones necesitan compartir una infraestructura de computación de GPU de alto rendimiento centralizada en diferentes equipos, unidades de negocios o cuentas dentro de su organización. Con esta infraestructura, pueden maximizar la utilización de costosos recursos informáticos acelerados como las GPU, en lugar de tener infraestructura aislada que podría ser subutilizada. Las organizaciones también usan múltiples cuentas de AWS para sus usuarios. Las empresas más grandes pueden querer separar diferentes unidades de negocios, equipos o entornos (producción, puesta en escena, desarrollo) en diferentes cuentas de AWS. Esto proporciona un control más granular y aislamiento entre estas diferentes partes de la organización. También hace que sea sencillo rastrear y asignar costos en la nube a los equipos o unidades de negocios apropiadas para una mejor supervisión financiera.
Las razones y la configuración específicos pueden variar según el tamaño, la estructura y los requisitos de la empresa. Pero en general, una estrategia de múltiples cuenta proporciona una mayor flexibilidad, seguridad y gestión de implementaciones de nubes a gran escala. En esta publicación, discutimos cómo una empresa con múltiples cuentas puede acceder a un Amazon Sagemaker Hyperpod Cluster para ejecutar sus cargas de trabajo heterogéneas. Utilizamos la gobernanza de tareas de Sagemaker HyperPod para habilitar esta función.
Descripción general de la solución
Sagemaker Hyperpod Gobierno de tareas Rimensione la asignación de recursos y proporciona a los administradores de clúster la capacidad de configurar políticas para maximizar la utilización de cálculos en un clúster. La gobernanza de tareas se puede utilizar para crear equipos distintos con su propio espacio de nombres único, cuotas de cálculo y límites de préstamo. En una configuración de cuenta múltiple, puede restringir qué cuentas tienen acceso a la cuota de cómputo de qué equipo usando control de acceso basado en roles.
En esta publicación, describimos la configuración requerida para configurar el acceso múltiple para los grupos de hiperpod de Sagemaker orquestados por Servicio de Kubernetes de Amazon Elastic (Amazon EKS) y cómo usar el gobierno de tareas de Sagemaker HyperPod para asignar el cómputo acelerado a múltiples equipos en diferentes cuentas.
El siguiente diagrama ilustra la arquitectura de la solución.
En esta arquitectura, una organización está dividiendo recursos en algunas cuentas. Cuenta A alberga el clúster Sagemaker HyperPod. La cuenta B es donde residen los científicos de datos. La cuenta C es donde se preparan y almacenan los datos para el uso de la capacitación. En las siguientes secciones, demostramos cómo configurar el acceso a múltiples cuenta para que los científicos de datos en la cuenta B puedan capacitar a un modelo en el clúster de Sagemaker HyperPod y EKS de la cuenta A, utilizando los datos preprocesados almacenados en la cuenta C. Desglosamos esta configuración en dos secciones: acceso a los científicos de datos cruzados y el acceso cruzado para datos preparados.
Acceso de cuenta cruzada para científicos de datos
Cuando tu crear una asignación de cómputo Con el gobierno de tareas de Sagemaker HyperPod, su clúster EKS crea un espacio de nombres único de Kubernetes por equipo. Para este tutorial, creamos un Gestión de identidad y acceso de AWS (Iam) papel por equipo, llamado Roles de acceso a clústerque luego se encuentran acceso solo al espacio de nombres generado por la gobernanza de tareas del equipo en el clúster EKS compartido. Control de acceso basado en roles es cómo nos aseguramos de que los miembros de la ciencia de datos del Equipo A no puedan enviar tareas en nombre del equipo B.
Para acceder al clúster EKS de la cuenta A como usuario en la cuenta B, deberá asumir un papel de acceso al clúster en la cuenta A. El rol de acceso al clúster solo tendrá los permisos necesarios para que los científicos de datos accedan al clúster EKS. Para obtener un ejemplo de roles IAM para científicos de datos que usan Sagemaker HyperPod, ver Usuarios de IAM para científicos.
A continuación, deberá asumir el papel de acceso al clúster desde un papel en la cuenta B. El rol de acceso al clúster en la cuenta A debe tener una política de fideicomiso para el papel de los científicos de datos en la cuenta B. El rol de científico de datos es el papel en la cuenta B que se utilizará para asumir el papel de acceso al clúster en la cuenta A. El siguiente código es un ejemplo del estado de la política para el científico de datos que puede asumir el rol de acceso al clúster en la cuenta A:
El siguiente código es un ejemplo de la política de confianza para el rol de acceso al clúster para que permita al rol de científico de datos asumirlo:
El último paso es crear una entrada de acceso para el papel de acceso al clúster del equipo en el clúster EKS. Esta entrada de acceso también debe tener una política de acceso, como Ekseditpolicyque se alcanza al espacio de nombres del equipo. Esto asegura que el equipo A los usuarios de la cuenta B no pueda iniciar tareas fuera de su espacio de nombres asignado. También puede configurar opcionalmente el control de acceso basado en roles personalizado; ver Configuración de Kubernetes Control de acceso basado en roles Para más información.
Para los usuarios en la cuenta B, puede repetir la misma configuración para cada equipo. Debe crear un papel de acceso de clúster único para cada equipo para alinear el papel de acceso para el equipo con su espacio de nombres asociado. Para resumir, usamos dos roles IAM diferentes:
- Rol de científico de datos – El papel en la cuenta B utilizado para asumir el papel de acceso al clúster en la cuenta A. Este papel solo necesita poder asumir el rol de acceso al clúster.
- Rol de acceso a clúster – El papel en la cuenta A utilizado para dar acceso al clúster EKS. Para un ejemplo, ver IAM papel para Sagemaker Hyperpod.
Acceso de cuenta cruzada a datos preparados
En esta sección, demostramos cómo configurar Identidad de la vaina de EKS y Puntos de acceso S3 De modo que las cápsulas que ejecutan tareas de capacitación en el clúster EKS de la cuenta A tienen acceso a los datos almacenados en la cuenta C. EKS POD Identity le permiten asignar un rol de IAM a una cuenta de servicio en un espacio de nombres. Si un POD usa la cuenta de servicio que tiene esta asociación, Amazon EKS establecerá las variables de entorno en los contenedores de la cápsula.
Los puntos de acceso S3 se denominan puntos finales de red que simplifican el acceso de datos para conjuntos de datos compartidos en cubos S3. Actúan como una forma de otorgar un control de acceso de grano fino a usuarios o aplicaciones específicas que acceden a un conjunto de datos compartido dentro de un cubo S3, sin requerir que esos usuarios o aplicaciones tengan acceso completo a todo el cubo. Los permisos al punto de acceso se otorgan a través de políticas de punto de acceso S3. Cada punto de acceso S3 está configurado con una política de acceso específica para un caso de uso o aplicación. Dado que el clúster HyperPod en esta publicación de blog puede ser utilizado por varios equipos, cada equipo podría tener su propio punto de acceso S3 y política de puntos de acceso.
Antes de seguir estos pasos, asegúrese de tener el Complemento de identidad eks pods instalado en tu clúster EKS.
- En la cuenta A, cree un papel IAM que contenga permisos S3 (como
s3:ListBucketys3:GetObjectal recurso del punto de acceso) y tiene una relación de confianza con la identidad de POD; Este será su rol de acceso a datos. A continuación se muestra un ejemplo de una política de confianza.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
- En la cuenta C, cree un punto de acceso S3 por siguiendo los pasos aquí.
- A continuación, configure su punto de acceso S3 para permitir el acceso al rol creado en el paso 1. Esta es una política de punto de acceso de ejemplo que le da a la cuenta un permiso para acceder a los puntos en la cuenta C.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<Account-A-ID>:role/<Data-Access-Role-Name>"
},
"Action": [
"s3:ListBucket",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:<Region>:<Account-C-ID>:accesspoint/<Access-Point-Name>",
"arn:aws:s3:<Region>:<Account-C-ID>:accesspoint/<Access-Point-Name>/object/*"
]
}
]
}
- Asegúrese de que su política de cubo S3 se actualice para permitir que la cuenta sea un acceso. Este es un ejemplo de política de cubo S3:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::<bucket-name>",
"arn:aws:s3:::<bucket-name>/*"
],
"Condition": {
"StringEquals": {
"s3:DataAccessPointAccount": "<Account-C-ID>"
}
}
}
]
}
- En la cuenta A, cree una asociación de identidad POD para su clúster EKS utilizando la AWS CLI.
- Las cápsulas que acceden a los cubos S3 de cuenta cruzada necesitarán el nombre de la cuenta de servicio referenciado en su especificación POD.
Puede probar el acceso a datos de cuenta cruzada haciendo girar un POD de prueba y la ejecución en el POD para ejecutar los comandos de Amazon S3:
Este ejemplo muestra la creación de un solo rol de acceso a datos para un solo equipo. Para múltiples equipos, use un servicio de servicio específico de nombres con su propio papel de acceso a datos para ayudar a evitar el acceso a los recursos superpuestos en los equipos. También puede configurar el acceso de Amazon S3 de cuenta transversal para un Amazon FSX para Luster sistema de archivo en la cuenta A, como se describe en Use Amazon FSX para Luster para compartir datos de Amazon S3 en todas las cuentas. FSX para Luster y Amazon S3 deberá estar en la misma región de AWS, y el sistema de archivos FSX para Luster deberá estar en la misma zona de disponibilidad que su clúster Sagemaker HyperPod.
Conclusión
En esta publicación, proporcionamos orientación sobre cómo configurar el acceso a través de la cuenta cruzada a los científicos de datos que acceden a un clúster Hyperpod centralizado de Sagemaker orquestado por Amazon EKS. Además, cubrimos cómo proporcionar acceso a datos de Amazon S3 desde una cuenta a un clúster EKS en otra cuenta. Con el gobierno de tareas de Sagemaker HyperPod, puede restringir el acceso y calcular la asignación a equipos específicos. Esta arquitectura puede ser utilizada a escala por organizaciones que desean compartir un grupo de cómputo grande en todas las cuentas dentro de su organización. Para comenzar con la gobernanza de tareas de Sagemaker HyperPod, consulte el Soporte de Amazon EKS en Amazon Sagemaker HyperPod Workshop y Documentación de gobernanza de tareas de Sagemaker Hyperpod.
Sobre los autores
Nisha nadkarni es una arquitecta senior de soluciones especialistas en Genai en AWS, donde guía a las empresas a través de las mejores prácticas al desplegar capacitación e inferencia distribuidas a gran escala en AWS. Antes de su papel actual, pasó varios años en AWS se centró en ayudar a las nuevas empresas emergentes de Genai a desarrollar modelos desde la ideación hasta la producción.
Anoop saha es un especialista en SR GTM en Amazon Web Services (AWS) que se centra en la capacitación e inferencia del modelo de IA generativo. Se asocia con los principales constructores de modelos de frontera, clientes estratégicos y equipos de servicio de AWS para permitir la capacitación e inferencia distribuidas a escala en AWS y dirigir las mociones conjuntas de GTM. Antes de AWS, Anoop tenía varios roles de liderazgo en nuevas empresas y grandes corporaciones, centrándose principalmente en la arquitectura de silicio y el sistema de infraestructura de IA.
Kareem Syed-Mohammed es gerente de producto en AWS. Está enfocado en la optimización de cálculo y la gobernanza de costos. Antes de esto, en Amazon Quicksight, lideró la experiencia integrada y la experiencia del desarrollador. Además de QuickSight, ha estado con AWS Marketplace y Amazon Retail como Gerente de Producto. Kareem comenzó su carrera como desarrollador de Call Center Technologies, expertos locales y anuncios para Expedia y consultor de gestión en McKinsey.
Rajesh Ramchander es un ingeniero principal de ML en servicios profesionales en AWS. Ayuda a los clientes en varias etapas en su viaje AI/ML y Genai, desde aquellos que recién comienzan hasta aquellos que están liderando su negocio con una estrategia de IA-Primera.