JP2009151502A - ルートファイルシステムを管理するシステム及び方法 - Google Patents

Abstract

【課題】コンピュータのローカルディスクによる運用を、ローカルディスクに障害が発生した場合に、ディスクレスによる運用に迅速に切り替える。
【解決手段】クラスタ１１とクラスタ１２とイメージサーバ２０とを含むシステムが提供される。クラスタ１１を構成するホスト１０１ａは、自身を動作させるためのルートファイルシステム１１１ａをローカルディスクに有する。一方、イメージサーバ２０は、ホスト１０１ａを動作させるためのルートファイルシステム２２１ａを有しており、ホスト１０１ａは、これをマウントすることで、ルートファイルシステム１２１ａを仮想的に構築する。そして、ホスト１０１ａは、ルートファイルシステム１１１ａが変更された場合に、ルートファイルシステム１１１ａとルートファイルシステム１２１ａとを同期させる。クラスタ１２を構成するホスト１０２ａについても同様である。
【選択図】図２

Description

本発明は、ルートファイルシステムを管理するシステム及び方法に関する。特に、本発明は、コンピュータを動作させるために用いられるルートファイルシステムを管理するシステム及び方法に関する。

近年、複数のコンピュータを一群にまとめたクラスタシステムにおいて、クラスタシステムを構成する個々のコンピュータがディスクを持たないディスクレスクラスタが注目されている。このディスクレスクラスタでは、イメージサーバ上で各コンピュータのルートファイルシステムが管理され、各コンピュータはこのルートファイルシステムをマウントすることにより運用される。
このようなディスクレスによる運用により、各コンピュータの管理は容易になる。ところが、イメージサーバにトラフィックが集中した際にパフォーマンスが低下してしまう。

そのため、パフォーマンスを優先するシステムでは、ローカルハードディスクドライブを用いた運用も提案されている（例えば、特許文献１参照）。この特許文献１の図３に示されたクライアントサーバ構成において、各クライアントは、サーバに接続されたルートファイル記憶からのローカルなルートファイルシステムのコピーを含むローカルなルートファイル記憶を有している。

また、ディスクレス計算機に関しては、アプリケーションに障害が発生した際に、スタック及びレジスタ内容をコアイメージとしてリモートのサーバへ送信し保存する技術（例えば、特許文献２参照）や、ネットワークが一時的に利用できないときや遅いときにローカル不揮発性メモリキャッシュを使用し、ネットワーク状態が改善された後、メモリキャッシュをサーバのストレージボリュームに同期させる技術（例えば、特許文献３参照）がある。

特開平９−３４８２５号公報 特開平８−３２８９１２号公報 特開２００４−１７８５９６号公報

しかしながら、特許文献１のようなローカルハードディスクドライブによる運用では、ローカルハードディスクドライブに障害が発生する可能性がある。障害が発生すると、新しいハードディスクドライブを準備し、システム環境を復旧（再構築）する作業が必要になる。このような作業には、多大な時間と手間がかかるという問題がある。
また、ハードディスクドライブの障害がアプリケーションの実行途中に発生した場合、アプリケーションの状態を障害前の状態に戻すのは困難であるという問題もある。

本発明の目的は、コンピュータのローカルディスクによる運用を、ローカルディスクに障害が発生した場合に、ディスクレスによる運用に迅速に切り替えることにある。
また、本発明の他の目的は、コンピュータの動作中に障害が発生した場合に、コンピュータの動作状態を障害前の状態に容易に戻すことにある。

かかる目的のもと、本発明は、コンピュータを動作させるために用いられるルートファイルシステムを管理するシステムであって、自身を動作させるために用いられる第１のルートファイルシステムを自身のローカルディスクに有するクライアントと、ローカルディスクに障害が発生した場合にクライアントを動作させるために用いられる第２のルートファイルシステムを有するサーバとを備え、クライアントは、第１のルートファイルシステムが変更された場合に、第１のルートファイルシステムの変更された部分の内容と、第２のルートファイルシステムの対応する部分の内容とを同期させる、システムを提供する。

また、このシステムにおいて、クライアントは、ローカルディスクに障害が発生した場合に、サーバが有する第２のルートファイルシステムに基づいて、障害が発生していないローカルディスク上に第１のルートファイルシステムを構築する、ものであってよい。
更に、このシステムにおいて、クライアントは、自身の動作状態を示す状態情報を、第１のルートファイルシステム内、及び、第２のルートファイルシステム内に出力する、ものであってよい。この場合、状態情報は、クライアントで動作するオペレーティングシステム及びアプリケーションの少なくとも何れか一方の動作状態を示すチェックポイント情報を含み、クライアントは、チェックポイント情報の取得元、取得時期、出力する版の個数、出力先の少なくとも何れか１つを定義したチェックポイントポリシに基づいて、チェックポイント情報を出力する、ものであってよい。
更にまた、このシステムにおいて、クライアントは、ローカルディスクに障害が発生したことにより第２のルートファイルシステムを用いて動作した場合に、第２のルートファイルシステム内に出力された状態情報に基づいて、障害が発生する前の動作状態を復元する、ものであってよい。この場合、状態情報は、クライアントで動作するオペレーティングシステム及びアプリケーションの少なくとも何れか一方の動作状態を示すチェックポイント情報を含み、クライアントは、チェックポイント情報の適用の可否、適用する版、読込元の少なくとも何れか１つを定義したリカバリポリシに基づいて、障害が発生する前の動作状態を復元する、ものであってよい。

