WO2018056044A1

WO2018056044A1 - 計算機並びにクラスタ管理システム、方法及び非一時的なコンピュータ可読媒体

Info

Publication number: WO2018056044A1
Application number: PCT/JP2017/031876
Authority: WO
Inventors: 佑将奥野; 孝昌大竹
Original assignee: 日本電気株式会社
Priority date: 2016-09-21
Filing date: 2017-09-05
Publication date: 2018-03-29
Also published as: US11119870B2; JPWO2018056044A1; US20190266059A1; JP7006606B2

Abstract

オブジェクトストレージを考慮した稼動状態の相互監視を実現する。本発明にかかる計算機（１０）は、他の計算機（２０）とクラスタを構成する計算機（１０）であって、データをオブジェクト単位で管理するオブジェクトストレージ（３０）に対して、自計算機の正常状態を示す第１の状態情報の格納を要求する格納要求部（１１）と、オブジェクトストレージ（３０）に対して他の計算機（２０）の正常状態を示す第２の状態情報の取得を要求する取得要求部（１２）と、第１の状態情報の格納結果及び第２の状態情報の取得結果に応じて、クラスタ制御を行うクラスタ制御部（１３）と、を備え、取得要求部（１２）は、第２の状態情報の取得結果が最新でなかった場合、所定回数、第２の状態情報の取得を要求する。

Description

計算機並びにクラスタ管理システム、方法及び非一時的なコンピュータ可読媒体

　本発明は計算機並びにクラスタ管理システム、方法及びプログラムに関し、特に稼動状態を相互に監視する計算機並びにクラスタ管理システム、方法及びプログラムに関する。

　システムが提供するサービスの停止時間を短くするために、同一のサービスを提供可能な複数の計算機を有するクラスタシステムが知られている。例えば、特許文献１には、クラスタシステムにおける可用性を向上させる技術が開示されている。

　特許文献１にかかるクラスタシステムは、複数のノードと、２つの生存情報記憶装置と、１つの成否情報記憶装置とを備えるものである。ノードは、正常動作中に、参照先の生存情報記憶装置に自ノードが正常動作中である旨を示す生存情報を記録し、参照先の生存情報記憶装置と生存情報の記録の成否とを示す成否情報を成否情報記憶装置に記録する。各ノードは、成否情報を参照することで、参照先の切替の判定を行う。

特開２００８－２９９３６９号公報

　ここで、特許文献１は、正副の２台の生存情報記憶装置を設けることで、生存情報記憶装置自体をクラスタ構成にし、さらに、１台の成否情報記憶装置を必要とするものである。そのため、成否情報記憶装置がボトルネックとなり得る。そこで、生存情報の格納先としてインターネットを介したオブジェクトストレージを用いることが挙げられる。

　オブジェクトストレージは、ディスク装置の冗長化のために内部的にデータの複製（レプリケーション）を行うことで、ディスク障害時のデータ可用性を担保している。しかしながら、データの複製には一定の時間がかかるため、新しいファイルを書き込んだ直後には、そのファイルが参照できない場合があるという問題点がある。そのため、特許文献１に係る技術を単純にオブジェクトストレージに置き換えることができない。

　本発明は、このような問題点を解決するためになされたものであり、オブジェクトストレージを考慮した稼動状態の相互監視を実現するための計算機並びにクラスタ管理システム、方法及びプログラムを提供することを目的とする。

　本発明の第１の態様にかかる計算機は、
　他の計算機とクラスタを構成する計算機であって、
　データをオブジェクト単位で管理するオブジェクトストレージに対して、自計算機の正常状態を示す第１の状態情報の格納を要求する格納要求部と、
　前記オブジェクトストレージに対して前記他の計算機の正常状態を示す第２の状態情報の取得を要求する取得要求部と、
　前記第１の状態情報の格納結果及び前記第２の状態情報の取得結果に応じて、クラスタ制御を行うクラスタ制御部と、を備え、
　前記取得要求部は、
　前記第２の状態情報の取得結果が最新でなかった場合、所定回数、前記第２の状態情報の取得を要求する。

　本発明の第２の態様にかかるクラスタ管理システムは、
　データをオブジェクト単位で管理するオブジェクトストレージと、
　前記オブジェクトストレージとネットワークを介して通信可能な複数の計算機と、を備え、
　前記複数のサーバのそれぞれは、
　前記オブジェクトストレージに対して自計算機の正常状態を示す第１の状態情報の格納を要求し、
　前記オブジェクトストレージに対して他の計算機の正常状態を示す第２の状態情報の取得を要求し、
　前記第１の状態情報の格納結果及び前記第２の状態情報の取得結果に応じて、クラスタ制御を行い、
　前記第２の状態情報の取得結果が最新でなかった場合、所定回数、前記取得の要求を行う。

　本発明の第３の態様にかかるクラスタ管理方法は、
　データをオブジェクト単位で管理するオブジェクトストレージに対して、自計算機の正常状態を示す第１の状態情報の格納を要求し、
　前記オブジェクトストレージに対して他の計算機の正常状態を示す第２の状態情報の取得を要求し、
　前記第１の状態情報の格納結果及び前記第２の状態情報の取得結果に応じて、クラスタ制御を行い、
　前記第２の状態情報の取得結果が最新でなかった場合、所定回数、前記第２の状態情報の取得を要求する。

