JP2007334717A - 分散オブジェクトの高信頼化方式 - Google Patents
分散オブジェクトの高信頼化方式 Download PDFInfo
- Publication number
- JP2007334717A JP2007334717A JP2006166999A JP2006166999A JP2007334717A JP 2007334717 A JP2007334717 A JP 2007334717A JP 2006166999 A JP2006166999 A JP 2006166999A JP 2006166999 A JP2006166999 A JP 2006166999A JP 2007334717 A JP2007334717 A JP 2007334717A
- Authority
- JP
- Japan
- Prior art keywords
- orb
- server
- stub
- client
- mirror
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Hardware Redundancy (AREA)
Abstract
【課題】分散オブジェクトを用いたクライアント・サーバ型システムにおいて、一部のハードウェアが停止しても、実行中のソフトウェアを継続実行させ得る方式を提供する。
【解決手段】サーバをORBに登録すると同時に、サーバのミラーを作成するマシン情報をORBに通知し、ORBが、指定されたマシン上にサーバのミラーを複数作成すること、およびサーバが何らかの理由で実行を完了できないときに、ORBが、正しくない結果を返したサーバあるいは何も結果を返さなかったミラーを切り離すことを特徴とし、ORBが、サーバおよびそのミラーからの実行結果を受け取り、正しいものをスタブヘ返し、クライアントがその実行結果を受け取り、スタブをサーバと思ってアクセスするので、サーバが停止してもクライアントが実行を継続し、分散オブジェクト技術として高信頼化が図れる。
【選択図】図4
【解決手段】サーバをORBに登録すると同時に、サーバのミラーを作成するマシン情報をORBに通知し、ORBが、指定されたマシン上にサーバのミラーを複数作成すること、およびサーバが何らかの理由で実行を完了できないときに、ORBが、正しくない結果を返したサーバあるいは何も結果を返さなかったミラーを切り離すことを特徴とし、ORBが、サーバおよびそのミラーからの実行結果を受け取り、正しいものをスタブヘ返し、クライアントがその実行結果を受け取り、スタブをサーバと思ってアクセスするので、サーバが停止してもクライアントが実行を継続し、分散オブジェクト技術として高信頼化が図れる。
【選択図】図4
Description
本発明は、分散オブジェクトを用いたクライアント・サーバ型システムにおいて、サーバの可用性を向上させる方式に関し、詳細には、何らかの理由で一部のハードウェアが停止した場合でも、実行中のソフトウェアを継続実行させ得る方式に関する。
クライアント・サーバ型ソフトウェアは、例えば銀行のオンラインシステムや、Webにおけるオンライン取引を行うシステムの実現のために数多く用いられている。大規模オンラインシステムや、サーバシステムなどの情報システムは、その一時的な停止でさえも人間生活に大きな影響を与えるようになってきている。そのため、それらのシステムの信頼性を向上させることは大変に重要である。現在でも、いくつかの方法で信頼性を向上させる努力がなされている。
銀行のオンラインシステム等のような情報システムは、ソフトウェアとそれを実行するための計算機のハードウェアから構成されるが、計算機のハードウェアは、その安定性を向上させるために、これまで様々な努力がなされてきた。ハードウェアモジュールの2重化や、システムを稼働させたままでモジュールを入れ替えるホツトスワツプ機能などが、その例である。
しかしながら、いくら安定したハードウェアシステムであれ、100%停止させないで実行を継続させることは不可能である。例えば、システムの保守のための停止は必要不可欠であり、また、停電や地震などの外部要因によるハードウェアの停止は、単一のハードウェア白身の信頼性の向上のみでは防ぐことのできない問題である。
このような停止の際に問題となるのは、ハードウェアが停止した際には、そこで実行されているソフトウェアも停止しまうことである。組み込み型のソフトウェアを別にして、ソフトウェアとハードウェアはもともと独立して存在しているものであるから、例えば、実行中のソフトウェアを他の計算機に移動させることができれば、実行を継続できるはずでる。
そこで、何らかの理由でハードウェアが停止した場合でも、実行中のソフトウェアを継続実行させる方式が必要となるが、そのために現在用いられている代表的な方式が、ハードディスクのミラーリング、フォールト・トーレラント・コンピュータ(FTC)、およびサーバのクラスタリングである。
ハードディスクのミラーリングは、データを書き込む際に、同一のデータを複数のハードディスクに同時に書き込むことにより信頼性を向上させる方式である。このため、一つのハードディスクに障害が起きた場合でも複数のディスクが全部故障しない限り、データが保障される。
またFTCでは、対故障性を高めるために、コンピュータを構成する各モジュールを冗長化(多重化)構成にしている。これにより、ひとつのモジュールが故障しても冗長化したモジュールで実行を継続することができる。
サーバのクラスタリング方式は、複数のサーバとなるコンピュータを相互接続することでクラスタを構成し、一つのコンピュータのように振舞わせる。現在、実用レベルに達しているものに、汎用的なクラスタリングシステムやWebアプリケーション専用のクラスタリングシステムなどがある。サーバのクラスタリングの実装方式はいくつかあるが、標準的な方式では、クラスタ内のサーバの中で、主系となるものが通常時はアプリケーションを実行し、他のサーバは待機系として主系のサーバを監視しており、主系に障害が起こったと判断した時は、待機系が主系となってアプリケーションを実行する。
しかしながら、ハードディスクのミラーリングでは、何か障害が発生した場合、データに関する信頼性は向上するが、処理の継続性が保証されないという問題がある。従って、ミラーリングだけでは、システムの信頼性を向上させるためには不十分で、他の方式と共に用いられることが多い。
FTCでは、各々のコンピュータの対故障性は向上させることができるものの、高価な専用ハードウェアが必要になる。また、最近は負荷分散のために分散システムを用いることも多く、分散システム全体の可用性の向上にはコストが掛かり過ぎて向いていない。また停電やサーバの定期保守などの際には、1台しかないサーバの停止に伴い、システム全体が停止してしまうという問題もある。
一方、サーバのクラスタリングでは、FTCとは異なり、停電や定期保守の際にも別の場所の別のサーバを使用してシステムの実行を継続できるという利点があるが、サーバに不具合が発生した場合、ロールバック、即ち停止した処理の再実行が発生してしまうという問題がある。サーバのクラスタリングでは、サーバアブリケーションを実行するサーバマシンごとに複製を作成することになる。言わば、アプリケーションレベルのクラスタリングである。従って、あるサーバマシン上で問題が発生すると、別のサーバマシンにアプリケーションごと切り替わるため、問題が発生したサーバマシン上で実行途中であった処理は失われてしまい、切り替わったサーバマシン上で再実行が必要となってしまう。しかも、そのロールバックは、アプリケーション単位で行われるため、再実行が必要となる処理が大きくなってしまうという問題がある。
特開2006−146580号
本発明は、上述した従来の問題点に鑑みてなしたもので、既存のアプリケーションレベルでのクラスタリングと異なり、オブシェクトレベルでのミラーリングを提案するものである。オブジェクトのミラーリングには、以下の3つの目的がある。
すなわち、これまでの方式では、RAIDシステムやFTCなどの特定のハードウェアを必要とする場合が多いが、オブジェクトのミラーリングでは、特定のハードウェアに依存しない高可用性システムを構築することを第1の目的とする。
また、アプリケーションのクラスタリングでは、サーバの切り替えの際に、ロールバックが発生することが問題であることは上述の通りであるが、オブジェクトのミラーリングでは、アプリケーションレベルではなく、より細粒度のオブジェクトレベルで多重化を図るだけでなく、FTCのようにオブジェクトを冗長構成として並列実行することにより、ロールバック作業ならびに切り替え作業を不要にすることを第2の目的とする。
さらに、アブリケーションレベルの粒度の大きなクラスタリングでは、クラスタリングするアプリケーションには手を加えないでそのまま多重化できるという利点があり、その一方ではオブジェクトレベルで細粒度の多重化を行う場合には、オブジェクト自身やそれを使用するアプリケーションに何らかの変更を加える必要が発生してしまう可能性がある。そこで、アプリケーションのクラスタリングと同様に、多重化されるオブジェクトや、それを使用するシステムに対しては、多重化のための変更を特に行う必要がないようにすることを第3の目的とする。
本発明は、既存のアプリケーションレベルでのクラスタリングと異なり、オブシェクトレベルでのミラーリングを提案するものである。
以下、分散オブジェクト技術の概要と、分散オブジェクトのミラーリングの概要について述べるが、次のような用語の使い分けを行う。或るオブジェクトが他のオブジェクトのメソッドを呼び出している場合、呼び出す側のオブジェクトをクライアント、呼び出される側のオブジェクトをサーバという。オブジェクトのサーバと計算機のサーバを区別するため、計算機のサーバに言及する必要がある場合は、サーバマシンという。また、あるオブジェクトのメソッドをネットワーク越しに他のホスト上のオブジェクトから呼び出すことができる時、そのメソッドをリモートメソッドという。リモートメソッドを含むオブジェクトをリモートオブジェクトあるいはリモートサーバという。
分散オブジェクト技術の概要について説明する。近年、クライアント・サーバ型システムは、RMIやCORBA等の分散オブジェクト技術を用いて実装することが多くなった。これは、クライアントとサーバ間での通信処理をTCP/IP等を用いて直接実装するよりも、RMIやCORBAを用いて実装することにより、開発効率が向上するだけでなく、汎用性の高い方式で実装できるからである。
これらの分散オブジェクト技術を利用してクライアント・サーバ型のシステムを開発する際には、Object Request Broker(ORB)と呼ばれるミドルウエアを使用することが一般的である。ORBには大分して2つの役割がある。まず、クライアントが自分とは離れたホスト上に存在するリモートサーバを検索する時に使用される。また。見つかったリモートサーバに対するメソッドの呼び出しや、その結果の受け取りもORBを経由して行われる。
現在では、数種類の分散オブジェクト技術が存在するが、それらは異なるORBを提供している。RMIやCORBAなどの分散オブジェクト技術でも、独自のORBを使用している。最近では、異なるORB間の通信プロトコルを定めたIIOPも開発されているので、異なるORB間での互換性も少しずつではあるが、実現されつつある。RMIやCORBA、RMI−IIOPといった標準的なORBの他にも、HORB、Voyagerなどの数多くのORBが開発され、提供されている。
これらの分散オブジェクト技術に共通する点は、図1に示す標準的分散オブジェクトモデルの通り、サーバ側とクライアント側にそれぞれ独自の代理オブジェクトを用いることである。これをJava(登録商標)言語での実装を例にとって説明する。
Java(登録商標)においては、RMIを代表とし、CORBAのJava(登録商標)での実装であるJava(登録商標)lDLや、RMI−IIOP、HORBなどが全てこの形式をとっている。代理オブジェクトの名称は、それぞれの方式において異なってはいるが、多くの場合、クライアント側の代理オブジェクトをスタブ、サーバ側の代理オブジェクトをスケルトンと呼ぶ。通常、スタブやスケルトンはORB側が提供するツールによってクライアントやサーバのコードから自動生成されるため、クライアントやサーバの開発者が自分で記述する必要はない。そのため、スタブやスケルトンはORBの一部としての機能も持つことが多い。
クライアント側とサーバ側にそれぞれ代理オブジェクトを置くモデルでは、クライアントとサーバ自身は、自分が分散環境にいることをそれほど意識しなくて済む。それは、代理オブジェクトが、クライアントやサーバに代わってネットワーク処理を行うからである。
すなわち、クライアント側では、スタブはサーバの参照としての役割を果たす。またクライアント側では、スタブをサーバだと思ってアクセスする。すると、スタブが、クライアントに代って0RBを介してサーバをアクセスすることになる。サーバとなるオブジェクトは、ネットワークを介したJava(登録商標)仮想マシン(JVM)上に存在するのであるが、クライアントは、自分と同じJVMにあるスタブをアクセスするため、ネットワークの存在を意識する必要は軽減される。ただし、多くの分散オブジェクト技術において、全く意識しなくて済むわけではない。クライアントは、スタブをORBから取得する作業と、スタブをアクセスする際でも、ネットワークに起因する例外の処理などを行う必要はある。なお、代理オブジェクト自身の存在をクライアントやサーバから透過的にするシステムにはTRMIがある。
一方、サーバ側でも、スタブからのアクセスをORBを経由して直接受け付けるのは、サーバ側の代理オブジェクトであるスケルトンとなる。スケルトンが、ネットワーク越しにアクセスを受け付け、それを同一JVM上のサーバに渡す。サーバは、受け取ったアクセスがクライアントからのものであるかのように処理を行うことができる。処理の結果は再びスケルトンとスタブを経由してクライアントに返ざれる。
図2は基本的な分散オブジェクト技術における処理の流れを示す図であり、サーバが何らかの理由で停止する例である。下記説明における(1)等は、図に示した処理の番号に対応している。
(1)サーバをORBに登録する。
(2)クライアントがサーバをORBで検索する。
(3)サーバが見つかった場合は、ORBはサーバのスタブを生成する。
(4)ORBはスタブの参照をクライアントヘ返す。
(5)クライアントはスタブをサーバと思ってアクセスする。
(6)スタブはクライアントからのサーバヘのアクセス要求をORBへ渡す。
(7)ORBはクライアントからの要求を指定されたサーバヘ渡す。
(8)サーバが要求を実行する。
(9)サーバが実行結果をORBに返す。
(10)スタブはORBから実行結果を受け取る。
(11)クライアントがスタブから実行結果を受け取る。
(12)サーバが何らかの理由で停止する。
(13)クライアントはスタブをサーバと思ってアクセスする。
(14)スタブはクライアントからのサーバヘのアクセス要求をORBへ渡す。
(15)ORBはクライアントからの要求を指定されたサーバヘ渡そうとするがサーバが停止しているので渡せない。
(16)クライアントは待ち状態となり、実行を継続できなくなってしまう。
もちろん(12)においてサーバが停止しなければ、(1)から(11)の処理が所要の処理が済むまで繰り返される。
(1)サーバをORBに登録する。
(2)クライアントがサーバをORBで検索する。
(3)サーバが見つかった場合は、ORBはサーバのスタブを生成する。
(4)ORBはスタブの参照をクライアントヘ返す。
(5)クライアントはスタブをサーバと思ってアクセスする。
(6)スタブはクライアントからのサーバヘのアクセス要求をORBへ渡す。
(7)ORBはクライアントからの要求を指定されたサーバヘ渡す。
(8)サーバが要求を実行する。
(9)サーバが実行結果をORBに返す。
(10)スタブはORBから実行結果を受け取る。
(11)クライアントがスタブから実行結果を受け取る。
(12)サーバが何らかの理由で停止する。
(13)クライアントはスタブをサーバと思ってアクセスする。
(14)スタブはクライアントからのサーバヘのアクセス要求をORBへ渡す。
(15)ORBはクライアントからの要求を指定されたサーバヘ渡そうとするがサーバが停止しているので渡せない。
(16)クライアントは待ち状態となり、実行を継続できなくなってしまう。
もちろん(12)においてサーバが停止しなければ、(1)から(11)の処理が所要の処理が済むまで繰り返される。
次に、分散オブジェクト技術を利用してクライアント・サーバ型のシステムにおいて分散オブジェクトのミラーリングを行うモデル、すなわち0RBに対してミラーリングの機能を追加する方式MMI(Mirrored Method Invocation)における新規な処理の流れを説明する。
MMIでは、前述の分散オブジェクトのモデルを拡張し、分散オブジェクトの高信頼化を図っている。MMIは、サーバの複製をいくつかのホスト上に生成し、それを同時にアクセスしてそれらの複製の状態を常に同じに保っておくことにより、いくつかの複製が使用不能になっても、残りの複製でシステムの運用に支障がないようにする方式である。しかも、クライアントやサーバの開発者にとっては、通常の分散オブジェクトを開発しているという認識のみで、高信頼化が達成できる。即ち、クライアントやサーバの開発者は、サーバの複製を自分で生成する必要が無いだけではなく、複製が作られていることさえも認識しなくてよい。
図3は、MMIの分散オブジェクトモデルである。MMIでは、サーバ側で分散オブジェクトを生成してORBに登録すると、その複製となるオブジェクトが複数個、異なるマシン上に自動的に生成される。このオブジェクトの複製をミラーと言う。そして、クライアントが分散オブジエクトをORBに対して要求すると、0RBは特定のミラーに依存しない参照であるスタブをクライアントに返す。クライアント側では、通常のJava(登録商標)の分散オブジェクトモデルと同様、クライアントがスタブをサーバだと思ってアクセスを行う。そのスタブを用いて、クライアントがサーバのメソッドを呼び出すと、すべてのミラーの同じメソッドが同時に実行される。
クラスタリングでは、一時に動作しているアブリケーションは一つのみであり、待機しているアプリケーションが複数存在していたが、ミラーリングでは、クラスタリングと異なり、複数のミラーが同時に動作していることに特徴がある。またサーバ側で実行が終了すると、その結果はスケルトンとスタブを経由してクライアントヘ返される。しかし、複数のミラーの実行結果を別々に返すことはできない。そこで、複数のミラーの実行結果は、0RBによって取りまとめられて、ひとつのサーバの実行結果であるかのようにクライアントヘ返される。従って、クライアントはサーバが一台だけ存在しているという認識で、複数のミラーを同時にアクセスすることができる。
MMIのORBは、サーバのどのミラーが正常であるかを常に監視しており、正常なミラーのみを用いてクライアントからの要求に笞える。また、ORBは、異常を検知したミラーを切り離す機能を持つ。異常なミラーとは、他のミラーと異なる実行結果を返したミラーや、一定時間経過しても結果を返さないミラーなどである。従って、常に動作しているミラーのみで実行を継続するため、MMIにおいてはミラーの切り替え作業やロールバックはあたかも発生していないかのように、クライアントからは認識される。
さらに、ORBは異常の発生したミラーを、可能な場合に限り自動的に復元する機能を持つ。それは、他の正常なミラーの複製を生成することにより行う。もちろん、ミラーホスト自身が停止しているような場合は、ミラーホスト自身が人手あるいはその他の方法で修復された後に、ミラーの復元が行われる。この作業が、ロールバックであるが、クライアントからは透過的に行われる。
このように、クライアントはサーバ側のオブジェクトがどのような状態でミラーリングされているか意識する必要はない。このため、クライアントは通常の分散型のアプリケーションを実行している感覚で。障害の発生を意識せずに安定して動作することが可能となる。
なお、MMIでは、0RB自身をクライアントやサーバから隠すことを目的としているわけではない。MMIでは、クライアントやサーバは、ORBが提供するAPIを経由して、通常通りメソッド呼び出しなどの処理を行う。従って、クライアントはORBの存在を通常通り意識する必要がある。ただし、サーバはクライアントからは透過的に多重化されていることに特徴がある。
図4は、MMI方式における処理の流れを示す図であり、図2の例と同様に、サーバが何らかの理由で停止する例である。下記説明における(1)等は、図に示した処理の番号に対応している。
(1)サーバをORBに登録すると同時にサーバのミラーを作成するマシン情報をORBに通知する。
(2)ORBは指定された指定された一または複数のマシン上にサーバのミラー(複製)を複数作成する。この例では、ミラーは2つ作成する。もちろん、ミラーの個数は2つに限定されるものではない。
(3)クライアントがサーバをORBで検索する。
(4)ORBはサーバのスタブを作成する。スタブは特定のミラーにはよらない。
(5)ORBはスタブヘの参照をクライアントヘ返す。
(6)クライアントはスタブをサーバと思ってアクセスする。
(7)スタブはクライアントからのサーバヘのアクセス要求をORBへ渡す。
(8)ORBは、クライアントからの要求をサーバとその全てのミラーに渡す。
(9)サーバおよびそのミラーが要求を実行する。
(10)サーバが何らかの理由で実行を完了できない。
(11)実行を完了できたミラーが実行結果をORBへ返す。
(12)ORBは、サーバおよびそのミラーからの実行結果を受け取り、正しいものをスタブヘ返す。
(13)ORBは正しくない結果を返したサーバあるいは何も結果を返さなかったミラーを切り離す。
(14)クライアントがスタブから実行結果を受け取る。
(15)クライアントはスタブをサーバと思ってアクセスする。
(16)スタブはクライアントからのサーバヘのアクセス要求をORBへ渡す。
(17)ORBは、クライアントからの要求を生きているミラーに渡す。
(18)ミラーが要求を実行する。
(19)実行を完了できたミラーが実行結果をORBへ返す。
(20)ORBは、ミラーからの実行結果を受け取り、正しいものをスタブヘ返す。
(21)クライアントがスタブから実行結果を受け取ることができ、サーバが停止してもクライアントは実行を継続できる。
(1)サーバをORBに登録すると同時にサーバのミラーを作成するマシン情報をORBに通知する。
(2)ORBは指定された指定された一または複数のマシン上にサーバのミラー(複製)を複数作成する。この例では、ミラーは2つ作成する。もちろん、ミラーの個数は2つに限定されるものではない。
(3)クライアントがサーバをORBで検索する。
(4)ORBはサーバのスタブを作成する。スタブは特定のミラーにはよらない。
(5)ORBはスタブヘの参照をクライアントヘ返す。
(6)クライアントはスタブをサーバと思ってアクセスする。
(7)スタブはクライアントからのサーバヘのアクセス要求をORBへ渡す。
(8)ORBは、クライアントからの要求をサーバとその全てのミラーに渡す。
(9)サーバおよびそのミラーが要求を実行する。
(10)サーバが何らかの理由で実行を完了できない。
(11)実行を完了できたミラーが実行結果をORBへ返す。
(12)ORBは、サーバおよびそのミラーからの実行結果を受け取り、正しいものをスタブヘ返す。
(13)ORBは正しくない結果を返したサーバあるいは何も結果を返さなかったミラーを切り離す。
(14)クライアントがスタブから実行結果を受け取る。
(15)クライアントはスタブをサーバと思ってアクセスする。
(16)スタブはクライアントからのサーバヘのアクセス要求をORBへ渡す。
(17)ORBは、クライアントからの要求を生きているミラーに渡す。
(18)ミラーが要求を実行する。
(19)実行を完了できたミラーが実行結果をORBへ返す。
(20)ORBは、ミラーからの実行結果を受け取り、正しいものをスタブヘ返す。
(21)クライアントがスタブから実行結果を受け取ることができ、サーバが停止してもクライアントは実行を継続できる。
すなわち、オブジェクトのミラーリングでは、特定のハードウェアに依存しない高可用性システムを構築でき、アプリケーションレベルではなく、より細粒度のオブジェクトレベルで多重化を図れ、ロールバック作業ならびに切り替え作業を不要とし、多重化されるオブジェクトや、それを使用するシステムに対しては、多重化のための変更を特に行う必要がないようにしている。
以下本発明を実施するための最良の形態を、図に示す実施例を参照して説明する。
この図5に示す実施例は、本発明の方式を、旧方式を用いて実装することが可能であることを示すものである。以下に、その場合の処理の流れを示す。
(1)サーバを新ORBに登録すると同時にサーバのミラーを作成するマシン情報を新ORBに通知する。
A:サーバを新ORBに登録すると同時にサーバのミラーを作成するマシン情報を新ORBに通知する。
B:新ORBはサーバを旧ORBに登録する。
(2)新ORBは指定されたマシン上にサーバのミラーを作成する。この例では、ミラーはやはり2つ作成するものとする。もちろん、ミラーの個数は2つに限定されない。
A:新ORBは指定されたマシン上にサーバのミラーを作成する。
B:新ORBは作成したミラーを旧ORBに登録する。
(3)クライアントがサーバを新ORBで検索する。
A:クライアントがサーバを新ORBで検索する。
B:新ORBがサーバおよびそのミラーを旧ORBで検索する。
(4)新ORBはサーバのスタブを作成する。スタブは特定のミラーにはよらないものである。
A:旧ORBはサーバおよび2つのミラーの個別の旧スタブを作成する。
B:旧ORBは旧スタブの参照を新ORBへ通知する。
C:新ORBは特定のミラーにはよらないサーバのスタブを作成する(旧ORBの上位で新ORBが統轄することになる)。
(5)新ORBはスタブヘの参照をクライアントヘ返す。
A:新ORBは新スタブヘの参照をクライアントヘ返す。
(6)クライアントは新スタブをサーバと思ってアクセスする。
(7)新スタブはクライアントからのサーバヘのアクセス要求を新ORBへ渡す。
(8)新ORBは、クライアントからの要求を、旧スタブと旧ORBを介してサーバとその全てのミラーに渡す。
A:新ORBはクライアントからの要求を旧スタブヘ渡す。
B:旧スタブはクライアントからの要求を旧ORBへ渡す。
C:旧ORBは、クライアントからの要求をサーバやミラーに渡す。
(9)サーバおよびそのミラーが要求を実行する。
(10)サーバが何らかの理由で実行を完了できない。
(11)実行を完了できたミラーが実行結果を旧ORBへ返す。
(12)新ORBは、サーバおよびそのミラーからの実行結果を受け取り、正しいものをスタブヘ返す。
A:旧ORBは実行結果を旧スタブヘ返す。
B:旧スタブはそれぞれの実行結果を新ORBへ返す。
C:新ORBは各旧スタブからの実行結果を受け取り、正しいものを選択し、正しい実行結果を新スタブヘ返す。
(13)新ORBは正しくない結果を返したサーバあるいは何も結果を返さなかったミラーを切り離す。
(14)クライアントが新スタブから実行結果を受け取る。
(1)サーバを新ORBに登録すると同時にサーバのミラーを作成するマシン情報を新ORBに通知する。
A:サーバを新ORBに登録すると同時にサーバのミラーを作成するマシン情報を新ORBに通知する。
B:新ORBはサーバを旧ORBに登録する。
(2)新ORBは指定されたマシン上にサーバのミラーを作成する。この例では、ミラーはやはり2つ作成するものとする。もちろん、ミラーの個数は2つに限定されない。
A:新ORBは指定されたマシン上にサーバのミラーを作成する。
B:新ORBは作成したミラーを旧ORBに登録する。
(3)クライアントがサーバを新ORBで検索する。
A:クライアントがサーバを新ORBで検索する。
B:新ORBがサーバおよびそのミラーを旧ORBで検索する。
(4)新ORBはサーバのスタブを作成する。スタブは特定のミラーにはよらないものである。
A:旧ORBはサーバおよび2つのミラーの個別の旧スタブを作成する。
B:旧ORBは旧スタブの参照を新ORBへ通知する。
C:新ORBは特定のミラーにはよらないサーバのスタブを作成する(旧ORBの上位で新ORBが統轄することになる)。
(5)新ORBはスタブヘの参照をクライアントヘ返す。
A:新ORBは新スタブヘの参照をクライアントヘ返す。
(6)クライアントは新スタブをサーバと思ってアクセスする。
(7)新スタブはクライアントからのサーバヘのアクセス要求を新ORBへ渡す。
(8)新ORBは、クライアントからの要求を、旧スタブと旧ORBを介してサーバとその全てのミラーに渡す。
A:新ORBはクライアントからの要求を旧スタブヘ渡す。
B:旧スタブはクライアントからの要求を旧ORBへ渡す。
C:旧ORBは、クライアントからの要求をサーバやミラーに渡す。
(9)サーバおよびそのミラーが要求を実行する。
(10)サーバが何らかの理由で実行を完了できない。
(11)実行を完了できたミラーが実行結果を旧ORBへ返す。
(12)新ORBは、サーバおよびそのミラーからの実行結果を受け取り、正しいものをスタブヘ返す。
A:旧ORBは実行結果を旧スタブヘ返す。
B:旧スタブはそれぞれの実行結果を新ORBへ返す。
C:新ORBは各旧スタブからの実行結果を受け取り、正しいものを選択し、正しい実行結果を新スタブヘ返す。
(13)新ORBは正しくない結果を返したサーバあるいは何も結果を返さなかったミラーを切り離す。
(14)クライアントが新スタブから実行結果を受け取る。
すなわちこの実施例においても、オブジェクトのミラーリングでは、特定のハードウェアに依存しない高可用性システムを構築できる。またアプリケーションレベルではなく、より細粒度のオブジェクトレベルで多重化を図れ、ロールバック作業及び切り替え作業を不要とする。したがって、多重化されるオブジェクトや、それを使用するシステムに対しては、多重化のための変更を特に行う必要がない。
Claims (4)
- 分散オブジェクトを用いたクライアント・サーバ型システムにおいて、一部のハードウェアが何らかの理由により停止した場合であっても、実行中のソフトウェアを継続実行させ得る方式であって、
サーバをORBに登録すると同時に、該サーバのミラーを作成するマシン情報をORBに通知するステップ、
前記ORBが、指定された一または複数のマシン上に前記サーバのミラーを複数作成するステップ、
クライアントが前記サーバを前記ORBで検索するステップ、
前記ORBが、前記サーバの、特定のミラーにはよらないスタブを作成するステップ、
前記ORBが前記スタブヘの参照を前記クライアントヘ返すステップ、
前記クライアントが前記サーバに代えて前記スタブをアクセスするステップ、
前記スタブが、前記クライアントからの前記サーバヘのアクセス要求を前記ORBへ渡すステップ、
前記ORBが、前記クライアントからの要求を前記サーバとその全ての前記ミラーに渡すステップ、
前記サーバおよびその前記ミラーが要求を実行するステップ
前記サーバが何らかの理由で実行を完了できないときに、実行を完了できた前記ミラーの少なくとも一が該実行結果を前記ORBへ返すステップ、
前記ORBが、前記サーバおよびそのミラーからの実行結果を受け取り、正しいものを前記スタブヘ返すステップ、
前記ORBが、正しくない結果を返したサーバあるいは何も結果を返さなかったミラーを切り離すステップ、
前記クライアントが前記スタブから実行結果を受け取るステップ、
前記クライアントが前記スタブをサーバと思ってアクセスするステップ、
前記スタブが前記クライアントからの前記サーバヘのアクセス要求を前記ORBへ渡すステップ、
前記ORBが、前記クライアントからの要求を生きているミラーに渡すステップ、
前記生きているミラーが要求を実行するステップ、
実行を完了できた前記ミラーが実行結果を前記ORBへ返すステップ、そして
前記ORBが、前記ミラーからの実行結果を受け取り、正しいものを前記スタブヘ返し、前記クライアントが、前記スタブから実行結果を受け取ることができ、前記サーバが停止しても前記クライアントが実行を継続するステップ
からなることを特徴とする分散オブジェクトの高信頼化方式。 - 分散オブジェクトを用いたクライアント・サーバ型システムにおいて、一部のハードウェアが何らかの理由により停止した場合であっても、実行中のソフトウェアを継続実行させ得る方式であって、
サーバをORBに登録すると同時に該サーバのミラーを作成するマシン情報をORBに通知するステップであって、
・前記サーバを新ORBに登録すると同時に該サーバのミラーを作成するマシン情報を新ORBに通知し、
・前記新ORBは前記サーバを旧ORBに登録し、
前記ORBが、指定された一または複数のマシン上に前記サーバのミラーを複数作成するステップであって、
・前記新ORBは指定されたマシン上にサーバのミラーを作成し、
・前記新ORBは作成したミラーを前記旧ORBに登録し、
クライアントが前記サーバをORBで検索するステップであって、
・前記クライアントが前記サーバを前記新ORBで検索し、
・前記新ORBが前記サーバおよびそのミラーを前記旧ORBで検索し、
前記ORBが、前記サーバの、特定のミラーにはよらないスタブを作成するステップであって、
・前記旧ORBは前記サーバおよび複数の前記ミラーの個別の旧スタブを作成し、
・前記旧ORBは前記旧スタブの参照を前記新ORBへ通知し、
・前記新ORBは特定のミラーにはよらないサーバのスタブを作成し、
前記新ORBが前記スタブヘの参照を前記クライアントヘ返すステップであって、
・前記新ORBは前記新スタブヘの参照を前記クライアントヘ返すステップ、
前記クライアントは前記新スタブをサーバと思ってアクセスし、前記新スタブは前記クライアントからのサーバヘのアクセス要求を前記新ORBへ渡すステップ、
前記新ORBは、前記クライアントからの要求を、前記旧スタブと前記旧ORBを介してサーバとその全てのミラーに渡すステップであって、
・前記新ORBは前記クライアントからの要求を前記旧スタブヘ渡し、
・前記旧スタブは前記クライアントからの要求を前記旧ORBへ渡し、
・前記旧ORBは、クライアントからの要求を前記サーバや前記ミラーに渡し、
前記サーバおよびそのミラーが要求を実行するステップ、
前記サーバが何らかの理由で実行を完了できないときには、実行を完了できたミラーが実行結果を前記旧ORBへ返すステップ、
前記旧ORBが、前記サーバおよびそのミラーからの実行結果を受け取り、正しいものをスタブヘ返すステップであって、
・前記旧ORBは実行結果を旧スタブヘ返し、
・前記旧スタブはそれぞれの実行結果を前記新ORBへ返し、
・前記新ORBは前記各旧スタブからの実行結果を受け取り、正しいものを選択し、正しい実行結果を前記新スタブヘ返し、
前記新ORBが、正しくない結果を返したサーバあるいは何も結果を返さなかったミラーを切り離すステップ、そして
前記クライアントが新スタブから実行結果を受け取るステップ
からなることを特徴とする分散オブジェクトの高信頼化方式。 - 分散オブジェクトを用いたクライアント・サーバ型システムにおいて、
サーバをORBに登録すると同時に、該サーバのミラーを作成するマシン情報をORBに通知し、該ORBが、指定されたマシン上に前記サーバのミラーを作成し、クライアントが前記サーバを前記ORBで検索し、
前記ORBが、前記サーバの、特定のミラーにはよらないスタブを作成し、前記ORBが前記スタブヘの参照を前記クライアントヘ返し、該クライアントが前記サーバに代えて前記スタブをアクセスし、
前記スタブが、前記クライアントからの前記サーバヘのアクセス要求を前記ORBへ渡し、該ORBが、前記クライアントからの要求を前記サーバとその全ての前記ミラーに渡し、前記サーバおよびその前記ミラーが要求を実行し、
前記サーバが何らかの理由で実行を完了できないときに、実行を完了できた前記ミラーの少なくとも一が該実行結果を前記ORBへ返し、該ORBが、前記サーバおよびそのミラーからの実行結果を受け取り、正しいものを前記スタブヘ返し、
前記クライアントが前記スタブから実行結果を受け取り、前記クライアントが前記スタブをサーバと思ってアクセスし、前記スタブが前記クライアントからの前記サーバヘのアクセス要求を前記ORBへ渡し、該ORBが、前記クライアントからの要求を生きているミラーに渡し、該生きているミラーが要求を実行し、
実行を完了できた前記ミラーが実行結果を前記ORBへ返し、該ORBが、前記ミラーからの実行結果を受け取り、正しいものを前記スタブヘ返し、前記クライアントが、前記スタブから実行結果を受け取ることができ、前記サーバが停止しても前記クライアントが実行を継続する分散オブジェクトの高信頼化方式において、
前記ORBが、指定された一または複数のマシン上に前記サーバのミラーを複数作成し、
また前記サーバが何らかの理由で実行を完了できないときに、前記ORBが、正しくない結果を返したサーバあるいは何も結果を返さなかったミラーを切り離すことを特徴とする分散オブジェクトの高信頼化方式。 - 分散オブジェクトを用いたクライアント・サーバ型システムにおいて、
サーバをORBに登録すると同時に該サーバのミラーを作成するマシン情報をORBに通知するに際し、前記サーバを新ORBに登録すると同時に該サーバのミラーを作成するマシン情報を新ORBに通知し、前記新ORBは前記サーバを旧ORBに登録し、
前記新ORBは指定されたマシン上にサーバのミラーを作成し、前記新ORBは作成したミラーを前記旧ORBに登録し、クライアントが前記サーバをORBで検索するに際し、前記クライアントが前記サーバを前記新ORBで検索し、前記新ORBが前記サーバおよびそのミラーを前記旧ORBで検索し、
前記ORBが、前記サーバの、特定のミラーにはよらないスタブを作成し、前記旧ORBは前記サーバおよび複数の前記ミラーの個別の旧スタブを作成し、前記旧ORBは前記旧スタブの参照を前記新ORBへ通知し、前記新ORBは特定のミラーにはよらないサーバのスタブを作成し、前記新ORBが前記スタブヘの参照を前記クライアントヘ返すに際し、前記新ORBは前記新スタブヘの参照を前記クライアントヘ返し、前記クライアントは前記新スタブをサーバと思ってアクセスし、前記新スタブは前記クライアントからのサーバヘのアクセス要求を前記新ORBへ渡し、
前記新ORBは、前記クライアントからの要求を、前記旧スタブと前記旧ORBを介してサーバとその全てのミラーに渡すに際し、前記新ORBは前記クライアントからの要求を前記旧スタブヘ渡し、前記旧スタブは前記クライアントからの要求を前記旧ORBへ渡し、前記旧ORBは、クライアントからの要求を前記サーバや前記ミラーに渡し、前記サーバおよびそのミラーが要求を実行し、前記サーバが何らかの理由で実行を完了できないときには、実行を完了できたミラーが実行結果を前記旧ORBへ返し、前記旧ORBが、前記サーバおよびそのミラーからの実行結果を受け取り、正しいものをスタブヘ返すに際し、前記旧ORBは実行結果を旧スタブヘ返し、前記旧スタブはそれぞれの実行結果を前記新ORBへ返し、前記新ORBは前記各旧スタブからの実行結果を受け取り、正しいものを選択し、正しい実行結果を前記新スタブヘ返し、
前記クライアントが新スタブから実行結果を受け取る分散オブジェクトの高信頼化方式において、
前記ORBが、指定された一または複数のマシン上に前記サーバのミラーを複数作成し、
前記新ORBが、正しくない結果を返したサーバあるいは何も結果を返さなかったミラーを切り離すことを特徴とする分散オブジェクトの高信頼化方式。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006166999A JP2007334717A (ja) | 2006-06-16 | 2006-06-16 | 分散オブジェクトの高信頼化方式 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006166999A JP2007334717A (ja) | 2006-06-16 | 2006-06-16 | 分散オブジェクトの高信頼化方式 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2007334717A true JP2007334717A (ja) | 2007-12-27 |
Family
ID=38934129
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006166999A Pending JP2007334717A (ja) | 2006-06-16 | 2006-06-16 | 分散オブジェクトの高信頼化方式 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2007334717A (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010009519A (ja) * | 2008-06-30 | 2010-01-14 | Canon Inc | サービスフロー処理装置及びサービスフロー処理方法 |
CN111259083A (zh) * | 2020-02-13 | 2020-06-09 | 神州数码融信软件有限公司 | 分布式事务处理方法及装置 |
-
2006
- 2006-06-16 JP JP2006166999A patent/JP2007334717A/ja active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010009519A (ja) * | 2008-06-30 | 2010-01-14 | Canon Inc | サービスフロー処理装置及びサービスフロー処理方法 |
CN111259083A (zh) * | 2020-02-13 | 2020-06-09 | 神州数码融信软件有限公司 | 分布式事务处理方法及装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5102901B2 (ja) | データセンタにわたる複数データサーバ間のデータ完全性を保持する方法およびシステム | |
US8230256B1 (en) | Method and apparatus for achieving high availability for an application in a computer cluster | |
US7523344B2 (en) | Method and apparatus for facilitating process migration | |
US6718486B1 (en) | Fault monitor for restarting failed instances of the fault monitor | |
Treaster | A survey of fault-tolerance and fault-recovery techniques in parallel systems | |
US6789114B1 (en) | Methods and apparatus for managing middleware service in a distributed system | |
US8560889B2 (en) | Adding scalability and fault tolerance to generic finite state machine frameworks for use in automated incident management of cloud computing infrastructures | |
US6978398B2 (en) | Method and system for proactively reducing the outage time of a computer system | |
KR100297906B1 (ko) | 동적인구성변화를지원하는방법및그장치 | |
KR0137406B1 (ko) | 고장 방지 컴퓨터 시스템 | |
CN101227315B (zh) | 动态服务器集群及其控制方法 | |
US20040205414A1 (en) | Fault-tolerance framework for an extendable computer architecture | |
US7444335B1 (en) | System and method for providing cooperative resource groups for high availability applications | |
JP2011060055A (ja) | 仮想計算機システム、仮想マシンの復旧処理方法及びそのプログラム | |
JP2008059583A (ja) | クラスタ・システムならびにクラスタ・システム内でレプリカをバックアップする方法およびプログラム製品 | |
CN110727709A (zh) | 一种集群数据库系统 | |
US8015432B1 (en) | Method and apparatus for providing computer failover to a virtualized environment | |
Lumpp et al. | From high availability and disaster recovery to business continuity solutions | |
CN101201767A (zh) | 计算机系统数据的磁盘镜像备份与恢复系统及方法 | |
JP2007334717A (ja) | 分散オブジェクトの高信頼化方式 | |
US20190124145A1 (en) | Method and apparatus for availability management | |
JP2006277724A (ja) | 処理装置及びその障害復旧方法と障害回復方法 | |
Rathore et al. | Comparative analysis of checkpointing | |
Bouizem et al. | Integrating request replication into FaaS platforms: an experimental evaluation | |
Lüthi et al. | Concepts for dependable distributed discrete event simulation. |