JP2007179310A - フェイルオーバ方法、フェイルオーバプログラム、および、クラスタシステム - Google Patents

Abstract

【課題】クラスタシステムにおいて、システムの稼動停止時間をより短縮し、より高い可用性を確保する。
【解決手段】複数のサーバを備えるクラスタシステムのフェイルオーバ方法であって、各サーバ３Ａ、３Ｂには、当該サーバが更新する自データベースと、他サーバが更新する他データベースのバックアップデータベースとが格納されたディスクがマウントされ、各サーバ３Ａ、３Ｂは、他サーバで発生した障害を検知する障害検知ステップと、データ検索時にアクセスするビューを、自データベースと他データベースとを結合した正常時ビューから、前記自データベースと前記バックアップデータベースとを結合したフェイルオーバ時ビューに切り替える切替ステップと、を行う。
【選択図】図１

Description

本発明は、クラスタシステムにおけるフェイルオーバ技術に関する。

サーバ（コンピュータ）に障害が発生した場合、代替サーバが処理やデータを引き継ぐフェイルオーバ技術がある。また、フェイルオーバ技術を適用したクラスタシステムは、複数のサーバによってシステムを冗長化したものである。

なお、フェイルオーバについては、例えば、非特許文献１に記載されている。
"フェイルオーバの仕組みと問題点"、[online]、［２００５年１１月２４日検索］、インターネット＜ＵＲＬ：http://www.atmarkit.co.jp/flinux/rensai/cluster02/cluster02.html＞

さて、インターネットや電子商取引の普及などに伴い、コンピュータシステムの連続稼動が求められている。連続稼動を実現するためにハードウェアを多重化した無停止サーバが存在する。無停止サーバは、システムを停止させることなく障害部位の修理が可能なため、連続稼動を実現することができるが、コストが非常に高い。

また、一般的なフェイルオーバ技術を適用したクラスタシステムでは、障害発生時にリソースの引き継ぎが必要となる。例えば、リソースの１つであるデータを引き継ぐ場合、障害が発生したサーバにマウントされているディスクを、正常な代替サーバからマウントし直す必要がある。このようなリソースの引継ぎには所定の時間を要するため、システムの稼動停止時間（ダウンタイム）が発生してしまう。

本発明は上記事情に鑑みてなされたものであり、本発明の目的は、システムの稼動停止時間をより短縮し、より高い可用性を確保することにある。

上記課題を解決するために、本発明では、例えば、複数のサーバを備えるクラスタシステムのフェイルオーバ方法であって、前記各サーバには、当該サーバが更新する自データベースと、他サーバが更新する他データベースのバックアップデータベースとが格納されたディスクがマウントされ、前記各サーバは、他サーバで発生した障害を検知する障害検知ステップと、データ検索時にアクセスするビューを、自データベースと他データベースとを結合した正常時ビューから、前記自データベースと前記バックアップデータベースとを結合したフェイルオーバ時ビューに切り替える切替ステップと、を行う。

本発明では、システムの稼動停止時間をより短縮し、より高い可用性を確保することができる。

以下、本発明の実施の形態について説明する。

図１は、本発明の一実施形態が適用されたシステムの全体構成図である。本実施形態のシステムは、端末１と、負荷分散装置（load balancer）２と、複数のサーバ３Ａ、３Ｂおよび共用ディスク４を備えたクラスタシステムと、を有する。クラスタシステムは、複数のコンピュータを一群にまとめて、信頼性や処理性能の向上を図るシステムである。本実施形態のクラスタシステムは、各端末１からの要求を処理するために、サーバ１号機３Ａおよびサーバ２号機３Ｂの２台のサーバを冗長化させている。なお、各端末１は、インターネットなどのネットワーク９および負荷分散装置２を介して、いずれかのサーバ３Ａ、３Ｂに接続することができる。