また、本発明は、ルートファイルシステムを用いて動作するコンピュータであって、自身を動作させるために用いられる第１のルートファイルシステムを記憶する記憶部と、記憶部に障害が発生した場合に自身を動作させるために用いられる第２のルートファイルシステムを、第２のルートファイルシステムを有する他のコンピュータからマウントするマウント部と、第１のルートファイルシステムが変更された場合に、第１のルートファイルシステムの変更された部分の内容と、マウント部によりマウントされた第２のルートファイルシステムの対応する部分の内容とを同期させる処理を行う同期処理部とを備えた、コンピュータも提供する。

更に、本発明は、コンピュータを動作させるために用いられるルートファイルシステムを管理する方法であって、クライアントのローカルディスクに構築された第１のルートファイルシステムを用いてクライアントを動作させるステップと、ローカルディスクに障害が発生した場合にクライアントを動作させるために用いられる第２のルートファイルシステムを、第２のルートファイルシステムを有するサーバからクライアントにマウントするステップと、第１のルートファイルシステムが変更された場合に、第１のルートファイルシステムの変更された部分の内容と、マウントされた第２のルートファイルシステムの対応する部分の内容とを同期させるステップとを含む、方法も提供する。

本発明によれば、コンピュータのローカルディスクによる運用を、ローカルディスクに障害が発生した場合に、ディスクレスによる運用に迅速に切り替えることができる。

以下、添付図面を参照して、本発明を実施するための最良の形態（以下、「実施の形態」という）について詳細に説明する。
まず、本実施の形態の前提として、一般的なディスクレスクラスタのシステム構成について説明する。
図１は、ディスクレスでクラスタを運用する場合の一般的なシステム構成である。
このシステムは、クラスタ１１と、クラスタ１２と、イメージサーバ２０とを含む。
このうち、クラスタ１１は、ホスト１０１ａ，１０１ｂ，１０１ｃ，…からなり、クラスタ１２は、ホスト１０２ａ，１０２ｂ，１０２ｃ，…からなり、各ホストは、イメージサーバ２０と図示しないネットワークを介して接続されている。
また、イメージサーバ２０では、クラスタ１１内の各ホストの運用するためのルートイメージ２０１と、クラスタ１２内の各ホストを運用するためのルートイメージ２０２とが集中管理されている。ここで、ルートイメージ２０１は、ホスト１０１ａのルートファイルシステム２２１ａ、ホスト１０１ｂのルートファイルシステム２２１ｂ、ホスト１０１ｃのルートファイルシステム２２１ｃ、…を圧縮したファイルであり、ルートイメージ２０２は、ホスト１０２ａのルートファイルシステム２２２ａ、ホスト１０２ｂのルートファイルシステム２２２ｂ、ホスト１０２ｃのルートファイルシステム２２２ｃ、…を圧縮したファイルである。

このような構成を有するシステムにおいて、ホスト１０１ａ，１０１ｂ，１０１ｃ，…には、それぞれ、ルートファイルシステム２２１ａ，２２１ｂ，２２１ｃがマウントされることで、ルートファイルシステム１２１ａ，１２１ｂ，１２１ｃが仮想的に構築されている。これにより、ホスト１０１ａ，１０１ｂ，１０１ｃ，…は、ディスクレスで動作することが可能となる。また、ホスト１０２ａ，１０２ｂ，１０２ｃ，…には、それぞれ、ルートファイルシステム２２２ａ，２２２ｂ，２２２ｃがマウントされることで、ルートファイルシステム１２２ａ，１２２ｂ，１２２ｃが仮想的に構築されている。これにより、ホスト１０２ａ，１０２ｂ，１０２ｃ，…は、ディスクレスで動作することが可能となる。

ところが、ディスクレスによる運用は、クラスタ内のホストの管理が容易である反面、イメージサーバ２０にネットワークのトラフィックが集中した場合、パフォーマンスが低下してしまうという課題がある。
このようにパフォーマンスの観点から、ディスクレスクラスタによる運用が困難な場合には、ローカルハードディスクドライブ（以下、「ローカルディスク」という）に構築したルートファイルシステムを使用した運用が考えられる。但し、ローカルディスクによる運用に際しては、ハードディスクドライブの故障を考慮しなければならない。

そこで、本実施の形態では、次のようなシステム構成を採用している。
図２は、本実施の形態におけるハードディスクドライブの障害を考慮したクラスタのシステム構成である。
このシステムは、図１に示したシステム構成と同様に、クラスタ１１と、クラスタ１２と、イメージサーバ２０とを含む。また、クラスタ１１が、ホスト１０１ａ，１０１ｂ，１０１ｃ，…からなり、クラスタ１２が、ホスト１０２ａ，１０２ｂ，１０２ｃ，…からなり、各ホストが、イメージサーバ２０と図示しないネットワークを介して接続されている点や、イメージサーバ２０で、クラスタ１１内の各ホストを運用するためのルートイメージ２０１と、クラスタ１２内の各ホストを運用するためのルートイメージ２０２とが集中管理されている点も、図１のシステム構成と同様である。

