Cómo migrar SLES 15 SP5 a SP6 sin tiempo de inactividad del sistema.

Puede mantener una aplicación disponible mientras migra un clúster SLES 15 SP5 a SP6, pero no puede actualizar ni reiniciar una única instancia del sistema operativo sin ninguna interrupción. SUSE admite la migración de Service Pack de SP5 a SP6, y el proceso de migración en línea aún requiere un reinicio del sistema. Para evitar tiempos de inactividad del servicio, actualice un nodo a la vez en un clúster SUSE Linux Enterprise High Availability (SLE HA) compatible, o cree un entorno SP6 de reemplazo y dirija el tráfico a él. El servicio debe tener un entorno en funcionamiento donde ejecutarse mientras cada host no esté disponible.

Esta guía para principiantes se centra en la actualización progresiva de un clúster SLE HA. También explica qué hacer si solo dispone de un servidor, qué comprobar antes del cambio y cómo verificar si el servicio se mantuvo en buen estado. Los comandos exactos y el orden para migrar las cargas de trabajo dependen de los recursos del clúster, el almacenamiento y la aplicación.

Qué significa “sin tiempo de inactividad del sistema”

Una migración de Service Pack reemplaza los paquetes del sistema mientras el sistema de origen está en funcionamiento. SUSE la denomina migración en línea. Reduce la necesidad de arrancar desde el medio de instalación, pero el procedimiento oficial indica que se debe reiniciar el sistema tras una migración exitosa. La migración en línea no es lo mismo que una actualización en vivo, que mantiene el mismo host atendiendo solicitudes de forma continua.

En un servicio en clúster, una actualización progresiva implica desconectar un nodo, migrarlo y reiniciarlo, reintegrarlo al clúster y repetir el proceso con el siguiente nodo. La aplicación puede seguir disponible desde otro nodo si la conmutación por error funciona correctamente y la capacidad restante es suficiente. Sin embargo, una conmutación por error puede provocar una breve interrupción en las sesiones activas, por lo que conviene evaluar el servicio de cara al usuario en lugar de asumir que la alta disponibilidad garantiza que todas las conexiones permanezcan ininterrumpidas.

SUSE incluye SLES 15 SP5 como fuente compatible para SP6, tanto en línea como fuera de línea. La ruta compatible se documenta en la guía de ruta de actualización de SLES 15 SP6 . La documentación de SUSE HA admite una actualización gradual del clúster entre paquetes de servicio dentro de la misma versión principal. Consulte la guía de actualización del clúster SLE HA .

Elige el enfoque correcto antes de cambiar nada.

• Un servidor independiente: programe una ventana de mantenimiento para la migración del host y el reinicio. Un balanceador de carga no puede eliminar el tiempo de inactividad si no hay una segunda instancia de la aplicación en buen estado.
• Dos o más nodos SLE HA: considere el procedimiento de actualización progresiva documentado, después de verificar el quórum, el aislamiento, la ubicación de los recursos, el acceso al almacenamiento y la capacidad de reserva.
• Aplicación con réplicas fuera de SLE HA: actualice un host o grupo SP6 de reemplazo, valídelo y traslade el tráfico gradualmente. Se trata de una implementación azul-verde o continua en la capa de aplicación; es independiente de una migración SLES in situ.
• Host gestionado por SUSE Manager: siga el flujo de trabajo de migración de clientes de SUSE Manager. SUSE recomienda no utilizar la migración en línea de YaST ni zypper migrationdirectamente en un cliente de SUSE Manager.

Si su servicio es una base de datos u otra aplicación con estado, considere la compatibilidad de la aplicación y la replicación de datos como un proceso independiente. Una migración del sistema operativo no actualiza automáticamente la base de datos ni garantiza la seguridad de su diseño de replicación y conmutación por error.

Preparar el clúster y el plan de cambio.

1. Confirme las versiones, el registro y la elegibilidad para la actualización.

