JP6127005B2 - クラスタシステムのサーバ装置およびプログラム - Google Patents

Description

本発明は、データの冗長度を管理するクラスタシステムを構成する各サーバ装置、および、そのプログラムに関する。

近年、複数のサーバを協調動作させて、全体で１台のコンピュータのように動作させるクラスタシステムが利用されている。クラスタシステムは、多量なデータの処理や再配置を効率的に実行するためにコンシステント・ハッシュ法などによってデータを管理することが多い。
非特許文献１には、コンシステント・ハッシュ法によるデータ管理方法が記載されている。非特許文献２には、コンシステント・ハッシュ法より実際に運用されている例が記載されている。

コンシステント・ハッシュ法では、各サーバが持つ複数の仮想的なＩＤ（メンバ）を、ＩＤ空間上に配置することで、各メンバが担当する領域を平均化し、各サーバの処理負荷を分散させている。また、コンシステント・ハッシュ法では、障害発生時に他のメンバでも処理を行えるように、冗長化した原本データと複製データとをクラスタシステム内に保持する。これにより、クラスタシステムは、サーバ故障などの障害発生時にもサービスを継続することが可能となる。

クラスタシステムは、複数のサーバ装置で構成される。各サーバ装置は、信号処理を行うメンバを１つ以上保持する。各メンバは、コンシステント・ハッシュ法などを用いたＩＤ空間上に配置される。
各メンバは、信号の受信／データの保持／データの操作／信号の送信の一連の処理を行い、ユーザへサービスを提供する。サービスで利用されるユーザデータは、実際のデータである「実データ」と、ユーザやデータの状態などを表す「メタデータ」とを含んでいる。各メンバは、ユーザ単位のユーザデータを保持する。

ユーザデータは、クラスタシステム上で原本データと、原本データのバックアップ用としての１以上の複製データが存在する。クラスタシステムは、同一のユーザデータを冗長度の数だけ保持することで、冗長性を担保する。冗長度の数とは、同一のクラスタシステム内に存在する原本データと複製データの総数である。
激甚災害などによるサーバの障害や故障により、メンバの一部が停止して冗長度が不足した場合、クラスタシステムは、残存するサーバ集合でクラスタを組み直し、自律的に冗長化構成などを回復する。クラスタシステムは、自律的にデータの探索およびデータの再配置（原本昇格・複製データの作成・削除）を行う。具体的にいうと、クラスタシステムは、故障してクラスタから離脱したサーバが保持しているデータを、残存している他のサーバへ自律的に引き継き、処理を行わせる。
これによりクラスタシステムは、激甚災害の発生時においても、サービスの継続が可能である。クラスタシステムは、故障したサーバが持つ冗長度が低下したデータについて、自動的に他のサーバがそのデータの複製を作成し、冗長度を回復する。

図１４（ａ），（ｂ）は、比較例のメモリ閾値超え時の複製データ保持動作を示す説明図である。
図１４（ａ）は、障害や故障により冗長度が不足した場合のデータの再配置動作を示している。
コンシステント・ハッシュ法などを用いたＩＤ空間６には、メンバ６１−１〜６１−５が配置される。原本データを保持するメンバ６１−２は、障害や故障により停止する。クラスタシステムは、メンバ６１−３〜６１−５上に、複製データを作成する。この状況は、冗長度が低下した過渡状態である。
このときメンバ６１−５は、メモリ利用量が閾値を超えている。図１４（ａ）では、メモリ利用量が閾値を超えたメンバ６１−５を、ハッチングで示している。

図１４（ｂ）は、データの再配置後のＩＤ空間６を示している。
ＩＤ空間６には、結果的にメンバ６１−１，６１−３，６１−４が配置される。障害や故障により停止したメンバ６１−２は、消滅する。メンバ６１−３は、原本データを保持する。メンバ６１−４，６１−５は、複製データを保持する。このとき、メンバ６１−５は、サーバのメモリ量を超えたデータを保持したため、処理不可に陥り故障する。図１４（ｂ）では、故障したメンバ６１−５を、「×」印で示している。

David Karger、他５名、"Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web"、［ｏｎｌｉｎｅ］、［２０１４年２月１９日検索］、インターネット<URL：http://www.akamai.com/dl/technical_publications/ConsistenHashingandRandomTreesDistributedCachingprotocolsforrelievingHotSpotsontheworldwideweb.pdf> Giuseppe DeCandia他８名、"Dynamo: Amazon’s Highly Available Key-value Store"、［ｏｎｌｉｎｅ］、［２０１４年２月１９日検索］、インターネット<URL：http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf>

