JP2013025742A - 分散ファイル管理装置、分散ファイル管理方法及びプログラム - Google Patents

Abstract

【課題】大容量ファイルが分散して複数のサーバマシンに書き込まれたシステムにおいて、システム全体の障害管理や構成管理を容易に実現でき、システムの故障の切り分けや、影響範囲の特定、増減設の計画等を容易に行う。
【解決手段】大容量ファイルを論理的に構成、制御するマスター機能２２から、大容量ファイルについての管理情報を取得するとともに、大容量ファイルが分散したデータを書き込まれた複数のサーバマシン４０−１〜４０−ｎ毎に、サーバマシン４０−１〜４０−ｎへのデータの物理的な書き込み／読み出しを制御するワーカー機能４１−１〜４１−ｎから、サーバマシン４０−１〜４０−ｎに書き込まれたデータについての管理情報を取得し、これらの情報を指定された設定に基づいて対応づけて管理する。
【選択図】図１

Description

本発明は、ファイルを複数のサーバマシンに分散して書き込むことにより、大容量のファイルの書き込みや読み出しを可能とするネットワークにて分散ファイルを管理する管理装置に関する。

大規模分散ファイルシステムは、個々のマシンに搭載される物理的なディスク単体では扱えない大容量のファイルを提供するものである。多数のマシンをネットワークで接続することにより、いくらでもファイル容量を拡大できる特徴がある。

図１７は、大規模分散ファイルシステムと従来の管理装置の一例を示す図である。

図１７に示すように、従来は、論理管理装置１１１と物理管理装置１１３とによって大規模分散ファイルシステム１２０を管理している。大規模分散ファイルシステム１２０は、特定のマシン１２１に設けられ、大容量ファイル１２３ａ〜１２３ｚを論理的に構成、制御するマスター機能１２２と、大容量ファイル１２３ａ〜１２３ｚが分散したデータを書き込まれた複数のサーバマシン１４０−１〜１４０ｎ毎に、そのサーバマシン１４０−１〜１４０ｎの物理的なディスク１４２−１〜１４２−ｎへの書き込み／読み出しを制御するワーカー機能１４１−１〜１４１−ｎとを有している。また、物理的なスイッチ群として、構成管理機能１３１−１，１３１−２及び監視機能１３２−１，１３２−２を具備するスイッチ１３０−１，１３０−２を有している。

このような大規模分散ファイルシステム１２０に対して、論理管理装置１１１は、論理的なファイル管理機能１１２によって大規模分散ファイルシステム１２０の論理的な大容量ファイル１２３ａ〜１２３ｚを管理し、また、物理管理装置１１３は、物理的なディスク管理機能１１５によってサーバマシン１４０−１〜１４０ｎ個々の物理的なディスク１４２−１〜１４２−ｎを管理するとともに、ネットワーク管理機能１１４によってスイッチ１３０−１，１３０−２を含むネットワークを管理している（例えば、非特許文献１参照）。

図１８は、図１７に示した管理装置にて管理される情報を示す図であり、（ａ）は論理管理装置１１１にて管理される情報を示す図、（ｂ）は物理管理装置１１３にて管理される情報を示す図である。

図１８に示すように、論理管理装置１１１においては、論理的なファイル管理として、ファイルの容量や作成日、利用者等を管理しており、物理管理装置１１３においては、物理的なディスク管理として、ディスクの使用容量や空き容量等を管理している（例えば、非特許文献２，３参照）。

The Google File System (S.Ghemawat, 他), 19th ACM Symposium on Operating Systems Principles, October, 2003. http://labs.google.com/papers/gfs.html HadoopのWebUI, Hadoop徹底入門, 太田他, 翔泳社,pp.287-292, 2011年 HUE(Hadoop User Experience): a Web UI for Hadoop, cloudera社, by bc, July 19, 2010 http://www.cloudera.com/blog/2010/07/whats-new-in-cdh3b2-hue/, 2011年3月ブラウズ

しかしながら、上述したように論理的な大容量ファイルの情報は物理的なディスクに格納されているが、その対応関係は、論理管理装置でも物理管理装置でも分からない。そのため、故障の切り分けや影響範囲の特定、増減設の計画等の構成管理が困難であるという問題点がある。

図１９は、図１７に示したネットワーク構成における問題点の一例を説明するための図である。

図１９に示すように、例えば、論理的な大容量ファイル１２３ａの情報Ａ１〜Ａｘが、物理的なディスク１４２−１，１４２−３，１４２−ｎに書き込まれているとする。このとき、情報Ａ２が書き込まれた物理的なディスク１４２−３を有するサーバマシン１４０−３に故障が生じたとしても、その故障が論理的な大容量ファイル１２３ａに影響があるか判定することは容易ではない。

ここで、ＵＮＩＸシステムで利用される分散ファイル共有システムとしてＮＦＳ（Network File System）がある。ＮＦＳを使うと、離れた場所にあるコンピュータのファイルを、あたかも自分のコンピュータにあるファイルのように操作することができるが、複数のサーバマシンの物理ディスクを論理的な大容量ファイルとして提供するものではないので、ＮＦＳの管理装置・方法で生じていなかった課題である。

図２０は、図１７に示したネットワーク構成における問題点の他の例を説明するための図である。

