サーバシステム
【課題】分散サーバシステムにおいて、システムを構成する各ノードに対して状況変化に応じた制御を行うことで効率的な稼働を可能にする。
【解決手段】複数のノード２０を有してネットワークを構成するサーバシステムにおいて、前記ネットワークに対して前記ノードの稼働状態を管理し制御する監視ノード１０を設置し、監視ノード１０は、各ノードから稼働状態に関連するパラメータを定期的に取得するノードパラメータ受信部１１と、各パラメータの値に応じてノードやシステムを対象とした制御の有無を判断する要制御パラメータ判断部１３と、予め記憶された制御リストに応じて各パラメータに対応するノード制御やシステム制御を決定するパラメータ実施制御決定部１４と、制御が必要なノードやシステムへ制御信号を送信する制御送信部１５を備える。
【解決手段】複数のノード２０を有してネットワークを構成するサーバシステムにおいて、前記ネットワークに対して前記ノードの稼働状態を管理し制御する監視ノード１０を設置し、監視ノード１０は、各ノードから稼働状態に関連するパラメータを定期的に取得するノードパラメータ受信部１１と、各パラメータの値に応じてノードやシステムを対象とした制御の有無を判断する要制御パラメータ判断部１３と、予め記憶された制御リストに応じて各パラメータに対応するノード制御やシステム制御を決定するパラメータ実施制御決定部１４と、制御が必要なノードやシステムへ制御信号を送信する制御送信部１５を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを構成する複数のノードに対して、状況変化に応じた制御を行うことで各ノードの効率的な稼働を可能にしたサーバシステムに関する。
【背景技術】
【０００２】
この種の技術としては、非特許文献１や非特許文献２で示されるように、複数のマシンのディスクを組み合わせて１つのファイルシステムとして機能する分散サーバシステムが提案されている。
非特許文献１に示されたGfarmは、広域ネットワーク上で、大容量、大規模データ処理の要求に応えるスケーラブルな分散ファイルシステムプラットフォームであり、広域なネットワーク上での効率的なファイル共有に適した分散プラットフォームである。
一方、非特許文献２に示されたHadoopは、１つのディスクで保存できない大量のデータを並列化することで高速かつ効率良く処理できるものであり、比較的大きなサイズかつ基本的に更新されることのないファイルのI/Oに適した分散プラットフォームである。
【０００３】
また、非特許文献３のDRDBには、一方のデータを他方にコピーする技術が開示されている。DRDBは、Linux-HAと呼ばれる高い可用性をもつシステムを構成するために必要な１要素であり、２台以上のサーバ間で定期的に通信を行い、稼働しているサーバの情報を稼働サーバの代替サーバへ複製し、稼働しているサーバに故障が発生した場合に代替サーバへ切り替えてシステムとして継続して利用できる仕組みである。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】URL：http://datafarm.apgrid.org/index.ja.html
【非特許文献２】URL：http://hadoop.apache.org/
【非特許文献３】URL：http://www.drbd.org/ja/home/what-is-drbd/
【非特許文献４】URL：http://www.linux-ha.org/wiki/main_Page
【発明の概要】
【発明が解決しようとする課題】
【０００５】
分散サーバシステムでは、ノードが故障した時に当該ノードをシステムから切り離すことでシステムが継続利用でき、高性能なサーバを用意することなく負荷分散やデータ分散を行うことによりシステム全体で高い性能を保持することが行われている。
すなわち、分散サーバシステムの制御において、特定のノードがダウンするとシステム全体へ影響するような重要なノードに対しては、予備系統を用意し故障時に切り替えることでシステムとして継続可能になるよう制御するシステムが存在する。その一方、ダウンしてもシステムの動作へ影響しないノードに関しては、予備系統を用意せず故障時にシステムから切り離すことが行われるが、ノードの稼働数が減ることによりシステム能力低下への影響が懸念される。また、規模の増大による故障台数の増加に伴い定型業務を含む故障対応が煩雑になる。
したがって、既存の分散サーバシステムでは、処理やデータの分散を行いかつ可用性を高めるために複数台のノードが稼働する場合に、システムを構成するノードが過少とならないよう過剰に稼働させることが行われていた。
【０００６】
本発明は上記実情に鑑みて提案されたもので、システムを構成する各ノード（サーバ）に対して状況変化に応じた制御を行うことで効率的な稼働を可能にするサーバシステムを提供することを目的としている。
【課題を解決するための手段】
【０００７】
上記目的を達成するため本発明は、サーバシステムに監視ノードを設置し、サーバシステムを構成する全ノードから定期的にパラメータ（例えばＣＰＵ使用率）を取得し監視するものである。
すなわち、請求項１の発明は、複数のノードを分散配置してネットワークを構成するサーバシステムにおいて、前記ネットワークに対して前記ノードの稼働状態を管理し制御する監視ノードを設置し、前記監視ノードは、次の構成を含むことを特徴としている。
ノードパラメータ受信部。このノードパラメータ受信部は、前記各ノードから稼働状態に関連するパラメータを定期的に取得する。
要制御パラメータ判断部。この要制御パラメータ判断部は、各パラメータの値に応じて前記ノードや前記システムを対象とした制御の有無を判断する。
パラメータ実施制御決定部。このパラメータ実施制御決定部は、予め記憶された制御リストに応じて各パラメータに対応するノード制御やシステム制御を決定する。
制御送信部。この制御送信部は、制御が必要なノードやシステムへ制御信号を送信する。
【０００８】
請求項２は、請求項１のサーバシステムにおいて、前記制御リストは、一つのパラメータに対して複数の制御方法が設定されることを特徴としている。
【０００９】
請求項３は、請求項２のサーバシステムにおいて、前記各ノードは、前記監視ノードからの制御信号に応じて実行された制御結果を記録する制御結果収集部と、制御結果を前記監視ノードに送信する制御結果送信部と備えるとともに、前記監視ノードは、前記制御結果送信部から送信される制御結果を受信する制御結果受信部を備え、前記パラメータ実施制御決定部は、前記制御結果を受けてノード制御やシステム制御を決定することを特徴としている。
【００１０】
請求項４は、請求項３のサーバシステムにおいて、前記パラメータ実施制御決定部は、一つのパラメータに対して複数の制御方法が存在する場合に、前記制御結果受信部で受信した制御結果に基づき、制御実施により復旧した割合が高い制御方法を選択することを特徴としている。
【発明の効果】
【００１１】
本発明によれば、監視ノードを設置し、ノードパラメータ受信部でパラメータを定期的に取得し、要制御パラメータ判断部で各パラメータの値に応じてノードやシステムを対象とした制御の有無を判断して制御を行うことにより、故障もしくは他の正常なノードと異なる挙動をするノードに対して自動で復旧を行うことができる。
【００１２】
また、システムの使用状況に応じて稼働するノード数を増減することが可能となるため、よりシステムで稼働させるノードの効率化を図ることができる。
【００１３】
更に、既に行った制御結果に基づいて、制御実施により復旧した割合が高い制御が選択されることで、システムにおける最適な稼働状態を確保することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態に係る分散サーバシステムの全体構成を示すモデル図である。
【図２】分散サーバシステムを構成する一つのノードと監視ノードとの接続状態を説明するためのブロック図である。
【図３】分散サーバシステムの監視ノードによる制御処理を説明するフローチャート図である。
【図４】分散サーバシステムの監視ノードによる制御選択処理を説明するフローチャート図である。
【発明を実施するための形態】
【００１５】
本発明を分散サーバシステムに適用した実施形態について、図１及び図２を参照して説明する。
分散サーバシステム１は、図１に示すように、複数のノード２０から構成された各ネットワーク２と、システム全体を管理する一つの管理サーバ３と、分散サーバシステム１外に設置された監視ノード１０により構成されている。管理サーバ３は、複数のノード２０を備えている。
各ネットワーク２に配置された複数のノード２０は、記憶部（ストレージ）を有するファイルサーバであり、このファイルサーバを広域な範囲に分散配置させることで構成されている。この分散サーバシステム１では、各ネットワーク２の各ノード２０に対して管理サーバ３を介してユーザがアクセスすることで、複数のユーザによるファイル書込み要求及びファイル読込み要求が行われ、各ノード２０を意識せず全体が単一のサーバとしてユーザに提供するシステムを構成している。
分散サーバシステム１外に設置された監視ノード１０は、各ノード２０の状態の監視および制御を行うものであり、制御対象となるノード２０（各ネットワーク２及び管理サーバ３を構成するノード）は全て同等に扱われる。
【００１６】
分散サーバシステム１を構成する各ノード２０の稼働状態を管理し制御する監視ノード１０の詳細構成について、図２を参照して説明する。
監視ノード１０は、ノードパラメータ受信部１１と、全ノードパラメータ集計部１２と、要制御パラメータ判断部１３と、パラメータ実施制御決定部１４と、制御送信部１５と、制御結果受信部１６と、制御履歴記憶部１７とを備えて構成され、ノード単体やシステム全体のパラメータを取得し、パラメータに制御が必要か判断し、制御が必要な場合には制御しその結果を受信する。
一方、ノード２０は、パラメータ収集部２１と、パラメータ送信部２２と、制御受信部２３と、制御実行部２４と、制御結果収集部２５と、制御結果送信部２６を備え、監視ノード１０へのパラメータ送信及び制御結果の送信を行う。
【００１７】
すなわち監視ノード１０では、各パラメータの値に応じて制御の要不要の判断や、制御が必要な場合の制御リストを保持しており、パラメータ要制御の判断を実施したのち、制御要と判断した場合は制御リストに従い制御を実施し、ノードやシステムの自動的な復旧処理を行う。制御リストには各パラメータに対応する少なくとも１つの制御（復旧処理）方法が設定されている。また、２つ以上の制御方法が存在する場合は、制御を実施した履歴に基づき、制御を実施し復旧した割合がより高い制御を実施するようになっている。
【００１８】
以下、監視ノード１０を構成する各ブロックについて説明する。
ノードパラメータ受信部１１は、各ノード２０のパラメータ送信部２２から送信されたパラメータを定期的に受信して取得する。ノード２０に関するパラメータは、ノードの稼働状態に関連する情報であり、例えば、ノード２０に関してはＣＰＵ使用率、メモリ使用率、ネットワーク疎通である。
全ノードパラメータ集計部１２では、各ノード２０のパラメータを収集し、システム全体としてのパラメータ値を算出する。システムに関するパラメータしては、例えばロードアベレージとディスク使用率がある。
要制御パラメータ判断部１３は、ノードパラメータ受信部１１で得た各ノード２０の各パラメータ、及び、全ノードパラメータ集計部１２で得たシステム（全ノード）の各パラメータを受信し、各パラメータに対して制御が必要か判断する。具体的には、各パラメータの値が予め設定された閾値（後述する制御基準値）との比較によりノード２０やシステムを対象とした制御の有無を判断する。
【００１９】
パラメータ実施制御決定部１４は、予め記憶された制御リストに応じて各パラメータに対応するノード制御やシステム制御を決定する。また、制御が必要と判断したパラメータに対して、どのような制御を行うかを制御履歴の情報を参照して決定する。
制御送信部１５は、パラメータ実施制御決定部１４で決定した制御方法（復旧処理）について、制御が必要なノードやシステムへ制御信号を送信する。
制御結果受信部１６では、ノード２０に対して行った制御結果を受信する。制御履歴記憶部１７では、制御が必要だと判断したパラメータに対してどのような制御を行い、成功したか失敗したかの履歴を格納する。
【００２０】
次に、ノード２０を構成する各ブロックについて説明する。
パラメータ収集部２１では、ノード２０内部のパラメータを定期的に収集する。
パラメータ送信部２２では、収集したパラメータを監視ノード１０へ送信する。
制御受信部２３では、監視ノード１０からの制御指示を受信する。
制御実行部２４では、監視ノード１０から受信した制御指示の内容を実行することにより、当該ノード２０について自動的な復旧処理が行われる。
制御結果収集部２５では、制御実行部２４で実行した制御によってパラメータが復旧したかの情報を収集する。
制御結果送信部２６では、制御結果収集部２５で収集した制御結果を監視ノード１０へ送信する。
【００２１】
次に、分散サーバシステム１の監視ノード１０による制御処理について、図３のフローチャートを参照して説明する。
先ず、ノードパラメータ受信部１１において、ネットワーク２及び管理サーバ３を構成する各ノード２０から稼働状態に関連するパラメータを収集する（ステップ３１）。
次に、取得したパラメータの値から各パラメータに対して制御が必要な値かを判断し（ステップ３２）、制御が必要な場合は、パラメータ実施制御決定部１４において、各パラメータの制御方法リストの中から最適な制御を選択する（ステップ３３）。
【００２２】
その後、ノード２０に対して制御を実施し（ステップ３４）、結果を受信し（ステップ３５）、制御結果を履歴へ格納する（ステップ３６）。
最後に、制御が成功した場合または、他にノードに対して実施する制御が存在しない場合は、制御終了と判断し（ステップ３７）、必要に応じてシステムの制御を実施する（ステップ３８）。
制御が失敗した場合は、再度制御を選択し、制御リストの制御を全て実施するまで若しくは制御が成功するまで処理を繰り返す。
【００２３】
このフローチャートによる処理は、ノード２０単体の自動制御だけでなく、複数ノード２０から構成されるシステムの自動制御にも用いることができる。ただし、システムが対象となる場合は故障ではなく、システム全体の負荷によって制御の有無を判断する。
【００２４】
続いて、分散サーバシステム１の監視ノード１０による制御選択処理について、図４のフローチャートを参照して説明する。
パラメータ実施制御決定部１４において、制御リストから制御が必要なパラメータに対する制御方法を取得する（ステップ４１）。
次に、同一制御フローで選択した制御方法を取り除き（ステップ４２）、制御成功回数（復旧回数）を制御実施回数で割った値（復旧割合）が最も大きい制御方法を選択する（ステップ４３）。そこで、復旧割合が同じ制御が複数ある場合は（ステップ４４）、復旧回数が最も多い制御方法を選択する（ステップ４５）。
さらに、復旧回数も同一の制御方法が存在する場合は（ステップ４６）、制御実施時刻を比較し、より最近に行った制御方法を選択する（ステップ４７）。復旧割合または復旧回数の選択肢で、１つに絞れた場合はその制御方法を選択する。
最後に、選択した制御を実施する（ステップ４８）。
【００２５】
具体的なパラメータの例及び各パラメータで制御が必要だと判断する値（制御基準値）を表１に示す。本発明のサーバシステムによる制御対象は、ノード２０単体、又は、複数ノード２０から構成されるシステムであるため、それぞれ分けて説明する。
【００２６】
先ず、制御対象がノード単体である場合、パラメータとしては、ＣＰＵ使用率、メモリ使用率、ネットワーク疎通が考えられる。
ＣＰＵ使用率については、１００％を制御基準値とした。ここでの１００％とは、特定のＣＰＵまたはコアでの使用率が１００％になった場合を指す。
メモリ使用率についても、１００％を制御基準値とした。
ネットワーク疎通に関しては、疎通不可を制御判断値とする。ネットワーク疎通に関しては、取り得る値が疎通可と疎通不可の２値しかないため、疎通不可としている。
【００２７】
制御対象がシステムの場合は、パラメータとしては、ロードアベレージとディスク使用率が考えられる。
ロードアベレージに関しては、３以上の値を取るノードが全体の８０％を超える場合にノードの追加を行い、０．１以下のノードが存在する場合にはノードを停止する。
ロードアベレージとは、１つのＣＰＵで処理可能な量を１とした場合のＣＰＵリソースの要求量である。例えば、１分間に１つのプロセスが１つのＣＰＵを占有する場合は「１」となり、２つのプロセスの場合は「２」となる。
【００２８】
【表１】
【００２９】
次に、表１に示した各パラメータに対する制御方法（復旧処理）の具体例を表２に示す。
ＣＰＵ使用率に対しては、（１）最もＣＰＵ使用率が高いプロセスの優先順位を下げる、（２）最も使用率が高いプロセスを停止する、の２種類の対処（制御）の仕方がある。
メモリ使用率に関しては、（１）swap領域を増やす、（２）最も使用率が高いプロセスを再起動する、（３）最も使用率が高いプロセスを停止する、の３種類の対処（制御）の仕方がある。
ネットワーク疎通に関しては、インタフェースの再起動を行う。設定の不備が存在する場合は設定の修正を行う。
【００３０】
ロードアベレージに関しては、ノードの増減を行うため、サーバ（ノード）を新たに起動する、サーバ（ノード）を停止する、の２種類の対処（制御）の仕方がある。
ディスク使用率に関しては、容量の増加でのみ対処可能であるため、サーバ（ノード）を新たに起動する制御のみが行われる。
一つのパラメータに対して複数の対処法（制御方法）がある場合には、上述したように、パラメータ実施制御決定部１４において、過去の制御履歴における復旧割合等を考慮して一の制御方法が決定される。
【００３１】
【表２】
【００３２】
上述したシステムによれば、故障もしくは他の正常なノードと異なる挙動をするノードに対して自動で復旧を試みるため、設定ミスや軽微な故障等の定型的な対処で復旧可能となるため、故障と判断したノードをより早くに再利用することが可能となる。
【００３３】
また、故障ノードに対して人手を介して行う定型的な対処を自動化することにより、再利用できないと判断したノードへ運用者が行う故障原因の特定や対処する作業を低減することが可能になる。
【００３４】
更に、既存の分散ファイルシステムではピーク時のパフォーマンスに最適化したシステム構成を設定し、定期的なノード追加を行う運用が主となる。よって、稼働しているノードの過剰供給となる場合が多く、仮に過少供給となった場合のノード追加には時間を要する。
これに対して上述のシステムによれば、使用状況に応じて稼働するノード数を増減することが可能となるため、よりシステムの稼働状況に最適化したノード数を稼働させることが可能となる。
【００３５】
上述したシステムでは、各ノード２０を意識せず全体が単一のサーバとして処理可能な分散サーバシステムに適用した例について説明したが、複数ノードを備えたシステムであれば適用することができる。
【符号の説明】
【００３６】
１…分散サーバシステム、 ２…ネットワーク、 ３…管理サーバ、 １０…監視ノード、 １１…ノードパラメータ受信部、 １２…全ノードパラメータ集計部、 １３…要制御パラメータ判断部、 １４…パラメータ実施制御決定部、 １５…制御送信部、 １６…制御結果受信部、 １７…制御履歴記憶部、 ２０…ノード、 ２１…パラメータ収集部、 ２２…パラメータ送信部、 ２３…制御受信部、 ２４…制御実行部、 ２５…制御結果収集部、 ２６…制御結果送信部。
【技術分野】
【０００１】
本発明は、ネットワークを構成する複数のノードに対して、状況変化に応じた制御を行うことで各ノードの効率的な稼働を可能にしたサーバシステムに関する。
【背景技術】
【０００２】
この種の技術としては、非特許文献１や非特許文献２で示されるように、複数のマシンのディスクを組み合わせて１つのファイルシステムとして機能する分散サーバシステムが提案されている。
非特許文献１に示されたGfarmは、広域ネットワーク上で、大容量、大規模データ処理の要求に応えるスケーラブルな分散ファイルシステムプラットフォームであり、広域なネットワーク上での効率的なファイル共有に適した分散プラットフォームである。
一方、非特許文献２に示されたHadoopは、１つのディスクで保存できない大量のデータを並列化することで高速かつ効率良く処理できるものであり、比較的大きなサイズかつ基本的に更新されることのないファイルのI/Oに適した分散プラットフォームである。
【０００３】
また、非特許文献３のDRDBには、一方のデータを他方にコピーする技術が開示されている。DRDBは、Linux-HAと呼ばれる高い可用性をもつシステムを構成するために必要な１要素であり、２台以上のサーバ間で定期的に通信を行い、稼働しているサーバの情報を稼働サーバの代替サーバへ複製し、稼働しているサーバに故障が発生した場合に代替サーバへ切り替えてシステムとして継続して利用できる仕組みである。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】URL：http://datafarm.apgrid.org/index.ja.html
【非特許文献２】URL：http://hadoop.apache.org/
【非特許文献３】URL：http://www.drbd.org/ja/home/what-is-drbd/
【非特許文献４】URL：http://www.linux-ha.org/wiki/main_Page
【発明の概要】
【発明が解決しようとする課題】
【０００５】
分散サーバシステムでは、ノードが故障した時に当該ノードをシステムから切り離すことでシステムが継続利用でき、高性能なサーバを用意することなく負荷分散やデータ分散を行うことによりシステム全体で高い性能を保持することが行われている。
すなわち、分散サーバシステムの制御において、特定のノードがダウンするとシステム全体へ影響するような重要なノードに対しては、予備系統を用意し故障時に切り替えることでシステムとして継続可能になるよう制御するシステムが存在する。その一方、ダウンしてもシステムの動作へ影響しないノードに関しては、予備系統を用意せず故障時にシステムから切り離すことが行われるが、ノードの稼働数が減ることによりシステム能力低下への影響が懸念される。また、規模の増大による故障台数の増加に伴い定型業務を含む故障対応が煩雑になる。
したがって、既存の分散サーバシステムでは、処理やデータの分散を行いかつ可用性を高めるために複数台のノードが稼働する場合に、システムを構成するノードが過少とならないよう過剰に稼働させることが行われていた。
【０００６】
本発明は上記実情に鑑みて提案されたもので、システムを構成する各ノード（サーバ）に対して状況変化に応じた制御を行うことで効率的な稼働を可能にするサーバシステムを提供することを目的としている。
【課題を解決するための手段】
【０００７】
上記目的を達成するため本発明は、サーバシステムに監視ノードを設置し、サーバシステムを構成する全ノードから定期的にパラメータ（例えばＣＰＵ使用率）を取得し監視するものである。
すなわち、請求項１の発明は、複数のノードを分散配置してネットワークを構成するサーバシステムにおいて、前記ネットワークに対して前記ノードの稼働状態を管理し制御する監視ノードを設置し、前記監視ノードは、次の構成を含むことを特徴としている。
ノードパラメータ受信部。このノードパラメータ受信部は、前記各ノードから稼働状態に関連するパラメータを定期的に取得する。
要制御パラメータ判断部。この要制御パラメータ判断部は、各パラメータの値に応じて前記ノードや前記システムを対象とした制御の有無を判断する。
パラメータ実施制御決定部。このパラメータ実施制御決定部は、予め記憶された制御リストに応じて各パラメータに対応するノード制御やシステム制御を決定する。
制御送信部。この制御送信部は、制御が必要なノードやシステムへ制御信号を送信する。
【０００８】
請求項２は、請求項１のサーバシステムにおいて、前記制御リストは、一つのパラメータに対して複数の制御方法が設定されることを特徴としている。
【０００９】
請求項３は、請求項２のサーバシステムにおいて、前記各ノードは、前記監視ノードからの制御信号に応じて実行された制御結果を記録する制御結果収集部と、制御結果を前記監視ノードに送信する制御結果送信部と備えるとともに、前記監視ノードは、前記制御結果送信部から送信される制御結果を受信する制御結果受信部を備え、前記パラメータ実施制御決定部は、前記制御結果を受けてノード制御やシステム制御を決定することを特徴としている。
【００１０】
請求項４は、請求項３のサーバシステムにおいて、前記パラメータ実施制御決定部は、一つのパラメータに対して複数の制御方法が存在する場合に、前記制御結果受信部で受信した制御結果に基づき、制御実施により復旧した割合が高い制御方法を選択することを特徴としている。
【発明の効果】
【００１１】
本発明によれば、監視ノードを設置し、ノードパラメータ受信部でパラメータを定期的に取得し、要制御パラメータ判断部で各パラメータの値に応じてノードやシステムを対象とした制御の有無を判断して制御を行うことにより、故障もしくは他の正常なノードと異なる挙動をするノードに対して自動で復旧を行うことができる。
【００１２】
また、システムの使用状況に応じて稼働するノード数を増減することが可能となるため、よりシステムで稼働させるノードの効率化を図ることができる。
【００１３】
更に、既に行った制御結果に基づいて、制御実施により復旧した割合が高い制御が選択されることで、システムにおける最適な稼働状態を確保することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態に係る分散サーバシステムの全体構成を示すモデル図である。
【図２】分散サーバシステムを構成する一つのノードと監視ノードとの接続状態を説明するためのブロック図である。
【図３】分散サーバシステムの監視ノードによる制御処理を説明するフローチャート図である。
【図４】分散サーバシステムの監視ノードによる制御選択処理を説明するフローチャート図である。
【発明を実施するための形態】
【００１５】
本発明を分散サーバシステムに適用した実施形態について、図１及び図２を参照して説明する。
分散サーバシステム１は、図１に示すように、複数のノード２０から構成された各ネットワーク２と、システム全体を管理する一つの管理サーバ３と、分散サーバシステム１外に設置された監視ノード１０により構成されている。管理サーバ３は、複数のノード２０を備えている。
各ネットワーク２に配置された複数のノード２０は、記憶部（ストレージ）を有するファイルサーバであり、このファイルサーバを広域な範囲に分散配置させることで構成されている。この分散サーバシステム１では、各ネットワーク２の各ノード２０に対して管理サーバ３を介してユーザがアクセスすることで、複数のユーザによるファイル書込み要求及びファイル読込み要求が行われ、各ノード２０を意識せず全体が単一のサーバとしてユーザに提供するシステムを構成している。
分散サーバシステム１外に設置された監視ノード１０は、各ノード２０の状態の監視および制御を行うものであり、制御対象となるノード２０（各ネットワーク２及び管理サーバ３を構成するノード）は全て同等に扱われる。
【００１６】
分散サーバシステム１を構成する各ノード２０の稼働状態を管理し制御する監視ノード１０の詳細構成について、図２を参照して説明する。
監視ノード１０は、ノードパラメータ受信部１１と、全ノードパラメータ集計部１２と、要制御パラメータ判断部１３と、パラメータ実施制御決定部１４と、制御送信部１５と、制御結果受信部１６と、制御履歴記憶部１７とを備えて構成され、ノード単体やシステム全体のパラメータを取得し、パラメータに制御が必要か判断し、制御が必要な場合には制御しその結果を受信する。
一方、ノード２０は、パラメータ収集部２１と、パラメータ送信部２２と、制御受信部２３と、制御実行部２４と、制御結果収集部２５と、制御結果送信部２６を備え、監視ノード１０へのパラメータ送信及び制御結果の送信を行う。
【００１７】
すなわち監視ノード１０では、各パラメータの値に応じて制御の要不要の判断や、制御が必要な場合の制御リストを保持しており、パラメータ要制御の判断を実施したのち、制御要と判断した場合は制御リストに従い制御を実施し、ノードやシステムの自動的な復旧処理を行う。制御リストには各パラメータに対応する少なくとも１つの制御（復旧処理）方法が設定されている。また、２つ以上の制御方法が存在する場合は、制御を実施した履歴に基づき、制御を実施し復旧した割合がより高い制御を実施するようになっている。
【００１８】
以下、監視ノード１０を構成する各ブロックについて説明する。
ノードパラメータ受信部１１は、各ノード２０のパラメータ送信部２２から送信されたパラメータを定期的に受信して取得する。ノード２０に関するパラメータは、ノードの稼働状態に関連する情報であり、例えば、ノード２０に関してはＣＰＵ使用率、メモリ使用率、ネットワーク疎通である。
全ノードパラメータ集計部１２では、各ノード２０のパラメータを収集し、システム全体としてのパラメータ値を算出する。システムに関するパラメータしては、例えばロードアベレージとディスク使用率がある。
要制御パラメータ判断部１３は、ノードパラメータ受信部１１で得た各ノード２０の各パラメータ、及び、全ノードパラメータ集計部１２で得たシステム（全ノード）の各パラメータを受信し、各パラメータに対して制御が必要か判断する。具体的には、各パラメータの値が予め設定された閾値（後述する制御基準値）との比較によりノード２０やシステムを対象とした制御の有無を判断する。
【００１９】
パラメータ実施制御決定部１４は、予め記憶された制御リストに応じて各パラメータに対応するノード制御やシステム制御を決定する。また、制御が必要と判断したパラメータに対して、どのような制御を行うかを制御履歴の情報を参照して決定する。
制御送信部１５は、パラメータ実施制御決定部１４で決定した制御方法（復旧処理）について、制御が必要なノードやシステムへ制御信号を送信する。
制御結果受信部１６では、ノード２０に対して行った制御結果を受信する。制御履歴記憶部１７では、制御が必要だと判断したパラメータに対してどのような制御を行い、成功したか失敗したかの履歴を格納する。
【００２０】
次に、ノード２０を構成する各ブロックについて説明する。
パラメータ収集部２１では、ノード２０内部のパラメータを定期的に収集する。
パラメータ送信部２２では、収集したパラメータを監視ノード１０へ送信する。
制御受信部２３では、監視ノード１０からの制御指示を受信する。
制御実行部２４では、監視ノード１０から受信した制御指示の内容を実行することにより、当該ノード２０について自動的な復旧処理が行われる。
制御結果収集部２５では、制御実行部２４で実行した制御によってパラメータが復旧したかの情報を収集する。
制御結果送信部２６では、制御結果収集部２５で収集した制御結果を監視ノード１０へ送信する。
【００２１】
次に、分散サーバシステム１の監視ノード１０による制御処理について、図３のフローチャートを参照して説明する。
先ず、ノードパラメータ受信部１１において、ネットワーク２及び管理サーバ３を構成する各ノード２０から稼働状態に関連するパラメータを収集する（ステップ３１）。
次に、取得したパラメータの値から各パラメータに対して制御が必要な値かを判断し（ステップ３２）、制御が必要な場合は、パラメータ実施制御決定部１４において、各パラメータの制御方法リストの中から最適な制御を選択する（ステップ３３）。
【００２２】
その後、ノード２０に対して制御を実施し（ステップ３４）、結果を受信し（ステップ３５）、制御結果を履歴へ格納する（ステップ３６）。
最後に、制御が成功した場合または、他にノードに対して実施する制御が存在しない場合は、制御終了と判断し（ステップ３７）、必要に応じてシステムの制御を実施する（ステップ３８）。
制御が失敗した場合は、再度制御を選択し、制御リストの制御を全て実施するまで若しくは制御が成功するまで処理を繰り返す。
【００２３】
このフローチャートによる処理は、ノード２０単体の自動制御だけでなく、複数ノード２０から構成されるシステムの自動制御にも用いることができる。ただし、システムが対象となる場合は故障ではなく、システム全体の負荷によって制御の有無を判断する。
【００２４】
続いて、分散サーバシステム１の監視ノード１０による制御選択処理について、図４のフローチャートを参照して説明する。
パラメータ実施制御決定部１４において、制御リストから制御が必要なパラメータに対する制御方法を取得する（ステップ４１）。
次に、同一制御フローで選択した制御方法を取り除き（ステップ４２）、制御成功回数（復旧回数）を制御実施回数で割った値（復旧割合）が最も大きい制御方法を選択する（ステップ４３）。そこで、復旧割合が同じ制御が複数ある場合は（ステップ４４）、復旧回数が最も多い制御方法を選択する（ステップ４５）。
さらに、復旧回数も同一の制御方法が存在する場合は（ステップ４６）、制御実施時刻を比較し、より最近に行った制御方法を選択する（ステップ４７）。復旧割合または復旧回数の選択肢で、１つに絞れた場合はその制御方法を選択する。
最後に、選択した制御を実施する（ステップ４８）。
【００２５】
具体的なパラメータの例及び各パラメータで制御が必要だと判断する値（制御基準値）を表１に示す。本発明のサーバシステムによる制御対象は、ノード２０単体、又は、複数ノード２０から構成されるシステムであるため、それぞれ分けて説明する。
【００２６】
先ず、制御対象がノード単体である場合、パラメータとしては、ＣＰＵ使用率、メモリ使用率、ネットワーク疎通が考えられる。
ＣＰＵ使用率については、１００％を制御基準値とした。ここでの１００％とは、特定のＣＰＵまたはコアでの使用率が１００％になった場合を指す。
メモリ使用率についても、１００％を制御基準値とした。
ネットワーク疎通に関しては、疎通不可を制御判断値とする。ネットワーク疎通に関しては、取り得る値が疎通可と疎通不可の２値しかないため、疎通不可としている。
【００２７】
制御対象がシステムの場合は、パラメータとしては、ロードアベレージとディスク使用率が考えられる。
ロードアベレージに関しては、３以上の値を取るノードが全体の８０％を超える場合にノードの追加を行い、０．１以下のノードが存在する場合にはノードを停止する。
ロードアベレージとは、１つのＣＰＵで処理可能な量を１とした場合のＣＰＵリソースの要求量である。例えば、１分間に１つのプロセスが１つのＣＰＵを占有する場合は「１」となり、２つのプロセスの場合は「２」となる。
【００２８】
【表１】
【００２９】
次に、表１に示した各パラメータに対する制御方法（復旧処理）の具体例を表２に示す。
ＣＰＵ使用率に対しては、（１）最もＣＰＵ使用率が高いプロセスの優先順位を下げる、（２）最も使用率が高いプロセスを停止する、の２種類の対処（制御）の仕方がある。
メモリ使用率に関しては、（１）swap領域を増やす、（２）最も使用率が高いプロセスを再起動する、（３）最も使用率が高いプロセスを停止する、の３種類の対処（制御）の仕方がある。
ネットワーク疎通に関しては、インタフェースの再起動を行う。設定の不備が存在する場合は設定の修正を行う。
【００３０】
ロードアベレージに関しては、ノードの増減を行うため、サーバ（ノード）を新たに起動する、サーバ（ノード）を停止する、の２種類の対処（制御）の仕方がある。
ディスク使用率に関しては、容量の増加でのみ対処可能であるため、サーバ（ノード）を新たに起動する制御のみが行われる。
一つのパラメータに対して複数の対処法（制御方法）がある場合には、上述したように、パラメータ実施制御決定部１４において、過去の制御履歴における復旧割合等を考慮して一の制御方法が決定される。
【００３１】
【表２】
【００３２】
上述したシステムによれば、故障もしくは他の正常なノードと異なる挙動をするノードに対して自動で復旧を試みるため、設定ミスや軽微な故障等の定型的な対処で復旧可能となるため、故障と判断したノードをより早くに再利用することが可能となる。
【００３３】
また、故障ノードに対して人手を介して行う定型的な対処を自動化することにより、再利用できないと判断したノードへ運用者が行う故障原因の特定や対処する作業を低減することが可能になる。
【００３４】
更に、既存の分散ファイルシステムではピーク時のパフォーマンスに最適化したシステム構成を設定し、定期的なノード追加を行う運用が主となる。よって、稼働しているノードの過剰供給となる場合が多く、仮に過少供給となった場合のノード追加には時間を要する。
これに対して上述のシステムによれば、使用状況に応じて稼働するノード数を増減することが可能となるため、よりシステムの稼働状況に最適化したノード数を稼働させることが可能となる。
【００３５】
上述したシステムでは、各ノード２０を意識せず全体が単一のサーバとして処理可能な分散サーバシステムに適用した例について説明したが、複数ノードを備えたシステムであれば適用することができる。
【符号の説明】
【００３６】
１…分散サーバシステム、 ２…ネットワーク、 ３…管理サーバ、 １０…監視ノード、 １１…ノードパラメータ受信部、 １２…全ノードパラメータ集計部、 １３…要制御パラメータ判断部、 １４…パラメータ実施制御決定部、 １５…制御送信部、 １６…制御結果受信部、 １７…制御履歴記憶部、 ２０…ノード、 ２１…パラメータ収集部、 ２２…パラメータ送信部、 ２３…制御受信部、 ２４…制御実行部、 ２５…制御結果収集部、 ２６…制御結果送信部。
【特許請求の範囲】
【請求項１】
複数のノードを有してネットワークを構成するサーバシステムにおいて、
前記ネットワークに対して前記ノードの稼働状態を管理し制御する監視ノードを設置し、
前記監視ノードは、
前記各ノードから稼働状態に関連するパラメータを定期的に取得するノードパラメータ受信部と、
各パラメータの値に応じて前記ノードや前記システムを対象とした制御の有無を判断する要制御パラメータ判断部と、
予め記憶された制御リストに応じて各パラメータに対応するノード制御やシステム制御を決定するパラメータ実施制御決定部と、
制御が必要なノードやシステムへ制御信号を送信する制御送信部と
を備えることを特徴とするサーバシステム。
【請求項２】
前記制御リストは、一つのパラメータに対して複数の制御方法が設定される請求項１に記載のサーバシステム。
【請求項３】
前記各ノードは、前記監視ノードからの制御信号に応じて実行された制御結果を記録する制御結果収集部と、制御結果を前記監視ノードに送信する制御結果送信部と備えるとともに、
前記監視ノードは、前記制御結果送信部から送信される制御結果を受信する制御結果受信部を備え、前記パラメータ実施制御決定部は、前記制御結果を受けてノード制御やシステム制御を決定する請求項２に記載のサーバシステム。
【請求項４】
前記パラメータ実施制御決定部は、一つのパラメータに対して複数の制御方法が存在する場合に、前記制御結果受信部で受信した制御結果に基づき、制御実施により復旧した割合が高い制御方法を選択する請求項３に記載のサーバシステム。
【請求項１】
複数のノードを有してネットワークを構成するサーバシステムにおいて、
前記ネットワークに対して前記ノードの稼働状態を管理し制御する監視ノードを設置し、
前記監視ノードは、
前記各ノードから稼働状態に関連するパラメータを定期的に取得するノードパラメータ受信部と、
各パラメータの値に応じて前記ノードや前記システムを対象とした制御の有無を判断する要制御パラメータ判断部と、
予め記憶された制御リストに応じて各パラメータに対応するノード制御やシステム制御を決定するパラメータ実施制御決定部と、
制御が必要なノードやシステムへ制御信号を送信する制御送信部と
を備えることを特徴とするサーバシステム。
【請求項２】
前記制御リストは、一つのパラメータに対して複数の制御方法が設定される請求項１に記載のサーバシステム。
【請求項３】
前記各ノードは、前記監視ノードからの制御信号に応じて実行された制御結果を記録する制御結果収集部と、制御結果を前記監視ノードに送信する制御結果送信部と備えるとともに、
前記監視ノードは、前記制御結果送信部から送信される制御結果を受信する制御結果受信部を備え、前記パラメータ実施制御決定部は、前記制御結果を受けてノード制御やシステム制御を決定する請求項２に記載のサーバシステム。
【請求項４】
前記パラメータ実施制御決定部は、一つのパラメータに対して複数の制御方法が存在する場合に、前記制御結果受信部で受信した制御結果に基づき、制御実施により復旧した割合が高い制御方法を選択する請求項３に記載のサーバシステム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２０１２−１９０３７８（Ｐ２０１２−１９０３７８Ａ）
【公開日】平成２４年１０月４日（２０１２．１０．４）
【国際特許分類】
【出願番号】特願２０１１−５５０１７（Ｐ２０１１−５５０１７）
【出願日】平成２３年３月１４日（２０１１．３．１４）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【Ｆターム（参考）】
【公開日】平成２４年１０月４日（２０１２．１０．４）
【国際特許分類】
【出願日】平成２３年３月１４日（２０１１．３．１４）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【Ｆターム（参考）】
[ Back to top ]