データの冗長度を自律的に確保するクラスタシステムにおいて、激甚災害などにより第１のサーバの故障が発生すると、ユーザのデータは第２のサーバへ引き継がれる。第２のサーバは、自装置の利用可能なメモリの許容量を超えてデータを保持すると、処理不可に陥り故障となる。故障となった第２のサーバの持つデータは、第３サーバへ割り振られる。第３のサーバも、自装置の利用可能なメモリの許容量を超えてデータを保持すると、処理不可に陥り故障となる。
大規模な激甚災害や多数のサーバの故障により、メモリ不足のサーバが多数存在する場合には、このようにメモリ不足によるサーバの故障が連鎖的に発生する虞がある。このとき、クラスタシステム全体が解体して、サービスが継続不能となる。

本発明は、前記した問題を解決し、データ間の冗長度のバランスをとり、かつクラスタシステムの解体を抑制してサービスを継続するクラスタシステムのサーバ装置およびプログラムを提供することを課題とする。

前記課題を解決するため、請求項１に記載の発明では、クラスタシステムに含まれるサーバ装置であって、前記サーバ装置は、メタデータと実データとを含み複製番号が付与された複製データまたは／および原本データを保持するメモリと、前記メモリの利用量を測定するメモリ利用量測定部と、前記メモリの利用量がメモリ不足閾値以上ならば、所定の複製番号の順に、前記複製データの実データの有無を判断し、前記所定の複製番号の順に当該複製データの実データを前記メモリから削除し、前記メモリの利用量が前記メモリ不足閾値よりも小さいメモリ不足解消閾値以下ならば、前記所定の複製番号の逆順に各前記複製データの実データの有無を判断し、当該複製データの実データが無いならば、当該複製データのメタデータに基づき当該複製データに対応する前記原本データの実データを他のサーバ装置から取得する複製データ削除／回復処理部と、を備える。

このようにすることで、サーバ装置は、データ間の冗長度を、バランスをとりつつ減少させ、かつクラスタ解体を抑制することができる。更にサーバ装置は、メモリ不足が解消したときに、データ間の冗長度のバランスをとりつつデータを回復できる。

請求項２に記載の発明では、前記所定の複製番号の順とは、前記複製データに付与された複製番号の範囲の降順、前記複製データに付与された複製番号の範囲の昇順、前記複製データに付与された複製番号の範囲の任意の指定順のうちいずれかである、ことを特徴とする請求項１に記載のクラスタシステムのサーバ装置とした。

このようにすることで、サーバ装置は、データ間の冗長度増減のバランスを容易にとることができる。

請求項３に記載の発明では、前記複製データ削除／回復処理部は、前記メモリの利用量が前記メモリ不足閾値以上ならば、前記メモリの利用量が前記メモリ不足閾値と前記メモリ不足解消閾値との間のいずれかである所定の閾値未満になるまで、前記所定の複製番号の順に前記複製データの実データを前記メモリから削除する、ことを特徴とする請求項１に記載のクラスタシステムのサーバ装置とした。

このようにすることで、サーバ装置は、複製データ削除処理の動作回数を減らすことができる。

請求項４に記載の発明では、前記複製データ削除／回復処理部は、前記メモリの利用量がメモリ不足解消閾値以下ならば、前記メモリの利用量がメモリ不足解消閾値と前記メモリ不足閾値との間のいずれかである所定の閾値を超過するまで、当該複製データのメタデータに基づき当該複製データに対応する前記原本データの実データを他のサーバ装置から取得する、ことを特徴とする請求項１に記載のクラスタシステムのサーバ装置とした。

このようにすることで、サーバ装置は、複製データ回復処理の動作回数を減らすことができる。
請求項５に記載の発明では、前記メモリに保持されるメタデータは、実データのサイズ情報を含む、ことを特徴とする請求項３または４に記載のクラスタシステムのサーバ装置とした。
このようにすることで、サーバ装置は、削除／回復するデータ量を容易に算出可能となる。

請求項６に記載の発明では、前記原本データおよび前記複製データは、コンシステント・ハッシュ法によるＩＤ空間で管理される、ことを特徴とする請求項１ないし５のいずれか１項に記載のクラスタシステムのサーバ装置とした。

このようにすることで、サーバ装置は、コンシステント・ハッシュ法によるＩＤ空間でデータを管理すると共に、データの冗長度を自律的に確保しつつ、クラスタシステムの解体を抑制して、サービスを継続することができる。

