JP4001698B2 - 負荷分散システム - Google Patents
負荷分散システム Download PDFInfo
- Publication number
- JP4001698B2 JP4001698B2 JP29290699A JP29290699A JP4001698B2 JP 4001698 B2 JP4001698 B2 JP 4001698B2 JP 29290699 A JP29290699 A JP 29290699A JP 29290699 A JP29290699 A JP 29290699A JP 4001698 B2 JP4001698 B2 JP 4001698B2
- Authority
- JP
- Japan
- Prior art keywords
- server
- primary
- load balancer
- load
- client
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/101—Server selection for load balancing based on network conditions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1038—Load balancing arrangements to avoid a single path through a load balancer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、クライアント／サーバシステムにおけるサーバの負荷を分散させる負荷分散装置に関するものであり、特に、災害発生時のサービス停止回避機能を備える負荷分散システムに関するものである。
【０００２】
近時、インターネットに代表される大規模ネットワークにおいては、１台のサーバに対する負荷集中を解決すべく、多数のアクセスを受けるサーバ側にサーバを複数台用意して、クライアントに対して、上記複数のサーバがあたかも１台のサーバとして機能しているように構成する負荷分散技術が用いられている。
【０００３】
この負荷分散技術は、クライアントからのアクセスを複数のサーバに分散させることにより、１台のサーバの負荷を低減させるための技術である。したがって、負荷分散技術においては、クライアントよりアクセスがあった場合、複数のサーバのうち、できるだけ低負荷であってかつ当該クライアントとの間の距離が短い１台のサーバに当該アクセスを振り分けることがネットワーク効率を高める上で重要である。
【０００４】
【従来の技術】
図１８は、従来のネットワークシステムの構成例１を示す図である。この図に示したネットワークシステムには、ＤＮＳ（Domain Name System）サーバにおける負荷分散の方式として、ラウンド・ロビン方式が採用されている。このラウンド・ロビン方式は、後述するドメイン名を用いてアクセスを受け付け、そのドメイン名をＩＰ（Internet Protocol）アドレスに変換する際に、複数のサーバのＩＰアドレスを順番に用いることにより、負荷分散を行う方式である。
【０００５】
同図において、ＬＡＮ（Local Area Network）／ＷＡＮ（Wide Area Network）１およびＬＡＮ／ＷＡＮ４は、インターネットワーキング（相互接続）によって、物理的に離隔配置されている複数のコンピュータ間でデータ通信を行うための大規模ネットワークであり、たとえば、インターネットである。
【０００６】
ここで、上記インターネットとしては、つぎの条件を満たすネットワークが該当する。
（１）コンピュータネットワークが、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）と呼ばれる通信プロトコル（通信接続手順）を実装していること。
（２）コンピュータネットワークが、いくつかの基幹ネットワークを中心として構成された一つの世界規模のネットワークに接続されていること。
【０００７】
また、上記ＴＣＰ／ＩＰとしては、ＯＳＩ（Open Systems Interconnection：開放形システム間相互接続）参照モデルの第４層（トランスポート層）にあるＴＣＰおよびＵＤＰ（User Datagram Protocol）の各プロトコルが定義されている。上記ＴＣＰの特徴は、信頼性のあるデータ通信（転送）を行うこと、すなわち、通信の開始から終了まで通信路の信頼性を保持してデータの正常な通信の制御、さらにエラー時のエラー検出及び回復を行うことにある。
【０００８】
また、上記ＴＣＰが信頼性を確保するためにコネクション形のサービス形態をとっているのに対して、ＵＤＰは、処理の高速化のためのコネクションレス型と呼ばれるデータ伝送プロトコルであり、信頼性向上のための応答確認やネットワーク内の異なった経路を通ってきた受信データの順序調整等を行わない。
【０００９】
クライアント２は、クライアント（ユーザ）側に設置されており、ＬＡＮ／ＷＡＮ１に接続されている。このクライアント２は、ＬＡＮ／ＷＡＮ１およびＬＡＮ／ＷＡＮ４を介して、後述するサーバ６（サーバ７）に対してサービスを要求するためのコンピュータ端末である。クライアント側ＤＮＳサーバ３は、インターネット標準のＤＮＳを実現するためのサーバであり、ＬＡＮ／ＷＡＮ１に接続されている。
【００１０】
ここで、上記ＤＮＳについて詳述する。インターネットにおいては、上述したように端末を識別するためにＩＰアドレスが用いられているが、このＩＰアドレスは、４オクテット（３２ビット）で表現される数字の組み合わせからなるため、人間にとって非常に覚えにくい。そこで、各端末には、人間にも理解し易い識別名称としてドメイン名（名前空間）がそれぞれ付与されている。
【００１１】
上記ＤＮＳは、ドメイン名とＩＰアドレスとの対応を管理し、クライアント２からのドメイン名による問い合わせに対してＩＰアドレスを応答するシステムである。このことから、クライアント側ＤＮＳサーバ３は、上記ＤＮＳを実現するための装置であり、クライアント２に対してローカルなＤＮＳサーバとして位置づけられる。
【００１２】
サーバ６は、サービス提供者側に設置されており、ＬＡＮ／ＷＡＮ４に接続されている。このサーバ６は、クライアント２からのサービス要求に応じてクライアント２に対してサービスの提供を行うためのコンピュータ端末である。サーバ７は、サーバ６と同様にして、サービス提供者側に設置されており、ＬＡＮ／ＷＡＮ４に接続されている。このサーバ７は、クライアント２からのサービス要求に応じてクライアント２に対してサービスの提供を行うための端末である。ここで、上述したサーバ６およびサーバ７は、それぞれ物理的に別々の場所に設置されている。したがって、サーバ６およびサーバ７とクライアント２（クライアント側ＤＮＳサーバ３）との間の各距離は、それぞれ異なる。
【００１３】
さらに、サーバ６およびサーバ７は、クライアント２からみればあたかも１台のサーバとして機能している。また、サーバ６およびサーバ７には、代表として一つのドメイン名（以下、代表ドメイン名と称する）が付与されているとともに、それぞれにＩＰアドレスが付与されている。すなわち、この場合には、一つのドメイン名に複数のＩＰアドレスが登録されており、クライアント２が一つのドメイン名としてアクセスすることにより、サーバ６、サーバ７のうちいずれか一つのサーバにアクセス可能とされる。
【００１４】
すなわち、サーバ６、サーバ７は、代表ドメイン名で表される一つの仮想サーバを構成しており、クライアント２は、この仮想サーバの代表ドメイン名に対してアクセスする。このように、サーバ６、サーバ７に対して一つの代表ドメイン名を付与するとともに、クライアント２からのアクセスをサーバ６、サーバ７のいずれか一つのサーバにアクセス可能としたのは、前述した負荷分散するためである。この負荷分散については後述する。
【００１５】
サーバ側ＤＮＳサーバ５は、クライアント側ＤＮＳサーバ３と同様にして、ＤＮＳサーバとしての機能を有しており、クライアント側ＤＮＳサーバ３の上位装置として位置づけられている。すなわち、サーバ側ＤＮＳサーバ５は、クライアント側ＤＮＳサーバ３からのＩＰアドレスの問い合わせに対して応答する機能を有している。
【００１６】
また、サーバ側ＤＮＳサーバ５は、サーバ６、サーバ７を配下に置いており、クライアント側ＤＮＳサーバ３から代表ドメイン名をＩＰアドレスに変換するための問い合わせがあったとき、代表ドメイン名を、サーバ６、サーバ７のうち、いずれか一つのサーバのＩＰアドレスに変換して、クライアント側ＤＮＳサーバ３に応答する。すなわち、サーバ側ＤＮＳサーバ５は、クライアント２からのアクセス要求を、サーバ６、サーバ７のうち、いずれか一つへ振り分けているのである。この振り分けが上述した負荷分散である。
【００１７】
上記構成において、上述した代表ドメイン名の仮想サーバにアクセスする場合、たとえば、ステップＳＡ１では、クライアント２は、クライアント側ＤＮＳサーバ３に対してＩＰアドレスの問い合わせを行べく、代表ドメイン名をクライアント側ＤＮＳサーバ３へＬＡＮ／ＷＡＮ１を介して、通知する。
【００１８】
クライアント側ＤＮＳサーバ３は、自身のキャッシュメモリ（図示略）にアクセスし、問い合わせ履歴データを参照することで、過去に同様の問い合わせがあったか否かを判断する。ここで、過去に同様の問い合わせがあった場合には、ステップＳＡ４では、クライアント側ＤＮＳサーバ３は、問い合わせ履歴データに含まれるＩＰアドレスをＬＡＮ／ＷＡＮ１を介してクライアント２へ通知する。なお、キャッシュメモリにおける問い合わせ履歴データの保存期間は、１日程度である。
【００１９】
一方、過去に同様の問い合わせが無かった場合、ステップＳＡ２では、クライアント側ＤＮＳサーバ３は、ＬＡＮ／ＷＡＮ１およびＬＡＮ／ＷＡＮ４を介してサーバ側ＤＮＳサーバ５へＤＮＳ問合せを行う。具体的には、クライアント側ＤＮＳサーバ３は、代表ドメイン名をサーバ側ＤＮＳサーバ５へ通知する。これにより、ステップＳＡ３では、サーバ側ＤＮＳサーバ５は、まず、第１番目のサーバをサーバ６、第２番目のサーバをサーバ７とする振分テーブル（図示略）を参照することで、通知を受けた代表ドメイン名をたとえば第１番目のサーバ６のＩＰアドレスに変換する。
【００２０】
つぎに、サーバ側ＤＮＳサーバ５は、上記サーバ６のＩＰアドレスをＬＡＮ／ＷＡＮ４およびＬＡＮ／ＷＡＮ１を介してクライアント側ＤＮＳサーバ３へ通知する。これにより、ステップＳＡ４では、クライアント側ＤＮＳサーバ３は、サーバ６のＩＰアドレスを前述した問い合わせ履歴データとしてキャッシュメモリ（図示略）に保存した後、ＬＡＮ／ＷＡＮ１を介してクライアント２へ通知する。
【００２１】
そして、ステップＳＡ５では、上記通知を受けたクライアント２は、サーバ６のＩＰアドレスを含むＩＰパケットをＬＡＮ／ＷＡＮ１およびＬＡＮ／ＷＡＮ４を介してサーバ６へ送出する。そして、上記ＩＰパケットは、図示しないルータによりルーティングされた後、サーバ６に到着する。この結果、クライアント２とサーバ６との間に接続が確立し、サーバ６は、クライアント２から要求されたサービスを提供する。
【００２２】
また、図示しない別のクライアントにより、代表ドメイン名がクライアント側ＤＮＳサーバ３へＬＡＮ／ＷＡＮ１を介して通知されると（ステップＳＡ１）、ステップＳＡ２では、クライアント側ＤＮＳサーバ３は、上述した動作と同様にして、ＬＡＮ／ＷＡＮ１およびＬＡＮ／ＷＡＮ４を介してサーバ側ＤＮＳサーバ５へＩＰアドレスの問い合わせを行う。この場合、過去に同様の問い合わせが無かったものとする。
【００２３】
これにより、ステップＳＡ３では、サーバ側ＤＮＳサーバ５は、振分テーブル（図示略）を参照することで、通知を受けた代表ドメイン名を、つぎの第２番目のサーバ７のＩＰアドレスに変換する。そして、サーバ側ＤＮＳサーバ５は、上記サーバ７のＩＰアドレスをＬＡＮ／ＷＡＮ４およびＬＡＮ／ＷＡＮ１を介してクライアント側ＤＮＳサーバ３へ通知する。つぎのステップＳＡ４では、クライアント側ＤＮＳサーバ３は、サーバ７のＩＰアドレスをＬＡＮ／ＷＡＮ１を介してクライアント（図示略）へ通知する。
【００２４】
そして、ステップＳＡ５では、上記通知を受けたクライアント（図示略）は、サーバ７のＩＰアドレスを含むＩＰパケットをＬＡＮ／ＷＡＮ１およびＬＡＮ／ＷＡＮ４を介してサーバ７へ送出する。そして、上記ＩＰパケットは、図示しないルータによりルーティングされた後、サーバ７に到着する。この結果、クライアント（図示略）とサーバ７との間に接続が確立し、サーバ７は、クライアント（図示略）から要求されたサービスを提供する。
【００２５】
以後、サーバ側ＤＮＳサーバ５は、ＩＰアドレスの問い合わせを受ける度に、振分テーブルを参照しつつ、クライアントからのアクセスをサーバ６→サーバ７→サーバ６→サーバ７→・・・という具合に振り分けることにより、負荷分散を行う。
【００２６】
つぎに、図１９に示したように、災害が発生することにより、サーバ６がシステムダウンするとともに、サーバ７にかかる回線が切断された場合の動作について説明する。同図において、災害発生により、サーバ６がシステムダウンするとともに、サーバ７にかかる回線が切断されると、サーバ６およびサーバ７は、外部からのアクセスができない状態になる。このとき、サーバ側ＤＮＳサーバ５における振分テーブルから上記サーバ６およびサーバ７が削除されていないものとする。
【００２７】
このような状態において、ステップＳＢ１では、クライアント２は、クライアント側ＤＮＳサーバ３に対してＩＰアドレスの問い合わせを行べく、代表ドメイン名をクライアント側ＤＮＳサーバ３へＬＡＮ／ＷＡＮ１を介して、通知する。
【００２８】
クライアント側ＤＮＳサーバ３は、自身のキャッシュメモリ（図示略）にアクセスし、問い合わせ履歴データを参照することで、過去に同様の問い合わせがあったか否かを判断する。ここで、災害が発生する以前の問い合わせ履歴データがキャッシュメモリに保存されているものとすると、ステップＳＢ４では、クライアント側ＤＮＳサーバ３は、問い合わせ履歴データに含まれる、たとえば、サーバ６のＩＰアドレスをＬＡＮ／ＷＡＮ１を介してクライアント２へ通知する。
これにより、ステップＳＢ５では、クライアント２は、サーバ６へアクセスを試みるが、サーバ６がシステムダウンしているため、アクセスできない。すなわち、この場合には、キャッシュメモリに災害が発生する以前の問い合わせ履歴データがそのまま残っているため、実際にはアクセス不可能なサーバ６のＩＰアドレスがクライアント２へ通知されたのである。
【００２９】
一方、過去に同様の問い合わせが無かった場合、ステップＳＢ２では、クライアント側ＤＮＳサーバ３は、ＬＡＮ／ＷＡＮ１およびＬＡＮ／ＷＡＮ４を介して代表ドメイン名をサーバ側ＤＮＳサーバ５へ通知する。これにより、ステップＳＢ３では、サーバ側ＤＮＳサーバ５は、まず、第１番目のサーバをサーバ６、第２番目のサーバをサーバ７とする振分テーブル（図示略）を参照することで、通知を受けた代表ドメイン名をたとえば第１番目のサーバ６のＩＰアドレスに変換する。ここで、注意すべき点は、上記振分テーブルは、災害発生以前のものであり、現時点のサーバ６の状態（アクセス不可能）が反映されたものではない。
【００３０】
つぎに、ステップＳＢ３でサーバ側ＤＮＳサーバ５は、上記サーバ６のＩＰアドレスをＬＡＮ／ＷＡＮ４およびＬＡＮ／ＷＡＮ１を介してクライアント側ＤＮＳサーバ３へ通知する。これにより、ステップＳＢ４では、クライアント側ＤＮＳサーバ３は、サーバ６のＩＰアドレスを前述した問い合わせ履歴データとしてキャッシュメモリ（図示略）に保存した後、ＬＡＮ／ＷＡＮ１を介してクライアント２へ通知する。そして、ステップＳＢ５では、上記通知を受けたクライアント２は、サーバ６へアクセスを試みるが、サーバ６がシステムダウンしているため、アクセスできない。
【００３１】
また、図示しない別のクライアントにより、代表ドメイン名がクライアント側ＤＮＳサーバ３へＬＡＮ／ＷＡＮ１を介して通知されると（ステップＳＢ１）、ステップＳＢ２では、クライアント側ＤＮＳサーバ３は、上述した動作と同様にして、ＬＡＮ／ＷＡＮ１およびＬＡＮ／ＷＡＮ４を介してサーバ側ＤＮＳサーバ５へ仮想サーバのＩＰアドレスの問い合わせを行う。この場合、過去に同様の問い合わせが無かったものとする。
【００３２】
これにより、ステップＳＢ３では、サーバ側ＤＮＳサーバ５は、振分テーブル（図示略）を参照することで、通知を受けた代表ドメイン名を、つぎの第２番目のサーバ７のＩＰアドレスに変換する。ここで注意すべき点は、上記振分テーブルの内容は、災害が発生する以前のものであり、現時点のサーバ７の状態（アクセス不可能）が反映されたものではない。
【００３３】
そして、サーバ側ＤＮＳサーバ５は、上記サーバ７のＩＰアドレスをＬＡＮ／ＷＡＮ４およびＬＡＮ／ＷＡＮ１を介してクライアント側ＤＮＳサーバ３へ通知する。つぎのステップＳＢ４では、クライアント側ＤＮＳサーバ３は、サーバ７のＩＰアドレスをＬＡＮ／ＷＡＮ１を介してクライアント（図示略）へ通知する。そして、ステップＳＢ５では、上記通知を受けたクライアントは、サーバ７へアクセスを試みるが、サーバ７にかかる回線が切断されているため、アクセスできない。
【００３４】
図２０は、従来のネットワークシステムの構成例２を示す図である。この図に示したネットワークシステムでは、負荷分散方式として、ＮＡＴ（Network Address Translator：ネットワークアドレス変換）によりＩＰヘッダの宛先アドレスを、振り分け先のサーバのＩＰアドレスに変換するＮＡＴ方式や、上記宛先アドレスを振り分け先のサーバのＭＡＣ（Media Access Control：媒体アクセス制御）アドレスに付け替える等のＭＡＣ方式が採用されている。
【００３５】
同図において、ＬＡＮ／ＷＡＮ１０は、インターネットワーキング（相互接続）によって、物理的に離隔配置されている複数のコンピュータ間でデータ通信を行うための大規模ネットワークであり、たとえば、インターネットである。クライアント１１は、クライアント（ユーザ）側に設置されており、ＬＡＮ／ＷＡＮ１０に接続されている。
【００３６】
このクライアント１１は、上述したＩＰパケットをＬＡＮ／ＷＡＮ１０を介して、後述するサーバ１３（サーバ１４）に対してサービスを要求するためのコンピュータ端末である。負荷分散装置１２は、上述したＮＡＴ方式やＭＡＣ方式により、クライアント１１からのアクセス要求をサーバ１３、サーバ１４のうちいずれか一つへ振り分けることにより、負荷分散を行う装置である。この負荷分散装置１２には、サーバ１３およびサーバ１４を代表する代表ＩＰアドレスが付与されている。
【００３７】
サーバ１３およびサーバ１４は、サービス提供者側に設置されており、ＬＡＮ／ＷＡＮ１０に接続されている。これらのサーバ１３およびサーバ１４は、クライアント１１からのサービス要求に応じてクライアント１１に対してサービスの提供を行うためのコンピュータ端末である。また、サーバ１３およびサーバ１４は、上述した代表ＩＰアドレスにより、クライアント１１からみればあたかも１台のサーバとして機能しており、それぞれにＩＰアドレスが付与されている。すなわち、サーバ１３、サーバ１４は、代表ＩＰアドレスで表される一つの仮想サーバを構成しており、クライアント１１は、この仮想サーバの代表ＩＰアドレスに対してアクセスする。
【００３８】
上記構成において、上述した仮想サーバにアクセスする場合、たとえば、ステップＳＣ１では、クライアント１１は、代表ＩＰアドレスを有する負荷分散装置１２へＬＡＮ／ＷＡＮ１０を介してアクセスする。これにより、ステップＳＣ２では、負荷分散装置１２は、クライアント１１からのＩＰパケット（サービス要求）を、ＮＡＴ方式やＭＡＣ方式により、たとえば、サーバ１４へ振り分ける。
【００３９】
つぎのステップＳＣ３では、クライアント１１とサーバ１４との間に、ＬＡＮ／ＷＡＮ１０および負荷分散装置１２を介して接続が確立し、サーバ１４は、クライアント１１から要求されたサービスを提供する。なお、クライアント１１とサーバ１４との接続ルートとしては、ステップＳＣ４のように、負荷分散装置１２を経由せず、ＬＡＮ／ＷＡＮ１０のみを介する接続ルートの場合もある。
【００４０】
つぎに、図２１に示したように、災害が発生することにより、負荷分散装置１２がシステムダウンするとともに、ＬＡＮ／ＷＡＮ１０に回線断が発生した場合の動作について説明する。ここで、災害の影響は、サーバ１３およびサーバ１４には、及んでいないものとする。
【００４１】
このような状態において、ステップＳＤ１では、クライアント１１は、代表ＩＰアドレスを有する負荷分散装置１２へアクセスを試みるが、負荷分散装置１２がシステムダウンしているとともに、ＬＡＮ／ＷＡＮ１０が回線断状態にあるため、サーバ１３およびサーバ１４が正常に稼働しているにもかかわらず、アクセスできない。
【００４２】
【発明が解決しようとする課題】
ところで、従来のネットワークシステムにおいては、図１８に示したクライアント側ＤＮＳサーバ３およびサーバ側ＤＮＳサーバ５、図２０に示した負荷分散装置１２により効率的に負荷分散を行っている旨を述べた。
【００４３】
しかしながら、従来のネットワークシステムは、図１９および図２１を参照して説明したように、災害に非常に弱いシステムであり、たとえば、一つの負荷分散装置１２が災害によりシステムダウンした場合であってもすべてのサービスが停止してしまう。
【００４４】
そこで、災害発生によるサービス停止を回避する方法として、各装置を冗長構成にする方法が採られる。しかしながら、この方法は、冗長構成が採られた複数の装置が設置されている地域に地震等の災害が発生した場合、当該複数の装置のすべてが被災する可能性が高く、根本的な解決にはならない。
【００４５】
本発明は、このような背景の下になされたもので、災害発生によるサービス停止を回避することができる負荷分散システムを提供することを目的とする。
【００４６】
【課題を解決するための手段】
上記目的を達成するために、請求項１にかかる発明は、サービスの提供を求めるクライアント（後述する一実施の形態のクライアント１００および２００に相当）の要求を、前記サービスを提供するサーバ（後述する一実施の形態のサーバ５１０、５２０、６１０および６２０に相当）を含むサイト（後述する一実施の形態のサービスサイトＳＳ 1 およびＳＳ 2 に相当）のいずれか１つに振り分けさせる一次負荷分散手段（後述する一実施の形態の一次負荷分散装置４１０、４２０、４３０に相当）と、自身が属するサイトに前記要求が振り分けられた場合に、該サイトに属するサーバのいずれか１つに該要求を振り分ける二次負荷分散手段（後述する一実施の形態の二次負荷分散装置５００および６００に相当）とを備える負荷分散システムであって、前記一次負荷分散手段は、前記二次負荷分散手段の運転状態を監視し、運転停止していない二次負荷分散手段を含むサイトのいずれか１つに前記要求を振り分けさせるとともに、監視結果を各二次負荷分散手段に配布し、前記二次負荷分散手段は、自身が属するサイトに含まれるサーバの負荷が所定よりも高い場合に、前記監視結果に基づいて運転停止していない他の二次負荷分散手段を選択し、自身が属するサイトへ振り分けられた前記要求を前記他の二次負荷分散手段へ転送することを特徴とする。
【００４７】
この請求項１にかかる発明によれば、あるクライアントからサービス要求があると、このサービス要求は、複数の一次負荷分散手段のうちいずれか一つの一次負荷分散手段により一つのサイト（二次負荷分散手段）に一次振り分けされる。そして、二次負荷分散手段は、当該サービス要求を一つのサーバに二次振り分けする。
【００４８】
また、一次負荷分散手段は、各二次負荷分散手段の運転状況を監視し、いずれかの二次負荷分散手段が運転停止した場合には、当該二次負荷分散手段は、一次振り分けにおける負荷分散の対象から除外される。したがって、災害発生等により二次負荷分散手段に障害が発生した場合には、クライアントからサービス要求があっても、除外された二次負荷分散手段に対しては一次振り分けが行われることがなく、その他の正常な二次負荷分散に対して一次振り分けが行われる。
【００４９】
また、いずれかのサイトの負荷が所定よりも高くなった場合には、そのサイトの二次負荷分散手段が他の正常な二次負荷分散手段へサービス要求を転送することにより、二次負荷分散手段間の協調による負荷分散が実現される。
【００５０】
このように、請求項１にかかる発明によれば、災害発生によるサービス停止を回避することができ、さらに、二次負荷分散手段間の協調によっても負荷分散を実現可能な２段階方式の負荷分散システムを得ることができる。
【００５１】
また、請求項２にかかる発明は、請求項１に記載の負荷分散システムにおいて、前記一次負荷分散手段は、サービスを提供するサーバにアクセスするためのドメイン名の解決を求めるＤＮＳ問合せに対して、前記二次負荷分散手段のいずれか１つのＩＰアドレスを応答することにより、該ＩＰアドレスを有する二次負荷分散手段を含むサイトへ前記要求を振り分けさせ、前記二次負荷分散手段は、自身が属するサイトに属するサーバのいずれか１つに前記要求を振り分ける場合に、自身が有するＩＰアドレスを宛先として前記クライアントから送信された前記要求のヘッダ部を書き換えることにより、前記サービスを提供するサーバに該要求を振り分けることを特徴とする。
【００５２】
この請求項２にかかる発明によれば、一次振り分けはＤＮＳ問合せに対して応答する二次負荷分散手段のＩＰアドレスを切り替えることで実現され、一次振り分けはアドレス情報を書き換えることで実現される。
【００５３】
このように、請求項２にかかる発明によれば、一次振り分けの結果は、ＤＮＳ問合せのキャッシュとして問合せ元に一定期間記憶され、キャッシュを保持している問合せ元では、このキャッシュに基づいて一次振り分けが行われることになるため、一次負荷分散手段の負荷が軽減される。
【００５４】
また、請求項３にかかる発明は、請求項２に記載の負荷分散システムにおいて、前記一次負荷分散手段は、各二次負荷分散手段に対して、前記ＤＮＳ問合せの送信元と当該の二次負荷分散手段との間の通信経路の経路負荷の計測を依頼し、計測された経路負荷に係る情報に基づいて、サービスを提供するサーバにアクセスするためのドメイン名の解決を求めるＤＮＳ問合せを受信した場合に、該ＤＮＳ問合せの送信元との間の経路負荷が最も少ない二次負荷分散手段のＩＰアドレスを応答することを特徴とする。
【００５５】
この請求項３にかかる発明によれば、一次負荷分散手段は、ＤＮＳ問合せの送信元との間の経路負荷が最も少ない二次負荷分散手段を、サービス要求の振り分け先として選択する。本来は、サービス要求の送信元との間の経路負荷が最も少ない二次負荷分散手段を、サービス要求の振り分け先として選択することが好ましいが、一次負荷分散手段は、サービス要求の送信元と直接情報のやりとりをすることはないため、サービス要求の送信元を識別することはできない。そこで、一次負荷分散手段は、直接情報のやりとりをし、サービス要求の送信元と近い位置にあると期待されるＤＮＳ問合せの送信元との間の経路負荷を基準にして、二次負荷分散手段を選択する。
【００５６】
このように、請求項３にかかる発明によれば、サービス要求の送信元との間の経路負荷が最も少ないことが期待される二次負荷分散手段がサービス要求の振り分け先として選択されるので、ネットワークに負荷をかけることなく負荷分散を実現することができる。
【００６４】
【発明の実施の形態】
以下、図面を参照して本発明にかかる負荷分散システムの一実施の形態について詳細に説明する。
【００６５】
図１は、本発明にかかる一実施の形態の概略構成を示すブロック図である。この図において、クライアント１００、クライアント側ＤＮＳサーバ１１０、クライアント２００、クライアント側ＤＮＳサーバ２１０、サーバ側ＤＮＳサーバ群３００、一次負荷分散装置群４００、二次負荷分散装置５００、サーバ５１０、サーバ５２０、二次負荷分散装置６００、サーバ６１０およびサーバ６２０は、それぞれ図示しないルータを含むネットワーク（たとえば、インターネット）に接続されており、それぞれがアクセス可能な状態とされている。
【００６６】
また、同図に示したネットワークシステムは、大きく分けて、クライアント側の領域であるＤＮＳゾーンＺ1 およびＤＮＳゾーンＺ2 、サービスを提供するサービスサイトＳＳ1 およびサービスサイトＳＳ2 、ならびに負荷分散を行う負荷分散サイトＬＢＳ（Load Balancing Site）に分類される。
【００６７】
ＤＮＳゾーンＺ1 において、クライアント１００は、クライアント（ユーザ）側に設置されており、前述したＩＰパケットをルータ（図示略）へ送出することにより、後述するサーバ５１０、サーバ５２０、サーバ６１０またはサーバ６２０からサービスの提供を受けるコンピュータ端末である。また、クライアント１００は、サーバへアクセスする前に、クライアント側ＤＮＳサーバ１１０に対して、サーバ５１０、サーバ５２０、サーバ６１０およびサーバ６２０の代表ドメイン名を通知して、アクセス先のＩＰアドレスを獲得するというＤＮＳ問合せを行う。
【００６８】
クライアント側ＤＮＳサーバ１１０は、前述したＤＮＳを実現するためのサーバであり、クライアント１００に接続されている。このクライアント側ＤＮＳサーバ１１０は、クライアント１００よりＤＮＳ問合せがあった場合に、その上位に位置するサーバ側ＤＮＳサーバ群３００（一次負荷分散装置群４００）に対して、ＤＮＳ問合せを行い、一次負荷分散装置群４００から通知される、クライアント１００のアクセス先である二次負荷分散装置５００または二次負荷分散装置６００のＩＰアドレス（ＤＮＳ回答）を受け取り、これをクライアント１００へ通知する。
【００６９】
ＤＮＳゾーンＺ2 において、クライアント２００は、クライアント１００と同様にしてクライアント（ユーザ）側に設置されており、前述したＩＰパケットをルータ（図示略）へ送出することにより、後述するサーバ５１０、サーバ５２０、サーバ６１０またはサーバ６２０からサービスの提供を受けるコンピュータ端末である。また、クライアント２００は、サーバへアクセスする前に、クライアント側ＤＮＳサーバ２１０に対して、サーバ５１０、サーバ５２０、サーバ６１０およびサーバ６２０の代表ドメイン名を通知して、アクセス先である二次負荷分散装置５００または二次負荷分散装置６００のＩＰアドレスを獲得するというＤＮＳ問合せを行う。
【００７０】
クライアント側ＤＮＳサーバ２１０は、前述したＤＮＳを実現するためのサーバであり、クライアント２００に接続されている。このクライアント側ＤＮＳサーバ２１０は、クライアント２００よりＤＮＳ問合せがあった場合に、その上位に位置するサーバ側ＤＮＳサーバ群３００（一次負荷分散装置群４００）に対して、ＤＮＳ問合せを行い、一次負荷分散装置群４００から通知される、クライアント２００のアクセス先である二次負荷分散装置５００または二次負荷分散装置６００のＩＰアドレス（ＤＮＳ回答）を受け取り、これをクライアント２００へ通知する。
【００７１】
サーバ側ＤＮＳサーバ群３００は、クライアント側ＤＮＳサーバ１１０およびクライアント側ＤＮＳサーバ２１０の上位装置であり、前述したＤＮＳを実現するためのものである。ただし、このサーバ側ＤＮＳサーバ群３００における負荷分散機能は、後述する一次負荷分散装置群４００が担っている。また、サーバ側ＤＮＳサーバ群３００は、サーバ側ＤＮＳサーバ（プライマリ）３１０およびサーバ側ＤＮＳサーバ（セカンダリ）３２０から構成されており、冗長構成が採られている。
【００７２】
一次負荷分散装置群４００は、クライアント側ＤＮＳサーバ１１０またはクライアント側ＤＮＳサーバ２１０からのＤＮＳ問合せに対して、後述する振分テーブル等に基づいて、二次負荷分散装置５００または二次負荷分散装置６００のうちいずれかのＩＰアドレスをＤＮＳ回答とする。すなわち、一次負荷分散装置群４００は、クライアント１００またはクライアント２００からのアクセス要求を二次負荷分散装置５００宛または二次負荷分散装置６００宛という具合に大まかに一次振り分けすることにより、一次負荷分散を行う装置である。
【００７３】
また、一次負荷分散装置群４００は、一次負荷分散装置（プライマリ）４１０、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０から構成されており、冗長構成が採られている。これらの一次負荷分散装置（プライマリ）４１０、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０のそれぞれは、負荷分散を行う点で共通の機能を備えている。
【００７４】
一次負荷分散装置（プライマリ）４１０は、負荷分散機能の他に、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０を制御する機能を備えている。一次負荷分散装置（セカンダリ）４２０は、一次負荷分散装置（プライマリ）４１０の機能が停止した場合に、一次負荷分散装置（プライマリ）４１０に代わってプライマリとして機能する装置である。なお、一次負荷分散装置群４００においては、プライマリ以外の装置は、すべてバックアップとしての装置である。したがって、一次負荷分散装置（セカンダリ）４２０は、バックアップとしての装置であるとともに、セカンダリとしての装置でもある。
【００７５】
サービスサイトＳＳ1 において、二次負荷分散装置５００は、サーバ５１０、サーバ５２０の近傍に配置されている。この二次負荷分散装置５００は、一次負荷分散装置群４００により一次振り分けされたＩＰパケット（サービス要求）を、サーバ５１０、サーバ５２０の運転状態に応じて、最良の運転状態のサーバへ二次振り分けを行うことにより、二次負荷分散を行う装置である。この二次振り分けには、前述したＮＡＴによりＩＰヘッダの宛先アドレスを、振り分け先のサーバのＩＰアドレスに変換する方法や、上記宛先アドレスを振り分け先のサーバのＭＡＣアドレスに付け替える等の方法が採られる。
【００７６】
また、二次負荷分散装置５００は、一次負荷分散装置群４００からの計測依頼をトリガとして、たとえば、クライアント側ＤＮＳサーバ１１０（サーバ５１０、サーバ５２０）との間の通信経路における経路負荷を測定する機能を備えている。サーバ５１０は、サービス提供者側に設置されており、たとえば、クライアント１００からのアクセスに基づくサービス要求に応じて、クライアント１００に対してサービスの提供を行うためのコンピュータ端末である。同様にして、サーバ５２０は、サービス提供者側に設置されており、たとえば、クライアント１００からのサービス要求に応じて、クライアント１００に対してサービスの提供を行うためのコンピュータ端末である。
【００７７】
サービスサイトＳＳ2 において、二次負荷分散装置６００は、サーバ６１０、サーバ６２０の近傍に配置されている。この二次負荷分散装置６００は、二次負荷分散装置５００と同様にして、一次負荷分散装置群４００により一次振り分けされたＩＰパケット（サービス要求）を、サーバ６１０、サーバ６２０の運転状態に応じて、最良の運転状態のサーバへ二次振り分けを行うことにより、二次負荷分散を行う装置である。この二次振り分けには、前述したＮＡＴによりＩＰヘッダの宛先アドレスを、振り分け先のサーバのＩＰアドレスに変換する方法や、上記宛先アドレスを振り分け先のサーバのＭＡＣアドレスに付け替える等の方法が採られる。
【００７８】
また、二次負荷分散装置６００は、二次負荷分散装置５００と同様にして、一次負荷分散装置群４００からの計測依頼をトリガとして、たとえば、クライアント側ＤＮＳサーバ２１０（サーバ６１０、サーバ６２０）との間の通信経路における経路負荷を測定する機能を備えている。サーバ６１０は、サービス提供者側に設置されており、たとえば、クライアント２００からのアクセスに基づくサービス要求に応じて、クライアント２００に対してサービスの提供を行うためのコンピュータ端末である。同様にして、サーバ６２０は、たとえば、クライアント２００からのサービス要求に応じて、クライアント２００に対してサービスの提供を行うためのコンピュータ端末である。
【００７９】
ここで、サーバ５１０、サーバ５２０、サーバ６１０およびサーバ６２０は、クライアント１００（クライアント２００）からみればあたかも１台の仮想サーバとして機能している。したがって、これらのサーバ５１０、サーバ５２０、サーバ６１０およびサーバ６２０には、代表として一つの代表ドメイン名が付与されている。ただし、サーバ５１０、サーバ５２０、サーバ６１０およびサーバ６２０それぞれには、固有のＩＰアドレスが付与されている。また、サービスサイトＳＳ1 における二次負荷分散装置５００には、サーバ５１０およびサーバ５２０を仮想サーバとするＩＰアドレスが付与されている。同様にして、サービスサイトＳＳ2 における二次負荷分散装置６００には、サーバ６１０およびサーバ６２０を仮想サーバとするＩＰアドレスが付与されている。
【００８０】
つぎに、図２を参照して一実施の形態の具体的構成について説明する。この図において、図１の各部にそれぞれ対応する部分には同一の符号を付ける。ただし、図２においては、説明を簡略化するために、図１に示したクライアント２００およびクライアント側ＤＮＳサーバ２１０が省略されている。
【００８１】
また、図２には、相互接続されたＬＡＮ／ＷＡＮ７００、ＬＡＮ／ＷＡＮ８００、ＬＡＮ／ＷＡＮ９００およびＬＡＮ／ＷＡＮ１０００が図示されている。ＬＡＮ／ＷＡＮ７００には、クライアント１００およびクライアント側ＤＮＳサーバ１１０が接続されている。ＬＡＮ／ＷＡＮ８００には、サーバ側ＤＮＳサーバ（プライマリ）３１０および一次負荷分散装置（プライマリ）４１０が接続されている。
【００８２】
また、ＬＡＮ／ＷＡＮ９００には、サーバ側ＤＮＳサーバ（セカンダリ）３２０、一次負荷分散装置（バックアップ）４３０、二次負荷分散装置５００、サーバ５１０およびサーバ５２０が接続されている。ＬＡＮ／ＷＡＮ１０００には、一次負荷分散装置（セカンダリ）４２０、二次負荷分散装置６００、サーバ６１０およびサーバ６２０が接続されている。
【００８３】
このように、クライアント１００、・・・、サーバ６２０のそれぞれは、地域災害発生による集中的な被災を避けるべく、地理的に分散配置されている。特に、一次負荷分散装置群４００（図１参照）を構成する一次負荷分散装置（プライマリ）４１０、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０は、システムの中枢を担う装置である。したがって、一次負荷分散装置（プライマリ）４１０等を地理的に分散配置させる意義は大きい。同様にして、サーバ側ＤＮＳサーバ（プライマリ）３１０およびサーバ側ＤＮＳサーバ（セカンダリ）３２０についても、地理的に分散配置する意義が大きい。
【００８４】
つぎに、図３を参照して、図２に示した一次負荷分散装置４１０（プライマリ）の構成について説明する。この図において、図２の各部に対応する部分には同一の符号を付ける。一次負荷分散装置（プライマリ）４１０は、装置各部を制御する制御部４１１、記憶部４１２、外部装置（クライアント側ＤＮＳサーバ１１０等）との間で通信を行う通信部４１３および通信部４１４から構成されている。
【００８５】
制御部４１１は、ＤＮＳ応答スレッドＳ1 、ＤＮＳ振分テーブル配布スレッドＳ2 、・・・、経路負荷計測結果集計スレッドＳ9 を発生させるとともに、これらのスレッドの実行に伴う制御を行う。この制御部４１１の動作の詳細については、後述する。記憶部４１２は、ＤＮＳ振分テーブルＴ1 、サイト運転状態テーブルＴ2 、・・・、サイト連携振分テーブルＴ7 およびＤＮＳアクセスログＬを記憶する。
【００８６】
上記ＤＮＳ振分テーブルＴ1 は、クライアント側ＤＮＳサーバ１１０からのＤＮＳ問合せに応じて、前述した一次振り分けを行う場合に用いられるテーブルであり、制御部４１１により、サイト負荷状態テーブルＴ4 、経路負荷計測テーブルＴ5 およびポリシー情報テーブルＴ6 等に基づいて作成される。すなわち、図４に示したように、ＤＮＳ振分テーブルＴ1 は、メインテーブルＴa 、振分先一貫性保持テーブルＴb およびＬＤ情報テーブルＴc から構成されている。
【００８７】
メインテーブルＴa は、代表ドメイン名を示す［ドメイン名］、振分先一貫性保持テーブルＴb へのポインタを示す［テーブルポインタ（１）］、振分先一貫性保持テーブルＴb の数を示す［テーブル数（１）］、ＬＤ情報テーブルＴc へのポインタを示す［テーブルポインタ（２）］、ＬＤ（Local Dispatcher）情報テーブルＴc の数を示す［テーブル数（２）］から構成されている。
【００８８】
振分先一貫性保持テーブルＴb は、ＤＮＳ問合せ元のクライアント側ＤＮＳサーバへの一次振分先のＩＰアドレスを一定時間保持するためのテーブルである。この振分先一貫性保持テーブルＴb は、ＤＮＳ問合せ元のクライアント側ＤＮＳサーバのＩＰアドレスを示す［クライアント側ＤＮＳサーバアドレス］、当該ＤＮＳ問合せに対応する二次負荷分散装置５００または二次負荷分散装置６００のＩＰアドレスを示す［回答アドレス］から構成されている。
【００８９】
ＬＤ情報テーブルＴc は、二次負荷分散装置５００または二次負荷分散装置６００における動作状態等に関する情報が格納されたテーブルである。すなわち、ＬＤ情報テーブルＴc において、［ＬＤアドレス］は、二次負荷分散装置５００のＩＰアドレス（二次負荷分散装置６００のＩＰアドレス）を示す。
【００９０】
［ＬＤ動作状態コード］は、二次負荷分散装置５００（二次負荷分散装置６００）の動作状態を示す動作状態コードを示す。この動作状態コードとしては、正常に動作していることを示す０ｘ０００１（＝正常動作中）、停止状態にあることを示す０ｘ０００２（＝停止）、高負荷状態にあることを示す０ｘ０００３（＝高負荷）、一次振り分け先として予約されていることを示す０ｘ０００４（＝予約）がある。
【００９１】
また、［優先コード］は、優先的に一次振り分けが行われるＤＮＳ問合せ元のクライアント側ＤＮＳサーバを識別するための優先コードを示しており、後述する経路負荷計測テーブルＴ5 における経路負荷計測結果に基づくものである。この優先コードとしては、単一のクライアント側ＤＮＳサーバを指定していることを示す０ｘ０００１（単一ＩＰアドレス指定）、複数のクライアント側ＤＮＳサーバを範囲指定していることを示す０ｘ０００２、クライアント側ＤＮＳサーバのＩＰアドレスに加えてサブネットを指定していることを示す０ｘ０００３がある。
【００９２】
ここで、［優先コード］として０ｘ０００１（＝単一ＩＰアドレス指定）が格納されている場合には、［クライアント側ＤＮＳアドレス（１）］に当該クライアント側ＤＮＳサーバのＩＰアドレスが格納される。また、［優先コード］として、０ｘ０００２（＝範囲指定）が格納されている場合には、［クライアント側ＤＮＳアドレス（１）］に複数のクライアント側ＤＮＳサーバにおける若番のＩＰアドレスが格納されるとともに、［クライアント側ＤＮＳアドレス（２）］に複数のクライアント側ＤＮＳサーバにおける老番のＩＰアドレスが格納される。
【００９３】
また、［優先コード］として、０ｘ０００３（＝ＩＰアドレス＋サブネット指定）が格納されている場合には、［クライアント側ＤＮＳアドレス（１）］に当該クライアント側ＤＮＳサーバのＩＰアドレスが格納されるとともに、［クライアント側ＤＮＳアドレス（２）］にサブネットが格納される。
【００９４】
図５に示したサイト運転状態テーブルＴ2 は、二次負荷分散装置５００、二次負荷分散装置６００の運転状態（停止または運転中）を示すテーブルである。すなわち、サイト運転状態テーブルＴ2 は、二次負荷分散装置５００（二次負荷分散装置６００）のＩＰアドレスを示す［ＬＤアドレス］、二次負荷分散装置５００（二次負荷分散装置６００）の運転状態を示す［運転状態フラグ］（０：停止、１５：運転中）から構成されている。
【００９５】
また、サイト運転状態テーブルＴ2 は、一次負荷分散装置（プライマリ）４１０の起動時に作成され、一次負荷分散装置（プライマリ）４１０から二次負荷分散装置５００（二次負荷分散装置６００）に対して一定時間間隔で行われる運転監視（ＬＤ運転監視スレッドＳ5 ：図３参照）に基づいて更新される。
【００９６】
図６に示したＬＢＣ（Load Balancing Controller）運転状態テーブルＴ3 は、一次負荷分散装置（セカンダリ）４２０（一次負荷分散装置（バックアップ）４３０）の運転状態（停止または運転中）を示すテーブルである。すなわち、ＬＢＣ運転状態テーブルＴ3 は、一次負荷分散装置（セカンダリ）４２０（一次負荷分散装置（バックアップ）４３０）のＩＰアドレスを示す［ＬＢＣアドレス］、一次負荷分散装置（セカンダリ）４２０（一次負荷分散装置（バックアップ）４３０）の運転状態を示す［運転状態フラグ］（０：停止、１５：運転中）、一次負荷分散装置群４００におけるセカンダリを示す［セカンダリフラグ］から構成されている。
【００９７】
また、ＬＢＣ運転状態テーブルＴ3 は、一次負荷分散装置（プライマリ）４１０の起動時に作成され、一次負荷分散装置（プライマリ）４１０から一次負荷分散装置（セカンダリ）４２０（一次負荷分散装置（バックアップ）４３０）に対して一定時間間隔で行われる運転監視（ＬＢＣ運転監視スレッドＳ6 ：図３参照）の結果に基づいて更新される。
【００９８】
図７に示したサイト負荷状態テーブルＴ4 は、サイト（サービスサイトＳＳ1 、サービスサイトＳＳ2 ：図１参照）毎の負荷状態を示すテーブルである。すなわち、サイト負荷状態テーブルＴ4 には、二次負荷分散装置５００（二次負荷分散装置６００）のＩＰアドレスを示す［ＬＤアドレス］、［ＶＩＰ］、当該サイトが広域振り分け（広域負荷分散）対象であるか否かを示す［広域振分フラグ］（対象：ＯＦＦ、対象外：ＯＮ）が含まれている。
【００９９】
また、サイト負荷状態テーブルＴ4 において、［サイト連携フラグ］（対象：ＯＦＦ、対象外：ＯＮ）は、複数のサイトが連携して、あるサイトで処理しきれないサービス要求（ＩＰパケット）を別のサイトに転送するというサイト連携の対象であるか否かを示すフラグである。［負荷状態フラグ］（通常負荷：ＯＦＦ、高負荷：ＯＮ）は、当該サイトの負荷状態（通常負荷または高負荷）を示すフラグである。
【０１００】
［サイト連携受入フラグ］（受入：ＯＮ、拒否：ＯＦＦ）は、当該サイトが他のサイトからサイト連携を受け入れているか否かを示すフラグである。［サイト連携受入実行フラグ］（実行：ＯＮ、未実行：ＯＦＦ）は、当該サイトが他のサイトへのサイト連携を実行しているか否かを示すフラグである。また、サイト負荷状態テーブルＴ4 は、一次負荷分散装置（プライマリ）４１０の起動時に作成され、後述する広域負荷分散管理スレッドＳ4 （図３参照）が実行され、サイト負荷情報が受信された場合に更新される。
【０１０１】
図８に示した経路負荷計測テーブルＴ5 は、二次負荷分散装置５００（二次負荷分散装置６００）により実行される経路負荷計測の方法、結果等の情報からなるテーブルである。すなわち、経路負荷計測テーブルＴ5 は、線路負荷計測の対象となる二次負荷分散装置５００（二次負荷分散装置６００）、クライアント側ＤＮＳサーバ１１０のＩＰアドレスを示す［対象アドレス］、経路負荷計測の方法を示す［計測方法］、経路負荷計測の結果を示す［計測結果］、経路負荷計測の計測日時を示す［計測日時］からなる。この経路負荷計測テーブルＴ5 は、後述する経路負荷計測結果集計スレッドＳ9 が実行された場合に更新される。この経路負荷計測テーブルＴ5 における経路負荷計測結果は、ＤＮＳ振分テーブルＴ1 に反映される。
【０１０２】
図９に示したポリシー情報テーブルＴ6 は、ネットワークシステムに用いられるドメイン名の一覧を示す［ドメイン名一覧］、設定されたＤＮＳの数を示す［設定ＤＮＳ数］、二次負荷分散装置５００（二次負荷分散装置６００）のＩＰアドレスを示す［ＬＤアドレス］、二次負荷分散装置５００、二次負荷分散装置６００の数を示す［ＬＤ数］、一次負荷分散装置群４００における一次振り分けの優先順位を示す［振分優先情報］からなる。
【０１０３】
図１０に示したＤＮＳアクセスログＬは、クライアント側ＤＮＳサーバ１１０からＤＮＳ問合せがある毎に記録されるものであり、アクセス累計、アクセス数等からなる。すなわち、ＤＮＳアクセスログＬは、問合せ元のクライアント１００のＤＮＳ名を示す［ＤＮＳ名］、アクセスの累計を示す［アクセス累計］、クライアント側ＤＮＳサーバ１１０のＩＰアドレスを示す［アクセスクライアントＤＮＳアドレス］、アクセス時間を示す［アクセス時間］、アクセス数を示す［アクセス数］から構成されている。
【０１０４】
図３に戻り、サイト連携振分テーブルＴ7 は、前述したアクセス連携において振分元のサイトと、振分先のサイトとの関係を示すテーブルである。また、一次負荷分散装置（プライマリ）４１０において、ＤＮＳ応答スレッドＳ1 は、クライアント側ＤＮＳサーバ１１０からのＤＮＳ問合せに対するＤＮＳ応答に関する処理を行うためのスレッドである。
【０１０５】
ＤＮＳ振分テーブル配布スレッドＳ2 は、ＤＮＳ振分テーブルＴ1 を一次負荷分散装置（セカンダリ）４２０、一次負荷分散装置（バックアップ）４３０へ配布するためのスレッドであり、ＤＮＳ振分テーブルＴ1 の作成時および更新時に実行される。したがって、ＤＮＳ振分テーブル配布スレッドＳ2 が一定時間間隔毎に実行されることにより、一次負荷分散装置（プライマリ）４１０、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０におけるＤＮＳ振分テーブルＴ1 およびＤＮＳ振分テーブルＴ１’（図１１参照）は、内容的に同期がとられる。
【０１０６】
ＤＮＳアクセスログ同期スレッドＳ3 は、一次負荷分散装置（プライマリ）４１０におけるＤＮＳアクセスログＬと、一次負荷分散装置（セカンダリ）４２０（一次負荷分散装置（バックアップ）４３０）におけるＤＮＳアクセスログＬ’（図１１参照）との同期をとる処理を行うためのスレッドである。広域負荷分散管理スレッドＳ4 は、広域負荷分散に関する管理（サイト運転状態テーブルＴ2 、サイト連携テーブルＴ7 の更新等）を行うためのスレッドである。
【０１０７】
ＬＤ運転監視スレッドＳ5 は、二次負荷分散装置５００（二次負荷分散装置６００）の運転監視を行うためのスレッドである。ＬＢＣ運転監視スレッドＳ6 は、一次負荷分散装置（セカンダリ）４２０（一次負荷分散装置（バックアップ）４３０）の運転監視を行うためのスレッドである。サイト連携振分テーブル配布スレッドＳ7 は、サイト連携振分テーブルＴ7 を二次負荷分散装置５００（二次負荷分散装置６００）へ配布するためのスレッドである。
【０１０８】
経路負荷計測依頼スレッドＳ8 は、二次負荷分散装置５００（二次負荷分散装置６００）に対して経路負荷計測を依頼するためのスレッドである。経路負荷計測結果集計スレッドＳ9 は、上記経路負荷計測の終了後、二次負荷分散装置５００（二次負荷分散装置６００）からの経路負荷計測結果を集計するためのスレッドである。
【０１０９】
つぎに、図１１を参照して、図２に示した一次負荷分散装置（セカンダリ）４２０の構成について説明する。この図において、図２の各部に対応する部分には同一の符号を付ける。一次負荷分散装置（セカンダリ）４２０は、装置各部を制御する制御部４２１、記憶部４２２、外部装置（クライアント側ＤＮＳサーバ１１０、一次負荷分散装置（プライマリ）４１０）との間で通信を行う通信部４２３から構成されている。
【０１１０】
記憶部４２２には、ＤＮＳ振分テーブルＴ1’、ＬＢＣ運転状態テーブルＴ3’、ポリシー情報テーブルＴ6’およびＤＮＳアクセスログＬ’が記憶されている。これらのＤＮＳ振分テーブルＴ1’、ＬＢＣ運転状態テーブルＴ3’、ポリシー情報テーブルＴ6’およびＤＮＳアクセスログＬ’は、図３に示したＤＮＳ振分テーブルＴ1 、ＬＢＣ運転状態テーブルＴ3 、ポリシー情報テーブルＴ6 およびＤＮＳアクセスログＬに対応している。
【０１１１】
また、一次負荷分散装置（セカンダリ）４２０において、ＤＮＳ応答スレッドＳ10は、クライアント側ＤＮＳサーバ１１０からのＤＮＳ問合せに対するＤＮＳ応答に関する処理を行うためのスレッドである。ＤＮＳ振分テーブル配布スレッドＳ11は、一次負荷分散装置（プライマリ）４１０からのＤＮＳ振分テーブルＴ1 の配布を受けるためのスレッドである。
【０１１２】
ＤＮＳアクセスログ同期スレッドＳ12は、一次負荷分散装置（セカンダリ）４２０におけるＤＮＳアクセスログＬ’と、一次負荷分散装置（プライマリ）４１０におけるＤＮＳアクセスログＬとの同期をとる処理を行うためのスレッドである。広域負荷分散管理スレッドＳ13は、一次負荷分散装置（プライマリ）４１０の制御により、広域負荷分散に関する管理を行うためのスレッドである。ＬＢＣ運転監視スレッドＳ14は、一次負荷分散装置（プライマリ）４１０の運転監視を行うためのスレッドである。
【０１１３】
なお、一次負荷分散装置（バックアップ）４３０の基本的な構成およびスレッドは、上述した一次負荷分散装置（セカンダリ）４２０と同様である。すなわち、一次負荷分散装置（バックアップ）４３０は、制御部４３１、記憶部４３２および通信部４３３を備えている。
【０１１４】
（運転監視動作）
つぎに、図１２を参照して一実施の形態における運転監視動作について説明する。同図において、一次負荷分散装置（プライマリ）４１０が起動されると、ＬＤ運転監視スレッドＳ5 およびＬＢＣ運転監視スレッドＳ6 （図３参照）が実行される。これにより、一次負荷分散装置（プライマリ）４１０は、二次負荷分散装置５００、二次負荷分散装置６００、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０へ運転監視メッセージ（ステップＳＥ１〜ステップＳＥ４）をそれぞれ一定時間間隔で送信する。
【０１１５】
そして、二次負荷分散装置５００および二次負荷分散装置６００により上記運転監視メッセージが受信されると、二次負荷分散装置５００および二次負荷分散装置６００は、送信元の一次負荷分散装置（プライマリ）４１０へ運転応答メッセージをそれぞれ送信する。
【０１１６】
また、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０により運転監視メッセージが受信されると、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０は、ＬＢＣ運転監視スレッドＳ14（図１１参照）を実行することにより、運転監視応答メッセージを送信元の一次負荷分散装置（プライマリ）４１０へ送信する。
【０１１７】
そして、一次負荷分散装置（プライマリ）４１０は、運転監視メッセージを送信してから一定時間待機し、この間に運転応答メッセージが受信された場合、送信先の装置が正常に運転しているものと判断する。一方、一定時間内に運転応答メッセージが受信されない場合には、当該装置に対して運転監視メッセージを再送する。以後、再送動作を一定回数（デフォルト３回）繰り返し、それでもなお、当該装置からの運転監視メッセージが受信されない場合、一次負荷分散装置（プライマリ）４１０は、当該装置の運転が停止しているものと判断する。この運転停止の要因の一つとしては、前述した災害の発生が挙げられる。
【０１１８】
ここで、二次負荷分散装置５００（または二次負荷分散装置６００）が運転停止（被災）しているものと判断した場合、一次負荷分散装置（プライマリ）４１０は、図５に示したサイト運転状態テーブルＴ2 における［運転状態フラグ］を０（＝運転停止）とする。
【０１１９】
さらに、一次負荷分散装置（プライマリ）４１０は、図４に示したＤＮＳ振分テーブルＴ1 のＬＤ情報テーブルＴc における［ＬＤ動作状態コード］を０ｘ０００２（＝停止）とするとともに、図３に示したサイト連携振分テーブルＴ7 における二次負荷分散装置５００（または二次負荷分散装置６００）の運転状態を停止とする。これにより、二次負荷分散装置５００（または二次負荷分散装置６００）は、一次振り分け対象から除外される。
【０１２０】
また、一次負荷分散装置（プライマリ）４１０は、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０へ、二次負荷分散装置５００（または二次負荷分散装置６００）が運転停止した旨を通知する。これにより、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０のそれぞれは、ＤＮＳ振分テーブルＴ1’（図１１参照）を更新し、二次負荷分散装置５００（または二次負荷分散装置６００）を一次振り分け対象から除外する。
【０１２１】
また、一次負荷分散装置（バックアップ）４３０（または一次負荷分散装置（セカンダリ）４２０）が運転停止（被災）しているものと判断した場合、一次負荷分散装置（プライマリ）４１０は、図６に示したＬＢＣ運転状態テーブルＴ3 における［運転状態フラグ］を０（＝運転停止）とする。
【０１２２】
以後、一次負荷分散装置（プライマリ）４１０は、運転停止していると判断された装置（たとえば、二次負荷分散装置５００、一次負荷分散装置（セカンダリ）４２０等）に対して、運転監視メッセージを一定時間間隔をおいて送信する。ただし、この場合、運転監視メッセージの再送は行われない。そして、運転停止していると判断された当該装置から運転監視応答メッセージを受信すると、一次負荷分散装置（プライマリ）４１０は、当該装置に対してプライマリアナウンスを送信する。そして、このプライマリアナウンスを受信すると、当該装置は、プライマリ了承メッセージを一次負荷分散装置（プライマリ）４１０へ送信する。
【０１２３】
このプライマリ了承メッセージが一次負荷分散装置（プライマリ）４１０に受信されると、一次負荷分散装置（プライマリ）４１０は、当該装置に関するＤＮＳ振分テーブルＴ1 、サイト運転状態テーブルＴ2 （またはＬＢＣ運転状態テーブルＴ3 ）を運転中の状態に更新する。なお、一次負荷分散装置（セカンダリ）４２０が運転停止（被災）している場合、一次負荷分散装置（プライマリ）４１０は、ＬＢＣ運転状態テーブルＴ3 （図６参照）の［セカンダリフラグ］に一次負荷分散装置（バックアップ）４３０を設定することで、一次負荷分散装置（セカンダリ）４２０に代えて一次負荷分散装置（バックアップ）４３０をセカンダリとする。
【０１２４】
また、一次負荷分散装置（プライマリ）４１０または一次負荷分散装置（プライマリ）４１０のリンクが被災することにより、一次負荷分散装置（プライマリ）４１０からの運転監視メッセージが所定時間（＝前回の運転監視時間＋運転監視時間＋待機時間）が経過しても一次負荷分散装置（セカンダリ）４２０に受信されない場合、一次負荷分散装置（セカンダリ）４２０は、つぎの動作を行う。ここで、上記待機時間は、一次負荷分散装置（セカンダリ）４２０がセカンダリからプライマリに自動的に昇格するのに要する時間である。
【０１２５】
この場合、一次負荷分散装置（セカンダリ）４２０は、一次負荷分散装置（プライマリ）４１０が消失したものと判断し、一次負荷分散装置（バックアップ）４３０、二次負荷分散装置５００および二次負荷分散装置６００へ、プライマリアナウンスを送信する。
【０１２６】
そして、一次負荷分散装置（バックアップ）４３０、二次負荷分散装置５００および二次負荷分散装置６００は、上記プライマリアナウンスを受信すると、プライマリ了承メッセージを一次負荷分散装置（セカンダリ）４２０へ送信する。このプライマリ了承メッセージを受信すると、一次負荷分散装置（セカンダリ）４２０は、一次負荷分散装置（プライマリ）４１０に代わって、プライマリとして機能する。以後、一次負荷分散装置（セカンダリ）４２０は、一次負荷分散装置（プライマリ）４１０と同様の動作を行う。
【０１２７】
なお、一次負荷分散装置（プライマリ）４１０と同時に一次負荷分散装置（セカンダリ）４２０も被災により運転停止した場合には、一次負荷分散装置（セカンダリ）４２０からは、プライマリアナウンスが送信されない。したがって、この場合、上述した所定時間を経過しても一次負荷分散装置（バックアップ）４３０には、上記プライマリアナウンスが受信されない。これにより、一次負荷分散装置（バックアップ）４３０は、プライマリ探索を行う。この場合には、上位の一次負荷分散装置または最初にプライマリ探索を行った一次負荷分散装置がプライマリとなる。
【０１２８】
そして、一次負荷分散装置（プライマリ）４１０が復旧し運転を再開すると、一次負荷分散装置（プライマリ）４１０は、一次負荷分散装置４２０、一次負荷分散装置（バックアップ）４３０、二次負荷分散装置５００および二次負荷分散装置６００へ自身が本来のプライマリであることを示すプライマリアナウンスを送信する。
【０１２９】
そして、現時点のプライマリである一次負荷分散装置４２０が上記プライマリアナウンスを受信すると、一次負荷分散装置４２０は、一次負荷分散装置（プライマリ）４１０が本来のプライマリであることを確認した後、負荷分散の管理下にある二次負荷分散装置５００、二次負荷分散装置６００および一次負荷分散装置（バックアップ）４３０に対して負荷分散を終了するための負荷分散終了メッセージを送信する。
【０１３０】
これにより、二次負荷分散装置５００、二次負荷分散装置６００および一次負荷分散装置（バックアップ）４３０は、一次負荷分散装置４２０をプライマリとする負荷分散の参加を取り消すための参加取り消しメッセージを送信する。
【０１３１】
つぎに、一次負荷分散装置４２０は、プライマリアナウンスの送信元（一次負荷分散装置（プライマリ）４１０）をプライマリとした負荷分散に参加を要請するための参加要請メッセージを、一次負荷分散装置（バックアップ）４３０、二次負荷分散装置５００および二次負荷分散装置６００へ送信する。そして、一次負荷分散装置（セカンダリ）４２０、一次負荷分散装置（バックアップ）４３０、二次負荷分散装置５００および二次負荷分散装置６００のそれぞれは、一次負荷分散装置（プライマリ）４１０をプライマリとする負荷分散に参加するための参加メッセージを一次負荷分散装置（プライマリ）４１０へ送信する。これにより、災害発生前の状態に自動復旧する。
【０１３２】
また、災害発生等により、一次負荷分散装置（プライマリ）４１０からの運転監視メッセージが所定時間（＝前回の運転監視時間＋運転監視時間＋待機時間）が経過しても一次負荷分散装置（バックアップ）４３０に受信されない場合、一次負荷分散装置（バックアップ）４３０は、つぎの動作を行う。すなわち、この場合、一次負荷分散装置（バックアップ）４３０は、一次負荷分散装置（プライマリ）４１０が消失したものと判断し、待機時間内に一次負荷分散装置（セカンダリ）４２０からのプライマリアナウンスを受信したか否かを判断する。
【０１３３】
この待機時間内にプライマリアナウンスを受信した場合、一次負荷分散装置（バックアップ）４３０は、上述したプライマリ了承メッセージを一次負荷分散装置（セカンダリ）４２０へ送信する。一方、待機時間内にプライマリアナウンスを受信しない場合、一次負荷分散装置（バックアップ）４３０は、プライマリとなる一次負荷分散装置を探索する。
【０１３４】
また、災害発生等により、一次負荷分散装置（プライマリ）４１０からの運転監視メッセージが所定時間（＝前回の運転監視時間＋運転監視時間＋待機時間）が経過しても二次負荷分散装置５００（二次負荷分散装置６００）に受信されない場合、二次負荷分散装置５００（二次負荷分散装置６００）は、つぎの動作を行う。すなわち、この場合、二次負荷分散装置５００（二次負荷分散装置６００）は、一次負荷分散装置（プライマリ）４１０が消失したものと判断し、待機時間内に一次負荷分散装置（セカンダリ）４２０からのプライマリアナウンスを受信したか否かを判断する。
【０１３５】
この待機時間内にプライマリアナウンスを受信した場合、二次負荷分散装置５００（二次負荷分散装置６００）は、上述したプライマリ了承メッセージを一次負荷分散装置（セカンダリ）４２０へ送信する。一方、待機時間内にプライマリアナウンスを受信しない場合、二次負荷分散装置５００（二次負荷分散装置６００）は、プライマリとなる一次負荷分散装置を探索する。
【０１３６】
（負荷情報収集動作）
つぎに、図１３を参照して一実施の形態における負荷情報収集動作について説明する。同図において、一次負荷分散装置（プライマリ）４１０が起動されると、広域負荷分散管理スレッドＳ4 （図３参照）が実行される。これにより、一次負荷分散装置（プライマリ）４１０は、二次負荷分散装置５００（二次負荷分散装置６００）へ負荷状態の計測を依頼する（ステップＳＦ１およびステップＳＦ２）。
【０１３７】
これにより、二次負荷分散装置５００は、サーバ５１０およびサーバ５２０の負荷状態（高負荷、通常負荷）をＩＰパケットの通過量や計測エージェントにより計測する。同様にして、二次負荷分散装置６００は、サーバ６１０およびサーバ６２０の負荷状態を計測する。そして、二次負荷分散装置５００および二次負荷分散装置６００は、負荷状態をサイト負荷情報として一次負荷分散装置（プライマリ）４１０へ送信する。このサイト負荷情報を受信すると、一次負荷分散装置（プライマリ）４１０は、サイト負荷状態テーブルＴ4（図７参照)を更新する。以後、一定時間間隔をおいて、負荷情報収集動作が実行される。
【０１３８】
（ＤＮＳアクセスログ収集動作）
つぎに、図１４を参照して一実施の形態におけるＤＮＳアクセスログ収集動作について説明する。同図において、ステップＳＧ１でクライアント側ＤＮＳサーバ１１０から一次負荷分散装置（セカンダリ）４２０に対してＤＮＳ問合せがあると、一次負荷分散装置（セカンダリ）４２０は、ＤＮＳアクセスログＬ’（図１１参照）を更新する。同様にして、ステップＳＧ３でクライアント側ＤＮＳサーバ１１０から一次負荷分散装置（バックアップ）４３０に対してＤＮＳ問合せがあると、一次負荷分散装置（バックアップ）４３０は、ＤＮＳアクセスログＬ’（図１１参照）を更新する。
【０１３９】
そして、ステップＳＧ２では、一次負荷分散装置（セカンダリ）４２０は、一定時間間隔毎にＤＮＳアクセスログ同期スレッドＳ12（図１１参照）を実行する。すなわち、一次負荷分散装置（セカンダリ）４２０は、ＤＮＳアクセスログＬ’を一次負荷分散装置（プライマリ）４１０へ送信する。同様にして、ステップＳＧ４では、一次負荷分散装置（バックアップ）４３０は、一定時間間隔毎にＤＮＳアクセスログ同期スレッドＳ12（図１１参照）を実行する。すなわち、一次負荷分散装置（バックアップ）４３０は、ＤＮＳアクセスログＬ’を一次負荷分散装置（プライマリ）４１０へ送信する。
【０１４０】
そして、上記ＤＮＳアクセスログＬ’を受信すると、一次負荷分散装置（プライマリ）４１０は、ＤＮＳアクセスログ同期スレッドＳ3 を実行し、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０からのＤＮＳアクセスログＬ’を集計し、集計結果をＤＮＳアクセスログＬ（図１０参照）に反映させる。
【０１４１】
（経路負荷情報収集動作）
つぎに、図１５を参照して一実施の形態における経路負荷情報収集動作について説明する。同図において、一次負荷分散装置（プライマリ）４１０は、経路負荷計測依頼スレッドＳ8 を実行する。すなわち、一次負荷分散装置（プライマリ）４１０は、ＤＮＳアクセスログＬを参照することで、最近アクセスがあり、かつ経路負荷計測が実施されていない、たとえば、クライアント側ＤＮＳサーバ１１０を選択する。
【０１４２】
つぎに、ステップＳＨ１では、一次負荷分散装置（プライマリ）４１０は、二次負荷分散装置５００に対して経路負荷計測を依頼する。これにより、ステップＳＨ２では、二次負荷分散装置５００は、クライアント側ＤＮＳサーバ１１０との間の通信経路におけるラウンドトリップタイム、最大セグメントサイズおよび平均輻輳ウインドウサイズ等に基づいて、上記通信経路における実効帯域幅を求める。
【０１４３】
具体的には、二次負荷分散装置５００は、ＳＹＮ（SYNchronous idle character）パケットをクライアント側ＤＮＳサーバ１１０に対して送信した後、クライアント側ＤＮＳサーバ１１０から送信される返信用のＡＣＫ（ACKnowledge character）パケットを受信する。これにより、二次負荷分散装置５００は、ＡＣＫパケットの受信時刻とＳＹＮパケットの送信時刻との差をラウンドトリップタイムとして求める。
【０１４４】
つぎに、二次負荷分散装置５００は、最大セグメントサイズ（単位：バイト）をつぎのようにして求める。ＴＣＰ通信では、通信経路上のルータの最大送信単位（ＭＴＵ）に基づいてパケットのサイズが決められている。ここで、中継用のルータが通信経路上に複数あるときは、最大通信単位の最小値がＴＣＰ通信の最大セグメントサイズとなる。したがって、二次負荷分散装置５００は、クライアント側ＤＮＳサーバ１１０との間の通信経路上にルータのＭＴＵを検出した後、最小値のＭＴＵを最大セグメントサイズとして求める。
【０１４５】
続いて、二次負荷分散装置５００は、平均輻輳ウインドウサイズ（単位：パケット）をつぎのようにして求める。ＴＣＰ通信では、パケットをスライディングウィンドウ方式により出力制限しながら送出している。すなわち、二次負荷分散装置５００は、ウインドウサイズという単位で一度に送出するパケット数を制限しながら、クライアント側ＤＮＳサーバ１１０に対してパケットを送出した後、クライアント側ＤＮＳサーバ１１０からの受信確認パケットによりウインドウサイズ分のパケットが転送されたことを確認する。
【０１４６】
また、二次負荷分散装置５００は、上記ウインドウサイズを送信または受信されたパケットのログ情報に基づいて、一つのウインドウサイクル内で送出されたパケットの数を調べることにより、上述したウィンドウサイズを得る。また、二次負荷分散装置５００は、クライアント側ＤＮＳサーバ１１０からの受信確認パケットが所定時間内に到着しない場合、通信経路（ネットワーク）が輻輳しているものと判断し、ウインドウサイズを調整する。このウインドウサイズの調整は、輻輳回避アルゴリズムによって行われる。
【０１４７】
すなわち、受信確認パケットが所定時間内に到着しない場合、言い換えれば、パケット廃棄が起こった場合、二次負荷分散装置５００は、ウインドウサイズを半分に減らし、その後に再び、パケット廃棄が起こるまで一つづつウインドウサイズを増やしていく。そして、パケット廃棄が再び発生すると、再びウインドウサイズを半分に減らして同じことを繰り返す。二次負荷分散装置５００は、上述した輻輳回避アルゴリズムが実行されている間のウインドウサイズの平均値を平均輻輳ウインドウサイズとして求める。
【０１４８】
つぎに、二次負荷分散装置５００は、上述したラウンドトリップタイム、最大セグメントサイズおよび平均輻輳ウインドウサイズに基づいて、クライアント側ＤＮＳサーバ１１０との間の通信経路における実効帯域幅（転送速度）を求める。具体的には、二次負荷分散装置５００は、実効帯域幅をＢＷ（バイト／秒）、ラウンドトリップタイムをＲＴＴ（ｍｓｅｃ）、最大セグメントサイズをＭＳＳ（バイト）および平均輻輳ウインドウサイズをＷ（パケット）としたつぎの（１）式に各値を代入することにより、実効帯域幅を求める。
ＢＷ＝Ｗ×ＭＳＳ／ＲＴＴ ・・・（１）
【０１４９】
同様にして、ステップＳＨ３では、一次負荷分散装置（プライマリ）４１０は、二次負荷分散装置６００に対して経路負荷計測を依頼する。これにより、ステップＳＨ４では、二次負荷分散装置６００は、二次負荷分散装置５００と同様にして、クライアント側ＤＮＳサーバ１１０との間の通信経路における実効帯域幅を求める。
【０１５０】
そして、二次負荷分散装置５００および二次負荷分散装置６００は、それぞれの実効帯域幅を経路負荷計測結果として一次負荷分散装置（プライマリ）４１０へ送信する。これにより、経路負荷計測結果集計スレッドＳ9 が実行され、一次負荷分散装置（プライマリ）４１０は、経路負荷計測結果を集計し、この集計結果に基づいて経路負荷計測テーブルＴ5 （図８参照）を更新する。
【０１５１】
（アクセス動作）
つぎに、図１６および図１７を参照して一実施の形態におけるアクセス動作について説明する。図１６において、ステップＳＩ１では、クライアント１００は、クライアント側ＤＮＳサーバ１１０に対して代表ドメイン名に基づくＤＮＳ問合せを行う。これにより、クライアント側ＤＮＳサーバ１１０は、自身のキャッシュメモリに回答すべき二次負荷分散装置５００または二次負荷分散装置６００のＩＰアドレスが保存されているか否かを判断し、保存されている場合、ステップＳＩ４で上記ＩＰアドレスをクライアント１００へ回答する。
【０１５２】
一方、キャッシュメモリに回答すべきＩＰアドレスが保存されていない場合、ステップＳＩ２では、クライアント側ＤＮＳサーバ１１０は、問い合わせがあったＤＮＳに関する権限を有するサーバ側ＤＮＳサーバ（プライマリ）３１０に対してＤＮＳ問合せを行う。これにより、サーバ側ＤＮＳサーバ（プライマリ）３１０は、登録されている一次負荷分散装置（プライマリ）４１０、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０のそれぞれのＩＰアドレスをクライアント側ＤＮＳサーバ１１０に返答する。
【０１５３】
ステップＳＩ３では、クライアント側ＤＮＳサーバ１１０は、受信した都合三つのＩＰアドレスのうち、たとえば、一次負荷分散装置（プライマリ）４１０のＩＰアドレスを用いて、一次負荷分散装置（プライマリ）４１０にアクセスする。すなわち、クライアント側ＤＮＳサーバ１１０は、一次負荷分散装置（プライマリ）４１０に対してＤＮＳ問合せを行う。
【０１５４】
これにより、一次負荷分散装置（プライマリ）４１０は、ＤＮＳ振分テーブルＴ1 を参照することで、全体の負荷が分散されるようなサイト、すなわち二次負荷分散装置のＩＰアドレスをクライアント側ＤＮＳサーバ１１０へ回答する。この場合、二次負荷分散装置６００のＩＰアドレスが回答されたものとする。そして、ステップＳＩ４では、クライアント側ＤＮＳサーバ１１０は、上記ＩＰアドレスをクライアント１００へ回答する。
【０１５５】
これにより、図１７に示したステップＳＪ１では、クライアント１００は、上記ＩＰアドレスに基づいて二次負荷分散装置６００にアクセスする。これにより、ステップＳＪ２では、二次負荷分散装置６００は、クライアント１００からのＩＰパケット（サービス要求）を、ＮＡＴ方式やＭＡＣ方式により、たとえば、サーバ６２０へ振り分ける。そして、ステップＳＪ３では、サーバ６２０は、サービスを提供するための返信パケットを二次負荷分散装置６００を介して、または直接クライアント１００へ送信する。これにより、サーバ６２０からクライアント１００へサービスが提供される。
【０１５６】
以上説明したように、一実施の形態によれば、プライマリの一次負荷分散装置４１０を設定し、この一次負荷分散装置（プライマリ）４１０により、他の一次負荷分散装置（セカンダリ）４２０、一次負荷分散装置（バックアップ）４３０、二次負荷分散装置５００および二次負荷分散装置６００の運転状態を監視し、運転停止した装置がある場合、当該装置を負荷分散を行う装置から除外するようにしたので、災害発生によるサービス停止を回避することができる。
【０１５７】
また、一実施の形態によれば、あらかじめセカンダリの一次負荷分散装置４２０を設定するようにしたので、一次負荷分散装置（プライマリ）４１０が運転停止した時点で即座に一次負荷分散装置（セカンダリ）４２０をプライマリとして機能させることができるため、プライマリが不在という致命的な事態を回避することができる。
【０１５８】
また、一実施の形態によれば、運転停止した一次負荷分散装置（プライマリ）４１０が運転を再開すると、現時点でのプライマリである一次負荷分散装置４２０が一次負荷分散装置（プライマリ）４１０に自動的に切り替わる。したがって、一実施の形態によれば、運転停止した一次負荷分散装置（プライマリ）４１０の運転状態を相互監視により監視するようにしたので、一次負荷分散装置（プライマリ）４１０が復旧した時点で即座に現時点でのプライマリとしての一次負荷分散装置（セカンダリ）４２０を本来の一次負荷分散装置（プライマリ）４１０に切り換えることができる。
【０１５９】
また、一実施の形態によれば、一次負荷分散装置（プライマリ）４１０、一次負荷分散装置（セカンダリ）４２０、一次負荷分散装置（バックアップ）４３０、二次負荷分散装置５００および二次負荷分散装置６００のそれぞれを広域にわたって地理的に分散配置するようにしたので、局部的に発生する災害（地震等）が発生した場合であっても、最小限の被災にとどめることができるため、災害発生によるサービス停止をさらに効果的に回避することができる。
【０１６０】
また、一実施の形態によれば、一次負荷分散装置（プライマリ）４１０により作成／更新されたＤＮＳ振分テーブルＴ1 をその他の一次負荷分散装置（セカンダリ）４２０、一次負荷分散装置（バックアップ）４３０へ配布するようにしたので、すべての一次負荷分散装置（プライマリ）４１０、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０で同一の基準で一次振り分けが行われるため、更新漏れによるトラブルを防止することができる。
【０１６１】
さらに、一実施の形態によれば、サーバ５１０、サーバ５２０、サーバ６１０およびサーバ６２０における実際の負荷を測定した結果が反映されたＤＮＳ振分テーブルＴ1 に基づいて、一次振り分けが行われるため、実際の負荷に応じた負荷分散を行うことができる。
【０１６２】
加えて、一実施の形態によれば、経路負荷が反映されたＤＮＳ振分テーブルＴ1 に基づいて、一次振り分けが行われるため、通信経路の状態に即した最適な負荷分散を行うことができる。
【０１６３】
【発明の効果】
以上説明したように、請求項１にかかる発明によれば、災害発生によるサービス停止を回避することができ、さらに、二次負荷分散手段間の協調によっても負荷分散を実現可能な２段階方式の負荷分散システムを得ることができるという効果を奏する。
【０１６４】
また、請求項２にかかる発明によれば、一次振り分けの結果は、ＤＮＳ問合せのキャッシュとして問合せ元に一定期間記憶され、キャッシュを保持している問合せ元では、このキャッシュに基づいて一次振り分けが行われることになるため、一次負荷分散手段の負荷が軽減されるという効果を奏する。
【０１６５】
また、請求項３にかかる発明によれば、サービス要求の送信元との間の経路負荷が最も少ないことが期待される二次負荷分散手段がサービス要求の振り分け先として選択されるので、ネットワークに負荷をかけることなく負荷分散を実現することができるという効果を奏する。
【図面の簡単な説明】
【図１】本発明にかかる負荷分散システムの一実施の形態の概略構成を示す図である。
【図２】同一実施の形態の構成を示す図である。
【図３】図２に示した一次負荷分散装置４１０（プライマリ）の構成を示すブロック図である。
【図４】図３に示したＤＮＳ振分テーブルＴ1 の一例を示す図である。
【図５】図３に示したサイト運転状態テーブルＴ2 の一例を示す図である。
【図６】図３に示したＬＢＣ運転状態テーブルＴ3 の一例を示す図である。
【図７】図３に示したサイト負荷状態テーブルＴ4 の一例を示す図である。
【図８】図３に示した経路負荷計測テーブルＴ5 の一例を示す図である。
【図９】図３に示したポリシー情報テーブルＴ6 の一例を示す図である。
【図１０】図３に示したＤＮＳアクセスログＬの一例を示す図である。
【図１１】図２に示した一次負荷分散装置４２０（セカンダリ）および一次負荷分散装置４３０（バックアップ）の構成を示すブロック図である。
【図１２】同一実施の形態における運転監視動作を説明する図である。
【図１３】同一実施の形態におけるサイト負荷情報収集動作を説明する図である。
【図１４】同一実施の形態におけるＤＮＳアクセスログ収集動作を説明する図である。
【図１５】同一実施の形態における経路負荷情報収集動作を説明する図である。
【図１６】同一実施の形態におけるアクセス動作を説明する図である。
【図１７】同一実施の形態におけるアクセス動作を説明する図である。
【図１８】従来のネットワークシステムの構成例１を示す図である。
【図１９】従来のネットワークシステムの構成例１における災害発生時の動作を説明する図である。
【図２０】従来のネットワークシステムの構成例２を示す図である。
【図２１】従来のネットワークシステムの構成例２における災害発生時の動作を説明する図である。
【符号の説明】
１００ クライアント
２００ クライアント
４００ 一次負荷分散装置群
４１０ 一次負荷分散装置
４２０ 一次負荷分散装置
４３０ 一次負荷分散装置
５００ 二次負荷分散装置
５１０ サーバ
５２０ サーバ
６００ 二次負荷分散装置
６１０ サーバ
６２０ サーバ
【発明の属する技術分野】
本発明は、クライアント／サーバシステムにおけるサーバの負荷を分散させる負荷分散装置に関するものであり、特に、災害発生時のサービス停止回避機能を備える負荷分散システムに関するものである。
【０００２】
近時、インターネットに代表される大規模ネットワークにおいては、１台のサーバに対する負荷集中を解決すべく、多数のアクセスを受けるサーバ側にサーバを複数台用意して、クライアントに対して、上記複数のサーバがあたかも１台のサーバとして機能しているように構成する負荷分散技術が用いられている。
【０００３】
この負荷分散技術は、クライアントからのアクセスを複数のサーバに分散させることにより、１台のサーバの負荷を低減させるための技術である。したがって、負荷分散技術においては、クライアントよりアクセスがあった場合、複数のサーバのうち、できるだけ低負荷であってかつ当該クライアントとの間の距離が短い１台のサーバに当該アクセスを振り分けることがネットワーク効率を高める上で重要である。
【０００４】
【従来の技術】
図１８は、従来のネットワークシステムの構成例１を示す図である。この図に示したネットワークシステムには、ＤＮＳ（Domain Name System）サーバにおける負荷分散の方式として、ラウンド・ロビン方式が採用されている。このラウンド・ロビン方式は、後述するドメイン名を用いてアクセスを受け付け、そのドメイン名をＩＰ（Internet Protocol）アドレスに変換する際に、複数のサーバのＩＰアドレスを順番に用いることにより、負荷分散を行う方式である。
【０００５】
同図において、ＬＡＮ（Local Area Network）／ＷＡＮ（Wide Area Network）１およびＬＡＮ／ＷＡＮ４は、インターネットワーキング（相互接続）によって、物理的に離隔配置されている複数のコンピュータ間でデータ通信を行うための大規模ネットワークであり、たとえば、インターネットである。
【０００６】
ここで、上記インターネットとしては、つぎの条件を満たすネットワークが該当する。
（１）コンピュータネットワークが、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）と呼ばれる通信プロトコル（通信接続手順）を実装していること。
（２）コンピュータネットワークが、いくつかの基幹ネットワークを中心として構成された一つの世界規模のネットワークに接続されていること。
【０００７】
また、上記ＴＣＰ／ＩＰとしては、ＯＳＩ（Open Systems Interconnection：開放形システム間相互接続）参照モデルの第４層（トランスポート層）にあるＴＣＰおよびＵＤＰ（User Datagram Protocol）の各プロトコルが定義されている。上記ＴＣＰの特徴は、信頼性のあるデータ通信（転送）を行うこと、すなわち、通信の開始から終了まで通信路の信頼性を保持してデータの正常な通信の制御、さらにエラー時のエラー検出及び回復を行うことにある。
【０００８】
また、上記ＴＣＰが信頼性を確保するためにコネクション形のサービス形態をとっているのに対して、ＵＤＰは、処理の高速化のためのコネクションレス型と呼ばれるデータ伝送プロトコルであり、信頼性向上のための応答確認やネットワーク内の異なった経路を通ってきた受信データの順序調整等を行わない。
【０００９】
クライアント２は、クライアント（ユーザ）側に設置されており、ＬＡＮ／ＷＡＮ１に接続されている。このクライアント２は、ＬＡＮ／ＷＡＮ１およびＬＡＮ／ＷＡＮ４を介して、後述するサーバ６（サーバ７）に対してサービスを要求するためのコンピュータ端末である。クライアント側ＤＮＳサーバ３は、インターネット標準のＤＮＳを実現するためのサーバであり、ＬＡＮ／ＷＡＮ１に接続されている。
【００１０】
ここで、上記ＤＮＳについて詳述する。インターネットにおいては、上述したように端末を識別するためにＩＰアドレスが用いられているが、このＩＰアドレスは、４オクテット（３２ビット）で表現される数字の組み合わせからなるため、人間にとって非常に覚えにくい。そこで、各端末には、人間にも理解し易い識別名称としてドメイン名（名前空間）がそれぞれ付与されている。
【００１１】
上記ＤＮＳは、ドメイン名とＩＰアドレスとの対応を管理し、クライアント２からのドメイン名による問い合わせに対してＩＰアドレスを応答するシステムである。このことから、クライアント側ＤＮＳサーバ３は、上記ＤＮＳを実現するための装置であり、クライアント２に対してローカルなＤＮＳサーバとして位置づけられる。
【００１２】
サーバ６は、サービス提供者側に設置されており、ＬＡＮ／ＷＡＮ４に接続されている。このサーバ６は、クライアント２からのサービス要求に応じてクライアント２に対してサービスの提供を行うためのコンピュータ端末である。サーバ７は、サーバ６と同様にして、サービス提供者側に設置されており、ＬＡＮ／ＷＡＮ４に接続されている。このサーバ７は、クライアント２からのサービス要求に応じてクライアント２に対してサービスの提供を行うための端末である。ここで、上述したサーバ６およびサーバ７は、それぞれ物理的に別々の場所に設置されている。したがって、サーバ６およびサーバ７とクライアント２（クライアント側ＤＮＳサーバ３）との間の各距離は、それぞれ異なる。
【００１３】
さらに、サーバ６およびサーバ７は、クライアント２からみればあたかも１台のサーバとして機能している。また、サーバ６およびサーバ７には、代表として一つのドメイン名（以下、代表ドメイン名と称する）が付与されているとともに、それぞれにＩＰアドレスが付与されている。すなわち、この場合には、一つのドメイン名に複数のＩＰアドレスが登録されており、クライアント２が一つのドメイン名としてアクセスすることにより、サーバ６、サーバ７のうちいずれか一つのサーバにアクセス可能とされる。
【００１４】
すなわち、サーバ６、サーバ７は、代表ドメイン名で表される一つの仮想サーバを構成しており、クライアント２は、この仮想サーバの代表ドメイン名に対してアクセスする。このように、サーバ６、サーバ７に対して一つの代表ドメイン名を付与するとともに、クライアント２からのアクセスをサーバ６、サーバ７のいずれか一つのサーバにアクセス可能としたのは、前述した負荷分散するためである。この負荷分散については後述する。
【００１５】
サーバ側ＤＮＳサーバ５は、クライアント側ＤＮＳサーバ３と同様にして、ＤＮＳサーバとしての機能を有しており、クライアント側ＤＮＳサーバ３の上位装置として位置づけられている。すなわち、サーバ側ＤＮＳサーバ５は、クライアント側ＤＮＳサーバ３からのＩＰアドレスの問い合わせに対して応答する機能を有している。
【００１６】
また、サーバ側ＤＮＳサーバ５は、サーバ６、サーバ７を配下に置いており、クライアント側ＤＮＳサーバ３から代表ドメイン名をＩＰアドレスに変換するための問い合わせがあったとき、代表ドメイン名を、サーバ６、サーバ７のうち、いずれか一つのサーバのＩＰアドレスに変換して、クライアント側ＤＮＳサーバ３に応答する。すなわち、サーバ側ＤＮＳサーバ５は、クライアント２からのアクセス要求を、サーバ６、サーバ７のうち、いずれか一つへ振り分けているのである。この振り分けが上述した負荷分散である。
【００１７】
上記構成において、上述した代表ドメイン名の仮想サーバにアクセスする場合、たとえば、ステップＳＡ１では、クライアント２は、クライアント側ＤＮＳサーバ３に対してＩＰアドレスの問い合わせを行べく、代表ドメイン名をクライアント側ＤＮＳサーバ３へＬＡＮ／ＷＡＮ１を介して、通知する。
【００１８】
クライアント側ＤＮＳサーバ３は、自身のキャッシュメモリ（図示略）にアクセスし、問い合わせ履歴データを参照することで、過去に同様の問い合わせがあったか否かを判断する。ここで、過去に同様の問い合わせがあった場合には、ステップＳＡ４では、クライアント側ＤＮＳサーバ３は、問い合わせ履歴データに含まれるＩＰアドレスをＬＡＮ／ＷＡＮ１を介してクライアント２へ通知する。なお、キャッシュメモリにおける問い合わせ履歴データの保存期間は、１日程度である。
【００１９】
一方、過去に同様の問い合わせが無かった場合、ステップＳＡ２では、クライアント側ＤＮＳサーバ３は、ＬＡＮ／ＷＡＮ１およびＬＡＮ／ＷＡＮ４を介してサーバ側ＤＮＳサーバ５へＤＮＳ問合せを行う。具体的には、クライアント側ＤＮＳサーバ３は、代表ドメイン名をサーバ側ＤＮＳサーバ５へ通知する。これにより、ステップＳＡ３では、サーバ側ＤＮＳサーバ５は、まず、第１番目のサーバをサーバ６、第２番目のサーバをサーバ７とする振分テーブル（図示略）を参照することで、通知を受けた代表ドメイン名をたとえば第１番目のサーバ６のＩＰアドレスに変換する。
【００２０】
つぎに、サーバ側ＤＮＳサーバ５は、上記サーバ６のＩＰアドレスをＬＡＮ／ＷＡＮ４およびＬＡＮ／ＷＡＮ１を介してクライアント側ＤＮＳサーバ３へ通知する。これにより、ステップＳＡ４では、クライアント側ＤＮＳサーバ３は、サーバ６のＩＰアドレスを前述した問い合わせ履歴データとしてキャッシュメモリ（図示略）に保存した後、ＬＡＮ／ＷＡＮ１を介してクライアント２へ通知する。
【００２１】
そして、ステップＳＡ５では、上記通知を受けたクライアント２は、サーバ６のＩＰアドレスを含むＩＰパケットをＬＡＮ／ＷＡＮ１およびＬＡＮ／ＷＡＮ４を介してサーバ６へ送出する。そして、上記ＩＰパケットは、図示しないルータによりルーティングされた後、サーバ６に到着する。この結果、クライアント２とサーバ６との間に接続が確立し、サーバ６は、クライアント２から要求されたサービスを提供する。
【００２２】
また、図示しない別のクライアントにより、代表ドメイン名がクライアント側ＤＮＳサーバ３へＬＡＮ／ＷＡＮ１を介して通知されると（ステップＳＡ１）、ステップＳＡ２では、クライアント側ＤＮＳサーバ３は、上述した動作と同様にして、ＬＡＮ／ＷＡＮ１およびＬＡＮ／ＷＡＮ４を介してサーバ側ＤＮＳサーバ５へＩＰアドレスの問い合わせを行う。この場合、過去に同様の問い合わせが無かったものとする。
【００２３】
これにより、ステップＳＡ３では、サーバ側ＤＮＳサーバ５は、振分テーブル（図示略）を参照することで、通知を受けた代表ドメイン名を、つぎの第２番目のサーバ７のＩＰアドレスに変換する。そして、サーバ側ＤＮＳサーバ５は、上記サーバ７のＩＰアドレスをＬＡＮ／ＷＡＮ４およびＬＡＮ／ＷＡＮ１を介してクライアント側ＤＮＳサーバ３へ通知する。つぎのステップＳＡ４では、クライアント側ＤＮＳサーバ３は、サーバ７のＩＰアドレスをＬＡＮ／ＷＡＮ１を介してクライアント（図示略）へ通知する。
【００２４】
そして、ステップＳＡ５では、上記通知を受けたクライアント（図示略）は、サーバ７のＩＰアドレスを含むＩＰパケットをＬＡＮ／ＷＡＮ１およびＬＡＮ／ＷＡＮ４を介してサーバ７へ送出する。そして、上記ＩＰパケットは、図示しないルータによりルーティングされた後、サーバ７に到着する。この結果、クライアント（図示略）とサーバ７との間に接続が確立し、サーバ７は、クライアント（図示略）から要求されたサービスを提供する。
【００２５】
以後、サーバ側ＤＮＳサーバ５は、ＩＰアドレスの問い合わせを受ける度に、振分テーブルを参照しつつ、クライアントからのアクセスをサーバ６→サーバ７→サーバ６→サーバ７→・・・という具合に振り分けることにより、負荷分散を行う。
【００２６】
つぎに、図１９に示したように、災害が発生することにより、サーバ６がシステムダウンするとともに、サーバ７にかかる回線が切断された場合の動作について説明する。同図において、災害発生により、サーバ６がシステムダウンするとともに、サーバ７にかかる回線が切断されると、サーバ６およびサーバ７は、外部からのアクセスができない状態になる。このとき、サーバ側ＤＮＳサーバ５における振分テーブルから上記サーバ６およびサーバ７が削除されていないものとする。
【００２７】
このような状態において、ステップＳＢ１では、クライアント２は、クライアント側ＤＮＳサーバ３に対してＩＰアドレスの問い合わせを行べく、代表ドメイン名をクライアント側ＤＮＳサーバ３へＬＡＮ／ＷＡＮ１を介して、通知する。
【００２８】
クライアント側ＤＮＳサーバ３は、自身のキャッシュメモリ（図示略）にアクセスし、問い合わせ履歴データを参照することで、過去に同様の問い合わせがあったか否かを判断する。ここで、災害が発生する以前の問い合わせ履歴データがキャッシュメモリに保存されているものとすると、ステップＳＢ４では、クライアント側ＤＮＳサーバ３は、問い合わせ履歴データに含まれる、たとえば、サーバ６のＩＰアドレスをＬＡＮ／ＷＡＮ１を介してクライアント２へ通知する。
これにより、ステップＳＢ５では、クライアント２は、サーバ６へアクセスを試みるが、サーバ６がシステムダウンしているため、アクセスできない。すなわち、この場合には、キャッシュメモリに災害が発生する以前の問い合わせ履歴データがそのまま残っているため、実際にはアクセス不可能なサーバ６のＩＰアドレスがクライアント２へ通知されたのである。
【００２９】
一方、過去に同様の問い合わせが無かった場合、ステップＳＢ２では、クライアント側ＤＮＳサーバ３は、ＬＡＮ／ＷＡＮ１およびＬＡＮ／ＷＡＮ４を介して代表ドメイン名をサーバ側ＤＮＳサーバ５へ通知する。これにより、ステップＳＢ３では、サーバ側ＤＮＳサーバ５は、まず、第１番目のサーバをサーバ６、第２番目のサーバをサーバ７とする振分テーブル（図示略）を参照することで、通知を受けた代表ドメイン名をたとえば第１番目のサーバ６のＩＰアドレスに変換する。ここで、注意すべき点は、上記振分テーブルは、災害発生以前のものであり、現時点のサーバ６の状態（アクセス不可能）が反映されたものではない。
【００３０】
つぎに、ステップＳＢ３でサーバ側ＤＮＳサーバ５は、上記サーバ６のＩＰアドレスをＬＡＮ／ＷＡＮ４およびＬＡＮ／ＷＡＮ１を介してクライアント側ＤＮＳサーバ３へ通知する。これにより、ステップＳＢ４では、クライアント側ＤＮＳサーバ３は、サーバ６のＩＰアドレスを前述した問い合わせ履歴データとしてキャッシュメモリ（図示略）に保存した後、ＬＡＮ／ＷＡＮ１を介してクライアント２へ通知する。そして、ステップＳＢ５では、上記通知を受けたクライアント２は、サーバ６へアクセスを試みるが、サーバ６がシステムダウンしているため、アクセスできない。
【００３１】
また、図示しない別のクライアントにより、代表ドメイン名がクライアント側ＤＮＳサーバ３へＬＡＮ／ＷＡＮ１を介して通知されると（ステップＳＢ１）、ステップＳＢ２では、クライアント側ＤＮＳサーバ３は、上述した動作と同様にして、ＬＡＮ／ＷＡＮ１およびＬＡＮ／ＷＡＮ４を介してサーバ側ＤＮＳサーバ５へ仮想サーバのＩＰアドレスの問い合わせを行う。この場合、過去に同様の問い合わせが無かったものとする。
【００３２】
これにより、ステップＳＢ３では、サーバ側ＤＮＳサーバ５は、振分テーブル（図示略）を参照することで、通知を受けた代表ドメイン名を、つぎの第２番目のサーバ７のＩＰアドレスに変換する。ここで注意すべき点は、上記振分テーブルの内容は、災害が発生する以前のものであり、現時点のサーバ７の状態（アクセス不可能）が反映されたものではない。
【００３３】
そして、サーバ側ＤＮＳサーバ５は、上記サーバ７のＩＰアドレスをＬＡＮ／ＷＡＮ４およびＬＡＮ／ＷＡＮ１を介してクライアント側ＤＮＳサーバ３へ通知する。つぎのステップＳＢ４では、クライアント側ＤＮＳサーバ３は、サーバ７のＩＰアドレスをＬＡＮ／ＷＡＮ１を介してクライアント（図示略）へ通知する。そして、ステップＳＢ５では、上記通知を受けたクライアントは、サーバ７へアクセスを試みるが、サーバ７にかかる回線が切断されているため、アクセスできない。
【００３４】
図２０は、従来のネットワークシステムの構成例２を示す図である。この図に示したネットワークシステムでは、負荷分散方式として、ＮＡＴ（Network Address Translator：ネットワークアドレス変換）によりＩＰヘッダの宛先アドレスを、振り分け先のサーバのＩＰアドレスに変換するＮＡＴ方式や、上記宛先アドレスを振り分け先のサーバのＭＡＣ（Media Access Control：媒体アクセス制御）アドレスに付け替える等のＭＡＣ方式が採用されている。
【００３５】
同図において、ＬＡＮ／ＷＡＮ１０は、インターネットワーキング（相互接続）によって、物理的に離隔配置されている複数のコンピュータ間でデータ通信を行うための大規模ネットワークであり、たとえば、インターネットである。クライアント１１は、クライアント（ユーザ）側に設置されており、ＬＡＮ／ＷＡＮ１０に接続されている。
【００３６】
このクライアント１１は、上述したＩＰパケットをＬＡＮ／ＷＡＮ１０を介して、後述するサーバ１３（サーバ１４）に対してサービスを要求するためのコンピュータ端末である。負荷分散装置１２は、上述したＮＡＴ方式やＭＡＣ方式により、クライアント１１からのアクセス要求をサーバ１３、サーバ１４のうちいずれか一つへ振り分けることにより、負荷分散を行う装置である。この負荷分散装置１２には、サーバ１３およびサーバ１４を代表する代表ＩＰアドレスが付与されている。
【００３７】
サーバ１３およびサーバ１４は、サービス提供者側に設置されており、ＬＡＮ／ＷＡＮ１０に接続されている。これらのサーバ１３およびサーバ１４は、クライアント１１からのサービス要求に応じてクライアント１１に対してサービスの提供を行うためのコンピュータ端末である。また、サーバ１３およびサーバ１４は、上述した代表ＩＰアドレスにより、クライアント１１からみればあたかも１台のサーバとして機能しており、それぞれにＩＰアドレスが付与されている。すなわち、サーバ１３、サーバ１４は、代表ＩＰアドレスで表される一つの仮想サーバを構成しており、クライアント１１は、この仮想サーバの代表ＩＰアドレスに対してアクセスする。
【００３８】
上記構成において、上述した仮想サーバにアクセスする場合、たとえば、ステップＳＣ１では、クライアント１１は、代表ＩＰアドレスを有する負荷分散装置１２へＬＡＮ／ＷＡＮ１０を介してアクセスする。これにより、ステップＳＣ２では、負荷分散装置１２は、クライアント１１からのＩＰパケット（サービス要求）を、ＮＡＴ方式やＭＡＣ方式により、たとえば、サーバ１４へ振り分ける。
【００３９】
つぎのステップＳＣ３では、クライアント１１とサーバ１４との間に、ＬＡＮ／ＷＡＮ１０および負荷分散装置１２を介して接続が確立し、サーバ１４は、クライアント１１から要求されたサービスを提供する。なお、クライアント１１とサーバ１４との接続ルートとしては、ステップＳＣ４のように、負荷分散装置１２を経由せず、ＬＡＮ／ＷＡＮ１０のみを介する接続ルートの場合もある。
【００４０】
つぎに、図２１に示したように、災害が発生することにより、負荷分散装置１２がシステムダウンするとともに、ＬＡＮ／ＷＡＮ１０に回線断が発生した場合の動作について説明する。ここで、災害の影響は、サーバ１３およびサーバ１４には、及んでいないものとする。
【００４１】
このような状態において、ステップＳＤ１では、クライアント１１は、代表ＩＰアドレスを有する負荷分散装置１２へアクセスを試みるが、負荷分散装置１２がシステムダウンしているとともに、ＬＡＮ／ＷＡＮ１０が回線断状態にあるため、サーバ１３およびサーバ１４が正常に稼働しているにもかかわらず、アクセスできない。
【００４２】
【発明が解決しようとする課題】
ところで、従来のネットワークシステムにおいては、図１８に示したクライアント側ＤＮＳサーバ３およびサーバ側ＤＮＳサーバ５、図２０に示した負荷分散装置１２により効率的に負荷分散を行っている旨を述べた。
【００４３】
しかしながら、従来のネットワークシステムは、図１９および図２１を参照して説明したように、災害に非常に弱いシステムであり、たとえば、一つの負荷分散装置１２が災害によりシステムダウンした場合であってもすべてのサービスが停止してしまう。
【００４４】
そこで、災害発生によるサービス停止を回避する方法として、各装置を冗長構成にする方法が採られる。しかしながら、この方法は、冗長構成が採られた複数の装置が設置されている地域に地震等の災害が発生した場合、当該複数の装置のすべてが被災する可能性が高く、根本的な解決にはならない。
【００４５】
本発明は、このような背景の下になされたもので、災害発生によるサービス停止を回避することができる負荷分散システムを提供することを目的とする。
【００４６】
【課題を解決するための手段】
上記目的を達成するために、請求項１にかかる発明は、サービスの提供を求めるクライアント（後述する一実施の形態のクライアント１００および２００に相当）の要求を、前記サービスを提供するサーバ（後述する一実施の形態のサーバ５１０、５２０、６１０および６２０に相当）を含むサイト（後述する一実施の形態のサービスサイトＳＳ 1 およびＳＳ 2 に相当）のいずれか１つに振り分けさせる一次負荷分散手段（後述する一実施の形態の一次負荷分散装置４１０、４２０、４３０に相当）と、自身が属するサイトに前記要求が振り分けられた場合に、該サイトに属するサーバのいずれか１つに該要求を振り分ける二次負荷分散手段（後述する一実施の形態の二次負荷分散装置５００および６００に相当）とを備える負荷分散システムであって、前記一次負荷分散手段は、前記二次負荷分散手段の運転状態を監視し、運転停止していない二次負荷分散手段を含むサイトのいずれか１つに前記要求を振り分けさせるとともに、監視結果を各二次負荷分散手段に配布し、前記二次負荷分散手段は、自身が属するサイトに含まれるサーバの負荷が所定よりも高い場合に、前記監視結果に基づいて運転停止していない他の二次負荷分散手段を選択し、自身が属するサイトへ振り分けられた前記要求を前記他の二次負荷分散手段へ転送することを特徴とする。
【００４７】
この請求項１にかかる発明によれば、あるクライアントからサービス要求があると、このサービス要求は、複数の一次負荷分散手段のうちいずれか一つの一次負荷分散手段により一つのサイト（二次負荷分散手段）に一次振り分けされる。そして、二次負荷分散手段は、当該サービス要求を一つのサーバに二次振り分けする。
【００４８】
また、一次負荷分散手段は、各二次負荷分散手段の運転状況を監視し、いずれかの二次負荷分散手段が運転停止した場合には、当該二次負荷分散手段は、一次振り分けにおける負荷分散の対象から除外される。したがって、災害発生等により二次負荷分散手段に障害が発生した場合には、クライアントからサービス要求があっても、除外された二次負荷分散手段に対しては一次振り分けが行われることがなく、その他の正常な二次負荷分散に対して一次振り分けが行われる。
【００４９】
また、いずれかのサイトの負荷が所定よりも高くなった場合には、そのサイトの二次負荷分散手段が他の正常な二次負荷分散手段へサービス要求を転送することにより、二次負荷分散手段間の協調による負荷分散が実現される。
【００５０】
このように、請求項１にかかる発明によれば、災害発生によるサービス停止を回避することができ、さらに、二次負荷分散手段間の協調によっても負荷分散を実現可能な２段階方式の負荷分散システムを得ることができる。
【００５１】
また、請求項２にかかる発明は、請求項１に記載の負荷分散システムにおいて、前記一次負荷分散手段は、サービスを提供するサーバにアクセスするためのドメイン名の解決を求めるＤＮＳ問合せに対して、前記二次負荷分散手段のいずれか１つのＩＰアドレスを応答することにより、該ＩＰアドレスを有する二次負荷分散手段を含むサイトへ前記要求を振り分けさせ、前記二次負荷分散手段は、自身が属するサイトに属するサーバのいずれか１つに前記要求を振り分ける場合に、自身が有するＩＰアドレスを宛先として前記クライアントから送信された前記要求のヘッダ部を書き換えることにより、前記サービスを提供するサーバに該要求を振り分けることを特徴とする。
【００５２】
この請求項２にかかる発明によれば、一次振り分けはＤＮＳ問合せに対して応答する二次負荷分散手段のＩＰアドレスを切り替えることで実現され、一次振り分けはアドレス情報を書き換えることで実現される。
【００５３】
このように、請求項２にかかる発明によれば、一次振り分けの結果は、ＤＮＳ問合せのキャッシュとして問合せ元に一定期間記憶され、キャッシュを保持している問合せ元では、このキャッシュに基づいて一次振り分けが行われることになるため、一次負荷分散手段の負荷が軽減される。
【００５４】
また、請求項３にかかる発明は、請求項２に記載の負荷分散システムにおいて、前記一次負荷分散手段は、各二次負荷分散手段に対して、前記ＤＮＳ問合せの送信元と当該の二次負荷分散手段との間の通信経路の経路負荷の計測を依頼し、計測された経路負荷に係る情報に基づいて、サービスを提供するサーバにアクセスするためのドメイン名の解決を求めるＤＮＳ問合せを受信した場合に、該ＤＮＳ問合せの送信元との間の経路負荷が最も少ない二次負荷分散手段のＩＰアドレスを応答することを特徴とする。
【００５５】
この請求項３にかかる発明によれば、一次負荷分散手段は、ＤＮＳ問合せの送信元との間の経路負荷が最も少ない二次負荷分散手段を、サービス要求の振り分け先として選択する。本来は、サービス要求の送信元との間の経路負荷が最も少ない二次負荷分散手段を、サービス要求の振り分け先として選択することが好ましいが、一次負荷分散手段は、サービス要求の送信元と直接情報のやりとりをすることはないため、サービス要求の送信元を識別することはできない。そこで、一次負荷分散手段は、直接情報のやりとりをし、サービス要求の送信元と近い位置にあると期待されるＤＮＳ問合せの送信元との間の経路負荷を基準にして、二次負荷分散手段を選択する。
【００５６】
このように、請求項３にかかる発明によれば、サービス要求の送信元との間の経路負荷が最も少ないことが期待される二次負荷分散手段がサービス要求の振り分け先として選択されるので、ネットワークに負荷をかけることなく負荷分散を実現することができる。
【００６４】
【発明の実施の形態】
以下、図面を参照して本発明にかかる負荷分散システムの一実施の形態について詳細に説明する。
【００６５】
図１は、本発明にかかる一実施の形態の概略構成を示すブロック図である。この図において、クライアント１００、クライアント側ＤＮＳサーバ１１０、クライアント２００、クライアント側ＤＮＳサーバ２１０、サーバ側ＤＮＳサーバ群３００、一次負荷分散装置群４００、二次負荷分散装置５００、サーバ５１０、サーバ５２０、二次負荷分散装置６００、サーバ６１０およびサーバ６２０は、それぞれ図示しないルータを含むネットワーク（たとえば、インターネット）に接続されており、それぞれがアクセス可能な状態とされている。
【００６６】
また、同図に示したネットワークシステムは、大きく分けて、クライアント側の領域であるＤＮＳゾーンＺ1 およびＤＮＳゾーンＺ2 、サービスを提供するサービスサイトＳＳ1 およびサービスサイトＳＳ2 、ならびに負荷分散を行う負荷分散サイトＬＢＳ（Load Balancing Site）に分類される。
【００６７】
ＤＮＳゾーンＺ1 において、クライアント１００は、クライアント（ユーザ）側に設置されており、前述したＩＰパケットをルータ（図示略）へ送出することにより、後述するサーバ５１０、サーバ５２０、サーバ６１０またはサーバ６２０からサービスの提供を受けるコンピュータ端末である。また、クライアント１００は、サーバへアクセスする前に、クライアント側ＤＮＳサーバ１１０に対して、サーバ５１０、サーバ５２０、サーバ６１０およびサーバ６２０の代表ドメイン名を通知して、アクセス先のＩＰアドレスを獲得するというＤＮＳ問合せを行う。
【００６８】
クライアント側ＤＮＳサーバ１１０は、前述したＤＮＳを実現するためのサーバであり、クライアント１００に接続されている。このクライアント側ＤＮＳサーバ１１０は、クライアント１００よりＤＮＳ問合せがあった場合に、その上位に位置するサーバ側ＤＮＳサーバ群３００（一次負荷分散装置群４００）に対して、ＤＮＳ問合せを行い、一次負荷分散装置群４００から通知される、クライアント１００のアクセス先である二次負荷分散装置５００または二次負荷分散装置６００のＩＰアドレス（ＤＮＳ回答）を受け取り、これをクライアント１００へ通知する。
【００６９】
ＤＮＳゾーンＺ2 において、クライアント２００は、クライアント１００と同様にしてクライアント（ユーザ）側に設置されており、前述したＩＰパケットをルータ（図示略）へ送出することにより、後述するサーバ５１０、サーバ５２０、サーバ６１０またはサーバ６２０からサービスの提供を受けるコンピュータ端末である。また、クライアント２００は、サーバへアクセスする前に、クライアント側ＤＮＳサーバ２１０に対して、サーバ５１０、サーバ５２０、サーバ６１０およびサーバ６２０の代表ドメイン名を通知して、アクセス先である二次負荷分散装置５００または二次負荷分散装置６００のＩＰアドレスを獲得するというＤＮＳ問合せを行う。
【００７０】
クライアント側ＤＮＳサーバ２１０は、前述したＤＮＳを実現するためのサーバであり、クライアント２００に接続されている。このクライアント側ＤＮＳサーバ２１０は、クライアント２００よりＤＮＳ問合せがあった場合に、その上位に位置するサーバ側ＤＮＳサーバ群３００（一次負荷分散装置群４００）に対して、ＤＮＳ問合せを行い、一次負荷分散装置群４００から通知される、クライアント２００のアクセス先である二次負荷分散装置５００または二次負荷分散装置６００のＩＰアドレス（ＤＮＳ回答）を受け取り、これをクライアント２００へ通知する。
【００７１】
サーバ側ＤＮＳサーバ群３００は、クライアント側ＤＮＳサーバ１１０およびクライアント側ＤＮＳサーバ２１０の上位装置であり、前述したＤＮＳを実現するためのものである。ただし、このサーバ側ＤＮＳサーバ群３００における負荷分散機能は、後述する一次負荷分散装置群４００が担っている。また、サーバ側ＤＮＳサーバ群３００は、サーバ側ＤＮＳサーバ（プライマリ）３１０およびサーバ側ＤＮＳサーバ（セカンダリ）３２０から構成されており、冗長構成が採られている。
【００７２】
一次負荷分散装置群４００は、クライアント側ＤＮＳサーバ１１０またはクライアント側ＤＮＳサーバ２１０からのＤＮＳ問合せに対して、後述する振分テーブル等に基づいて、二次負荷分散装置５００または二次負荷分散装置６００のうちいずれかのＩＰアドレスをＤＮＳ回答とする。すなわち、一次負荷分散装置群４００は、クライアント１００またはクライアント２００からのアクセス要求を二次負荷分散装置５００宛または二次負荷分散装置６００宛という具合に大まかに一次振り分けすることにより、一次負荷分散を行う装置である。
【００７３】
また、一次負荷分散装置群４００は、一次負荷分散装置（プライマリ）４１０、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０から構成されており、冗長構成が採られている。これらの一次負荷分散装置（プライマリ）４１０、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０のそれぞれは、負荷分散を行う点で共通の機能を備えている。
【００７４】
一次負荷分散装置（プライマリ）４１０は、負荷分散機能の他に、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０を制御する機能を備えている。一次負荷分散装置（セカンダリ）４２０は、一次負荷分散装置（プライマリ）４１０の機能が停止した場合に、一次負荷分散装置（プライマリ）４１０に代わってプライマリとして機能する装置である。なお、一次負荷分散装置群４００においては、プライマリ以外の装置は、すべてバックアップとしての装置である。したがって、一次負荷分散装置（セカンダリ）４２０は、バックアップとしての装置であるとともに、セカンダリとしての装置でもある。
【００７５】
サービスサイトＳＳ1 において、二次負荷分散装置５００は、サーバ５１０、サーバ５２０の近傍に配置されている。この二次負荷分散装置５００は、一次負荷分散装置群４００により一次振り分けされたＩＰパケット（サービス要求）を、サーバ５１０、サーバ５２０の運転状態に応じて、最良の運転状態のサーバへ二次振り分けを行うことにより、二次負荷分散を行う装置である。この二次振り分けには、前述したＮＡＴによりＩＰヘッダの宛先アドレスを、振り分け先のサーバのＩＰアドレスに変換する方法や、上記宛先アドレスを振り分け先のサーバのＭＡＣアドレスに付け替える等の方法が採られる。
【００７６】
また、二次負荷分散装置５００は、一次負荷分散装置群４００からの計測依頼をトリガとして、たとえば、クライアント側ＤＮＳサーバ１１０（サーバ５１０、サーバ５２０）との間の通信経路における経路負荷を測定する機能を備えている。サーバ５１０は、サービス提供者側に設置されており、たとえば、クライアント１００からのアクセスに基づくサービス要求に応じて、クライアント１００に対してサービスの提供を行うためのコンピュータ端末である。同様にして、サーバ５２０は、サービス提供者側に設置されており、たとえば、クライアント１００からのサービス要求に応じて、クライアント１００に対してサービスの提供を行うためのコンピュータ端末である。
【００７７】
サービスサイトＳＳ2 において、二次負荷分散装置６００は、サーバ６１０、サーバ６２０の近傍に配置されている。この二次負荷分散装置６００は、二次負荷分散装置５００と同様にして、一次負荷分散装置群４００により一次振り分けされたＩＰパケット（サービス要求）を、サーバ６１０、サーバ６２０の運転状態に応じて、最良の運転状態のサーバへ二次振り分けを行うことにより、二次負荷分散を行う装置である。この二次振り分けには、前述したＮＡＴによりＩＰヘッダの宛先アドレスを、振り分け先のサーバのＩＰアドレスに変換する方法や、上記宛先アドレスを振り分け先のサーバのＭＡＣアドレスに付け替える等の方法が採られる。
【００７８】
また、二次負荷分散装置６００は、二次負荷分散装置５００と同様にして、一次負荷分散装置群４００からの計測依頼をトリガとして、たとえば、クライアント側ＤＮＳサーバ２１０（サーバ６１０、サーバ６２０）との間の通信経路における経路負荷を測定する機能を備えている。サーバ６１０は、サービス提供者側に設置されており、たとえば、クライアント２００からのアクセスに基づくサービス要求に応じて、クライアント２００に対してサービスの提供を行うためのコンピュータ端末である。同様にして、サーバ６２０は、たとえば、クライアント２００からのサービス要求に応じて、クライアント２００に対してサービスの提供を行うためのコンピュータ端末である。
【００７９】
ここで、サーバ５１０、サーバ５２０、サーバ６１０およびサーバ６２０は、クライアント１００（クライアント２００）からみればあたかも１台の仮想サーバとして機能している。したがって、これらのサーバ５１０、サーバ５２０、サーバ６１０およびサーバ６２０には、代表として一つの代表ドメイン名が付与されている。ただし、サーバ５１０、サーバ５２０、サーバ６１０およびサーバ６２０それぞれには、固有のＩＰアドレスが付与されている。また、サービスサイトＳＳ1 における二次負荷分散装置５００には、サーバ５１０およびサーバ５２０を仮想サーバとするＩＰアドレスが付与されている。同様にして、サービスサイトＳＳ2 における二次負荷分散装置６００には、サーバ６１０およびサーバ６２０を仮想サーバとするＩＰアドレスが付与されている。
【００８０】
つぎに、図２を参照して一実施の形態の具体的構成について説明する。この図において、図１の各部にそれぞれ対応する部分には同一の符号を付ける。ただし、図２においては、説明を簡略化するために、図１に示したクライアント２００およびクライアント側ＤＮＳサーバ２１０が省略されている。
【００８１】
また、図２には、相互接続されたＬＡＮ／ＷＡＮ７００、ＬＡＮ／ＷＡＮ８００、ＬＡＮ／ＷＡＮ９００およびＬＡＮ／ＷＡＮ１０００が図示されている。ＬＡＮ／ＷＡＮ７００には、クライアント１００およびクライアント側ＤＮＳサーバ１１０が接続されている。ＬＡＮ／ＷＡＮ８００には、サーバ側ＤＮＳサーバ（プライマリ）３１０および一次負荷分散装置（プライマリ）４１０が接続されている。
【００８２】
また、ＬＡＮ／ＷＡＮ９００には、サーバ側ＤＮＳサーバ（セカンダリ）３２０、一次負荷分散装置（バックアップ）４３０、二次負荷分散装置５００、サーバ５１０およびサーバ５２０が接続されている。ＬＡＮ／ＷＡＮ１０００には、一次負荷分散装置（セカンダリ）４２０、二次負荷分散装置６００、サーバ６１０およびサーバ６２０が接続されている。
【００８３】
このように、クライアント１００、・・・、サーバ６２０のそれぞれは、地域災害発生による集中的な被災を避けるべく、地理的に分散配置されている。特に、一次負荷分散装置群４００（図１参照）を構成する一次負荷分散装置（プライマリ）４１０、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０は、システムの中枢を担う装置である。したがって、一次負荷分散装置（プライマリ）４１０等を地理的に分散配置させる意義は大きい。同様にして、サーバ側ＤＮＳサーバ（プライマリ）３１０およびサーバ側ＤＮＳサーバ（セカンダリ）３２０についても、地理的に分散配置する意義が大きい。
【００８４】
つぎに、図３を参照して、図２に示した一次負荷分散装置４１０（プライマリ）の構成について説明する。この図において、図２の各部に対応する部分には同一の符号を付ける。一次負荷分散装置（プライマリ）４１０は、装置各部を制御する制御部４１１、記憶部４１２、外部装置（クライアント側ＤＮＳサーバ１１０等）との間で通信を行う通信部４１３および通信部４１４から構成されている。
【００８５】
制御部４１１は、ＤＮＳ応答スレッドＳ1 、ＤＮＳ振分テーブル配布スレッドＳ2 、・・・、経路負荷計測結果集計スレッドＳ9 を発生させるとともに、これらのスレッドの実行に伴う制御を行う。この制御部４１１の動作の詳細については、後述する。記憶部４１２は、ＤＮＳ振分テーブルＴ1 、サイト運転状態テーブルＴ2 、・・・、サイト連携振分テーブルＴ7 およびＤＮＳアクセスログＬを記憶する。
【００８６】
上記ＤＮＳ振分テーブルＴ1 は、クライアント側ＤＮＳサーバ１１０からのＤＮＳ問合せに応じて、前述した一次振り分けを行う場合に用いられるテーブルであり、制御部４１１により、サイト負荷状態テーブルＴ4 、経路負荷計測テーブルＴ5 およびポリシー情報テーブルＴ6 等に基づいて作成される。すなわち、図４に示したように、ＤＮＳ振分テーブルＴ1 は、メインテーブルＴa 、振分先一貫性保持テーブルＴb およびＬＤ情報テーブルＴc から構成されている。
【００８７】
メインテーブルＴa は、代表ドメイン名を示す［ドメイン名］、振分先一貫性保持テーブルＴb へのポインタを示す［テーブルポインタ（１）］、振分先一貫性保持テーブルＴb の数を示す［テーブル数（１）］、ＬＤ情報テーブルＴc へのポインタを示す［テーブルポインタ（２）］、ＬＤ（Local Dispatcher）情報テーブルＴc の数を示す［テーブル数（２）］から構成されている。
【００８８】
振分先一貫性保持テーブルＴb は、ＤＮＳ問合せ元のクライアント側ＤＮＳサーバへの一次振分先のＩＰアドレスを一定時間保持するためのテーブルである。この振分先一貫性保持テーブルＴb は、ＤＮＳ問合せ元のクライアント側ＤＮＳサーバのＩＰアドレスを示す［クライアント側ＤＮＳサーバアドレス］、当該ＤＮＳ問合せに対応する二次負荷分散装置５００または二次負荷分散装置６００のＩＰアドレスを示す［回答アドレス］から構成されている。
【００８９】
ＬＤ情報テーブルＴc は、二次負荷分散装置５００または二次負荷分散装置６００における動作状態等に関する情報が格納されたテーブルである。すなわち、ＬＤ情報テーブルＴc において、［ＬＤアドレス］は、二次負荷分散装置５００のＩＰアドレス（二次負荷分散装置６００のＩＰアドレス）を示す。
【００９０】
［ＬＤ動作状態コード］は、二次負荷分散装置５００（二次負荷分散装置６００）の動作状態を示す動作状態コードを示す。この動作状態コードとしては、正常に動作していることを示す０ｘ０００１（＝正常動作中）、停止状態にあることを示す０ｘ０００２（＝停止）、高負荷状態にあることを示す０ｘ０００３（＝高負荷）、一次振り分け先として予約されていることを示す０ｘ０００４（＝予約）がある。
【００９１】
また、［優先コード］は、優先的に一次振り分けが行われるＤＮＳ問合せ元のクライアント側ＤＮＳサーバを識別するための優先コードを示しており、後述する経路負荷計測テーブルＴ5 における経路負荷計測結果に基づくものである。この優先コードとしては、単一のクライアント側ＤＮＳサーバを指定していることを示す０ｘ０００１（単一ＩＰアドレス指定）、複数のクライアント側ＤＮＳサーバを範囲指定していることを示す０ｘ０００２、クライアント側ＤＮＳサーバのＩＰアドレスに加えてサブネットを指定していることを示す０ｘ０００３がある。
【００９２】
ここで、［優先コード］として０ｘ０００１（＝単一ＩＰアドレス指定）が格納されている場合には、［クライアント側ＤＮＳアドレス（１）］に当該クライアント側ＤＮＳサーバのＩＰアドレスが格納される。また、［優先コード］として、０ｘ０００２（＝範囲指定）が格納されている場合には、［クライアント側ＤＮＳアドレス（１）］に複数のクライアント側ＤＮＳサーバにおける若番のＩＰアドレスが格納されるとともに、［クライアント側ＤＮＳアドレス（２）］に複数のクライアント側ＤＮＳサーバにおける老番のＩＰアドレスが格納される。
【００９３】
また、［優先コード］として、０ｘ０００３（＝ＩＰアドレス＋サブネット指定）が格納されている場合には、［クライアント側ＤＮＳアドレス（１）］に当該クライアント側ＤＮＳサーバのＩＰアドレスが格納されるとともに、［クライアント側ＤＮＳアドレス（２）］にサブネットが格納される。
【００９４】
図５に示したサイト運転状態テーブルＴ2 は、二次負荷分散装置５００、二次負荷分散装置６００の運転状態（停止または運転中）を示すテーブルである。すなわち、サイト運転状態テーブルＴ2 は、二次負荷分散装置５００（二次負荷分散装置６００）のＩＰアドレスを示す［ＬＤアドレス］、二次負荷分散装置５００（二次負荷分散装置６００）の運転状態を示す［運転状態フラグ］（０：停止、１５：運転中）から構成されている。
【００９５】
また、サイト運転状態テーブルＴ2 は、一次負荷分散装置（プライマリ）４１０の起動時に作成され、一次負荷分散装置（プライマリ）４１０から二次負荷分散装置５００（二次負荷分散装置６００）に対して一定時間間隔で行われる運転監視（ＬＤ運転監視スレッドＳ5 ：図３参照）に基づいて更新される。
【００９６】
図６に示したＬＢＣ（Load Balancing Controller）運転状態テーブルＴ3 は、一次負荷分散装置（セカンダリ）４２０（一次負荷分散装置（バックアップ）４３０）の運転状態（停止または運転中）を示すテーブルである。すなわち、ＬＢＣ運転状態テーブルＴ3 は、一次負荷分散装置（セカンダリ）４２０（一次負荷分散装置（バックアップ）４３０）のＩＰアドレスを示す［ＬＢＣアドレス］、一次負荷分散装置（セカンダリ）４２０（一次負荷分散装置（バックアップ）４３０）の運転状態を示す［運転状態フラグ］（０：停止、１５：運転中）、一次負荷分散装置群４００におけるセカンダリを示す［セカンダリフラグ］から構成されている。
【００９７】
また、ＬＢＣ運転状態テーブルＴ3 は、一次負荷分散装置（プライマリ）４１０の起動時に作成され、一次負荷分散装置（プライマリ）４１０から一次負荷分散装置（セカンダリ）４２０（一次負荷分散装置（バックアップ）４３０）に対して一定時間間隔で行われる運転監視（ＬＢＣ運転監視スレッドＳ6 ：図３参照）の結果に基づいて更新される。
【００９８】
図７に示したサイト負荷状態テーブルＴ4 は、サイト（サービスサイトＳＳ1 、サービスサイトＳＳ2 ：図１参照）毎の負荷状態を示すテーブルである。すなわち、サイト負荷状態テーブルＴ4 には、二次負荷分散装置５００（二次負荷分散装置６００）のＩＰアドレスを示す［ＬＤアドレス］、［ＶＩＰ］、当該サイトが広域振り分け（広域負荷分散）対象であるか否かを示す［広域振分フラグ］（対象：ＯＦＦ、対象外：ＯＮ）が含まれている。
【００９９】
また、サイト負荷状態テーブルＴ4 において、［サイト連携フラグ］（対象：ＯＦＦ、対象外：ＯＮ）は、複数のサイトが連携して、あるサイトで処理しきれないサービス要求（ＩＰパケット）を別のサイトに転送するというサイト連携の対象であるか否かを示すフラグである。［負荷状態フラグ］（通常負荷：ＯＦＦ、高負荷：ＯＮ）は、当該サイトの負荷状態（通常負荷または高負荷）を示すフラグである。
【０１００】
［サイト連携受入フラグ］（受入：ＯＮ、拒否：ＯＦＦ）は、当該サイトが他のサイトからサイト連携を受け入れているか否かを示すフラグである。［サイト連携受入実行フラグ］（実行：ＯＮ、未実行：ＯＦＦ）は、当該サイトが他のサイトへのサイト連携を実行しているか否かを示すフラグである。また、サイト負荷状態テーブルＴ4 は、一次負荷分散装置（プライマリ）４１０の起動時に作成され、後述する広域負荷分散管理スレッドＳ4 （図３参照）が実行され、サイト負荷情報が受信された場合に更新される。
【０１０１】
図８に示した経路負荷計測テーブルＴ5 は、二次負荷分散装置５００（二次負荷分散装置６００）により実行される経路負荷計測の方法、結果等の情報からなるテーブルである。すなわち、経路負荷計測テーブルＴ5 は、線路負荷計測の対象となる二次負荷分散装置５００（二次負荷分散装置６００）、クライアント側ＤＮＳサーバ１１０のＩＰアドレスを示す［対象アドレス］、経路負荷計測の方法を示す［計測方法］、経路負荷計測の結果を示す［計測結果］、経路負荷計測の計測日時を示す［計測日時］からなる。この経路負荷計測テーブルＴ5 は、後述する経路負荷計測結果集計スレッドＳ9 が実行された場合に更新される。この経路負荷計測テーブルＴ5 における経路負荷計測結果は、ＤＮＳ振分テーブルＴ1 に反映される。
【０１０２】
図９に示したポリシー情報テーブルＴ6 は、ネットワークシステムに用いられるドメイン名の一覧を示す［ドメイン名一覧］、設定されたＤＮＳの数を示す［設定ＤＮＳ数］、二次負荷分散装置５００（二次負荷分散装置６００）のＩＰアドレスを示す［ＬＤアドレス］、二次負荷分散装置５００、二次負荷分散装置６００の数を示す［ＬＤ数］、一次負荷分散装置群４００における一次振り分けの優先順位を示す［振分優先情報］からなる。
【０１０３】
図１０に示したＤＮＳアクセスログＬは、クライアント側ＤＮＳサーバ１１０からＤＮＳ問合せがある毎に記録されるものであり、アクセス累計、アクセス数等からなる。すなわち、ＤＮＳアクセスログＬは、問合せ元のクライアント１００のＤＮＳ名を示す［ＤＮＳ名］、アクセスの累計を示す［アクセス累計］、クライアント側ＤＮＳサーバ１１０のＩＰアドレスを示す［アクセスクライアントＤＮＳアドレス］、アクセス時間を示す［アクセス時間］、アクセス数を示す［アクセス数］から構成されている。
【０１０４】
図３に戻り、サイト連携振分テーブルＴ7 は、前述したアクセス連携において振分元のサイトと、振分先のサイトとの関係を示すテーブルである。また、一次負荷分散装置（プライマリ）４１０において、ＤＮＳ応答スレッドＳ1 は、クライアント側ＤＮＳサーバ１１０からのＤＮＳ問合せに対するＤＮＳ応答に関する処理を行うためのスレッドである。
【０１０５】
ＤＮＳ振分テーブル配布スレッドＳ2 は、ＤＮＳ振分テーブルＴ1 を一次負荷分散装置（セカンダリ）４２０、一次負荷分散装置（バックアップ）４３０へ配布するためのスレッドであり、ＤＮＳ振分テーブルＴ1 の作成時および更新時に実行される。したがって、ＤＮＳ振分テーブル配布スレッドＳ2 が一定時間間隔毎に実行されることにより、一次負荷分散装置（プライマリ）４１０、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０におけるＤＮＳ振分テーブルＴ1 およびＤＮＳ振分テーブルＴ１’（図１１参照）は、内容的に同期がとられる。
【０１０６】
ＤＮＳアクセスログ同期スレッドＳ3 は、一次負荷分散装置（プライマリ）４１０におけるＤＮＳアクセスログＬと、一次負荷分散装置（セカンダリ）４２０（一次負荷分散装置（バックアップ）４３０）におけるＤＮＳアクセスログＬ’（図１１参照）との同期をとる処理を行うためのスレッドである。広域負荷分散管理スレッドＳ4 は、広域負荷分散に関する管理（サイト運転状態テーブルＴ2 、サイト連携テーブルＴ7 の更新等）を行うためのスレッドである。
【０１０７】
ＬＤ運転監視スレッドＳ5 は、二次負荷分散装置５００（二次負荷分散装置６００）の運転監視を行うためのスレッドである。ＬＢＣ運転監視スレッドＳ6 は、一次負荷分散装置（セカンダリ）４２０（一次負荷分散装置（バックアップ）４３０）の運転監視を行うためのスレッドである。サイト連携振分テーブル配布スレッドＳ7 は、サイト連携振分テーブルＴ7 を二次負荷分散装置５００（二次負荷分散装置６００）へ配布するためのスレッドである。
【０１０８】
経路負荷計測依頼スレッドＳ8 は、二次負荷分散装置５００（二次負荷分散装置６００）に対して経路負荷計測を依頼するためのスレッドである。経路負荷計測結果集計スレッドＳ9 は、上記経路負荷計測の終了後、二次負荷分散装置５００（二次負荷分散装置６００）からの経路負荷計測結果を集計するためのスレッドである。
【０１０９】
つぎに、図１１を参照して、図２に示した一次負荷分散装置（セカンダリ）４２０の構成について説明する。この図において、図２の各部に対応する部分には同一の符号を付ける。一次負荷分散装置（セカンダリ）４２０は、装置各部を制御する制御部４２１、記憶部４２２、外部装置（クライアント側ＤＮＳサーバ１１０、一次負荷分散装置（プライマリ）４１０）との間で通信を行う通信部４２３から構成されている。
【０１１０】
記憶部４２２には、ＤＮＳ振分テーブルＴ1’、ＬＢＣ運転状態テーブルＴ3’、ポリシー情報テーブルＴ6’およびＤＮＳアクセスログＬ’が記憶されている。これらのＤＮＳ振分テーブルＴ1’、ＬＢＣ運転状態テーブルＴ3’、ポリシー情報テーブルＴ6’およびＤＮＳアクセスログＬ’は、図３に示したＤＮＳ振分テーブルＴ1 、ＬＢＣ運転状態テーブルＴ3 、ポリシー情報テーブルＴ6 およびＤＮＳアクセスログＬに対応している。
【０１１１】
また、一次負荷分散装置（セカンダリ）４２０において、ＤＮＳ応答スレッドＳ10は、クライアント側ＤＮＳサーバ１１０からのＤＮＳ問合せに対するＤＮＳ応答に関する処理を行うためのスレッドである。ＤＮＳ振分テーブル配布スレッドＳ11は、一次負荷分散装置（プライマリ）４１０からのＤＮＳ振分テーブルＴ1 の配布を受けるためのスレッドである。
【０１１２】
ＤＮＳアクセスログ同期スレッドＳ12は、一次負荷分散装置（セカンダリ）４２０におけるＤＮＳアクセスログＬ’と、一次負荷分散装置（プライマリ）４１０におけるＤＮＳアクセスログＬとの同期をとる処理を行うためのスレッドである。広域負荷分散管理スレッドＳ13は、一次負荷分散装置（プライマリ）４１０の制御により、広域負荷分散に関する管理を行うためのスレッドである。ＬＢＣ運転監視スレッドＳ14は、一次負荷分散装置（プライマリ）４１０の運転監視を行うためのスレッドである。
【０１１３】
なお、一次負荷分散装置（バックアップ）４３０の基本的な構成およびスレッドは、上述した一次負荷分散装置（セカンダリ）４２０と同様である。すなわち、一次負荷分散装置（バックアップ）４３０は、制御部４３１、記憶部４３２および通信部４３３を備えている。
【０１１４】
（運転監視動作）
つぎに、図１２を参照して一実施の形態における運転監視動作について説明する。同図において、一次負荷分散装置（プライマリ）４１０が起動されると、ＬＤ運転監視スレッドＳ5 およびＬＢＣ運転監視スレッドＳ6 （図３参照）が実行される。これにより、一次負荷分散装置（プライマリ）４１０は、二次負荷分散装置５００、二次負荷分散装置６００、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０へ運転監視メッセージ（ステップＳＥ１〜ステップＳＥ４）をそれぞれ一定時間間隔で送信する。
【０１１５】
そして、二次負荷分散装置５００および二次負荷分散装置６００により上記運転監視メッセージが受信されると、二次負荷分散装置５００および二次負荷分散装置６００は、送信元の一次負荷分散装置（プライマリ）４１０へ運転応答メッセージをそれぞれ送信する。
【０１１６】
また、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０により運転監視メッセージが受信されると、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０は、ＬＢＣ運転監視スレッドＳ14（図１１参照）を実行することにより、運転監視応答メッセージを送信元の一次負荷分散装置（プライマリ）４１０へ送信する。
【０１１７】
そして、一次負荷分散装置（プライマリ）４１０は、運転監視メッセージを送信してから一定時間待機し、この間に運転応答メッセージが受信された場合、送信先の装置が正常に運転しているものと判断する。一方、一定時間内に運転応答メッセージが受信されない場合には、当該装置に対して運転監視メッセージを再送する。以後、再送動作を一定回数（デフォルト３回）繰り返し、それでもなお、当該装置からの運転監視メッセージが受信されない場合、一次負荷分散装置（プライマリ）４１０は、当該装置の運転が停止しているものと判断する。この運転停止の要因の一つとしては、前述した災害の発生が挙げられる。
【０１１８】
ここで、二次負荷分散装置５００（または二次負荷分散装置６００）が運転停止（被災）しているものと判断した場合、一次負荷分散装置（プライマリ）４１０は、図５に示したサイト運転状態テーブルＴ2 における［運転状態フラグ］を０（＝運転停止）とする。
【０１１９】
さらに、一次負荷分散装置（プライマリ）４１０は、図４に示したＤＮＳ振分テーブルＴ1 のＬＤ情報テーブルＴc における［ＬＤ動作状態コード］を０ｘ０００２（＝停止）とするとともに、図３に示したサイト連携振分テーブルＴ7 における二次負荷分散装置５００（または二次負荷分散装置６００）の運転状態を停止とする。これにより、二次負荷分散装置５００（または二次負荷分散装置６００）は、一次振り分け対象から除外される。
【０１２０】
また、一次負荷分散装置（プライマリ）４１０は、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０へ、二次負荷分散装置５００（または二次負荷分散装置６００）が運転停止した旨を通知する。これにより、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０のそれぞれは、ＤＮＳ振分テーブルＴ1’（図１１参照）を更新し、二次負荷分散装置５００（または二次負荷分散装置６００）を一次振り分け対象から除外する。
【０１２１】
また、一次負荷分散装置（バックアップ）４３０（または一次負荷分散装置（セカンダリ）４２０）が運転停止（被災）しているものと判断した場合、一次負荷分散装置（プライマリ）４１０は、図６に示したＬＢＣ運転状態テーブルＴ3 における［運転状態フラグ］を０（＝運転停止）とする。
【０１２２】
以後、一次負荷分散装置（プライマリ）４１０は、運転停止していると判断された装置（たとえば、二次負荷分散装置５００、一次負荷分散装置（セカンダリ）４２０等）に対して、運転監視メッセージを一定時間間隔をおいて送信する。ただし、この場合、運転監視メッセージの再送は行われない。そして、運転停止していると判断された当該装置から運転監視応答メッセージを受信すると、一次負荷分散装置（プライマリ）４１０は、当該装置に対してプライマリアナウンスを送信する。そして、このプライマリアナウンスを受信すると、当該装置は、プライマリ了承メッセージを一次負荷分散装置（プライマリ）４１０へ送信する。
【０１２３】
このプライマリ了承メッセージが一次負荷分散装置（プライマリ）４１０に受信されると、一次負荷分散装置（プライマリ）４１０は、当該装置に関するＤＮＳ振分テーブルＴ1 、サイト運転状態テーブルＴ2 （またはＬＢＣ運転状態テーブルＴ3 ）を運転中の状態に更新する。なお、一次負荷分散装置（セカンダリ）４２０が運転停止（被災）している場合、一次負荷分散装置（プライマリ）４１０は、ＬＢＣ運転状態テーブルＴ3 （図６参照）の［セカンダリフラグ］に一次負荷分散装置（バックアップ）４３０を設定することで、一次負荷分散装置（セカンダリ）４２０に代えて一次負荷分散装置（バックアップ）４３０をセカンダリとする。
【０１２４】
また、一次負荷分散装置（プライマリ）４１０または一次負荷分散装置（プライマリ）４１０のリンクが被災することにより、一次負荷分散装置（プライマリ）４１０からの運転監視メッセージが所定時間（＝前回の運転監視時間＋運転監視時間＋待機時間）が経過しても一次負荷分散装置（セカンダリ）４２０に受信されない場合、一次負荷分散装置（セカンダリ）４２０は、つぎの動作を行う。ここで、上記待機時間は、一次負荷分散装置（セカンダリ）４２０がセカンダリからプライマリに自動的に昇格するのに要する時間である。
【０１２５】
この場合、一次負荷分散装置（セカンダリ）４２０は、一次負荷分散装置（プライマリ）４１０が消失したものと判断し、一次負荷分散装置（バックアップ）４３０、二次負荷分散装置５００および二次負荷分散装置６００へ、プライマリアナウンスを送信する。
【０１２６】
そして、一次負荷分散装置（バックアップ）４３０、二次負荷分散装置５００および二次負荷分散装置６００は、上記プライマリアナウンスを受信すると、プライマリ了承メッセージを一次負荷分散装置（セカンダリ）４２０へ送信する。このプライマリ了承メッセージを受信すると、一次負荷分散装置（セカンダリ）４２０は、一次負荷分散装置（プライマリ）４１０に代わって、プライマリとして機能する。以後、一次負荷分散装置（セカンダリ）４２０は、一次負荷分散装置（プライマリ）４１０と同様の動作を行う。
【０１２７】
なお、一次負荷分散装置（プライマリ）４１０と同時に一次負荷分散装置（セカンダリ）４２０も被災により運転停止した場合には、一次負荷分散装置（セカンダリ）４２０からは、プライマリアナウンスが送信されない。したがって、この場合、上述した所定時間を経過しても一次負荷分散装置（バックアップ）４３０には、上記プライマリアナウンスが受信されない。これにより、一次負荷分散装置（バックアップ）４３０は、プライマリ探索を行う。この場合には、上位の一次負荷分散装置または最初にプライマリ探索を行った一次負荷分散装置がプライマリとなる。
【０１２８】
そして、一次負荷分散装置（プライマリ）４１０が復旧し運転を再開すると、一次負荷分散装置（プライマリ）４１０は、一次負荷分散装置４２０、一次負荷分散装置（バックアップ）４３０、二次負荷分散装置５００および二次負荷分散装置６００へ自身が本来のプライマリであることを示すプライマリアナウンスを送信する。
【０１２９】
そして、現時点のプライマリである一次負荷分散装置４２０が上記プライマリアナウンスを受信すると、一次負荷分散装置４２０は、一次負荷分散装置（プライマリ）４１０が本来のプライマリであることを確認した後、負荷分散の管理下にある二次負荷分散装置５００、二次負荷分散装置６００および一次負荷分散装置（バックアップ）４３０に対して負荷分散を終了するための負荷分散終了メッセージを送信する。
【０１３０】
これにより、二次負荷分散装置５００、二次負荷分散装置６００および一次負荷分散装置（バックアップ）４３０は、一次負荷分散装置４２０をプライマリとする負荷分散の参加を取り消すための参加取り消しメッセージを送信する。
【０１３１】
つぎに、一次負荷分散装置４２０は、プライマリアナウンスの送信元（一次負荷分散装置（プライマリ）４１０）をプライマリとした負荷分散に参加を要請するための参加要請メッセージを、一次負荷分散装置（バックアップ）４３０、二次負荷分散装置５００および二次負荷分散装置６００へ送信する。そして、一次負荷分散装置（セカンダリ）４２０、一次負荷分散装置（バックアップ）４３０、二次負荷分散装置５００および二次負荷分散装置６００のそれぞれは、一次負荷分散装置（プライマリ）４１０をプライマリとする負荷分散に参加するための参加メッセージを一次負荷分散装置（プライマリ）４１０へ送信する。これにより、災害発生前の状態に自動復旧する。
【０１３２】
また、災害発生等により、一次負荷分散装置（プライマリ）４１０からの運転監視メッセージが所定時間（＝前回の運転監視時間＋運転監視時間＋待機時間）が経過しても一次負荷分散装置（バックアップ）４３０に受信されない場合、一次負荷分散装置（バックアップ）４３０は、つぎの動作を行う。すなわち、この場合、一次負荷分散装置（バックアップ）４３０は、一次負荷分散装置（プライマリ）４１０が消失したものと判断し、待機時間内に一次負荷分散装置（セカンダリ）４２０からのプライマリアナウンスを受信したか否かを判断する。
【０１３３】
この待機時間内にプライマリアナウンスを受信した場合、一次負荷分散装置（バックアップ）４３０は、上述したプライマリ了承メッセージを一次負荷分散装置（セカンダリ）４２０へ送信する。一方、待機時間内にプライマリアナウンスを受信しない場合、一次負荷分散装置（バックアップ）４３０は、プライマリとなる一次負荷分散装置を探索する。
【０１３４】
また、災害発生等により、一次負荷分散装置（プライマリ）４１０からの運転監視メッセージが所定時間（＝前回の運転監視時間＋運転監視時間＋待機時間）が経過しても二次負荷分散装置５００（二次負荷分散装置６００）に受信されない場合、二次負荷分散装置５００（二次負荷分散装置６００）は、つぎの動作を行う。すなわち、この場合、二次負荷分散装置５００（二次負荷分散装置６００）は、一次負荷分散装置（プライマリ）４１０が消失したものと判断し、待機時間内に一次負荷分散装置（セカンダリ）４２０からのプライマリアナウンスを受信したか否かを判断する。
【０１３５】
この待機時間内にプライマリアナウンスを受信した場合、二次負荷分散装置５００（二次負荷分散装置６００）は、上述したプライマリ了承メッセージを一次負荷分散装置（セカンダリ）４２０へ送信する。一方、待機時間内にプライマリアナウンスを受信しない場合、二次負荷分散装置５００（二次負荷分散装置６００）は、プライマリとなる一次負荷分散装置を探索する。
【０１３６】
（負荷情報収集動作）
つぎに、図１３を参照して一実施の形態における負荷情報収集動作について説明する。同図において、一次負荷分散装置（プライマリ）４１０が起動されると、広域負荷分散管理スレッドＳ4 （図３参照）が実行される。これにより、一次負荷分散装置（プライマリ）４１０は、二次負荷分散装置５００（二次負荷分散装置６００）へ負荷状態の計測を依頼する（ステップＳＦ１およびステップＳＦ２）。
【０１３７】
これにより、二次負荷分散装置５００は、サーバ５１０およびサーバ５２０の負荷状態（高負荷、通常負荷）をＩＰパケットの通過量や計測エージェントにより計測する。同様にして、二次負荷分散装置６００は、サーバ６１０およびサーバ６２０の負荷状態を計測する。そして、二次負荷分散装置５００および二次負荷分散装置６００は、負荷状態をサイト負荷情報として一次負荷分散装置（プライマリ）４１０へ送信する。このサイト負荷情報を受信すると、一次負荷分散装置（プライマリ）４１０は、サイト負荷状態テーブルＴ4（図７参照)を更新する。以後、一定時間間隔をおいて、負荷情報収集動作が実行される。
【０１３８】
（ＤＮＳアクセスログ収集動作）
つぎに、図１４を参照して一実施の形態におけるＤＮＳアクセスログ収集動作について説明する。同図において、ステップＳＧ１でクライアント側ＤＮＳサーバ１１０から一次負荷分散装置（セカンダリ）４２０に対してＤＮＳ問合せがあると、一次負荷分散装置（セカンダリ）４２０は、ＤＮＳアクセスログＬ’（図１１参照）を更新する。同様にして、ステップＳＧ３でクライアント側ＤＮＳサーバ１１０から一次負荷分散装置（バックアップ）４３０に対してＤＮＳ問合せがあると、一次負荷分散装置（バックアップ）４３０は、ＤＮＳアクセスログＬ’（図１１参照）を更新する。
【０１３９】
そして、ステップＳＧ２では、一次負荷分散装置（セカンダリ）４２０は、一定時間間隔毎にＤＮＳアクセスログ同期スレッドＳ12（図１１参照）を実行する。すなわち、一次負荷分散装置（セカンダリ）４２０は、ＤＮＳアクセスログＬ’を一次負荷分散装置（プライマリ）４１０へ送信する。同様にして、ステップＳＧ４では、一次負荷分散装置（バックアップ）４３０は、一定時間間隔毎にＤＮＳアクセスログ同期スレッドＳ12（図１１参照）を実行する。すなわち、一次負荷分散装置（バックアップ）４３０は、ＤＮＳアクセスログＬ’を一次負荷分散装置（プライマリ）４１０へ送信する。
【０１４０】
そして、上記ＤＮＳアクセスログＬ’を受信すると、一次負荷分散装置（プライマリ）４１０は、ＤＮＳアクセスログ同期スレッドＳ3 を実行し、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０からのＤＮＳアクセスログＬ’を集計し、集計結果をＤＮＳアクセスログＬ（図１０参照）に反映させる。
【０１４１】
（経路負荷情報収集動作）
つぎに、図１５を参照して一実施の形態における経路負荷情報収集動作について説明する。同図において、一次負荷分散装置（プライマリ）４１０は、経路負荷計測依頼スレッドＳ8 を実行する。すなわち、一次負荷分散装置（プライマリ）４１０は、ＤＮＳアクセスログＬを参照することで、最近アクセスがあり、かつ経路負荷計測が実施されていない、たとえば、クライアント側ＤＮＳサーバ１１０を選択する。
【０１４２】
つぎに、ステップＳＨ１では、一次負荷分散装置（プライマリ）４１０は、二次負荷分散装置５００に対して経路負荷計測を依頼する。これにより、ステップＳＨ２では、二次負荷分散装置５００は、クライアント側ＤＮＳサーバ１１０との間の通信経路におけるラウンドトリップタイム、最大セグメントサイズおよび平均輻輳ウインドウサイズ等に基づいて、上記通信経路における実効帯域幅を求める。
【０１４３】
具体的には、二次負荷分散装置５００は、ＳＹＮ（SYNchronous idle character）パケットをクライアント側ＤＮＳサーバ１１０に対して送信した後、クライアント側ＤＮＳサーバ１１０から送信される返信用のＡＣＫ（ACKnowledge character）パケットを受信する。これにより、二次負荷分散装置５００は、ＡＣＫパケットの受信時刻とＳＹＮパケットの送信時刻との差をラウンドトリップタイムとして求める。
【０１４４】
つぎに、二次負荷分散装置５００は、最大セグメントサイズ（単位：バイト）をつぎのようにして求める。ＴＣＰ通信では、通信経路上のルータの最大送信単位（ＭＴＵ）に基づいてパケットのサイズが決められている。ここで、中継用のルータが通信経路上に複数あるときは、最大通信単位の最小値がＴＣＰ通信の最大セグメントサイズとなる。したがって、二次負荷分散装置５００は、クライアント側ＤＮＳサーバ１１０との間の通信経路上にルータのＭＴＵを検出した後、最小値のＭＴＵを最大セグメントサイズとして求める。
【０１４５】
続いて、二次負荷分散装置５００は、平均輻輳ウインドウサイズ（単位：パケット）をつぎのようにして求める。ＴＣＰ通信では、パケットをスライディングウィンドウ方式により出力制限しながら送出している。すなわち、二次負荷分散装置５００は、ウインドウサイズという単位で一度に送出するパケット数を制限しながら、クライアント側ＤＮＳサーバ１１０に対してパケットを送出した後、クライアント側ＤＮＳサーバ１１０からの受信確認パケットによりウインドウサイズ分のパケットが転送されたことを確認する。
【０１４６】
また、二次負荷分散装置５００は、上記ウインドウサイズを送信または受信されたパケットのログ情報に基づいて、一つのウインドウサイクル内で送出されたパケットの数を調べることにより、上述したウィンドウサイズを得る。また、二次負荷分散装置５００は、クライアント側ＤＮＳサーバ１１０からの受信確認パケットが所定時間内に到着しない場合、通信経路（ネットワーク）が輻輳しているものと判断し、ウインドウサイズを調整する。このウインドウサイズの調整は、輻輳回避アルゴリズムによって行われる。
【０１４７】
すなわち、受信確認パケットが所定時間内に到着しない場合、言い換えれば、パケット廃棄が起こった場合、二次負荷分散装置５００は、ウインドウサイズを半分に減らし、その後に再び、パケット廃棄が起こるまで一つづつウインドウサイズを増やしていく。そして、パケット廃棄が再び発生すると、再びウインドウサイズを半分に減らして同じことを繰り返す。二次負荷分散装置５００は、上述した輻輳回避アルゴリズムが実行されている間のウインドウサイズの平均値を平均輻輳ウインドウサイズとして求める。
【０１４８】
つぎに、二次負荷分散装置５００は、上述したラウンドトリップタイム、最大セグメントサイズおよび平均輻輳ウインドウサイズに基づいて、クライアント側ＤＮＳサーバ１１０との間の通信経路における実効帯域幅（転送速度）を求める。具体的には、二次負荷分散装置５００は、実効帯域幅をＢＷ（バイト／秒）、ラウンドトリップタイムをＲＴＴ（ｍｓｅｃ）、最大セグメントサイズをＭＳＳ（バイト）および平均輻輳ウインドウサイズをＷ（パケット）としたつぎの（１）式に各値を代入することにより、実効帯域幅を求める。
ＢＷ＝Ｗ×ＭＳＳ／ＲＴＴ ・・・（１）
【０１４９】
同様にして、ステップＳＨ３では、一次負荷分散装置（プライマリ）４１０は、二次負荷分散装置６００に対して経路負荷計測を依頼する。これにより、ステップＳＨ４では、二次負荷分散装置６００は、二次負荷分散装置５００と同様にして、クライアント側ＤＮＳサーバ１１０との間の通信経路における実効帯域幅を求める。
【０１５０】
そして、二次負荷分散装置５００および二次負荷分散装置６００は、それぞれの実効帯域幅を経路負荷計測結果として一次負荷分散装置（プライマリ）４１０へ送信する。これにより、経路負荷計測結果集計スレッドＳ9 が実行され、一次負荷分散装置（プライマリ）４１０は、経路負荷計測結果を集計し、この集計結果に基づいて経路負荷計測テーブルＴ5 （図８参照）を更新する。
【０１５１】
（アクセス動作）
つぎに、図１６および図１７を参照して一実施の形態におけるアクセス動作について説明する。図１６において、ステップＳＩ１では、クライアント１００は、クライアント側ＤＮＳサーバ１１０に対して代表ドメイン名に基づくＤＮＳ問合せを行う。これにより、クライアント側ＤＮＳサーバ１１０は、自身のキャッシュメモリに回答すべき二次負荷分散装置５００または二次負荷分散装置６００のＩＰアドレスが保存されているか否かを判断し、保存されている場合、ステップＳＩ４で上記ＩＰアドレスをクライアント１００へ回答する。
【０１５２】
一方、キャッシュメモリに回答すべきＩＰアドレスが保存されていない場合、ステップＳＩ２では、クライアント側ＤＮＳサーバ１１０は、問い合わせがあったＤＮＳに関する権限を有するサーバ側ＤＮＳサーバ（プライマリ）３１０に対してＤＮＳ問合せを行う。これにより、サーバ側ＤＮＳサーバ（プライマリ）３１０は、登録されている一次負荷分散装置（プライマリ）４１０、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０のそれぞれのＩＰアドレスをクライアント側ＤＮＳサーバ１１０に返答する。
【０１５３】
ステップＳＩ３では、クライアント側ＤＮＳサーバ１１０は、受信した都合三つのＩＰアドレスのうち、たとえば、一次負荷分散装置（プライマリ）４１０のＩＰアドレスを用いて、一次負荷分散装置（プライマリ）４１０にアクセスする。すなわち、クライアント側ＤＮＳサーバ１１０は、一次負荷分散装置（プライマリ）４１０に対してＤＮＳ問合せを行う。
【０１５４】
これにより、一次負荷分散装置（プライマリ）４１０は、ＤＮＳ振分テーブルＴ1 を参照することで、全体の負荷が分散されるようなサイト、すなわち二次負荷分散装置のＩＰアドレスをクライアント側ＤＮＳサーバ１１０へ回答する。この場合、二次負荷分散装置６００のＩＰアドレスが回答されたものとする。そして、ステップＳＩ４では、クライアント側ＤＮＳサーバ１１０は、上記ＩＰアドレスをクライアント１００へ回答する。
【０１５５】
これにより、図１７に示したステップＳＪ１では、クライアント１００は、上記ＩＰアドレスに基づいて二次負荷分散装置６００にアクセスする。これにより、ステップＳＪ２では、二次負荷分散装置６００は、クライアント１００からのＩＰパケット（サービス要求）を、ＮＡＴ方式やＭＡＣ方式により、たとえば、サーバ６２０へ振り分ける。そして、ステップＳＪ３では、サーバ６２０は、サービスを提供するための返信パケットを二次負荷分散装置６００を介して、または直接クライアント１００へ送信する。これにより、サーバ６２０からクライアント１００へサービスが提供される。
【０１５６】
以上説明したように、一実施の形態によれば、プライマリの一次負荷分散装置４１０を設定し、この一次負荷分散装置（プライマリ）４１０により、他の一次負荷分散装置（セカンダリ）４２０、一次負荷分散装置（バックアップ）４３０、二次負荷分散装置５００および二次負荷分散装置６００の運転状態を監視し、運転停止した装置がある場合、当該装置を負荷分散を行う装置から除外するようにしたので、災害発生によるサービス停止を回避することができる。
【０１５７】
また、一実施の形態によれば、あらかじめセカンダリの一次負荷分散装置４２０を設定するようにしたので、一次負荷分散装置（プライマリ）４１０が運転停止した時点で即座に一次負荷分散装置（セカンダリ）４２０をプライマリとして機能させることができるため、プライマリが不在という致命的な事態を回避することができる。
【０１５８】
また、一実施の形態によれば、運転停止した一次負荷分散装置（プライマリ）４１０が運転を再開すると、現時点でのプライマリである一次負荷分散装置４２０が一次負荷分散装置（プライマリ）４１０に自動的に切り替わる。したがって、一実施の形態によれば、運転停止した一次負荷分散装置（プライマリ）４１０の運転状態を相互監視により監視するようにしたので、一次負荷分散装置（プライマリ）４１０が復旧した時点で即座に現時点でのプライマリとしての一次負荷分散装置（セカンダリ）４２０を本来の一次負荷分散装置（プライマリ）４１０に切り換えることができる。
【０１５９】
また、一実施の形態によれば、一次負荷分散装置（プライマリ）４１０、一次負荷分散装置（セカンダリ）４２０、一次負荷分散装置（バックアップ）４３０、二次負荷分散装置５００および二次負荷分散装置６００のそれぞれを広域にわたって地理的に分散配置するようにしたので、局部的に発生する災害（地震等）が発生した場合であっても、最小限の被災にとどめることができるため、災害発生によるサービス停止をさらに効果的に回避することができる。
【０１６０】
また、一実施の形態によれば、一次負荷分散装置（プライマリ）４１０により作成／更新されたＤＮＳ振分テーブルＴ1 をその他の一次負荷分散装置（セカンダリ）４２０、一次負荷分散装置（バックアップ）４３０へ配布するようにしたので、すべての一次負荷分散装置（プライマリ）４１０、一次負荷分散装置（セカンダリ）４２０および一次負荷分散装置（バックアップ）４３０で同一の基準で一次振り分けが行われるため、更新漏れによるトラブルを防止することができる。
【０１６１】
さらに、一実施の形態によれば、サーバ５１０、サーバ５２０、サーバ６１０およびサーバ６２０における実際の負荷を測定した結果が反映されたＤＮＳ振分テーブルＴ1 に基づいて、一次振り分けが行われるため、実際の負荷に応じた負荷分散を行うことができる。
【０１６２】
加えて、一実施の形態によれば、経路負荷が反映されたＤＮＳ振分テーブルＴ1 に基づいて、一次振り分けが行われるため、通信経路の状態に即した最適な負荷分散を行うことができる。
【０１６３】
【発明の効果】
以上説明したように、請求項１にかかる発明によれば、災害発生によるサービス停止を回避することができ、さらに、二次負荷分散手段間の協調によっても負荷分散を実現可能な２段階方式の負荷分散システムを得ることができるという効果を奏する。
【０１６４】
また、請求項２にかかる発明によれば、一次振り分けの結果は、ＤＮＳ問合せのキャッシュとして問合せ元に一定期間記憶され、キャッシュを保持している問合せ元では、このキャッシュに基づいて一次振り分けが行われることになるため、一次負荷分散手段の負荷が軽減されるという効果を奏する。
【０１６５】
また、請求項３にかかる発明によれば、サービス要求の送信元との間の経路負荷が最も少ないことが期待される二次負荷分散手段がサービス要求の振り分け先として選択されるので、ネットワークに負荷をかけることなく負荷分散を実現することができるという効果を奏する。
【図面の簡単な説明】
【図１】本発明にかかる負荷分散システムの一実施の形態の概略構成を示す図である。
【図２】同一実施の形態の構成を示す図である。
【図３】図２に示した一次負荷分散装置４１０（プライマリ）の構成を示すブロック図である。
【図４】図３に示したＤＮＳ振分テーブルＴ1 の一例を示す図である。
【図５】図３に示したサイト運転状態テーブルＴ2 の一例を示す図である。
【図６】図３に示したＬＢＣ運転状態テーブルＴ3 の一例を示す図である。
【図７】図３に示したサイト負荷状態テーブルＴ4 の一例を示す図である。
【図８】図３に示した経路負荷計測テーブルＴ5 の一例を示す図である。
【図９】図３に示したポリシー情報テーブルＴ6 の一例を示す図である。
【図１０】図３に示したＤＮＳアクセスログＬの一例を示す図である。
【図１１】図２に示した一次負荷分散装置４２０（セカンダリ）および一次負荷分散装置４３０（バックアップ）の構成を示すブロック図である。
【図１２】同一実施の形態における運転監視動作を説明する図である。
【図１３】同一実施の形態におけるサイト負荷情報収集動作を説明する図である。
【図１４】同一実施の形態におけるＤＮＳアクセスログ収集動作を説明する図である。
【図１５】同一実施の形態における経路負荷情報収集動作を説明する図である。
【図１６】同一実施の形態におけるアクセス動作を説明する図である。
【図１７】同一実施の形態におけるアクセス動作を説明する図である。
【図１８】従来のネットワークシステムの構成例１を示す図である。
【図１９】従来のネットワークシステムの構成例１における災害発生時の動作を説明する図である。
【図２０】従来のネットワークシステムの構成例２を示す図である。
【図２１】従来のネットワークシステムの構成例２における災害発生時の動作を説明する図である。
【符号の説明】
１００ クライアント
２００ クライアント
４００ 一次負荷分散装置群
４１０ 一次負荷分散装置
４２０ 一次負荷分散装置
４３０ 一次負荷分散装置
５００ 二次負荷分散装置
５１０ サーバ
５２０ サーバ
６００ 二次負荷分散装置
６１０ サーバ
６２０ サーバ
Claims (3)
- サービスの提供を求めるクライアントの要求を、前記サービスを提供するサーバを含むサイトのいずれか１つに振り分けさせる一次負荷分散手段と、自身が属するサイトに前記要求が振り分けられた場合に、該サイトに属するサーバのいずれか１つに該要求を振り分ける二次負荷分散手段とを備える負荷分散システムであって、
前記一次負荷分散手段は、前記二次負荷分散手段の運転状態を監視し、運転停止していない二次負荷分散手段を含むサイトのいずれか１つに前記要求を振り分けさせるとともに、監視結果を各二次負荷分散手段に配布し、
前記二次負荷分散手段は、自身が属するサイトに含まれるサーバの負荷が所定よりも高い場合に、前記一次負荷分散手段によって予め配布された前記監視結果に基づいて運転停止していない他の二次負荷分散手段を選択し、自身が属するサイトへ振り分けられた前記要求を前記他の二次負荷分散手段へ転送することを特徴とする負荷分散システム。 - 前記一次負荷分散手段は、サービスを提供するサーバにアクセスするためのドメイン名の解決を求めるＤＮＳ問合せに対して、前記二次負荷分散手段のいずれか１つのＩＰアドレスを応答することにより、該ＩＰアドレスを有する二次負荷分散手段を含むサイトへ前記要求を振り分けさせ、
前記二次負荷分散手段は、自身が属するサイトに属するサーバのいずれか１つに前記要求を振り分ける場合に、自身が有するＩＰアドレスを宛先として前記クライアントから送信された前記要求のヘッダ部を書き換えることにより、前記サービスを提供するサーバに該要求を振り分けることを特徴とする請求項１に記載の負荷分散システム。 - 前記一次負荷分散手段は、各二次負荷分散手段に対して、前記ＤＮＳ問合せの送信元と当該の二次負荷分散手段との間の通信経路の経路負荷の計測を依頼し、計測された経路負荷に係る情報に基づいて、サービスを提供するサーバにアクセスするためのドメイン名の解決を求めるＤＮＳ問合せを受信した場合に、該ＤＮＳ問合せの送信元との間の経路負荷が最も少ない二次負荷分散手段のＩＰアドレスを応答することを特徴とする請求項２に記載の負荷分散システム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP29290699A JP4001698B2 (ja) | 1999-10-14 | 1999-10-14 | 負荷分散システム |
| US09/628,353 US6725253B1 (en) | 1999-10-14 | 2000-07-28 | Load balancing system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP29290699A JP4001698B2 (ja) | 1999-10-14 | 1999-10-14 | 負荷分散システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001117897A JP2001117897A (ja) | 2001-04-27 |
| JP4001698B2 true JP4001698B2 (ja) | 2007-10-31 |
Family
ID=17787939
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP29290699A Expired - Fee Related JP4001698B2 (ja) | 1999-10-14 | 1999-10-14 | 負荷分散システム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6725253B1 (ja) |
| JP (1) | JP4001698B2 (ja) |
Families Citing this family (112)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100719745B1 (ko) * | 1999-11-12 | 2007-05-17 | 주식회사 케이티 | 인터넷 전자상거래 서비스 시스템에서의 입점 신청 상점 관리 장치 및 그 방법 |
| US7251688B2 (en) * | 2000-05-26 | 2007-07-31 | Akamai Technologies, Inc. | Method for generating a network map |
| US7500243B2 (en) * | 2000-08-17 | 2009-03-03 | Sun Microsystems, Inc. | Load balancing method and system using multiple load balancing servers |
| US7277933B2 (en) * | 2000-08-28 | 2007-10-02 | Fujitsu Limited | System for operating a plurality of apparatuses based on accumulated operating times thereof to equalize the respective operating times of the apparatuses |
| US6871210B1 (en) * | 2000-09-05 | 2005-03-22 | International Business Machines Corporation | Automatic allocation of least loaded boot server to PXE client on a network VIA DHCP server |
| US7454500B1 (en) * | 2000-09-26 | 2008-11-18 | Foundry Networks, Inc. | Global server load balancing |
| US9130954B2 (en) * | 2000-09-26 | 2015-09-08 | Brocade Communications Systems, Inc. | Distributed health check for global server load balancing |
| US7657629B1 (en) | 2000-09-26 | 2010-02-02 | Foundry Networks, Inc. | Global server load balancing |
| JP3885865B2 (ja) * | 2000-10-16 | 2007-02-28 | 日本電気株式会社 | データ配信システム及びデータ配信方法 |
| US7606898B1 (en) | 2000-10-24 | 2009-10-20 | Microsoft Corporation | System and method for distributed management of shared computers |
| JP3885483B2 (ja) * | 2000-10-30 | 2007-02-21 | 富士通株式会社 | サービス実行方法および装置 |
| US7219346B2 (en) * | 2000-12-05 | 2007-05-15 | Microsoft Corporation | System and method for implementing a client side HTTP stack |
| US7418522B2 (en) * | 2000-12-21 | 2008-08-26 | Noatak Software Llc | Method and system for communicating an information packet through multiple networks |
| US7287090B1 (en) * | 2000-12-21 | 2007-10-23 | Noatak Software, Llc | Method and system for identifying a computing device in response to a request packet |
| US20020116397A1 (en) | 2000-12-21 | 2002-08-22 | Berg Mitchell T. | Method and system for communicating an information packet through multiple router devices |
| US20020087722A1 (en) * | 2000-12-29 | 2002-07-04 | Ragula Systems D/B/A/ Fatpipe Networks | Domain name resolution making IP address selections in response to connection status when multiple connections are present |
| US6871347B2 (en) * | 2001-04-13 | 2005-03-22 | Interland, Inc. | Method and apparatus for facilitating load balancing across name servers |
| US8135834B1 (en) * | 2001-06-18 | 2012-03-13 | Packet Design, Inc. | Method and system for causing intra-AS network traffic to be more evenly balanced |
| US20030009559A1 (en) * | 2001-07-09 | 2003-01-09 | Naoya Ikeda | Network system and method of distributing accesses to a plurality of server apparatus in the network system |
| JP2003131961A (ja) * | 2001-07-09 | 2003-05-09 | Hitachi Ltd | ネットワークシステム及び負荷分散方法 |
| JP3564435B2 (ja) * | 2001-07-18 | 2004-09-08 | 株式会社エヌ・ティ・ティ・データ | アクセス誘導装置及び方法 |
| US20030028640A1 (en) * | 2001-07-30 | 2003-02-06 | Vishal Malik | Peer-to-peer distributed mechanism |
| JP3901982B2 (ja) * | 2001-10-18 | 2007-04-04 | 富士通株式会社 | ネットワークプロセッサの負荷分散装置 |
| US20030079016A1 (en) * | 2001-10-23 | 2003-04-24 | Sheng (Ted) Tai Tsao | Using NAS appliance to build a non-conventional distributed video server |
| JP3645852B2 (ja) * | 2001-11-19 | 2005-05-11 | Ｎｅｃアクセステクニカ株式会社 | 負荷分散方法、コンテンツ配信システム及び負荷分散装置 |
| US7082122B2 (en) * | 2001-12-24 | 2006-07-25 | Innomedia Pte Ltd. | Method and system for connecting to a proxy server with the lowest workload through a load balancing proxy server |
| US7050424B2 (en) * | 2001-12-31 | 2006-05-23 | Innomedia Pte Ltd. | Method and system for automatic proxy server workload shifting for load balancing |
| US7085829B2 (en) * | 2001-12-31 | 2006-08-01 | Innomedia, Pte Ltd. | Method and system for an intelligent proxy server for workload balancing by workload shifting |
| US7284067B2 (en) * | 2002-02-20 | 2007-10-16 | Hewlett-Packard Development Company, L.P. | Method for integrated load balancing among peer servers |
| US7181527B2 (en) * | 2002-03-29 | 2007-02-20 | Intel Corporation | Method for transmitting load balancing in mixed speed environments |
| ATE438243T1 (de) * | 2002-06-28 | 2009-08-15 | Nokia Corp | Lastausgleicheinrichtung und verfahren dafür |
| KR100497230B1 (ko) * | 2002-07-23 | 2005-06-23 | 삼성에스디아이 주식회사 | 플라즈마 디스플레이 패널의 구동 장치 및 구동 방법 |
| US7676576B1 (en) | 2002-08-01 | 2010-03-09 | Foundry Networks, Inc. | Method and system to clear counters used for statistical tracking for global server load balancing |
| US7086061B1 (en) | 2002-08-01 | 2006-08-01 | Foundry Networks, Inc. | Statistical tracking of global server load balancing for selecting the best network address from ordered list of network addresses based on a set of performance metrics |
| US7574508B1 (en) | 2002-08-07 | 2009-08-11 | Foundry Networks, Inc. | Canonical name (CNAME) handling for global server load balancing |
| US7571206B2 (en) * | 2002-08-12 | 2009-08-04 | Equallogic, Inc. | Transparent request routing for a partitioned application service |
| JP4167876B2 (ja) * | 2002-10-03 | 2008-10-22 | 株式会社日立製作所 | ネットワーク計測設定装置 |
| KR100462886B1 (ko) * | 2002-10-15 | 2004-12-17 | 삼성전자주식회사 | 부하 분담 구조와 프라이머리/백업 구조가 혼합된 시스템 |
| US7647427B1 (en) | 2002-10-18 | 2010-01-12 | Foundry Networks, Inc. | Redundancy support for network address translation (NAT) |
| US20040111513A1 (en) * | 2002-12-04 | 2004-06-10 | Shen Simon S. | Automatic employment of resource load information with one or more policies to automatically determine whether to decrease one or more loads |
| US7627650B2 (en) * | 2003-01-20 | 2009-12-01 | Equallogic, Inc. | Short-cut response for distributed services |
| US7461146B2 (en) * | 2003-01-20 | 2008-12-02 | Equallogic, Inc. | Adaptive storage block data distribution |
| US7937551B2 (en) * | 2003-01-21 | 2011-05-03 | Dell Products L.P. | Storage systems having differentiated storage pools |
| US20040210724A1 (en) * | 2003-01-21 | 2004-10-21 | Equallogic Inc. | Block data migration |
| US8037264B2 (en) | 2003-01-21 | 2011-10-11 | Dell Products, L.P. | Distributed snapshot process |
| US8499086B2 (en) * | 2003-01-21 | 2013-07-30 | Dell Products L.P. | Client load distribution |
| US7254642B2 (en) * | 2003-01-30 | 2007-08-07 | International Business Machines Corporation | Method and apparatus for local IP address translation |
| US7450499B2 (en) * | 2003-02-21 | 2008-11-11 | Samsung Electronics Co., Ltd. | Method and apparatus for interconnecting IPv4 and IPv6 networks |
| US7072807B2 (en) * | 2003-03-06 | 2006-07-04 | Microsoft Corporation | Architecture for distributed computing system and automated design, deployment, and management of distributed applications |
| US8122106B2 (en) | 2003-03-06 | 2012-02-21 | Microsoft Corporation | Integrating design, deployment, and management phases for systems |
| US7689676B2 (en) | 2003-03-06 | 2010-03-30 | Microsoft Corporation | Model-based policy application |
| US7890543B2 (en) | 2003-03-06 | 2011-02-15 | Microsoft Corporation | Architecture for distributed computing system and automated design, deployment, and management of distributed applications |
| WO2004107131A2 (en) | 2003-05-28 | 2004-12-09 | Caymas Systems, Inc. | Policy based network address translation |
| US7567504B2 (en) * | 2003-06-30 | 2009-07-28 | Microsoft Corporation | Network load balancing with traffic routing |
| US7613822B2 (en) * | 2003-06-30 | 2009-11-03 | Microsoft Corporation | Network load balancing with session information |
| US7590736B2 (en) * | 2003-06-30 | 2009-09-15 | Microsoft Corporation | Flexible network load balancing |
| US7454120B2 (en) * | 2003-07-02 | 2008-11-18 | Macrovision Corporation | Methods and apparatus for client aggregation of television programming in a networked personal video recording system |
| US8438601B2 (en) | 2003-07-02 | 2013-05-07 | Rovi Solutions Corporation | Resource management for a networked personal video recording system |
| US7603022B2 (en) * | 2003-07-02 | 2009-10-13 | Macrovision Corporation | Networked personal video recording system |
| US9584360B2 (en) | 2003-09-29 | 2017-02-28 | Foundry Networks, Llc | Global server load balancing support for private VIP addresses |
| US8528015B2 (en) * | 2003-11-06 | 2013-09-03 | Aptiv Digital, Inc. | Resource sharing system of set-top boxes |
| US7751327B2 (en) * | 2004-02-25 | 2010-07-06 | Nec Corporation | Communication processing system, packet processing load balancing device and packet processing load balancing method therefor |
| US7778422B2 (en) | 2004-02-27 | 2010-08-17 | Microsoft Corporation | Security associations for devices |
| US20050246529A1 (en) | 2004-04-30 | 2005-11-03 | Microsoft Corporation | Isolated persistent identity storage for authentication of computing devies |
| US7584301B1 (en) * | 2004-05-06 | 2009-09-01 | Foundry Networks, Inc. | Host-level policies for global server load balancing |
| US7496651B1 (en) * | 2004-05-06 | 2009-02-24 | Foundry Networks, Inc. | Configurable geographic prefixes for global server load balancing |
| US20060020691A1 (en) * | 2004-07-20 | 2006-01-26 | Hewlett-Packard Development Company, L.P. | Load balancing based on front-end utilization |
| US7423977B1 (en) * | 2004-08-23 | 2008-09-09 | Foundry Networks Inc. | Smoothing algorithm for round trip time (RTT) measurements |
| US8024483B1 (en) * | 2004-10-01 | 2011-09-20 | F5 Networks, Inc. | Selective compression for network connections |
| US20060174119A1 (en) * | 2005-02-03 | 2006-08-03 | Xin Xu | Authenticating destinations of sensitive data in web browsing |
| JP4512192B2 (ja) * | 2005-02-09 | 2010-07-28 | 株式会社日立製作所 | 輻輳制御装置、および、ネットワークの輻輳制御方法 |
| US7793305B2 (en) * | 2005-03-14 | 2010-09-07 | At&T Intellectual Property I, L.P. | Methods and systems for providing a communication manager for wireless wireline converged telecommunication services |
| JP4161998B2 (ja) | 2005-03-28 | 2008-10-08 | 日本電気株式会社 | 負荷分散振り分けシステム、イベント処理分散制御装置並びにイベント処理分散制御プログラム |
| US8489728B2 (en) | 2005-04-15 | 2013-07-16 | Microsoft Corporation | Model-based system monitoring |
| US7802144B2 (en) | 2005-04-15 | 2010-09-21 | Microsoft Corporation | Model-based system monitoring |
| US7797147B2 (en) | 2005-04-15 | 2010-09-14 | Microsoft Corporation | Model-based system monitoring |
| US8549513B2 (en) | 2005-06-29 | 2013-10-01 | Microsoft Corporation | Model-based virtual system provisioning |
| US7933987B2 (en) * | 2005-09-30 | 2011-04-26 | Lockheed Martin Corporation | Application of virtual servers to high availability and disaster recovery solutions |
| US7934216B2 (en) * | 2005-10-03 | 2011-04-26 | International Business Machines Corporation | Method and system for load balancing of computing resources |
| US7941309B2 (en) | 2005-11-02 | 2011-05-10 | Microsoft Corporation | Modeling IT operations/policies |
| US8582946B2 (en) * | 2005-11-04 | 2013-11-12 | Rovi Guides, Inc. | Systems and methods for recording programs using a network recording device as supplemental storage |
| WO2007074797A1 (ja) | 2005-12-28 | 2007-07-05 | International Business Machines Corporation | クライアント・サーバ・システムにおける負荷分散 |
| US7873065B1 (en) | 2006-02-01 | 2011-01-18 | F5 Networks, Inc. | Selectively enabling network packet concatenation based on metrics |
| JP4648224B2 (ja) * | 2006-03-16 | 2011-03-09 | 富士通株式会社 | 帯域制御装置、帯域制御プログラム、帯域制御方法 |
| JP2007251818A (ja) * | 2006-03-17 | 2007-09-27 | Fujitsu Ltd | 送信制御プログラム、送信制御方法および送信制御装置 |
| US8141164B2 (en) | 2006-08-21 | 2012-03-20 | Citrix Systems, Inc. | Systems and methods for dynamic decentralized load balancing across multiple sites |
| JP4529974B2 (ja) * | 2006-12-26 | 2010-08-25 | 日本電気株式会社 | サーバ負荷分散システム、サーバ負荷分散装置、コンテンツ管理装置、及びサーバ負荷分散プログラム |
| US20080168301A1 (en) * | 2007-01-10 | 2008-07-10 | Inventec Corporation | Method of automatically adjusting storage sources for server a system |
| US7760642B2 (en) | 2007-03-12 | 2010-07-20 | Citrix Systems, Inc. | Systems and methods for providing quality of service precedence in TCP congestion control |
| US7796510B2 (en) | 2007-03-12 | 2010-09-14 | Citrix Systems, Inc. | Systems and methods for providing virtual fair queueing of network traffic |
| US8484656B2 (en) * | 2007-03-12 | 2013-07-09 | Citrix Systems, Inc. | Systems and methods for providing global server load balancing of heterogeneous devices |
| US8539035B2 (en) * | 2008-09-29 | 2013-09-17 | Fujitsu Limited | Message tying processing method and apparatus |
| US7925748B2 (en) | 2008-10-24 | 2011-04-12 | International Business Machines Corporation | System and method for managing system resources in a network environment |
| US8260926B2 (en) * | 2008-11-25 | 2012-09-04 | Citrix Systems, Inc. | Systems and methods for GSLB site persistence |
| US7930395B2 (en) | 2008-12-01 | 2011-04-19 | International Business Machines Corporation | System and method for managing system resources in a network environment |
| CN102158512B (zh) * | 2010-02-11 | 2016-03-30 | 联想(北京)有限公司 | 一种负载均衡调度方法、装置及系统 |
| US8949410B2 (en) * | 2010-09-10 | 2015-02-03 | Cisco Technology, Inc. | Server load balancer scaling for virtual servers |
| US8817614B1 (en) * | 2010-09-16 | 2014-08-26 | Vasona Networks Inc. | Policy enforcer having load balancing capabilities |
| US8549148B2 (en) | 2010-10-15 | 2013-10-01 | Brocade Communications Systems, Inc. | Domain name system security extensions (DNSSEC) for global server load balancing |
| US8533285B2 (en) | 2010-12-01 | 2013-09-10 | Cisco Technology, Inc. | Directing data flows in data centers with clustering services |
| US9241031B2 (en) * | 2011-08-02 | 2016-01-19 | Verizon Patent And Licensing Inc. | Selecting an auxiliary event-package server |
| US9154549B2 (en) | 2011-10-27 | 2015-10-06 | Cisco Technology, Inc. | Dynamic server farms |
| CN104811396A (zh) * | 2014-01-23 | 2015-07-29 | 中兴通讯股份有限公司 | 一种负荷均衡的方法及系统 |
| US20170201456A1 (en) * | 2014-08-07 | 2017-07-13 | Intel IP Corporation | Control of traffic from applications when third party servers encounter problems |
| CN104283804B (zh) * | 2014-10-27 | 2018-05-11 | 新华三技术有限公司 | 一种链路负载均衡方法和装置 |
| US10313243B2 (en) | 2015-02-24 | 2019-06-04 | Commvault Systems, Inc. | Intelligent local management of data stream throttling in secondary-copy operations |
| US10341426B2 (en) * | 2015-04-30 | 2019-07-02 | Amazon Technologies, Inc. | Managing load balancers associated with auto-scaling groups |
| US10412020B2 (en) | 2015-04-30 | 2019-09-10 | Amazon Technologies, Inc. | Background processes in update load balancers of an auto scaling group |
| US10038640B2 (en) | 2015-04-30 | 2018-07-31 | Amazon Technologies, Inc. | Managing state for updates to load balancers of an auto scaling group |
| US10298680B1 (en) | 2015-09-23 | 2019-05-21 | Cohesity, Inc. | Dynamic throughput ingestion of backup sources |
| US10574741B2 (en) | 2016-04-18 | 2020-02-25 | Nokia Technologies Oy | Multi-level load balancing |
| US10581749B2 (en) * | 2017-07-13 | 2020-03-03 | Nicira, Inc. | Automatic discovery of maximum transmission unit size for a software defined network |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4925311A (en) * | 1986-02-10 | 1990-05-15 | Teradata Corporation | Dynamically partitionable parallel processors |
| JPH0452953A (ja) * | 1990-06-20 | 1992-02-20 | Fujitsu Ltd | 負荷分散方式 |
| JPH05265777A (ja) * | 1992-03-19 | 1993-10-15 | Hitachi Ltd | プリントキュー自動コンフィギュレーションネットワークシステム |
| US5548724A (en) * | 1993-03-22 | 1996-08-20 | Hitachi, Ltd. | File server system and file access control method of the same |
| JPH06309284A (ja) * | 1993-04-20 | 1994-11-04 | Hitachi Ltd | 問合せ処理負荷分散方法 |
| JP2615408B2 (ja) * | 1993-09-20 | 1997-05-28 | 工業技術院長 | 並列計算機システム |
| JP2743865B2 (ja) * | 1995-04-28 | 1998-04-22 | 日本電気株式会社 | ジョブスケジューリング方式 |
| US5603029A (en) * | 1995-06-07 | 1997-02-11 | International Business Machines Corporation | System of assigning work requests based on classifying into an eligible class where the criteria is goal oriented and capacity information is available |
| JP2776338B2 (ja) * | 1995-10-03 | 1998-07-16 | 日本電気株式会社 | ジョブスケジューリング方式 |
| US6185601B1 (en) * | 1996-08-02 | 2001-02-06 | Hewlett-Packard Company | Dynamic load balancing of a network of client and server computers |
| US5774660A (en) * | 1996-08-05 | 1998-06-30 | Resonate, Inc. | World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network |
| US6108684A (en) * | 1996-12-23 | 2000-08-22 | Lsi Logic Corporation | Methods and apparatus for balancing loads on a storage subsystem among a plurality of controllers |
| US6078943A (en) * | 1997-02-07 | 2000-06-20 | International Business Machines Corporation | Method and apparatus for dynamic interval-based load balancing |
| JP3784137B2 (ja) * | 1997-06-04 | 2006-06-07 | 富士通株式会社 | 負荷分散システム |
| US6078960A (en) * | 1998-07-03 | 2000-06-20 | Acceleration Software International Corporation | Client-side load-balancing in client server network |
| US6393485B1 (en) * | 1998-10-27 | 2002-05-21 | International Business Machines Corporation | Method and apparatus for managing clustered computer systems |
| US6671259B1 (en) * | 1999-03-30 | 2003-12-30 | Fujitsu Limited | Method and system for wide area network load balancing |
-
1999
- 1999-10-14 JP JP29290699A patent/JP4001698B2/ja not_active Expired - Fee Related
-
2000
- 2000-07-28 US US09/628,353 patent/US6725253B1/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001117897A (ja) | 2001-04-27 |
| US6725253B1 (en) | 2004-04-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4001698B2 (ja) | 負荷分散システム | |
| US7284051B1 (en) | Relaying apparatus for use in a network system | |
| US9143558B2 (en) | Geographic resiliency and load balancing for SIP application services | |
| US7343413B2 (en) | Method and system for optimizing a network by independently scaling control segments and data flow | |
| JP3224745B2 (ja) | 高信頼化ネットワークシステム及びサーバ切り替え方法 | |
| US7003575B2 (en) | Method for assisting load balancing in a server cluster by rerouting IP traffic, and a server cluster and a client, operating according to same | |
| US9130954B2 (en) | Distributed health check for global server load balancing | |
| US7315896B2 (en) | Server network controller including packet forwarding and method therefor | |
| CN1909507B (zh) | 一种报文转发方法和系统 | |
| US9137271B2 (en) | System for switching between communication devices, switching method, and switching program | |
| JP2003163689A (ja) | ネットワーク連携情報処理システムおよびその複数負荷分散機間のアクセス移動方法 | |
| CN107332793B (zh) | 一种报文转发方法、相关设备及系统 | |
| US10652310B2 (en) | Secure remote computer network | |
| JP2001312434A (ja) | 情報配信システム | |
| Cisco | Novell IPX Commands | |
| Cisco | Novell IPX Commands | |
| Cisco | Designing SRB Internetworks | |
| Cisco | Designing SRB Internetworks | |
| Cisco | Designing SRB Internetworks | |
| Cisco | Designing SRB Internetworks | |
| Cisco | Designing SRB Internetworks | |
| Cisco | Novell IPX Commands | |
| Cisco | Novell IPX Commands | |
| Cisco | Novell IPX Commands | |
| Cisco | Novell IPX Commands |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040824 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20061129 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061212 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070209 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070522 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070720 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070814 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070815 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100824 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110824 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120824 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120824 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130824 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |