

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.

# Actualizar la versión del programador de un AWS Clúster PCS
<a name="working-with_clusters_version_update_procedure"></a>

Siga estos pasos para actualizar la versión del planificador en su clúster. Hay dos opciones en función de si puede tolerar la interrupción del trabajo. Para obtener más información sobre cómo elegir entre las opciones, consulte[Actualización de la versión del programador de un clúster en AWS UNIDADES](working-with_clusters_version_update.md).

## Opción 1: actualización continua
<a name="version_update-procedure-option1"></a>

El mando se actualiza mientras la flota sigue funcionando. Los nodos existentes seguirán utilizando la versión anterior de Slurm hasta que se agoten y se sustituyan. Los nuevos nodos lanzados después de la actualización utilizan la versión de destino. Los trabajos en ejecución no se interrumpen.

**Cuándo usar:**
+ El controlador de clúster está en la versión 24.05 o posterior de Slurm.
+ Puede proporcionar AMI que incluyan tanto la versión actual como la de destino de Slurm.

### Paso 0: Comprobar el estado inicial
<a name="version_update-procedure-option1-step0"></a>

Su clúster ejecuta la versión «A» del controlador (por ejemplo, la 24.11) y desea migrar a la versión «B» (por ejemplo, la 25.11). Confirme que todos los nodos de cómputo de su flota ejecutan la misma versión principal mediante este comando desde un nodo de clúster:

```
scontrol show nodes | grep "Version="

# Example output:
#   NodeAddr=compute-1 NodeHostName=compute-1 Version=24.11.7
#   NodeAddr=compute-2 NodeHostName=compute-2 Version=24.11.7
```

Confirme la versión del agente AWS PCS en un nodo de cómputo. Conéctese al nodo con Systems Manager y compruebe el registro de arranque:

```
grep "PCS Agent version" /var/log/amazon/pcs/bootstrap.log | tail -1

# Example output:
#   /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Bootstrap starting with PCS Agent version: 1.3.2-1
```

Las actualizaciones sucesivas requieren la versión 1.4.0 o posterior del agente AWS PCS en todas las AMI de nodos de cómputo. Para obtener más información, consulte [AWS Versiones del agente PCS](pcs-agent-versions.md).

### Paso 1: Prepare e implemente las AMI de doble versión
<a name="version_update-procedure-option1-step1"></a>

Cree o identifique las AMI que incluyan **tanto la versión A como la versión B de Slurm y el agente de PCS más reciente AWS **.
+ **Puede utilizar las DLAMI más recientesPCS-ready .** Estas AMI vienen con las tres últimas versiones compatibles de Slurm. Para obtener más información, consulte [Uso de PCS-ready DLAMI con AWS UNIDADES](working-with_ami_pcs-ready-dlami.md).
+ Puede crear una **AMI personalizada** siguiendo los pasos de instalación de los paquetes Slurm y el agente AWS PCS. Para obtener más información, consulte [Imágenes personalizadas de Amazon Machine (AMIs) para AWS PCS](working-with_ami_custom.md).
+ **No puede** utilizar un **ejemplo de AMI de AWS PCS**. Estas AMI no están diseñadas para la producción y actualmente incluyen solo una versión de Slurm.

**nota**  
Si su AMI incluye más de dos versiones de Slurm, AWS PCS selecciona automáticamente la versión que coincida con el mando. Tener versiones adicionales instaladas no causa problemas.

Una vez que las AMI estén listas:

1. Llame `UpdateComputeNodeGroup` a cada grupo de nodos de cómputo para configurar la nueva AMI de doble versión. AWS PCS configurará los nodos en DRAIN y migrarán a la nueva AMI.

1. Espere a que los nodos agotados completen sus tareas, finalicen y sean reemplazados por nodos que utilicen la nueva AMI de doble versión. Compruebe que todas las instancias EC2 del clúster utilizan la nueva AMI con:

   ```
   aws ec2 describe-instances \
       --filters "Name=tag:aws:pcs:cluster-id,Values={{cluster-id}}" \
       --query "Reservations[].Instances[].[InstanceId,ImageId,State.Name]" \
       --output table
   ```

### Paso 2: Actualizar el controlador del clúster
<a name="version_update-procedure-option1-step2"></a>

Llame `UpdateCluster` con la versión B `scheduler.version` configurada.

