JP2012181744A - 分散ファイルシステムにおける運用監視システム及び運用監視方法 - Google Patents

Abstract

【課題】複数のサーバで構成された分散ファイルシステムにおいて、ファイルアクセス（書き込み、読み込み、更新等）の実施に関する各サーバの通信ログを収集することで、システム全体の監視を行う。
【解決手段】データの格納を行う１つまたは複数のファイルサーバ２と、ユーザ端末６からのアクセス要求の受付とデータの格納先の管理を行う少なくとも１つのプロキシサーバ１とを備え、ファイルサーバ２とプロキシサーバ１、プロキシサーバ２とユーザ端末６とがそれぞれネットワークを介して接続された分散ファイルシステム１０において、ファイルサーバ２及びプロキシサーバ１上で取得した通信ログを検出するログ収集部２１と、各通信ログを比較することで分散ファイルシステム１０におけるボトルネック箇所を特定するための分析を行うボトルネック分析部２３を備える。
【選択図】図１

Description

本発明は、複数のユーザによるファイル書込み要求及びファイル読込み要求が行われるネットワークにおいて、記憶部（ストレージ）を有する複数のファイルサーバを広域な範囲に分散配置させて形成される分散ファイルシステムの監視に関し、特に、分散ファイルシステムの各サーバ上で観測した情報を比較して各サーバの状態を定期的に収集し、これらの情報を統合的に分析することで伝送遅延やパケットロス等が発生するボトルネック箇所を特定可能とする運用監視システム及び運用監視方法に関する。

この種の技術としては、非特許文献１や非特許文献２で示されるように、複数のマシンのディスクを組み合わせて１つの分散ファイルシステムとして機能する分散プラットフォームが提案されている。
非特許文献１に示されたGfarmは、広域ネットワーク上で、大容量、大規模データ処理の要求に応えるスケーラブルな分散ファイルシステムプラットフォームであり、広域なネットワーク上での効率的なファイル共有に適した分散プラットフォームである。
一方、非特許文献２に示されたHadoopは、１つのディスクで保存できない大量のデータを並列化することで高速かつ効率良く処理できるものであり、比較的大きなサイズかつ基本的に更新されることのないファイルのＩ／Ｏに適した分散プラットフォームである。

従来、複数のサーバで構成された分散ファイルシステムにおける監視システムは、各サーバの状態を定期的に収集し、統合的に分析することが行われている。収集される情報としては、ＣＰＵ使用率、メモリ使用量、ディスク使用量、ＣＰＵ温度、ネットワーク接続状態などが存在する。統合的な分析例としては、ＣＰＵ使用率が８０％以上のファイルサーバの台数を把握することでファイルサーバの混雑度が分かる。これにより、システムの使用状況に対して、ファイルサーバの台数が十分かどうかなどの指標を得ることができる。

URL：http://datafarm.apgrid.org/indeＸ.ja.html URL：http://hadoop.apache.org/

上述した分散ファイルシステムの監視システムとしては、定期的に各サーバに対してリアルタイム（予め設定された時間毎）でのポーリングを行うことでサーバ状態を収集することが行われる。しかしながら、ポーリングによるサーバ状態を収集はリアルタイムに行われるので、サーバおよび監視システムにおいて負担が大きい上に、サーバ負荷が高い際に正常な状態取得ができない場合が生じる可能性がある。
また、上述した監視システムでは、各サーバが過負荷であるかの状態は分かるものの、分散ファイルシステムを構成するネットワークの問題（過負荷等による不具合）は測定できないという問題点が存在した。

本発明は上記実情に鑑みて提案されたもので、複数のサーバで構成された分散ファイルシステムにおいて、サーバでの負担の軽減を図りながらシステム全体の監視を行い、分散ファイルシステム内におけるボトルネックの発生箇所の特定を可能とする運用監視システム及び運用監視方法を提供することを目的としている。

上記目的を達成するため本発明は、複数のサーバで構成された分散ファイルシステムにおいて、ファイルアクセス（書き込み、読み込み、更新等）の実施に関する各サーバの通信ログを収集することでシステム全体の監視を行う。
すなわち、請求項１の発明は、データの格納を行う１つまたは複数のファイルサーバと、ユーザ端末からのアクセス要求の受付とデータの格納先の管理を行う少なくとも１つのプロキシサーバとを備え、前記ファイルサーバとプロキシサーバ、プロキシサーバとユーザ端末とがそれぞれネットワークを介して接続された分散ファイルシステムにおいて、次の構成を含むことを特徴としている。
ログ収集部。このログ収集部は、前記ファイルサーバおよび前記プロキシサーバ上で取得した通信ログを検出する。
ボトルネック分析部。このボトルネック分析部は、検出された各通信ログを比較することで分散ファイルシステムにおけるボトルネック箇所を特定するための分析を行う。

