Guía para actualizar desde BroadWorks 21.sp1

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

Overview

BroadWorks Release 21.sp1 soporta actualizaciones a las versiones 22.0, 23.0 y 24.0. La versión 2.0 es Fin de mantenimiento (EoM) y la 23.0 es EoM a finales de julio de 2024. 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.

Versiones principales de Linux compatibles

R21: 5, 6 y 7 (se requiere ap379473)
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

2018.01+: 5,9+, 6,5+, 7
2019.10+: 6,5+, 7
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 R21: 5, 6
DBS R22: +5,9, +6,5
DBS 2018.11 a 2020.08: 6,5+, 7
DBS 2020.11 a 2022.06: solo más de 7,5
DBS 2022.07+: 7.5+, 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

Reversión del servidor de red

El servidor de red (NS) puede actualizar de 21.sp1 a RI, pero no se admite la reversión; se requiere una reversión si es necesario volver a 21.sp1. Una reversión cambia la versión del servidor de nuevo a la versión de origen y revierte todos los cambios en la base de datos manteniendo el contenido agregado. Una reversión cambia la versión del servidor de nuevo a la versión de origen e importa la copia de seguridad de la base de datos tomada justo antes de la actualización, todos los datos agregados a la base de datos desde que se perdió la actualización en una reversión. La solución consiste en actualizar primero el NS a la versión 23.0 y, a continuación, actualizar a la versión RI deseada. Si no se desea una actualización doble, una solución alternativa, si se requiere la reversión, sería revertir el NS y luego ejecutar el procedimiento Network Server and Application Server Synchronization de la Guía de Mantenimiento para sincronizar la base de datos NS con la base de datos AS.

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.

Desde 21.sp1, la última versión de RI de ADP a la que los PS y XSP pueden actualizar es 202.07. Para actualizar a 2022.08+, se requiere una actualización de dos pasos. 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 21.sp1 soporta Linux 5 y 6. Si se ejecuta Linux 5, el DBS sólo puede actualizar a la versión 2.0. Si se ejecuta Linux 6, el DBS puede actualizarse a RI 2020.08. El DBS debe cambiar el hardware a Linux 7, donde podrá actualizarlo 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

21.sp1 y 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 de 21.sp1 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 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) son el fin del ciclo de vida de 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 un UMS en 21.sp1. No se recomienda actualizar el UMS a 2.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

El NFM requiere una actualización de dos etapas desde 21.sp1. Se puede actualizar a 2019.05, luego a 2022.08+. Si se implementa la supervisión de red, se requiere un paso adicional: de la actualización de 21.sp1 a 2019.05, luego a 2020.11 y, a continuación, a 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 el parche "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 2.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.
Hay varias funciones que son EoM a partir de la versión 2.0. Estos se documentan en la Descripción de la función de eliminación del producto al final del mantenimiento. Estas funciones ya no están disponibles después de la actualización.

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

2017.xx = R22
2018.xx = R22
De 2019,01 a 2020,06 = R23
De 2020,07 a 2022,07 = R24

Mejores medidas

Solicitar asistencia

El equipo de actualización de BroadWorks proporciona asistencia directa para la actualización.

El equipo de actualización de BroadWorks proporciona asistencia para actualizaciones a una versión actual de "asistencia", para laboratorio y producción, una vez al año según el contrato de mantenimiento y asistencia. El equipo de actualización puede proporcionar asistencia para prepararse para una actualización y asistencia en tiempo real durante la misma, que puede incluir ingenieros de Cisco que realicen la actualización de forma remota. El ámbito del equipo de actualización se limita únicamente a la actividad de actualización y no proporciona soporte directo para los problemas que deben resolverse antes de la actualización, como las actualizaciones de hardware o del sistema operativo, o la depuración de problemas preexistentes, y no proporciona pruebas completas posteriores a la actualización más allá de las comprobaciones generales del estado del servidor.

Póngase en contacto con el equipo de actualización de BroadWorks, a través del equipo de cuentas, o envíe un correo electrónico a bwupgrade@cisco.com. La disponibilidad para la asistencia de actualización en tiempo real no está disponible con un aviso previo breve o programado con antelación.

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 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 un período de mantenimiento predeterminado (durante una hora no ocupada). Actualice siempre un nodo cada vez y asegúrese de que uno o más nodos de un clúster 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.