　本発明の第４の態様にかかるクラスタ管理プログラムは、
　データをオブジェクト単位で管理するオブジェクトストレージに対して、自計算機の正常状態を示す第１の状態情報の格納を要求する処理と、
　前記オブジェクトストレージに対して他の計算機の正常状態を示す第２の状態情報の取得を要求する処理と、
　前記第１の状態情報の格納結果及び前記第２の状態情報の取得結果に応じて、クラスタ制御を行う処理と、
　前記第２の状態情報の取得結果が最新でなかった場合、所定回数、前記第２の状態情報の取得を要求する処理と、
　をコンピュータに実行させる。

　本発明により、オブジェクトストレージを考慮した稼動状態の相互監視を実現するための計算機並びにクラスタ管理システム、方法及びプログラムを提供することができる。

本発明の実施の形態１にかかるクラスタ管理システムの全体構成を示すブロック図である。本発明の実施の形態１にかかるクラスタ制御処理の流れを示すフローチャートである。本発明の実施の形態２にかかるクラスタ管理システムの構成を示すブロック図である。ハートビート通信処理の流れを示すフローチャートである。タイムアウト時の処理の流れを示すフローチャートである。本発明の実施の形態２にかかるオブジェクトストレージを介したハートビート通信処理（格納）の流れを示すフローチャートである。本発明の実施の形態２にかかる格納要求の例を示す図である。本発明の実施の形態２にかかるハートビート情報ファイルの一覧の例を示す図である。本発明の実施の形態２にかかる削除要求の例を示す図である。本発明の実施の形態２にかかるオブジェクトストレージを介したハートビート通信処理（取得）の流れを示すフローチャートである。本発明の実施の形態２にかかる前回取得した他サーバのハートビート情報ファイルの例を示す図である。本発明の実施の形態２にかかる取得要求の例を示す図である。本発明の実施の形態３にかかるクラスタ管理システムの構成を示すブロック図である。本発明の実施の形態３にかかるハートビート通信経路テーブルの例を示す図である。本発明の実施の形態３にかかるハートビート間隔調整処理の流れを示すフローチャートである。

　以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略する。

＜実施の形態１＞
　図１は、本発明の実施の形態１にかかるクラスタ管理システム１０００の全体構成を示すブロック図である。クラスタ管理システム１０００は、計算機１０と、計算機２０と、オブジェクトストレージ３０と、ネットワーク４０とを備える。ここで、計算機１０、２０及びオブジェクトストレージ３０は、ネットワーク４０により接続されている。つまり、計算機１０及び２０は、ネットワーク４０を介してオブジェクトストレージ３０と通信可能である。尚、計算機は、３台以上であってもよい。

　ネットワーク４０は、例えば、インターネット等の外部に公開された通信ネットワークである。オブジェクトストレージ３０は、データをオブジェクト単位で管理するストレージシステムである。また、オブジェクトストレージ３０は、クラウドサービスとして提供され、各サーバからＡＰＩ（Application Programming Interface）を通じて共通的にアクセスでき、ファイル格納が可能なものである。また、オブジェクトストレージ３０は、ストレージシステム内において冗長化されている。

　計算機１０は、他の計算機２０とクラスタを構成する。計算機１０は、格納要求部１１と、取得要求部１２と、クラスタ制御部１３とを備える。格納要求部１１は、オブジェクトストレージ３０に対して、自計算機１０の正常状態を示す第１の状態情報の格納を要求する。取得要求部１２は、オブジェクトストレージ３０に対して他の計算機２０の正常状態を示す第２の状態情報の取得を要求する。クラスタ制御部１３は、第１の状態情報の格納結果及び第２の状態情報の取得結果に応じて、クラスタ制御を行う。ここで、取得要求部１２は、第２の状態情報の取得結果が最新でなかった場合、所定回数、第２の状態情報の取得を要求する。

　計算機２０は、格納要求部２１と、取得要求部２２と、クラスタ制御部２３とを備える。その他、計算機２０の各構成は、計算機１０と同様であるため、詳細な説明を省略する。

　図２は、本発明の実施の形態１にかかるクラスタ制御処理の流れを示すフローチャートである。まず、格納要求部１１は、オブジェクトストレージ３０に対して、第１の状態情報の格納を要求する（Ｓ１１）。次に、取得要求部１２は、オブジェクトストレージ３０に対して第２の状態情報の取得を要求する（Ｓ１２）。そして、取得要求部１２は、第２の状態情報の取得結果が最新か否かを判定する（Ｓ１３）。第２の状態情報の取得結果が最新でなかった場合（Ｓ１３でＮＯ）取得要求部１２は、取得要求の繰り返しが所定回数であるか否かを判定する（Ｓ１４）。繰り返しが所定回数未満の場合、再度、ステップＳ１２を実行する。一方、ステップＳ１４で繰り返しが所定回数の場合、ステップＳ１５へ進む。

　また、第２の状態情報の取得結果が最新であった場合（Ｓ１３でＹＥＳ）、クラスタ制御部１３は、第１の状態情報の格納結果及び第２の状態情報の取得結果に応じて、クラスタ制御を行う（Ｓ１５）。例えば、第１の状態情報の格納に失敗した場合、計算機１０におけるネットワーク通信に異常が発生している可能性があり、計算機１０が正常なサービスを提供できないおそれがある。そのため、クラスタ制御部１３は、計算機１０を異常状態と判定してクラスタ制御する。また、計算機１０が現在、待機系であり、第２の状態情報の取得結果が最新でない場合、計算機２０が異常状態の可能性があるため、クラスタ制御部１３は、計算機１０を稼働系に切り替える。

