JP2003022259A

JP2003022259A - クライアントサーバ制御システム

Info

Publication number: JP2003022259A
Application number: JP2001205921A
Authority: JP
Inventors: Masao Ijiri; 昌男井尻
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2001-07-06
Filing date: 2001-07-06
Publication date: 2003-01-24

Abstract

(57)【要約】【課題】クライアントからのリクエストに対するサー
バ側の応答性を高めるとともに、運用系サーバに障害が
発生した場合の待機系サーバへの引き継ぎが迅速かつ円
滑に行われるクライアントサーバ制御システムを提供す
る。【解決手段】クライアント２には各サーバ１１，１２
が運用系か待機系かを識別するための運転モード情報を
管理する運転モード管理部２０と、各サーバ１１，１２
の障害発生の有無を検知する構成制御管理部２１と、運
転モード管理部２０による運転モード情報および構成制
御管理部２１による障害検知情報に基づいて接続すべき
サーバに接続するサーバ接続部２２とが設けられる一
方、各サーバ１１，１２には、当該サーバ１１，１２が
運用系か待機系かを識別するための運転モード情報を管
理する運転モード管理部１１０，１２０と、自己を含む
各サーバ１１，１２の障害発生の有無を検知するととも
に自己の障害発生時には他のサーバおよびクライアント
２に障害発生を通知する構成制御管理部１１１，１２１
とが設けられている。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、クライアントサー
バ制御システムに係り、特には、クライアント側からの
リクエストに対するサーバの応答性を高めるとともに、
障害発生時のサーバの代替制御を迅速かつ円滑に行える
ようにしたクライアントサーバ制御システムに関する。

【０００２】

【従来の技術】従来のクライアントサーバ制御システム
には、障害発生に効率的に対処できるようにするため
に、リクエストを発信する各クライアントに対して複数
のサーバを設け、各サーバが同一の共有ディスクに格納
されているデータベースに対してアクセスできるように
した構成のものがある。

【０００３】たとえば、特開平８−２１２０９５号公報
に開示されているクライアントサーバ制御システムは、
図１７に示すように、リクエストを発信する多数のクラ
イアント１０３と、各クライアント１０３からのリクエ
ストに応じた処理を実行運用する運用系サーバ１０１
と、この運用系サーバ１０１の処理を代替する待機系サ
ーバ１０２とを有し、クライアント１０３および各サー
バ１０１，１０２が通信回線としてのＬＡＮ１０４を介
して互いに接続されている。さらに、各サーバ１０１，
１０２に対しては、共有ディスク１０６が配置されてい
る。

【０００４】運用系と待機系の各サーバ１０１，１０２
は、各クライアント１０３との間で通信を行う通信部１
０７，１１０、各クライアント１０３からのリクエスト
に応じて共有ディスク１０６に対するアクセスを行うデ
ィスク制御部１０９，１１２、ディスク制御部１０１，
１１２へのリクエストの配分、ディスク制御部１０９，
１１２および通信部１０７，１１０における障害発生の
監視、待機系サーバ１０２への障害発生通知等の処理を
行うプロセス管理部１０８，１１１を備えている。

【０００５】そして、各プロセス管理部１０８，１１１
には、ディスク制御部１０９，１１２による共有ディス
ク１０６へのアクセスが可能なら『正常状態』、アクセ
ス不可能なら『障害発生』を示す情報を登録する状態管
理テーブル（図示せず）が設けられている。

【０００６】次に、上記構成のクライアントサーバ制御
システムにおける各部の動作について説明する。クライ
アント１０３がＬＡＮ１０４を介して運用系サーバ１０
１に対してリクエストの送信を行うと、そのリクエスト
が運用系サーバ１０１の通信部１０７に受信される。そ
して、通信部１０７は、この受信したリクエストをプロ
セス管理部１０８に渡すと、プロセス管理部１０８は、
状態管理テーブルの登録内容を参照する。

【０００７】プロセス管理部１０８は、状態管理テーブ
ルの登録内容が『正常状態』なら、ディスク制御部１０
９が共有ディスク１０６へのアクセスが可能であると判
断してディスク制御部１０９に対してそのリクエストを
配分する。これに対して、プロセス管理部１０８は、状
態管理テーブルの登録内容が『障害発生』なら、ディス
ク制御部１０９が共有ディスク１６０へのアクセスが不
可能であると判断して、そのリクエストを専用通信線１
０５等を介して待機系サーバ１０２のプロセス管理部１
１１に配分する。

【０００８】運用系サーバ１０１のディスク制御部１０
９がリクエストを受けた場合には、そのリクエストに応
じて共有ディスク上のファイルに対して読み書き等を行
うと共に、自己の故障発生に備えた引き継ぎ情報を同時
に共有ディスク１０６に書き込む。

【０００９】また、プロセス管理部１０８は、運用系サ
ーバ１０１内の各処理部１０７，１０９の状態を監視し
ており、これらに何らかの障害が発生した場合には、状
態管理テーブルの状態を『正常状態』から『障害発生』
に変更し、運用系サーバ１０１上で記録されたファイル
情報、通信情報、未処理のリクエスト等を途中処理情報
として待機系サーバ１０２に送信する。

【００１０】待機系サーバ１０２のプロセス管理部１１
１は、運用系サーバ１０１から上記のファイル情報、通
信情報、未処理のリクエスト等の途中処理情報を受信す
ると、これらの途中処理情報を各部１１０，１１１，１
１２にそれぞれ分配する。

【００１１】これにより、たとえば、運用系サーバ１０
１の通信部１０７に障害が発生している場合には、その
通信部１０７を停止させた後、待機系サーバ１０２は、
共有ディスク１０６の引き継ぎ情報を参照して、通信部
１１０で運用系サーバ１０１の論理アドレスが使用でき
るようにし、さらに、ＬＡＮ１０４に接続されている全
てのクライアント１０３に対して、変更されたアドレス
情報を送信する。

【００１２】

【発明が解決しようとする課題】このような従来のクラ
イアントサーバ制御システムにおいては、次に指摘する
ような問題が残されており、未だ改善の余地がある。（１）従来のものでは、クライアント１０３には、運
用系サーバ１０１の障害発生を検知するための手段は何
ら設けられていない。そのため、運用系サーバ１０１の
プロセス管理部１０８によって、たとえばディスク制御
部１０９の状態が『障害発生』であると検知された場合
でも、クライアント１０３ではそれが分からないため、
クライアント１０３からのリクエストは、必ず運用系サ
ーバ１０１に一旦送られ、その後、プロセス管理部１０
８によって待機系サーバ１０２に転送される。このた
め、運用系サーバ１０１と待機系サーバ１０２との間で
不必要な処理や通信が行われることになり、その結果、
各サーバ１０１，１０２やＬＡＮ１０４に余分な負荷を
与えるばかりか、クライアント１０３からのリクエスト
に対する応答性能も悪くなる。

【００１３】（２）また、運用系サーバ１０１のディ
スク制御部１０９は、共有ディスク１０６に対してデー
タの読み書きとは別に、自己の障害発生の場合に備えた
引き継ぎ情報を共有ディスク１０６に保存しなければな
らない。そのため、運用系サーバ１０２に余分な負荷を
与え、しかも、共有ディスク１０６には余分な記憶容量
が必要となる。

【００１４】（３）さらに、運用系サーバ１０１に障
害が発生した場合には、運用系サーバ１０１上で記録さ
れたファイル情報、通信情報、未処理のリクエスト等の
途中処理情報を待機系サーバ１０２に送信する必要があ
り、そのような途中処理情報を送ることができないよう
な障害（たとえば、オペレーティングシステムのハング
等）が発生した場合には、運用系サーバ１０１が処理途
中で中断した情報は、待機系サーバ１０２側で引き継ぐ
ことができなくなる。

【００１５】本発明は、上記のような各問題点を解決す
るためになされたものであって、クライアントからのリ
クエストに対するサーバ側の応答性を高めるとともに、
運用系サーバに障害が発生した場合の運用系サーバへの
引き継ぎが迅速かつ円滑に行われるようにすることを第
１の課題とする。さらには、運用系サーバの障害発生だ
けでなく、通信回線や共有ディスク等に障害が発生した
場合や、データバックアップ時にも、クライアントから
のリクエストに応じた処理を円滑に行えるようにするこ
とを第２の課題とする。

【００１６】

【課題を解決するための手段】本発明は、上記の課題を
解決するために、リクエストを発信するクライアント
と、このクライアントからのリクエストに応じた処理を
実行運用する運用系サーバと、この運用系サーバの処理
を代替する待機系サーバとを有し、前記クライアントお
よび各サーバが通信回線を介して互いに接続され、か
つ、前記各サーバには、同一の共有ディスクに対してア
クセスを行うＲＤＢＭＳ部が設けられているクライアン
トサーバ制御システムにおいて、次の構成を採用してい
る。

【００１７】すなわち、請求項１記載に係る発明では、
前記クライアントには、各サーバが運用系か待機系かを
識別するための運転モード情報を管理する運転モード管
理部と、各サーバの障害発生の有無を検知する構成制御
管理部と、前記運転モード管理部による運転モード情報
および前記構成制御管理部による障害検知情報に基づい
て接続すべきサーバを決定して当該サーバに接続するサ
ーバ接続部とが設けられる一方、前記各サーバには、当
該サーバが運用系か待機系かを識別するための運転モー
ド情報を管理する運転モード管理部と、自己を含む各サ
ーバの障害発生の有無を検知するとともに自己の障害発
生時には他のサーバおよび前記クライアントに障害発生
を通知する構成制御管理部とが設けられていることを特
徴としている。

【００１８】請求項２記載に係る発明では、請求項１記
載の発明の構成において、前記クライアントと各サーバ
とを接続する前記通信回線は複数設けられる一方、前記
クライアントおよび各サーバには、前記各通信回線の状
態を監視し、通信回線が故障した場合には最適の通信回
線を決定する通信管理部が設けられていることを特徴と
している。