請求項７に記載の発明では、メタデータと実データとを含む原本データまたは／および複製データを保持するメモリの利用量を測定するステップ、前記メモリの利用量がメモリ不足閾値以上ならば、所定の複製番号の順に、前記複製データの実データの有無を判断するステップ、前記所定の複製番号の順に前記複製データの実データを前記メモリから削除するステップ、前記メモリの利用量が前記メモリ不足閾値よりも小さいメモリ不足解消閾値以下ならば、前記所定の複製番号の逆順に各前記複製データの実データの有無を判断するステップ、前記複製データの実データが無いならば、当該複製データのメタデータに基づき当該複製データに対応する前記原本データの実データを他のサーバ装置から取得するステップ、をクラスタシステムのサーバ装置に実行させるためのプログラムとした。

このようにすることで、プログラムは、サーバ装置にデータ間の冗長度をバランスをとりつつ減少させ、クラスタ解体を抑制することができる。更にサーバ装置は、メモリ不足が解消したときに、データ間の冗長度のバランスをとりつつデータを回復できる。

本発明によれば、データ間の冗長度のバランスをとり、かつクラスタシステムの解体を抑制してサービスを継続するクラスタシステムのサーバ装置およびプログラムを提供することが可能となる。

本実施形態におけるクラスタシステムを示す概略の構成図である。 クラスタシステム内のユーザデータ例を示す図である。 本実施形態におけるクラスタシステムのＩＤ空間上のメンバ配置の説明図である。 本実施形態の変形例のクラスタシステムのＩＤ空間上のメンバ配置の説明図である。 通常時のメンバとユーザデータの例を示す説明図である。 激甚災害発生によるメモリ不足時のメンバとユーザデータの例を示す説明図である。 激甚災害発生による複製データ削除の例を示す説明図である。 災害回復時の複製データ回復の例を示す説明図である。 メモリ使用量と各種閾値におけるアクションを示す説明図である。 複製データ削除リスト例と複製データ回復リスト例を示す図である。 複製データ削除／回復処理を示すフローチャートである。 複製データ削除処理を示すフローチャートである。 複製データ回復処理を示すフローチャートである。 比較例のメモリ閾値超え時の複製データ保持動作を示す説明図である。

次に、本発明を実施するための形態（「実施形態」という）について、適宜図面を参照して詳細に説明する。

（第１の実施形態）
図１は、本実施形態におけるクラスタシステムを示す概略の構成図である。
クラスタシステム１は、複数のサーバ２−１〜２−ｎ（サーバ装置）からなるクラスタ３と、振分装置４−１〜４−ｍと、ロードバランサ５とを含んで構成される。以下、サーバ２−１〜２−ｎを特に区別しない場合には、単にサーバ２と記載する。振分装置４−１〜４−ｍを特に区別しない場合には、単に振分装置４と記載する。

各サーバ２は、コンピュータなどの物理装置や仮想マシンなどの論理装置である。サーバ２は、信号処理部２１と、メモリ利用量測定部２２と、複製データ削除／回復処理部２３と、記憶部２４と、メモリ２５とを備えている。記憶部２４は、例えばハードディスクやフラッシュメモリなどの二次記憶装置であり、信号処理プログラム２４１を格納する。メモリ２５は、例えばＤＲＡＭ（Dynamic Random Access Memory）などの一次記憶装置であり、各メンバ６１を保持する。
信号処理部２１は、他のサーバ２の信号アクセスを受け付けて処理する。
メモリ利用量測定部２２は、メモリ２５の使用量を測定する。
複製データ削除／回復処理部２３は、後記する図２に示すユーザデータの実データを削除／取得する。
信号処理プログラム２４１は、このサーバ２上の不図示のＣＰＵ（Central Processing Unit）によって実行されて、信号処理部２１と、メモリ利用量測定部２２と、複製データ削除／回復処理部２３と、各メンバ６１とを具現化する。
振分装置４は、コンピュータなどの物理装置であり、受信したメッセージを振り分ける振分部４１と、不図示の入出力部、制御部、記憶部などを備える。
クライアント端末９や、ロードバランサ５は、コンピュータなどの物理装置であり、それぞれ不図示の入出力部、制御部、記憶部などを備える。

クライアント端末９からのメッセージは、ロードバランサ５にて、単純なラウンドロビン法などにより、振分装置４に振り分けられる。振分装置４は、例えばコンシステント・ハッシュ法などに基づき、受信したメッセージが要求するデータの識別子を参照して、このデータを管理しているサーバ２を特定する。振分装置４は、特定したサーバ２に、受信したメッセージを振り分ける。

各サーバ２は、信号を処理する１つ以上の論理的な処理機能であるメンバ６１を保持している。各サーバ２は、データの識別子により処理するメンバ６１を特定してメッセージ処理を行わせ、クライアント端末９にサービスを提供する。

なお、第１の実施形態では、振分装置４と各サーバ２とを別に記載したが、同一筐体上で別々の機能として動作させてもよい。また、振分装置４をクラスタ構成としてもよい。更に、ロードバランサ５が存在せず、クライアント端末９から任意の振分装置４にメッセージを送信するように構成してもよい。

