JP5015965B2 - サーバ管理システムおよび方法 - Google Patents

Description

本発明は、概してコンピュータネットワークに関し、特に、ネットワークサーバの平衡（ｂａｌａｎｃｉｎｇ）と冗長性（ｒｅｄｕｎｄａｎｃｙ）に関する。

［従来技術の説明］
図１は、従来技術によるネットワークサーバ管理に対するアプローチのための単純化されたアーキテクチャ１００を示す。三つのサーバが示されている。サーバ１１０は、データベースの第１のセグメントを含み、サーバ１２０は、そのデータベースの第２のセグメントを含み、サーバ１３０は、その同じデータベースの第３のセグメントを含む。図１にはまた、ユーザ１５０〜１７０と、三つのサーバのうち特定のクエリに対して応答する責任のある一のサーバとの間で、情報を転送する責任を負う通信ネットワーク１４０も示されている。

図１に示される従来技術におけるサーバ管理に対するアプローチは、いくつかの欠点を有している。

第１に、図１のデータベース全体は、三つの別々のサーバ間で分割されている。どの一のサーバもデータベース全体を含んでおらず、また、サーバ間で、データベースのセグメントが重複することもない。例えば電話帳データベースの場合、サーバＡ（１１０）は、ＡからＨまでのエントリを含み、サーバＢ（１２０）は、ＩからＱまでのエントリを含み、サーバＣ（１３０）は、ＲからＺまでのエントリを含んでもよい。その結果、図１に示される三つのサーバのうちの一つに遅延または障害が起きた場合、ネットワーク内の他のサーバは要求されたデータを有していないため、その障害が起きたサーバの代わりに応答することができない。これにより、クエリ群に対するいくつかの応答が遅延したり、処理されなかったりする。

第２に、たとえ図１に描かれるネットワーク内の全てのサーバが要求されるデータを格納しており、また全てのクエリを受信するとしても、一のサーバが、あるクエリを処理する責任を有する他のサーバが実際にそのクエリを処理しているのか、モニタするメカニズムがない。この結果、ある一のサーバが、他のサーバにおいてクエリが処理されていると誤認したために、その一のサーバに用可能な処理機能があっても利用されないかもしれない。

第３に、図１に説明されている従来のアーキテクチャは、拡大縮小可能（スケーラブル）ではない。サーバについての制限（例えば、プロセッサのスピードや、記憶装置の容量など）が、一のサーバが処理することのできるクエリの数を決定づける。さらなる情報を格納するために、また、さらなるクエリを処理して格納するために、追加サーバを導入する際には、ネットワーク全体をシャットダウンしなければならない。しばしば、既存サーバ間でデータを再配置するために、さらなる休止時間（ダウンタイム）が課せられる。よって、図１に示される従来技術のアーキテクチャによって証明されるように、サーバ管理のための、より改良されたシステムおよび方法に対する需要が存在する。

［発明の概要］
本発明は、サーバ管理のためのシステムまたは方法例を提供する。このシステムのある例は、複数のサーバを備え、各サーバは、データベースにアクセスする機能を有する。通信ネットワーク例によって、そのネットワーク内で、全てのサーバをクエリが受信することが可能となる。ルックアップテーブルは、そのネットワーク内で、ある特定のクエリを処理するサーバを特定する。一方、このシステムの別の実施形態は、そのネットワークサーバの作業量負荷を監視し、再平衡化（ｒｅｂａｌａｎｃｉｎｇ）するためのプログラムロジックコントローラを備えることを特徴とする。

サーバ管理方法の一例は、データベースの複製（あるいはその一部）を各ネットワークサーバにインストールするステップと、全てのサーバで全てのクエリを受け取るステップと、ルックアップテーブルの指示に従ってクエリを処理するステップとを備える。

クエリ処理方法の一例は、クエリをネットワークに送出するステップと、そのネットワーク内のそれぞれのサーバにそのクエリを送信するステップと、各サーバが、ネットワーク内の、その特定のクエリを処理する第１の責任を有するサーバを、ルックアップテーブルで検索するステップとを備える。ネットワーク内のクエリの処理は、全てのネットワークサーバによって、モニタされる。クエリ結果はユーザに送信されてもよく、それにより、処理が完了する。

サーバの作業負荷を再平衡化する方法の一例は、ネットワークの全体のクエリ応答率を決定するステップと、そのネットワークの全体のクエリ応答率を、目標とする（ｔａｒｇｅｔ）全体のクエリ応答率と比較するステップと、そのネットワーク内の各サーバについて、クエリ応答率を決定するステップと、そのネットワーク内の全てのサーバについて、クエリ応答率を比較するステップと、を含む。この方法に基づいて、一以上のデータセグメントに対する第１の責任を、そのネットワーク内で比較的低いクエリ応答率を有するサーバから、そのネットワーク内で比較的速いネットワーク応答率を有するサーバへと、移動することが可能となる。この方法は、マニュアルで、または任意の（オプショナル）プログラムロジックコントローラの支援によって、実行可能である。サーバの作業量が再平衡化されなかった場合のために、本発明のさらなる実施例は、ネットワークに追加サーバを導入する方法を含む。

追加サーバをネットワーク内に導入する方法の一例は、ネットワーク内に存在するサーバによって用いられているデータベースの複製（またはその一部）を、追加サーバにインストールするステップと、追加サーバが全てのクエリを受信するように追加サーバを構成するステップと、追加サーバ内に常駐する、あるいは追加サーバによってアクセス可能なルックアップテーブルをそのネットワークにインストールするステップと、を備える。また別の実施形態は、追加サーバがネットワーク内におけるクエリの処理をモニタするように、追加サーバを構成するステップを含む。

従来技術による、非スケーラブルで、重複がなく、障害が起こりやすいネットワークサーバ管理手法の単純化されたアーキテクチャを示す図である。

スケーラブルで、重複があり、信頼性のあるサーバネットワークを実装可能なネットワークアーキテクチャの一例を示す図である。

本発明の一実施形態にかかるルックアップテーブルの例を示す図である。

サーバ間の作業負荷を平衡化するシナリオの一例にかかるルックアップテーブルの例である。

ネットワークにサーバを追加することによって、サーバ間の作業負荷を再平衡化するシナリオの一例にかかるルックアップテーブルの例である。

本発明の様々な実施形態にかかる方法であって、スケーラブルで、重複があり、信頼性のあるサーバネットークを構築するための方法の一例を示すフローチャートである。

本発明の様々な実施形態にかかる方法であって、スケーラブルで、重複があり、信頼性のあるサーバネットワークにおいてクエリを処理するための方法の一例を示すフローチャートである。

本発明の様々な実施形態にかかる方法であって、マニュアルで、またはプログラムロジックコントローラの使用によって、ネットワークサーバの作業負荷を再平衡化する方法の一例を示すフローチャートである。