図２０に示すように、例えば、論理的な大容量ファイル１２３ａの情報Ａ１〜Ａｘが、物理的なディスク１４２−１，１４２−３，１４２−ｎに書き込まれており、物理的なスイッチ１３０−１の配下に複数のサーバマシン１４０−１，１４０−３，１４０−ｎが接続しているとする。このとき、スイッチ１３０−１に故障が生じると、サーバマシン１４０−１，１４０−３，１４０−ｎに接続できなくなり、結果的に論理的な大容量ファイル１２３ａにも接続できなくなるが、その判定は容易ではない。

本発明は、上述したような従来の技術が有する問題点に鑑みてなされたものであって、大容量ファイルが分散して複数のサーバマシンに書き込まれたシステムにおいて、システム全体の障害管理や構成管理を容易に実現でき、システムの故障の切り分けや、影響範囲の特定、増減設の計画等を容易に行うことができる、分散ファイル管理装置、分散ファイル管理方法及びプログラムを提供することを目的とする。

上記目的を達成するために本発明は、
大容量ファイルを論理的に構成、制御するマスター機能と、前記大容量ファイルが分散したデータを書き込まれた複数のサーバマシン毎に、当該サーバマシンへのデータの物理的な書き込み／読み出しを制御するワーカー機能とを有するネットワークにて、前記大容量ファイルと該大容量ファイルが分散したデータとを管理する分散ファイル管理装置であって、
大容量ファイルについての管理情報を前記マスター機能から取得する論理管理情報取得部と、
前記複数のサーバマシンに書き込まれたデータについての管理情報を前記ワーカー機能から取得する物理管理情報取得部と、
指定された設定に基づいて、前記論理管理情報取得部にて取得された大容量ファイルについての管理情報と、前記物理管理情報取得部にて取得されたデータについての管理情報とを対応づけて論理物理情報として記憶する論理物理管理部とを有する。

また、大容量ファイルを論理的に構成、制御するマスター機能と、前記大容量ファイルが分散したデータを書き込まれた複数のサーバマシン毎に、当該サーバマシンへのデータの物理的な書き込み／読み出しを制御するワーカー機能とを有するネットワークにて、前記大容量ファイルと該大容量ファイルが分散したデータとを管理する分散ファイル管理方法であって、
大容量ファイルについての管理情報を前記マスター機能から取得する論理管理情報取得処理と、
前記複数のサーバマシンに書き込まれたデータについての管理情報を前記ワーカー機能から取得する物理管理情報取得処理と、
指定された設定に基づいて、前記論理管理情報取得処理にて取得された大容量ファイルについての管理情報と、前記物理管理情報取得処理にて取得されたデータについての管理情報とを対応づけて論理物理情報として記憶する論理物理管理処理とを有する。

また、大容量ファイルを論理的に構成、制御するマスター機能と、前記大容量ファイルが分散したデータを書き込まれた複数のサーバマシン毎に、当該サーバマシンへのデータの物理的な書き込み／読み出しを制御するワーカー機能とを有するネットワークにて、前記大容量ファイルと該大容量ファイルが分散したデータとを管理するコンピュータに実行させるためのプログラムであって、
大容量ファイルについての管理情報を前記マスター機能から取得する論理管理情報取得手順と、
前記複数のサーバマシンに書き込まれたデータについての管理情報を前記ワーカー機能から取得する物理管理情報取得手順と、
指定された設定に基づいて、前記論理管理情報取得手順にて取得された大容量ファイルについての管理情報と、前記物理管理情報取得手順にて取得されたデータについての管理情報とを対応づけて論理物理情報として記憶する論理物理管理手順とを実行させる。

本発明は、大容量ファイルを論理的に構成、制御するマスター機能から、大容量ファイルについての管理情報を取得するとともに、大容量ファイルが分散したデータを書き込まれた複数のサーバマシン毎に、当該サーバマシンへのデータの物理的な書き込み／読み出しを制御するワーカー機能から、複数のサーバマシンに書き込まれたデータについての管理情報を取得し、これらの情報を指定された設定に基づいて対応づけて論理物理情報として記憶する構成としたため、大容量ファイルが分散して複数のサーバマシンに書き込まれたシステムにおいて、システム全体の障害管理や構成管理を容易に実現でき、システムの故障の切り分けや、影響範囲の特定、増減設の計画等を容易に行うことができる。