但し、図２では、図１のシステム構成とは異なり、ホスト１０１ａ，１０１ｂ，１０１ｃ，…のローカルディスク上には、それぞれ、ルートファイルシステム１１１ａ，１１１ｂ，１１１ｃ，…が構築されている。加えて、ホスト１０１ａ，１０１ｂ，１０１ｃ，…には、ルートファイルシステム２２１ａ，２２１ｂ，２２１ｃ，…がマウントされることで、ルートファイルシステム１２１ａ，１２１ｂ，１２１ｃ，…が仮想的に構築されている。また、ホスト１０２ａ，１０２ｂ，１０２ｃ，…のローカルディスク上には、それぞれ、ルートファイルシステム１１２ａ，１１２ｂ，１１２ｃ，…が構築されている。加えて、ホスト１０１ａ，１０１ｂ，１０１ｃ，…には、ルートファイルシステム２２２ａ，２２２ｂ，２２２ｃ，…がマウントされることで、ルートファイルシステム１２２ａ，１２２ｂ，１２２ｃ，…が仮想的に構築されている。そして、図中、ルートファイルシステム１１１ａとルートファイルシステム１２１ａとの間に矢印で示すように、これらのルートファイルシステムを常に同期させておく。また、同様に、ルートファイルシステム１１２ａとルートファイルシステム１２２ａも常に同期させておく。

尚、本実施の形態では、クライアントの一例として各ホストを設け、サーバの一例としてイメージサーバ２０を設けている。また、第１のルートファイルシステムの一例として、各ホスト上のルートファイルシステムを用い、第２のルートファイルシステムの一例として、イメージサーバ２０上のルートファイルシステムを用いている。

即ち、本実施の形態では、通常はローカルディスクで運用するクラスタシステムにおいて、ローカルディスク上に構築したルートファイルシステムとイメージサーバ２０上に構築したルートファイルシステムとを二重化している。そして、これらのルートファイルシステムの内容を常時同期させている。これにより、ローカルディスクに障害が発生した場合に、システム停止時間を最小限に留め、速やかにディスクレスによる運用に切り替え、同一のシステム環境で運用を再開できるようになる。
また、本実施の形態では、システム及びアプリケーションのチェックポイント情報等を、ローカルディスク上のルートファイルシステム内、及び、イメージサーバ２０上のルートファイルシステム内に保存し、これらを同期させる。これにより、障害前のシステム及びアプリケーションの状態に復旧することが可能となる。この場合に、本実施の形態では、チェックポイント情報の保存や障害前の状態への復旧を予め設定したポリシに基づいて行うことも可能とする。

ここで、チェックポイントポリシは、チェックポイント情報を取得する元となるアプリケーションのリスト、チェックポイント情報を取得又は保存するタイミング（例えば、ｘ分ごと）、何世代前までのチェックポイント情報を保持しておくか（保存すべきチェックポイント情報の版の個数）、チェックポイント情報を格納したファイルの出力先等を規定するポリシである。
また、リカバリポリシは、障害前の状態に復旧する際に、チェックポイント情報を適用するかどうか、適用する場合には、適用するチェックポイント情報が保存されている場所（読込元）、何世代前のチェックポイントへ戻るか（適用するチェックポイント情報の版）等を規定するポリシである。

本実施の形態において、このチェックポイントポリシやリカバリポリシは、それぞれ、ホストごとに設定することができる。
或いは、例えば同じクラスタを構成するホストのように、同一のシステム環境で同一のアプリケーションを動作させているような複数のホストは、ポリシを共有してもよい。

図３は、複数のホスト間でチェックポイントポリシ及びリカバリポリシを共有する様子を示したものである。ここでは、イメージサーバ２０に、ホスト１０ａと、ホスト１０ｂと、ホスト１０ｘと、ホスト１０ｙとが接続されている場合を考える。
この場合、イメージサーバ２０は、ホスト１０ａ用のルートイメージ２２ａ、ホスト１０ｂ用のルートイメージ２２ｂ、ホスト１０ｘ用のルートイメージ２２ｘ、ホスト１０ｙ用のルートイメージ２２ｙを記憶している。

ここで、各ルートイメージ内のルートファイルシステムにおけるディレクトリ「/etc」の直下にある「/policy」には、例えば、各アプリケーションの動作の幾つかのパターンが定義されるとする。そして、例えば、各アプリケーションがその幾つかのパターンのうちどの動作を行うかが、「/etc/sync/policy」に定義されるとする。このような場合に、各アプリケーションの動作のパターンは、同一のシステム環境のホストであれば、ある程度決まってくるため、共有することが可能である。そこで、図では、四角で囲んで示したように、ホスト１０ａとホスト１０ｂとの間で「/policy」の部分を共有し、ホスト１０ｘとホスト１０ｙとの間で「/policy」の部分を共有している。

以下、本実施の形態における動作について説明する。尚、以下では、本実施の形態における動作を３つの運用モード（以下、単に「モード」という）に分けて説明する。
第１のモードは、ローカルディスク上のルートファイルシステムとイメージサーバ２０上のルートファイルシステムとの同期を取りながら運用するモードである。以下では、このモードを「通常オペレーションモード」と称する。
第２のモードは、ローカルディスクに障害が発生し、イメージサーバ２０上のルートファイルシステムのみで運用するモードである。以下では、このモードを「リモートディスクオペレーションモード」と称する。
第３のモードは、新しいハードディスクの準備が完了し、イメージサーバ２０上のルートファイルシステムによるリカバリを行うモードである。以下では、このモードを「リカバリオペレーションモード」と称する。

