JP2010086227A - 計算機間相互結合網における通信経路の冗長化と切り替え方法、この方法を実現するサーバ装置、そのサーバモジュール、および、そのプログラム - Google Patents

Abstract

【課題】通信経路上で障害が発生した場合の迅速な通信経路の切り替え動作を維持しながら、従来の自明な通信経路冗長化方式が持つ問題を解決する。
【解決手段】正常動作時には、冗長化された通信経路のうちの１つだけを使用してホストＡ、Ｂ間でのデータ転送を行う。ホストＡでは、データがディスクから読み出され主メモリ上のセグメント（ＲＤＭＡ領域）に格納されていくとともに、ＬＭＲ群１を用いて通信経路１経由でＲＤＭＡによりそれらのデータがホストＢへ転送される。ホストＢでは、ＬＭＲ群１を用いて通信経路１から受信したデータを主メモリに格納する。通信経路１に障害が発生すると、ホストＡ、ＢはＲＤＭＡに使用するＬＭＲ群を１から２へ切り替え、まだホストＢへ転送していない主メモリ上のセグメントから、ＲＤＭＡによるデータ転送を再開する。
【選択図】図１０

Description

ＰＣ（Personal Computer）などの計算機を複数台接続して１つの高速な計算機システムを構築するＰＣクラスタリング分野において、計算機間を接続する相互結合網の構成を冗長化して通信経路の耐障害性を向上させる、ＰＣクラスタシステム内部通信の高信頼化手法に関する。

処理能力が低いかわりに安価であるＰＣ等の小型計算機を多数接続して、１台の大型で高速な計算機システムと同等の処理能力を有するシステムを経済的に構築する、ＰＣクラスタリングとよばれる技術がある。このＰＣクラスタリング技術は、科学技術計算システム、データセンター等における各種サーバ、大容量ストレージシステムなどの構築手法として幅広い分野で用いられている。

ＰＣクラスタリングにおいて、ＰＣ間の接続に用いられる物理伝送媒体を相互結合網と呼ぶ。相互結合網には様々な種類があり、それぞれが持つ通信機能の特色を生かした使い分けがなされている。相互結合網の具体的な例としては、Ｍｙｒｉｎｅｔ，Ｆｉｂｒｅ Ｃｈａｎｎｅｌ，ＩｎｆｉｎｉＢａｎｄなどがある。さらに通常は、１種類の相互結合網においても、その上位レイヤでは複数の種類の通信方式（プロトコル）を動作させることができる。図１にＰＣクラスタシステムの概要を示す。

これら数ある相互結合網の中でも、高速性、低価格性、使い易さ等が評価され、近年のＰＣクラスタシステムにおいて最も広く用いられているのがＩｎｆｉｎｉＢａｎｄ（非特許文献１）である。そして、このＩｎｆｉｎｉＢａｎｄの上位レイヤではＴＣＰ／ＩＰ，ＳＤＰ，ＭＰＩ等の様々な種類のプロトコルが動作可能であるが、その中の代表的なプロトコルの１つにｕＤＡＰＬ（user direct access programming library）（非特許文献２）がある。

ｕＤＡＰＬとは、ＩｎｆｉｎｉＢａｎｄ等の幾つかの相互結合網自体が持つＲＤＭＡ（remote direct memory access）機能を、相互結合網の種類に依らない共通のソフトウェアインタフェースを介して利用できるようにするための統一されたＡＰＩ（application interface）、および、データ転送プロトコルを提供するソフトウェア体系である。ここで、ＲＤＭＡとは、従来から広く用いられている、１台の計算機における入出力（Ｉ／Ｏ）処理の高速化技術であるＤＭＡ（ｄirect memory access）を、ＬＡＮ（local area network）や相互結合網で接続された遠隔の計算機間の通信に拡張したものである。

ＤＭＡでは、計算機に直結された外部装置との間のデータの入出力（Ｉ／Ｏ）の際に、ＣＰＵをほとんど使用せずに当該外部装置のコントローラが自計算機の主メモリに直接アクセスしてデータ転送を行うことで、計算機にかかる処理負荷の低減やデータ入出力の高速化を図る。

ＲＤＭＡにおいても同様に、遠隔の計算機どうしの主メモリ間でＣＰＵをほとんど使用しないデータ転送が行えるため、非常に低負荷かつ高速な計算機間通信が可能となる。実際、ｕＤＡＰＬはＩｎｆｉｎｉＢａｎｄの上位レイヤで動作するプロトコル群の中でも最も高速な物の１つであり、重要性が高まっている。

ＲＤＭＡでは、データ送信や受信の対象となる計算機の主メモリの領域をあらかじめ通信相手に対して公開し、データ転送経路を確立した後に通信を開始するのが本質的な動作形態となる。この点において、その他の一般的なデータ転送方式、すなわち、送信側では受信側の最終的なデータの格納場所を認識せずにデータを送信し、受信側ではデータを受信するたびにアドホックに格納場所を決定するような方式とは異なっている。

後者のような方式では、計算機間であらかじめ通信経路を確立しない非コネクション型通信が可能であるのに対し、前者のＲＤＭＡにおいては、計算機間で事前に通信経路を確立するコネクション型通信が前提となる。

さらに、データの送信／受信処理の対象となるメモリ領域を明示的に指定する必要がある。

したがってｕＤＡＰＬも、このようなＲＤＭＡの本質的な動作形態を反映したもの、すなわち、コネクション設定機構やデータ転送の対象となる主メモリ領域の抽象化機構等を中心としたＡＰＩとなっている。以下にｕＤＡＰＬのＡＰＩの概要を説明する。

まず、ｕＤＡＰＬのＡＰＩで用いられる主なオブジェクト群を図２に示す。ＩｎｆｉｎｉＢａｎｄ ＨＣＡ（Host Channel Adapter）を搭載したホストＡ（以降、ＰＣ等の小型計算機をホストと呼ぶ）とホストＢとがＩｎｆｉｎｉＢａｎｄスイッチ経由で接続されており、上記ホストの主メモリ間でＲＤＭＡによるデータ転送を行うことを前提とした図である。なお、ここではホストＡがＲＤＭＡのイニシエータ、すなわち、ＲＤＭＡによるデータ転送を発動する側となる場合を示している。

前述のように、ｕＤＡＰＬはコネクション型の通信方式を採用している。図２のＥＰ（End Point）は、通信主体となるアプリケーションプロセス間のコネクションの端点を抽象化したオブジェクトである。コネクションはＥＰ間で確立され、１対１接続のみが可能である。アプリケーションプロセスは通信処理を起動する際、自身が保持するＥＰのうちの特定の１つを指定する。これにより、その通信に使われるコネクション（と通信の相手となるＥＰ）が特定される。

なお、本明細書では、ホストのＨＣＡとＩｎｆｉｎｉＢａｎｄスイッチ間の物理的な１本の接続回線を通信リンクと呼ぶ。また、ＥＰ間で確立された論理的な通信経路をコネクションと呼ぶ。

ＬＭＲ（Local Memory Region）は、通信動作の対象となる主メモリの領域を抽象的に表現するためのオブジェクトである。１つのＬＭＲは、単一の連続した仮想的なメモリ領域を表す。アプリケーションプロセスはこのＬＭＲが表す仮想的な連続メモリ領域の全部、あるいは一部を指定して通信処理を起動する。ＬＭＲはその使用に先立って、それが対応づけられている（マッピングされている）主メモリの実際の物理的な領域が決定されている。そのため、ＬＭＲの指定は当該通信処理の対象となる主メモリの領域を指定することを意味する。

ＲＭＲ（Remote Memory Region）は、自ホスト内のＬＭＲにマッピングされた主メモリの領域に対する遠隔ホストからのアクセス制限に関する設定のためのオブジェクトである。ＲＭＲはＬＭＲの全部、あるいは一部対してバインドすることができ（図は１つのＲＭＲをＬＭＲの全領域にバインドした場合を示している）、バインドされたＬＭＲの領域にマッピングされている主メモリの領域に対してＲＭＲに付随して設定したアクセス制限が適用される。すなわち、ＬＭＲから任意の領域を切り出してアクセス制限を柔軟に設定するためのメモリウインドウを提供する。

ＰＺ（Protection Zone）は、各種オブジェクトをグループ化し、グループ外のオブジェクトからの操作を排除する手段を提供するオブジェクトである。上記ＥＰ、ＬＭＲ、ＲＭＲはそれぞれ、その生成時にただ１つのＰＺと関連づけられる。あるＥＰを経由して実行される通信操作は、そのＥＰが属するＰＺと同じＰＺに属するＬＭＲやＲＭＲにマッピングされた主メモリの領域にしかアクセスできない。

ＥＶＤ（Event Dispatcher）は、ｕＤＡＰＬの各種操作の完了をイベントとして通知するためのオブジェクトである。前述のＥＰはその生成時において、メッセージ受信完了通知用ＥＶＤ（ｒｅｃｅｉｖｅ ＥＶＤ）、メッセージ送信／ＲＤＭＡ ｒｅｅｄ／ＲＤＭＡ ｗｒｉｔｅ／ＲＭＲのＬＭＲへのマッピング完了通知用ＥＶＤ（ｒｅｑｕｅｓｔ ＥＶＤ）、ＥＰ間コネクション確立通知用ＥＶＤ（ｃｏｎｎｅｃｔ ＥＶＤ）の３つのＥＶＤと関連づけられる。アプリケーションプロセスは当該ＥＰを介して行ったこれらの動作の完了を各ＥＶＤからのイベント通知により認識する。

なお、上記ＥＰ、ＬＭＲ、ＲＭＲ、ＰＺ、ＥＶＤの各オブジェクトは、その生成時に１つのＩｎｆｉｎｉＢａｎｄ ＨＣＡに関連づけられる。

以上がｕＤＡＰＬのＡＰＩで用いられる主なオブジェクト群の説明である。次に、これらを用いて実際に通信を行う際の手順を説明する。例えば、ホストＡがホストＢの主メモリ内のデータをＲＤＭＡによって読み出し、自身の主メモリ内に格納する場合の手順は以下の（１）〜（９）のようになる。本手順の概要を図３に示す。

（１）ホストＡは、ＲＤＭＡによってアクセスすべきホストＢのメモリ領域（ターゲットメモリ領域）に関する情報を要求する。この要求メッセージ自体はホストＡの主メモリ内の要求送信バッファ内に格納されており、このバッファとマッピングされているＬＭＲ、および、ＥＰを指定してメッセージ送信動作を起動する。（この動作はＲＤＭＡの機能を使用しない通常のメッセージ送信である。ホストＡは、送信したメッセージがホストＢの主メモリ上のどの場所に格納されるかを知らないことに留意）。

（２）ホストＡは、送信用ＥＶＤからの送信動作完了イベント通知を通して上記メッセージ送信が正常に完了した事を確認する。