端末１は、ユーザが入力した各種の要求を受け付け、受け付けた要求をネットワーク９を介して負荷分散装置２に送信する。負荷分散装置２は、各端末１からの要求をサーバ１号機３Ａまたはサーバ２号機３Ｂに振り分け、各サーバの負荷を分散させる。

サーバ１号機３Ａおよびサーバ２号機３Ｂには、共用ディスク４が接続されている。そして、共用ディスク４は、サーバ１号機３Ａ用のパーティション（以下、「１号機用ディスク」）４Ａと、サーバ２号機３Ｂ用のパーティション（以下、「２号機用ディスク」）４Ｂと、に分割されているものとする。

なお、いずれのサーバにも障害が発生していない正常運用時においては、サーバ１号機３Ａは１号機用ディスク４Ａをマウントし、サーバ２号機３Ｂは２号機用ディスク４Ｂをマウントしている。すなわち、１号機用ディスク４Ａは、サーバ１号機３Ａ上で認識され、サーバ１号機３Ａからアクセス可能なように接続されている。また、２号機用ディスク４Ｂは、サーバ２号機３Ｂ上で認識され、サーバ２号機３Ｂからアクセス可能なように接続されている。

サーバ１号機３Ａおよびサーバ２号機３Ｂは、業務処理部３１と、受信部３２と、状態監視部３３と、フェイルオーバ処理部３４と、ＭＱ通信部３５とをそれぞれ有する。業務処理部３１は、端末１の要求に応じて所定の業務処理を行い、データベースに対して所定のアクセス要求を生成する。アクセス要求には、データの書き込み要求（write要求）、データの読み出し要求（read要求）などが含まれる。

受信部３２は、メッセージキューイング（ＭＱ：message queueing）方式を用いて受信したデータを、バックアップテーブル４２Ａ、４２Ｂに書き込む。状態監視部３３は、他サーバの状態を監視し、他サーバで発生した障害を検知する。本実施形態では、サーバ１号機３Ａおよびサーバ２号機３Ｂの状態監視部３３は、ハートビートの送受信を行うことにより、相互に状態を監視するものとする。

例えば、状態監視部３３は、ハートビートの応答の有無により、相手サーバの死活監視を行うことが考えられる。また、状態監視部３３は、自サーバの稼動状態を監視する運用監視エージェント機能を有し、ハートビート等のメッセージに自サーバの稼動状態（ＣＰＵ利用率、メモリ使用量、自サーバ内の障害など）を相手サーバに送信することとしてもよい。また、本実施形態のクラスタシステムは障害監視サーバ（不図示）を備え、障害監視サーバが各サーバの稼動状態を監視し、障害を検知することとしてもよい。

フェイルオーバ処理部３４は、障害が発生したサーバの処理やリソースを、正常なサーバに引き継ぐ処理を行う。具体的には、フェイルオーバ処理部３４は、データ検索時にアクセスするビュー（view）を所定のタイミングで切り替えるとともに、ディスクのマウントなどを行う。なお、ビューは、実テーブルから生成される仮想的なテーブルである。また、フェイルオーバ処理部３４については後述する。ＭＱ通信部３５は、図示しない送信キューおよび受信キューを有し、メッセージキューイング方式によりデータを送受信する。

１号機用ディスク４Ａは、１号機用ログテーブル４１Ａと、２号機用バックアップテーブル４２Ａとを有する。１号機用ログテーブル４１Ａは、サーバ１号機３Ａ上で行われた処理の履歴情報（更新データ）を格納するためのデータベースである。すなわち、サーバ１号機３Ａが、１号機用ログテーブル４１Ａにデータを書き込み、更新する。２号機用バックアップテーブル４２Ａは、２号機用ログテーブル４１Ｂのバックアップである。

２号機用ディスク４Ｂは、２号機用ログテーブル４１Ｂと、１号機用バックアップテーブル４２Ｂとを有する。２号機用ログテーブル４１Ｂは、サーバ２号機３Ｂ上で行われた処理の履歴情報（更新データ）を格納するためのデータベースである。すなわち、サーバ２号機３Ｂが、２号機用ログテーブル４１Ｂにデータを書き込み、更新する。１号機用バックアップテーブル４２Ｂは、１号機用ログテーブル４１Ａのバックアップである。