本発明の様々な実施形態にかかる方法であって、追加サーバを導入することによって、ネットワークサーバ作業負荷を再平衡化する方法の一例を示すフローチャートである。

［詳細な説明］
図２を参照して、本発明の様々な実施形態を実装可能なネットワークアーキテクチャ例２００について説明する。ネットワークアーキテクチャ例２００は、オプショナルプログラムロジックコントローラ２０２と、オプショナルマスタデータベース２０４と、ルックアップテーブル３００（図３）とを含む。オプショナル通信リンケージ２０６、サーバ２０８〜２１８、通信ネットワーク２２０もまた、図２に示されるネットワークアーキテクチャ例を構成する。本発明のいくつかの実施形態においては、サーバ２０８〜２１８はそれぞれ、一以上のクロック、かつ／または、その他のタイミング装置を含む。これらは、互いに同期を保ち、または、原始時計のような、定期的に通信ネットワーク２２０を通して共有標準時計を参照するクロックやタイミング装置に基づいて、同期を保つ。結局の所、以下で詳しく説明するように、クエリを処理（例えば、応答）のために第２のサーバに受け渡す前に、そのクエリを第１のサーバでタイミングよく処理するためには、ある種のタイミング手段（例えばクロック、タイマなど）は必要である。

ある種のタイミング装置は、他のものよりも、特定の構成によりよく適合するかもしれない（必ずしも、その他のタイミング装置が、その特定の構成に実装されることを防止する必要はないとしても）。例えば、あるクロックは、（以下で述べるように）共有クエリ資源（リソース）によりよく適合するかもしれない。これに対して、ネットワークアーキテクチャ例２００に配信される個々のクエリに応答するためには、ある単純なタイマが、最適かもしれない。

図２に置いて、クエリは、ユーザ１５０〜１７０によって生成され、（以下で詳しく説明されるように）通信ネットワーク２２０を通じてサーバ２０８〜２１８に通信される。ある一の実施例においては、通信ネットワーク２２０は、マルチキャストまたはブロードキャストの手法を用いて、クエリをサーバに通信する。この実施例においては、すべてのサーバが、全てのクエリを受け取る。クエリは、特に、計算の要求や演算の要求、特定の値や他の情報の決定の要求を含んでもよい。クエリはまた、情報の報告（リターン）要求を含んでもよい。ここで報告すべき情報は、前述の値や他の情報をも含んでもよい。この他の実施例においては、他の有線または無線メカニズムにより、全てのクエリが全てのサーバに送信される。さらに別の実施形態においては、クエリまたはクエリの通知が、ネットワークを構成するサーバの一部（サブセット）に通信される。この実施形態においては、ある特定のクエリの処理やバックアップについて責任を有さないサーバは、そのクエリを受信しない。さらに本発明の他の実施形態においては、クエリは共有資源（リソース）に保持されてもよい。その共有リソースは、未処理（ｏｕｔｓｔａｎｄｉｎｇ）クエリのリストを備え、前述のサーバのネットワークにより、モニタかつ／またはアクセスされうる。この共有リソースは、中間（ｉｎｔｅｒｍｅｄｉａｔｅ）サーバ、ある種の待ち行列メカニズム（例えば、ルータなど）、メモリバッファ、その他のクエリリストまたは実際のクエリそのものを保持する手段であってよい。

通信ネットワーク２２０によって、ネットワークアーキテクチャ例２００の各サーバは、そのネットワーク内における他のサーバによるクエリの処理をモニタすることができる。例えば、クエリへの返信は、ネットワーク２００を介してマルチキャストまたはブロードキャストされてもよい。別の実施形態においては、例えば、オプショナル通信リンケージ２０６などの、他の形のサーバピアモニタリング（ｓｅｒｖｅｒ ｐｅｅｒ ｍｏｎｉｔｏｒｉｎｇ）が用いられる。またさらに他の実施形態においては、ネットワークを構成するサーバの一部（サブセット）が、ピアサーバによってモニタされる。ここでは、ある特定のクエリを処理する責任を負わないサーバは、モニタされない。

ある実施形態においては、サーバ２０８〜２１８はそれぞれ、データベース全体またはデータベースの複製を含む。各データベースまたはデータベースの複製の内容は、実質的に同一であってもよく、あるいは、幾つかのデータのセグメントが除かれていてもよい。本発明の別の実施形態は、ネットワーク内の全てのサーバによってアクセス可能であるオプショナルマスタデータベース２０４を含む。オプショナルマスタデータベース２０４は、各サーバにインストールされるデータベース全体またはデータベースの複製を代替するものであってもよく、またはこれらに追加されるものであってもよい。ネットワークアーキテクチャ例２００においては、データベースまたはデータベースの複製は、全体として、ユーザ１５０〜１７０によって問い合わせられる情報を含む。データベースの例には例えば、電話帳、顧客データベース、製品あるいはサービスのカタログなどが含まれる。その他の内容のデータベースのカテゴリもまた、本発明の範囲に含まれる。本発明の他の実施形態においては、サーバ２０８〜２１８は、前述のクエリを処理し、かつ／または応答するように構成されてもよい（例えば、ある特定の計算要求に応答するために、必要なロジックを用いてプログラムされてもよい）。この構成は、前述のデータベースまたはデータベースの複製に追加されてもよく、またこれらを置き換えるものであってもよい。

各データベースまたはデータベースの複製は、一またはそれ以上の、データのセグメントであるデータセグメントを備える。幾つかの実施例においては、データのセグメントは、その基礎であるデータベースの特質に基づいて決定される。電話帳データベースを形成する２６個のデータのセグメントは、例えば２６個の英語のアルファベットによって表されてもよい。２６個のサーバがそれぞれ、アルファベットの特定の文字に対応するクエリの処理に責任を持つ。例えば一のサーバは、文字「Ａ」で始まる姓に対応するクエリを処理する第１の責任を割り当てられる。これに対して第２のサーバは、文字「Ｂ」で始まる姓に対応するクエリを処理する第１の責任を割り当てられる。同様にして、第３のサーバは、文字「Ｃ」で始まる姓に対応するクエリを処理する第１の責任を割り当てられる、などである。

別の実施形態においては、任意のデータセグメントの指定に基づいて、ネットワークの内の各サーバの責任が決定されてもよい。例えば幾つかの実施形態においては、データベースは、ネットワークを形成するサーバの数と同じ数の、同じサイズ（メガバイト）のデータにセグメント化されてもよい。また、データの特定のセグメントに対するクエリ頻度の平均または予測によって、あるいはデータの特定のセグメントに関する特定の処理の必要性に基づいて、セグメントの重み付けを決定するために、様々な方式が用いられてもよい。

