Introducción
Este documento describe consideraciones y requisitos para ayudar en la planificación de una actualización desde la versión de origen de BroadWorks 24.0.
Overview
BroadWorks versión 24.0 admite actualizaciones a las versiones 25.0 y 26.0. La versión 24.0 de mantenimiento (EoM) se ha anunciado para finales de julio de 2026. Todos los servidores 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") hasta 2028.07.
Liberar versiones independientes
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.
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
R24: 6,5+, 7, 8
R25: 6,5+, 7, 8
Versiones de Linux compatibles independientes de versiones
+ 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
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.
Se necesitan una licencia de ADP y una versión actualizada de las aplicaciones implementadas. Las actualizaciones de XSP deben realizarse después de que se actualicen los 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.
Al actualizar los servidores ADP a 2025.07 o posterior, se produce un cambio en la versión Java JRE que complica la actualización si las aplicaciones Release Independent y Release Anchored se combinan en el servidor ADP. Consulte este documento de ayuda para obtener más información.
DBS
El DBS es el fin de la vida útil. 2024.09 es la versión final de las aplicaciones DBS y ECCR. ECCR debe ser sustituido por CCER. Para obtener más información sobre las opciones para la DBS, consulte este documento. Una vez que ECCR ya no esté en uso, la DBS debe ser retirada del servicio.
Registros de llamadas mejorados (ECL)
ECL es el final del ciclo de vida de DBS después de DBS 2020.08. La base de datos 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.
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 25.0
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. 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
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.
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 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 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.
Comentarios