サブスクライバからのCUCMパブリッシャの再構築
内容
概要
このドキュメントでは、事前のバックアップやルートアクセスなしで、サブスクライバデータベースからCisco Unified Communications Manager(CUCM)パブリッシャノードを復元する方法について説明します。
バックグラウンド
CUCMの初期のバージョンでは、パブリッシャノードは構造化照会言語(SQL)DBの唯一の権威ソースと見なされていました。
したがって、ハードウェア障害やファイルシステムの破損が原因でパブリッシャノードが失われた場合、パブリッシャノードを回復する唯一の方法は、DRS（ディザスタリカバリシステム）バックアップからデータベースを再インストールして復元することです。
一部のお客様では、適切なバックアップを保持しなかったり、古いバックアップが存在していたため、唯一の選択肢は、パブリッシャサーバノードを再構築して再設定することでした。
CUCMバージョン8.6(1)では、サブスクライバデータベースからパブリッシャDBを復元するための新機能が導入されました。
このドキュメントでは、サブスクライバからパブリッシャDBを正常に復元するために、この機能を利用する方法について説明します。
クラスタ全体の完全なディザスタリカバリフレームワーク(DRF)バックアップを保持することを強く推奨します。
このプロセスはCUCM DB設定のみをリカバリするため、証明書、保留音(MoH)、TFTPファイルなどの他のデータはリカバリされません。これらの問題を回避するには、クラスタ全体のDRFバックアップを保持します。
クラスタデータの収集
パブリッシャを再インストールする前に、前のパブリッシャに関する詳細情報を収集することが重要です。これらの詳細は、元のパブリッシャのインストールと一致している必要があります。
- IP アドレス
- ホスト名
- ドメイン名
- セキュリティパスフレーズ
- 正確なCUCMバージョン
- インストール済みのCisco Options Package(COP)ファイル
リストの最初の3つの項目を取得するには、現在のサブスクライバノードのCLIでshow network clusterコマンドを入力します。
admin:show network cluster
172.18.172.213 cucm911ccnasub1 Subscriber authenticated
172.18.172.212 cucm911ccnapub Publisher not authenticated - INITIATOR
since Tue Dec 3 12:43:24 2013
172.18.172.214 cucm911ccnasub2 Subscriber authenticated using TCP since
Sun Dec 1 17:14:58 2013
この場合、IPアドレスは172.18.172.212、ホスト名はcucm911ccnapubであり、パブリッシャに対してドメイン名が設定されていません。
セキュリティパスフレーズ（リストの4番目の項目）は、サイトのドキュメントから取得されます。
セキュリティパスフレーズが不明な場合は、最善の方法で推測し、CUCMのバージョンに基づいて必要に応じて確認および修正できます。
セキュリティパスフレーズが正しくない場合、この状況を修正するにはクラスタの停止が必要です。
正確なCUCMのバージョンとインストールされているCOPファイル（リストの最後の2つの項目）を取得するには、show version activeコマンドからシステム出力を収集します。
admin:show version active
Active Master Version: 9.1.2.10000-28
Active Version Installed Software Options:
No Installed Software Options Found.
この場合、バージョン9.1.2.10000-28はアドオンCOPファイルなしでインストールされます。
すべてのサブスクライバでレプリケーションを停止する
パブリッシャをインストールする際には、レプリケーションによって現在のサブスクライバDBが設定および削除されないことが重要です。これを防ぐには、すべてのサブスクライバでutils dbreplication stopコマンドを入力します。
admin:utils dbreplication stop
********************************************************************************
This command can delete the marker file(s) so that automatic replication setup
is stopped
It can also stop any replication setup currently executing
********************************************************************************
Deleted the marker file, auto replication setup is stopped
Service Manager is running
Commanded Out of Service
A Cisco DB Replicator[NOTRUNNING]
Service Manager is running
A Cisco DB Replicator[STARTED]
Completed replication process cleanup
Please run the command 'utils dbreplication runtimestate' and make sure all nodes
are RPC reachable before a replication reset is executed
CUCMパブリッシャのインストール
適切なバージョンのブート可能なイメージを収集し、適切なバージョンにアップグレードしてインストールを実行します。
パブリッシャをインストールし、前述のIPアドレス、ホスト名、ドメイン名、およびセキュリティパスフレーズに正しい値を指定します。
パブリッシャのプロセスノード値の更新
ノードリストを取得するには、現在のサブスクライバのCLIでrun sql select name,description,nodeid from processnodeコマンドを入力します。
名前の値には、ホスト名、IPアドレス、または完全修飾ドメイン名(FQDN)を使用できます。
CUCMバージョン10.5(2)以降を実行する場合、ノードをSystem > Serverに追加する前に、パブリッシャのCLIでutils disaster_recovery prepare restore pub_from_subコマンドを実行する必要があります。
ノードリストを受信したら、System > Serverの順に移動し、EnterpriseWideData以外のすべての名前の値をPublisher Server Unified CM Administrationページに追加します。
名前の値は、System > ServerメニューのHost Name/IP Addressフィールドに対応している必要があります。
admin:run sql select name,description,nodeid from processnode
name description nodeid
================== =============== ======
EnterpriseWideData 1
172.18.172.212 CUCM901CCNAPub 2
172.18.172.213 CUCM901CCNASub1 3
172.18.172.214 CUCM901CCNASub2 4
パブリッシャノードのリブート
プロセスノードの変更が完了した後でパブリッシャを再起動するには、utils system restartコマンドを入力します。
admin:utils system restart
Do you really want to restart ?
Enter (yes/no)? yes
Appliance is being Restarted ...
Warning: Restart could take up to 5 minutes.
Shutting down Service Manager. Please wait...
\Service Manager shutting down services... Please Wait
Broadcast message from root (Tue Dec 3 14:29:09 2013):
The system is going down for reboot NOW!
Waiting .
Operation succeeded
クラスタ認証の確認
パブリッシャが再起動した後、変更を正しく行い、セキュリティパスフレーズが正しい場合、クラスタは認証済み状態である必要があります。これを確認するには、show network clusterコマンドを入力します。
admin:show network cluster
172.18.172.212 cucm911ccnapub Publisher authenticated
172.18.172.213 cucm911ccnasub1 Subscriber authenticated using TCP since
Tue Dec 3 14:24:20 2013 172.18.172.214 cucm911ccnasub2 Subscriber authenticated using TCP since
Tue Dec 3 14:25:09 2013
新しいバックアップの実行
使用可能な以前のバックアップがない場合は、DRSページでクラスタバックアップを実行します。
使用可能なバックアップがない場合は、新しいバックアップを実行します。バックアップがすでに存在する場合は、このセクションをスキップできます。
バックアップデバイスの追加
ナビゲーションメニューを使用して、ディザスタリカバリシステムに移動し、バックアップデバイスを追加します。
手動バックアップの開始
バックアップデバイスを追加したら、手動バックアップを開始します。
サブスクライバDBからのパブリッシャの復元
Disaster Recovery Systemページで、Restore > Restore Wizardの順に移動します。
現在のバックアップが使用可能であり、前のセクションをスキップした場合は、[機能の選択]セクションで、Enterprise License Manager(ELM)（使用可能な場合）、CDR_CAR、およびUnified Communications Manager(UCM)のすべての機能チェックボックスをオンにします。
前のセクションで実行したバックアップを使用する場合は、UCMチェックボックスだけをオンにします。
[Next] をクリックします。パブリッシャノードのチェックボックス(CUCM911CCNAPUB)をオンにし、復元が行われるサブスクライバDBを選択します。次に、Restoreをクリックします。
復元ステータス
復元がCCMDBコンポーネントに到達すると、「Status」テキストが「Restoring Publisher from Subscriber Backup」と表示される必要があります。
パブリッシャデータベースでの健全性チェックの実行
再起動してレプリケーションを設定する前に、リストアが正常に行われ、パブリッシャDBに必要な情報が含まれていることを確認することをお勧めします。
次のクエリを実行する前に、パブリッシャノードとサブスクライバノードで同じ値が返されることを確認してください。
- デバイスからsql select count(*)を実行
- エンドユーザーからsql select count(*)を実行する
クラスタのリブート
復元が完了したら、各ノードでutils system restartコマンドを入力します。パブリッシャから開始し、その後に各サブスクライバを続けます。
admin:utils system restart
Do you really want to restart ?
Enter (yes/no)? yes
Appliance is being Restarted ...
Warning: Restart could take up to 5 minutes.
Shutting down Service Manager. Please wait...
\ Service Manager shutting down services... Please Wait
Broadcast message from root (Tue Dec 3 14:29:09 2013):
The system is going down for reboot NOW!
Waiting .
Operation succeeded
レプリケーション設定の要件の確認
Cisco Unified Reportingページに移動し、Unified CMデータベースステータスレポートを生成します。
レプリケーションはまだ設定されていない可能性がありますが、Unified CMホスト、Unified CM Rhosts、およびUnified CM Sqlhostsファイルがパブリッシャと一致していることを確認することが重要です。
一致しない場合は、一致しないノードを再度リブートする必要があります。これらのファイルが一致しない場合は、次の手順に進んだり、レプリケーションをリセットしたりしないでください。
複製の設定
バージョンによっては、レプリケーションを自動的に設定できません。これを確認するには、すべてのサービスが起動するのを待って、utils dbreplication runtimestateコマンドを入力します。
状態の値0はセットアップが進行中であることを示し、値2は、そのノードのレプリケーションが正常にセットアップされていることを示します。
次の出力は、レプリケーションのセットアップが進行中であることを示しています(状態は、2つのノードに対して0として表示されます)。
次の出力は、レプリケーションが正常にセットアップされたことを示しています。
状態値4を持つノードが表示された場合、または複製が数時間後に正常に設定されない場合は、パブリッシャノードからutils dbreplication reset allコマンドを入力します。
レプリケーションが引き続き失敗する場合、問題のトラブルシューティング方法の詳細については、シスコの記事「LinuxアプライアンスモデルでのCUCMデータベースレプリケーションのトラブルシューティング」を参照してください。
復元後
DBの復元では以前のコンポーネントがすべて復元されるわけではないため、多くのサーバレベルの項目は手動でインストールまたは復元する必要があります。
サービスのアクティブ化
DRFの復元では、サービスはアクティブになりません。Tools > Service Activationの順に移動し、Unified Serviceabilityページのサイトのドキュメントに基づいて、パブリッシャが実行する必要のある必要なサービスをアクティブにします。
復元されなかったデータのインストール
完全バックアップが使用できない場合は、特定の手動設定を再現する必要があります。特に、証明書とTFTP機能を含む設定は次のとおりです。
- MoHファイル
- デバイスパック
- ダイヤルプラン(北米以外の番号計画(NANP)ダイヤル用)
- ロケール
- その他のCOPファイル
- 以前にパブリッシャに手動でアップロードされたファイル（TFTPサーバの場合）
- Simple Network Management Protocol（SNMP）のコミュニティ ストリング
- Extension Mobility Cross Cluster(EMCC)、Intercluster Location Bandwidth Manager(LBM)、およびIntercluster Lookup Service(ILS)の証明書の一括エクスポート
- セキュアなトランク、ゲートウェイ、および会議ブリッジの証明書交換
トラブルシュート
このセクションでは、この手順が失敗する原因となる可能性のあるさまざまなシナリオについて説明します。
クラスタが認証されない
クラスタが認証されない場合、最も一般的な2つの原因は、セキュリティパスフレーズの不一致とTCPポート8500の接続の問題です。
クラスタセキュリティパスフレーズが一致することを確認するには、両方のノードのCLIでutils create report platformコマンドを入力し、platformConfig.xmlファイルのハッシュ値を調べます。これらはパブリッシャノードとサブスクライバノードで一致している必要があります。
<IPSecSecurityPwCrypt>
<ParamNameText>Security PW for this node</ParamNameText>
<ParamDefaultValue>password</ParamDefaultValue><ParamValue>0F989713763893AC831812812AB2825C8318
12812AB2825C831812812AB2825C </ParamValue>
</IPSecSecurityPwCrypt>
これらが一致する場合は、ポート8500のTCP接続を確認します。これらが一致しない場合、手順を取り囲むCUCMコードにいくつかの不具合があるため、パスフレーズを修正するときに問題が発生する可能性があります。
- Cisco Bug ID CSCtn79868:pwrecoveryツールがsftpuserパスワードだけをリセットする
- Cisco Bug ID CSCug92142 - pwrecoveryツールで内部ユーザパスワードが更新されない
- Cisco Bug ID CSCug97360:pwrecoveryユーティリティでのselinux denials
- Cisco Bug ID CSCts10778：セキュリティパスワード回復手順で拒否がスローされる
- Cisco Bug ID CSCua09290:CLIの「set password user security」で正しいアプリケーションパスワードが設定されなかった
- Cisco Bug ID CSCtx45528:pwd reset cliで「good」が返されるが、パスワードは変更されない
- Cisco Bug ID CSCup30002:CUCM 10.5でセキュリティパスワードを変更した後、DBサービスがダウンする
- Cisco Bug ID CSCus13276:CUCM 10.5.2のセキュリティパスワード回復により、リブート時にDBが起動しない
CUCMバージョンにこれらのすべての問題に対する修正が含まれている場合、最も簡単な解決策は、すべてのノードで『Cisco Unified Communications Operating System Administration Guide, Release 10.0(1)』に記載されているパスワード回復手順を実行することです。
CUCMバージョンにこれらの問題の修正が含まれていない場合は、状況に応じて、Cisco Technical Assistance Center(TAC)で回避策を実行できます。
復元でCCMDBコンポーネントが処理されない
復元でDBコンポーネントが表示されない場合は、バックアップ自体にDBコンポーネントが含まれていない可能性があります。パブリッシャDBが実行され、クエリを受け入れることができることを確認し、新しいバックアップを実行します。
複製の失敗
レプリケーションの障害をトラブルシューティングするには、シスコの記事「LinuxアプライアンスモデルでのCUCMデータベースレプリケーションのトラブルシューティング」を参照してください。
電話機が登録されない、またはサービスにアクセスできない
DBの復元では証明書は復元されないため、パブリッシャがプライマリTFTPサーバの場合、署名者は異なります。
電話がSubscriber Trust Verification Service(TVS)証明書を信頼し、電話とTVSサーバ間でTCPポート2445が開いている場合、問題は自動的に解決される必要があります。
このため、完全なクラスタDRFバックアップを維持することをお勧めします。
バージョン8.6よりも前のCUCMバージョンでは、以前に正常にバックアップした場合でも、Cisco Bug ID CSCtn50405が原因で証明書の問題が発生する可能性があります。
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
11-Oct-2023 |
初版 |
フィードバック