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.
Uso de Instancias de spot
AWS ParallelCluster utiliza instancias de spot si la configuración del clúster ha definido cluster_type = spot. Las instancias puntuales son más rentables que las instancias bajo demanda, pero pueden interrumpirse. El efecto de la interrupción varía en función del planificador específico utilizado. Puede ser útil aprovechar los avisos de interrupción de instancias de spot, que proporcionan una advertencia de dos minutos antes de que Amazon EC2 tenga que detener o terminar la instancia de spot. Para obtener más información, consulte Interrupciones de instancias de instancias de spot en la Guía del usuario de Amazon EC2 para instancias de Linux. En las secciones siguientes se describen tres escenarios en los que las instancias de spot pueden interrumpirse.
El uso de instancias de spot requiere que elAWSServiceRoleForEC2Spot rol vinculado al servicio exista en la cuenta. Para crear este rol en su cuenta con laAWS CLI, ejecute el siguiente comando:
aws iam create-service-linked-role --aws-service-name spot.amazonaws.com
Para obtener más información, consulte Función vinculada a servicios para solicitudes de instancias de spot en la Guía del usuario de Amazon EC2 para instancias de Linux.
Escenario 1: Se interrumpe una instancia de spot sin trabajos en ejecución
Cuando se produce esta interrupción, AWS ParallelCluster intenta reemplazar la instancia si la cola del programador tiene trabajos pendientes que requieren instancias adicionales o si el número de instancias activas es menor que el valor de initial_queue_size. Si noAWS ParallelCluster puedes aprovisionar nuevas instancias, la solicitud de instancias nuevas se repite periódicamente.
Escenario 2: Se interrumpe una instancia de spot que ejecuta trabajos de un solo nodo
El comportamiento de esta interrupción depende del programador que se esté utilizando.
- Slurm
-
El trabajo falla con un código de
NODE_FAILestado de y se pone en cola (a menos que--no-requeuese especifique al enviar el trabajo). Si el nodo es estático, se reemplaza. Si el nodo es un nodo dinámico, se termina y se restablece. Para obtener más información sobresbatcheste parámetro, incluido el--no-requeueparámetro, consulte sbatchla documentación de Slurm. nota Este comportamiento cambió enAWS ParallelCluster la versión 2.9.0. Las versiones anteriores finalizaban el trabajo con un código de estado de
NODE_FAILy el nodo se eliminaba de la cola del programador. - SGE
-
nota Esto solo se aplica aAWS ParallelCluster las versiones anteriores a la 2.11.4, incluida. A partir de la versión 2.11.5,AWS ParallelCluster no admite el uso deSGETorque programadores.
Se termina el trabajo. Si el trabajo ha habilitado el indicador "rerun" (mediante
qsub -r yesoqalter -r yes) o la cola tiene el valor dererunestablecido enTRUE, el trabajo se reprograma. La instancia de computación se elimina de la cola del programador. Este comportamiento proviene de estos parámetros de configuración de SGE:-
reschedule_unknown 00:00:30 -
ENABLE_FORCED_QDEL_IF_UNKNOWN -
ENABLE_RESCHEDULE_KILL=1
-
- Torque
-
nota Esto solo se aplica aAWS ParallelCluster las versiones anteriores a la 2.11.4, incluida. A partir de la versión 2.11.5,AWS ParallelCluster no admite el uso deSGETorque programadores.
El trabajo se elimina del sistema y el nodo se elimina del programador. El trabajo no se vuelve a ejecutar. Si se están ejecutando varios trabajos en la instancia cuando se interrumpe, es posible que se agote el tiempo de espera de Torque durante la eliminación del nodo. Es posible que aparezca un error en el archivo desqswatcher registro. Esto no afecta a la lógica de escalado, y los reintentos posteriores realizan una limpieza adecuada.
Escenario 3: Se interrumpe una instancia de spot que ejecuta trabajos de varios nodos
El comportamiento de esta interrupción depende del programador que se esté utilizando.
- Slurm
-
El trabajo falla con un código de estado de
NODE_FAILy se pone en cola (a menos que--no-requeuese haya especificado cuando se envió el trabajo). Si el nodo es estático, se reemplaza. Si el nodo es un nodo dinámico, se termina y se restablece. Es posible que otros nodos que ejecutaran las tareas finalizadas se asignaran a otras tareas pendientes o se redujeran unascaledown_idletime vez transcurrido el tiempo configurado.nota Este comportamiento cambió enAWS ParallelCluster la versión 2.9.0. Las versiones anteriores finalizaban el trabajo con un código de estado de
NODE_FAILy el nodo se eliminaba de la cola del programador. Es posible que otros nodos que ejecutaban las tareas finalizadas se redujeran unascaledown_idletime vez transcurrido el tiempo configurado. - SGE
-
nota Esto solo se aplica aAWS ParallelCluster las versiones anteriores a la 2.11.4, incluida. A partir de la versión 2.11.5,AWS ParallelCluster no admite el uso deSGETorque programadores.
El trabajo no finaliza y continúa ejecutándose en los nodos restantes. El nodo de computación se elimina de la cola del programador, pero aparecerá en la lista de hosts como un nodo huérfano y no disponible.
El usuario debe eliminar el trabajo cuando esto ocurra (
qdel). El nodo sigue apareciendo en la lista de anfitriones (<jobid>qhost), aunque esto no afectaAWS ParallelCluster. Para eliminar el host de la lista, ejecute el siguiente comando después de reemplazar la instancia.sudo -- bash -c 'source /etc/profile.d/sge.sh; qconf -dattr hostgroup hostlist<hostname>@allhosts; qconf -de<hostname>' - Torque
-
nota Esto solo se aplica aAWS ParallelCluster las versiones anteriores a la 2.11.4, incluida. A partir de la versión 2.11.5,AWS ParallelCluster no admite el uso deSGETorque programadores.
El trabajo se elimina del sistema y el nodo se elimina del programador. El trabajo no se vuelve a ejecutar. Si se están ejecutando varios trabajos en la instancia cuando se interrumpe, es posible que se agote el tiempo de espera de Torque durante la eliminación del nodo. Es posible que aparezca un error en el archivo desqswatcher registro. Esto no afecta a la lógica de escalado, y los reintentos posteriores realizan una limpieza adecuada.
Para obtener más información acerca de las instancias de spot, consulte Instancias de spot en la Guía del usuario de Amazon EC2 para instancias Linux.
