Cisco Prime Collaboration Deployment 管理ガイド、リリース 10.5(1)
Cisco Prime Collaboration Deployment のトラブルシューティング
Cisco Prime Collaboration Deployment のトラブルシューティング

目次

Cisco Prime Collaboration Deployment のトラブルシューティング

移行用のディスク容量

多数の Unified CM サーバの同時移行に 1 つの Cisco Prime Collaboration Deployment サーバが使用されている場合、Cisco Prime Collaboration Deployment ディスクは空きスペースの少ない状態で実行され、移行タスクが失敗する場合があります。 Cisco Prime Collaboration Deployment を使用して複数のサーバを同時に移行する場合、以下のコマンドを実行してディスク サイズを増やすことができます。

手順
    ステップ 1   Cisco Prime Collaboration Deployment CLI にログインし、utils system shutdown コマンドを入力して Cisco Prime Collaboration Deployment サーバをシャットダウンします。
    ステップ 2   Cisco Prime Collaboration Deployment サーバがシャットダウンされたら、ESXi host に移動して、Cisco Prime Collaboration Deployment サーバがある仮想マシンのディスク サイズを増加します。
    ステップ 3   Cisco Prime Collaboration Deployment サーバを再起動します。
    ステップ 4   Cisco Prime Collaboration Deployment サーバで利用できるディスク スペースの容量を表示するには、CLI コマンド show status を Cisco Prime Collaboration Deployment サーバで使用します。

    一般的なトラブルシューティングの問題

    段階的なイベントのログの表示

    Cisco Prime Collaboration Deployment の段階的なログを表示するには、[Monitoring(モニタリング)] ダッシュボードで [View Log(ログの表示)] ボタンを使用します。

    Cisco Prime Collaboration Deployment ログへのアクセス

    CLI コマンドを使用して Cisco Prime Collaboration Deployment ログにアクセスして詳細を取得します。 次に例を示します。

    file get activelog tomcat/logs/ucmap/log4j/*

    タスク開始前に問題をチェック

    タスクを開始する前に問題をチェックするには、[Validate(検証)] ボタンを使用します。 検証で問題が発見された場合、[View Log(ログの表示)] ボタンをクリックして検出された検証の問題に関する詳細を確認します。

    ノード情報の不一致

    Cisco Prime Collaboration Deployment に保管されたノード情報および実際のノードとの間の不一致は自動的に修正できます(たとえば、アクティブなバージョン)。 他の情報を修正するには再検出が必要です。

    サーバ間の通信の確認

    network capture CLI コマンドを使用して、サーバ間の通信を検証できます(たとえば、パケットが正しいポートに送受信されているかどうか)。

    [View Log(ログの表示)] に表示されるエラー

    [Monitoring(モニタリング)] ダッシュボードの [View Log(ログの表示)] ボタンを使用して、タスクの実行時に Cisco Prime Collaboration Deployment のログを段階的に確認できます。 ログを確認する場合、イベントまたはエラーが表示される場合があります。 より一般的なエラーの例、およびそれを解決するために提案されるアクションが以下に示されています。

    ノードの接続/コンタクトの問題

    エラー メッセージ:

    • "The network diagnostic service indicates node {0} has a network issue.(ネットワーク診断サービスは ノード {0} にネットワーク障害があることを示しています。) The network settings cannot be changed until the network issue is resolved.(ネットワーク障害が解決されるまでネットワーク設定を変更することはできません。)"
    • "The node could not be located(ノードを検出できませんでした)"
    • "The node could not be contacted(ノードにコンタクトできませんでした)"

    ノードの接続/コンタクトの問題を解決するために実行できるアクションは以下のとおりです。

    • 指定されたノードに対するネットワーク設定とファイアウォール設定を確認して、Cisco Prime Collaboration Deployment サーバがノードと通信できるようにします。
    • ノードの電源がオフになっているかどうか、ノード名のつづりが正しいかどうか、またはノードにアクセスできるかどうかを確認します。

    他の接続の問題

    エラー メッセージ:

    • "The switch version status could not be determined.(バージョン切り替えステータスを検出できませんでした。) Please manually verify that the switch version completed.(手動で一時停止してバージョン切り替えが完了したことを検証してください。)"

    問題解決のために考えられるアクションは以下のとおりです。

    バージョン切り替えタスクでは、サーバが一定期間応答しない場合、切り替えに成功していても、正常に切り替えられていないように見える場合があります。 このエラーが発生した場合、応答していないサーバの CLI にログインし、show version active コマンドを発行してバージョン切り替えが正常に実行されたか確認します。 たとえば、UCCX サーバ上のバージョン切り替えは 60 分以上かかることがよくあります。

    ノード応答

    エラー メッセージ:

    • "The node did not respond within the expected time frame.(ノードが予想時間内に応答しませんでした。)"
    • "The upgrade service for node {0} did not send back the expected response.(ノード {0} のアップグレード サービスが期待される応答を返信しませんでした。) This is assumed to be a failure.(これはエラーと見なされます。) However, this can also happen when network connectivity is temporarily lost.(ただし、これはネットワーク接続が一時的に失われた場合に発生することがあります。) Please manually verify the upgrade status on node {0} before proceeding.(続行する前にノード {0} 上のアップグレード ステータスを手動で確認してください。)"

    問題解決のために考えられるアクションは以下のとおりです。

    これらのメッセージは通常、タスク実行中(インストール、アップグレードなど)に新規ノードが一定期間内に Cisco Prime Collaboration Deployment とコンタクトしない場合に表示されます。 アップグレードの場合、これは 8 時間であるため、このエラーが発生したらタスクが失敗したことを意味している場合があります。 ただし、アップグレード(またはインストール)中にサーバが Cisco Prime Collaboration Deployment とコンタクトするのを妨げるネットワーク障害が発生したことを意味する場合もあります。 そのため、このメッセージが表示されたら、(CLI を使用して)応答していないサーバにログオンし、show version active コマンドを発行してアップグレードが正常に実行されたか確認します。

    データストアをマウントできない

    エラー メッセージ:

    • "Unable to mount datastore xxx_NFS on ESXi host <hostname>(ESXi ホスト <hostname> でデータストア xxx_NFS をマウントできませんでした)"

    問題解決のために考えられるアクションは以下のとおりです。

    このエラーは、NFS データストアに問題がある場合に発生します。 これは Cisco Prime Collaboration Deployment が予想外にシャットダウンした場合に発生する場合があります。 このエラーが発生した場合、ESXi ホストを確認し、古い NFS マウントをアンマウントしてください。 次に、ESXi ホストを Cisco Prime Collaboration Deployment から削除してから再度追加してください。

    ESXi ホストをインベントリに追加できない

    考えられる原因:

    このエラーは、ESXi ホストの vSwitch ホストのネットワーキングの問題によって発生した可能性があります。

    問題解決のために考えられるアクションは以下のとおりです。

    • ホストに Ping を実行し、CLI コマンド utils network ping hostname を実行して接続性を確認します。
    • ESXi ホストのライセンスが有効であることを確認します。 デモ ライセンスはサポートされていません。
    • ESXi ホストへのルート アクセス権が必要であることに注意してください。 ESXi ホストのクレデンシャルを追加する場合にルートのユーザ名およびパスワードを使用します。
    • ネットワーク アドレス トランスレーション(NAT)を使用している場合、Cisco Prime Collaboration およびノードと正常に通信するためには、Cisco Prime Collaboration Deployment およびクラスタ内のすべてのノードが、同じ NAT の後ろにある必要があります。

    VM の電源を投入できない

    エラー メッセージ:

    • "Unable to power on the VM named xxx on ESXi host xxxxxxx(ESXi ホスト xxxxxxx 上で xxx という名前の VM の電源を投入できませんでした)"

    問題解決のために考えられるアクションは以下のとおりです。

    VM が置かれる ESXi ホストを確認します。 [Tasks and Events(タスクとイベント)] タブで、Cisco Prime Collaboration Deployment がいつ VM の電源投入を試行したかを示すタイムスタンプを確認します。 そのホストの VM の数が多すぎないか確認します。 その場合は、このクラスタに使用されていない VM の電源をオフにすることが必要になる場合があります。

    VM の電源状態

    エラー メッセージ:

    • "The power state of VM xxxxx in ESXi host XX.XX.X.XX needs to be OFF.(ESXi ホスト XX.XX.X.XX 内の VM xxxxx の電源状態は OFF である必要があります。) The task is now paused.(タスクは一時停止されます。)"

    問題解決のために考えられるアクションは以下のとおりです。

    移行タスクの宛先クラスタ、または新規インストール クラスタで使用される VM が OFF 状態になっている必要があります。 このエラー メッセージが表示された場合は、指定された VM を確認します。 オフになっていない場合、電源をオフにします。 次に、タスクの再試行または再開を実行できます。

    ユーザ名またはパスワードが無効

    エラー メッセージ:

    • "The username and/or password is not valid.(ユーザ名とパスワードの両方またはいずれか一方が無効です。)"

    問題解決のために考えられるアクションは以下のとおりです。

    クラスタ ページでこのサーバの管理名およびパスワードを修正します。 その後、このノードを検出できます。

    Platform Administrative Web Services(PAWS)

    エラー メッセージ:

    • "The Platform Administrative Web Services (PAWS) is not available.(Platform Administrative Web Services(PAWS)を利用できません。)"
    • "Unable to access node {0} via the Platform Administrative Web Services (PAWS) interface.(Platform Administrative Web Services(PAWS)インターフェイスを通してノード {0} にアクセスできません。)"

    問題解決のために考えられるアクションは以下のとおりです。

    サーバにアクセス可能であり、PAWS サービスがノード上でアクティブであることを確認します。 Cisco Prime Collaboration Deployment がアプリケーション サーバ上でのサーバのアップグレード、バージョン切り替え、またはタスクの再起動のために使用される場合(たとえば、Cisco Prime Collaboration Deployment が Unified CM サーバのアップグレードに使用される場合)、アプリケーション サーバで Platform Administrative Web Service がアクティブになっている必要があります。アクティブでない場合、Cisco Prime Collaboration Deployment サーバは Unified CM アプリケーション サーバと通信することができません。

    {0} VMs Named {1} Were Located on ESXi Host {2}

    エラー メッセージ:

    • "{0} VMs named {1} were located on ESXi host {2}.({1} という名前の {0} VM が ESXi ホスト {2} で検出されました。)"

    問題解決のために考えられるアクションは以下のとおりです。

    指定された仮想マシンがまだ ESXi ホスト上に存在することを確認します。 場合によっては、VM が別の ESXi ホストに移動されることがあります。この場合、VM を保持する ESXi ホストを Cisco Prime Collaboration Deployment サーバに追加する必要があります。

    Power State of VM {0} in ESXi Host {1} Needs to Be OFF

    エラー メッセージ:

    • " The power state of VM {0} in ESXi host {1} needs to be OFF.(ESXi ホスト {1} の VM {0} の電源状態が OFF である必要があります。)"

    問題解決のために考えられるアクションは以下のとおりです。

    Cisco Prime Collaboration Deploymentを VM にインストールまたは移行するには、ターゲット VM の電源がオフになっている必要があります。

    CLI コマンドのタイムアウト

    エラー メッセージ:

    • "CLI command timed out for node {0}(ノード {0} で CLI コマンドがタイムアウトしました)"

    問題解決のために考えられるアクションは以下のとおりです。

    ノードのネットワーキング、接続、またはパスワードの問題を確認します。 また、コマンドがタイムアウトした間に別の操作が発生していたかどうか(たとえば COP ファイルのインストール)を確認します。

    検証の問題によるタスクの一時停止

    エラー メッセージ:

    • "Task paused due to validation issues(検証の問題によりタスクが一時停止しました)"

    問題解決のために考えられるアクションは以下のとおりです。

    タスクを実行する前に、Cisco Prime Collaboration Deployment サーバは、使用される VM が利用可能かどうか、iso ファイルを検出可能かどうかなどを確認するために検証チェックを実行します。 このメッセージは、検証チェックのいずれかが失敗したことを示しています。 どの検証が失敗したかの詳細はログ ファイルを確認してください。

    ロック エラー

    大部分の製品では、一度に 1 つのみの変更を加えることができます(たとえば、アップグレードの進行中は NTP 設定を変更することはできません)。 ノードのロック中にリクエストが作成されると、以下の情報を含むロック メッセージが表示されます。

    • ロックされたリソース
    • リソースをロックしたプロセス ID
    • ノードのホスト名

    通常、数分待ってから再試行できます。 詳細については、ノード CLI を使用して、提供されたプロセス ID およびホスト名に基づいた正確なプロセスを識別します。

    NFS データストア

    例外およびその他の NFS 関連の問題

    例外またはその他の NFS 関連の問題については、Cisco Prime Collaboration Deployment ログを参照してください。

    VMware vSphere の使用

    NFS データストアが使用可能であること確認するために VMware vSphere を使用します。

    現在のすべてのデータストアのマウント解除および再マウント

    Cisco Tomcat を再起動すると、現在のすべてのデータストアがマウント解除され、その再マウントが試行されます。

    [Monitor(モニタ)] ページの一時停止状態

    タスクが手動介入を待機中

    移行や再アドレス付けなどの特定のタスクは、手動による介入が必要になった地点で一時停止します。 これらのタスクでは、Cisco Prime Collaboration Deployment システムが一時停止を強制的に適用します。 タスクがこのポイントに到達すると、タスクは停止し、メッセージが [Monitoring(モニタリング)] ページに表示されます。 手動の手順を必要に応じて実行し、タスクの再開の準備ができたら [Resume(再開)] ボタンをクリックします。

    検証の問題によるタスクの一時停止

    このメッセージが表示された場合は、[View log(ログの表示)] リンクをクリックしてどの検証が失敗したかについて詳細を確認します。

    タスク アクションの失敗によるタスクの一時停止

    このメッセージが表示された場合は、[View log(ログの表示)] リンクをクリックしてどのタスクが失敗したかについて詳細を確認します。

    スケジューリング

    スケジュール日の確認

    タスクがスケジュールされていても開始していない場合、スケジュール日を確認します。

    検証テスト

    タスクが開始すると、一連の検証テストが実行されます。 検証エラーではタスクを一時停止します。

    タスクが一時停止している理由の確認

    [View Log(ログの表示)] ボタンを使用して、タスクが一時停止している理由(検証エラー、要求されるまたは必須の一時停止、特定の手順の後に 1 つまたは複数のノードが失敗したなど)を確認します。

    キャンセルされたタスク

    手順の中には、一度開始するとキャンセルできないものがあります(たとえばサーバの再起動など)。 タスクをキャンセルすると、手順が終了するまでキャンセル状態のままになります。

    サーバ接続

    接続の確認

    接続性を確認するには、utils network ping および traceroute CLI コマンドを使用します。

    転送および予約 DNS ルックアップの検証

    utils network host CLI コマンドを使用して転送および予約 DNS ルックアップを検証します1。

    Platform Administrative Web Services

    アップグレード、再起動、およびバージョン切り替えが実行されるノードで Platform Administrative Web Services がアクティブであることを確認します。

    ポートが開いていることの確認

    ポート ガイドでリストされるポートが開いている(たとえば、NFS および SOAP コール バック ポートが他のネットワーク デバイスによってブロックされていない)ことを確認します。

    再起動によるタスクの失敗

    以下の各タスクの成功または失敗は、Prime Collaboration Deployment サーバが移行中にクラスタ内の各サーバから応答を得ることができるかどうかに依存しています。 サーバへの接続が失われた場合、または Prime Collaboration サーバがタスク中に再起動する場合、タスクは正常に完了してもエラーを表示する場合があります。

    インストール タスクの失敗

    問題

    インストール タスクの各手順の成功または失敗は、Prime Collaboration Deployment サーバが移行中にクラスタ内の各サーバから応答を得ることができるかどうかに依存しています。

    考えられる原因

    インストール タスク中に Prime Collaboration サーバが再起動すると、インストールは正常に完了していてもエラーを表示する場合があります。

    次のテーブルは、タスクがアプリケーション サーバ上で正常に完了したかどうかを確認する手順、そしてこのタイプのエラーから回復する方法について説明しています。

    ソリューション

    表 1 展開例:マルチノード クラスタ展開

    If

    解決策

    障害は最初のノードでのインストールの際に発生します

    1. 同じクラスタ ノードで新規フレッシュ インストール タスクを作成する必要があります。

      (注)     

      Cisco Unified Communications Manager および IM and Presence サービスなどの Unified Communications 製品の場合、Cisco Prime Collaboration Deployment は後続のノードをクラスタから個別にインストールするインストール タスクをサポートしません。

    2. 宛先クラスタに関連付けられた ESXi ホストの VM のステータスを確認します。 任意の VM に電源が投入され、インストールされたら、これらの VM を削除して OVA を再展開します。

      (注)      詳細は、インストール タスクに関するトピックを参照してください。

    インストールが最初のノードで正常に実行されたが Prime Collaboration Deployment が接続を失った後に後続のノードで失敗する

    1. Cisco Unified Communications Manager などの障害が発生した Unified Communications VM ノードにログインし、手動でインストール状態を確認します。 詳細は、Unified Communications 製品マニュアルを参照してください。

    2. すべての新規クラスタ ノードで新規インストール タスクを作成します。 インストールされたすべての VM の削除、新規 VM を作成するために推奨される OVA の再配備、および新規インストール タスクの作成を実行することでインストール プロセスを再起動する必要があります。

      (注)     

      VM 名が以前の設定から変更される場合、新規フレッシュ インストール クラスタを追加し、新規フレッシュ インストール タスクを作成し、そのタスクを実行する必要があります。

    3. 宛先クラスタに関連付けられた ESXi ホストの VM のステータスを確認します。 任意の VM に電源が投入され、インストールされたら、これらの VM を削除して OVA を再展開します。

      (注)     

      詳細は、インストール タスクに関するトピックを参照してください。

    アップグレード タスクの失敗

    問題

    アップグレード タスクの各手順の成功または失敗は、Prime Collaboration Deployment サーバがアップグレード中にクラスタ内の各サーバから応答を得ることができるかどうかに依存しています。

    考えられる原因

    Prime Collaboration サーバがアップグレード タスク中に再起動した場合、アップグレードは正常に完了した場合でもエラーを表示することがあります。

    次の表は、タスクがアプリケーション サーバ上で正常に完了したかどうかを確認する手順、そしてこのタイプのエラーから回復する方法について説明しています。

    ソリューション

    表 2 展開例:マルチノード クラスタ展開
    If 解決策

    障害は最初のノードのアップグレードの際に発生します

    1. どの手順に成功し、どの手順が失敗したか確認するには、[Monitoring(モニタリング)] ページでタスクのステータスを確認します。

    2. Cisco Unified Communications Manager などの最初の Unified Communications VM ノードにログインし、ソフトウェア バージョンとアップグレード ステータスを確認して、このノードが正常に新バージョンにアップグレードされたか検証します。 詳細は、Unified Communications 製品マニュアルを参照してください。

    3. 最初のノードのアップグレードが正常に行われた場合、後続ノードで新規アップグレード タスクを作成できます。

    4. 最初のノードのアップグレードに失敗した場合、すべてのノードで新規アップグレード タスクを作成できます。

    5. アップグレード タスクが自動バージョン切り替えで設定されている場合、Unified Communications 製品ノード上でアクティブおよび非アクティブなパーティションのステータスをチェックします。 自動バージョン切り替えが Unified Communications 製品ノードで失敗した場合は、バージョン切り替えを実行します。 詳細は、Unified Communications 製品マニュアルを参照してください。

      (注)      バージョン切り替えが必要な場合で、新規アップグレード タスクに自動バージョン切り替えが設定されている場合、これは後続のノードで新規アップグレード タスクを実行する前に実行する必要があります。
    (注)      アップグレード タスクが COP ファイルをインストールするために作成された場合、COP ファイルのインストール ステータスを Unified Communications ノードで直接検証します。

    アップグレードが最初のノードで正常に実行されたが Prime Collaboration Deployment が接続を失った後に後続のノードで失敗する

    1. Cisco Unified Communications Manager などの失敗した Unified Communications VM ノードにログインし、ソフトウェア バージョンとアップグレード ステータスを確認して、このノードが正常に新バージョンにアップグレードされたか検証します。 詳細は、Unified Communications 製品マニュアルを参照してください。

      (注)      後続のノードが正しい新規バージョンを表示する場合、Prime Collaboration Deployment でアップグレード タスクを再作成する必要はありません。
    2. 後続ノードで、新規バージョンが非アクティブなパーティションで表示され、古いバージョンがアクティブなパーティションで表示されており、アップグレード タスクが自動バージョン切り替えを実行するように設定されている場合、自動バージョン切り替えを Cisco Unified Communications Manager で手動で実行するか、Prime Collaboration Deployment を使用してバージョン切り替えタスクを作成する必要があります。

    3. アップグレード タスクが自動バージョン切り替えで設定され、後続のノードがバージョンを正しく表示しない場合、バージョン切り替えを実行します。 詳細は、Unified Communications 製品マニュアルを参照してください。

    (注)      アップグレード タスクが COP ファイルをインストールするために作成された場合、COP ファイルのインストール ステータスを Unified Communications ノードで直接検証します。

    移行タスクの失敗

    問題

    移行タスクの各手順の成功または失敗は、Prime Collaboration Deployment サーバが移行中にクラスタ内の各サーバから応答を得ることができるかどうかに依存しています。

    考えられる原因

    移行タスク中に Prime Collaboration サーバが再起動すると、移行は正常に完了していてもエラーを表示する場合があります。

    ソリューション

    Prime Collaboration Deployment が接続を失った後に移行タスクが失敗した場合、移行プロセス全体を再起動することをお勧めします。 移行タスクを再起動する場合、新規タスクを作成する必要があります。 展開がマルチノードのクラスタの場合、以下の手順に従うことができます。

    1. どの手順に成功し、どの手順が失敗したか確認するには、[Monitoring(モニタリング)] ページでタスクのステータスを確認します。

    2. 送信元ノードがシャット ダウンした場合、ノードの電源を手動で投入する必要があります。

      (注)  


      シャット ダウンされたすべての送信元ノードでこの手順を繰り返して行ってください。
    3. 失敗した移行タスクを削除します。

    4. 失敗した移行タスクに関連付けられる宛先移行クラスタを削除します。

      (注)  


      送信元クラスタを削除する必要はありません。
    5. 宛先クラスタに関連付けられた ESXi ホストの VM のステータスを確認します。 任意の VM に電源が投入され、インストールされたら、これらの VM を削除して OVA を再展開します。

      (注)  


      詳細は、移行タスクに関するトピックを参照してください。

    バージョン切り替えタスクの失敗

    問題

    バージョン切り替えタスクの各手順の成功または失敗は、Prime Collaboration Deployment サーバがバージョン切り替え中にクラスタ内の各サーバから応答を得ることができるかどうかに依存しています。

    考えられる原因

    Prime Collaboration サーバがバージョン切り替えタスク中に再起動する場合、バージョン切り替えは、正常に完了した場合でもエラーを表示することがあります。

    次のテーブルは、タスクがアプリケーション サーバ上で正常に完了したかどうかを確認する手順、そしてこのタイプのエラーから回復する方法について説明しています。

    ソリューション

    表 3 展開例:マルチノード クラスタ展開
    もし 解決策

    障害は最初のノードのバージョン切り替えの際に発生します

    1. 最初の Unified Communications VM ノード(たとえば、Cisco Unified Communications Manager)にログインし、アクティブおよび非アクティブなパーティションの両方でソフトウェア バージョンを手動で確認します。 詳細は、Unified Communications 製品マニュアルを参照してください。

    2. 最初のノードがアクティブなパーティションの古いバージョンをまだ表示しており、新規バージョンが非アクティブなパーティションにある場合、Prime Collaboration の同じノードで新規バージョン切り替えタスクを作成し、そのタスクを再度実行します。

    バージョン切り替えが最初のノードで正常に実行されたが Prime Collaboration Deployment が接続を失った後に後続のノードで失敗する

    1. 後続の Unified Communications VM ノード(たとえば、Cisco Unified Communications Manager)にログインし、ソフトウェアおよびバージョン切り替えステータスをチェックして後続のノードが正しいバージョンで正常に起動しているかどうか確認します。

    2. 後続ノードがアクティブなパーティションで正しい新規バージョンを表示する場合、Prime Collaboration Deployment でバージョン切り替えタスクを再作成する必要はありません。

    3. 後続ノードが非アクティブ パーティションで新規バージョンを表示しており、古いバージョンがアクティブなパーティションにある場合、後続ノードではバージョン切り替えは失敗します。 後続ノードでバージョン切り替えを手動で実行するか、Prime Collaboration Deployment でのみ後続ノードで新規バージョン切り替えタスクを作成できます。

    タスク再アドレス付けの失敗

    問題

    再アドレス付けタスクの各手順の成功または失敗は、Prime Collaboration Deployment サーバがクラスタ内のすべてのサーバから応答を得られるかどうかに依存しています。

    考えられる原因

    Prime Collaboration サーバが再アドレス付けタスク中に再起動すると、再アドレス付けに成功した場合でもエラーが通知されることがあります。

    次のテーブルは、タスクがアプリケーション サーバ上で正常に完了したかどうかを確認する手順、そしてこのタイプのエラーから回復する方法について説明しています。

    ソリューション

    表 4 展開例:マルチノード クラスタ展開
    If 解決策

    障害は最初のノードの再アドレス付けの際に発生します

    1. 最初の Unified Communications VM ノード(たとえば、Cisco Unified Communications Manager)にログインし、ネットワーク設定が正常に変更されたことを確認します。 詳細は、Unified Communications 製品マニュアルを参照してください。

    2. ネットワーク設定が最初のノードで正常に変更されたことを確認したら、Prime Collaboration Deployment 上の次のノード上で新規再アドレス付けタスクを作成し、このタスクを実行します。 ネットワーク設定が最初のノードで正常に変更されていない場合、Prime Collaboration Deployment の両方のノードで新規再アドレス付けタスクを作成し、このタスクを再実行します。

    再アドレス付けタスクが最初のノードで正常に実行されたが Prime Collaboration Deployment が接続を失った後に後続のノードで失敗する

    1. 最初の Unified Communications VM ノード(たとえば、Cisco Unified Communications Manager)にログインし、ネットワーク設定が正常に変更されたことを確認します。 詳細は、Unified Communications 製品マニュアルを参照してください。

    2. ネットワーク設定が最初のノードで正常に変更されたことを確認したら Prime Collaboration Deployment の最初のノードで新規再アドレス付けタスクを作成する必要はありませんが、後続のノードで新規再アドレス付けタスクを作成する必要はあります。 ネットワーク設定が最初のノードで正常に変更されなかった場合、Prime Collaboration Deployment 上の最初のノードおよび後続のノードで新規再アドレス付けタスクを作成し、新規タスクを実行します。

    3. ネットワーク設定が正常に変更された場合、Prime Collaboration Deployment のネットワーク設定が正しいことを確実にするために、このクラスタに対するクラスタ ディスカバリをアップデートします。
      1. [Clusters(クラスタ)] 画面で、クラスタ内のノードを示す三角形をクリックします。

      2. ネットワーク設定を確認して、必ず [Cluster Nodes(クラスタ ノード)] テーブルに新しいネットワーク設定(たとえばホスト名)が表示されるようにします。

      3. 正しいネットワーク設定が表示されない場合は、クラスタ内の各ノードに対する [Refresh Node(ノードのリフレッシュ)] のリンクをクリックします。

    サーバ再起動タスクの失敗

    問題

    サーバ再起動タスクの各手順の成功または失敗は、Prime Collaboration Deployment サーバがサーバ再起動中にクラスタ内の各サーバから応答を得ることができるかどうかに依存しています。

    考えられる原因

    Prime Collaboration サーバがサーバ再起動中に再起動する場合、サーバ再起動は正常に完了してもエラーを表示する場合があります。

    次のテーブルは、タスクがアプリケーション サーバ上で正常に完了したかどうかを確認する手順、そしてこのタイプのエラーから回復する方法について説明しています。

    ソリューション

    表 5 展開例:マルチノード クラスタ展開
    If 解決策

    障害は最初のノードのサーバ再起動の際に発生します

    1. 最初の Unified Communications VM ノード(たとえば、Cisco Unified Communications Manager)にログインし、再起動のステータスを手動でチェックします。

    2. 最初のノードが再起動されていない場合は、すべてのノードで新しいサーバ再起動タスクを再作成し、タスクを再度実行します。

    サーバ再起動が最初のノードで正常に実行されたが Prime Collaboration Deployment が接続を失った後に後続のノードで失敗する

    1. 2 番目の Unified Communications VM ノード(たとえば、Cisco Unified Communications Manager)にログインし、再起動のステータスを手動でチェックします。

    2. 後続のノードが正常に再起動した場合、新規サーバ再起動タスクを再作成する必要はありません。 後続ノードが再起動していない場合、後続ノードにのみ新規サーバ再起動タスクを作成します。

    タスクのスケジューリング

    スケジュールされているが開始されていないタスク

    タスクがスケジュールされていても開始していない場合、スケジュール日を確認します。

    検証エラー

    タスクが開始すると、一連の検証テストが実行されます。 検証エラーではタスクを一時停止します。

    タスクの一時停止の原因

    タスクが一時停止している理由(検証エラー、要求されるまたは必須の一時停止、特定の手順の後に 1 つまたは複数のノードが失敗したなど)を確認するには、[View Log(ログの表示)] ボタンをクリックします。

    キャンセルできないタスク

    タスクの中には、一度開始するとキャンセルできないものがあります(たとえば、サーバの再起動など)。 タスクをキャンセルすると、手順が終了するまでキャンセル状態のままになります。 一度開始したらキャンセルできない他のタスクはサーバ ノードのインストールです。

    タスクのタイムアウト

    結果の手動による確認

    すべての Cisco Prime Collaboration Deployment タスクには、タスクと製品のタイプに応じて、30 分から 10 時間の内蔵タイムアウトがあります。 Cisco Prime Collaboration Deployment がその期間内に期待される結果を受信しない場合、実際のプロセスが成功した場合でも Cisco Prime Collaboration Deployment はエラーを示します。 ユーザは手動で結果を確認し、偽陰性を無視する必要があります。

    再アドレス付けのタイムアウト

    再アドレス付け中、VLAN の変更が要求される場合、Cisco Prime Collaboration Deployment はそのノードに対して予期されるアップデートを受信しません。 その結果、再アドレス付けは、実際の再アドレス付けプロセスが成功した場合にもタイムアウトします。

    リソースの問題によるノードの遅延

    VMware vSphere を使用して、ノードを遅延させているリソースがないか検証します。 ディスク、CPU、およびメモリの問題によって、ログインが通常より遅くなる場合があります。これにより、クラスタ検出中に接続タイムアウトの問題が発生する場合があります。

    ネットワークの輻輳

    アップグレード、インストール、および移行中に大型のファイルがネットワークに渡ってプッシュされるため、ネットワークの輻輳によりタスクのログインに長時間かかる場合があります。

    移行とインストールのアップグレード

    VM が起動しない

    移行またはインストール中に、付属のインストール ISO を使用して VM が起動しない場合、BIOS の VM の起動順序を検証してください。 正規の Cisco OVF を使用して新規作成された VM のみを使用することをお勧めします。

    VM が見つからない

    VM が見つからない場合、vMotion が無効になっていることを確認します。

    アップグレード ファイルのリストが空

    アップグレード用の iso ファイルのリストが空の場合、アップグレードするクラスタ内の 1 つ以上のサーバに停止した既存のアップグレードがある可能性があります。 CUCM 側のアップグレード プロセスが停止したため、ファイル リストは空と表示されます。 そのため、ファイルはアップグレードできず、有効ではありません。 アプリケーション サーバ CLI からアップグレードを試行すると、メッセージ「The resource lock platform.api.network.address is currently locked(リソース ロック platform.api.network.address が現在ロックされています)」が表示される場合があります。

    この問題から回復するには、CUCM サーバの再起動を試行します。

    アップグレード ISO または COP ファイルがタスク ウィザードに表示されない

    アップグレード ISO または COP ファイルがタスク ウィザードに表示されない場合、[Administation(管理)] > [SFTP Datastore(SFTP データストア)] メニュー オプションから PCD サーバの正しいディレクトリにアップロードされていることを確認します。 使用されるディレクトリは通常タスク ウィザードの先頭に表示されます。

    アップグレード ISO はすべてのノードに対して有効である必要がある

    アップグレード ISO は、ウィザードでリストされるためにタスク内のすべてのノードで有効である必要があります。 リストされない場合、タスクにパブリッシャが含まれることまたはパブリッシャがすでにアップグレードされていることを検証します。

    リリース 10.x 以降の製品

    リリース 10.x 以前の製品の大部分は、一般的なアップグレードおよびインストール失敗のメッセージのみをレポートします。 ユーザは失敗したノードに直接アクセスし、従来のツールおよび製品固有のプロセス(たとえば、アップグレード ログを参照するには RTMT または CLI)を使用して問題を診断する必要があります。

    現在のタスクがキャンセル状態の場合の新規タスクの実行

    フレッシュ インストール タスクの再実行

    以下の処理は、プロセス内の現在のタスクがキャンセルされる場合に新規タスクを再実行するための手順の概要を示しています。 詳細については、タスク管理に関するトピックを参照してください。

    手順
      ステップ 1   最も最近のタスクのステータスを検証するにはタスク ログを参照してください。
      1. VM の電源がオンで、フレッシュ インストールタスクが宛先 VM でまだ進行中の場合、新規 VM を作成するには、VM の電源をオフにしてから削除し、OVA を再展開します。 新規 VM には同じ名前を使用できます。
      2. VM の電源がオフで、フレッシュ インストールが VM 上で開始されていない場合、VM をオフのままにしてください。
      ステップ 2   クラスタをチェックして、クラスタ内の任意のノードがアクティブなバージョンとディスカバリ ステータスでアップデートされたことを確認します。
      1. ノードのいずれかが新規バージョンでアップデートされたかまたはディスカバリ ステータスの場合、同じ VM とインストール設定を含めて新しい名前で新規クラスタを作成します。
      2. クラスタ内のノードが更新されていない場合、フレッシュ インストール タスクを再作成する場合にクラスタを再使用します。
      ステップ 3   新規インストール タスクを作成して実行します。

      移行タスクの再実行

      以下は、現在の移行タスクがキャンセル処理中である場合に同じ送信元および宛先クラスタに対して移行タスクを再実行するための手順の概要を示しています。 詳細については、タスク管理に関するトピックを参照してください。

      手順
        ステップ 1   最も最近のタスクのステータスを検証するにはタスク ログを参照してください。
        1. VM の電源がオンで、移行タスクが宛先 VM でまだ進行中の場合、新規宛先 VM を作成するには、宛先 VM の電源をオフにし、削除して、OVA を再展開します。 新規 VM には同じ名前を使用できます。
        2. VM の電源がオフで、移行が VM 上で開始されていない場合、VM をオフのままにしてください。
        ステップ 2   新規タスクを実行する前にソース クラスタ上でノードのステータスを確認してください。
        1. 送信元ノードの電源がオフの場合、送信元ノードの電源をオンにし、移行タスクを再実行する前にノードが実行状態にあることを確認してください。
        2. ネットワーク移行の場合、送信元ノードは電源オンのままとなっている場合があります。
        ステップ 3   クラスタ検出は、送信元ノードで再実行する必要はありません。
        ステップ 4   アクティブなバージョンまたは検出ステータスでノードがアップデートされていないことを宛先クラスタで確認してください。
        1. 宛先クラスタ内の任意のノードがアプリケーションまたはディスカバリ ステータスの適切なバージョンでアップデートされた場合、同じ送信元クラスタで新しい名前を付けて、同じ宛先 VM を選択することで新規移行宛先クラスタを作成します。
        2. 宛先クラスタ内のノードがアプリケーションまたは検出ステータスの新規バージョンでアップデートされていない場合、後で新規移行タスクを作成する場合に移行宛先クラスタを再利用できる場合があります。 これが可能でない場合は移行宛先クラスタを新しい名前で再作成します。
        ステップ 5   同じ送信元クラスタおよび新しい宛先クラスタを持つ新規移行タスクを作成します。
        ステップ 6   新しいタスクの実行を開始します。