内容

はじめに

公式ドキュメント

標準手順

インストール手順

ネットワーク機能マネージャ(NFM)

データベースサーバ(DBS)

ネットワークデータベースサーバ(NDS)

ネットワークサーバ(NS)

メディアサーバ(MS)

アプリケーションサーバ(AS)

サービスコントロール機能(SCF)

アプリケーション配信プラットフォーム(ADP)

はじめに

このドキュメントでは、BroadWorks Upgrade Teamが準拠するBroadWorksサーバを他の正式なソースからアップグレードする手順について説明します。

公式ドキュメント

これらのリファレンスドキュメントは『Cisco BroadWorks Documentation Guide Release 25』のページにあります。次の主要なドキュメントを参照してください。

- ソフトウェア管理ガイド

- システム構成ガイド

- メンテナンスガイド

- 26.0リリースノート

- 25.0リリースノート

- 24.0 ASリリースノート

リリース ノート

アップグレードの前に、ターゲットリリースのリリースノートを確認し、記載されている変更による潜在的な影響を測定します。ターゲットリリースのリリースノート、およびソースリリースとターゲットリリースの中間リリースを確認します。たとえば、23.0から25.0にアップグレードする場合は、24.0と25.0のリリースノートを確認する必要があります。

これらは、シスコの文書ページまたは提供されたリンクから入手できます。

標準手順

これは、サーバをアップグレードする順序です。ネットワークサーバ(NS)とメディアサーバ(MS)は、互いに関連して特定の順序でアップグレードする必要はありません。

ADPの最初のセットは、DBSObserver、DBManagement、およびその他のプロファイルサービスを実行するADPで構成されているため、アプリケーション配信プラットフォーム(ADP)はシーケンスの2回言及されます。2番目のADPセットは、拡張サービスインターフェイス(XSI)、オープンクライアントインターフェイス – プロビジョニング(OCI-P)、デバイス管理システム(DMS)、および通知プッシュサーバ(NPS)サービスで構成されます。

BroadWorksサーバをアップグレードする場合は、次の標準的な高度な手順に従ってください。

1. サーバをバックアップします。

2. 最新のリリース非依存(RI)インストールソフトウェアパッケージをインストールします。swmanagerはRIパッケージに含まれています。

3. ターゲットリリースライセンスをインストールします。

4. CLIからアップグレードチェックツールを実行して、警告がないことを確認します。
ADP_CLI/Maintenance/Tools> upgradeCheck ADP_Rel_2021.02_1.50

クラスタのメンバの1つをアップグレードする前に、必ず同じクラスタのすべてのピアにターゲットリリースをインストールしてください。

各サーバの完了したタスクを確認しておくと便利です。例：

マシン

サーバ1

サーバ2

サーバ3

バックアップ

Done

Done

テクニカルサポート

Done

…など…

ターゲットリリースのインストール

Done

ライセンスのインポート

Done

Healthmonチェック

Done

アップグレードチェック

Done

手順の期待値

このドキュメントの想定事項を以下に示します。

1. バックアップの実行、新しいバイナリのインストール、およびアップグレードを行うのに十分なディスク領域があります。

2. 各サーバには、パッケージをインストールする機能があります。

3. OSはターゲットリリースと互換性があります。

4. すべてのサーバでPre-InstallCheckが実行され、警告または障害が修正されました。

5. システムは正常な状態です。

6. 適切なライセンスが取得されている。

7. アップグレード後のテスト計画が作成され、アップグレードの前に実行され、結果が記録されました。

サーバ固有の注意事項

- 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): y

NFMでのライセンス管理

『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/$TAG

DBSObserverの停止

冗長構成の場合は、アップグレード中に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を復帰させるために必要な手順は同じであり、特定の順序で実行する必要があります。これらの手順では、両方の設定について説明します。

1. 古いCisco BroadWorksバージョンをアクティブにします。冗長構成の場合は、最初にスタンバイサーバを復帰させる必要があります。スタンバイを復帰させる場合は、バックアップの場所を指定しないでください。

2. 冗長構成の場合は、プライマリサーバの反転に進みます。

3. 復元後の検証を実行します。

シーケンス図に対応する手順を明確にするために、スタンバイ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 --cleanup

DBSの復元手順の詳細については、『DBSコンフィギュレーションガイド』を参照してください。

プライマリ/スタンバイスイッチをアップグレード前の状態に戻す

復元が完了したら、peerctlコマンドを使用して、サーバをアップグレード前のプライマリ/スタンバイ状態に戻します。例：

bwadmin@dbs1$ peerctl setPrimary dbs1

DBSObserverが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.273

NDSアップグレードスイッチ

クラスタでは、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): y

NDSのアップグレード後のチェック

アップグレード後、起動後に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.27

qcurrentコマンドで、現在使用されているコールなどの数を確認します。

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): y

bwPeriodMaint.shスクリプトを実行して、データベース統計情報を更新します。

$ bwPeriodMaint.sh

NSのアップグレード後のチェック

アップグレード後、起動後の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を入力します。

- ショーラン

- 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.273

qcurrentコマンドを使用して、現在使用されているポート数を確認します。

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): y

MSのアップグレード後のチェック

アップグレード後、起動後の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 -a

extensionTimeInSecondsを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> unlock

bwPeriodMaint.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): y

bwPeriodMaint.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> lock

SCFアップグレードスイッチ

コールが許容レベルに下がったら、次の手順でアップグレードを開始します。

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> unlock

SCFのアップグレード後のチェック

アップグレード後、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> lock

R23の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.411

ADPアップグレードスイッチ

次のコマンドを入力して、アップグレードを開始します。

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): y

ADPのアップグレード後のアクション

アプリケーションのアップグレード

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 /callcenter

Cisco 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 ...Done

ADPアプリケーションのロールバック

何らかの理由でアプリケーションを以前のバージョンにロールバックする必要がある場合、このプロセスはアップグレードと同様です。ロールバック操作の実行後に、アップグレード後およびロールバック前に行われた構成変更は失われます。これは、変更が非アクティブなソフトウェアバージョンに対して行われたためです。

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 ...Done

ADPのアップグレード後のチェック

アップグレード後、正常に起動したかどうかをログで確認し、以前と同様に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に戻されていますが、これはすべての以前のリリースに置き換えることができます。