Verifique que cada nodo esté en SLES 15 SP5, con la extensión SLE HA y los demás módulos o productos registrados según lo previsto. La lista de destinos de migración depende de los productos y extensiones instalados. La ausencia del destino SP6 puede indicar un problema de registro, repositorio o disponibilidad de la extensión; no intente forzar una ruta de repositorio diferente solo para que aparezca el destino.

Para un sistema registrado, las siguientes comprobaciones de solo lectura pueden ayudar a determinar su estado:

cat /etc/os-release
sudo SUSEConnect --status
sudo zypper lr -u

Compare los productos, repositorios y arquitectura de SLES y SLE HA instalados en todos los nodos. Si el host se administra mediante SUSE Manager, utilice el procedimiento de migración de cliente correspondiente en lugar de los pasos directos que se describen a continuación.

2. Aplicar parches, realizar copias de seguridad y probar.

SUSE requiere que el sistema de origen tenga instalado el parche más reciente antes de actualizar. Aplique las actualizaciones de mantenimiento SP5 vigentes y revise las notas de la versión SP6 para conocer los cambios en paquetes, módulos y aplicaciones. Las instrucciones de preparación para la actualización de SUSE también recomiendan realizar una copia de seguridad reciente y revisar las notas de la versión.

Realice una copia de seguridad de la configuración del sistema y los datos de la aplicación, y verifique que la copia de seguridad se pueda restaurar. Pruebe todo el procedimiento en un clúster de prueba que coincida con el de producción, incluyendo las interfaces de red, el almacenamiento, los recursos del clúster, los repositorios de terceros y las comprobaciones del estado de la aplicación. Registre el tiempo que tardan la migración y el reinicio en cada nodo para poder estimar el tiempo necesario para realizar los cambios.

3. Demostrar que los nodos restantes pueden soportar la carga de trabajo.

Antes de eliminar un nodo, confirme que el clúster esté en buen estado y no presente fallos de recursos sin resolver. Verifique que otro nodo pueda ejecutar los servicios, montar o acceder al almacenamiento necesario y gestionar el tráfico previsto. Si la pérdida de un nodo sobrecargaría la CPU, la memoria, la red o el almacenamiento, aumente la capacidad, reduzca la carga o programe una ventana de mantenimiento en lugar de declarar que no habrá tiempo de inactividad.

Asegúrese de que el aislamiento del clúster esté configurado y funcionando según su diseño de alta disponibilidad (HA) establecido. El aislamiento protege los recursos compartidos al aislar un nodo que no es confiable; deshabilitarlo para que una actualización parezca más sencilla puede generar un riesgo de división de clúster (split-brain). Mantenga disponible el acceso a la consola o fuera de banda en caso de que un nodo no se reactive después del reinicio.

Ejecuta una actualización progresiva, un nodo a la vez.

Utilice los pasos que se describen a continuación como guía de planificación. Siga el procedimiento correspondiente a su versión exacta de SLE HA y a la configuración de sus recursos; no copie una secuencia de gestión de recursos directamente en el entorno de producción.

1. Confirme el estado del clúster. Capture el estado actual y confirme que todos los nodos y recursos estén en buen estado. En SLE HA, crm statusesta es una forma documentada de inspeccionar el estado del clúster.
2. Traslada o vacía los servicios del nodo. Utiliza el procedimiento aprobado por tu clúster para colocar los recursos de la aplicación en otro nodo en buen estado. Verifica el punto final de la aplicación y el almacenamiento dependiente antes de continuar.
3. Detenga la pila del clúster en el nodo que se está actualizando. Las instrucciones de actualización progresiva de SUSE advierten que dejar el administrador de recursos del clúster activo durante una actualización de software puede provocar problemas como el aislamiento de nodos activos. El comando documentado a nivel de nodo es crm cluster stop.
4. Ejecute la migración del Service Pack de SLES. En un host registrado que no esté administrado por SUSE Manager, utilice sudo zypper migration. Revise los cambios de destino y repositorio de SP6 ofrecidos. Lea las acciones de paquete propuestas, especialmente los paquetes que se eliminarán o degradarán, antes de confirmar. Las instrucciones oficiales de migración en línea de SLES describen esta ruta de línea de comandos.
5. Reinicie y verifique el nodo. Una vez finalizada la migración, reinicie el host según las instrucciones de SUSE. Confirme que arranca con SLES 15 SP6, que los productos necesarios están registrados, que los repositorios coinciden con el Service Pack de destino y que el nodo no presenta errores críticos del sistema.
6. Devuelva el nodo al clúster. Inicie su pila de clúster siguiendo el procedimiento aprobado; la guía de SLE HA lo muestra crm cluster start. Compruebe crm statusHawk2 y verifique que el nodo se reincorpore sin fallos de recursos.
7. Repita este proceso solo cuando el clúster esté estable. Retire la carga de trabajo del siguiente nodo, exclúyalo del clúster, migre, reinicie, valide y vuelva a unirlo. No inicie el siguiente nodo mientras el clúster restante esté degradado o tenga una carga de trabajo superior a la que puede soportar de forma segura.

