Guía para actualizar desde BroadWorks 25.0

Introducción

Este documento describe las consideraciones y los requisitos para planificar una actualización del sistema Cisco BroadWorks desde la versión de origen 20.0.

Overview

Todos los servidores actualizan a la última versión independiente disponible (consulte la sección Matriz de compatibilidad de software titulada "Mapas de actualización admitidos").

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 7 finalizó el 20 de junio de 2024 con 2024.07.

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

Versiones de Linux compatibles

+ de 2020.07: 6,5+, 7, 8
+ de 2023.05: 7, 8

+ de 2023.10: 7, 8, 9 (Linux 9 no es compatible con los servidores de aplicaciones (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

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 recomendaba 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

DBS

El DBS debe actualizarse en saltos múltiples para actualizar a la última versión de RI debido a las restricciones del SO. DBS 22.0 admite Linux 5 y 6. Si ejecuta Linux 5, DBS no puede actualizar más allá de 22.0. Las versiones independientes de la versión de DBS no admiten Linux 5. Si ejecuta Linux 6, DBS puede actualizar a 2020.08. DBS debe cambiar el hardware a Linux 7, donde puede actualizar de nuevo. Al actualizar DBS y Profile Server (PS), las versiones de DBManagement y DBSObserver deben coincidir con la versión de DBS para garantizar la compatibilidad de la versión de Oracle subyacente.

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 base de datos (DB) desde la versión 2.0 directamente en DBS 2022.03+. Sin embargo, este proceso no es rápido y debe ser probado en el laboratorio para verificar el tiempo esperado para la producción. Consulte la sección Notas de la versión de DBS 6, BWKS-3069, y la sección Guía de configuración de DBS 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 final del mantenimiento (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.

Notas de la versión 26.0
Método de actualización del procedimiento (MOP)
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.

Mejores medidas

Notificar al soporte de BroadWorks antes de una actualización

Se recomienda notificar a BroadWorks Support con unos días de antelació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 realizar 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.

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 cualquier advertencia o error debe solucionarse 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 de laboratorio y producción en 3 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 el 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	19-May-2026	Versión inicial