【００１９】請求項３記載に係る発明では、請求項１ま
たは請求項２に記載の発明の構成において、前記運転モ
ード管理部は、各サーバが運用系か待機系かを識別する
情報に加えてその他の運転モードの情報も同時に管理す
るものである一方、前記クライアントのサーバ接続部
は、その運転モード管理部で管理されている前記運転モ
ード情報に基づいて、リクエストされた運転モードに適
合したサーバを決定するものであることを特徴としてい
る。

【００２０】請求項４記載に係る発明では、請求項１な
いし請求項３のいずれか１項に記載の発明の構成におい
て、前記実行系と待機系の各サーバには、データの高速
アクセスが可能な高速ファイルシステムと、この高速フ
ァイルシステムに対するデータの書き込み制御を行う二
重書き管理部とが設けられる一方、前記クライアントに
は、高速書き込みリクエストに応じて、前記共有ディス
クに書き込まれるべきデータを前記高速ファイルシステ
ムに格納するのに適合したデータ構造へデータ変換する
クライアント側ＤＢ変換部が設けられていることを特徴
としている。

【００２１】請求項５記載に係る発明では、請求項４記
載の発明の構成において、前記実行系と待機系の各サー
バには、前記高速ファイルシステムに格納されたデータ
を前記共有ディスクに保存すべきデータ構造に変換して
前記ＲＤＢＭＳ部に引き渡すサーバ側ＤＢ変換部が設け
られていることを特徴としている。

【００２２】請求項６記載に係る発明では、請求項５記
載の発明の構成において、前記待機系サーバは、前記運
用系サーバによる共有ディスクへのデータ格納が完了す
るまでは、共有ディスクに対するデータ書き込み要求を
一定時間保持するものであることを特徴としている。

【００２３】請求項７記載に係る発明では、請求項５ま
たは請求項６に記載の発明の構成において、前記高速フ
ァイルシステムから前記共有ディスクへ書き込み転送す
るデータは、レコード単位で行うものであることを特徴
としている。

【００２４】請求項８記載に係る発明では、請求項５ま
たは請求項６に記載の発明の構成において、前記高速フ
ァイルシステムから前記共有ディスクへ書き込み転送す
るデータは、テーブル単位で行うものであることを特徴
としている。

【００２５】請求項９記載に係る発明では、請求項４な
いし請求項８のいずれか１項に記載の構成において、前
記高速ファイルシステムは、不揮発性の記憶媒体で構成
されていることを特徴としている。

【００２６】請求項１０記載に係る発明では、請求項５
ないし請求項９のいずれか１項に記載の発明の構成にお
いて、前記待機系サーバは、前記運用系サーバのＲＤＢ
ＭＳ部の故障が回復するまでは、共有ディスクに対する
データ書き込み要求を保持するものであることを特徴と
している。

【００２７】請求項１１記載に係る発明では、請求項５
ないし請求項９のいずれか１項に記載の発明の構成にお
いて、前記待機系サーバは、前記共有ディスクの故障が
回復するまでは、共有ディスクに対するデータ書き込み
要求を保持するものであることを特徴としている。

【００２８】請求項１２記載に係る発明では、請求項５
ないし請求項９のいずれか１項に記載の発明の構成にお
いて、前記待機系サーバは、運用系サーバ部によるバッ
クアップ処理が終了するまでは、共有ディスクに対する
データ書き込み要求を保持するものであることを特徴と
している。

【００２９】

【発明の実施の形態】実施の形態１．図１は、本発明の
実施の形態１に係るクライアントサーバ制御システムの
全体構成を示すブロック図である。この実施の形態１の
クライアントサーバ制御システムは、リクエストを発信
する多数のクライアント２と、各クライアント２からの
リクエストに応じた処理を実行運用する運用系サーバ１
１と、この運用系サーバ１１の処理を代替する待機系サ
ーバ１２とを有し、各クライアント２および各サーバ１
１，１２が通信回線としてのＬＡＮ４を介して互いに接
続されている。さらに、各サーバ１１，１２に対して
は、共有ディスク３が設けられている。

【００３０】各クライアント２には、各サーバ１１，１
２が運用系か待機系かを認識するための情報や各サーバ
１１，１２のその他の運転モード情報を管理する運転モ
ード管理部２０、各サーバ１１，１２の障害発生の有無
を検知する構成制御管理部２１、運転モード管理部２０
による運転モード情報および構成制御管理部２１による
障害検知情報に基づいて接続すべきサーバ１１または１
２を決定して当該サーバに接続するサーバ接続部２２、
および予め設定されたアプリケーションソフトを実行し
てサーバ接続部２２で接続されたサーバ１１または１２
に対してリクエストを要求するアプリケーション実行部
２３が設けられている。

【００３１】一方、各サーバ１１，１２には、当該サー
バが運用系か待機系かを識別するための情報やその他の
運転モード情報を管理する運転モード情報を管理する運
転モード管理部１１０，１２０、自己を含む各サーバ１
１，１２の障害発生の有無を検知するとともに自己の障
害発生時には他のサーバおよびクライアント２に対して
障害発生を通知する構成制御管理部１１１，１２１、共
有ディスク３に格納されているデータベースの維持、運
用を行うための市販のＲＤＢＭＳ（リレーショナルデー
タベース管理システム）が搭載されたＲＤＢＭＳ部１１
２，１２２、およびＲＤＢＭＳ部１１２，１２１が共有
ディスク３にアクセスする場合の各種制御を行うＤＢ制
御部１１３，１２３が設けられている。なお、市販のＲ
ＤＢＭＳとしては、たとえば、マイクロソフト社のＳＱ
Ｌや、オラクル社のＯｒａｃｌｅ等がある。

【００３２】次に、上記構成のクライアントサーバ制御
システムの動作について説明する。まず、運用系サーバ
１１が正常な運用状態において処理を実行している場合
について説明する。ある一つのクライアント２におい
て、そのアプリケーション実行部２３は、サーバ接続部
２２に対してＤＢアクセスリクエストを発行する。これ
に応じて、サーバ接続部２２は、運転モード管理部２０
に対して運用系のサーバがどれであるかを問い合わせ、
運転モード管理部２０は、運用系サーバ１１のアドレス
をサーバ接続部２２に返す。サーバ接続部２２は、アプ
リケーション実行部２３からのＤＢアクセスリクエスト
を運転モード管理部２０から返されたアドレスに対応し
た運用系サーバ１１に対してＬＡＮ４を使って送信す
る。

【００３３】運用系サーバ１１の構成制御管理部１１１
は、クライアント２からのＤＢアクセスリクエストが自
己のアドレスに一致していると、そのリクエストをＲＤ
ＢＭＳ部１１２に送信する。これに応じてＲＤＢＭＳ部
１１２は、共有ディスク３内にあるデータベース３１に
アクセスを行い、その結果をＬＡＮ４を介してクライア
ント２に送信し、サーバ接続部２２を介してアプリケー
ション実行部２３に返す。

【００３４】ここで、待機系サーバ１２は、運用系サー
バ１１に対する専属のものではなく、実行系サーバ１１
が正常に実行運用されている場合には、待機系サーバ１
２独自のサーバ処理を行っている。また、運用系サーバ
１１と待機系サーバ１２の各構成制御管理部１１１、１
２１は、相互にサーバの状態を監視している。たとえ
ば、待機系サーバ１２に着目すると、その構成制御管理
部１２１は、自己の障害発生の有無を監視するととも
に、運用系サーバ１１に障害が発生していないか否かも
同時に監視している。

【００３５】次に、運用系サーバ１１に障害が発生した
場合の動作について説明する。まず、運用系サーバ１１
がダウンして全く動作できないような完全障害が発生し
た場合の処理について説明する。この場合には、実行系
サーバ１１の構成制御管理部１１１からは、待機系サー
バ１２およびクライアント２に対して一定時間内に監視
情報が通知されなくなるので、これに応じて待機系サー
バ１２およびクライアント２の各構成制御管理部１２
１，２１は、実行系サーバ１１において完全障害が発生
したものと判断する。

【００３６】これに応じて、クライアント２は、構成制
御管理部２１が運転モード管理部２０に対して、今まで
の待機系サーバ１２を運用系サーバに切り替わることを
知らせるので、運転モード管理部２０は、待機系サーバ
１２が運用系となるように運転モードを切り替える。し
たがって、これ以降は、クライアント２のサーバ接続部
２２は、アプリケーション実行部２３からのＤＢアクセ
スリクエストに対して新たに運用系となったサーバ１２
を選択して接続するようになる。

【００３７】また、待機系サーバ１２の構成制御管理部
１２１も、実行系サーバ１１から一定時間内に監視情報
が通知されなくなると、自己のサーバを実行系に切り替
える。すなわち、待機系サーバ１２は、運用系サーバ１
１に障害が発生したと判断すると、これに応じて運転モ
ード管理部１２０は、自己が待機系から運用系となるよ
うに運転モードを切り替える。また、構成制御管理部１
２１は、ＤＢ制御部１２３に対して共有ディスク３のマ
ウント処理とＲＤＢＭＳ部１２２の起動を命ずる。これ
に応じて、ＤＢ制御部１２３は、共有ディスク３のマウ
ントを行うとともに、ＲＤＢＭＳ部１２２を起動する。
これにより、ＲＤＢＭＳ部１２２は、共有ディスク３内
のデータベース３１と接続する。

【００３８】次に、運用系サーバ１１にたとえばソフト
ウェア障害や周辺機器（ＤＢ制御部１１３など）のハー
ドウェア障害など、構成制御管理部１１１が障害発生を
検知できるような障害が発生した場合の動作について説
明する。