　このように本実施の形態では、オブジェクトストレージの冗長化を考慮した稼動状態の相互監視が可能となる。

　ここで、既存のクラスタシステムの場合、ハートビート通信のための通信経路の障害（「ネットワーク・パーティション」）により、クラスタシステムを構成する複数のサーバが孤立すると、当該複数のサーバで同じサービスが開始され、データが破壊されるといった、クラスタとして不整合な状態が発生する。このような状態は、「スプリットブレイン」と呼ばれている。

　そして、ネットワーク・パーティションを解決する（スプリットブレインの発生を抑制する）ための手法のひとつとして、複数のサーバに接続された共有ディスクに対してread/writeを行うことで、相手方サーバがシステムダウンしたのか、それとも通信経路の障害によってハートビート通信が途切れたのかを判断する手法（ディスク・ハートビート）が知られている。

　一方、近年になって仮想的なサーバや計算機用資源をサービスとして利用できる「クラウドホスティングサービス」が様々な企業によって提供されている。このサービスを利用することで、例えば「自社内（オンプレミス）の物理サーバ」と「社外のクラウドホスティングサービスの仮想サーバ」の組み合わせ、あるいは、「北米西海岸にある仮想サーバ」と「北米東海岸にある仮想サーバ」の組み合わせによって、長距離のクラスタシステムを構成することができるようになった。

　上記のように遠隔地にあるサーバから１つの共有ディスクに接続することは、物理的な制約やコストの問題により、現実的ではない。そのため、前述のディスク・ハートビートの手法は、クラスタシステムを構成する複数のサーバが互いに離れた場所に存在する場合には容易に適用できない。

　そこで、本実施の形態１では、オブジェクトストレージ３０を用いることで、ネットワーク・パーティションを解決し、遠隔地に設置されたサーバ同士で相互監視しつつ稼動することが可能となるという効果も奏する。

＜実施の形態２＞
　本実施の形態２は、上述した実施の形態１の具体的な実施例である。
　図３は、本発明の実施の形態２にかかるクラスタ管理システム２０００の構成を示すブロック図である。クラスタ管理システム２０００は、サーバ３００と、サーバ３５０と、オブジェクトストレージ１００と、インターネット２００とを備える。サーバ３００、３５０及びオブジェクトストレージ１００は、インターネット２００を介して接続されている。また、サーバ３００とサーバ３５０とは、ハートビート通信経路４００により接続されている。オブジェクトストレージ１００は、上述したオブジェクトストレージ３０と同様である。インターネット２００は、上述したネットワーク４０の一例である。

　サーバ３００は、クラスタ制御部３０１と、ハートビート通信部３０２と、オブジェクトストレージアクセス部３０３とを備える。クラスタ制御部３０１は、ハートビート通信部３０２を用いて他サーバの死活監視を行い、クラスタを構成する各サーバの状態を把握する。

　ハートビート通信部３０２は、ハートビート通信経路４００を介して他サーバとハートビートを送受信する機能を有する。また、ハートビート通信部３０２は、オブジェクトストレージアクセス部３０３に対して自サーバにおけるハートビート相当の情報をオブジェクトストレージ１００に格納する要求を行う。併せて、ハートビート通信部３０２は、オブジェクトストレージアクセス部３０３に対して他サーバにおけるハートビート相当の情報をオブジェクトストレージ１００から取得する要求を行う。

　オブジェクトストレージアクセス部３０３は、ハートビート通信部３０２からの要求に応じて、自サーバのハートビート情報ファイルを生成し、オブジェクトストレージ１００に対して自サーバのハートビート情報ファイルの格納を要求する。また、ハートビート通信部３０２からの要求に応じて、オブジェクトストレージ１００に格納された他サーバのハートビート情報ファイルの取得を要求する。

　続いて、図４を用いて、通常のハートビート通信処理の流れを説明する。

　（Ｓ００１）サーバ３００のクラスタ制御部３０１は、クラスタ管理システム２０００を構成する他サーバに自サーバの状態を伝えるために、ハートビート通信部３０２に対してハートビートの送信を要求する。
　（Ｓ００２）ハートビート通信部３０２は、ハートビート通信経路４００を通じて、サーバ３５０のハートビート通信部３５２にハートビートを送信する。
　（Ｓ００３）ハートビート通信部３５２は、サーバ３００からハートビートを受信したことを、クラスタ制御部３５１に通知する。
　（Ｓ００４）クラスタ制御部３５１は、ハートビート通信部３５２からのハートビート受信通知に従って、サーバ３００の死活状態を「正常状態」に更新する。
　また、サーバ３５０からサーバ３００に対するハートビートも同じように送信される。

　以上のように動作することで、サーバ３００とサーバ３５０は、ハートビート通信経路４００を通じて、互いのサーバの死活状態を監視できる。

　ここで、ハートビート通信経路４００で断線などの障害が発生し、サーバ３００とサーバ３５０の間で直接ハートビートを送受信することが不可能になったケースを想定する。この場合、他サーバからのハートビートが途絶える。図５を用いて、タイムアウト時の処理の流れを説明する。

　（Ｓ１０１）ハートビート通信部３５２は、サーバ３００からのハートビートを最後に受信してからの経過時間を測定している。そして、ハートビート通信部３５２は経過時間が所定のタイムアウト時間に達しているかどうかを確認する。達している場合はステップＳ１０３へ、そうでない場合はステップＳ１０２へ進む。