請求項２は、請求項１の運用監視システムにおいて、前記プロキシサーバは、前記データの格納先の管理を行うため独立して存在させたメタデータサーバを含み、前記ログ収集部は、前記メタデータサーバ上で取得した通信ログを検出し、前記ボトルネック分析部は、前記メタデータサーバ上で取得した通信ログも併せて比較対象として分析を行うことを特徴としている。

請求項３は、請求項１の運用監視システムにおいて、前記ファイルサーバおよびプロキシサーバをそれぞれ複数設け、前記ボトルネック分析武は、前記複数のファイルサーバおよび複数のプロキシサーバで取得した通信ログも併せて比較することを特徴としている。

請求項４は、請求項２の運用監視システムにおいて、前記メタデータサーバを複数設け、前記ボトルネック分析部は、前記複数のメタデータサーバで取得した通信ログも併せて比較することを特徴としている。

請求項５は、請求項１又は請求項３の運用監視システムにおいて、前記通信ログは、ユーザ端末での処理時間、プロキシサーバでの処理時間、ファイルサーバでの処理時間、あるいは、これらのうちの一部であることを特徴としている。

請求項６は、請求項２又は請求項４の運用監視システムにおいて、前記通信ログは、ユーザ端末での処理時間、プロキシサーバでの処理時間、ファイルサーバでの処理時間、メタデータサーバでの処理時間の全て、あるいは、これらのうちの一部であることを特徴としている。

請求項７は、請求項１、請求項３又は請求項５のいずれか１項に記載の運用監視システムにおいて、ユーザ要求の処理時間及びプロキシサーバでの処理時間は前記プロキシサーバで収集し、ファイルサーバでの処理時間は前記ファイルサーバで収集することを特徴としている。

請求項８は、請求項２、請求項４または請求項６のいずれか１項に記載の運用監視システムにおいて、ユーザ要求の処理時間及びプロキシサーバでの処理時間は前記プロキシサーバで収集し、ファイルサーバでの処理時間は前記ファイルサーバで収集し、メタデータサーバでの処理時間は前記メタデータサーバで収集することを特徴としている。

請求項９は、請求項１又は請求項２の運用監視システムにおいて、前記通信ログを一定時間毎に収集し、前記一定時間よりも大きな単位時間毎に、サンプル数、平均値、分散、最大値、最小値、９９％値、９５％値などの統計情報に加工するログ加工部を有することを特徴としている。

請求項１０は、請求項９の運用監視システムにおいて、前記ファイルサーバ、プロキシサーバ及びメタデータサーバをそれぞれ複数設け、前記ログ加工部は、取得した通信ログの統計情報に関して、複数の同一種別のサーバに対して統計量を集約する機能を有することを特徴としている。

請求項１１は、請求項１０の運用監視システムにおいて、前記ボトルネック分析部は、前記ログ加工部で取得した通信ログの統計情報に関して、前記統計情報が予め記憶された閾値を超えた場合に異常値と判断することを特徴としている。

請求項１２は、請求項９又は請求項１０の運用監視システムにおいて、前記通信ログは、ユーザ要求の処理時間の統計情報、プロキシサーバでの処理時間の統計情報、ファイルサーバでの処理時間の統計情報、メタデータサーバでの処理時間の統計情報の全て、あるいは、これらのうちの一部であり、前記統計情報に関する正常値・異常値の組合せによって、ボトルネックの切り分けを行うことを特徴としている。

請求項１３は、請求項１１又は請求項１２の運用監視システムにおいて、前記通信ログの統計情報に関して、これまでに得られたサンプルをＸ₁〜Ｘ_nとし、その平均Ｅ（Ｘ）、標準偏差σ（Ｘ）、予め定められた係数αに関して、新しく得られた値Ｘ_n+1がＥ（Ｘ）+ασ（Ｘ）よりも大きい場合に異常値と判定することを特徴としている。

請求項１４は、請求項１１又は請求項１２の運用監視システムにおいて、前記通信ログの統計情報に関して、ある時間枠Ｔi（時刻t_iから時刻t_i+1まで）に得られたサンプルをＸ₁〜Ｘ_nとし、その平均Ｅ（Ｘ）、標準偏差σ（Ｘ）、予め定められた係数αに関して、新しく得られた値Ｘ_n+1がＥ（Ｘ）+ασ（Ｘ）よりも大きい場合に異常値と判定し、次以降の時間枠Ｔ_i+j（時刻t_i+jから時刻t_i+j+1まで）においても異常判定のためその閾値を利用することを特徴としている。

