JP4897927B2 - 複数のアダプタにわたり複数の仮想ｉｐアドレスを同時にサポートしているホストにおけるフェイルオーバのための方法、システム、およびプログラム - Google Patents

Description

本発明は、一般に、ネットワーク内の改良型ホスト・システムに関し、より具体的に言えば、複数の仮想インターネット・プロトコル（ＩＰ）アドレス（ＶＩＰＡ）を同時にサポート可能な複数のアダプタを備えるホストにおける改良型フェイルオーバに関する。

インターネットなどの伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）ネットワークで使用される、アドレス解決プロトコル（ＡＲＰ）は、ＩＰアドレスとメディア・アクセス制御（ＭＡＣ）アドレスとの間のマッピングを要求側ホストに提供する。一例では、所与のＩＰアドレスに関するＭＡＣアドレスを習得する必要のある要求側ホストは、ＩＰアドレスを含むＡＲＰ要求を、ネットワーク内のすべてのルータおよびホストにブロードキャストする。ホスト側のアダプタはこの要求を受信する。ＩＰアドレスが割り当てられたアダプタは、ＩＰアドレスに対応するＭＡＣアドレスを含むＡＲＰ応答によって、ＡＲＰ要求に応答する。したがって、要求側ホストは、ＡＲＰ要求に対するＡＲＰ応答を通じて、ＩＰアドレスに対応するＭＡＣアドレスを習得する。

「実」ＩＰアドレスとは、物理アダプタに関連付けられたものである。アダプタは、しばしば、他のホストとの何千ものネットワーク・セッションをサポートする。アダプタに障害が発生した場合、アダプタに関連付けられたＩＰアドレスを使用するすべてのアクティブ・セッションも障害を起こすことになる。仮想ＩＰアドレス（ＶＩＰＡ）は、この問題を緩和するものと考えられた。ＶＩＰＡとは、物理アダプタではなくホストに関連付けられたＩＰアドレスである。メッセージは実ＩＰアドレスまたはＶＩＰＡへとアドレス指定することができる。ホストが複数のアダプタを含む場合、ＶＩＰＡへとアドレス指定されたＩＰトラフィックは、いずれかのアダプタを介してルーティング可能である。この場合、ホストは、ＶＩＰＡトラフィックを異なる物理アダプタを介してルーティングすることにより、アダプタ障害後に耐障害性を提供することができる。

しかしながら、複数のＶＩＰＡが単一のホストに割り当てられている場合、ＶＩＰＡベースのフェイルオーバ・システムは依然として効率性が制限される。具体的に言えば、単一のＶＩＰＡを複数のアダプタにわたってサポート可能であるが、複数のＶＩＰＡがホストによって割り当てられている場合、各ＶＩＰＡはそのＶＩＰＡにのみ割り当てられた別のアダプタ・セットを必要とする。しかしながら、複数のアダプタを別々のＶＩＰＡそれぞれに別々に割り当てるためには、アダプタ障害時にフェイルオーバを容易にするために、各ＶＩＰＡに別々のバックアップ・アダプタを割り当てることが必要な可能性がある。各ＶＩＰＡに別々のバックアップ・アダプタを割り当てることは、非効率的なリソースの割り振りである。

したがって、上記に鑑み、効率的なフェイルオーバを依然として可能にしながら、ホストの任意のハードウェア・アダプタが、ホストに関連付けられた複数のＶＩＰＡのいずれかについて着信データを同時に受け入れることを可能にするための、方法、システム、プロセス、およびプログラム製品が提供される。

一実施形態では、ホストは、ホストの複数のアダプタのうちの任意のアダプタが、ホストに割り当てられた複数のＶＩＰＡのうちの任意のＶＩＰＡを同時にサポートできるようにする。複数のアダプタの中の少なくとも１つの特定アダプタの障害に応答して、ホストは、各ＶＩＰＡに関する別々のハードウェア・アドレス更新をネットワークを介してブロードキャストするために残りの機能アダプタをトリガすることから、結果として、複数のＶＩＰＡをサポートするホストにおけるフェイルオーバの場合、ホストは、ネットワークを介してアクセス可能な少なくとも１つの他のホストに、複数のＶＩＰＡに関する任意の新しいパケットを、残りのアダプタのうちの１つの別々のハードウェア・アドレスのうちの１つへとアドレス指定するように指示する。

ホストは、ホストで受信したＡＲＰ要求内に指定されたＩＰアドレスと、複数のＶＩＰＡのリストとを比較して、ホストがＶＩＰＡのリスト内のＩＰアドレスをサポートしているかどうかを判別するために、ホスト上にネットワーク・スタックを構成することによって、ホストの複数のアダプタのうちの任意のアダプタが、ホストに割り当てられた複数のＶＩＰＡのうちの任意のＶＩＰＡを同時にサポートできるようにする。ホストが、複数のＶＩＰＡのうちの特定ＶＩＰＡに一致する特定のＩＰアドレスに関して、少なくとも１つの他のホストの中から要求側ホストからのＡＲＰ要求を受信することに応答して、ホストは、特定ＶＩＰＡに関する各アダプタの各ハードウェア・アドレスと共に、要求側ホストにＡＲＰ応答を送信するために各アダプタをトリガし、要求側ホストは、複数のアダプタからの複数のＡＲＰ応答のうちの１つを格納する。

以下で，本発明の諸実施形態について、添付の図面を参照しながら単なる例として説明する。

複数のＶＩＰＡの同時サポートが実行可能な複数のアダプタが割り当てられたホストの一例を示すブロック図である。 複数のＶＩＰＡの同時サポートが実行可能な複数のアダプタに関するフェイルオーバをサポートするホストが実装可能な、ネットワーク環境の一例を示すブロック図である。 本発明が内部に実装可能なコンピュータ・システムの一実施形態を示すブロック図である。 複数のＶＩＰＡの同時サポートが実行可能な複数のアダプタに関する効率的なフェイルオーバをサポートするための、ネットワーク・スタックを示すブロック図である。 複数のホストとゲートウェイ・ホストとの間で送信されるＡＲＰパケットの一例を示し、ゲートウェイ・ホストが複数のＶＩＰＡを同時に容易にできる複数のアダプタをサポートする、流れ図である。 内部に本発明が実装可能な、ゲートウェイを含むネットワーク環境の一例を示すブロック図である。 複数のＶＩＰＡの同時サポートが実行可能な複数のアダプタをサポートし、停止ゲートウェイ検出（Dead Gateway Detection）をサポートする、ホスト・システムの例を示す流れ図である。 要求側ホストからの要求に応答する受信側ホストのネットワーク・スタックに関するプロセスおよびプログラムを示し、受信側ホストは複数のアダプタが複数のＶＩＰＡを同時にサポートできるようにする、高水準論理流れ図である。 要求側ホストが、複数のアダプタが複数のＶＩＰＡを同時にサポートできるようにした場合、フェイルオーバを容易にするために障害アダプタに応答する受信側ホストのネットワーク・スタックに関するプロセスおよびプログラムを示す、高水準論理流れ図である。

次に図面、特に図１を参照すると、ブロック図は、複数のＶＩＰＡの同時サポートが実行可能な複数のアダプタが割り当てられたホストの一例を示す。この例では、ホスト１００は複数のアダプタ１１０、１１２、および１１４を含む。加えて、この例では、複数のＶＩＰＡ１０２および１０４が単一のホスト１００に関連付けられる。この例では、ホスト１００は、ネットワークに接続され、ネットワーク内でデータを受信または送信する、１つまたは複数の物理または論理のデータ処理システム、ルータ、または他のシステムを表すことができる。この例では、アダプタ１１０、１１２、および１１４は物理アダプタとして記述されるが、他の例では、アダプタ１１０、１１２、および１１４のうちの１つまたは複数は、１つまたは複数の物理アダプタの仮想表現を表すことができる。

一例では、ホスト１００内で、アダプタ１１０、１１２、および１１４は、それぞれがＶＩＰＡ１０２およびＶＩＰＡ１０４の両方をサポートするように構成される。アダプタ１１０、１１２、および１１４がＶＩＰＡ１０２およびＶＩＰＡ１０４の両方を同時にサポートするように構成することによって、ＶＩＰＡ１０２およびＶＩＰＡ１０４の両方がアダプタ１１０、１１２、および１１４のそれぞれで着信データを受け入れることが可能であり、ＶＩＰＡ１０２およびＶＩＰＡ１０４の両方がアダプタ１１０、１１２、および１１４のそれぞれを通じてデータをルーティングすることが可能である。示されていないが、他の例では、アダプタ１１０、１１２、および１１４のうちの１つを初期に着信データを受信するように設定することが可能であり、残りのアダプタをＶＩＰＡ１０２およびＶＩＰＡ１０４の両方について発信データをロード・バランシングするために設定することが可能である。

