特許第6055197号(P6055197)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 日本電信電話株式会社の特許一覧
<>
  • 特許6055197-データベースシステム 図000002
  • 特許6055197-データベースシステム 図000003
  • 特許6055197-データベースシステム 図000004
  • 特許6055197-データベースシステム 図000005
  • 特許6055197-データベースシステム 図000006
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6055197
(24)【登録日】2016年12月9日
(45)【発行日】2016年12月27日
(54)【発明の名称】データベースシステム
(51)【国際特許分類】
   G06F 11/20 20060101AFI20161219BHJP
   G06F 12/00 20060101ALI20161219BHJP
   G06F 17/30 20060101ALI20161219BHJP
【FI】
   G06F11/20 694
   G06F12/00 531M
   G06F12/00 531R
   G06F17/30 110C
【請求項の数】1
【全頁数】12
(21)【出願番号】特願2012-87604(P2012-87604)
(22)【出願日】2012年4月6日
(65)【公開番号】特開2013-218481(P2013-218481A)
(43)【公開日】2013年10月24日
【審査請求日】2014年10月22日
(73)【特許権者】
【識別番号】000004226
【氏名又は名称】日本電信電話株式会社
(74)【代理人】
【識別番号】110001807
【氏名又は名称】特許業務法人磯野国際特許商標事務所
(72)【発明者】
【氏名】宮城 安敏
(72)【発明者】
【氏名】近藤 悟
(72)【発明者】
【氏名】福元 健
(72)【発明者】
【氏名】金子 雅志
【審査官】 三坂 敏夫
(56)【参考文献】
【文献】 特表2010−501942(JP,A)
【文献】 特開2004−361994(JP,A)
【文献】 特開2011−095976(JP,A)
【文献】 特開2005−062928(JP,A)
【文献】 入江 道生 他,「コンシステント・ハッシュ法におけるデータの複製を意識した負荷分散手法」,電子情報通信学会技術研究報告,日本,社団法人電子情報通信学会,2010年10月 7日,第110巻 第224号,69頁〜74頁
(58)【調査した分野】(Int.Cl.,DB名)
G06F 11/20
G06F 17/30
G06F 12/00
(57)【特許請求の範囲】
【請求項1】
クライアントマシンからのリクエストを処理する複数のサーバと、前記クライアントマシンからのリクエストを前記複数のサーバのいずれかに振り分ける管理装置と、を備え、環状のID(IDentifier)空間に、前記複数のサーバが処理する管理対象の複数のデータのすべて、および、前記複数のサーバ、が割り振られ、それぞれの前記サーバが、前記ID空間において自身から所定方向回りに次の前記サーバまでの間に位置する前記データを管理するとともに、当該次の前記サーバから前記所定方向回りにさらに次の前記サーバまでの間に位置する前記データの複製を記憶する分散処理システムと、
前記分散処理システムで扱う前記管理対象のデータをバックアップとして記憶する記憶装置を備えるバックアップシステムと、
を有するデータベースシステムであって、
前記分散処理システム内で前記管理対象のデータの更新を行った場合、前記管理装置および前記複数のサーバのいずれかは、更新したデータを前記バックアップシステムに送信し、
前記バックアップシステムにおける記憶装置は、受信したデータを記憶し、
前記分散処理システム内で複数の前記サーバに障害が発生して前記管理対象のデータを消失した場合、前記管理装置は、前記バックアップシステムの記憶装置に記憶されたデータを用いて、データを消失した前記サーバのデータ復旧を行い、
前記バックアップシステムは、異なる2つ以上の地域それぞれに前記記憶装置を有し、それぞれの前記記憶装置は、前記バックアップのデータを記憶し、
前記分散処理システム内で複数の前記サーバに障害が発生して前記管理対象のデータを消失した場合、前記管理装置は、前記バックアップシステムにおけるいずれかの前記記憶装置に記憶されたデータを用いて、データを消失した前記サーバのデータ復旧を行う
ことを特徴とするデータベースシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、複数のサーバを備えた分散処理システムで扱うデータのバックアップ技術に関する。
【背景技術】
【0002】
近年、クラウドコンピューティングの隆盛に伴い、多量のデータの処理や保持を効率的に行うことが求められている。そこで、複数のサーバを協調動作させることにより効率的な処理を実現する分散処理技術が発展している。
【0003】
分散処理を行う際には、処理対象(管理対象)のデータを、クラスタを構成する各サーバ(以下、「クラスタメンバ」または「メンバ」とも称する。)に振り分けておく必要がある。このとき、クラスタ全体での処理能力を高めるためには、各クラスタメンバが担当するデータ数(データ量)は平均化されていることが望ましい。
【0004】
代表的なデータの振り分け手法として、各データのkeyをハッシュ関数にかけた値(以下、「hash(key)」と称する。)をクラスタメンバ数Nで割った余り、すなわち「hash(key) mod N」を番号として持つクラスタメンバにデータを振り分ける手法がある。この場合、各クラスタメンバに事前に「0」から「N−1」までの番号を割り当てていることが前提となる。このような振り分け手法を用いた場合、クラスタメンバを追加すると、Nの値が変化して、多くのデータについて、担当するクラスタメンバが変更になるため、担当するデータの再配置が必要になる。
【0005】
そこで、クラスタメンバの追加に伴い担当するクラスタメンバが変更になるデータ数を約1/Nに抑える方法として、コンシステント・ハッシュ法[Consistent Hashing](非特許文献1参照)を用いた振り分け手法がある。
【0006】
このコンシステント・ハッシュ法を用いたデータ振り分け手法では、クラスタメンバとデータの双方にID(IDentifier)を割り当て、データのIDからID空間を時計回りに辿った場合に最初に出合ったクラスタメンバをそのデータの担当とする。
【0007】
また、多量のデータの管理をクラスタ構成の分散処理システムで行う場合、あるクラスタメンバに障害が発生した場合でも他のクラスタメンバで処理を継続できるように、データの複製を保持することでデータ冗長化を実現する必要がある。これは、コンシステント・ハッシュ法によるデータ管理手法を用いた分散処理システムにおいても同様である。
【0008】
図4に示すように、コンシステント・ハッシュ法では、クラスタメンバ(メンバ1〜4)とデータ(データA〜D。黒丸で表示)の双方にIDを割り当て、データのIDからID空間を時計回りに辿り最初に出合ったクラスタメンバをそのデータの担当として決定する。そして、担当するクラスタメンバのさらに右隣(時計回りに次)のクラスタメンバに複製データを担当させる。
【0009】
例えば、図4においては、データAはID空間上を時計回りに辿り最初に出合ったメンバ1が担当となり、その複製データはID空間上でメンバ1の右隣にあたるメンバ2に担当させる。このように原本データ・複製データを担当するクラスタメンバを決定することで、クラスタメンバに離脱があった場合でもその複製データを所持しているクラスタメンバが新しくデータを担当するクラスタメンバとなることで対応できるという利点がある。なお、複製データを複数個とる場合には、さらに右隣のクラスタメンバに2個目の複製データを担当させるようにすることもできる。
【0010】
なお、このような手法に使用できるデータベースサーバとしては、例えば、Cassandra(非特許文献2)等に記載されている、複数サーバが動的にクラスタに参加・離脱可能できる分散データベースサーバがある。非特許文献2の技術では、コンシステント・ハッシュ法を用いたデータの均等な分散と、O(1)の高速アクセスを実現している。また、複製情報を複数のサーバに対して持たせることで、耐故障性を高めている。
【0011】
また、激甚災害等が発生し、複数のサーバが同時にダウン(故障)した場合でも、原本データおよび複製データの両方を消失してしまう可能性を低減しておく必要がある。例えば、関東をエリアとするデータセンタエリア(サーバを管理するデータセンタが管轄するエリア)のみに複数のサーバを配置した場合、関東全域に激甚災害等が発生すると、すべてのサーバがダウンし、すべてのデータが消失してしまう可能性がある。したがって、広域なエリアに複数のサーバを分散させておくことが、まず必要になる。
【0012】
ここで、図5に示すように、複数のサーバが全国に跨ってK種類(ここでは5種類)のデータセンタエリアのいずれかに属している場合について考える。なお、図5のID空間では、記号(黒丸、白丸、黒三角、白三角、白四角)が同じサーバは、同じデータセンタエリアに属しているものとする。
【0013】
この場合、関東全域に激甚災害等が発生しても、関東のデータセンタエリアに属するサーバはダウンするが、その他のデータセンタエリアに属するサーバはダウンしない。つまり、コンシステント・ハッシュ法のID空間では、関東のデータセンタエリアのサーバは離脱するが、他のデータセンタエリアのサーバは離脱しない。
【0014】
なお、通常、コンシステント・ハッシュ法のID空間では、サーバの物理位置を考慮せずにサーバを分散(配置)させている。そのため、図5において、ID空間における上部に破線で囲った2つのサーバのように、同じデータセンタエリアに属するサーバが隣り合っていると、そのデータセンタエリア全域に激甚災害等が発生した場合、原本データと複製データの両方を同時に消失してしまう可能性がある。したがって、例えば、コンシステント・ハッシュ法のID空間で、同じ地域のサーバが隣り合わないようにすることで、そのような原本データと複製データの両方を同時に消失してしまう可能性を低減できる。
【先行技術文献】
【非特許文献】
【0015】
【非特許文献1】David Karger et al., “Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web”, [online], 1997, ACM, [平成24年2月20日検索], インターネット<URL:http://www.akamai.com/dl/technical_publications/ConsistenHashingandRandomTreesDistributedCachingprotocolsforrelievingHotSpotsontheworldwideweb.pdf>
【非特許文献2】Avinash Lakshman et al., “Cassandra - A Decentralized Structured Storage System”, [online], [平成24年2月20日検索], インターネット<URL:http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf>
【発明の概要】
【発明が解決しようとする課題】
【0016】
しかしながら、例えば、クラスタ内でソフトウェア障害等が発生し、クラスタ内の複数のサーバが同時にダウンしてしまった場合、原本データと複製データの両方を同時に消失し、容易にデータを復旧できない事態に陥ってしまう可能性がある。
【0017】
そこで、本発明は、前記した事情に鑑みてなされたものであり、分散処理システムにおいて、クラスタ内の複数のサーバが同時にダウンし、原本データと複製データの両方を同時に消失してしまった場合でも、容易にデータを復旧することを課題とする。
【課題を解決するための手段】
【0018】
前記課題を解決するために、本発明は、クライアントマシンからのリクエストを処理する複数のサーバと、前記クライアントマシンからのリクエストを前記複数のサーバのいずれかに振り分ける管理装置と、を備え、環状のID空間に、前記複数のサーバが処理する管理対象の複数のデータのすべて、および、前記複数のサーバ、が割り振られ、それぞれの前記サーバが、前記ID空間において自身から所定方向回りに次の前記サーバまでの間に位置する前記データを管理するとともに、当該次の前記サーバから前記所定方向回りにさらに次の前記サーバまでの間に位置する前記データの複製を記憶する分散処理システムと、前記分散処理システムで扱う前記管理対象のデータをバックアップとして記憶する記憶装置を備えるバックアップシステムと、を有するデータベースシステムであって、前記分散処理システム内で前記管理対象のデータの更新を行った場合、前記管理装置および前記複数のサーバのいずれかは、更新したデータを前記バックアップシステムに送信し、前記バックアップシステムにおける記憶装置は、受信したデータを記憶し、前記分散処理システム内で複数の前記サーバに障害が発生して前記管理対象のデータを消失した場合、前記管理装置は、前記バックアップシステムの記憶装置に記憶されたデータを用いて、データを消失した前記サーバのデータ復旧を行い、前記バックアップシステムは、異なる2つ以上の地域それぞれに前記記憶装置を有し、それぞれの前記記憶装置は、前記バックアップのデータを記憶し、前記分散処理システム内で複数の前記サーバに障害が発生して前記管理対象のデータを消失した場合、前記管理装置は、前記バックアップシステムにおけるいずれかの前記記憶装置に記憶されたデータを用いて、データを消失した前記サーバのデータ復旧を行うことを特徴とする。
【0019】
これによれば、分散処理システムの外部に設けたバックアップシステムの記憶装置によってデータのバックアップを行うため、分散処理システム(クラスタ)内の複数のサーバが同時にダウンし、原本データと複製データの両方を同時に消失してしまった場合でも、バックアップシステムの記憶装置に記憶されたデータを用いて、データを消失したサーバのデータ復旧を容易に行うことができる。
また、これによれば、バックアップシステムにおいて異なる2つ以上の地域それぞれに配置された記憶装置がバックアップのデータを記憶することで、分散処理システム(クラスタ)内でソフトウェア障害等によって複数のサーバが同時にダウンするとともに、激甚災害等で1つの地域のすべてのサーバがダウンした場合でも、バックアップシステムにおける記憶装置のいくつかはダウンせず、管理装置は、そのダウンしていない記憶装置に記憶されたデータを用いて、データを消失したサーバのデータ復旧を容易に行うことができる。
【発明の効果】
【0022】
本発明によれば、分散処理システムにおいて、クラスタ内の複数のサーバが同時にダウンし、原本データと複製データの両方を同時に消失してしまった場合でも、容易にデータを復旧することができる。
【図面の簡単な説明】
【0023】
図1】本実施形態の概要の説明図である。
図2】本実施形態のデータベースシステム等の構成図である。
図3】本実施形態の管理装置による処理の流れを示すフローチャートである。
図4】従来のコンシステント・ハッシュ法の説明図である。
図5】従来のコンシステント・ハッシュ法におけるID空間およびクラスタメンバの物理位置の説明図である。
【発明を実施するための形態】
【0024】
以下、本発明を実施するための形態(以下、実施形態と称する。)について、図面を参照(言及図以外の図も適宜参照)しながら説明する。なお、理解を容易にするために、まず、図1を参照して本実施形態の概要について説明し、その後、本実施形態について説明する。
【0025】
(本実施形態の概要)
図1に示すように、K種類(ここでは5種類)のデータセンタエリア(以下、「地域」とも称する。)がある場合について考える。まず、激甚災害等の対策のため、コンシステント・ハッシュ法のID空間では、同じ地域のサーバが隣り合わないように、サーバを配置する。
【0026】
また、サーバの増設時には、ID空間における新たなクラスタメンバの挿入先を決定した後、その挿入先の両隣のサーバの地域を調査し、その両隣のサーバのいずれも属さない地域のサーバを選択し、そのサーバを増設すればよい(地域が3つ以上の場合)。そうすれば、コンシステント・ハッシュ法のID空間で同じ地域のサーバが隣り合わない状態を維持できる。
【0027】
これにより、ID空間において同じ地域のサーバが隣り合うことがないので、激甚災害等で、3つ以上の地域のうちの1つの地域に存在するすべてのサーバがダウンしても、原本データと複製データの両方が消失する事態を回避することができる。
【0028】
ここで、例えば、クラスタ内でソフトウェア障害が発生し、クラスタ内の複数のサーバが同時にダウンして、原本データと複製データの両方を同時に消失した場合でも、容易にデータを復旧できるように、バックアップ装置を導入する。具体的には、分散処理システムの外部装置として、K種類のデータセンタエリアのうち地理的に離れた二箇所に、それぞれ、第1バックアップ装置5(記憶装置)と第2バックアップ装置6(記憶装置)を配置する。そして、第1バックアップ装置5と第2バックアップ装置6は、それぞれ、クラスタ内の複数のサーバが扱うデータのバックアップを記憶する。
【0029】
これにより、クラスタ内のソフトウェア障害のほかに、1つの地域で激甚災害等が発生してその地域のすべてのサーバがダウンした場合でも、第1バックアップ装置5と第2バックアップ装置6の少なくともいずれかはダウンしないので、そのダウンしてないほうに記憶されたデータを用いることで、消失したデータを容易に復旧できる。
【0030】
具体的には、第1バックアップ装置5は、複数のバックアップサーバ(記憶装置)から構成される。また、第2バックアップ装置6は、複数のストレージ(大容量の記憶装置)から構成される。この複数のストレージは、例えば、Key Valueクラスタ等のクラスタ構成として実現できる。
【0031】
例えば、管理装置4は、データベースクラスタ(複数のサーバからなるクラスタ)に対してのデータ更新を行う際に、同時に、第1バックアップ装置5に対するデータのバックアップを行う。ここで、第1バックアップ装置5のバックアップサーバは、例えば、ランダムアクセス可能なメディアを用いたデータのバックアップを行えばよい。このような第1バックアップ装置5を用いたデータのバックアップを行いつつ、さらに、例えば、第1バックアップ装置5から第2バックアップ装置6へ非同期で定期的(例えば1日に1回)なバックアップ(スナップショット)を行う。第2バックアップ装置6のストレージは、例えば、テープドライブを用いたデータのバックアップを行えばよい。
【0032】
そして、データベースクラスタのソフトウェア障害発生後は、管理装置4が、第1バックアップ装置5または第2バックアップ装置6を用いて、消失したデータの復旧を行えばよい。このデータの復旧は、例えば、データベースクラスタを再度立ち上げ直した後に、第1バックアップ装置5または第2バックアップ装置6からデータを上書きする形で復旧する。データの復旧に、第1バックアップ装置5と第2バックアップ装置6のいずれを用いるかは、データの消失の規模、種類、消失データ特定の可否等により、適宜決定すればよい。また、同時に激甚災害等も発生して第1バックアップ装置5と第2バックアップ装置6のいずれかがダウンしている場合は、ダウンしていないほうをデータ復旧に使えばよい。
【0033】
(実施形態)
次に、本実施形態について説明する。図2に示すように、本実施形態のデータベースシステムSは、分散処理システム1000とバックアップシステム10を備えて構成される。
【0034】
分散処理システム1000は、管理装置4と、クラスタ100を構成する複数のサーバ3を備えている。管理装置4は、インターネット等のネットワーク2を介して、複数のクライアントマシン1と接続されている。
【0035】
通常(障害未発生時)の全体動作の概要について説明すると、クライアントマシン1からのリクエスト(データ処理リクエスト)を、ネットワーク2経由で管理装置4が受け取る。管理装置4は、データのID空間上のサーバ割当表(ID空間管理情報411)に基づいて、そのリクエストを、データ処理を行う複数のサーバ3のいずれかに振り分ける。振り分けられたサーバ3は、そのリクエストの処理を行う。
【0036】
次に、管理装置4の構成について説明する。管理装置4は、コンシステント・ハッシュ法に基づいて、クライアントマシン1からのリクエストを複数のサーバ3(クラスタメンバ)のいずれに振り分けるかを決定するコンピュータ装置である。なお、前記したように、このコンシステント・ハッシュ法では、環状のID空間に、管理対象の複数のデータ、および、データを管理しクラスタ100を構成する複数のサーバ3、が割り振られ、それぞれのサーバ3が、ID空間において自身から時計回り(所定方向回り)に次のサーバ3までの間に位置するデータを管理(担当)するとともに、当該次のサーバ3から時計回りにさらに次のサーバ3までの間に位置するデータの複製を記憶することを前提とする。
【0037】
管理装置4は、記憶部41、処理部42、入力部43、表示部44、通信部45を備える。
記憶部41は、情報を記憶する手段であり、RAM(Random Access Memory)やROM(Read Only Memory)などのメモリ、HDD(Hard Disk Drive)などによって構成される。記憶部41には、ID空間管理情報411、地域名情報412、サーバ管理情報413、第1バックアップ装置管理情報414、第2バックアップ装置管理情報415が格納されている。なお、記憶部41には、処理部42の動作プログラムなども格納されている(図示を省略)。
【0038】
ID空間管理情報411は、管理対象のデータについて所定のハッシュ値変換を行って算出されたIDを用いて、そのデータを担当するサーバ3を管理するための情報である。
【0039】
地域名情報412は、地域IDと、その地域IDに対応する地域名との対応付けを管理するための情報である。
【0040】
サーバ管理情報413は、地域(地域ID)ごとに、当該地域に物理的に存在するすべてのサーバ3との対応付けを管理する情報である。
【0041】
第1バックアップ装置管理情報414は、第1バックアップ装置5を構成するバックアップサーバのIDやアドレス等の情報である。
第2バックアップ装置管理情報415は、第2バックアップ装置6を構成するストレージのIDやアドレス等の情報である。
【0042】
処理部42は、記憶部41に格納された情報に基づいて演算処理を行う手段であり、例えばCPUによって構成される。処理部42は、クラスタ100に対してデータの更新(書き込み)をする際、クラスタ100に対して、データのIDおよび値(データ内容)を送信する。また、処理部42は、そのデータをバックアップとして第1バックアップ装置5に送信する際には、同様に、データのIDおよび値(データ内容)値を送信する。第1バックアップ装置5の各バックアップサーバにアクセスするためのアドレスは、第1バックアップ装置管理情報414に格納されている。なお、バックアップのデータを第1バックアップ装置5に送信するのは、管理装置4でなくても、クラスタ100におけるサーバ3であってもよい。
【0043】
入力部43は、管理装置4のユーザが情報を入力する手段であり、例えば、キーボードやマウスによって実現される。
表示部44は、情報を表示する手段であり、例えば、LCD(Liquid Crystal Display)によって実現される。
通信部45は、外部装置との通信に用いられる通信インタフェースである。
【0044】
バックアップシステム10は、第1バックアップ装置5と第2バックアップ装置6を備えて構成される。
第1バックアップ装置5は、分散処理システム1000で扱う管理対象のデータをバックアップとして記憶する複数のバックアップサーバから構成される。
第2バックアップ装置6は、分散処理システム1000で扱う管理対象のデータをバックアップとして記憶する複数のストレージから構成される。
【0045】
次に、管理装置4による処理について説明する。
図3に示すように、ステップS1において、管理装置4の処理部42は、クラスタ100による分散処理(通常(障害未発生時)のリクエスト処理)を実行する。
【0046】
次に、ステップS2において、処理部42は、第1バックアップ装置5によるバックアップタイミングが到来したか否かを判定し、Yesの場合はステップS3に進み、Noの場合はステップS4に進む。このバックアップタイミングは、例えば、リクエスト処理においてデータ更新が発生するたびでもよいし、あるいは、所定時間(例えば10分)ごとでもよい。
【0047】
ステップS3において、処理部42は、第1バックアップ装置5によるバックアップを実行する。つまり、処理部42は、更新データのIDと値(データ内容)を第1バックアップ装置5に送信し、第1バックアップ装置5のバックアップサーバは受信したデータを記憶する。なお、バックアップのデータを第1バックアップ装置5に送信するのは、管理装置4でなくても、クラスタ100におけるサーバ3であってもよい。
【0048】
次に、ステップS4において、処理部42は、第2バックアップ装置6によるバックアップタイミングが到来したか否かを判定し、Yesの場合はステップS5に進み、Noの場合はステップS6に進む。このバックアップタイミングは、例えば、所定時間(例えば1日)ごとであればよい。
【0049】
ステップS5において、処理部42は、第2バックアップ装置6によるバックアップを実行する。つまり、処理部42は、第1バックアップ装置5および第2バックアップ装置6に指示を出し、第1バックアップ装置5の格納データのIDと値(データ内容)を第2バックアップ装置6に送信させる。第2バックアップ装置6のストレージは受信したデータを記憶する。
【0050】
ステップS6において、処理部42は、クラスタ100内にソフトウェア障害が発生したか否かを判定し、Yesの場合はステップS7に進み、Noの場合はステップS1に戻る。
【0051】
ステップS7において、処理部42は、バックアップに使用すべき装置が第1バックアップ装置5と第2バックアップ装置6のいずれであるかを判定し、第1バックアップ装置5であると判定すればステップS8に進み、第2バックアップ装置6であると判定すればステップS9に進む。この判定は、前記したように、データの消失の規模、種類、消失データ特定の可否等により、適宜決定すればよい。
【0052】
ステップS8において、処理部42は、第1バックアップ装置5によるクラスタ100のデータ復旧を実行する。つまり、第1バックアップ装置5の格納データを用いて、クラスタ100で消失したデータを復旧させる。
【0053】
ステップS9において、処理部42は、第2バックアップ装置6によるクラスタ100のデータ復旧を実行する。つまり、第2バックアップ装置6の格納データを用いて、クラスタ100で消失したデータを復旧させる。
処理部42は、ステップS8またはステップS9の後、ステップS1に戻る。
【0054】
このようにして、本実施形態のデータベースシステムSによれば、分散処理システム1000の外部に設けたバックアップシステム10の記憶装置(第1バックアップ装置5のバックアップサーバ、第2バックアップ装置6のストレージ。以下同様)によってデータのバックアップを行うため、分散処理システム1000(クラスタ100)内の複数のサーバ3が同時にダウンし、原本データと複製データの両方を同時に消失してしまった場合でも、バックアップシステム10の記憶装置に記憶されたデータを用いて、データを消失したサーバ3のデータ復旧を容易に行うことができる。
【0055】
また、バックアップシステム10において異なる2つ以上の地域それぞれに配置された記憶装置がバックアップのデータを記憶することで、分散処理システム1000(クラスタ100)内でソフトウェア障害等によって複数のサーバ3が同時にダウンするとともに、激甚災害等で1つの地域のすべてのサーバ3がダウンした場合でも、バックアップシステム10における記憶装置のいくつかはダウンせず、管理装置4は、そのダウンしていない記憶装置に記憶されたデータを用いて、データを消失したサーバ3のデータ復旧を容易に行うことができる。
【0056】
以上で本実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。
例えば、本実施形態では、クラスタ100内でのソフトウェア障害の発生と、激甚災害等の発生の両方の対策のため、バックアップ装置として異なる地域に配置された第1バックアップ装置5と第2バックアップ装置6の2つを用いたが、クラスタ100内でのソフトウェア障害等の発生の対策のためだけには、バックアップ装置は1つでもよい。
【0057】
また、バックアップ装置へのデータのバックアップのタイミングは、管理対象のデータの更新に対して同期的でも非同期的でもいずれでもよい。
また、分散処理システム1000において負荷分散装置(ロードバランサ)を使用してもよい。
【0058】
また、地域として、データセンタエリアを単位とする場合を例にとって説明したが、データセンタエリアをさらに分割したものや都道府県等の別の単位を採用してもよい。
また、第1バックアップ装置5の記憶装置をバックアップサーバとし、第2バックアップ装置6の記憶装置をストレージとしたが、記憶装置の種類はそれらに限定されず、例えば、両方ともストレージを使用する、あるいは、いずれかに他の記憶装置を使用する等してもよい。
【0059】
また、本実施形態ではコンシステント・ハッシュ法を前提としたが、他の手法を前提としてもよい。
その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
【符号の説明】
【0060】
1 クライアントマシン
2 ネットワーク
3 サーバ
4 管理装置
5 第1バックアップ装置
6 第2バックアップ装置
10 バックアップシステム
41 記憶部
42 処理部
43 入力部
44 表示部
45 通信部
100 クラスタ
411 ID空間管理情報
412 地域名情報
413 サーバ管理情報
414 第1バックアップ装置管理情報
415 第2バックアップ装置管理情報
1000 分散処理システム
S データベースシステム
図1
図2
図3
図4
図5