請求項１５は、請求項１〜請求項１４のいずれか１項に記載の運用監視システムにおいて、前記通信ログの統計情報に関して、特定の統計情報に関して異常値が発生した場合に運用者への通知を行うボトルネック通知部を備えたことを特徴としている。

請求項１６は、データの格納を行う１つまたは複数のファイルサーバと、ユーザ端末からのアクセス要求の受付とデータの格納先の管理を行う少なくとも１つのプロキシサーバとを備え、前記ファイルサーバとプロキシサーバ、プロキシサーバとユーザ端末とがそれぞれネットワークを介して接続された分散ファイルシステムにおいて、前記ファイルサーバおよび前記プロキシサーバ上で取得した通信ログを定期的に収集し、前記各通信ログを比較することで、ボトルネックが、ユーザ端末／プロキシサーバ間のネットワーク、プロキシサーバ／ファイルサーバ間のネットワーク、特定のプロキシサーバ、ファイルサーバ全体、特定のファイルサーバのいずれに存在するかの切り分けを行ってボトルネック箇所を特定することを特徴としている。

本発明によれば、ファイルアクセス（書き込み、読み込み、更新等）の実施に関する各サーバの通信ログを定期的に収集し、ボトルネック分析部により検出された各通信ログを比較することで分散ファイルシステムにおけるボトルネック箇所を特定するための分析を行うので、ポーリング方式の課題であるサーバへの負荷発生やデータ取得時の不具合を回避することができる。また、定期的な収集は、リアルタイム性を必要としないという点でポーリングと異なるので、サーバへの負荷を削減して、データの収集を行うことができる。

各通信ログには、ファイルサーバ、プロキシサーバ、メタデータサーバにおいて取得したものを使用するので、ボトルネック発生箇所について、ユーザ端末／プロキシサーバ間のネットワーク、プロキシサーバ／ファイルサーバ間のネットワーク、プロキシサーバ、ファイルサーバ、メタデータサーバのいずれに存在するかを切り分け可能とすることができる。
すなわち、分散ファイルシステムが有する通信ログ取得機能を用いて、分散ファイルシステム内のどの箇所にボトルネックが発生したかについての切り分けを確実に行うことができる。その結果、分散ファイルシステムの性能劣化要因を的確に把握することができ、ボトルネック回避と安定運用に向けて、適切な対策を行うことができる。

本発明の分散ファイルシステムにおける監視システムの実施形態の一例を示す全体構成モデル図である。 監視システムの構成を示すブロック図である。 分散ファイルシステムにおける監視システムの実施形態の他の例を示す全体構成モデル図である。 分散ファイルシステムにおける監視システムの実施形態の他の例を示す全体構成モデル図である。

本発明の分散ファイルシステムにおける監視システムの実施形態の一例について、図面を参照しながら説明する。図１は、分散ファイルシステムにおける監視システムの全体構成図である。
分散ファイルシステム１０は、プロキシサーバ１と、１台〜複数台のファイルサーバ２で構成され、プロキシサーバ１と各ファイルサーバ２との間は、インターネットやイントラネット等のネットワーク（あるいはＬＡＮ）３で接続されている。ファイルサーバ２間はＬＡＮ４で接続され、各ファイルサーバ２が記憶部（ストレージ）を有することで、複数のファイルサーバ２を広域な範囲に分散配置させた分散ファイルシステム１０を形成している。
そして、分散ファイルシステム１０は、インターネット等のネットワーク５を介して複数のユーザ端末６に接続され、分散ファイルシステム１０に対して各ユーザによりファイル書込み要求及びファイル読込み要求が行われ、ユーザ端末６に対して複数のファイルサーバ２を仮想的に１つの巨大ストレージとして見せるネットワークが構成されている。
プロキシサーバ１及び各ファイルサーバ２は、インターネット等のネットワークや独自のネットワークを介して運用システム２０に接続されることで管理されている。

プロキシサーバ１は、ユーザ端末６に対して分散ファイルシステム１０へのアクセス環境を提供する。また、プロキシサーバ１は、ファイルの格納先ファイルサーバ２の情報（メタ情報と呼ぶ）を管理するメタデータサーバ７に接続されている。メタデータサーバ７が行う機能については、プロキシサーバ１が兼用する分散ファイルシステム１０により行うようにしてもよい。