　（Ｓ１０２）ハートビート通信部３５２は、所定の時間待機し、再度、ステップＳ１０１へ進んで経過時間を確認する。
　（Ｓ１０３）所定のタイムアウト時間に達したため、ハートビート通信部３５２は、サーバ３００からのハートビートを受信できない状態であることをクラスタ制御部３５１に通知する。

　（Ｓ１０４）クラスタ制御部３５１は、サーバ３００の死活状態を「異常状態」に更新する。
　サーバ３００がサーバ３５０からのハートビートを待ち、タイムアウト時間に達した場合の動作も同様である。

　次に、本発明の実施の形態２にかかるオブジェクトストレージを介したハートビート通信処理（格納）を、図６を用いて説明する。尚、サーバ３５０によるオブジェクトストレージを介したハートビート通信処理（格納）も同様である。

　（Ｓ２０１）サーバ３００のクラスタ制御部３０１は、クラスタ管理システム２０００を構成する他サーバに自サーバの状態を伝えるために、ハートビート通信部３０２に対してハートビートの送信を要求する。
　（Ｓ２０２）ハートビート通信部３０２は、オブジェクトストレージアクセス部３０３に対して、ハートビート情報ファイル（詳細は後述）をオブジェクトストレージ１００に格納するよう要求する。

　（Ｓ２０３）オブジェクトストレージアクセス部３０３は、オブジェクトストレージ１００にハートビート情報ファイルを格納する要求を行う。ここで、ハートビート情報ファイルとは、「ハートビート情報ファイルの生成時刻」「サーバが所属するタイムゾーン」「サーバの状態」といった情報を持つデータである。以下では、実装例としてＪＳＯＮ（JavaScript（登録商標） Object Notation）のデータ構造で表記しているが、他のデータ構造（例えばＸＭＬ（Extensible Markup Language）やＹＡＭＬ（YAML Ain’t Markup Language）など）であってもよい。オブジェクトストレージにハートビート情報ファイルを格納するために、オブジェクトストレージアクセス部３０３は図７に示すようなＨＴＴＰリクエストを送信する。

　図７は、本発明の実施の形態２にかかる格納要求の例を示す図である。図７のＨＴＴＰリクエストは、オブジェクトストレージの一例としてＡｍａｚｏｎ　Ｓ３ (Amazon Simple Storage Service)（登録商標）を想定したものとなっている。

　（Ｓ２０３－１）オブジェクトストレージアクセス部３０３は、オブジェクトストレージ１００へのハートビート情報ファイルの格納が成功したか否かを判定する。ハートビート情報ファイルの格納が成功した場合は、次にステップＳ２０４の処理に進む。格納に失敗した場合は、ステップＳ２０３－２の処理に進む。

　ここで、サーバ３００及びサーバ３５０からオブジェクトストレージ１００にハートビート情報ファイルが格納されると、オブジェクトストレージ１００が保持するデータは図８に示すものとなる。図８は、本発明の実施の形態２にかかるハートビート情報ファイルの一覧の例を示す図である。ハートビート情報ファイルのファイル名は、「日付＋時刻」もしくは「ＵＮＩＸ（登録商標）時間」を用いて、最新のファイルと最新でないファイルを区別できるようになっている。

　（Ｓ２０４）オブジェクトストレージアクセス部３０３は、オブジェクトストレージ１００に格納されている自サーバのハートビート情報ファイルの一覧を確認し、直前に格納したファイルよりも古いファイルが存在するかどうか確認する。存在する場合はステップＳ２０５へ進み、そうでない場合は終了する。

　「ハートビート情報ファイルの一覧」とは、図８におけるファイル（オブジェクト）のパスの一覧のことである。パスの一部にサーバ名が用いられており、それを参照することで自サーバのハートビート情報ファイルであるかどうかを判断できる。

　（Ｓ２０５）オブジェクトストレージアクセス部３０３は、オブジェクトストレージ１００に格納された「自サーバの古いハートビート情報ファイル」を削除するために、図９に示すようなHTTPリクエストを送信する。図９は、本発明の実施の形態２にかかる削除要求の例を示す図である。図９のHTTPリクエストは、オブジェクトストレージの一例としてAmazon S3（登録商標）を想定したものとなっている。

　（Ｓ２０３－２）ステップＳ２０３－１でオブジェクトストレージ１００へのハートビート情報ファイルの格納に失敗した場合、クラスタ制御部３０１は、自サーバを異常状態に更新する。例えば、サーバ３００とオブジェクトストレージ１００の間で通信ができなくなり、もう一方のサーバ３５０とオブジェクトストレージ１００の間の通信が可能である場合である。このような場合、サーバ３００は自サーバがネットワーク的に孤立した状態（異常状態）であると判断する。

　一方、サーバ３５０はオブジェクトストレージ１００と通信できる状態なので、図６のＳ２０３－１で成功と判定され、以降の動作は正常に実行される。もし、サーバ３００とサーバ３５０の両方がオブジェクトストレージ１００と通信できなくなった場合は、両方のサーバが、自サーバがネットワーク的に孤立した状態（異常状態）であると判断する。

　続いて、本発明の実施の形態２にかかるオブジェクトストレージを介したハートビート通信処理（取得）の流れについて、図１０を用いて説明する。尚、サーバ３００によるオブジェクトストレージを介したハートビート通信処理（取得）も同様である。