（３）ホストＡは、メモリ情報受信バッファにマッピングされているＬＭＲとＥＰを指定して、ホストＢからのメモリ情報受信動作を起動する。

（４）ホストＡは、受信用ＥＶＤからの通知を通してホストＢからのメモリ情報の受信完了を待つ。

（５）ホストＢは、自身の主メモリ内の要求受信バッファにマッピングされているＬＭＲ、および、ＥＰを指定して、ホストＡからのメモリ要求受信動作を起動する。

（６）ホストＢは、受信用ＥＶＤからの通知を通してホストＡからのメモリ情報要求の受信完了を待つ。

（７）ホストＢは、ホストＡからのメモリ情報要求を受信すると、要求受信バッファに格納されたメモリ要求の内容を確認し、ホストＡからのＲＤＭＡによるメモリアクセスを許可する主メモリ領域（ＲＤＭＡ領域）に関する情報、具体的には、開始アドレス、レングス、アクセスキーの３つ組（ｒｍｒ＿ｔｒｉｐｌｅｔ）の送信動作を起動する。この時送信する内容は主メモリのメモリ情報送信バッファに格納しておき、この領域にマッピングされたＬＭＲとＥＰを指定してメッセージ送信を行う。（この動作もＲＤＭＡとは異なる通常のメッセージ送信である）。

（８）ホストＢは、送信用ＥＶＤからの送信動作完了イベント通知を通して上記メッセージの送信完了を待つ。この完了を確認すると、（３）の動作に戻る。（ホストＢはＲＤＭＡ処理そのものの開始・終了については感知しない）。

（９）ホストＡは、受信用ＥＶＤからのイベント通知を通してホストＢからのメモリ情報の受信を確認すると、メモリ情報受信バッファに格納された、ホストＢからのメモリ情報（ｒｍｒ＿ｔｒｉｐｌｅｔ）を用いて、（７）のＲＤＭＡ動作の起動処理に移る。

（１０）主メモリ上のＲＤＭＡ領域にマッピングされたＬＭＲを用いてその主メモリ領域をデータ受信用領域に指定し、上記ｒｍｒ＿ｔｒｉｐｌｅｔによりターゲットとなるホストＢの主メモリ領域を指定して、また、ＥＰを指定して、ＲＤＭＡ ｒｅａｄ処理を起動する。この処理を起動した後は、（９）で用いたのと同一の受信用ＥＶＤを用いてＲＤＭＡ ｒｅａｄの終了通知を待つ。

（１１）ＩｎｆｉｎｉＢａｎｄの物理層、および、リンクレイヤの機能によりＲＤＭＡによる実際のデータ転送が行われる。ホストＢの主メモリ上のＲＤＭＡ領域内のデータがＩｎｆｉｎｉＢａｎｄで扱われる最大データ長（４Ｋｂｙｔｅ）より大きい場合、当該データは複数のパケットに分割されてホストＡに転送される。ホストＡでは、受信したパケットを主メモリ上のＲＤＭＡ領域に格納していく。ホストＡ、Ｂにおいてこれらの処理がほとんどＣＰＵの介在なく行われる。

（１２）ホストＡは、ＥＶＤからの通知によりＲＤＭＡ ｒｅａｄの終了を確認すると、ホストＢの当該ＬＭＲに相当するＲＤＭＡ領域の全てのデータがホストＡの当該ＬＭＲに相当するＲＤＭＡ領域に転送されたと判断する。引き続き他のＲＤＭＡ領域を使用してＲＤＭＡ転送を続ける場合は（１）へ戻る。

以上がｕＤＡＰＬによるＲＤＭＡ通信手順の概要である。なお、上記はＲＤＭＡ ｒｅａｄの説明であるが、イニシエータが対向ホストへデータを送信するＲＤＭＡ ｗｒｉｔｅの場合も、データの転送方向が異なる以外は同様の動作手順となる。

本明細書は、コネクション設定機構やデータ転送の対象となる主メモリ領域の抽象化機構を持つＡＰＩから成る通信方式を対象とする。現時点でその唯一の具体例として挙げられるものがｕＤＡＰＬである。

INFINIBAND NETWORK ARCHITECTURE、MINDSHARE、INC.、 Tom Shanley、PC SYSTEM ARCHITECTURE SERIES、Addison-Wesley (2003)、ISBN 0-321-11765-4. uDAPL:User Direct Access Programming Library, Version 2.0, DAT collaborative.

バージョン１．２までの従来のｕＤＡＰＬでは、通信経路の耐障害性向上のための仕組み、すなわち、通信経路の冗長化や障害発生時の通信経路の切り替え等の仕組みを提供していなかった。現在のｕＤＡＰＬバージョン２．０では、これらの機能をＨＡ（High Availability）機能としてオプションでサポートするとしている（非特許文献２、Page 58-62）。しかし、そのＡＰＩにおいて、ＥＰのコネクション設定の冗長化の指定方法については明記されている（非特許文献２、Page 231, 233）ものの、ＬＭＲと組み合わせた場合の動作等について詳細が明記されておらず、不明な点が多い。

したがって、現状、相互結合網の耐障害性を図るには、アプリケーションソフトウェアレベルでユーザ自身が明示的に耐障害性を考慮したアーキテクチャを実現する以外に方法がない。その場合、以下の２つの自明な方式が考えられる。

（方式１）冗長化した通信経路の全てに常時同じデータを冗長的に流すが、実際にはそのうちの１つの通信経路上のデータのみを使用する。障害が発生した際には、使用するデータを他の通信経路上のデータに切り替える。

（方式２）通信経路は冗長化するが、ただ１つの通信経路にのみデータを流し通信を行う。障害が発生した際には、使用する通信経路を切り替え、その新しい通信経路にのみデータを流す。

図４は、（方式１）を図示したものである。ホストＡが外部装置であるディスクからデータを主メモリ内に読み出した後、それがホストＢの主メモリにＲＤＭＡによって転送され、ホストＢはその受信データをＮＩＣ経由でネットワークに配信する例である。ホストＡ、Ｂ間のＲＤＭＡ通信の耐障害性を向上するため、コネクション１、２に対応した２つの通信経路による冗長化を図っている。

ホストＡ、Ｂの主メモリ上には、通信経路１、および、通信経路２に対応したＲＤＭＡ領域１、２が存在する。そして、これらのＲＤＭＡ領域は複数のセグメントに分割されており、各セグメントに対して１つずつＬＭＲがマッピングされている。ＲＤＭＡ領域１内の各セグメントにマッピングされたＬＭＲの集合をＬＭＲ群１、ＲＤＭＡ領域２内の各セグメントにマッピングされたＬＭＲの集合をＬＭＲ群２と呼ぶ。すなわち、図４は、各通信経路に対して図２に示したＲＤＭＡ領域、および、ＬＭＲを複数保持する例である。

ホストＡは、主メモリ上のセグメントと同じサイズのデータを読み出し、セグメントへ順番に格納していく。ディスク上の１つのデータについて、必ず２重に読み出し、一方をＲＤＭＡ領域１内のセグメント、もう一方をＲＤＭＡ領域２内のセグメントに格納する。このようにして、同じデータをＲＤＭＡ領域１、２に冗長化して格納していく。

また、ＬＭＲ群１、２を用いて、常時通信経路１、２の両方を使用しながら、ＲＤＭＡ領域１、２に格納されたデータがホストＡからホストＢへ転送される（ＲＤＭＡのイニシエータはどちらのホストでも構わない）。ホストＡのＲＤＭＡ領域１内のデータは通信経路１経由でホストＢのＲＤＭＡ領域１へ、ホストＡのＲＤＭＡ領域２内のデータは通信経路２経由でホストＢのＲＤＭＡ領域２へ転送される。

各通信経路上では、１回のＲＤＭＡ動作で１つのセグメント内のデータが転送され、これを繰り返すことによってデータ転送が継続して行われる。なお、このデータ転送動作はディスクからのデータ読み出し動作と並行して行われる。

以上のようにして、ディスクから読み出された全てのデータが冗長化され、冗長化された通信経路を経由してホスト間で転送される。

ホストＢは、ホストＡからのデータ受信動作と並行して、コネクション１、２のどちらか一方からのデータをＮＩＣ経由でネットワークへ配信する動作を行う。

ここで、例えば通信経路１からのデータをネットワークに配信している最中に同通信経路上で障害が発生し通信できなくなった場合、ホストＢは、そのＮＩＣ上で、ネットワークへ配信するデータを通信経路２からのデータに切り替える。このようにして、ネットワークに対し途切れのないデータ配信を継続する。

この例から分かるように、（方式１）では、ホスト間で冗長化された通信経路のうちの一部の通信経路に障害が発生してもホスト間のデータ転送が途切れることがない。図４の例では、ホストＢのＮＩＣ上でネットワークへ配信するデータの供給元となる通信経路を切り替えるだけで、システムとしての正常な動作が維持できる。データを流す通信経路の切り替えが必要ないので、後述する（方式２）が有するような、通信経路の切り替えに伴うＲＤＭＡ領域間でのデータのコピーや移動処理が必要ない、という利点がある。

しかし、（方式１）では、常時データを冗長化して転送するため、ホストの処理負荷や通信に使用する各種リソースの消費量が増大するという問題がある。図４の例では、
・ホストＡにおけるディスクからのデータ読み出し
・ホストＡにおけるデータ送信
・ホストＢにおけるデータ受信
の処理が常時二重化されている。ホストＡの送信処理、および、ホストＢの受信処理はＲＤＭＡによって行われるため、ホストのＣＰＵにかかる負荷は小さい。しかし、ディスクからのデータ読み出し処理は、ホストの処理負荷を増大させることがある。また、ディスクのような外部装置とのデータの入出力性能は、システムの全体性能の支配項となる場合が多く、Ｉ／Ｏバス等この部分のリソースの消費量を増やすことはシステムの全体性能を向上させる上で得策でないことが多い。特に、高速・大容量のデータ通信を行うシステムほどこのような問題は深刻となる。以上が（方式１）の問題点である。

一方、図５は、（方式２）を図示したものである。図４と同様に本例も、ホストＡが外部のディスクからデータを主メモリ内に読み出した後、それがホストＢの主メモリにＲＤＭＡによって転送され、ホストＢはその受信データをＮＩＣ経由でネットワーク上に配信する。ホストＡ、Ｂ間の通信経路も図４の例と同様に２重化している。

図４と異なる点は、２つの通信経路のうちのただ１つの通信経路にのみデータを流して通信を行う点である。正常時において、ホストＡのディスクから読み出されたデータは、主メモリの通信経路１用のＲＤＭＡ領域１へ格納されたのち、ＲＤＭＡによって通信経路１を用いてデータをホストＢへ転送される。ホストＢは、主メモリの通信経路１用のＲＤＭＡ領域１に受信したデータを、ＮＩＣを経由してネットワークへ配信する。図５ではこの状態でのデータの流れを実線矢印で示している。