ユーザ端末６は、インターネット等のネットワーク５を介して、プロキシサーバ１経由で分散ファイルシステム１０にアクセスする。具体的には、ファイルサーバ２へのファイルの書き込み、読み込み、更新などの制御を行う。
運用監視システム２０は、分散ファイルシステム１０を構成するサーバ（プロキシサーバ１及び複数台のファイルサーバ２）に対して管理用ネットワークで接続され、各サーバの通信ログを収集し、ボトルネック箇所の検出と運用者への通知を行う。管理用ネットワークに代えて、通常のネットワーク（インターネット等）で接続されるようにしてもよい。

次に、ボトルネック箇所の検出と運用者への通知を行う運用監視システム２０の内部構成について、図２を参照しながら説明する。
運用監視システム２０は、ログ収集部２１、ログ加工部２２、ボトルネック分析部２３、異常値決定部２４、ボトルネック通知部２５、ログ蓄積情報を保管するデータベース（ログ履歴情報管理部）２６で構成される。
ログ収集部２１は、各サーバ（プロキシサーバ１及びファイルサーバ２）より通信ログを収集する。ログ加工部２２は、通信ログをサーバ種別毎に集約した情報に加工する。ボトルネック分析部２３は、集約された通信ログを元に、ボトルネック箇所の分析を行う。データベース２６（ログ履歴情報管理部）は、ログ加工部２２が収集・蓄積したログ履歴情報を保管する。異常値決定部２４は、ログ加工部２２が収集しデータベース２６に蓄積したログ履歴情報をもとに異常と判定するための閾値を決定し、ボトルネック分析部２３に通知する。閾値は、例えば運用監視システム２０の運用者により予め設定されている。ボトルネック通知部２５は、検出されたボトルネック箇所を運用者に通知する。

ログ収集部２１において各サーバから収集する通信ログは、プロキシサーバ１、ファイルサーバ２、メタデータサーバ７において、それぞれ以下のものが想定される。
プロキシサーバ１は、ユーザ端末６から各種Ｉ／Ｏ要求(ファイル書き込み、ファイル読み込み、ファイル名変更等)を受け付けるので、通信ログとして、個々のＩ／Ｏ要求における要求時刻、自サーバアドレス、要求元アドレス、データ方向、ファイルサイズ、ユーザ要求処理時間、ファイル片サイズ、ファイル片毎の処理時間の情報を取得する。
この場合、自サーバアドレスは、プロキシサーバ１のＩＰアドレスである。
要求元アドレスは、ユーザ端末６のＩＰアドレスである。
データ方向は、ユーザ端末６→プロキシサーバ１（ファイル書き込みの場合、これに該当）、プロキシサーバ１→ユーザ端末６（ファイル読み込みの場合、これに該当）、データ転送なし（ファイル名変更の場合、これに該当）の３種類が存在する。
ユーザ要求の処理時間は、Ｉ／Ｏ要求を受けてから、ユーザ端末６に応答を返すまでの時間である。
ファイル片サイズは、分散ファイルシステム１０内でデータを転送する際の単位長を示す。１つの分散ファイルシステム１０において固定値である場合も存在する。
ファイル片毎の処理時間は、ファイル片に対するＩ／Ｏ要求をプロキシサーバ１／ファイルサーバ２間で処理する時間である。

ファイルサーバ２は、プロキシサーバ１から各種Ｉ／Ｏ要求（ファイル片書き込み、ファイル片読み込み）を受け付けるので、通信ログとして、個々のＩ／Ｏ要求における要求時刻、自サーバアドレス、要求元アドレス、データ方向、ファイル片サイズ、処理時間の情報を取得する。
この場合、自サーバアドレスは、ファイルサーバ２のＩＰアドレスである。
要求元アドレスは、プロキシサーバ１のＩＰアドレスである。
データ方向は、プロキシサーバ１→ファイルサーバ２（ファイル書き込みの場合、これに該当）、ファイルサーバ２→プロキシサーバ１（ファイル読み込みの場合、これに該当）の２種類が存在する。
処理時間は、Ｉ／Ｏ要求を受けてから、プロキシサーバ１に応答を返すまでの時間である。

メタデータサーバ７は、プロキシサーバ１から各種Ｉ／Ｏ要求（ファイル属性情報閲覧、ファイル属性情報更新等）を受け付けるので、通信ログとして、個々のＩ／Ｏ要求における要求時刻、自サーバアドレス、要求元アドレス、Ｉ／Ｏ要求種別、処理時間の情報を取得する。
この場合、自サーバアドレスは、メタデータサーバ７のＩＰアドレスである。
要求元アドレスは、プロキシユーザ１のＩＰアドレスである。
Ｉ／Ｏ要求種別は、ファイル書き込み、ファイル読み込み、ファイル名変更、ディレクトリ名変更、ファイル名参照、ディレクトリ名参照などのＩ／Ｏ要求の識別である。
処理時間は、メタデータサーバ内でＩ／Ｏ要求の処理に要する時間である。