本発明の分散ファイル管理装置が採用されたシステムの実施の一形態を示す図である。 図１に示した管理情報記憶部に記憶された情報を示す図である。 図１に示した分散ファイル管理装置における処理手順の概要動作を示すフローチャートである。 図３に示した設定フェーズの手順を示すフローチャートである。 図３に示した管理情報取得・通知フェーズの手順を示すフローチャートである。 図１に示した分散ファイル管理装置における処理手順の具体例を示す図であり、（ａ）は通常時の処理手順を示す図、（ｂ）はサーバマシンの故障時の処理手順を示す図である。 図１に示した分散ファイル管理装置における処理手順の具体例を示す図であり、（ａ）は通常時の処理手順を示す図、（ｂ）はサーバマシンの故障時の処理手順を示す図である。 図２に示した論理物理管理情報の一例を示す図である。 図１に示したサーバマシンがダウンした際の論理物理管理情報の一例を示す図である。 故障したサーバマシンが回復した際の論理物理管理情報の一例を示す図である。 図２に示した論理物理管理情報の一例を示す図である。 図２に示した論理物理管理情報の一例を示す図である。 図１に示した大規模分散ファイルシステムにてチャンクのレプリカの集中が生じた状態を示す図であり、（ａ）はサーバマシンの故障前の状態を示す図、（ｂ）はサーバマシンの故障後の図１２に示した状態を示す図である。 図２に示した論理物理管理情報の一例を示す図である。 図２に示した論理物理管理情報の一例を示す図である。 図１に示した大規模分散ファイルシステムにて仮想サーバを用いた場合の仮想マシンとチャンクのレプリカ配置を示す図であり、（ａ）は仮想マシンの故障前の状態を示す図、（ｂ）は仮想マシンの故障後の図１５に示した状態を示す図である。 大規模分散ファイルシステムと従来の管理装置の一例を示す図である。 図１７に示した管理装置にて管理される情報を示す図であり、（ａ）は論理管理装置にて管理される情報を示す図、（ｂ）は物理管理装置にて管理される情報を示す図である。 図１７に示したネットワーク構成における問題点の一例を説明するための図である。 図１７に示したネットワーク構成における問題点の他の例を説明するための図である。

以下に、本発明の実施の形態について図面を参照して説明する。

図１は、本発明の分散ファイル管理装置が採用されたシステムの実施の一形態を示す図である。

本形態は図１に示すように、大規模分散ファイルシステム２０を分散ファイル管理装置１０によって管理するものである。大規模分散ファイルシステム２０は、特定のマシン２１に設けられ、大容量ファイル２３ａ〜２３ｚを論理的に構成、制御するマスター機能２２と、大容量ファイル２３ａ〜２３ｚが分散したデータを書き込まれた複数のサーバマシン４０−１〜４０ｎ毎に、そのサーバマシン４０−１〜４０ｎの物理的なディスク４２−１〜４２−ｎへの書き込み／読み出しを制御するワーカー機能４１−１〜４１−ｎとを有している。また、物理的なスイッチ群として、構成管理機能３１−１，３１−２及び監視機能３２−１，３２−２を具備するスイッチ３０−１，３０−２を有している。

分散ファイル管理装置１０は、論理管理情報取得部１１と、物理管理情報取得部１２と、論理物理管理部１３とから構成されている。

論理管理情報取得部１１は、大容量ファイル２３ａ〜２３ｚについての管理情報をマスター機能２２から取得する。

物理管理情報取得部１２は、複数のサーバマシン４０−１〜４０−ｎに書き込まれたデータについての管理情報をワーカー機能４１−１〜４１−ｎから取得する。

論理物理管理部１３は、指定された設定情報に基づいて、論理管理情報取得部１１にて取得された大容量ファイル２３ａ〜２３ｚについての管理情報と、物理管理情報取得部１２にて取得されたデータについての管理情報とを対応づけて論理物理情報として記憶するものであって、論理物理管理情報対応付け部１４と、通知閾値判定部１５と、管理情報記憶部１６と、制御部１７と、ユーザ通知部となるユーザインタフェース部１８とから構成されている。

論理物理対応付け部１４は、論理管理情報取得部１１にて取得された大容量ファイル２３ａ〜２３ｚについての管理情報と、物理管理情報取得部１２にて取得されたデータについての管理情報とを対応づけて論理物理情報として管理情報記憶部１６に記憶する。

通知閾値判定部１５は、物理管理情報取得部１２にて取得されたデータについての管理情報に基づいて、大規模分散ファイルシステム２０の各種状態が通知すべき状態かどうか、すなわち、管理情報が予め決められた条件を満たしているかどうかを判定する。

ユーザインタフェース部１８は、通知閾値判定部１５にて、大規模分散ファイルシステム２０の各種状態が通知すべき状態であると判定された場合にその旨をユーザに通知したり、上述した管理情報の対応付けや閾値の設定のためのＧＵＩやＣＵＩを提供したりする。

制御部１７は、管理情報記憶部１６に対する各種設定の入力、削除、変更を行うとともに、各種設定を参照しつつ、上述した管理情報の取得、対応付け、通知判定を制御する。

図２は、図１に示した管理情報記憶部１６に記憶された情報を示す図である。

図１に示した管理情報記憶部１６は図２に示すように、論理管理情報取得部１１にて取得された論理管理情報５２と、論理管理情報５２を取得するために必要な論理管理情報取得設定５１と、物理管理情報取得部１２にて取得された物理管理情報５４と、物理管理情報５４を取得するために必要な物理管理情報取得設定５３と、論理物理管理情報対応付け部１４にて対応付けられた論理物理管理情報５６と、論理物理管理情報５６を対応付けるために必要な論理物理管理情報対応付け設定５５と、通知のための閾値設定５７とにより構成される。なお、論理管理情報５２とは、論理的な大容量ファイル２３ａ〜２３ｚについての情報であって、ファイル名や使用容量等である。また、物理管理情報５４とは、サーバマシン４０−１〜４０−ｎの名称や物理的なディスク４２−１〜４２−ｎの名称や使用容量、状態、さらには、個々のスイッチ３０−１，３０−２等の物理構成やネットワークの利用状況に関する情報である。

