简介
本文档介绍帮助规划从BroadWorks 21.sp1的源版本升级的注意事项和要求。
概述
BroadWorks 21.sp1支持升级到22.0、23.0和24.0版。版本22.0为维护终止(EoM),23.0在2024年7月底为EoM。升级到24.0是推荐的路径。
独立版本发布
从版本23.0开始，MS是独立版本(RI),24.0是除AS独立版本之外的所有服务器。所有新功能、漏洞和安全修复都以新版本提供。修补程序不可用，相反，需要将服务器从一个版本升级到另一个版本才能获得修补程序。每个月都会发布每台服务器的新版本（而不是每月补丁包），如果需要紧急修复则更频繁。
RI版本使用的格式与标准Rel_24.0_1.944格式不同。此RI格式为Server_Rel_yyyy.mm_x.xxx:
- 例如，服务器为MS
- yyyy是4位数的年份
- mm是2位数的月份
- x.xxx是该月的增量版本
MS_Rel_2022.11_1.273.Linux-x86_64.bin是2022年11月发布的MS的一个版本。如果不指特定服务器类型或增量版本，通常缩写为2022.11。
操作系统要求
验证目标版本是否支持源操作系统(OS)。
支持的操作系统是Red Hat Enterprise Linux、Oracle Linux和CentOS 7。不支持CentOS 8、CentOS Stream、Rocky Linux和Alma Linux。
Linux 6支持于2023年4月30日终止，2023.05。
Linux 7支持将于2024年6月20日与2024.07一起终止。
支持的主要版本Linux版本
R21:5、6和7(需379473ap)
R22:5.9+、6.5+、7
R23:5.9+、6.5+、7和8.x(需385046ap)
R24:6.5+、7、8
独立于发行版受支持的Linux版本
2018.01+:5.9+、6.5+、7
2019.10+:6.5+、7
2020.07+:6.5+、7、8
2023.05+:7、8
2023.09+:7、8、9
数据库服务器(DBS)支持的Linux版本
DBS R21:5、6
DBS R22:5.9+、6.5+
DBS 2018.11至2020.08:6.5+、7
DBS 2020.11至2022.06：仅7.5+
DBS 2022.07+:7.5+、8.5+
操作系统升级
BroadWorks不支持在主要Linux版本之间进行就地升级。建议执行硬件交换，在目标Linux版本上构建新服务器，并将现有服务器迁移到新服务器。请参阅《软件管理指南》的5.2.6节和《维护指南》的12.2节。
建议不要在同一维护窗口中同时使用硬件交换来升级BroadWorks或执行硬件交换和BroadWorks升级。带有数据库的服务器必须完成升级过程；不能将某个版本的BroadWorks中的数据库导入另一个版本的BroadWorks。
升级限制和特定于服务器的说明
网络服务器回滚
网络服务器(NS)可以从21.sp1升级到RI，但不支持回滚，如果需要返回到21.sp1，则需要执行恢复。回滚会将服务器版本改回源版本，并回滚对数据库的所有更改，同时保留任何添加的内容。还原操作将服务器版本改回源版本，并导入升级前准备的数据库备份，还原时升级丢失之后添加到数据库的所有数据。解决方案是先将NS升级到23.0，然后升级到所需的RI版本。如果不需要双重升级，如果需要回滚，一种解决方法是：恢复NS ，然后通过维护指南中的“网络服务器和应用程序服务器同步”过程运行，将NS数据库与AS数据库同步。
Profile Server和Extended Service Platform升级到应用交付平台
从版本24.0开始，配置文件服务器(PS)和扩展服务平台(XSP)成为相同的服务器类型，称为应用交付平台(ADP)。PS和XSP服务器升级到位，升级后成为ADP服务器类型。
从21.sp1中，PS和XSP可升级到的最新RI版本为2022.07。要升级到2022.08+，需要两步升级。需要ADP许可证和已部署应用的更新版本。XSP升级必须在升级应用服务器(AS)后进行。下载门户上有PS和XSP的RI版本，但这些版本仅适用于部署执行服务器(XS)代替AS的系统。所有带AS的系统必须将PS和XSP升级到ADP。
Cisco BroadWorks应用和Web应用需要在XSP、PS和ADP上手动升级。
数据库服务器
由于操作系统限制，数据库服务器(DBS)必须多次升级才能升级到最新的RI版本。DBS 21.sp1支持Linux 5和6。如果运行Linux 5,DBS只能升级到22.0。如果运行Linux 6,DBS可以升级到RI 2020.08。然后，DBS必须硬件交换到Linux 7，以便再次升级。升级DBS和PS时，DBManagement和DBSObserver的版本必须与DBS的版本匹配，以确保底层的Oracle版本匹配兼容性。
DBS发放和Oracle发放调整
21.sp1和22.0:Oracle 11
2018.11到2020.08:Oracle 12
2020.11+:Oracle 19
跳过DBS升级
有一个选项可以跳过DBS升级，并将数据库从21.sp1直接导入DBS 2022.03+。但是，此过程速度不快，应在实验室中进行测试，以验证预计的生产时间。请参阅DBS发行说明第6部分BWKS-3069和DBS配置指南第6.5.7.3部分。
增强的呼叫日志
增强型呼叫日志(ECL)在DBS 2020.08之后在DBS上终止。ECL数据库必须迁移到网络数据库服务器(NDS)才能继续使用，迁移不是自动的。有关详细信息，请参阅增强型呼叫日志解决方案指南和NDS增强型呼叫日志功能说明。有关迁移过程，请参阅网络数据库服务器配置指南以设置NDS和ECL从DBS迁移到NDS功能说明。升级前必须执行迁移。
协作服务器
消息传送服务器(UMS)、共享服务器(USS)、视频服务器(UVS)、WebRTC服务器(WRS)、Business Communicator客户端(BTBC)和连接客户端的维护结束(EoM)时间为2022年1月31日。UMS的最新RI版本是22.0，而USS、UVS和WRS的最新版本是2022.01。
AS在24.0与UMS在21.sp1兼容。建议不要将UMS升级到22.0。位于22.0的UMS使用MariaDB而非Oracle TimesTen，需要额外的升级步骤，具有单独的过程方法(MOP)，并且需要额外的节点以实现冗余。请参阅UMS Upgrade MOP和有关MariaDB 10.1寿命终止的字段通知。
建议使用WebEx for BroadWorks替换协作服务。请参阅WebEx for BroadWorks解决方案指南。
元件管理系统和虚拟许可服务器
自2018年第2季度起，元素管理系统(EMS)和虚拟许可服务器(VLS)为寿命终止(EoL)，其功能已由网络功能管理器(NFM)取代。没有到NFM的升级路径或任何EMS或VLS节点的停用。
网络功能管理器
NFM需要从21.sp1进行两阶段升级。它可以升级到2019.05，然后升级到2022.08+。如果部署了网络监控，还需要执行其他步骤：从21.sp1升级到2019.05，然后升级到2020.11，再升级到2022.08+。
在Linux 6上升级到23.0
如果在Linux 6上将应用服务器升级到23.0，则一定不能应用多个补丁，或者升级在打补丁“Rel_22.0/v1.450/
”时失败。升级到23.0时，请勿将这些修补程序应用于AS:AP.platform.23.0.1075.ap38541、AP.as.23.0.1075.ap385380、AP.as.23.0.1075.ap385413和AP.as.23.0.1075.ap385453。
评审文档
必须审核目标版本以及目标版本和源版本之间的任何版本的版本说明。如果目标版本是24.0，则必须查看22.0、23.0和24.0的版本说明。
22.0版本说明
23.0版本说明
24.0版本说明
过程升级方法
有关官方支持的升级路径，请参阅软件兼容性列表。
从版本22.0开始，EoM有多种功能。有关这些信息，请参阅维护结束时的产品删除功能说明。升级后不再提供这些功能。
许可证要求
目标版本需要新的许可证。要申请许可证，请打开票证。要升级到24.0，请将PS和XSP许可证转换为ADP许可证；ADP不接受PS或XSP许可证。
将RI与主版本保持一致
2017.xx = R22
2018.xx = R22
2019.01到2020.06 = R23
2020.07到2022.07 = R24
最佳实践
请求支持
BroadWorks升级团队提供直接升级支持。
根据维护和支持合同，BroadWorks升级团队每年一次为实验室和生产升级到当前的“支持中”版本提供支持。升级团队可提供升级准备支持和升级期间的实时支持，包括远程执行升级的思科工程师。升级团队的范围仅限于升级活动，不直接支持需要在升级前解决的问题（例如硬件或操作系统更新）或调试以前存在的问题，并且不提供除常规服务器运行状况检查之外的全面升级后测试。
通过客户团队联系BroadWorks升级团队，或发送电子邮件至bwupgrade@cisco.com。实时升级支持服务不能提前安排在短时间内提供。
升级前通知BroadWorks支持
如果没有升级团队的支持而执行升级，建议提前几天通知BroadWorks支持人员严重程度为4(s4)的故障单。如果在维护期间出现问题，请将故障单的严重性提高到s1，打开新的s1故障单或拨打支持热线与工程师通话。
测试计划
测试计划对于确保顺利升级至关重要。在生产升级之前，必须制定测试计划并在实验室中对其进行测试。升级之前在系统上运行测试计划并记录结果。这可确保系统运行正常，验证所有测试用户和帐户是否正确配置且运行正常，提供弥补测试计划中潜在差距的机会，并提供预计测试所需时间的估计值。
每台服务器在升级后都必须进行测试，以确保其能按预期运行，然后再继续升级至序列中的下一台服务器。
修补
在升级之前，将源版本修补到最新修补程序级别的6个月或更短时间。
安装前检查脚本
必须在每台服务器、实验室和生产上运行安装前检查脚本，且在升级前解决任何警告或故障。
实验室升级
我们始终建议在复制生产环境的实验室环境中，使用任何第三方工具、应用程序或客户端来测试升级、测试计划和目标版本。本实验可以缩小规模，但应具有相同的服务器类型、软件版本、操作系统版本、接入设备、会话边界控制(SBC)等。将实验室升级视为生产环境升级的试运行。升级实验时，请使用最新的目标版本补丁级别。将实验室升级和生产升级之间的时间保持为3个月或更短。
计划和升级顺序
升级预计会在多个维护时段进行，时间跨几个晚上，按照《软件管理指南》第4.2节中所述的“安装和升级订单”执行。在预定的维护时间段（非繁忙时间）内，始终执行升级。 每次始终升级一个节点，并确保群集的一个或多个节点在任何给定时间关闭。维护时段的长度(MW)、要升级的服务器数量、服务器类型以及测试所需的时间决定了需要多少个维护时段。集群中的所有服务器必须在同一MW中升级。根据需要保留计划MW中用于故障排除和/或回滚的时间。
升级失败
如果在升级后测试期间发现问题或升级失败，请在恢复到源版本或恢复服务器之前收集日志。备份整个日志目录，以确保保留所有可能有用的日志。立即打开票证，并在仍处于MW状态时致电支持部门寻求帮助。
反馈