ログ収集部２１で取得する通信ログは、以下のいずれかの方法で取得する。
分散ファイルシステム１０の各サーバプログラム自身が予め有する機能により通信ログを出力し、外部のプログラムから参照できるようにする。
分散ファイルシステム１０の各サーバプログラムが動作するサーバ機上で、wireshark等のトラフィック監視ツールで取得したパケットより、分散ファイルシステム１０へのアクセスに関するパケットだけ抜き出したものを通信ログとして出力し、外部のプログラムから参照できるようにする。

ログ加工部２２では、ログ収集部２１で取得した通信ログを統計的に集約（情報の圧縮）する。
具体的には以下の機能を実現する。一定時間毎に下記のパラメータの集約を行う。
プロキシサーバ１におけるユーザ要求の処理時間、ファイル片のＩ／Ｏ要求の処理時間。
ファイルサーバ２におけるファイル片のＩ／Ｏ要求の処理時間。
メタデータサーバ７におけるＩ／Ｏ要求の処理時間。
そして、一定時間毎に収集された通信ログ（サンプル）に関して、ログ加工部２２において予め設定された前記一定時間よりも大きな単位時間毎に、サンプル数、平均値、分散、最大値、最小値、９９％値、９５％値などの統計情報に加工する。
メタデータサーバ７のＩ／Ｏ要求の処理時間は、Ｉ／Ｏ要求の種別毎に分けて処理時間の統計情報を得るようにしてもよい。
また、処理の効率化を図るため、１つのサーバ上の複数の通信ログを集約することや、複数の同種のサーバ(プロキシサーバ１、ファイルサーバ２、メタデータサーバ７といった種別が同じサーバ)の通信ログを集約するようにしてもよい。

図１の例では、メタデータサーバ７がプロキシサーバ１に直接接続又は、プロキシサーバ１内部に存在する構成としたが、図３に示すように、ファイルサーバ２が接続されるＬＡＮ４にメタデータサーバ７が接続されるように構成してもよい。
この場合、プロキシサーバ１におけるファイルの格納先としてのファイルサーバ２の情報（メタ情報）は、ネットワーク３及びＬＡＮ４を介してメタデータサーバ７へ提供される。

また、図４に示すように、プロキシサーバ１ａ，１ｂ、メタデータサーバ７ａ，７ｂが複数存在する分散ファイルシステム１０の構成も考えられる。この例の場合、複数のファイルサーバ２に対してそれぞれＬＡＮ４ａ又はＬＡＮ４ｂを接続することで、複数のセグメントに分かれてファイルサーバ群を構成している。
各サーバが複数存在する場合には、ログ加工部２２では、複数の同種のサーバ(プロキシサーバ、ファイルサーバ、メタデータサーバといった種別が同じサーバ)の通信ログを集約することを可能とする。また、セグメント単位で統計情報を集約することで、セグメント間のネットワークにおけるボトルネックの発生箇所の特定（切り分け）を行うことを可能としている。

図４のネットワーク構成を例にした場合、ボトルネックが発生する箇所は以下の（ａ）〜（ｅ−２）いずれかの部分となる。
（ａ）ユーザ端末／プロキシサーバ間のネットワーク
（ｂ）プロキシサーバ／ファイルサーバ間のネットワーク、又は、プロキシサーバ（全般的に）
（ｃ）特定のプロキシサーバ
（ｄ−１）ファイルサーバ（全般的に）
（ｄ−２）特定のファイルサーバ
（ｅ−１）メタデータサーバ（全般的に）
（ｅ−２）特定のメタデータサーバ

ボトルネック分析部２３におけるボトルネック発生箇所の切り分けは、各サーバの通信ログにおける処理時間（ユーザ要求の処理時間、プロキシサーバでの処理時間、メタデータサーバでの処理時間、ファイルサーバでの処理時間）の正常，異常の識別の組合せによって判定する。具体的には、前記（ａ）〜（ｅ−２）に対して、各サーバの通信ログにおける処理時間の正常，異常との対応関係は、表１のような対応づけとなる。

すなわち、ユーザ要求の処理時間が異常、プロキシサーバ１での処理時間が正常、メタデータサーバ７での処理時間が正常、ファイルサーバ２での処理時間が正常である場合は、（ａ）のユーザ端末／プロキシサーバ間のネットワークにボトルネック箇所が生じたと判断する。
ユーザ要求の処理時間が異常、プロキシサーバ１での処理時間が異常、メタデータサーバ７での処理時間が正常、ファイルサーバ２での処理時間が正常である場合は、（ｂ）のプロキシサーバ／ファイルサーバ間のネットワーク、あるいは、全般的なプロキシサーバにボトルネック箇所が生じたと判断する。
ユーザ要求の処理時間が異常（一部のプロキシサーバ１にのみ異常）、プロキシサーバ１での処理時間が異常（一部のプロキシサーバにのみ異常）、メタデータサーバ７での処理時間が正常、ファイルサーバ２での処理時間が正常である場合は、（ｃ）の特定のプロキシサーバ１にボトルネック箇所が生じたと判断する。

