Guía para actualizar desde BroadWorks 23.0

Introducción

Este documento describe las consideraciones y los requisitos para ayudar en la planificación de una actualización desde la versión de origen de BroadWorks 23.0.

Overview

BroadWorks Release 23.0 admite actualizaciones a las versiones 24.0 y 25.0. La versión 23.0 era EoM a finales de julio de 2024, y se espera que la versión 24.0 sea End of Maintenance (EoM) a finales de julio de 2026. Los servidores que no son de aplicaciones actualizan a la última versión independiente de la versión disponible (consulte la sección Matriz de compatibilidad de software titulada "Mapas de actualización admitidos"). Los servidores de aplicaciones actualizan a 2024.07. Una vez que todos los servidores se han actualizado, los servidores de aplicaciones deben actualizarse de nuevo a la última versión hasta 2026.07.

Liberar versiones independientes

A partir de la versión 23.0, MS es independiente de la versión (RI), en la versión 24.0 todos los servidores excepto los servidores de aplicaciones (AS) RI, y en la versión 25.0 todos los servidores son independientes de la versión. Todas las nuevas funciones, errores y correcciones de seguridad se entregan en una nueva versión. Los parches no están disponibles; en su lugar, los servidores deben actualizarse de una versión a otra para obtener una corrección. Cada mes se lanza una nueva versión de cada servidor (en lugar de paquetes de parches mensuales) o con mayor frecuencia si se requiere una solución urgente.

Las versiones de RI utilizan un formato diferente al formato estándar Rel_24.0_1.944. Este formato de RI es Server_Rel_yyyy.mm_x.xxx:

• El servidor es MS, por ejemplo:
• aaaa es el año de cuatro dígitos
• mm es el mes de dos dígitos
• x.xxx es la versión incremental para ese mes

MS_Rel_2022.11_1.273.Linux-x86_64.bin es una versión de MS lanzada en noviembre de 2022. A menudo, se abrevia como 2022.11 si no se hace referencia a un tipo de servidor específico o a una versión incremental.

Requisitos del sistema operativo

Compruebe que la versión de destino admite el sistema operativo (SO) de origen.

Los sistemas operativos compatibles son Red Hat Enterprise Linux, Oracle Linux y CentOS 7. CentOS 8, CentOS Stream, Rocky Linux y Alma Linux no son compatibles.

El soporte para Linux 6 finalizó el 30 de abril de 2023 con 2023.05.
El soporte para Linux 7 finalizó el 20 de junio de 2024 con 2024.07.

El soporte para Linux 9 está disponible a partir de 2023.09+.

Versiones principales de Linux compatibles

R23 5.9+, 6.5+, 7 y 8.x (se requiere ap385046)
R24: 6,5+, 7, 8

Versiones de Linux compatibles independientes de versiones

Más de 2018.01: 5,9+, 6,5+, 7
Más de 2019.10: 6,5+, 7
+ de 2020.07: 6,5+, 7, 8
+ de 2023.05: 7, 8

+ de 2023.10: 7, 8, 9 (Linux 9 no es compatible con el AS hasta 2024.04)

+ de 2024.04: 7, 8, 9
+ de 2024.07: 8, 9

Servidor de base de datos (DBS) Versiones de Linux compatibles

2018.11 a 2020.08: 6,5+, 7
2020.11 a 2022.06: 7.5+ solo
+ de 2022.07: + de 7,5 y + de 8,5

+ de 2024.07: + de 8,5

2024.09: Versión final/fin de vida útil

Actualizaciones de SO

BroadWorks no ha soportado históricamente actualizaciones in situ entre las principales versiones de Linux. Históricamente, se recomienda realizar un intercambio de hardware, crear un nuevo servidor en la versión de Linux de destino y migrar el servidor existente al nuevo servidor. A partir de la versión 2023.12, se admiten actualizaciones de Linux in situ de Linux 7 a 8 y de 8 a 9. Para realizar una actualización de Linux in situ, los servidores deben actualizarse primero a 2023.12 o posterior.

Para obtener documentación sobre las actualizaciones de Linux in situ, consulte la sección 9 de la Guía de administración de software. Para obtener documentación sobre el proceso de intercambio de hardware, consulte sección 5.2.6 de la Guía de administración de software y sección 12.2 de la Guía de mantenimiento.

