Mantenga los servicios disponibles durante una actualización de SLES 15 SP5 a SP6.

Es difícil programar una ventana de mantenimiento corta cuando un servidor SLES ejecuta un servicio de cara al cliente. SUSE admite la migración en línea de Service Packs de SLES 15 SP5 a SP6, pero la máquina actualizada aún necesita reiniciarse; "en línea" no significa sin reinicio. Para mantener la accesibilidad de una aplicación, actualice los nodos redundantes uno a la vez o cree un reemplazo SP6 y redirija el tráfico hacia él. Un solo servidor no puede mantener su propio sistema operativo disponible mientras se reinicia.

Escenario ilustrativo: Un equipo ficticio ejecuta una aplicación web en tres nodos SLES 15 SP5 detrás de un balanceador de carga. La aplicación puede atender las solicitudes de los otros dos nodos mientras se realiza el mantenimiento de uno de ellos. La siguiente secuencia muestra cómo ese equipo podría migrar el clúster; se trata de un ejemplo, no de una afirmación de que se haya realizado una prueba ni de que todos los clústeres puedan tolerar la falla de un nodo.

1. Elija una ruta que coincida con el servicio.

Para la migración de SLES 15 SP5 a SP6, SUSE documenta métodos de actualización tanto en línea como fuera de línea. El método en línea utiliza la migración con YaST o zypper migrationmientras el sistema operativo está en funcionamiento, y requiere un reinicio del sistema después de la migración. Los cambios en los paquetes también pueden reiniciar los servicios, por lo que la migración en línea por sí sola no garantiza la continuidad de las aplicaciones.

Utilice el procedimiento de actualización progresiva de alta disponibilidad de SLE solo si su carga de trabajo ya está protegida por un clúster compatible y en buen estado. El clúster debe mantener el quórum y la capacidad suficiente para ejecutar el servicio incluso con un nodo fuera de línea. Un balanceador de carga convencional sin redundancia de aplicaciones, o un clúster de dos nodos que pierde el quórum cuando uno de ellos se detiene, no es suficiente. Si el servidor es independiente, utilice un host SP6 paralelo y una migración de datos/carga de trabajo probada para mantener la accesibilidad; de lo contrario, programe un tiempo de inactividad para su reinicio.

2. Verificar el objetivo y preparar un plan de recuperación.

Antes de modificar el clúster, verifique la versión inicial, el registro, los repositorios y las extensiones compatibles. SUSE indica que SLES 15 SP5 a SP6 es una ruta compatible. La migración en línea requiere que la máquina esté registrada en SUSE Customer Center o en un servidor RMT local; los clientes de SUSE Manager deben usar el procedimiento de migración de clientes de Manager en lugar de ejecutarlo zypper migrationdirectamente. El destino disponible puede depender de los productos y extensiones registrados.

Según la información de lanzamiento de SUSE, a partir del 1 de enero de 2026, SLES 15 SP6 se ​​ha migrado a LTSS. Confirme que su suscripción y fuente de registro ofrecen actualmente la compatibilidad con SP6 antes de programar esta migración. Si no está disponible, no fuerce un cambio de repositorio para simular una migración compatible.

Realice copias de seguridad de los datos y la configuración de la aplicación mediante el método compatible y confirme que puede restaurarlos. Consulte la guía de actualización de SLE HA y las notas de la versión SP6 para sus extensiones, bases de datos, almacenamiento y hardware. En el clúster ficticio, el operador también verifica el quórum, el aislamiento, el estado de la replicación, la capacidad de reserva, las comprobaciones del estado del balanceador de carga y un método probado para redirigir el tráfico fuera de cada nodo. Una instantánea puede facilitar la reversión en configuraciones raíz de Btrfs compatibles, pero no reemplaza las copias de seguridad de la aplicación ni de la base de datos.

3. Actualiza un nodo agotado a la vez.

Para cada nodo, siga el procedimiento de actualización progresiva de SLE HA y el manual de operaciones de su clúster. Nunca actualice varios nodos a la vez a menos que el procedimiento específico del producto lo permita explícitamente.

1. Confirme que los nodos restantes puedan gestionar la carga de trabajo. Verifique el estado de la aplicación y del clúster. Mueva o redirija el tráfico del nodo utilizando los controles documentados para su balanceador de carga y los recursos del clúster. No continúe si los nodos restantes no pueden mantener el quórum o cumplir con la capacidad mínima del servicio.
2. Detenga la pila del clúster en ese nodo. SUSE advierte que dejar el administrador de recursos del clúster activo durante la actualización del software puede provocar el aislamiento de los nodos activos. En el nodo seleccionado para el mantenimiento, ejecute:

sudo crm cluster stop

3. Inicie la migración del paquete de servicio e inspeccione la propuesta. Ejecute el comando de migración de Zypper documentado:

sudo zypper migration

Seleccione SLES 15 SP6 solo si aparece como destino disponible. Lea el repositorio y el plan de paquetes, especialmente aquellos que se proponen para su eliminación o degradación, y deténgase si los cambios son inesperados. No acepte un plan que no haya revisado. La lista exacta de paquetes varía según el software instalado y las extensiones registradas.

4. Reinicie el nodo actualizado. Después de que Zypper informe que la migración se realizó correctamente, reinicie la máquina para que arranque el kernel y los servicios de SP6:

sudo reboot

5. Vuelva a unirse y verifique antes de pasar al siguiente nodo. Una vez que el nodo regrese, inicie su pila de clúster:

sudo crm cluster start
sudo crm status

Espere hasta que el clúster informe que el nodo se ha unido y que los recursos están en buen estado; luego, restáurelo al servicio según su manual de procedimientos. Compruebe la aplicación desde fuera del clúster. Solo entonces repita el proceso para el siguiente nodo. SUSE permite versiones mixtas solo brevemente durante una actualización progresiva e indica a los administradores que completen la actualización del clúster en el plazo de una semana.

4. Verifique el servicio, no solo la etiqueta del sistema operativo.

Una vez actualizados todos los nodos, confirme su liberación con cat /etc/os-release, inspeccione el estado del clúster con crm statusy verifique las unidades systemd que hayan fallado con systemctl --failed. A continuación, pruebe la aplicación a través de su dirección de cliente habitual, incluyendo las comprobaciones de estado, el acceso a la base de datos o al almacenamiento y cualquier trabajo programado relevante para los usuarios. Revise los registros de migración y confirme que los repositorios y extensiones esperados estén activos en cada nodo.

Una migración exitosa del sistema operativo no garantiza la compatibilidad de todas las dependencias de la aplicación ni la ausencia de interrupciones en las solicitudes. Si la aplicación no tolera la conmutación por error de un nodo, utilice una implementación azul-verde con replicación de datos validada y un cambio de punto final controlado, o bien, planifique una ventana de mantenimiento. Para conocer las opciones de comandos y las condiciones de soporte, consulte la guía de actualización en línea de SLES 15 SP6 de SUSE , las rutas de actualización compatibles , el procedimiento de actualización continua de SLE HA y las notas de la versión 5.1 de SUSE Multi-Linux Manager para la nota de transición del ciclo de vida de SP6.