　（Ｓ３０１）サーバ３５０のハートビート通信部３５２は、オブジェクトストレージアクセス部３５３に対して、オブジェクトストレージ１００に格納されたハートビート情報ファイルを取得するよう要求する。
　（Ｓ３０２）オブジェクトストレージアクセス部３５３は、オブジェクトストレージ１００に格納されているファイルの一覧を取得する。
　（Ｓ３０２－１）オブジェクトストレージアクセス部３５３は、ファイルの一覧の取得に成功したか否かを判定する。ステップＳ３０２の処理が成功した場合は、次にステップＳ３０３の処理に進む。処理が失敗した場合は、ステップＳ３０２－２の処理に進む。
　（Ｓ３０２－２）ステップＳ３０２－１でオブジェクトストレージ１００からハートビート情報ファイルの一覧の取得に失敗した場合、クラスタ制御部３５１は、自サーバを異常状態に更新する。

　（Ｓ３０３）オブジェクトストレージアクセス部３５３は、図１１に示すように、前回取得した他サーバのハートビート情報ファイルの名前を記憶している。図１１は、本発明の実施の形態２にかかる前回取得した他サーバのハートビート情報ファイルの例を示す図である。取得したファイルの一覧を読み取るとファイル名が分かるので、オブジェクトストレージアクセス部３５３は、ハートビート情報ファイルのファイル名に基づいてファイルの最新性を判断し、「他サーバの最新のハートビート情報ファイル」を特定できる。
　（Ｓ３０４）オブジェクトストレージアクセス部３５３は、他サーバの最新のハートビート情報ファイルが存在するか否かを判定する。他サーバの最新のハートビート情報ファイルが存在する場合、ステップＳ３０８に進む。そうでない場合、ステップＳ３０５に進む。

　（Ｓ３０５）オブジェクトストレージアクセス部３５３は、オブジェクトストレージ１００に最新のハートビート情報ファイルが存在しなかった場合に、所定の回数だけリトライを実行する。リトライ回数が閾値に達している場合、それ以上は何も処理を行わずに終了し、図５で示した通りのタイムアウト時の動作に移行する。すなわち、サーバ３００から最新のハートビート情報ファイルが格納されなかった（ハートビートが途絶えた）ことになり、サーバ３００の死活状態を「異常状態」に更新する。リトライ回数が閾値に達していない場合、ステップＳ３０６に進む。

　このリトライは、一般的なオブジェクトストレージで採用されている「冗長化」の仕組みを考慮した動作である。多くのオブジェクトストレージでは、データを複製すること（レプリケーション）によって、ディスク障害時のデータ可用性を担保している。データの複製には一定の時間がかかるため、例えば新しいファイル（オブジェクト）を書き込み、すぐにファイル（オブジェクト）の一覧を表示すると、追加したファイル（オブジェクト）が表示されない場合があるためである。

　（Ｓ３０６）オブジェクトストレージアクセス部３５３は、所定の時間だけ待機する。
　（Ｓ３０７）オブジェクトストレージアクセス部３５３は、リトライ回数を１つ加算し、再度ステップＳ３０２を実行する。

　（Ｓ３０８）ステップＳ３０４で該当するファイルが存在する場合、オブジェクトストレージアクセス部３５３は、オブジェクトストレージ１００に格納された「他サーバの最新のハートビート情報ファイル」を取得する。そのためのＨＴＴＰリクエストは図１２のような形式となる。図１２は、本発明の実施の形態２にかかる取得要求の例を示す図である。図１２のＨＴＴＰリクエストは、オブジェクトストレージの一例としてＡｍａｚｏｎ　Ｓ３（登録商標）を想定したものとなっている。
　（Ｓ３０９）オブジェクトストレージアクセス部３５３は、ハートビート情報ファイルを読み取り、ハートビート通信部３５２に結果を通知する。
　（Ｓ３１０）ハートビート通信部３５２は、他サーバからのハートビートを受信したことを、クラスタ制御部３５１に通知する。
　（Ｓ３１１）クラスタ制御部３５１は、他サーバの死活状態を「正常状態」に更新する。

　以上のように動作することで、サーバ３００とサーバ３５０は、オブジェクトストレージ１００を介して、互いのサーバの死活状態を監視できる。

　なお、ここまでの実施例では２台のサーバで構成されたクラスタを例として説明したが、３台以上のサーバで構成されたクラスタにも適用可能である。具体的には、図１０におけるステップＳ３０３以降の処理を、（自サーバ以外の）他サーバの数だけ繰り返し実行することで実現できる。

　このように、本実施の形態２により、クラスタシステムを構成する複数のサーバが遠隔地に存在する場合であっても、ネットワーク・パーティションを解決できる。また、共有ディスクは（利用しない分も含めて）大容量で高価格であるが、オブジェクトストレージは必要な分だけを低価格で利用できる。そのため、共有ディスクを用いた従来のネットワーク・パーティション解決手法（ディスク・ハートビート）に比べて、クラスタシステムの構築コストを下げることができる。

　共有ディスクを利用するためにはハードウェア、ＯＳ、デバイスドライバといった様々な制約をクリアする必要があるが、オブジェクトストレージを利用するためにはＨＴＴＰ通信をサポートできていればよい。そのため、共有ディスクを用いた従来のネットワーク・パーティション解決手法（ディスク・ハートビート）に比べて、クラスタシステムを構成するサーバの制約を少なくすることができる。

