本文档介绍从源版本20.0规划Cisco BroadWorks系统升级的注意事项和要求。
所有服务器均升级到最新版本的独立版本(请参阅标题为“Supported Upgrade Maps”的Software Compatibility Matrix 部分)。
验证目标版本是否支持源操作系统(OS)。
支持的操作系统是Red Hat Enterprise Linux、Oracle Linux和CentOS 7。不支持CentOS 8、CentOS Stream、Rocky Linux和Alma Linux。
Linux 7支持于2024年6月20日结束,2024.07。
从2024.04+开始支持Linux 9。
2020.07+:6.5+、7、8
2023.05+:7、8
2023.10+:7、8、9(直到2024.04应用服务器(AS)才支持Linux 9)
2024.04+:7、8 和 9
2024.07+:8、9
2020.11 到 2022.06:仅7.5+
2022.07+:7.5+、8.5+
2024.07+:8.5+
2024.09:最终版本/寿命终止
BroadWorks以前不支持主要Linux版本之间的就地升级。过去,建议执行硬件交换,在目标Linux版本上构建新服务器,并将现有服务器迁移到新服务器。从版本2023.12开始,支持从Linux 7到8和8到9就地升级Linux。要执行就地升级Linux,服务器必须首先升级到2023.12或更高版本。
有关本地Linux升级的文档,请参阅《软件管理指南》第9部分。有关硬件交换过程的文档,请参阅 《软件管理指南》第5.2.6节和《维护指南》第12.2节。
建议不要使用硬件交换来同时升级BroadWorks,也不要在同一维护窗口中执行硬件交换或就地升级Linux和BroadWorks升级。带有数据库的服务器必须完成升级过程;一个数据库不能从一个BroadWorks版本导入到另一个BroadWorks版本中。
由于操作系统限制,DBS必须多次升级才能升级到最新的RI版本。DBS 22.0支持Linux 5和6。如果运行Linux 5,则DBS不能升级到22.0以上。发行独立版本的DBS不支持Linux 5。如果运行Linux 6,则DBS可以升级到2020.08。然后DBS必须硬件交换到Linux 7,以便再次升级。升级DBS和配置文件服务器(PS)时,DBManagement和DBSObserver的版本必须与DBS的版本匹配,以确保底层的Oracle版本匹配兼容性。
22.0:Oracle 11
2018.11 到 2020.08:Oracle 12
2020.11+:Oracle 19
有一个选项可以跳过DBS升级,并将数据库(DB)从22.0直接导入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。
24.0上的AS与22.0和21.sp1上的UMS兼容。建议不要将UMS升级到22.0。位于22.0的UMS使用MariaDB而非Oracle TimesTen,需要额外的升级步骤,具有单独的过程方法(MoP),并且需要额外的节点以实现冗余。请参阅UMS Upgrade MOP和有关MariaDB 10.1寿命终止的字段通知。
建议使用WebEx for BroadWorks替换协作服务。请参阅WebEx for BroadWorks解决方案指南。
必须审核目标版本以及目标版本和源版本之间的任何版本的版本说明。
26.0版本说明
过程升级方法(MOP)
有关官方支持的升级路径,请参阅软件兼容性列表。
目标版本需要新许可证。要请求许可证,请打开票证。
建议使用严重性4(s4)故障单提前几天通知BroadWorks支持。如果在维护期间出现问题,请将故障单的严重性提高到s1,打开新的s1故障单,或拨打支持热线与工程师通话。
测试计划对于确保顺利升级至关重要。在生产升级之前,必须制定测试计划并在实验室中对其进行测试。升级之前在系统上运行测试计划并记录结果。这可确保系统运行正常,验证所有测试用户和帐户是否正确配置且运行正常,提供弥补测试计划中潜在差距的机会,并提供预计测试所需时间的估计值。
每台服务器在升级后都必须进行测试,以确保在升级至序列中的下一台服务器之前能按预期运行。
必须在每台服务器、实验室和生产上运行安装前检查脚本,并且必须在升级之前解决任何警告或故障问题。
我们始终建议在复制生产环境的实验室环境中,使用任何第三方工具、应用程序或客户端来测试升级、测试计划和目标版本。本实验可以缩小规模,但应具有相同的服务器类型、软件版本、操作系统版本、接入设备、会话边界控制(SBC)等。将实验室升级视为生产环境升级的试运行。升级实验时,请使用最新的目标版本补丁级别。将实验室升级和生产升级之间的时间保持为3个月或更短。
升级预计会在多个维护时段进行,时间跨几个晚上,按照《软件管理指南》第4.2节中所述的“安装和升级订单”执行。始终在预定的维护时段内(非繁忙时段)执行升级。始终每次升级一个节点,并确保在任何给定时间群集的一个或多个节点出现故障。维护窗口(MW)的长度、要升级的服务器数量、服务器类型以及测试所需的时间决定了需要多少个维护窗口。集群中的所有服务器必须在同一MW中升级。根据需要保留计划MW中用于故障排除和/或回滚的时间。
如果在升级后测试期间发现问题或升级失败,请在恢复到源版本或恢复服务器之前收集日志。备份整个日志目录,以确保保留所有可能有用的日志。立即打开票证,并在仍处于MW状态时致电支持部门寻求帮助。
| 版本 | 发布日期 | 备注 |
|---|---|---|
1.0 |
19-May-2026
|
初始版本 |