以前のバックアップやルート アクセスがない状態で、サブスクライバから CUCM パブリッシャ ノードを復元する
目次
概要
このドキュメントでは、以前のバックアップやルート アクセスがない状態のサブスクライバ データベース（DB）から、Cisco Unified Communications Manager（CUCM）パブリッシャ ノードを回復する方法について説明します。
背景説明
CUCM の以前のバージョンでは、パブリッシャ ノードは構造化照会言語 （SQL） DB における唯一の保証された 出典とみなされました。 その結果パブリッシャ ノードがハードウェア障害かファイルシステムの不良が失われた原因、それを回復 する唯一の方法はディザスタ リカバリ システム（DR）バックアップからの DB を再インストールし、復元するでした。
何人かの顧客は適切なバックアップを保存しませんでしたし、または旧式だった、従って唯一のオプションはパブリッシャ サーバ ノードを再製し、再構成することでしたバックアップがありませんでした。
CUCM バージョン 8.6(1)では加入者データベースからのパブリッシャ DB を復元するために、新しい 機能は導入されました。 この資料に正常にサブスクライバからのパブリッシャ DB を復元するのにこの機能を利用する方法を記述されています。
Cisco は全体のクラスタの完全なディザスタ リカバリ フレームワーク（DRF）バックアップを保存することを強く推奨します。 このプロセスが CUCM DB 設定だけを、他のデータ、証明書のような、Music on Hold （MoH）、および TFTP ファイル回復 するので、回復 されません。 これらの問題を避けるために、完全なクラスタ DRF バックアップを保存して下さい。
収集する クラスタ データ
パブリッシャを再インストールする前に、前のパブリッシャについての適切な詳細を収集することは重要です。 これらの詳細はオリジナル パブリッシャ インストールを一致する必要があります:
- IP アドレス
- ホスト名
- ドメイン名
- セキュリティ パスフレーズ
- 正確な CUCM バージョン
- インストール済み Cisco オプション パッケージ（COPS）ファイル
リストの最初の 3 つの項目を取得するために、現在の Subscriber ノード CLI で提示ネットワーク 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 バージョンおよびインストール済み COPS ファイル（リストの最後の 2 つの項目）を取得するために、show version アクティブなコマンドからのシステム出力を収集して下さい:
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 は付加 COPS ファイル無しでインストールされています。
すべてのサブスクライバの複製を停止して下さい
パブリッシャがインストールされているとき、複製が現在のサブスクライバ DB を設定しないし、削除することは重要です。 これを防ぐために、すべてのサブスクライバの utils dbreplication 停止コマンドを入力して下さい:
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 アドレス、ホスト名、ドメイン名およびセキュリティ パスフレーズの正しい値を規定 して下さい。
パブリッシャの Processnode 値をアップデートして下さい
ノード リストを取得するために、現在のサブスクライバの CLI で processnode コマンドから実行 SQL 選定された名前を、説明、nodeid 入力して下さい。 名の値はホスト名、IP アドレス、または完全修飾ドメイン名（FQDN）のどちらである場合もあります。
CUCM バージョン 10.5(2) または それ 以降を実行する場合、disaster_recovery が復元 pub_from_sub コマンドを準備する utils はパブリッシャ CLI で System > Server に Add ノードに進むことができる前に実行する必要があります:
ノード リストを受け取った後、System > Server にナビゲート し、EnterpriseWideData 以外パブリッシャ サーバによって統一される CM 管理 ページにネーム値すべてを追加して下さい。 ネーム値は System > Server メニューのホスト名/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
パブリッシャ ノードをリブートして下さい
processnode 変更が完了する後パブリッシャを再起動するために、utils システム 再始動 コマンドを入力して下さい:
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
クラスタ 認証を確認して下さい
パブリッシャが再起動した後、変更を正しく行なった、セキュリティ パスフレーズが正しければ場合、クラスタは認証された状態にあるはずです。 これを確認するために、提示ネットワーク 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
新しいバックアップを行って下さい
前のバックアップが利用できない場合、DR ページのクラスタ バックアップを行って下さい。
バックアップが利用できない場合、新しいものを行って下さい; 既に存在 する バックアップがそれからこのセクションをスキップできれば。
バックアップ デバイスを追加して下さい
ディザスタ リカバリ システムにナビゲート するために Navigation メニューを使用しバックアップ デバイスを追加して下さい。
手動バックアップを開始して下さい
バックアップ デバイスが追加された後、手動バックアップを開始して下さい。
サブスクライバ DB からのパブリッシャ 復元
ディザスタ リカバリ システム ページ、復元するべきナビゲート > Restore ウィザード。 現在のバックアップが利用できた、前のセクションをスキップしたら場合、選定された Features セクションの Feature チェックボックスすべてをチェックして下さい: エンタープライズ License Manager （ELM）もし可能であれば、CDR_CAR および Unified Communications Manager （UCM）。 前のセクションで実行された バックアップを使用したら、UCM チェックボックスだけチェックして下さい:
[Next] をクリックします。 パブリッシャ Node チェックボックス（CUCM911CCNAPUB）をチェックし、復元が起こるサブスクライバ DB を選択して下さい。 それから、『Restore』 をクリック して下さい。
ステータスを復元する
リストアが CCMDB コンポーネントに達するとき、ステータス テキストはサブスクライバ バックアップからのパブリッシャを復元するとして出る必要があります:
パブリッシャ DB の正常性チェックを実行して下さい
複製をリブートし、設定する前に、それはリストアが正常であること、そしてパブリッシャ DB が必要情報が含まれていることを確認する好ましい習慣です。 続行する前にこれらのクエリー リターン パブリッシャ および サブスクライバ ノードの同じ値ことを確認して下さい:
- デバイスから SQL 選定された数を（*）実行して下さい
- エンド ユーザーから SQL 選定された数を（*）実行して下さい
クラスタをリブートして下さい
リストアが完了する後、各ノードの utils システム 再始動 コマンドを入力して下さい。 各サブスクライバに先行させているパブリッシャから開始して下さい。
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 報告ページにナビゲート し、統一された CM データベース ステータス レポートを生成して下さい。 複製が統一された CM が、統一された CM Rhosts ですまだ設定しないかもしれませんが、統一された CM Sqlhosts ファイルはパブリッシャをホストしようにすることは重要一致する可能性が高いといえます。 それらが場合、一致するそれらのノードは再度リブートされる必要があります。 これらのファイルが一致する場合、次のステップかリセット 複製に進まないで下さい。
複製 セットアップ
バージョンに依存は、複製自動的に設定しないかもしれません。 開始し、utils dbreplication runtimestate コマンドを入力するためにこれ、待機をサービス全員があるように確認するため。 0 というステート値は複製のそのノードのために設定が完了することを 2 という値は示すがセットアップが進行中であることを示します。
この出力は複製 セットアップが進行中であることを示したものです（状態はノードの 2 のための 0 として現われます）:
この出力は複製の設定が完了することを示したものです:
どのノードでも 4 のステート値と現われるか、または複製が数時間後に設定を完了しなかったら、dbreplication がパブリッシャ ノードからのすべてのコマンドをリセットした utils を入力して下さい。 複製が失敗し続ける場合問題を解決する方法に関する詳細については Linux アプライアンス モデル Ciscoの記事のトラブルシューティング CUCM データベース複製を参照して下さい。
復元を掲示して下さい
DB リストアが前のコンポーネントすべてを復元するので、多くのサーバ レベル 項目は手動でインストールされるか、または復元する必要があります。
サービスのアクティブ化
DRF リストアはサービスをアクティブにしません。 Tools > Service アクティベーションにナビゲート し、統一されたサービサビリティ ページからのサイト ドキュメントに基づいて経営するパブリッシャが必要がある必要なサービスをアクティブにして下さい:
データをインストールして下さい復元する
完全バックアップが利用できなかった場合、ある特定のマニュアル設定を再現 して下さい。 特に、それらのコンフィギュレーション 証明書を含み、機能を TFTP する:
- MoH ファイル
- デバイス パック
- ダイヤル プラン（北以外のアメリカ ナンバリングプラン（NANP）ダイヤルのために）
- ロケール
- 他の雑多な COPS ファイル
- （それが TFTPサーバ）パブリッシャに以前に 手動でアップロードされたファイル
- Simple Network Management Protocol（SNMP）のコミュニティ ストリング
- エクステンションモビリティ交差クラスタ（EMCC）、ゾーン間の Location 帯域幅 マネージャ（LBM）、およびゾーン間のルックアップ サービス（ILS）のためのバルク証明書輸出高
- セキュア トランク、ゲートウェイおよびコンファレンスブリッジのための証明書交換
トラブルシューティング
このセクションはこのプロシージャが失敗しますかもしれないさまざまなシナリオを解説しています。
クラスタは認証しません
クラスタが認証しない場合、2 つのもっとも一般的な原因は TCPポート 8500 の組合わせを誤まられたセキュリティ パスフレーズおよび接続上の問題です。
クラスタ セキュリティ passphrases マッチが両方のノードの CLI で、utils Create レポート プラットフォーム コマンドを入力し、platformConfig.xml ファイルからのハッシュ 値を点検することを確認するため。 これらはパブリッシャ および サブスクライバ ノードで一致する必要があります。
<IPSecSecurityPwCrypt>
<ParamNameText>Security PW for this node</ParamNameText>
<ParamDefaultValue>password</ParamDefaultValue><ParamValue>0F989713763893AC831812812AB2825C8318
12812AB2825C831812812AB2825C </ParamValue>
</IPSecSecurityPwCrypt>
一致するこれらがポート 8500 の TCP 接続を確認すれば。 それらが一致する場合、プロシージャを囲む CUCM コードの複数の問題によるパスフレーズを固定するように試みるとき問題があるかもしれません:
- Cisco バグ ID CSCtn79868 - sftpuser パスワードだけ変える pwrecovery ツール
- Cisco バグ ID CSCug92142 は- pwrecovery ツール 内部ユーザ パスワードをアップデートしません
- Cisco バグ ID CSCug97360 - pwrecovery ユーティリティの selinux 否定
- Cisco バグ ID CSCts10778 -セキュリティパスワード 回復手順のために投げられる否定
- Cisco バグ ID CSCua09290 - CLI 「set password ユーザー セキュリティ」は正しいアプリケーション パスワードを設定 しません でした
- Cisco バグ ID CSCtx45528 は-よい pwd リセット cli 戻りしかしパスワードの変更
- Cisco バグ ID CSCup30002 - DB サービスは CUCM 10.5 のセキュリティパスワードを変更した後、ダウンしています
- Cisco バグ ID CSCus13276 -再度ブートするで開始しないべき CUCM 10.5.2 セキュリティパスワード リカバリ原因 DB
CUCM バージョンがこれらの問題すべてのための修正が含まれている場合、最も容易なソリューションはリリースしますすべてのノードの 10.0(1) を Cisco Unified Communications オペレーティング システム管理 ガイドで詳述されるパスワード回復手順を完了することです。 CUCM バージョンがこれらの問題のための修正が含まれない場合、Cisco Technical Assistance Center （TAC）は状況に回避策を、依存実行する機能があるかもしれません。
リストアは CCMDB コンポーネントを処理しません
リストアが DB コンポーネントをリストしない場合、バックアップ自体が DB コンポーネントが含まれていないことは可能性のあるです。 ようにパブリッシャ DB 実行し、クエリを受け入れることができ新しいバックアップを行います。
複製の失敗
複製失敗を解決するために Linux アプライアンス モデル Ciscoの記事のトラブルシューティング CUCM データベース複製を参照して下さい。
電話はサービスにアクセスすることが登録されませんし、できません
DB 復元が証明書を復元するので、パブリッシャがプライマリ TFTPサーバである場合、署名者は異なっています。 電話がサブスクライバ信頼確認サービス（TV）証明書を信頼し、TCPポート 2445 が電話と TV サーバ間で開いていれば場合、問題は自動的に解決する必要があります。 従って、Cisco は完全なクラスタ DRF バックアップを維持することを推奨します。
バージョン 8.6 以前の CUCM バージョンはまた Cisco バグ ID CSCtn50405 による前の正常なバックアップにおいての証明書問題が、あるかもしれません。
フィードバック