この例では、ＶＩＰＡ１０２およびＶＩＰＡ１０４が仮想または論理のＩＰアドレスを表し、アダプタ１１０、１１２、および１１４に、それぞれＭＡＣアドレスなどのハードウェア・アドレスが割り当てられる。加えて、ＶＩＰＡ１０２およびＶＩＰＡ１０４は実ＩＰアドレスを表すことが可能であり、アダプタ１１０、１１２、および１１４には、仮想アドレス、複数の物理アドレス、または他のタイプのアドレス指定を割り当てることが可能であることが理解されよう。

一例では、ＶＩＰＡ１０２およびＶＩＰＡ１０４の両方が、ホスト１００の同じサービスにアクセスするように割り当てられ、サービスは、アプリケーション、データ、あるいは、ホスト１００またはホスト１００にアクセス可能な他のシステムの機能を含むことが可能であるが、これらには限定されない。他の例では、ＶＩＰＡ１０２およびＶＩＰＡ１０４のそれぞれが、ホスト１００の別々のサービスに割り当てられ、ホスト１００は、アダプタ１１０、１１２、および１１４のいずれかを通じてホスト１００によって受信された異なるサービスについて異なるＶＩＰＡに関するパケットの分布を管理するために、１つまたは複数の追加のプロセッサまたはハードウェアを実装する。

この例では、ＶＩＰＡ１０２および１０４はホスト１００に関連付けられているが、他の例では、任意数のＶＩＰＡを単一のホストまたはクラスタあるいは他のホスト・グループに関連付けることが可能であること、および、１つまたは複数のＶＩＰＡを１つのホストから他のホストへ転送することが可能であることに留意されたい。加えて、この例では、アダプタ１１０、１１２、および１１４はＶＩＰＡ１０２と１０４との間で共有されているが、他の諸実施形態では、アダプタのうちの１つまたは複数を主として特定のＶＩＰＡに割り当てることが可能であることに留意されたい。

次に図２を参照すると、ブロック図は、複数のＶＩＰＡの同時サポートが実行可能な複数のアダプタに関するフェイルオーバをサポートするホストが実装可能な、ネットワーク環境の一例を示す。ネットワーク環境２００は、それぞれがネットワーク環境２００内で通信するための１つまたは複数のアダプタを備えた、１つまたは複数のホストをサポート可能な、１つのタイプのネットワーク環境の例示であるが、追加、代替、または他のタイプのホストを他のネットワーク環境内に実装可能であることに留意されたい。加えて、ネットワーク環境２００内でのシステムの分散は、システムの分散の例示であるが、ネットワーク環境内での他のシステムの分散が実装可能であることに留意されたい。

図に示されるように、ネットワーク環境２００内の複数のシステムは、通信的に接続された様々なデバイスとコンピュータ・システムとの間に通信リンクを提供するために使用されるメディアである、ネットワーク２０２を介して、通信的に接続可能である。ネットワーク２０２は、ワイヤまたは光ファイバ・ケーブルなどの永続接続と、たとえば電話接続および無線伝送接続を介して行われる一時接続とを、含むことができる。ネットワーク２０２は、パケット交換ベースのネットワークおよび電話ベースのネットワーク、ローカル・エリアおよびワイヤ・エリアのネットワーク、公衆および専用のネットワークのうちの、１つまたは複数を表すことができる。

ネットワーク２０２は、物理レイヤ、リンク・レイヤ、ネットワーク・レイヤ、移送レイヤ、プレゼンテーション・レイヤ、およびアプリケーション・レイヤのうちの１つまたは複数を含むことが可能な、１つまたは複数のタイプのネットワーク・プロトコル・スタックのうちの１つまたは複数のレイヤを実装することができる。たとえば、ネットワーク２０２は、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）プロトコル・スタックまたはオープン・システム相互接続（ＯＳＩ）プロトコル・スタックのうちの、１つまたは複数を実装することができる。加えて、たとえばネットワーク２０２は、互いに通信するためにＴＣＰ／ＩＰプロトコル・スート（suite）を使用する、ネットワークおよびゲートウェイの世界規模接続を表すことができる。他の例では、ネットワーク２０２は、１つまたは複数の異なるタイプのプロトコル・スタックおよび他のタイプのプロトコル・スタックを実装することができる。

ネットワーク環境２００は、複数タイプのネットワーク・アーキテクチャを実装することができる。一例では、ネットワーク環境２００は、クライアント／サーバ・アーキテクチャを使用して実装可能であり、ここではデータまたはプロセスを要求するコンピューティング・システムがクライアントと呼ばれ、データ要求およびプロセスを処理するコンピューティング・システムがサーバと呼ばれる。他の例では、ネットワーク環境２００はピア・ツー・ピア・ネットワーク・アーキテクチャ内に実装可能である。更に他の例では、ネットワーク環境２００はグリッド・アーキテクチャ内に実装可能である。他のタイプのネットワーク・アーキテクチャおよびネットワーク・アーキテクチャの組み合わせがネットワーク環境２００内に実装可能であることを理解されよう。

この実施形態では、図に示されるように、クライアント・システム２１０、クライアント・システム２２０、およびサーバ・システム２３０のうちの１つまたは複数が、ネットワーク環境２００内でネットワーク２０２を介して通信的に接続される。一般に、クライアント・システム２１０およびクライアント・システム２２０は、ネットワーク２０２を介して１つまたは複数のサービスをサーバ・システム２３０に要求し、サーバ・システム２３０によって送達されるデータは、ネットワーク２０２を介してクライアント・システム２１０およびクライアント・システム２２０へと出力される。クライアント・システム２１０およびクライアント・システム２２０はそれぞれ、サービスに関する要求を受信するため、およびデータまたは他の出力を他のシステムへ送達するための、サーバとして実装可能であることを理解されよう。加えて、サーバ・システム２３０は、ネットワーク２０２を介して、サービスに関する要求を送信するためおよび他のシステムからの出力を受信するための、クライアント・システムとして実装可能であることを理解されよう。ネットワーク環境２００は、１つまたは複数のクライアント・システム、１つまたは複数のサーバ・システム、ならびに、ネットワーク環境２００内のシステムを通信的に接続するネットワーク２０２の１つまたは複数のインスタンスを、含むことが可能であることを理解されよう。

図に示されるように、クライアント・システム２１０、クライアント・システム２２０、およびサーバ・システム２３０は、それぞれ、図１のホスト１００などのホストを表すことができる。加えて、グループ化、クラスタ、または他のネットワーク・マッピングは、クライアント・システム２１０、クライアント・システム２２０、およびサーバ・システム２３０のすべてまたは一部の組み合わせを含むものとして、ホスト１００を指定することができる。

具体的に言えば、この実施形態に示されるように、サーバ・システム２３０は、サーバ・システム２３０の１つまたは複数のソフトウェア・レイヤおよびハードウェア・レイヤ内に実装された、複数ＶＩＰＡフェイルオーバ・コントローラ２３２を介して、複数ＶＩＰＡ２３６を同時にサポートすることが可能な複数アダプタ２３４を備えたホストを表す。複数ＶＩＰＡフェイルオーバ・コントローラ２３２は、複数ＶＩＰＡ２３６の同時サポートが可能な複数アダプタ２３４のうちの１つが障害を起こすかまたは除去された場合の、フェイルオーバもサポートする。

第１に、複数ＶＩＰＡフェイルオーバ・コントローラ２３２は、複数アダプタ２３４のそれぞれが、複数ＶＩＰＡ２３６のうちのいずれか向けのデータを受け入れることを実行可能にする。一例では、いずれかのアダプタがそれぞれのＶＩＰＡ向けのデータを受け入れ可能にするために、複数ＶＩＰＡフェイルオーバ・コントローラ２３２は、複数アダプタ２３４をトリガし、着信パケット内のＩＰと複数ＶＩＰＡ２３６のうちの１つとの間に合致が存在するかどうかを判別するために、各着信パケットに関する複数ＶＩＰＡ２３６のリストをチェックする。

