この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
多数の Unified CM サーバの同時移行に 1 つの Cisco Prime Collaboration Deployment サーバが使用されている場合、Cisco Prime Collaboration Deployment ディスクは空きスペースの少ない状態で実行され、移行タスクが失敗する場合があります。 Cisco Prime Collaboration Deployment を使用して複数のサーバを同時に移行する場合、以下のコマンドを実行してディスク サイズを増やすことができます。
Cisco Prime Collaboration Deployment の段階的なログを表示するには、[Monitoring(モニタリング)] ダッシュボードで [View Log(ログの表示)] ボタンを使用します。
CLI コマンドを使用して Cisco Prime Collaboration Deployment ログにアクセスして詳細を取得します。 次に例を示します。
file get activelog tomcat/logs/ucmap/log4j/*
タスクを開始する前に問題をチェックするには、[Validate(検証)] ボタンを使用します。 検証で問題が発見された場合、[View Log(ログの表示)] ボタンをクリックして検出された検証の問題に関する詳細を確認します。
Cisco Prime Collaboration Deployment に保管されたノード情報および実際のノードとの間の不一致は自動的に修正できます(たとえば、アクティブなバージョン)。 他の情報を修正するには再検出が必要です。
network capture CLI コマンドを使用して、サーバ間の通信を検証できます(たとえば、パケットが正しいポートに送受信されているかどうか)。
[Monitoring(モニタリング)] ダッシュボードの [View Log(ログの表示)] ボタンを使用して、タスクの実行時に Cisco Prime Collaboration Deployment のログを段階的に確認できます。 ログを確認する場合、イベントまたはエラーが表示される場合があります。 より一般的なエラーの例、およびそれを解決するために提案されるアクションが以下に示されています。
エラー メッセージ:
ノードの接続/コンタクトの問題を解決するために実行できるアクションは以下のとおりです。
エラー メッセージ:
問題解決のために考えられるアクションは以下のとおりです。
バージョン切り替えタスクでは、サーバが一定期間応答しない場合、切り替えに成功していても、正常に切り替えられていないように見える場合があります。 このエラーが発生した場合、応答していないサーバの CLI にログインし、show version active コマンドを発行してバージョン切り替えが正常に実行されたか確認します。 たとえば、UCCX サーバ上のバージョン切り替えは 60 分以上かかることがよくあります。
エラー メッセージ:
問題解決のために考えられるアクションは以下のとおりです。
これらのメッセージは通常、タスク実行中(インストール、アップグレードなど)に新規ノードが一定期間内に Cisco Prime Collaboration Deployment とコンタクトしない場合に表示されます。 アップグレードの場合、これは 8 時間であるため、このエラーが発生したらタスクが失敗したことを意味している場合があります。 ただし、アップグレード(またはインストール)中にサーバが Cisco Prime Collaboration Deployment とコンタクトするのを妨げるネットワーク障害が発生したことを意味する場合もあります。 そのため、このメッセージが表示されたら、(CLI を使用して)応答していないサーバにログオンし、show version active コマンドを発行してアップグレードが正常に実行されたか確認します。
エラー メッセージ:
問題解決のために考えられるアクションは以下のとおりです。
このエラーは、NFS データストアに問題がある場合に発生します。 これは Cisco Prime Collaboration Deployment が予想外にシャットダウンした場合に発生する場合があります。 このエラーが発生した場合、ESXi ホストを確認し、古い NFS マウントをアンマウントしてください。 次に、ESXi ホストを Cisco Prime Collaboration Deployment から削除してから再度追加してください。
考えられる原因:
このエラーは、ESXi ホストの vSwitch ホストのネットワーキングの問題によって発生した可能性があります。
問題解決のために考えられるアクションは以下のとおりです。
エラー メッセージ:
問題解決のために考えられるアクションは以下のとおりです。
VM が置かれる ESXi ホストを確認します。 [Tasks and Events(タスクとイベント)] タブで、Cisco Prime Collaboration Deployment がいつ VM の電源投入を試行したかを示すタイムスタンプを確認します。 そのホストの VM の数が多すぎないか確認します。 その場合は、このクラスタに使用されていない VM の電源をオフにすることが必要になる場合があります。
エラー メッセージ:
問題解決のために考えられるアクションは以下のとおりです。
移行タスクの宛先クラスタ、または新規インストール クラスタで使用される VM が OFF 状態になっている必要があります。 このエラー メッセージが表示された場合は、指定された VM を確認します。 オフになっていない場合、電源をオフにします。 次に、タスクの再試行または再開を実行できます。
エラー メッセージ:
問題解決のために考えられるアクションは以下のとおりです。
クラスタ ページでこのサーバの管理名およびパスワードを修正します。 その後、このノードを検出できます。
エラー メッセージ:
問題解決のために考えられるアクションは以下のとおりです。
サーバにアクセス可能であり、PAWS サービスがノード上でアクティブであることを確認します。 Cisco Prime Collaboration Deployment がアプリケーション サーバ上でのサーバのアップグレード、バージョン切り替え、またはタスクの再起動のために使用される場合(たとえば、Cisco Prime Collaboration Deployment が Unified CM サーバのアップグレードに使用される場合)、アプリケーション サーバで Platform Administrative Web Service がアクティブになっている必要があります。アクティブでない場合、Cisco Prime Collaboration Deployment サーバは Unified CM アプリケーション サーバと通信することができません。
エラー メッセージ:
問題解決のために考えられるアクションは以下のとおりです。
指定された仮想マシンがまだ ESXi ホスト上に存在することを確認します。 場合によっては、VM が別の ESXi ホストに移動されることがあります。この場合、VM を保持する ESXi ホストを Cisco Prime Collaboration Deployment サーバに追加する必要があります。
エラー メッセージ:
問題解決のために考えられるアクションは以下のとおりです。
Cisco Prime Collaboration Deploymentを VM にインストールまたは移行するには、ターゲット VM の電源がオフになっている必要があります。
エラー メッセージ:
問題解決のために考えられるアクションは以下のとおりです。
ノードのネットワーキング、接続、またはパスワードの問題を確認します。 また、コマンドがタイムアウトした間に別の操作が発生していたかどうか(たとえば COP ファイルのインストール)を確認します。
エラー メッセージ:
問題解決のために考えられるアクションは以下のとおりです。
タスクを実行する前に、Cisco Prime Collaboration Deployment サーバは、使用される VM が利用可能かどうか、iso ファイルを検出可能かどうかなどを確認するために検証チェックを実行します。 このメッセージは、検証チェックのいずれかが失敗したことを示しています。 どの検証が失敗したかの詳細はログ ファイルを確認してください。
大部分の製品では、一度に 1 つのみの変更を加えることができます(たとえば、アップグレードの進行中は NTP 設定を変更することはできません)。 ノードのロック中にリクエストが作成されると、以下の情報を含むロック メッセージが表示されます。
通常、数分待ってから再試行できます。 詳細については、ノード CLI を使用して、提供されたプロセス ID およびホスト名に基づいた正確なプロセスを識別します。
例外またはその他の NFS 関連の問題については、Cisco Prime Collaboration Deployment ログを参照してください。
NFS データストアが使用可能であること確認するために VMware vSphere を使用します。
Cisco Tomcat を再起動すると、現在のすべてのデータストアがマウント解除され、その再マウントが試行されます。
移行や再アドレス付けなどの特定のタスクは、手動による介入が必要になった地点で一時停止します。 これらのタスクでは、Cisco Prime Collaboration Deployment システムが一時停止を強制的に適用します。 タスクがこのポイントに到達すると、タスクは停止し、メッセージが [Monitoring(モニタリング)] ページに表示されます。 手動の手順を必要に応じて実行し、タスクの再開の準備ができたら [Resume(再開)] ボタンをクリックします。
このメッセージが表示された場合は、[View log(ログの表示)] リンクをクリックしてどの検証が失敗したかについて詳細を確認します。
このメッセージが表示された場合は、[View log(ログの表示)] リンクをクリックしてどのタスクが失敗したかについて詳細を確認します。
タスクがスケジュールされていても開始していない場合、スケジュール日を確認します。
タスクが開始すると、一連の検証テストが実行されます。 検証エラーではタスクを一時停止します。
[View Log(ログの表示)] ボタンを使用して、タスクが一時停止している理由(検証エラー、要求されるまたは必須の一時停止、特定の手順の後に 1 つまたは複数のノードが失敗したなど)を確認します。
手順の中には、一度開始するとキャンセルできないものがあります(たとえばサーバの再起動など)。 タスクをキャンセルすると、手順が終了するまでキャンセル状態のままになります。
接続性を確認するには、utils network ping および traceroute CLI コマンドを使用します。
utils network host CLI コマンドを使用して転送および予約 DNS ルックアップを検証します1。
アップグレード、再起動、およびバージョン切り替えが実行されるノードで Platform Administrative Web Services がアクティブであることを確認します。
ポート ガイドでリストされるポートが開いている(たとえば、NFS および SOAP コール バック ポートが他のネットワーク デバイスによってブロックされていない)ことを確認します。
以下の各タスクの成功または失敗は、Prime Collaboration Deployment サーバが移行中にクラスタ内の各サーバから応答を得ることができるかどうかに依存しています。 サーバへの接続が失われた場合、または Prime Collaboration サーバがタスク中に再起動する場合、タスクは正常に完了してもエラーを表示する場合があります。
インストール タスクの各手順の成功または失敗は、Prime Collaboration Deployment サーバが移行中にクラスタ内の各サーバから応答を得ることができるかどうかに依存しています。
インストール タスク中に Prime Collaboration サーバが再起動すると、インストールは正常に完了していてもエラーを表示する場合があります。
次のテーブルは、タスクがアプリケーション サーバ上で正常に完了したかどうかを確認する手順、そしてこのタイプのエラーから回復する方法について説明しています。
アップグレード タスクの各手順の成功または失敗は、Prime Collaboration Deployment サーバがアップグレード中にクラスタ内の各サーバから応答を得ることができるかどうかに依存しています。
Prime Collaboration サーバがアップグレード タスク中に再起動した場合、アップグレードは正常に完了した場合でもエラーを表示することがあります。
次の表は、タスクがアプリケーション サーバ上で正常に完了したかどうかを確認する手順、そしてこのタイプのエラーから回復する方法について説明しています。
If | 解決策 | ||||
---|---|---|---|---|---|
障害は最初のノードのアップグレードの際に発生します |
|
||||
アップグレードが最初のノードで正常に実行されたが Prime Collaboration Deployment が接続を失った後に後続のノードで失敗する |
|
移行タスクの各手順の成功または失敗は、Prime Collaboration Deployment サーバが移行中にクラスタ内の各サーバから応答を得ることができるかどうかに依存しています。
移行タスク中に Prime Collaboration サーバが再起動すると、移行は正常に完了していてもエラーを表示する場合があります。
Prime Collaboration Deployment が接続を失った後に移行タスクが失敗した場合、移行プロセス全体を再起動することをお勧めします。 移行タスクを再起動する場合、新規タスクを作成する必要があります。 展開がマルチノードのクラスタの場合、以下の手順に従うことができます。
どの手順に成功し、どの手順が失敗したか確認するには、[Monitoring(モニタリング)] ページでタスクのステータスを確認します。
(注) |
シャット ダウンされたすべての送信元ノードでこの手順を繰り返して行ってください。 |
失敗した移行タスクを削除します。
(注) |
送信元クラスタを削除する必要はありません。 |
(注) |
詳細は、移行タスクに関するトピックを参照してください。 |
バージョン切り替えタスクの各手順の成功または失敗は、Prime Collaboration Deployment サーバがバージョン切り替え中にクラスタ内の各サーバから応答を得ることができるかどうかに依存しています。
Prime Collaboration サーバがバージョン切り替えタスク中に再起動する場合、バージョン切り替えは、正常に完了した場合でもエラーを表示することがあります。
次のテーブルは、タスクがアプリケーション サーバ上で正常に完了したかどうかを確認する手順、そしてこのタイプのエラーから回復する方法について説明しています。
もし | 解決策 |
---|---|
障害は最初のノードのバージョン切り替えの際に発生します |
|
バージョン切り替えが最初のノードで正常に実行されたが Prime Collaboration Deployment が接続を失った後に後続のノードで失敗する |
|
再アドレス付けタスクの各手順の成功または失敗は、Prime Collaboration Deployment サーバがクラスタ内のすべてのサーバから応答を得られるかどうかに依存しています。
Prime Collaboration サーバが再アドレス付けタスク中に再起動すると、再アドレス付けに成功した場合でもエラーが通知されることがあります。
次のテーブルは、タスクがアプリケーション サーバ上で正常に完了したかどうかを確認する手順、そしてこのタイプのエラーから回復する方法について説明しています。
If | 解決策 |
---|---|
障害は最初のノードの再アドレス付けの際に発生します |
|
再アドレス付けタスクが最初のノードで正常に実行されたが Prime Collaboration Deployment が接続を失った後に後続のノードで失敗する |
|
サーバ再起動タスクの各手順の成功または失敗は、Prime Collaboration Deployment サーバがサーバ再起動中にクラスタ内の各サーバから応答を得ることができるかどうかに依存しています。
Prime Collaboration サーバがサーバ再起動中に再起動する場合、サーバ再起動は正常に完了してもエラーを表示する場合があります。
次のテーブルは、タスクがアプリケーション サーバ上で正常に完了したかどうかを確認する手順、そしてこのタイプのエラーから回復する方法について説明しています。
If | 解決策 |
---|---|
障害は最初のノードのサーバ再起動の際に発生します |
|
サーバ再起動が最初のノードで正常に実行されたが Prime Collaboration Deployment が接続を失った後に後続のノードで失敗する |
タスクがスケジュールされていても開始していない場合、スケジュール日を確認します。
タスクが開始すると、一連の検証テストが実行されます。 検証エラーではタスクを一時停止します。
タスクが一時停止している理由(検証エラー、要求されるまたは必須の一時停止、特定の手順の後に 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、およびメモリの問題によって、ログインが通常より遅くなる場合があります。これにより、クラスタ検出中に接続タイムアウトの問題が発生する場合があります。
アップグレード、インストール、および移行中に大型のファイルがネットワークに渡ってプッシュされるため、ネットワークの輻輳によりタスクのログインに長時間かかる場合があります。
移行またはインストール中に、付属のインストール ISO を使用して VM が起動しない場合、BIOS の VM の起動順序を検証してください。 正規の Cisco OVF を使用して新規作成された VM のみを使用することをお勧めします。
VM が見つからない場合、vMotion が無効になっていることを確認します。
アップグレード用の iso ファイルのリストが空の場合、アップグレードするクラスタ内の 1 つ以上のサーバに停止した既存のアップグレードがある可能性があります。 CUCM 側のアップグレード プロセスが停止したため、ファイル リストは空と表示されます。 そのため、ファイルはアップグレードできず、有効ではありません。 アプリケーション サーバ CLI からアップグレードを試行すると、メッセージ「The resource lock platform.api.network.address is currently locked(リソース ロック platform.api.network.address が現在ロックされています)」が表示される場合があります。
この問題から回復するには、CUCM サーバの再起動を試行します。
アップグレード ISO または COP ファイルがタスク ウィザードに表示されない場合、[Administation(管理)] > [SFTP Datastore(SFTP データストア)] メニュー オプションから PCD サーバの正しいディレクトリにアップロードされていることを確認します。 使用されるディレクトリは通常タスク ウィザードの先頭に表示されます。
アップグレード ISO は、ウィザードでリストされるためにタスク内のすべてのノードで有効である必要があります。 リストされない場合、タスクにパブリッシャが含まれることまたはパブリッシャがすでにアップグレードされていることを検証します。
リリース 10.x 以前の製品の大部分は、一般的なアップグレードおよびインストール失敗のメッセージのみをレポートします。 ユーザは失敗したノードに直接アクセスし、従来のツールおよび製品固有のプロセス(たとえば、アップグレード ログを参照するには RTMT または CLI)を使用して問題を診断する必要があります。
以下の処理は、プロセス内の現在のタスクがキャンセルされる場合に新規タスクを再実行するための手順の概要を示しています。 詳細については、タスク管理に関するトピックを参照してください。
ステップ 1 | 最も最近のタスクのステータスを検証するにはタスク ログを参照してください。 |
ステップ 2 | クラスタをチェックして、クラスタ内の任意のノードがアクティブなバージョンとディスカバリ ステータスでアップデートされたことを確認します。 |
ステップ 3 | 新規インストール タスクを作成して実行します。 |
以下は、現在の移行タスクがキャンセル処理中である場合に同じ送信元および宛先クラスタに対して移行タスクを再実行するための手順の概要を示しています。 詳細については、タスク管理に関するトピックを参照してください。
ステップ 1 | 最も最近のタスクのステータスを検証するにはタスク ログを参照してください。 |
ステップ 2 | 新規タスクを実行する前にソース クラスタ上でノードのステータスを確認してください。 |
ステップ 3 | クラスタ検出は、送信元ノードで再実行する必要はありません。 |
ステップ 4 | アクティブなバージョンまたは検出ステータスでノードがアップデートされていないことを宛先クラスタで確認してください。 |
ステップ 5 | 同じ送信元クラスタおよび新しい宛先クラスタを持つ新規移行タスクを作成します。 |
ステップ 6 | 新しいタスクの実行を開始します。 |
目次
- Cisco Prime Collaboration Deployment のトラブルシューティング
- 移行用のディスク容量
- 一般的なトラブルシューティングの問題
- [View Log(ログの表示)] に表示されるエラー
- ロック エラー
- NFS データストア
- [Monitor(モニタ)] ページの一時停止状態
- スケジューリング
- サーバ接続
- 再起動によるタスクの失敗
- インストール タスクの失敗
- アップグレード タスクの失敗
- 移行タスクの失敗
- バージョン切り替えタスクの失敗
- タスク再アドレス付けの失敗
- サーバ再起動タスクの失敗
- タスクのスケジューリング
- タスクのタイムアウト
- 移行とインストールのアップグレード
- 現在のタスクがキャンセル状態の場合の新規タスクの実行
- フレッシュ インストール タスクの再実行
- 移行タスクの再実行
移行用のディスク容量
手順多数の 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(ログの表示)] ボタンをクリックして検出された検証の問題に関する詳細を確認します。
[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(ノードにコンタクトできませんでした)"
ノードの接続/コンタクトの問題を解決するために実行できるアクションは以下のとおりです。
他の接続の問題
エラー メッセージ:
- "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 を確認します。 オフになっていない場合、電源をオフにします。 次に、タスクの再試行または再開を実行できます。
ユーザ名またはパスワードが無効
エラー メッセージ:
問題解決のために考えられるアクションは以下のとおりです。
クラスタ ページでこのサーバの管理名およびパスワードを修正します。 その後、このノードを検出できます。
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}
エラー メッセージ:
問題解決のために考えられるアクションは以下のとおりです。
指定された仮想マシンがまだ 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 の電源がオフになっている必要があります。
[Monitor(モニタ)] ページの一時停止状態
スケジューリング
サーバ接続
再起動によるタスクの失敗
インストール タスクの失敗
問題
インストール タスクの各手順の成功または失敗は、Prime Collaboration Deployment サーバが移行中にクラスタ内の各サーバから応答を得ることができるかどうかに依存しています。
考えられる原因
インストール タスク中に Prime Collaboration サーバが再起動すると、インストールは正常に完了していてもエラーを表示する場合があります。
次のテーブルは、タスクがアプリケーション サーバ上で正常に完了したかどうかを確認する手順、そしてこのタイプのエラーから回復する方法について説明しています。
ソリューション
表 1 展開例:マルチノード クラスタ展開 If
解決策
障害は最初のノードでのインストールの際に発生します
同じクラスタ ノードで新規フレッシュ インストール タスクを作成する必要があります。
(注) Cisco Unified Communications Manager および IM and Presence サービスなどの Unified Communications 製品の場合、Cisco Prime Collaboration Deployment は後続のノードをクラスタから個別にインストールするインストール タスクをサポートしません。
宛先クラスタに関連付けられた ESXi ホストの VM のステータスを確認します。 任意の VM に電源が投入され、インストールされたら、これらの VM を削除して OVA を再展開します。
(注) 詳細は、インストール タスクに関するトピックを参照してください。 インストールが最初のノードで正常に実行されたが Prime Collaboration Deployment が接続を失った後に後続のノードで失敗する
Cisco Unified Communications Manager などの障害が発生した Unified Communications VM ノードにログインし、手動でインストール状態を確認します。 詳細は、Unified Communications 製品マニュアルを参照してください。
すべての新規クラスタ ノードで新規インストール タスクを作成します。 インストールされたすべての VM の削除、新規 VM を作成するために推奨される OVA の再配備、および新規インストール タスクの作成を実行することでインストール プロセスを再起動する必要があります。
(注) VM 名が以前の設定から変更される場合、新規フレッシュ インストール クラスタを追加し、新規フレッシュ インストール タスクを作成し、そのタスクを実行する必要があります。
宛先クラスタに関連付けられた ESXi ホストの VM のステータスを確認します。 任意の VM に電源が投入され、インストールされたら、これらの VM を削除して OVA を再展開します。
(注) 詳細は、インストール タスクに関するトピックを参照してください。
アップグレード タスクの失敗
問題
アップグレード タスクの各手順の成功または失敗は、Prime Collaboration Deployment サーバがアップグレード中にクラスタ内の各サーバから応答を得ることができるかどうかに依存しています。
考えられる原因
Prime Collaboration サーバがアップグレード タスク中に再起動した場合、アップグレードは正常に完了した場合でもエラーを表示することがあります。
次の表は、タスクがアプリケーション サーバ上で正常に完了したかどうかを確認する手順、そしてこのタイプのエラーから回復する方法について説明しています。
ソリューション
表 2 展開例:マルチノード クラスタ展開 If 解決策 障害は最初のノードのアップグレードの際に発生します
どの手順に成功し、どの手順が失敗したか確認するには、[Monitoring(モニタリング)] ページでタスクのステータスを確認します。
Cisco Unified Communications Manager などの最初の Unified Communications VM ノードにログインし、ソフトウェア バージョンとアップグレード ステータスを確認して、このノードが正常に新バージョンにアップグレードされたか検証します。 詳細は、Unified Communications 製品マニュアルを参照してください。
最初のノードのアップグレードが正常に行われた場合、後続ノードで新規アップグレード タスクを作成できます。
最初のノードのアップグレードに失敗した場合、すべてのノードで新規アップグレード タスクを作成できます。
アップグレード タスクが自動バージョン切り替えで設定されている場合、Unified Communications 製品ノード上でアクティブおよび非アクティブなパーティションのステータスをチェックします。 自動バージョン切り替えが Unified Communications 製品ノードで失敗した場合は、バージョン切り替えを実行します。 詳細は、Unified Communications 製品マニュアルを参照してください。
(注) バージョン切り替えが必要な場合で、新規アップグレード タスクに自動バージョン切り替えが設定されている場合、これは後続のノードで新規アップグレード タスクを実行する前に実行する必要があります。
(注) アップグレード タスクが COP ファイルをインストールするために作成された場合、COP ファイルのインストール ステータスを Unified Communications ノードで直接検証します。 アップグレードが最初のノードで正常に実行されたが Prime Collaboration Deployment が接続を失った後に後続のノードで失敗する
Cisco Unified Communications Manager などの失敗した Unified Communications VM ノードにログインし、ソフトウェア バージョンとアップグレード ステータスを確認して、このノードが正常に新バージョンにアップグレードされたか検証します。 詳細は、Unified Communications 製品マニュアルを参照してください。
(注) 後続のノードが正しい新規バージョンを表示する場合、Prime Collaboration Deployment でアップグレード タスクを再作成する必要はありません。 後続ノードで、新規バージョンが非アクティブなパーティションで表示され、古いバージョンがアクティブなパーティションで表示されており、アップグレード タスクが自動バージョン切り替えを実行するように設定されている場合、自動バージョン切り替えを Cisco Unified Communications Manager で手動で実行するか、Prime Collaboration Deployment を使用してバージョン切り替えタスクを作成する必要があります。
アップグレード タスクが自動バージョン切り替えで設定され、後続のノードがバージョンを正しく表示しない場合、バージョン切り替えを実行します。 詳細は、Unified Communications 製品マニュアルを参照してください。
(注) アップグレード タスクが COP ファイルをインストールするために作成された場合、COP ファイルのインストール ステータスを Unified Communications ノードで直接検証します。 移行タスクの失敗
ソリューション
Prime Collaboration Deployment が接続を失った後に移行タスクが失敗した場合、移行プロセス全体を再起動することをお勧めします。 移行タスクを再起動する場合、新規タスクを作成する必要があります。 展開がマルチノードのクラスタの場合、以下の手順に従うことができます。
どの手順に成功し、どの手順が失敗したか確認するには、[Monitoring(モニタリング)] ページでタスクのステータスを確認します。
送信元ノードがシャット ダウンした場合、ノードの電源を手動で投入する必要があります。
(注)
シャット ダウンされたすべての送信元ノードでこの手順を繰り返して行ってください。失敗した移行タスクを削除します。
失敗した移行タスクに関連付けられる宛先移行クラスタを削除します。
(注)
送信元クラスタを削除する必要はありません。 宛先クラスタに関連付けられた ESXi ホストの VM のステータスを確認します。 任意の VM に電源が投入され、インストールされたら、これらの VM を削除して OVA を再展開します。
(注)
詳細は、移行タスクに関するトピックを参照してください。バージョン切り替えタスクの失敗
問題
バージョン切り替えタスクの各手順の成功または失敗は、Prime Collaboration Deployment サーバがバージョン切り替え中にクラスタ内の各サーバから応答を得ることができるかどうかに依存しています。
考えられる原因
Prime Collaboration サーバがバージョン切り替えタスク中に再起動する場合、バージョン切り替えは、正常に完了した場合でもエラーを表示することがあります。
次のテーブルは、タスクがアプリケーション サーバ上で正常に完了したかどうかを確認する手順、そしてこのタイプのエラーから回復する方法について説明しています。
ソリューション
表 3 展開例:マルチノード クラスタ展開 もし 解決策 障害は最初のノードのバージョン切り替えの際に発生します
最初の Unified Communications VM ノード(たとえば、Cisco Unified Communications Manager)にログインし、アクティブおよび非アクティブなパーティションの両方でソフトウェア バージョンを手動で確認します。 詳細は、Unified Communications 製品マニュアルを参照してください。
最初のノードがアクティブなパーティションの古いバージョンをまだ表示しており、新規バージョンが非アクティブなパーティションにある場合、Prime Collaboration の同じノードで新規バージョン切り替えタスクを作成し、そのタスクを再度実行します。
バージョン切り替えが最初のノードで正常に実行されたが Prime Collaboration Deployment が接続を失った後に後続のノードで失敗する
後続の Unified Communications VM ノード(たとえば、Cisco Unified Communications Manager)にログインし、ソフトウェアおよびバージョン切り替えステータスをチェックして後続のノードが正しいバージョンで正常に起動しているかどうか確認します。
後続ノードがアクティブなパーティションで正しい新規バージョンを表示する場合、Prime Collaboration Deployment でバージョン切り替えタスクを再作成する必要はありません。
後続ノードが非アクティブ パーティションで新規バージョンを表示しており、古いバージョンがアクティブなパーティションにある場合、後続ノードではバージョン切り替えは失敗します。 後続ノードでバージョン切り替えを手動で実行するか、Prime Collaboration Deployment でのみ後続ノードで新規バージョン切り替えタスクを作成できます。
タスク再アドレス付けの失敗
考えられる原因
Prime Collaboration サーバが再アドレス付けタスク中に再起動すると、再アドレス付けに成功した場合でもエラーが通知されることがあります。
次のテーブルは、タスクがアプリケーション サーバ上で正常に完了したかどうかを確認する手順、そしてこのタイプのエラーから回復する方法について説明しています。
ソリューション
表 4 展開例:マルチノード クラスタ展開 If 解決策 障害は最初のノードの再アドレス付けの際に発生します
最初の Unified Communications VM ノード(たとえば、Cisco Unified Communications Manager)にログインし、ネットワーク設定が正常に変更されたことを確認します。 詳細は、Unified Communications 製品マニュアルを参照してください。
ネットワーク設定が最初のノードで正常に変更されたことを確認したら、Prime Collaboration Deployment 上の次のノード上で新規再アドレス付けタスクを作成し、このタスクを実行します。 ネットワーク設定が最初のノードで正常に変更されていない場合、Prime Collaboration Deployment の両方のノードで新規再アドレス付けタスクを作成し、このタスクを再実行します。
再アドレス付けタスクが最初のノードで正常に実行されたが Prime Collaboration Deployment が接続を失った後に後続のノードで失敗する
最初の Unified Communications VM ノード(たとえば、Cisco Unified Communications Manager)にログインし、ネットワーク設定が正常に変更されたことを確認します。 詳細は、Unified Communications 製品マニュアルを参照してください。
ネットワーク設定が最初のノードで正常に変更されたことを確認したら Prime Collaboration Deployment の最初のノードで新規再アドレス付けタスクを作成する必要はありませんが、後続のノードで新規再アドレス付けタスクを作成する必要はあります。 ネットワーク設定が最初のノードで正常に変更されなかった場合、Prime Collaboration Deployment 上の最初のノードおよび後続のノードで新規再アドレス付けタスクを作成し、新規タスクを実行します。
ネットワーク設定が正常に変更された場合、Prime Collaboration Deployment のネットワーク設定が正しいことを確実にするために、このクラスタに対するクラスタ ディスカバリをアップデートします。サーバ再起動タスクの失敗
問題
サーバ再起動タスクの各手順の成功または失敗は、Prime Collaboration Deployment サーバがサーバ再起動中にクラスタ内の各サーバから応答を得ることができるかどうかに依存しています。
考えられる原因
Prime Collaboration サーバがサーバ再起動中に再起動する場合、サーバ再起動は正常に完了してもエラーを表示する場合があります。
次のテーブルは、タスクがアプリケーション サーバ上で正常に完了したかどうかを確認する手順、そしてこのタイプのエラーから回復する方法について説明しています。
タスクのスケジューリング
タスクのタイムアウト
結果の手動による確認
すべての Cisco Prime Collaboration Deployment タスクには、タスクと製品のタイプに応じて、30 分から 10 時間の内蔵タイムアウトがあります。 Cisco Prime Collaboration Deployment がその期間内に期待される結果を受信しない場合、実際のプロセスが成功した場合でも Cisco Prime Collaboration Deployment はエラーを示します。 ユーザは手動で結果を確認し、偽陰性を無視する必要があります。
再アドレス付けのタイムアウト
再アドレス付け中、VLAN の変更が要求される場合、Cisco Prime Collaboration Deployment はそのノードに対して予期されるアップデートを受信しません。 その結果、再アドレス付けは、実際の再アドレス付けプロセスが成功した場合にもタイムアウトします。
移行とインストールのアップグレード
VM が起動しない
移行またはインストール中に、付属のインストール ISO を使用して VM が起動しない場合、BIOS の VM の起動順序を検証してください。 正規の Cisco OVF を使用して新規作成された VM のみを使用することをお勧めします。
アップグレード ファイルのリストが空
アップグレード用の 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 サーバの正しいディレクトリにアップロードされていることを確認します。 使用されるディレクトリは通常タスク ウィザードの先頭に表示されます。
現在のタスクがキャンセル状態の場合の新規タスクの実行
フレッシュ インストール タスクの再実行
移行タスクの再実行
手順以下は、現在の移行タスクがキャンセル処理中である場合に同じ送信元および宛先クラスタに対して移行タスクを再実行するための手順の概要を示しています。 詳細については、タスク管理に関するトピックを参照してください。
ステップ 1 最も最近のタスクのステータスを検証するにはタスク ログを参照してください。 ステップ 2 新規タスクを実行する前にソース クラスタ上でノードのステータスを確認してください。 ステップ 3 クラスタ検出は、送信元ノードで再実行する必要はありません。 ステップ 4 アクティブなバージョンまたは検出ステータスでノードがアップデートされていないことを宛先クラスタで確認してください。 ステップ 5 同じ送信元クラスタおよび新しい宛先クラスタを持つ新規移行タスクを作成します。 ステップ 6 新しいタスクの実行を開始します。