まず、これら３つのモードについて、概略動作の説明を行い、その後、詳細動作の説明を行う。また、詳細動作の説明の前に、ホスト１０の機能構成についても説明する。尚、これまで述べてきた各ホストは、全て同じ機能構成を有しているので、これらを区別する必要がない場合には、このように「ホスト１０」と表現するものとする。

１．通常オペレーションモード（概略動作）
図４は、このモードでの概略動作を示した図である。尚、イメージサーバ２０には、実際には複数のホスト１０が接続されるが、ここではその中でホスト１０ａに着目する。
まず、ホスト１０ａは、ローカルディスク１３ａにインストールされているブートイメージから起動する。そして、ローカルディスク１３ａ上のルートファイルシステム１１ａをＮＦＳ（Network File System）マウント（以下、単に「マウント」という）してＯＳ（Operating System）を運用する。
一方で、ホスト１０ａは、イメージサーバ２０上のルートファイルシステム２２ａをリモートマウントして仮想的なルートファイルシステム１２ａを構築する。そして、ローカルディスク１３ａ上のルートファイルシステム１１ａと、イメージサーバ２０上のルートファイルシステム２２ａとを例えば定期的に同期し、常時、ディスクレスによる運用に移行できる状態にしておく。

また、ホスト１０ａは、チェックポイントポリシに基づいて、例えば定期的に、チェックポイント情報を、ローカルディスク１３ａ上のルートファイルシステム１１ａ内、及び／又は、イメージサーバ２０上のルートファイルシステム２２ａ内に保存する。

以上述べたこのモードにおける動作をまとめると、次のようになる。
まず、このモードでは、ローカルディスク１３ａ、イメージサーバ２０（ホスト１０ａ用のルートイメージ）の何れも使用可能である。また、ブートイメージ、ルートファイルシステムは、ローカルディスク１３ａ、イメージサーバ２０の何れにも存在する。更に、チェックポイント情報の生成方法及び出力先は、チェックポイントポリシに基づいて決定される。ここで、チェックポイント情報の生成方法とは、例えば、チェックポイント情報を生成する対象となるアプリケーションのリストや、チェックポイント情報を生成するタイミングである。

２．リモートディスクオペレーションモード（概略動作）
図５は、このモードでの概略動作を示した図である。尚、イメージサーバ２０には、実際には複数のホスト１０が接続されるが、ここではその中でホスト１０ａに着目する。
このモードは、ホスト１０ａのローカルディスク１３ａに障害が発生した場合のモードである。ローカルディスク１３ａに障害が発生したことは、ローカルディスク１３ａに「×」印を付すことで示している。このような場合に、まず、ホスト１０ａは、イメージサーバ２０上のブートイメージから起動する。そして、イメージサーバ２０上のルートファイルシステム２２ａをマウントして仮想的なルートファイルシステム１２ａを構築し、ＯＳを運用する。

また、ホスト１０ａは、起動時に、リカバリポリシに基づいて、イメージサーバ２０上のルートファイルシステム２２ａ内に保存されているチェックポイント情報からリカバリを行う。尚、図中、リカバリを行うのに用いるチェックポイント情報の保存先を四角で囲んで示している。更に、新しいハードディスクドライブが準備できるまでの間、チェックポイントポリシに基づいて、例えば定期的に、マウントしているイメージサーバ２０上のルートファイルシステム２２ａ内にチェックポイント情報を保存する。

以上述べたこのモードにおける動作をまとめると、次のようになる。
まず、このモードでは、ローカルディスク１３ａは使用不可であるが、イメージサーバ２０（ホスト１０ａ用のルートイメージ）は使用可能である。また、ブートイメージ、ルートファイルシステムは、イメージサーバ２０にのみ存在する。更に、チェックポイント情報の生成方法は、チェックポイントポリシに基づいて決定されるが、チェックポイント情報の出力先は、イメージサーバ２０になる。また、チェックポイント情報の適用方法は、リカバリポリシに基づいて決定されるが、チェックポイント情報の読込元は、イメージサーバ２０になる。ここで、チェックポイント情報の生成方法とは、例えば、チェックポイント情報を生成する対象となるアプリケーションのリストや、チェックポイント情報を生成するタイミングであり、チェックポイント情報の適用方法とは、例えば、チェックポイント情報の適用の可否である。

３．リカバリオペレーションモード（概略動作）
図６は、このモードでの概略動作を示した図である。尚、イメージサーバ２０には、実際には複数のホスト１０が接続されるが、ここではその中でホスト１０ａに着目する。
このモードは、ホスト１０ａの新しいハードディスクドライブ１４ａが準備できた場合のモードである。新しいハードディスクドライブ１４ａが準備できるまでの間、ホスト１０ａは、イメージサーバ２０上のルートファイルシステム２２ａをマウントし、仮想的なルートファイルシステム１２ａを構築することで運用されていた。このモードは、このような状況の下で、イメージサーバ２０上のルートファイルシステム２２ａ（仮想的なルートファイルシステム１２ａ）からシステムを復旧するものである。また、その際、リカバリポリシに基づいて、イメージサーバ２０上のルートファイルシステム２２ａ内に保存されたチェックポイント情報からシステムを復旧する。これにより、ホスト１０ａは、通常オペレーションモードに復帰することが可能な状態となる。

