JP2007102452A - システム管理プログラムおよびシステム管理方法 - Google Patents

Abstract

【課題】アプリケーションによるデータのアクセス状況に応じたシステムの効率的な運用環境構築を支援できるようにする。
【解決手段】アプリケーション情報収集手段１ａは、ネットワークシステムを構成するサーバ２でアプリケーションプログラムが実行されることで実現するアプリケーション機能２ａからデータへのアクセス状況を示す管理情報を取得し、システム管理テーブル１ｃに登録する。システム情報収集手段１ｂは、サーバ２のオペレーティングシステム２ｂが有する資源管理情報を取得し、システム管理テーブル１ｃに登録する。情報解析手段１ｄは、システム管理テーブル１ｃを参照し、アプリケーション機能のデータアクセス状況に応じた資源の管理状況の適否を判断する。
【選択図】図１

Description

本発明は複数のサーバで構成されるシステム構成をコンピュータで管理するためのシステム管理プログラムおよびシステム管理方法に関し、特にハードウェア資源の自動追加が可能なシステム管理プログラムおよびシステム管理方法に関する。

現在、ネットワークを介して様々なサービスの提供が行われている。その場合、ユーザの増加等の影響により、運用中のシステムの負荷が増加することがある。そこで、適宜、システムの機能を増強する必要が生じる。一般的には、コンピュータシステムの処理能力が不足した際に、不足分を補う資源（サーバやストレージデバイスなど）を追加し、システム全体を構築し直すこととなる。

また、コンピュータシステムが大規模になり、且つ頻繁にシステム構成が変更されると、資源を効率よく運用するのが難しくなる。そこで、ストレージデバイス等の資源運用の効率化を図るためのさまざまな技術が考えられている（例えば、特許文献１−３参照）。
特開２００４−２２７３５９号公報 特開２００１−１８４１７５号公報 特開平５−１７３８７３号公報

ところで、従来のシステムは、ディスクの空き容量等のＯＳ（Operating System）で管理されている各種管理情報に基づいて、最適なシステム構成を判断している。しかし、実際には、アプリケーションプログラムに基づく機能（以下、単にアプリケーションと呼ぶ）が資源を利用した処理を実行しているため、ＯＳから得られる管理情報のみに基づく判断では、判断の的確性に欠ける場合があった。

たとえば、ホストコンピュータに接続されているストレージデバイス（ＲＡＩＤ（Redundant Arrays of Inexpensive Disks）装置を含む）にデータを格納する場合、そのシステム上で動作するアプリケーションが、そのアプリケーションに割り当てられたディスク上にデータを書き込む。書き込まれたデータは、アプリケーションによって更新、削除等が行われる。

アプリケーションによって処理されるデータには様々な属性（更新日、大きさ、所有者、Ｉ／Ｏレスポンス、重要性、リカバリ頻度）がある。これらの属性には、重要性やリカバリ頻度のように、アプリケーション上でしか把握できないものがある。その属性を考慮せずに資源の過不足を判断すると、下記のような問題が生じる。

１）一般的なファイルシステムは、データの最後のアクセス日時の情報は有しているが、アクセス頻度に関する情報は有していない。アクセス頻度が低いデータが、高速且つ高額なディスク装置に放置されれば、ディスクの投資対効果の悪化を招く。すなわち、低いアクセス頻度のデータは、高速かつ高額なディスクに格納しておく必要はない。そのデータを別の媒体に移動させることで、高機能のディスクを有効利用できる。

２）アクセス頻度の低いデータがディスク装置内に放置されそのディスク装置の空き容量が少なくなると、大きなデータを連続の領域に格納できなくなる等の理由により、ディスクのＩ／Ｏレスポンス（アクセス要求を出してから応答があるまでの時間）の悪化を招く。この現象は、アクセス箇所がディスクの一定箇所に集中した場合に顕著に現れる。

３）最近のコンピュータシステムでは、ディスク装置の増設等の構成変更が頻繁に行われる。すると、アクセスの監視機能が設けられている場合でも、増設されたディスク装置が監視対象から漏れてしまうことがある。そのため、ディスク装置内のデータへのアプリケーションからのアクセス状況を、アクセスを行うアプリケーションとは別の監視機能を用いて常に監視し続けることが困難である。

４）スケジュールに沿ったデータの自動バックアップは、専用のアプリケーションによって行われる。このようなバックアップスケジュールがシステムの運用管理の情報として利用されていないため、非効率なバックアップが行われていた。例えば、バックアップ管理において、データの更新状態を加味したバックアップになっておらず（差分バックアップはあるが最適スケジューリングか否かは不明）、データ消失の危険度に関係なく所定の期間（１回／日または週）でバックアップしている。そのため、アプリケーションの欠陥のような事象から災害発生に至るあらゆる局面での影響（手もどり）が大きい。

５）バックアップの対象とするディスクを管理者が予め設定することでバックアップが行われる。そのため、ハードウェアの増減設によりバックアップを忘れがちである。
このように、従来は、アプリケーションから得られる管理情報が不足していることにより、アプリケーションの処理内容に応じた効率的なシステム管理が難しかった。

本発明はこのような点に鑑みてなされたものであり、アプリケーションによるデータのアクセス状況に応じたシステムの効率的な運用環境構築を支援できるシステム管理プログラムおよびシステム管理方法を提供することを目的とする。

本発明では上記課題を解決するために、図１に示すようなシステム管理プログラムが提供される。本発明に係るシステム管理プログラムは、システムの構成の最適化を支援するために、図１に示す機能をコンピュータに実行させることができる。

アプリケーション情報収集手段１ａは、ネットワークシステムを構成するサーバ２でアプリケーションプログラムが実行されることで実現するアプリケーション機能２ａからデータへのアクセス状況を示す管理情報を取得し、システム管理テーブル１ｃに登録する。システム情報収集手段１ｂは、サーバ２のオペレーティングシステム２ｂが有する資源管理情報を取得し、システム管理テーブル１ｃに登録する。情報解析手段１ｄは、システム管理テーブル１ｃを参照し、アプリケーション機能のデータアクセス状況に応じた資源の管理状況の適否を判断する。

このようなシステム管理プログラムを実行するコンピュータによれば、アプリケーション情報収集手段１ａにより、アプリケーション機能２ａからデータへのアクセス状況を示す管理情報が取得され、システム管理テーブル１ｃに登録される。また、システム情報収集手段１ｂにより、サーバ２のオペレーティングシステム２ｂが有する資源管理情報が取得され、システム管理テーブル１ｃに登録される。そして、情報解析手段１ｄにより、システム管理テーブル１ｃが参照され、アプリケーション機能のデータアクセス状況に応じた資源の管理状況の適否が判断される。

本発明では、アプリケーション機能のデータアクセス状況を示す管理情報を用いて資源の管理状況の適否を判断するようにしたため、管理状況の適否について適切な判断を下すことができる。

以下、本発明の実施の形態を図面を参照して説明する。
図１は、本実施の形態の概略を示す図である。システム管理装置１は、ネットワークシステムを構成するサーバ２に接続されている。ネットワークシステムには、サーバ２の他、例えば、ストレージデバイス３が接続されている。

システム管理装置１は、システムの構成の最適化を支援するために、アプリケーション情報収集手段１ａ、システム情報収集手段１ｂ、システム管理テーブル１ｃ、および情報解析手段１ｄを有している。

