Lanzamiento de instancias con bloques de capacidad (CB) - AWS ParallelCluster

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.

Lanzamiento de instancias con bloques de capacidad (CB)

AWS ParallelCluster admite reservas de capacidad bajo demanda (ODCR) y bloques de capacidad (CB) para Machine Learning. A diferencia de las ODCR, los bloques de capacidad pueden tener una hora de inicio en el futuro y tienen una duración finita en el tiempo. Para obtener más información sobre el lanzamiento con ODCR, consulte Inicio de instancias con reservas de capacidad bajo demanda (ODCR).

Uso de CB con AWS ParallelCluster

Para configurar sus clústeres nuevos o existentes para que usen un CB, primero debe tener un CB válido en su AWS cuenta. Puedes usar el AWS Management Console AWS Command Line Interface, o el SDK para buscar y comprar un CB disponible siguiendo la documentación oficial. Una vez que tenga un CB válido, podrá establecer el nombre de Amazon Resource Name (ARN) del CB y los parámetros relacionados en su archivo de AWS ParallelCluster configuración. Para obtener más información, consulte Búsqueda y compra de bloques de capacidad (CB)

CB en la configuración del clúster

Para usar un CB para una cola específica, debe usar el parámetro CapacityReservationId. Configúrelo en un ID de CB existente. Puede obtener el ARN del CB del AWS Management Console AWS CLI, o del SDK que utilizó para crear el CB.

Tiene que configurar el parámetro CapacityType = CAPACITY_BLOCK de la cola en la que quiere usar el CB. Configúrelo en el InstanceType del recurso de computación (el mismo tipo de instancia de Amazon Elastic Compute Cloud del CB).

Cuando CapacityReservationId se especifica a nivel de recurso de computación, InstanceType es opcional porque se recuperará automáticamente de la reserva.

Al usar CapacityType = CAPACITY_BLOCK, MaxCount debe ser igual a MinCount y superior a 0, ya que todas las instancias que forman parte de la reserva de CB se administran como nodos estáticos.

En el momento de la creación del clúster, el nodo principal espera a que todos los nodos estáticos estén listos para indicar que la creación del clúster se ha realizado correctamente. Sin embargo, cuando se utiliza CapacityType = CAPACITY_BLOCK, los nodos que forman parte de los recursos de computación asociados no se tendrán en cuenta en esta comprobación. El clúster se creará aunque no todos los que se han configurado estén activos.

El siguiente fragmento de archivo de configuración muestra los parámetros necesarios para habilitarlos en el AWS ParallelCluster archivo de configuración.

SlurmQueues: - Name: string CapacityType: CAPACITY_BLOCK ComputeResources: - Name: string InstanceType: String (EC2 Instance type of the CB) MinCount: integer (<= total capacity of the CB) MaxCount: integer (equal to MinCount) CapacityReservationTarget: CapacityReservationId: String (CB id)

¿Cómo se AWS ParallelCluster utilizan los bloques de capacidad (CB)

AWS ParallelCluster gestiona los nodos estáticos asociados a ellos de una forma peculiar. AWS ParallelCluster crea un clúster incluso si el CB aún no está activo, y las instancias se lanzan automáticamente una vez que el CB está activo.

La Slurm los nodos que corresponden a los recursos informáticos, que están asociados a los recursos informáticos y que aún no están activos, se mantienen en mantenimiento hasta que llegan a la hora de inicio del CB. Slurm los nodos permanecen en estado de reserva o mantenimiento y están asociados al usuario administrador de slurm. Esto significa que pueden aceptar trabajos, pero dichos trabajos permanecen como pending hasta que se elimina la reserva.

AWS ParallelCluster se actualiza automáticamente Slurm reserva y pone en mantenimiento los nodos CB relacionados (correspondientes al estado CB). Cuando el CB está activo, el Slurm se elimina la reserva, los nodos se inician y pasan a estar disponibles para los trabajos pendientes o para la presentación de nuevos trabajos.

Cuando se alcance la hora de finalización del CB, los nodos volverán a ser un reservation/maintenance state. It’s up to users to resubmit/requeue the jobs to a new queue/compute recurso cuando el CB deje de estar activo y las instancias se cierren.