以上述べたこのモードにおける動作をまとめると、次のようになる。
まず、このモードでは、ローカルディスク、イメージサーバ２０（ホスト１０ａ用のルートイメージ）の何れも使用可能である。また、ブートイメージ、ルートファイルシステムは、イメージサーバ２０にのみ存在する。更に、チェックポイント情報の適用方法は、リカバリポリシに基づいて決定されるが、チェックポイント情報の読込元は、イメージサーバ２０になる。ここで、チェックポイント情報の適用方法とは、例えば、チェックポイント情報の適用の可否である。

４．ホスト１０の機能構成
図７は、ホスト１０の機能構成例を示したブロック図である。
図示するように、ホスト１０は、記憶部３１と、ブート部３２と、ＯＳ起動部３３と、通信部３４と、マウント部３５と、同期処理部３６と、チェックポイント取得部３７と、リカバリ処理部３８とを備える。

記憶部３１は、例えば、磁気ディスクで実現され、ブートイメージやルートファイルシステムを記憶する。尚、この記憶部３１は、上記１〜３におけるローカルディスクに相当し、下記５〜６では、ローカルディスク１３として説明する。
ブート部３２は、記憶部３１に記憶されたブートイメージ又は通信部３４がイメージサーバ２０からダウンロードしたブートイメージに基づいて、ブートを行う。
ＯＳ起動部３３は、記憶部３１上に構築されたルートファイルシステムをマウントし、或いは、イメージサーバ２０上に構築されたルートファイルシステムを通信部３４を介してマウントし、ＯＳを起動する。
通信部３４は、イメージサーバ２０との間で情報の送受信を行う。ここで、通信部３４により送受信される情報には、ブートイメージ、ルートファイルシステムの情報、チェックポイント情報、チェックポイントポリシ、リカバリポリシ等がある。

マウント部３５は、イメージサーバ２０上のルートファイルシステムや、新しく準備された記憶部３１をマウントする。
同期処理部３６は、記憶部３１上のルートファイルシステムとイメージサーバ２０上のルートファイルシステムの同期をとる処理を行う。ここで、同期をとる処理としては、例えば、記憶部３１上のルートファイルシステムに対する更新をイメージサーバ２０上のルートファイルシステムに反映させる処理や、記憶部３１上のルートファイルシステムに対する更新を破棄する処理等がある。
チェックポイント取得部３７は、チェックポイントポリシに基づいて、アプリケーションのチェックポイント情報を取得する。そして、チェックポイント情報を記憶部３１に出力し、或いは、通信部３４を介してイメージサーバ２０に出力する。本実施の形態では、状態情報を出力する出力部の一例として、チェックポイント取得部３７を設けている。

リカバリ処理部３８は、イメージサーバ２０上のルートファイルシステムに基づいて記憶部３１にルートファイルシステムを構築する。即ち、本実施の形態では、第１のルートファイルシステムを構築する構築部の一例として、リカバリ処理部３８を設けている。また、リカバリポリシに基づいて、アプリケーションの障害前の状態を復元する。即ち、本実施の形態では、動作状態を復元する復元部の一例として、リカバリ処理部３８を設けている。
尚、上記構成のうち、マウント部３５、同期処理部３６、チェックポイント取得部３７、リカバリ処理部３８は、ＯＳ起動部３３により起動されたＯＳによって実現される機能である。

５．通常オペレーションモード（詳細動作）
図８は、このモードにおける詳細動作を示したフローチャートである。
ホスト１０に電源が投入されると、ブート部３２は、ローカルディスク１３上のブートイメージからローカルディスクブートを実行する（ステップ３０１）。尚、電源の投入時にどのブートイメージからブートするかは、例えば、ＢＩＯＳに設定しておくとよい。
次に、ＯＳ起動部３３は、ローカルディスク１３上のルートファイルシステムをマウントし、ＯＳを起動する（ステップ３０２）。これにより、マウント部３５と、同期処理部３６と、チェックポイント取得部３７と、リカバリ処理部３８の各機能が実現されることになる。

その後、マウント部３５は、イメージサーバ２０上のルートファイルシステムに関する情報を通信部３４を介して受け取り、このルートファイルシステムをローカルディスク１３上の所定のマウントポイントへマウントする（ステップ３０３）。このとき、イメージサーバ２０上のどのルートファイルシステムをマウントすればよいかは、ローカルディスク１３内の設定ファイルに基づいて、判断するとよい。また、具体的なマウント方法としては、例えば、ルート（/）の配下に、「/mount」というディレクトリを用意し、ここにイメージサーバ２０上のルートファイルシステムにおけるルート（/）をマウントする方法が考えられる。
そして、ローカルディスク１３上のルートファイルシステムとイメージサーバ２０上のルートファイルシステムの同期が開始される（ステップ３０４）。例えば、同期処理部３６が、ローカルディスク１３上のルートファイルシステムに対する更新を検出し、その検出した更新を通信部３４を介してイメージサーバ２０に送信する。或いは、ローカルディスク１３上のルートファイルシステムに対する更新を破棄するようにしてもよい。