第２に、複数ＶＩＰＡフェイルオーバ・コントローラ２３２は、複数アダプタ２３４のうちの１つが障害を起こし、結果としてサーバ・システム２３０への現在の接続が中断された場合、フェイルオーバを容易にする。一例では、複数アダプタ２３４のいずれかがＶＩＰＡ向けのデータを受け入れることが可能であるため、クライアント・システム２１０またはクライアント・システム２２０は、複数アダプタ２３４のそれぞれに関する物理アドレスを受信し、複数ＶＩＰＡ２３６のうちの１つに関するサーバ・システム２３０へとパケットをアドレス指定する際に使用するために物理アドレスのうちの１つを選択する。複数アダプタ２３４のうちの１つが障害を起こした場合、複数ＶＩＰＡフェイルオーバ・コントローラ２３２は、クライアント・システム２１０およびクライアント・システム２２０などのすべての他のホストに対して、複数ＶＩＰＡ２３６のそれぞれに関する物理アドレスが変更された旨の更新と共に、更新をブロードキャストする。クライアント・システム２１０とクライアント・システム２２０との間のサーバ・システム２３０との接続は、ＶＩＰＡに結合されるため、クライアント・システム２１０またはクライアント・システム２００は、サーバ・システム２３０へのいずれの新しいパケットも、現在の接続を中断することなく、更新された機能アダプタの物理アドレスへと送信する。

サーバ・システム２３０を参照しながら説明した複数ＶＩＰＡフェイルオーバ・コントローラ２３２の分散に加えて、複数ＶＩＰＡフェイルオーバ・コントローラ２３２は、クライアント・システム２１０、クライアント・システム２２０、またはネットワーク２０２内などの、ネットワーク環境内の追加または代替システム間で分散可能であることに留意されたい。加えて、複数ＶＩＰＡフェイルオーバ・コントローラ２３２は、単一のクライアント・システム２１０または２２０、サーバ・システム２３０、またはネットワーク２０２内で、あるいは、複数のクライアント・システム、サーバ・システム、またはネットワークにまたがって分散された、複数の論理ネットワーク区画間で分散可能である。さらに、複数ＶＩＰＡフェイルオーバ・コントローラ２３２の複数の物理、論理、または仮想のインスタンスは、クライアント・システム、サーバ・システム、またはネットワークで開始可能である。

具体的に言えば、複数ＶＩＰＡフェイルオーバ・コントローラのプロセス・ソフトウェアは、サーバ・システム２３０の複数ＶＩＰＡフェイルオーバ・コントローラ２３２、および、ＣＤ、ＤＶＤなどのストレージ・メディアのローディングを介したプロキシ・コンピュータ・システム（図示せず）などの、システム内への直接の手動ローディングによって、展開可能であることがわかるが、プロセス・ソフトウェアは、プロセス・ソフトウェアをサーバ・システムまたはサーバ・システム・グループへ送信することによって、コンピュータ・システム内に自動的または半自動的に展開することも可能である。その後、プロセス・ソフトウェアは、プロセス・ソフトウェアを実行することになるクライアント・コンピュータまたはサーバ・システム内にダウンロードされる。別の方法として、プロセス・ソフトウェアは、電子メールまたは他の電子通信を介して、クライアント・システムまたはサーバ・システムへ直接送信される。その後、プロセス・ソフトウェアは、プロセス・ソフトウェアをディレクトリ内に分離するプログラムを実行する、電子メールまたは他の電子通信上のボタンによって、ディレクトリへと分離されるか、またはディレクトリ内にロードされる。他の代替方法は、クライアント・システムまたはサーバ・システムのハード・ドライブ上にあるディレクトリに、プロセス・ソフトウェアを直接送信することである。いずれかのプロキシ・サーバが存在する場合、プロセスは、プロキシ・サーバ・コードを選択し、プロキシ・サーバのコードを配置するコンピュータを決定し、プロキシ・サーバ・コードを伝送した後、プロキシ・コンピュータ上にプロキシ・サーバ・コードをインストールすることになる。プロセス・ソフトウェアは、プロキシ・サーバへと伝送された後、プロキシ・サーバ上に格納されることになる。

加えて、具体的に言えば、複数ＶＩＰＡフェイルオーバ・コントローラのプロセス・ソフトウェアは、オペレーティング・システム、ネットワーク・スタック、または、アダプタなどのネットワーク・ハードウェアとは別に配置することが可能であることが理解されるが、プロセス・ソフトウェアは、クライアント・システムおよびサーバ・システム上のアプリケーション、オペレーティング・システム、またはネットワーク・サービス、あるいは、プロセス・ソフトウェアが機能することになるネットワーク環境内のアダプタまたは他のネットワーク・ハードウェアの機能に、全体または一部分が統合されるか、またはこれらと共存することも可能である。さらに、複数ＶＩＰＡフェイルオーバ・コントローラのプロセス・ソフトウェアは、共用サーバ・システム上にオンデマンドで使用可能とすることができる。

次に図３を参照すると、ブロック図は、本発明が内部に実装可能なコンピュータ・システムの一実施形態を示す。本発明のプロセス、方法、コンピュータ・プログラム製品、およびシステムは、ネットワーク２０２などのネットワークに通信的に接続された、コンピュータ・システム３００などの多様なコンピューティング・システムを含む、多様なシステム内で実行可能である。コンピュータ・システム３００は、１つまたは複数のアダプタを備えるホスト１００を表すか、または複数ホスト内に分散させることができる。加えて、コンピュータ・システム３００は、ホスト１００を表すために、他のコンピュータ・システムとグループ化することができる。

コンピュータ・システム３００は、コンピュータ・システム３００内で情報を通信するためのバス３２２または他の通信デバイスと、情報処理のためにバス３２２に結合された、プロセッサ３１２などの少なくとも１つの処理デバイスとを含む。バス３２２は、ブリッジおよびアダプタによって接続され、複数のバス・コントローラによってコンピュータ・システム３００内で制御される、低レイテンシ（latency）および高レイテンシのパスを含む。サーバとして実装される場合、コンピュータ・システム３００は、ネットワーク・サービス能力を向上させるように設計された、複数のプロセッサを含むことができる。複数のプロセッサがバス３２２を共用する場合、バス・アクセスおよびロックを管理するための追加のコントローラ（図示せず）が実装可能である。

プロセッサ３１２は、通常の動作中に、ランダム・アクセス・メモリ（ＲＡＭ）３１４などの動的ストレージ・デバイス、読み取り専用メモリ（ＲＯＭ）３１６などの静的ストレージ・デバイス、大容量ストレージ・デバイス３１８などのデータ・ストレージ・デバイス、または他のデータ・ストレージ・メディアからアクセス可能な、オペレーティング・システム３６０、アプリケーション・ソフトウェア３７０、ミドルウェア（図示せず）、ネットワーク・ソフトウェア、および他のコードの制御の下で、データを処理する、ＩＢＭのＰｏｗｅｒＰＣ（ＴＭ）プロセッサなどの、汎用プロセッサとすることができる。オペレーティング・システム３６０、アプリケーション・ソフトウェア３７０、または他のソフトウェア・レイヤは、図２に示された複数ＶＩＰＡフェイルオーバ・コントローラ２３２のコンポーネントのうちの１つまたは複数を実装することができる。

一実施形態では、図８および図９の流れ図の動作ならびに本明細書で説明される他の動作で説明されるように、プロセッサ３１２によって実行される動作が、検索結果リンクの検出、現在の検索結果リンクとのユーザ対話に基づく検索結果リンクにおけるユーザの関心事の予測、および、現在のユーザの関心事に基づく検索結果リンクの動的再編成を、制御することができる。プロセッサ３１２によって実行される動作は、オペレーティング・システム３６０、アプリケーション・ソフトウェア３７０、ミドルウェアまたは他のコードによって要求可能であるか、あるいは本発明の諸ステップは、諸ステップを実行するためのハードワイヤード論理を含む特定のハードウェア・コンポーネントによって、または、プログラム済みコンピュータ・コンポーネントおよびカスタム・ハードウェア・コンポーネントの任意の組み合わせによって、実行可能である。

本発明は、コンピュータ・システム３００上で実行された場合、本発明に従ったプロセスをコンピュータ・システム３００に実行させる、コンピュータ読み取り可能プログラムの実行可能命令を格納した、コンピュータまたは機械読み取り可能メディア上に含まれる、コンピュータ・プログラム製品として提供可能である。本明細書で使用される「コンピュータ読み取り可能メディア」または「機械読み取り可能メディア」という用語は、プロセッサ３１２またはコンピュータ・システム３００の他のコンポーネントへ、実行のための命令を提供することに関与しているいずれのメディアも含む。こうしたメディアは、不揮発性メディアおよび揮発性メディアなどのストレージ・タイプ・メディア、ならびに伝送メディアを含むが、これらに限定されない、多くの形を取ることができる。不揮発性メディアの一般的な形は、たとえば、フロッピー・ディスク（商標）、フレキシブル・ディスク、ハード・ディスク、磁気テープまたは任意の他の磁気メディア、コンパクト・ディスクＲＯＭ（ＣＤ−ＲＯＭ）または任意の他の光メディア、パンチ・カードまたはホール・パターンを伴う任意の他の物理メディア、プログラマブルＲＯＭ（ＰＲＯＭ）、消去可能ＰＲＯＭ（ＥＰＲＯＭ）、電気的ＥＰＲＯＭ（ＥＥＰＲＯＭ）、フラッシュ・メモリ、任意の他のメモリ・チップまたはカートリッジ、あるいは、コンピュータ・システム３００が読み取り可能であり命令の格納に好適な任意の他のメディアを含む。本実施形態では、不揮発性メディアの例は、コンピュータ・システム３００の内部コンポーネントとして示されている大容量ストレージ・デバイス３１８であるが、外部デバイスによっても提供されるものと理解されよう。揮発性メディアは、ＲＡＭ３１４などの動的メモリを含む。伝送メディアは、バス３２２を備えるワイヤを含む、同軸ケーブル、銅線、または光ファイバを含む。伝送メディアは、無線周波または赤外線のデータ通信中に生成されるような、音波または光波の形を取ることもできる。