ユーザ要求の処理時間が異常、プロキシサーバ１での処理時間が異常、メタデータサーバ７での処理時間が正常、ファイルサーバ２での処理時間が異常である場合は、（ｄ−１）の全般的なファイルサーバにボトルネック箇所が生じたと判断する。
ユーザ要求の処理時間が異常（一部のファイルサーバ２にのみ異常）、プロキシサーバ１での処理時間が異常（一部のファイルサーバ２にのみ異常）、メタデータサーバ７での処理時間が正常、ファイルサーバ２での処理時間が異常（一部のファイルサーバ２にのみ異常）である場合は、（ｄ−２）の特定のファイルサーバ２にボトルネック箇所が生じたと判断する。

ユーザ要求の処理時間が正常、プロキシサーバ１での処理時間が正常、メタデータサーバ７での処理時間が異常、ファイルサーバ２での処理時間が正常である場合は、（ｅ−１）の全般的なメタデータサーバ７にボトルネック箇所が生じたと判断する。
ユーザ要求の処理時間が正常、プロキシサーバ１での処理時間が正常、メタデータサーバ７での処理時間が異常（一部のメタデータサーバ７に異常）、ファイルサーバ２での処理時間が正常である場合は、（ｅ−２）の特定のメタデータサーバ７にボトルネック箇所が生じたと判断する。
なお、メタデータサーバの異常時においては、メタデータサーバの性能が著しく低下した場合には、ユーザ要求の処理時間が異常となる場合がある。

ボトルネック分析部２３における各処理時間の正常，異常の識別は、異常値決定部２４において各処理時間のパラメータ毎に予め設定された閾値と、ログ加工部２２で取得した統計量を比較することで判断する。例えば、閾値１０msec、統計量として通信ログ（処理時間）の平均を使用する場合、処理時間の平均が１０msec未満であれば正常、１０msec以上であれば異常と判断する。
ボトルネック通知部２５は、上述したいずれかの処理時間において異常が発生した場合、運用監視システムの画面上で「異常」を表示し、運用者へのメールの送信，警報音の発生等を行う。

ボトルネック通知部２５からの通知頻度は、例えば以下のようにして行われる。
一定時間の集約の際、異常であったものについて全て通知を行う。
一定時間の集約の際、新たに異常となったものについてのみ通知を行う。
一定時間毎の集約の際、新たに異常となったもののうち、一定時間前にさかのぼって異常が通知されていない項目のみ通知を行う。
異常から正常に変化した場合にも同様の通知を行う。

上述した実施形態では、ボトルネック分析部２３における各処理時間の正常，異常を識別するため異常値決定部２４で予め設定される閾値は、運用者がノウハウに基づき予め決定して記憶させている。しかし、新しく導入したサーバ機等においては、処理時間に関して異常と判定すべき閾値に関するノウハウを運用者が持たない場合が存在する。このような場合に対処するため、起動処理中において閾値を自動的に算出する機能を異常値決定部２４が備えるように構成してもよい。

この機能は、例えば、新しく導入したサーバへのＩ／Ｏ要求が少ないときに得られた処理時間を正常値と判断して記憶しておき、正常な処理時間の値から大きく離れた値を異常と判定する。
すなわち、分散ファイルシステムにおいて新規にサーバを導入した場合には、そのサーバ上にファイルが存在しないため、ファイル読み込み要求が発生しない分、Ｉ／Ｏ要求は少ないものと考えられる。したがって、Ｉ／Ｏ要求がある一定の閾値を超えるまでは、サーバは低負荷のため、ほぼ一定の処理時間を保つと考えられる。サーバの負荷が一定値を超えると急に処理時間が増大するものと考えられる。
処理時間の増大については、それ以前に得られた処理時間サンプルの標準偏差を得ることで検知する。