図２は、クラスタシステム内のユーザデータ例を示す図である。
メンバ６１−１〜６１−Ｍは、ユーザデータを保持している。このユーザデータは、クライアント端末９などのユーザへ、サービスを提供するためのユーザ個別のデータである。ユーザデータは、データに係る情報を表す「メタデータ」と、実際のサービスで用いられる「実データ」とを含む。
「メタデータ」は、データＩＤと、所有者・バディ情報と、データサイズと、実データ有無フラグとを有している。

データＩＤは、このユーザデータをユニークに識別する値である。
所有者・バディ情報は、このデータの所有者情報とバディ情報である。バディ情報は、複製データ番号を示すバディ番号と、この複製データの保持先情報との組合せである。
データサイズは、実データのサイズ情報である。
実データ有無フラグは、このユーザデータが、実データを含んでいるか否かの情報である。実データ有無フラグは、例えば０のときには実データが無いことを示し、１のときには実データが有ることを示す。

なお、「メタデータ」は、上記以外にも、原本として保持するメンバ６１の識別子や、データへのアクセス時刻などの情報を含んでいてもよい。
メンバ６１−１は、ユーザデータの原本である原本データを格納している。メンバ６１−２〜６１−Ｍは、原本データの複製である複製データを格納している。これにより、クラスタシステム１（図１参照）は、ユーザデータの冗長性を確保することができる。冗長度Ｍは、原本データと複製データとを併せた数である。クラスタシステム１には、同一データが冗長度Ｍだけ存在する。
クラスタシステム１は、複製データが消失した場合には原本データより復元して冗長性を回復し、原本データが消失した場合には複製データより実データを取得してサービスを継続する。

クラスタシステム１は、複数のサーバ２を含む分散システムである。図３に示すように、各サーバ２は、拠点７−１〜７−３のいずれかに相互に通信可能に配置されて分散システムを構成する。
第１の実施形態では、コンシステント・ハッシュ法のＩＤ空間６上に、メンバ６１を配置している。各サーバ２は、１個以上のメンバ６１を保持している。例えば拠点７−１のサーバ２−１は、２個のメンバ６１−１，６１−２を保持している。
各サーバ２は、メンバ６１とデータの双方にＩＤを割り当て、データのＩＤから仮想ノードＩＤ空間であるＩＤ空間６を時計回りに辿り、最初に当たったメンバ６１を担当とする。ノードに対するＩＤの与え方は、例えば、ＩＰアドレスのハッシュ関数値などがある。

各サーバ２は、担当となったメンバ６１が持つデータを原本データと判断し、データの更新・削除などは原本データのみに実施する。各サーバ２は、原本データが変更された場合、定期的もしくは逐次的に複製データへ変更差分を反映する。データの取得・更新・削除も、同様な方法により各データに対してメンバ６１を特定する。

図４は、第１の実施形態の変形例のクラスタシステム１ＡのＩＤ空間６上のメンバ６１の配置の説明図である。
クラスタシステム１Ａは、複数のサーバ２を含み、複数の現用系が並列に動作するＮ−ＡＣＴ構成のシステムである。各サーバ２は、相互に通信可能に配置される。
このように、信号処理を行う論理的なメンバ６１は、分散システムの不特定のサーバ２上に限られず、Ｎ−ＡＣＴ構成の特定のサーバ２上に配置されてもよい。

コンシステント・ハッシュ法を用いてメンバ６１をＩＤ空間６上に配置した例を、以下の図５から図８に示す。ここでは、クラスタシステム１が保持するユーザデータの冗長度を３としている。
図５は、通常時のメンバとユーザデータの例を示す説明図である。
各メンバ６１−１〜６１−５は、同一のサーバ２または異なるサーバ２内に存在する。各メンバ６１−１〜６１−５は、ＩＤ空間６上の一部に配置される。
メンバ６１−１は、データＧの第２複製と、データＦの第１複製と、データＡの原本とを保持する。データＧ，Ｆ，Ａは、いずれもメタデータと実データとを含んでいる。
メンバ６１−２は、データＢの原本と、データＦの第２複製と、データＡの第１複製とを保持する。データＢ，Ｆ，Ａは、いずれもメタデータと実データとを含んでいる。

メンバ６１−３は、データＢの第１複製と、データＣの原本と、データＡの第２複製とを保持する。データＢ，Ｃ，Ａは、いずれもメタデータと実データとを含んでいる。
メンバ６１−４は、データＢの第２複製と、データＣの第１複製と、データＤの原本とを保持する。データＢ，Ｃ，Ｄは、いずれもメタデータと実データとを含んでいる。
メンバ６１−５は、データＥの原本と、データＣの第２複製と、データＤの第１複製とを保持する。データＥ，Ｃ，Ｄは、いずれもメタデータと実データとを含んでいる。
図５の通常時にて、激甚災害の発生によりメンバ６１−１，６１−２を保持するサーバ２が減設すると、図６の状態に遷移する。

