BroadWorks Servers R25のアップグレード手順
はじめに
このドキュメントでは、BroadWorks Upgrade Teamが準拠するBroadWorksサーバを他の正式なソースからアップグレードする手順について説明します。
公式ドキュメント
これらのリファレンスドキュメントは『Cisco BroadWorks Documentation Guide Release 25』のページにあります。次の主要なドキュメントを参照してください。
リリース ノート
アップグレードの前に、ターゲットリリースのリリースノートを確認し、記載されている変更による潜在的な影響を測定します。ターゲットリリースのリリースノート、およびソースリリースとターゲットリリースの中間リリースを確認します。たとえば、23.0から25.0にアップグレードする場合は、24.0と25.0のリリースノートを確認する必要があります。
これらは、シスコの文書ページまたは提供されたリンクから入手できます。
標準手順
これは、サーバをアップグレードする順序です。ネットワークサーバ(NS)とメディアサーバ(MS)は、互いに関連して特定の順序でアップグレードする必要はありません。
ADPの最初のセットは、DBSObserver、DBManagement、およびその他のプロファイルサービスを実行するADPで構成されているため、アプリケーション配信プラットフォーム(ADP)はシーケンスの2回言及されます。2番目のADPセットは、拡張サービスインターフェイス(XSI)、オープンクライアントインターフェイス – プロビジョニング(OCI-P)、デバイス管理システム(DMS)、および通知プッシュサーバ(NPS)サービスで構成されます。
BroadWorksサーバをアップグレードする場合は、次の標準的な高度な手順に従ってください。
- サーバをバックアップします。
- 最新のリリース非依存(RI)インストールソフトウェアパッケージをインストールします。swmanagerはRIパッケージに含まれています。
- ターゲットリリースライセンスをインストールします。
- CLIからアップグレードチェックツールを実行して、警告がないことを確認します。
ADP_CLI/Maintenance/Tools> upgradeCheck ADP_Rel_2021.02_1.50
クラスタのメンバの1つをアップグレードする前に、必ず同じクラスタのすべてのピアにターゲットリリースをインストールしてください。
各サーバの完了したタスクを確認しておくと便利です。例：
|
マシン |
サーバ1 |
サーバ2 |
サーバ3 |
|---|---|---|---|
|
バックアップ |
Done |
Done |
|
|
テクニカルサポート |
Done |
…など… |
|
|
ターゲットリリースのインストール |
Done |
||
|
ライセンスのインポート |
Done |
||
|
Healthmonチェック |
Done |
||
|
アップグレードチェック |
Done |
手順の期待値
このドキュメントの想定事項を以下に示します。
- バックアップの実行、新しいバイナリのインストール、およびアップグレードを行うのに十分なディスク領域があります。
- 各サーバには、パッケージをインストールする機能があります。
- OSはターゲットリリースと互換性があります。
- すべてのサーバでPre-InstallCheckが実行され、警告または障害が修正されました。
- システムは正常な状態です。
- 適切なライセンスが取得されている。
- アップグレード後のテスト計画が作成され、アップグレードの前に実行され、結果が記録されました。
サーバ固有の注意事項
- Network Function Manager(NFM)は他のBroadWorksサーバから独立しているため、相互運用性は問題になりません。常に最新バージョンのNFMを実行することをお勧めします。
- Database Server(DBS)へのアップグレードによってソフトウェアはアップグレードされますが、データベースに対するスキーマの変更は、ADP（EnhancedCallLogsDBManagementアプリケーションを実行）がアップグレードされるまで行われません。
- EnhancedCallLogsDBManagementNDSまたはCCReportingDBManagementを実行しているADPをアップグレードする前に、DBSまたはネットワークデータベースサーバ(NDS)をバックアップしておくことをお勧めします。
- Application Server(AS)の前にMS/NSをアップグレードします。 通常、ASがアップグレードされるまで、MS/NSを最新リリースで1 ～ 2日稼働させたままにしておきます。
詳細は、『互換性マトリクス』を参照してください。
アップグレード前およびアップグレード後のテスト計画
完全なテスト計画を作成し、アップグレードの前にこのテスト計画の結果を実行して記録しておくことをお勧めします。これにより、アップグレード前に問題を特定できるだけでなく、アップグレード後のテスト結果との比較が可能になります。
復帰とロールバック
BroadWorksのアップグレードでは、サーバの復帰とロールバックは同じではありません。サーバの復元では、最後に実行されたデータベース(DB)のバックアップを復元して、アップグレード前の状態に戻します。最初のアップグレードが失われた後にDBに追加されたデータを元に戻します。ロールバックは、アップグレードのプロセスでDBに加えられたすべての変更を取り消し、初期アップグレードの後でDBに追加されたデータはそのまま残します。
独立したサーバのリリース
すべてのサーバがRIです。すべての新機能、バグ、およびセキュリティ修正は、新しいバージョンのソフトウェアで提供されます。パッチを利用できません。修正を行うには、サーバをあるバージョンから別のバージョンにアップグレードする必要があります。各サーバの新しいバージョンは、（毎月のパッチバンドルではなく）毎月リリースされることが予想されます。
RIバージョンは、標準のRel_25.0_1.944形式とは異なる形式を使用します。このRI形式は、Server_Rel_yyyy.mm_1.xxxです。
- サーバはMSです。たとえば、
- yyyyは4桁の年です
- mmは2桁の月です
- xxxはその月の増分リリースです
たとえば、MS_Rel_2022.11_1.273.Linux-x86_64.binは、2022年11月にリリースされたMSのバージョンです。
ADP
リリース25では、拡張サービスプラットフォーム(XSP)とプロファイルサーバ(PS)の機能オファリングがADPに移行しました。XSPおよびPSで実行されるアプリケーションは、コアアプリケーション（コアインフラストラクチャにサービスを提供）とボーダーアプリケーション（外部APIアクセスを提供）の2つのカテゴリに分けられます。 インストールされるアプリケーションによって、ネットワーク内でのADPの位置が定義されます。
ADPで提供されるアプリケーションは、RI方式またはリリースアンカー(RA)方式で提供されます。 RAは、アプリケーションがASバージョンにスキーマ依存していることを意味するため、アプリケーションファイル名にリリースコンポーネントが存在し、ASリリースに関連付けられた別の「ブランチ」が提供されます。
ADPで利用可能なアプリケーションと利用可能な最新バージョンのリストについては、『BroadWorks Application Delivery Platform Software Download』を参照してください。
インストール手順
BroadWorksのインストーラはCisco BroadWorks - Downloadsからダウンロードできます。
ターゲットリリースバイナリのインストール
これらのインストールは、サービスを中断することなく実行できます。インストール手順はすべてのサーバで同じですが、サーバタイプが若干異なります。RIサーバにはインストールパッチがありません。
以下の手順ではASを使用していますが、手順はすべての25.x BroadWorksバイナリで同じです。これはrootユーザとして実行する必要があります（sudoは受け付けられません）。 umaskはrootの場合は0022、bwadminの場合は0002です。
$ chmod +x AS-25_Rel_2023.03_1.411.Linux-x86_64.bin $ ./AS-25_Rel_2023.03_1.411.Linux-x86_64.bin
インストールが完了したら、出力でその他のアクションや警告を確認します。新しいライセンスが必要であること、およびターゲットリリースを手動でアクティブ化する必要があることを示すメッセージが表示されます。
============================================================== The installation is now completed. ============================================================== +++ Warnings summary +++ +++WARNING --- 1001 <You may have to install new license files> +++WARNING --- 1002 <You will need to manually activate the new software version> Please refer to the information reported in file: /var/broadworks/logs/installation/installation.230418.20h03m19s.warning for details as some warnings may require manual intervention. done Moving logs, steps and warnings to /var/broadworks/logs/installation
インストールが完了したら、bwcliからqversionsコマンドを入力して、そのファイルが存在することを確認します。ステータスがInstalled(Activeではない)である点に注意してください。
AS_CLI> qversions
Identity Version Install Date Status
==================================================
AS 2023.03_1.411 Apr 18, 2023 Installed
AS 24.0_1.944 Feb 11, 2022 Active
インストールされたバイナリの削除
バイナリが正しくインストールされないか、削除する必要がある場合は、uninstall-bwserver.plスクリプトを実行します。
$ cd /bw/broadworks//uninstall/ $ ./uninstall-bwserver.pl -r
「 – r」パラメータは、/bw/broadworks/<server>にある残りのフォルダ構造を削除する指示を与えます。
ターゲットリリースライセンスのインストール
このセクションでは、Universal Unique Identifier(UUID)ライセンスについてのみ説明します。NFMベースのライセンスについては、『Network Function Manager Node and License Management Guide』の「License Management」のセクションを参照してください。
UUIDベースのライセンスの場合、ライセンスファイルは複数のzipファイルに格納され、サーバは.txtファイルと.sigファイルを含むzipファイルを想定します。 ローカルマシンでファイルを解凍して.txtファイルと.sigファイルをコピーしないでください。署名が無効になります。
CLIからのライセンスのインポート
ライセンスファイルを解凍してフルパスを使用する必要はありません。
AS_CLI/System/Licensing/LicenseManager/LicenseStore> import /path/to/licensefiles.zip
OSからのライセンスのインストール
ライセンスファイルを解凍して、bwadminまたはroot runとしてフルパスを使用する必要はありません。
$ cd /usr/local/broadworks/bw_base/bin/ $ ./install-license.pl /path/to/licensefiles.zip
OSからライセンスをインストールしてXSPをADPに変換する
ADP taragetリリースフォルダcd /usr/local/broadworks/ADP_Rel_2024.11_1.311/に移動し、install-license.plスクリプトを実行する必要があります
$ cd /usr/local/broadworks/ADP_Rel_2024.11_1.311/bw_base/bin/ $ ./install-license.pl /path/to/licensefiles.zip
UpgradeCheckツールの実行
bwcliからupgradeCheckツールを実行し、警告がないことを確認します。
ASからの例を次に示します。
AS_CLI/Maintenance/Tools> upgradeCheck AS_Rel_2023.03_1.411
This is a dry-run upgrade.
BroadWorks SW Manager checking AS server version 2023.03_1.411...
Checking license file information
Checking configuration file presences
Checking installation.conf file
Checking version presences
Checking Broadworks version dependencies
Checking target Broadworks version present
Checking for available disk space
Space required = 32768 Mb
[done]
Checking System configuration
BW Daemon configuration validation
testing /etc/xinetd.d... [done]
Validating MoDaemon
Checking upgrade compatibility
Checking for dangling softlink
...Monitoring directory tree starting at: /var/broadworks
Running /usr/local/broadworks/AS_Rel_2023.03_1.411 /bin/preUpgradeCheck
Executing transform... [ok]
####### CCRS Support Check START #######
No need to check for CCRS devices, upgrading from release 19 or later
####### CCRS Support Check END #######
####### Conference Access Check START #######
No need to check for duplicate conference Id's and Moderator Pins , upgrading from release 19 or later
####### Conference Access Check END #######
####### trunk group check START #######
####### Startup Parameters IP Addresses Check START #######
####### Startup Parameters IP Addresses Check END #######
####### Reporting File Queues Check START #######
####### Reporting File Queues Check END #######
####### Domains table sanity check START #######
####### Domains table sanity check END #######
####### DNIS UID sanity check START #######
####### DNIS UID sanity check END #######
####### File System Protocol Check START #######
No need to check for use of WebDav interface for custom media files.
Upgrading from release 20 or later
####### File System Protocol Check END #######
####### Disk space check for Announcement repository START #######
No need to check for available diskspace for announcement repository.
Upgrading from release 20 or later
####### Disk space check for Announcement repository END #######
####### DeviceProfileAuthMode Check START #######
####### DeviceProfileAuthMode Check END #######
####### Activatable Feature Validation START #######
Validation Successful
####### Activatable Feature Validation END #######
####### Database Manual Connections START #######
No manual database connections detected..
####### Database Manual Connections END #######
Waiting for maintenance tasks to complete if any
Checking sshd configuration
Checking for critical patches
Checking for feature patches conformity between source and target version
Checking TimesTen permanent memory size
Checking version of active TimesTen
####### Database Impacts Check START #######
Database impacts detected: datastore will be unloaded, replication will be restarted, database will be imported on non-primary nodes.
####### Database Impacts Check END #######
setactiveserver command successfully executed.
Dry-run upgrade completed.ネットワーク機能マネージャ(NFM)
NFMは、ネットワークおよびライセンス管理機能を実装します。
healthmonに問題がないことを確認します。
-------------------------------- System Health Report Page BroadWorks Server Name: nfm1 Date and time : Thu Nov 8 05:19:16 EST 2022 Report severity : NOTIFICATION Server type : NetworkFunctionManager Server state : Unlock -------------------------------- No abnormal condition detected. --------------------------------
バックアップとテクニカルサポート
サーバをアップグレードする前に、アップグレード前にバックアップを取り、からのテクニカルサポートをログに記録することを推奨します。
$ bwBackup.pl -type=full -file=/var/broadworks/backup/bwBackup.bak $ tech-support >> tsup_hostname_sourceRelease.txt
アップグレード前
upgradeCheckツールを実行して、警告が発行されていないことを確認します。
NFM_CLI/Maintenance/Tools> upgradeCheck NFM_Rel_2022.11_1.274
アップグレード中のNFMにNetworkMonitoringが存在するかどうかの確認
NFM_CLI/Applications/NetworkMonitoring/Replication> status
Admin state = standby
Effective state = standby
Name Admin State Effective State
================================================
PostgreSQL Online Online
OpenNMS Offline Offline
File replication Online Offline
Monitoring Online Offline
4 entries found.
NFM_CLI/Applications/NetworkMonitoring/Replication> exit
Please confirm (Yes, Y, No, N): y
This session is now ending...
bwadmin@nfm02-cormac.local$ pgctl status
Database Status: Running
Accepting Connections: TRUE
Configured Mode: standby
Effective Mode: standby
Replication stats:
WAL files: 66
NFMアップグレードスイッチ
NFMクラスタでは、NFMがネットワーク監視を実行している場合、ネットワーク監視プライマリとして機能するNFMを最初にアップグレードし、ネットワーク監視スタンバイであるサーバを2番目にアップグレードする必要があります。ネットワークモニタリングを使用していない場合は、アップグレードを任意の順序で実行できます。NFMサーバは、常に1つずつアップグレードする必要があります。
次のコマンドを入力して、アップグレードを開始します。
NFM_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server NFM 2022.11_1.274
+++ WARNING +++ WARNING +++ WARNING +++
This command will change the active software version of NFM to 2022.11_1.274. NOTE that this action will cause downtime.
Continue?
Please confirm (Yes, Y, No, N): yNFMでのライセンス管理
『NFM Node and License Management Guide』を参照してください。
NFMのアップグレード後のチェック
アップグレード後、起動後のNFMステータスを確認します。
healthmon -lショーランbwshowver（ダウンロード）mdbctlステータス- ネットワークモニタリングがアクティブの場合：
pgctl status - /var/broadworks/logs/maintenance/ setactiveserver.NFM.Rel_2022.11_1.274.<date-time>.logファイルで、潜在的なアクティベーションエラーを確認します。
- NFMがNetworkMonitoringを実行している場合は、アプリケーションがターゲットリリースで再起動していることを確認します。
推奨されるNFMアップグレード後テスト
NFMサーバに接続されているアプリケーションがデータベーストランザクションを実行できることを確認します。
これらのテストは一般的なものであり、アップグレード後のテスト計画に含まれる追加のテストを実行します。
NFMサーバの復帰
NFM復元の手順は、他のサーバと同じです。
R21.SP1へのNFMの復帰はサポートされていません。これは、このリリースではデータベースの暗号化がサポートされていないためです。ここでrevertオプションを使用する必要があります。NFMクラスタを元に戻すと、データベースのバックアップを復元するためにすべてのクラスタメンバーでデータベースを停止する必要があるため、アプリケーションにダウンタイムが発生します。
詳細な復元手順については、『NFMコンフィギュレーションガイド』を参照してください。
元に戻す
NFMがアップグレード後のチェックに合格しない場合は、以前のリリースに戻します。
NFM_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server NFM 2022.10_1.318 revert
+++ WARNING +++ WARNING +++ WARNING +++
This command will change the active software version of NFM to 2022.10_1.318 NOTE that this action will cause downtime.
Continue?
Please confirm (Yes, Y, No, N): yこの例では、2022.10_1.318に戻されていますが、これはすべての以前のリリースに置き換えることができます。
データベースサーバ(DBS)
DBSは、他のBroadWorks製品とは異なるデータベース・エンジン(Oracle 11g)を実行するため、アップグレードの前提条件、アップグレード手順、およびバックアップ・コマンドは、BroadWorksスイートの他の部分とはまったく異なります。このセクションをよく読み、明確にする必要がある場合は、Technical Assistance Center(TAC)に通知チケットを遠慮なく発行してください。
DBSとDBSだけが異なる点は、まずスタンバイサーバのアップグレードを開始することです。これは、DBSアップグレードでは実際にはDBスキーマが変更されないためです。これは、CCReportingDBManagementがアップグレードされる際に発生します。DBSアップグレードでは、ソフトウェアとデータベースはアップグレードされますが、スキーマは変更されません。
その他の特殊事項として、アップグレードを実行する前にサーバをリブートする必要があること、スケジュールされたタスクを手動で削除する（アップグレードの妨げにならないため）ことが挙げられます。
必要なものについては、次のセクションで詳しく説明します。
両方のDBのバックアップ
dbsctl diskinfoコマンドを使用して、DATAのサイズをメモします。
bwadmin@dbs1$ dbsctl diskinfo
Disk Group Usage Summary
DATA 12.32 % used (8075/65530 MB)
FRA 11.12 % used (7286/65530 MB)
FRA LIM 11.50 % used (7156/62253 MB)
FRA 11.12 % used (7286/65530 MB) , w/o Reclaimable data
Disk Usage Summary
DATA 12.32 % used (8075/65530 MB)
FRA 11.12 % used (7286/65530 MB)
Rebalancing in progress: noバックアップに必要なスペースは、その約1/7です。
バックアップするには、次のコマンドを入力します。
bwadmin@dbs1$ export TAG=`echo -n $(showver | grep Rel | sed -e ‘s|.*Rel_||’);echo -n “-“; date +%Y.%m.%d`
bwadmin@dbs1$ bwBackup.pl -type=Full -tag=$TAG -path= /var/broadworks/backup/$TAG -compressed
BroadWorks Database Server Backup Tool version 1.10
Checking for sufficient disk space…[DONE]
Backing up database...[DONE]
bwadmin@dbs1$バックアップはOracleユーザーとして実行されるため、Oracleが書き込み権限を持っている場所に書き込む必要があることに注意してください。パーティション上でこれを処理するのに十分なディスク領域があることを確認します。
完全バックアップは、次のコマンドを使用して実行できます。
bwadmin@dbs1$ bwBackup.pl -f -type=full -tag=$TAG -device=/var/broadworks/backup/$TAGDBSObserverの停止
冗長構成の場合は、アップグレード中にADPでDBSObserverアプリケーションを停止します。
bwadmin@<ps1>$ stopbw DBSObserver
DBSObserverは、いずれかのADPに導入されます。特定のADPがDBSObserverを実行しているかどうかを確認するには、ADPでのshowrunコマンドの出力を調べます。
アップグレード前の健全性チェック
両方のDBでdbsctl statusコマンドを使用して、レプリケーションが実行されていて正常であり、DBが正しく配置されていることを確認します。
bwadmin@dbs1$ dbsctl status Database Name : bwCentralizedDb0 Database Instance : DBSI0 Database Service : bwCentralizedDb Database Status (Mode) : running (Read Write) Database Service Status : running Database Role (Expected Role) : Primary (Primary)
bwadmin@dbs2$ dbsctl status Database Name : bwCentralizedDb1 Database Instance : DBSI0 Database Service : bwCentralizedDb Database Status (Mode) : running (Read Only w/Apply) Database Service Status : running Database Role (Expected Role) : Secondary (Secondary) Check repctl status to ensure that logs are shipping and both DBS are in sync. bwadmin@dbs1$ repctl status Gathering site information, please be patient...[DONE] Redundancy/Replication Status----------------------------- Database Name = bwCentralizedDb1 Database Service Name = bwCentralizedDb Dataguard Replication pid = 26502 Primary Database = bwCentralizedDb0 [DBS1] Standby Database = bwCentralizedDb1 [DBS2] Primary Database Reachable = yes Standby Database Reachable = yes Replication gap summary = OK Replication gap details Primary SCN: 842675099 Standby SCN: 842675095 Redo Apply Lag = +00 00:00:00 Estimated Redo Rate = 0.01 MB/s Primary Estimated Redo Log Space = 791991 MB Primary Estimated Log Space Exhaustion = +916 15:45:00 Primary Redo free space condition = NORMAL Primary Lag vs Redo state = N/A Standby Estimated Redo Log Space = 788521 MB Standby Estimated Log Space Exhaustion = +912 15:21:40 Standby Redo free space condition = NORMAL Standby Lag vs Redo state = N/A Archive gap summary = N/A Archive gap details N/A
アップグレード前の必須手順
スケジュール済みタスクをスケジューラから削除する
アップグレードの失敗とソースリリースへの自動復帰を引き起こすスケジュールされたタスクが特定されています。最初に、初期設定を書き留めます。
DBS_CLI/Maintenance/Scheduler> get
Id Name Date Day Hour Minute
=================================================================
1 tech-support - - 4 33
2 cpuMon - - - 5
3 healthmon - - - 30(offset: 1)
4 autoCleanup - saturday 2 33
5 backup - saturday 4 03次に、スケジュールされたタスクを削除します。タスクを削除するときは、ID番号が変わることに注意してください。最初に最も高いIDを削除します。
DBS_CLI/Maintenance/Scheduler> del 5 DBS_CLI/Maintenance/Scheduler> del 4 DBS_CLI/Maintenance/Scheduler> del 3 DBS_CLI/Maintenance/Scheduler> del 2 DBS_CLI/Maintenance/Scheduler> del 1
getコマンドを使用して、エントリが削除されていることを確認します。
アップグレード前のサーバのリブート(init 6)
アップグレードする前に、各サーバを必ずリブートしてください。ここでも、アップグレードの失敗を回避するのに役立ちます。常にスタンバイDBSサーバでアップグレードを実行しているため、何も影響を受けず、通常よりも多くのロールスイッチングが発生しません。
注文のアップグレードシーケンス図を参照してください。init 6は、バックアップの後、各サーバのアクティブ化の前に実行されます。
アップグレードの起動
DBSは、スタンバイ/セカンダリDBSが最初にアップグレードされるという点で、他のすべてのBroadWorksサーバとは異なります。現在アクティブなサーバから開始する場合は、リブートまたはロールの追加の変更が必要です。
スタンバイ/セカンダリの場合：
DBS_CLI/Maintenance/ManagedObjects> lock
ターゲットリリースに切り替えます。
DBS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server 2023.03_1.411
完了したら、サーバのロックを解除します。
DBS_CLI/Maintenance/ManagedObjects> unlock
Healthmonをチェックして、DBSが正しく起動したことを確認します。
新しくアップグレードしたスタンバイ/セカンダリDBSのアクティブ/プライマリへのスイッチオーバー
注：このコマンドは、新しくアップグレードしたサーバ（以前のリリースのDBSではなく）で実行してください。
bwadmin@dbs1$ peerctl ls
PEER Role Status State
===========================================================
dbs1 PRIMARY ACTIVE Unlocked
dbs2 SECONDARY STANDBY Unlocked
bwadmin@dbs1$ peerctl setPrimary dbs2
Setting 'dbs2' as new primary.
Switch over may take a few moments to complete, do you still want to proceed? (y/n) [y]?y
Switching over to 'bwCentralizedDb1', this may take a few moments to complete.[DONE]
Switch over completed.
bwadmin@dbs1$ peerctl ls
PEER Role Status State
===========================================================
dbs1 SECONDARY STANDBY Unlocked
dbs2 PRIMARY ACTIVE Unlocked
この段階で、アップグレードされたDBS(dbs2)がプライマリになります。
データベースサーバのアップグレード後のチェック
- コールセンターにコールを発信し、このアクティビティを示すレポートを取得します。
- 履歴レポートを取得します。
- データがDBS2に出荷されている（ファイルキューにない）ことを確認するために、ASでXSLogsを確認します。
以前のプライマリ（現在はスタンバイ）のアップグレード
以前のプライマリ<dbs1>（現在はスタンバイ）で、次のようにロックします。
DBS_CLI/Maintenance/ManagedObjects> lock宛先リリースに切り替えます。
DBS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server DBS 2023.03_1.411プライマリdbs1のロックを解除します。
DBS_CLI/Maintenance/ManagedObjects> unlockスイッチオーバーを元の設定に戻し、スタンバイをプライマリに戻す
peerctl setPrimary dbs1コマンドを使用して、DBS1をプライマリに戻します。
bwadmin@dbs1$ peerctl ls
PEER Role Status State
===========================================================
dbs1 SECONDARY STANDBY Unlocked
dbs2 PRIMARY ACTIVE Unlocked
bwadmin@dbs1$ peerctl setPrimary dbs1
Setting 'dbs1' as new primary.
Switch over may take a few moments to complete, do you still want to proceed? (y/n) [y]?y
Switching over to 'bwCentralizedDb0', this may take a few moments to complete.[DONE]
Switch over completed.
bwadmin@dbs1$ peerctl ls
PEER Role Status State
===========================================================
dbs1 PRIMARY ACTIVE Unlocked
dbs2 SECONDARY STANDBY Unlocked
スケジューラを以前の状態にリセットする
スケジュールされたタスクをスケジューラから削除したので、これらのタスクを再度追加する必要があります。念のため、標準的なタイミングは次のとおりです。
DBS_CLI/Maintenance/Scheduler> add tech-support daily 4 33
DBS_CLI/Maintenance/Scheduler> add cpuMon minute 5
DBS_CLI/Maintenance/Scheduler> add healthmon minute 30 1
DBS_CLI/Maintenance/Scheduler> add autoCleanup day saturday 2 33
DBS_CLI/Maintenance/Scheduler> add backup day saturday 4 3プライマリ・データベース・サーバのアップグレード後のチェック
- コールセンターにコールを発信し、このアクティビティを示すレポートを取得します。
- 履歴レポートを取得します。
- データがDBS1に出荷されている（ファイルキューにない）ことを確認するために、ASでXSLogsを確認します。
healthmon、レプリケーション、およびREDOログ配布を確認します。
bwadmin@dbs1$ repctl status
bwadmin@dbs1$ dbsctl status
bwadmin@dbs1$ dbsctl diskinfo
bwadmin@dbs1$ dbsctl redolog infoアップグレード後に両方のDBが良好な状態であることを確認するために、両方のDBでこの操作を実行します。
ADPからの健全性の検証
CCReportingDBManagementを実行しているADPから、次のコマンドを入力します。
bwadmin@ps1$ bwcli
ADP_CLI/Applications/CCReportingDBManagement/Database/Databases/Sites> validate
Host Name Database Status
===========================================================
dbs01 bwCentralizedDb Primary
dbs02 bwCentralizedDb Standby
ADP_CLI/Applications/CCReportingDBManagement/Database/Schemas> validate
Name Status
===========================================================bweccr Read/Write
DBSObserverの起動
両方のDBSがアップグレードされたら、DBSObserverアプリケーションを起動してフェールオーバーを制御します。
bwadmin@ADP1$ startbw DBSObserver
Starting DBSObserver...データベースサーバの復元手順
データベースサーバ全体の復元手順は、『BroadWorksソフトウェア管理ガイド』に記載されている一般的なBroadWorksの復元手順と非常によく似ています。
主な違いは次のとおりです。
- ロールバックはサポートされていません。復元のみがサポートされています。
- 冗長構成の場合、ソフトウェアの復元は最初にスタンバイサイトで行われます。
- 復帰後チェック(データベースサーバ>データベースサーバの復帰手順>詳細な手順>復帰後チェックを参照)は、ソフトウェアのアクティブ化後に、データベースの復帰が正しく行われたかどうか、および何らかの修正措置が必要かどうかを確認するために実行する必要があります。
ロールバック拒否
次の例に示すように、データベース・サーバ上のアクティブなソフトウェア・バージョンをロールバックしようとする操作はすべて拒否されます。
DBS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server DBS 2022.12_1.371
+++ WARNING +++ WARNING +++ WARNING +++
This command will change the active software version of DBS to 2022.12_1.371. NOTE that this action will cause downtime.
Continue?
Please confirm (Yes, Y, No, N): y
SW Manager initialized!
[Error] This server type does not support rollback. The revert flag is mandatory.詳細な手順
スタンドアロンサーバと冗長サーバ構成でCisco BroadWorksを復帰させるために必要な手順は同じであり、特定の順序で実行する必要があります。これらの手順では、両方の設定について説明します。
- 古いCisco BroadWorksバージョンをアクティブにします。冗長構成の場合は、最初にスタンバイサーバを復帰させる必要があります。スタンバイを復帰させる場合は、バックアップの場所を指定しないでください。
- 冗長構成の場合は、プライマリサーバの反転に進みます。
- 復元後の検証を実行します。
シーケンス図に対応する手順を明確にするために、スタンバイSiteBを復元する際にはバックアップファイルを指定しません。ただし、SiteAを復元するときにバックアップファイルを指定できます。または、次の手順でバックアップファイルを復元できます。スタンバイ同期ステップでは、SiteAとSiteBの間でデータを同期します。
元に戻す
元に戻す操作は、BroadWorks CLIのManagedObjectレベルから開始されます。他のサーバタイプと同様に、次の例に示すように、CLI内でバックアップの場所を直接指定できます。
DBS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server DBS 2022.12_1.371 revert /var/broadworks/backup/2022.12_1.371-2022.12.28-12.15.43
+++ WARNING +++ WARNING +++ WARNING +++
This command will change the active software version of DBS to 2022.12_1.371. NOTE that this action will cause downtime.
Continue?ただし、復元オペレーションがスタンバイサイトで実行される場合は、バックアップの場所を指定しないでください。スタンバイサイトは、復元操作の後にimportdb.plを使用してプライマリから再作成されるか、復元スクリプト自体によって自動的に再同期されます。復元が完了したら、revertcheckテストの結果で推奨される修正措置を確認してください。
さらに、プライマリをアップグレードする前に復元を実行した場合、プライマリで実行されているデータベースはアップグレードの影響を受けないため、スタンバイを以前のリリースに安全に戻すことができます。復元や再同期操作は必要ありません。
次のコマンド出力ログは、バックアップディレクトリを指定せずに起動したときの復元シーケンスを示しています。
DBS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server DBS 2022.12_1.371 revert復帰後の確認
revertcheck後のスクリプトは、データベースの復元が正しく行われたかどうか、および修正措置が必要かどうかを判断するように設計されています。 これは、フルパスまたはドットスラッシュ(./)プレフィックスを使用して、最新のBroadWorksリリースのbinディレクトリから実行する必要があります。
bwadmin@dbs01.example.com$ cd /usr/local/broadworks/DBS_Rel_2022.12_1.371/bin/
bwadmin@dbs01.example.com$ ./dbsctl validate revertcheck
The last activation completed 0d 18h 23m 39s ago.
Running database post revert checks...
Oracle version already active.
Grid version already active.
... reverting init check [success]
... reverting check permissions [skipped]
... reverting check hardware [skipped]
... reverting check peer time [skipped]
... reverting check kernel [skipped]
... reverting check inventory [skipped]
... reverting check archivelog [skipped]
... reverting check backup [skipped]
... reverting check standby count [skipped]
... reverting check remote versions [skipped]
... reverting check patch level [skipped]
... reverting check peer idle [skipped]
... reverting check node id [skipped]
... reverting check replication [success]
... reverting check peer status [success]
... reverting check peer name lookup [skipped]
... reverting check traced event [skipped]
... reverting check invalid objects [skipped]
... reverting check active tasks [skipped]
... reverting check supported data types [skipped]
... reverting check dbcontrol [skipped]
... reverting check database status [skipped]
Post check... [DONE]
No corrective action necessaryバックアップの復元
set activeSoftwareVersion serverコマンドでバックアップディレクトリを指定していた場合は、復元プロセスでバックアップが自動的に復元されます。
それ以外の場合は、次のコマンドを使用してバックアップを復元する必要があります。
bwadmin@dbs01$ bwRestore.pl -recover -path=/var/broadworks/backup/<backup_name>スタンバイの同期
スタンバイをデータベースと再同期する必要がある場合は、importdb.plスクリプトが使用されます。
サイトAのプライマリがアップグレードされていない場合、サイトBのデータベースを再同期するには、次のコマンドを使用します。
bwadmin@dbs02$ importdb.pl --peer=dbs01サイトAをアップグレードして元に戻した場合は、プライマリサイトからスタンバイデータベースを再作成し、冗長性を再設定する必要があります。これを行うには、代わりに次のコマンドを使用します。
bwadmin@dbs02$ importdb.pl --peer=dbs01 --cleanupDBSの復元手順の詳細については、『DBSコンフィギュレーションガイド』を参照してください。
プライマリ/スタンバイスイッチをアップグレード前の状態に戻す
復元が完了したら、peerctlコマンドを使用して、サーバをアップグレード前のプライマリ/スタンバイ状態に戻します。例：
bwadmin@dbs1$ peerctl setPrimary dbs1DBSObserverがADPで実行されていない場合は、起動します。
ネットワークデータベースサーバ(NDS)
healthmonに問題がないことを確認します。
--------------------------------
System Health Report Page
BroadWorks Server Name: nds1
Date and time : Thu Nov 7 05:19:16 EST 2022
Report severity : NOTIFICATION
Server type : NDS
Server state : Unlock
--------------------------------
No abnormal condition detected.
--------------------------------バックアップとテクニカルサポート
サーバをアップグレードする前に、アップグレード前に完全バックアップを取り、からのテクニカルサポートをログに記録することを推奨します。
$ bwBackup.pl -type=full -file=/var/broadworks/backup/bwBackup.bak
$ tech-support >> tsup_hostname_sourceRelease.txtアップグレードチェック
upgradeCheckツールを実行して、警告が発行されていないことを確認します。
NDS_CLI/Maintenance/Tools> upgradeCheck NDS_Rel_2022.11_1.273NDSアップグレードスイッチ
クラスタでは、NDSがアップグレードされる順序は関係ありません。ただし、一度に1つずつアップグレードする必要があります。 次のコマンドを入力して、アップグレードを開始します。
NDS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server NDS 2022.11_1.273
+++ WARNING +++ WARNING +++ WARNING +++
This command will change the active software version of NDS to 2022.11_1.273. NOTE that this action will cause downtime.
Continue?
Please confirm (Yes, Y, No, N): yNDSのアップグレード後のチェック
アップグレード後、起動後にNDSのステータスを確認します。
healthmon -lショーランbwshowver（ダウンロード）mdbctlステータス- /var/broadworks/logs/maintenance/ setactiveserver.NDS.Rel_2022.11_1.273.<date-time>.logファイルで、潜在的なアクティベーションエラーを確認します。
推奨されるNDSアップグレード後テスト
NDSに接続されているアプリケーションがデータベーストランザクションを実行できることを確認します。
これらのテストは一般的なものであり、アップグレード後のテスト計画に含まれる追加のテストを実行します。
NDSサーバの復帰
NDSクラスタを元に戻すと、データベースのバックアップを復元するためにすべてのクラスタメンバーでデータベースを停止する必要があるため、アプリケーションにダウンタイムが発生します。
NDS復元の手順は、他のサーバと同じです。
元に戻す
NDSがアップグレード後のチェックに合格しなかった場合は、前のリリースに戻します。
NDS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server NDS 2022.08_1.352 revert
+++ WARNING +++ WARNING +++ WARNING +++
This command will change the active software version of NDS to 2022.08_1.352 NOTE that this action will cause downtime.
Continue?
Please confirm (Yes, Y, No, N): yこの例では、2022.08_1.352に戻されていますが、これはすべての以前のリリースに置き換えることができます。
ネットワークサーバ(NS)
NSがRIになっていることに注意してください。
healthmonに問題がないことを確認します。
--------------------------------
System Health Report Page
BroadWorks Server Name: ns1
Date and time : Thu Oct 3 15:50:21 BST 2022
Report severity : NOTIFICATION
Server type : NetworkServer
Server state : Unlock
--------------------------------
No abnormal condition detected.
--------------------------------
バックアップとテクニカルサポート
サーバをアップグレードする前に、バックアップを取り、tech-supportファイルをログに記録しておくことをお勧めします。
$ bwBackup.pl NetworkServer NS_hostname_sourceRelease.tar
$ tech-support >> tsup_hostname_sourceRelease.txtアップグレード前
NSを呼び出すテストコールを実行し、正常な302メッセージが/var/broadworks/logs/routingserver/にあるNSXSLogログにあることを確認します。
upgradeCheckツールを実行して、警告が発行されていないことを確認します。
NS_CLI/Maintenance/Tools> upgradeCheck NS_Rel_2022.11_1.27qcurrentコマンドで、現在使用されているコールなどの数を確認します。
NS_CLI/Monitoring/Report> qcurrentすべての非プライマリピアNSでデータベース同期(synchcheck_basic.pl -a)を確認します。
$ synchcheck_basic.pl -aプライマリNSアップグレードスイッチ
次のコマンドを入力して、アップグレードを開始します。
NS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server NS 2022.11_1.27
+++ WARNING +++ WARNING +++ WARNING +++
This command will change the active software version of NS to 2022.11_1.27. NOTE that this action will cause downtime.
Continue?
Please confirm (Yes, Y, No, N): ybwPeriodMaint.shスクリプトを実行して、データベース統計情報を更新します。
$ bwPeriodMaint.shNSのアップグレード後のチェック
アップグレード後、起動後のNSステータスを確認します。
healthmon -l- ピアが同期されていないことが示されますが、これはセカンダリがアップグレードされるまで予想されます。
- healthmonが一部のデータベースページサイズの超過を示す場合、
check_dbpages.pl networkserver modifyを入力します。
ショーランbwshowver（ダウンロード）- アクティベーションエラーの可能性については、/var/broadworks/logs/maintenance/ setactiveserver.NS.Rel_2022.11_1.27.<date-time>.logファイルを確認してください。
- NSテストを実行して、このNSがコールを正しく処理していることを確認します。
推奨されるNSのアップグレード後のテスト
- 公衆電話交換網(PSTN)インバウンド302リダイレクトを検証します。
- ASアウトバウンド302リダイレクトを検証します。
- MS要求/応答に対してASを検証します。
- CLIアクセスの検証（ログインしてNS_CLI/System/Device/HostingNEに移動し、getコマンドを入力）
- NSへのWebアクセスを検証します（有効になっている場合）。
- ADPにログインするだけで、NSモード通信を使用してADPからのユーザルックアップを検証します。
NSのアップグレード後のアクティビティ
異なるバージョンのASにADPがログインすることを拒否するようにNSが設定されていないことを確認します。NS_CLI/System/Device/HostingNE>で、各hostingNEのADP Versionをfalseに設定します。
NS復元
NSがアップグレード後のチェックに合格しなかった場合は、前のリリースに戻します。
NS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server NS 2022.09_1.340 revert
+++ WARNING +++ WARNING +++ WARNING +++
This command will change the active software version of NS to 2022.09_1.340. NOTE that this action will cause downtime.
Continue?
Please confirm (Yes, Y, No, N): yこの例では、2022.09_1.340に戻されていますが、これはすべての以前のリリースに代わることができます。
セカンダリNSにはソース・リリースの最新バージョンのデータベースがあるため、DBをそこからインポートできます。
セカンダリNSでは、
$ repctl startプライマリNSでは
$ stopbw
$ repctl stop
$ importdb.pl networkserver <peer_ns2>
$ repctl start
$ startbwセカンダリ（および他のすべての）NSデータベースのロックを解除します。
$ peerctl unlock復帰したプライマリNSでレプリケーションが実行されていることを確認します。
$ repctl statusすべてのセカンダリNSでレプリケーションが実行されていること、およびデータベースがロック解除されていることを確認します。
$ repctl statusすべてのNSでhealthmon -lにチェックマークを付けます。報告された重大度がすべてのサーバに対する通知であることを確認します。
セカンダリNSデータベースとプライマリNSデータベースが同期していることを確認します（セカンダリで）。
$ synchcheck_basic.pl -aセカンダリNSアップグレードスイッチ
次のコマンドを入力して、アップグレードを開始します。
NS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server NS 2022.11_1.27
+++ WARNING +++ WARNING +++ WARNING +++
This command will change the active software version of NS to 2022.11_1.27. NOTE that this action will cause downtime.
Continue?
Please confirm (Yes, Y, No, N): yセカンダリNSのアップグレード中に自動的に実行されたインポートの前に実行されているため、統計情報の更新スクリプトを実行する必要はありません。
NSのアップグレード後のチェック
アップグレード後、起動後のNSステータスの確認
healthmon -l- healthmonが一部のデータベースページサイズを超過したことを示す場合、
check_dbpages.pl networkserver modifyを入力します。
- healthmonが一部のデータベースページサイズを超過したことを示す場合、
ショーランbwshowver（ダウンロード）- アクティベーションエラーの可能性については、/var/broadworks/logs/maintenance/ setactiveserver.NS.Rel_2022.11_1.27.<date-time>.logファイルを確認してください。
- NSテストを実行して、このNSがコールを正しく処理していることを確認します。
推奨されるNSのアップグレード後のテスト
プライマリNSをロックすると、すべてのトラフィックがセカンダリを介してルーティングされます。
- PSTNインバウンド302リダイレクトを検証します。
- ASアウトバウンド302リダイレクトを検証します。
- MS要求/応答に対してASを検証します。
- CLIアクセスの検証（ログインしてNS_CLI/System/Device/HostingNEに移動し、getコマンドを入力）
- NSへのWebアクセスを検証します（有効になっている場合）。
- XSPにログインするだけで、NSモード通信を使用してXSPからのユーザルックアップを検証します。
- クラスタ後テスト
- すべてのサーバに対してhealthmonレポートの重大度NOTIFICATIONを確認します。
- データベースの同期を確認します。
$ healthmon -l
$ synchcheck_basic.pl –aメディアサーバ(MS)
healthmonに問題がないことを確認します。
--------------------------------
System Health Report Page
BroadWorks Server Name: ms1
Date and time : Thu Mar 3 11:10:53 BST 2022
Report severity : NOTIFICATION
Server type : MediaServer
Server state : Unlock
--------------------------------
No abnormal condition detected.
--------------------------------バックアップとテクニカルサポート
サーバをアップグレードする前に、アップグレードの前にからテクニカルサポートのバックアップを取ってログに記録しておくことを推奨します。MSでは、次のようにダウンします。
$ bwAutoBackup.sh
$ tech-support >> tsup_hostname_sourceRelease.txtアップグレード前
自動音声応答(IVR)を呼び出すテストコールを発信するか、ボイスメールを取得して、予期したとおりに動作し、コールがログで確認できることを確認します。
upgradeCheckツールを実行して、警告が発行されていないことを確認します。
MS_CLI/Maintenance/Tools> upgradeCheck MS_Rel_2022.11_1.273qcurrentコマンドを使用して、現在使用されているポート数を確認します。
MS_CLI/Monitoring/Report> qcurrent新しいバージョンのアクティブ化を開始する前に、NSからメディアの送信を停止するため、NSのMS状態をオフラインに設定します
NS_CLI/System/Device/ResourceNE> set ms1 state OffLine
...Done
NS_CLI/System/Device/ResourceNE> get
About to filter through 2 entries. Continue?
Please confirm (Yes, Y, No, N): y
Retrieving data... Please wait...
Resource NE Type Location Stat Cost Stat Weight Poll OpState State Dflt Dflt Cost Dflt Weight Services
======================================================================================================================
ms1 ms 1847744 1 99 false enabled OffLine true 1 99 all
ms2 ms 1847744 1 99 false enabled OnLine true 1 99 all
2 entries found.
NS_CLI/System/Device/ResourceNE> MSアップグレードスイッチ
次のコマンドを実行して、アップグレードを開始します。
MS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server MS 2022.11_1.273
+++ WARNING +++ WARNING +++ WARNING +++
This command will change the active software version of MS to 2022.11_1.273. NOTE that this action will cause downtime.
Continue?
Please confirm (Yes, Y, No, N): yMSのアップグレード後のチェック
アップグレード後、起動後のMSステータスを確認し、ボイスメールおよびボイスメールの取得を残すことを確認します。
healthmon -lショーランbwshowver（ダウンロード）メディアを受信するため、NSのMS状態をonLineに戻します。
推奨されるMSアップグレード後テスト
- ボイスメールの登録と取得が正常に行われたことを検証します。
- 正常なIVRインタラクションを検証します。
- 正常な3方向コールを検証します。
これらのテストは一般的なものであり、アップグレード後のテスト計画に含まれる追加のテストを実行します。
MS復元
MSがアップグレード後のチェックに合格しない場合は、以前のリリースに戻します。
MS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server MS 2022.08_1.350 revert
+++ WARNING +++ WARNING +++ WARNING +++
This command will change the active software version of MS to 2022.08_1.350. NOTE that this action will cause downtime.
Continue?
Please confirm (Yes, Y, No, N): y前の例では、2022.08_1.350に戻していますが、これはすべての以前のリリースに置き換えることができます。
アプリケーションサーバ(AS)
healthmonに問題がないことを確認します。
--------------------------------
System Health Report Page
BroadWorks Server Name: as1
Date and time : Thu Oct 3 15:50:21 BST 2022
Report severity : NOTIFICATION
Server type : AppServer
Server state : Unlock
--------------------------------
No abnormal condition detected.
-------------------------------- ログを調べて、両方のASがコールを処理していることを確認します（AS1をロックすることで、新しいコールを強制的にセカンダリに送ることができます）。
- Webサーバおよび各ASを介したWebアクセスを検証します。
バックアップとテクニカルサポート
アップグレードの前に、からテクニカルサポートのバックアップを取ってログに記録しておくことを推奨します。
$ bwBackup.pl AppServer AS_hostname_sourceRelease.tar
$ tech-support >> tsup_hostname_sourceRelease.txtアップグレード前
upgradeCheckツールを実行して、警告が発行されていないことを確認します。
AS_CLI/Maintenance/Tools> upgradeCheck AS_Rel_2023.03_1.411
注:/var/broadworks/eccrまたは/var/broadworks/eclディレクトリ内のファイルが原因でupgradeCheckが失敗した場合は、bwcliから「lock force」が実行されるまで待機します。これにより、数分以内にファイルがDBSにパージされます。
セカンダリASでデータベースの同期(synchcheck_basic.pl -a)を確認します。
$ synchcheck_basic.pl -aextensionTimeInSecondsを10800（3時間）に設定して、サーバのアップグレードのために予約された時間に合わせます。
AS_CLI/System/Registration> set extensionTimeInSeconds 10800通常、この設定は、『システム設定ガイド』に従って2400をアップグレードしない場合の設定です。
複製はこの変更をクラスタ内の残りのサーバにプッシュします。
スケジューラからバックアップオペレーションを削除します。
AS_CLI/Maintenance/Scheduler> get
Id Name Date Day Hour Minute
=================================================================
5 backup - saturday 4 03アップグレード中にバックアップがトリガーされると、アクティブ化中に問題が発生します。
AS_CLI/Maintenance/Scheduler> del 5プライマリASのロック
プライマリASをロックします。新しいコールはセカンダリを経由するため、切り替えを実行する前にプライマリのアクティブコールの数をドロップできます（切り替えまたはロック強制によってアクティブコールがドロップします）。
AS_CLI/Maintenance/ManagedObjects> lock
+++ WARNING +++ WARNING +++ WARNING +++
This command will lock the server. Note that this action could cause downtime.
The server state is persisted across server restarts and upgrade.
A server in "Locked" state will need to be manually unlocked after a server
restart or upgrade. Continue?
Please confirm (Yes, Y, No, N): y
...Done完了したら、qcurrentコマンドを使用してASのコール数を確認します。
AS_CLI/Monitoring/Report> qcurrentプライマリASアップグレードスイッチ
コールが許容レベルに下がったら、次の手順でアップグレードを開始します。
AS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server AS 2023.03_1.411
+++ WARNING +++ WARNING +++ WARNING +++
This command will change the active software version of AS to 2023.03_1.411 . NOTE that this action will cause downtime.
Continue?
Please confirm (Yes, Y, No, N): y完了したら、サーバのロックを解除します。
AS_CLI/Maintenance/ManagedObjects> unlockbwPeriodMaint.shを使用してDB統計情報を更新します。
$ bwPeriodMaint.shこのコマンドは出力を返しません。
スケジューラからバックアップオペレーションを削除したので、アップグレード後に再び追加する必要があります。これは推奨値です。アップグレード前に設定した値に追加し直す必要があります。
AS_CLI/Maintenance/Scheduler> add backup day saturday 4 3プライマリASのアップグレード後のアクション
ASのアップグレード後のチェック
アップグレード後、起動後のASステータスを確認し、登録とコールを確認します。
healthmon -l- ピアが同期されていないことが示されますが、これはセカンダリがアップグレードされるまで予想されます。
ショーランbwshowver（ダウンロード）- アクティベーションエラーの可能性については、/var/broadworks/logs/maintenance/ setactiveserver.AS.Rel_2023.03_1.411 .<date-time>.logファイルを確認してください。
- ASテストを実行して、このASがコールを正しく処理していることを確認します。
アップグレード後のテストとして推奨
- SIP発信コールを検証します。
- メディアゲートウェイコントロールプロトコル(MGCP)発信コールを検証します。
- PSTNからSIPへのユーザ着信コールを検証します。
- PSTNからMGCPへのユーザ着信コールを検証します。
- ボイスメールの発信/取得（音声ポータル）を検証します。
- CommPilotの開始/終了を検証します。
- CLIアクセスを検証します（AS_CLI/System/Aliasに移動し、getコマンドを使用します）。
- ASへの直接Webアクセスを検証します。
ローカライズされた音声プロンプト
R25にアップグレードすると、カスタム音声プロンプトがソースリリースから自動的にコピーされます。「機能の説明」のセクション4.5を参照してください。
AS復元
ASがアップグレード後のチェックに合格しなかった場合は、以前のリリースに戻します。
AS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server AS 2022.08_1.354 revert
+++ WARNING +++ WARNING +++ WARNING +++
This command will change the active software version of AS to 2022.08_1.354. NOTE that this action will cause downtime.
Continue?
Please confirm (Yes, Y, No, N): yこの例では、2022.08_1.354に戻されていますが、これはすべての以前のリリースに置き換えることができます。
セカンダリASにはデータベースの最新バージョンがあるため、そこからDBをインポートします。
セカンダリAS上：
$ repctl startプライマリASで次のコマンドを実行します。
$ stopbw
$ repctl stop
$ importdb.pl appserver appserver
$ repctl start
$ startbwセカンダリASデータベースのロックを解除します。
$ peerctl unlock復元されたプライマリASでレプリケーションが実行されていることを確認します。
$ repctl statusセカンダリASでレプリケーションが実行されていること、およびデータベースがロック解除されていることを確認します。
$ repctl status
$ peerctl unlockすべてのASでhealthmon -lにチェックマークを付けます。報告された重大度がすべてのサーバに対する通知であることを確認します。
セカンダリASデータベースとプライマリASデータベースが同期されていることを確認します（セカンダリで）。
$ synchcheck_basic.pl -aセカンダリASアップグレードスイッチ
次のコマンドを入力して、アップグレードを開始します。
AS_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server AS 2023.03_1.411
+++ WARNING +++ WARNING +++ WARNING +++
This command will change the active software version of AS to 2023.03_1.411. NOTE that this action will cause downtime.
Continue?
Please confirm (Yes, Y, No, N): ybwPeriodMaint.shスクリプトを実行して、データベース統計情報を更新します。
$ bwPeriodMaint.shセカンダリASのアップグレード後のアクション
ASのアップグレード後のチェック
アップグレード後、起動後のASステータスを確認し、登録とコールを確認します。
healthmon -lショーランbwshowver（ダウンロード）- アクティベーションエラーの可能性については、/var/broadworks/logs/maintenance/ setactiveserver.AS.Rel_2023.03_1.411.<date-time>.logファイルを確認してください。
- このASがコールを正しく処理していることを確認するには、ASテストを実行します。
アップグレード後のテストとして推奨
- プライマリASをロックして、新しいコールをセカンダリに強制的に発信します。
- SIP発信コールを検証します。
- MGCP発信コールを検証します。
- PSTNからSIPへのユーザ着信コールを検証します。
- PSTNからMGCPへのユーザ着信コールを検証します。
- ボイスメールの発信/取得（音声ポータル）を検証します。
- CommPilotの開始/終了を検証します。
- CLIアクセスを検証します（AS_CLI/System/Aliasに移動し、getコマンドを使用します）。
- ASへの直接Webアクセスを検証します。
クラスタ後テスト
- すべてのサーバに対してhealthmonレポートの重大度NOTIFICATIONを確認します。
- データベース同期の確認：
$ healthmon -l
$ synchcheck_basic.pl –aサービスコントロール機能(SCF)
healthmonに問題がないことを確認します。
--------------------------------
System Health Report Page
BroadWorks Server Name: scf1
Date and time : Fri Nov 8 11:30:38 GMT 2022
Report severity : NOTIFICATION
Server type : ServiceControlFunction
Server state : Unlock
--------------------------------
No abnormal condition detected.
--------------------------------- ログを調べて、SCFがコールを処理していることを確認します。
バックアップとテクニカルサポート
サーバをアップグレードする前に、アップグレードの前にからテクニカルサポートのバックアップを取ってログに記録しておくことを推奨します。これは次の機能によって実現されます。
$ bwAutoBackup.sh
$ tech-support >> tsup_hostname_sourceRelease.txtアップグレード前
現在の機能が正常に動作していることを確認するために、モバイルネットワークからのテストコール。
upgradeCheckツールを実行して、警告が発行されていないことを確認します。
SCF_CLI/Maintenance/Tools> upgradeCheck SCF_Rel_2023.03_1.411冗長構成の場合は、サーバをロックして、他のSCFへのコールを強制的に行います。
SCF_CLI/Maintenance/ManagedObjects> lockSCFアップグレードスイッチ
コールが許容レベルに下がったら、次の手順でアップグレードを開始します。
SCF_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server SCF 2023.03_1.411
+++ WARNING +++ WARNING +++ WARNING +++
This command will change the active software version of SCF to 2023.03_1.411. NOTE that this action will cause downtime.
Continue?
Please confirm (Yes, Y, No, N): y完了したら、サーバのロックを解除し、コールをテストします。
SCF_CLI/Maintenance/ManagedObjects> unlockSCFのアップグレード後のチェック
アップグレード後、SS7ログで正常な起動を確認します。
healthmon -lショーランbwshowver（ダウンロード）- /var/broadworks/logs/maintenance/ setactiveserver.SCF.Rel_2023.03_1.411.<date-time>.logファイルで、潜在的なアクティベーションエラーを確認します。
- テストを実行して、このSCFがコールを正しく処理していることを確認します。
- モバイルネットワークからBroadWorksコアへの通話が、アップグレード前と同様に機能していることを確認します。
SCFサーバの復元
SCFがアップグレード後のチェックに合格しなかった場合は、前のリリースに戻します。
SCF_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server SCF 2022.10_1.313 revert
+++ WARNING +++ WARNING +++ WARNING +++
This command will change the active software version of SCF to 2022.10_1.313. NOTE that this action will cause downtime.
Continue?
Please confirm (Yes, Y, No, N): yこの例では、2022.10_1.313に戻されていますが、これはすべての以前のリリースに置き換えることができます。
アプリケーション配信プラットフォーム(ADP)
healthmonに問題がないことを確認します。
--------------------------------
System Health Report Page
BroadWorks Server Name: adp1
Date and time : Fri Nov 8 11:30:38 GMT 2022
Report severity : NOTIFICATION
Server type : ApplicationDeliveryPlatform
Server state : Unlock
--------------------------------
No abnormal condition detected.
--------------------------------バックアップとテクニカルサポート
サーバをアップグレードする前に、アップグレードの前にからテクニカルサポートのバックアップを取ってログに記録しておくことを推奨します。これを行うには、次のコマンドを使用します。
$ bwAutoBackup.sh
$ tech-support >> tsup_hostname_sourceRelease.txtアップグレード前
upgradeCheckツールを実行して、警告が発行されていないことを確認します。
ADP_CLI/Maintenance/Tools> upgradeCheck ADP_Rel_2022.10_1.313新しいソフトウェアバージョンのアクティベーションの前にサーバをロックします。
ADP_CLI/Maintenance/ManagedObjects> lockR23のADP/PSからRIに移行する場合のECLQueryアプリケーションの配置解除および非アクティブ化
ADPを最新のRIにアップグレードする前に、R23上のソースADP/PSでECLQueryアプリケーションが実行されている場合は、ECLQueryアプリケーションをNDSに移行する必要があります。『データベースサーバからネットワークデータベースサーバへの拡張コールログ移行』を参照してください。
ADP_CLI/Maintenance/ManagedObjects> undeploy application /ECLQuery
ADP_CLI/Maintenance/ManagedObjects> deactivate application /ECLQueryこの操作を行わないと、新しいリリースのアクティベーション後にADPに「bwCentralizedDatabaseListenerFailure」アラームが表示されます。
ソースリリースに配備されたアプリケーションと一致するADP RI/RAアプリケーションのアップロード
ADP BroadWorksサーバでは、ソースリリースに現在導入されているアプリケーションのRI/RAバージョンをCisco.comからダウンロードする必要があります。必要なアプリケーションのリストを取得するには、次の操作を実行します。
ADPで次のように入力します。
$ bwshowver
ADP version Rel_2022.11_1.273
Applications Info:
- OpenClientServer version 2022.11_1.273
- WebContainer version 2022.11_1.273
- OCIOverSoap version 2022.11_1.273 context path /webservice
- CommPilot version 2022.11_1.273 context path /
- Xsi-Actions version 2022.11_1.273 context path /com.broadsoft.xsi-actions
- Xsi-Events version 2022.11_1.273 context path /com.broadsoft.xsi-events
- Xsi-VTR version 2022.11_1.273 context path /vtr
- OCIFiles version 2022.11_1.273 context path /ocifiles
- BroadworksDms version 2022.11_1.273 context path /dms
- AuthenticationService version 2022.11_1.273 context path /authservice「アプリケーション情報」の後に表示されるアプリケーションはすべて、ADPに導入され、Cisco.comからADP互換バージョンをダウンロードする必要があるアプリケーションです。最新バージョンをダウンロードします。前述の例に基づくアプリケーションの例：
OCS_2023.01_1.193.bwar
OCIOverSoap_2023.01_1.193.bwar
Xsi-Actions-24_2023.01_1.010.bwar
Xsi-Events-24_2023.01_1.010.bwar
CommPilot-24_2023.01_1.010.bwar
Xsi-VTR-24_2023.01_1.010.bwar
OCIFiles_2023.01_1.010.bwar
dms_2023.01_1.193.bwar
ダウンロードしたbwar / warファイルをADPにコピーし、/usr/local/broadworks/appsディレクトリに配置します。
$ cd <bwar / war directory location>
$ cp OCS_2023.01_1.193.war /usr/local/broadworks/apps/
$ 残りのアップグレードは、通常のBroadWorksのアップグレードです。
アップグレード前
upgradeCheckツールを実行して、警告が発行されていないことを確認します。
ADP_CLI/Maintenance/Tools> upgradeCheck ADP_Rel_2023.03_1.411ADPアップグレードスイッチ
次のコマンドを入力して、アップグレードを開始します。
ADP_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server ADP 2023.03_1.411
+++ WARNING +++ WARNING +++ WARNING +++
This command will change the active software version of ADP to 2023.03_1.411. NOTE that this action will cause downtime.
Continue?
Please confirm (Yes, Y, No, N): yADPのアップグレード後のアクション
アプリケーションのアップグレード
WebContainerアプリケーションは自動的にアップグレードされます。その他のアプリケーションは、Cisco BroadWorksアプリケーションとWebアプリケーションの2種類に分類されます。アップグレード手順は、アプリケーションがCisco BroadWorksアプリケーションかWebアプリケーションかによって異なります。
- Cisco BroadWorksアプリケーションは、BroadWorks ARchive(.bwar)ファイルとしてパッケージ化されています。
- Webアーカイブ(.war)ファイルとしてパッケージ化されたWebアプリケーション。
qbwコマンドを入力し、各アプリケーションとその展開されたコンテキストパスに対して現在アクティブなバージョンを確認します。
Webアプリケーションのアップグレード
Webアプリケーションをアップグレードするには、現在のバージョンを非アクティブ化および展開解除してから、新しいバージョンをアクティブ化および展開します。
ADP_CLI/Maintenance/ManagedObjects> undeploy application /callcenter
ADP_CLI/Maintenance/ManagedObjects> deactivate application /callcenter
ADP_CLI/Maintenance/ManagedObjects> activate application BWCallCenter 2023.04_1.150 /callcenter
ADP_CLI/Maintenance/ManagedObjects> deploy application /callcenterCisco BroadWorksアプリケーションのアップグレード
Cisco BroadWorksアプリケーションは、set activeSoftwareVersion applicationコマンドを使用してbwcliからアップグレードします。
詳細は『アプリケーションリリースノート』および『アプリケーション導入プラットフォーム設定ガイド』を参照してください。
ADP_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion application LoadBalancer 2023.02_1.090
+++ WARNING +++ WARNING +++ WARNING +++ Upgrading an application will cause downtime for the targeted component. Continue?
Please confirm (Yes, Y, No, N): y
--> Stopping application LoadBalancer <--
Stopping [done]
BroadWorks SW Manager upgrading LoadBalancer to version 2023.02_1.090 ...DoneADPアプリケーションのロールバック
何らかの理由でアプリケーションを以前のバージョンにロールバックする必要がある場合、このプロセスはアップグレードと同様です。ロールバック操作の実行後に、アップグレード後およびロールバック前に行われた構成変更は失われます。これは、変更が非アクティブなソフトウェアバージョンに対して行われたためです。
Webアプリケーションのロールバック
Webアプリケーションを元に戻すには、現在のバージョンを非アクティブ化して展開を解除し、新しいバージョンをアクティブ化して展開します。
ADP_CLI/Maintenance/ManagedObjects> undeploy application /callcenter
ADP_CLI/Maintenance/ManagedObjects> deactivate application /callcenter
ADP_CLI/Maintenance/ManagedObjects> activate application BWCallCenter 2023.04_1.150 /callcenter
ADP_CLI/Maintenance/ManagedObjects> deploy application /callcenter
Cisco BroadWorksアプリケーションのロールバック
Cisco BroadWorksアプリケーションは、set activeSoftwareVersion applicationコマンドを使用して、bwcliから復帰します。
ADP_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion application LoadBalancer 2020.09_1.090
+++ WARNING +++ WARNING +++ WARNING +++ Upgrading an application will cause downtime for the targeted component. Continue?
Please confirm (Yes, Y, No, N): y
--> Stopping application LoadBalancer <--
Stopping [done]
BroadWorks SW Manager upgrading LoadBalancer to version 2020.09_1.090 ...DoneADPのアップグレード後のチェック
アップグレード後、正常に起動したかどうかをログで確認し、以前と同様にGUIにログインします。
healthmon -lショーランbwshowver（ダウンロード）- /var/broadworks/logs/maintenance/ setactiveserver.ADP.Rel_2023.03.0_1.1411.<date-time>.logファイルで、潜在的なアクティベーションエラーを確認します。
推奨されるADPアップグレード後テスト
- 管理者レベルのログインを確認します。
- ユーザレベルのログインを確認します。
- CommPilot Call Managerの機能を検証します。
- コール制御クライアント（BroadWorks Assistant-Enterpriseなど）およびオペレーションサポートシステム(OSS)/オープンクライアントインターフェイス(OCI)機能の検証
- ASまたはNSへのOpen Client Server(OCS)プロキシプロビジョニングが正常に機能していることを確認します。
これらのテストは一般的なものであり、アップグレード後のテスト計画に含まれる追加のテストを実行します。
ADPサーバの復帰
ADPがアップグレード後のチェックに合格しない場合は、以前のリリースに戻します。
ADP_CLI/Maintenance/ManagedObjects> set activeSoftwareVersion server ADP 2022.10_1.313 revert
+++ WARNING +++ WARNING +++ WARNING +++
This command will change the active software version of ADP to 2022.10_1.313. NOTE that this action will cause downtime.
Continue?
Please confirm (Yes, Y, No, N): yこの例では、2022.10_1.313に戻されていますが、これはすべての以前のリリースに置き換えることができます。
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
2.0 |
28-Oct-2025
|
公開標準に沿って改訂され、TACの実行したアップグレードに関する情報が削除されました。 |
1.0 |
21-Jul-2023
|
初版 |
フィードバック