【００３９】運用系サーバ１１の構成制御管理部１１１
が自己の障害を検知すると、ＤＢ制御部１１３に対して
ＲＤＢＭＳ部１１２の終了処理と共有ディスク３のアマ
ウントとを命じる。これに応じて、ＤＢ制御部１１３
は、ＲＤＢＭＳ部１１２の処理を終了させるとともに、
共有ディスク３のアンマウント処理を行う。さらに、待
機系サーバ１２およびクライアント２の各構成制御管理
部１２１、２１に対して、運用系サーバ１１に障害が発
生した旨を通知して、運用系サーバ１１を停止させる。

【００４０】一方、待機系サーバ１２の構成制御管理部
１２１は、運用系サーバ１１からの障害発生の通知を受
け取ると、この障害検知に応じて運転モード管理部１２
０の運転モードを待機系から運用系に切り替えるように
指示する。また、ＤＢ制御部１２３に対して共有ディス
ク３のマウント処理とＲＤＢＭＳ部１２２の起動を命ず
る。これに応じて、ＤＢ制御部１２３は、共有ディスク
３のマウントを行うとともに、ＲＤＢＭＳ部１２２を起
動する。これにより、ＲＤＢＭＳ部１２２は、共有ディ
スク３内のＤＢ３１と接続する。さらに、クライアント
の構成制御管理部２１に対して待機系サーバ１２が運用
系になったことを通知する。

【００４１】また、クライアント２は、運用系サーバ１
１からの障害発生の通知を受け取ると、構成制御管理部
２１が運転モード管理部２０に対して、今までの待機系
サーバ１２が運用系サーバに切り替わったことを知らせ
るので、運転モード管理部２０は、待機系サーバ１２が
運用系となるように運転モードを切り替える。したがっ
て、これ以降は、クライアント２のサーバ接続部２２
は、アプリケーション実行部２３からリクエストが出さ
れた場合に、新たに運用系となったサーバ１２に対して
接続するようになる。

【００４２】なお、クライアント２において、アプリケ
ーション実行部２３からのＤＢアクセスリクエスト発行
時において、運用系サーバ１１に障害が既に発生してい
るが、未だクライアント側の運転モード管理部２０が待
機系から運用系に切り替わっていない場合が起こり得
る。その場合には、クライアント２の構成制御管理部２
１は、待機系サーバ１２が運用系として確立するまでの
間、一定時間にわたって時間待ちをする。これによっ
て、クライアント２からのリクエストに対する処理の抜
けを防止することができる。このため、クライアント２
側のアプリケーション実行部２３は、障害発生時の運用
系サーバ１１から待機系サーバ１２への系の切り替えつ
いて全く意識する必要がなくなる。

【００４３】また、運用系サーバ１１においては、極め
て軽微な故障、あるいはバージョンアップなどのために
一時的に待機系サーバ１２に系を切り替えたいような場
合が生じる。そのようなときには、運用系サーバ１１の
構成制御管理部１１１から待機系サーバ１２およびクラ
イアント２に対して系切り替え要求を出すようにする。
このような系切り替え要求に対して、待機系サーバ１２
とクライアント２の各構成制御管理部１２１，２１は、
運用系サーバ１１の構成制御管理部１１１から障害発生
の通知を受けた場合と同様な処理を行うことにより、系
を切り替えることができる。

【００４４】以上のように、この実施の形態１では、サ
ーバ１１，１２およびクライアント２の各構成制御管理
部１１１，１２１，２１が互いの状態を常時監視し、障
害発生時には、クライアント２のサーバ接続部２２がそ
の障害検知に応じて、新たに運用系となるサーバ１２を
選択する一方、新たに運用系となるサーバ１２のＤＢ制
御部１２３がＲＤＢＭＳ部１２２の起動制御を行うの
で、クライアント２のアプリケーション実行部２３から
のＤＢアクセスリクエストは最短の経路でサーバ１２に
受け付けられることになり、クライアント２からのリク
エストの応答性が高まる。

【００４５】しかも、運用系サーバ１１は、従来のよう
に故障発生時に備えて引き継ぎ情報を共有ディスク３に
保管しておく必要がなく、また、障害発生時に運用系サ
ーバ１１で記録されたファイル情報や通信情報等の途中
処理情報を待機系サーバ１２側に転送する必要もないの
で、運用系サーバ１１で未処理のデータも待機系サーバ
１２に迅速かつ円滑に引き継いで処理することが可能に
なる。

【００４６】実施の形態２．図２は、本発明の実施の形
態２に係るクライアントサーバ制御システムの全体構成
を示すブロック図であり、図１に示した実施の形態１の
構成と対応する部分には同一の符号を付す。

【００４７】この実施の形態２のクライアントサーバ制
御システムは、クライアント２、運用系サーバ１１、お
よび待機系サーバ１２を互いに接続する通信回線として
複数（ここでは２ライン分）のＬＡＮ４１，４２が設け
られている。また、クライアント２、運用系サーバ１
１、および待機系サーバ１２に対しては、それぞれ各Ｌ
ＡＮ４１，４２の状態を監視し、ＬＡＮ４１，４２が故
障した場合には最適のＬＡＮを決定する通信管理部とし
てのＬＡＮ監視部２４，１１４，１２４，が設けられて
いる。さらに、２つのＬＡＮ４１，４２の双方に障害が
発生した場合に、運用系と待機系のサーバ１１，１２間
同士で障害発生が通知できるように両者１１，１２を結
ぶ別の専用回線４３が設けられている。その他の構成
は、図１に示した実施の形態１のものと同じであるか
ら、ここでは詳しい説明は省略する。

【００４８】次に、上記構成のクライアントサーバ制御
システムにおける、主としてＬＡＮ監視部１１４，１２
４，２４の動作について説明する。この実施の形態２の
クライアントサーバ制御システムでは、クライアント２
および各サーバ１１，１２に設けられているそれぞれの
ＬＡＮ監視部２４，１１４，１２４が各ＬＡＮＡ４１、
ＬＡＮＢ４２の状態が正常か否かを監視している。

【００４９】クライアント２のアプリケーション実行部
２３は、サーバ接続部２２に対してＤＢアクセスリクエ
ストを発行する。これに応じてサーバ接続部２２は、運
転モード管理部２０に対して運用系がどかれかを問い合
わせて、運用系サーバ１１を特定する。また、サーバ接
続部２２は、ＬＡＮ監視部２４から各ＬＡＮ４１，４２
の状態の情報を取得する。

【００５０】ここで、一方のＬＡＮ４１は正常だが、他
方のＬＡＮ４２が故障しているものとすると、ＬＡＮ監
視部２４は正常なＬＡＮ４１を検出する。正常なＬＡＮ
４１がある場合は、運転モード管理部２０はそのＬＡＮ
Ａ４１を経由して送信すべき運用系サーバ１１のアドレ
スをサーバ接続部２２に返す。サーバ接続部２２は、ア
プリケーション実行部２３からのＤＢアクセスリクエス
トを運転モード管理部２０から返されたアドレスに対し
て、正常なＬＡＮＡ４１を使って運用系サーバ１１のＲ
ＤＢＭＳ部１１２に送信する。

【００５１】なお、ＬＡＮ監視部２４で監視されている
２つのＬＡＮ４１，４２の双方に異常が生じた場合、ク
ライアント２の構成制御管理部２１は、予め設定された
所定時間の間、各サーバ１１，１２からの通知を待つ。
この状態のときに運用系サーバ１１に障害が生じた場
合、運用系サーバ１１のＬＡＮ監視部１１４は、いずれ
のＬＡＮ４１，４２を経由してもクライアント２あるい
は待機系サーバ１２への通信ができないと判断すると、
その旨を構成制御管理部１１１に通知する。構成制御管
理部１１１はこの通知を受け取ると、ＬＡＮ４１、４２
とは別の専用回線４３を経由して待機系サーバ１２の構
成制御管理部１２１に障害発生を通知する。これに応じ
て、待機系サーバ１２は、運転モード管理部１２０が運
転モードを待機系から運用系に切り替えるとともに、待
機系から運用系に切り替わる旨をクライアント２に通知
する。その結果、クライアント２の構成制御管理部２１
は、新たに運用系となったサーバ１２から各ＬＡＮ４
１，４２の状態をＬＡＮ監視部２４を経由して取得す
る。

【００５２】その後、ＬＡＮ４１，４２のいずれか一方
の故障が回復された結果、クライアント２でて回復した
正常なＬＡＮがＬＡＮ監視部２４によって見つかれば、
クライアント２からはそのＬＡＮたとえば４１を経由し
て新たに運用系となったサーバ１２に対してＤＢアクセ
スリクエストを送信する。

【００５３】以上のように、この実施の形態２では、ク
ライアント２、運用系サーバ１１、および待機系サーバ
１２のそれぞれに各ＬＡＮ４１，４２の状態を監視し、
ＬＡＮ４１，４２が故障した場合には最適のＬＡＮを決
定するＬＡＮ監視部１１４，１２４，２４を設けている
ので、実施の形態１の作用効果に加えて、常に最適なＬ
ＡＮを選択して接続することができ、しかも、クライア
ント２側のアプリケーション実行部２３は、二重化され
たＬＡＮを意識することなく、各サーバ１１，１２に対
してアクセスできるようになる。

【００５４】なお、この実施の形態２では二重化された
通信回線として、バス型のＬＡＮについて説明したが、
これに限らず、多重化されたＬＡＮやリング型やスター
型の他のトポロジーのネットワークに対しても、また、
ＬＡＮのみならずＷＡＮ等の通信回線を使用する場合に
も同様に適用することが可能である。

【００５５】実施の形態３．前述の各実施の形態１，２
では、システムとして運用／待機の２つのモードをもつ
場合について説明したが、クライアント２も含めて運用
／待機以外の運転モード（たとえば、試験やシミュレー
ションを行うための試験モードや訓練モードなど）が必
要となるシステムもある。したがって、この実施の形態
３では、このような各種の運用モードをもつ場合に対応
できるようにしたものである。