本動作中に通信経路１上で障害が発生すると、ホストＡとホストＢは、使用する主メモリのＲＤＭＡ領域、および、ＬＭＲ群を通信経路１用から通信経路２用の物へと切り替える。これにより、切り替え後は、図中の破線矢印で示すように、ディスクから読み出されたデータは通信経路２を経由してホストＢへ転送され、ネットワークへ配信される。

このように（方式２）では、データ転送そのものは冗長化しないため、ホストの処理負荷や各種リソースの消費量が増大するという（方式１）のような問題はない。

しかし、（方式２）では、障害発生時にデータを流す通信経路を切り替える操作が必要であり、この時に、主メモリ上のＲＤＭＡ領域間でデータをコピー（または移動）したり、あるいは、新しく使用するＲＤＭＡ領域へ外部装置からデータを再度読み出さなければならない場合がある。例えば図６に示すように、通信経路１上で障害が発生した時に、ホストＡのＲＤＭＡ領域１内にまだホストＢへの転送が完了していないデータが残っていた場合を考える。この場合ホストＡは、このデータを通信経路２経由でホストＢへ転送できるようにするため、以下の（Ａ）、（Ｂ）のうちのいずれかを実行する必要がある。

（Ａ）ＲＤＭＡ領域１内の未転送データをＲＤＭＡ領域２へコピー（または移動）する（図７）。

（Ｂ）ＲＤＭＡ領域１内の未転送データと同じデータを再度ディスクから読み出し、ＲＤＭＡ領域２へ格納する（図８）。

なお、図のように１回のＲＤＭＡ動作におけるデータ転送単位（本例では１つのセグメント）内のデータのＲＤＭＡ転送の途中で通信経路１に障害が発生し、当該ＲＤＭＡ転送が途中で異常終了した場合は、上記（Ａ）、（Ｂ）のいずれかを完了した後、当該セグメントの先頭からＲＤＭＡ転送を再開する。これは、各回のＲＤＭＡの進行状況はアプリケーションプロセスでは把握できず、異常終了するまでに転送したデータ量を正確に把握することができないため、初めから実行し直す必要があるためである。

そして、上記（Ａ）または（Ｂ）の実行中は、ホストＡ、Ｂ間のデータ転送は停止する。そのため、ホストＢからのネットワークへのデータ配信がとぎれないようにするには、ホストＡ側で上記の動作をできるだけ高速に実行する必要がある。しかし、特にシステムが高速・大容量のデータを扱う場合、上記のコピー（移動）や再読み出しを行うデータ量が大きくなる傾向があり、上記の動作を高速に実行することは容易ではない。

本発明の目的は、通信経路上で障害が発生した場合の迅速な通信経路の切り替え動作を維持しながら、上述の従来の自明な通信経路冗長化方式が持つ問題を解決することである。

上記課題を解決するための手段として、外部装置とのデータの入出力、および、ホスト間でのＲＤＭＡ転送の対象となる主メモリの領域は単一の物を用意する一方で、冗長化した通信経路毎にその通信経路上で通信を行うためのＬＭＲを用意し、上記単一の主メモリ領域に対して、各通信リンクに対応したＬＭＲを重ねてマッピングする方式を発明した。

本発明の概要を図９に示す。本発明は、冗長化された通信経路（ここでは２つの通信経路）毎にそれぞれ対応したＬＭＲ群を用意する点は［発明が解決しようとする課題］において説明した従来の（方式１）、（方式２）と同様であるが、主メモリ上のＲＤＭＡ領域は単一の領域を用意する点が異なる。

正常動作時には、［発明が解決しようとする課題］で述べた従来の（方式２）と同様に、冗長化された複数の通信経路のうちの１つだけを使用してホスト間でのデータ転送を行う。図９の例で言えば、ホストＡでは、主メモリ上のセグメントと同じサイズのデータがディスクから読み出されセグメントに格納されていくとともに、ＬＭＲ群１を用いて通信経路１経由でＲＤＭＡによりそれらのデータがホストＢへ転送される（ＲＤＭＡのイニシエータはどちらのホストでもよい）。ホストＢでは、ＬＭＲ群１を用いて通信経路１から受信したデータを主メモリに格納するとともに、主メモリ上のデータをＮＩＣ経由でネットワークへ配信する。

ここで、図１０に示すように、通信経路１に障害が発生すると、ホストＡ、および、ホストＢはＲＤＭＡに使用するＬＭＲ群を１から２へ切り替える。そして、まだホストＢへ転送していない主メモリ上のセグメントから、ＲＤＭＡによるデータ転送を再開する。

同図のように１回のＲＤＭＡ動作におけるデータ転送単位（本例では１つのセグメント）内のデータのＲＤＭＡ転送の途中で通信経路１に障害が発生し、当該ＲＤＭＡ転送が途中で異常終了した場合は、使用するＬＭＲ群を１から２へ切り替えた後、当該セグメントの先頭から再びＲＤＭＡ転送を実行する。これは、各回のＲＤＭＡの進行状況はアプリケーションプロセスでは把握できず、異常終了するまでに転送したデータ量を正確に把握することができないため、初めから実行し直す必要があるためである。

ホストＡにおけるディスクから主メモリへのデータ読み出し、および、ホストＢにおける主メモリからネットワークへのデータ配信動作は、ＬＭＲ群の切り替えの影響を受けずに継続が可能である。

本発明では、ディスクからのデータ読み出しは、各データについて１度だけ、単一のＲＤＭＡ領域に対して行えばよい。また、ネットワークへのデータ配信においても、単一のＲＤＭＡ領域からＮＩＣへのデータ読み出しは各データについて１度だけ行えばよい。したがって、［発明が解決しようとする課題］で述べた（方式１）の問題、すなわち、外部装置と主メモリとの間のデータ転送を冗長して行うことに起因する、ホストの処理負荷の増大や各種リソース消費量の増大という問題はない。

また、本発明は、障害発生時においてデータを流す通信経路を変更する点では［発明が解決しようとする課題］で述べた（方式２）と同じである。しかし、本発明では、通信経路の切り替えのために必要な動作はＬＭＲ群の切り替えだけである。図９の例では、ホストＡにおけるディスクから主メモリへのデータ読み出し、および、ホストＢにおける主メモリからネットワークへのデータ配信動作は、上記のＬＭＲ群の切り替えの影響を受けずに、単一のＲＤＭＡ領域を使用したまま常時継続できる。したがって、［発明が解決しようとする課題］で述べた（方式２）の問題、すなわち、ＲＤＭＡ領域間でのデータのコピー（移動）やディスクからのデータの再読み出しのような、高速実行が困難となり得る処理が介在する、という問題もない。

本発明によれば、通信経路上で障害が発生した場合の迅速な通信経路の切り替え動作を維持しながら、［発明が解決しようとする課題］で述べた従来の自明な通信経路冗長化方式が持つ問題を解決することが可能である。

［発明を実施するための最良の形態１］
以下、本発明を実施するための最良の形態１（以下、形態１と記載）について説明する。本形態１は、［特許請求の範囲］に記載の請求項１、３、４の方法に基づいており、また、それを具現化したサーバ装置であるため請求項５にも対応する。本形態１の装置全体の構成を図１１に示す。

図１１に示す相互結合網冗長型マルチメディアサーバ装置が本形態に係るサーバ装置である。映像データなどの時間連続性を持つマルチメディアデータを外部装置へ配信する機能、および、外部装置から受信したマルチメディアデータを蓄積する機能を有する。外部装置と直接通信する通信サーバモジュール１〜Ｍ_１、マルチメディアデータが格納される蓄積装置１〜Ｍ_２、蓄積装置を制御する蓄積サーバモジュール１〜Ｍ_２、サーバ内データベース、通信サーバモジュールと蓄積サーバモジュール間でのマルチメディアデータ転送に使用されるサーバモジュール間ネットワークスイッチ、および、通信サーバモジュールと蓄積サーバモジュールとサーバ内データベースを接続するローカルエリアネットワークで構成される。

通信サーバモジュールと蓄積サーバモジュールは汎用の計算機から成るモジュールで、相互結合網冗長型マルチメディアサーバ装置はこれらをクラスタ化したものである。すなわち、通信サーバモジュールと蓄積サーバモジュールは請求項１に記載の計算機に対応し、相互結合網冗長型マルチメディアサーバ装置は請求項１に記載のサーバ装置に対応する。

相互結合網冗長型マルチメディアサーバ装置は、端末側ネットワークを介して端末やマルチメディア情報入力装置などの外部装置と接続されている。端末は、同サーバ装置からマルチメディアデータの配信を受ける装置である。また、マルチメディア情報入力装置は、同サーバ装置へ蓄積したいマルチメディアデータを送信する装置である。

相互結合網冗長型マルチメディアサーバ装置内のサーバモジュール間ネットワークスイッチは、請求項１に記載の相互結合網に対応する。本形態１では、同スイッチはＩｎｆｉｎｉＢａｎｄスイッチで、上位レイヤにｕＤＡＰＬを用いるものとする。このｕＤＡＰＬは請求項１に記載の「計算機間のコネクション設定機構および当該計算機の主メモリ領域の抽象化機構を持つ通信方式」に対応する。

本形態１では、上記スイッチを２つ用いることにより相互結合網を冗長化している。すなわち、請求項１に記載のＤの値を２とした場合に対応する。

１つのスイッチ、そこから伸びる通信リンク、および、それらの通信リンクによって当該スイッチに接続された全てのＨＣＡからなる１つのサーバモジュール間ネットワークを系と呼び、同図における２つの系をそれぞれ０系、１系とする。また、この０系あるいは１系内において、ある１台の通信サーバモジュールとある１台の蓄積サーバモジュールを接続する通信リンクと同スイッチからなる通信経路を、０系通信経路、１系通信経路、のように呼ぶ。

各系の内部では任意のＨＣＡ間で通信が可能であるが、系をまたがる通信はできないものとする。

各通信サーバモジュールは、端末側ネットワークとの接続のためのネットワークインタフェースカード（ＮＩＣ）を１枚、および、０系、１系の各サーバモジュール間ネットワークスイッチとの接続のためにＩｎｆｉｎｉＢａｎｄホストアダプタカード（ＨＣＡ）を２枚搭載している。

各蓄積サーバモジュールは、０系、１系の各サーバモジュール間ネットワークスイッチとの接続のためのＩｎｆｉｎｉＢａｎｄ ＨＣＡを２枚、および、自身が管理する蓄積装置との接続のためのファイバチャネルホストバスアダプタ（ＨＢＡ）を１枚搭載している。

