简介
本文档介绍帮助规划从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是两位数的月份
- 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，则需要执行恢复。回滚会将服务器版本改回源版本，并回滚对数据库的所有更改，同时保留所有添加的内容。还原操作会将服务器版本改回源版本，并导入升级前准备的数据库备份，还原操作会丢失升级后添加至DB的所有数据。解决方案是先将NS升级到23.0 ，然后升级到所需的RI版本。如果不需要双重升级，则在需要回滚时，应急方案是恢复NS，然后通过维护指南中的网络服务器和应用程序服务器同步过程实现NS数据库与AS数据库的同步。
Profile Server和扩展服务平台升级到应用交付平台
从版本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可用的最新RI版本是2022.01。
AS在24.0与UMS在21.sp1兼容。不建议将UMS升级到22.0。位于22.0的UMS使用MariaDB而不是Oracle TimesTen，需要额外的升级步骤，具有单独的过程方法(MOP)，并且需要额外的节点以实现冗余。请参阅UMS升级MOP和有关MariaDB 10.1生命周期终止的字段通知。
建议用WebEx for BroadWorks取代协作服务。请参阅用于BroadWorks解决方案指南的WebEx。
元件管理系统和虚拟许可服务器
截至2018年第二季度，元素管理系统(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个月或更短时间。
预安装Check脚本
必须在每台服务器、实验室和生产上运行安装前检查脚本，并在升级前解决任何警告或故障。
实验室升级
始终建议使用复制生产环境的实验室环境中的任何第三方工具、应用程序或客户端来测试升级、测试计划和目标版本。本实验可以缩小规模，但应具有相同的服务器类型、软件版本、操作系统版本、访问设备、会话边界控制(SBC)等。将实验室升级视为生产环境升级的试运行。升级实验时，请使用最新的目标版本修补程序级别。将实验室升级和生产升级之间的时间保持为3个月或更短。
计划和升级顺序
升级预计跨多个维护时段，时间跨多个晚上，按照软件管理指南第4.2部分中记录的安装和升级顺序执行。在预定的维护时段内（在非繁忙时段）始终执行升级。 每次始终升级一个节点，并确保群集的一个或多个节点在任何给定时间关闭。维护时段长度(MW)、要升级的服务器数量、服务器类型以及测试所需时间决定了需要多少个维护时段。群集中的所有服务器必须在同一个MW中升级。根据需要将时间保留在计划的MW中用于故障排除和/或回滚。
升级失败
如果在升级后测试期间发现问题或升级失败，请在恢复至源版本或恢复服务器之前收集日志。备份整个日志目录，以确保保留所有可能有用的日志。立即打开票证，并在仍在主站时致电支持部门寻求帮助。
反馈