No se recomienda utilizar un intercambio de hardware para actualizar BroadWorks al mismo tiempo o para realizar un intercambio de hardware o una actualización de Linux in situ y una actualización de BroadWorks en la misma ventana de mantenimiento. Los servidores con una base de datos deben pasar por el proceso de actualización; una base de datos de una versión de BroadWorks no se puede importar a otra versión de BroadWorks.

Limitaciones de actualización y notas específicas del servidor

Actualización del servidor Profile y la plataforma de servicio ampliado a la plataforma de suministro de aplicaciones

A partir de la versión 24.0, Profile Server (PS) y Xtended Service Platform (XSP) se convierten en el mismo tipo de servidor, conocido como Application Delivery Platform (ADP). Los servidores PS y XSP se actualizan in situ y se convierten en el tipo de servidor ADP después de la actualización. Al actualizar desde la versión 23.0, el PS y el XSP solo pueden actualizar hasta la versión 2024.07 de ADP. Después, el ADP debe actualizarse de nuevo para obtener la última versión.

Se necesitan una licencia de ADP y una versión actualizada de las aplicaciones implementadas. Las actualizaciones de XSP deben realizarse después de actualizar los servidores de aplicaciones (AS). Existen versiones de RI de PS y XSP en el portal de descargas, pero estas son solo para sistemas que implementan el servidor Execution Server (XS) en lugar del AS. Todos los sistemas con un AS deben actualizar PS y XSP a ADP.

Las aplicaciones Cisco BroadWorks y las aplicaciones web se deben actualizar manualmente en XSP, PS y ADP.

Servidor de base de datos

El servidor de base de datos (DBS) debe actualizarse en varios saltos para poder actualizar a la última versión de RI debido a las restricciones del sistema operativo. DBS 22.0 es compatible con Linux 5 y 6. Si ejecuta Linux 5, DBS no puede actualizar más allá de 22.0. Las versiones de RI de DBS no son compatibles con Linux 5. Si ejecuta Linux 6, DBS puede actualizar a 2020.08. DBS debe entonces cambiar el hardware a Linux 7, donde puede actualizar de nuevo. Al actualizar DBS y PS, las versiones de DBManagement y DBSObserver deben coincidir con la versión de DBS para asegurarse de que la versión de Oracle subyacente coincide en cuanto a compatibilidad.

Versión DBS y Alineación de Versión Oracle

22.0: Oracle 11
2018.11 a 2020.08: Oracle 12
Más de 2020.11: Oracle 19

Omitiendo la actualización de DBS

Existe la opción de omitir la actualización de DBS e importar la BD desde la versión 2.0 directamente a DBS 2022.03+. Sin embargo, este proceso no es rápido y se debe probar en el laboratorio para verificar el tiempo esperado para la producción. Consulte las Notas de la versión de DBS sección 6, BWKS-3069, y la Guía de configuración de DBS sección 6.5.7.3.

Registros de llamadas mejorados

Los registros de llamadas mejorados (ECL) finalizan su vida útil en el DBS después de DBS 2020.08. La base de datos de ECL debe migrarse a un servidor de base de datos de red (NDS) para poder seguir utilizándola, la migración no es automática. Refiérase a la Guía de la Solución de Registros de Llamadas Mejorados y a la Descripción de la Función de Registros de Llamadas Mejorados de NDS para obtener más información. Consulte la Guía de Configuración del Servidor de Base de Datos de Red para configurar un NDS y la Descripción de la Función ECL Migration From DBS to NDS para el procedimiento de migración. La migración se debe realizar antes de la actualización.

Servidores de colaboración

El EoM para Messaging Server (UMS), Sharing Server (USS), Video Server (UVS), WebRTC Server (WRS), Business Communicator Client (BTBC) y Connect Client fue el 31 de enero de 2022. La última versión de RI disponible para el UMS es 22.0 y para el USS, UVS y WRS la última disponible es 202.01.

El AS en 24.0 es compatible con el UMS en 22.0 y 21.sp1. No se recomienda actualizar el UMS a 22.0. UMS en 22.0 utiliza MariaDB en lugar de Oracle TimesTen, por lo que se necesitan pasos adicionales para realizar la actualización, tiene un método de procedimiento (MoP) independiente y requiere un nodo adicional para redundancia. Consulte MOP de actualización de UMS y Notificación de campo sobre MariaDB 10.1 End of Life.