上記説明した端末１および各サーバ３Ａ、３Ｂは、いずれも、例えば図２に示すようなＣＰＵ９０１と、メモリ９０２と、ＨＤＤ等の外部記憶装置９０３と、キーボードやマウスなどの入力装置９０４と、ディスプレイやプリンタなどの出力装置９０５と、ネットワークと接続するための通信制御装置９０６と、を備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵ９０１がメモリ９０２上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。

例えば、端末１およびサーバ３Ａ、３Ｂの各機能は、端末１用のプログラムの場合は端末１のＣＰＵ９０１が、そして、サーバ３Ａ、３Ｂ用のプログラムの場合はサーバ３Ａ、３ＢのＣＰＵ９０１が、それぞれ実行することにより実現される。なお、共用ディスク４は、サーバ１号機３Ａおよびサーバ２号機３Ｂの外部記憶装置９０３である。また、入力装置９０４および出力装置９０５については、各装置が必要に応じて備えるものとする。

次に、サーバ１号機３Ａおよびサーバ２号機３Ｂが、ともに正常に稼動している正常運用時（フェイルオーバ前）の処理について説明する。

図３は、正常運用時の処理を模式的に示した図である。なお、以下に述べる正常運用時の処理はサーバ１号機３Ａを例として説明するが、サーバ２号機３Ｂの処理もサーバ１号機３Ａの処理と同様である。また、正常運用時においては、１号機用ディスク４Ａはサーバ１号機３Ａからマウントされ、２号機用ディスク４Ｂはサーバ２号機３Ｂからマウントされている。

サーバ１号機３Ａの業務処理部３１は、負荷分散装置２を介して端末１の要求を受け付けて所定の業務処理を行い、データベースにアクセスする。すなわち、業務処理部３１は、書き込み要求（write要求）、読み出し要求（read要求）などのアクセス要求を生成し、図示しないデータ管理部（ＤＢＭＳ：DataBase Management System）に送出する。データ管理部は、業務処理部から受け付けたアクセス要求に基づいて、データベースにデータを書き込み、または、データベースからデータを読み出す。

なお、業務処理部３１は、データを書き込む場合は実テーブルである１号機用ログテーブル４１Ａに、また、データを読み出す場合は仮想テーブルであるビュー４３Ａにアクセスするものとする。

まず、データを書き込む場合の処理を説明する。サーバ１号機３Ａの業務処理部３１は、データ管理部を用いて業務処理の結果である更新データを１号機用ログテーブル４１Ａに書き込むとともに、当該更新データを送信キュー４５Ａに書き込む（Ｓ１１）。

そして、ＭＱ通信部３５は、送信キュー４５Ａに書き込まれた更新データを、メッセージキューイング方式により２号機用ディスク４Ｂの受信キュー４６Ｂに送信する（Ｓ１２）。そして、サーバ２号機３Ｂの受信部３２は、受信キュー４６Ｂから更新データを取り出し（Ｓ１３）、取り出した更新データを１号機用バックアップテーブル４２Ｂに書き込む（Ｓ１４）。

このように、１号機用ディスク４Ａの１号機用ログテーブル４１Ａに書き込まれたデータは、メッセージキューイングにより、２号機用ディスク４Ｂの１号機用バックアップテーブル４２Ｂに書き込まれる。すなわち、１号機用バックアップテーブル４２Ｂには、１号機用ログテーブル４１Ａのデータと同じデータが格納される。

次に、データを読み出す場合（データを検索する場合）の処理を説明する。サーバ１号機３Ａの業務処理部３１は、データ管理部を用いて１号機用ディスク４Ａのビュー４３Ａにアクセスし、所定のデータを読み出す（Ｓ２１）。なお、正常運用時のビュー４３Ａは、１号機用ログテーブル４１Ａと、２号機用ディスク４Ｂの２号機用ログテーブル４１Ｂと、を結合した仮想テーブルである。正常運用時のビュー４３Ａのビュー定義情報は、メモリまたは外部記憶装置にあらかじめ記憶されているものとする。

