BroadWorks 25.0からのアップグレードガイド

はじめに

このドキュメントでは、ソースリリース20.0からのCisco BroadWorksシステムアップグレードを計画する際の考慮事項と要件について説明します。

概要

すべてのサーバが、入手可能な最新リリースの独立バージョンにアップグレードされます(「サポートされるアップグレードマップ」の「ソフトウェア互換性マトリクス」セクションを参照)。

オペレーティングシステム要件

ソースのオペレーティングシステム(OS)がターゲットリリースでサポートされていることを確認します。

サポートされているオペレーティングシステムは、Red Hat Enterprise Linux、Oracle Linux、およびCentOS 7です。CentOS 8、CentOS Stream、Rocky Linux、およびAlma Linuxはサポートされていません。

Linux 7のサポートは2024年6月20日に2024.07で終了しました。

Linux 9のサポートは2024.04以降で利用可能です。

サポートされるLinuxバージョン

2020.07以降：6.5以降、7、8
2023.05以降：7、8

2023.10+:7、8、9(Linux 9は2024.04までApplication Servers(AS)ではサポートされません)

2024.04以降：7、8、9
2024.07以降：8、9

データベースサーバ(DBS)でサポートされるLinuxバージョン

2020.11 ～ 2022.06:7.5以上のみ
2022.07以降：7.5以降、8.5以降

2024.07以上：8.5以上

2024.09:最終リリース/サポート終了

OSのアップグレード

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

OSの制約により、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およびProfile Server(PS)をアップグレードする場合、基礎となるOracleバージョンの互換性を確保するために、DBManagementおよびDBSObserverのバージョンがDBSのバージョンと一致している必要があります。

DBSリリースとOracleリリースの連携

22.0:Oracle 11
2018.11 ～ 2020.08:Oracle 12
2020.11以降：Oracle 19

DBSアップグレードのスキップ

DBSのアップグレードをスキップして、データベース(DB)を22.0から直接DBS 2022.03+にインポートするオプションがあります。ただし、このプロセスは迅速ではなく、実稼働に期待されるタイミングを検証するためにラボでテストする必要があります。「DBSリリースノート」セクション6、BWKS-3069、および「DBS設定ガイド」セクション6.5.7.3を参照してください。

拡張コールログ

Enhanced Call Logs(ECL)は、DBS 2020.08以降のDBSではサポートが終了しています。ECLデータベースを継続的に使用するには、ネットワークデータベースサーバ(NDS)に移行する必要があります。移行は自動的には行われません。詳細については、『Enhanced Call Logsソリューションガイド』および『NDS Enhanced Call Logs Feature Description』を参照してください。移行手順については、『ネットワークデータベースサーバ設定ガイド』および『DBSからNDSへのECL移行の機能説明』を参照してください。アップグレードの前に移行を実行する必要があります。

Collaborateサーバ

Messaging Server(UMS)、Sharing Server(USS)、Video Server(UVS)、WebRTC Server(WRS)、Business Communicator Client(BTBC)、およびConnect Clientのメンテナンス終了(EoM)は、2022年1月31日でした。UMSで利用可能な最新のRIバージョンは22.0で、USS、UV、およびWRSで利用可能な最新バージョンは2022.01です。

24.0のASは、22.0および21.sp1のUMSと互換性があります。UMSを22.0にアップグレードすることはお勧めしません。22.0のUMSでは、アップグレードに追加の手順を必要とするOracle TimesTenの代わりにMariaDBが使用され、別のMethod of Procedure(MoP)があり、冗長性のために追加のノードが必要です。「UMSアップグレードMOP」および「MariaDB 10.1サポート終了に関するフィールド通知」を参照してください。

CollaborateサービスをWebEx for BroadWorksに置き換えることをお勧めします。『WebEx for BroadWorks Solutions Guide』を参照してください。

ドキュメントの確認

ターゲットリリースのリリースノート、およびターゲットリリースとソースリリースの間のすべてのリリースを確認する必要があります。

26.0リリースノート
アップグレード手順説明書(MOP)
正式にサポートされているアップグレードパスについては、『ソフトウェア互換性マトリクス』を参照してください。

ライセンス要件

ターゲットリリースには新しいライセンスが必要です。 ライセンスを要求するには、チケットを開きます。

ベスト プラクティス

アップグレードの前にBroadWorksサポートに通知

BroadWorks Supportに対し、数日前に重大度4(s4)のチケットを通知することを推奨します。メンテナンス中に問題が発生した場合は、チケットの重大度をs1に上げるか、新しいs1チケットを開くか、サポートラインに電話してエンジニアと話します。

テスト計画

アップグレードを円滑に行うには、テスト計画が不可欠です。テスト計画は、実稼働アップグレードの前にラボで開発およびテストする必要があります。アップグレードの前にシステムでテスト計画を実行し、結果を記録します。これにより、システムの健全性が確保され、すべてのテストユーザおよびアカウントが正しく設定されて機能していることが検証されます。また、テスト計画に明らかなギャップを見つける機会が提供され、テストにかかる時間の見積もりが提供されます。

アップグレードが完了した各サーバをテストして、正常に機能していることを確認してから、次のサーバにアップグレードする必要があります。

インストール前のチェックスクリプト

インストール前のチェックスクリプトは、すべてのサーバ、ラボ、および実稼働環境で実行する必要があります。また、警告や障害があれば、アップグレード前に対処する必要があります。

ラボでのアップグレード

実稼働環境を複製するラボ環境で、サードパーティ製のツール、アプリケーション、またはクライアントを使用して、アップグレード、テスト計画、およびターゲットリリースをテストすることを常に推奨します。ラボはスケールダウンできますが、サーバタイプ、ソフトウェアバージョン、OSバージョン、アクセスデバイス、セッションボーダーコントロール(SBC)などが同じである必要があります。ラボでのアップグレードは、実稼働環境のアップグレードの場合は予行演習として扱ってください。ラボをアップグレードするときは、最新のターゲットリリースパッチレベルを使用します。ラボと実稼働環境のアップグレードの間隔を3か月以下に抑えます。

スケジューリングとアップグレードの順序

アップグレードは、複数の夜間にまたがる複数のメンテナンス時間帯に行うことが想定され、『ソフトウェア管理ガイド』のセクション4.2に記載されているように、インストールおよびアップグレード順序で実行されます。アップグレードは必ず、事前に決められたメンテナンス時間帯（最頻時ではない時間帯）に実行してください。 常に1ノードずつアップグレードし、常にクラスタの1つ以上のノードがダウンしていることを確認してください。メンテナンスウィンドウ(MW)の長さ、アップグレードするサーバの数、サーバタイプ、およびテストの予想所要時間によって、必要なメンテナンスウィンドウの数が決まります。クラスタ内のすべてのサーバは、同じMWでアップグレードする必要があります。必要に応じて、トラブルシューティングやロールバックに使用できる時間を、スケジュールされたメガワットに残しておきます。

アップグレードの失敗

アップグレード後のテスト中に問題が検出された場合、またはアップグレードが失敗した場合は、ログを収集してからソースリリースに戻すか、サーバを復元します。ログディレクトリ全体をバックアップして、有用な可能性があるすべてのログを確実に保持します。直ちにチケットを開き、MWにいる間にサポートを依頼してください。

更新履歴

改定	発行日	コメント
1.0	19-May-2026	初版