また、チェックポイント取得部３７は、チェックポイントポリシを通信部３４を介して読み込む（ステップ３０５）。尚、ここでのチェックポイントポリシの読込元は、ローカルディスク１３であってもイメージサーバ２０であってもよい。そして、チェックポイントポリシの中に、チェックポイント情報を保存する対象のアプリケーションがあるかどうかを判定する（ステップ３０６）。

ここで、チェックポイント情報を保存する対象のアプリケーションがないと判定されれば、ホスト１０は、そのまま運用を継続する（ステップ３１２）。
一方、チェックポイント情報を保存する対象のアプリケーションがあると判定されれば、チェックポイント取得部３７は、チェックポイント情報を取得する間隔を設定し（ステップ３０７）、何世代前までのチェックポイント情報を保存するかを設定し（ステップ３０８）、チェックポイント情報の出力先を設定する（ステップ３０９）。この状態で、ユーザの指示等があると、アプリケーションを実行し（ステップ３１０）、チェックポイント情報の取得を開始する（ステップ３１１）。そして、ホスト１０は、運用を継続する（ステップ３１２）。

６．リモートディスクオペレーションモード（詳細動作）
図９は、このモードにおける詳細動作を示したフローチャートである。
ホスト１０に電源が投入されると、ブート部３２は、イメージサーバ２０から通信部３４を介してブートイメージをダウンロードし、ネットワークブートを実行する（ステップ３２１）。尚、電源の投入時にどのブートイメージからブートするかは、例えば、ＢＩＯＳに設定しておくとよい。
次に、ＯＳ起動部３３は、イメージサーバ２０上のルートファイルシステムを通信部３４を介してマウントし、ＯＳを起動する（ステップ３２２）。このとき、イメージサーバ２０上のどのルートファイルシステムをマウントすればよいかは、ブートイメージに付された情報に基づいて、判断するとよい。これにより、マウント部３５と、同期処理部３６と、チェックポイント取得部３７と、リカバリ処理部３８の各機能が実現されることになる。

その後、リカバリ処理部３８は、イメージサーバ２０上のリカバリポリシを通信部３４を介して読み込む（ステップ３２３）。そして、リカバリポリシにおいて、チェックポイント情報を適用すべき旨が規定されているかどうかを判定する（ステップ３２４）。
ここで、チェックポイント情報を適用すべき旨が規定されていないと判定されれば、ステップ３２９以降のチェックポイント情報取得処理へ移行する。
一方、チェックポイント情報を適用すべき旨が規定されていると判定されれば、リカバリ処理部３８は、何世代前のチェックポイント情報に基づいて復旧するかを設定し（ステップ３２５）、チェックポイント情報の読込元を設定する（ステップ３２６）。この状態で、ユーザの指示等があると、チェックポイント情報を保存しておいたアプリケーションを実行し（ステップ３２７）、リカバリポリシに基づいて、保存されたチェックポイント情報からリカバリを実行する（ステップ３２８）。

また、チェックポイント取得部３７は、イメージサーバ２０上のチェックポイントポリシを通信部３４を介して読み込む（ステップ３２９）。そして、チェックポイントポリシの中に、チェックポイント情報を保存する対象のアプリケーションがあるかどうかを判定する（ステップ３３０）。

ここで、チェックポイント情報を保存する対象のアプリケーションがないと判定されれば、ホスト１０は、そのままローカルディスク１３が準備できるまで運用を継続する（ステップ３３６）。
一方、チェックポイント情報を保存する対象のアプリケーションがあると判定されれば、チェックポイント取得部３７は、チェックポイント情報を取得する間隔を設定し（ステップ３３１）、何世代前までのチェックポイント情報を保存するかを設定し（ステップ３３２）、チェックポイント情報の出力先を設定する（ステップ３３３）。この状態で、ユーザの指示等があると、アプリケーションを実行し（ステップ３３４）、チェックポイント情報の取得を開始する（ステップ３３５）。そして、ホスト１０は、ローカルディスク１３が準備できるまで運用を継続する（ステップ３３６）。
尚、このフローチャートでは、ステップ３３４でアプリケーションを実行することとした。しかしながら、ステップ３２７で既にアプリケーションが実行されている場合は、改めてアプリケーションを実行する必要はなく、実行中のアプリケーションからチェックポイント情報を取得すればよい。

７．リカバリオペレーションモード（詳細動作）
図１０は、このモードにおける詳細動作を示したフローチャートである。
ホスト１０に電源が投入されると、ブート部３２は、イメージサーバ２０から通信部３４を介してブートイメージをダウンロードし、ネットワークブートを実行する（ステップ３４１）。尚、電源の投入時にどのブートイメージからブートするかは、例えば、ＢＩＯＳに設定しておくとよい。
次に、ＯＳ起動部３３は、イメージサーバ２０上のルートファイルシステムを通信部３４を介してマウントし、ＯＳを起動する（ステップ３４２）。これにより、マウント部３５と、同期処理部３６と、チェックポイント取得部３７と、リカバリ処理部３８の各機能が実現されることになる。