アプリケーション情報収集手段１ａは、ネットワークシステムを構成するサーバ２でアプリケーションプログラムが実行されることで実現するアプリケーション機能２ａからデータへのアクセス状況を示す管理情報を取得し、システム管理テーブル１ｃに登録する。例えば、アプリケーション情報収集手段１ａは、アプリケーション機能２ａをデータのバックアップ機能を有してれば、バックアップのスケジュールおよびバックアップデータのリストア処理の履歴等の情報を収集する。

システム情報収集手段１ｂは、サーバ２のオペレーティングシステム２ｂが有する資源管理情報を取得し、システム管理テーブル１ｃに登録する。例えば、システム情報収集手段１ｂは、オペレーティングシステム２ｂが有するファイルシステムや、そのファイルシステムを介したデータアクセスの履歴等の情報を収集することができる。

システム管理テーブル１ｃには、アプリケーション情報収集手段１ａが収集した管理情報と、システム情報収集手段１ｂが収集した管理情報とが、例えば、データの識別情報やストレージデバイスの識別情報等によって関連づけて登録されている。

情報解析手段１ｄは、システム管理テーブル１ｃを参照し、アプリケーション機能２ａのデータアクセス状況に応じた資源の管理状況の適否を判断する。例えば、情報解析手段１ｄは、ファイルシステムで管理されているデータの内、バックアップスケジュールから漏れているデータを抽出することができる。また、情報解析手段１ｄは、バックアップスケジュールに含まれるデータの更新状況をオペレーティングシステムから取得した管理情報から判断し、バックアップ間隔等の妥当性を判断することもできる。

このようなシステム管理装置によれば、アプリケーション情報収集手段１ａにより、アプリケーション機能２ａからデータへのアクセス状況を示す管理情報が取得され、システム管理テーブル１ｃに登録される。また、システム情報収集手段１ｂにより、サーバ２のオペレーティングシステム２ｂが有する資源管理情報が取得され、システム管理テーブル１ｃに登録される。そして、情報解析手段１ｄにより、システム管理テーブル１ｃが参照され、アプリケーション機能のデータアクセス状況に応じた資源の管理状況の適否が判断される。

その結果、アプリケーション機能２ａやオペレーティングシステム２ｂによるシステムの管理状況の適否について適切な判断を下すことができる。例えば、バックアップスケジュールの妥当性や、データの格納先の妥当性（アプリケーションによるアクセス頻度が高いデータほど、高性能のストレージデバイスに格納されているか）等を適切に判断できる。

なお、情報解析手段１ｄによる解析結果は、ビジュアルなグラフによって出力することができる。これにより、システム管理者が傾向分析結果を容易に認識できる。
さらに、解析結果に基づいて、マイグレート、性能向上可能なデータ配置転換、バックアップスケジュールの変更等を自動で行うこともできる。そこで、図１に示した機能と自動マイグレート機能とを組み合わせたシステムを、実施の形態として詳細に説明する。

図２は、本発明の実施の形態に係るシステム構成例を示す図である。図２には、インターネット９０に接続された複数の端末装置２１，２２，・・・に対して各種サービスを提供するＷｅｂシステム２００の例が示されている。このＷｅｂシステム２００は、ネットワーク１０を介して接続された管理サーバ１００によって管理される。また、管理サーバ１００には、ネットワーク１０を介して、管理用端末装置２０が接続されている。

Ｗｅｂシステム２００には、ロードバランサ２１０、レベル２（Ｌ２）スイッチ２２０、複数のサーバ２３０，２３０ａ，２３０ｂ、ファイバーチャネル（ＦＣ）スイッチ２４０、および複数のストレージデバイス２５１〜２５６を含むストレージデバイス群２５０を有している。

ロードバランサ２１０は、インターネット９０に接続されており、端末装置２１，２２，・・・との間で通信を行う。また、ロードバランサ２１０は、運用中のサーバの処理負荷等を監視し、負荷が分散されるように端末装置２１，２２，・・・からの処理要求のサーバへの振り分けを行う。

Ｌ２スイッチ２２０は、ロードバランサ２１０とサーバ２３０，２３０ａ，２３０ｂとの間に設けられており、ロードバランサで振り分けられた処理要求を、対応するサーバに転送する。

サーバ２３０，２３０ａ，２３０ｂは、端末装置２１，２２，・・・からの処理要求に応じて処理を実行し、処理結果を応答する。なお、原則としてサーバ２３０，２３０ａ，２３０ｂのうちの少なくとも１つが予備としてサービスを提供しない状態に置かれ、他のサーバによって処理が実行される。サーバ２３０，２３０ａ，２３０ｂは、処理を実行する際には、必要に応じてストレージデバイス群２５０にアクセスする。

ＦＣスイッチ２４０は、サーバ２３０，２３０ａ，２３０ｂとストレージデバイス群２５０との間に設けられており、サーバ２３０，２３０ａ，２３０ｂからのアクセス要求に応じて、そのアクセス要求で指定されたストレージデバイスに転送する。

ストレージデバイス群２５０は、複数のストレージデバイス２５１〜２５６を管理している。これらのストレージデバイス２５１〜２５６のうち、少なくとも１つが予備としてプールされ、他のストレージデバイスがサーバで使用される。

管理サーバ１００は、ネットワーク１０を介して、Ｗｅｂシステム２００内の各装置に接続されており、各装置の運用状況を管理する。また、任意のサービスを提供するためのハードウェア資源が不足した場合、追加すべきハードウェア資源の種別（サーバまたはストレージデバイス）を判断する。そして、管理サーバ１００は、追加すべきと決定されたハードウェア資源がサービスの提供に利用されるように、Ｗｅｂシステム２００の運用形態を再構築する。

管理用端末装置２０は、システム管理者が使用する端末装置である。システムの使用状況に関する傾向分析結果等が管理サーバ１００から管理用端末装置２０に送られることで、システム管理者は、システム構成変更の要否を判断できる。

このようなシステムにより、サービス毎のサーバまたはストレージデバイスの追加が可能となる。すなわち、管理サーバ１００は、サービス毎に、一定期間のストレージデバイス使用量の増分を計測する。そして、管理サーバ１００は、使用量の増分をサービス毎の閾値と比較し、ストレージデバイスのみを増加させるか、サーバを追加するかを判断する。

サーバを追加する場合、管理サーバ１００は、追加するサーバにＯＳおよび各種ソフトウェアを含むイメージデータをコピーし、そのＯＳによってサーバを起動する。そして、起動したサーバにＩＰアドレス等を設定する。

また、管理サーバ１００は、現在使用しているストレージデバイスから必要なデータを切り出し、新しいストレージデバイスにコピーする。さらに、管理サーバ１００は、ロードバランサ２１０に対してサーバのサービスへの組み込み指示等を行う。

ストレージデバイスを追加する場合、管理サーバ１００は、追加するストレージデバイスに対して、該当するサービスからアクセスできるように、ＦＣスイッチ２４０等の設定を行う。

図３は、本実施の形態に用いるコンピュータのハードウェア構成例を示す図である。管理サーバ１００は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０７を介してＲＡＭ（Random Access Memory）１０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、および通信インタフェース１０６が接続されている。

ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳのプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３には、ＯＳやアプリケーションプログラムが格納される。

グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号を、バス１０７を介してＣＰＵ１０１に送信する。

通信インタフェース１０６は、ネットワーク１０に接続されている。通信インタフェース１０６は、ネットワーク１０を介して、他のコンピュータとの間でデータの送受信を行う。