異常と判定する閾値の算出方法としては、以下のいずれかの場合が考えられる。
一例として、あるパラメータにおいて、これまでに得られたサンプルをＸ₁〜Ｘ_n（ｎ個）とした場合、その平均Ｅ（Ｘ）、標準偏差σ（Ｘ）を求め、異常閾値をＥ（Ｘ）+ασ（Ｘ）として記憶しておき、Ｘ_n+1が異常閾値よりも大きい場合に異常値と判定する。ただし、αはパラメータごとに運用者が設定する固定値とする。
他の例として、あるパラメータにおいて、ある時間枠Ｔ_i（時刻t_iから時刻t_i+1まで）に得られたサンプルをＸ₁〜Ｘ_n（ｎ個）とした場合、その平均Ｅ（Ｘ）、標準偏差σ（Ｘ）を求め、異常閾値をＥ（Ｘ）+ασ（Ｘ）として記憶しておき、Ｘ_n+1が異常閾値よりも大きい場合に異常値と判定する。ただし、αはパラメータごとに運用者が設定する固定値とする。次の時間枠Ｔ_i+1（時刻t_i+1から時刻t_i+2まで）においても、時間枠Ｔ_iと同じ異常閾値を用いる。

運用管理システムの各実施形態によれば、ポーリング方式の課題であるサーバへの負荷発生やデータ取得時の不具合を回避するため、ファイルアクセス（書き込み、読み込み、更新等）の実施に関する各サーバの通信ログを定期的に収集してボトルネック分析部で分析する。この定期的な収集は、リアルタイム性を必要としないという点でポーリングと異なるので、サーバへの負荷を削減して、データの収集を行うことができる。
また、プロキシサーバ上の通信ログとファイルサーバの通信ログを比較することで、プロキシサーバ／ファイルサーバ間のネットワークの問題の有無を確認することができる。

運用者がボトルネック通知部２５によりボトルネック箇所を把握した場合、以下のような運用対策例を行うことができる。
ファイルサーバ２が全般的にボトルネックの場合、ファイルサーバ数を物理的に増やす、各ファイルサーバ単体の処理性能を向上させるなどにより、ボトルネックを回避する。
特定のファイルサーバ２がボトルネックの場合、ファイルサーバ２へのアクセスが分散されるように、ファイルサーバ毎のファイルの格納数を分散させる。または、アクセス頻度が大きいファイルサーバ２について複製を作成し、ファイルサーバのアクセスの分散を図る。
ユーザ端末／プロキシサーバ間のネットワークがボトルネックの場合、プロキシサーバ１をユーザ端末６の近くに設置し、ネットワーク遅延を減らしてボトルネックを回避する。
プロキシサーバ／ファイルサーバ間で、特定のセグメントのネットワークにボトルネックが発生した場合、そのセグメントのファイルサーバ２を別のセグメントに移動させることにより、ボトルネックを回避する。

１…プロキシサーバ、 ２…ファイルサーバ、 ３…ネットワーク、 ４…ＬＡＮ、 ５…ネットワーク、 ６…ユーザ端末、 ７…メタデータサーバ、 １０…分散ファイルシステム、 ２０…運用監視システム、 ２１…ログ収集部、 ２２…ログ加工部、 ２３…ボトルネック分析部、 ２４…異常値決定部、 ２５…ボトルネック通知部、 ２６…データベース（ログ履歴情報管理部）。

Claims (16)

1. データの格納を行うファイルサーバと、ユーザ端末からのアクセス要求の受付とデータの格納先の管理を行うプロキシサーバとを備え、前記ファイルサーバとプロキシサーバ、プロキシサーバとユーザ端末とがそれぞれネットワークを介して接続された分散ファイルシステムにおいて、
   前記ファイルサーバおよび前記プロキシサーバ上で取得した通信ログを検出するログ収集部と、
   前記各通信ログを比較することで前記分散ファイルシステムにおけるボトルネック箇所を特定するための分析を行うボトルネック分析部と
   を備えたことを特徴とする分散ファイルシステムにおける運用監視システム。
2. 前記プロキシサーバは、前記データの格納先の管理を行うため独立して存在させたメタデータサーバを含み、
   前記ログ収集部は、前記メタデータサーバ上で取得した通信ログを検出し、
   前記ボトルネック分析部は、前記メタデータサーバ上で取得した通信ログも併せて比較対象として分析を行う
   請求項１に記載の分散ファイルシステムにおける運用監視システム。
3. 前記ファイルサーバおよびプロキシサーバをそれぞれ複数設け、
   前記ボトルネック分析部は、前記複数のファイルサーバおよび複数のプロキシサーバで取得した通信ログも併せて比較する
   請求項１に記載の分散ファイルシステムにおける運用監視システム。
4. 前記メタデータサーバを複数設け、
   前記ボトルネック分析部は、前記複数のメタデータサーバで取得した通信ログも併せて比較する
   請求項２に記載の分散ファイルシステムにおける運用監視システム。