上記のように構成された分散ファイル管理装置１０を用いて大容量ファイルの分散ファイル管理を行う場合は、オペレータは予め、ユーザインタフェース部１８を介して、論理管理情報取得設定５１と、物理管理情報取得設定５３と、論理物理対応付け設定５５と、通知のための通知閾値５７とを設定する。

ここで、論理管理情報取得設定５１とは、論理管理情報５２を取得するために必要な情報であり、例えば、大規模分散ファイルシステム２０のマスター機能２２に接続するため、マスター機能２２が稼動しているマシン２１のＩＰアドレスやマスター機能２２から必要な情報を取り出すための設定等である。例えば、取得のタイミングや具体的な取得方法（問い合わせによる取得やイベントによる通知、マスター機能２２がエージェント機能を有していれば、当該機能による定期的な報告等）を設定する。

また、物理管理情報取得設定５３とは、物理管理情報５４を取得するために必要な情報であり、例えば、ワーカー機能４１−１〜４１−ｎが稼動している個々のサーバマシン４０−１〜４０−ｎやスイッチ３０−１，３０−２のＩＰアドレスや必要な情報を取り出すための設定等である。例えば、取得のタイミングや具体的な取得方法（問い合わせによる取得やイベントによる通知、ワーカー機能４１−１〜４１−ｎがエージェント機能を有していれば、当該機能による定期的な報告等）を設定する。

また、論理物理管理情報対応付け設定５５とは、論理管理情報５２と物理管理情報５４とを対応付けるための設定である。例えば、個々のサーバマシン４０−１〜４０−ｎのＩＰアドレスや、大容量ファイル２３ａ〜２３ｚのチャンクＩＤ等が対応付けるためのキーとなる。

また、オペレータは、ユーザインタフェース部１８を介して、大規模分散ファイルシステム２０の状態について通知を受けるための通知閾値５７を設定する。例えば、故障したレプリカの数、マシンの数や特定のファイルの破損等を通知閾値５７として設定する。これにより、オペレータは、その後、大規模分散ファイルシステム２０の状態と通知閾値５７とに基づいた通知をユーザインタフェース部１８を介して受け取る。

このような設定が行われた後、論理管理情報取得部１１は、予め設定されている論理管理情報取得設定５１を参照し、大規模分散ファイルシステム２０のマスター機能２２に問い合せることで、論理管理情報５２を取得する。取得される論理管理情報５２としては、大規模分散ファイルシステム２０における論理的な大容量ファイル２３ａ，２３ｂに関する情報であり、例えば、ファイル名、ファイルの容量、最終更新日等がある。

また、物理管理情報取得部１２は、予め設定されている物理管理情報取得設定５３を参照し、ワーカー機能４１−１〜４１−ｎが稼動しているサーバマシン４０−１〜４０−ｎ及び各スイッチ３０−１，３０−２の構成管理機能３１−１，３１−２と監視機能３２−１，３２−２に問い合せることで、物理管理情報５４を取得する。取得される物理管理情報５４としては、大規模分散ファイルシステム２０を構成する個々のサーバマシン４０−１〜４０−ｎとネットワークの利用状況であり、例えば、サーバマシン４０−１〜４０−ｎの名称、ＣＰＵ使用率、物理的なディスク４２−１〜４２−ｎの名称、ディスク使用量、メモリ使用量等と個々のスイッチ等の物理構成、トラフィック量、パケットロス等がある。

そして、論理物理管理情報対応付け部１４は、予め設定されている論理物理管理情報対応付け設定５５を参照し、論理管理情報５２と物理管理情報５４との対応付けを行い、論理物理管理情報５６を作成する。

また、通知閾値判定部１５は、予め設定されている通知閾値５７に基づき、大規模分散ファイルシステム２０の状態を確認し、オペレータに対して通知をすべき状態かの判定を行う。

以下に、上述した分散ファイル管理装置１０における処理手順について説明する。

図３は、図１に示した分散ファイル管理装置１０における処理手順の概要動作を示すフローチャートである。

図１に示した分散ファイル管理装置１０を起動すると（ステップ１）、まず、設定フェーズにおける処理が行われ（ステップ２）、次に、管理情報取得・通知フェーズにおける処理が行われる（ステップ３）。

その後、設定変更を行う場合は、ステップ２の設定フェーズに戻る（ステップ４）。

また、処理が終了した場合（ステップ５）、分散ファイル管理装置１０を停止させる（ステップ６）。

図４は、図３に示した設定フェーズの手順を示すフローチャートである。

設定フェーズでは、論理管理情報５２を取得するために必要な情報がユーザインタフェース部１８を介して入力されることにより、論理管理情報取得設定５１を設定する（ステップ２１）。

また、物理管理情報５４を取得するために必要な情報がユーザインタフェース部１８を介して入力されることにより、物理管理情報取得設定５３を設定する（ステップ２２）。