さらに本発明は、コンピュータ・プログラム製品としてダウンロードまたは配布可能であり、ここでコンピュータ読み取り可能プログラム命令は、搬送波または他の伝搬メディア内に具体化されたデータ信号によって、バス３２２に結合された通信インターフェース３３２へのネットワーク・リンク３３４（たとえばモデムまたはネットワーク接続）へ、ネットワーク２０２を介して、サーバ３４０などのリモート・コンピュータから、要求側コンピュータ・システム３００へと伝送可能である。一例では、プロセッサ３１２が複数のプロセッサ要素を含む場合、プロセッサ要素間に分散された処理タスクは、ローカルであるかネットワークを介するかに関わらず、コンピュータ・プログラム製品を表すことが可能であり、処理タスクは、プロセスを実行するためのＪａｖａ（Ｊａｖａはサンマイクロシステムズ社の登録商標である）オブジェクトまたは他の実行可能プログラムにアクセスするための、プロセスまたはプログラム命令を実行するためのプログラム命令を含む。通信インターフェース３３２は、たとえば、ローカル・エリア・ネットワーク（ＬＡＮ）へ、ワイド・エリア・ネットワーク（ＷＡＮ）へ、または直接インターネット・サービス・プロバイダ（ＩＳＰ）へ接続可能な、ネットワーク・リンク３３４に結合している双方向データ通信を提供する。具体的に言えば、ネットワーク・リンク３３４は、ネットワーク２０２などの１つまたは複数のネットワークへ、有線あるいは無線またはその両方のネットワーク通信を提供することができる。さらに、図示されていないが、通信インターフェース３３２は、デバイス・ドライバなどのソフトウェア、アダプタなどのハードウェア、および通信が可能な他のコントローラを含むことができる。サーバとして実装された場合、コンピュータ・システム３００は、たとえば入力／出力コントローラに接続された複数の周辺コンポーネント相互接続（ＰＣＩ）バス・ブリッジを介してアクセス可能な、複数の通信インターフェースを含むことができる。このようにして、コンピュータ・システム３００は、複数の別々のポートを介して複数のクライアントに接続することが可能であり、各ポートは、複数のクライアントへの複数の接続をサポートすることも可能である。

ネットワーク・リンク３３４およびネットワーク２０２は、どちらも、デジタル・データ・ストリームを搬送する、電気、電磁、または光の信号を使用する。コンピュータ・システム３００との間でデジタルデータを搬送する、様々なネットワークを介する信号およびネットワーク・リンク３３４上で通信インターフェース３３２を介する信号は、情報を移送する搬送波の形を取ることができる。

加えて、コンピュータ・システム３００は、入力および出力を容易にする複数の周辺コンポーネントを含むことができる。これらの周辺コンポーネントは、複数レベルのバス３２２のうちの１つに結合された、入力／出力（Ｉ／Ｏ）インターフェース３２６などの、複数のコントローラ、アダプタ、および拡張スロットに接続される。入力デバイス３２４は、入力を制御するＩ／Ｏインターフェース３２６を介してバス３２２上で通信的に実行可能な、たとえばマイクロフォン、ビデオ・キャプチャ・デバイス、全身スキャン・システム、キーボード、マウス、または他の入力周辺デバイスを含むことができる。加えて、出力を制御するためにＩ／Ｏインターフェース３２６を介してバス３２２上で通信的に実行可能な出力デバイス３２０は、たとえば、１つまたは複数のグラフィカル・ディスプレイ・デバイス、オーディオ・スピーカ、および触知検出可能出力インターフェースを含むことができるが、他の出力インターフェースを含むこともできる。本発明の代替実施形態では、追加または代替の入力および出力周辺コンポーネントも追加可能である。

当業者であれば、図３に示されたハードウェアが変更可能であることを理解されよう。さらに当業者であれば、示された例が、本発明に関してアーキテクチャ上の制限を示唆することを意味するものでないことを理解されよう。たとえば、コンピュータ・システム３００は、タブレット・コンピュータ、ラップトップ・コンピュータ、または電話デバイスとすることもできる。

次に図４を参照すると、ブロック図は、複数のＶＩＰＡの同時サポートが実行可能な複数のアダプタに関する効率的なフェイルオーバをサポートするための、ネットワーク・スタックを示す。ネットワーク・スタック４００のレイヤおよびコンポーネントは、複数のメモリ・コンポーネント間、複数のデバイス間、複数のインターフェース間、複数のコンピューティング・システム間、ならびに複数のネットワークおよびルータなどのネットワーク・デバイス間に分散可能であることに留意されたい。加えて、本発明を実装するネットワーク・スタックは、ネットワーク・スタック４００に示されたものに追加または代替のレイヤ、プロセス、およびデータを含むことが可能であることに留意されたい。

この例では、ネットワーク・スタック４００は、受信側ホストおよび要求側ホストの両方に関して説明される。一例では、ネットワーク・スタック４００が受信側ホストを表す場合、ネットワーク・スタック４００は１つまたは複数の要求側ホストからの要求を受信する。一例では、ネットワーク・スタック４００が要求側ホストを表す場合、ネットワーク・スタック４００は受信側ホストあるいは１つまたは複数の外部ホストに要求を送信する。

この例では、ネットワーク・スタック４００はカーネル・レイヤ４０４を含む。カーネル・レイヤ４０４は、オペレーティング・システム３６０のインスタンスなどの１つまたは複数のタイプのオペレーティング・システムの１つまたは複数のインスタンス、複数のコンピュータ・プラットフォームの統合を可能にするＷｅｂＳｐｈｅｒｅ（ＷｅｂＳｐｈｅｒｅはインターナショナル・ビジネス・マシーンズ社の登録商標である）ミドルウェアなどのミドルウェアの１つまたは複数のインスタンスを含むことが可能であるが、これらに限定されない。

この例では、カーネル４０４は、ルーティング・テーブル４０６を維持することができる。ルーティング・テーブル４０６は、ハードウェア、ＩＰ、およびネットワークを介してアクセス可能な他のホストの他のレベルのアドレス指定を含むことが可能であり、１つまたは複数のゲートウェイに関するインターフェース・アドレス指定を含むことができる。一例では、カーネル４０４は、他のホストに対してアクセスされたアドレスのキャッシュを維持すること、および、キャッシュ内に維持するためのアドレスを決定する際の、ホストがアクセスされてからの時間などの、規則を適用することができる。

加えて、この例では、ネットワーク・スタック４００はＴＣＰ／ＩＰレイヤ４０８を含む。複数ＶＩＰＡフェイルオーバ・コントローラ２３２の一実装では、ＴＣＰ／ＩＰレイヤ４０８はＶＩＰＡリスト４１０を使用して実行可能である。ＶＩＰＡリスト４１０は、ネットワーク・スタック４００によってサポートされているＩＰアドレスおよびＶＩＰＡのシステム規模のリストを含む。着信ＡＲＰパケットなどの着信パケットに関して、ＩＰアドレスがネットワーク・スタック４００によってサポートされているかどうかを判別するために、着信パケット内で要求されたＩＰアドレスがＶＩＰＡリスト４１０に照らしてチェックされるように、複数ＶＩＰＡフェイルオーバ・コントローラ２３２における設定値およびプロセスを通じて、アダプタ・レイヤ４２０が設定される。

ＶＩＰＡリスト４１０に照らして着信パケットＩＰをチェックするようにネットワーク・スタック４００を設定することにより、アダプタ・レイヤ４２０内のアダプタ４１４、４１６、および４１８の中のアダプタは、ＶＩＰＡリスト４１０内の任意のＶＩＰＡ向けのデータを受け入れることができる。具体的に言えば、ＶＩＰＡリスト４１０はＴＣＰ／ＩＰレイヤ４０８内に実装されているように示されているが、ＶＩＰＡリスト４１０およびＶＩＰＡリスト４１０とパケットＩＰとの比較は、アダプタ・レイヤ４２０などの他のレイヤで実行可能であることに留意されたい。加えて、異なるレイヤまたは異なるレイヤ内の異なるコンポーネントが、ＶＩＰＡリスト４１０の別々のインスタンスを維持できることに留意されたい。