図６は、激甚災害発生によるメモリ不足時のメンバとユーザデータの例を示す説明図である。図６は、図５の後の状態を示している。
メンバ６１−１，６１−２は、激甚災害の発生により減設する。メンバ６１−１，６１−２が保持していた各データは、メンバ６１−３〜６１−５に引き継がれる。更にメンバ６１−３〜６１−５が保持する各データは、必要に応じて昇格する。
メンバ６１−３は、データＢの原本と、データＣの原本と、データＡの原本と、データＦの第１複製と、データＧの第２複製とを保持する。データＢ，Ａは、原本に昇格する。データＦ，Ｇは、メンバ６１−３に新たに引き継がれる。これらデータＢ，Ｃ，Ａ，Ｆ，Ｇは、いずれもメタデータと実データとを含んでいる。

メンバ６１−４は、データＢの第１複製と、データＣの第１複製と、データＡの第１複製と、データＦの第２複製と、データＤの原本とを保持する。データＢは、第２複製から第１複製に昇格する。データＡ，Ｆは、メンバ６１−４に新たに引き継がれる。これらデータＢ，Ｃ，Ａ，Ｆ，Ｄは、いずれもメタデータと実データとを含んでいる。メンバ６１−４は、データＡ，Ｆの引き継ぎにより、メモリ利用量αが閾値Ｘ（第１の閾値）以上となり、メモリ不足となる。図６では、メンバ６１−４のメモリ不足を、ハッチングで示している。

メンバ６１−５は、データＢの第２複製と、データＣの第２複製と、データＡの第２複製と、データＥの原本と、データＤの第１複製とを保持する。データＢ，Ａは、メンバ６１−５に新たに引き継がれる。データＢ，Ｃ，Ａ，Ｅ，Ｄは、いずれもメタデータと実データとを含んでいる。

ここで、メモリ不足のメンバ６１−４は、複製データの実データを削除する。本実施形態における削除の優先順位は、複製データ番号の降順であり、第２複製から第１複製の順である。しかし、これに限られず、削除の優先順位は、特定の複製データ番号順であればよく、例えば複製データ番号の昇順や、任意に指定した複製データ番号順であってもよい。これにより、ユーザデータ間の冗長度増減のバランスを容易にとることができる。
本実施形態のメンバ６１−４は、複製データ番号が同じ複数の複製データを所定の順序で削除する。これにより、データ間の冗長度のバランスを確保できる。しかし、これに限られず、メンバ６１は、複製データ番号が同じ複数の複製データをランダムに削除してもよい。
図６に示す状態にて複製データが削除されると、図７に示す状態に遷移する。

図７は、激甚災害発生による複製データ削除の例を示す説明図である。
メンバ６１−４は、データＦの第２複製の実データを削除する。以降、メンバ６１−４は、メモリ利用量が閾値Ｙを下回るまで、データＡの第１複製、データＢの第１複製、データＣの第１複製の順で削除する。しかし、メンバ６１−４は、メモリ利用量が閾値Ｙを下回るまで、データＡ，Ｂ，Ｃの第１複製をランダムに削除してもよい。
この事例にてメンバ６１−４は、メモリ利用量が閾値Ｙを下回ったのち更に、自然減などにより閾値Ｚ（第３の閾値）以下となると、図８に示す複製データ回復に遷移する。

図８は、災害回復時の複製データ回復の例を示す説明図である。図８は、図７の後の状態を示している。
メンバ６１−４は、メモリ利用量が閾値Ｚ以下となり、メモリ不足が解消されたため、データＦの第２複製の実データを回復する。メンバ６１−４は、データＦの原本を保持するメンバ６１−０にアクセスして、その実データを取得する。データの回復の優先順位は、データの削除の優先順位の逆順であり、第１複製から第２複製の順である。本事例では、メンバ６１−４は、データＦの第２複製の実データのみを削除していたため、第２複製からデータを回復させる。

図９は、メモリ使用量と各種閾値におけるアクションを示す説明図である。
各サーバ２は、所定の周期、または、データ操作の前後でメモリ利用量αをチェックする。メモリ利用量αが以下のときに、サーバ２のメンバ６１は、所定のアクションを実施する。
サーバ２は、メモリ利用量αが閾値Ｘ（例えば容量の８０％）以上であることを検知したら、メモリ不足と判断する。このときサーバ２のメンバ６１は、遷移Ｍ２に示すように、閾値Ｙ未満（例えば容量の６０％）まで、複製データのメタデータのみを残して実データを削除する。これにより、複製データ削除処理の起動と停止との繰り返しを防き、その動作回数を減らすことができる。
閾値Ｘ，Ｙは、任意に設定可能であり、例えば両方とも容量の８０％としてもよい。このときサーバ２は、メモリ利用量αが閾値Ｘ以上のときに、複製データのメタデータのみを残して実データを削除する。