以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図３には管理サーバのハードウェア構成を示したが、他のサーバ２３０，２３０ａ，２３０ｂや端末装置２１，２２，・・・も同様のハードウェア構成で実現することができる。

次に、管理サーバ１００とサーバ２３０，２３０ａ，２３０ｂとが有する機能について説明する。
図４は、管理サーバとサーバの処理機能を示すブロック図である。サーバ２３０は、ＯＳ２３１、エージェント２３２、および複数のアプリケーション２３３，２３３ａ，２３３ｂ，・・・等の各種アプリケーションを有している。

ＯＳ２３１は、サーバ２３０全体を管理している。また、ＯＳ２３１は、ストレージデバイス２５１，２５２にアクセスするためのファイルシステムや、デバイスドライバを有している。そして、ＯＳ２３１は、アプリケーション２３３，２３３ａ，２３３ｂ，・・・等の要求に応じてストレージデバイス２５１，２５２に対するアクセスを行う。

エージェント２３２は、管理サーバ１００からの要求に応じて、ＯＳ２３１が有している管理情報を管理サーバ１００に送信する。例えば、エージェント２３２は、ＯＳ２３１のファイルシステムからストレージデバイス２５１，２５２の空き容量等の情報を収集し、管理サーバ１００に対して送信する。

アプリケーション２３３，２３３ａ，２３３ｂ，・・・は、バックアップ処理等を行うための処理機能である。アプリケーション２３３，２３３ａ，２３３ｂ，・・・は、処理に必要なデータをストレージデバイス２５１，２５２から取得したり、処理結果のデータをストレージデバイス２５１，２５２に格納したりする。また、アプリケーション２３３，２３３ａ，２３３ｂ，・・・は、管理サーバ１００からの要求に応じて、ストレージデバイス２５１，２５２へのアクセス状況等に関する管理情報を管理サーバ１００に送信する。

管理サーバ１００は、アプリケーション情報収集部１１０、システム情報収集部１２０、ハードウェア情報収集部１３０、データ属性テーブル１４０、ストレージ属性テーブル１５０、情報解析部１６０、解析結果通知部１７０、自動マイグレート部１８０およびシステム管理機能制御部１９０を有する。

アプリケーション情報収集部１１０は、アプリケーション２３３，２３３ａ，２３３ｂ，・・・に対して、管理しているデータの属性（データ属性）を要求する。すなわち、管理情報の収集は、ポーリングによって、アプリケーション情報収集部１１０側で必要としたときに行うことができる。

その要求に応じてデータ属性を示す情報が送られると、アプリケーション情報収集部１１０は、取得したデータ属性をデータ属性テーブル１４０やストレージ属性テーブル１５０に格納する。例えば、アプリケーション情報収集部１１０は、アプリケーション２３３，２３３ａ，２３３ｂ，・・・が作成、更新、削除する資産（ファイル、データ、ＤＢスペースなどのアプリケーションが扱うデータ単位）に関する情報を収集する。

システム情報収集部１２０は、エージェント２３２に対して、ＯＳ２３１で管理しているデータの属性情報を要求する。すなわち、ＯＳ２３１が管理するデータの収集は、ポーリングによって、システム情報収集部１２０側で必要としたときに行うことができる。

その要求に応じてストレージ属性を示す情報が送られると、システム情報収集部１２０は、取得したストレージ属性をストレージ属性テーブル１５０に格納する。例えば、システム情報収集部１２０は、データの更新日、大きさ、所有者等のＯＳ２３１が管理する情報を収集することができる。

ハードウェア情報収集部１３０は、ストレージデバイス２５１，２５２，・・・にアクセスし、ストレージデバイス２５１，２５２，・・・の属性情報を取得する。すなわち、ストレージデバイス２５１，２５２，・・・からのデータの収集は、ポーリングによって、ハードウェア情報収集部１３０側で必要としたときに行うことができる。ハードウェア情報収集部１３０は、取得した属性情報をストレージ属性テーブル１５０に格納する。

なお、アプリケーション情報収集部１１０、システム情報収集部１２０、およびハードウェア情報収集部１３０による情報の収集は、予め設定された収集ポリシー定義に従ったタイミングで実行される。

情報解析部１６０は、データ属性テーブル１４０やストレージ属性テーブル１５０に登録された情報を参照し、資源の利用状況を解析する。例えば、情報解析部１６０は、所定日数以上未アクセスのデータの抽出、所定時間以上のＩ／Ｏレスポンスを要するデータの抽出、一月当たりのリカバリ回数が所定値以上のデータの抽出等を行う。

そして、情報解析部１６０は、資源の過不足や、アプリケーションへの資源の割り当て等の適否を判断する。その際、不足する資源があれば、情報解析部１６０は、資源が不足している旨の情報を解析結果通知部１７０に渡す。また、情報解析部１６０は、情報の解析の結果、システム構成の変更が必要となり、自動で変更可能な内容であれば、システム変更指示を自動マイグレート部１８０に渡す。

解析結果通知部１７０は、電子メール等の技術を使い、情報解析部１６０での解析結果を、システム管理者に通知する。
自動マイグレート部１８０は、情報解析部１６０からの指示に従って、システムの自動マイグレートを行う。例えば、自動マイグレート部１８０は、ストレージデバイスの追加指示を受け取ると、プールされていたストレージデバイスを運用状態とし、追加されたストレージデバイスを各サーバ２３０，２３０ａ，２３０ｂのファイルシステムからアクセスできるように設定する。

また、自動マイグレート部１８０は、所定日数以上未アクセスであり、且つ重要度がhigh以外のデータを、低速のハードディスク装置に移動させることもできる。これにより、高速且つ高価なストレージデバイスの機能を有効活用できる。

また、自動マイグレート部１８０は、Ｉ／Ｏレスポンスが所定時間以上のデータを、同等の他のストレージデバイスに移動させることもできる。これにより、複数のストレージへアクセスを分散させ、Ｉ／Ｏレスポンスを向上させることができる。

システム管理機能制御部１９０は、解析部による解析結果に応じて、サーバ２３０に実装されたアプリケーション２３３，２３３ａ，２３３ｂに対して動作指示を行う。例えば、システム管理機能制御部１９０は、一月当たりのリカバリ回数が所定回数以上のデータに関し、バックアップ頻度を高めるように、バックアップ用のアプリケーションの設定を変更させることもできる。これにより、システム障害時に消失するデータを減らすことができ、リカバリ作業の効率化が図れる。

図５は、データ属性テーブルのデータ構造例を示す図である。データ属性テーブル１４０には、データ識別子、データ属性、およびストレージ識別子の欄が設けられている。
データ識別子の欄には、ファイルシステムが管理しているデータ（例えば、ファイル）の識別子が設定される。データ属性の欄には、データの属性が設定されている。

データ属性の欄は、属性の種別毎に分けられている。図５の例では、更新日、大きさ、所有者、重要度、Ｉ／Ｏレスポンス、リカバリ頻度、およびバックアップ有無の欄が設けられている。更新日の欄には、データの内容が最後に更新された日付が設定される。大きさの欄には、データ容量が設定される。所有者の欄には、データの所有者のユーザ名が設定される。重要度の欄には、データの重要度（High：高、Middle：中、Low：低）が設定される。Ｉ／Ｏレスポンスの欄には、データに対するアクセスに要する時間（アクセス要求を出力してから応答が返されるまでの時間）が設定される。リカバリ頻度の欄には、所定期間内にバックアップデータのリカバリを実施した回数が設定される。また、リカバリ頻度の欄には、リカバリを実施したすべての日付が設定されている。バックアップ有無の欄には、バックアップの実施の有無が設定される。