この例では、ネットワーク・スタック４００は受信側ホストであり、アダプタ・レイヤ４２０はＶＩＰＡリスト４１０内の任意のＶＩＰＡに関するＡＲＰ要求を受信し、この要求が、ＡＲＰ要求内のＩＰがＶＩＰＡリスト４１０内のＶＩＰＡのうちの１つである旨を決定するＴＣＰ／ＩＰレイヤ４０８にプッシュアップ（push up）される。その後、ＴＣＰ／ＩＰレイヤ４０８は、ネットワーク上で要求側ホストにＡＲＰ応答を送信するために、アダプタ・レイヤ４２０をトリガする。具体的に言えば、ＴＣＰ／ＩＰレイヤ４０８は、要求されたＶＩＰＡに関するＡＲＰ応答を要求側ホストに送信するために、それぞれがそのアダプタに関するＭＡＣアドレスおよび要求されたＶＩＰＡを使用してＡＲＰ応答を指定する、アダプタ４１４、４１６、および４１８のそれぞれをトリガする。

この例では、アダプタ・レイヤ４２０内の各アダプタにはＭＡＣハードウェア・アドレスが割り当てられる。たとえば、アダプタ４１４にはＭＡＣ１が割り当てられ、アダプタ４１６にはＭＡＣ２が割り当てられ、アダプタ４１８にはＭＡＣ３が割り当てられる。アダプタ４１４、４１６、および４１８には、複数のハードウェア・アドレス、ハードウェア・アドレスおよびネットワーク・アドレス、または他のタイプのアドレス指定を割り当てることも可能であることを理解されよう。加えて、アダプタ・レイヤ４２０は、アダプタ４１４、４１６、および４１８によって表されるアダプタに対して追加または代替のアダプタを含むことが可能であることを理解されよう。

この例では、ＶＩＰＡリスト４１０がＶＩＰＡ１およびＶＩＰＡ２を含む場合、ネットワーク・スタック４００がＶＩＰＡ１に関するＡＰＲ要求を受信することに応答して、アダプタ４１４はＶＩＰＡ１のＡＲＰ応答、ＭＡＣ１を送信し、アダプタ４１６はＶＩＰＡ１のＡＲＰ応答、ＭＡＣ２を送信し、アダプタ４１８はＶＩＰＡ１のＡＲＰ応答、ＭＡＣ３を送信することになる。加えて、この例では、ネットワーク・スタック４００がＶＩＰＡ２に関するＡＲＰ要求を受信することに応答して、アダプタ４１４はＶＩＰＡ２のＡＲＰ応答、ＭＡＣ１を送信し、アダプタ４１６はＶＩＰＡ２のＡＲＰ応答、ＭＡＣ２を送信し、アダプタ４１８はＶＩＰＡ２のＡＲＰ応答、ＭＡＣ３を送信することになる。

ネットワーク・スタック４００が要求側ホストを表す場合、ネットワーク・スタック４００は、それぞれが異なるＭＡＣアドレスを備える、ＶＩＰＡに関する特定のＡＲＰ要求に対する複数のＡＲＰ応答を受信することができる。カーネル・レイヤ４０４などの、ネットワーク・スタック４００のレイヤのうちの少なくとも１つは、ルーティング・テーブル４０６または他のキャッシュ内のＡＲＰ応答のうちの１つを選択およびキャッシュし、他のＡＲＰ応答を廃棄するための、ＡＲＰ規則を適用する。加えて、代替実施形態では、ネットワーク・スタック４００は、特定のＡＲＰ要求に関するすべてのＡＲＰ応答をキャッシュするが、パケットを送信するためにＡＲＰ応答のうちの１つのみを選択し、ＡＲＰ応答のうちの１つにおいて選択されたＭＡＣアドレスを介して、ＴＣＰ／ＩＰレイヤ４１２からＶＩＰＡアドレスへと結合することができる。

受信側ホストを表すネットワーク・スタック４００に戻ると、ネットワーク・スタック４００内の１つまたは複数のレイヤで動作する複数ＶＩＰＡフェイルオーバ・コントローラ２３２のフェイルオーバ・コントローラ４１２は、アダプタ障害を検出し、すべてのＶＩＰＡに関するＡＲＰ更新をブロードキャストするために機能アダプタをトリガする。たとえば、フェイルオーバ・コントローラ４１２がアダプタ４１４の障害または除去を検出した場合、フェイルオーバ・コントローラ４１２は、ＶＩＰＡリスト４１０内のそれぞれのＶＩＰＡに関するＡＲＰ更新をブロードキャストするために、アダプタ４１６および４１８をトリガする。

この例では、ＶＩＰＡリスト４１０がＶＩＰＡ１およびＶＩＰＡ２を含む場合、フェイルオーバ・コントローラ４１２がアダプタ４１４などのアダプタのフェイルオーバを検出することに応答して、アダプタ４１６は、ＶＩＰＡ１のＡＲＰ更新、ＭＡＣ２と、ＶＩＰＡ２のＡＲＰ更新、ＭＡＣ２とをブロードキャストし、アダプタ４１８は、ＶＩＰＡ１のＡＲＰ更新、ＭＡＣ３と、ＶＩＰＡ２のＡＲＰ更新、ＭＡＣ３とをブロードキャストする。

一例では、フェイルオーバ・コントローラ４１２はカーネル・レイヤ４０４内に実装される。具体的に言えば、一例では、カーネル・レイヤ４０４は、デバイス・ドライバの監視および各アダプタの状況の維持などを通じて、アダプタ４１４、４１６、または４１８のうちのいずれかでの障害を検出することが可能である。カーネル・レイヤ４０４がフェイルオーバ・コントローラ４１２を通じて障害を検出できる場合、カーネル・レイヤ４０４は、１つまたは複数のアダプタ内の障害イベントにおいて、機能アダプタ上のＶＩＰＡリスト４１０内のすべてのＶＩＰＡに関するＡＲＰ更新を送信するように、ＴＣＰ／ＩＰレイヤ４０８に指示する。

他の例では、フェイルオーバ・コントローラ４１２は、アダプタ４１４、４１６、および４１８がスイッチを表し、カーネル・レイヤ４０４がスイッチ内の障害を検出できない場合などに、ＴＣＰ／ＩＰレイヤ４０８、アダプタ・レイヤ４２０、または他のレイヤ内で実装される。具体的に言えば、一例では、ＴＣＰ／ＩＰレイヤ４０８、アダプタ・レイヤ４２０、または他のレイヤが、カーネル・レイヤ４０４に渡されないアダプタ内の障害を検出できる場合、１つまたは複数のアダプタ内の障害イベントにおいて、機能アダプタ上のＶＩＰＡリスト４１０内のすべてのＶＩＰＡに関するＡＲＰ更新を送信するように、ＴＣＰ／ＩＰレイヤ４０８またはアダプタ・レイヤ４２０をトリガするために、フェイルオーバ・コントローラ４１２は、ＴＣＰ／ＩＰレイヤ４０８、アダプタ・レイヤ４２０、または他のレイヤ内に実装可能である。

ＡＲＰ更新がネットワークを介してブロードキャストされるため、結果として、ＭＡＣアドレスを読み取るネットワーク上のすべての他のホストが、物理アドレスが変更されたことを示すＡＲＰ更新を検出することになる。一例では、ＡＲＰ更新は、ＡＲＰ応答と同じヘッダまたは他の識別子を含むが、ＡＲＰ更新は一般にネットワーク内でブロードキャストされる。他の例では、ＡＲＰ更新は、アドレス指定が、以前に受信されたアドレス指定に対する更新であることを識別する、ＡＲＰ応答とは異なるヘッダまたは他の識別子を含むことができる。

要求側ホストを表すネットワーク・スタック４００に戻ると、ネットワーク・スタック４００がブロードキャストされたＡＲＰ更新を受信した場合、カーネル・レイヤ４０４は、ＶＩＰＡに関する１つのＡＲＰ更新を選択するため、および同じＶＩＰＡに関するその他を廃棄するための、ＡＲＰ規則に従って、それぞれのＶＩＰＡに関するＡＲＰ更新でブロードキャストされた１つのＭＡＣアドレスを使用して、ルーティング・テーブル４０６を更新する。この例では、現在の接続が要求側ホストと受信側ホストとの間に確立されている場合、要求側ホストは、物理アドレスではなく受信側ホストのＩＰに結合する。要求側ホストのＡＲＰ更新におけるすべてのＶＩＰＡに関して更新されたＭＡＣアドレスを受信することによって、要求側ホストが受信側ホストの更新されたＶＩＰＡのうちの１つに現在接続されている場合、受信側ホストは、現在の接続を中断することなく、ＶＩＰＡに送信された任意の新しいパケットを、更新された機能ＭＡＣアドレスのうちの１つにリダイレクトすることができる。