【００５６】この実施の形態３のクライアントサーバ制
御システムの全体構成は、図１のものと基本的に同じで
あるが、図１と異なる点は、この実施の形態３では、ク
ライアント２、運用系および待機系の各サーバ１１，１
２の運転モード管理部２０，１１０，１２０には、運用
／待機のモードの外に、試験モードや訓練モードなどの
他の運転モードを規定する情報が予め登録されている。
また、共有ディスク３には、図３に示すように、各々の
運転モードに応じた複数のデータベース３１，３２、
…，３Ｎが格納されていることである。

【００５７】図１および図３において、クライアント２
のアプリケーション実行部２３は、ＤＢ接続部２２に対
してＤＢアクセスリクエストを発行する。サーバ接続部
２２は、接続すべきサーバのアドレスを運転モード管理
部２０に問い合わせる。運転モード管理部２０は、自己
の運転モードと一致するモードで動作するサーバ（ここ
ではたとえば待機系サーバ１２とする）を検索する。運
転モード管理部２０は、サーバ接続部２２に自己の運転
モードに一致するサーバ１２のアドレスを返すので、サ
ーバ接続部２２は、ＤＢアクセスリクエストをそのアド
レスに一致する待機系サーバ１２に向けて送信する。

【００５８】待機系サーバ１２の構成制御管理部１２１
は、サーバ立ち上げの際に運転モード管理部１２０によ
って自分が動作すべき運転モードを取得し、それをＤＢ
制御部１２３に通知する。ＤＢ制御部１２３は、共有デ
ィスク３をマウントし、指定された運転モードに従って
ＲＤＢＭＳ部１２２に対して、共有ディスク２のデータ
ベースたとえばＤＢ３Ｎに接続するように指示する。

【００５９】以上のように、この実施の形態３では、運
用系／待機系のモードだけでなく他の運転モード（試験
モードや訓練モードなど）においてもＲＤＢＭＳ部１１
２，１２２を起動することができ、他の運転モードを必
要とするクライアント２が共有ディスク３のデータベー
ス３１，３２、…，３Ｎに対してアクセスできるように
なる。したがって、サーバ１１，１２やＲＤＢＭＳ部１
１２，１２２を運転モード毎に予め用意しておく必要が
なくこれらを共有化できるため、資源を有効に活用する
ことができる。

【００６０】実施の形態４．図４は、本発明の実施の形
態４に係るクライアントサーバ制御システムの全体構成
を示すブロック図であり、図２に示した実施の形態２の
構成と対応する部分には同一の符号を付す。

【００６１】クライアントサーバ制御システムでは、ク
ライアント２のアプリケーション実行部２３から一時に
多量のデータが生成され、これをリアルタイムでサーバ
１１，１２側で保存することが必要となる場合がある。
この実施の形態４のクライアントサーバ制御システムで
は、このようなリアルタイム性の要求に応えることがで
きるように構成したものである。

【００６２】すなわち、この実施の形態４のクライアン
トサーバ制御システムでは、クライアント２側に、高速
書き込みリクエストに応じて本来は共有ディスク３に書
き込まれるべきＲＤＢ（リレーショナルデータベース）
のデータを後述の高速ファイルシステム１１５，１２５
に格納するのに適合したデータ構造へデータ変換するク
ライアント側ＤＢ変換部２６と、データ構造の変換ルー
ルを定義したクライアント側ＤＢ変換テーブル２７と、
アプリケーション実行部２３からのリクエストに応じて
データを共有ディスク３あるいは高速ファイルシステム
１１６，１２６のいずれに格納するのかを選択するＤＢ
切替部２５とが設けられている。

【００６３】一方、実行系と待機系の各サーバ１１，１
２には、データの高速アクセスが可能な高速ファイルシ
ステム１１６，１２６と、これらの高速ファイルシステ
ム１１６，１２６に対するデータの書き込み制御を行う
二重書き管理部１１５，１２５とが設けられている。上
記の各高速ファイルシステム１１６，１２６は、この実
施の形態４では、高速アクセスが可能なＤＲＡＭ等の半
導体記憶装置で構成されている。

【００６４】ここで、運用系サーバ１１の二重書き管理
部１１５は、クライアント２からの高速書き込みリクエ
ストを受信すると、これに応じて自己の高速ファイルシ
ステム１１６にデータを書き込むとともに、このリクエ
ストを待機系サーバ１２の二重書き管理部１２５に転送
することで、待機系サーバ１２側の高速ファイルシステ
ム１２６にもクライアント２から送られる同じデータが
重複して格納されるようになっている。その他の構成
は、図２に示した実施の形態２の場合と同様であるか
ら、ここでは詳しい説明は省略する。

【００６５】クライアント２のアプリケーション実行部
２３は、サーバ接続部２２に対してＤＢアクセスリクエ
ストを発行する。サーバ接続部２２は、アプリケーショ
ン実行部２３から要求されたＤＢアクセスリクエストが
共有ディスク２への格納対象となるＲＤＢのデータなの
か、高速ファイルシステム１１６，１２６への格納対象
となるデータなのかを予め設定された定義ファイルを元
に判断する。アクセス対象がＲＤＢのデータの場合は、
実施の形態２の場合と同様に、運用系サーバ１１と適切
なＬＡＮたとえば４１とを決定して運用系サーバ１１の
ＲＤＢＭ部１１２にリクエストを送信する。

【００６６】これに対して、リクエスト対象が高速ファ
イルシステム１１６に対するデータの場合には、クライ
アント２では、データ構造の変換ルールを定義したクラ
イアント側ＤＢ変換テーブル２７を参照して、クライア
ント側ＤＢ変換部２６がアクセスリクエストを高速ファ
イルシステム１１６，１２６のデータ構造に変換した上
で、適切なＬＡＮたとえば４１とを決定して運用系サー
バ１１の二重書き管理部１１５にリクエストを送信す
る。

【００６７】クライアント２からリクエストを受け付け
た二重書き管理部１１６は、高速ファイルシステム１１
５に対してアクセスを行うとともに、クライアント２に
対して応答データを返信する。特に、クライアント２か
ら高速書き込みリクエストが出されている場合には、待
機系サーバ１２の二重書き管理部１２５にもリクエスト
を送信し、それを受け取った二重書き管理部１２５は、
高速ファイルシステム１２６に対してアクセスを行う。
したがって、運用系サーバ１１と待機系サーバ１２の双
方の高速ファイルシステム１１６，１２６に対して同じ
内容のデータが重複して書き込まれる。

【００６８】これにより、クライアント２のアプリケー
ション実行部２３から多量のデータが生成される場合で
も、これをリアルタイムで運用系サーバ１１の高速ファ
イルシステム１１６に格納できるので、クライアント２
側からのリアルタイム性の要求に応えることができる。
しかも、運用系と待機系の各サーバ１１，１２の高速フ
ァイルシステム１１６，１２６の双方に同じデータが重
複して格納されるため、運用系サーバ１１６に障害が生
じた場合には、待機系サーバ１２の高速ファイルシステ
ム１２６に格納されている情報に基づいてクライアント
２からのリクエストに対応できることになる。

【００６９】以上のように、この実施の形態４では、各
サーバ１１，１２のＲＤＢＭＳ部１１２または１２２に
よって共有ディスク３にデータを保存するようなシーケ
ンスではクイアント２のアプリケーション実行部２３の
リアルタイム性を損ねるような場合には、各高速ファイ
ルシステム１１６または１２６にデータを高速で格納で
きるため、リアルタイム性の要求に応えることが可能に
なる。しかも、クライアント２側では、アプリケーショ
ンを変更することなく定義ファイルを変更するだけで対
処できるため、クライアント２側の負荷も少なくて済
む。

【００７０】実施の形態５．図５は、本発明の実施の形
態５に係るクライアントサーバ制御システムの全体構成
を示すブロック図であり、図４に示した実施の形態４の
構成と対応する部分には同一の符号を付す。

【００７１】この実施の形態５のクライアントサーバ制
御システムは、実行系と待機系の各サーバ１１，１２
に、高速ファイルシステム１１６，１２６に一旦格納さ
れたデータを共有ディスク３に保存すべきＲＤＢのデー
タ構造に変換するサーバ側ＤＢ変換部１１７，１２７
と、高速ファイルシステム１１６，１２６のデータ構造
をＲＤＢのデータ構造に変換する変換ルールを定義した
サーバ側ＤＢ変換テーブル１１８，１２８とが設けられ
ている。さらに、サーバ側ＤＢ変換部１１７，１２７
は、高速ファイルシステム１１６，１２６に格納されて
いるデータをサーバ側ＤＢ変換部１１７，１２７を用い
て共有ディスク３に格納可能なデータ構造となるように
データ変換するとともに、ＲＤＢＭＳ部１１２，１２２
に対して共有ディスク３への格納を指令するように構成
されている。その他の構成は、図４に示した実施の形態
４の場合と同様であるから、ここでは詳しい説明は省略
する。

【００７２】この実施の形態５の構成において、クライ
アント２のアプリケーション実行部２３が運用系サーバ
１１の二重書き管理部１１５に書き込みリクエストを通
知して、運用系サーバ１１の高速ファイルシステム１１
６にデータが一旦格納されると、その後、ＤＢ変換部１
１７は、ＲＤＢＭＳ部１１２に対して書き込みリクエス
トを発行し、高速ファイルシステム１１６に保存された
データを非同期、または定周期にＤＢ変換テーブル１１
８を用いて共有ディスク３に格納すべきデータ構造に変
換する。これに応じて、ＲＤＢＭＳ部１１２は、クライ
アント２からの書き込みリクエストとは非同期に、共有
ディスク３上の所定のデータベースたとえば３２に対し
て高速ファイルシステム１１６にデータを書き込む速度
よりも低速度でもって書き込みを行う（以下、この処理
を遅延書き込みと称する）。