相互結合網冗長型マルチメディアサーバ装置内のローカルエリアネットワークは、通信サーバモジュール、蓄積サーバモジュール、サーバ内データベースを接続するネットワークである。このネットワークは前記０系、１系のサーバモジュール間ネットワークのように計算機間のコネクション設定機構や当該計算機の主メモリ領域の抽象化機構を持つ通信方式を実行可能である必要はなく、ＬＡＮ（Local Area Network）等で用いられるイーサネットなどの一般的なネットワークでよい。

相互結合網冗長型マルチメディアサーバ装置内のサーバ内データベースは、同サーバ装置に格納されている番組の格納場所や、各蓄積装置の使用状況に関するデータを保持するデータベースである。同サーバ装置の通信サーバモジュール、および、蓄積サーバモジュールはこのローカルエリアネットワークを介してこのサーバ内データベースにアクセスし、上記の情報を得る。このサーバ内データベースを実現する装置としては、前記のデータを保持できるだけの記憶装置を内部に持ち、かつ、通信サーバモジュールや蓄積サーバモジュールとの通信が可能な物であればよく、汎用の計算機等で実現するのが簡明である。このサーバ内データベースは内部に、番組格納情報テーブル、および、蓄積装置使用状況テーブルの２つのテーブルを持つ。これらを図１２に示す。

番組格納情報テーブルは、相互結合網冗長型マルチメディアサーバ装置に格納されている各番組のマルチメディアデータがどの蓄積装置に格納されているかを示すテーブルである。図１２の例ではＩＤが１の番組が蓄積装置５に、ＩＤが２の番組が蓄積装置Ｍ_２に格納されていることを示している。新しい番組が同サーバ装置に格納されるたびに、テーブル内にこのようなエントリが作成されていく。また、蓄積装置使用状況テーブルは、同サーバ装置の各蓄積装置の空き容量を示すテーブルである。蓄積装置１からＭ_２の各蓄積装置の空き容量が記憶されている。新しい番組が同サーバ装置に格納されるたびに、テーブル内の空き容量を表す数値が更新されていく。

本形態１において、マルチメディアデータの配信は以下のように行われる。マルチメディアデータの配信を要求する端末は、サーバ装置内の任意の１台の通信サーバモジュールに対し、端末側ネットワークを介してマルチメディアデータの配信要求を発行する。配信要求には、要求元の端末を特定する要求元ＩＤ、および、配信を要求するマルチメディアデータを特定する番組ＩＤが情報として含まれる（要求元ＩＤや番組ＩＤの管理方法についてはここでは規定しない）。

この配信要求を受信した通信サーバモジュールは、ローカルエリアネットワークを介してサーバ内データベースにアクセスし、同データベース内の番組格納情報テーブルの当該番組ＩＤを含むエントリを検索して、当該番組のマルチメディアデータが格納されている蓄積装置番号を得る。

そして、サーバモジュール間ネットワークのうち正常に動作している１つの系を使用して、上記蓄積装置番号の蓄積装置を管理する蓄積サーバモジュールから当該番組のマルチメディアデータを受信し、これを要求元ＩＤに相当する端末へ配信する。

また、マルチメディアデータの蓄積は以下のように行われる。マルチメディアデータの蓄積を要求するマルチメディア情報入力装置は、サーバ装置内の任意の１台の通信サーバモジュールに対し、端末側ネットワークを介してマルチメディアデータの蓄積要求を発行する。蓄積要求には、要求元のマルチメディア情報入力装置を特定する要求元ＩＤ、および、蓄積するマルチメディアデータに新規に割り振る番組ＩＤが情報として含まれる。

蓄積要求を受信した通信サーバモジュールは、ローカルエリアネットワークを介してサーバ内データベースにアクセスし、同データベース内の蓄積装置使用状況テーブルを参照して、空き容量が最も多い蓄積装置を当該マルチメディアデータの格納先蓄積装置に決定する。

そして、サーバモジュール間ネットワークのうち正常に動作している１つの系を使用して、上記蓄積装置を管理する蓄積サーバモジュールに対し、マルチメディア情報入力装置から受信したマルチメディアデータを送信する。

蓄積サーバモジュールは、受信したマルチメディア情報を自身が管理する蓄積装置へ格納する。当該番組の全てのマルチメディア情報の蓄積装置への格納が完了すると、蓄積サーバモジュールは、サーバ内データベースにアクセスし、当該番組ＩＤとそれを格納した蓄積装置番号からなる新しいエントリを番組格納情報テーブルへ追加し、さらに、番組格納後の当該蓄積装置の空き容量を蓄積装置使用状況テーブルに記録し、処理を終了する。

なお、１番組のマルチメディア情報は固定長のセグメントに分割されて蓄積装置に格納されるものとする。蓄積装置からの読み出しや蓄積装置への書き込み、通信サーバモジュールと蓄積サーバモジュール間の転送は、いずれもこのセグメントを単位に行う。

また、通信サーバモジュールと蓄積サーバモジュールとの間のデータ転送はｕＤＡＰＬのＡＰＩを介したＲＤＭＡにより実行する。１回のＲＤＭＡ操作で上記セグメントの１つが両者の間で転送される。この転送動作を繰り返すことにより当該番組のマルチメディアデータの転送が行われる。なお、本形態１においては、通信サーバモジュールがＲＤＭＡのイニシエータであるものとする。

なお、端末側ネットワークとのデータの送受信時の形式については特に規定しない。

以上が本形態１の装置構成、および、動作の概要の説明である。これらを踏まえ、以下に本発明技術を含んだ詳細な説明を行う。まず、図１３に通信サーバモジュールの内部構造の詳細を示す。

ＲＤＭＡ領域は、番組のマルチメディア情報を格納するためのバッファで、オペレーティングシステムが提供する仕組みを用いて主メモリに確保した領域である。Ｎ個の領域に分かれており、各領域にマルチメディア情報の１つのセグメントを格納する。

配信動作の場合はＲＤＭＡ転送によって蓄積サーバモジュールから受信したセグメントが格納され、端末側ネットワークへ配信されるまでのバッファとして機能する。

蓄積動作の場合は端末側ネットワークから受信したマルチメディア情報が格納され、ＲＤＭＡ転送によってセグメント単位で蓄積サーバモジュールへ転送されるまでのバッファとして機能する。

読み出しポインタ（ｒｄ＿ｐｔｒ）、書き込みポインタ（ｗｒ＿ｐｔｒ）、フルフラグ（ｆｕｌｌ＿ｆｌａｇ）、エンプティフラグ（ｅｍｐｔｙ＿ｆｌａｇ）は、上記ＲＤＭＡ領域へのセグメントの格納状況を管理するための、ソフトウェアプログラム変数である。

ｒｄ＿ｐｔｒは、ＲＤＭＡ領域に既に格納されているセグメントを読み出す際に、読み出し元となるバッファ番号を保持するポインタである。配信動作の場合は、ＮＩＣ経由で端末側ネットワークへ配信するセグメントを指し、蓄積動作の場合は、ＲＤＭＡで蓄積サーバモジュールへ転送するセグメントを指す。

ｗｒ＿ｐｔｒは、ＲＤＭＡ領域へセグメントを書き込む際に、書き込み先となるバッファ番号を保持するポインタである。配信動作の場合は、蓄積サーバモジュールからＲＤＭＡで転送されてきたセグメントの格納先バッファを指し、蓄積動作の場合は、端末側ネットワークから受信したマルチメディアデータの格納先バッファを指す。

ｆｕｌｌ＿ｆｌａｇは、全てのバッファにセグメントが格納されていれば値１、それ以外の場合は値０を保持するフラグである。

ｅｍｐｔｙ＿ｆｌａｇは、どのバッファにもセグメントが格納されていない場合は値１、それ以外の場合は値０を保持するフラグである。

これらのポインタとフラグを用いて、Ｎ個のバッファからなる有限長のＲＤＭＡ領域を仮想的なリングバッファとして使用することにより、セグメント長がＮよりも長い番組データを扱うことができる。

要求送信バッファは、ＲＤＭＡ領域と同様の方法で主メモリ上に確保した領域で、ＲＤＭＡ転送の実行前に蓄積サーバモジュールに対して送信するメモリ情報要求を格納するバッファである。

メモリ情報受信バッファは、上記と同様の方法で主メモリ上に確保した領域で、上記メモリ情報要求に対して蓄積サーバモジュールから送られてきたメモリ情報を受信するためのバッファである。

上記ＲＤＭＡ領域、要求送信バッファ、メモリ情報受信バッファを全て合わせたものが請求項１に記載のデータ格納手段に対応する。したがって、これらは全て、冗長化した通信経路の数には関係なく１つだけ確保する。

データ転送用ＬＭＲ群０、１はｕＤＡＰＬのオブジェクトであり、それぞれ、冗長化した２つの０系、１系通信経路用のＬＭＲである。図９のＬＭＲ群１、２に相当する物である。主メモリ上のＲＤＭＡ領域の各バッファ［ｉ］（０≦ｉ≦Ｎ−１）に対して、０系用のＬＭＲ［０］［ｉ］と１系用のＬＭＲ［１］［ｉ］の２つのＬＭＲがマッピングされている。

本形態１では、マルチメディアデータの転送だけでなくＲＤＭＡに伴うメモリ情報の送受信においても２つの通信経路を用いて信頼性の向上を図る。そのために、上記要求送信バッファ、および、メモリ情報受信バッファについても、それらにマッピングされた０系、１系通信経路用のＬＭＲを用意する。Ｓ−ＬＭＲが要求送信バッファ、Ｒ−ＬＭＲがメモリ情報受信バッファに対応したＬＭＲである。

１つのデータ転送用ＬＭＲ群と１つのメモリ情報交換用ＬＭＲ群を合わせた物が請求項１に記載のメモリ領域抽象化手段に対応し、本形態１では２つのメモリ領域抽象化手段を保持した場合に対応する。

ｒｅｑｕｅｓｔ ＥＶＤは、蓄積サーバモジュールへ送信するメモリ情報要求の送信完了、および、１回のＲＤＭＡ ｒｅａｄ／ｗｒｉｔｅ動作の完了を通知するｕＤＡＰＬオブジェクトである。０系、１系通信経路毎に用意する。

ｒｅｃｅｉｖｅ ＥＶＤは、蓄積サーバモジュールからのメモリ情報の受信完了を通知するｕＤＡＰＬオブジェクトである。０系、１系通信経路毎に用意する。

ＥＰは、蓄積サーバモジュールとの通信を行うために確立するコネクションの端点となるｕＤＡＰＬオブジェクトである。本形態１では、０系、１系の２つの通信経路上で通信サーバモジュールと蓄積サーバモジュール間のコネクションを確立することでコネクションを冗長化し、両者間の通信の高信頼化を図る。そのために０系、１系用の２つのＥＰを用いる。すなわち、本形態１は、合計２本の冗長な通信経路を保有する請求項１に記載の経路冗長化手段の一例を実現している。

