Actualización de BroadWorks Release 2.0

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 2.0.

Overview

BroadWorks Release 2.0 admite actualizaciones a las versiones 23.0 y 24.0. La versión 2.0 es End of Maintenance (EoM), la 23.0 es EoM a finales de julio de 2024, y se espera que la 24.0 EoM sea a finales de julio de 2026. La ruta recomendada es actualizar a 24.0.

Liberar versiones independientes

A partir de la versión 23.0, el MS es independiente de la versión (RI) y a partir de la versión 24.0 todos los servidores excepto el AS independiente 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 solució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 4 dígitos
• mm es el mes de 2 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.
La compatibilidad con Linux 7 finaliza 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

R22 5,9+, 6,5+, 7
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.09: 7, 8, 9

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

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

Actualizaciones de SO

BroadWorks no soporta una actualización in situ entre las principales versiones de Linux. 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. Consulte la sección 5.2.6 de la Guía de administración de software y la 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 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 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 de Cisco BroadWorks y las aplicaciones web deben actualizarse manualmente en XSP, PS y ADP.

Servidor de base de datos

El servidor de base de datos (DBS) debe actualizarse en varios saltos para actualizar a la última versión de RI debido a las restricciones del sistema operativo. 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 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 debe ser probado 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.

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

Sistema de administración de elementos y servidor de licencias virtual

El sistema de gestión de elementos (EMS) y el servidor de licencias virtuales (VLS) han alcanzado el fin de su vida útil (EoL) en el segundo trimestre de 2018 y su funcionalidad ha sido sustituida por el administrador de funciones de red (NFM). No hay ninguna ruta de actualización a NFM ni retirada de servicio de ningún nodo EMS o VLS.

Administrador de funciones de red

Si se implementa la supervisión de red, se requiere un paso adicional; de la actualización 22.0 a la 2020.11 y, a continuación, a la 2022.08+.

Actualización a 23.0 en Linux 6

Si se actualiza un servidor de aplicaciones a la versión 23.0 en Linux 6, no se deben aplicar varios parches o la actualización falla al aplicar los parches. "Rel_22.0/v1.450/". No aplique estos parches al AS al actualizar a 23.0: AP.platform.23.0.1075.ap38541, AP.as.23.0.1075.ap385380, AP.as.23.0.1075.ap385413 y AP.as.23.0.1075.ap385453.

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 22.0, 23.0 y 24.0.
Notas de la versión 23.0

Notas de la versión 24.0
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. Para las actualizaciones a la versión 24.0, solicite que las licencias PS y XSP se conviertan en licencias ADP; el ADP no acepta una licencia PS o XSP.

Alineación de RI con la versión principal

2018.xx = R22
2019.01 to 2020.06 = R23
2020.07 to 2022.07 = R24

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, aumente 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 de la secuencia.

Parcheado

Parche la versión de origen a 6 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 debe ejecutarse en cada servidor, laboratorio y producción, así como en cualquier advertencia o error que se solucione 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 actualizarán, el tipo de servidor y el tiempo que se espera que tarde la prueba en determinar cuántos períodos de mantenimiento son necesarios. 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. Realice una copia de seguridad del directorio de registros completo 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.