音声とユニファイド コミュニケーション : Cisco Unified Communications Manager Version 7.1

Cisco Unified Communications Manager 7.x/8.x: バックアップの問題のトラブルシューティング

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2014 年 4 月 9 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

Cisco Unified Communications Manager バックアップがスケジュールどおりに動作していません。 すべての Disaster Recovery Framework(DRF)サービスがダウンし、新しいデバイス、スケジュール、またはステータスが DRF のコンソールから見ることができません。 このドキュメントでは、この問題のトラブルシューティング方法について説明します。

前提条件

要件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

このドキュメントの情報は、Cisco Unified Communications Manager 7.1(3)/8.x に基づくものです。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

問題

Cisco Unified Communications Manager バックアップがスケジュールどおりに動作していません。 すべての Disaster Recovery Framework(DRF)サービスがダウンし、新しいデバイス、スケジュール、またはステータスが DRF のコンソールから見ることができません。 また、DRF の管理ページにアクセスすると、次のエラー メッセージを受け取ります。

Status:  Local Agent is not responding. 
This may be due to Master or Local Agent being down.

http://www.cisco.com/c/dam/en/us/support/docs/unified-communications/unified-communications-manager-version-71/111796-cucm-drf-01.gif

この RTMT アラートは、バックアップが失敗したときに表示されます。

CiscoDRFFailure Reason : Master Agent was unable to send a 
backup/restore request to the local agent. 
Node [ELS-PUB1] is not connected. 
AppID : Cisco DRF Master 
ClusterID : NodeID: ELS-pub1 .
The alarm is generated on Tue Nov 24 02:00:04 PST 2009

解決策

最初に、パブリッシャのキーストア内の証明書のシリアル番号が、すべてのサブスクライバのトラストストアに存在しているかどうかを確認します。 次の手順を実行します。

  1. クラスタ構成のパブリッシャ サーバの CUCM OS Administration ページにログインします。 [Security] > [Certificate Management] を選択します。 [Certificate List] ウィンドウが表示されます。

  2. [Find] コントロールを使用すると、証明書をフィルタリングできます。

  3. ipsec.pem ファイルをクリックして、証明書のシリアル番号を確認します。

  4. クラスタの各ノードの CUCM OS Administration ページにログインします。 [Security] > [Certificate Management] を選択します。 [Certificate List] ウィンドウが表示されます。

  5. [Find] コントロールを使用すると、証明書をフィルタリングできます。

  6. パブリッシャのホスト名をファイル名に持つ ipsec-trust.pem ファイルをクリックし、証明書のシリアル番号を確認します。

  7. 証明書のシリアル番号は、クラスタのすべてのノードで同じである必要があります。 シリアル番号が一致しないノードがある場合は、次の手順を実行します。

    1. 対象ノードの CUCM OS Admin ページにログインします。

    2. [Security] > [Certificate Management] を選択します。 [Certificate List] ウィンドウが表示されます。

    3. [Find] コントロールを使用すると、証明書をフィルタリングできます。

    4. ipsec.pem ファイルをクリックして、その証明書をダウンロードします。

    5. ファイル名がパブリッシャのホスト名である既存の ipsec-trust を探し、ファイル名をクリックして [Delete] を選択します。

    6. ダウンロードした ipsec.pem ファイルを、ipsec-trust というキャプションを付けてアップロードします。

    7. DRF マスター エージェント(MA)/DRF ローカル エージェント(LA)を再起動します。

エラー: Cannot write: Broken pipe

DRF のバックアップが失敗して、次のエラー メッセージが表示されます。

/bin/tar: -: Cannot write: Broken pipe
/bin/tar: Error is not recoverable: exiting now
CCMDB Backup failed, unable to tar data to master agent
Restoring CAR services ...

この問題は、Cisco Bug ID CSCte62205登録ユーザ専用)に記述されています。

回避策として、次の手順のいずれかを試してください。

  1. Open SSH サーバの client alive message を無効にします。

  2. バックアップ中にサーバが CUCM への接続をタイムアウトしないように、ClientAliveCountMax および ClientAliveInterval の値を十分に大きい回数/間隔に設定します。

  3. DRF マスター エージェント(MA)/DRF ローカル エージェント(LA)を再起動します。

CCMDB のバックアップ中に DRS がハングする

問題

preserve フォルダに多数の CDR/CMR ファイルが累積していると、CCMDB のバックアップ中に DRS がハングします。 この問題は、Cisco Bug ID CSCsl16967登録ユーザ専用)に記述されています。

CAR サービスを停止しても、フラット CDR ファイルの累積は停止されません。

解決策