各系のＥＰは、その生成時において、それぞれ図中のｒｅｑｕｅｓｔ ＥＶＤ、ｒｅｃｅｉｖｅ ＥＶＤと関連づけられているものとする。これにより、ある系のＥＰを経由して実行する動作の完了通知は同じ系内の当該ＥＶＤを通して行われる。

本形態１では、ＬＭＲ群とＥＰについては、同じ系内の物どうしの組み合わせでしか使用しない。このため、各系のＬＭＲ群とＥＰはその系内の１つのＰＺに関連づけて生成し、異なる系に属するこれらのリソースを混在させた処理が行えないようにしている。

通信経路監視部は、通信サーバモジュールと蓄積サーバモジュールを結ぶ各通信経路の通信可否状態を監視するソフトウェアモジュールである。０系、１系の各通信経路に対応して１つずつ存在する。また、その内部に、当該通信経路の状態を記録するためのソフトウェアプログラム変数であるステータス変数を持つ。請求項４に記載の通信経路障害・回復検出手段に対応する。

各系の通信経路監視部は、当該通信経路の対向の蓄積サーバモジュール上の通信経路監視部と相互に定期的にメッセージ交換を行い、事前に設定した規定時間（請求項３に記載の「メッセージ交換の規定時間」に対応するもの）に基づいて、当該通信経路における障害発生や障害からの回復を検出する。

メッセージ交換が上記規定時間以内に終了できなかった場合、当該通信経路に障害が発生して使用不可能になったとみなし、ステータス変数に値「断」を設定する。メッセージ交換が上記規定時間以内に終了できた場合は、当該通信経路が使用可能であるとみなし、ステータス変数の値を「正常」に設定する。

なお、このメッセージ交換は、ｕＤＡＰＬのＡＰＩで提供されるメッセージｓｅｎｄ／ｒｅｃｅｉｖｅやＲＤＭＡではなく、ＩＣＭＰ ｅｃｈｏ ｒｅｑｕｅｓｔ／ｒｅｐｌｙのような軽量な通信を使用する。

ｕＤＡＰＬには通信経路の障害をアプリケーションソフトウェアに対して割り込み通知する機能がない。しかし、後述するように、ＥＶＤを経由して各種の処理の完了通知を待つ際、待ち時間の規定時間（請求項３に記載の「データ転送の規定時間」に対応するもの）を設定することができる。したがって、データ転送の際にこの規定時間を用いて通信経路の障害を検出することも可能である。

これに対し、本形態１は、請求項３、４に記載の方法、すなわち、データ転送の規定時間と通信経路監視部の２つを併用して通信経路の状態を判断する方法を用いている。これは以下の２点において前者より優れている。

・マルチメディアデータの１つのセグメントのデータサイズは非常に大きく、その転送にかかる時間のばらつき（ジッタ）も大きくなる傾向がある。したがって、データ転送の規定時間を元に通信経路の障害検出を行う方法では、このジッタを吸収できるだけの十分に長い規定時間を設定しなければ、データ転送時の単なる処理遅れと通信経路障害を混同する可能性が生じる。しかし、これでは迅速な障害検出が行えない。請求項３、４に記載の方法では、上記のような誤判断なく、しかも、障害検出の迅速化が図れる。

・データ転送動作とは独立に動作する通信可否状態の監視機構により、障害検出だけでなく障害からの回復を検出できる。

以上が通信サーバモジュールの内部構造の詳細説明である。次に、図１４に蓄積サーバモジュールの内部構造の詳細を示す。

蓄積サーバモジュールの０系ＥＰと通信サーバモジュールの０系ＥＰとの間、および、蓄積サーバモジュールの１系ＥＰと通信サーバモジュールの１系ＥＰとの間でコネクションが確立されている。

主メモリ上のＲＤＭＡ領域は、番組のマルチメディア情報を格納するためのバッファで、配信動作の場合は蓄積装置から読み出されたセグメントが格納され、ＲＤＭＡによって通信サーバモジュールへ送信するまでのバッファとして機能する。蓄積動作の場合はＲＤＭＡ転送によって通信サーバモジュールから受信したセグメントが格納され、蓄積装置へ書き込むまでのバッファとして機能する。

本ＲＤＭＡ領域も通信サーバモジュールにおけるそれと同様に、ｒｄ＿ｐｔｒ、ｗｒ＿ｐｔｒ、ｆｕｌｌ＿ｆｌａｇ、ｅｍｐｔｙ＿ｆｌａｇを用いて仮想的なリングバッファとして使用する。

メモリ情報送信バッファは、通信サーバモジュールからのメモリ情報要求に対して送信するメモリ情報を格納するバッファである。

要求受信バッファは、通信サーバモジュールからのメモリ情報要求を受信するためのバッファである。

これら以外の構成要素については、通信サーバモジュールの対応する構成要素と同じあるため説明は省略する。

以上が通信サーバモジュール、および、蓄積サーバモジュールの内部構造の詳細説明である。以上のように構成した相互結合網冗長型マルチメディアサーバ装置の動作の詳細を以下に説明する。

なお、以下では、同サーバ装置から端末へのマルチメディアデータの配信動作だけを説明する。蓄積動作の場合はマルチメディアデータの転送方向が逆になるだけで、本質的な差異は存在しない。

また、通信／蓄積サーバモジュール内の各構成要素を生成するタイミングについては本形態１では規定せず、全ての動作の開始前に各構成要素が存在していることを前提とする。したがって、図１３と図１４に示した通信サーバモジュール／蓄積サーバモジュール間のコネクションについても、以下の説明の配信動作における対向のサーバモジュールどうしを接続したもので、事前の存在を前提とする。

また、簡略化のため、図１３、図１４においてはＥＰ間コネクション確立通知用ＥＶＤの記載を、図１４においてはデータ転送用ＬＭＲに対応するＲＭＲの記載は省略している。

まず、図１５に、本形態１における通信サーバモジュールの処理を示すフローチャートを示す。同図に示すＳ１〜Ｓ１５に従って通信サーバモジュールの処理を説明する。

（Ｓ１）端末から番組の配信要求を受信する。

（Ｓ２）サーバ内データベースにアクセスし、上記配信要求に含まれる番組ＩＤをキーとして同データベース内の番組格納情報テーブルを検索し、当該番組が格納されている蓄積装置を管理する蓄積装置番号を得る。

（Ｓ３）Ｓ２で得た蓄積装置番号の蓄積装置を管理する蓄積サーバモジュールに対し、当該番組ＩＤを含む配信開始通知を発行する。

（Ｓ４）当該蓄積サーバモジュールからの前処理完了通知を受信するまで待つ。この前処理完了通知は、蓄積サーバモジュール側が各種リソースの初期化を完了し、当該番組のセグメントの転送が可能となったことを示す。

（Ｓ５）端末への初期配信時刻、すなわち、当該番組の当該端末への配送を開始する時刻を設定する。例えば、初期配送時刻を、端末からの配信要求を受信した時刻に設定すると、蓄積サーバモジュールから当該番組の最初のセグメントを受信した時に配信が開始される。

（Ｓ６）ｒｄ＿ｐｔｒ、および、ｗｒ＿ｐｔｒの値をそれぞれ、主メモリ内のバッファ［０］を指すよう、０に初期化する。また、上記バッファがまだ空（セグメントが一切格納されていない）であるため、ｆｕｌｌ＿ｆｌａｇを０、ｅｍｐｔｙ＿ｆｌａｇを１に初期化する。

（Ｓ７）冗長化された２つの通信経路のうち、使用する通信経路の系番号を表す変数Ｉを０に初期化する（最初は０系通信経路から使用する）。

（Ｓ８）後述する「端末へのセグメント配信処理」を起動する。

（Ｓ９）蓄積サーバモジュールに対して送信するメモリ情報要求の内容を主メモリ上の要求送信バッファへ書き込む。このメモリ情報要求は、転送対象となるセグメントを特定する番号等を含めることによりＲＤＭＡ ｒｅａｄ動作の対象となる蓄積サーバモジュールのＬＭＲを特定するものであるが、本明細書ではその形式は規定しない。

（Ｓ１０）ｆｕｌｌ＿ｆｌａｇの値が０になるまで待つ。すなわち、主メモリ上にバッファの空きがあり、蓄積サーバモジュールからのセグメントの受信が可能になるまで待つ。

（Ｓ１１）蓄積サーバモジュールから当該番組の１つのセグメントを受信する。本ステップの詳細は後述する。

（Ｓ１２）１つのセグメントを受信したら、ｗｒ＿ｐｔｒがその次のセグメントの格納先のバッファを指すよう、値を更新する。すでに最後尾のバッファ［Ｎ１］を指していれば先頭バッファ［０］を、そうでなければ、１つ先のバッファを指すように値を更新する。

（Ｓ１３）セグメントの受信直後は主メモリ上の全バッファが空でないことが確実であるため、ｅｍｐｔｙ＿ｆｌａｇの値を０にセットする。

（Ｓ１４）Ｓ１２でｗｒ＿ｐｔｒの値を更新した結果、もしｒｄ＿ｐｔｒの値と等しくなれば、主メモリ上の全バッファがセグメントデータによって占有されたことを意味するため、ｆｕｌｌ＿ｆｌａｇの値を１にセットする。そうでなければ何もしない。

（Ｓ１５）Ｓ１１で蓄積サーバモジュールから受信したセグメントが当該番組の最終セグメントであれば、処理を終了する。そうでなければＳ９へ戻る。

図１６は、図１５のＳ８において起動された「端末へのセグメント配信処理」のフローチャートである。同図に示すＳ２０〜Ｓ２７に従って本処理を説明する。

（Ｓ２０）現在の時刻が、設定されている「端末への配信時刻」を過ぎるまで待つ。

（Ｓ２１）主メモリのｅｍｐｔｙ＿ｆｌａｇを参照し、その値が０、すなわち、配信すべきセグメントがあることを確認する。ｅｍｐｔｙ＿ｆｌａｇの値が１であれば０になるまで待つ。

（Ｓ２２）バッファ［ｒｄ＿ｐｔｒ］に格納されているセグメントを、Ｓ１で受信した配信要求内の要求元ＩＤで特定される端末へ配信する。本明細書では、端末側ネットワークへ配信する際のデータ形式については規定しない。

（Ｓ２３）１つのセグメントを配信したら、ｒｄ＿ｐｔｒがその次のセグメントの格納先のバッファを指すように、値を更新する。すでに最後尾のバッファ［Ｎ１］を指していれば先頭バッファ［０］を、そうでなければ、１つ先のバッファを指すように値を更新する。

（Ｓ２４）セグメントの配信直後は、主メモリのバッファのうちセグメントが格納されていない空のバッファが少なくとも１つはあるので、ｆｕｌｌ＿ｆｌａｇの値を０にセットする。