次に図５を参照すると、流れ図は、複数のホストとゲートウェイ・ホストとの間で送信されるＡＲＰパケットの一例を示し、ここでゲートウェイ・ホストが複数のＶＩＰＡを同時に容易にできる複数のアダプタをサポートする。

この例では、ホスト５０２は要求側ホストとして動作し、ＶＩＰＡ１に関するＡＲＰ要求を、受信側ホストとして動作するゲートウェイ５０６に送信する。ゲートウェイ５０６は、アダプタ１ ５０８、アダプタ２ ５１０、およびアダプタ３ ５１２を備え、これらはすべて、ＶＩＰＡ１およびＶＩＰＡ２として表される複数ＶＩＰＡを同時にサポートすることができる。ゲートウェイ５０６は、ＡＲＰ応答を送信することによってホスト１ ５０２からのＡＲＰ要求に応答するために、アダプタ１ ５０８、アダプタ２ ５１０、およびアダプタ３ ５１２のそれぞれをトリガする。この例では、アダプタ１ ５０８はＶＩＰＡ１およびＭＡＣ１を備えたＡＲＰ応答を送信し、ここでＭＡＣ１はアダプタ１ ５０８に関するハードウェア・アドレスを表す。同様に、この例では、アダプタ２ ５１０はＶＩＰＡ１およびＭＡＣ２を備えたＡＲＰ応答を送信し、ここでＭＡＣ２はアダプタ２ ５１０に関するハードウェア・アドレスを表し、さらにアダプタ３ ５１２はＶＩＰＡ１およびＭＡＣ３を備えたＡＲＰ応答を送信し、ここでＭＡＣ３はアダプタ３ ５１２に関するハードウェア・アドレスを表す。

図に示されるように、ホスト１ ５０２は複数のＡＲＰ応答を受信し、ＡＲＰ規則または他の規則を適用することによって、アダプタ１ ５０８に関するＡＲＰ応答を選択する。ホスト１ ５０２は、ゲートウェイ５０６のアダプタ１ ５０８上でＭＡＣ１を介してＶＩＰＡ１に結合する。

加えて、この例では、ホスト２ ５１４は要求側ホストとして動作し、ＶＩＰＡ２に関するＡＲＰ要求を、受信側ホストとして動作するゲートウェイ５０６に送信する。ゲートウェイ５０６は、ＡＲＰ応答を送信することによってホスト２ ５１４からのＡＲＰ要求に応答するために、アダプタ１ ５０８、アダプタ２ ５１０、およびアダプタ３ ５１２のそれぞれをトリガする。この例では、アダプタ１ ５０８はＶＩＰＡ２およびＭＡＣ１を備えたＡＲＰ応答を送信し、アダプタ２ ５１０はＶＩＰＡ２およびＭＡＣ２を備えたＡＲＰ応答を送信し、アダプタ３ ５１２はＶＩＰＡ２およびＭＡＣ２を備えたＡＲＰ応答を送信する。

図に示されるように、ホスト２ ５１４は複数のＡＲＰ応答を受信し、ＡＲＰ規則または他の規則を適用することによって、アダプタ３ ５１２に関するＡＲＰ応答を選択する。ホスト２ ５１４は、ゲートウェイ５０６のアダプタ３ ５１２上でＭＡＣ３を介してＶＩＰＡ２に結合する。

次にゲートウェイ５０６は、アダプタ１ ５０８内の障害を検出する。ホスト１ ５０２およびホスト２ ５１４は、ＶＩＰＡ１またはＶＩＰＡ２に関するパケットを送信するために、アダプタ１ ５０８、アダプタ２ ５１０、およびアダプタ３ ５１２のいずれかを選択することが可能であり、ゲートウェイ５０６は、ＶＩＰＡ１またはＶＩＰＡ２の両方に関するＡＲＰ更新をブロードキャストするために、アダプタ２ ５１０およびアダプタ３ ５１２をトリガする。この例では、アダプタ２ ５１０は、ＶＩＰＡ１、ＭＡＣ２、およびＶＩＰＡ２、ＭＡＣ２に関するＡＲＰ更新をブロードキャストし、これらは、ホスト１ ５０２およびホスト２ ５１４の両方によって検出される。加えて、アダプタ３ ５１２は、ＶＩＰＡ１、ＭＡＣ３、およびＶＩＰＡ２、ＭＡＣ３に関するＡＲＰ更新をブロードキャストし、これらは、ホスト１ ５０２およびホスト２ ５１４の両方によって検出される。

ホスト１ ５０２は、ＶＩＰＡ１、ＭＡＣ２と、ＶＩＰＡ１、ＭＡＣ３と、ＶＩＰＡ２、ＭＡＣ２と、ＶＩＰＡ２、ＭＡＣ３との、ＡＲＰ更新を受信し、ＭＡＣ２またはＭＡＣ３のいずれかへのＶＩＰＡ１に関するキャッシュ済みＭＡＣアドレスを更新し、ＶＩＰＡ１への接続を中断することなく、任意の新しいパケットを更新されたキャッシュ済みＭＡＣアドレスに送信する。ホスト２ ５１４も、ＶＩＰＡ１、ＭＡＣ２と、ＶＩＰＡ１、ＭＡＣ３と、ＶＩＰＡ２、ＭＡＣ２と、ＶＩＰＡ２、ＭＡＣ３との、ＡＲＰ更新を受信し、ＶＩＰＡ２に関するキャッシュ済みＭＡＣアドレスを更新する。この例では、ＭＡＣ３が依然としてＶＩＰＡ２に対して使用可能であるため、ホスト２ ５１４が、ＶＩＰＡ２に関するキャッシュ済みアドレスとしてＭＡＣ３を維持することが可能であるか、あるいはホスト２ ５１４が、ＭＡＣ２およびＭＡＣ３のうちの１つまたは複数をキャッシュするために任意に選択することができる。

次に図６を参照すると、ブロック図は、内部に本発明が実装可能な、ゲートウェイを含むネットワーク環境の一例を示す。この例では、ネットワーク環境が、サブネットワーク６００内のホストが互いにＡＲＰパケットを検出してこれに応答する、サブネットワーク６００を含む。たとえば、ゲートウェイ６０４、ホスト６０６、ホスト６０８、ホスト６１２、およびホスト６１４は、ローカル・エリア・ネットワーク（ＬＡＮ）６１０を介して互いに通信する。ゲートウェイ６０４は、インターネット６０２を介してサブネットワーク６００外部の他のシステムとも通信することができる。加えて、ホスト６０８は、他のＬＡＮ６１６を介してホスト６１８などの他のシステムと通信可能な、ルータを表す。

この例では、サブネットワーク６００内のホストのうちのいずれかが、サブネットワーク６００内のすべての他のホストによって受信されたＡＲＰ要求およびＡＲＰ更新をＬＡＮ６１０上でブロードキャストすることができる。加えて、この例では、ゲートウェイ６０４およびホストのルータ６０８は、サブネットワーク６００内のホストがサブネットワーク６００外部のシステムにアクセスする際に通過するインターフェースを提供することができる。

ゲートウェイ６０４ならびにホスト６０６、６０８、６１２、６１４、および６１８のいずれか、ならびに、ＬＡＮ６１０、ＬＡＮ６１６およびインターネット６０２のいずれかは、１つまたは複数のアダプタを含むことが可能であり、ネットワーク・スタック４００を実装することなどによって、アダプタが複数のＶＩＰＡを同時にサポートできるようにするネットワーク・スタックを実装することが可能である。たとえば、ゲートウェイ６０４は、図５でゲートウェイ５０６を参照しながら説明した複数アダプタなどの、複数のアダプタを含むことができる。

次に図７を参照すると、流れ図は、複数のＶＩＰＡの同時サポートが実行可能な複数のアダプタをサポートし、停止ゲートウェイ検出をサポートする、ホスト・システムの例を示す。この例では、ホスト７１０は、ゲートウェイ７０２がダウンしているか否かを検出するために、停止ゲートウェイ検出（ＤＧＤ）をサポートする。具体的に言えば、ホスト７１０は、ゲートウェイ７０２のインターフェースが機能しているかどうかの検出を制御するＤＧＤコントローラ７０８を含むかまたはこれにアクセスすることができる。この例では、ホスト７１０はアダプタ１ ７１２およびアダプタ２ ７１４のうちの１つを介して、ｐｉｎｇをゲートウェイ７０２に送信する。ゲートウェイ７０２は、ホストからのｐｉｎｇに応答して、ゲートウェイ７０２が機能していることを確認する。ＤＧＤコントローラ７０８がｐｉｎｇへの応答を検出しない場合、ＤＧＤコントローラ７０８はゲートウェイ停止を検出し、代替ゲートウェイの識別を試行するか、またはゲートウェイが機能していない旨の警告を提供することができる。