ストレージ識別子の欄には、データが格納されているストレージデバイスの識別子が設定される。
データ属性テーブル１４０に設定されているデータ属性のうち、更新日、大きさ、所有者については、ＯＳ２３１内のファイルシステムから取得される情報である。また、重要度、Ｉ／Ｏレスポンス、リカバリ頻度、バックアップ有無のデータ属性は、アプリケーション２３３から取得される情報である。

また、Ｉ／Ｏレスポンスの欄の情報は、採取されたアクセス時間の情報に基づいて、その採取時刻毎に算出された統計データである。
図６は、ストレージ属性テーブルのデータ構造例を示す図である。ストレージ属性テーブル１５０には、ストレージ識別子とストレージ属性との欄が設けられている。

ストレージ識別子の欄には、ストレージデバイスの識別子が設定される。ストレージ属性の欄には、ストレージデバイスの属性が設定されている。
ストレージ属性の欄は、属性の種別毎に分けられている。図６の例では、価格、性能、使用量、未使用量、Ｉ／Ｏレスポンス、およびバックアップ有無の欄が設けられている。価格の欄には、ストレージデバイスの価格の相対的な評価（High：高額、Middle：標準、Low：低額）が設定される。性能の欄には、ストレージデバイスの性能の相対的な評価（High：高速、Middle：標準、Low：低速）が設定される。使用量の欄には、現在使用されているデータ記憶容量が設定される。未使用量の欄には、空き容量が設定される。Ｉ／Ｏレスポンスの欄には、ストレージデバイスに対するアクセスに要する時間が設定される。バックアップ有無の欄には、バックアップの実施の有無が設定される。

なお、Ｉ／Ｏレスポンスの欄の情報は、採取されたアクセス時間の情報に基づいて、その採取時刻毎に算出された統計データである。
以上のような構成のシステムにおいて、以下のような処理が行われる。

図７は、システム管理処理の手順を示すフローチャートである。以下、図７に示す処理をステップ番号に沿って説明する。
［ステップＳ１１］アプリケーション情報収集部１１０は、サーバ２３０のアプリケーション２３３，２３３ａ，２３３ｂからシステム管理に関する情報を収集する。アプリケーション情報収集部１１０は、収集した情報を、データ属性テーブル１４０やストレージ属性テーブル１５０に登録する。

［ステップＳ１２］システム情報収集部１２０は、サーバ２３０のエージェント２３２を介して、サーバ２３０内のＯＳ２３１で管理されているシステム情報を収集する。システム情報収集部１２０は、収集した情報を、データ属性テーブル１４０やストレージ属性テーブル１５０に登録する。

［ステップＳ１３］ハードウェア情報収集部１３０は、ストレージデバイス２５１，２５２にアクセスし、ストレージデバイス２５１，２５２が有する管理情報を収集する。ハードウェア情報収集部１３０は、収集した情報を、データ属性テーブル１４０やストレージ属性テーブル１５０に登録する。

このように、情報が収集されることにより、ステップＳ１１−Ｓ１３で収集した情報が互いに関連づけられる。具体的には、リソース（ストレージデバイス等）の属性（価格、性能、使用量等）、そのリソースに含まれるデータの属性（更新日、大きさ等）、およびポリシー（バックアップ処理の要否等）が関連づけられる。

［ステップＳ１４］情報解析部１６０は、データ属性テーブル１４０とストレージ属性テーブル１５０に登録された情報を解析し、各種情報の値の推移に関する傾向分析を行う。例えば、ストレージデバイス２５１，２５２の平均アクセス時間の推移などが求められる。

［ステップＳ１５］解析結果通知部１７０は、傾向分析結果をモニタ１１に表示する。例えば、解析結果通知部１７０は、平均アクセス時間の時間帯毎の推移を示すグラフを画面に表示する。

［ステップＳ１６］自動マイグレート部１８０は、傾向分析結果に応じて、自動マイグレートを行う。具体的には、自動マイグレート部１８０は、傾向分析結果に基づいて、不足資源、または余剰資源を判断し、適切なシステム構成となるようなシステム変更案をモニタ１１に表示する。そして、自動マイグレート部１８０は、システム変更案を承認する操作入力がユーザによって行われると、そのシステム変更案に沿ったマイグレート処理を実行する。

［ステップＳ１７］システム管理機能制御部１９０は、傾向分析結果に応じて、システム設定の最適化を行う。具体的には、システム管理機能制御部１９０は、サーバ２３０のアプリケーション２３３，２３３ａ，２３３ｂやエージェント２３２に対して、システム設定の更新要求を出力する。アプリケーション２３３，２３３ａ，２３３ｂやエージェント２３２は、更新要求に応じて各種処理の設定値を更新する。例えば、バックアップ処理を行うアプリケーションであれば、バックアップスケジュールやバックアップ対象となるストレージデバイスの追加／削除等が行われる。

次に、図７に示す処理を詳細に説明する。
図８は、情報収集処理を示す図である。まず、アプリケーション情報収集部１１０が、システム上のアプリケーションを検索する。そして、アプリケーション情報収集部１１０は、検出されたアプリケーション２３３，２３３ａ，２３３ｂに対して、管理情報を要求する（ステップＳ２１）。すると、アプリケーション２３３，２３３ａ，２３３ｂは、管理している情報をアプリケーション情報収集部１１０に対して送信する（ステップＳ２２）。バックアップのアプリケーションであれば、データ毎、またはストレージデバイス毎のリカバリ頻度やバックアップ処理の要否等の情報が送信される。アプリケーション情報収集部１１０は、アプリケーション２３３，２３３ａ，２３３ｂから送られた管理情報を、データ属性テーブル１４０やストレージ属性テーブル１５０に格納する（ステップＳ２３）。

また、システム情報収集部１２０が、サーバ群を検索し、検出したサーバ２３０内のエージェント２３２に対して、管理情報を要求する（ステップＳ２４）。すると、エージェント２３２は、ＯＳ２３１内のファイルシステムやデバイスドライバの保持する管理情報にアクセスする（ステップＳ２５）。そして、エージェント２３２は、ファイルシステムやデバイスドライバが有するシステムの管理情報を取得する（ステップＳ２６）。例えば、データの更新日、大きさ、所有者等の情報が取得される。さらに、エージェント２３２は、取得した管理情報を管理サーバ１００のシステム情報収集部１２０に対して送信する（ステップＳ２７）。システム情報収集部１２０は、受け取った管理情報を、データ属性テーブル１４０やストレージ属性テーブル１５０に格納する（ステップＳ２８）。

さらに、ハードウェア情報収集部１３０が、ストレージデバイス２５１，２５２内の管理情報にアクセスする（ステップＳ２９）。そして、ハードウェア情報収集部１３０は、ストレージデバイス２５１，２５２の管理情報を取得する（ステップＳ３０）。例えば、Ｉ／Ｏレスポンス、ストレージデバイスの使用量、未使用量（空き容量）等の情報が取得される。ハードウェア情報収集部１３０は、取得した管理情報を、データ属性テーブル１４０やストレージ属性テーブル１５０に格納する（ステップＳ３１）。

図９は、アプリケーションから収集される管理情報の例を示す図である。図９には、データ管理情報３１ａ，３１ｂ，３１ｃ，３１ｄ，３２ａ，３２ｂ，３２ｃ，３２ｄと、ディレクトリ管理情報３３，３４が示されている。