ある実施例においては、データベース中のデータのセグメントは、マニュアルで、または自動で、ルックアップテーブル（図３）によって目録化（ｃａｔａｌｏｇｕｅｄ）される。別の実施形態においては、オプショナルプログラムロジックコントローラ２０２が、データベースを、最適化したデータのセグメントに分割してもよい。最適化したデータのセグメントは、自動で更新され、ルックアップテーブル３００に反映される。サーバネットワークのある実施形態においては、オプショナルプログラムロジックコントローラ２０２は、サーバの利用率（ｕｓａｇｅ）の変化、サーバの記憶装置（ｓｔｏｒａｇｅ）の容量、クエリの頻度などのファクタに基づいて、サーバの作業負荷をモニタし、平衡化（ｂａｌａｎｃｅ）させ、かつ／または再平衡化（ｒｅｂａｌａｎｃｅ）させる。

図３には、ルックアップテーブル３００の例が示される。本発明のいくつかの実施形態においては、ルックアップテーブル３００のようなルックアップテーブルが、ネットワークサーバによるクエリの処理を指示する。ルックアップテーブル３００内の列やヘッダは、説明の目的のために示されており、特定のデータ構造や形式に関して制限を課すことを意図するものではない。

ルックアップテーブル３００においては、サーバ２０８〜２１８（図２）が列３１０において特定されている。本発明の幾つかの実施形態においては、これらのサーバのそれぞれが、ルックアップテーブル３００の複製を含む。また別の実施形態においては、サーバは、集中化された（ｃｅｎｔｒａｌｉｚｅｄ）ルックアップテーブルにアクセス可能である。

ルックアップテーブル３００の列３２０において、それぞれのサーバにインストールされているデータのセグメントが指定されている。図２において説明されているネットワークアーキテクチャにおいては、ルックアップテーブル３００は、データセグメント１〜６を含むデータベース全体が、サーバ２０８〜２１８にインストールされていることを示す。

実施例においては、ネットワーク内の各サーバは、１以上のユニークなデータセグメントに割り当てられる。ネットワーク内の各サーバに割り振られたそれぞれのユニークなデータセグメントは、まとめると（ｃｏｌｌｅｃｔｉｖｅｌｙ）、データベース全体を含む。データベースのユニークな部分、すなわちユニークなデータセグメントは、その特定のサーバが処理すべき責任（ｒｅｓｐｏｎｓｉｂｉｌｉｔｙ）を表す。すなわち、そのサーバのユニークなデータセグメントに置かれている（ｌｏｃａｔｅｄ）情報に対する問い合わせ（クエリ）が、ネットワーク内の全てのサーバに通信されたとき、その特定のサーバが処理をする責任を有する。ネットワークの全てのサーバに通信されたクエリに応えて、その要求された情報を含むデータセグメントについて責任を有する特定のサーバは、そのクエリを処理するための所定量の時間を割り当てられる。その間、他のサーバはその処理をモニタする。従って、あるクエリの処理について第１に責任を有するサーバは、そのサーバのユニークなデータセグメント内に置かれた情報に対するクエリを処理する第１の責任を有するものと見なされる。

ネットワーク内の各サーバについての第１の責任は、ルックアップテーブル３００の列３３０に特定されている。図３に示されるように、サーバ２０８は、データセグメント１に対する第１の責任を割り当てられている。サーバ２１０は、データセグメント２に対する第１の責任を割り当てられている。サーバ２１２は、データセグメント３に対する第１の責任を割り当てられている。サーバ２１４は、データセグメント４に対する第１の責任を割り当てられている。サーバ２１６は、データセグメント５に対する第１の責任を割り当てられている。サーバ２１８は、データセグメント６に対する第１の責任を割り当てられている。

ルックアップテーブル３００において、列３４０に示されるように、各サーバは、割り当てられた第１の責任（例えば、クエリに対する応答）を完了するために１００ミリ秒を割り当てられている。ルックアップテーブル３００はまた、列３７０に反映されているように、第２のクエリの始動のために割り振られた時間をも含む。第１の責任を割り当てられたある特定のサーバが、その割り当てられた時間内に、特定のクエリを処理し、または応答をすることができなかった場合、第２の責任を有するサーバに対して、そのクエリを始動するためのある特別の時間が割り当てられる。例えば、サーバ２０８が、データセグメント１（このデータセグメントに対して、サーバ２０８は、第１の責任を割り当てられている）についてのクエリに対して、１００ミリ秒以内に応答することができなかった場合、サーバ２０８に割り当てられた第１の応答時間の満了の後に（例えば、列３６０に反映されるように、１０１ミリ秒に）、サーバ２１０は、その同じクエリの処理を始動する。本発明の幾つかの実施形態においては、第２のクエリ始動時間（列３７０）を必然的に割り当てなくともよい。それによると、クエリに対する応答がなかった場合、第２のサーバは、単純に、割り当てられた第１のクエリ応答時間（列３４０）の満了と共に、処理の責任を引き受ける。

ルックアップテーブル３００においては、列３６０に反映されているように、サーバ２０８は、データセグメント６に対する第２の責任を割り当てられており、サーバ２１０は、データセグメント１に対する第２の責任を割り当てられており、サーバ２１２は、データセグメント２に対する第２の責任を割り当てられており、サーバ２１４は、データセグメント３に対する第２の責任を割り当てられており、サーバ２１６は、データセグメント４に対する第２の責任を割り当てられており、サーバ２１８は、データセグメント５に対する第２の責任を割り当てられている。実施例においては、データの特定のセグメントに対するクエリについての第２の責任は、データの同じセグメントに対して第１の責任を有するサーバと同じサーバには割り当てられていない。サーバの遅延や障害が起きた際のネットワークの信頼性を高めるためである。すなわち、一のサーバの遅延または障害によって、第２のサーバの、介入（ｓｔｅｐ−ｉｎ）し、ある特定のクエリに応答する機能が、反対に損なわれてはならない。

ルックアップテーブル３００において列３５０に反映されるように、サーバネットワーク例は、２重の冗長性（ｒｅｄｕｎｄａｎｃｙ）を持って動作（ｏｐｅｒａｔｅ）している。望ましい冗長性レベルによって、そのサーバネットワークが２重の冗長性を持って動作していることが示される場合、第３の責任を有する第３のサーバが、第１のサーバおよび第２のサーバによって処理し損われたクエリの処理を試みるだろう。

ルックアップテーブル例３００に示されるように、２重の冗長性で作動しているサーバネットワークには、第３の責任とそれぞれのクエリ始動時間が割り当てられる。実施例においては、データの特定のセグメントに対するクエリについての第３の責任は、そのデータの同じセグメントに対する第２の責任を有するサーバと同じサーバには割り当てられていない。２重の冗長性は、２つのサーバに障害が発生している場合に、ネットワークの信頼性とパフォーマンスを高める。その理由は、第３のサーバが、そのサーバが第３の責任を有するデータセグメントに対するクエリに介入し、処理することが可能であるからである。