また、論理管理情報５２と物理管理情報５４とを対応付けるための設定がユーザインタフェース部１８を介して入力されることにより、論理物理管理情報対応付け設定５５を設定する（ステップ２３）。例えば、個々のサーバマシン４０−１〜４０−ｎのＩＰアドレスや、大容量ファイル２３ａ〜２３ｚのチャンクＩＤ等が対応付けるためのキーとし、大容量ファイル２３ａ〜２３ｚのチャンクＩＤによって識別されるデータがどのサーバマシン４０−１〜４０−ｎに分散されるかを設定する。

また、大規模分散ファイルシステム２０の状態について通知を受けるための情報がユーザインタフェース部１８を介して入力されることにより通知閾値５７を設定する。

なお、これらの処理は、オペレータがユーザインタフェース部１８を介して情報を入力して設定する代わりに、大規模分散ファイルシステム２０のマスター機能２２やワーカー機能４１−１〜４１−ｎが、それぞれの管理情報を返却する機構を有していれば、その機能を利用して自動的に設定しても良い。

図５は、図３に示した管理情報取得・通知フェーズの手順を示すフローチャートである。

管理情報取得・通知フェーズでは、まず、論理管理情報取得部１１にて論理管理情報を取得する（ステップ３１）。取得に必要な設定については、予め設定フェーズで設定した管理情報記憶部１６内の論理管理情報取得設定５１（マスター機能２２が稼働しているマシン２０のＩＰアドレス、取得方法やタイミング等）を参照する。取得方法は、マスター機能２２に問い合せて結果を取得する方法や、マスター機能２２からのイベント通知を取得する方法、また、マスター機能２２がエージェント機能を有していれば、その機能による定期的な報告等がある。

そして、取得した論理管理情報を管理情報記憶部１６に書き込む（ステップ３２）。

同様に、物理管理情報取得部１２にて物理管理情報を取得する（ステップ３３）。取得に必要な設定については、予め設定フェーズで設定した管理情報記憶部１６内の物理管理情報取得設定５３（ワーカー機能４１−１〜４１−ｎが稼働しているサーバマシン４０−１〜４０−ｎのＩＰアドレス、取得方法やタイミング等）を参照する。取得方法は、ワーカー機能４１−１〜４１−ｎに問い合せて結果を取得する方法や、ワーカー機能４１−１〜４１−ｎからのイベント通知を取得する方法、また、ワーカー機能４１−１〜４１−ｎがエージェント機能を有していれば、その機能による定期的な報告等がある。例えば、故障の通知にはイベント通知やエージェント機能が向いている。

そして、取得した物理管理情報を管理情報記憶部１６に書き込む（ステップ３４）。

続いて、管理情報記憶部１６に書き込まれた論理管理情報５２と物理管理情報５４との対応付けを行う（ステップ３５）。対応付けに必要な設定については、管理情報記憶部１６内の論理物理管理情報対応付け設定５５を参照する。例えば、上述したように、論理物理管理情報対応付け設定５５において、個々のサーバマシン４０−１〜４０−ｎのＩＰアドレスや、大容量ファイル２３ａ〜２３ｚのチャンクＩＤ等が対応付けるためのキーとし、大容量ファイル２３ａ〜２３ｚのチャンクＩＤによって識別されるデータがどのサーバマシン４０−１〜４０−ｎに分散されるかが設定されている場合は、これらをキーとして、大容量ファイル２３ａ〜２３ｚについての論理管理情報と、この大容量ファイル２３ａ，２３ｂの分散データが実際に書き込まれたサーバマシン４０−１〜４０−ｎの物理管理情報とを対応付ける。

そして、対応付けた論理物理管理情報を管理情報記憶部１６に書き込む（ステップ３６）。

その後、通知閾値判定部１５において、管理情報記憶部１６に書き込まれた論理管理情報５２、物理管理情報５４及び論理物理管理情報５６と、通知閾値５７とに基づいて、通知を行うかどうかを判定し（ステップ３７）、通知が必要であれば、ユーザインタフェース部１８を介して、オペレータに大規模分散ファイルシステム２０の状態を通知する（ステップ３８）。

ここで、上述した処理を具体的に説明する。

図６は、図１に示した分散ファイル管理装置１０における処理手順の具体例を示す図であり、（ａ）は通常時の処理手順を示す図、（ｂ）はサーバマシンの故障時の処理手順を示す図である。

通常時は、論理管理情報取得部１１において、論理的な大容量ファイル２３ａ〜２３ｚについての管理情報をマスター機能２２に問い合せて取得し（ステップ４１）、また、物理管理情報取得部１２において、個々のサーバマシン４０−１〜４０−ｎの物理的なディスク４２−１〜４２−ｎについての管理情報を、サーバマシン４０−１〜４０−ｎ個々のワーカー機能４１−１〜４１−ｎに問い合せて取得する（ステップ４２）。

そして、論理物理管理部１３において、取得した論理管理情報と物理管理情報を対応付けて管理情報記憶部１６に書き込む（ステップ４３）。この処理を、常時、最新状態の情報を管理できるように繰り返す。マスター機能２２やワーカー機能４１−１〜４１−ｎからの各管理情報の取得については、予め設定した取得のタイミングや取得方法（問い合わせによる取得やイベントによる通知、エージェント機能による定期的な報告等）に基づいて、制御部１７が制御する。