データ管理情報３１ａ，３１ｂ，３１ｃ，３１ｄは、ファイルシステムの絶対パスが「/home/aplA/」であるディレクトリ内の複数のデータそれぞれに関する管理情報である。データ管理情報３２ａ，３２ｂ，３２ｃ，３２ｄは、ファイルシステムの絶対パスが「/work/aplA/」であるディレクトリ内の複数のデータそれぞれに関する管理情報である。データ管理情報３１ａ，３１ｂ，３１ｃ，３１ｄ，３２ａ，３２ｂ，３２ｃ，３２ｄには、パス名（ディレクトリのパスにファイル名を追加したもの）、オーナ（データの作成者）、作成日、および更新日が含まれている。

ディレクトリ管理情報３３は、絶対パスが「/home/aplA/」であるディレクトリに関する管理情報である。ディレクトリ管理情報３４は、絶対パスが「/work/aplA/」であるディレクトリに関する管理情報である。ディレクトリ管理情報３３，３４には、パス名、重要度、Ｉ／Ｏレスポンス保証値、および自動化フラグの情報が含まれている。

ここで、重要度は、ディレクトリに格納されるデータを消失したときに業務に与える影響の度合いを示している。この例では、重要度が、high（高）、low（低）で示されている。Ｉ／Ｏレスポンス保証値は、ディレクトリ内のデータに対するアクセスにおいて、保証すべきＩ／Ｏレスポンス（アクセスから応答までの時間）が設定される。なお、Ｉ／Ｏレスポンスの保証をおこなわない場合、Ｉ／Ｏレスポンス保証値として、設定可能な最大値（図９の例では「９９９９秒」）が設定される。

自動化フラグは、自動的にシステムの自動マイグレートを行うか否かを示すフラグである。自動設定を行う場合、自動化フラグが「ＯＮ」に設定される。自動設定を行わない場合、自動化フラグが「ＯＦＦ」に設定される。

図１０は、エージェントから収集される管理情報の例を示す図である。図１０には、ファイルシステム毎のファイルシステム管理情報４１，４２と、ファイルシステム管理ポリシー情報４３，４４とが示されている。

ファイルシステム管理情報４１，４２は、ファイルシステムに割り当てられた資源の情報が示されている。具体的には、ファイルシステム管理情報４１，４２には、ファイルシステム名、割り当て量、使用量、作成日、および更新日が含まれている。

ファイルシステム管理ポリシー情報４３，４４には、ファイルシステムを管理するための指針となる情報が示されている。具体的には、ファイルシステム管理ポリシー情報４３，４４には、ファイルシステム名、重要度、Ｉ／Ｏレスポンス保証値、使用量監視閾値、自動化フラグ、閾値超え通知フラグ、拡張フラグ、およびマイグレートフラグ等が設定されている。ここで、重要度は、ファイルシステムで管理されるデータを消失したときに業務に与える影響の度合いを示している。この例では、重要度が、high（高）、low（低）で示されている。Ｉ／Ｏレスポンス保証値は、ファイルシステムで管理されるデータに対するアクセスにおいて、保証すべきＩ／Ｏレスポンス（アクセスから応答までの時間）が設定される。なお、Ｉ／Ｏレスポンスの保証をおこなわない場合、Ｉ／Ｏレスポンス保証値として、設定可能な最大値（図１０の例では「９９９９秒」）が設定される。

使用量監視閾値には、ファイルシステムの空き容量不足と判断するための閾値が設定される。この閾値は、割り当て量に対する使用量の割合（パーセンテージで示される）によって表される。閾値を超えて使用されていると、空き容量不足と判断される。

自動化フラグは、自動的にシステムの自動マイグレートを行うか否かを示すフラグである。自動設定を行う場合、自動化フラグが「ＯＮ」に設定される。自動設定を行わない場合、自動化フラグが「ＯＦＦ」に設定される。

閾値超え通知フラグは、ファイルシステムの使用量が閾値を超えたときに、管理者の端末にその旨を通知するか否かを示すフラグである。通知する場合、閾値超え通知フラグが「ＯＮ」に設定される。通知しない場合、閾値超え通知フラグが「ＯＦＦ」に設定される。なお閾値超え通知フラグが「ＯＮ」の場合、通知先の電子メールアドレス等の情報が詳細設定として登録される。

拡張フラグは、容量の拡張を行うか否かを示すフラグである。容量の拡張を行う場合、拡張フラグが「ＯＮ」に設定される。容量の拡張をおこなわない場合、拡張フラグが「ＯＦＦ」に設定される。

マイグレートフラグは、システムマイグレートの対象とするか否かを示すフラグである。システムマイグレートの対象とするファイルシステムであれば、マイグレートフラグが「ＯＮ」に設定される。システムマイグレートの対象としないファイルシステムであれば、マイグレートフラグが「ＯＦＦ」に設定される。なお、マイグレートフラグが「ＯＮ」の場合、マイグレートに必要な情報（例えば、データの移行先のストレージデバイスに要求される性能）等が詳細情報として登録される。

図１１は、ストレージデバイスから収集される管理情報の例を示す図である。図１１には、ストレージデバイス管理情報５１，５２と、ストレージデバイス管理ポリシー情報５３，５４とが示されている。

ストレージデバイス管理情報５１，５２には、ストレージデバイスに割り当てられた資源の情報が示されている。具体的には、ストレージデバイス管理情報５１，５２には、プール名（本実施の形態では、マイグレートの管理対象となるストレージデバイスをプールと称している）、割り当て量、使用量、未割り当て量、作成日、および更新日が含まれている。

ストレージデバイス管理ポリシー情報５３，５４には、ストレージデバイスを管理するための指針となる情報が示されている。具体的には、ストレージデバイス管理ポリシー情報５３，５４には、プール名、重要度、Ｉ／Ｏレスポンス保証値、および自動化フラグが設定されている。ここで、重要度は、ストレージデバイスに格納されるデータを消失したときに業務に与える影響の度合いを示している。この例では、重要度が、high（高）、low（低）で示されている。Ｉ／Ｏレスポンス保証値は、ストレージデバイスに格納されるデータに対するアクセスにおいて、保証すべきＩ／Ｏレスポンスが設定される。なお、Ｉ／Ｏレスポンスの保証をおこなわない場合、Ｉ／Ｏレスポンス保証値として、設定可能な最大値（図１１の例では「９９９９秒」）が設定される。

自動化フラグは、自動的にシステムの自動マイグレートを行うか否かを示すフラグである。自動設定を行う場合、自動化フラグが「ＯＮ」に設定される。自動設定を行わない場合、自動化フラグが「ＯＦＦ」に設定される。

図９〜図１１に示した情報に基づいて、情報解析部１６０により傾向分析が行われる。そして、傾向分析の結果がモニタ１１に表示されるとともに、システム管理者宛に電子メール等で送信される。以下、図１２〜図１５を参照して、傾向分析結果の例を示す。

図１２は、サーバで管理するデータ量の推移を示す図である。図１２では、横軸に日付、縦軸にサーバにおけるデータの使用割合（使用量を割り当て量で除算し、その値を百分率で示したもの）が示されている。なお、サーバの使用量と割り当て量は、そのサーバのファイルシステムに設定されている使用量と割り当て量とのそれぞれの合算値である。

