vCenter Server のロールアップ ジョブがパフォーマンス データを処理しているかどうかを判断する
Article ID: 340898
Updated On:
Products
Issue/Introduction
免責事項： これは英文の記事 Determining if vCenter Server rollup jobs are processing performance data (2007388) の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。
- vCenter Server データベースが過度に大きくなっている。
- vCenter Server のロールアップ ジョブが存在する。
- パフォーマンス データの取得時に応答に時間がかかる、またはタイムアウトが生じる。
- パフォーマンス データの表示時にリアル タイム データしか確認できない。
- 24 時間以上前のパフォーマンス データにアクセスすると、次のメッセージが表示される。
Performance data is currently not available for this entity
Environment
VMware vCenter Server 5.0.x
VMware vCenter Server 4.0.x
Resolution
vCenter Server のパフォーマンス データの問題を診断するためには、vCenter Server がパフォーマンス データをどのように処理するかを理解しておくことが役立ちます。vCenter Server にデータが取り込まれたときに、いくつかのコンポーネントが対話して処理を実施します。
アーキテクチャ
vCenter Server 4.0 では、パフォーマンス データが 8 つの異なるテーブルに分割され、いくつかのロールアップ ジョブで処理されます。このジョブは、一定期間のデータを平均化し、時間の経過とともに情報を集約していきます。これらのテーブルには、メトリック データを保存する vpx_hist_stat[1-4] と、データの間隔情報を保存する vpx_sample_time[1-4] があります。
データベース テーブルをこのように分割することで、各間隔のデータが異なるテーブルに分離されるために、ストレージの負担が緩和されるほか、取り込まれるパフォーマンス データの後処理がしやすくなります。パフォーマンス データの後処理は、統計ロールアップ ジョブによって行われます。vCenter Server には、過去 1 日、過去 1 週間、過去 1 か月のロールアップ ジョブがあります。これらの各ジョブはスケジュールに従って実行され、データを遅滞なく処理して構成どおりの量の情報が保持されるようにします。
vCenter Server 4.1 および vCenter Server 5.0 には、デッドロックを防止し、データベースへの情報の取り込み速度を高めるキャッシュ メカニズムがあります。このメカニズムは、受信したパフォーマンス情報を指定した時刻に vpx_temptable[0-2] に取り込み、その後パフォーマンス データを、直接テーブルに取り込むのではなく、統計履歴テーブルに一括して取り込みます。
ワークフローとしては、パフォーマンス データが vpx_hist_stat1/vpx_sample_time1 テーブルに取り込まれると、スケジュールされた過去 1 日のロールアップ ジョブによって情報の後処理が開始されます。このジョブはスケジュールされた頻度で実行され、データを処理して平均化および集約し、 vpx_hist_stat2/vpx_sample_time2 テーブルに取り込みます。過去 1 週間や過去 1 か月のロールアップ ジョブでもこうした処理が行われるため、各間隔で情報がさらに集約され、最終的にデータが vpx_hist_stat4/vpx_sample_time4 に移されます。
ロールアップ ジョブは、デフォルトで次の間隔で実行されるようスケジュールされています。
- 過去 1 日の統計ロールアップ：30 分ごと
- 過去 1 週間の統計ロールアップ：2 時間ごと
- 過去 1 か月の統計ロールアップ：24 時間ごと
情報は処理されると消去され、元のパフォーマンス データ テーブルがクリーンアップされます。これにより、データベースが増大しすぎることはなく、vCenter で履歴データを表示できます。各間隔の情報の詳細度や期間は、管理 > vCenter Server 設定 > 統計情報（Statistics）で構成します。
- 収集期間を 有効 にするか 無効 にするか
- この統計期間の集約間隔をどのくらいにするか
- この設定は、1 つめの統計期間（上図の 5 分間）でのみ利用できます。
- この統計期間の情報をどのくらい保持するか
- デフォルトでは、統計データを 1 年しか保持せず、1 年経過後に消去されます。この保持期間は延長でき、また、より細かなデータが必要な場合は、特定の統計期間のデータを保持期間を延ばすこともできます。
- さまざまなロールアップ段階の統計期間
- デフォルトで、vCenter Server の統計期間はどれもレベル 1 に設定されています。この設定によって、その統計期間で収集されるデータの量が制御されます。
- レベル 1：基本メトリックである CPU、メモリ、ディスク、ネットワークの平均使用量、システムのアップタイム、システムのハートビート、vCenter DRS メトリックなどが含まれます。このレベルには、デバイスの統計情報は含まれません。
- レベル 2：CPU、メモリ、ディスク、ネットワークのカウンタ（平均、合計、前回のロールアップの種類。ただし、最大および最小のロールアップの種類を除く）のすべてのメトリック、システムのアップタイム、システムのハートビート、vSphere DRS メトリックなどが含まれます。このレベルには、デバイスの統計情報は含まれません。
- レベル 3：すべてのカウンタ グループ（平均、合計、前回のロールアップの種類。ただし、最大および最小のロールアップの種類を除く）のすべてのメトリックが含まれます。
- レベル 4：vCenter Server でサポートされるすべてのメトリックが含まれます。
- デフォルトで、vCenter Server の統計期間はどれもレベル 1 に設定されています。この設定によって、その統計期間で収集されるデータの量が制御されます。
注：問題をデバッグする場合を除き、統計期間をレベル 3 以上に設定することはお勧めしません。収集されるデータの量が大幅に増えるため、SQL Server に十分な処理能力がない場合にパフォーマンス データが適切に収集されないことがあります。
診断および解決策
vCenter Server でのパフォーマンス データの状況を診断するには、最初にデータベース テーブルのサイズを確認します。 vpx_hist_stat1/vpx_sample_time1 には統計期間の未処理の受信データが保存されるため、これらのテーブルでは頻繁に問題が生じます。
データベース テーブルのサイズを確認するには：
- Microsoft SQL（MSSQL）を実行している場合は、次のコマンドを実行します。
exec sp_spaceused vpx_hist_statx
この x は、統計テーブルです。
出力は次のようになります。
行 および データ 列に、データベースに存在するデータの量が示されます。許容量は環境のサイズによって異なりますが、 vpx_hist_stat1 データベース テーブルに 1000 万を超える行がある場合は、問題があるものと思われます。 - MSSQL、Oracle、および DB2 の場合は、次のコマンドを実行します。
select count(*) from vpx_hist_statx
この x は、対象の統計テーブルです。
このクエリによって、指定したデータベース テーブルの行数が返されます。
ロールアップ ジョブが実行されていない場合は、非処理のパフォーマンス データが保存されている vpx_hist_stat1 テーブルから開始します。
パフォーマンス データが処理されていないと思われるときは、次のコマンドを実行して、前回データが正常に処理され、後続のデータベース テーブルに移された時点を調べます。
select max(sample_time) from vpx_sample_time2
このクエリにより、パフォーマンス データが正常にロールアップされ、 vpx_hist_stat1/vpx_sample_time1 データベース テーブルから消去された日時が出力されます。返された日付が 24 時間より前の場合は、ロールアップ ジョブに問題のある可能性が高くなります。また、このクエリを使用して、処理中のデータの量を調べることもできます。事前に問題があった場合は、このクエリを使用して、ロールアップ ジョブがデータのバックログを処理するまで待機することが妥当かどうか、あるいはデータを切り詰めたほうがよいのかどうかを検証できます。測定期間に処理されている量より多くのデータを受信している場合は、サーバの処理が追いつくことがありません。
この問題は、次の場合に発生する可能性があります。
- 統計ロールアップ ジョブが存在しない。アップグレードやリカバリの場合は、ロールアップ ジョブのリストアが（適切に行われていても）データベースに含まれていないことがあります。MSSQL または Oracle 内に、過去 1 日、過去 1 週間、過去 1 か月のロールアップ ジョブが存在するかどうかを調べ、必要に応じて再作成します。詳細については、 Updating rollup jobs after the error:Performance data is currently not available for this entity (1004382) を参照してください。
- データベース サーバで MSSQL エージェント サービスが開始されない。デフォルトでは、SQL がインストールされると、MSSQL エージェント サービスが手動モードで開始されます。再起動時に、サービスが開始されないために、ロールアップ ジョブが実行されないことがあります。この構成を検証するために、エージェント サービスを調べ、SQL エージェント サービスが開始済み、かつ自動に設定されていることを確認します。
- 所定の構成の統計収集レベルの設定が高すぎる。統計収集レベルをレベル 3 以上にすると、問題をデバッグする場合を除き、データベースが増大することがあります。レベルを下げるとシステムは安定しますが、リカバリできないことがあります。
vpx_hist_stat1 table からの非処理の情報を切る詰めることは通常最後の手段ですが、適切な時間内にデータを処理できない場合に究極の解決策になることがあります。非処理の情報を切る詰めるには、次のコマンドを実行します。
truncate table vpx_hist_stat1
truncate table vpx_sample_time1
これらのコマンドは、処理されていないデータを削除します。問題が生じる前からある残りの履歴データはそのままです。
Additional Information
Feedback
