はじめに
このドキュメントでは、BroadWorks 24.0のソースリリースからのアップグレードを計画する際に役立つ考慮事項と要件について説明します。
概要
BroadWorksリリース24.0では、リリース25.0および26.0へのアップグレードがサポートされています。リリース24.0のメンテナンス終了(EoM)が2026年7月末に発表されました。2028.07までに、すべてのサーバを最新のリリース非依存バージョン(「ソフトウェア互換性マトリクス」の「サポートされるアップグレードマップ」セクションを参照)にアップグレードしてください。
独立したバージョンのリリース
25.0では、すべてのサーバはリリースに依存しません。すべての新機能、バグ、およびセキュリティ修正は、新しいバージョンで提供されます。パッチは使用できません。修正を取得するには、サーバを別のバージョンにアップグレードする必要があります。緊急の修正が必要な場合は、毎月（毎月のパッチバンドルの代わりに）またはそれ以上の頻度で各サーバの新しいバージョンがリリースされます。
オペレーティングシステム要件
ソースのオペレーティングシステム(OS)がターゲットリリースでサポートされていることを確認します。
サポートされている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 9のサポートは2023.09以降で利用可能です。
メジャーリリースサポートされるLinuxバージョン
R24:6.5以降、7、8
R25:6.5以降、7、8
独立したサポート対象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にインポートすることはできません。
アップグレードの制限およびサーバ固有の注意事項
プロファイルサーバと拡張サービスプラットフォームのアプリケーション配信プラットフォームへのアップグレード
リリース24.0以降、プロファイルサーバ(PS)と拡張サービスプラットフォーム(XSP)は同じサーバタイプになり、アプリケーション配信プラットフォーム(ADP)と呼ばれます。 PSサーバとXSPサーバはアップグレードが行われ、アップグレード後にADPサーバタイプになります。
導入されたアプリケーションのADPライセンスと更新バージョンが必要です。XSPのアップグレードは、ASのアップグレード後に行う必要があります。ダウンロードポータルにはPSおよびXSPのRIバージョンがありますが、これらはASの代わりに実行サーバ(XS)サーバを導入するシステム専用です。ASを使用するすべてのシステムでは、PSおよびXSPをADPにアップグレードする必要があります。
Cisco BroadWorksアプリケーションおよびWebアプリケーションは、XSP、PS、およびADPで手動でアップグレードする必要があります。
ADPサーバを2025.07以降にアップグレードすると、Release IndependentとRelease AnchorのアプリケーションがADPサーバ上で混在している場合、Java JREバージョンに変更が加えられ、アップグレードが複雑になります。詳細については、このヘルプドキュメントを参照してください。
DBS
DBSはサポート終了です。2024.09は、DBSおよびECCRアプリケーションの最終リリースです。ECCRはCCERに置き換える必要があります。DBSのオプションの詳細については、このドキュメントを参照してください。 ECCRが使用されなくなったら、DBSを廃止する必要があります。
拡張コールログ(ECL)
DBS 2020.08以降のDBSでは、ECLのサポートは終了しています。ECLデータベースを継続的に使用するには、ネットワークデータベースサーバ(NDS)に移行する必要があります。移行は自動的には行われません。詳細については、『Enhanced Call Logsソリューションガイド』および『NDS Enhanced Call Logs Feature Description』を参照してください。移行手順については、『ネットワークデータベースサーバ設定ガイド』および『DBSからNDSへのECL移行の機能説明』を参照してください。アップグレードの前に移行を実行する必要があります。
ドキュメントの確認
ターゲットリリースのリリースノート、およびターゲットリリースとソースリリースの間のすべてのリリースを確認する必要があります。
25.0リリースノート
26.0リリースノート
アップグレード手順説明書(MoP)
正式にサポートされているアップグレードパスについては、『ソフトウェア互換性マトリクス』を参照してください。
ライセンス要件
ターゲットリリースには新しいライセンスが必要です。ライセンスを要求するには、チケットを開きます。PSおよびXSPライセンスをADPライセンスに変換するように要求します。ADPはPSまたはXSPライセンスを受け入れません。
ベスト プラクティス
アップグレードの前にBroadWorksサポートに通知
BroadWorks Supportに対し、数日前に重大度4(s4)のチケットを通知することを推奨します。メンテナンス中に問題が発生した場合は、チケットの重大度をs1に上げるか、新しいs1チケットを開くか、サポートラインに電話してエンジニアと話します。
テスト計画
アップグレードを円滑に行うには、テスト計画が不可欠です。テスト計画は、実稼働アップグレードの前にラボで開発およびテストする必要があります。アップグレードの前にシステムでテスト計画を実行し、結果を記録します。これにより、システムの健全性が確保され、すべてのテストユーザおよびアカウントが正しく設定されて機能していることが検証されます。また、テスト計画に明らかなギャップを見つける機会が提供され、テストにかかる時間の見積もりが提供されます。
アップグレードが完了した各サーバをテストして、正常に機能していることを確認してから、次のサーバにアップグレードする必要があります。
パッチ
アップグレードを行う前に、ソースリリースに最新のパッチレベルの6か月以内のパッチを適用します。
インストール前のチェックスクリプト
インストール前のチェックスクリプトは、すべてのサーバ、ラボ、および実稼働環境で実行する必要があります。また、警告や障害があれば、アップグレード前に対処する必要があります。
ラボでのアップグレード
実稼働環境を複製するラボ環境で、サードパーティ製のツール、アプリケーション、またはクライアントを使用して、アップグレード、テスト計画、およびターゲットリリースをテストすることを常に推奨します。ラボはスケールダウンできますが、サーバタイプ、ソフトウェアバージョン、OSバージョン、アクセスデバイス、セッションボーダーコントロール(SBC)などが同じである必要があります。ラボでのアップグレードは、実稼働環境のアップグレードの場合は予行演習として扱ってください。ラボをアップグレードするときは、最新のターゲットリリースパッチレベルを使用します。ラボ環境から実稼働環境へのアップグレードまでの期間を3か月以下に抑えます。
スケジューリングとアップグレードの順序
アップグレードは、複数の夜間にまたがる複数のメンテナンス時間帯に行うことが想定され、『ソフトウェア管理ガイド』のセクション4.2に記載されているように、インストールおよびアップグレード順序で実行されます。アップグレードは必ず、事前に決められたメンテナンス時間帯（最頻時ではない時間帯）に実行してください。 常に1ノードずつアップグレードし、常にクラスタの1つ以上のノードがダウンしていることを確認してください。メンテナンスウィンドウ(MW)の長さ、アップグレードするサーバの数、サーバタイプ、およびテストの予想所要時間によって、必要なメンテナンスウィンドウの数が決まります。クラスタ内のすべてのサーバは、同じMWでアップグレードする必要があります。必要に応じて、トラブルシューティングやロールバックのために、スケジュールされたMWで時間を空けておきます。
アップグレードの失敗
アップグレード後のテスト中に問題が検出された場合、またはアップグレードが失敗した場合は、ログを収集してからソースリリースに戻すか、サーバを復元します。ログディレクトリ全体をバックアップして、有用な可能性があるすべてのログを確実に保持します。直ちにチケットを開き、MWにいる間にサポートを依頼してください。
フィードバック