【００７３】以上のように、この実施の形態５では、リ
アルタイム性を要求するアプリケーション２からの運用
系サーバ１１への書き込み要求を一旦高速ファイルシス
テム１１６に保存してクライアント２には即応答を返
し、その後、高速ファイルシステム１１６から共有ディ
スク３に遅延書き込みを行うので、クライアント２のア
プリケーション実行部２３のリアルタイム性の要求を保
証するとともに、各高速ファイルシステム１１６，１２
６と共有ディスク３の双方の負担を軽減することができ
る。

【００７４】実施の形態６．前述の実施の形態５では、
運用系サーバ１１がクライアント２からの書き込み要求
を受け付けて高速ファイルシステム１１６に一旦データ
を保存し、その後、ＲＤＢＭＳ部１１２によって共有デ
ィスク３にデータを遅延書き込みする場合について説明
したが、この実施の形態６では、このような遅延書き込
みを行っている途中で運用系サーバ１１やＬＡＮ４１，
４２に障害が発生した場合の具体的な処理について説明
する。なお、この実施の形態６のクライアントサーバ制
御システムにおける構成は、図５に示した実施の形態５
のものと基本的に同じである。

【００７５】まず、高速ファイルシステム１１６に保存
されているデータを共有ディスク３に遅延書き込みする
際に、障害が発生することなく正常に実行運用される場
合の処理について、図６に示すフローチャートを参照し
て説明する。

【００７６】運用系サーバ１１においてクライアント２
からの書き込みリクエストを受信すると、二重書き管理
部１１５は、高速ファイルシステム１１６に書き込みを
行う（ステップＡ２）。運用系サーバ１１は、クライア
ント２からの書き込みリクエストを待機系サーバ１２に
も転送するので、待機系サーバ１２は、この転送された
書き込みリクエストに応じて、同様に高速ファイルシス
テム１２６に書き込みを行う（ステップＢ０）。運用系
サーバ１１は、この時点でクライアント２に完了通知を
行う（ステップＡ３）。

【００７７】運用系サーバ１１は、高速ファイルシステ
ム１１６にデータが格納されると、共有ディスク３への
遅延書き込みを開始するために、まず、遅延書き込みリ
クエストを待機系サーバ１２にも転送する（ステップＡ
４）。待機系サーバ１２は、この転送されてきた遅延書
き込みリクエストを受信すると(ステップＢ１)、ＲＤＢ
ＭＳ部１１２による共有ディスク３への遅延書き込みの
リクエストを一旦キューイングする（ステップＢ３）。

【００７８】運用系サーバ１１は、ステップＡ４の処理
後、ＲＤＢＭＳ部１１２に共有ディスク３への遅延書込
み要求を行い（ステップＡ５）、遅延書き込みを開始す
る。運用系サーバ１１のＲＤＢＭＳ部１１２が共有ディ
スク３への遅延書き込みを完了すると、その旨を待機系
サーバ１２にＬＡＮたとえば４１を介して通知する（ス
テップＡ６）。待機系サーバ１２は、運用系サーバ１１
からのこの遅延書込み完了通知を受け取ると、先のステ
ップＢ３でキューイングしていた遅延書き込み要求を破
棄する（ステップＢ４）。

【００７９】次に、運用系サーバ１１が遅延書き込みの
途中で何らかの要因で重故障となり、ＲＤＢＭＳ部１１
２による共有ディスク３への遅延書き込みができなかっ
た場合の処理について、図７のフローチャートを参照し
て説明する。

【００８０】運用系サーバ１１におけるステップＡ２〜
Ａ４、待機系サーバ１２におけるステップＢ０、Ｂ１，
Ｂ３は、図６のフローチャートで示した処理と同じであ
る。すなわち、待機系サーバ１２は、運用系サーバ１１
から転送された遅延書き込みリクエストを受信した後
（ステップＢ１）、ＲＤＢＭＳ部１２２による共有ディ
スク３への遅延書き込み要求を一旦キューイングし（ス
テップＢ３）、運用系サーバからの遅延書き込み完了通
知を待ち受けている。

【００８１】運用系サーバ１１は、ステップＡ４の処理
後において重故障が発生してＲＤＢＭＳ部１１２による
共有ディスク３への遅延書き込みが行われなかった場
合、運用系サーバ１１の構成制御管理部１１１から待機
系サーバ１２に対して障害が発生した旨を通知するの
で、待機系サーバ１２の構成制御管理部１２１は、この
通知を検知すると、運転モード管理部１２０は待機系か
ら運用系にモードを切り替える（ステップＢ１１）。そ
して、ステップＢ３でキューイングしていたＲＤＢＭＳ
部１２２による共有ディスク３への遅延書き込み要求を
取り出し（ステップＢ１２）、共有ディスク３への書き
込みを行う（ステップＢ１３）。

【００８２】次に、運用系サーバ１１の遅延書き込みの
途中で、たとえば２つのＬＡＮ４１，４２に共に障害が
発生してＲＤＢＭＳ部１１２による共有ディスク３への
遅延書き込み完了を待機系サーバ１２に通知できなかっ
た場合の処理について、図８に示すフローチャートを参
照して説明する。

【００８３】運用系サーバ１１におけるステップＡ２〜
Ａ４、待機系サーバ１２におけるステップＢ０、Ｂ１，
Ｂ３は、図６のフローチャートで示した処理と同じであ
る。すなわち、待機系サーバ１２は、運用系サーバ１１
から転送された遅延書き込みリクエストを受信した後
（ステップＢ１）、ＲＤＢＭＳ部１２２による共有ディ
スク３への遅延書込み要求を一旦キューイングし（ステ
ップＢ３）、運用系サーバからの遅延書き込み完了通知
を待ち受けている。

【００８４】運用系サーバ１１には何ら障害が発生して
いないので、運用系サーバ１１は、ステップＡ４の処理
後、共有ディスク３への遅延書き込み要求に応じて、Ｒ
ＤＢＭＳ部１１２は共有ディスク３への遅延書き込みを
行う(ステップＡ５)。この遅延書き込みが完了後すると
(ステップＡ６)、運用系サーバ１１は待機系サーバ１２
に対して書き込み完了を知らせようとするが、いずれの
ＬＡＮ４１，４２にも障害が生じているときには、遅延
書き込みの完了を待機系サーバ１２に通知できなくな
る。

【００８５】待機系サーバ１２は、運用系サーバ１１か
ら上述の遅延書き込み完了通知が到来せず、しかも、予
め定義された一定時間以内に運用系サーバ１１から別の
専用回線４３等を経由して障害発生の通知（待機系から
運用系へのモード切り替えの通知）が到来しない場合に
は、運用系サーバ１１の障害発生ではなくてＬＡＮ４
１，４２の障害発生であって運用系サーバ１１の遅延書
き込みは完了したものと判断して、ＲＤＢＭＳ部１１２
の共有ディスク３への遅延書き込み要求を破棄する（ス
テップＢ２１）。

【００８６】以上のように、この実施の形態６では、ク
ライアント２のアプリケーション実行部２３のリアルタ
イム性の要求を保証できるだけでなく、運用系サーバ１
１が遅延書き込みの途中で重故障が生じた場合でも、待
機系サーバ１２側でＲＤＢＭＳ部１２２による共有ディ
スク３への遅延書き込みを保証することが可能になる。
また、遅延書き込みを行っている途中でＬＡＮ４１，４
２に障害が発生した場合にも円滑に対処することができ
る。

【００８７】なお、運用系サーバ１１がダウンして全く
動作できないような完全障害が最初から発生している場
合には、実施の形態１で説明したように、クライアント
２と各サーバ１１，１２の構成制御管理部２１，１１
１，１２１の相互の障害監視によって、待機系サーバ１
２が運用系に切り替わって、クライアント２からの書き
込みリクエストは新たに運用系となったサーバ１２に送
信されるので、そのサーバ１２において、図６に示した
ステップＡ２〜Ａ６の一連の処理が実行され、ＲＤＢＭ
Ｓ部１２２による共有ディスク３への遅延書込みが実行
される。

【００８８】実施の形態７．この実施の形態７では、ク
ライアント２が複数のレコードを運用系サーバ１１に一
括して書き込むリクエストを発行した場合において、運
用系と待機系の各サーバ１１，１２が遅延書き込みを行
う処理について説明する。なお、この実施の形態７のク
ライアントサーバ制御システムおける全体構成は、図５
に示したものと基本的に同じである。

【００８９】まず、運用系サーバ１１に何ら障害が発生
することなく正常に実行運用される場合の処理につい
て、図９に示すフローチャートを参照して説明する。運
用系サーバ１１においてクライアント２から複数レコー
ドの一括書き込みリクエストを受信すると、二重書き管
理部１１５は高速ファイルシステム１１６に１レコード
目から順に書き込みを行う（ステップＡ２）。また、運
用系サーバ１１は、待機系サーバ１２にもこの一括書き
込みリクエストを転送するので、待機系サーバ１２の二
重書き管理部１２５は、この転送された一括書き込みリ
クエストに応じて、同様に高速ファイルシステム１２６
に書き込みを行う(ステップＢ０)。運用系サーバ１１
は、全てのレコードの書き込みが完了すると、クライア
ント２に対して書き込み完了を通知する（ステップＡ
３）。

【００９０】運用系サーバ１１は、高速ファイルシステ
ム１１６に全てのレコードが格納されると、共有ディス
ク３への遅延書き込みを開始するために、まず、遅延書
き込みリクエストを待機系サーバ１２にも転送する(ス
テップＡ４)。待機系サーバ１２は、この転送されてき
た遅延書き込みリクエストを受信すると(ステップＢ
１)、ＲＤＢＭＳ部１２２による共有ディスク３への遅
延書き込み要求を一旦キューイングする（ステップＢ
３）。