本発明の幾つかの実施例においては、ネットワークアーキテクチャ例２００に示されるように、サーバ２０８〜２１８のそれぞれに格納されたデータベースまたはデータベースの複製に加えて、オプショナルマスタデータベース２０４が存在することにより、さらなるフェールセーフメカニズムが提供される。特定のクエリに対して割り当てられた責任を有する各サーバ（すなわち、第１、第２、第３などの）が、その割り当てられた責任を、割り当てられた時間内に処理できなかった場合に、このデータベースはアクセスされうる。オプショナルマスタデータベース２０４を含むサーバが機能し続けることを前提とすると、そのようなネットワークにおいては、未処理クエリは存在しない。なぜなら、オプショナルマスタデータベース２０４を含むサーバが介入し、クエリを処理するためである。これに代えて、ネットワーク内の他の機能しているサーバが、必要なデータを獲得し、処理し、配信するために、オプショナルマスタデータベース２０４にアクセスしてもよい。

図４には、サーバ負荷の平衡化のシナリオの一例によるルックアップテーブルの例が示される。サーバの責任について、かつ／または、格納されるデータベースについて、平衡化、かつ／または再平衡化が必要である理由をほんの幾つかを並べると、クエリ応答時間、サーバ利用率、格納されるデータ量、クエリ頻度などがある。クエリ応答時間、サーバ利用率、格納されるデータ量、かつ／またはクエリ頻度をモニタし、また、サーバネットワークを自動的に再平衡化するために、オプショナルプログラムロジックコントローラ２０２（図２）を用いることもできる。いくつかの実施形態においては、これらの調整はマニュアルで行われる。どちらの場合においても、クエリ応答時間の増加が、サーバネットワークが再平衡化を必要としていることの、最初の兆候であるかもしれない。サーバネットワークを平衡化、かつ／または再平衡化させるための一の方法は、ルックアップテーブル例４００によって説明される。ルックアップテーブル例４００においては、各サーバのデータベースを構成するデータセグメントを選択的にインストールすることによって、余分なサーバの記憶容量が作り出される。

ルックアップテーブル４００に含まれる情報のカテゴリは、ルックアップテーブル例
３００（図３）に含まれる情報のカテゴリと同様である。ただし、列４２０は、ネットワーク内の各サーバが、そのデータベース全体の複製は有していないことを反映している。ルックアップテーブル例３００に示される説明的なネットワークとは異なり、列４２０に示される、サーバにインストールされたデータセグメントは、数セグメントのデータが除かれたものである。

ルックアップテーブル例４００の列４２０に示されているように、データセグメント１−２と４−６は、サーバ２０８にインストールされる。データセグメント３は、サーバ２０８のデータベースからは除かれる。列３３０に示されるように、サーバ２０８は、データセグメント１に対する第１の責任を割り当てられる。サーバ２０８はまた、データセグメント６に対する第２の責任を割り当てられ（列３６０）、データセグメント５に対する第３の責任を割り当てられる（列３８０）。

これらに加えて、列４２０に示されるように、データセグメント１−３と５−６が、サーバ２１０にインストールされる。データセグメント１−４と６は、サーバ２１２にインストールされる。データセグメント１−５は、サーバ２１４にインストールされる。データセグメント２−６は、サーバ２１６にインストールされる。データセグメント１と３−６は、サーバ２１８にインストールされる。

ルックアップテーブル４００例に示されるサーバ負荷の平衡化または再平衡化のシナリオ例は、図２および図３に示されるネットワーク例に適用することができる。その結果、サーバ１つの記憶容量に等しい６個のデータセグメントを節減することができる。図４の列３５０に示されるように、サーバ負荷の平衡化、かつ／または再平衡化のシナリオ例においては、ネットワークの冗長性率は、２重に保たれる。以下で、図７に関連して述べるように、応答時間が遅くなっているサーバから転送されたデータセグメントを格納するために、余分なサーバの記憶容量を使うことができる。

図５は、ネットワークにサーバを追加することによって、サーバの作業負荷を再平衡させるシナリオ例にかかるルックアップテーブルの例を示す。ルックアップテーブル５００に含まれる情報のカテゴリは、ルックアップテーブル例３００に含まれる情報のカテゴリのと同様であるが、サーバの導入前（列５３０及び列５７０）とサーバの導入後（列５４０及び列５８０）との比較が示されていることのみ異なる。

図５に示されるように、追加サーバ導入のプロセス全体に渡って、各サーバにインストールされているデータベースは、同じであり続ける。これに対して、ネットワークサーバの数と、その責任（すなわち、第１、第２、第３、など）は、変更される。ルックアップテーブル例５００の列５２０には、サーバ２０８〜２１８がそれぞれ、データセグメント１−５０を備えるデータベースを包含することが示されている。サーバの導入を開始する前に、データセグメント１−５０は、（「新」と称される）追加のサーバに、インストールされている。各サーバが、同じデータセグメントを備えるデータベースを含むため、「新」サーバが、ネットワークに付け加えられている間も、ネットワークは動作しつづけることができる。すなわち、ネットワークの動作の継続性は、どの一のサーバにも依存することはない。「新」サーバがネットワークに接続されるとき、サーバ導入前の設定（列５３０および５７０）は、サーバ導入後の設定（列５４０及び５８０）によって置き換えられ、ネットワークは、中断されることなく動作し続ける。

追加サーバの導入により、サーバ負荷再平衡化を実行する例として、ルックアップテーブル例５００において、「新」サーバの導入前には、サーバ２０８と、サーバ２１０と、サーバ２１２と、サーバ２１４とは、それぞれ、受け入れがたいほど遅いスピードでクエリを処理していたと仮定されたい。さらに、サーバ２１６は、許容可能なスピードでクエリを処理しており、サーバ２１８は、最大のスピードでクエリを処理していたと仮定されたい。列５６０に示されるように、ネットワークは、１重（ｓｉｎｇｌｅ）の冗長性の率すなわち冗長性レベルにおいて動作している。

図８に関連して述べる方法例に基づいてサーバ負荷を再平衡化することにより、サーバ２０８は、データセグメント７−８（列５３０）に対する第１の責任をサーバ２１０（列５４０）に移動せしめ、サーバ２１０は、データセグメント１４−１７（列５３０）に対する第１の責任をサーバ２１２（列５４０）に移動せしめ、サーバ２１２は、データセグメント２１−２６（列５３０）に対する第１の責任を「新」サーバ（列５４０）に移動せしめる。同様に、サーバの負荷の再平衡化によって、サーバ２１４の、データセグメント２７（列５３０）に対する第１の責任が「新」サーバ（列５４０）に移動され、データセグメント３５−３６（列５３０）に対する第１の責任が、サーバ２１６（列５４０）に移動される。最後に、サーバ２１６は、データセグメント４２−４３（列５３０）に対する第１の責任をサーバ２１８（列５４０）に移動せしめる。