Se recomienda sustituir los servicios de colaboración por WebEx para BroadWorks. Consulte la Guía de soluciones de WebEx para BroadWorks.

Revisar documentación

Se deben revisar las notas de la versión para la versión de destino y cualquier versión entre la versión de destino y la de origen. Si la versión de destino es 24.0, se deben revisar las notas de versión para 24.0 y 25.0.
Notas de la versión 24.0

Release Notes 25.0 y posteriores
Método de actualización del procedimiento
Consulte la Matriz de compatibilidad de software para ver las rutas de actualización admitidas oficialmente.

Requisitos de Licencia

Se necesita una nueva licencia para la versión de destino. Para solicitar una licencia, abra un ticket. Solicitar que las licencias PS y XSP se conviertan en licencias ADP; el ADP no acepta una licencia PS o XSP.

Mejores medidas

Notificar al soporte de BroadWorks antes de una actualización

Si realiza una actualización sin el apoyo del Equipo de Actualización, se recomienda notificar al Soporte de BroadWorks con unos días de anticipación con un ticket de gravedad 4 (s4). Si surge un problema durante el mantenimiento, eleve la gravedad del ticket a s1, abra un nuevo ticket s1 o llame a la línea de soporte para hablar con un ingeniero.

Planes de prueba

Un plan de pruebas es esencial para garantizar una actualización sin problemas. Se debe desarrollar y probar un plan de pruebas en un laboratorio antes de una actualización de producción. Ejecute el plan de prueba en el sistema antes de la actualización y registre los resultados. Esto garantiza que el sistema esté en buen estado, verifica que todos los usuarios y cuentas de prueba estén correctamente configurados y en funcionamiento, proporciona una oportunidad para detectar posibles lagunas en el plan de prueba y proporciona una estimación del tiempo que se espera que tarden las pruebas.

Cada servidor debe probarse después de haber sido actualizado para asegurarse de que funciona según lo esperado antes de pasar a actualizar al siguiente servidor en la secuencia.

Parcheado

Parche la versión de origen a seis meses o menos del último nivel de parche antes de actualizar.

Script de comprobación previa a la instalación

La secuencia de comandos de comprobación previa a la instalación se debe ejecutar en cada servidor, laboratorio y producción, y se debe corregir cualquier advertencia o error antes de la actualización.

Actualización de laboratorio

Siempre se recomienda probar la actualización, el plan de pruebas y la versión de destino con herramientas, aplicaciones o clientes de terceros en un entorno de laboratorio que replique el entorno de producción. El laboratorio se puede reducir, pero debe tener los mismos tipos de servidor, versión de software, versión de SO, dispositivos de acceso, control de límite de sesión (SBC), etc. Considere la actualización de laboratorio como un simulacro para la actualización del entorno de producción. Utilice el último nivel de revisión de la versión de destino al actualizar el laboratorio. Mantenga el tiempo entre la actualización del laboratorio y la producción en tres meses o menos.

Secuencia de programación y actualización

Se espera que las actualizaciones se realicen en varios períodos de mantenimiento distribuidos a lo largo de varias noches y se realizan en el pedido de instalación y actualización, como se describe en la sección 4.2 de la Guía de administración de software. Realice siempre las actualizaciones durante una ventana de mantenimiento predeterminada (durante una hora no ocupada). Actualice siempre un nodo a la vez y asegúrese de que uno o más nodos de un cluster están inactivos en un momento dado. La longitud de la ventana de mantenimiento (MW), el número de servidores que se van a actualizar, el tipo de servidor y el tiempo que se espera que tarde la prueba en determinar el número de ventanas de mantenimiento necesarias. Todos los servidores de un clúster deben actualizarse en el mismo MW. Deje tiempo disponible en el MW programado para la resolución de problemas y/o la reversión si es necesario.

Fallos de actualización

Si se detecta un problema durante la prueba posterior a la actualización o se produce un error en una actualización, recopile los registros antes de volver a la versión de origen o restaurar el servidor. Haga una copia de seguridad de todo el directorio de registros para asegurarse de que se mantienen todos los registros potencialmente útiles. Inmediatamente abra un ticket y llame a Soporte para obtener asistencia mientras está en el MW.

Historial de revisiones

Revisión	Fecha de publicación	Comentarios
1.0	06-Aug-2026	Versión inicial