(57)【特許請求の範囲】
【請求項１】
サービス・グループの中の１つのホストから複数の他のホストの中の任意のホストにコンピュータ・サービスへの再割り当てを生じさせるコンピュータ・ネットワーク・システムであって、
前記サービス・グループの中の第１のホストに、前記サービス・グループに割り当てられたインターネット・プロトコル（ＩＰ）アドレスであるサービス・グループ・アドレスを介して、前記第１のホストの状態に関するメッセージを送信させる手段と、
前記サービス・グループの中の第２のホストに、前記サービス・グループ・アドレスを介して、少なくとも１つの他のホストからの少なくとも１つのメッセージを受信させる手段と、
コンピュータ・サービスを取得する又はリリースするとの少なくとも１つのメッセージに応答する手段と、
を備えていることを特徴とするコンピュータ・ネットワーク・システム。
【請求項２】
請求項１記載のコンピュータ・ネットワーク・システムにおいて、コンピュータ・サービスを取得する又はリリースするとの前記メッセージは、前記サービス・グループの中の別のホストの故障の結果であることを特徴とするコンピュータ・ネットワーク・システム。
【請求項３】
請求項１記載のコンピュータ・ネットワーク・システムにおいて、コンピュータ・サービスを取得する又はリリースするとの前記メッセージは、前記サービス・グループの中の負荷均衡の結果であることを特徴とするコンピュータ・ネットワーク・システム。
【請求項４】
コンピュータを、請求項１から請求項３までのいずれかの請求項に記載されたコンピュータ・ネットワーク・システムに含まれる手段のそれぞれとして機能させるコンピュータ・プログラム。
【請求項５】
計算サービスをネットワークの中の様々なホスト・コンピュータに動的に再割り当てする方法であって、
それぞれが計算サービスを提供することができる複数のホスト・コンピュータから構成されるサービス・グループを確立するステップであって、前記サービス・グループにはインターネット・プロトコル（ＩＰ）アドレスが割り当てられ、よって、前記複数のホスト・コンピュータの中の１つが使用可能である限りは前記計算サービスが使用可能である、ステップと、
計算サービスに対する責任を、前記サービス・グループの中の第１のホスト・コンピュータに割り当てるステップと、
前記サービス・グループを構成するホスト・コンピュータの間で、前記サービス・グループに割り当てられたＩＰアドレスであるサービス・グループ・アドレスを介して、少なくとも前記第１のホスト・コンピュータの状態を表すメッセージを周期的に送信するステップと、
前記サービス・グループの中の残りのホスト・コンピュータから、前記サービス・グループ・アドレスを介して、これらの残りのホスト・コンピュータの状態を表すメッセージを受信するステップと、
前記メッセージの存在又は不存在とその内容とを評価するステップと、
前記評価に応答して、前記サービス・グループの中の別のホストに、前記計算サービスに対する責任を再割り当てするステップと、
を含むことを特徴とする方法。
【請求項６】
請求項５記載の方法において、前記再割り当てステップは、前記ホスト・コンピュータの中の１つからのメッセージの欠如の結果であることを特徴とする方法。
【請求項７】
請求項５記載の方法において、前記再割り当てステップは、前記サービス・グループの中の負荷均衡の結果であることを特徴とする方法。
【請求項８】
複数のホストを含むネットワークの中で、計算サービスの動的な再配分を提供する装置であって、
それぞれが所望の計算サービスを提供するのに使用可能である少なくとも３つである複数のホストを含むサービス・グループであって、前記少なくとも３つのホストのそれぞれにはインターネット・プロトコル（ＩＰ）アドレスが割り当てられ、よって、前記少なくとも３つのホストの中の１つが使用可能である限りは前記計算サービスが使用可能である、サービス・グループと、
前記少なくとも３つのホストのそれぞれの状態に関するデータを、サービス・グループ・アドレスを介して提供するように構成されているメッセージ部分と、
前記メッセージ部分に応答して、前記計算サービスのそれぞれに対する責任を、サービス・グループ・アドレスを介して前記サービス・グループの中の任意のホストに割り当てるように構成されているリーダ部分と、
を備えていることを特徴とする装置。
【発明の詳細な説明】
発明の分野
本発明は、コンピュータ・システムのネットワーク内部でのサービスを管理するシステム及び方法に関し、特に、そのようなネットワーク内部での負荷の均衡化とホスト・フェールオーバとに関する。
発明の背景
信頼できるコンピュータ・サービスを提供する際には、特に、ＨＴＴＰ、ＦＴＰ、ニューズおよびメールなどのインターネット・アプリケーションに関する場合には、基本的な要求は、これらのサービスのためのスケーラブルであり信頼できるプラットフォームである。
スケーラビリティには、垂直的なものと水平的なものという２つの種類がある。垂直的なスケーラビリティは、１９７０年代と１９８０年代のＩＢＭパラダイムによって最も良く特徴付けられる。このパラダイムでは、コンピュータ・サービスに対するある企業の必要性が増大するということは、パワーの劣るコンピュータをそれよりもパワーの大きなコンピュータと全体として交換するということを意味する。このパラダイムは、多くの理由のために、その評価が実質的に低下している。理由には、このパラダイムが、最もパワーのあるハードウェアにそれがどのようなものであっても制限され、そのようなマシンの費用のために、実現不可能となるという事実が含まれる。そのようなマシンは、本来的に、値段・パフォーマンス比において最適ではない。１つのマシンという点で信頼性が欠如していることも、垂直的なスケーラビリティにおける主な制限である。
対照的に、水平的なスケーラビリティは、負荷が増加するにつれて、より多くのコンピュータ・システムを追加することになる。これらのコンピュータは、それぞれが、垂直的なスケーラビリティに関する解決策よりもパワーが劣るのが典型的であるが、そのようなシステムを複数組み合わせたパワーは、多くのアプリケーションに関して、垂直的な解決策の有するパワーを超えることが多い。また、水平的な解決策は、ユーザが、それまでの投資（すなわち、まだ互換性を有しているシステムのそれまでの購入）の費用・便益を最大化することを可能にする。水平的なスケーラビリティは、従って、垂直的なスケーラビリティと比較して、多くの重要な長所を提供すると考えることができる。
信頼性は、水平的なスケーラビリティによる解決策によって、最も良く与えられる。信頼性は、必要とされる場合におけるコンピュータ・サービスの利用可能性によって測定される。どのようなコンピュータであっても、１台で１００％の使用可能時間を有することはないことがわかっているので、信頼性のために、必要とされるコンピュータ・サービスを提供することができる複数のコンピュータが要求される。
連続的に使用可能なコンピュータ・サービスに対する必要性が大きくなるにつれて、スケーラビリティと信頼性との増大に対する必要性もまた、大きくなってきた。重要な問題の１つとして、通常はホストと称される第１のコンピュータによって提供されるサービスが、このホストが使用不可能になったときには、別のコンピュータすなわちバックアップによって提供され得ることを保証することである。このようなサービスの移転は、フェールオーバ（failover）と称され、現在のシステムでは、ソフトウェアによって取り扱われるのが一般的である。
従来技術においては、２つのフェールオーバの方式が広く知られている。一対一のフェールオーバは、ホスト・システムを一次システムと指定し、バックアップ・システムを二次システムと指定する。このアプローチにおける最も古典的な実現例では、ホストが故障するまで、二次システムはアイドル状態であり、サービスを提供しない。ホストが使用不可能になると、二次システムが、通常はホストによって提供されているサービスを提供する。対称的な一対一のフェールオーバは、これと類似の技術であって、両者が使用可能であるときには、「ホスト」システムと「バックアップ」システムとのそれぞれが、別個であるが有益なサービスの組を提供し、共に、他方のシステムによって通常提供されるサービスは、それ自身が提供することができる。従って、それぞれのシステムは、同時に一次システムであり二次システムであるのだが、一方のマシンだけが他方に対するバックアップとして機能することができる。
従来技術において知られている第２のフェールオーバ方式は、多対一のフェールオーバである。このアプローチでは、多くの一次システムが存在するが、二次システムはただ１つであり、一次システムは、それぞれが、別個の組のサービスを提供する。二次すなわちバックアップ・システムは、一次システムのどれか又はすべてによって提供されるサービスであれば、どれでも実行することができるが、一次システムが１つ故障するまでは、通常は、アイドル状態のままである。
これらの方式には、それぞれに、故障するのがただ１つのシステムである限りでネットワークは信頼できるのであって、複数のシステムが使用不可能になると、ネットワーク・サービスは使用不可能となるという点で、制限がある。更に、これらのシステムでは、二次システムは、当初のコンフィギュレーションにおいて識別されなければならず後で変更することはできないのが典型的であるから、よいフェールオーバのスケーラビリティが不可能である。これと同じ方向の問題であるが、従来技術のシステムは、故障したホストは永久に再インストールできず、また、既存のホストを再構成することなく、新たなホストを追加したり構成したりすることもできない。このような従来技術による方法には、負荷の平衡化を行うことができないという制限もある。
従って、複数のホスト又は一次システムが故障したときであっても計算サービスがネットワーク上で利用可能であり続け、ネットワークを形成するシステムの残りの部分を再構成することなくホストを追加したり削除したりが可能であるような改良されたフェールオーバ・システムに対する必要性が存在している。
発明の概要
本発明は、計算サービスがグループ内の複数のシステムの中の任意のものによって提供され得るようなシステムおよび方法を提供し、少なくとも１つのシステムがそのグループの中で利用可能である限り、そのグループによって提供される計算サービスが引き続いて利用可能となるようにすることによって、従来技術のすべての制限を仮想的に克服する。このシステム及び方法は、ＩＰアドレスのホストとサービスとへの割り当てと、これらのＩＰアドレスを管理して以下で述べる機能を達成することとを含む。
多対多のフェールオーバを提供するために、複数のホストがサービス・グループに属するように構成され、それぞれのホストが、そのサービス・グループによって与えられるサービスを提供することができるようになっている。それぞれのホストは、また、他のサービスを提供するようにも利用可能であり、従って、他のグループのメンバーとなることもできる。任意の与えられた時点で、サービスは、サービス・グループのアクティブなメンバーのどれによっても提供され得る。従って、グループ内での通信を維持し、様々なホストの協動を調整することによって、故障や負荷の不均衡などの理由で、サービスを提供する１又は複数のホストが時として利用不可能になった場合であっても、そのグループによって提供されるサービスが利用可能なままに維持されることを保証することが重要である。
サービス・グループ内のホストの間の通信を維持するために、それぞれのホストは、そのグループ内の他のホストすべてに「制御メッセージ」を周期的に送る。制御メッセージは、「情報メッセージ」として、又は、目的によっては、「心拍」として考えることができる。制御メッセージは、基本的には、そのグループ内の他のホストの知覚された状態に関するデータに関してだけではなく、送出側のホストとしての状態に関しても、ホストを相互に評価さされている状態に維持する。
サービス・グループ内の様々なホストの協動を調整するために、リーダとなるホストが確立され、様々なホストに、特定のサービス・アドレスに対する責任を割り当てる。リーダは、対応されていないサービス・アドレス（例えば、ＩＰアドレス）などのリソースを識別して、そのようなリソースが指定されたホストによって取得されるようにする。リーダは、また、そのサービス・グループに新たに追加されたり復帰したホストに、リソースを動的（ダイナミカル）に再割り当てしたり、故障したホストが扱っていたリソースをリリース（解放）する。
負荷の平衡化も、本発明によって、利用（utilization）を測定しドメイン・ネーム・サービス（ＤＮＳ）ゾーンにおけるエントリのラウンド・ロビン式のローテーションを用いることによる統計的な負荷の均衡化を行うか、ＤＮＳゾーンの修正を行うかによって、達成することができる。
利用は、負荷（例えば、アイドル状態でない秒当たりの命令で表現される）を現在の能力（典型的には、１秒当たりの命令によって表現される）で除算した比として決定され、それぞれのホストに対して、サービスに特定のモジュールによって計算される。というのは、１つのホストによってサポートされているそれぞれのサービスは、異なる負荷と能力とを有していることがありうるからである。利用と予め設定された最大の利用設定（高い水位標（high water mark）と称される）とを比較することによって、ホストの利用が高い水位標を超えている場合には、新たな接続を負荷のより少ない他のホストにシフトすることによって、負荷の分散（shedding）を開始させることができる。ホストの利用が予め設定された最小の利用（又は、低い水位標）よりも下まで低下するときには、そのホストを再びＤＮＳゾーンに再び追加することができる。
ＤＮＳゾーンの修正は、ＤＮＳゾーンに存在しなければならない利用可能なサービス・アドレスの最小の数を特定するコンフィギュレーション・パラメータを確立することによって、負荷の均衡化に用いることができる。このようなアプローチによれば、高い水位標を超える高負荷のホストはそのまま利用可能なものとして識別され続けることができる。
本発明によるシステムのそれ以外の特徴には、ホストをホット・スペア（hotspare）として維持する、つまり、ホストがサービス・アドレスを取得することを防止する、すなわち、ホストを「クイースした（休止した、quiesced）」状態に維持することと、ホスト全体の故障又はサービスの故障どちらかに対する故障検出とが含まれる。
上述のような態様で、本発明によるサービス・アドレスの管理は、新しい新規な態様で計算サービスを提供することがわかる。この及び追加的な効果は、以下の発明の詳細な説明と、添付の図面とから理解できるはずである。添付の図面では、本発明の実施例が図解されており、本発明の原理を説明する機能を有している。
図面
図１Ａは、本発明に従って様々なオブジェクト・タイプを扱うホスト内でのＲＡＩＳデーモン（daemon）の動作を、ブロック図形式で示している。
図１Ｂは、様々なサービス・モニタからその関連するテスト・オブジェクト及び負荷オブジェクトへのリンクを示す。
図２Ａは、複数のサービス・グループから構成されているネットワークをブロック図形式で示している。
図２Ｂは、制御情報メッセージのデータ構造を示している。
図２Ｃは、ホスト情報エントリのデータ構造を示している。
図２Ｄは、サービス・アドレス・データベースのデータ構造を示している。
図３は、サービス・モニタの「送信」スレッドを流れ図形式で示している。
図４Ａは、サービス・モニタの「受信」スレッドを流れ図形式で示している。
図４Ｂは、受信スレッドの「取得」メッセージ部分を流れ図形式で示している。
図４Ｃは、受信スレッドの受信メッセージ部分を流れ図形式で示している。
図４Ｄは、受信スレッドの「更新テーブル」部分を流れ図形式で示している。
図５Ａは、サービス・モニタの「スクリプト」スレッドを流れ図形式で示している。
図５Ｂは、スクリプト・スレッドの取得作用（acquire action）部分を流れ図形式で示している。
図５Ｃは、スクリプト・スレッドの「リリース作用」部分を流れ図形式で示している。
図６Ａは、サービス・モニタの「制御」スレッドを流れ図形式で示している。
図６Ｂは、制御サービス・アドレス・テーブルのデータ構造を示している。
図６Ｃは、利用と重み付けされた利用とを示すテーブルのデータ構造を示している。
発明の詳細な説明
本発明は、１つのグループ内にある複数のシステムの中の任意のシステムが計算サービスを提供することによって、そのグループ内の少なくとも１つのシステムが使用可能である限り、そのグループが提供する計算サービスが継続的に使用可能であり続けるようになる、システム及び方法を提供する。本発明は、特に、独立サーバの冗長アレイ（Redundant Array of Independent Servers）ＲＡＩＳ上での動作に適している。
更に、本発明によれば、既存のホストを再構成せずに、新たなホストを追加したり構成したりすることが可能となる。そして、本発明のシステムは、新たなホストを適切なグループの中に動的かつ自動的に組み入れる。同様にして、故障したホストを、それ以外のホストを再構成することなく、取り除くことができる。
このような改良は、複数のコンピュータ・システムのＩＰアドレスを適切に管理することによって達成される。ここでの複数のコンピュータ・システムとは、それぞれが、ネットワークから使用可能な計算サービスのためのサービス・プロバイダと考えることができる。それぞれのコンピュータ・システム、すなわち、ホストには、従来型の態様で一意的なＩＰアドレスが割り当てられているが、これらのＩＰアドレスは、所望のサービスのプロバイダに従って、グループに分けられる。従って、グループのそれぞれのメンバーは、そのサービスの提供に使うことができる。ホストのこの集まりは、「サービス・グループ」と称され、１つのサービス・グループに属するメンバーは、協動してある特定のサービスを提供する。１つのホストは、複数のサービス・グループに属することが可能である。しかし、明瞭性と簡潔性を維持するために、以下の議論では、１つのサービス・グループに属するホストの間での相互作用についてのみ説明することにする。
サービス・グループに属する様々なメンバーの間での調整（coordination）を維持するためには、「サービス・グループ」のアドレスを確立し、それを、単純に、そのグループのＩＰアドレスとする。そのサービス・グループのすべてのメンバーは、サービス・グループのアドレスを用いて、相互に通信する。すなわち、それぞれのメンバーは、そのサービス・グループの他のすべてのメンバーに対して、メッセージをそのサービス・グループのアドレスにアドレシングすることによって、メッセージを送信する。また、それぞれのメンバーは、そのサービス・グループのアドレスに向けられたメッセージを受信することによって、そのサービス・グループの他のすべてのメンバーからのメッセージを受信する。これらのメッセージは、「制御メッセージ」と考えることができ、そのメッセージを提供しているホストが故障していないこと、それぞれのサービス・アドレスの状態、サービス・グループのメンバーによって実行される作用、そして、そのメッセージング能力に提供している他の任意の機能を通信する。
信頼性を向上させるために、複数の冗長ハードウェア・ネットワーク・インターフェースを、ホストが用いるために提供することができる。これらのインターフェースは、「制御インターフェース」と称するが、ホストが制御メッセージを送受信するための手段を提供する。「サービス・ネットワーク・インターフェース」と称するネットワーク・インターフェースも存在し、このネットワーク・インターフェースは、クライアントが、ホスト上のサービスと通信することを可能にする。従って、サービス・ネットワーク・インターフェースは、単に、ホスト上のサービスにアクセスするためにクライアントによって用いられるネットワーク・インターフェースである。ネットワーク・インターフェースは、サービス・インターフェースと制御インターフェースとの両方でありうるが、現に好適な構成では、それぞれのホストは、典型的には、それぞれが独立で孤立したネットワークに接続されている、少なくとも２つの制御インターフェースを有している。
ここで用いている「制御アドレス」とは、制御インターフェースのＩＰアドレスを意味する。それぞれのホストは、好ましくは、１又は複数の制御アドレスを有し、典型的には、少なくとも１つの制御インターフェースを有していなければならない。第１の制御アドレスは、典型的には、関連するホストを一意的に識別するのに用いられるが、以後は、「ｈｏｓｔ  ｉｄ」又は「ｉｄ＿ａｄｄｒｅｓｓ」と称する。制御アドレスは、ホストがグループ・メッセージを送受信するのにどのインターフェースを用いるべきであるのかを識別する。
サービス・アドレスは、サービス・グループにおけるホストがそれを介してサービスを提供するＩＰアドレスである。このサービス・アドレスの管理が、本発明の中心的な部分である。
新たなホストがサービス・グループに対して使用可能となると、このホストは、サービス・グループに、ｈｏｓｔ  ｉｄとサービス・アドレスとの両方を導入する。サービス・アドレスは、このホストが故障しない限り、このホストに関連付けされる、又は、このホストに属し、このホストに対する好適なサービス・アドレスとして知られることになる。
既に述べたように、サービス・グループ内のそれぞれのホストは、サービス・グループのアドレスを介して、サービス・グループに制御（又は、情報）メッセージを周期的に送信する。それぞれの情報メッセージは、ホスト制御アドレスの組と、その好適なサービス・アドレスと、現にサービスを与えているサービス・アドレスの組とを、それ以外のものに加えて含む。これらのメッセージにより、サービス・グループのメンバーは、サービス・グループにおけるそれぞれのホストの状態を判断することができる。
制御メッセージの別の機能として、サービス・グループ内のホストが、ホストを１つ選択して、そのサービス・グループの「リーダ」としての論理的役割を満足させることを可能にすることがある。リーダの役割は論理的なものであるから、この役割は、ホストが追加されたり除去されたりするときを含む様々な時点において、あるホストから別のホストに移動することがある。ある実施例では、最低のｈｏｓｔ  ｉｄを有しているホストがリーダに指名される。ただし、これ以外の方法も採用することが可能である。
サービス・グループのリーダは、グループ内のサービス・アドレスを管理する。他のタスクに加えて、リーダは、平衡状態にある様々な条件を確立することを試みる。これには、すべてのサービス・アドレスにサービスが与えられていること、それぞれのサービス・アドレスがただ１つのホストに割り当てられていること、それぞれのホストがその好適なサービス・アドレスにサービスを与えていることが含まれる。リーダは、また、これらの条件の違反がある場合には、典型的には、ホストに、サービス・アドレスを与えさせる又はサービス・アドレスを与えることを停止させるようにすることによって、訂正作用を開始する。これは、「取得（aquiring）」又は「リリース（解放、releasing）」と考えることができる。サービス・アドレスのこのような取得及びリリースによって、あるサービス・グループ内に含まれるホストは、すべてのアドレスにサービスが提供されていることを保証する。更に、本発明は、ゾーン・ファイルを修正しゾーン・ファイル変更をＤＮＳサーバに告知することによって、ドメイン・ネーム・サービス・バインディングを修正する能力を有している。この点は、上述の関連特許出願の部分に番号（１）として識別された同時出願の米国特許出願に記載されている。ドメイン・ネーム・ゾーンは、また、インターネットのＲＦＣのページ１０３４及び１０３５において、詳細に論じられている。基本的には、ゾーンとは、１つの共通の親（parent）を有するＩＰアドレスのグループである。ただし、ゾーンは、子のアドレス、すなわち、それよりも下位レベルのノードをすべて含むとは限らない。
リーダは、また、サービス・アドレスの割り当てに関して、唯一責任を負っている。従って、システムに追加されたホストに好適なサービス・アドレスが与えられている場合でも、リーダがそれを割り当てるまでは、そのホストはそのサービス・アドレスを有していることにはならない。リーダは、制御メッセージの内容を知り、新たに加わったホストによって導入された好適なサービス・アドレスを、サービス・グループ内の別のホストによって現に用いられている場合には、直ちにリリースする。好適なサービス・アドレスがどのホストにも用いられていない場合には、リーダは、単に、それを新たなホストに割り当てる。
新たなホストの好適なサービス・アドレスが既に別のホストに割り当てられているというケースは、先に故障したホストが今回グループに復帰しているような場合に生じるのが通常である。そのような状況では、リーダは、その好適なサービス・アドレスを現に有しているホストにそれを開放するように要請し、リリースの要請が完了するまで待機して、その好適なサービス・アドレスを参加しようとしている新たなホストに割り当てる。
ホストが故障すると、リーダは、元々がその故障したホストが使用していたサービス・アドレスがアクティブに使用されてはいないことを検出する。というのは、制御メッセージは、そのサービス・アドレスが用いられた直前の時点からますます長い期間を示すからである。次に、リーダは、これらの用いられていないアドレスを、グループ内の他の使用可能なホストに割り当てる。割り当てはランダムに行われる、又は、負荷均衡化方式に基づいて、又は、他の任意の適切な方法を用いて行われる。
サービス・アドレスを再割り当てすることによって、故障したホストをサービス・グループから取り除くことができる。その好適なホストに割り当てられていないサービス・アドレスは、「孤児（orphaned）」サービス・アドレスと称される。それぞれの孤児サービス・アドレスには、リーダによって維持される論理的なカウントダウン・タイマが関連している。このカウントダウン・タイマは、アドレスが孤児になるときに作成され開始され、それが終了すると、サービス・アドレスは無効になる。サービス・アドレスが無効になると、リーダは、ホストが未知のサービス・アドレスを用いていることを認めて、そのホストにそのサービス・アドレスのリリースを要求する。
一体化した（integrated）ネーム・サービス（後に論じる）は孤児であるサービス・アドレスを公表しないので、その孤児であるアドレスは、ネーム・サービスを介して新たなクライアントを取得することはない。孤児であるアドレスのクライアントが時間経過と共にログアウト又は切断すると、孤児であるサービス・アドレスの側からの必要性は結果的になくなり、そのアドレスを無効にする又は除去することができる。アドレスのそのような自動的な除去を生じさせることが好ましくない場合には、カウントダウン・タイマに非常に大きな値、例えば、何年もの範囲の値を与えることができる。
上述した一体化したネーム・サービスとは、ゾーン・ファイルを修正しＤＮＳサーバにゾーン・ファイルの変更を告知することによって、ＤＮＳバインディングを修正することができるという本発明の能力を意味する。上述の関連出願の部分にある出願、特に、Swee Boon Limによって１９９６年７月１日に出願された″A Service For a Redundant Array of Internet Server″と題する米国特許出願第08/673,951号を参照のこと。
ＤＮＳサーバのホストであるホストがサービス・グループのメンバーについて知ることを確実にするためには、それは、サービス・グループにも属していなければならない。そのグループのサービスを提供する場合には、それは、通常の態様でメッセージを受信する。提供しない場合には、それはグループに加わることができるが、それ自身を単純に故障していると識別する。このようにして、それは適切なメッセージを受け取るが、リーダによってサービス・アドレスを割り当てられることはない。本発明の好適実施例では、それぞれのサービス・グループは、それ自身のＤＮＳゾーンを有する。この要件により、元のサービス・グループから単一のＤＮＳゾーン・ファイルへのＤＮＳの変更が分離される。更に、ＤＮＳゾーンは、使用可能なメンバーの好適なサービス・アドレスだけが公表されるように、設定される。孤児であるサービス・アドレスが取得できないので、孤児であるサービス・アドレスは、上述のように消え去ることになる。
負荷の均衡化は、本発明のもう１つの重要な側面である。２つの技術、すなわち、統計的な負荷均衡化と、ゾーン修正とが、組み合わされて用いられる。ゾーン修正による負荷均衡化を用いるには、情報メッセージは、２つの値を含む。一方は現在の負荷であり、他方は現在の能力（capacity）である。現在の能力は、典型的には、１秒当たりの命令で表現される。現在の負荷は、典型的には、１秒当たりのアイドル状態ではない命令の数で表される。これらは共に、適当な期間に亘って測定される。ネットワークの帯域幅集中（intensive）サービスでは、能力は、サービス・インターフェースの最大の帯域幅となることがあり、他方で、負荷は、直前の測定期間の間に消費された平均の帯域幅でありうる。
利用（utilization）は、単純に、負荷を能力で除算することにより決定される。オペレータの構成による高い水位標を確立することができ、与えられたホストが利用に対する高い水位標を超える場合には、そのホストは、ほとんどの状況においてＤＮＳゾーンから除去することができる。これにより、新たな接続は、利用のより少ない他のホストにシフトされる。ホストの利用がオペレータが構成した低い水位標より下まで低下すると、ホストはＤＮＳゾーンに再び追加され、新たなアドレスの割り当てに関して使用可能となる。
コンフィギュレーション・パラメータもまた提供され、ＤＮＳゾーンに存在しなければならない使用可能なサービス・アドレスの最小の数を特定し、すべての好適なサービス・アドレスがそのゾーンから除去されることを防止する。使用可能なアドレスの数がこの最小値よりも少なくなるのを回避するために、頻繁に用いられているホストを公表することもできる。
サービス・アドレスを適切に管理することにより、様々なネットワーク機能を管理することができる。例えば、ホット・スペアリング（hot sparing）、クイーシング（quiescing）、故障検出などである。ホット・スペアリングは、別のホストが故障したときにのみ、ホストがサービス・プロバイダとして指定されることに関する。すなわち、本質的には、そのようなデバイスは、故障したホストとその好適なサービス・アドレスとの代理である。ホット・スペア・ホストは、好適なサービス・アドレスを有していないが、その代わりに、それが使用可能であると告げる情報メッセージを送出する。これによって、リーダは、必要な場合には、サービス・アドレスをホット・スペアに割り当てることができる。特に、リーダは、典型的には、孤児であるサービス・アドレスをホット・スペアだけに割り当てる。サービス・アドレスの割り当ては、ランダムであるか、又は、負荷均衡化方式に従うかのどちらかである。
クイーシングとは、サービス・グループにおけるホストがサービス・アドレスを取得することを防止し、同時に、そのホストがアドレスをリリースすることを許容すること、と定義される。実施例では、あるホストをクイーシングされたものとして設定するには、システム・オペレータによる介入が必要となる。これによって、システム・アドミニストレータは、影響を受けているホストを故障であると宣言することなく、リソース問題を取り扱うことが可能となる。故障したホストのように、クイーシングのなされたホストは、サービス・グループＤＮＳゾーンの中に含まれず、従って、そのアドレスは、使用可能なホストのリストの中には現れない。また、故障したホストとは異なり、クイーシングのなされたホストは、その現在のサービス・アドレスを使用し続けることができる。
故障検出機能もまた、本発明によって実行されることができるのであるが、これは、それぞれのホストによって送られる「情報」又は制御メッセージのモニタリングに関する。情報メッセージは、基本的に、「心拍」信号として機能する。心拍信号がタイムアウト期間内に生じない場合には、ホストの全体的な故障が検出される。情報メッセージ／心拍の送信周波数とタイムアウト期間とは、オペレータによってシステムの動作を最適化するように調整される。更に、ホストは、サービス故障を経験することもありうる。この故障は、ホストが、部分的な故障のためにサービスをもはや提供できないときに生じる。これらの故障は、一次的又は持続的であるが、リソースの枯渇やデータの破壊などのソフトウェア又はハードウェアの故障を含む。実施例では、サービス故障を伴うホストは、サービス・グループへの参加は継続することができるが、そのサービス・アドレスは、自発的にリリースする。
まず図１Ａを参照すると、コンピュータ・システム、すなわち、ホスト１０は、その中に、ＨＴＴＰやＮＥＷＳなどのネットワーク・サービス３０Ａ及び３０Ｂを扱うデーモン（daemon）２０を有する。これらのサービス３０は、それぞれが、サービス・モニタＳＭ１又はＳＭ２、テスト・オブジェクトＴＯ１及びＴＯ２、負荷オブジェクトＬＯ１及びＬＯ２などの、複数のオブジェクト・タイプを備えている。のちに更に詳細に述べるが、サービス・モニタは、本発明におけるキーとなるプログラム要素の多くを含み、それ以外の動作の多くを本質的に管理する。テスト・オブジェクトは、単に、特定のホストが正しく動作していることを確認する機能を有し、この情報をサービス・モニタが使用できるようにする。同じように、負荷オブジェクトは、単に、能力と負荷とを測定し、それによって、このデータがサービス・モニタによって用いられることができるようにする。オブジェクト・タイプの組合せは、協動して、ネットワーク・サービスを提供する。すなわち、サービス・モニタと、テスト・オブジェクトと、負荷オブジェクトとは、メモリ３４において動作しているプロセッサ３２によって実現される。
図１Ａには、このサービスが２つだけ示されているが、当業者であれば理解するように、特定のホスト１０は、任意の数のサービスを提供することができる。
次に図１Ｂを参照すると、サービス・モニタＳＭ１及びＳＭ２、関連するテスト・オブジェクトＴＯ１−ＴＯ２、負荷オブジェクトＬＯ１及びＬＯ２の間の関係が、ＲＡＩＳデーモン２０の内容において図解されている。特に、単に例示的な構成としてではあるが、サービス・モニタＳＭ１が、テスト・オブジェクトＴＯ１及びＴＯ２と負荷オブジェクトＬＯ１とにリンクされ、また、サービス・モニタＳＭ２が、テスト・オブジェクトＴＯ３と負荷オブジェクトＬＯ２とにリンクされている。サービス・モニタは、任意の数のテスト・オブジェクトにリンクさせることができ、それぞれのテスト・オブジェクトは、複数のサービス・モニタにリンクさせることができる。
本発明によると、サービス３０のプロバイダは、それぞれが、一意的なＩＰアドレスによって識別される。次に図２Ａを参照すると、本発明のキーとなる特徴に従って、それぞれのネットワーク・サービス３０が、図１Ａ−１Ｂに示されているタイプの複数のホスト１０によって提供される。これらの複数のホストは、ここでサービス・グループ１００と称しているものとして構成されており、複数のサービス・グループ１００が、ネットワーク１１０内で相互に接続され、必要なコンピュータ・サービスをすべて提供することができる。１つのホスト１０が複数のサービス・グループ１００に属することもありうるが、明瞭性のために、ここでは、１つのサービス・グループの中での相互作用を説明することにする。
サービス・グループの様々なメンバーの間での調整（coordination）を維持するために、サービス・グループ・アドレスと称される新たなＩＰアドレスが、それぞれのサービス・グループに対して確立されるが、これは、典型的には、ＩＰマルチキャスト・アドレスであり、ポート番号である。あるサービス・グループ１００の中のすべてのホスト１０、すなわち、メンバーは、サービス・グループ・アドレス１０５を用いて相互に通信する。つまり、それぞれのメンバーが、サービス・グループ・アドレスにメッセージをアドレシングすることによって、すべての他のグループ・メンバーにメッセージを送信し、それぞれのメンバーが、サービス・グループ・アドレスに向けられたメッセージを受信することによって、すべての他のメンバーからのメッセージを受信する。これらのメッセージは、制御メッセージと考えることができるが、典型的には、ＵＤＰなどのプロトコルを用いてそれぞれのホストによって周期的にブロードキャストされ、様々なデータを通信する。制御／情報メッセージのデータ構造は、図２Ｂに示されている。典型的なメッセージの内容には、（１）メッセージを提供しているホストが故障していない（well-being）ということ、（２）能力及び負荷、（３）制御アドレスのリスト、（４）好適なサービス・アドレス、（５）現在用いられているアドレスのリスト、そして、（６）（ａ）サービス・アドレスと、（ｂ）好適なホストによってアドレスが最後に用いられた時刻と、を含む用いられるべきアドレスのリスト、が含まれる。
制御メッセージに含まれる送信側のホストに関する上述のデータは、典型的には、ホスト情報エントリと称されるデータ・テーブルの中に維持され、正しいとの承認がある場合にだけ送信される。ホスト情報エントリの例が、図２Ｃに示されている。更に、実施例では、制御メッセージは、更に、サービス・グループに含まれる残りのホストに関してそのホストが受信した情報は、それがどのようなものであってもすべて、含み、また、そのホストから情報が最後にいつ受信されたか（すなわち、エージング、aging）も含んでいる。このデータは、ホスト情報データベースと称されるデータベースに記憶される。ホスト情報データベースのデータ構造は、単に、ｉｄ＿ａｄｄｒｅｓｓによって組織化された、一連のホスト情報エントリである。更に、制御メッセージは、サービス・アドレス・データベースを含んでおり、これは、サービス・アドレスとそれぞれの対する最後の更新からの時間との組として構成されている。図２Ｄに構造の例が示されている。以下で説明するように、新たなエントリごとに、時間がリセットされ、このリセットは、そのサービス・アドレスに対して責任を負っているホストが死んでいないことを保証するのに用いられる。故障した、すなわち、死んでいるホストは、メッセージの送信を停止するが、これによって、本発明は、そのホストのタスクを再割り当てすることに関して警告を受ける。
制御メッセージの送信は、それぞれのサービスに関連する、ＳＭ１などのサービス・モニタによって行われる。サービス・モニタは、マルチスレッドになっており、それに対して、送信、受信、スクリプト、制御、ＤＮＳなどの複数のスレッドが作成される。送信スレッドは、制御メッセージを送信し、受信スレッドは、サービス・グループ内の他のホストから制御メッセージを受信する。スクリプト・スレッドは、それ以外のスレッドによって扱われるには時間がかかりすぎるイベントをすべて扱い、制御スレッドは、サービス・グループの中のどのホストが「リーダ」であり、割り当ての決定を行うのかを決める。最後に、ＤＮＳスレッドは、単に、ＤＮＳを更新する。これらのスレッドについては、それぞれが、後で更に詳細に論じることにする。
次に図３を参照すると、送信スレッドをよりよく理解することができよう。それぞれのホストは、それぞれのサービスに対して１つの送信スレッドを開始することがわかる。送信スレッドは、ステップ３００において、「スリープ」状態で開始する。このプロセスは、ステップ３０５において、そのサービスに関連するテスト・オブジェクトＴＯ１−ＴＯｎを求めることによって、進み、ステップ３１０でテストが合格したかどうかをチェックすることによって、更に前進する。テストが不合格である場合、すなわち、ステップ３１０の結論がＮＯである場合には、プロセスは、ステップ３２０に進んで、現在のすべてのサービス・アドレスをリリースするように（従って、そのサービス・アドレスが、別の故障していないホストに再割り当てされるように）スクリプトに求め、次に、ステップ３３０において、制御メッセージが作成され、送られる。そして、プロセスは、ステップ３００のスリープ状態にループ・バックする。
しかし、ステップ３１０のテストの結果がＯＫである場合には、プロセスは、ステップ３５０に進み、そこで、（上述した）負荷及び能力情報が、負荷オブジェクトＬＯ１−ＬＯｎのそれぞれから集められる。ステップ３６０では、サービス・アドレスとタイマ・データとが、動作しているタイムアウト・タイマが要求する場合には、書き込まれる。次に、ステップ３７０において、制御すなわち情報メッセージが作成され送られて、そのホストの状態を、サービス・グループの他のメンバーに通信し、ステップ３８０において、ＡＲＰパケットが送られる。そして、プロセスは、ステップ３００のスリープ状態にループ・バックする。次に、デーモンは、適当な時間の後で、プロセスを再度開始する。
次に、図４Ａ−４Ｄを参照する。受信スレッドが、図４Ａのトップ・レベルに示されており、図４Ｂ−４Ｄは、受信スレッドの一部として含まれている様々な分岐を示している。受信スレッドは、ステップ４００で開始して、ステップ４０２に進み、そこでメッセージがサービス・グループ内の別のホストから受信される。次のステップ４０４では、メッセージが複写であるかどうかが判断される。複写である場合には、プロセスは、ステップ４０２にループ・バックし、別のメッセージを受け取る。メッセージが複写ではない場合には、プロセスは、ステップ４０６に進み、メッセージが取得メッセージであるかどうかをチェックする。そうである場合には、プロセスは、後に論じる図４Ｂに分岐する。そうでない場合には、プロセスは、ステップ４０８に進み、メッセージがリリース・メッセージであるかどうかを判断する。そうである場合には、プロセスは、後述の図４Ｃに分岐し、そうではない場合には、プロセスは、ステップ４１０に進む。ステップ４１０では、メッセージが情報すなわち制御メッセージであるかどうかがチェックされる。そうである場合には、プロセスは、やはり後述の図４Ｄに分岐し、そうでない場合には、メッセージは廃棄されて、プロセスは、ステップ４０２にループ・バックする。
次に図４Ｂを参照すると、「取得」メッセージに応答する受信スレッドの動作を見ることができる。この「取得」プロセスは、基本的に、リーダに、ソース及び目的地のｉｄ＿ａｄｄｒｅｓｓを、取得の際のサービス・アドレスと共に識別させることを含む。従って、プロセスは、ステップ４１２で、受信された取得メッセージがそのホストに対するものであるかどうかをチェックすることによって、開始する。そうでない場合には、プロセスは終了し、ステップ４０２にループすることによって、ステップ４１４に戻る。メッセージがそのホストに対するものである場合には、プロセスは、ホスト情報データベースにおけるアドレスを比較することにより、メッセージがそのホストからのものであるかどうかのチェックに進む。そうでない場合には、プロセスは、再び、ステップ４１４に戻る。
ステップ４１６でのチェックの結果がＹＥＳである場合には、プロセスは、ステップ４１８に進み、受信側のホストがＯＫであるかどうかを判断する。そうでない場合には、プロセスは、再び、ステップ４１４に戻る。しかし、そうである場合には、プロセスは、ステップ４２０に進み、ホストがクイーシングされている（quiesced）かどうか（これは、ホスト情報エントリから確認することができるが、典型的には、ホストをクイーシングされている状態に設定するオペレータによる介入が求められる）を判断するチェックを行う。ステップ４２０での解答がＹＥＳである場合には、サービス・アドレスは取得できず、従って、プロセスは、再び、ステップ４１４に戻る。しかし、ホストがクイーシングされていない場合には、ステップ４２２において、ホストが、現に、取得メッセージにおいて識別されたサービス・アドレスを用いているかどうかを判断するチェックを行う。これは、ホストのホスト情報エントリを調べることによって、判断することができる。そうである場合には、「新たな」サービス・アドレスを再び取得することは必要なく、プロセスは、ステップ４１４に戻る。ホストが現に識別されたサービス・アドレスを用いていない場合には、プロセスは、新たなサービス・アドレスに対するエントリを用いてホスト情報データベースを更新することによって、ステップ４２４に進み、取得作用は、ステップ４２６に予定されている。「取得」作用は、図５Ｂとの関係で更に詳細に説明される。プロセスは、次に、ステップ４１４に戻る。
次に、図４Ｃを参照すると、受信スレッドのリリース部分をよりよく理解することができるであろう。以下の説明から、当業者であれば、リリース部分が、実質的に取得部分と類似することを理解するはずである。プロセスは、ステップ４３２において、メッセージが受信側のホストに対するものであるのかどうかをチェックすることによって、開始する。そうでない場合には、プロセスは、ステップ４３４に戻る。そうである場合には、プロセスは、ステップ４３６に進み、ホスト情報データベースにおけるホストＩＤを比較することによって、そのメッセージがサービス・グループのリーダからのものであるかどうかをチェックする。そうでない場合には、プロセスは、再び、ステップ４３４に戻る。メッセージがリーダからのものである場合には、ステップ４４０において、（ホスト情報エントリにおける関係するフラグを見ることによって）識別されたリリースされるサービス・アドレスがオンラインであるかどうかが判断される。「取得」メッセージに関しては、「リリース」メッセージは、ソース及び目的地のｉｄ＿ａｄｄｅｓｓを含む。リリースされるサービス・アドレスが受信側のホストによって用いられていない場合には、プロセスは、ステップ４３４に戻る。しかし、サービス・アドレスが、ホスト情報エントリのリストによって判断されるように、用いられている場合には、サービス・アドレスは、サービス・アドレス情報において、まず、「リリース」としてマークされ、ホスト情報データベースは、ステップ４４２において、そのサービス・アドレスをそのホストによって用いられているサービス・アドレスのリストから削除することによって、更新され、プロセスは、ステップ４４４に進んで、リリース作用を予定する。リリース作用は、図５Ｃとの関係で説明する。プロセスは、次に、ステップ４３４に進む。
次に、図４Ｄを参照すると、情報すなわち制御メッセージに対する応答を理解することができる。情報メッセージへの応答は、単純に、受信側のホストによって維持されている適切なテーブルを、特に、先に述べたホスト情報データベースを更新することである。これによって、それぞれのサービス・アドレスの情報が、効果的に更新される。従って、プロセスは、他方のホストから受信された情報を用いてサービス・アドレス・データベースを更新することによって、ステップ４５０で開始し、ステップ４５２に進んで、そのサービス・グループによって用いられるべきアドレスのテーブルすなわちリストを更新する。リストは、それぞれのサービス・アドレスに対して、好適なホストによってアドレスが最後に用いられた時刻を特定し、責任を負うホストが生きており故障していないことを確認するという機能を基本的に有するタイムアウト・タイマをリセットする。これらのテーブルがいったん更新されると、プロセスはステップ４５４に戻る。
考慮すべきサービス・モニタの次のスレッドは、スクリプト（script）であり、これに関しては、図５Ａ−５Ｃを参照する。図５Ａは、スレッドの全体を示しており、図５Ｂ及び５Ｃは、スレッドのキーとなる分岐を示している。スクリプトは、一般に、より複雑なプロセスであるが、その理由は、これが、直ちにではなく、いくらかの遅延の後で動作させることができるからである。プロセスは、ステップ５００において開始し、ステップ５０２に進み、キュー（ｑｕｅｕｅ）から作用への要求を除去する。次に、ステップ５０４において、要求された作用が、「取得」作用であるかどうかが判断される。そうである場合には、プロセスは、図５Ｂに分岐する。そうでない場合には、プロセスは、ステップ５０６に進み、要求された作用が「リリース」作用であるかどうかが判断される。そうである場合には、プロセスは、図５Ｃに分岐し、そうでない場合には、プロセスは、ステップ５０８に進み、要求されている作用が、テスト失敗作用（test failed action）であるかどうかが判断される。この結果がＹＥＳである場合には、「テスト失敗」ＳＮＭＰトラップが、ステップ５１０において送られる。結果がＮＯである場合には、プロセスは、ステップ５１２に進み、要求されている作用が「割り当て不可能」作用であるかどうかが判断される。このチェックの結果がＹＥＳである場合には、プロセスは、ステップ５１４に分岐して、「割り当て不可能」ＳＮＭＰトラップが送られる。解答がＮＯである場合には、プロセスは、ステップ５１６において終了する。
次に図５Ｂを参照すると、図５Ａからの「取得」分岐を、よりよく理解できるはずである。先に述べたように、取得プロセスは、サービス・アドレスをホストに割り当てる。分岐は、ステップ５３０において開始し、ソフトウェア・サービス・アドレスに対するハードウェア・サービス・インターフェースを構成し、次に、ステップ５３２に進んで、取得スクリプトがランされる。取得スクリプトの実行に続いて、プロセスは、ステップ５３４に進み、エラーのチェックがなされる。エラーが生じていない場合には、プロセスは、ステップ５３６に進み、そのサービス・アドレスに対して、オンラインへのホスト情報エントリを更新する。次にプロセスは、ステップ５３８に進み、ＳＮＭＰ取得トラップを送り、その後で、プロセスは、ステップ５４０において終了する。
ステップ５３４においてエラーが生じ、ＹＥＳが戻された場合には、プロセスはステップ５４２に進み、サービス・インターフェース・ハードウェアを、サービス・アドレスを除去するように構成する。次にプロセスは、ステップ５４４に進み、そのサービス・アドレスに対するホスト情報エントリを、「サービスなし（notserving）」に更新し、ステップ５４６において、「取得失敗」ＳＮＭＰトラップを送る。こうして、プロセスは、終了する。
次に図５Ｃを参照すると、スクリプト・スレッドのリリース・スクリプト分岐を、よりよく理解できるはずである。図５Ｂに示された取得分岐と同様に、リリース作用によって、ホストは、それまで使用してきたサービス・アドレスの中の１つをリリースする。この分岐はステップ５６０で開始して、リリース・スクリプトをランする。サービス・インターフェース（ハードウェア）は、そのサービス・アドレス（ソフトウェア）に対して、リリースされているサービス・アドレスを除去するようにステップ５６２において構成される。エラーのチェックがステップ５６４においてなされ、エラーが生じている場合には、リリース失敗トラップが、ステップ５６６で送られ、その後で、ステップ５６８において、プロセスが終了する。エラーが生じているかどうかとは関係なく、「リリース」トラップがステップ５７０で送られ、ホスト情報エントリもまた、影響を受けたサービス・アドレスを除去するように更新され、プロセスが終了する。
図６Ａを参照すると、サービス・モニタの制御スレッドをよりよく理解できるはずである。制御スレッドの目的は、サービス・グループの中のどのホストがリーダであるかを確立することであり、そのリーダが、システムの状態に従ってサービス・アドレスを動的に管理できるようにすることである。プロセスは、ステップ６００においてスリープ・モードで開始する。スリープ・モードから覚醒すると、プロセスは、ステップ６０２に進んで、現在のリーダは誰であるのかを判断する。ステップ６０４においては、現在のホストがリーダであるのかどうかがチェックされる。そうでない場合には、プロセスは、ステップ６００にループ・バックする。
しかし、ステップ６０４におけるチェックの結果がＹＥＳである場合には、プロセスはステップ６０６に進み、データベースを現在の状態に更新することによって、古く時間切れのエントリと静止（silent）ホスト情報とを除去する。静止ホストとは、タイムアウト期間内に制御情報メッセージを送ることに失敗し、それによって、死んでしまったものとリーダが推定しているホストである。これによって、故障したホストによって先に用いられていたサービス・アドレスの再割り当てなどの追加的な決定が、リーダによって責任をもってなされることが可能となる。古くなったエントリがいったん除去されると、制御データベースが、ステップ６０８において構築される。これについては後述する。制御データベースが作られると、サービス・アドレスは、それぞれが、ステップ６１０において処理され、その状態が現在の情報に更新される。これについても後述する。プロセスは、次に、ステップ６００のスリープ・モードにループ・バックする。
制御データベースは、基本的に３つのテーブルを有している。第１は、図６Ｂに示されている制御サービス・アドレス・テーブルであり、ここには、４つの項目が設定されている。すなわち、（１）サービス・グループ内のサービス・アドレスと、（２）それぞれのサービス・アドレスの状態（すなわち、取得、リリース、オンライン、又は使用なし（unserved））と、（３）好適なサービス・アドレス（すなわち、好適なｉｄ＿ａｄｄｒｅｓｓ）と、（４）そのサービス・アドレスを与えると主張するｉｄ＿ａｄｄｒｅｓｓの組と、である。第２のテーブルは、制御Ｓｐａｒｅ＿Ｈｏｓｔ＿Ｌｉｓｔであり、第３は、Ｎｏｎ＿Ｓｐａｒｅ＿Ｅｌｉｇｉｂｌｅ＿Ｌｉｓｔである。これらは、単に、ＩＰアドレスの単一コラムのリストである。ホット・スペアのためには、好適なサービス・アドレスは、オペレータによってゼロに構成されるか、又は、割り当てられない。
テーブルは、１対の入れ子構造のループによって作られ、ホスト情報データベースの調査から開始する。実施例の外部入れ子ループ（outer nested loop）の擬似コード表現は、次の通りである。
0004087903.tif 000002
現に用いられているサービス・アドレスのリストにおけるそれぞれのサービス・アドレスに対する内側入れ子ループ（inner nested loop）は、ホスト情報エントリに維持されており、次の通りである。
0004087903.tif 000003
先に用いられているｉｄ＿ａｄｄｒｅｓｓは、ホストＩＤを意味する。当業者であれば理解するように、以上は、好適なサービス・アドレス及びｉｄ＿ａｄｄｒｅｓｓ、又は、制御サービス・アドレス・テーブルの項目（３）及び（４）を通して反復し、次に、テーブル内の様々なサービス・アドレスの状態を通じて反復するように戻る。
様々なエントリの状態を発展させるのに必要なステップの擬似コード表現は、次の通りである。
0004087903.tif 000004
以上のプロセスは、本質的には、サービス・アドレスのエントリを人工的に注入し、複写ホストに関しては後に行われるテストに依存して、そのアドレスを用いている２つのホストの一方を除去する。擬似コードにおいて用いられている「複写」（duplicate）とは、関数であり、システムが複写を決定することを含むことを要求する。詳細は後述する。
不使用状態（unserved state）を管理する擬似コードは、次のように表すことができる。
0004087903.tif 000005
適切な動作を保証するために、同じサービス・アドレスを用いている複写ホストに関しては、リーダがチェックを行わなければならず、一方が除去される。既に述べたように、実施例では、すべての制御決定はリーダによってなされる。このプロセスに対する擬似コードは、次の通りである。
0004087903.tif 000006
以上のプロセスは、そのアドレスが使用可能である場合には、サービス・アドレスを好適なサービス・アドレスに割り当てるものと考えることができる。そうでない場合には、リーダは、サービス・アドレスを使用可能なホット・スペアに割り当てる。これらが共に機能しない場合には、リーダは、単純に、１つを選択する。そして、リーダは、残りのサービス・アドレスにそのアドレスをリリースするように命じる。このプロセスの例外は、上述した人工的に注入されたアドレスに対して存在する。この場合には、人工的に挿入されたアドレスは、リリースを命じられることはない。
サービス・モニタの最後のスレッドは、ＤＮＳスレッドである。ＤＮＳスレッドは、基本的に、負荷の均衡化のために、能力当たりの負荷を判断して、現在及び過去に亘る、様々なサービス・アドレスの利用が、比較によって、計算される。図６Ｃに示されている第１のテーブル、すなわち、データベースＭは、それぞれのサービス・アドレスに対するこれまでの利用と重み付けされた利用とが記憶され、他方で、第２のテーブル、すなわち、データベースＢＢには、様々なサービス・アドレスに対する現在の利用と重み付けされた利用とが記憶されている。データベースＭ及びＢＢは、同じ構造を有しており、データベースＢＢからのデータは、新たなサンプルがデータベースＢＢに入力されると、データベースＭに転送される。ＤＮＳスレッドの擬似コードは、次のように表すことができる。
0004087903.tif 000007
0004087903.tif 000008
以上のスケーリング・ファクタは、多数の規準に従ってパフォーマンスを最適にするために、変動させることが可能である。スケーリング・ファクタは、典型的には、１００から１０００であり、使用（Util）の値は整数である。スケーリング・ファクタは、いったん選択されると、スケーリング・ファクタの変動が望ましいというパラダイムも存在するが、典型的には、固定されたまま維持される。デルタの値は、高い水位標と低い水位標との間の差であり、予め設定されている。
現在のデータベースＢＢにおけるエントリのソーティングは、負荷の均衡化のための調整を与えることを理解すべきである。
以上で本発明の好適実施例と様々なそれ以外の例とを説明したが、当業者であれば理解するように、この出願の内容を与えられれば、本発明から離れることなく、多くの代替例や均等物が存在する。従って、本発明は、以上の説明によって限定されることはなく、請求の範囲によってのみ画定されるものである。
【図１Ａ】
0004087903.tif 000009
【図１Ｂ】
0004087903.tif 000010
【図２Ａ】
0004087903.tif 000011
【図２Ｂ】
0004087903.tif 000012
【図２Ｃ】
0004087903.tif 000013
【図２Ｄ】
0004087903.tif 000014
【図３】
0004087903.tif 000015
【図４Ａ】
0004087903.tif 000016
【図４Ｂ】
0004087903.tif 000017
【図４Ｃ】
0004087903.tif 000018
【図４Ｄ】
0004087903.tif 000019
【図５Ａ】
0004087903.tif 000020
【図５Ｂ】
0004087903.tif 000021
【図５Ｃ】
0004087903.tif 000022
【図６Ａ】
0004087903.tif 000023
【図６Ｂ】
0004087903.tif 000024
【図６Ｃ】
0004087903.tif 000025