図１３は、アプリケーションで使用するデータ量の推移を示す図である。図１３では、横軸に日付、縦軸にアプリケーションにおけるデータの使用割合が示されている。
図１４は、ファイルシステムで管理するデータ量の推移を示す第１の図である。図１４では、横軸に日付、縦軸にパスが「/home/aplA」であるファイルシステムにおけるデータの使用割合が示されている。

図１５は、ファイルシステムで管理するデータ量の推移を示す第２の図である。図１５では、横軸に日付、縦軸にパスが「/work/aplA」であるファイルシステムにおけるデータの使用割合が示されている。

以上のような情報収集および傾向分析は、予め設定されたスキャンスケジュールに従って実行される。また、収集した管理情報に基づいて、使用量監視閾値を超えたかどうかの判断が、アクションスケジュールに従って実行される。そして、解析結果通知部１７０は、解析結果により、いずれかのファイルシステムに関して、使用量監視閾値を超えた場合、管理用端末装置２０に対して閾値超え通知を送信する。

図１６は、閾値越え通知状況を示す図である。解析結果通知部１７０は、例えば、電子メールを用いて閾値越え通知６０を管理用端末装置２０に送信する。
その後、マイグレートが必要であれば、自動マイグレート部１８０によってシステムのマイグレートが行われる。例えば、使用量が使用量監視閾値を超えたストレージデバイス内のデータの一部を、他のストレージデバイスに移動させる。

図１７は、マイグレートの状況を示す図である。図１７の例では、自動マイグレート部１８０からの指示により、エージェント２３２がストレージデバイス２５２内のデータを別のストレージデバイス２５３に移動させている。同様に、自動マイグレート部１８０からの指示により、アプリケーション２３３がストレージデバイス２５２内のデータを別のストレージデバイス２５３に移動させている。

例えば、自動マイグレート部１８０は、「/work/AplA」内の３００日間未アクセスのデータを、「/tmp」というディレクトリに移動させる。「/tmp」のディレクトリは、「/work/AplA」のディレクトリが設けられたストレージデバイスよりも安価でアクセス速度の遅いストレージデバイスに設けられている。その結果、システム内の資源の使用効率を向上させることができる。ただし、この場合、図５のデータの重要度、図６のストレージの性能、図９のディレクトリ管理情報の重要度とＩ／Ｏレスポンス保証が同じである必要がある。

以下にその他の自動マイグレートの例を示す。
図１８は、長期間未使用データの傾向分析結果を示す図である。情報解析部１６０は、データ属性テーブル１４０を参照し、例えば、１年以上未アクセスのデータを検索する。さらに、情報解析部１６０は、ストレージ属性テーブル１５０を参照し、１年以上未アクセスのデータが格納されているストレージデバイスを判断する。そして、情報解析部１６０が取得したデータから傾向分析を行い、解析結果通知部１７０が分析結果を管理用端末装置２０に送信する。

解析結果は、例えば、データリスト７１、サーバ別分布表７２、ストレージデバイス別分布表７３の形式で通知される。データリスト７１は、１年以上未アクセスのデータが登録されたリストである。

サーバ別分布表７２は、１年以上未アクセスのデータのサーバ間の分布を示す円グラフである。なお、各ストレージデバイスがどのサーバからアクセスできるのかは、図示していないシステム構成情報によって判断できる。

ストレージデバイス別分布表７３は、１年以上未アクセスのデータのストレージデバイス間の分布を示す円グラフである。
このような傾向分析結果から、例えば、「pool1」のストレージデバイス内に長期間未アクセスのデータが偏って存在していることが分かる。そこで、自動マイグレート部１８０は、アプリケーション２３３，２３３ａ，２３３ｂやエージェント２３２を介して、「pool1」のストレージデバイス内の長期間未アクセスのデータを他のストレージデバイスに移動させる。これにより、ストレージデバイス間のデータアクセス頻度の均等化が可能となる。

図１９は、過去から未来へのデータ格納量の傾向分析結果を示す図である。情報解析部１６０がデータ属性テーブル１４０とストレージ属性テーブル１５０を参照し、サーバ毎およびストレージデバイス毎のデータ格納領域使用割合を判断する。情報解析部１６０は、このような使用割合の判断を、定期的に継続して行う。そして、情報解析部１６０は、過去からの使用割合の推移を解析すると共に、未来の使用割合の推移を予想する。解析結果通知部１７０は、過去から未来までのサーバおよびストレージデバイスのデータ格納領域使用割合の推移の解析結果を、管理用端末装置２０に送信する。

図１９の例では、サーバＡの格納領域使用割合推移表８１と、「pool1」の格納領域使用割合推移表８２とが解析結果として送信されている（２００５年１０月０１日時点のデータとする）。この解析結果によれば、サーバＡの使用割合はあまり変化していないが、高額なストレージデバイスである「pool1」の使用割合は増加傾向にあることが分かる。

図２０は、Ｉ／Ｏレスポンスとデータ記憶領域使用割合の傾向分析結果を示す図である。情報解析部１６０がデータ属性テーブル１４０とストレージ属性テーブル１５０を参照し、アプリケーション毎のＩ／Ｏレスポンスとストレージデバイス毎のデータ格納領域使用割合を判断する。情報解析部１６０は、このような処理を、定期的に継続して行う。そして、情報解析部１６０は、過去からのアプリケーションのＩ／Ｏレスポンスの推移を解析すると共に、未来の使用割合の推移を予想する。また、情報解析部１６０は、過去からのストレージデバイスのデータ記憶領域使用割合の推移を解析すると共に、未来の使用割合の推移を予想する。解析結果通知部１７０は、アプリケーションのＩ／Ｏレスポンスの推移と、ストレージデバイスのデータ格納領域使用割合の推移との解析結果を、管理用端末装置２０に送信する。

図２０の例では、アプリケーションＡのＩ／Ｏレスポンス推移表９１と、「pool1」の格納領域使用割合推移表９２とが解析結果として送信されている（２００５年１０月０１日時点のデータとする）。この解析結果によれば、アプリケーションＡのＩ／Ｏレスポンスが悪化しているとともに、ストレージデバイス「pool1」の使用割合が増加傾向にあることが分かる。すなわち、ストレージデバイスの空き容量の減少が、アプリケーションＡのＩ／Ｏレスポンスの悪化を招いていると推定できる。この場合、解析結果通知部１７０は、システムの管理者に対して、「pool1」のスリム化（データの他のストレージデバイスへの移動）を提案するメッセージを送信する。

図２１は、ビジー率とＩ／Ｏレスポンスとの傾向分析結果を示す図である。情報解析部１６０がデータ属性テーブル１４０とストレージ属性テーブル１５０を参照し、アプリケーション毎のＩ／Ｏレスポンスとストレージデバイス毎のビジー率とを判断する。なお、ストレージデバイスのビジー率は、ハードウェア情報収集部１３０によって予め各ストレージデバイスから収集され、図６に示すストレージ属性テーブル１５０に追加登録されているものとする。

情報解析部１６０は、このような処理を、定期的に継続して行う。そして、情報解析部１６０は、過去からのアプリケーションのＩ／Ｏレスポンスの推移を解析すると共に、未来の使用割合の推移を予想する。また、情報解析部１６０は、過去からのストレージデバイスのビジー率の推移を解析すると共に、未来のビジー率の推移を予想する。解析結果通知部１７０は、アプリケーションのＩ／Ｏレスポンスの推移と、ストレージデバイスのビジー率の推移との解析結果を、管理用端末装置２０に送信する。