この問題を解決するには、次の手順を実行します。

  1. 次の手順を実行して、DRS が処理を続行できるように、CDR ファイルを一時的にクリーンアップします。

    1. クラスタ内のすべてのサーバの CDR Agent サービスを停止して、新しい CDR ファイルがパブリッシャにプッシュされないようにします。

    2. 次のコマンドを実行して、すべてのファイルが課金サーバにプッシュされていることを確認します。

      file list activelog /cm/cdr_repository/destination/*
      
  2. 次の手順を実行して、シンボリック リンクのあるサブフォルダがないことを確認します。

    1. パブリッシャの CDR Repository Manager、CAR スケジューラ、および CAR Web サービスを停止します。

    2. 次のコマンドを使用して、/var/log/active/cm/cdr_repository/preserve/<date> の下に累積されているすべてのファイルを削除します。

      file delete activelog /cm/cdr_repository/preserve/* noconfirm
      
    3. 次のコマンドを使用して、/var/log/active/cm/cdr_repository/car/<date> の下のすべてのシンボリック リンクを削除します。

      file delete activelog /cm/cdr_repository/car/* noconfirm
      
    4. パブリッシャの CDR Repository Manager、CAR スケジューラ、および CAR Web サービスを再起動します。

  3. 次の手順を実行して、それ以上 CDR ファイルが累積されないようにします。

    CDR ファイルがそれ以上累積されないようにするには、CAR スケジューラ サービスを起動し、継続的にロードするようにローダをスケジュールして、CDR のみをロードするように設定する必要があります。

    1. まだ作成されていない場合は、ccmadmin ページのユーザ グループ管理で ccmadmin アカウントを作成します。

    2. CAR にログインし、[System] > [Scheduler] > [CDR Load] の順に移動します。

    3. [Continuous Loading 24/7] および [Load CDR only] チェックボックスにチェックマークを入れて、[Update] をクリックします。

    4. [System] > [Database] > [Configure Automatic Database Purge] の順に選択します。

    5. [Min Age of Call Detail Records] および [Max Age of Call Detail Records] に「1」と入力し、[Update] をクリックします。

    6. [Report Config] > [Automatic Generation/Alert] を選択します。

    7. それぞれのレポートについて、[Disabled] を選択して [Update] をクリックします。

  4. すべてのサーバで CDR Agent サービスを再起動します。

エラー: The system is currently locked by another process. Please try again later

DRS のバックアップが実行を自動的に停止し、手動バックアップを試みると、「Backup operation currently in progress. Please wait and try after sometime」というエラー メッセージが表示されます。 新しいバージョンまたは COP ファイルのインストールを試みると、「The system is currently locked by another process. Please try again later」というエラー メッセージが表示されます。 この問題は、CUCM サーバを自動的にバックアップするように DRF をスケジュールしている場合に発生します。 この問題は、Cisco Bug ID CSCsr87199登録ユーザ専用)に記述されています。

解決策

この問題を解決するには、DRF マスター エージェントをリセットします。

Winsock エラーでバックアップが失敗する

CUCM 8.x で、「Winsock Error 10054/10035/10053」というエラー メッセージとともにバックアップが失敗しました。

解決策

リモート バックアップ デバイスでファイアウォールが無効になっていることを確認して、再度バックアップを実行します。

DRF のバックアップで証明書がバックアップされない

CUCM 8.x で、ブリッジ アップグレードによって復元したサーバの ITL ファイルには有効な署名者が存在しません。 パブリッシャが TFTP サーバである場合、電話機には HTTPS サービスがありません。 UCS に移行する場合や、バックアップと復元が実行された新しいハードウェアの場合、電話機から既存の ITL を手動で削除しないと、電話機は新しいクラスタからの設定ファイルや変更を受け入れません。

ディザスタ リカバリ状況からの復元時、復元されたサーバが TFTP サーバであった場合、電話機は DRS の復元後に設定ファイルや ITL ファイルを認識しなくなります。 既存の ITL が削除され、新しく生成された ITL に置き換えられるまで、電話機は設定の変更やアップグレードを認識しない可能性があります。

また、サーバで show itl CLI コマンドを発行すると、次のエラー メッセージが表示されます。

This etoken was not used to sign the ITL file.
Verification of the ITL file failed.
Error parsing the ITL file

この問題は、Cisco Bug ID CSCtn50405登録ユーザ専用)に記述されています。

解決策

ディザスタ リカバリやハードウェアの移行の状況が発生した後は、次の手順を実行します。

  1. (復元されたサーバでのみ)CallManager.pem ファイルを再生成して、ファイル システム上の CallManager.pem ファイルを、データベース内の同じファイルに同期させます。

  2. TVS と TFTP を再起動します。

  3. 単一ノード クラスタの場合や TFTP サーバが 1 台のみの場合は、クラスタ内のすべての電話機から ITL ファイルを手動で削除します。

  4. 複数ノード クラスタの場合、電話機は代替 CallManager グループ サーバの TVS を自動的に使用して、新しい ITL ファイルを認証します。 あるいは、電話機でクラスタ内の別の TFTP サーバを指し示すこともできます。

ブリッジ アップグレードの後は、次の手順を実行します。

  1. (復元されたサーバでのみ)CallManager.pem ファイルを再生成して、ファイル システム上の CallManager.pem ファイルを、データベース内の同じファイルに同期させます。

  2. TVS と TFTP を再起動します。

  3. 電話機をリセットして新しい ITL ファイルをダウンロードする必要がありますが、電話機にはそれまで、ダウンロードする有効な ITL ファイルがなかったと考えられるため、ITL ファイルを削除する必要はありません。

エラー メッセージ: bad decrypt 16404:error

CUCM 8.x で、DRS の復元が TFTP コンポーネントで失敗し、次のエラー メッセージが表示されます。

error:06065064:digital envelope routines:EVP_DecryptFinal:bad
decrypt:evp_enc.c:438:

解決策

このエラー メッセージは、IP アドレスまたはホスト名のミスマッチがあることを示しています。 CUCM サーバの IP アドレスとホスト名が、バックアップ元の MCS サーバのものと同じであることを確認します。 ホスト名がバックアップ サーバと異なる場合、ホスト名をバックアップ サーバと同じになるように変更して、復元を再度実行します。

CUCM のバックアップ ページのエラー

問題

バックアップ ページに移動すると、「Local Agent is not responding. This may be due to Master or Local Agent being down」というエラー メッセージが表示されます。 これは、バックアップ デバイスの追加を試行中にも発生します。

解決策

この問題を解決するには、次の手順を実行します。

  1. CUCM OS Admin ページにログインします。

  2. [Security] > [Certificate Management] を選択します。

  3. ipsec.pem ファイルでシリアル番号を確認します。

  4. シリアル番号がサブスクライバのための ipsectrust.pem ファイルと一致するようにして下さい。

  5. パブリッシャの Cisco DRF マスターおよび DRF ローカル サービスを再起動します。

  6. TFTP サービスをアクティブにします。

バックアップ デバイスを追加できない

問題

CUCM DRS ページでバックアップ デバイスを追加できません。

解決策

この問題を解決するには、バックアップ デバイスとしてシスコが推奨する SFTP サーバを追加する必要があります。 次のいずれかの SFTP サーバを使用できます。

  • Open SSH:UNIX システム用

  • Cygwin leavingcisco.com

  • Titan leavingcisco.com

  • GlobalSCAPE EFT サーバ:旧称 GlobalSCAPE 社のセキュア FTP サーバ

シスコでは、Cisco Technology Developer Partner プログラム(CTDP)で認定された SFTP 製品を推奨しています。

詳細は、『Cisco Unified Communications Manager のバックアップ サーバの設定』を参照してください。

CUCM 8.x サーバを復元できない

問題

このエラー メッセージは、CUCM 8.5 の復元を試みると表示されます。

digital envelope routines:EVP_DecryptFinal:bad
decrypt:evp_enc.c:438:

解決策

バックアップを取る際に DNS が設定されていたが、復元の実行時に DNS が設定されていない場合に、このエラーが発生します。 この問題を解決するには、次の手順を実行します。

  1. 復元を実行する前に DNS を設定します。

  2. サーバの FQDN を DNS で解決できることを確認します。

    この問題は、Cisco Bug ID CSCtk05743登録ユーザ専用)に記述されています。

CUCM 8.5 を復元できない

問題

次のエラーを与える 8.5 サーバを復元する不可能:

digital envelope routines:EVP_DecryptFinal:bad
decrypt:evp_enc.c:438:

解決策

この問題は、IP/ホスト名/セキュリティ パスワードにミスマッチがある場合に発生する可能性があります。 ただし、この場合はすべて一致しています。

問題は DNS/一致するためにサーバで設定されないドメイン 情報に関連してあります。 バックアップを取る際に DNS が設定されていたが、復元の実行時に DNS が設定されていない場合に、このエラーが発生します。

この問題を解決するには、復元を実行する前に DNS を設定します。 サーバの FQDN を DNS で解決できることを確認します。

この問題は、Cisco Bug ID CSCtk05743登録ユーザのみ


関連情報


Document ID: 111796