また、２号機用ディスク４Ｂの正常運用時のビュー４３Ｂは、２号機用ログテーブル４１Ｂと、１号機用ディスク４Ａの１号機用ログテーブル４１Ａと、を結合した仮想テーブルである。このビュー４３Ｂのビュー定義情報についても、メモリまたは外部記憶装置にあらかじめ記憶されているものとする。

業務処理部３１がビュー４３Ａにアクセスすることより、データ管理部は、ビュー定義情報を参照し、実テーブルである１号機用ログテーブル４１Ａおよび２号機用ログテーブル４１Ｂにアクセスする。そして、業務処理部３１は、ビュー４３Ａ（すなわち、実テーブル４１Ａ、４１Ｂに格納された全てのデータがマージされた仮想テーブル）の中から、所定のデータを読み出す。

なお、データ管理部は、ビュー４３Ａにアクセスする際に、サーバ２号機３Ｂにマウントされている２号機用ディスク４Ｂの２号機用ログテーブル４１Ｂに対して、ＤＢリンクなどの機能を用いてリモートアクセスする。

このように、データを読み出す際にビュー４３Ａにアクセスすることにより、業務処理部３１は、１号機用ログテーブル４１Ａのデータだけでなく、サーバ２号機３Ｂが更新した２号機用ログテーブル４１Ｂのデータを、取得することができる。また、データを読み出す際にビューにアクセスすることにより、サーバ２号機３Ｂが行った２号機用ログテーブル４１Ｂに対する更新データを、タイムラグを発生させることなく、リアルタイムに取得することができる。

次に、いずれかのサーバに障害が発生し、フェイルオーバ処理を実行中の片寄せ運用時の処理について説明する。フェイルオーバ処理については後述する。

図４は、片寄せ運用時（フェイルオーバ中）の処理を模式的に示した図である。なお、図示する例では、サーバ２号機３Ｂに障害が発生した場合を示している。この場合、フェイルオーバ処理が完了するまで、正常なサーバ１号機３Ａは、サーバ２号機３Ｂからマウントされている２号機用ディスク４Ｂにアクセスすることができない。そのため、サーバ１号機３Ａと１号機用ディスク４Ａに片寄せして、システムを運用する。

サーバ１号機３Ａの業務処理部３１は、負荷分散装置２を介して端末１から送信された要求を受け付け、所定の業務処理を行う。そして、業務処理部３１は、データベースにアクセする。なお、サーバ２号機に障害が発生すると、負荷分散装置２は、端末１からの要求を全てサーバ１号機に送出するものとする。

データを書き込む場合、サーバ１号機３Ａの業務処理部３１は、正常運用時の書き込み処理と同様に、データ管理部を用いて１号機用ログテーブル４１Ａに更新データを書き込むとともに、更新データを送信キュー４５Ａに書き込む（Ｓ３１）。また、サーバ２号機３Ｂの更新データが１号機用ディスク４Ａの受信キュー４６Ａに受信されていた場合、サーバ１号機３Ａの受信部３２は、受信キュー４６Ａから更新データを取り出し（Ｓ３２）、取り出した更新データを２号機用バックアップテーブル４２Ａに書き込む（Ｓ３３）。

データを読み出す場合、サーバ１号機３Ａの業務処理部３１は、データ管理部を用いて１号機用ディスク４Ａのビュー４７Ａにアクセスし、所定のデータを読み出す（Ｓ４１）。なお、片寄せ運用時のビュー４７Ａは、１号機用ディスク４Ａに格納された１号機用ログテーブル４１Ａおよび２号機用バックアップテーブル４２Ａを結合した仮想テーブルである。フェイルオーバ処理部３４は、後述する処理により、正常運用時のビュー４３Ａのビュー定義情報を、上述のビュー４７Ａのビュー定義情報に変更するものとする。