導入前（列５３０）と導入後（列５４０）の各ネットワークサーバに対するデータセグメントの数を比較することにより、以下のことが証明される。サーバ２０８に対する第１の責任は、２データセグメント分減少し、サーバ２１０に対する第１の責任は、２データセグメント分減少し、サーバ２１２に対する第１の責任は、２データセグメント分減少し、サーバ２１４に対する第１の責任は、３データセグメント分減少する。合計して、これらの四つのサーバの作業負荷は、９データセグメント分減少する。「新」サーバの導入後、サーバ２１６に対する第１の責任は変化せず、サーバ２１８に対する第１の責任は、２データセグメント分増加する。最後に、「新」サーバに対する第１の責任は、初期値として７データセグメントとされる（列５４０）。列５６０に示されるように、このネットワークは、１重の冗長性率で、動作しつづける。

図６には、本発明の様々なある実施形態にかかる、スケーラブルで、重複があり、耐障害性のあるサーバネットークを構築するための、ある方法のフローチャートの例が示されている。

ステップ６０２において、オプショナルプログラムロジックコントローラ２０２（図２）が、任意で、ネットワークアーキテクチャ例２００（図２）の一部として、インストールされる。本サーバネットワークの実施例において、オプショナルプログラムロジックコントローラ２０２は、サーバの利用率と、サーバの記憶容量と、クエリの頻度とに一部もとづいて、サーバの作業負荷をモニタし、再平衡化する。オプショナルプログラムロジックコントローラ２０２により、例えば前述のような機能を自動化されることを通じて、ネットワークにおいてマニュアルでサーバをメンテナンスしたり、関連する装置をアップグレードしたり、購入したりする必要性が減少する。

ステップ６０４において、ネットワークアーキテクチャ例２００の各サーバにデータベースがインストールされる。インストールされた各データベース、またはインストールされたデータベースの複製の内容は、実質的に同様であってもよく、または、幾つかのデータのセグメントが除かれていてもよい。データベースは例えば、電話帳、顧客データベース、製品かつ／またはサービスのカタログを含むが、これらに限定されるものではない。

ステップ６０６において、オプショナルマスタデータベース２０４（図２）が、サーバネットワークに任意でインストールされる。オプショナルマスタデータベース２０４へのアクセスが必要であると判明した場合には、オプショナルマスタデータベース２０４は、ネットワーク内の全てのサーバによって、アクセス可能である。

ステップ６０８において、ネットワークアーキテクチャ例２００内のネットワークサーバは、全てのクエリを受信するように構成される。実施例において、通信ネットワーク２２０は、全てのサーバに全てのクエリを通信するために、マルチキャストまたはブロードキャストを用いる。これらの実施形態においては、全てのサーバが、全てのクエリを受ける。別の実施例においては、その他の、有線、かつ／または無線のメカニズムによって、全てのサーバに全てのクエリを通信される。さらに別の実施形態においては、クエリ、かつ／またはクエリの通知（ｎｏｔｉｃｅ ｏｆ ｑｕｅｒｉｅｓ）は、ネットワークを構成するサーバのサブセットに通信される。ここでは、ある特定のクエリを処理する責任を負わないサーバは、そのクエリを受信しない。

ステップ６１０において、ルックアップテーブル３００（図３）が、ネットワークアーキテクチャ例２００を構成する各サーバ２０８〜２１８用にインストールされる。実施例においては、ルックアップテーブル３００が、サーバのクエリ処理を指示する。ルックアップテーブル３００は、サーバ２０８〜２１８に対して、局所的（ｌｏｃａｌ）に存在してもよく、また、遠隔（ｒｅｍｏｔｅ）に存在してもよい。

ステップ６１２において、ネットワークアーキテクチャ例２００上のサーバ冗長レベルが構築されてもよい。サーバ冗長レベルは、サーバネットワークの障害に対する寛容性の関数である。サーバネットワーク障害に対する寛容性が少ないほど、サーバ冗長レベルは高くなる。例えば、時折のネットワーク障害を許容できるユーザは、図５に示されるように、一重の冗長レベルを構築するかもしれない。これに対して、時折のネットワーク障害をも許容できないユーザは、図４に示されるように、二重の冗長レベルを構築するかもしれない。１重の冗長レベルとは、ルックアップテーブル例３００に示されるように、第１の責任を割り当てられたサーバが、割り当てられた時間内に割り当てられたクエリを処理することに失敗した場合に、同じデータのセグメントについて、第２の責任を負うその他のサーバが、そのクエリの処理を試みるということを意味する。２重の冗長レベルとは、第３の責任を割り当てられた第３のサーバが、第１および第２の責任を有するサーバによって処理されなかったクエリの処理を試みることを意味する。図２、図３および図５に示されるように、各ネットワークサーバにデータベース全体がインストールされると仮定すると、サーバネットワークの冗長レベルは、そのネットワーク上のサーバ（例えばサーバ２０８〜２１８）の数によってのみ、制限される。

ステップ６１４において、ネットワークアーキテクチャ例２００を構成するサーバは、各クエリを受信した際に、ステップ６１０でインストールされたルックアップテーブルをチェックするように、構成される。実施例においては、ルックアップテーブル３００が、各サーバにインストールされたデータセグメントを指定する。

ステップ６１６において、ネットワークアーキテクチャ例２００を構成するサーバは、ルックアップテーブル３００によってクエリを処理するように、構成される。本実施例において、ルックアップテーブル３００は、各サーバに、その割り当てられた第１の責任を完了するために、１００ミリ秒を割り当てる。

ステップ６１８において、ネットワークアーキテクチャ例２００を構成するサーバは、そのネットワーク内の他のサーバによるクエリの処理をモニタするように、構成される。実施例においては、通信ネットワーク２２０により、ネットワークアーキテクチャ例２００内の各サーバが、そのネットワーク内の他のサーバによるクエリ処理をモニタすることが可能となる。例えば、そのクエリに対する返答がブロードキャストまたはマルチキャストされるのを、「聞く」事により、モニタすることが可能である。この他の実施形態においては、オプショナル通信リンケージ２０６のような、サーバピアモニタリングの他の形式が用いられる。さらに別の実施形態においては、ネットワークを構成するサーバのサブセットが、各ピアサーバ（ｐｅｅｒ ｓｅｒｖｅｒ）により、モニタされる。ここでは、特定のクエリを処理する責任のないサーバは、モニタされない。

ステップ６２０において、ネットワークアーキテクチャ例２００を構成するサーバは、クエリ結果をユーザに送信するように、構成される。