　尚、本実施の形態２の一部を次のように表現することもできる。すなわち、前記クラスタ制御部は、前記取得要求部により取得された前記第２の状態情報を保持し、その後、前記第２の状態情報の取得に成功した場合の前記第２の状態情報と前記保持した第２の状態情報との比較により、前記他の計算機の稼動状態を判定する。

　さらに、前記クラスタ制御部は、前記オブジェクトストレージから取得されるオブジェクトのパスに基づいて、前記他の計算機の稼動状態を判定する。

＜実施の形態３＞
　本実施の形態３は、上述した実施の形態２の改良例である。
　オブジェクトストレージを介したハートビート情報のやり取りは、既存のハートビート通信と比較すると、通信路に対する負荷が大きい。また、利用するオブジェクトストレージによっては、格納されているデータのサイズやデータにアクセスする際のHTTPリクエストの数に応じて利用料が発生することがある。そのため、オブジェクトストレージを介したハートビート情報のやり取りは、必要最小限に抑えることが望ましい。しかし、単純にハートビート情報をやり取りする回数を減らしてしまうと、障害発生の検出が遅れてしまい、サービスの停止時間が長くなってしまう原因となる。

　そこで、本実施の形態３では、オブジェクトストレージを介したハートビート情報のやり取りを、状況に応じて適切な頻度で実行できるようにする。すなわち、前記計算機は、前記他の計算機と相互に稼動状態を監視するための第１の通信回線で接続され、前記オブジェクトストレージとの第２の通信回線と前記第１の通信回線とを含む複数の通信回線のそれぞれについて、監視間隔を対応付けて記憶する記憶部を備える。これにより、複数の通信回線の種別に応じて柔軟に監視を実現できる。

　さらに、前記複数の通信回線の一部が利用不能となった場合、他の通信回線に対応付けられた前記監視間隔を調節する間隔調節部をさらに備える。これにより、一定のサービスレベルを保つことができる。

　さらに、前記記憶部は、前記複数の通信回線のそれぞれについて、前記監視間隔の調節の要否をさらに対応付けて記憶し、前記間隔調節部は、前記他の通信回線のうち、前記調節の要否に基づいて各通信回線の調節を行う。これにより、きめ細かく監視間隔を調整できる。

　図１３は、本発明の実施の形態３にかかるクラスタ管理システム３０００の構成を示すブロック図である。クラスタ管理システム３０００は、クラスタ管理システム２０００に改良を加えたものである。具体的には、サーバ３００と３５０の間を２本のハートビート通信経路４００及び４０１で接続している。また、サーバ３００には、ハートビート間隔調節部３０４が追加され、サーバ３５０には、ハートビート間隔調節部３５４が追加されている。さらに、サーバ３００及び３５０のそれぞれには図示しない構成として、ハートビート通信経路テーブルが格納されている。

　図１４は、本発明の実施の形態３にかかるハートビート通信経路テーブルの例を示す図である。ハートビート通信経路テーブルは、クラスタ管理システム３０００内のハートビート情報のやり取りに使われている経路等を表している。ハートビート通信経路テーブルは、経路の種別や、その経路を使って判明した相手方サーバの（死活）状態、ハートビート通信の間隔、通信間隔の調整の要否、といった情報が存在する。図１４の例では、ハートビート通信経路４００及び４０１を使ったハートビート通信は１０秒間隔で行い、オブジェクトストレージ１００を使ったハートビート通信は６０秒間隔で行うように定義されている。

　クラスタ制御部３０１及び３５１は、サーバ３００及び３５０におけるクラスタシステム起動時にハートビート間隔調節部３０４に問い合わせを行い、ハートビート通信間隔を取得する。以降、クラスタ制御部３０１及び３５１は取得した通信間隔に従ってハートビート通信を実施する。

　図１５は、本発明の実施の形態３にかかるハートビート間隔調整処理の流れを示すフローチャートである。尚、サーバ３５０によるハートビート間隔調整処理も同様である。
　（Ｓ４０１）クラスタ制御部３０１は、図４におけるステップＳ００４、図５におけるステップＳ１０４、図１０におけるステップＳ３１１が実行されて、相手方サーバ３５０の死活状態を更新する際に、ハートビート間隔調節部３０４にも最新の死活状態の情報を入力する。
　（Ｓ４０２）ハートビート間隔調節部３０４は、クラスタ制御部３０１からの入力に応じて、ハートビート通信経路テーブルの状態を更新する。
　（Ｓ４０３）ハートビート間隔調節部３０４は、ハートビート通信経路テーブルの「状態」に変化があったか否かを判定する。変化があった場合、ステップＳ４０４へ進み、変化がなかった場合、処理を終了する。

　（Ｓ４０４）ハートビート間隔調節部３０４は、ハートビート通信経路テーブルの「状態」が「正常」かつ「調節要否」が「要」に設定されている経路の「通信間隔」を変更する。通信間隔の調節は以下の式に基づいて行われる。
通信間隔の初期値　ｘ　（正常状態の経路数　／　総経路数）　＝　調節後の通信間隔

　例えば、ハートビート通信経路４００で障害が発生し、この経路を使ったハートビート通信ができなくなったと仮定する。このとき、ハートビート通信経路テーブルの「ＩＤ：４００」の状態が異常に更新される。すると、「ＩＤ：１００」のオブジェクトストレージの通信間隔は、６０秒　ｘ　２／３＝４０秒に変更される。一方、「ＩＤ：４０１」のハートビート経路については、「調節要否」が不要となっているので、通信間隔の調整は行われない。