SUSE indica que los nodos de clúster con versiones mixtas solo se admiten temporalmente durante la actualización progresiva y que esta debe completarse en una semana. Planifique una secuencia corta y controlada en lugar de dejar un clúster con versiones mixtas indefinidamente. Para finalizar, confirme que todos los nodos ejecutan SP6, verifique el estado del clúster y de la aplicación, y revise los registros y el registro del repositorio.

Problemas comunes y qué hacer

• No aparece ningún destino de migración a SP6: verifique el registro, los repositorios activos y si cada módulo o extensión instalado tiene un destino SP6 compatible. Resuelva los problemas de repositorio o de permisos antes de comenzar.
• El solucionador propone eliminaciones inesperadas: deténgase e investigue el origen de los paquetes, los repositorios de terceros y las dependencias. SUSE indica que los repositorios locales o de DVD obsoletos deben deshabilitarse para la migración. No acepte un plan de paquetes que no pueda explicar.
• El nodo actualizado no se volverá a unir: mantenga la aplicación en nodos en buen estado, inspeccione los registros del clúster y del sistema, y ​​verifique la red del nodo, el registro del producto, la configuración del repositorio y los paquetes SLE HA antes de volver a intentarlo.
• El servicio está disponible, pero los usuarios reportan errores: pruebe las transacciones de la aplicación, no solo la disponibilidad del servidor. Valide las conexiones a la base de datos, el almacenamiento compartido, la autenticación, las tareas programadas y cualquier comprobación del estado del balanceador de carga.
• Un sistema de servidor único debe permanecer en línea: no existe un procedimiento de migración de paquete de servicio SLES in situ que evite el reinicio en ese mismo host. Agregue una segunda instancia de la aplicación o planifique un período de mantenimiento.

Cómo determinar si se evitó el tiempo de inactividad

Defina una condición de éxito medible antes del cambio. Por ejemplo: la comprobación de estado externa del servicio se mantiene correcta durante el mantenimiento de cada nodo, las tasas de error permanecen dentro del umbral acordado y una transacción de usuario representativa se completa con éxito mientras un nodo no está disponible. Registre cualquier interrupción en la conmutación por error, sesiones interrumpidas, trabajo en cola o rendimiento degradado. Si el punto final se mantuvo activo, pero falló un flujo de trabajo clave, la migración no cumplió con el objetivo de nivel de servicio.

Una actualización progresiva puede mantener disponible un servicio diseñado adecuadamente mientras se reinician los servidores individuales. Sin embargo, no garantiza sesiones ininterrumpidas, no compensa un clúster con capacidad insuficiente ni elimina el reinicio de cada host migrado. Para implementaciones de un solo nodo, aplicaciones con estado sin replicación probada o clústeres con extensiones no compatibles, utilice una ventana de mantenimiento planificada o cree y valide un entorno de reemplazo antes de migrar el tráfico de producción.

Referencias oficiales

• SUSE: Rutas de actualización y migración compatibles a SLES 15 SP6
• SUSE: Preparando la actualización
• SUSE: Actualización en línea con YaST o Zypper
• SUSE: Actualización progresiva del clúster SLE HA
• SUSE: Notas de la versión SLES 15 SP6