ステップ６２２において、ネットワークアーキテクチャ例２００を構成するサーバは、ユーザへのクエリ結果の送信の際に、リセットするように構成される。すなわち、現在（ｐｒｅｓｅｎｔ）の応答時間は、”０”にリセットされる。

図７には、ネットワークアーキテクチャ例２００（図２）におけるクエリ処理方法の例のためのフローチャートが示されている。

ステップ７１０において、クエリがネットワークアーキテクチャ例２００に送出される。電話帳データベースのためのサーバネットワークの場合、ユーザ１５０（図２）が、例えば、ジョーンズという姓の人物に対応する住所を問い合わせるクエリを送出する。

ステップ７２０において、送出されたクエリは、ネットワークサーバへと通信される。ここでは、ジョーンズという姓の人物に対応する住所に関するクエリは、通信ネットワーク２２０（図２）を介して、ネットワークアーキテクチャ例２００内のすべてのサーバに、マルチキャストされる。

ステップ７３０において、ルックアップテーブルの参照結果に基づいて、送出されたクエリを処理する第１の責任を有するサーバのＩＤが、決定される。ここで、電話帳データベースのクエリ用のルックアップテーブルには、（それぞれがアルファベットの文字に対応する）２６個のサーバのうちの１０番目のサーバには、文字Ｊで始まる姓に対応するクエリの処理について第１の責任が割り当てられていることが反映されている。従って、サーバ１０が、ジョーンズの住所のために、そのデータセグメントへ問い合わせる（ｑｕｅｒｙｉｎｇ）第１の責任を有する。

ステップ７４０において、送出されたクエリが、第１の責任を有するサーバによって処理される（または、処理しようと試みられる）。この特定の場合においては、サーバ１０が、ジョーンズに対応する住所についてのクエリを処理する。

ステップ７５０において、送出されたクエリの、第１の責任を有するサーバによる処理が、そのネットワーク内の他のサーバによって、モニタされる。実施例においては、通信ネットワーク２２０によって、ネットワークアーキテクチャ例２００内の各サーバによるモニタが可能となる。例えば、クエリへの応答であるマルチキャストまたはブロードキャストを、ネットワークアーキテクチャ例２００内の各サーバが聞くことによって、ネットワーク内の他のサーバのクエリ処理をモニタすることができる。別の実施形態においては、例えばオプショナル通信リンケージ２０６を用いる形式のような、その他のサーバモニタピアリングの形式が用いられる。さらに別の実施形態においては、ネットワークを構成するサーバのサブセットが、ピアサーバによってモニタされる。ここでは、特定のクエリを処理する責任を有さないサーバはモニタされない。この特定の例においては、電話帳データベースのためのサーバネットワークを構成する２６個のサーバのうちの２５個のサーバが、サーバ１０による、ジョーンズに対応する住所についての処理をモニタする。

ステップ７６０において、割り当てられた時間内に、送出されたクエリが処理されたか否か決定される。ルックアップテーブル３００（図３）を参照すると、各サーバは、そのサーバに割り当てられた第１の責任を実行し終えるために、１００ミリ秒を割り当てられている。この特定の例において、サーバ１０は、１００ミリ秒以内に、ジョーンズに対応する住所は、「カルフォルニア パロ・アルト ゲングロード２２００」であることを決定した。

ステップ７７０において、あるクエリについて第１の責任を有するサーバによって、（例えばサーバの遅延や障害によって）そのサーバに割り当てられた時間内に割り当てられたクエリが処理されなかった場合、ステップ７３０に関連して述べた方法に基づいて、第２の責任を有するサーバが決定される。それから、第２の責任を有するサーバが、ステップ７４０から７５０において説明されたように、クエリを処理する。その他の予備（バックアップ）の、かつ／または補助的（ｓｅｃｏｎｄａｒｙ）なサーバは、クエリがステップ７６０に置いて適時に処理されたことを示す徴候（ｉｎｄｉｃａｔｉｏｎ）を待ちつづける。

ステップ７８０において、例えばマルチキャストやブロードキャストの手法によって、そのクエリを送出したユーザに、クエリ結果が転送される。この特定の例においては、ユーザ１５０（図２）は、通信ネットワーク２２０を介したマルチキャスト送信を通して、ジョーンズの住所を受信することになる。

ステップ７９０において、ネットワークサーバは、次のクエリに備えてリセットする。この特定の例においては、電話帳データベースを構成する２６個のサーバは、次のクエリがユーザによって送出されるだろうことを予想して、現在の処理時間を０にリセットする。すなわち、ネットワークサーバは、新たなクエリの到着を待つ。ここで、特定のクエリに関する全体の処理時間は、その特定のクエリと、クエリ自身のタイムスタンプに対して相対的に開始する（すなわち、クエリが生成され、またはネットワークサーバによって受信されてからの全体の時間）。

図８を参照する。図８には、本発明の様々な実施形態にかかる、ネットワークサーバの作業負荷を評価し、再平衡化する方法の一例を示すフローチャートが示される。図８のすべてのステップは、マニュアルで、またはオプショナルプログラムロジックコントローラ２０２（図２）の支援によって、実行することができる。

ステップ８１０において、ネットワーク全体のクエリ応答率が決定される。例えば、ネットワークアーキテクチャ例２００（図２）に送出された各クエリを処理するために要する時間の、２４時間に渡る平均が、マニュアルで、またはオプショナルプログラムロジックコントローラ２０２（図２）によって、決定されてもよい。他の様々な時間または応答時間の尺度（ｍｅａｓｕｒｅｓ）が用いられてもよい。

ステップ８２０において、ステップ８１０で決定されたネットワーク全体のクエリ応答率は、目標（ターゲット）とするネットワーク全体のクエリ応答率と比較される。例えば図７に関連して述べた電話帳データベースについて、その電話帳データベースに対して責任を有する特定の電話会社は、全てのクエリが平均して１００秒以内に処理されるように要求することを決定するかもしれない。この比較は、サーバネットワークを、その構成要素であるサーバのパフォーマンスとは別個に評価することのできる手法の代表例である。

ステップ８３０において、個々のサーバのクエリ応答率が決定される。例えば、図２のサーバ２０８〜２１８がそれぞれ、ネットワークアーキテクチャ例２００（図２）内に送出された各クエリを処理するために要する、２４時間に渡る平均の時間が、マニュアルで、またはオプショナルプログラムロジックコントローラ２０２（図２）により、決定される。各クエリを処理するために要する平均の時間は、他の様々な時間または応答時間の尺度（ｍｅａｓｕｒｅｓ）によって決定されてもよい。

ステップ８４０において、すべてのサーバの応答率が比較される。例えば図５に示され、ここで説明されている実施例においては、サーバ２０８、サーバ２１０、サーバ２１２、サーバ２１４の応答率は、サーバ２１６とサーバ２１８の応答率よりも遅かった。これは、サーバ２０８〜２１４がクエリの処理について第１の責任を有していたデータセグメントの数を、削減すべき理由があることを示していた。