遷移Ｍ３に示すように、メモリ利用量αは、閾値Ｚ（例えば容量の４０％）以下まで自然に減少する。
サーバ２は、メモリ利用量αが閾値Ｚ以下であることを検知したら、メモリ不足が解消したと判断する。このときサーバ２のメンバ６１は、遷移Ｍ０に示すように、閾値Ｙを超過するまで、複製データの実データを回復させる。これにより、複製データ回復処理の起動と停止との繰り返しを防き、その動作回数を減らすことができる。その後、遷移Ｍ１に示すように、メモリ利用量αが閾値Ｘ以上まで自然に増加すると、再び遷移Ｍ２の削除処理が行われる。
閾値Ｚ，Ｙは、任意に設定可能であり、例えば両方とも容量の４０％としてもよい。このときサーバ２は、メモリ利用量αが閾値Ｚ以下のときに、複製データの実データを回復させる。

図１０（ａ），（ｂ）は、複製データ削除リスト例と複製データ回復リスト例を示す図である。
図１０（ａ）は、複製データ削除リスト例を示す図である。
複製データ削除リストは、サーバ２がメモリ不足と判断したときに、このサーバ２のメンバ６１が作成する。複製データ削除リストの各行は、各データに対応している。複製データ削除リストは、データ識別子と、複製データ番号と、データサイズと、実データ有無フラグの各カラムを含んでいる。メンバ６１は、各ユーザデータのメタデータを参照して、この複製データ削除リストを生成する。複製データ削除リストは、データサイズの情報を含んでいるので、削除したデータ量を容易に算出可能である。
メンバ６１は、自身が保持するデータのうち、ノードアドレスとバディとが一致し、かつ、実データ有無フラグが１（実データ有り）のものを抽出して複製データ削除リストを作成する。メンバ６１は更に、複製データ番号が降順になるように、複製データ削除リストを並び替える。

図１０（ｂ）は、複製データ回復リスト例を示す図である。
複製データ回復リストは、サーバ２がメモリ不足が解消したと判断したときに、このサーバ２のメンバ６１が作成する。複製データ回復リストの各行は、各データに対応している。複製データ回復リストの各カラムは、複製データ削除リストの各カラムと同様である。複製データ回復リストは、データサイズの情報を含んでいるので、回復したデータ量を容易に算出可能である。
メンバ６１は、自身が保持するデータのうち、ノードアドレスとバディとが一致し、かつ、実データ有無フラグが０（実データ無し）のものを抽出して複製データ回復リストを作成する。メンバ６１は更に、複製データ番号が昇順になるように、複製データ回復リストを並び替える。

図１１は、複製データ削除／回復処理を示すフローチャートである。
サーバ２は、起動したのち、図１１に示す複製データ削除／回復処理を繰り返す。
ステップＳ１０において、サーバ２は、所定の周期であるか否かを判断する。サーバ２は、所定の周期であれば（Ｙｅｓ）、ステップＳ１２の処理を行い、所定の周期でなかったならば（Ｎｏ）、ステップＳ１１の処理を行う。
ステップＳ１１において、サーバ２は、データ操作の前後であるか否かを判断する。サーバ２は、データ操作の前後であれば（Ｙｅｓ）、ステップＳ１２の処理を行い、データ操作の前後でなかったならば（Ｎｏ）、ステップＳ１０の処理に戻る。
ステップＳ１２において、サーバ２は、メモリ利用量測定部２２により、メモリ利用量αを測定する。

ステップＳ１３において、サーバ２は、メモリ利用量αをチェックする。サーバ２は、メモリ利用量αが閾値Ｘ以上ならば、ステップＳ１４の処理を行い、メモリ利用量αが閾値Ｚ以下ならば、ステップＳ１５の処理を行い、メモリ利用量αが閾値Ｚを超え、かつ閾値Ｘ未満ならば、ステップＳ１０の処理に戻る。
ステップＳ１４において、サーバ２は、自身の各メンバ６１に複製データ削除処理を行わせ、ステップＳ１０の処理に戻る。この複製データ削除処理は、後記する図１２で詳細に説明する。
ステップＳ１５において、サーバ２は、自身の各メンバ６１に複製データ回復処理を行わせ、ステップＳ１０の処理に戻る。この複製データ回復処理は、後記する図１３で詳細に説明する。