この例では、ホスト７１０は、アダプタ１ ７１２およびアダプタ２ ７１４が複数のＶＩＰＡを同時にサポートできるようにする。ＤＧＤコントローラ７０８と共に複数の同時ＶＩＰＡサポートが可能となることにより、ホスト７１０は、アダプタ１ ７１２およびアダプタ２ ７１４のうちの１つが障害を起こしたことを検出し、機能アダプタのハードウェア・アドレスを使用してゲートウェイ７０２を更新するため、ゲートウェイ７０２は機能アダプタへのｐｉｎｇに応答することが可能であり、停止ゲートウェイを検出するためにＤＧＤコントローラ７０８を誤ってトリガすることがない。

具体的に言えば、この例では、スイッチ７０４および７０６を通過するホスト７１０からゲートウェイ７０２への複数のパスが存在する。ＤＧＤコントローラ７０８は、スイッチ７０４を含むパスを介してアダプタ１ ７１２を通るか、またはスイッチ７０６を含むパスを介してアダプタ２ ７１４を通るかの、いずれかによって、ゲートウェイ７０２へｐｉｎｇを送信することができる。ゲートウェイ７０２は、たとえば、あらゆる他のｐｉｎｇに応答する。アダプタ２ ７１４が障害を起こした場合、ｐｉｎｇ応答がスイッチ７０４を介してアダプタ１ ７１２へとルーティングされれば、ＤＧＤコントローラ７０８は、ゲートウェイ７０２を依然として機能しているものとして検出する可能性がある。しかしながら、アダプタ２ ７１４が障害を起こした場合、ｐｉｎｇ応答がスイッチ７０６を介してアダプタ２ ７１４へとルーティングされれば、ＤＧＤコントローラ７０８は、ゲートウェイ７０２を機能していないものとして検出する可能性もある。したがって、ＤＧＤコントローラ７０８がｐｉｎｇ応答を介してゲートウェイ７０２にアクセス可能であるかどうかを監視すると同時に、ホスト７１０は、アダプタ１ ７１２およびアダプタ２ ７１４のそれぞれが機能しているかどうかを検出し、アダプタ１ ７１２およびアダプタ２ ７１４のいずれかが障害を起こした場合、ゲートウェイ７０２にＡＲＰ更新を送信する。この例では、アダプタ２ ７１４が障害を起こした場合、アダプタ１ ７１２は、アダプタ１ ７１２上でサポートされているすべてのＶＩＰＡに関するＡＲＰ更新をゲートウェイ７０２に送信することになる。ゲートウェイ７０２はＡＲＰ更新を受信し、ｐｉｎｇ応答に関するアドレスを、アダプタ１ ７１２のＭＡＣアドレスとなるように更新するため、結果としてＤＧＤコントローラ７０８は、障害を起こしたアダプタがホスト７１０のアダプタである場合、偽の停止ゲートウェイを検出することがなく、また結果として、ホスト７１０内の複数ＶＩＰＡフェイルオーバ・コントローラ２３２は、アダプタ・フェイルオーバの際にゲートウェイ７０２への「パス・フェイルオーバ」を容易にすることになる。

一例では、ユーザは、複数ＶＩＰＡフェイルオーバ・コントローラ２３２を実行可能にすることとは別に、ＤＧＤコントローラ７０８を実行可能にするように選択できる。他の例では、ＤＧＤコントローラ７０８は複数ＶＩＰＡフェイルオーバ・コントローラ２３２内で実装可能であり、アダプタ障害の更新を受信可能である。

次に図８を参照すると、高水準論理流れ図は、要求側ホストからの要求に応答する受信側ホストのネットワーク・スタックに関するプロセスおよびプログラムを示し、受信側ホストは複数のアダプタが複数のＶＩＰＡを同時にサポートできるようにする。この例では、プロセスはブロック８００で開始された後、ブロック８０２へと進む。ブロック８０２は、ＩＰアドレスに関連付けられたハードウェア・アドレスに関する要求を受信することを示す。次にブロック８０４は、要求されたＩＰアドレスに関して、受信側ホストによってサポートされる複数のＶＩＰＡのリストを調べることを示す。その後、ブロック８０６は、要求されたＩＰアドレスがＶＩＰＡリストに含まれているかどうかの決定を示す。要求されたＩＰアドレスがＶＩＰＡリストに含まれていない場合、プロセスは終了する。要求されたＩＰアドレスがＶＩＰＡリストに含まれている場合、プロセスはブロック８０８へと渡される。ブロック８０８は、各アダプタのアダプタ指定ハードウェア・アドレスと共に、要求されたＩＰアドレスに関する応答を要求側ホストに送信するために、各アダプタをトリガすることを示し、プロセスは終了する。要求はＡＲＰ要求を通じて実装可能であり、応答は、ＡＲＰ応答を通じて実装可能であり、指定されたハードウェア・アドレスはＭＡＣアドレスとすることができる。

次に図９を参照すると、高水準論理流れ図は、要求側ホストが、複数のアダプタが複数のＶＩＰＡを同時にサポートできるようにした場合、フェイルオーバを容易にするために障害アダプタに応答する受信側ホストのネットワーク・スタックに関するプロセスおよびプログラムを示す。この例では、プロセスはブロック９００で開始され、その後ブロック９０２へと進む。ブロック９０２は、ネットワーク・スタックが障害アダプタを検出したかどうかの決定を示す。前述のように、ネットワーク・スタックの異なるレイヤが障害アダプタを検出し、ネットワーク・スタックの他のレイヤに対して障害アダプタのインジケータを渡すか、またはフェイルオーバ・コントローラを直接トリガすることができる。ブロック９０２で、ネットワーク・スタックが障害アダプタを検出した場合、プロセスはブロック９０４へと渡される。ブロック９０４は、アダプタ指定ハードウェア・アドレスと共に、ＶＩＰＡリスト内の各ＶＩＰＡに関する更新をネットワーク上でブロードキャストするために、残りの各機能アダプタをトリガすることを示し、その結果、ネットワーク上の各ホストは、各アダプタに関する各ＶＩＰＡの更新を受信し、プロセスは終了する。更新は、ＡＲＰ更新を通じて実装可能であり、指定されるハードウェア・アドレスはＭＡＣアドレスとすることができる。

以上、本発明について、好ましい実施形態を参照しながら具体的に図示および説明してきたが、当業者であれば、形および細部における様々な変更が、本発明の趣旨および範囲を逸脱することなく実行可能であることを理解されよう。

Claims (19)

1. ネットワーク上での複数の仮想ＩＰアドレスのホスト・サポートにおいてフェイルオーバを管理するためのコンピュータ実装方法であって、
   前記ホストの複数のアダプタのうちの任意のアダプタが、前記ホストに割り当てられた前記複数の仮想ＩＰアドレスのうちの任意の仮想インターネット・プロトコル（ＩＰ）アドレスを同時にサポートできるようにするステップと、
   前記複数のアダプタの中の少なくとも１つの特定アダプタの障害に応答して、各仮想ＩＰアドレスに関する別々のハードウェア・アドレス更新を、前記ネットワークを介して前記複数のアダプタの中の残りの各アダプタからブロードキャストするステップであって、結果として、前記複数の仮想ＩＰアドレスをサポートする前記ホストにおけるフェイルオーバの場合、前記ホストが、前記ネットワークを介してアクセス可能な少なくとも１つの他のホストに、前記複数の仮想ＩＰアドレスに関する任意の新しいパケットを、前記残りのアダプタのうちの１つの前記別々のハードウェア・アドレスのうちの１つへとアドレス指定するように指示する、ブロードキャストするステップと、
   を含む、コンピュータ実装方法。
2. 前記ホストの複数のアダプタのうちの任意のアダプタが、前記ホストに割り当てられた前記複数の仮想ＩＰアドレスのうちの任意の仮想インターネット・プロトコル（ＩＰ）アドレスを同時にサポートできるようにするステップが、
   前記ホストで受信したＡＲＰ要求内に指定されたＩＰアドレスと、前記複数の仮想ＩＰアドレスのリストとを比較して、前記ホストが前記複数の仮想ＩＰアドレスのリスト内の前記ＩＰアドレスをサポートしているかどうかを判別するために、前記ホスト上にネットワーク・スタックを構成するステップをさらに含む、請求項１に記載の方法。