故障時は、論理管理情報取得部１１において、論理的な大容量ファイル２３ａ〜２３ｚについての管理情報を取得し（ステップ４４）、また、故障が生じたサーバマシンのワーカー機能からの故障通知を物理管理情報として取得すると（ステップ４５）、管理情報記憶部１６の内容を読み出し、通知閾値判定部１５において、通知閾値５７に基づいて故障通知を行うかどうかを判定し（ステップ４６）、ユーザインタフェース部１８を介してオペレータに対して故障を通知する（ステップ４７）。

図７は、図１に示した分散ファイル管理装置１０における処理手順の具体例を示す図であり、（ａ）は通常時の処理手順を示す図、（ｂ）はサーバマシンの故障時の処理手順を示す図である。

通常時は、論理管理情報取得部１１において、論理的な大容量ファイル２３ａ〜２３ｚについての管理情報をマスター機能２２に問い合せて取得し（ステップ５１）、また、物理管理情報取得部１２において、個々のサーバマシン４０−１〜４０−ｎの物理的なディスク４２−１〜４２−ｎについての管理情報を、サーバマシン４０−１〜４０−ｎ個々のワーカー機能４１−１〜４１−ｎに問い合せて取得するとともに、ネットワークの管理情報について、個々のスイッチ３０−１，３０−２の構成管理機能３１−１，３１−２や監視機能３２−１，３２−２に問い合せて取得する（ステップ５２）。

そして、論理物理管理部１３において、取得した論理管理情報と物理管理情報を対応付けて、時刻印とともに管理情報記憶部１６に書き込む（ステップ５３）。この処理を、常時、最新状態の情報及び過去の情報を管理できるように繰り返す。マスター機能２２やワーカー機能４１−１〜４１−ｎからの各管理情報の取得については、予め設定した取得のタイミングや取得方法（問い合わせによる取得やイベントによる通知、エージェント機能による定期的な報告等）に基づいて、制御部１７が制御する。

故障時は、論理管理情報取得部１１において、論理的な大容量ファイル２３ａ〜２３ｚについての管理情報を取得し（ステップ５４）、また、故障が生じたスイッチの監視機能からの故障通知を物理管理情報として取得すると（ステップ５５）、管理情報記憶部１６の内容を読み出し、通知閾値判定部１５において、通知閾値５７に基づいて故障通知を行うかどうかを判定し（ステップ５６）、ユーザインタフェース部１８を介してオペレータに対して故障を通知する（ステップ５７）。

以下に、上述した処理手順の詳細を、管理情報記憶部１６内の論理管理情報５２、物理管理情報５３及び論理物理管理情報５６の例を用いて具体的に説明する。

図８は、図２に示した論理物理管理情報５６の一例を示す図である。

大規模分散ファイルシステム２０として、図８に示すように、論理的な大容量ファイルが特定の大きさ（例えば、６４ＭＢｙｔｅ）を１つのブロックとする複数のチャンクに分割され、個々のチャンクが、通常３つのサーバマシンの物理ディスクにコピーされて保管されているとする。本形態では、分散ファイル管理装置１０の論理物理管理部１３が、どのファイルがいくつのチャンクで構成されるか、どのサーバマシンがどのチャンクのコピー（レプリカと称する）を持っているか、等の情報を管理情報記憶部１６で管理する。

図９は、図１に示したサーバマシンがダウンした際の論理物理管理情報５６の一例を示す図である。

通常の運用時は、論理的な大容量ファイル−ａを構成する各チャンクのレプリカが３つ、正常状態（ｕｐ）である。そして、図９に示すように、あるサーバマシン―３の物理的なディスク−×３が故障（ｄｏｗｎ）したとする。

すると、サーバマシン−３のワーカー機能は、分散ファイル管理装置１０に対して、物理的なディスクの故障を通知する。分散ファイル管理装置１０の論理物理管理部１３は、論理物理管理情報５６（レプリカの管理）より、対応する論理的な大容量ファイル−ａを特定し、ユーザインタフェース部１８を介してオペレータに対して故障の旨を通知する。なお、論理物理管理部１３においては、通知閾値５７により、故障したレプリカの数が所定数以上となった場合にオペレータに通知することや、故障したレプリカの数（例えば、３つのレプリカのうち、２つが故障）等に応じて、オペレータへの故障通知の内容を変えることもできる。例えば、信号表示の色を青・黄・赤と変えたり、重要なお客さまの論理的な大容量ファイルのレプリカが１つになったらアラームを上げたりする等が考えられる。

図１０は、故障したサーバマシンが回復した際の論理物理管理情報５６の一例を示す図である。

上述した故障に対して、サーバマシンや物理的なディスクの交換や、大規模分散ファイルシステム自体のレプリカの再配置処理により、リカバリが完了したとする（本例では、サーバマシン−３５の物理ディスク−×２３にレプリカがコピーされ、状態がｒｅｃｏｖｅｒｙになったとする）。

すると、リカバリが完了したサーバマシンのワーカー機能は、分散ファイル管理装置１０に対して、物理的なディスクの復旧を通知する。分散ファイル管理装置１０の論理物理管理部１３は、論理物理管理情報５６（レプリカの管理）より、対応する論理的な大容量ファイルを特定し（本例は、論理的な大容量ファイル−ａ）、ユーザインタフェース部１８を介してオペレータに対して復旧の旨を通知する。