図２１の例では、アプリケーションＡのＩ／Ｏレスポンス推移表３０１と、「pool1」，「pool2」のビジー率推移表３０２とが解析結果として送信されている（２００５年１０月０１日時点のデータとする）。この解析結果によれば、アプリケーションＡのＩ／Ｏレスポンスが悪化しているとともに、ストレージデバイス「pool1」のビジー率が増加傾向にあることが分かる。すなわち、ストレージデバイスに対するアクセスの集中が、アプリケーションＡのＩ／Ｏレスポンスの悪化を招いていると推定できる。この場合、解析結果通知部１７０は、システムの管理者に対して、「pool1」のデータを「pool2」へ移動させることを提案するメッセージを送信する。このようなデータの移動により、Ｉ／Ｏレスポンスが向上する。

なお、システム管理者への解析結果通知を行わずに、自動マイグレート部１８０が自動でデータの移動を行うこともできる。例えば、ストレージデバイスのビジー率が所定値（例えば、３０％）に近づくと、所定値を超えないように自動マイグレート部１８０が、ビジー率が高いストレージデバイスから低いストレージデバイスへデータを移動する。

図２２は、リカバリ頻度の傾向分析に基づくバックアップスケジュールの妥当性分析結果を示す図である。情報解析部１６０がデータ属性テーブル１４０とストレージ属性テーブル１５０を参照しデータ毎のリカバリ頻度、バックアップ有無、およびバックアップ時刻を判断する。なお、データのバックアップ時刻は、アプリケーション情報収集部１１０によって予めバックアップ用のアプリケーションから収集され、図５に示すデータ属性テーブル１４０に追加登録されているものとする。

情報解析部１６０は、このような処理を、定期的に継続して行う。そして、情報解析部１６０は、データあるいはストレージデバイスに対するリカバリ操作（バックアップデータを元のストレージデバイスに戻す操作）が作業割合を解析すると共に、バックアップスケジュールの妥当性を解析する。解析結果通知部１７０は、リカバリ操作割合とバックアップスケジュールの妥当性との解析結果を、管理用端末装置２０に送信する。

図２２の例では、リカバリ割合表３１１と、バックアップスケジュール解析表３１２とが解析結果として送信されている。なお、バックアップスケジュールの妥当性は、リカバリに使用したバックアップデータのバックアップ時刻と、リカバリに使用可能な最新のバックアップデータのバックアップ時刻との比較によって行われる。

リカバリに使用したバックアップデータが、使用可能な最新のバックアップデータよりも過去のものであれば、バックアップスケジュールは妥当と判断される。一方、リカバリに使用したバックアップデータが使用可能な最新のバックアップデータであれば、そのバックアップデータのバックアップ時刻からリカバリ時刻までの間、データのロス（復旧させるべきデータの消失）が存在したものと判断される。

また、情報解析部１６０は、リカバリ頻度の傾向分析に基づくバックアップスケジュールの妥当性分析結果として、所定期間内にリカバリが行われていないバックアップスケジュールをリストアップすることもできる。

図２３は、未リカバリバックアップスケジュールの解析結果を示す図である。情報解析部１６０は、リカバリ操作回数が「０」のデータをデータ属性テーブル１４０やストレージ属性テーブル１５０から検索し、未リカバリバックアップスケジュールリスト３１３を生成する。未リカバリバックアップスケジュールリスト３１３は、解析結果通知部１７０によって管理用端末装置２０に送信される。

未リカバリバックアップスケジュールリスト３１３には、所定期間内のリカバリ操作回数が「０」であるデータがリストアップされている。この例では、該当データのバックアップデータ量やバックアップスケジュールが合わせて示されている。

システムの管理者は、この未リカバリバックアップスケジュールリスト３１３を参照して、不要なバックアップ処理を停止することができる。
また、情報解析部１６０は、バックアップスケジュールの設定漏れを検出することもできる。

図２４は、バックアップスケジュールの設定漏れの解析結果を示す図である。情報解析部１６０は、バックアップの設定が「無」のデータをデータ属性テーブル１４０やストレージ属性テーブル１５０から検索すると共に、該当するデータの所定期間内での更新の有無を検索する。そして、情報解析部１６０は、無バックアップデータ表３２１と無バックアップデータ更新有無割合表３２２とを作成する。無バックアップデータ表３２１と無バックアップデータ更新有無割合表３２２とは、解析結果通知部１７０によって管理用端末装置２０に送信される。

無バックアップデータ表３２１には、バックアップの設定が「無」のデータがリストアップされている。各データには、格納されているストレージデバイスの名称（pool番号）と、推奨バックアップスケジュールが設定される。

推奨バックアップスケジュールは、データの更新頻度や重要度に応じて決定される。例えば、データの重要度が高いほど、バックアップ間隔が短く設定される。また、データの更新間隔が短いほど、バックアップ間隔が短く設定される。

無バックアップデータ更新有無割合表３２２には、無バックアップのデータのうち、所定期間内に更新されたデータと未更新のデータとの割合が、円グラフで示される。なお、無バックアップデータ更新有無割合表３２２は、ストレージデバイス毎に生成することもできる。

このように、アプリケーションが有する管理情報、ＯＳが有する管理情報、およびストレージデバイスが有する管理情報を組み合わせて、システムの運用計画を計算するようにしたため、システムを効率的に運用することが可能となる。

例えば、アプリケーションから各データのアクセス頻度に関する情報を取得し、アクセス頻度が低いデータを低速且つ安価なストレージデバイスに移動することで、ストレージデバイスの投資対効果を向上させることができる。

また、アプリケーション等からディスクのＩ／Ｏレスポンスに関する管理情報を取得することで、Ｉ／Ｏレスポンスの悪化を容易に見つけ出すことができる。Ｉ／Ｏレスポンスが悪化した場合、該当ストレージデバイス内のデータの一部を他のストレージデバイスに移動させることができる。

また、バックアップ管理において、データの更新状態を加味してバックアップスケジュールの妥当性を判断できることにより、障害発生時の対応の手間を最小限に抑えることができる。

また、ＯＳが管理するデータのうち、バックアップのスケジュールから漏れているデータが検出できるようになり、重要なデータのバックアップ漏れを防ぐことができる。
さらに、管理情報の収集は、必要なとき（例えば、システム構成が変更されたとき等）にポーリングによって行われる。そのため、管理情報収集によるシステムに対する負荷を低く抑えることができる。その結果、大規模はシステムであっても、各アプリケーションからのアクセス状況等を監視することが可能となる。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、管理サーバが有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。

なお、本発明は、上述の実施の形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変更を加えることができる。
以上説明した実施の形態の主な技術的特徴は、以下の付記の通りである。

（付記１） システムの構成の最適化を支援するシステム管理プログラムにおいて、
コンピュータを、
ネットワークシステムを構成するサーバでアプリケーションプログラムが実行されることで実現するアプリケーション機能からデータへのアクセス状況を示す管理情報を取得し、システム管理テーブルに登録するアプリケーション情報収集手段、
前記サーバのオペレーティングシステムが有する資源管理情報を取得し、前記システム管理テーブルに登録するシステム情報収集手段、
前記システム管理テーブルを参照し、前記アプリケーション機能のデータアクセス状況に応じた資源の管理状況の適否を判断する情報解析手段、
として機能させることを特徴とするシステム管理プログラム。