業務処理部３１がデータ管理部を用いてビュー４７Ａにアクセスすることより、データ管理部は、変更後のビュー定義情報を参照し、実テーブルである１号機用ログテーブル４１Ａおよび２号機用バックアップテーブル４２Ａにアクセスする。そして、業務処理部３１は、ビュー４７Ａ（すなわち、実テーブル４１Ａ、４２Ａに格納された全てのデータがマージされた仮想テーブル）の中から、所定のデータを取得する。

片寄せ運用時において、データの書き込み処理については、サーバ１号機３Ａ側で正常運用時と同様に行うことができる。また、データの読み出し処理については、正常運用時のビュー４３Ａから上述のビュー４７Ａに切り替えることにより、サーバ１号機３Ａ側で、サーバ２号機３Ｂの更新データを取得することができる。これにより、フェイルオーバ中であっても、システムを停止することなく、端末に対するサービスを継続することができる。また、業務処理部３１は、アクセスするビューが正常運用時のビュー４３Ａかフェイルオーバ中のビュー４７Ａかを意識することなく、所望のデータを取得することができる。

次に、フェイルオーバ処理が完了した後の処理について説明する。

図５は、フェイルオーバ後の処理を模式的に示した図である。なお、図示する例では、図４と同様にサーバ２号機３Ｂに障害が発生した場合を示している。フェイルオーバが完了したことにより、サーバ２号機３Ｂからマウントされていた２号機用ディスク４Ｂは、サーバ１号機３Ａ上でマウントされ、サーバ１号機３Ａから２号機用ディスク４Ｂへのアクセスが可能となる。

サーバ１号機３Ａの業務処理部３１は、負荷分散装置２を介して端末１から送信された要求を受け付け、所定の業務処理を行う。そして、業務処理部３１は、データベースにアクセスする。データを書き込む場合、サーバ１号機３Ａの業務処理部３１は、正常運用時の書き込み処理と同様に、データ管理部を用いて更新データを１号機用ログテーブル４１Ａに書き込むとともに、更新データを送信キュー４５Ａに書き込む（Ｓ５１）。

そして、ＭＱ通信部３５は、送信キュー４５Ａに書き込まれた更新データを、メッセージキューイング方式により２号機用ディスク４Ｂの受信キュー４６Ｂに送信する（Ｓ５２）。なお、送信キュー４５Ａに書き込まれた更新データには、フェイルオーバ中に書き込まれた更新データも含まれる。そして、フェイルオーバ処理により、サーバ１号機３Ａに引き継がれたサーバ２号機３Ｂの受信部３９は、受信キュー４６Ｂから更新データを取り出し（Ｓ５３）、取り出した更新データを１号機用バックアップテーブル４２Ｂに書き込む（Ｓ５４）。

また、データを読み出す場合、サーバ１号機３Ａの業務処理部３１は、データ管理部を用いてビュー４３Ａにアクセスし、所定のデータを読み出す（Ｓ６１）。なお、フェイルオーバ後のビュー４３Ａは、正常運用時のビュー４３Ａと同じものである。すなわち、１号機用ログテーブル４１Ａと、２号機用ログテーブル４１Ｂとを結合した仮想テーブルである。フェイルオーバ処理部３４は、後述する処理により、フェイルオーバ中のビュー４７Ａのビュー定義情報を、正常運用時のビュー４３Ａのビュー定義情報に変更するものとする。

業務処理部３１がデータ管理部を用いてビュー４３Ａにアクセスすることより、データ管理部は，変更後のビュー定義情報を参照し、実テーブルである１号機用ログテーブル４１Ａおよび２号機用ログテーブル４１Ｂにアクセスする。そして、業務処理部３１は、ビュー４３Ａ（すなわち、実テーブル４１Ａ、４１Ｂに格納された全てのデータがマージされた仮想テーブル）の中から、所定のデータを取得する。

