内容

概要

バックグラウンド

クラスタデータの収集

すべてのサブスクライバでレプリケーションを停止する

CUCMパブリッシャのインストール

パブリッシャのプロセスノード値の更新

パブリッシャノードのリブート

クラスタ認証の確認

新しいバックアップの実行

バックアップデバイスの追加

手動バックアップの開始

サブスクライバDBからのパブリッシャの復元

復元ステータス

パブリッシャデータベースでの健全性チェックの実行

クラスタのリブート

レプリケーション設定の要件の確認

複製の設定

復元後

サービスのアクティブ化

復元されなかったデータのインストール

トラブルシュート

クラスタが認証されない

復元でCCMDBコンポーネントが処理されない

複製の失敗

電話機が登録されない、またはサービスにアクセスできない

概要

このドキュメントでは、事前のバックアップやルートアクセスなしで、サブスクライバデータベースから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ファイルなしでインストールされます。

注：一部の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パブリッシャのインストール

適切なバージョンのブート可能なイメージを収集し、適切なバージョンにアップグレードしてインストールを実行します。

注：ほとんどのCUCM Engineering Special(ES)リリースはすでにブート可能です。

パブリッシャをインストールし、前述のIPアドレス、ホスト名、ドメイン名、およびセキュリティパスフレーズに正しい値を指定します。

パブリッシャのプロセスノード値の更新

注：パブリッシャは、そのサブスクライバからDBを復元するために、少なくとも1つのサブスクライバサーバを認識している必要があります。すべてのサブスクライバを追加することをお勧めします。

ノードリストを取得するには、現在のサブスクライバの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コマンドを実行する必要があります。

警告:CUCMバージョン10.5(2)以降を使用している多くのユーザは、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

注：デフォルトのインストールでは、パブリッシャホスト名がプロセスノードテーブルに追加されます。名前列にパブリッシャのIPアドレスが表示されている場合は、これをIPアドレスに変更できます。この場合は、パブリッシャエントリを削除せずに、現在のホスト名/IPアドレスフィールドを開いて変更します。

パブリッシャノードのリブート

プロセスノードの変更が完了した後でパブリッシャを再起動するには、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を使用できますが、DB以外のコンポーネントを復元するにはバックアップが必要です。

使用可能なバックアップがない場合は、新しいバックアップを実行します。バックアップがすでに存在する場合は、このセクションをスキップできます。

バックアップデバイスの追加

ナビゲーションメニューを使用して、ディザスタリカバリシステムに移動し、バックアップデバイスを追加します。

手動バックアップの開始

バックアップデバイスを追加したら、手動バックアップを開始します。

注：パブリッシャノードにCCMDBコンポーネントが登録されていることが重要です。

サブスクライバ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)の証明書の一括エクスポート

- セキュアなトランク、ゲートウェイ、および会議ブリッジの証明書交換

注：混合モードクラスタの場合は、証明書信頼リスト(CTL)クライアントを再実行する必要があります。

トラブルシュート

このセクションでは、この手順が失敗する原因となる可能性のあるさまざまなシナリオについて説明します。

クラスタが認証されない

クラスタが認証されない場合、最も一般的な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が原因で証明書の問題が発生する可能性があります。

注:Initial Trust List(ITL)ファイルのトラブルシューティングの詳細については、シスコの記事「Communications Manager Security By Default and ITL Operation and Troubleshooting」を参照してください。