【００９１】運用系サーバ１１は、ステップＡ４の後、
ＲＤＢＭＳ部１１２に共有ディスク３への遅延書き込み
要求を行い(ステップＡ５)、レコードごとに順次遅延書
き込みを開始する。ＲＤＢＭＳ部１１２は、トランザク
ションをサポートしていて、ステップＡ５の遅延書き込
み要求に応じて共有ディスク３に対して１レコード目か
ら順にインサートしていくが、全てのレコードをインサ
ートした後、ＣＯＭＭＩＴコマンドを発行して、ＲＤＢ
ＭＳ部１１２の共有ディスク３への書き込みを確定させ
る。ＲＤＢＭＳ部１１２の共有ディスク３への遅延書き
込みが完了すると、その旨を待機系サーバ１２に対して
ＬＡＮたとえば４１を介して通知する（ステップＡ
６）。待機系サーバ１２は、運用系サーバ１１からのこ
の遅延書き込み完了通知を受け取ると、先のステップＢ
３でキューイングしていた遅延書き込み要求を破棄する
（ステップＢ４）。

【００９２】次に、運用系サーバ１１が遅延書き込みの
途中で何らかの要因で重故障になり、ＲＤＢＭＳ部１１
２による共有ディスク３への遅延書き込みが完了できな
かった場合の処理について、図１０に示すフローチャー
トを参照して説明する。

【００９３】運用系サーバ１１におけるステップＡ２〜
Ａ４、待機系サーバ１２におけるステップＢ０，Ｂ１，
Ｂ３は、図９のフローチャートで示した処理と同じであ
る。すなわち、待機系サーバ１２は、運用系サーバ１１
から転送された遅延書き込みリクエストを受信した後
(ステップＢ１)、ＲＤＢＭＳ部１２２への遅延書き込み
要求を一旦キューイングし（ステップＢ３）、運用系サ
ーバ１１からの遅延書き込み完了通知を待ち受けてい
る。

【００９４】運用系サーバ１１において、共有ディスク
３に対して全レコードの格納を完了してＣＯＭＭＩＴコ
マンドを発行するまでに至らない途中の時点（ここでは
一例として２レコード分のデータを格納しただけの時
点）で重故障が発生した場合、運用系サーバ１１からは
待機系サーバ１２に対して一定期間を経過しても遅延書
き込み完了通知が発信されないので、待機系サーバ１２
の構成制御管理部１２１は、運用系サーバ１１に重故障
が発生したものと判断して、待機系サーバ１２を運用系
に切り替える（ステップＢ３１）。そして、ＲＤＢＭＳ
部１２２を立ち上げる（ステップＢ３２）。その際、旧
運用系サーバ１１側のトランザクションの途中までしか
遅延書き込みが実施されていないので（ここでは２レコ
ード目まででしか実行されていない）、まず、ロールフ
ォワード処理を行う（ステップＢ３３）。次いで、ステ
ップＢ３でキューイングしていたＲＤＢＭＳ部１２２に
よる共有ディスク３への遅延書き込み要求を取り出し
（ステップＢ３４）、１レコード目から順にインサート
を行い最後にＣＯＭＭＩＴを発信し、ＲＤＢＭＳ部１２
２の共有ディスク３への書込みが完了する（ステップＢ
３５）。

【００９５】以上のように、この実施の形態７では、ク
ライアント２からの複数のレコードの一括書き込み要求
に応じて、運用系サーバ１１がトランザクションをサポ
ートしつつ、レコード単位で遅延書き込みを行っている
途中で何らかの障害が発生した場合には、待機系のサー
バ１２はトランザクションによりロールフォワド処理す
るので、運用系サーバ１１から待機系サーバ１２へレコ
ード単位の遅延書き込み処理を円滑に引き継ぐことが可
能になる。

【００９６】実施の形態８．この実施の形態８では、ク
ライアント２が複数のテーブルを運用系サーバ１１に一
括して書き込むリクエストを発行した場合において、運
用系と待機系の各サーバ１１，１２が遅延書き込みを行
う処理について説明する。なお、この実施の形態８のク
ライアントサーバ制御システムおける全体構成は、図５
に示したものと基本的に同じである。

【００９７】まず、運用系サーバ１１に何ら障害が発生
することなく正常に実行運用される場合の処理を図１１
のフローチャートに示す。図９に示した実施の形態７に
おける正常な運用時のフローチャートと比較すると容易
に分かるように、この実施の形態８の場合、運用系サー
バ１１および待機系サーバ１２がテーブル単位でデータ
を取り扱う以外は、図９に示したレコード単位でデータ
を格納する場合と基本的な処理動作は同じである。した
がって、ここでは詳しい説明は省略する。

【００９８】次に、ＲＤＢＭＳ部への遅延書込み中に何
らかの要因により重故障になってしまった場合の処理を
図１２のフローチャートに示す。図１０に示した実施の
形態７における重故障発生時のフローチャートと比較す
ると容易に分かるように、この実施の形態８の場合、運
用系サーバ１１および待機系サーバ１２がテーブル単位
でデータを取り扱う以外は、図１０に示したレコード単
位でデータを格納する場合と基本的な処理動作は同じで
ある。したがって、ここでは詳しい説明は省略する。

【００９９】以上のように、この実施の形態８では、ク
ライアント２からの複数テーブルの一括書込み要求に応
じて、運用系サーバ１１がテーブル単位で遅延書き込み
を行っている途中で何らかの障害が発生した場合には、
待機系のサーバ１２はトランザクションによりロールフ
ォワド処理するので、運用系サーバ１１から待機系サー
バ１２へのテーブル単位の遅延書き込み処理を円滑に引
き継ぐことが可能になる。

【０１００】実施の形態９．図１３は、本発明の実施の
形態９に係るクライアントサーバ制御システムの全体構
成を示すブロック図であり、図５に示した実施の形態５
の構成と対応する部分には同一の符号を付す。

【０１０１】この実施の形態９において、実施の形態５
の構成と異なる点は、運用系と待機系の各サーバ１１，
１２の高速ファイルシステム１１６，１２６をＤＲＡＭ
のような揮発性の半導体記憶装置に代えて、不揮発性記
憶装置（たとえばＨＤＤ）にしたことである。その他の
構成は図５に示したものと基本的に同じであるから、こ
こでは詳しい説明は省略する。

【０１０２】高速ファイルシステム１１６，１２６を不
揮発性記憶装置にすることにより、たとえば、運用系サ
ーバ１１に障害が発生して使用不能になり、待機系サー
バ１２が単独で新たな運用系として動作している場合
に、さらに、このサーバ１２において、ＲＤＢＭＳ部１
２２により共有ディスク３への遅延書込みが完了する前
に、何らかの要因で重故障になって両サーバ１１，１２
が共にダウンした場合にも、少なくとも一方のサーバ１
２の高速ファイルシステム１２６にはデータがそのまま
保存されていて消失は免れる。

【０１０３】以上のように、この実施の形態９によれ
ば、たとえば、一方のサーバ１２の重故障の要因が取り
除かれて、サーバ１２を再び立ち上げた後に、不揮発性
の高速ファイルシステム１２６に残っているデータを読
み出して遅延書き込み要求を再開すれば、クライアント
２からの要求に応じてＲＤＢＭＳ部１２２によって共有
ディスク３に遅延書き込みを行うことができるようにな
る。

【０１０４】実施の形態１０．この実施の形態１０で
は、図１３に示した構成のクライアントサーバ制御シス
テムにおいて、運用系サーバ１１のＲＤＢＭＳ部１１２
により共有ディスク３に遅延書き込みを行っている途中
で、ＲＤＢＭＳ部１１２自身に障害が発生した場合の処
理について、図１４に示すフローチャートを参照して説
明する。

【０１０５】まず、運用系サーバ１１においてクライア
ント２からの書き込みリクエストを受信すると、二重書
き管理部１１５は、高速ファイルシステム１１６に書き
込みを行う（ステップＡ２）。運用系サーバ１１は、待
機系サーバ１２にもこの書き込みリクエストを転送する
ので、待機系サーバ１２は、この転送された書き込みリ
クエストに応じて、同様に高速ファイルシステム１２６
に書き込みを行う（ステップＢ０）。運用系サーバ１１
は、高速ファイルシステム１１６への書き込みが完了す
ると、クライアント２に対してこの時点で完了通知を行
う（ステップＡ３）。

【０１０６】運用系サーバ１１は、高速ファイルシステ
ム１１６にデータが格納されると、その後、ＲＤＢＭＳ
部１１２による共有ディスク３への遅延書き込みを開始
するために、待機系サーバ１２に対して遅延書き込みリ
クエストを転送する(ステップＡ４)。待機系サーバ１２
は、運用系サーバ１１からの遅延書き込みリクエストを
受信すると(ステップＢ１)、ＲＤＢＭＳ部１２２による
共有ディスク３への遅延書込み要求を一旦キューイング
する（ステップＢ３）。

【０１０７】運用系サーバ１１は、ステップＡ４の処理
後、ＲＤＢＭＳ部１１２による共有ディスク３への遅延
書き込みを開始しようとするが、構成制御管理部１１１
がＲＤＢＭＳ部１２２の故障を検知すると、遅延書き込
み要求をキューイングする(ステップＡ５１)。

【０１０８】その後、運用系サーバ１１のＲＤＢＭＳ部
１１２が復旧されて、構成制御管理部１１１がＤＢ制御
部１１３によりＲＤＢＭＳ部１１２が起動されるのを検
知すると(ステップＡ５２)、遅延書き込みリクエストを
デキューし(ステップＡ５３)、ＲＤＢＭＳ部１１２が共
有ディスク３への遅延書き込みを行う。遅延書き込みが
完了すると、その旨を待機系サーバに通知する（ステッ
プＡ５４）。

【０１０９】一方、待機系サーバ１２は、ステップＢ３
で遅延書き込み要求を一旦キューイングしていても、運
用系サーバ１１から一定期間内に遅延書き込み完了通知
が来ないとタイムアウトが発生するが、待機系サーバ１
２は、運用系サーバ１１の障害発生を検知すると、遅延
書き込み要求はデキューせずにキュー状態をそのまま保
持する(ステップＢ５１)。そして、運用系サーバ１１の
ＲＤＢＭＳ部１１２が復旧して運用系サーバ１１から遅
延書き込み完了通知を受け取ると、キュー状態を保持し
ていた遅延書き込み要求を破棄する（ステップＢ５
２）。

