はじめに
このドキュメントでは、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(ap379473が必要)
R22:5.9以上、6.5以上、7
R23:5.9以降、6.5以降、7および8.x(ap385046が必要)
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
Database Server(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以降
OSのアップグレード
BroadWorksは、主要なLinuxバージョン間のインプレースアップグレードをサポートしていません。ハードウェア交換を実行し、対象のLinuxバージョンに新しいサーバを構築し、既存のサーバを新しいサーバに移行することをお勧めします。『ソフトウェア管理ガイド』のセクション5.2.6と『メンテナンスガイド』のセクション12.2を参照してください。
ハードウェアの交換を使用してBroadWorksを同時にアップグレードしたり、ハードウェアの交換とBroadWorksのアップグレードを同じメンテナンス時間帯に行うことは推奨されません。データベースを持つサーバは、アップグレード処理を行う必要があります。あるバージョンのBroadWorksのデータベースを別のバージョンのBroadWorksにインポートすることはできません。
アップグレードの制限とサーバ固有の注意事項
ネットワークサーバロールバック
ネットワークサーバ(NS)は21.sp1からRIにアップグレードできますが、ロールバックはサポートされていません。21.sp1に戻す必要がある場合は、復元が必要です。ロールバックを実行すると、サーバのバージョンがソースリリースに戻され、追加された内容を保持したまま、すべての変更がデータベースにロールバックされます。復元を実行すると、サーバのバージョンがソースリリースに戻され、アップグレード直前に作成されたDBバックアップと、アップグレード後にDBに追加されたデータが復元に使用されてインポートされます。ソリューションとしては、まずNSを23.0にアップグレードしてから、目的のRIバージョンにアップグレードします。二重アップグレードが望ましくない場合、ロールバックが必要な場合の回避策として、NSを元に戻してから、「メンテナンスガイド」に記載されているネットワークサーバとアプリケーションサーバの同期手順に従い、NSデータベースをASデータベースと同期させます。
プロファイルサーバと拡張サービスプラットフォームのアプリケーション配信プラットフォームへのアップグレード
リリース24.0以降、プロファイルサーバ(PS)と拡張サービスプラットフォーム(XSP)は同じサーバタイプになり、アプリケーション配信プラットフォーム(ADP)と呼ばれるようになりました。PSサーバとXSPサーバはアップグレードが完了し、アップグレード後にADPサーバタイプになります。
21.sp1から、PSおよびXSPがアップグレードできるADPの最新のRIバージョンは2022.07です。2022.08+にアップグレードするには、2段階のアップグレードが必要です。ADPライセンスと、導入されたアプリケーションの更新バージョンが必要です。XSPのアップグレードは、アプリケーションサーバ(AS)のアップグレード後に行う必要があります。ダウンロードポータルにはPSおよびXSPのRIバージョンがありますが、これらはASの代わりに実行サーバ(XS)サーバを導入するシステム専用です。ASを持つすべてのシステムで、PSおよびXSPをADPにアップグレードする必要があります。
Cisco BroadWorksアプリケーションおよびWebアプリケーションは、XSP、PS、およびADPで手動でアップグレードする必要があります。
データベースサーバ
データベースサーバ(DBS)は、OSの制限により、複数のジャンプでアップグレードして最新の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のバージョンは、基礎となるOracleのバージョンと互換性を確保するためにDBSのバージョンと一致する必要があります。
DBSリリースとOracleリリースの連携
21.sp1および22.0:Oracle 11
2018.11から2020.08:Oracle 12
2020.11以降：Oracle 19
DBSアップグレードのスキップ
DBSのアップグレードをスキップして、DBを21.sp1から直接DBS 2022.03+にインポートするオプションがあります。ただし、このプロセスは迅速ではなく、実稼働に必要なタイミングを確認するためにラボでテストする必要があります。「DBSリリースノート」セクション6、BWKS-3069および「DBS設定ガイド」セクション6.5.7.3を参照してください。
拡張コールログ
Enhanced Call Logs(ECL)は、DBS 2020.08以降のDBSではサポートが終了しています。継続的に使用するには、ECLデータベースをNetwork Database Server(NDS)に移行する必要があります。移行は自動的には行われません。詳細については、『Enhanced Call Logsソリューションガイド』および『NDS拡張コールログ機能の説明』を参照してください。移行手順については、『ネットワークデータベースサーバ設定ガイド』および『DBSからNDSへのECL移行の機能説明』を参照してください。アップグレードの前に移行を実行する必要があります。
Collaborateサーバ
メッセージングサーバ(UMS)、共有サーバ(USS)、ビデオサーバ(UVS)、WebRTCサーバ(WRS)、Business Communicatorクライアント(BTBC)、および接続クライアントのメンテナンス終了(EoM)は、2022年1月31日でした。UMSで使用できる最新のRIバージョンは22.0で、USS、UV、およびWRSで使用できる最新バージョンは2022.01です。
24.0のASは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ソリューションガイド』を参照してください。
要素管理システム及び仮想ライセンスサーバ
Element Management System(EMS)とVirtual Licensing Server(VLS)は2018年第2四半期時点でサポート終了(EoL)となっており、これらの機能はNetwork Function Manager(NFM)に置き換えられています。NFMへのアップグレードパスや、EMSまたはVLSノードの運用停止はありません。
ネットワーク機能マネージャ
NFMを21.sp1から2段階アップグレードする必要があります。2019.05にアップグレードした後、2022.08+にアップグレードできます。ネットワークモニタリングを導入する場合は、21.sp1から2019.05へのアップグレード、2020.11へのアップグレード、さらに2022.08+へのアップグレードという追加のステップが必要です。
Linux 6での23.0へのアップグレード
Linux 6でApplication Serverを23.0にアップグレードする場合、いくつかのパッチを適用する必要はありません。そうしないと、パッチ「Rel_22.0/v1.450/
」の適用でアップグレードが失敗します。23.0にアップグレードする場合は、AP.platform.23.0.1075.ap38541、AP.as.23.0.1075.ap385380、AP.as.23.0.1075.ap385413、およびAP.as.23.0.1075.ap385453のパッチをASには適用しないでください。
ドキュメントの確認
ターゲットリリースのリリースノート、およびターゲットリリースとソースリリース間のリリースを確認する必要があります。ターゲットリリースが24.0の場合は、22.0、23.0、および24.0のリリースノートを確認する必要があります。
22.0リリースノート
23.0リリースノート
24.0リリースノート
アップグレード手順
正式にサポートされているアップグレードパスについては、『ソフトウェア互換性マトリクス』を参照してください。
リリース22.0以降のEoMには、いくつかの機能があります。これらの問題は、メンテナンス終了(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 Upgrade Teamから利用できます。
BroadWorksアップグレードチームは、メンテナンスおよびサポート契約に基づき年1回、ラボおよび実稼働用の最新の「サポート中」リリースへのアップグレードをサポートします。アップグレードチームは、アップグレードの準備に関するサポートと、アップグレード中にリアルタイムでサポートを提供できます。サポートには、アップグレードをリモートで実行するシスコのエンジニアが含まれます。アップグレードチームの範囲はアップグレード作業のみに限定され、ハードウェアやオペレーティングシステムのアップデート、既存の問題のデバッグなど、アップグレード前に解決する必要がある問題については直接サポートを提供しません。また、一般的なサーバのヘルスチェックを超える包括的なアップグレード後テストは提供しません。
BroadWorksのアップグレードチームにアカウントチームを通じてお問い合わせいただくか、bwupgrade@cisco.comまで電子メールでお問い合わせください。リアルタイムアップグレードサポートは、事前にスケジュールされた急な連絡では利用できません。
アップグレード前のBroadWorksサポートへの通知
アップグレードチームのサポートなしでアップグレードを実行する場合は、重大度4(s4)チケットを添えて数日前にBroadWorksサポートに通知することを推奨します。メンテナンス中に問題が発生した場合は、チケットの重大度をs1に上げ、新しいs1チケットを開くか、サポート回線に電話してエンジニアと話します。
テスト計画
アップグレードを円滑に行うには、テスト計画が不可欠です。テスト計画は、実稼働アップグレードの前にラボで作成およびテストする必要があります。アップグレードの前にシステムでテスト計画を実行し、結果を記録します。これにより、システムの健全性が保証され、すべてのテストユーザとアカウントが正しく設定されて機能していることが検証されます。また、テスト計画に含まれる潜在的なギャップを把握する機会が提供され、テストにかかる時間の見積もりが提供されます。
アップグレード後に各サーバをテストして、期待どおりに機能することを確認してから、次のサーバにアップグレードする必要があります。
パッチ
アップグレードの前に、ソースリリースに最新のパッチレベルの6か月以内のパッチを適用します。
インストール前のチェックスクリプト
アップグレードの前に対処するサーバ、ラボ、および実稼働環境で、インストール前のチェックスクリプトを実行する必要があります。
ラボでのアップグレード
本稼働環境を再現するラボ環境で、サードパーティ製のツール、アプリケーション、またはクライアントを使用して、アップグレード、テスト計画、およびターゲットリリースをテストすることが常に推奨されます。ラボはスケールダウンできますが、サーバタイプ、ソフトウェアバージョン、OSバージョン、アクセスデバイス、セッションボーダーコントロール(SBC)などが同じである必要があります。ラボでのアップグレードは、実稼働環境のアップグレードの際の予行演習として扱ってください。ラボをアップグレードするときは、最新のターゲットリリースのパッチレベルを使用します。ラボと実稼働アップグレードの間の時間は、3ヵ月以内に抑えてください。
スケジューリングとアップグレードの順序
アップグレードは数日の夜間に分散された複数のメンテナンス時間帯に行うことが想定され、ソフトウェア管理ガイドのセクション4.2に記載されているように、インストールおよびアップグレード順序で実行されます。アップグレードは、事前に決められたメンテナンス時間帯（混雑していない時間帯）に必ず実行してください。 常に一度に1つのノードをアップグレードし、クラスタの1つ以上のノードが常にダウンしていることを確認してください。メンテナンスウィンドウ(MW)の長さ、アップグレードするサーバの数、サーバタイプ、およびテストの予想所要時間によって、必要なメンテナンスウィンドウの数が決まります。クラスタ内のすべてのサーバは、同じMWでアップグレードする必要があります。必要に応じて、トラブルシューティングやロールバックのために、スケジュールされたMWで利用可能な時間を残します。
アップグレードの失敗
アップグレード後のテスト中に問題が検出された場合、またはアップグレードが失敗した場合は、ソースリリースに戻す前、またはサーバを復元する前に、ログを収集します。ログディレクトリ全体をバックアップして、有用な可能性のあるすべてのログを確実に保持します。ただちにチケットを開き、MWにいる間にサポートに連絡して支援を求めてください。
フィードバック