(57)【特許請求の範囲】
【請求項１】
コンピューティング環境のリソース・グループに対する修正を管理する方法であって、
バックアップ・リソース・グループの１つまたは複数のリソースに対する現在の修正要求を実行するステップと、
前記修正されたバックアップ・リソース・グループが現在のリソース・グループになるように、前記修正されたバックアップ・リソース・グループと現在のリソース・グループをアトミックにスワップするステップであって、前記バックアップ・リソース・グループの名前および前記現在のリソース・グループの名前を、名前の長さに影響を与えることなく変更することを含むステップ
とを含む方法。
【請求項２】
コンピューティング環境のリソース・グループに対する修正を管理するシステムであって、
バックアップ・リソース・グループの１つまたは複数のリソースに対する現在の修正要求を実行する手段と、
前記修正されたバックアップ・リソース・グループが現在のリソース・グループになるように、前記修正されたバックアップ・リソース・グループと現在のリソース・グループをアトミックにスワップする手段であって、前記バックアップ・リソース・グループの名前および前記現在のリソース・グループの名前を、名前の長さに影響を与えることなく変更する手段
とを備えるシステム。
【請求項３】
コンピューティング環境のリソース・グループに対する修正を管理するプログラムであって、前記プログラムがコンピュータに、
バックアップ・リソース・グループの１つまたは複数のリソースに対する現在の修正要求を実行する機能と、
前記修正されたバックアップ・リソース・グループが現在のリソース・グループになるように、前記修正されたバックアップ・リソース・グループと現在のリソース・グループをアトミックにスワップする機能であって、前記バックアップ・リソース・グループの名前および前記現在のリソース・グループの名前を、名前の長さに影響を与えることなく変更する機能と
を実現させるプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は一般に、コンピューティング環境内の処理に関し、詳細には、一貫性のある永続的かつアトミックなリソース・グループのスワップを提供することに関する。
【０００２】
【従来の技術】
データ整合性は、コンピューティング環境内で動作を実行するときに発生する最も重要な関心事の１つである。詳細には、どのタイプのデータ修正をも失わないことが重大である。コンピューティング環境内のシステムが故障すれば、充分な復元シナリオを有することが通常避けられない。
【０００３】
適切な復元を可能にするために、データのバックアップを維持管理するのが普通である。一例においてこのバックアップは、定期的に実行される。さらにデータに対する変更は、最後のバックアップ以来発生したことを追跡するログ・ファイルに書込まれる。故障前に行われた動作を再構築しデータをリストアするために、復元中にこのバックアップおよびログ・ファイルが使用される。
【０００４】
【発明が解決しようとする課題】
充分なバックアップを提供するために努力がなされたが、さらに改善が必要である。例えば、プラットフォームに独立で、アプリケーション・レベルで提供される効率的なデータのバックアップを提供する機能が必要である。
【０００５】
【課題を解決するための手段】
コンピューティング環境のリソース・グループに対する修正を管理する方法の提供により、従来技術の欠点が克服され、他の利点が提供される。本方法は例えば、バックアップ・リソース・グループの１つまたは複数のリソースに対して現在の修正要求を実行すること、およびこの修正されたバックアップ・リソース・グループが現在のリソース・グループになるように、修正されたバックアップ・リソース・グループおよび現在のリソース・グループをアトミックにスワップすることを含み、このアトミックなスワップは、バックアップ・リソース・グループ名と現在のリソース・グループ名を、名前の長さに影響を与えることなく変更することを含む。
【０００６】
上記要約した方法に対応するシステムおよびコンピュータ・プログラムもまた、本明細書に述べられ、請求される。
【０００７】
他の機能および利点が、本発明の手法を介して実現される。本発明の他の実施形態および態様が、本明細書に詳細に述べられ、請求される本発明の一部と考えられる。
【０００８】
【発明の実施の形態】
本発明の少なくとも一態様にしたがって、リソース・グループの１つまたは複数のリソース（例えば、ファイル、テーブル、オブジェクト等）に対する修正がアトミックかつ永続的に実行される。詳細には、２組以上のリソースの一貫性のある永続的かつアトミックなスワップが提供される。
【０００９】
本発明の諸態様を組込み使用するコンピューティング環境の一例が図１に示され、本明細書に述べられる。分散コンピューティング環境１００は例えば、複数のＬＡＮゲート１０４を介して互いに結合された複数のフレーム１０２を含む。フレーム１０２およびＬＡＮゲート１０４は、本明細書に詳細に述べられる。
【００１０】
一例において分散コンピューティング環境１００は、８フレームを含み、そのそれぞれは、複数の処理ノード１０６を含む。一例において各フレームは、（それぞれが１つまたは複数のプロセッサを有する）１６処理ノードを含む。各処理ノードは例えば、ＵＮＩＸに基づくオペレーティング・システムであるＡＩＸを実行するＲＩＳＣ／６０００コンピュータである。フレーム内の各処理ノードは、例えば内部ＬＡＮ接続を介して、そのフレームの他の処理ノードに結合される。さらに各フレームは、ＬＡＮゲート１０４を介して他のフレームに結合される。
【００１１】
例として、各ＬＡＮゲート１０４は、ＲＩＳＣ／６０００コンピュータ、ＬＡＮに対する任意のコンピュータ・ネットワーク接続、またはネットワーク・ルータのいずれかを含む。しかしこれらは単なる例に過ぎない。他のタイプのＬＡＮゲートがあること、およびフレームを互いに結合するために使用することのできる他の機構があることは、当業者であれば明らかであろう。
【００１２】
図１の分散コンピューティング環境は、単なる一例に過ぎない。８より多いまたは少ないフレーム、あるいは１フレーム毎に１６より多いまたは少ないノードを有することが可能である。さらに処理ノードは、ＡＩＸを実行するＲＩＳＣ／６０００コンピュータである必要はない。いくつかのまたはすべての処理ノードは、様々なタイプのコンピュータおよび／または様々なオペレーティング・システムを含むことができる。例えば本発明は、ＬＩＮＵＸ（Ｒ）および／またはＷｉｎｄｏｗｓ（Ｒ）オペレーティング・システムと共に用いることができる。さらに、その環境の１つまたは複数のノードおよび／またはオペレーティング・システムが、その環境の他のノードまたはオペレーティング・システムと異なる異種環境が、本発明の態様を含み利用することができる。そのような異種環境の諸ノードは、互いに協力しリソースを共用する点で相互動作する。これらの変形形態のすべてが、請求される本発明の一部と考えられる。
【００１３】
分散コンピューティング環境のユーザは、そのコンピューティング環境のノードまたはそのノードに結合された記憶装置の中に記憶された（ファイル、テーブル、オブジェクトなどの）リソースにデータを書込み、そこからデータを読取る。一例において諸動作は、１組の論理的に関連するリソース上で実行される。この１組のリソースは、本明細書においてリソース・グループと呼ばれる。リソース・グループの諸リソースは、そのリソースに対して読取りまたは書込み動作を実行するユーザによりアクセスされる。リソース・グループの１つまたは複数のリソースに対して書込み要求が実行されるときはいつも、その変更が、本発明の一態様にしたがって永続的かつアトミックに実行される。
【００１４】
変更を永続的かつアトミックに実行するために、少なくとも２つのリソース・グループが維持管理される。１つのリソース・グループは、現在の状態のリソースであり、現在のリソース・グループと呼ばれ、他のリソース・グループは、バックアップまたはシャドー・バージョンのリソースであり、バックアップ（またはワーク）リソース・グループと呼ばれる。
【００１５】
図２に示されるように、現在のリソース・グループ２００は、１つまたは複数のリソース２０２を有し、バックアップ・リソース・グループ２０４は、それらのリソースの複製２０６を有する。リソース・グループの１つまたは複数のリソースが更新されるとき、その更新は、本発明の諸態様にしたがって、バックアップ・リソース・グループ内で実行され、次いでそのリソース・グループがアトミックにスワップされる。したがってスワップ後には、両方のリソース・グループにおいてその変更が反映される。
【００１６】
アトミックで一貫性のある永続的な方法でリソースを修正することに関するロジックの一実施形態が、図３を参照して述べられる。一例においてこのロジックは、ノード（例えばサーバ）内の機能により実行される。
【００１７】
最初にユーザは、例えば（一例として）書込み要求３００をコンピューティング環境の１ノードに転送する。その要求がノードに受け取られるとき、ノード内のロジックがいくつかの動作を実行する。例えばノードは、０またはそれより多い前の修正を現在のリソース・グループ３０２からバックアップ・リソース・グループ３０４にコピーする（ステップ３０６）。詳細には、現在のリソース・グループ内のデータを反映するようにバックアップ・リソース・グループが更新される。これは、更新される両方のリソース・グループをロックステップに保持することにより行うことができる。詳細には、どの時点においてもこの２つのグループは、最後の書込み動作において導入された修正によってしか異ならない。したがってバックアップ・リソース・グループは、前の書込み動作で更新される。
【００１８】
現在のリソース・グループ内のデータを反映するようにバックアップ・リソース・グループを更新するのに続いて、ノードはバックアップ・リソース・グループに対して新たな書込み要求を実行する（ステップ３０８）。その間に、現在のリソース・グループ上で任意の読取り要求が並列で進むことができる（ステップ３１０）。
【００１９】
書込み動作が正常に終了すると、バックアップおよび現在のリソース・グループがスワップされる（ステップ３１２）。一実施形態においてスワップは、アトミックな方法で実行され、その結果、スワップ動作中にシステムが故障するかエラーが発生しても、復元手順またはシステムの次の初期化において、リソースの一貫性のある状態を依然として得ることができる。
【００２０】
一例においてアトミック・スワップは、リソースのリネームにより実行される。詳細には、各リソースが、そのリソースに関連付けられた名前を有し、各名前は、リソースのバージョンを示すサフィックスを有する。一例として、可能なバージョン・サフィックスは、．０、．１、．２であり、この数は、モジューロ３で順序付けられる。すなわち、０＜１、１＜２、２＜０である。順序の中の最高バージョンは、そのリソースの現在のバージョンであり、一方最低バージョンは、そのリソースがバックアップ・リソース・グループに属することを示す。したがって、どのリソースが現在のバージョンに対応するかを、リソースのバージョン・サフィックスに基づいて判定することが可能である。
【００２１】
本発明の一態様によれば、変更のアトミック性を提供するために、最小数のリソース動作を用いてバージョン番号が切り替えられる。特定の一例を示す図４を参照して、切り換えの一例をさらに述べる。
【００２２】
図４の例において、２つのリソース・グループ４００および４０２があり、各グループがＡおよびＢと呼ばれる２つのリソースを有すると仮定する。したがってバックアップ・リソース・グループは、リソースＡ．０およびＢ．０を含み、一方現在のグループは、リソースＡ．１およびＢ．１を含む。この例において、初期化時に、両方のリソース・セットは同じ情報を含む。
【００２３】
次の書込み動作が要求される。書込み動作は、（現在のリソース・グループの内容を反映するように更新された）バックアップ（またはワーク）リソース・グループにおいて行われる。更新が正常であれば、データが、例えばディスクに、最低バージョンを有するリソース内に保管される。この例では、バージョン０である。エラーが発生しなければ、今度はバックアップ・グループがそのリソース・グループの現在のバージョンを含む。したがって最低バージョンは、ｍｏｄ３の順序を用いて最高バージョンにリネームされる。
【００２４】
詳細には、一例においてリソースのリネームは、同じ順序、例えば辞書編集的に実行される。したがってこの場合、現在のリソース・グループの名前は不変のままであるが（参照番号４０６参照）、リソースＡ．０は、最初にＡ．２にリネームされる（参照番号４０４参照）。次いでリソースＢ．０がＢ．２にリネームされる（参照番号４０８参照）。１グループの最後のリソースを正常にリネームすれば、現在のグループとバックアップ・グループのアトミック・スワップが完了する。したがって今度は、リソースＡ．２およびＢ．２が、新たな現在のリソース・グループ（４０８）の一部であり、リソースＡ．１およびＢ．１は、新たなバックアップ・リソース・グループ４１０のメンバである。
【００２５】
上記詳述は、現在のリソース・グループとバックアップ・リソース・グループのアトミック・スワップである。本明細書に述べる例では、リソースの名前が修正されているが、名前の長さは一定に保たれる（これがモジューロ３演算の理由である）。通常、ＵＮＩＸなどのファイル・システムにおいて、名前の変更は、Ｉノードまたは等価なリソース構造定義の修正を伴う。たとえファイル・システムが一杯であっても、この修正は安全に実行することができる。
【００２６】
リソース・グループのアトミック・スワップを構成するのは、最後の（この場合第２の）リネーム動作である。前の動作が正常であった場合、リソース・グループは更新されたと考えられる。したがって今度は、バックアップ・リソース・グループが現在のリソース・グループであり、逆も同様である。リソースを制御するサービスがダウンする場合、より高いバージョンが現在のバージョンであると宣言することにより、データを復元することができる。
【００２７】
リソース・グループが２つより多いリソース、例えばｎ個のリソース、を有する場合、最後のリソースのリネーム動作がそのリソース・グループのアトミック・スワップと考えられる。さらに、特定のリソース・グループの１つまたは複数であるがすべてよりは少ないリソースをリネーム後に故障が発生した場合、一貫性のないリソース・グループ・バージョンがあるであろう。したがって一貫性のないリソース・グループ・バージョンは、壊れていると宣言され、他方のバージョンが依然現在のバージョンと考えられる。これは、現在のバージョンが、一貫性のある最高バージョンを有するからである（すなわち、そのすべてが同じバージョンを有する１組のリソースがある場合に、リソース・グループは一貫性がある）。
【００２８】
リソースのアトミック・スワップを提供するためのモジューロ（ｎ）演算および順序付けは、リソース・グループの１つが書込み動作のターゲットであるかどうかに関わらず、多数のシナリオにおいて使用することができる。さらに、本明細書に述べる手法は、ｎ個のリソースを有するリソース・グループに等しく応用可能である。リソースは、事前定義の順序を用いてリネームされ、その順序内の最後のリソースのリネームが、両方のリソースをスワップするアトミック・アクションと考えられる。ｎ個のリソース・グループでこの手法を用いるとき、モジューロ（ｎ＋１）演算が使用される。この演算は、ｎ組のリソースをソートするために使用することができる。
【００２９】
本発明は、両方のグループのリソース間に必ずしも対応がないリソース・グループに、詳細には、ドライバ・プログラムが各リソース・グループ内の少なくとも２つのリソースを識別できる場合にもまた応用可能である。その場合、その一対の２つのリソースの第１のリソースが最初にリネームされ、その対の最後のリソースが最後にリネームされて、その結果、システム・シャットダウンの場合に、その対を比較して、それらのバージョンが互換であるかどうかを判定することができる。再び、互換バージョンを有する最高の対のリソース・グループが、現在のリソース・グループと宣言される。
【００３０】
本発明の機構は、リソース・グループのどのバージョンが現在のバージョンであるかを判定する固定サイズのネーミング方式および手法を提供することにより、基礎にあるオペレーティング・システムのアトミック性レベルでオールオアナッシングのセマンティックスを提供する、プラットフォームに独立なアプリケーション・レベルの手法を有利に提供する。さらに本発明の機構は、データの整合性を損なう可能性のあるどんな余分のリソース（例えばファイル）も使用することなく（すなわち、制御ファイルが壊れれば、データ自体が壊れる）、少なくとも１つの一貫性のあるバージョンのリソース・グループを見つけることを可能にする。
【００３１】
本発明の諸態様は、現在のバージョンおよびバックアップ・バージョンのデータが、一貫性のある方法で維持管理される任意のシナリオに応用可能である。一例においてこの手法は、どれほど広範囲かに関わらず、１つのテーブルが１組のリソースとして記憶され、アトミックな書込み動作がサポートされるリレーショナル・データ・リポジトリ（ｒｅｌａｔｉｏｎａｌ  ｄａｔａ  ｒｅｐｏｓｉｔｏｒｙ）のために使用される。
【００３２】
本発明は、分散コンピューティング環境に限定されることなく、単一システム環境を含む任意のコンピューティング環境で使用することができる。さらに、本発明の１つまたは複数の態様は、異種システムのみならず同種システムにも応用可能である。一例として、異種環境のシステムの相互動作性を容易にする機能が提供されている。
【００３３】
本発明は、例えばコンピュータ使用可能媒体を有する製品（例えば１つまたは複数のコンピュータ・プログラム）内に含めることができる。その媒体は例えば、本発明の機能を提供し容易にするコンピュータ可読プログラム・コード手段をその中に実施済みである。その製品は、コンピュータ・システムの一部として含めるか、または別々に販売することができる。
【００３４】
さらに、本発明の機能を実行するために、マシンによって実行可能な命令のプログラムを少なくとも１つ有形に実施する、そのマシンにより可読な少なくとも１つのプログラム記憶装置を提供することができる。
【００３５】
本明細書に示された流れ図は単なる例である。本発明の精神から逸脱することなく、流れ図に記載したこれらの図またはステップ（または動作）に対する多数の変形形態があってよい。例えば、異なる順序でステップを実行すること、あるいはステップを追加、削除または修正することができる。これらの変形形態はすべて、請求される発明の一部と考えられる。
【００３６】
好ましい実施形態を本明細書に詳細に示し述べたが、本発明の精神から逸脱することなく、様々な修正、追加、代用等を行うことができ、したがってこれらは、請求の範囲に定義された本発明の範囲内と考えられることが、当業者には明らかであろう。
【００３７】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００３８】
（１）コンピューティング環境のリソース・グループに対する修正を管理する方法であって、
バックアップ・リソース・グループの１つまたは複数のリソースに対する現在の修正要求を実行するステップと、
前記修正されたバックアップ・リソース・グループが現在のリソース・グループになるように、前記修正されたバックアップ・リソース・グループと現在のリソース・グループをアトミックにスワップするステップであって、前記バックアップ・リソース・グループの名前および前記現在のリソース・グループの名前を、名前の長さに影響を与えることなく変更することを含むステップ
とを含む方法。
（２）コンピューティング環境のリソース・グループに対する修正を管理するシステムであって、
バックアップ・リソース・グループの１つまたは複数のリソースに対する現在の修正要求を実行する手段と、
前記修正されたバックアップ・リソース・グループが現在のリソース・グループになるように、前記修正されたバックアップ・リソース・グループと現在のリソース・グループをアトミックにスワップする手段であって、前記バックアップ・リソース・グループの名前および前記現在のリソース・グループの名前を、名前の長さに影響を与えることなく変更する手段
とを備えるシステム。
（３）コンピューティング環境のリソース・グループに対する修正を管理するプログラムであって、前記プログラムがコンピュータに、
バックアップ・リソース・グループの１つまたは複数のリソースに対する現在の修正要求を実行する機能と、
前記修正されたバックアップ・リソース・グループが現在のリソース・グループになるように、前記修正されたバックアップ・リソース・グループと現在のリソース・グループをアトミックにスワップする機能であって、前記バックアップ・リソース・グループの名前および前記現在のリソース・グループの名前を、名前の長さに影響を与えることなく変更する機能と
を実現させるプログラム。
【図面の簡単な説明】
【図１】本発明の諸態様を組込み使用するコンピューティング環境の一実施形態を示す図である。
【図２】本発明の一態様による、現在のリソース・グループおよびそのバックアップ・コピーの一例を示す図である。
【図３】本発明の一態様による、アトミックかつ永続的な方法でリソース・グループの諸リソースを修正するために実行される様々なステップを示す図である。
【図４】本発明の一態様による、現在のリソース・グループとバックアップ・リソース・グループのアトミック・スワップを示す図である。
【符号の説明】
３００  書込み要求
３０２  現在のリソース・グループ
３０４  バックアップ・リソース・グループ
【図１】
0003594241.tif 000002
【図２】
0003594241.tif 000003
【図３】
0003594241.tif 000004
【図４】
0003594241.tif 000005