　また、ハートビート通信経路４０１でもさらに障害が発生した場合は、「ＩＤ：１００」のオブジェクトストレージの通信間隔は６０秒　ｘ　１／３＝２０秒に変更される。

　（Ｓ４０５）ハートビート間隔調節部３０４は、ハートビート通信経路テーブルの通信間隔を更新すると、最新の情報をクラスタ制御部３０１に通知する。これにより、以降のハートビート通信の間隔が変更される。

　以上のように動作することで、通常のハートビート経路を使った死活監視が正常に機能しているときは、オブジェクトストレージを介したハートビート情報のやり取りを少なくすることによって、通信路への負荷やオブジェクトストレージの利用料の増加を抑えることができる。一方、通常のハートビート経路を使った死活監視が異常となっているときは、通信間隔を短くすることによって相手方サーバの死活状態をタイムリーに確認することができる。

＜その他の実施の形態＞
　なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。

　また、上述の実施の形態では、本発明をハードウェアの構成として説明したが、本発明は、これに限定されるものではない。本発明は、任意の処理を、ＣＰＵ（Central Processing Unit）にコンピュータプログラムを実行させることにより実現することも可能である。

　上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ－ＲＯＭ（Read Only Memory）、ＣＤ－Ｒ、ＣＤ－Ｒ／Ｗ、ＤＶＤ（Digital Versatile Disc）、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

　上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
　（付記１）
　他の計算機とクラスタを構成する計算機であって、
　データをオブジェクト単位で管理するオブジェクトストレージに対して、自計算機の正常状態を示す第１の状態情報の格納を要求する格納要求部と、
　前記オブジェクトストレージに対して前記他の計算機の正常状態を示す第２の状態情報の取得を要求する取得要求部と、
　前記第１の状態情報の格納結果及び前記第２の状態情報の取得結果に応じて、クラスタ制御を行うクラスタ制御部と、を備え、
　前記取得要求部は、
　前記第２の状態情報の取得結果が最新でなかった場合、所定回数、前記第２の状態情報の取得を要求する
　計算機。
　（付記２）
　クラスタ制御部は、
　前記第１の状態情報の格納に失敗した場合、自計算機が異常であると判定してクラスタ制御を行う
　付記１に記載の計算機。
　（付記３）
　前記計算機は、
　前記他の計算機と相互に稼動状態を監視するための第１の通信回線で接続され、
　前記オブジェクトストレージとの第２の通信回線と前記第１の通信回線とを含む複数の通信回線のそれぞれについて、監視間隔を対応付けて記憶する記憶部を備える
　付記１又は２に記載の計算機。
　（付記４）
　前記複数の通信回線の一部が利用不能となった場合、他の通信回線に対応付けられた前記監視間隔を調節する間隔調節部をさらに備える
　付記３に記載の計算機。
　（付記５）
　前記記憶部は、前記複数の通信回線のそれぞれについて、前記監視間隔の調節の要否をさらに対応付けて記憶し、
　前記間隔調節部は、前記他の通信回線のうち、前記調節の要否に基づいて各通信回線の調節を行う
　付記４に記載の計算機。
　（付記６）
　前記クラスタ制御部は、
　前記取得要求部により取得された前記第２の状態情報を保持し、
　その後、前記第２の状態情報の取得に成功した場合の前記第２の状態情報と前記保持した第２の状態情報との比較により、前記他の計算機の稼動状態を判定する
　付記１乃至５のいずれか１項に記載の計算機。
　（付記７）
　前記クラスタ制御部は、
　前記オブジェクトストレージから取得されるオブジェクトのパスに基づいて、前記他の計算機の稼動状態を判定する
　付記６に記載の計算機。
　（付記８）
　データをオブジェクト単位で管理するオブジェクトストレージと、
　前記オブジェクトストレージとネットワークを介して通信可能な複数の計算機と、を備え、
　前記複数の計算機のそれぞれは、
　前記オブジェクトストレージに対して自計算機の正常状態を示す第１の状態情報の格納を要求し、
　前記オブジェクトストレージに対して他の計算機の正常状態を示す第２の状態情報の取得を要求し、
　前記第１の状態情報の格納結果及び前記第２の状態情報の取得結果に応じて、クラスタ制御を行い、
　前記第２の状態情報の取得結果が最新でなかった場合、所定回数、前記取得の要求を行う
　クラスタ管理システム。
　（付記９）
　データをオブジェクト単位で管理するオブジェクトストレージに対して、自計算機の正常状態を示す第１の状態情報の格納を要求し、
　前記オブジェクトストレージに対して他の計算機の正常状態を示す第２の状態情報の取得を要求し、
　前記第１の状態情報の格納結果及び前記第２の状態情報の取得結果に応じて、クラスタ制御を行い、
　前記第２の状態情報の取得結果が最新でなかった場合、所定回数、前記第２の状態情報の取得を要求する
　クラスタ管理方法。
　（付記１０）
　データをオブジェクト単位で管理するオブジェクトストレージに対して、自計算機の正常状態を示す第１の状態情報の格納を要求する処理と、
　前記オブジェクトストレージに対して他の計算機の正常状態を示す第２の状態情報の取得を要求する処理と、
　前記第１の状態情報の格納結果及び前記第２の状態情報の取得結果に応じて、クラスタ制御を行う処理と、
　前記第２の状態情報の取得結果が最新でなかった場合、所定回数、前記第２の状態情報の取得を要求する処理と、
　をコンピュータに実行させるクラスタ管理プログラム。