フェイルオーバ後では、データの書き込み処理およびデータの読み込み処理が、サーバ１号機３Ａ側で正常運用時と同様に行うことができる。すなわち、システムを停止することなく、端末１に対するサービスを継続することができる。また、サーバ１号機３Ａ側で、サーバ２号機３Ｂの受信部３９を起動し、サーバ２号機３Ｂの受信処理を行うことにより、１号機用ログテーブル４１Ａと、１号機用バックアップテーブル４２Ｂとデータの同期をとることができる。

次に、フェイルオーバ処理について説明する。

図６は、各サーバが行うフェイルオーバ処理のフローチャートである。なお、以下に述べるフェイルオーバ処理は、サーバ２号機３Ｂに障害が発生し、サーバ１号機３Ａがサーバ２号機の処理およびリソースを引き継ぐ場合を例として説明する。

まず、サーバ１号機３Ａの状態監視部３３は、サーバ２号機３Ｂの状態監視部３３とハートビートを送受信することにより、サーバ２号機３Ｂの状態を監視する。すなわち、状態監視部３３は、ハートビートの応答がない場合、サーバ２号機３Ｂに障害が発生したものと判別する。サーバ２号機３Ｂの障害を検知した場合（Ｓ１０１：ＹＥＳ）、状態監視部３３は、フェイルオーバ処理部３４に、障害が発生したことを通知する。

そして、フェイルオーバ処理部３４は、あらかじめ設定されていた正常運用時のビュー４３Ａを削除する（Ｓ１０２）。そして、フェイルオーバ処理部３４は、フェイルオーバ中のビュー４７Ａを作成する（Ｓ１０３）。これにより、図４に示す片寄せ運用時の処理となる。

なお、ビューを削除する場合、例えば「DROP VEIW」のＳＱＬ文を用いることが考えられる。また、ビューを作成する場合、例えば、「CREATE VIEW」のＳＱＬ文を用いて、ビューの定義情報を設定することが考えられる。

そして、フェイルオーバ処理部３４は、サーバ２号機３Ｂからデータを引き継ぐために、サーバ２号機３Ｂにマウントされている２号機用ディスク４Ｂを、サーバ１号機３Ａにマウントする（Ｓ１０４）。そして、フェイルオーバ処理部３４は、２号機用ディスク４Ｂに格納されているデータベース４１Ｂ、４２Ｂを起動する（Ｓ１０５）。

そして、フェイルオーバ処理部３４は、Ｓ１０３で作成したフェイルオーバ中のビュー４７Ａを削除する（Ｓ１０６）。そして、フェイルオーバ処理部３４は、正常運用時のビュー４３Ａを作成する（Ｓ１０７）。そして、フェイルオーバ処理部３４は、サーバ２号機３Ｂで行っていた処理（アプリケーション）を、サーバ１号機３Ａ上で起動する（Ｓ１０８）。本実施形態では、サーバ２号機３Ｂの受信部３２の処理をサーバ１号機３Ａ上で起動し、メッセージキューイング方式を用いて送信されるサーバ１号機３Ａの更新データを、１号機用バックアップテーブル４２Ｂに反映させる。これにより、図５に示すフェイルオーバ後の処理となる。

以上説明した本実施形態では、フェイルオーバ処理中であっても、システムを停止することなく、片寄せ運用により（図４参照）、端末に対するサービスを継続することができる。すなわち、データの書き込み処理については、正常なサーバで正常運用時と同様に行うことができ、データの読み出し処理については、正常運用時のビューからフェイルオーバ中のビューに切り替えることにより、正常なサーバ側で障害となったサーバの更新データを取得することができる。