3. 前記ホストが、前記複数の仮想ＩＰアドレスのうちの特定仮想ＩＰアドレスに一致する特定のＩＰアドレスに関して、前記少なくとも１つの他のホストの中から要求側ホストからのＡＲＰ要求を受信することに応答して、前記特定仮想ＩＰアドレスに関する前記アダプタの各ハードウェア・アドレスと共に、前記要求側ホストにＡＲＰ応答を送信するために前記複数のアダプタそれぞれをトリガするステップであって、前記要求側ホストが、前記複数のアダプタからの前記複数のＡＲＰ応答のうちの１つを格納する、トリガするステップをさらに含む、請求項１または２に記載の方法。
4. `前記各仮想ＩＰアドレスに関する別々のハードウェア・アドレス更新を受信する前記少なくとも１つの他のホストに応答して、前記少なくとも１つの他のホストにより、前記複数の仮想ＩＰアドレスのうちの１つに結合された接続を、前記残りのアダプタのうちの１つの前記別々のハードウェア・アドレスのうちの特定の１つにリダイレクトするステップを、さらに含む、請求項１から３ののいずれか一項に記載の方法。
5. 前記ネットワークを介した各仮想ＩＰアドレスに関する前記別々のハードウェア・アドレス更新が、各仮想ＩＰアドレスに関するＭＡＣアドレスを指定する別々のＡＲＰ更新である、請求項１から４ののいずれか一項に記載の方法。
6. 前記ホストが、サブネットワークと少なくとも１つの他のネットワークとの間のゲートウェイである、請求項１から５ののいずれか一項に記載の方法。
7. 前記ゲートウェイがｐｉｎｇへの応答を戻す場合に、前記ゲートウェイが機能しているかどうかを判別するために、前記ホストによって、ゲートウェイを備える前記少なくとも１つの他のホストへｐｉｎｇを定期的に送信するステップをさらに含む、請求項１から６ののいずれか一項に記載の方法。
8. ホストの複数のアダプタのうちの任意のアダプタが、前記ホストに割り当てられた複数の仮想ＩＰアドレスのうちの任意の仮想インターネット・プロトコル（ＩＰ）アドレスを同時にサポートできるようにするための、ネットワーク・レイヤを備えるホストであって、
   前記ホストが、ネットワークを介して、少なくとも１つの他のホストへと通信的に接続され、
   前記ホストが、前記複数のアダプタの中の少なくとも１つの特定アダプタの障害に応答して、各仮想ＩＰアドレスに関する別々のハードウェア・アドレス更新を、前記ネットワークを介して前記複数のアダプタの中の残りの各アダプタからブロードキャストするための、前記ネットワーク・レイヤをさらに備え、前記複数の仮想ＩＰアドレスをサポートする前記ホストにおけるフェイルオーバの場合、前記ネットワーク・レイヤが、前記ネットワークを介してアクセス可能な前記少なくとも１つの他のホストに、前記複数の仮想ＩＰアドレスに関する任意の新しいパケットを、前記残りのアダプタのうちの１つの前記別々のハードウェア・アドレスのうちの１つへとアドレス指定するように指示する、
   ホストを備える、フェイルオーバを管理するためのシステム。
9. 前記ホストの複数のアダプタのうちの任意のアダプタが、前記ホストに割り当てられた前記複数の仮想ＩＰアドレスのうちの任意の仮想インターネット・プロトコル（ＩＰ）アドレスを同時にサポートできるようにするための前記ネットワーク・レイヤが、
   前記ホストで受信したＡＲＰ要求内に指定されたＩＰアドレスと、前記複数の仮想ＩＰアドレスのリストとを比較して、前記ホストが前記複数の仮想ＩＰアドレスのリスト内の前記ＩＰアドレスをサポートしているかどうかを判別するために、前記ホスト上にネットワーク・スタックを構成するための、移送レイヤをさらに備える、請求項８に記載のシステム。
10. 前記ホストが、前記複数の仮想ＩＰアドレスのうちの特定仮想ＩＰアドレスに一致する特定のＩＰアドレスに関して、前記少なくとも１つの他のホストの中から要求側ホストからのＡＲＰ要求を受信することに応答して、前記特定仮想ＩＰアドレスに関する前記アダプタの各ハードウェア・アドレスと共に、前記要求側ホストにＡＲＰ応答を送信するために前記複数のアダプタそれぞれをトリガするための、前記ネットワーク・レイヤをさらに備え、前記要求側ホストが、前記複数のアダプタからの前記複数のＡＲＰ応答のうちの１つを格納する、請求項８または９に記載のシステム。
11. 前記各仮想ＩＰアドレスに関する別々のハードウェア・アドレス更新を受信する前記少なくとも１つの他のホストに応答して、前記複数の仮想ＩＰアドレスのうちの１つに結合された接続を、前記残りのアダプタのうちの１つの前記別々のハードウェア・アドレスのうちの特定の１つにリダイレクトするための、前記少なくとも１つの他のホストをさらに備える、請求項８から１０のいずれか一項に記載のシステム。
12. 前記ネットワークを介した各仮想ＩＰアドレスに関する前記別々のハードウェア・アドレス更新が、各仮想ＩＰアドレスに関するＭＡＣアドレスを指定する別々のＡＲＰ更新である、請求項８から１１のいずれか一項に記載のシステム。
13. 前記ホストが、サブネットワークと少なくとも１つの他のネットワークとの間のゲートウェイである、請求項８から１２のいずれか一項に記載のシステム。
14. 前記ゲートウェイがｐｉｎｇへの応答を戻す場合に、前記ゲートウェイが機能しているかどうかを判別するために、ゲートウェイを備える前記少なくとも１つの他のホストへｐｉｎｇを定期的に送信するためのホストをさらに備える、請求項８から１３のいずれか一項に記載のシステム。
15. ネットワーク上での複数の仮想ＩＰアドレスのホスト・コンピュータにおけるサポートにおいてフェイルオーバを管理するためのプログラムであって、前記プログラムは、前記ホスト・コンピュータに、
    前記ホスト・コンピュータの複数のアダプタのうちの任意のアダプタが、前記ホスト・コンピュータに割り当てられた前記複数の仮想ＩＰアドレスのうちの任意の仮想インターネット・プロトコル（ＩＰ）アドレスを同時にサポートできるようにすること、および
    前記複数のアダプタの中の少なくとも１つの特定アダプタの障害に応答して、各仮想ＩＰアドレスに関する別々のハードウェア・アドレス更新を、前記ネットワークを介して前記複数のアダプタの中の残りの各アダプタから少なくとも１つの他のホストに対してブロードキャストすることを、
    実行させる、プログラム。
16. 前記プログラムは、前記ホスト・コンピュータにさらに、
    前記ホスト・コンピュータで受信したＡＲＰ要求内に指定されたＩＰアドレスと、前記複数の仮想ＩＰアドレスのリストとを比較して、前記ホスト・コンピュータが前記複数の仮想ＩＰアドレスのリスト内の前記ＩＰアドレスをサポートしているかどうかを判別するために、前記ホスト・コンピュータ上にネットワーク・スタックを構成することを実行させる、請求項１５に記載のプログラム。
17. 前記プログラムは、前記ホスト・コンピュータにさらに、
    前記ホスト・コンピュータが、前記複数の仮想ＩＰアドレスのうちの特定仮想ＩＰアドレスに一致する特定のＩＰアドレスに関して、前記少なくとも１つの他のホストの中から要求側ホストからのＡＲＰ要求を受信することに応答して、前記特定仮想ＩＰアドレスに関する前記アダプタの各ハードウェア・アドレスと共に、前記要求側ホストにＡＲＰ応答を送信するために前記複数のアダプタそれぞれをトリガすることを実行させ、前記要求側ホストにおいて、前記複数のアダプタからの複数のＡＲＰ応答のうちの１つが格納される、請求項１５から１６のいずれか一項に記載のプログラム。
18. 前記プログラムは、前記少なくとも１つの他のホストに、
    前記各仮想ＩＰアドレスに関する別々のハードウェア・アドレス更新を受信することに応答して、前記複数の仮想ＩＰアドレスのうちの１つに結合された接続を、前記残りのアダプタのうちの１つの前記別々のハードウェア・アドレスのうちの特定の１つにリダイレクトすることを実行させる、請求項１５から１７のいずれか一項に記載のプログラム。
19. 前記プログラムは、前記ホスト・コンピュータにさらに、
    前記ネットワークを介した各仮想ＩＰアドレスに関する前記別々のハードウェア・アドレス更新を、各仮想ＩＰアドレスに関するＭＡＣアドレスを指定する別々のＡＲＰ更新を通じて更新することを実行させる、請求項１５から１８のいずれか一項に記載のプログラム。

Images