1.3.1 データベース容量の管理
(1) IMデータベース容量の管理
JP1/IMが使用する統合監視DBは,運用を継続しても無効領域が増加しないよう設計されています。必要な容量を確保していれば,運用中にデータベースを確認する必要はありません。
データ自体は,セットアップ時に作成されたデータベースに書き込むため,基本的にはセットアップ時に容量を見積もっておけば,容量の増加を考慮する必要はありません。
ログファイル容量の増加については,「1.3.2 ログファイル容量の管理」を参照してください。
統合監視DBでは,JP1イベントの容量が格納可能な範囲を超えた場合,JP1イベントが自動で削除されます。そのため,定期的にJP1イベントの情報を保存出力し,データの消失を防ぐ必要があります。
次に,保存出力を用いてディスク容量を管理する手順を示します。
-
保存出力に関する情報を確認する。
jcoevtreport -showsv
コマンドを実行すると,保存出力に関する情報を表示します。情報を参考に,保存出力する周期,保存出力に必要な空き容量を見積もってください。
表示する項目を次の表に示します。
表1‒15 表示する項目 表示項目
内容
未出力イベントの割合
統合監視DB内の保存出力していないJP1イベントの割合(統合監視DBの最大件数との比率)をパーセンテージで表示します。
未出力イベントのサイズ
統合監視DB内の保存出力していないJP1イベントの統合監視DB内でのデータサイズを,メガバイト単位で表示します。
表示するサイズは,統合監視DB内でのデータサイズです。CSV出力には,表示された未出力イベントのサイズ×1.2の容量が必要となります。
削除警告通知設定
削除警告通知位置の設定値を表示します。
削除警告通知がOFFの場合は「-」(半角ハイフン)を表示します。
-
未出力イベントを保存出力する。
jcoevtreport -save
コマンドを実行すると,保存出力していないJP1イベントをすべてCSV形式で出力します。
jcoevtreportコマンドについては,マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「jcoevtreport」(1. コマンド)を参照してください。
JP1イベントが多く発生してしまい,定期的な保存出力では間に合わなかった場合は,削除警告通知イベントを発行できます。削除警告通知イベントは,保存出力していないJP1イベントの割合が削除警告通知位置を超えたことを通知します。
次に,削除警告通知の設定手順を示します。
-
削除警告通知イベントの発行を有効にする。
jcoimdef -dbntc ON
コマンドを実行すると,統合監視DB内の保存出力していないJP1イベントの割合(統合監視DBの最大件数との比率)が削除警告通知位置を超えたとき,削除警告通知イベントを発行する機能を有効にします。削除警告通知イベントのデフォルトはOFFです。
-
削除警告通知位置を指定する。
jcoimdef -dbntcpos 70
コマンドを実行すると,削除警告通知イベントを発行するJP1イベントの割合を,70%に指定します。
jcoimdefコマンドについては,マニュアル「JP1/Integrated Management 3 - Manager コマンド・定義ファイル・APIリファレンス」の「jcoimdef」(1. コマンド)を参照してください。
IM構成管理DBを使用している場合については,「1.2.1(5) IMデータベースの再編成」を参照してください。
(2) インテリジェント統合管理データベース容量の管理
インテリジェント統合管理データベースとして使用しているPostgreSQLのディスク容量が不足すると,次のような問題が発生するおそれがあります。
-
トレンドデータの書き込み,参照,削除の実行不可
-
データベースの強制終了
-
トレンドデータの破損※
- 注※
-
インテリジェント統合管理データベース(PostgreSQL)では,データベースの処理を高速に行えるように,トレンドデータが書き込まれる際のディスクアクセスをできる限り減らし,WAL(先行書き込みログ)と呼ばれるログにデータベースに対する更新操作(トランザクション)の内容を書き出し,ある程度まとまった単位でディスクに書き出すようにしています。ディスクフルの状態となるタイミングによっては,このWALへの書き出しに失敗したり,WALのファイル自体が破損したりすることが考えられます。
上記のような問題を未然に防止するには,ディスクの空き容量を監視する運用が必要です。
なお,データベース内で頻繁に登録が行われるデータに限り,データ件数が登録可能な上限に達した場合は,登録日時の古いデータが削除されて新しいデータが登録されます。
次の表に示す「JP1/IM - Managerでの監視対象ディレクトリ」のディスクの空き容量を監視してください。
監視対象となる領域 |
JP1/IM - Managerでの監視対象ディレクトリ |
|
---|---|---|
データベースクラスタ領域 |
インテリジェント統合管理データベースのデータファイルの格納先※1 |
|
TABLESPACE領域 |
||
データベースの一時領域 |
||
WALの格納領域 |
||
データベースのログの格納領域 |
||
サーバーログの格納領域 |
運用コマンドの個別ログ |
運用コマンドの個別ログの格納先※1 |
トレンドデータ管理サービスのログ |
トレンドデータ管理サービスのログの格納先※1 |
|
OSのログ |
Windowsイベントログ |
システムドライブ:\Windows\System32\winevt\Logs |
syslog |
/var/log※2 |
|
シスログ(syslog) |
/var/log※2 |
- 注※1
-
マニュアル「JP1/Integrated Management 3 - Manager 導入・設計ガイド」の「2.7.1(1)(d) 関連ファイルの格納先」を参照してください。
- 注※2
-
Linux 7以降の場合,格納先は,「/etc/syslog.conf」または「/etc/rsyslog.conf」で変更できます。格納先を変更した場合は,変更先のディレクトリを監視対象としてください。
- 注意事項
-
データベースの再編成は自動で行うため,ユーザーによる再編成の必要はありません。
ユーザー単位のディスククォータを使用している場合は,トレンドデータ管理DBを起動するユーザーに対して,ディスクの使用量と使用限度を監視してください。ディスクの容量不足に余裕をもって対処できるように,例えば,ディスクの空き容量が,全体の20%を割り込む状態となったときに対処するなど,あらかじめ目安を設けておく運用を推奨します。
なお,インテリジェント統合管理データベースで管理するトレンドデータは,一定期間(デフォルトの保存期間は32日)が経過すると削除されますが,次のような場合に,トレンドデータが削除されるよりも前に,大量のトレンドデータがインテリジェント統合管理データベースに挿入されることで,ディスクが枯渇してしまうリスクが考えられます。
-
トレンドデータの保存期間を長めに設定した場合
-
監視対象数やサンプル数が極端に多い場合
一定期間(1日,1週間など)の稼働後に,稼働前後のディスク使用量の増加量を元に,ディスクフルの状態となる時期を想定するなどして,事前に,ディスクの容量不足の対処に関する計画を立てておくことを検討してください。
(a) ディスクフル状態からの復旧
ディスクフルの状態となった場合に復旧する手順を,次に示します。
-
サービスが停止していることを確認する。
万が一,ディスクフルの状態となった場合,いったん監視エージェントからのリクエストを受け付けない状態にして対処を行う必要があるため,インテリジェント統合管理データベースのサービス※が停止していることを確認してください。また,トレンドデータ管理サービスも停止させてください。
- 注※
-
ディスクフルの状態となった場合,サービスは強制終了していることが考えられますが,サービスが停止していなかったときは,停止させてください。
-
ディスクの空き領域を確保する。
不要なファイルの削除やディスク領域の追加(LVMなどOS機能)を行って,十分なディスクの空き領域を確保してください。
-
サービスを起動する。
インテリジェント統合管理データベースのサービス,およびトレンドデータ管理サービスを起動してください。
上記の手順で復旧できなかった場合は,インテリジェント統合管理データベースの削除および再構築を行ってください。定期的にバックアップを取得しているときは,バックアップからリカバリーすることで,前回バックアップを取得した時点の状態には復旧※できます。
- 注※
-
基本的には,ディスクフルの状態となった場合,それまでに収集したトレンドデータの復旧は保証できません。