（付記２） 前記コンピュータを、さらに、
前記情報解析手段による解析結果をシステム管理者の使用する端末装置に通知する解析結果通知手段として機能させることを特徴とする付記１記載のシステム管理プログラム。

（付記３） 前記コンピュータを、さらに、
前記情報解析手段による解析結果に基づいて最適なシステム構成を判断し、判断結果に従ってシステムの構成を変更する自動マイグレート手段、
として機能させることを特徴とする付記１記載のシステム管理プログラム。

（付記４） 前記アプリケーション情報収集手段は、前記アプリケーション機能からデータのバックアップおよびリカバリ状況を示す管理情報を収集し、
前記システム情報収集手段は、前記オペレーティングシステムから、ファイルシステムに管理されているデータの管理情報を収集し、
前記情報解析手段は、前記アプリケーション機能によるバックアップスケジュールの良否を判定することを特徴とする付記１記載のシステム管理プログラム。

（付記５） 前記情報解析手段は、リカバリに使用したバックアップデータのバックアップ時刻と、リカバリに使用可能な最新のバックアップデータのバックアップ時刻とを比較することにより、バックアップスケジュールの妥当性を判断することを特徴とする付記４記載のシステム管理プログラム。

（付記６） 前記情報解析手段は、リカバリに使用したバックアップデータのバックアップ時刻が、リカバリに使用可能な最新のバックアップデータのバックアップ時刻より前であれば、バックアップスケジュールが妥当であると判断することを特徴とする付記５記載のシステム管理プログラム。

（付記７） 前記情報解析手段は、リカバリに使用したバックアップデータのバックアップ時刻が、リカバリに使用可能な最新のバックアップデータのバックアップ時刻と同日の場合、バックアップスケジュールが不適切であると判断することを特徴とする付記５記載のシステム管理プログラム。

（付記８） 前記情報解析手段は、バックアップ処理が行われていながら所定期間リカバリが行われないデータをリストアップすることを特徴とする付記４記載のシステム管理プログラム。

（付記９） 前記情報解析手段は、前記オペレーティングシステムにおいて管理されているデータのうち、バックアップ処理を行う前記アプリケーション機能において前記バックアップスケジュールから漏れているデータをリストアップすることを特徴とする付記４記載のシステム管理プログラム。

（付記１０） コンピュータの演算処理により、システムの構成の最適化を支援するシステム管理方法において、
ネットワークシステムを構成するサーバでアプリケーションプログラムが実行されることで実現するアプリケーション機能からデータへのアクセス状況を示す管理情報を取得し、システム管理テーブルに登録し、
前記サーバのオペレーティングシステムが有する資源管理情報を取得し、前記システム管理テーブルに登録し、
前記システム管理テーブルを参照し、前記アプリケーション機能のデータアクセス状況に応じた資源の管理状況の適否を判断する、
ことを特徴とするシステム管理方法。

（付記１１） システムの構成の最適化を支援するシステム管理装置において、
ネットワークシステムを構成するサーバでアプリケーションプログラムが実行されることで実現するアプリケーション機能からデータへのアクセス状況を示す管理情報を取得し、システム管理テーブルに登録するアプリケーション情報収集手段と、
前記サーバのオペレーティングシステムが有する資源管理情報を取得し、前記システム管理テーブルに登録するシステム情報収集手段と、
前記システム管理テーブルを参照し、前記アプリケーション機能のデータアクセス状況に応じた資源の管理状況の適否を判断する情報解析手段と、
として機能させることを特徴とするシステム管理装置。

本実施の形態の概略を示す図である。 本発明の実施の形態に係るシステム構成例を示す図である。 本実施の形態に用いるコンピュータのハードウェア構成例を示す図である。 管理サーバとサーバの処理機能を示すブロック図である。 データ属性テーブルのデータ構造例を示す図である。 ストレージ属性テーブルのデータ構造例を示す図である。 システム管理処理の手順を示すフローチャートである。 情報収集処理を示す図である。 アプリケーションから収集される管理情報の例を示す図である。 エージェントから収集される管理情報の例を示す図である。 ストレージデバイスから収集される管理情報の例を示す図である。 サーバで管理するデータ量の推移を示す図である。 アプリケーションで使用するデータ量の推移を示す図である。 ファイルシステムで管理するデータ量の推移を示す第１の図である。 ファイルシステムで管理するデータ量の推移を示す第２の図である。 閾値越え通知状況を示す図である。 マイグレートの状況を示す図である。 長期間未使用データの傾向分析結果を示す図である。 過去から未来へのデータ格納量の傾向分析結果を示す図である。 Ｉ／Ｏレスポンスとデータ記憶領域使用割合の傾向分析結果を示す図である。 ビジー率とＩ／Ｏレスポンスとの傾向分析結果を示す図である。 リカバリ頻度の傾向分析に基づくバックアップスケジュールの妥当性分析結果を示す図である。 未リカバリバックアップスケジュールの解析結果を示す図である。 バックアップスケジュールの設定漏れの解析結果を示す図である。

符号の説明

１ システム管理装置
１ａ アプリケーション情報収集手段
１ｂ システム情報収集手段
１ｃ システム管理テーブル
１ｄ 情報解析手段
２ サーバ
２ａ アプリケーション機能
２ｂ オペレーティングシステム
３ ストレージデバイス

Claims (5)

1. システムの構成の最適化を支援するシステム管理プログラムにおいて、
   コンピュータを、
   ネットワークシステムを構成するサーバでアプリケーションプログラムが実行されることで実現するアプリケーション機能からデータへのアクセス状況を示す管理情報を取得し、システム管理テーブルに登録するアプリケーション情報収集手段、
   前記サーバのオペレーティングシステムが有する資源管理情報を取得し、前記システム管理テーブルに登録するシステム情報収集手段、
   前記システム管理テーブルを参照し、前記アプリケーション機能のデータアクセス状況に応じた資源の管理状況の適否を判断する情報解析手段、
   として機能させることを特徴とするシステム管理プログラム。
2. 前記アプリケーション情報収集手段は、前記アプリケーション機能からデータのバックアップおよびリカバリ状況を示す管理情報を収集し、
   前記システム情報収集手段は、前記オペレーティングシステムから、ファイルシステムに管理されているデータの管理情報を収集し、
   前記情報解析手段は、前記アプリケーション機能によるバックアップスケジュールの良否を判定することを特徴とする請求項１記載のシステム管理プログラム。
3. 前記情報解析手段は、リカバリに使用したバックアップデータのバックアップ時刻と、リカバリに使用可能な最新のバックアップデータのバックアップ時刻とを比較することにより、バックアップスケジュールの妥当性を判断することを特徴とする請求項２記載のシステム管理プログラム。
4. 前記情報解析手段は、前記オペレーティングシステムにおいて管理されているデータのうち、バックアップ処理を行う前記アプリケーション機能において前記バックアップスケジュールから漏れているデータをリストアップすることを特徴とする請求項２記載のシステム管理プログラム。
5. コンピュータの演算処理により、システムの構成の最適化を支援するシステム管理方法において、
   ネットワークシステムを構成するサーバでアプリケーションプログラムが実行されることで実現するアプリケーション機能からデータへのアクセス状況を示す管理情報を取得し、システム管理テーブルに登録し、
   前記サーバのオペレーティングシステムが有する資源管理情報を取得し、前記システム管理テーブルに登録し、
   前記システム管理テーブルを参照し、前記アプリケーション機能のデータアクセス状況に応じた資源の管理状況の適否を判断する、
   ことを特徴とするシステム管理方法。

Images