(57)【要約】  多層クライアント/サーバのデータ処理システムのアプリケーション層の一部分である複数の独立した処理スレイブノード(210、210'、210")にわたって分散した複製ファイルの一貫性を維持するための方法およびシステムが説明される。複製ファイルはマスタ層のマスタノードから分散される。マスタデータベースを更新する更新要求(142)を受け取ると、最初に複製ファイルの新バージョンが生成されて共有ファイルシステム(160)に格納される。次いで、新バージョンの可用性の通知が同期スレイブノードに転送され、そこから、すべてのスレイブノード(210、210'、210")に一斉送信される。各スレイブノードは、共有ファイルシステム(160)からの複製ファイルの新バージョン(150)をプリロードして、無事完了を確認する。
2014535081.tif 000002
【特許請求の範囲】
【請求項１】
多層クライアント/サーバのデータ処理システムのアプリケーション層(200)の一部分である複数の独立した処理スレイブノード(210、210'、210")にわたって分散した複製ファイル(250)の一貫性を維持する方法であって、前記複製ファイル(250、150)が、マスタ層(100)のマスタノード(110)から分散され、少なくとも1つのデータプロセッサで遂行される以下のステップ、すなわち
前記データ処理システムのマスタデータベース(120)を更新するために、前記マスタ層(100)の少なくともマスタサーバ(112)で更新要求(142)を受け取るステップ(1)と、
前記更新要求に基づいて、前記マスタ層(100)の共有ファイルシステム(160)に格納された複製ファイルの新バージョン(150)を生成して格納するステップ(2)と、
すべてのスレイブノード(210、210'、210")に対して前記複製ファイルの前記新バージョン(150)の可用性を通知するステップ(3、4)と、
各スレイブノード(210、210'、210")において、前記共有ファイルシステム(160)からの前記複製ファイルの前記新バージョン(150)のプリロードを開始(51)して、前記プリロードの終了に際して前記プリロードの無事完了を確認するステップ(52)と
を含み、
すべてのスレイブノード(210、210'、210")が前記プリロードの無事完了を確認した(52)場合に限って、
前記マスタサーバ(112)でプリロード達成の通知を受け取るステップ(6)と、
前記マスタサーバ(112)から、前記複製ファイルの前記新バージョン(150)のデータを用いて前記マスタデータベース(120)を更新する(7)ことにより、前記マスタ層(100)による前記複製ファイルの前記新バージョン(150)の使用をコミットするステップと、
すべての複製ファイル(150、250)のバージョンを記録するように構成された前記アプリケーション層(200)のスレイブデータベース(260)における前記複製ファイルの前記新バージョン(150)の前記使用をコミットするステップ(9)と、
すべてのスレイブノード(210、210'、210")のコミットメントの通知を前記マスタサーバ(112)に転送するステップ(10)と、
マスタサーバ(112)から、受け取った前記更新要求(142)に応答して、前記更新の達成を確認するステップ(11)と
を遂行し、
すべての前記スレイブノード(210、210'、210")が前記プリロードの無事完了を確認した(52)わけではない場合には、前記マスタノード(110)でエラーの通知を受け取ることを特徴とする方法。
【請求項２】
すべてのスレイブノード(210、210'、210")に対して前記複製ファイルの前記新バージョン(150)の可用性を通知する前記ステップ(3、4)が、
前記マスタサーバ(112)から、前記スレイブノード(210、210'、210")から得られた同期スレイブノード(210)へ、前記複製ファイルの前記新バージョン(150)の可用性の通知を転送するステップ(3)と、
前記同期スレイブノード(210)から、他のすべてのスレイブノード(210'、210")へ、前記可用性の通知を一斉送信するステップ(4)とを含む請求項1に記載の方法。
【請求項３】
前記プリロードの無事完了を確認する前記ステップ(52)が、前記スレイブノード(210、210'、210")が前記同期スレイブノード(210)のサーバ処理(220)に対して前記プリロードの無事完了を確認するステップ(52)を含む請求項2に記載の方法。
【請求項４】
一旦、すべてのスレイブノード(210、210'、210")が前記同期スレイブノード(210)の前記サーバ処理(220)に対して前記プリロードの無事完了を確認する(52)と、前記マスタサーバ(112)でプリロード達成の通知を受け取る前記ステップ(6)の前に、前記同期スレイブノード(210)が、プリロード達成の前記通知を前記マスタサーバ(112)へ転送する(6)請求項3に記載の方法。
【請求項５】
前記マスタ層による前記複製ファイルの前記新バージョン(150)の前記使用をコミットする前記ステップが終了すると、前記マスタノード(110)が、前記同期スレイブノード(210)へコミットメントの通知を転送し(8)、次いで、前記同期スレイブノード(210)が、前記スレイブデータベース(260)における前記複製ファイルの前記新バージョン(150)の前記使用をコミットする前記ステップ(9)をトリガする請求項1から4のいずれか一項に記載の方法。
【請求項６】
ユーザからの情報を求めるクエリによって起動されたトランザクションの初めに、少なくとも前記トランザクションに含まれる各スレイブノード(210、210'、210")において、作用的処理(240、240'、240")が、前記スレイブデータベース(260)に問い合わせを送り(264)、前記複製ファイルの現行バージョン(250)から前記複製ファイルの前記プリロードされた新バージョン(150)へ切り換える(12)かどうかを指示される請求項1から5のいずれか一項に記載の方法。
【請求項７】
ユーザからの情報を求めるクエリによって起動されたトランザクションの初めに、前記トランザクションに含まれる各スレイブノード(210、210'、210")において、作用的処理(240、240'、240")が、前記複製ファイルの現行バージョン(250)のタグを読み取り、前記タグが前記複製ファイルの新バージョン(150)が利用可能かどうかを示し、前記タグが前記複製ファイルの新バージョン(150)が利用可能であることを示す場合には、前記作用的処理(240、240'、240")が、前記スレイブデータベース(260)に問い合わせを送り(264)、前記複製ファイルの前記現行バージョン(250)から前記複製ファイルの前記新バージョン(150)へ切り換える(12)べきかどうかを指示される請求項1から5のいずれか一項に記載の方法。
【請求項８】
前記タグが、前記複製ファイルの新バージョン(150)のプリロード(51)の無事完了時にセットされ、前記作用的処理(240、240'、240")による最初の読取りでリセットされる請求項7に記載の方法。
【請求項９】
前記受け取られる更新要求(142)が少なくとも1つの更新を含み、前記共有ファイルシステム(160)の中に複製ファイルの新バージョン(150)を生成して格納する前記ステップが、インクリメンタル処理であって、前記マスタサーバ(112)の中で、
前記共有ファイルシステム(160)から複製ファイルの現行バージョン(250)を取得して、更新するべき前記複製ファイルの前記現行バージョンを適切なフォーマット(114)に変換するステップ(152)と、
前記現行バージョンに前記更新を適用し(142)、前記共有ファイルシステム(160)中に前記複製ファイルの前記新バージョン(150)を変換して格納するステップ(154)とを含む請求項1から8のいずれか一項に記載の方法。
【請求項１０】
前記複製ファイル(150、250)が、前記共有ファイルシステム(160)に格納されるとき圧縮され、前記インクリメンタル更新(152)を遂行するとき、前記共有ファイルシステム(160)に格納された前記複製ファイルが、前記マスタサーバ(112)によって解凍されて適切なフォーマットに変換され、プリロード(51)に際して、前記スレイブノード(210、210'、210")によって解凍されて適切なフォーマットに変換される請求項9に記載の方法。
【請求項１１】
すべてのスレイブノード(210、210'、210")が前記プリロードの無事完了を確認した(52)わけではない場合には、前記マスタノード(110)が、前記更新要求(142)を送った管理者にエラーの通知を送る請求項1に記載の方法。
【請求項１２】
前記共有ファイルシステム(160)がネットワークに接続された記憶装置(NAS)である請求項1から11のいずれか一項に記載の方法。
【請求項１３】
前記スレイブデータベース(260)が格納するのは、複製ファイルの前記バージョンに関連するデータのみである請求項1から12のいずれか一項に記載の方法。
【請求項１４】
コンピュータ可読記憶メディアに格納され、請求項1から13のいずれか一項に記載の方法を遂行するコンピュータプログラム。
【請求項１５】
アプリケーション層(200)およびマスタ層(100)を備える分散型の多層クライアント/サーバのデータ処理システムであって、前記アプリケーション層(200)が複数の独立した処理スレイブノード(210、210'、210")を備え、前記マスタ層(100)が、前記スレイブノード(210、210'、210")に複製ファイル(250、150)を分散するように構成されたマスタノード(110)、マスタデータベース(120)およびマスタサーバ(112)を備え、前記マスタ層(100)が共有ファイルシステム(160)を備え、前記マスタサーバ(112)が、前記マスタデータベース(120)を更新するようにとの更新要求(142)を受け取り(1)、前記共有ファイルシステム(160)に格納された複製ファイルの新バージョン(150)を生成して、前記新バージョン(150)を前記共有ファイルシステム(160)に格納する(2)ように構成されていること、すべてのスレイブノード(210、210'、210")に接続され、すべての複製ファイルバージョン(150、250)を記録するように構成されたスレイブデータベース(260)を前記マスタ層(100)が備えること、および前記システムが、
すべてのスレイブノード(210、210'、210")に対して前記複製ファイルの前記新バージョン(150)の可用性を通知し(3、4)、
各スレイブノード(210、210'、210")において、前記共有ファイルシステム(160)からの前記複製ファイルの前記新バージョン(150)のプリロードを開始(51)して、前記プリロードの終了に際して前記プリロードの無事完了を確認し(52)、
すべてのスレイブノード(210、210'、210")が前記プリロードの無事完了を確認した(52)場合に限って、前記マスタサーバ(112)でプリロード達成の通知を受け取るステップ(6)、前記マスタサーバ(112)から、前記複製ファイルの前記新バージョン(150)のデータを用いて前記マスタデータベース(120)を更新する(7)ことにより、前記マスタ層(100)による前記複製ファイルの前記新バージョン(150)の使用をコミットするステップ、前記スレイブデータベース(260)における前記複製ファイルの前記新バージョン(150)の前記使用をコミットするステップ(9)、すべてのスレイブノード(210、210'、210")のコミットメントの通知を前記マスタサーバ(112)に転送するステップ(10)、マスタサーバ(112)から、受け取った前記更新要求(142)に応答して、前記更新の達成を確認するステップ(11)を遂行し、
すべての前記スレイブノード(210、210'、210")が前記プリロードの無事完了を確認した(52)わけではない場合には、前記マスタノード(110)でエラーの通知を受け取る
ように構成されること
を特徴とするデータ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にデータ処理システムに関し、詳細には分散型クライアント/サーバのソフトウェアアーキテクチャに関する。より詳細には、本発明は、複数の処理ノードにわたって分散したキャッシュファイルのコンテンツ間の一貫性を維持する一方で、それらの疑似リアルタイムの可用性を保証する方法およびシステムに関する。
【背景技術】
【０００２】
1980年代後半に出現したクライアント/サーバモデルは、その時代に標準であった、集中型の、メインフレームにおける時分割コンピューティングと比較して、可用性、融通性、相互運用性、およびスケーラビリティを改善するために考案された汎用のモジュール式ソフトウェアのアーキテクチャである。それ以来、クライアント/サーバのアーキテクチャは、すべての知能が中央のホストコンピュータ内にあってユーザがダムターミナルを通じてホストと情報をやりとりしていた、以前のメインフレームソフトウェアのアーキテクチャに漸次完全に取って代わった。しかし、メインフレームが依然として使用されている場合には、種々のクライアント/サーバのアーキテクチャの強力なサーバとしてのみあり、ダムターミナルも、サーバとの間で送受されるデータを自己処理することができるインテリジェントなグラフィカルユーザインターフェース(GUI)で置換されている。
【０００３】
最新のデータ処理システムでは、主として使用され、多数の遠隔設置されたクライアントをサポートすることができる、いわゆるクライアント/サーバのアーキテクチャは、3層アーキテクチャである。このようなアーキテクチャの一例が図1に示されている。マスタ層100は、従来、あらゆる種類の商用および管理用の操作を行うために、恐らくあらゆる事業組織、会社または企業の日常作業に必要なすべてのデータの大きな、または非常に大きなリポジトリであるデータベースシステム120のまわりに構築されている。ほとんどのデータベースは、リレーショナルデータベース管理システムすなわちRDBMSで制御されるリレーショナルタイプである。リレーショナルタイプのデータベースは、一般に、GUI  140から(from  GUI's  140)データ処理システムの管理者によって1つまたは複数のマスタサーバ112を通じて管理されている。管理者は、一般に、データベースのコンテンツを直接更新する権限を与えられたシステムの唯一のユーザである。
【０００４】
図1の例示的3層システムの中間層すなわち中位の層は、データ処理システムの所有者である組織の特定ソフトウェアアプリケーション240のすべてが実行されるアプリケーション層200である。全体的にミドルウェアソフトウェアと称される特定のアプリケーションのこの集合は、組織の所有するソフトウェアである。この集合は、そのデータのリポジトリ120から、マスタサーバ110を通じて、すべての組織の遠隔クライアントの要求を満たすように用いられる。遠隔クライアントは、3層アーキテクチャの第3の層300を形成する。したがって、クライアント層300からのクエリは、中間層200の特定のアプリケーションによって、マスタ層100から取り込まれたデータに対して処理され、対応される。
【０００５】
3層アーキテクチャでは、多数の遠隔クライアントの要求を満たす必要があるとき、データ処理システムの全体的な処理能力を高めるように中間層の中に独立した処理ノードを追加することにより、全体的な性能を維持するためのシステムのスケーラビリティが得られる。したがって、アプリケーション層200は、以下の説明では一般にスレイブノード210と称されるいくつかの独立した処理ノードから成る。そこで、マスタ層100がますます増加するスレイブノードからの多すぎるデータリクエストによって圧倒されるのを防止するための一般的なやり方は、データの部分に対して作用する作用的処理(applicative  processes)240を、必要な限りマスタデータベースから持って来て各アプリケーションノードに格納することである。図1の例示的システムでは、これはキャッシュファイル250の形態をとり、作用的処理240は、必要な度に、マスタデータベースからマスタサーバを通じてキャッシュファイル250を得るのに長い遅延を招く必要なく作用することができる。このようなデータ処理システムでは、処理能力およびソフトウェアアプリケーションはこのように分散しており、すなわち、システムの遠隔クライアント300のすべての要求を満たすのに必要な処理能力のレベルに達するのに必要なだけの数のノード210に分割されている。分散したキャッシュファイル250もそうである。
【０００６】
しかし、このような分散コンピューティング環境では、分散型データシステムのいくつかの望ましい特性のすべてを必ずしも同時に保証することはできないことが判明している。図2に示されるように、分散型データ処理システムに期待される特性40は、一貫性、可用性およびスケーラビリティである。CAP定理として知られている定理によれば、分散型システムは、これらの特性のうち任意の2つを同時に満たすことができるが、3つのすべてを同時に満たすことはできない。CAPは、一貫性、可用性および分割許容性を意味し、2000年に米国カリフォルニア大学バークレー校教授のE.  Brewerによって推測されている。この定理は、後に、2002年発行のACM  SIGACT  News、v.33  issue  2、51〜59頁におけるN.  LynchおよびS.  Gilbertの論文で実証されている。上記で論じたように、システムの全般的な処理能力(power  processing)が実際には分散、すなわち、それを独立した処理ノードにわたって分割することで得られるので、CAPの分割許容特性はスケーラビリティとの関連が強い。
【０００７】
3層アーキテクチャでは、一貫性および可用性41を完全に満たすことができるのは、中間層アプリケーションによって用いられるデータが常にマスタデータベースに由来する場合のみである。これは、クライアント層300からのクエリに応えるだけのために、マスタ層100からアプリケーション層200への非常に高速の下りトラフィックを生じさせ、また、クエリに応えるのに、マスタデータベースが非常に高度に占有されるという犠牲を払って達成することができるものである。これは、データベースへの書込みの割合が全般的に比較的低い場合でも、管理者(140)によるマスタデータベースの管理および更新と競合することになる。クライアント層のユーザ数が増加すると、明らかに、データベースへのアクセスならびにデータ層とアプリケーション層の間のネットワーク上のトラフィックが、性能を制限するボトルネックになる。
【０００８】
図1に示された例示的なもののような3層アーキテクチャでは、可用性およびスケーラビリティ42は、データベースの占有ならびにデータ層とアプリケーション層の間の高速トラフィックという上記の問題を乗り越えるためにキャッシュファイル250を分散させることによって達成することができる。しかし、この場合、キャッシュファイルが独立したコンピュータノードにわたって分散しているので、キャッシュファイルのコンテンツがスレイブノード間で一貫していることおよびマスタデータベースのコンテンツと一致していることは保証されない。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】N.  LynchおよびS.  Gilbertの論文、2002年発行のACM  SIGACT  News、v.33  issue  2、51〜59頁
【発明の概要】
【発明が解決しようとする課題】
【００１０】
したがって、本発明の目的は、この問題に対する解決策を提供することである。クライアントアプリケーションおよび複製ファイルが複数の独立したスレイブノードにわたって分散している3層クライアント/サーバのアーキテクチャにおいて、本発明は、複製ファイルのコンテンツ間の強一貫性および完全な可用性を維持する一方で、いくらかのスケーラビリティを保つこと43のための方法およびシステムを開示するものである。
【００１１】
当業者には、添付図面を参照しながら以下の説明を検討することにより、本発明のさらなる目的、特徴および利点が明らかになるであろう。いかなる追加の利点も本明細書に組み込まれるように意図されている。
【課題を解決するための手段】
【００１２】
一態様によれば、本発明は、多層クライアント/サーバのデータ処理システムのアプリケーション層の一部分である複数の独立した処理スレイブノードにわたって分散する、マスタ層のマスタノードから分散される複製ファイルの一貫性を維持する方法を説明するものである。この方法のステップは、少なくとも1つのプロセッサで遂行され、
-  データ処理システムのマスタデータベースを更新するために、マスタ層の少なくともマスタサーバで更新要求を受け取るステップと、
-  前記更新要求に基づいて、マスタ層の共有ファイルシステムに格納された複製ファイルの新バージョンを生成して格納するステップと、
-  すべてのスレイブノードに対して複製ファイルの新バージョンの可用性を通知するステップと、
-  各スレイブノードにおいて、共有ファイルシステムからの複製ファイルの新バージョンのプリロードを開始するステップと、プリロードの終了に際してプリロードの無事完了を確認するステップとを含み、
・すべてのスレイブノードがプリロードの無事完了を確認した場合に限って、
-  マスタサーバでプリロード達成の通知を受け取るステップと、
-  マスタサーバから、複製ファイルの新バージョンのデータを用いてマスタデータベースを更新することにより、マスタ層による複製ファイルの新バージョンの使用をコミットするステップと、
-  すべての複製ファイルのバージョンを記録するように構成されたアプリケーション層のスレイブデータベースにおける複製ファイルの新バージョンの使用をコミットするステップと、
-  すべてのスレイブノードのコミットメントの通知をマスタサーバに転送するステップと、
-  マスタサーバから、受け取った更新要求に応答して、更新の達成を確認するステップとを遂行し、
・すべてのスレイブノードがプリロードの無事完了を確認したわけではない場合には、マスタノードでエラーの通知を受け取り、マスタデータベースは更新せず、スレイブデータベースにおける新バージョンの使用のコミットメントも通知しない。
【００１３】
このように、本発明は、情報のクエリにほぼリアルタイムで応答する一方で、クエリに応えるのに必要な情報の一部分を有する恐らく多数のノードにわたって強一貫性を保証するための効率的な解決策を提供するものである。したがって、本発明により、強一貫性の維持、待ち時間が非常に短い可用性およびスケーラビリティの改善が可能になる。
【００１４】
任意選択で、本発明は以下の任意選択機能のうち少なくとも1つを含んでよい。
【００１５】
本発明では、複製ファイルとして示されるのは、マスタデータベースから複製されて、作用的処理による対応するデータの処理を促進するように、スレイブノードの中にそのようなものとして持ち込まれる完全なファイルである。複製ファイル自体は、より遅いバックエンドメモリからキャッシュメモリに持って来られたデータの小片ではない。本発明の文脈ではレプリカとも称される複製ファイルは、スレイブノードの作用的処理がデータのいかなるミス(miss)も経験せずに完結することができる確かに完全なファイルである。
【００１６】
特定の、制限的ではない実施形態によれば、レプリカとも称される複製ファイルはキャッシュファイルである。
【００１７】
すべてのスレイブノードに対して複製ファイルの新バージョンの可用性を通知するステップは、
-  マスタサーバから、スレイブノードの間で得られた同期スレイブノードへ、複製ファイルの新バージョンの可用性の通知を転送するステップと、
-  同期スレイブノードから、他のすべてのスレイブノードへ、前記可用性の通知を一斉送信するステップとを含む。
【００１８】
プリロードの無事完了を確認するステップは、各スレイブノードが、同期スレイブノードのサーバ処理に対してプリロードの無事完了を確認するステップを含む。
【００１９】
一旦、すべてのスレイブノードが、同期スレイブノードのサーバ処理に対してプリロードの無事完了を確認すると、マスタサーバでプリロード達成の通知を受け取るステップの前に、同期スレイブノードは、プリロード達成の前記通知をマスタサーバへ転送する。
【００２０】
マスタ層による複製ファイルの新バージョンの使用をコミットするステップが終了すると、マスタノードは、同期スレイブノードにコミットメントの通知を転送し、次いで、同期スレイブノードは、スレイブデータベースにおける複製ファイルの新バージョンの使用をコミットするステップをトリガする。
【００２１】
ユーザからの情報を求めるクエリによって起動されたトランザクションの初めに、少なくとも前記トランザクションに関与する各スレイブノードにおいて、作用的処理はスレイブデータベースに問い合わせを行い、現行バージョンの複製ファイルからプリロードされた複製ファイルの新バージョンへ切り換えるべきかどうかを指示される。
【００２２】
好ましくは、ユーザからの情報を求めるクエリによって起動されたトランザクションの初めに、前記トランザクションに含まれる各スレイブノードにおいて、作用的処理は、複製ファイルの現行バージョンのタグを読み取り、タグが複製ファイルの新バージョンが利用可能かどうかを示す。このタグが、複製ファイルの新バージョンが利用可能であることを示す場合には、作用的処理はスレイブデータベースに問い合わせを送り、複製ファイルの現行バージョンから複製ファイルの新バージョンへ切り換えるべきかどうかを指示される。
【００２３】
このタグは、複製ファイルの新バージョンのプリロードの無事完了時にセットされ、作用的処理による最初の読取りでリセットされる。
【００２４】
受け取られる更新要求は少なくとも1つの更新を含み、共有ファイルシステムの中に複製ファイルの新バージョンを生成して格納するステップは、インクリメンタル処理であって、マスタサーバの中で、
共有ファイルシステムから複製ファイルの現行バージョンを取得して、更新するべき複製ファイルの現行バージョンを適切なフォーマットに変換するステップと、
現行バージョンに更新を適用し、変換して、共有ファイルシステムに複製ファイルの新バージョンを格納するステップとを含む。
【００２５】
複製ファイルは、共有ファイルシステムに格納されるとき圧縮される。
【００２６】
インクリメンタル更新を遂行するとき、共有ファイルシステムに格納された複製ファイルは、マスタサーバが解凍して適切なフォーマットに変換し、プリロードに際して、スレイブノードが解凍して適切なフォーマットに変換する。
【００２７】
すべてのスレイブノードがプリロードの無事完了を確認したわけではない場合には、マスタノードは、前記更新要求を送った管理者にエラーの通知を送る。
【００２８】
マスタデータベースは、マスタ層の単一のマシンまたは複数のマシンに格納することができる。スレイブデータベースは、アプリケーション層の単一のマシンまたは複数のマシンに格納することができる。
【００２９】
共有ファイルシステムは、ネットワークに接続された記憶装置NASである。
【００３０】
別の態様によれば、本発明は、非一時的なコンピュータ可読記憶メディアに格納された、先の特徴の任意のものによる方法を遂行するコンピュータプログラム製品に関するものである。
【００３１】
別の態様によれば、本発明は、ビジネスルールを含んでいる複製ファイルの一貫性を維持する方法に関し、前記複製ファイルは、マスタ層のマスタノードから分散され、多層クライアント/サーバのデータ処理システムのアプリケーション層の一部分を形成する複数の独立した処理スレイブノードにわたって分散しており、この方法のステップは、少なくとも1つのデータプロセッサで遂行され、
-  データ処理システムのマスタデータベースに格納されたビジネスルールを更新するために、マスタ層の少なくとも1つのマスタサーバで更新要求を受け取るステップと、
-  前記更新要求に基づいて、マスタ層の共有ファイルシステムに格納された複製ファイルの新バージョンを生成して格納するステップと、
-  すべてのスレイブノードに対して複製ファイルの新バージョンの可用性を通知するステップと、
-  各スレイブノードにおいて、共有ファイルシステムからの複製ファイルの新バージョンのプリロードを開始するステップと、プリロードの終了に際してプリロードの無事完了を確認するステップとを含み、
・すべてのスレイブノードがプリロードの無事完了を確認した場合に限って、
-  マスタサーバでプリロード達成の通知を受け取るステップと、
-  マスタサーバから、複製ファイルの新バージョンのデータを用いてマスタデータベースを更新することにより、マスタ層による複製ファイルの新バージョンの使用をコミットするステップとを遂行し、
すべてのスレイブノードがプリロードの無事完了を確認したわけではない場合には、マスタノードでエラーの通知を受け取るステップを遂行する。
【００３２】
任意選択で、本発明は以下の任意選択機能のうち少なくとも1つを含んでよい。
【００３３】
有利には、各ビジネスルールは1組の基準およびコンテンツを含む。好ましくは、各基準は重みに関連しており、それによって、検索エンジンは、検索が開始されると、最も関連したルールを識別することができる。
【００３４】
基準の組は、売場、国、一群の国々、フライトの出発国、フライトの目的地、顧客プロファイルのうち少なくとも1つを含む。
【００３５】
この多層クライアント/サーバのデータ処理システムは、旅行プロバイダのインベントリの一部分である。
【００３６】
より一般的には、スレイブノードは、航空会社のインベントリ、航空会社の出国管理システム、航空会社の収益管理システム、航空会社の収益会計システム、航空会社の電子チケットサーバのうち少なくとも1つに接続されている。
【００３７】
本発明の別の態様は、アプリケーション層およびマスタ層を備える分散型の多層クライアント/サーバのデータ処理システムであり、アプリケーション層は、複数の独立した処理スレイブノードを備える。マスタ層は、スレイブノードに複製ファイルを分散するように構成されたマスタノード、マスタデータベースおよびマスタサーバを備える。マスタ層は共有ファイルシステムを備える。マスタサーバは、マスタデータベースを更新するようにとの更新要求を受け取り、共有ファイルシステムに格納された複製ファイルの新バージョンを生成して、前記新バージョンを共有ファイルシステムに格納するように構成されている。本発明によるこのシステムには、すべてのスレイブノードに接続され、すべての複製ファイルバージョンを記録するように構成されたスレイブデータベースも備わっている。このシステムは、
・すべてのスレイブノードに対して複製ファイルの新バージョンの可用性を通知し、
・各スレイブノードにおいて、共有ファイルシステムからの複製ファイルの新バージョンのプリロードを開始し、プリロードが終了するとプリロードの無事完了を確認し、
・すべてのスレイブノードがプリロードの無事完了を確認した場合に限って、マスタサーバでプリロード達成の通知を受け取るステップと、マスタサーバから、複製ファイルの新バージョンのデータを用いてマスタデータベースを更新することにより、マスタ層による複製ファイルの新バージョンの使用をコミットするステップと、スレイブデータベースにおける複製ファイルの新バージョンの使用をコミットするステップと、すべてのスレイブノードのコミットメントの通知をマスタサーバに転送するステップと、マスタサーバから、受け取った更新要求に応答して、更新の達成を確認するステップとを遂行し、
・すべてのスレイブノードがプリロードの無事完了を確認したわけではない場合には、マスタノードでエラーの通知を受け取り、マスタデータベースは更新せず、スレイブデータベースにおける新バージョンの使用のコミットメントも通知しないように構成されている。
【図面の簡単な説明】
【００３８】
【図１】標準的な分散型3層データ処理システムの実例を示す図である。
【図２】分散型データ処理システムの一貫性、可用性およびスケーラビリティについて論じる図である。
【図３】マスタデータベースのコンテンツが複製ファイルの形でスレイブノードに分散している本発明による例示的データ処理システムを示す図である。
【図４ａ】本発明によるデータ処理システムの分散した複製ファイルの間で強一貫性を達成する方法のステップを説明する図である。
【図４ｂ】本発明によるデータ処理システムの分散した複製ファイルの間で強一貫性を達成する方法のステップを説明する図である。
【図５】新バージョン(Vn+1)の複製ファイルを生成するとき遂行されるインクリメンタル更新を説明する図である。
【発明を実施するための形態】
【００３９】
本発明の以下の詳細な説明は添付図面を参照する。説明には例示的実施形態が含まれているが、他の実施形態も可能であり、説明された実施形態は、本発明の趣旨および範囲から逸脱することなく変更され得る。
【００４０】
図3は、アプリケーション層200およびデータ層100とも称されるマスタ層100を備える本発明による例示的分散型データ処理システムを示す。アプリケーション層200は、複数の独立した処理スレイブノード210、210'、210"を備える。マスタ層100は、マスタノード110、マスタデータベース120およびマスタサーバ112を備える。マスタデータベース120のコンテンツはスレイブノード210、210'、210"の中に複製ファイル250、150の形で分散しており、その結果、これらのスレイブノード210、210'、210"上で動作するクライアントアプリケーション240、240'、240"は、マスタデータベース120に問い合わせを送る必要なくデータの対応する部分を用いることができる。
【００４１】
マスタ層100は、1つまたは複数のサーバ112から成るマスタノード110を含む。マスタノード100は、データリポジトリシステムすなわちマスタデータベース120を管理し、マスタデータベース120は、一般に、商業用途および工業用途を含み、恐らくはあらゆる種類の管理上のアクティビティ、教育上のアクティビティおよび政治上のアクティビティも対象として含む、あらゆるタイプの大きなビジネスアクティビティを処理するのに必要なデータをすべて保持する、大きな、または非常に大きなデータベースシステムである。航空会社および観光業では、これは、例えば世界的配送システム(global  distribution  system)すなわちGDSであり得る。GDSは、航空運賃、スケジュール、および座席の可用性、ならびに一般的には何らかの旅行商品へのリアルタイムのアクセスを可能にするように観光業の会社によって導入された任意の大きなデータ処理システムである。GDSにより、旅行代理店および個人が、多数のオンラインの旅行サイトを通じて、世界中から予約を入れ、旅行券を発券することができる。
【００４２】
このようなデータベース120は、任意の認可されたユーザによって、一般的にはグラフィックユーザインターフェース(GUI)であるシステムのユーザインターフェース140からマスタサーバ112を通じて管理される。データベースの管理権限を有するユーザは、そのコンテンツを更新することが許容されているユーザである。例えば、GDSの場合には、旅行券の予約に適用されるビジネスルールを追加するかもしくは変更すること、または旅行商品の提供を変更することである。この場合、これは、ほとんど現行の旅行製品の提供にもたらされる更新である。したがって、更新は、スレイブノード210、210'、210"上で動作するクライアントアプリケーション240、240'、240"によって用いられる分散した複製ファイルにおいて順序正しく複製されなければならない。
【００４３】
マスタ層100には、例えば管理権限を有するユーザの要求に応じて生成される複製ファイルの新バージョンの保持を目的とした、ネットワークに接続された記憶装置すなわちNASシステム160といった共有ファイルシステム(filed  system)160も含まれる。NAS  160およびシステムの他のコンポーネントの使用は、図4にさらに説明されており、図4では、スレイブノード210、210'、210"の種々の分散した複製ファイルをマスタデータベース120のコンテンツに対してコヒーレントに保つ方法が論じられる。
【００４４】
クライアントアプリケーション層200に関する限り、これは、システムの第3の層(図3には示されていない)を構成する多くの遠隔のエンドユーザの要求をそれぞれが満たすことができる複数のスレイブノード210、210'、210"から成る。上記のGDSの実例では、これらの遠隔のエンドユーザには、例えば従来の旅行代理店の社員、および公共ネットワークすなわちインターネットを通じてオンラインの旅行サイトに接続する個人ユーザが含まれる。したがって、スレイブノード210、210'、210"の作用的処理240、240'、240"を起動する多くのさまざまなソフトウェアのクライアントアプリケーションが、各スレイブノード210、210'、210"の共有メモリ230、230'、230"に持ち込まれた複製ファイルから動作することができる。したがって、これらのアプリケーションが必要とするデータは、作用的処理のうちの任意のものによって容易にアクセス可能であって、各アプリケーション向けに複製する必要はなく、したがってメモリ使用量が大幅に減少する。スレイブノード210、210'、210"上で実行される作用型ソフトウェア製品の範囲および数は可能性として非常に大きく、実際にはノードのコンピュータ資源によって限定されるのみである。作用型ソフトウェア製品の範囲および数は、主としてデータ処理システムの所有者が営む業種に依拠する。観光業では、GDSについては、作用型ソフトウェア製品には、現在すべての旅行者に提供される電子的予約および発券サービスならびに空港における旅客の出国管理のような特定のアプリケーションが含まれる。あらゆる業種のためのより一般的なアプリケーションには、財貨およびサービス、収益管理ならびに収益会計の可用性に関するものが含まれる。したがって、アプリケーション層200のユーザは、顧客に限定されず、データ処理システムを所有する会社の資産管理を担当する専門家も含む。
【００４５】
クライアントアプリケーション層200には、当初はデータ処理システムの管理者の要求に応じてマスタサーバ112のうちのいずれかによってNASシステム160に格納されている新バージョン(Vn+1)の複製ファイル150の配備を制御する各スレイブノード210、210'、210"に存在する特定のサーバ処理タスク220、220'、220"を担当するスレイブデータベース260がさらに含まれる。スレイブデータベースは、一方ではスレイブノード210、210'、210"に分散された複製ファイルの新バージョン150と現行バージョンの複製ファイル250の間の強いコヒーレンスを強化し、他方では、マスタデータベース120のコンテンツに対する強いコヒーレンスを強化するように、基本的に、スレイブノード210、210'、210"の共有メモリ230、230'、230"に収容された複製ファイルのバージョンを記録することを目的とする。有利には、スレイブデータベース260に格納されるのは複製ファイルのバージョンに関するデータのみであって、複製ファイルのコンテンツは格納されない。
【００４６】
図3に示された例示的データ処理システムに対してこの結果を達成することができる処理を、以下で図4において説明する。
【００４７】
本発明によるシステムに寄与するすべてのソフトウェアコンポーネントは、1つまたは複数の相互接続されたネットワークを通じて通信することもできる多様な個々のコンピュータまたはコンピュータ化されたプラットフォーム30、30'、30"から実施され、かつ実行される。このようなネットワークは、一般に企業ネットワークを形成するローカルエリアネットワークすなわちLANである。LANは通信プロトコルの標準的なセットの下で動作する。ほとんどの場合、インターネットの伝送制御プロトコル(TCP)をインターネットプロトコル(IP)自体に関連付けるプロトコルのTCP/IPスイートが採用される。種々のコンピュータ化されたプラットフォームとソフトウェアコンポーネントの間の通信は、実際にはメッセージを交換することによって実現される。データ処理システムの種々のコンポーネント間の通信チャネルを確立するのに、例えば国際連合(UN)の組織および国際航空運送協会(IATA)によって奨励された規格のEDIFACT(行政、商業および運輸のための電子データ交換)メッセージを用いることができる。メッセージは、通常、サービスインテグレータ(SI)とも称される企業サービスバス(図示せず)を通じて交換される。
【００４８】
図4は、図4aおよび図4bから成り、以前の図で実例が示され、かつ論じられている本発明によるデータ処理システムの分散した複製ファイルの間で強一貫性を達成する方法のステップを説明するものである。
【００４９】
システムの内部データを更新する2段階コミット処理の第1段階が図4aに示されている。第1段階は、マスタノード100のサーバのうちの1つを介して更新トランザクションを開始する正規の管理者によって起動される。これは、図5に示されるように、一般にグラフィックユーザインターフェース(GUI)である標準的なユーザインターフェースからマスタサーバ112に更新要求142を送るステップ1(sending  1)の形で行われる。これは、データ更新処理の第1のステップすなわちステップ1である。
【００５０】
ステップ2は、担当するマスタサーバ112によって遂行され、マスタサーバ112は、更新要求142を受け取ると、対応する新バージョン(Vn+1)の複製ファイル150を生成してNASシステム160に格納する。新規の複製ファイル150の生成を促進するために、前バージョンの複製ファイル250のインクリメンタル更新が有利に遂行される。これは以下で図5においてさらに説明される。どちらの方法が用いられるにせよ、このステップの最終結果は、新バージョン(Vn+1)の複製ファイル150が、NAS  160において全体のデータ処理システムに対して利用可能になるということである。
【００５１】
次いで、ステップ3で、新規の複製ファイル150の可用性が通知されなければならない。これは、例えば図3に示されたスレイブノード210といった、スレイブノード210、210'、210"のうちの1つによって行われる。この目的を達成するために、担当のマスタサーバ112によって、サーバ処理220、220'、220"、すなわちこのノード上で動作している特定のソフトウェアタスクならびに他のすべてのスレイブノード210'、210"にメッセージが送られる。次いで、そのときから、選択されたスレイブノード210は、すべてのスレイブノード210、210'、210"に対するシステムの同期ポイントとして働く。したがって、本発明の以下の説明では、選択されたスレイブノード210は「同期スレイブノード」210と称される。マスタ層の観点からすると、すべてのスレイブノードが同一の役割を果たす。そこで、同期スレイブノードの選択は、一般に作業負荷の検討に基づくものになる。
【００５２】
次のステップ4では、同期スレイブノード210のサーバ処理220のタスクの制御下で、複製ファイルの新バージョン150(new  version  150)の可用性の通知がすべての他のスレイブノード210'、210"に一斉送信される。
【００５３】
次いで、ステップ5で、同期スレイブノード210を含む各スレイブノード210、210'、210"は、新規の複製ファイル150の可用性の通知を受け取ると、
-  更新の遂行を担当するマスタサーバ112によって前もってNASシステム160に格納されている新規の利用可能な複製ファイル150をコピーする、すなわちプリロードするステップ51を、NASシステム160から行うステップと、
-  一旦、プリロードが適切に終了したら、各スレイブノード210、210'、210"のサーバ処理タスク220、220'、220"によって、無事完了の確認を同期スレイブノード210に返送するステップ52との2つのサブステップを遂行する。
【００５４】
同期スレイブノード210のサーバ処理タスク220は、プリロード完了成功の確認をすべて収集することも担当する。これが達成されると、次に、ステップ6で、すべてのスレイブノード210、210'、210"におけるプリロード達成成功の通知が、担当のマスタサーバ112に転送される。これは全般的な更新処理のステップ6である。このステップでは、新規の複製ファイル150は、各スレイブノード210、210'、210"の共有メモリ230、230'、230"にプリロードされており、したがって、これらのノードで動作するクライアントアプリケーションによって潜在的に使用可能である。しかし、新規の複製ファイル150は、次の更新処理のステップが遂行されるまで不活性に保たれる。
【００５５】
システムの内部データの更新処理の第2段階が図4bに示されている。第2段階は、ステップ6において、マスタサーバで、すべてのスレイブノード210、210'、210"による新規の複製ファイル150のプリロード達成成功の通知を受け取ることから始まる。プリロード達成のこの通知は、同期スレイブノード210のサーバ処理タスク220が発するものである。次いで、担当するマスタサーバ112は、ステップ7で、新規の複製ファイル150のバージョン(Vn+1)のデータをマスタデータベース120に格納し、このようにして、全体のデータ処理システムに新バージョン150の使用をコミットする。
【００５６】
コミットメントのステップは、ステップ8で、マスタサーバ112が発したコミットメントのメッセージを同期スレイブノード210のサーバ処理220のタスクに向けて送り、新規のプリロードされた複製ファイル150の(Vn+1)を用いる準備ができていることを同期スレイブノード210のサーバ処理220のタスクに知らせることによってさらに達成する必要がある。
【００５７】
コミットメントのメッセージを受け取ると、実際には、ステップ9で、新バージョンの複製データファイル150も、同期ノード210のサーバ処理タスク220によってスレイブデータベース260の中に送り込まれる。この段階では、各スレイブノード210、210'、210"に既にプリロードされている複製ファイルの新バージョン150は、実際には、以下で説明される切換えステップが始まるまで、スレイブノード210、210'、210"のクライアントアプリケーションによってまだ用いられていない。
【００５８】
それにもかかわらず、ステップ10で、マスタサーバ112は、同期ノード210のサーバ処理220のタスクから、スレイブデータベース260へのコミットメントの終了を知らせる返答を受け取る。この返答は、ステップ11で、データ処理システムの管理者のデータ処理デバイス140に対して、要求された更新142が実際にコミットされて現在有効になっていることを前記管理者に知らせるために、さらに伝搬される。
【００５９】
しかし、複製ファイルの新バージョン150の実際の使用が効力を生じるのは、システムの内部で、作用的処理が情報を求めるクエリに応答するために実際にそれを必要とするときのみとなる。本発明では、情報を求めるクエリとは、履行するのに、システムに格納されたデータを検索することを要求するクエリであり、更新要求クエリとは、履行するのに、格納されたデータを更新することを要求するクエリである。このように、情報を求めるクエリは、需要家または旅行代理店などのシステムのエンドユーザによって送られるのに対し、更新要求142は、エンドユーザに提供される商品、サービスまたは情報に関連するデータの更新を担当する管理者によって送られる。作用的処理の実行に際して、対応するクライアントアプリケーションは、必要とされる複製ファイルのどのバージョンを用いなければならないかというスレイブデータベース260からの問い合わせ264を常に調べる。共有メモリに既にプリロードされている複製ファイルの新バージョン150が利用可能であれば、次いで、この新バージョンへ切り換えられる。この切換えは、この点において、データベースのトランザクションに関して定義されたACIDルール、すなわち原子性、一貫性、独立性および永続性に適合するという意味で、いわゆる原子動作である。原子性は、クライアントアプリケーションによって遅延が引き起こされないように、切換えが完全に実行され、他の処理による割込みが生じないことを意味する。すべてのクライアントアプリケーション処理に対して同一のメカニズムが適用される。この解決策により、分散したレプリカのうちの任意のものから用いられるデータの完全な一貫性が保証される。この切換えが原子動作であるので、作用的処理が行き詰まる(freezing)可能性なしで複製ファイルの新バージョン150が取得される。複製ファイルのプリロードが更新処理の実行における早期に行われているので、クライアントアプリケーションが複製ファイルの新バージョン150にアクセスするとき、さらなる遅延が導入されることはない。
【００６０】
作用的処理の流れは、スレイブデータベース260に対する要求の数を最適化するために有利に修正することができる。実際、この同期ポイントを参照してよいのは、新規のキャッシュバージョンのプリロードとスレイブデータベース260におけるこの新バージョンのコミットの間の移行中のみである。
【００６１】
この趣旨で、プリロードの操作中に、共有メモリに「プリロード」インジケータが追加される。このインジケータがなければ、作用的処理はスレイブデータベース260に要求するのでなく、キャッシュの最新の利用可能なバージョンにアクセスすることになる。そうでなければ、スレイブデータベース260に対して要求され、次いでスレイブデータベース260からのバージョンが用いられる。
【００６２】
プリロードされたバージョンがスレイブデータベース260にコミットされている場合には、上記で説明した切換え操作が遂行される。この操作では、「プリロード」インジケータは共有メモリから削除される。
【００６３】
複製ファイルを、疑似リアルタイムでスレイブノード210、210'、210"に対して利用可能にする様子を説明している前の図で説明されたメカニズムは、システムの2つのタイプのノードに関する2つのタイプの動作を、以下のように明瞭に識別する。
-  マスタノード110は、場合によってはいくつかのマスタサーバ112で構成される書込みノードである。マスタノード110のそれぞれが、データ処理システムのいずれかの正規の管理者によってユーザインターフェース140を介して発行されたトランザクションを管理することができる。管理トランザクションは、最終的にはマスタデータベース120を更新するように意図されている。この目的を達成するために、既に論じられたように、管理トランザクションは、第1に新バージョン(Vn+1)の複製ファイル150を生成し、NASシステム160に格納する。本発明は、マスタノード110にはスレイブノード210、210'、210"の接続形態の知識がなく、スレイブノード210、210'、210"の中にさらなるデータをプッシュすることには関与しないと想定する。このように、アプリケーション200のスケーラビリティは、マスタノード110から完全に独立している。
-  その代わりに、スレイブノード210、210'、210"は、それ自体で、複製ファイルの読取り専用のコピーを共有のNASシステム160から直接プリロードすることによって取得する。スレイブノード210、210'、210"への情報の一斉送信は、前述の企業サービスバスまたはサービスインテグレータ(SI)によって行われる。可能な限り高い性能を保つために、一斉送信されるデータの容量は、有利には最小限に抑えられる。この目的を達成するために、本発明の方法は、スレイブノード210、210'、210"に対して新規の複製ファイルの可用性の通知を一斉送信することのみを管理し、それにより、図4で説明されたように、スレイブノード210、210'、210"が共通の共有ファイル構造、NAS  160から新規の複製ファイル150をコピーすることが可能になる。
【００６４】
疑似リアルタイムのレプリカ作成は、図4で論じられたように、ステップ11で、管理トランザクションが終了すると直ちに、すべてのクライアントノードが複製ファイルの新バージョン150へ実際に切り換えることができることを意味する。このタイプのレプリカ作成は、しばしば怠惰な(lazy)レプリカ作成とみなされる、あまり厳格でない他のタイプのレプリカ作成よりはるかに強制的で(constraining)熱心な(eager)タイプのレプリカ作成としても知られている。この結果を得るために、本発明は、データの流れを、制御の流れとデータの流れに分離する。したがって、前述のように、用いるべき複製ファイルのバージョンの通知が、サービスインテグレータによってクライアントノードに一斉送信される。複製ファイルのデータに関して、これらの複製ファイルは、共有ファイルシステムすなわちNASシステム160から利用可能になる。同期スレイブノード210を介してアプリケーション層200のすべての他のスレイブノード210'、210"へルーティングして伝達する必要があるのはバージョンを搬送する制御流れのみであり、一方、データは、各スレイブノード210、210'、210"へ並行して直接伝送することができる。このアーキテクチャは、マスタノード100のサーバ112すなわちライタとスレイブノード210、210'、210"の間を分離するという要件を満たす。このように、ライタは、新規のデータを先ずNAS共有ファイルシステムに格納し、次いでマスタデータベース120自体に格納するだけでよい。ライタは、スレイブノード210、210'、210"の接続形態のいかなる知識も有する必要はない。マスタサーバすなわちライタは、バージョン情報をスレイブノード210、210'、210"へルーティングするのをサービスインテグレータに依存する。
【００６５】
NASの共有ファイル構造への書込みが図5に示されている。図5は、新バージョン(Vn+1)の複製ファイル150を生成するときステップ2で遂行されるインクリメンタル更新を説明するものである。
【００６６】
複製ファイルを利用可能にする、すなわちNASシステム160などの共有ファイル構造から複製ファイルを公開すると、さらなる利点がもたらされる。更新要求142の処理を担当するマスタサーバ112は、すべてのスレイブノード210、210'、210"によって現在用いられている最複製ファイルの新バージョン250を得る(152)のに、NASの共有ファイル構造に容易にアクセスすることができる。NAS  160の二元構造は、複製ファイルの回復を容易にし、記憶装置の要件も最小化するために有利に考案されたものである。したがって、すべての複製ファイルを収容するのに必要な記憶装置の全体量をさらに制限するために、場合により複製ファイルを圧縮する。データ処理システムの期待される性能に適合するアクセス時間内に複製ファイルを回復することができる一方で、必要とされる記憶装置の全体量をなんとかして制限するように、アクセス時間と記憶装置の要件の間のトレードオフが必要になることがある。ファイルを伝送するネットワークの帯域幅の消費も考慮に入れられる。どちらで妥協するにせよ、マスタサーバは、取得した複製ファイルを、サーバメモリの中へ、作業することができるビジネスオブジェクトモデル(BOM)114に変換しなければならない。次いで、マスタサーバ112は、更新要求142で管理者が要求した変更を組み込むように、要求された更新を現行バージョンの複製ファイルに追加する際にインクリメンタル更新116を遂行することができる。
【００６７】
より正確には、マスタサーバは、取得した複製ファイルを、サーバメモリの中へ、C++ビジネスオブジェクトモデル114に変換しなければならない。次いで、マスタサーバ112は、C++構造116に対してこの更新を追加することにより、インクリメンタル更新を遂行することができる。次いで、この新規のC++構造に基づいて新規の複製ファイルが構築される。
【００６８】
このやり方は、対応する情報をマスタデータベース120から回復するのと比較して、複製ファイルの新バージョンを生成する処理をかなり速める。1桁(×10)の平均的な改善を達成することができる。更新された複製ファイルは、最終的には、変換されてNAS共有ファイル構造160へ戻して格納される(154)。
【００６９】
以下で、強一貫性が、本発明の状況で意味するもの、および、それぞれが別々の物理的マシン30、30'、30"上で実現されたスレイブノード210、210'、210"のすべての複製ファイルに対する前述のシステムおよび方法で得られる様子をさらに論じる。
【００７０】
本発明のデータ処理システムでは、マスタデータベース120は定期的に更新されると想定されている。考慮に入れるべき更新の一般的な頻度は毎分2、3回程度であるが、この数字は、主に本発明の用途に依拠して変化する可能性がある。それぞれの更新によって、新バージョン(Vn+1)の複製ファイル150が生成される。次いで、所与のバージョン、すなわちバージョンNの複製ファイルが所与のスレイブノードで読み取られ、いかなる他のスレイブノード210'、210"における後続の読取りも同一の複製ファイルのバージョンNを実際に返す場合には、その瞬間から強一貫性が達成される。明らかに、その間にも、複製ファイルの新バージョン150が既に配布されている場合には、より高位のバージョンが読み取られることがある。
【００７１】
一貫性は、すべての複製ファイルの有効なバージョンを記録する中央のアクセスポイントをすべてのスレイブノード210、210'、210"に与えることによって達成される。このアクセスポイントは、好ましくは、ACID特性を満たすことを保証するために標準的なリレーショナルデータベース管理システム(RDBMS)の下で動作するデータベースのテーブルとして実施される。本発明のシステムでは、図3に示されるように、この役割はスレイブデータベース260によって果たされる。格納されたバージョンテーブル262の抜粋が示されている。図示の実例では、BA-NGIがVn+1に対応しており、このことは、複製ファイルのバージョンVn+1、すなわち旅行プロバイダ英国航空(BA)によって管理されたNGIアプリケーションのデータを使用しなければならないことを意味する。NGIはNew  Generation  Inventory(新世代インベントリ)の頭字語であり、所与のルールデータに関与する、特定のアプリケーションの所有者を識別する。スレイブデータベースに格納された中央のバージョンテーブルは、図4に説明された2段階コミット処理で更新される。
【００７２】
次いで、スレイブノード上で動作するクライアントアプリケーションによって起動される各トランザクションの開始時点で、有効な複製ファイルのバージョンが、スレイブデータベース260のバージョンテーブル262から取得される(264)。現在用いられるものより大きい有効な複製ファイルバージョンが見つかった場合には、スレイブノード210、210'、210"は、直ちに複製ファイル150の新規のバージョン(Vn+1)に切り換える。図4で説明されたように、更新された複製ファイル150が、スレイブノード210、210'、210"の共有メモリ230、230'、230"に既にプリロードされているので、これが可能である。ここで、クライアントアプリケーションによって起動されたトランザクションが複製ファイルへのいくつかのアクセスを必要とする場合、システムは、このトランザクションの存続期間を通じて、その間に複製ファイルの新バージョン150が利用可能になったとしても、同一のバージョンを用いることを考慮しておく必要がある。これは、データベーストランザクションに適用されるACIDルールセットのうちの独立性ルールを満たす。
【００７３】
共有メモリのデータのアクセスに対してさらに高レベルの性能をもたらすために、各トランザクションの初めに、スレイブデータベースの上記の問い合わせ264は任意選択で飛ばして進まれてもよい。この場合、共有メモリに格納された複製ファイルが、複製ファイルの新バージョン150が利用可能かどうかを示すタグまたはフラグを含む必要がある。したがって、系統的にスレイブデータベースに問い合わせを送る代わりに、各トランザクションの開始時点で最初に調べられるのはこのタグである。このタグが、利用可能な複製ファイルの新バージョン150がないことを示す場合には、現行の複製ファイルが用いられる。このタグが、複製ファイルの新バージョン150が実際に利用可能であることを示す場合には、スレイブデータベースからバージョンテーブル262が読み取られ、その結果、作用的処理240、240'、240"は、新規のプリロードされた複製ファイルのバージョン(Vn+1)に切り換えることができる。複製ファイルの新バージョン150がプリロードされたときセットされたタグは、クライアントアプリケーションがその現行のトランザクションの処理を終了したときリセットされる。多数の処理が同一の複製ファイルにアクセスしている環境では、それらのうちの1つがタグをリセットする前にデータベースを調べなければならない処理は、ほんのわずかのはずである。
【００７４】
前述のメカニズムは、生産環境で機能するために、フォールトトレラントであることも必要である。完全な一貫性に達することができるのは、複製ファイルが、実際にすべて首尾よくプリロードされる場合、すなわち管理トランザクションがマスタデータベースにコミットされ得る前にすべてのスレイブノードの共有メモリの中に分散されてマッピングされる場合のみである。これは、スレイブノードが不可分のやり方で(in  an  atomic  manner)新規の複製ファイルに実際に切り換えることができることを保証するのに必須のことである。そうでなければ、いくつかのスレイブノードが新バージョンに切換え可能で他のスレイブノードが切換え不可能になり、それによって一貫性に欠けるエラーとなる場合があり得る。したがって、この状況が生じるのを防止するために、何らかの理由で、いずれかの所与のスレイブノードに対する分散が失敗した場合には、すべてのトランザクションが異常終了し、更新要求に応答してエンドユーザにエラーが送られる。これは、導入された、図4に説明されている2段階コミット処理のために可能になる。本発明は、一貫性と可用性の間で一貫性に重点を置くものである。しかし、スレイブノードからの読取りの可用性が引き続き十分に保証され、また、情報を求めるクエリがほぼリアルタイムで満たされ得るのを強調することが重要である。可用性が損なわれる可能性があるのは、データの更新/管理の部分のみである。本発明の状況では、これは、すべてのスレイブノードにわたって分散した複製ファイルの読取りの可用性および強一貫性と比べてはるかに重要性が低い。したがって、各スレイブノードへ複製ファイルを首尾よく分散することは、本発明の重要な部分である。以前に論じた企業サービスバスまたはサービスインテグレータ(SI)は、クライアントアプリケーション層に対してアクティブに関与するスレイブノードのグループのイメージが常に利用可能であることを確かめるのに用いられる。スレイブノードがグループに加わるとき、またはグループを去るとき、イメージは、本発明の方法を適切に実行することができるようにそれに応じて更新される。
【００７５】
本発明の好ましい実施形態が示され、説明されているが、本発明はそれに限定されるものではなく、以下の特許請求の範囲の範囲内で実施するようにさまざまに実施され得ることを明確に理解されたい。
【符号の説明】
【００７６】
30  コンピュータ、コンピュータ化されたプラットフォーム、物理的マシン
30'  コンピュータ、コンピュータ化されたプラットフォーム、物理的マシン
30"  コンピュータ、コンピュータ化されたプラットフォーム、物理的マシン
40  分散型データ処理システムに期待される特性
41  一貫性および可用性
42  可用性およびスケーラビリティ
43  強一貫性および完全な可用性を維持する一方で、いくらかのスケーラビリティを保つこと
100  マスタ層
110  マスタノード
112  マスタサーバ
114  適切なフォーマット
116  インクリメンタル更新
112  マスタサーバ
120  マスタデータベース
140  管理者
142  更新要求
150  複製ファイル
160  ネットワークに接続された記憶装置(NAS)
200  アプリケーション層
210  スレイブノード
210'  スレイブノード
210"  スレイブノード
220  サーバ処理
220'  サーバ処理
220"  サーバ処理
230  共有メモリ
230'  共有メモリ
230"  共有メモリ
240  作用的処理
240'  作用的処理
240"  作用的処理
250  キャッシュファイル、複製ファイル
260  スレイブデータベース
262  バージョンテーブル
264  問い合わせ
300  クライアント層
【図１】
2014535081.tif 000003
【図２】
2014535081.tif 000004
【図３】
2014535081.tif 000005
【図４ａ】
2014535081.tif 000006
【図４ｂ】
2014535081.tif 000007
【図５】
2014535081.tif 000008
【手続補正書】
【提出日】平成26年4月1日(2014.4.1)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
データ処理システムの複数のノードにわたって分散した複製ファイルのコピー間の一貫性を維持する方法であって、
複製ファイルの更新要求をマスタサーバで受け取るステップであって、前記複製ファイルがマスタデータベースで更新されることを前記更新要求が要求するステップと、
前記更新要求に基づいて、共有ファイルシステムの中で前記複製ファイルの新バージョンを生成して格納するステップと、
複数のスレイブノードに対して前記複製ファイルの前記新バージョンの可用性の通知を行うステップと、
前記可用性の通知を各スレイブノードで受け取るのに応答して、前記共有ファイルシステムから前記複製ファイルの前記新バージョンのコピーを各スレイブノードのメモリへプリロードし、前記プリロードの終了に際して前記プリロードの無事完了を確認するステップと、
各スレイブノードが前記マスタサーバに対して前記プリロードの無事完了を確認した場合に限って、前記複製ファイルの前記新バージョンを用いるように前記データ処理システムにコミットするステップと
を含む方法。
【請求項２】
前記複数のスレイブノードに対して前記複製ファイルの前記新バージョンの前記可用性の通知を行うステップが、
前記マスタサーバから、前記複数のスレイブノードから選択された同期スレイブノードへ、前記複製ファイルの前記新バージョンの前記可用性の通知を転送するステップと、
前記同期スレイブノードから、前記複数のスレイブノードの他のスレイブノードへ、前記可用性の通知を一斉送信するステップとを含む請求項1に記載の方法。
【請求項３】
各スレイブノードが、前記同期スレイブノードのサーバ処理に対して前記プリロードの無事完了を確認する請求項2に記載の方法。
【請求項４】
前記複数のスレイブノードのうちのすべての前記スレイブノードが、前記同期スレイブノードの前記サーバ処理に対して前記プリロードの無事完了を確認するのに応答して、前記同期スレイブノードからプリロード達成の通知を前記マスタサーバへ転送するステップをさらに含む請求項3に記載の方法。
【請求項５】
前記データ処理システムに対して前記複製ファイルの前記新バージョンを用いるようにコミットするステップが、
前記マスタサーバから前記同期スレイブノードへコミットメントの通知を転送するステップと、
前記コミットメントの通知を受け取るのに応答して、前記同期スレイブノードを用いてスレイブデータベースの中の前記複製ファイルの前記新バージョンの使用をトリガするステップと
を含む請求項2に記載の方法。
【請求項６】
ユーザからの情報を求めるクエリによって起動されたトランザクションに応答して、前記トランザクションに含まれる各スレイブノードにおけるスレイブデータベースに問い合わせを送るステップと、前記問い合わせに基づき、前記トランザクションに含まれる各スレイブノードに、前記複製ファイルの現行バージョンから前記複製ファイルの前記プリロードされた新バージョンへ切り換えるかどうかを指示するステップとをさらに含む請求項1に記載の方法。
【請求項７】
ユーザからの情報を求めるクエリによって起動されたトランザクションに応答して、前記トランザクションに含まれる各スレイブノードにおいて、前記複製ファイルの現行バージョンのタグを読み取るステップであって、前記タグが複製ファイルの新バージョンが利用可能かどうかを示すステップと、
前記タグが前記複製ファイルの新バージョンが利用可能であることを示すのに応答して、前記トランザクションに含まれる各スレイブノードにおける前記スレイブデータベースに問い合わせを送るステップと、
問い合わせに応答して、前記問い合わせを送ったスレイブノードに、前記複製ファイルの前記現行バージョンから前記複製ファイルの前記新バージョンへ切り換えるべきかどうかを指示するステップとをさらに含む請求項1に記載の方法。
【請求項８】
前記タグが、前記複製ファイルの前記新バージョンのプリロードの無事完了時にセットされ、前記スレイブノードによる最初の読取りでリセットされる請求項7に記載の方法。
【請求項９】
前記受け取られる更新要求が前記複製ファイルに関する更新を含み、前記共有ファイルシステムの中に複製ファイルの前記新バージョンを生成して格納するステップが、前記マスタサーバの中のインクリメンタル処理であって、
前記共有ファイルシステムから複製ファイルの現行バージョンを取得するステップと、
前記複製ファイルの前記現行バージョンを、更新される適切なフォーマットに変換するステップと、
前記複製ファイルの前記現行バージョンに前記更新を適用して、前記複製ファイルの前記新バージョンを生成するステップと、
前記複製ファイルの前記新バージョンを前記共有ファイルシステムに格納するように変換するステップと、
前記複製ファイルの前記新バージョンを前記共有ファイルシステムに格納するステップと
を含む請求項1に記載の方法。
【請求項１０】
前記複製ファイルが、前記共有ファイルシステムに格納されるとき圧縮され、前記複製ファイルの前記現行バージョンを前記適切なフォーマットに変換するステップが、
前記共有ファイルシステムに格納された前記複製ファイルの前記現行バージョンを、前記マスタサーバを用いて解凍するステップを含み、
前記複製ファイルの前記新バージョンの前記コピーをプリロードするステップが、前記スレイブノードを用いて前記複製ファイルの前記新バージョンを解凍するステップを含む請求項9に記載の方法。
【請求項１１】
前記複数のスレイブノードのうちの少なくとも1つのスレイブノードが、前記プリロードの無事完了の確認に失敗することに応答して、前記更新要求の送信元に、前記マスタサーバからエラー通知を送るステップをさらに含む請求項1に記載の方法。
【請求項１２】
前記共有ファイルシステムがネットワークに接続された記憶装置(NAS)を備える請求項1に記載の方法。
【請求項１３】
前記スレイブデータベースが格納するのは、複製ファイルのバージョンに関連するデータのみである請求項1に記載の方法。
【請求項１４】
プログラム命令を含む非一時的コンピュータ可読記憶メディアに記録したコンピュータプログラムであって、1つまたは複数のプロセッサが前記プログラム命令を実行すると、前記それぞれのプロセッサが、
更新要求をマスタサーバで受け取り、複製ファイルがマスタデータベースで更新されることを前記更新要求が要求し、
前記更新要求に基づき、共有ファイルシステムの中で前記複製ファイルの新バージョンを生成して格納し、
複数のスレイブノードに対して前記複製ファイルの前記新バージョンの可用性の通知を行い、
前記可用性の通知を各スレイブノードで受け取るのに応答して、前記共有ファイルシステムから前記複製ファイルの前記新バージョンのコピーを各スレイブノードのメモリへプリロードし、前記プリロードが完了したら前記プリロードの無事完了を確認し、
前記複数のスレイブノードのうちのすべてのスレイブノードが前記プリロードの無事完了を確認した場合に限って、前記複製ファイルの前記新バージョンを用いるように前記データ処理システムにコミットするコンピュータプログラム。
【請求項１５】
ビジネスルールを含み、データ処理システムの複数のノードにわたって分散した複製ファイルのコピー間の一貫性を維持する方法であって、
マスタデータベースに格納されたビジネスルールを更新するようにとの更新要求をマスタサーバで受け取るステップと、
前記更新要求に基づき、共有ファイルシステムの中で前記複製ファイルの新バージョンを生成して格納するステップと、
複数のスレイブノードに対して前記複製ファイルの前記新バージョンの可用性の通知を行うステップと、
前記可用性の通知を各スレイブノードで受け取るのに応答して、前記共有ファイルシステムから前記複製ファイルの前記新バージョンのコピーを各スレイブノードのメモリへプリロードし、前記プリロードが完了したら前記プリロードの無事完了を確認するステップと、
前記複数のスレイブノードのうちのすべてのスレイブノードが前記プリロードの無事完了を確認した場合に限って、前記複製ファイルの前記新バージョンを用いるように前記データ処理システムにコミットするステップと
を含む方法。
【請求項１６】
各ビジネスルールが1組の基準およびコンテンツを含む請求項15に記載の方法。
【請求項１７】
前記1組の基準のうちの各基準が重みに関連付けられている請求項16に記載の方法。
【請求項１８】
前記1組の基準が、売場、国、一群の国々、フライトの出発国、フライトの目的地、または顧客プロファイルを含む請求項15に記載の方法。
【請求項１９】
旅行プロバイダのインベントリが前記データ処理システムを備える請求項15に記載の方法。
【請求項２０】
前記スレイブノードのうち少なくとも1つが、航空会社のインベントリ、航空会社の出国管理システム、航空会社の収益管理システム、航空会社の収益会計システム、または航空会社の電子チケットサーバに接続されている請求項15に記載の方法。
【請求項２１】
前記データ処理システムに対して前記複製ファイルの前記新バージョンを用いるようにコミットするステップが、
すべての複製ファイルのバージョンを記録するように構成されたスレイブデータベースにおける前記複製ファイルの前記新バージョンの使用をコミットするステップと、
すべてのスレイブノードのコミットメントの通知を前記マスタサーバに転送するステップと、
前記マスタサーバから、前記受け取った更新要求に応答して、前記更新要求の達成を確認するステップと
を含む請求項15に記載の方法。
【請求項２２】
マスタサーバおよび共有ファイルシステムを含むマスタ層と、
複数のスレイブノードを含むアプリケーション層とを備え、各スレイブノードがメモリを有して前記マスタ層に通信で結合され、前記マスタサーバが、前記複数のスレイブノードへ前記共有ファイルシステムの中の複製ファイルの新バージョンの可用性の通知を行うように構成されており、
前記複数のスレイブノードの各スレイブノードが、前記可用性の通知を受け取るのに応答して、前記共有ファイルシステムから前記複製ファイルの前記新バージョンのコピーをプリロードし、前記プリロードが完了したら前記プリロードの無事完了を確認するように構成されており、
前記マスタサーバが、すべてのスレイブノードが前記プリロードの無事完了を確認することに応答して、前記データ処理システムに、前記複製ファイルの前記新バージョンを用いるように単にコミットするようにさらに構成されている分散型データ処理システム。
【請求項２３】
前記データ処理システムに対して前記複製ファイルの前記新バージョンを用いるようにコミットするステップが、
前記マスタデータベースの中の前記複製ファイルを前記複製ファイルの前記新バージョンに更新するステップと、
前記複数のスレイブノードによって用いられる複製ファイルのバージョンを記録するように構成されたスレイブデータベースの中のデータを更新するステップであって、前記データが、前記複数のスレイブノードによって用いられる前記複製ファイルの前記バージョンを識別するステップと、
前記スレイブデータベースの中の前記複製ファイルの前記バージョンを識別する前記データの更新に応答して、前記マスタサーバにおいて、前記複製ファイルの前記新バージョンを用いるようにとの前記複数のスレイブノードのうちの各スレイブノードのコミットメントの通知を受け取るステップとを含む請求項1に記載の方法。
【請求項２４】
前記複数のスレイブノードのうちのそれぞれのスレイブノードが、前記プリロードの無事完了を確認するのに応答して、前記マスタサーバでプリロード達成の通知を受け取るステップであって、前記マスタデータベースの中の前記複製ファイルを前記複製ファイルの前記新バージョンに更新するステップが、前記プリロード達成の通知を受け取るステップに応答するものであるステップをさらに含む請求項23に記載の方法。
【請求項２５】
前記スレイブデータベースにおける前記複製ファイルの前記新バージョンの前記使用をトリガするステップが、
前記複製ファイルの前記新バージョンのバージョン番号を用いて前記スレイブデータベースの中のバージョンテーブルを更新するステップを含む請求項5に記載の方法。
【国際調査報告】
2014535081.tif 000009
2014535081.tif 000010