サブスクライバからのCUCMパブリッシャの再構築

はじめに

このドキュメントでは、事前バックアップなしでサブスクライバデータベースからCisco Unified Communications Manager(CUCM)パブリッシャノードを復元する方法について説明します。

背景

CUCMの初期のバージョンでは、パブリッシャノードは構造化照会言語(SQL)DBの唯一の信頼できるソースと見なされていました。

したがって、ハードウェア障害やファイルシステムの破損によってパブリッシャノードが失われた場合、パブリッシャノードを回復する唯一の方法は、ディザスタリカバリシステム(DRS)バックアップからDBを再インストールして復元することでした。

一部のお客様は、適切なバックアップを保持しなかったり、古いバックアップを保持していたりしたため、唯一のオプションは、パブリッシャサーバノードを再構築して再設定することでした。 

CUCMバージョン8.6(1)では、サブスクライバデータベースからパブリッシャDBを復元するための新機能が導入されました。

このドキュメントでは、サブスクライバからパブリッシャDBを正常に復元するためにこの機能を利用する方法について説明します。

クラスタ全体の完全なディザスタリカバリフレームワーク(DRF)バックアップを保持することを強く推奨します。

このプロセスはCUCM DB設定のみをリカバリするため、証明書、保留音(MoH)、TFTPファイルなどの他のデータはリカバリされません。これらの問題を回避するには、クラスタ全体のDRFバックアップを保持します。

注：開始する前に、このドキュメントに記載されているプロセス全体を確認し、精通しておくことを推奨します。

クラスタデータの収集

Publisherを再インストールする前に、前のPublisherに関する詳細情報を収集しておくことが重要です。これらの詳細は、元のパブリッシャのインストールと一致している必要があります。

• 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以外のすべての名前値をパブリッシャサーバの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

注：デフォルトのインストールでは、パブリッシャのホスト名がprocessnodeテーブルに追加されます。名前の列にパブリッシャの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] をクリックします。Publisher nodeチェックボックス(CUCM911CCNAPUB)をオンにし、復元が行われるサブスクライバDBを選択します。次にRestoreをクリックします。

復元ステータス

復元がCCMDBコンポーネントに達すると、ステータステキストがRestoring Publisher from Subscriber Backupとして表示される必要があります。

パブリッシャDBの健全性チェックの実行

再起動してレプリケーションを設定する前に、リストアが正常に行われ、パブリッシャ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 Database Status Reportを生成します。

レプリケーションはまだ設定されていない可能性がありますが、Unified CM Hosts、Unified CM Rhosts、およびUnified CM Sqlhostsファイルがパブリッシャと一致していることを確認することが重要です。

一致しない場合は、一致しないノードを再度リブートする必要があります。これらのファイルが一致しない場合は、次の手順に進んだり、レプリケーションをリセットしたりしないでください。

レプリケーションの設定

バージョンによっては、レプリケーションを自動的に設定できません。これを確認するには、すべてのサービスが起動するのを待って、utils dbreplication runtimestateコマンドを入力します。

状態値0はセットアップが進行中であることを示し、値2はレプリケーションがそのノードに対して正常にセットアップされていることを示します。

次の出力は、レプリケーションの設定が進行中であることを示しています(状態が0と表示されるノードが2つある場合)。

次の出力は、レプリケーションが正常にセットアップされたことを示しています。

状態値4を持つノードが表示される場合、または複製が数時間後に正常に設定されない場合は、パブリッシャノードでutils dbreplication reset allコマンドを入力します。

複製が引き続き失敗する場合、問題のトラブルシューティング方法についての詳細は、シスコの記事「LinuxアプライアンスモデルでのCUCMデータベースレプリケーションのトラブルシューティング」を参照してください。 

復元後

DBの復元では以前のコンポーネントがすべて復元されるわけではないため、サーバレベルの項目の多くは手動でインストールまたは復元する必要があります。

サービスのアクティブ化

DRFの復元では、サービスはアクティブになりません。Unified Serviceabilityページのサイトのドキュメントに基づいて、Tools > Service Activationに移動し、パブリッシャが実行する必要のある必要なサービスをアクティブにします。

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

完全バックアップが使用できない場合は、特定の手動設定を再現する必要があります。特に、証明書とTFTP機能に関連する設定は次のとおりです。

• MoHファイル
• デバイスパック
• ダイヤルプラン(North American Numbering Plan(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が良好を返すが、パスワードは変更されない
• 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サーバの場合は、署名者が異なります。

電話が加入者の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」を参照してください。