図１１は、図２に示した論理物理管理情報５６の一例を示す図である。

本例においては、図１１に示すように、論理物理管理情報５６として、物理サーバ、物理ディスク等と、論理的な大容量ファイル、チャンク等との対応を管理する。この論理物理管理情報５６により、大規模分散ファイルシステム１０を構成する多数のサーバマシンについて、サーバマシン毎に、論理的な大容量ファイルの持ち分や、使用容量の片寄り（本例では、サーバマシン−１に対してサーバマシン−２の物理ディスクの使用に片寄り）等を管理することができる。

図１２は、図２に示した論理物理管理情報５６の一例を示す図である。

本例においては、図１２に示すように、論理物理管理情報５６として、スイッチ、物理サーバ等と、論理的な大容量ファイル、チャンク等との対応を管理する。この論理物理管理情報５６により、スイッチが故障した際に接続できなくなるチャンクが存在するか否かが判定可能となる。

図１３は、図１に示した大規模分散ファイルシステム２０にてチャンクのレプリカの集中が生じた状態を示す図であり、（ａ）はサーバマシンの故障前の状態を示す図、（ｂ）はサーバマシンの故障後の図１２に示した状態を示す図である。

大規模分散ファイルシステムにおいては、通常は、スイッチの故障に対する耐故障性を高めるため、チャンクのレプリカが異なるスイッチ配下に配置される配置戦略をとることが一般的である。ただし、図１３（ａ）に示す大規模分散ファイルシステム２０にてサーバマシン４に故障が生じたり、サーバマシン４を交換するために停止したりした場合、リペアが発生し、図１３（ｂ）に示すように、１つのスイッチ−１の配下に、あるチャンクのレプリカが全て集中してしまう可能性がある。そのため、スイッチ−１が故障すると、チャンク１を取得できなくなってしまう。

そこで、本形態のような構成とすることにより、１つのスイッチの配下にあるチャンクのレプリカが全て集中してしまうことを回避することができる。

図１４は、図２に示した論理物理管理情報５６の一例を示す図である。

本例においては、図１４に示すように、論理物理管理情報５６として、スイッチ、トラフィック、物理サーバ、物理ディスクとそのアクセス履歴等と、論理的な大容量ファイル、チャンクとそのアクセス履歴等との対応を管理する。この論理物理管理情報５６により、物理的なトラフィックやアクセス履歴と論理的なアクセス履歴とを統合的に監視すること可能となり、増減設の計画などの構成管理が容易となる。

図１５は、図２に示した論理物理管理情報５６の一例を示す図である。

本例においては、図１５に示すように、論理物理管理情報５６として、物理マシン、仮想マシンと、論理的な大容量ファイル、チャンク等との対応を管理する。本例は、図１２及び図１３における説明において、スイッチと当該スイッチに接続する物理サーバの管理を行うと同様に、物理マシンと当該物理マシンで動作する仮想マシンの管理を行うことで実現されるシステムの管理方法である。この論理物理管理情報５６により、物理マシンが故障した際に接続できなくなるチャンクが存在するか否かが判定可能となる。

図１６は、図１に示した大規模分散ファイルシステム２０にて仮想サーバを用いた場合の仮想マシンとチャンクのレプリカ配置を示す図であり、（ａ）は仮想マシンの故障前の状態を示す図、（ｂ）は仮想マシンの故障後の図１５に示した状態を示す図である。

大規模分散ファイルシステムにおいては、通常は、サーバの故障に対するシステムとしての耐故障性を高めるため、チャンクのレプリカが異なるサーバ配下に配置される配置戦略をとることが一般的である。ただし、図１６（ａ）に示す大規模分散ファイルシステム２０にて仮想マシン−４に故障が生じたり、仮想マシン−４を交換するために停止したりした場合、リペアが発生し、図１６（ｂ）に示すように、特定のマシン−１の配下に、あるチャンクのレプリカが全て集中してしまう可能性がある。そのため、故障発生時の処理で、同一物理マシンにチャンクを配置した場合、すなわち、仮想マシン−４で管理していたチャンク１を仮想マシン−２に配置した場合、マシン−１が故障するとチャンク１を取得できなくなってしまう。

そこで、本形態のように、物理マシンと仮想マシンの対応を論理物理管理情報５６として管理しておけば、この論理物理管理情報５６から同一物理マシンにチャンク１が偏ることが分かるので、別の物理マシンの配下の仮想マシンにチャンク１を配置する判断が可能になる。

このように、本形態においては、故障時にデータ（論理情報）が失われてしまう可能性の高い箇所（物理情報）の検出やトラフィックが集中している箇所（論理・物理）の検出が容易となる。

１０ 分散ファイル管理装置
１１ 論理管理情報取得部
１２ 物理管理情報取得部
１３ 論理物理管理部
１４ 論理物理管理情報対応付け部
１５ 通知閾値判定部
１６ 管理情報記憶部
１７ 制御部
１８ ユーザインタフェース部
２０ 大規模分散ファイルシステム
２１ マシン
２２ マスター機能
２３ａ，２３ｂ 論理的な大容量ファイル
３０−１，３０−２ スイッチ
３１−１，３１−２ 構成管理機能
３２−１，３２−２ 監視機能
４０−１〜４０−ｎ サーバマシン
４１−１〜４１−ｎ ワーカー機能
４２−１〜４２−ｎ 物理的なディスク
５１ 論理管理情報取得設定
５２ 論理管理情報
５３ 物理管理情報取得設定
５４ 物理管理情報
５５ 論理物理管理情報対応付け設定
５６ 論理物理管理情報
５７ 通知閾値