図１２は、複製データ削除処理を示すフローチャートである。
ステップＳ２０において、メンバ６１は、ノードアドレスとバディが一致し、かつ実データを持つ複製データを抽出して、複製データ削除リスト（図１０（ａ）参照）を作成する。
ステップＳ２１において、メンバ６１は、複製データ削除リストを、特定の複製データ番号順にソートする。本実施形態において特定の複製データ番号順とは、降順である。
ステップＳ２２において、メンバ６１は、複製データの総容量格納変数を０で初期化する。
ステップＳ２３において、メンバ６１は、複製データ削除リストの先頭要素を取得し、この先頭要素を削除する。複製データ削除リストの先頭要素とは、第１行目の要素である。先頭要素の削除により、第２行目以降の要素が順に繰り上がる。

ステップＳ２４において、メンバ６１は、この要素に係る複製データの実データを削除する。
ステップＳ２５において、メンバ６１は、総容量格納変数に対象要素の実データサイズを加算する。
ステップＳ２６において、メンバ６１は、ステップＳ１２で測定したメモリ利用量αから総容量格納変数を減算して現在のメモリ利用量を算出し、閾値Ｙと比較する。メンバ６１は、現在のメモリ利用量が閾値Ｙ未満ならば（Ｙｅｓ）、図１２の処理を終了し、現在のメモリ利用量が閾値Ｙ以下ならば（Ｎｏ）、ステップＳ２３の処理に戻る。
このようにすることで、メモリ利用量測定部２２の処理回数を削減し、かつ複製データの実データ削除の度に現在のメモリ利用量を算出することができる。

図１３は、複製データ回復処理を示すフローチャートである。
ステップＳ３０において、メンバ６１は、ノードアドレスとバディが一致し、かつ実データを持たない複製データを抽出して、複製データ回復リスト（図１０（ｂ）参照）を作成する。
ステップＳ３１において、メンバ６１は、複製データ回復リストを、特定の複製データ番号の逆順にソートする。本実施形態において特定の複製データ番号順の逆順とは、昇順である。
ステップＳ３２において、メンバ６１は、複製データの総容量格納変数を０で初期化する。

ステップＳ３３において、メンバ６１は、複製データ回復リストの先頭要素を取得し、この先頭要素を削除する。複製データ回復リストの先頭要素とは、第１行目の要素である。先頭要素の削除により、第２行目以降の要素が順に繰り上がる。
ステップＳ３４において、メンバ６１は、この要素に係る複製データの実データを回復する。
ステップＳ３５において、メンバ６１は、総容量格納変数に対象要素の実データサイズを加算する。
ステップＳ３６において、メンバ６１は、ステップＳ１２で測定したメモリ利用量αに総容量格納変数を加算して現在のメモリ利用量を算出し、閾値Ｙと比較する。メンバ６１は、現在のメモリ利用量が閾値Ｙを超過したならば（Ｙｅｓ）、図１３の処理を終了し、
現在のメモリ利用量が閾値Ｙ以下ならば（Ｎｏ）、ステップＳ３３の処理に戻る。

比較例のクラスタシステム（図１４参照）は、自律的な機能によりシステムの解体へ発展してしまう機能を持っている。大規模な激甚災害や複数のサーバ２が故障しメモリ２５が不足している状況でデータの複製を作成することで、メモリ２５の枯渇による故障が発生する。このデータの引き継ぎ先の他サーバ２においても、メモリ２５の枯渇による故障が連鎖して発生することで、クラスタシステム１の全体が解体し、サービスが停止してしまう。

本実施形態のクラスタシステム１（図１参照）は、一時的に冗長度を低下させることによりメモリ２５を確保しつつ、データの探索・取得を行う。これにより、クラスタシステム１は、原本のデータは救済かつ確保しつつ、自身の解体を抑制してサービスの継続を可能とする。
本実施形態のクラスタシステム１によれば、メモリ２５が不足している状況においては、各ユーザデータの冗長度のバランスをとりつつ実データを削除し、メタデータのみを保持しつつメモリ２５の利用を抑制する。これにより、クラスタシステム１の解体を回避し、激甚災害時においてもサービスの継続を可能とする。更に、ユーザデータの冗長度の偏りによるデータ消失を抑止することができる。
また、本実施形態のクラスタシステム１によれば、激甚災害時などの一時的にメモリ２５が必要になる場合に備えて多量のメモリ・リソースを用意せずともよく、効率的にメモリ２５を利用することが可能となる。