【０１１０】なお、運用系サーバ１１において遅延書き
込みの途中で重故障が生じたときには、実施の形態６
（図７参照）で説明した通り、待機系サーバ１２が運用
系に切り替わって、そのＲＤＢＭＳ部１２２による共有
ディスク３への遅延書き込みが円滑に引き継がれる。

【０１１１】以上のように、この実施の形態１０によれ
ば、運用系サーバ１１のＲＤＢＭＳ部１１２が何らかの
要因で故障して動作しない場合でも、クライアント２か
らの書込み要求を受け付け、ＲＤＢＭＳ部１１２が復旧
した後は、復旧したＲＤＢＭＳ部１１２により共有ディ
スク３への遅延書き込みを円滑に行うことができる。

【０１１２】実施の形態１１．この実施の形態１１で
は、図１３に示した構成のクライアントサーバ制御シス
テムにおいて、運用系サーバ１１のＲＤＢＭＳ部１１２
により共有ディスク３に遅延書き込みを行っている途中
で、共有ディスク３自身に障害が発生した場合の処理に
ついて、図１５に示すフローチャートを参照して説明す
る。

【０１１３】運用系サーバ１１におけるステップＡ２〜
Ａ４、待機系サーバ１２におけるステップＢ０，Ｂ１，
Ｂ３は、図１４のフローチャートで示した処理と同じで
ある。すなわち、待機系サーバ１２は、運用系サーバ１
１から転送された遅延書き込みリクエストを受信した後
(ステップＢ１)、ＲＤＢＭＳ部１２２への遅延書き込み
要求を一旦キューイングし（ステップＢ３）、運用系サ
ーバ１１からの遅延書き込み完了通知を待ち受けてい
る。

【０１１４】運用系サーバ１１は、ステップＡ４の処理
後、構成制御管理部１１１が共有ディスク３の故障を検
知すると、遅延書き込み要求をキューイングする(ステ
ップＡ６１)。その後、共有ディスク３が復旧されて、
ＤＢ制御部１１３がＲＤＢＭＳ部１１２が起動されるの
を検知すると(ステップＡ６２)、遅延書き込みリクエス
トをデキューし(ステップＡ６３)、ＲＤＢＭＳ部１１２
が共有ディスク３への遅延書き込みを行う。遅延書き込
みが完了すると、その旨を待機系サーバ１２に通知する
（ステップＡ６４）。

【０１１５】待機系サーバ１２は、ステップＢ３で遅延
書き込み要求を一旦キューイングしていても、運用系サ
ーバ１１から一定期間内に遅延書き込み完了通知が来な
いとタイムアウトが発生するが、待機系サーバ１２は、
共有ディスク３の障害発生を検知すると、遅延書き込み
要求はデキューせずにキュー状態をそのまま保持する
(ステップＢ６１)。そして、共有ディスク３が復旧して
運用系サーバ１１から遅延書き込み完了通知を受け取る
と、キュー状態を保持していた遅延書き込み要求を破棄
する（ステップＢ６２）。なお、運用系サーバ１１にお
いて遅延書き込みの途中で重故障が生じたときには、実
施の形態６（図７参照）で説明した通り、待機系サーバ
１２が運用系に切り替わって、そのＲＤＢＭＳ部１２２
による共有ディスク３への遅延書き込みが円滑に引き継
がれる。

【０１１６】以上のように、この実施の形態１１によれ
ば、共有ディスク３が何らかの要因で故障して動作して
いない場合でも、クライアント２からの書き込み要求を
受け付け、共有ディスク３が復旧した後は、運用系サー
バ１１のＲＤＢＭＳ部１１２により復旧した共有ディス
ク３への遅延書き込みが円滑に行われる。

【０１１７】実施の形態１２．共有ディスク３に格納さ
れているデータが不意に破壊されないようにするために
は、フロッピディスクや磁気テープなどの補助記録装置
に保存しておくことが好ましい。そこで、この実施の形
態１２では、運用系サーバ１１のＲＤＢＭＳ部１１２に
よる共有ディスク３への遅延書き込みを一時的に停止し
て、バックアップ処理する場合の動作について、図１６
に示すフローチャートを参照して説明する。

【０１１８】この実施の形態１２の場合において、運用
系サーバ１１のＲＤＢＭＳ部１１２による共有ディスク
３への遅延書き込みを一時的に停止してバックアップ処
理する期間中の状態は、運用系と待機系の各サーバ１
１，１２が共有ディスク３の故障として取り扱うのと類
似の状態になっている。したがって、図１６に示すこの
実施の形態１２のバックアップ処理のフローチャート
は、図１５に示した実施の形態１１におけるフローチャ
ートと比較すると容易に分かるように、『共有ディスク
２の故障』を『バックアップ』の用語に置き換えたにす
ぎず、実施の形態１１の場合と基本的に同じ処理内容に
なる。

【０１１９】なお、運用系サーバ１１においてバックア
ップ処理の途中で重故障が生じたときには、実施の形態
６（図７参照）で説明した通り、待機系サーバ１２が運
用系に切り替わって、そのＲＤＢＭＳ部１２２による共
有ディスク３への遅延書き込みが円滑に引き継がれる。

【０１２０】以上のように、この実施の形態１２によれ
ば、運用系サーバ１１のＲＤＢＭＳ部１１２による共有
ディスク３への遅延書き込みを一時的に停止して、バッ
クアップ処理する場合でも、クライアント２からの書き
込み要求を受け付け、バックアップ完了後は、運用系サ
ーバ１１のＲＤＢＭＳ部１１２により共有ディスク３へ
の遅延書き込みが円滑に行われる。

【０１２１】

【発明の効果】請求項１記載の発明によれば、運用系と
待機系の各サーバおよびクライアントの各構成制御管理
部が互いの状態を常時監視し、障害発生時には、クライ
アント側がその障害検知に応じて、新たに運用系となる
サーバを選択するようになるので、クライアントからの
共有ディスクへのアクセスリクエストは最短の経路でサ
ーバに受け付けられることになり、クライアントからの
リクエストの応答性が高まる。

【０１２２】しかも、運用系サーバは、従来のように故
障発生時に備えて引き継ぎ情報を共有ディスクに保管し
ておく必要がなく、また、障害発生時に運用系サーバで
記録された途中処理情報を待機系サーバ側に転送する必
要もないので、運用系サーバで未処理のデータも待機系
サーバに迅速かつ円滑に引き継ぐことができる。

【０１２３】請求項２記載の発明によれば、クライアン
トや運用系と待機系の各サーバのそれぞれに通信回線の
状態を監視する手段を設けているので、請求項１記載の
効果に加えて、常にに最適な通信回線を選択してクライ
アントとサーバ間を接続することができる。

【０１２４】請求項３記載の発明によれば、運用系／待
機系のモードだけでなく他の運転モード（試験モードや
訓練モードなど）においてもクライアントがサーバを経
由して共有ディスクのデータベースに対してアクセスで
きるようになる。したがって、サーバを運転モード毎に
予め設ける必要がなく兼用できるため、資源を有効に活
用することができる。

【０１２５】請求項４記載の発明によれば、運用系と待
機系の各サーバに高速ファイルシステムを設けているの
で、請求項１ないし請求項３記載の発明の効果に加え
て、クライアントからのデータのリアルタイム性が要求
される場合でも、迅速かつ確実に運用系サーバの高速フ
ァイルシステムにデータを格納できるようになる。

【０１２６】請求項５記載の発明によれば、クライアン
トからデータのリアルタイム性が要求される場合でも、
サーバが十分にその要求を保証することができるととも
に、一旦、高速ファイルシステムに保存したデータを非
同期で共有ディスクに遅延書き込みを行うため、高速フ
ァイルシステムと共有ディスクの双方の負担を軽減する
ことができる。

【０１２７】請求項６記載の発明によれば、請求項５の
効果に加えて、運用系サーバが遅延書き込みの途中で重
故障が生じた場合でも、待機系サーバ側で共有ディスク
への遅延書き込みを保証することが可能になる。また、
遅延書き込みを行っている途中で通信回線に障害が発生
した場合にも円滑に対処することができる。

【０１２８】請求項７記載の発明によれば、クライアン
トからの書き込み要求に応じて、運用系サーバが共有デ
ィスクにレコード単位で遅延書き込みを行っている途中
で何らかの障害が発生した場合でも、運用系と待機系の
各サーバのトランザクションにより処理するので、待機
系サーバがレコード単位の遅延書き込み処理を円滑に引
き継ぐことが可能になる。

【０１２９】請求項８記載の発明によれば、クライアン
トからの書き込み要求に応じて、運用系サーバが共有デ
ィスクにテーブル単位で遅延書き込みを行っている途中
で何らかの障害が発生した場合でも、運用系と待機系の
各サーバのトランザクションにより処理するので、待機
系サーバがテーブル単位の遅延書き込み処理を円滑に引
き継ぐことが可能になる。

【０１３０】請求項９記載の発明によれば、高速ファイ
ルシステムを不揮発性の記憶媒体で構成しているので、
運用系の障害により待機系サーバが新たな運用系となっ
て遅延書き込みを行っている途中でさらに重ねて待機系
サーバに障害が発生した場合でも、高速ファイルシステ
ムにはデータが確実に残っているので、サーバの復旧後
は不揮発性の高速ファイルシステムに残っているデータ
を読み出して遅延書き込みを行うことが可能になる。

【０１３１】請求項１０記載の発明によれば、運用系サ
ーバのＲＤＢＭＳ部が何らかの要因で故障して動作しな
い場合でも、クライアントからの書き込み要求を受け付
けることができ、ＲＤＢＭＳ部が復旧した後は、復旧し
たＲＤＢＭＳ部により共有ディスクへの遅延書き込みを
円滑に行うことができる。