Claims (8)

1. 大容量ファイルを論理的に構成、制御するマスター機能と、前記大容量ファイルが分散したデータを書き込まれた複数のサーバマシン毎に、当該サーバマシンへのデータの物理的な書き込み／読み出しを制御するワーカー機能とを有するネットワークにて、前記大容量ファイルと該大容量ファイルが分散したデータとを管理する分散ファイル管理装置であって、
   大容量ファイルについての管理情報を前記マスター機能から取得する論理管理情報取得部と、
   前記複数のサーバマシンに書き込まれたデータについての管理情報を前記ワーカー機能から取得する物理管理情報取得部と、
   指定された設定に基づいて、前記論理管理情報取得部にて取得された大容量ファイルについての管理情報と、前記物理管理情報取得部にて取得されたデータについての管理情報とを対応づけて論理物理情報として記憶する論理物理管理部とを有する分散ファイル管理装置。
2. 請求項１に記載の分散ファイル管理装置において、
   前記論理物理管理部は、
   前記物理管理情報取得部にて取得されたデータについての管理情報が予め決められた条件を満たしているかどうかを判定する通知閾値判定部と、
   前記通知閾値判定部にて、前記物理管理情報取得部にて取得されたデータについての管理情報が前記条件を満たしていると判定された場合に、その旨をユーザに通知するユーザ通知部とを有する分散ファイル管理装置。
3. 請求項２に記載の分散ファイル管理装置において、
   前記ユーザ通知部は、前記条件を満たしていると判定された管理情報に対応づけられた大容量ファイルについての管理情報をユーザに通知する分散ファイル管理装置。
4. 請求項１乃至３のいずれか１項に記載の分散ファイル管理装置において、
   前記物理管理情報取得部は、前記サーバマシンが接続されたネットワークについての管理情報を取得し、
   前記論理物理管理部は、指定された設定に基づいて、前記論理管理情報取得部にて取得された大容量ファイルについての管理情報と、前記物理管理情報取得部にて取得されたデータについての管理情報及びネットワークについての管理情報とを対応づけて論理物理情報として記憶する分散ファイル管理装置。
5. 大容量ファイルを論理的に構成、制御するマスター機能と、前記大容量ファイルが分散したデータを書き込まれた複数のサーバマシン毎に、当該サーバマシンへのデータの物理的な書き込み／読み出しを制御するワーカー機能とを有するネットワークにて、前記大容量ファイルと該大容量ファイルが分散したデータとを管理する分散ファイル管理方法であって、
   大容量ファイルについての管理情報を前記マスター機能から取得する論理管理情報取得処理と、
   前記複数のサーバマシンに書き込まれたデータについての管理情報を前記ワーカー機能から取得する物理管理情報取得処理と、
   指定された設定に基づいて、前記論理管理情報取得処理にて取得された大容量ファイルについての管理情報と、前記物理管理情報取得処理にて取得されたデータについての管理情報とを対応づけて論理物理情報として記憶する論理物理管理処理とを有する分散ファイル管理方法。
6. 請求項５に記載の分散ファイル管理方法において、
   前記物理管理情報取得処理にて取得されたデータについての管理情報が予め決められた条件を満たしているかどうかを判定する通知閾値判定処理と、
   前記通知閾値判定処理にて、前記物理管理情報取得処理にて取得されたデータについての管理情報が前記条件を満たしていると判定された場合に、その旨をユーザに通知するユーザ通知処理とを有する分散ファイル管理方法。
7. 大容量ファイルを論理的に構成、制御するマスター機能と、前記大容量ファイルが分散したデータを書き込まれた複数のサーバマシン毎に、当該サーバマシンへのデータの物理的な書き込み／読み出しを制御するワーカー機能とを有するネットワークにて、前記大容量ファイルと該大容量ファイルが分散したデータとを管理するコンピュータに、
   大容量ファイルについての管理情報を前記マスター機能から取得する論理管理情報取得手順と、
   前記複数のサーバマシンに書き込まれたデータについての管理情報を前記ワーカー機能から取得する物理管理情報取得手順と、
   指定された設定に基づいて、前記論理管理情報取得手順にて取得された大容量ファイルについての管理情報と、前記物理管理情報取得手順にて取得されたデータについての管理情報とを対応づけて論理物理情報として記憶する論理物理管理手順とを実行させるプログラム。
8. 請求項７に記載のプログラムにおいて、
   前記コンピュータに、
   前記物理管理情報取得手順にて取得されたデータについての管理情報が予め決められた条件を満たしているかどうかを判定する通知閾値判定手順と、
   前記通知閾値判定手順にて、前記物理管理情報取得手順にて取得されたデータについての管理情報が前記条件を満たしていると判定された場合に、その旨をユーザに通知するユーザ通知手順とを実行させるプログラム。

Images