5. 前記通信ログは、ユーザ端末での処理時間、プロキシサーバでの処理時間、ファイルサーバでの処理時間、あるいは、これらのうちの一部である請求項１又は請求項３に記載の分散ファイルシステムにおける運用監視システム。
6. 前記通信ログは、ユーザ端末での処理時間、プロキシサーバでの処理時間、ファイルサーバでの処理時間、メタデータサーバでの処理時間の全て、あるいは、これらのうちの一部である請求項２又は請求項４に記載の分散ファイルシステムにおける運用監視システム。
7. ユーザ要求の処理時間及びプロキシサーバでの処理時間は前記プロキシサーバで収集し、ファイルサーバでの処理時間は前記ファイルサーバで収集する請求項１、請求項３または請求項５のいずれか１項に記載の分散ファイルシステムにおける運用監視システム。
8. ユーザ要求の処理時間及びプロキシサーバでの処理時間は前記プロキシサーバで収集し、ファイルサーバでの処理時間は前記ファイルサーバで収集し、メタデータサーバでの処理時間は前記メタデータサーバで収集する請求項２、請求項４または請求項６のいずれか１項に記載の分散ファイルシステムにおける運用監視システム。
9. 前記通信ログを一定時間毎に収集し、前記一定時間よりも大きな単位時間毎に、サンプル数、平均値、分散、最大値、最小値、９９％値、９５％値などの統計情報に加工するログ加工部を有する請求項１又は請求項２に記載の分散ファイルシステムにおける運用監視システム。
10. 前記ファイルサーバ、プロキシサーバ及びメタデータサーバをそれぞれ複数設け、
    前記ログ加工部は、取得した通信ログの統計情報に関して、複数の同一種別のサーバに対して統計量を集約する機能を有する請求項９に記載の分散ファイルシステムにおける運用監視システム。
11. 前記ボトルネック分析部は、前記ログ加工部で取得した通信ログの統計情報に関して、前記統計情報が予め記憶された閾値を超えた場合に異常値と判断する請求項１０に記載の分散ファイルシステムにおける運用監視システム。
12. 前記通信ログは、ユーザ要求の処理時間の統計情報、プロキシサーバでの処理時間の統計情報、ファイルサーバでの処理時間の統計情報、メタデータサーバでの処理時間の統計情報の全て、あるいは、これらのうちの一部であり、前記統計情報に関する正常値・異常値の組合せによって、ボトルネックの切り分けを行う請求項９又は請求項１０に記載の分散ファイルシステムにおける運用監視システム。
13. 前記通信ログの統計情報に関して、これまでに得られたサンプルをＸ₁〜Ｘ_nとし、その平均Ｅ（Ｘ）、標準偏差σ（Ｘ）、予め定められた係数αに関して、新しく得られた値Ｘ_n+1がＥ（Ｘ）+ασ（Ｘ）よりも大きい場合に異常値と判定する請求項１１又は請求項１２に記載の分散ファイルシステムにおける運用監視システム。
14. 前記通信ログの統計情報に関して、ある時間枠Ｔi（時刻t_iから時刻t_i+1まで）に得られたサンプルをＸ₁〜Ｘ_nとし、その平均Ｅ（Ｘ）、標準偏差σ（Ｘ）、予め定められた係数αに関して、新しく得られた値Ｘ_n+1がＥ（Ｘ）+ασ（Ｘ）よりも大きい場合に異常値と判定し、次以降の時間枠Ｔ_i+j（時刻t_i+jから時刻t_i+j+1まで）においても異常判定のためその閾値を利用する請求項１１又は請求項１２に記載の分散ファイルシステムにおける運用監視システム。
15. 前記通信ログの統計情報に関して、特定の統計情報に関して異常値が発生した場合に運用者への通知を行うボトルネック通知部を備えた請求項１〜１４のいずれか１項に記載の分散ファイルシステムにおける運用監視システム。
16. データの格納を行う１つまたは複数のファイルサーバと、ユーザ端末からのアクセス要求の受付とデータの格納先の管理を行う少なくとも１つのプロキシサーバとを備え、前記ファイルサーバとプロキシサーバ、プロキシサーバとユーザ端末とがそれぞれネットワークを介して接続された分散ファイルシステムにおいて、
    前記ファイルサーバおよび前記プロキシサーバ上で取得した通信ログを定期的に収集し、
    前記各通信ログを比較することで、ボトルネックが、ユーザ端末／プロキシサーバ間のネットワーク、プロキシサーバ／ファイルサーバ間のネットワーク、特定のプロキシサーバ、ファイルサーバ全体、特定のファイルサーバのいずれに存在するかの切り分けを行ってボトルネック箇所を特定する分散ファイルシステムにおける運用監視方法。

Images