Una pregunta común que hacen los clientes es cómo actualizar correctamente las instancias de SUSE Linux Enterprise en la nube pública. Hay dos escenarios diferentes a tener en cuenta. El primer escenario es cuando desea realizar una actualización del paquete de servicio de una instancia de SLES o SLES para SAP. Por ejemplo, desea actualizar de SLES 15 SP1 a SLES 15 SP2. El segundo escenario es cuando desea realizar una actualización de versión importante de una instancia de SLES o SLES para SAP. Por ejemplo, desea actualizar de SLES 12 SP4 a SLES 15 SP2. Esta publicación detallará cómo lograr estos escenarios y, lo que es más importante, analizará los problemas que puede encontrar o que debe conocer y algunos consejos para validar su entorno una vez que se complete la actualización.
Tenga en cuenta que esta publicación asumirá que los repositorios de software de SUSE están disponibles para su instancia, ya sea que tengan una imagen PAYG o BYOS. Tampoco tratará otros procedimientos importantes que su organización pueda recomendar, por ejemplo, instantáneas de volumen o copias de seguridad de instancias antes de la actualización. Para obtener más información sobre cómo preparar su instancia o más detalles sobre los procedimientos mencionados en esta publicación, consulte la guía de implementación de SLE [1] .
Antes de hacer nada, querrá familiarizarse con las rutas de actualización admitidas. Consulte la guía de implementación para la versión SLE que necesita actualizar a [1] .
Me referiré a cada fase del proceso de actualización como la fase de PREPARACIÓN , donde la instancia está lista para ser actualizada, y la fase de MIGRACIÓN cuando la instancia se migra realmente.
Exploremos el primer escenario que mencioné anteriormente, que consiste en realizar una actualización del paquete de servicios. Esto podría ser la actualización de SLE 12 SP3 a SLE 12 SP4 o la actualización de SLE 15 SP1 a SLE 15 SP2. Esta no es una actualización de versión importante como SLE 12 a SLE 15. Hablaré de eso más adelante. Realizar una actualización de Service Pack es un proceso bastante sencillo. Lo primero que querrá hacer es PREPARAR la instancia, asegurándose de que esté completamente actualizada con las últimas actualizaciones. Para hacer esto, ejecute:
parche de zypper
Asegúrese de leer la salida mientras ejecuta este comando. Hay casos en los que es posible que deba ejecutar este comando más de una vez si es necesario reiniciar el administrador de paquetes. Esto se mostrará claramente como “Nota: Es necesario reiniciar el administrador de paquetes. (Ejecute este comando una vez más después de que la pila de actualizaciones se haya actualizado) ”.
Una vez que esto se completa, la instancia está lista para la fase de MIGRACIÓN . Para iniciar la migración de la instancia, ejecute:
migración zypper
Siga las indicaciones para seleccionar su destino de migración. Una vez que se complete la actualización, reinicie la instancia. Puede continuar ejecutando estos dos comandos si necesita actualizar más la instancia. Por ejemplo, si la instancia se actualizó de SLES 12 SP2 a SLES 12 SP3, puede volver a ejecutar estos dos comandos para actualizar la instancia de SLES 12 SP3 a SLES 12 SP4. Es así de simple.
Pasemos al segundo escenario, que está realizando una actualización de versión importante. Estos tipos de actualizaciones son únicos porque solo pueden ocurrir sin conexión. Esto significa que ejecutar zypper mientras la instancia está en línea no es una opción. Afortunadamente, nuestro equipo de ingeniería de nube pública creó un sistema sólido llamado SUSE Distribution Migration System [2] . Este sistema está disponible para todos los clientes de nube pública de Azure, GCP y AWS con imágenes PAYG o BYOS. Antes de entrar en el proceso de actualización, primero quiero describir cómo funciona este sistema.
During a major release upgrade, the instance will need to boot to the distribution media upgrading to, SLE 15. Unlike on-premise servers or VMs, it’s impossible to attach an ISO or USB physically or virtually through a console. There needs to be another way. This is where the SUSE Distribution Migration System enters to solve the problem. Before the migration is started on the instance, the instance bootloader configuration is modified, and an entry is created to boot to an image during the next reboot. From here, the distribution migration begins.
Sin embargo, antes de comenzar este proceso, es importante PREPARAR la instancia, que consta de varios pasos. El primer paso es utilizar el proceso del primer escenario anterior para actualizar la instancia a SLE 12 SP4 o SLE 12 SP5. Si la instancia ya estaba en uno de estos niveles, asegúrese de que esté completamente parcheada. Como recordatorio, para hacer esto, ejecute:
parche de zypper
A continuación, los paquetes del Sistema de migración de distribución de SUSE deberán instalarse ejecutando:
zypper en suse-migración-sle15-activación
Esto creará la configuración del cargador de arranque mencionada anteriormente y también agregará la imagen ISO a la instancia. Esta imagen es lo que cargará la entrada del cargador de arranque durante el próximo arranque. Un último paso opcional es realizar la personalización del proceso de actualización. De forma predeterminada, las instancias se actualizarán a SLE 15 SP1. Pero si la intención es actualizar a SLE 15, entonces se requiere personalización [3] . Para cambiar el producto de migración, cree un archivo con el nombre /etc/sle-migration-service.ymly agregue el producto de migración deseado.
Por ejemplo, para actualizar a SLES para SAP 15 en lugar de SLES para SAP 15 SP1, /etc/sle-migration-service.ymldebe contener:
SLES_SAP / 15 / x86_64
Después de completar cualquier personalización , puede comenzar la siguiente fase, MIGRACIÓN . Para iniciar este proceso, reinicie la instancia. Esto iniciará el proceso de migración de distribución automatizada. Ahora siéntese y espere a que se complete el proceso. Si desea monitorear el progreso, puede usar la consola serial, si es compatible, o la captura de pantalla de la consola. También puede realizar lo siguiente para obtener una jugada por jugada:
migración de sudo ssh @ IP_OF_INSTANCEntail -f /system-root/var/log/distro_migration.log
Una vez que se complete el proceso, la instancia se reiniciará automáticamente. Si todo salió según lo planeado, la instancia se actualizaría y la versión del sistema operativo se puede confirmar con:
cat / etc / os-release
Tenga en cuenta que la migración de la distribución siempre actualizará la instancia a los últimos paquetes disponibles. No hay forma de manipular esto.
Si se encontraran problemas que impidieran que se completara la actualización, la instancia volvería a su estado original. El archivo de registro /var/log/distro_migration.logdebería revelar el problema. Pero si necesita más ayuda para las imágenes PAYG, comuníquese con su proveedor de servicios en la nube. Para imágenes BYOS, comuníquese con SUSE.
Quiero compartir algunos problemas que he visto más de una vez y recomiendo verificar proactivamente la instancia o el entorno antes de comenzar el proceso.
Según mi experiencia, la causa más común de falla se debe a repositorios no compatibles o que ya no funcionan. Para probar esto antes de iniciar el proceso de migración de la distribución, zypper refreshdebe actualizar los repositorios y completar sin necesidad de intervención manual. Si la actualización falla para un repositorio, entonces el repositorio debe eliminarse o rectificarse antes de continuar.
En GCP, si las instancias usan Cloud NAT y los puertos mínimos por instancia de VM no se han aumentado de 64, la migración siempre fallará. Consulte el siguiente TID para asegurarse de que Cloud NAT esté configurado correctamente para manejar la actualización [4] .
Puede haber paquetes instalados que causen conflictos. En SLES para instancias de SAP, los dos paquetes siguientes nunca deberían estar presentes:
sle-ha-releasensle-ha-release-POOL
Si la instancia es SLES para SAP, elimine estos paquetes antes de comenzar la migración de distribución:
zypper eliminar sle-ha-release sle-ha-release-POOL
Todos los entornos de clientes son únicos y, como tal, pueden surgir problemas como resultado. Realizar una actualización de versión importante es exactamente eso, importante, y algunos aspectos del entorno no están en el estado exacto en el que estaban antes de la actualización. Como resultado, es importante realizar una verificación posterior de todas las aplicaciones y configuraciones. Recomendaría realizar una comprobación de los paquetes huérfanos, que son paquetes que no pertenecen a un repositorio activo. El siguiente comando le dará una lista de paquetes huérfanos para que pueda decidir si deben desinstalarse:
paquetes zypper --orphaned
Por último, busque los archivos *.rpmnewo y examine su contenido para determinar si es necesario fusionarlos con la configuración actual. Puede consultar la Guía de actualización para obtener más información [1] .*.rpmsave/etc
Para terminar, tenga en cuenta que también tiene la opción de comenzar de nuevo en lugar de actualizar. Comenzar de cero significa lanzar una nueva instancia y luego migrar los datos, las aplicaciones y la configuración a la nueva instancia desde la anterior. Escucharás diferentes opiniones sobre cuál es tu preferencia dependiendo de a quién le preguntes. Al final, la decisión es tuya.
[1] https://documentation.suse.com/sles
[4] https://www.suse.com/support/kb/doc/?id=000019662
Linware Panamá ⯈