以前のバックアップやルート アクセスがない状態で、サブスクライバから CUCM パブリッシャ ノードを復元する
目次
はじめに
このドキュメントでは、以前のバックアップやルート アクセスがない状態のサブスクライバ データベース（DB）から、Cisco Unified Communications Manager（CUCM）パブリッシャ ノードを回復する方法について説明します。
バックグラウンド
CUCMの初期バージョンでは、パブリッシャノードはStructured Query Language(SQL)DBの唯一の正規ソースと見なされていました。したがって、ハードウェアの障害やファイルシステムの破損によりパブリッシャノードが失われた場合、回復する唯一の方法は、ディザスタリカバリシステム(DRS)バックアップからDBを再インストールして復元することでした。
一部のお客様は、適切なバックアップを保持しなかったり、古いバックアップを保持していたりしたため、パブリッシャサーバのノードを再構築して再設定するしか方法がありませんでした。
CUCMバージョン8.6(1)では、サブスクライバデータベースからパブリッシャDBを復元するための新機能が導入されました。このドキュメントでは、サブスクライバからパブリッシャDBを正常に復元するために、この機能を利用する方法について説明します。
クラスタ全体の完全なディザスタリカバリフレームワーク(DRF)バックアップを保持することを強く推奨します。このプロセスはCUCM DB設定のみを回復するため、証明書、保留音(MoH)、TFTPファイルなどの他のデータは回復されません。これらの問題を回避するには、クラスタ全体のDRFバックアップを保持します。
クラスタデータの収集
パブリッシャを再インストールする前に、前のパブリッシャに関する詳細を収集することが重要です。次の詳細は、元のパブリッシャのインストールと一致している必要があります。
- IPアドレス
- ホスト名
- ドメイン名
- セキュリティパスフレーズ
- 正確なCUCMバージョン
- インストール済みのシスコオプションパッケージ(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 will delete the marker file(s) so that automatic replication setup
is stopped
It will 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)以降を実行する場合は、パブリッシャのCLIでutils disaster_recovery prepare restore pub_from_subコマンドを実行する必要があり、その後でSystem > Serverにノードを追加できます。
ノードリストを受信したら、[System] > [Server]に移動し、[EnterpriseWideData]以外のすべての名前値を[Publisher Server Unified CM Administration]ページに追加します。名前の値は、[システム(System)] > [サーバ(Server)]メニューの[ホスト名/IPアドレス(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 2013172.18.172.214 cucm911ccnasub2 Subscriber authenticated using TCP since
Tue Dec 3 14:25:09 2013
新しいバックアップの実行
以前のバックアップが使用できない場合は、[DRS]ページでクラスタバックアップを実行します。
使用可能なバックアップがない場合は、新しいバックアップを実行します。バックアップがすでに存在する場合は、このセクションをスキップできます。
バックアップデバイスの追加
[Navigation]メニューを使用して[Disaster Recovery System]に移動し、バックアップデバイスを追加します。
手動バックアップの開始
バックアップデバイスを追加したら、手動バックアップを開始します。
サブスクライバDBからのパブリッシャの復元
[ディザスタリカバリシステム]ページで、[復元] > [復元ウィザード]に移動します。現在のバックアップが利用可能で、前のセクションをスキップした場合は、[機能の選択]セクションのすべての機能チェックボックスをオンにします。Enterprise License Manager(ELM)(使用可能な場合)、CDR_CAR、およびUnified Communications Manager(UCM)。 前のセクションで実行したバックアップを使用する場合は、[UCM]チェックボックスのみをオンにします。
[Next] をクリックします。パブリッシャノードのチェックボックス(CUCM911CCNAPUB)をオンにし、復元の元となるサブスクライバDBを選択します。次に、[復元]をクリックします。
復元ステータス
リストアがCCMDBコンポーネントに達すると、[Status]テキストが[Restoring Publisher from Subscriber Backup]と表示されます。
パブリッシャDBでの健全性チェックの実行
再起動して複製を設定する前に、復元が成功し、パブリッシャのDBに必要な情報が含まれていることを確認することをお勧めします。続行する前に、次のクエリがパブリッシャノードとサブスクライバノードで同じ値を返すことを確認してください。
- sql select count(*)をデバイスから実行
- enduserから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 Hosts、Unified CM Rhosts、およびUnified CM Sqlhostsファイルがパブリッシャと一致していることを確認することが重要です。一致しない場合は、一致しないノードを再度リブートする必要があります。これらのファイルが一致しない場合は、次の手順に進んだり、複製をリセットしないでください。
複製の設定
バージョンによっては、レプリケーションが自動的に設定されない場合があります。これを確認するには、すべてのサービスが起動するまで待ち、utils dbreplication runtimestateコマンドを入力します。state値が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 toolでsftpuserパスワードのみをリセット
- Cisco Bug ID CSCug92142 - pwrecovery tool does not update the internal user passwords
- Cisco Bug ID CSCug97360 - pwrecovery utilityのselinux denials
- Cisco Bug ID CSCts10778 – セキュリティのパスワード回復手順でDenialsがスローされる
- Cisco Bug ID CSCua09290 - CLIの「set password user security」で正しいアプリケーションパスワードが設定されていない
- Cisco Bug ID CSCtx45528 - pwd reset cliは正常に戻りますが、パスワードは変更されません
- 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サーバの場合、署名者は異なります。電話機がサブスクライバ信頼検証サービス(TVS)証明書を信頼し、電話機とTVSサーバの間でTCPポート2445が開いている場合、問題は自動的に解決されます。このため、クラスタ全体のDRFバックアップを維持することをお勧めします。
バージョン8.6より前のCUCMのバージョンでも、Cisco Bug ID CSCtn50405が原因で、以前の正常なバックアップでも証明書の問題が発生する場合があります。
フィードバック