その後、マウント部３５は、新しく準備したローカルディスク１３を所定のマウントポイントへマウントする（ステップ３４３）。ここで、具体的なマウント方法としては、例えば、ルート（/）の配下に、「/mount」というディレクトリを用意し、ここに新しく準備したローカルディスク１３をマウントする方法が考えられる。
また、リカバリ処理部３８は、イメージサーバ２０上のリカバリポリシを通信部３４を介して読み込む（ステップ３４４）。そして、イメージサーバ２０上のルートファイルシステムに基づいて、ローカルディスク１３上のルートファイルシステムのリカバリを行い（ステップ３４５）、イメージサーバ２０上のチェックポイント情報をローカルディスク１３上にコピーする（ステップ３４６）。最後に、ブート部３２は、システムを再起動し、ステップ３４５でローカルディスク１３にコピーされたブートイメージからブートする（ステップ３４７）。
これにより、ホスト１０は、通常オペレーションモードで起動することが可能となる。

以上、本実施の形態について詳細に述べてきた。
ところで、上記説明では、アプリケーションのチェックポイント情報（途中状態）をローカルディスク１３内又はイメージサーバ２０内に保存するようにした。しかしながら、保存する対象は、これに限られるものではない。例えば、ＯＳのチェックポイント情報を保存するようにしてもよい。また、ＯＳ等の設定情報（ＣＰＵレジスタ、メモリ、テンポラリファイル等）を保存するものであってもよい。即ち、本実施の形態は、コンピュータの動作状態を示す状態情報をローカルディスク１３又はイメージサーバ２０に保存するものとして捉えることができる。