（Ｓ２５）Ｓ２３でｒｄ＿ｐｔｒの値を更新した結果、もしｗｒ＿ｐｔｒの値と等しくなれば、主メモリ上の全バッファが空となったことを意味するため、ｅｍｐｔｙ＿ｆｌａｇの値を１にセットする。そうでなければ何もしない。

（Ｓ２６）現在設定されている「端末への配信時刻」に、端末での１セグメントの再生時間を加えたものを、次の配信時刻として設定する。

（Ｓ２７）Ｓ２２で配信したセグメントが当該番組の最終セグメントであれば、処理を終了する。そうでなければＳ２０へ戻る。

図１７は、図１５のＳ１１「蓄積サーバモジュールからのセグメント受信処理」を詳細に示したものである。同図に示すＳ３０〜Ｓ４４に従って本処理を説明する。

（Ｓ３０）要求送信バッファ内の内容をメモリ情報要求として、Ｓ−ＬＭＲ［Ｉ］を用いてＩ系通信経路を介して蓄積サーバモジュールへ送信する。このメモリ情報要求はＲＤＭＡではなく、ｕＤＡＰＬで用意されている単純なメッセージｓｅｎｄ機構を用いる。

（Ｓ３１）Ｓ３０のメッセージｓｅｎｄが事前に設定した規定時間内に正常に終了すれば、Ｓ３５へ移る。規定時間内に終了しなければＳ３２へ移る。

（Ｓ３２）Ｉ系通信経路のステータス変数の値を確認する。その値が「正常」なら、メッセージｓｅｎｄの処理遅れの可能性があるため、Ｓ３１へ戻る。「正常」でなければ（「断」であれば）Ｓ３３へ移る。

（Ｓ３３）Ｉ系通信経路に障害が発生したと判断し、代わりに使用できる通信経路が他にあるか否かを判断する。なければここで処理を終了（異常終了）する。あればＳ３４へ移る。

（Ｓ３４）新しく使用する通信経路の系番号を決定する。ステータスが「正常」な通信経路の系番号のうち、最小の番号を変数Ｉにセットする。その後、Ｓ３０に戻り、新しい通信経路上でメモリ情報要求を送信し直す。

（Ｓ３５）Ｒ−ＬＭＲ［Ｉ］を用いてＩ系通信経路を介してメモリ情報を蓄積サーバモジュールから受信し、内容をメモリ情報受信バッファに格納する。このメモリ情報の受信はＲＤＭＡではなく、ｕＤＡＰＬで用意されている単純なメッセージｒｅｃｅｉｖｅ機構を用いる。

（Ｓ３６）Ｓ３５のメッセージｒｅｃｅｉｖｅが事前に設定した規定時間内に正常に終了すれば、Ｓ４０へ移る。規定時間内に終了しなければＳ３７へ移る。

（Ｓ３７）Ｉ系通信リンクのステータス変数の値を確認する。その値が「正常」なら、メッセージｒｅｃｅｉｖｅの処理遅れの可能性があるため、Ｓ３６へ戻る。「正常」でなければ（「断」であれば）Ｓ３８へ移る。

（Ｓ３８）Ｉ系通信経路に障害が発生したと判断し、代わりに使用できる通信経路が他にあるか否かを判断する。なければここで処理を終了（異常終了）する。あればＳ３９へ移る。

（Ｓ３９）新しく使用する通信経路の系番号を決定する。ステータスが「正常」な通信経路の系番号のうち、最小の番号を変数Ｉにセットする。その後、Ｓ３５に戻り、新しい通信リンク上でメモリ情報を受信し直す。

（Ｓ４０）蓄積サーバモジュールから番組情報のセグメントを受信するために、ＬＭＲ［Ｉ］［ｒｄ＿ｐｔｒ］を受信用ＬＭＲに指定し、Ｓ３６で受信したメモリ情報で指定された蓄積サーバモジュールのバッファのアドレスをターゲットとするＲＤＭＡ ｒｅａｄを発行する。

（Ｓ４１）Ｓ４０のＲＤＭＡ ｒｅａｄが事前に設定した規定時間内に正常に終了しセグメントをバッファ［Ｉ］［ｒｄ＿ｐｔｒ］に受信できれば、図１５のＳ１２へ移る。規定時間内に終了しなければＳ４２へ移る。

（Ｓ４２）Ｉ系通信経路のステータス変数の値を確認する。その値が「正常」なら、ＲＤＭＡ ｒｅａｄの処理遅れの可能性があるため、Ｓ４１へ戻る。「正常」でなければ（「断」であれば）Ｓ４３へ移る。

（Ｓ４３）Ｉ系通信経路に障害が発生したと判断し、代わりに使用できる通信経路が他にあるか否かを判断する。なければここで処理を終了（異常終了）する。あればＳ４４へ移る。

（Ｓ４４）新しく使用する通信経路の系番号を決定する。ステータスが「正常」な通信経路の系番号のうち、最小の番号を変数Ｉにセットする。その後、Ｓ４０に戻り、新しい通信経路上でＲＤＭＡ ｒｅａｄをやり直す。

図１８は、図１３における０系、１系通信経路監視部の処理を示したフローチャートである。各系の通信経路監視部は互いに独立に、また、図１５、図１６、図１７に示した通信サーバモジュールの動作とも独立に、それぞれ同図のように動作する。同図のＳ５０〜Ｓ６０に従って通信経路監視部の処理を説明する。

（Ｓ５０）自通信経路の状態を表すステータス変数の値を「正常」に初期化する。

（Ｓ５１）対向ホスト上の、同じ系に対応する通信経路監視部に対し、ＩＣＭＰ ｅｃｈｏリクエストパケットを送信する。

（Ｓ５２）Ｓ５１の対向の通信経路監視部から、事前に設定した規定時間内にＩＣＭＰ ｅｃｈｏリプライパケットを受信できれば、自通信経路に問題はないと判断し、Ｓ５１へ戻って監視を継続する。受信できなければＳ５３へ移る。

（Ｓ５３）自通信経路に障害が発生したと判断し、ステータス変数の値を「断」に変更する。

（Ｓ５４）自通信経路の回復を検出するため、Ｓ５１の対向の通信経路監視部に対し、ＩＣＭＰ ｅｃｈｏリクエストパケットを送信する。

（Ｓ５５）Ｓ５４の対向の通信経路監視部から、事前に設定した規定時間内にＩＣＭＰ ｅｃｈｏリプライパケットを受信できれば、自通信経路が回復したと判断し、Ｓ５６へ移る。受信できなければＳ５４へ戻って自通信経路の回復検出動作を継続する。

（Ｓ５６）自通信経路のＥＰと対向ホスト上のＥＰとの間のコネクションを切断する。

（Ｓ５７）自通信経路のＥＰを消去する。

（Ｓ５８）自通信経路の新しいＥＰを生成する。

（Ｓ５９）Ｓ５８で生成した新しいＥＰを用いて、自通信経路における対向のＥＰと新規にコネクションを確立する。

（Ｓ６０）自通信経路のステータス変数の値を「正常」に戻し、Ｓ５１へ移って通常の回線監視動作を行う。

ＩｎｆｉｎｉＢａｎｄには、通信経路に対して一度発行した通信処理を明示的に取り消すための機能がない。そのため、障害から回復した通信経路をそのまま再使用せずにＥＰとコネクションを消去した後に新しいものを作り直す処理をステップ５６からステップ５９でおこなっている。これにより、通信経路に障害が発生した瞬間に実行中であった通信処理が障害からの回復後に誤って再起動されることを防止する。

図１９は、本形態１における蓄積サーバモジュールの処理を示すフローチャートである。同図のＳ７０〜Ｓ８１に従って、通信サーバモジュールの処理を説明する。

（Ｓ７０）通信サーバモジュールが図１５のＳ３において送信した配信開始通知を受信する。

（Ｓ７１）ｒｄ＿ｐｔｒ、および、ｗｒ＿ｐｔｒの値をそれぞれ、主メモリ内のバッファ［０］を指すよう、０に初期化する。また、上記バッファがまだ空（セグメントが一切格納されていない）であるため、ｆｕｌｌ＿ｆｌａｇを０、ｅｍｐｔｙ＿ｆｌａｇを１に初期化する。

（Ｓ７２）冗長化された２つの通信リンクのうち、使用する方の通信経路を示す変数Ｉを０に初期化する（最初は０系通信リンクから使用する）。

（Ｓ７３）後述する「蓄積装置からのセグメント読み出し処理」を起動する。

（Ｓ７４）ｅｍｐｔｙ＿ｆｌａｇの値が０になるまで待つ。すなわち、蓄積装置から読み出され主メモリ上のバッファに格納されたセグメントが存在し、通信サーバモジュールへのセグメントの送信が可能になるまで待つ。

（Ｓ７５）バッファ［Ｉ］［ｒｄ＿ｐｔｒ］内のセグメントが当該番組の最初のセグメントであればＳ７６へ、そうでなければＳ７７へ移る。

（Ｓ７６）通信サーバモジュールに対して前処理完了通知を発行する。

（Ｓ７７）通信サーバモジュールへ当該番組の１つのセグメントを送信する。本ステップの詳細は後述する。

（Ｓ７８）１つのセグメントを送信したら、ｒｄ＿ｐｔｒがその次に送信するセグメントの格納先のバッファを指すよう、値を更新する。すでに最後尾のバッファ［Ｎ１］を指していれば先頭バッファ［０］を、そうでなければ、１つ先のバッファを指すように値を更新する。

（Ｓ７９）セグメントの送信直後は主メモリ上の全バッファが満杯ないことが確実であるため、ｆｕｌｌ＿ｆｌａｇの値を０にセットする。

（Ｓ８０）Ｓ７８でｒｄ＿ｐｔｒの値を更新した結果、もしｗｒ＿ｐｔｒの値と等しくなれば、主メモリ上の全バッファが空となったことを意味するため、ｅｍｐｔｙ＿ｆｌａｇの値を１にセットする。そうでなければ何もしない。

（Ｓ８１）Ｓ７７で通信サーバモジュールへ送信したセグメントが当該番組の最終セグメントであれば、処理を終了する。そうでなければＳ７４へ戻る。

図２０は、図１９のＳ７３において起動された「蓄積装置からのセグメント読み出し処理」の処理を示すフローチャートである。同図のＳ９０〜Ｓ９５に従って、本処理を説明する。

（Ｓ９０）ｆｕｌｌ＿ｆｌａｇの値が０になるまで待つ。すなわち、主メモリ上にバッファの空きがあり、蓄積装置から読み出すセグメントの格納が可能になるまで待つ。

（Ｓ９１）蓄積装置から当該番組のセグメントを１つ読み出し、主メモリ上のバッファ［ｗｒ＿ｐｔｒ］に格納する。

（Ｓ９２）１つのセグメントをバッファに格納したら、ｗｒ＿ｐｔｒがその次に蓄積装置から読み出したセグメントの格納先のバッファを指すよう、値を更新する。すでに最後尾のバッファ［Ｎ１］を指していれば先頭バッファ［０］を、そうでなければ、１つ先のバッファを指すように値を更新する。