また、本実施形態では、障害を検知した後、正常運用時のビューをフェイルオーバ時のビューに変更するだけで、瞬時に、片寄せ運用時の処理（図４参照）に切り替えることができる。また、本実施形態では、フェイルオーバ処理（図６参照）の完了後、フェイルオーバ時のビューを正常運用時のビューに変更する（戻す）だけで、瞬時に、フェイルオーバ後の処理（図５参照）に切り替えることができる。これにより、フェイルオーバ処理のリソースの引継ぎに時間を要する場合であっても、システムの稼動停止時間をより短縮し、より高い可用性を確保することができる。

なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。

本発明の一実施形態が適用されたシステムの全体構成図である。 各装置のハードウェア構成例を示す図である。 通常運用時の処理を模式的に示す図である。 片寄せ運用時（フェイルオーバ中）の処理を模式的に示す図である。 フェイルオーバ後の処理を模式的に示す図である。 フェイルオーバ処理のフローチャートである。

符号の説明

１：端末、２：負荷分散装置、３Ａ：サーバ１号機、３Ｂ：サーバ２号機、３１：業務処理部、３２：受信部、３３：状態監視部、３４：フェイルオーバ処理部、３５：ＭＱ通信部、４：共用ディスク、４Ａ：１号機用ディスク、４１Ａ：１号機用ログテーブル、４２Ａ：２号機用バックアップテーブル、４Ｂ：２号機用ディスク、４１Ｂ：２号機用ログテーブル、４２Ｂ：１号機用バックアップテーブル

Claims (6)

1. 複数のサーバを備えるクラスタシステムのフェイルオーバ方法であって、
   前記各サーバには、当該サーバが更新する自データベースと、他サーバが更新する他データベースのバックアップデータベースとが格納されたディスクがマウントされ、
   前記各サーバは、
   他サーバで発生した障害を検知する障害検知ステップと、
   データ検索時にアクセスするビューを、自データベースと他データベースとを結合した正常時ビューから、前記自データベースと前記バックアップデータベースとを結合したフェイルオーバ時ビューに切り替える切替ステップと、を行うこと
   を特徴とするフェイルオーバ方法。
2. 請求項１記載のフェイルオーバ方法であって、
   前記他サーバにマウントされたディスクを、自サーバにマウントするマウントステップと、
   前記切替ステップにおいて切り替えたフェイルオーバ時ビューを、前記正常時ビューに戻す再切替ステップと、をさらに行うこと
   を特徴とするフェイルオーバ方法。
3. 請求項１または請求項２記載のフェイルオーバ方法であって、
   前記自データベースに対する更新データを送信するとともに、前記他データベースに対する更新データを受信して前記バックアップデータベースに書き込む通信ステップと、をさらに行うこと
   を特徴とするフェイルオーバ方法。
4. 請求項３記載のフェイルオーバ方法であって、
   前記通信ステップは、メッセージキューイング方式を用いて、更新データの送受信を行うこと
   を特徴とするフェイルオーバ方法。
5. 複数のサーバを備えるクラスタシステムにおける、各サーバが実行するフェイルオーバプログラムであって、
   前記各サーバには、当該サーバが更新する自データベースと、他サーバが更新する他データベースのバックアップデータベースとが格納されたディスクがマウントされ、
   前記各サーバに、
   他サーバで発生した障害を検知する障害検知ステップと、
   データ検索時にアクセスするビューを、自データベースと他データベースとを結合した正常時ビューから、前記自データベースと前記バックアップデータベースとを結合したフェイルオーバ時ビューに切り替える切替ステップと、を実行させること
   を特徴とするフェイルオーバプログラム。
6. 複数のサーバを備えるクラスタシステムであって、
   前記各サーバには、当該サーバが更新する自データベースと、他サーバが更新する他データベースのバックアップデータベースとが格納されたディスクがマウントされ、
   前記各サーバは、
   他サーバで発生した障害を検知する障害検知手段と、
   データ検索時にアクセスするビューを、自データベースと他データベースとを結合した正常時ビューから、前記自データベースと前記バックアップデータベースとを結合したフェイルオーバ時ビューに切り替えるフェイルオーバ手段と、を有すること
   を特徴とするクラスタシステム。