最後に、本実施の形態を適用するのに好適なコンピュータのハードウェア構成について説明する。図１１は、このようなコンピュータのハードウェア構成の一例を示した図である。図示するように、コンピュータは、演算手段であるＣＰＵ(Central Processing Unit）９０ａと、Ｍ／Ｂ(マザーボード）チップセット９０ｂを介してＣＰＵ９０ａに接続されたメインメモリ９０ｃと、同じくＭ／Ｂチップセット９０ｂを介してＣＰＵ９０ａに接続された表示機構９０ｄとを備える。また、Ｍ／Ｂチップセット９０ｂには、ブリッジ回路９０ｅを介して、ネットワークインターフェイス９０ｆと、磁気ディスク装置（ＨＤＤ）９０ｇと、音声機構９０ｈと、キーボード／マウス９０ｉと、フレキシブルディスクドライブ９０ｊとが接続されている。

尚、図１１において、各構成要素は、バスを介して接続される。例えば、ＣＰＵ９０ａとＭ／Ｂチップセット９０ｂの間や、Ｍ／Ｂチップセット９０ｂとメインメモリ９０ｃの間は、ＣＰＵバスを介して接続される。また、Ｍ／Ｂチップセット９０ｂと表示機構９０ｄとの間は、ＡＧＰ（Accelerated Graphics Port）を介して接続されてもよいが、表示機構９０ｄがＰＣＩ Ｅｘｐｒｅｓｓ対応のビデオカードを含む場合、Ｍ／Ｂチップセット９０ｂとこのビデオカードの間は、ＰＣＩ Ｅｘｐｒｅｓｓ（ＰＣＩｅ）バスを介して接続される。また、ブリッジ回路９０ｅと接続する場合、ネットワークインターフェイス９０ｆについては、例えば、ＰＣＩ Ｅｘｐｒｅｓｓを用いることができる。また、磁気ディスク装置９０ｇについては、例えば、シリアルＡＴＡ（AT Attachment）、パラレル転送のＡＴＡ、ＰＣＩ（Peripheral Components Interconnect）を用いることができる。更に、キーボード／マウス９０ｉ、及び、フレキシブルディスクドライブ９０ｊについては、ＵＳＢ（Universal Serial Bus）を用いることができる。

ここで、本発明は、全てハードウェアで実現してもよいし、全てソフトウェアで実現してもよい。また、ハードウェア及びソフトウェアの両方により実現することも可能である。また、本発明は、コンピュータ、データ処理システム、コンピュータプログラムとして実現することができる。このコンピュータプログラムは、コンピュータにより読取り可能な媒体に記憶され、提供され得る。ここで、媒体としては、電子的、磁気的、光学的、電磁的、赤外線又は半導体システム（装置又は機器）、或いは、伝搬媒体が考えられる。また、コンピュータにより読取り可能な媒体としては、半導体、ソリッドステート記憶装置、磁気テープ、取り外し可能なコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、リジッド磁気ディスク、及び光ディスクが例示される。現時点における光ディスクの例には、コンパクトディスク−リードオンリーメモリ（ＣＤ−ＲＯＭ）、コンパクトディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）及びＤＶＤが含まれる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態には限定されない。本発明の精神及び範囲から逸脱することなく様々に変更したり代替態様を採用したりすることが可能なことは、当業者に明らかである。

本発明の実施の形態の前提となる一般的なディスクレスクラスタのシステム構成を示した図である。 本発明の実施の形態におけるハードディスクドライブの障害を考慮したクラスタのシステム構成を示した図である。 本発明の実施の形態において複数のホスト間でチェックポイントポリシ及びリカバリポリシを共有する様子を説明するための図である。 本発明の実施の形態における通常オペレーションモードでのホストの概略動作を示した図である。 本発明の実施の形態におけるリモートディスクオペレーションモードでのホストの概略動作を示した図である。 本発明の実施の形態におけるリカバリオペレーションモードでのホストの概略動作を示した図である。 本発明の実施の形態におけるホストの機能構成例を示したブロック図である。 本発明の実施の形態における通常オペレーションモードでのホストの詳細動作を示したフローチャートである。 本発明の実施の形態におけるリモートディスクオペレーションモードでのホストの詳細動作を示したフローチャートである。 本発明の実施の形態におけるリカバリオペレーションモードでのホストの詳細動作を示したフローチャートである。 本発明の実施の形態を適用可能なコンピュータのハードウェア構成を示した図である。

符号の説明

１０…ホスト、２０…イメージサーバ、３１…記憶部、３２…ブート部、３３…ＯＳ起動部、３４…通信部、３５…マウント部、３６…同期処理部、３７…チェックポイント取得部、３８…リカバリ処理部

Claims (11)

1. コンピュータを動作させるために用いられるルートファイルシステムを管理するシステムであって、
   自身を動作させるために用いられる第１のルートファイルシステムを自身のローカルディスクに有するクライアントと、
   前記ローカルディスクに障害が発生した場合に前記クライアントを動作させるために用いられる第２のルートファイルシステムを有するサーバと
   を備え、
   前記クライアントは、前記第１のルートファイルシステムが変更された場合に、当該第１のルートファイルシステムの変更された部分の内容と、前記第２のルートファイルシステムの対応する部分の内容とを同期させる、システム。
2. 前記クライアントは、前記ローカルディスクに障害が発生した場合に、前記サーバが有する前記第２のルートファイルシステムに基づいて、当該障害が発生していないローカルディスク上に前記第１のルートファイルシステムを構築する、請求項１のシステム。
3. 前記クライアントは、自身の動作状態を示す状態情報を、前記第１のルートファイルシステム内、及び、前記第２のルートファイルシステム内に出力する、請求項１のシステム。
4. 前記状態情報は、前記クライアントで動作するオペレーティングシステム及びアプリケーションの少なくとも何れか一方の動作状態を示すチェックポイント情報を含み、
   前記クライアントは、前記チェックポイント情報の取得元、取得時期、出力する版の個数、出力先の少なくとも何れか１つを定義したチェックポイントポリシに基づいて、前記チェックポイント情報を出力する、請求項３のシステム。
5. 前記クライアントは、前記ローカルディスクに障害が発生したことにより前記第２のルートファイルシステムを用いて動作した場合に、当該第２のルートファイルシステム内に出力された前記状態情報に基づいて、当該障害が発生する前の前記動作状態を復元する、請求項３のシステム。
6. 前記状態情報は、前記クライアントで動作するオペレーティングシステム及びアプリケーションの少なくとも何れか一方の動作状態を示すチェックポイント情報を含み、
   前記クライアントは、前記チェックポイント情報の適用の可否、適用する版、読込元の少なくとも何れか１つを定義したリカバリポリシに基づいて、前記障害が発生する前の前記動作状態を復元する、請求項５のシステム。
7. ルートファイルシステムを用いて動作するコンピュータであって、
   自身を動作させるために用いられる第１のルートファイルシステムを記憶する記憶部と、
   前記記憶部に障害が発生した場合に自身を動作させるために用いられる第２のルートファイルシステムを、当該第２のルートファイルシステムを有する他のコンピュータからマウントするマウント部と、
   前記第１のルートファイルシステムが変更された場合に、当該第１のルートファイルシステムの変更された部分の内容と、前記マウント部によりマウントされた前記第２のルートファイルシステムの対応する部分の内容とを同期させる処理を行う同期処理部と
   を備えた、コンピュータ。
8. 前記記憶部に障害が発生した場合に、前記他のコンピュータが有する前記第２のルートファイルシステムに基づいて、当該障害が発生していない記憶部上に前記第１のルートファイルシステムを構築する構築部を更に備えた、請求項７のコンピュータ。
9. 自身の動作状態を示す状態情報を、前記第１のルートファイルシステム内、及び、前記第２のルートファイルシステム内に出力する出力部を更に備えた、請求項７のコンピュータ。
10. 前記記憶部に障害が発生したことにより前記第２のルートファイルシステムを用いて動作した場合に、当該第２のルートファイルシステム内に出力された前記状態情報に基づいて、当該障害が発生する前の前記動作状態を復元する復元部を更に備えた、請求項９のコンピュータ。
11. コンピュータを動作させるために用いられるルートファイルシステムを管理する方法であって、
    クライアントのローカルディスクに構築された第１のルートファイルシステムを用いて当該クライアントを動作させるステップと、
    前記ローカルディスクに障害が発生した場合に前記クライアントを動作させるために用いられる第２のルートファイルシステムを、当該第２のルートファイルシステムを有するサーバから当該クライアントにマウントするステップと、
    前記第１のルートファイルシステムが変更された場合に、当該第１のルートファイルシステムの変更された部分の内容と、マウントされた前記第２のルートファイルシステムの対応する部分の内容とを同期させるステップと
    を含む、方法。

Images