（Ｓ９３）蓄積装置から読み出したセグメントを主メモリ上のバッファへ格納した直後は、全バッファが空でないことが確実であるため、ｅｍｐｔｙ＿ｆｌａｇの値を０にセットする。

（Ｓ９４）Ｓ９３でｗｒ＿ｐｔｒの値を更新した結果、もしｒｄ＿ｐｔｒの値と等しくなれば、主メモリ上の全バッファがセグメントデータによって占有されたことを意味するため、ｆｕｌｌ＿ｆｌａｇの値を１にセットする。そうでなければ何もしない。

（Ｓ９５）Ｓ９１で蓄積装置から読み出したセグメントが当該番組の最終セグメントであれば、処理を終了する。そうでなければＳ９０へ戻る。

図２１は、図１９のＳ７７「通信サーバモジュールへのセグメント送信処理」を詳細に示したものである。同図に示すＳ１００〜Ｓ１１１に従って本処理を説明する。

（Ｓ１００）Ｒ−ＬＭＲ［Ｉ］を用いてＩ系通信経路を介してメモリ情報要求を通信サーバモジュールから受信し、内容を要求受信バッファに格納する。このメモリ情報要求の受信はＲＤＭＡではなく、ｕＤＡＰＬで用意されている単純なメッセージｒｅｃｅｉｖｅ機構を用いる。

（Ｓ１０１）Ｓ１００のメッセージｒｅｃｅｉｖｅが事前に設定した規定時間内に正常に終了すれば、Ｓ１０５へ移る。規定時間内に終了しなければＳ１０２へ移る。

（Ｓ１０２）Ｉ系通信経路のステータス変数の値を確認する。その値が「正常」なら、メッセージｒｅｃｅｉｖｅの処理遅れの可能性があるため、Ｓ１０１へ戻る。「正常」でなければ（「断」であれば）Ｓ１０３へ移る。

（Ｓ１０３）Ｉ系通信経路に障害が発生したと判断し、代わりに使用できる通信経路が他にあるか否かを判断する。なければここで処理を終了（異常終了）する。あればＳ１０４へ移る。

（Ｓ１０４）新しく使用する通信経路の系番号を決定する。ステータスが「正常」な通信経路の系番号のうち、最小の番号を変数Ｉにセットする。その後、Ｓ１００に戻り、新しい通信経路上でメモリ情報を受信し直す。

（Ｓ１０５）通信サーバモジュールへ送信するメモリ情報の内容をメモリ情報送信バッファへ書き込む。メモリ情報には、バッファ［ｒｄ＿ｐｔｒ］に対応するｒｍｒ＿ｔｒｉｐｌｅｔ（開始アドレス、レングス、アクセスキー）が含まれる。

（Ｓ１０６）主メモリ上のバッファ［ｒｄ＿ｐｔｒ］に蓄積装置から読み出したセグメントが格納された状態になるまで待つ。

（Ｓ１０７）Ｓ−ＬＭＲ［Ｉ］を用いてＩ系通信経路を介して、バッファ［ｒｄ＿ｐｔｒ］に関するメモリ情報を通信サーバモジュールへ送信する。このメモリ情報の送信はＲＤＭＡではなく、ｕＤＡＰＬで用意されている単純なメッセージｓｅｎｄ機構を用いる。

（Ｓ１０８）Ｓ１０６のメッセージｓｅｎｄが事前に設定した規定時間内に正常に終了すれば、図１９のＳ７８へ移る。終了しなければＳ１０８へ移る。

（Ｓ１０９）Ｉ系通信経路のステータス変数の値を確認する。その値が「正常」なら、メッセージｓｅｎｄの処理遅れの可能性があるため、Ｓ１０７へ戻る。「正常」でなければ（「断」であれば）Ｓ１０９へ移る。

（Ｓ１１０）Ｉ系通信経路に障害が発生したと判断し、代わりに使用できる通信経路が他にあるか否かを判断する。なければここで処理を終了（異常終了）する。あればＳ１１０へ移る。

（Ｓ１１１）新しく使用する通信経路の系番号を決定する。ステータスが「正常」な通信経路の系番号のうち、最小の番号を変数Ｉにセットする。その後、Ｓ１０６に戻り、新しい通信リンク上でメモリ情報を送信し直す。

なお、図１４における０系、１系通信経路監視部は、通信サーバモジュールのそれらと同様に、それぞれが独立に、また、図１９、図２０、図２１に示した蓄積サーバモジュールの動作とも独立に動作する。その動作は、図１８に示した通信サーバモジュールの通信経路監視部の動作と同じである。

本形態１は２個のサーバモジュール間ネットワークスイッチを用いているので２本のコネクションを備えているが、Ｄ（≧２）個のサーバモジュール間ネットワークスイッチを用いる場合は、Ｄ本のコネクションを備え、データ転送用ＬＭＲ群等もこれに対応して各モジュールでＤ個ずつ備えることはいうまでもない。

［発明を実施するための最良の形態２］
以下、本発明を実施するための最良の形態２（以下、形態２と記載）について説明する。本形態２は、［特許請求の範囲］に記載の請求項２、３、４の方法に基づいており、また、それを具現化したサーバ装置であるため請求項６にも対応する。本形態２のサーバ装置全体の構成を図２２に示す。

図１１に示した形態１との違いは、０系−１系間接続用通信リンクが存在する点である。これは請求項２に記載の相互結合網間通信リンクに対応するものである。この通信リンクにより、本形態２では、０系ＨＣＡと１系ＨＣＡとの間の通信が可能となっている。

図２２における通信サーバモジュールと蓄積サーバモジュールの内部構造の詳細を図２３に示す。

通信サーバモジュール上のデータ格納手段は、請求項１に記載のそれに対応するもので、図１３のバッファ、要求送信バッファ、および、メモリ情報受信バッファを合わせて簡略化して記載したものである。また、メモリ領域抽象化手段１〜４は、請求項１に記載のメモリ領域抽象化手段に対応するもので、図１３のデータ転送ＬＭＲ群とメモリ情報交換用ＬＭＲ群を合わせて簡略化して記載したものである。通信経路監視部１〜４は、請求項４に記載の通信経路障害・回復検出手段に対応するものである。また、図１３と同様に各コネクションに対応してＰＺと各ＥＶＤを備える記載を省略している。また、図１３と同様に読み出しポインタ、書き込みポインタ、フルフラグ、エンプティフラグも備えるが記載を省略している。

蓄積サーバモジュール上のデータ格納手段は、請求項１に記載のそれに対応するもので、図１４のバッファ、メモリ情報送信バッファ、および、要求受信バッファを合わせて簡略化して記載したものである。その他の部分については、通信サーバモジュールの場合と同じように図１４の一部を省略して記載している。

形態１との違いは、通信サーバモジュールと蓄積サーバモジュールの０系通信リンクと１系通信リンクをまたがるものを含む合計４本のコネクションを備え、メモリ領域抽象化手段、ＥＰ、通信経路監視部、および、記載を省略したＰＺ、各ＥＶＤもこの４本のコネクションに対応して両計算機で４つずつ備えている点である。

これにより、計算機間通信の耐障害性を形態１の場合よりも高めている。形態１では、例えば通信サーバモジュールの０系通信リンクと蓄積サーバモジュールの１系通信リンクの合計２箇所が切断した場合、両計算機間の通信ができなくなる。本形態２ではこのような場合でも、通信サーバモジュールの１系通信リンクと蓄積サーバモジュールの０系通信リンクを使用したコネクション３を使用して通信を継続することが可能である。

サーバ内データベースについても、形態１と全く同様のものであり、図１２に示したものと同様の情報を内部に持つ。

図２３の各部の動作フローの詳細については、形態１とほぼ同様のため、記載を省略する。

なお、本形態２においては、コネクション１に相当する通信経路を通信経路１、コネクション２に相当する通信経路を通信経路２、以下同様に、通信経路３、４のように呼ぶ。

また、上記の各通信経路に対応するリソースであるコネクション、ＥＰ、メモリ領域抽象化手段、通信経路監視部への番号の付与について、ＲＤＭＡのイニシエータである通信サーバモジュール側を基準にして図２３のように１から４の番号を付与し、蓄積サーバモジュール側では、通信サーバモジュール側の対応するリソースの番号と同じ番号を付与する。これにより、通信経路の切り替え処理（形態１における図１７、および、図２１に含まれる処理）において、形態１の図１７と図２１と同じ方法で通信サーバモジュールと蓄積サーバモジュールの間で使用する通信経路を常時同期させることができる。

本形態２は２本の通信リンクを有するものであるので４本のコネクションを備えているが、Ｄ（≧２）本の通信リンクを有する場合は、Ｄ^２本のコネクションを備え、メモリ領域抽象化手段等もこれに対応して各計算機でＤ^２個ずつ備えることはいうまでもない。

以上の本発明の各形態の説明で明らかなように、本発明の相互結合網冗長型マルチメディアサーバ装置は次のような利点がある。

まず、同サーバ装置から番組のマルチメディア情報を配信する場合、マルチメディア情報のセグメントの読み出しは各セグメントについて１度だけ、単一のＲＤＭＡ領域に対して行えばよい。また、ネットワークへのデータ配信においても、単一のＲＤＭＡ領域からＮＩＣへのデータ読み出しは各データについて１度だけ行えばよい。

したがって、［発明が解決しようとする課題］で述べた（方式１）の問題、すなわち、外部装置と主メモリとの間のデータ転送を冗長して行うことに起因する、ホストの処理負荷の増大や各種リソース消費量の増大という問題を回避することができる。これは、同サーバ装置へ番組のマルチメディア情報を蓄積する場合にも言える。

さらに、本発明において、通信リンクの障害発生時にデータを流す通信リンクを変更する点では［発明が解決しようとする課題］で述べた（方式２）と同じである。しかし、本発明では通信リンクの切り替えのために必要な動作はＬＭＲ群の切り替えだけである。そして、この切り替え処理にはほとんど負荷がかからず、瞬時に終了する。

したがって、同サーバ装置から番組のマルチメディアデータを配信する場合、ホストＢにおける主メモリからネットワークへのデータ配信動作は上記のＬＭＲ群の切り替えの影響をほとんど受けずに、とぎれることなく正常に継続できる。また、同サーバ装置へ番組のマルチメディア情報を蓄積する場合においても、ホストＢからホストＡへのセグメントの転送ができなくなる時間は非常にわずかである。したがって、マルチメディア情報入力装置から送信されてきた番組のマルチメディア情報をとりこぼすことはない。