【０１３２】請求項１１記載の発明によれば、共有ディ
スクが何らかの要因で故障して動作しない場合でも、ク
ライアントからの書き込み要求を受け付けることがで
き、共有ディスクが復旧した後は、運用系サーバのＲＤ
ＢＭＳ部により復旧した共有ディスクへの遅延書き込み
が円滑に行われる。

【０１３３】請求項１２記載の発明では、運用系サーバ
で共有ディスクへの遅延書き込みを一時的に停止してバ
ックアップ処理する場合でも、クライアントからの書き
込み要求を受け付けることができ、バックアップ完了後
は、運用系サーバにより共有ディスクへの遅延書き込み
が円滑に行われる。

【図面の簡単な説明】

【図１】本発明の実施の形態１に係るクライアントサ
ーバ制御システムの全体構成を示すブロック図である。

【図２】本発明の実施の形態２に係るクライアントサ
ーバ制御システムの全体構成を示すブロック図である。

【図３】本発明の実施の形態３に係るクライアントサ
ーバ制御システムにおける共有ディスクのデータベース
の格納状態を示す説明図である。

【図４】本発明の実施の形態４に係るクライアントサ
ーバ制御システムの全体構成を示すブロック図である。

【図５】本発明の実施の形態５に係るクライアントサ
ーバ制御システムの全体構成を示すブロック図である。

【図６】本発明の実施の形態６に係るクライアントサ
ーバ制御システムにおいて、運用系サーバが正常に運用
されている場合の遅延書き込み動作を示すフローチャー
トである。

【図７】本発明の実施の形態６に係るクライアントサ
ーバ制御システムにおいて、運用系サーバが遅延書込み
の途中で障害が発生した場合の動作を示すフローチャー
トである。

【図８】本発明の実施の形態６に係るクライアントサ
ーバ制御システムにおいて、運用系サーバが遅延書込み
の途中で通信回線等の故障により遅延書込み完了通知エ
ラーが生じた場合の動作を示すフローチャートである。

【図９】本発明の実施の形態７に係るクライアントサ
ーバ制御システムにおいて、運用系サーバが正常に運用
されている場合のレコード単位で遅延書き込みを行う場
合の動作を示すフローチャートである。

【図１０】本発明の実施の形態７に係るクライアント
サーバ制御システムにおいて、運用系サーバがレコード
単位で遅延書込みを行っている途中で障害が発生した場
合の動作を示すフローチャートである。

【図１１】本発明の実施の形態８に係るクライアント
サーバ制御システムにおいて、運用系サーバが正常に運
用されている場合のテーブル単位で遅延書き込みを行う
場合の動作を示すフローチャートである。

【図１２】本発明の実施の形態８に係るクライアント
サーバ制御システムにおいて、運用系サーバがテーブル
単位で遅延書込みを行っている途中で障害が発生した場
合の動作を示すフローチャートである。

【図１３】本発明の実施の形態９に係るクライアント
サーバ制御システムの全体構成を示すブロック図であ
る。

【図１４】本発明の実施の形態１０に係るクライアン
トサーバ制御システムにおいて、運用系サーバが遅延書
込みを行っている途中でＲＤＢＭＳ部に故障が生じた場
合の動作を示すフローチャートである。

【図１５】本発明の実施の形態１１に係るクライアン
トサーバ制御システムにおいて、運用系サーバが遅延書
込みを行っている途中で共有ディスクに故障が生じた場
合の動作を示すフローチャートである。

【図１６】本発明の実施の形態１２に係るクライアン
トサーバ制御システムにおいて、運用系サーバの遅延書
込みを中断してバックアップ処理を行う場合の動作を示
すフローチャートである。

【図１７】従来のクライアントサーバ制御システムの
全体構成を示すブロック図である。

【符号の説明】

２クライアント、３共有ディスク、４ＬＡＮ（通
信回線）、１１サーバ、１２サーバ、２０運転モ
ード管理部、２１構成制御管理部、２２サーバ接続
部、２３アプリケーション実行部、２５ＤＢ切替
部、２６クライアント側ＤＢ変換部、２７クライア
ント側ＤＢ変換テーブル、４１，４２ＬＡＮ（通信回
線）、１１０運転モード管理部、１１１構成制御管
理部、１１２ＲＤＢＭＳ部、１１３ＤＢ制御部、１
１４ＬＡＮ監視部、１１５二重書き管理部、１１６
高速ファイルシステム、１１７サーバ側変換部、１
１８サーバ側ＤＢ変換テーブル、１２０運転モード管
理部、１２１構成制御管理部、１２２ＲＤＢＭＳ
部、１２３ＤＢ制御部、１２４ＬＡＮ監視部、１２
５二重書き管理部、１２６高速ファイルシステム、
１２７サーバ側変換部、１２８サーバ側ＤＢ変換テ
ーブル。

───────────────────────────────────────────────────── フロントページの続きＦターム(参考） 5B034 BB02 BB17 CC01 DD02 5B045 JJ01 JJ16 JJ22 JJ44 JJ46 JJ48 5B083 AA08 BB02 BB03 CC04 CD11 CE01 DD09 EE02 EE06 EE08 5B085 AA03 AC11 AC16 BA07 5B089 GA12 GA21 JB17 KA12 MD02 MD03 ME02 ME04 ME09 ME15

Claims

【特許請求の範囲】

【請求項１】リクエストを発信するクライアントと、
このクライアントからのリクエストに応じた処理を実行
運用する運用系サーバと、この運用系サーバの処理を代
替する待機系サーバとを有し、前記クライアントおよび
各サーバが通信回線を介して互いに接続され、かつ、前
記各サーバには、同一の共有ディスクに対してアクセス
を行うＲＤＢＭＳ部が設けられているクライアントサー
バ制御システムにおいて、前記クライアントには、各サーバが運用系か待機系かを
識別するための運転モード情報を管理する運転モード管
理部と、各サーバの障害発生の有無を検知する構成制御
管理部と、前記運転モード管理部による運転モード情報
および前記構成制御管理部による障害検知情報に基づい
て接続すべきサーバを決定して当該サーバに接続するサ
ーバ接続部とが設けられる一方、前記各サーバには、当
該サーバが運用系か待機系かを識別するための運転モー
ド情報を管理する運転モード管理部と、自己を含む各サ
ーバの障害発生の有無を検知するとともに自己の障害発
生時には他のサーバおよび前記クライアントに障害発生
を通知する構成制御管理部とが設けられていることを特
徴とするクライアントサーバ制御システム。
【請求項２】前記クライアントと各サーバとを接続す
る前記通信回線は複数設けられる一方、前記クライアン
トおよび各サーバには、前記各通信回線の状態を監視
し、通信回線が故障した場合には最適の通信回線を決定
する通信管理部が設けられていることを特徴とする請求
項１記載のクライアントサーバ制御システム。
【請求項３】前記運転モード管理部は、各サーバが運
用系か待機系かを識別する情報に加えてその他の運転モ
ードの情報も同時に管理するものである一方、前記クラ
イアントのサーバ接続部は、その運転モード管理部で管
理されている前記運転モード情報に基づいて、リクエス
トされた運転モードに適合したサーバを決定するもので
あることを特徴とする請求項１または請求項２に記載の
クライアントサーバ制御システム。
【請求項４】前記実行系と待機系の各サーバには、デ
ータの高速アクセスが可能な高速ファイルシステムと、
この高速ファイルシステムに対するデータの書き込み制
御を行う二重書き管理部とが設けられる一方、前記クラ
イアントには、高速書き込みリクエストに応じて、前記
共有ディスクに書き込まれるべきデータを前記高速ファ
イルシステムに格納するのに適合したデータ構造へデー
タ変換するクライアント側ＤＢ変換部が設けられている
ことを特徴とする請求項１ないし請求項３のいずれか１
項に記載のクライアントサーバ制御システム。
【請求項５】前記実行系と待機系の各サーバには、前
記高速ファイルシステムに格納されたデータを前記共有
ディスクに保存すべきデータ構造に変換して前記ＲＤＢ
ＭＳ部に引き渡すサーバ側ＤＢ変換部が設けられている
ことを特徴とする請求項４記載のクライアントサーバ制
御システム。
【請求項６】前記待機系サーバは、前記運用系サーバ
による共有ディスクへのデータ格納が完了するまでは、
共有ディスクに対するデータ書き込み要求を一定時間保
持するものであることを特徴とする請求項５記載のクラ
イアントサーバ制御システム。
【請求項７】前記高速ファイルシステムから前記共有
ディスクへ書き込み転送するデータは、レコード単位で
行うものであることを特徴とする請求項５または請求項
６に記載のクライアントサーバ制御システム。
【請求項８】前記高速ファイルシステムから前記共有
ディスクへ書き込み転送するデータは、テーブル単位で
行うものであることを特徴とする請求項５または請求項
６に記載のクライアントサーバ制御システム。
【請求項９】前記高速ファイルシステムは、不揮発性
の記憶媒体で構成されていることを特徴とする請求項４
ないし請求項８のいずれか１項に記載のクライアントサ
ーバ制御システム。
【請求項１０】前記待機系サーバは、前記運用系サー
バのＲＤＢＭＳ部の故障が回復するまでは、共有ディス
クに対するデータ書き込み要求を保持するものであるこ
とを特徴とする請求項５ないし請求項９のいずれか１項
に記載のクライアントサーバ制御システム。
【請求項１１】前記待機系サーバは、前記共有ディス
クの故障が回復するまでは、共有ディスクに対するデー
タ書き込み要求を保持するものであることを特徴とする
請求項５ないし請求項９のいずれか１項に記載のクライ
アントサーバ制御システム。
【請求項１２】前記待機系サーバは、運用系サーバ部
によるバックアップ処理が終了するまでは、共有ディス
クに対するデータ書き込み要求を保持するものであるこ
とを特徴とする請求項５ないし請求項９のいずれか１項
に記載のクライアントサーバ制御システム。