本実施形態により、多数のサーバ２が故障した場合であっても、クラスタシステム１は、サービスの継続が可能である。
更に各サーバ２が故障から回復し、またはサーバ２が増設されて利用可能なメモリ２５が増えた場合に、クラスタシステム１は、データの冗長度のバランスをとりつつ回復する。これにより、ユーザデータの冗長度の偏りによるデータ消失を抑止することができる。

本実施形態のサーバ２は、前記したような処理を実行させる信号処理プログラム２４１によって実現することができ、そのプログラムをコンピュータによる読み取り可能な記録媒体（ＣＤ−ＲＯＭなど）に記憶して提供することが可能である。また、そのプログラムを、インターネット等のネットワークを通して提供することも可能である。

上記実施形態は、コンシステント・ハッシュ法でデータ管理するクラスタシステムに限定されず、データを冗長化して管理するクラスタシステムであればよい。

１，１Ａ クラスタシステム
２，２−１〜２−ｎ サーバ （サーバ装置）
２１ 信号処理部
２２ メモリ利用量測定部
２３ 複製データ削除／回復処理部
２４ 記憶部
２４１ 信号処理プログラム
２５ メモリ
４，４−１〜４−ｍ 振分装置
４１ 振分部
５ ロードバランサ
６ ＩＤ空間
６１，６１−０〜６１−９ メンバ
７，７−１〜７−３ 拠点
９ クライアント端末
Ｘ 閾値 （第１の閾値）
Ｙ 閾値 （第２の閾値）
Ｚ 閾値 （第３の閾値）

Claims (7)

1. クラスタシステムに含まれるサーバ装置であって、
   前記サーバ装置は、
   メタデータと実データとを含み複製番号が付与された複製データまたは／および原本データを保持するメモリと、
   前記メモリの利用量を測定するメモリ利用量測定部と、
   前記メモリの利用量がメモリ不足閾値以上ならば、所定の複製番号の順に、前記複製データの実データの有無を判断し、前記所定の複製番号の順に当該複製データの実データを前記メモリから削除し、前記メモリの利用量が前記メモリ不足閾値よりも小さいメモリ不足解消閾値以下ならば、前記所定の複製番号の逆順に各前記複製データの実データの有無を判断し、当該複製データの実データが無いならば、当該複製データのメタデータに基づき当該複製データに対応する前記原本データの実データを他のサーバ装置から取得する複製データ削除／回復処理部と、
   を備えることを特徴とするクラスタシステムのサーバ装置。
2. 前記所定の複製番号の順とは、前記複製データに付与された複製番号の範囲の降順、前記複製データに付与された複製番号の範囲の昇順、前記複製データに付与された複製番号の範囲の任意の指定順のうちいずれかである、
   ことを特徴とする請求項１に記載のクラスタシステムのサーバ装置。
3. 前記複製データ削除／回復処理部は、前記メモリの利用量が前記メモリ不足閾値以上ならば、前記メモリの利用量が前記メモリ不足閾値と前記メモリ不足解消閾値との間のいずれかである所定の閾値未満になるまで、前記所定の複製番号の順に前記複製データの実データを前記メモリから削除する、
   ことを特徴とする請求項１に記載のクラスタシステムのサーバ装置。
4. 前記複製データ削除／回復処理部は、前記メモリの利用量が前記メモリ不足解消閾値以下ならば、前記メモリの利用量が前記メモリ不足解消閾値と前記メモリ不足閾値との間のいずれかである所定の閾値を超過するまで、当該複製データのメタデータに基づき当該複製データに対応する前記原本データの実データを他のサーバ装置から取得する、
   ことを特徴とする請求項１に記載のクラスタシステムのサーバ装置。
5. 前記メモリに保持されるメタデータは、実データのサイズ情報を含む、
   ことを特徴とする請求項３または４に記載のクラスタシステムのサーバ装置。
6. 前記原本データおよび前記複製データは、コンシステント・ハッシュ法によるＩＤ空間で管理される、
   ことを特徴とする請求項１ないし５のいずれか１項に記載のクラスタシステムのサーバ装置。
7. メタデータと実データとを含む原本データまたは／および複製データを保持するメモリの利用量を測定するステップ、
   前記メモリの利用量がメモリ不足閾値以上ならば、所定の複製番号の順に、前記複製データの実データの有無を判断するステップ、
   前記所定の複製番号の順に前記複製データの実データを前記メモリから削除するステップ、
   前記メモリの利用量が前記メモリ不足閾値よりも小さいメモリ不足解消閾値以下ならば、前記所定の複製番号の逆順に各前記複製データの実データの有無を判断するステップ、
   前記複製データの実データが無いならば、当該複製データのメタデータに基づき当該複製データに対応する前記原本データの実データを他のサーバ装置から取得するステップ、
   をクラスタシステムのサーバ装置に実行させるためのプログラム。

Images