ステップ８５０において、特定のデータセグメントについての第１の責任が、クエリ応答率が遅いサーバから、応答率が速いサーバへと受け渡される。例えば図５に関連して述べたように、サーバ２０８は、データセグメント７〜８（２個のデータセグメント）に関する第１の責任を、サーバ２１０に受け渡す。サーバ２１０は、データセグメント１４〜１７（４個のデータセグメント）に関する第１の責任を、サーバ２１２に受け渡す。

ステップ８６０において、ネットワーク全体のクエリ応答率が、ステップ８１０に関して述べたのと同様の方法で再決定される。

ステップ８７０において、ステップ８６０で決定されたネットワーク全体のクエリ応答率を、目標とするネットワーク全体の応答率と、再び比較する。

ステップ８８０において、再平衡化されたサーバネットワークのパフォーマンスが、目標とするネットワーク応答率に対して、好適であるか否か、決定される。再平衡化されたサーバネットワークのパフォーマンスが、要求を満たすものである場合、ステップ８１０に関して述べたように、ネットワーク全体のクエリ応答率は、定期的に再決定されてもよい。再平衡化されたサーバネットワークのパフォーマンスが、要求を満たさないときには、ステップ８９０への着手が必要とされる場合がある。

ステップ８９０において、図９に示す方法例に関して述べるように、サーバネットワークに追加サーバが導入される。

図９は、追加サーバの導入によって、ネットワークサーバ負荷を再平衡化する方法の例のフローチャートを示す。

ステップ９０２において、既存のサーバネットワーク内において用いられているデータベースに対応するデータベースまたはデータベースの複製が、追加サーバにインストールされる。

ステップ９０４において、オプショナルマスタデータベース２０４（図２）を、ネットワークに加えられた新たなサーバによってアクセス可能であるように設定する。このオプショナルマスタデータベース２０４は、前もって、ネットワーク内の全てのサーバに関して、利用可能であるように設定されていてもよい。

ステップ９０６において、サーバネットワークに送出された全てのクエリを受信するように、追加サーバが構成される。図２に示される例において、ユーザのクエリは、通信ネットワーク２２０（図２）を通じて、ネットワーク内の全てのサーバに宛てられる。また別の実施形態においては、クエリ、かつ／またはクエリの通知は、そのネットワークを構成するサーバのサブセットへと通信される。

ステップ９０８において、ルックアップテーブル例５００（図５）のような、ルックアップテーブルが、追加サーバにインストールされるか、または追加サーバによってアクセス可能であるように設定される。ルックアップテーブル例５００の列５１０に示されるように、ルックアップテーブルには、追加サーバの存在が反映されている。

ステップ９１０において、サーバネットワークへの追加サーバは、ステップ９０８で述べた修正ルックアップテーブルをチェックするように、構成される。

ステップ９１２において、ネットワークへの追加サーバは、クエリを処理するように、構成される。

ステップ９１４において、ネットワークへの追加サーバは、ネットワーク内の他のサーバによるクエリの処理をモニタするように構成される。

ステップ９１６において、ネットワークへの追加サーバは、ユーザに、クエリ結果を送信するように構成される。

ステップ９１８において、そのネットワークへの追加サーバは、ネットワークを通じて送出される次のクエリに備えて、現在の（ｐｒｅｓｅｎｔ）応答時間をリセットするように、構成される。

以上、実施例を参照して本発明を説明した。本発明のより広い範囲を逸脱することなく、様々な修正が可能であること、また他の実施形態を用いることが可能であることは、当業者には理解されるところである。したがって、実施形態に関するこれらの、またこの他の変形例も、本発明の範囲に含まれることが意図されている。

Claims (13)

1. 冗長サーバネットワークであって、
   複数のサーバを備え、該複数のサーバはそれぞれ、
   サーバにおけるクエリ処理中にアクセスされる一以上のセグメントを格納するデータベースの複製を含み、
   少なくとも前記データベースの一部について責任を割り当てられており、
   通信ネットワークに接続され、ユーザにより作成されたクエリを受信し、
   前記ユーザにより作成されたクエリをルックアップテーブルの記述に従って処理し、
   クエリ結果を前記ユーザによって作成されたクエリを出したユーザに送信し、
   前記複数のサーバはそれぞれ、前記クエリが正常に終了すると、次のユーザ作成クエリを処理するためにリセットされ、
   本冗長サーバネットワークはさらに、
   メモリに格納されるルックアップテーブルであって、ユーザによって作成され、前記複数のサーバの各々に通信されるクエリを受信した際のサーバにおけるクエリ処理を定義するためのルックアップテーブルを備え、該ルックアップテーブルは前記複数のサーバの各々からアクセス可能であり、該ルックアップテーブルは各サーバにユーザにより作成されたクエリを処理するための割当時間を割り当て、該ルックアップテーブルは前記複数のサーバに対して１重の冗長レベルを構築し、
   前記１重の冗長レベルは、
   前記複数のサーバのうち、前記ユーザにより作成されたクエリを処理する主要な責任を割り当てられた第１のサーバであって、該ユーザにより作成されたクエリ処理について１番目の責任を負う第１のサーバと、
   前記複数のサーバのうち、前記ユーザにより作成されたクエリを処理する二次的な責任を割り当てられた第２のサーバであって、前記第１のサーバをモニタする他のサーバが、割り当てられた時間内に前記クエリが処理されたことを検出しなかった場合に、前記ユーザにより作成されたクエリを処理するための２番目のサーバである第２のサーバと、を含む冗長サーバネットワーク。
2. 前記ユーザにより作成されたクエリは、マルチキャスト送信によって前記複数のサーバの各々において受信される請求項１に記載の冗長サーバネットワーク。
3. 前記ユーザにより作成されたクエリは、ブロードキャスト送信によって前記複数のサーバの各々において受信される請求項１に記載の冗長サーバネットワーク。
4. 前記ユーザにより作成されたクエリの処理の終了をモニタするプログラムロジックコントローラをさらに備える請求項１に記載の冗長サーバネットワーク。
5. 前記第１のサーバに割り当てられた、前記ユーザにより作成されたクエリの処理に対する主要な責任と、前記第２のサーバに割り当てられた、前記ユーザにより作成されたクエリの処理に対する二次的な責任とは異なる請求項１に記載の冗長サーバネットワーク。
6. 前記クエリは、クエリ結果の前記ユーザへの送信を要求する請求項１に記載の冗長サーバネットワーク。
7. 前記クエリは、計算による特定の値の決定を要求する請求項１に記載の冗長サーバネットワーク。
8. 前記クエリは、該通信ネットワークに接続された中間サーバを介して前記複数のサーバのそれぞれによって受信され、
   前記中間サーバは、前記ユーザにより作成されたクエリを処理する責任を負わない請求項１に記載の冗長サーバネットワーク。