------
#### [ AWS Management Console ]

1. Abra la consola AWS PCS en [https://console.aws.amazon.com/pcs/](https://console.aws.amazon.com/pcs/).

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. Seleccione el clúster que desee actualizar y pulse **Editar**.

1. En **Detalles del clúster**, selecciona la versión del programador de destino en el menú desplegable del **programador**.

1. Selecciona **Actualizar para enviar la actualización** de la versión.

1. Supervise el estado del clúster. El clúster se muestra como `UPDATING` durante la actualización y vuelve a aparecer `ACTIVE` cuando se ha completado. La actualización suele completarse en un plazo de 5 a 15 minutos.

------
#### [ AWS CLI ]

```
aws pcs update-cluster \
  --cluster-identifier {{cluster-id}} \
  --scheduler version={{25.11}}
```

Espere a que el clúster regrese a. `ACTIVE` La actualización suele completarse en un plazo de 5 a 15 minutos.

------

Durante esta operación, el mando no está disponible por un momento:
+ Los trabajos en ejecución en los nodos de cómputo **continúan ejecutándose**.
+ El envío de nuevos trabajos y los comandos del programador no estarán disponibles hasta que se complete la actualización.
+ El escalado automático se detiene hasta que el clúster vuelva a funcionar. `ACTIVE`

Tras la actualización, la flota informática pasa a un **estado mixto**: los nodos que se ejecutan antes de la actualización siguen utilizando la versión A de Slurm`slurmd`; los nodos nuevos utilizan la versión B. Es lo esperado.

**nota**  
No añada ajustes de Slurm específicos de la versión B mientras la flota aún contenga nodos en la versión A. La configuración se distribuye a todos los nodos; es posible que los antiguos `slurmd` no reconozcan los parámetros nuevos.

Si el clúster no regresa a los 30 minutos `ACTIVE` o `UPDATE_FAILED` en un plazo de 30 minutos, póngase en contacto con AWS Support para obtener ayuda.

### Paso 3: Vacíe los nodos que aún ejecutan la versión A de Slurm
<a name="version_update-procedure-option1-step3"></a>

Identifique y vacíe los nodos que aún estén en la versión anterior. Desde un nodo del clúster, ejecute:

```
scontrol show nodes | grep "Version="
scontrol update NodeName={{node}} State=DRAIN Reason="Slurm version update"
```

Una vez que los nodos agotados terminan sus tareas actuales, finalizan y son reemplazados por nodos de la versión B de Slurm.

### Paso 4: Verificar la coherencia de la flota en la versión B de Slurm
<a name="version_update-procedure-option1-step4"></a>

Confirme que todos los nodos informen de la versión B. Desde un nodo del clúster, ejecute:

```
scontrol show nodes | grep "Version="
```

Todos los nodos deberían informar ahora de la versión B de Slurm. La actualización se ha completado.

## Opción 2: reciclar Full-fleet
<a name="version_update-procedure-option2"></a>

Se cierra toda la flota antes de que se actualice el mando y, a continuación, se vuelve a escalar desde una nueva AMI con la versión de Slurm de destino. Este procedimiento es más sencillo, pero requiere que se cierren todos los nodos y los trabajos en ejecución.

**Cuándo usar:**
+ No puede proporcionar AMI con ambas versiones de Slurm instaladas.
+ El controlador de clústeres tiene la versión 23.11 (la opción 1 no está disponible para los clústeres 23.11).

**nota**  
Si se cancela toda la flota de una sola vez, aumenta la probabilidad de que se cometan errores de capacidad insuficiente al volver a escalar. Considere la posibilidad de utilizar la capacidad reservada o programarla fuera de las horas de mayor actividad.

### Paso 0: Comprobar el estado inicial
<a name="version_update-procedure-option2-step0"></a>

Su clúster ejecuta la versión «A» del controlador (por ejemplo, la 24.11) y desea migrar a la versión «B» (por ejemplo, la 25.11). Confirme que todos los nodos de cómputo de su flota ejecutan la misma versión principal mediante este comando desde un nodo de clúster:

```
scontrol show nodes | grep "Version="

# Example output:
#   NodeAddr=compute-1 NodeHostName=compute-1 Version=24.11.7
#   NodeAddr=compute-2 NodeHostName=compute-2 Version=24.11.7
```

Confirme la versión del agente AWS PCS en un nodo de cómputo. Conéctese al nodo con Systems Manager y compruebe el registro de arranque:

```
grep "PCS Agent version" /var/log/amazon/pcs/bootstrap.log | tail -1

# Example output:
#   /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Bootstrap starting with PCS Agent version: 1.3.2-1
```

Utilice el agente de AWS PCS más reciente en las AMI de destino. Para obtener más información, consulte [AWS Versiones del agente PCS](pcs-agent-versions.md).

### Paso 1: Prepare las AMI de destino
<a name="version_update-procedure-option2-step1"></a>

Cree o identifique las AMI que incluyan la **versión B de Slurm y el agente de AWS PCS más reciente.**
+ **Puede utilizar las DLAMI más recientesPCS-ready .** Estas AMI vienen con las tres últimas versiones compatibles de Slurm. Para obtener más información, consulte [Uso de PCS-ready DLAMI con AWS UNIDADES](working-with_ami_pcs-ready-dlami.md).
+ Puede crear una **AMI personalizada** siguiendo los pasos de instalación de los paquetes Slurm y el agente AWS PCS. Para obtener más información, consulte [Imágenes personalizadas de Amazon Machine (AMIs) para AWS PCS](working-with_ami_custom.md).
+ **No se recomienda utilizar el ejemplo de AMI del AWS PCS**. Estas AMI no están diseñadas para la producción.

### Paso 2: Reducir la escala de toda la flota
<a name="version_update-procedure-option2-step2"></a>

Registre el grupo de nodos `maxNodeCount` de cómputo actual `minNodeCount` y el de cada uno; los restaurará en el paso 4.

```
for cng in $(aws pcs list-compute-node-groups --cluster-identifier {{cluster-id}} --query "computeNodeGroups[].id" --output text); do
    aws pcs get-compute-node-group \
      --cluster-identifier {{cluster-id}} \
      --compute-node-group-identifier "$cng" \
      --query "computeNodeGroup.{Id:id,AmiId:amiId,Min:scalingConfiguration.minInstanceCount,Max:scalingConfiguration.maxInstanceCount}" \
      --output table
  done
```

**aviso**  
La siguiente operación finaliza todos los nodos en ejecución y las tareas que contienen.

Configure `minNodeCount` y `maxNodeCount` `0` en cada grupo de nodos de cómputo:

```
aws pcs update-compute-node-group \
  --cluster-identifier {{cluster-id}} \
  --compute-node-group-identifier {{cng-id}} \
  --scaling-configuration '{"minNodeCount": 0, "maxNodeCount": 0}'
```

Comprueba que no se esté ejecutando ninguna instancia etiquetada `aws:pcs:cluster-id` que coincida con tu clúster antes de continuar:

```
aws ec2 describe-instances \
    --filters "Name=tag:aws:pcs:cluster-id,Values={{cluster-id}}" \
    --query "Reservations[].Instances[].[InstanceId,ImageId,State.Name]" \
    --output table
```

### Paso 3: actualice el controlador del clúster
<a name="version_update-procedure-option2-step3"></a>

------
#### [ AWS Management Console ]

1. Abra la consola AWS PCS en [https://console.aws.amazon.com/pcs/](https://console.aws.amazon.com/pcs/).

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. Seleccione el clúster que desee actualizar y pulse **Editar**.

1. En **Detalles del clúster**, selecciona la versión del programador de destino en el menú desplegable del **programador**.

1. Selecciona **Actualizar para enviar la actualización** de la versión.

1. Supervise el estado del clúster. El clúster se muestra como `UPDATING` durante la actualización y vuelve a aparecer `ACTIVE` cuando se ha completado. La actualización suele completarse en un plazo de 5 a 15 minutos.

------
#### [ AWS CLI ]

```
aws pcs update-cluster \
  --cluster-identifier {{cluster-id}} \
  --scheduler version={{25.11}}
```

Espere a que el clúster regrese a. `ACTIVE` La actualización suele completarse en un plazo de 5 a 15 minutos.

Si el clúster no regresa a los 30 minutos `ACTIVE` o `UPDATE_FAILED` en un plazo de 30 minutos, póngase en contacto con AWS Support para obtener ayuda.

------

### Paso 4: Actualizar los grupos de nodos de cómputo y restaurar la capacidad
<a name="version_update-procedure-option2-step4"></a>

Para cada grupo de nodos de procesamiento, configure la nueva AMI y restablezca los límites de capacidad mínima y máxima originales:

```
aws pcs update-compute-node-group \
  --cluster-identifier {{cluster-id}} \
  --compute-node-group-identifier {{cng-id}} \
  --ami-id {{new-ami-id}} \
  --scaling-configuration '{"minNodeCount": {{previous-min}}, "maxNodeCount": {{previous-max}}}'
```

El clúster se amplía de nuevo. Todos los nodos nuevos ejecutan la versión B de Slurm con el agente de AWS PCS más reciente.

## Ejemplo: actualización en varias versiones
<a name="version_update-procedure-multi-hop"></a>

Si la versión de destino está fuera de la ventana de compatibilidad de tu versión actual, debes pasar del mando a una o más versiones intermedias y actualizarlo paso a paso. Cada salto debe apuntar a una versión compatible dentro de la ventana de compatibilidad de la versión actual del mando.

Dado que [Opción 2: reciclar Full-fleet](#version_update-procedure-option2) reduce la flota a cero antes de actualizar la controladora, no se ejecuta ningún nodo de cómputo mientras la controladora cambia de una versión a otra. Como resultado, las AMI pueden usar directamente la versión **final** de destino; solo se repite la actualización de la controladora (paso 3) en cada salto.

En el siguiente ejemplo, se actualiza un clúster del **23.11 al 25.11** mediante el procedimiento de la opción 2. El 23.11 está fuera del intervalo de compatibilidad del 25.11, por lo que el controlador se actualiza en dos saltos (del 23.11 al 25.05 y, luego, del 25.05 al 25.11). Siga los pasos de la opción 2, dividiendo el paso 3 en una actualización por salto:

1. **Paso 1: Prepare las AMI de destino.** Cree o identifique las AMI con la versión **final** (25.11) y el agente de AWS PCS más reciente. Consulte [Paso 1: Prepare las AMI de destino](#version_update-procedure-option2-step1).

1. **Paso 2: Reduzca la escala de toda la flota.** Registre la capacidad actual (consulte[Paso 2: Reducir la escala de toda la flota](#version_update-procedure-option2-step2)) y, a continuación, establezca todos los grupos de nodos de cómputo en cero.

   ```
   aws pcs update-compute-node-group \
   --cluster-identifier {{my-cluster}} \
   --compute-node-group-identifier {{my-cng}} \
   --scaling-configuration '{"minNodeCount": 0, "maxNodeCount": 0}'
   ```

1. **Paso 3a: actualice el controlador del 23 de noviembre al 25 de mayo.** Espere a que el clúster regrese a. `ACTIVE`

   ```
   aws pcs update-cluster --cluster-identifier {{my-cluster}} \
   --scheduler version=25.05
   ```

1. **Paso 3b: actualice el controlador del 25 de mayo al 25 de noviembre.** Espere a que el clúster regrese a. `ACTIVE`

   ```
   aws pcs update-cluster --cluster-identifier {{my-cluster}} \
   --scheduler version=25.11
   ```

1. **Paso 4: Actualizar los grupos de nodos de cómputo y restaurar la capacidad.** Configure la AMI 25.11 en cada grupo de nodos de procesamiento y restablezca los límites de capacidad originales (consulte[Paso 4: Actualizar los grupos de nodos de cómputo y restaurar la capacidad](#version_update-procedure-option2-step4)).

   ```
   aws pcs update-compute-node-group \
   --cluster-identifier {{my-cluster}} \
   --compute-node-group-identifier {{my-cng}} \
   --ami-id {{ami-0123456789abcdef0}} \
   --scaling-configuration '{"minNodeCount": {{previous-min}}, "maxNodeCount": {{previous-max}}}'
   ```

**nota**  
Cada salto de controlador debe realizarse en una versión que se encuentre dentro de la ventana de compatibilidad de la versión anterior. Para encontrar versiones intermedias válidas, consulte[Compatibilidad de versiones](working-with_clusters_version_update.md#version_update-cluster-compatibility). La flota permanece en cero durante los pasos 3a y 3b, por lo que no se requieren actualizaciones intermedias de la AMI.