　以上、実施の形態を参照して本願発明を説明したが、本願発明は上記によって限定されるものではない。本願発明の構成や詳細には、発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

　この出願は、２０１６年９月２１日に出願された日本出願特願２０１６－１８４５１５を基礎とする優先権を主張し、その開示の全てをここに取り込む。

　１０００　クラスタ管理システム
　２０００　クラスタ管理システム
　３０００　クラスタ管理システム
　１０　計算機
　１１　格納要求部
　１２　取得要求部
　１３　クラスタ制御部
　２０　計算機
　２１　格納要求部
　２２　取得要求部
　２３　クラスタ制御部
　３０　オブジェクトストレージ
　４０　ネットワーク
　１００　オブジェクトストレージ
　１０１　ハートビート情報
　１０２　ハートビート情報
　２００　インターネット
　３００　サーバ
　３０１　クラスタ制御部
　３０２　ハートビート通信部
　３０３　オブジェクトストレージアクセス部
　３０４　ハートビート間隔調節部
　３５０　サーバ
　３５１　クラスタ制御部
　３５２　ハートビート通信部
　３５３　オブジェクトストレージアクセス部
　３５４　ハートビート間隔調節部
　４００　ハートビート通信経路
　４０１　ハートビート通信経路

Claims

　データをオブジェクト単位で管理するオブジェクトストレージに対して、自計算機の正常状態を示す第１の状態情報の格納を要求する格納要求手段と、
　前記オブジェクトストレージに対して前記自計算機とクラスタを構成する他の計算機の正常状態を示す第２の状態情報の取得を要求する取得要求手段と、
　前記第１の状態情報の格納結果及び前記第２の状態情報の取得結果に応じて、クラスタ制御を行うクラスタ制御手段と、を備え、
　前記取得要求手段は、
　前記第２の状態情報の取得結果が最新でなかった場合、所定回数、前記第２の状態情報の取得を要求する
　計算機。
　クラスタ制御手段は、
　前記第１の状態情報の格納に失敗した場合、自計算機が異常であると判定してクラスタ制御を行う
　請求項１に記載の計算機。
　前記計算機は、
　前記他の計算機と相互に稼動状態を監視するための第１の通信回線で接続され、
　前記オブジェクトストレージとの第２の通信回線と前記第１の通信回線とを含む複数の通信回線のそれぞれについて、監視間隔を対応付けて記憶する記憶手段を備える
　請求項１又は２に記載の計算機。
　前記複数の通信回線の一部が利用不能となった場合、他の通信回線に対応付けられた前記監視間隔を調節する間隔調節手段をさらに備える
　請求項３に記載の計算機。
　前記記憶手段は、前記複数の通信回線のそれぞれについて、前記監視間隔の調節の要否をさらに対応付けて記憶し、
　前記間隔調節手段は、前記他の通信回線のうち、前記調節の要否に基づいて各通信回線の調節を行う
　請求項４に記載の計算機。
　前記クラスタ制御手段は、
　前記取得要求手段により取得された前記第２の状態情報を保持し、
　その後、前記第２の状態情報の取得に成功した場合の前記第２の状態情報と前記保持した第２の状態情報との比較により、前記他の計算機の稼動状態を判定する
　請求項１乃至５のいずれか１項に記載の計算機。
　前記クラスタ制御手段は、
　前記オブジェクトストレージから取得されるオブジェクトのパスに基づいて、前記他の計算機の稼動状態を判定する
　請求項６に記載の計算機。
　データをオブジェクト単位で管理するオブジェクトストレージと、
　前記オブジェクトストレージとネットワークを介して通信可能な複数の計算機と、を備え、
　前記複数の計算機のそれぞれは、
　前記オブジェクトストレージに対して自計算機の正常状態を示す第１の状態情報の格納を要求し、
　前記オブジェクトストレージに対して前記自計算機とクラスタを構成する他の計算機の正常状態を示す第２の状態情報の取得を要求し、
　前記第１の状態情報の格納結果及び前記第２の状態情報の取得結果に応じて、クラスタ制御を行い、
　前記第２の状態情報の取得結果が最新でなかった場合、所定回数、前記取得の要求を行う
　クラスタ管理システム。
　データをオブジェクト単位で管理するオブジェクトストレージに対して、自計算機の正常状態を示す第１の状態情報の格納を要求し、
　前記オブジェクトストレージに対して前記自計算機とクラスタを構成する他の計算機の正常状態を示す第２の状態情報の取得を要求し、
　前記第１の状態情報の格納結果及び前記第２の状態情報の取得結果に応じて、クラスタ制御を行い、
　前記第２の状態情報の取得結果が最新でなかった場合、所定回数、前記第２の状態情報の取得を要求する
　クラスタ管理方法。
　データをオブジェクト単位で管理するオブジェクトストレージに対して、自計算機の正常状態を示す第１の状態情報の格納を要求する処理と、
　前記オブジェクトストレージに対して前記自計算機とクラスタを構成する他の計算機の正常状態を示す第２の状態情報の取得を要求する処理と、
　前記第１の状態情報の格納結果及び前記第２の状態情報の取得結果に応じて、クラスタ制御を行う処理と、
　前記第２の状態情報の取得結果が最新でなかった場合、所定回数、前記第２の状態情報の取得を要求する処理と、
　をコンピュータに実行させるクラスタ管理プログラムが格納された非一時的なコンピュータ可読媒体。