［発明が解決しようとする課題］で述べた（方式２）では、ＲＤＭＡ領域間でのデータのコピー（移動）やディスクからのデータの再読み出しが必要である。上記のような配信動作や外部からのマルチメディア情報の受信をとぎれなく実行するには、これらの動作を高速に実行する必要があるが、これは非常に困難である。しかし、本発明においては、このような問題も解決される。

以上に述べたことから、本発明によれば、通信リンク上で障害が発生した場合の迅速な通信リンクの切り替え動作を維持しながら、［発明が解決しようとする課題］で述べた従来の自明な通信リンク冗長化方式が持つ問題を解決することが可能である。

本発明の装置はコンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。

背景技術であるＰＣクラスタシステムの構成例を示す図である。 背景技術であるｕＤＡＰＬのＡＰＩで用いられる主なオブジェクト群を示す図である。 ｕＤＡＰＬのＲＤＭＡ ｒｅａｄにより２台の計算機間で通信を行う際の手順を示す図である。 従来技術の例である（方式１）を説明する図である。 従来技術の例である（方式２）の概要を説明する図である。 従来技術の例である（方式２）の動作の詳細を説明する図である。 従来技術の例である（方式２）の動作の詳細を説明する図である。 従来技術の例である（方式２）の動作の詳細を説明する図である。 本発明の課題を解決するための手段の概要を説明する図である。 本発明の課題を解決するための手段の動作の詳細を説明する図である。 本発明の実施の形態１の装置全体の構成を示す図である。 本発明の実施の形態１におけるサーバ内データベースが管理する情報を説明する図である。 本発明の実施の形態１における通信サーバモジュールの構成を示すブロック図である。 本発明の実施の形態１における蓄積サーバモジュールの構成を示すブロック図である。 本発明の実施の形態１における通信サーバモジュールの処理を示すフローチャートである。 本発明の実施の形態１における通信サーバモジュールの、端末へのセグメント配信処理を示すフローチャートである。 図１４のステップ１１の詳細を示すフローチャートである。 本発明の実施の形態１における通信サーバモジュール、および、蓄積サーバモジュールの通信経路監視部の処理を示すフローチャートである。 本発明の実施の形態１における蓄積サーバモジュールの処理を示すフローチャートである。 本発明の実施の形態１における蓄積サーバモジュールの、蓄積装置からのセグメント読み出し処理を示すフローチャートである。 図１８のステップ７７の詳細を示すフローチャートである。 本発明の実施の形態２の装置全体の構成を示す図である。 本発明の実施の形態２における通信サーバモジュール、および、蓄積サーバモジュールの構成を示すブロック図である。

Claims (10)

1. 計算機間のコネクション設定機構および当該計算機の主メモリ領域の抽象化機構を持つ通信方式を実行可能な相互結合網を用いて計算機を複数台接続し、さらに、その相互結合網がＤ（≧２）個の系に冗長化され各計算機がそれぞれの系に接続するためのＤ本の通信リンクを有する構成のサーバ装置における通信経路の冗長化と切り替え方法であって、
   前記各計算機は、
   自身の通信リンクｉ（１≦ｉ≦Ｄ）と対向の計算機の通信リンクｉとの間にコネクションを設定して合計Ｄ本の冗長な通信経路を確保する経路冗長化手段と、
   通信対象となるデータの格納領域として主メモリ内に確保した１つのデータ格納手段と、
   前記各通信経路に対応し全て前記データ格納手段に対応づけられたＤ個のメモリ領域抽象化手段を有し、
   ある１つの前記メモリ領域抽象化手段を経由することによりそれに対応した通信経路を使用して対向の計算機との間で前記データ格納手段に含まれるデータの転送を行っている最中に当該通信経路に障害が発生した場合に、使用するメモリ領域抽象化手段を他の通信経路に対応したメモリ領域抽象化手段に切り替えるだけで当該データ転送に使用する通信経路を切り換えて当該データ転送を継続する、通信経路の冗長化と切り替え方法。
2. 請求項１に記載の通信経路の冗長化と切り替え方法において、
   前記サーバ装置に対し、Ｄ（≧２）個の系に冗長化された相互結合網の任意の系の間で通信が可能となるように相互結合網間通信リンクを追加したサーバ装置において、
   前記各計算機に対し、自身の計算機の通信リンクｉ（１≦ｉ≦Ｄ）と対向の計算機の全ての通信リンクとの間にコネクションを設定して合計Ｄ^２本の冗長な通信経路を確保するように前記経路冗長化手段を変更し、また、前記メモリ領域抽象化手段を前記各通信経路に対応したＤ^２個持たせるように変更した、通信経路の冗長化と切り替え方法。
3. 請求項１または２に記載の通信経路の冗長化と切り替え方法において、
   前記各計算機は、各通信経路に対応し、当該通信経路を経由して対向の計算機と軽量なメッセージ交換を行い、データ転送に通常要する時間よりもわずかに長い時間をデータ転送の規定時間とし、さらにこれよりも短い時間を前記メッセージ交換の規定時間として、前記メッセージ交換がこの規定時間以内に終了できた場合にはその通信経路の状態として正常状態を記録した後同じ処理を繰り返し、規定時間以内に終了できなかった場合にはその通信経路の状態として異常状態を記録して処理を終了する機能を有する通信経路障害検出手段を有し、
   データ転送がその規定時間以内に終了できなかった場合には、前記通信経路の状態を参照して、正常状態であればデータ転送の終了を次の規定時間が経過するまで継続して待ち、異常状態であれば正常状態である別の通信経路に切り替えて当該データ転送を継続する、通信経路の冗長化と切り替え方法。
4. 請求項３に記載の通信経路の冗長化と切り替え方法において、
   前記各計算機は、前記通信経路障害検出手段に対し、通信経路の状態として異常状態を記録した後も前記メッセージ交換を継続して行い、再びメッセージ交換をその規定時間以内に終了できるようになった場合には通信経路の状態を正常状態に戻すように機能を変更した通信経路障害・回復検出手段を有し、
   これにより一度障害が発生した後に通信が回復した通信経路を再使用可能にする、通信経路の冗長化と切り替え方法。
5. 計算機間のコネクション設定機構および当該計算機の主メモリ領域の抽象化機構を持つ通信方式を実行可能な相互結合網を用いて計算機を複数台接続し、さらに、その相互結合網がＤ（≧２）個の系に冗長化され各計算機がそれぞれの系に接続するためのＤ本の通信リンクを有する構成のサーバ装置であって、
   前記各計算機は、
   自身の通信リンクｉ（１≦ｉ≦Ｄ）と対向の計算機の通信リンクｉとの間にコネクションを設定して合計Ｄ本の冗長な通信経路を確保する経路冗長化手段と、
   通信対象となるデータの格納領域として主メモリ内に確保した１つのデータ格納手段と、
   前記各通信経路に対応し全て前記データ格納手段に対応づけられたＤ個のメモリ領域抽象化手段を有し、
   ある１つの前記メモリ領域抽象化手段を経由することによりそれに対応した通信経路を使用して対向の計算機との間で前記データ格納手段に含まれるデータの転送を行っている最中に当該通信経路に障害が発生した場合に、使用するメモリ領域抽象化手段を他の通信経路に対応したメモリ領域抽象化手段に切り替えるだけで当該データ転送に使用する通信経路を切り換えて当該データ転送を継続する、サーバ装置。
6. 請求項５に記載のサーバ装置において、
   前記サーバ装置に対し、Ｄ（≧２）個の系に冗長化された相互結合網の任意の系の間で通信が可能となるように相互結合網間通信リンクを追加したサーバ装置において、
   前記各計算機に対し、自身の計算機の通信リンクｉ（１≦ｉ≦Ｄ）と対向の計算機の全ての通信リンクとの間にコネクションを設定して合計Ｄ^２本の冗長な通信経路を確保するように前記経路冗長化手段を変更し、また、前記メモリ領域抽象化手段を前記各通信経路に対応したＤ^２個持たせるように変更した、サーバ装置。
7. 計算機間のコネクション設定機構および当該計算機の主メモリ領域の抽象化機構を持つ通信方式を実行可能な相互結合網を用いて複数台の計算機を接続し、さらに、その相互結合網がＤ（≧２）個の系に冗長化され各計算機がそれぞれの系に接続するためのＤ本の通信リンクを有し、前記複数台の計算機は外部装置と直接通信する通信サーバモジュールと蓄積装置を制御する蓄積サーバモジュールから構成されるサーバ装置における通信サーバモジュールであって、
   自身の通信リンクｉ（１≦ｉ≦Ｄ）と前記蓄積サーバモジュールの通信リンクｉとの間にコネクションを設定して合計Ｄ本の冗長な通信経路を確保する経路冗長化手段と、
   通信対象となるデータの格納領域として主メモリ内に確保した１つのデータ格納手段と、
   前記各通信経路に対応し全て前記データ格納手段に対応づけられたＤ個のメモリ領域抽象化手段を有し、
   ある１つの前記メモリ領域抽象化手段を経由することによりそれに対応した通信経路を使用して対向の計算機との間で前記データ格納手段に含まれるデータの転送を行っている最中に当該通信経路に障害が発生した場合に、使用するメモリ領域抽象化手段を他の通信経路に対応したメモリ領域抽象化手段に切り替えるだけで当該データ転送に使用する通信経路を切り換えて当該データ転送を継続する、通信サーバモジュール。
8. 計算機間のコネクション設定機構および当該計算機の主メモリ領域の抽象化機構を持つ通信方式を実行可能な相互結合網を用いて複数台の計算機を接続し、さらに、その相互結合網がＤ（≧２）個の系に冗長化され各計算機がそれぞれの系に接続するためのＤ本の通信リンクを有し、前記複数台の計算機は外部装置と直接通信する通信サーバモジュールと蓄積装置を制御する蓄積サーバモジュールから構成されるサーバ装置における蓄積サーバモジュールであって、
   自身の通信リンクｉ（１≦ｉ≦Ｄ）と前記通信サーバモジュールの通信リンクｉとの間にコネクションを設定して合計Ｄ本の冗長な通信経路を確保する経路冗長化手段と、
   通信対象となるデータの格納領域として主メモリ内に確保した１つのデータ格納手段と、
   前記各通信経路に対応し全て前記データ格納手段に対応づけられたＤ個のメモリ領域抽象化手段を有し、
   ある１つの前記メモリ領域抽象化手段を経由することによりそれに対応した通信経路を使用して対向の計算機との間で前記データ格納手段に含まれるデータの転送を行っている最中に当該通信経路に障害が発生した場合に、使用するメモリ領域抽象化手段を他の通信経路に対応したメモリ領域抽象化手段に切り替えるだけで当該データ転送に使用する通信経路を切り換えて当該データ転送を継続する、蓄積サーバモジュール。
9. 請求項７に記載の通信サーバモジュールとしてコンピュータを機能させるためのプログラム。
10. 請求項８に記載の蓄積サーバモジュールとしてコンピュータを機能させるためのプログラム。

Images