9. 前記中間サーバは、前記複数のサーバに分配するクエリの待ち行列を保持する請求項８に記載の冗長サーバネットワーク。
10. 複数のサーバーを含むサーバネットワークに、ユーザにより作成されたクエリの処理方法を提供させるプログラムであって、
    サーバネットワークが、前記複数のサーバのそれぞれによってアクセス可能なルックアップテーブルに基づいて、第１のサーバに、ユーザにより作成されたクエリの処理に対する主要な責任を割り当てるステップと、
    サーバネットワークが、前記複数のサーバのそれぞれによってアクセス可能なルックアップテーブルに基づいて、第２のサーバに、ユーザにより作成されたクエリの処理に対する二次的な責任を割り当てるステップと、
    サーバネットワークが、第１のサーバに、前記複数のサーバに接続された通信ネットワーク経由でユーザにより作成されたクエリを受信した際に該クエリの処理を実行するための時間を割り当てるステップと、
    前記第１のサーバに前記ユーザにより作成されたクエリを処理するために割り当てられた時間が、該クエリが前記第１のサーバによって処理されることなく満了した場合、サーバネットワークが、ユーザにより作成されたクエリの処理に対する二次的な責任を有する第２のサーバに、ユーザにより作成されたクエリの処理を指示するステップと、
    を備え、
    前記ユーザにより作成されたクエリの処理に対する主要な責任を割り当てられた第１のサーバは、ユーザにより作成されたクエリの処理に対して、１番目の責任を負うサーバであり、
    前記ユーザにより作成されたクエリを処理する二次的な責任を割り当てられた第２のサーバは、前記第１のサーバをモニタする他のサーバが前記割り当てられた時間内に前記クエリが処理されたことを検出しなかった場合に、前記ユーザにより作成されたクエリを処理するための２番目のサーバである方法を提供するプログラム。
11. サーバの冗長ネットワークに新たなサーバを導入する方法であって、
    前記冗長ネットワーク内の既存の各サーバにインストールされているデータベースと同じデータベースであって、サーバにおけるクエリ処理中にアクセスされる一以上のセグメントを格納するデータベースを、前記新たなサーバにインストールするステップと、
    前記サーバの冗長ネットワークに送出されたユーザにより作成されたクエリの全てを受信するように、前記新たなサーバを構成するステップと、
    メモリに格納されるルックアップテーブルを介して、主要なおよび二次的な処理責任を前記新たなサーバに割り当てるステップとを備え、
    前記ルックアップテーブルは、前記サーバの冗長ネットワーク内の各サーバからアクセス可能であり、各サーバにユーザにより作成されたクエリを処理するための割当時間を割り当て、該ルックアップテーブルは前記複数のサーバに対して１重の冗長レベルを構築し、
    前記１重の冗長レベルは、
    前記複数のサーバのうち、前記ユーザにより作成されたクエリを処理する主要な責任を割り当てられた第１のサーバであって、該ユーザにより作成されたクエリ処理について１番目の責任を負う第１のサーバと、
    前記複数のサーバのうち、前記ユーザにより作成されたクエリを処理する二次的な責任を割り当てられた第２のサーバであって、前記第１のサーバをモニタする他のサーバが前記割り当てられた時間内に前記クエリが処理されたことを検出しなかった場合に、前記ユーザにより作成されたクエリを処理するための２番目のサーバである第２のサーバと、を含む方法。
12. ネットワーク内の複数のサーバ間の冗長性を構築する方法であって、
    前記複数のサーバそれぞれに、サーバにおけるクエリ処理中にアクセスされる一以上のセグメントを格納するデータベースの複製をインストールするステップと、
    前記複数のサーバの各々が、該複数のサーバの各々に通信されるユーザにより作成されたクエリを受信した際のサーバにおけるクエリ処理を定義するためのルックアップテーブルにアクセスするように構成するステップと、
    前記ルックアップテーブルの記述に従って、前記クエリを処理するステップとを備え、
    前記ルックアップテーブルは、メモリに格納され、前記複数のサーバの各々からアクセス可能であり、該ルックアップテーブルは各サーバにユーザにより作成されたクエリを処理するための割当時間を割り当て、該ルックアップテーブルは前記複数のサーバに対して１重の冗長レベルを構築し、
    前記１重の冗長レベルは、
    前記複数のサーバのうち、前記ユーザにより作成されたクエリを処理する主要な責任を割り当てられた第１のサーバであって、該ユーザにより作成されたクエリ処理について１番目の責任を負う第１のサーバと、
    前記複数のサーバのうち、前記ユーザにより作成されたクエリを処理する二次的な責任を割り当てられた第２のサーバであって、前記第１のサーバをモニタする他のサーバが前記割り当てられた時間内に前記クエリが処理されたことを検出しなかった場合に、前記ユーザにより作成されたクエリを処理するための２番目のサーバである第２のサーバと、を含む方法。
13. ユーザにより作成されたクエリの処理方法であって、
    ネットワーク内の複数のサーバのそれぞれにおいてユーザにより作成されたクエリを受信するステップと、
    前記複数のサーバのそれぞれによりアクセス可能なルックアップテーブルによって指定される通りに、前記複数のサーバのうちから、前記ユーザにより作成されたクエリを処理する主要な責任を有するサーバを特定するステップと、
    前記複数のサーバのうち、前記ルックアップテーブルによって、前記ユーザにより作成されたクエリを処理する主要な責任を有すると指定されたサーバにおいて、該クエリを処理するステップと、
    前期ルックアップテーブルによって、前記ユーザにより作成されたクエリを処理する主要な責任を有すると決定されたサーバにおける該ユーザにより作成されたクエリの処理を、モニタするステップとを備え、
    前記ルックアップテーブルはメモリに格納され、該ルックアップテーブルは
    前記複数のサーバの各々にユーザにより作成されたクエリを処理するための割当時間を割り当て、該ルックアップテーブルは前記複数のサーバに対して１重の冗長レベルを構築し、
    前記１重の冗長レベルは、
    前記複数のサーバのうち、前記ユーザにより作成されたクエリを処理する主要な責任を割り当てられた第１のサーバであって、該ユーザにより作成されたクエリ処理について１番目の責任を負う第１のサーバと、
    前記複数のサーバのうち、前記ユーザにより作成されたクエリを処理する二次的な責任を割り当てられた第２のサーバであって、前記第１のサーバをモニタする他のサーバが前記割り当てられた時間内に前記クエリが処理されたことを検出しなかった場合に、前記ユーザにより作成されたクエリを処理するための２番目のサーバである第２のサーバと、を含むクエリ処理方法。

Images