(57)【要約】【課題】ネットワーク装置又はサーバ装置の多重化方式を提供する。【解決手段】ネットワーク装置又はサーバ装置である複数のサービス提供側装置と、サービス提供側装置とネットワークを介して通信する少なくとも１つのサービス利用側装置と、を備えたシステムにおけるサービス提供側装置の多重化方式であって、サービス提供側装置の各々は、ユニークな実識別情報と全てのサービス提供側装置に共通な仮想識別情報とを予め設定されており、サービス利用側装置は、仮想識別情報により通信先を指定した通信開始要求を送信する識別情報送信部と、通信開始要求を受信したサービス提供側装置の各々から、それぞれの実識別情報を含む各応答を受信したことに応じて、複数のサービス提供側装置のうちのいずれかを通信先として決定する通信先決定部と、を備え、かつ、通信先として決定されたサービス提供側装置との間で実識別情報を使用して通信を行う。【選択図】図１３
2014032576.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク装置又はサーバ装置である複数のサービス提供側装置と、前記サービス提供側装置とネットワークを介して通信する少なくとも１つのサービス利用側装置と、を備えたシステムにおけるサービス提供側装置の多重化方式であって、
前記サービス提供側装置の各々は、ユニークな実識別情報と全てのサービス提供側装置に共通な仮想識別情報とを予め設定されており、
前記サービス利用側装置は、
前記仮想識別情報により通信先を指定した通信開始要求を送信する識別情報送信部と、
前記通信開始要求を受信した前記サービス提供側装置の各々から、それぞれの前記実識別情報を含む各応答を受信したことに応じて、複数の前記サービス提供側装置のうちのいずれかを通信先として決定する通信先決定部と、を備え、かつ、
通信先として決定されたサービス提供側装置との間で前記実識別情報を使用して通信を行うことを特徴とするネットワーク装置又はサーバ装置の多重化方式。
【請求項２】
前記サービス利用側装置はさらに、
通信中のサービス提供側装置に対して監視用情報を送信し、前記監視用情報に対する前記サービス提供側装置からの応答を受信し、前記監視用情報に対する応答が途絶えたことにより前記サービス提供側装置における障害発生を検知する障害監視部を備え、
前記障害監視部が障害発生を検知したことに応じて、前記識別情報送信部が再度、通信開始要求を送信し、前記通信先決定部が別のサービス提供側装置を通信先として決定することを特徴とする
請求項1に記載のネットワーク装置又はサーバ装置の多重化方式。
【請求項３】
前記サービス提供側装置の各々はさらに、現時点の処理負荷を示す処理負荷レベル情報をそれぞれ保有しており、かつ、前記通信開始要求に対する前記サービス提供側装置の各々からの各応答には、それぞれのサービス提供側装置の処理負荷レベル情報が含まれており、
前記サービス利用側装置の前記通信先決定部は、前記処理負荷レベル情報に基づいて、現時点の処理負荷が最小のサービス提供側装置を通信先として決定することを特徴とする請求項１又は２に記載のネットワーク装置又はサーバ装置の多重化方式。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネット又は企業内ＬＡＮ等のネットワーク関連の情報システムを構成するネットワーク装置又はサーバ装置の多重化方式に関するものである。
【背景技術】
【０００２】
非特許文献１の、経済産業省が取りまとめた「情報システムの信頼性向上に関するガイドライン」でも述べられている通り、情報システムの大規模化・ネットワーク化により情報システムが複雑化することで、情報システムの障害（ハードウェアまたはソフトウェアの問題によって正常に稼動できない状態）が国民生活や社会に与える影響が益々大きくなっており、情報システムにとって信頼性および性能の向上が喫緊かつ重要な課題となっている。
【０００３】
情報システムの信頼性および性能を向上させる最も主要な施策として、ネットワーク装置やサーバ装置などのハードウェア装置の多重化がある。例えば、特許文献１、２に開示されている。
【０００４】
インターネットや企業内ＬＡＮ上で稼動する情報システムにおいて、サーバ装置の多重化の最も一般的な実現方式は、負荷分散装置による方式である。
【０００５】
図２は、負荷分散装置によってサーバ装置の多重化を実現した従来方式の情報システムの構成図である。サービス提供側（２０１）で示している範囲が、インターネット上のウェブサイトや企業内ＬＡＮ上の情報システムである。サーバ装置１（２０２）、サーバ装置２（２０３）．．．サーバ装置ｎ（２０４）は、多重化されたサーバ装置群を示している。サーバ装置を多重化することにより、情報システム全体の信頼性と性能を向上させている。これらのサーバ装置群に対してネットワーク（２０６）から送られてくるサービス要求を負荷分散装置（２０５）が振り分ける。ネットワークの先にあるサービス利用側（２０７）の範囲に含まれるサーバ装置（２０８）又はクライアントＰＣ（２０９）が、サービス要求を送信し、サービスの提供を受ける。
【０００６】
例えば、サービス提供側（２０１）のサーバ装置１台当たりの稼働率（正常に稼動する確率）をａとし、サーバ装置ｎ台で構成された情報システム全体の稼働率は下式で求められる。
［情報システム全体の稼働率］＝ １−（１−ａ）ｎ
ここでａを９９％、ｎを４とすると、下式で計算される通り、情報システム全体の稼働率は９９．９９９９９９％となる。
［情報システム全体の稼働率］＝ １−（１−０．９９）４
このように、サーバ装置の多重化によって稼働率を飛躍的に向上させることができる。
【０００７】
しかし、ここで、負荷分散装置（２０５）自体の稼働率を考慮しなければならない。図２のように、負荷分散装置とサーバ装置は直列の関係で接続されている。このため、負荷分散装置を含めた全体の稼働率は負荷分散装置の稼働率を超えることはない。負荷分散装置の稼働率をｂとした場合の、負荷分散装置を含めた全体の稼働率は下式で求められる。
［情報システム全体の稼働率］＝ １−（１−（１−ａ）ｎ）×ｂ
前述と同様に、サーバ装置の稼働率を９９％、台数を４台、負荷分散装置の稼働率を９９％とした場合のサーバ装置、負荷分散装置を含めた全体の稼働率は、下式で計算される通り、９８．９９９９９９０１％となり、９９％を下回る。
［情報システム全体の稼働率］＝ １− {１−（１−０．９９）４ }×０．９９
【０００８】
図２においては、サーバ装置の多重化によって信頼性と性能が確保される一方、負荷分散装置（２０５）が障害となった場合にサーバ装置へのサービス要求が振り分けられなくなるために、情報システム全体が障害となってしまう。従って、負荷分散装置自体の多重化も併せて実施することが必要となる。
【０００９】
図３は、負荷分散装置自体をも多重化した従来方式の情報システムの構成図である。
図３の構成では、サービス提供側（３０１）のサーバ装置（３０２、３０４）の多重化は、サービス利用側（３０８）から送られてくるサービス要求を負荷分散装置（３０５、３０６）が各サーバ装置へ均等に振り分けることで実現している。この場合、２つの負荷分散装置の多重化は、次のような従来方式により実現している。複数の負荷分散装置は、「アクティブ（Ａｃｔｉｖｅ）」と称される１台の負荷分散装置と、「スタンバイ（Ｓｔａｎｄｂｙ）」と称される１台または複数台の負荷分散装置とから構成されている。アクティブ負荷分散装置とは、通常稼動している負荷分散装置であり、サーバの振り分け処理を行っている。スタンバイ負荷分散装置とは、通常は稼動しない負荷分散装置であり、アクティブ負荷分散装置が障害になった場合に、これに替わってサーバ装置の振り分け処理を行う。
【００１０】
図２、図３におけるサーバ装置の多重化は、負荷分散装置がこれらにサービス利用側からのサービス要求を振り分けることで各サーバ装置を均等に実行させている。これに対し、図３における負荷分散装置自体の多重化においては、サービス利用側からのサービス要求を複数の負荷分散装置にどのように均等に振り分けるかが課題になる。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開平８−３１６９５７号公報
【特許文献２】特開２０１２９０１９４号公報
【非特許文献】
【００１２】
【非特許文献１】経済産業省「情報システムの信頼性向上に関するガイドライン第２版」、２００９年３月２４日
【発明の概要】
【発明が解決しようとする課題】
【００１３】
図４は、アクティブとスタンバイの２種類の負荷分散装置で構成された従来方式による負荷分散装置の多重化のイメージ図である。図４（ａ）に示すように負荷分散装置を、アクティブ（４０４）とスタンバイ（４０５）の２種類に分けている。なお、従来方式における負荷分散装置を、その時点での機能によって「アクティブ負荷分散装置」又は「スタンバイ負荷分散装置」と称するが、特定の負荷分散装置がアクティブかスタンバイかは必ずしも固定的ではない。アクティブ負荷分散装置は、通常時にサービス利用側からのサービス要求を受付け、処理する。これに対してスタンバイ負荷分散装置は、通常時はサービス利用側からのサービス要求を処理しない。一方、図４（ｂ）に示すように、一旦、アクティブ負荷分散装置（４１２）に障害が発生した場合には、スタンバイ負荷分散装置（４１３）がアクティブ負荷分散装置に成り替わってサービス要求を処理するようになる。つまり、スタンバイ負荷分散装置がアクティブ負荷分散装置となって処理を行う。
【００１４】
図４に示す負荷分散装置の多重化の従来方式における技術課題として、アクティブ負荷分散装置の障害をどのように検知し、その機能をどのようにスタンバイ負荷分散装置へ引き継がせるかという点がある。
【００１５】
現状では、この障害検知と機能引き継ぎの方式として、主に下記の２つがある。
［従来方式１］アクティブ負荷分散装置（１台）とスタンバイ負荷分散装置（１台）の間をケーブルで接続し、スタンバイ負荷分散装置がアクティブ負荷分散装置の死活（正常に稼動しているか否か）を監視し、「死んだ（障害となった）」ことをスタンバイ負荷分散装置が検知したことを契機に、スタンバイ負荷分散装置がアクティブ負荷分散装置に成り代わる方式（以降、「１対１監視方式」と呼ぶ）
［従来方式２］ネットワークプロトコルであるＶＲＲＰ（Ｖｉｒｔｕａｌ Ｒｏｕｔｅｒ Ｒｅｄｕｎｄａｎｃｙ Ｐｒｏｔｏｃｉｌ）を使用する方式（以降、「ＶＲＲＰ方式」と呼ぶ）
それぞれの方式について以下に説明し、それぞれの課題を示す。
【００１６】
図５は、１対１監視方式のイメージ図を示した図である。図５（ａ）に示す通常時には、スタンバイ負荷分散装置（５０２）がアクティブ負荷分散装置（５０１）に対して「Ｈｅａｒｔ Ｂｅａｔ」または「Ｋｅｅｐａｌｉｖｅ」と呼ばれるパケット（通信メッセージの単位）（以降、「Ｈｅａｒｔ Ｂｅａｔパケット」と称す）を送出する。このＨｅａｒｔ Ｂｅａｔパケットに対してアクティブ負荷分散装置は、応答パケットを返送することで「活きている（正常に稼動している）」ことをスタンバイ負荷分散装置に知らせる。
【００１７】
次に、図５（ｂ）に示す障害発生時における負荷分散装置の切り替え動作を説明する。スタンバイ負荷分散装置（５０４）はアクティブ負荷分散装置（５０３）にＨｅａｒｔ Ｂｅａｔパケットを送出するが、アクティブ負荷分散装置が障害となっている場合にはこれに応答することができない。スタンバイ負荷分散装置はこれによってアクティブ負荷分散装置の障害を検知し、以降、アクティブ負荷分散装置の処理を引き継いでサーバ装置への振り分け処理を開始する。
【００１８】
ここで、ネットワーク上の動作について補足する。ネットワークに接続された装置にはＩＰアドレスというユニークな識別子が個々に付与されている。アクティブ負荷分散装置は、サービス利用側装置から自分のＩＰアドレスを宛先としたサービス要求が来た時にこれを取り込み、サーバ装置に振り分ける処理を行う。アクティブ負荷分散装置が障害になった場合には、スタンバイ負荷分散装置がアクティブ負荷分散装置のＩＰアドレスに宛てたサービス要求を取り込んで代行するようになる。アクティブ負荷分散装置とスタンバイ負荷分散装置は同一のＬＡＮセグメント上にあるため、サービス利用側装置が送ってきたサービス要求をいずれもが受信することができ、ＩＰアドレスを参照して自分宛か否かを判定している。
【００１９】
１対１監視方式は、比較的平易な実現方式であるが、以下のような課題がある。
［課題１］アクティブ負荷分散装置が１台であるため、複数台の負荷分散装置を準備しても常に１台分の性能しか出ない。
［課題２］クティブ負荷分散装置が１台であるため、アクティブ負荷分散装置が障害になった場合にはスタンバイ負荷分散装置に切り替わるまでの間、情報システム全体が障害となる。
［課題３］スタンバイ負荷分散装置が１台であるため、アクティブ負荷分散に続いてスタンバイ負荷分散装置も障害になった場合（いわゆる２重障害）には情報システム全体が障害となる。
［課題４］アクティブ負荷分散装置とスタンバイ負荷分散装置では役割が異なることから、装置に設定する情報なども異なり、その分、ネットワーク管理者の設計・運用負担が生じる。
【００２０】
図６は、ＶＲＲＰ方式のイメージ図を示した図である。ＶＲＲＰとは、もともとはネットワーク装置であるルータ装置の多重化のためにインターネット技術に関する標準化団体ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）が定めたプロトコルであり（ドキュメント番号：ＲＦＣ３７６８）、これを負荷分散装置の多重化に応用した方式である。
【００２１】
ＶＲＲＰ方式においても、負荷分散装置にアクティブとスタンバイの２種類がある。１対１監視方式ではスタンバイ負荷分散装置が１台であったのに対し、ＶＲＲＰ方式では２台以上あってもよい。さらに、１対１監視方式と異なる点は、アクティブ負荷分散装置（６０１）が活きていることを示すパケットをアクティブ負荷分散装置自身が発信する点である。このパケットを「Ａｄｖｅｒｔｉｓｅｍｅｎｔパケット」と言う。
【００２２】
図６（ａ）の通常時において、スタンバイ負荷分散装置（６０２、６０３）は、アクティブ負荷分散装置が発信するＡｄｖｅｒｔｉｓｅｍｅｎｔパケットを監視している。これが一定間隔で受信できることにより、スタンバイ負荷分散装置はアクティブ負荷分散装置が活きていることを確認する。
【００２３】
次に、図６（ｂ）の障害発生時においては、以下の手順でアクティブ負荷分散装置の障害を検知し、スタンバイ負荷分散装置のアクティブ負荷分散装置への切り替えを行う。
(1)アクティブ負荷分散装置（６０４）が障害となると、Ａｄｖｅｒｔｉｓｅｍｅｎｔパケットが発信されなくなる。
(2)スタンバイ負荷分散装置（６０５、６０６）はアクティブ負荷分散装置からのＡｄｖｅｒｔｉｓｅｍｅｎｔパケットの受信が途絶えると、ある一定時間監視を継続する。
(3)一定時間経過後、それでも同パケットが受信できない場合にはアクティブ負荷分散装置に障害が発生した、アクティブ負荷分散装置が「死んだ（障害となった）」と判断する。続いて、これに成り代わってサーバ装置への振り分け処理を開始する。
(4)ここで、スタンバイ負荷分散装置が複数台ある場合には、いずれをアクティブの負荷分散装置とさせるかを決定しなければならない。予め、負荷分散装置にプライオリティ値（優先順位を示す値）を設定しておき、各スタンバイ負荷分散装置はこのプライオリティ値を設定したＡｄｖｅｒｔｉｓｅｍｅｎｔパケットを発信する。
(5)互いに他のスタンバイ負荷分散装置のプライオリティ値を確認し合い、その中で最も値の大きなプライオリティ値を有するスタンバイ負荷分散装置を新たなアクティブ負荷分散装置として認識する。
（6）最も高いプライオリティ値を設定されているスタンバイ負荷分散装置がアクティブ負荷分散装置に切り替わる。
【００２４】
１対１監視方式に比較して、ＶＲＲＰ方式では複数台のスタンバイ負荷分散装置を構成できるところが利点であるが、依然として以下の課題がある。
［課題５］アクティブ負荷分散装置が１台であるため、複数台の負荷分散装置を準備しても常に１台分の性能しか出ない。
［課題６］アクティブ負荷分散装置が１台であるため、アクティブ負荷分散装置が障害になった場合にはスタンバイ負荷分散装置に切り替わるまでの間、情報システム全体が障害となる。
［課題７］アクティブ負荷分散装置が障害となった場合に、いずれのスタンバイ負荷分散装置がこれに成り代わるべきかを決定するために、予め、スタンバイ負荷分散装置に対してプライオリティ値を設定しなければならず、これはネットワーク管理者の設計、運用負担になる。
【００２５】
以上の通り、負荷分散装置の多重化に関する２種類の従来方式のいずれにおいても解決するべき課題がある。本発明は、これらの課題を解決することを目的とする。また、これらの課題を解決する多重化方式であって、負荷分散装置に限らず、種々のネットワーク装置又はサーバ装置に適用可能な方式を提供することを目的とする。
【課題を解決するための手段】
【００２６】
上記の目的を実現するべく本発明は、以下の構成を提供する。
本発明の態様は、ネットワーク装置又はサーバ装置である複数のサービス提供側装置と、前記サービス提供側装置とネットワークを介して通信する少なくとも１つのサービス利用側装置と、を備えたシステムにおけるサービス提供側装置の多重化方式であって、前記サービス提供側装置の各々は、ユニークな実識別情報と全てのサービス提供側装置に共通な仮想識別情報とを予め設定されており、前記サービス利用側装置は、前記仮想識別情報により通信先を指定した通信開始要求を送信する識別情報送信部と、前記通信開始要求を受信した前記サービス提供側装置の各々から、それぞれの前記実識別情報を含む各応答を受信したことに応じて、複数の前記サービス提供側装置のうちのいずれかを通信先として決定する通信先決定部と、を備え、かつ、通信先として決定されたサービス提供側装置との間で前記実識別情報を使用して通信を行うことを特徴とする。
【００２７】
上記態様において、前記サービス利用側装置はさらに、通信中のサービス提供側装置に対して監視用情報を送信し、前記監視用情報に対する前記サービス提供側装置からの応答を受信し、前記監視用情報に対する応答が途絶えたことにより前記サービス提供側装置における障害発生を検知する障害監視部を備え、前記障害監視部が障害発生を検知したことに応じて、前記識別情報送信部が再度、通信開始要求を送信し、前記通信先決定部が別のサービス提供側装置を通信先として決定することが、好適である。
【００２８】
上記態様において、前記サービス提供側装置の各々はさらに、前記サービス提供側装置の各々はさらに、現時点の処理負荷を示す処理負荷レベル情報をそれぞれ保有しており、かつ、前記通信開始要求に対する前記サービス提供側装置の各々からの各応答には、それぞれのサービス提供側装置の処理負荷レベル情報が含まれており、前記サービス利用側装置の前記通信先決定部は、前記処理負荷レベル情報に基づいて、現時点の処理負荷が最小のサービス提供側装置を通信先として決定することが、好適である。
【発明の効果】
【００２９】
本発明による、ネットワーク装置又はサーバ装置であるサービス提供側装置の多重化方式は、従来方式（１対１監視方式、ＶＲＲＰ方式）と比較して以下の効果を奏することができる。ここでは、サービス提供側装置が負荷分散装置の場合について説明するが、後に例示する他の装置であっても、同様の効果を奏する。
【００３０】
従来方式では、サーバ振り分け処理を行うのはアクティブな負荷分散装置１台だけであり、複数台の負荷分散装置を用意したとしても性能向上を図ることはできない。これに対し、本発明による方式では、全ての負荷分散装置がほぼ均等にサーバ振り分けを実行することになるため、台数に比例した性能が得られる。
【００３１】
従来方式では、サーバ振り分け処理を行うのはアクティブな負荷分散装置１台だけであるため、アクティブ負荷分散装置の障害時には、スタンバイ負荷分散装置への切り替えが完了するまでの間は情報システム全体が障害となる。これに対し、本発明による方式では、すべての負荷分散装置が均等にサーバ振り分け処理を行うため、情報システム全体の障害には至らず、その影響は当該負荷分散装置を使用していたサービス利用側装置に限られる。
【００３２】
従来方式では、負荷分散装置に対してアクティブ、スタンバイの区別や、ＶＲＲＰ方式であれば、プライオリティ値を設定しなければならない。一方、本発明による方式では、多重化対象の負荷分散装置はすべて同じ設定でよい。このため、ネットワーク管理者の負担を軽減することができる。（なお、本発明による方式においても、ＩＰアドレスやＭＡＣアドレス等の装置個別の識別情報を設定することは、必要である。しかしながら、これらはそもそも、いずれの多重化方式を採用したとしても、一般的なシステムにおいて装置を識別するために必ず設定される項目である。）
以上の通り、本発明によるネットワーク装置又はサーバ装置の多重化方式は、従来方式の課題を解決することができる。
【００３３】
さらに本発明による方式は、負荷分散装置への適用に留まらず、応用範囲が広い。例えば、サービス提供側の複数のサーバ装置自体にも応用することができる。サーバ装置に応用した場合、サービス利用側装置が複数のサーバ装置を均等に使い分けることになることから、もともとそのような役割を担ってきた負荷分散装置自体が不要になる。さらに本発明による方式は、ＯｐｅｎＦｌｏｗネットワーク技術における複数のＯｐｅｎＦｌｏｗコントローラにも応用することができる。このように、本発明の方式の原理は、複数の装置により処理負荷を分散するシステムにおいて、処理を担当する装置を適切に選択して各装置の処理負荷を均等とするために適用することができる。
【図面の簡単な説明】
【００３４】
【図１】図１は、本発明による方式を適用して負荷分散装置の多重化を実現したシステム構成の一例を示す図である。
【図２】図２は、負荷分散装置によりサーバ装置の多重化を実現した従来方式の情報システムの構成図である。
【図３】図３は、負荷分散装置を多重化した従来方式の情報システムの構成図である。。
【図４】図４は、アクティブとスタンバイの２種類の負荷分散装置で構成された従来方式による負荷分散装置の多重化のイメージ図である。
【図５】図５は、多重化された負荷分散装置の構成における障害検知のための１対１監視方式（従来方式）の実現イメージ図である。
【図６】図６は、多重化された負荷分散装置の構成における障害検知のためのＶＲＲＰ方式（従来方式）の実現イメージ図である。
【図７】図７は、図１に示した本発明による負荷分散装置の多重化方式における処理の流れを示す図である。
【図８】図８は、本発明方式おける、負荷分散装置に対する障害検知の処理と他の負荷分散装置への切り替え処理を説明する図である。
【図９】図９は、負荷分散装置の多重化に関する従来方式と本発明による方式の比較図である。
【図１０】図１０は、負荷分散装置の多重化に関する従来方式と本発明による方式の比較表である。
【図１１】図１１は、サービス提供側装置である複数のサーバ装置の選択に関して本発明の方式を適用したシステム構成の一例を示した図である。
【図１２】図１２は、新しいネットワーク技術であるＯｐｅｎＦｌｏｗに対して本発明の方式を適用したシステム構成の一例を示した図である。
【図１３】図１３は、本発明による方式を適用して任意のサービス提供側装置の多重化を実現したシステム構成の一例を示す図である。
【発明を実施するための形態】
【００３５】
以下、本発明によるネットワーク装置又はサーバ装置の多重化方式を、負荷分散装置に適用した多重化方式、サーバ装置に適用した多重化方式、並びに新しいネットワーク技術であるＯｐｅｎＦｌｏｗコントローラに適用した多重化方式の各例について説明する。
【００３６】
インターネットや企業内ＬＡＮなどのＴＣＰ／ＩＰネットワークにおいては、ネットワークに接続される装置をＩＰアドレスやＭＡＣアドレスである識別情報により識別し、これによって通信先や通信経路を判定している。本発明による多重化方式では、ＩＰアドレス、ＭＡＣアドレスのいずれにも適用可能であるため、以降、ＩＰアドレスを例として説明する。
【００３７】
図１は、インターネットや企業内ＬＡＮの情報システムにおいて、本発明による方式を適用して負荷分散装置の多重化を実現したシステム構成の一例を示す図である。
【００３８】
サービス提供側（１０１）で示している範囲がインターネット上のウェブサイトや企業ＬＡＮ上の情報システムである。サーバ装置１（１０２）、サーバ装置２（１０３）．．．サーバ装置ｎ（１０４）は多重化されたサーバ装置群を示している。サーバ装置を多重化することで情報システム全体の信頼性と性能を向上させている。これらのサーバ群に対してネットワーク（１１４）から送られてくるサービス要求を、負荷分散装置１（１０５）、負荷分散装置２（１０８）．．．負荷分散装置ｍ（１１１）が振り分ける。これらは、多重化された負荷分散装置群である。本明細書では、サービス提供側（１０１）のサーバ装置（１０２、１０３、１０４）又は負荷分散装置（１０５、１０８、１１１）を「サービス提供側装置」と称する場合がある。
【００３９】
ネットワーク１１４の先にサービス利用側（１１５）が存在する。サービス利用側（１１５）の範囲には、実際のサービス要求を送信し、サービスの提供を受けるサーバ装置（１１６）又はクライアントＰＣ（１１７）が含まれる。本明細書では、サービス利用側（１１５）のサーバ装置（１１６）又はクライアントＰＣ（１１７）を「サービス利用側装置」と称する場合がある。
【００４０】
個々の負荷分散装置（１０５、１０８、１１１）は、それぞれＩＰアドレス（１０６、１０９、１１２）を有する。ＩＰアドレス（１０６、１０９、１１２）には、ユニークなＩＰアドレスと全ての負荷分散装置に共通のＩＰアドレスの２種類が含まれる。ユニークなＩＰアドレスを「実ＩＰアドレス」と称し、共通のＩＰアドレスを「仮想ＩＰアドレス」と称することとする。
【００４１】
さらに個々の負荷分散装置（１０５、１０８、１１１）は、それぞれコネクション数（１０７、１１０、１１３）を保有する。コネクション数は、その負荷分散装置がすでに通信を開始しているサービス利用側装置の数を表す。
【００４２】
本発明において、サービス要求したサービス利用側装置と通信を行う１つの負荷分散装置を決定する手順の概要を述べる。まず、サービス利用側装置は、仮想ＩＰアドレスを用いて通信開始要求を行う。この通信開始要求は全ての負荷分散装置が受け取る。これに対して、各負荷分散装置は稼働情報を送り返す。サービス利用側装置は、各負荷分散装置（１０５、１０８、１１１）から送られてくる稼動情報を取得する。稼動情報には、各負荷分散装置（１０５、１０８、１１１）の実ＩＰアドレスとコネクション数が含まれている。次に、最小のコネクション数をもつ実ＩＰアドレスを選択し、選択された実ＩＰアドレスを有する負荷分散装置を通信先として決定する。その後、サービス利用側装置は、決定された負荷分散装置と通信を開始する。
【００４３】
図７を参照して、本発明による負荷分散装置の多重化方式における処理の流れを説明する。図７では、左端にサービス利用側装置であるクライアントＰＣ（７０１）、その右側に複数の負荷分散装置（７０５、７０９、７１２）を示している。
【００４４】
本発明による方式では、従来方式と異なり、負荷分散装置にアクティブ、スタンバイという区別はない。図１で説明した通り、負荷分散装置のそれぞれは、ユニークな実ＩＰアドレスと、共通の仮想ＩＰアドレスとからなる２つのＩＰアドレス（７０６、７１０、７１３）を予め設定されている。
【００４５】
サービス利用側装置であるクライアントＰＣ（７０１）は、サービス提供側装置であるサーバ装置にサービス要求を送信する時、まず、仮想ＩＰアドレスにより通信先を指定して通信開始要求を送信する（ステップ７０２）。仮想ＩＰアドレスは全ての負荷分散装置に共通であるので、各負荷分散装置（７０５、７０９、７１２）がそれぞれ通信開始要求を受信する。続いて、各負荷分散装置は、クライアントＰＣからの通信開始要求に対して応答を返す。この応答において、各負荷分散装置は、自らの実ＩＰアドレスとコネクション数を設定して返す（ステップ７０７、７１１、７１４）。
【００４６】
クライアントＰＣは、各負荷分散装置からの応答を受信する。各応答に設定されているコネクション数を比較することにより、最も小さいコネクション数をもつ負荷分散装置を選択する（ステップ７０３）。図７の例では、負荷分散装置１（７０５）のコネクション数"１"が最も小さいので、負荷分散装置１（７０５）を選択する。その後、選択した負荷分散装置の実ＩＰアドレスを使用して、負荷分散装置１との間で通信を行う（ステップ７０４）。
【００４７】
上記のステップ７０３において、最小のコネクション数が複数ある場合には、ランダムに１つを選択する。ここで選ばれた負荷分散装置は、当該クライアントＰＣから送信されてくるサービス要求を、サービス提供側装置である複数のサーバ装置（図１の１０２、１０３，１０４）に振り分ける処理を行う。また、選ばれた負荷分散装置は、クライアントＰＣとの通信を開始したときにコネクション数を１だけ増分する。
【００４８】
この方式においては、クライアントＰＣが、複数ある負荷分散装置の中から通信先として使用するものを選び出す。さらに、負荷分散装置を選ぶ基準が、最小のコネクション数に基づいている。この結果、各負荷分散装置のコネクション数が均等化される。つまり、各負荷分散装置自体の処理負荷が均等化されることを意味する。これはちょうど、負荷分散装置が複数のサーバ装置の処理負荷を均等化させるために複数のサーバ装置にサービスを振り分けていることと同じことを、複数の負荷分散装置に対してサービス利用側装置自体が行っていることになる。
【００４９】
従来方式では、１台のアクティブ負荷分散装置のみがサーバ振り分け処理を実行するのに対し、本発明では、複数ある負荷分散装置のすべてを均等に使用することとなるので、性能の面で優っている。
【００５０】
図８を参照して、本発明による方式おける、負荷分散装置に対する障害検知処理と他の負荷分散装置への切り替え処理について説明する。
【００５１】
図８（ａ）は、図７の方式によりクライアントＰＣ（８０６）が使用する負荷分散装置１（８０２）を決定した後の状態を示している。この段階では、クライアントＰＣ（８０６）が、サーバ装置（８０１）との通信を開始している。クライアントＰＣ（８０６）が相手の負荷分散装置１（８０２）に対してＨｅａｒｔ Ｂｅａｔパケットを送付することで負荷分散装置の死活を監視している。
【００５２】
図８（ｂ）を参照し、クライアントＰＣ（８１２）が選択した負荷分散装置１（８０８）において、通信開始後に障害が発生した場合について説明する。負荷分散装置（８０８）に障害が発生した場合、Ｈｅａｒｔ Ｂｅａｔパケットに対する応答が返らなくなるので、クライアントＰＣは通信先の負荷分散装置に障害が発生したと見なす。続いて、クライアントＰＣは、再度、図７で説明した通信開始要求を負荷分散装置の仮想ＩＰアドレスに対して送出する。仮想ＩＰアドレスは負荷分散装置に共通であるので、全ての負荷分散装置（８０８、８０９、８１０）により受信される。以降、図７で説明した手順にて代替する負荷分散装置（８１０）を決定する。
【００５３】
負荷分散装置の再選択を行う際、以下のケースについて考慮することが好ましい。
・クライアントＰＣ（８１２）が障害を検知した負荷分散装置（８０８）からも応答が返ってくる可能性がある。この場合は、再度同じ障害に陥る可能性があるので、設定されているコネクション数に関わりなく、通信先の候補から負荷分散装置（８０８）を除外する。
・すべての負荷分散装置（８０８、８０９、８１０）が障害の場合にはいずれの負荷分散装置からも応答がないことが考えられる。この場合は、回避不可能な恒久障害と見なし、クライアントＰＣ（８１２）の画面にその旨のエラーメッセージを出力するなどによりエンドユーザにその旨を通知する。
【００５４】
図９及び図１０の図及び表により、負荷分散装置の多重化に関する従来方式と本発明の方式とを比較した結果を示す。図９（ａ）は従来方式を、図９（ｂ）は本発明の方式を示す。
【００５５】
図９（ａ）の従来方式では、サーバ振り分け処理をアクティブ負荷分散装置（９０２）１台でのみ処理する。これに対し、図９（ｂ）の本発明による方式ではすべての負荷分散装置（９０８、９０９、９１０）をほぼ均等に使用するため、負荷分散装置の台数に見合った性能を発揮させることができる。
【００５６】
また、図９（ａ）の従来方式では、サーバ振り分け処理をアクティブ負荷分散装置（９０２）１台でのみ処理するために、これが障害となった場合には、スタンバイ負荷分散装置（９０３又は９０４）に切り替わるまでの間、すべてのサービス利用側装置（９０６）はサーバ装置（９０１）を使用することができなくなる。これに対し、本発明による方式では、すべての負荷分散装置（９０８、９０９、９１０）が並行してサーバ装置（９０７）への振り分け処理を行うため、そのうちの１台の負荷分散装置（９０８）に障害が発生しても、他の負荷分散装置（９０９、９１０）を使用しているサービス利用側装置（９１２）には影響が及ばない。このため、従来方式よりも本発明による方式の方がより信頼性が高いと言える。
【００５７】
さらに、図９（ａ）の従来方式では、負荷分散方式をアクティブ（９０２）とスタンバイ（９０３、９０４）の２種類に分けて管理しなければならないので、装置の設定情報などもそれぞれに管理して設定する必要がある。これに対し、図９（ｂ）の本発明による方式では、アクティブとスタンバイの区別はなく、全ての負荷分散装置（９０８、９０９、９１０）について同一の設定でよいので、ネットワーク管理者の負担を軽減させる効果がある。
【００５８】
図１１及び図１２を参照し、本発明を負荷分散装置以外に適用した応用例を説明する。
図１１は、サービス提供側装置である多重化されたサーバ装置の選択に関して本発明の方式を適用したシステム構成の一例を示している。
【００５９】
図１１（ａ）に示すように、サービス利用側装置（１１０５）は、サービス提供側装置である複数のサーバ装置（１１０１、１１０２、１１０３）のいずれを使用するかを決定する。事前の設定として、サーバ装置（１１０１、１１０２、１１０３）の各々に対して、ユニークな実ＩＰアドレスと、共通の仮想ＩＰアドレスの２つのＩＰアドレスが付与されている。また、各サーバ装置は、通信しているサービス利用側装置の数を示すコネクション数を保有可能である。
【００６０】
まず、クライントＰＣ（１１０５）が、仮想ＩＰアドレスを指定してサーバ装置との通信開始要求を送信する。通信開始要求を受信した各サーバ装置（１１０１、１１０２、１１０３）は、実ＩＰアドレスと、現時点で保有しているコネクション数を応答する。クライアントＰＣは、最もコネクション数の少ない実ＩＰアドレスをもつサーバ装置１（１１０１）を通信先として決定する。
【００６１】
図１１（ｂ）に示すように、通信開始後は、クライアントＰＣ（１１１０）がＨｅａｒｔ Ｂｅａｔパケットを送信することにより、通信先のサーバ装置１（１１０６）の稼働を監視する。
【００６２】
図１１（ｃ）に示すように、サーバ装置１（１１１１）に障害が発生し、Ｈｅａｒｔ Ｂｅａｔパケットが途絶したことにより、クライアントＰＣ（１１１５）は障害の発生を検知する。
【００６３】
図１１（ｄ）に示すように、クライアントＰＣ（１１２０）は、再び、仮想ＩＰアドレスを用いて通信開始要求を送信する。それに対する応答に含まれるコネクション数に基づいて、クライアントＰＣは、障害が発生したサーバ装置（１１１６）以外のサーバ装置（１１１７又は１１１８）を通信先として決定する。
【００６４】
本発明をサービス提供側装置である多重化されたサーバ装置に適用することにより、以下の効果がある。
・サービス利用側装置（クライアントＰＣまたはサーバ装置）が、使用するサービス提供側装置であるサーバ装置を決定するので、上述した負荷分散装置自体が不要となる。
・背景技術で述べた通り、サーバ装置と負荷分散装置を直列に接続することで全体の稼働率は低下する。よって、負荷分散装置を介さないで直接サーバ装置と通信する方が稼働率は高まるという効果がある。
・負荷分散装置にかかる費用も不要となる。
・サービスを提供する多重化されたサーバ装置の性能、信頼性の向上が図れる。
【００６５】
図１２は、２つ目の応用例として、新しいネットワーク技術であるＯｐｅｎＦｌｏｗに対して本発明の方式を適用したシステム構成の一例を示している。
【００６６】
図１２（ａ）を参照して「ＯｐｅｎＦｌｏｗ」について説明する。「ＯｐｅｎＦｌｏｗ」とは、Ｏｐｅｎ Ｎｅｔｗｏｒｋｉｎｇ Ｆｏｕｎｄａｔｉｏｎという標準化団体が標準化を進めている新しいネットワーク技術である。これは、従来のＬ３スイッチ、Ｌ２スイッチで構成されてきたネットワークを、まったく新しい考え方によって刷新するものでる。ＯｐｅｎＦｌｏｗでは、ネットワークは、「ＯｐｅｎＦｌｏｗコントローラ」と「ＯｐｅｎＦｌｏｗスイッチ」という２種類のネットワーク装置で構成される。従来技術では、ネットワークに関する経路情報（ルーティング情報とも言う）はＬ３スイッチへ個々に設定する必要があった。これに対し、ＯｐｅｎＦｌｏｗでは、この経路情報をＯｐｅｎＦｌｏｗコントローラ（１２０１）が一元的に管理し、実際の経路制御を行うＯｐｅｎＦｌｏｗスイッチ（１２０２、１２０３、１２０４）がＯｐｅｎＦｌｏｗコントローラ（１２０１）に動的に問い合わせることで経路情報を入手する。
【００６７】
このように、管理情報を一元管理することでネットワーク管理者の負担を軽減することができる。しかし、一元管理と性能、信頼性は背反する面がある。つまり、管理情報を特定の装置で一元管理すると、その装置に処理が集中して性能が低下したり、また、その装置が障害となった場合にネットワーク全体に影響が生じたりするという問題がある。
【００６８】
ＯｐｅｎＦｌｏｗコントローラとＯｐｅｎＦｌｏｗスイッチは垂直分散構成となっており、ここに本発明の多重化方式を応用することができる。図１２（ｂ）を参照して、本発明の適用形態を説明する。この場合、複数のＯｐｅｎＦｌｏｗコントローラ（１２０５、１２０６、１２０７）と、複数のＯｐｅｎＦｌｏｗスイッチ（１２０８、１２０９、１２１０）が設けられる。この形態では、ＯｐｅｎＦｌｏｗコントローラが多重化されている。
【００６９】
事前の設定として、複数のＯｐｅｎＦｌｏｗコントローラ（１２０５、１２０６、１２０７）の各々は、ユニークな実ＩＰアドレスと、共通の仮想ＩＰアドレスを付与されている。また、各ＯｐｅｎＦｌｏｗコントローラは、通信中のＯｐｅｎＦｌｏｗスイッチの数をコネクション数として保有可能とする。
【００７０】
例えば、ＯｐｅｎＦｌｏｗスイッチ１（１２０８）が、問い合わせ先のＯｐｅｎＦｌｏｗコントローラを決定するために、共通の仮想ＩＰアドレスを設定して問い合わせ開始要求を送信する。各ＯｐｅｎＦｌｏｗコントローラ（１２０５、１２０６、１２０７）は、実ＩＰアドレスとコネクション数を含む応答を行う。ＯｐｅｎＦｌｏｗスイッチ（１２０８）は、コネクション数が最小であるＯｐｅｎＦｌｏｗコントローラ２（１２０６）を選択し、問い合わせ先として決定する。上述したように、問い合わせ中は監視を行い、問い合わせ先のＯｐｅｎＦｌｏｗコントローラに障害が発生したときは、再度の選択処理を行う。
【００７１】
本発明の方式をＯｐｅｎＦｌｏｗに適用することにより、以下の効果が得られる。
・ＯｐｅｎＦｌｏｗコントローラの負荷を複数のＯｐｅｎＦｌｏｗコントローラで分散処理でき、性能面の課題が解決できる。
・利用中のＯｐｅｎＦｌｏｗコントローラが障害になった場合にも、別に稼動するＯｐｅｎＦｌｏｗコントローラを動的に選び直すことができ、信頼性面での課題が解決できる。
【００７２】
図１３は、本発明による方式を適用して任意のサービス提供側装置の多重化を実現したシステム構成の一例を示す図である。
サービス提供側１３０１には、多重化されたサービス提供側装置（１３０２、１３０３、１３０４）が設けられている。サービス利用側１３０６には、少なくとも１つのサービス利用側装置（１３０７）が存在する。多くのシステムでは、複数のサービル利用側装置（１３０７、１３０８、１３０９）が存在する。
【００７３】
なお、図１３には、適宜のコンピュータであるこれらの装置の機能のうち、本発明の方式を適用するための機能のみを示しており、これらの装置の本来のサービス等に関連する機能については示していない。本発明の方式に関連する機能は、各装置に導入された所定のプログラムにより実現される。各装置のＣＰＵが、所定のプログラムをメモリに読み込み実行する。
【００７４】
サービス提供側装置（１３０２、１３０３、１３０４）の各々は、ユニークな実識別情報と、共通の仮想識別情報とからなる２つの識別情報を予め設定されており、これらの識別情報は適宜の記憶装置（１３０２ｄ）に格納されている。これらの識別情報は、適宜のネットワークにおいて通信先や通信経路を指定するために用いられるものである。図１３における実識別情報及び仮想識別情報は、上述した例における実ＩＰアドレス及び仮想ＩＰアドレスにそれぞれ対応する。なお、ＩＰアドレスに替えてＭＡＣアドレスでもよい。
【００７５】
また、サービス提供側装置の記憶装置（１３０２ｄ）には、サービス提供側装置の現時点の処理負荷のレベルを示す処理負荷レベル情報も格納される。この処理負荷レベル情報は、上述した例におけるコネクション数に対応する。
【００７６】
一方、サービス利用側装置（１３０７、１３０８、１３０９）の各々は、通信先となり得る複数のサービス提供側装置に共通する仮想識別情報を、適宜の記憶装置（１３０７ｄ）に予め格納している。
【００７７】
例えば、サービス利用側装置１（１３０７）が、サービス提供側装置に通信開始要求を送信する時、識別情報送信部（１３０７ａ）が、仮想識別情報を記憶装置１３０７ｄから取得し、仮想識別情報により通信先を指定して通信開始要求を送信する。
【００７８】
各サービス提供側装置（１３０２、１３０３、１３０４）は、それぞれ通信開始要求を受信する。続いて、各サービス提供側装置の稼働情報応答部（１３０２ａ）は、通信開始要求に対する応答として稼働情報をサービス利用側装置１（１３０７）に返す。この稼働情報には、実識別情報と処理負荷レベル情報が含まれている。
【００７９】
サービス利用側装置１（１３０７）は、各サービス提供側装置からの応答すなわち稼働情報を受信する。サービス利用側装置１の通信先決定部（１３０７ｂ）は、各稼働情報に含まれている処理負荷レベル情報を比較することにより、処理負荷が現時点で最小であるサービス提供側装置を選択する。選択したサービス提供側装置を通信先として決定する。その後、決定したサービス提供側装置の実識別情報を使用してそのサービス提供側装置との間で通信を行う。
【００８０】
なお、処理負荷レベル情報の好適例は、上述したコネクション数であるが、これに限られない。例えば、現時点の処理タスク量、メモリ使用量等を処理負荷レベル情報として利用できる。処理負荷レベル情報としては、サービス提供側装置が、通常、当然に保有している数値等をそのまま利用することが好ましい。そして、サービス利用側装置の通信先決定部は、処理負荷レベル情報に基づいて、現時点において処理負荷が最小であるサービス提供側装置を通信先として決定する。これは、複数のサービス提供側装置の処理負荷を均一とするためである。
【００８１】
サービス提供側装置の処理負荷レベル情報管理部（１３０２ｂ）は、処理負荷レベル情報の記憶装置（１３０２ｄ）への格納及び更新を管理する。処理負荷レベル情報がコネクション数の場合、処理負荷レベル情報管理部は、１つのサービス利用側装置との通信を開始したとき、記憶装置に格納したコネクション数を１だけ増分して更新する。１つのサービス利用側装置との通信が完了したときは、コネクション数を１だけ減らす。
【００８２】
通信中、サービス利用側装置１（１３０７）の障害監視部（１３０７ｃ）は、Ｈｅａｒｔ  Ｂｅａｔパケット等の監視用情報をサービス提供側装置に定期的に送信する。サービス提供側装置の監視応答部（１３０２ｃ）は、監視用情報を受信したとき、それに対して応答を返す。サービス利用側装置１の障害監視部（１３０７ｃ）は、監視用情報に対する応答が途絶えることにより、障害発生を検知する。
【００８３】
障害発生を検知したサービス利用側装置１では、再度、識別情報送信部（１３０７ａ）が仮想識別情報を用いて各サービス提供装置に対して通信開始要求を送信し、最初と同様の手順により通信先のサービス提供側装置を決定する。
【００８４】
図１３に示した多重化されたサービス提供側装置は、例えば、図１に示した多重化された負荷分散装置若しくは図１２に示したＯｐｅｎＦｌｏｗにおける多重化されたＯｐｅｎＦｌｏｗコントローラ等の多重化されたネットワーク装置、又は、図１１に示したサービス提供側の多重化されたサーバ装置に対応する。
【００８５】
図１３に示したサービス利用側装置は、例えば、図１若しくは図１１に示したサービス利用側のクライアントＰＣ若しくはサーバ装置、又は、図１２に示したＯｐｅｎＦｌｏｗにおけるＯｐｅｎＦｌｏｗスイッチに対応する。
【符号の説明】
【００８６】
１０１、２０１、３０１、１３０１：サビース提供側
１０２、１０３、１０４、２０２、２０３、２０４、３０２、３０３、３０４、４０１、４０２、４０３、４０９、４１０、４１１、８０１、８０７、９０１、９０７、１１０１、１１０２、１１０３、１１０６、１１０７、１１０８、１１１１、１１１２、１１１３、１１１６、１１１７、１１１８：サービス提供側のサーバ装置
１０５、１０８、１１１、２０５、３０５、３０６、４０４、４０５、４１２、４１３、５０１、５０２、５０３、５０４、６０１、６０２、６０３、６０４、６０５、６０６、７０５、７０９、７１２、８０２、８０３、８０４、８０８、８０９、８１０、９０２、９０３、９０４、９０８、９０９、９１０：負荷分散装置
１０６、１０９、１１２：負荷分散装置が保有する仮想ＩＰアドレスと実ＩＰアドレス
１０７、１１０、１１３：負荷分散装置が保有するコネクション数
１１４、２０６、３０７、４０６、４１４、８０５、８１１、９０５、９１１、１１０４、１１０９、１１１４、１１１９、１３０５：ネットワーク
１１５、２０７、３０８、１３０６：サービス利用側
１１６、２０８、３０９、４０７、４１５：サービス利用側のサーバ装置
１１７、２０９、３１０、４０８、４１６、７０１、８０６、８１２、９０６、９１２、１１０５、１１１０、１１１５、１１２０：サービス利用側のクライアントＰＣ
７０２、７０３、７０４：クライアントＰＣでの処理
７０６、７０７、７０８、７１０、７１１、７１３、７１４：負荷分散装置での処理
１００１：従来方式と本発明による方式に関する比較表
１２０１、１２０５、１２０６、１２０７：ＯｐｅｎＦｌｏｗコントローラ
１２０２、１２０３、１２０４、１２０８、１２０９、１２１０：ＯｐｅｎＦｌｏｗスイッチ
１３０２、１３０２、１３０４：サービス提供側装置
１３０２ａ：識別情報応答部
１３０２ｂ：コネクション数管理部
１３０２ｃ：監視応答部
１３０３ｄ：記憶装置
１３０７ａ：識別情報送信部
１３０７ｂ：通信先決定部
１３０７ｃ：障害監視部
１３０７ｄ：記憶装置
【図１】
2014032576.tif 000003
【図２】
2014032576.tif 000004
【図３】
2014032576.tif 000005
【図４】
2014032576.tif 000006
【図５】
2014032576.tif 000007
【図６】
2014032576.tif 000008
【図７】
2014032576.tif 000009
【図８】
2014032576.tif 000010
【図９】
2014032576.tif 000011
【図１０】
2014032576.tif 000012
【図１１】
2014032576.tif 000013
【図１２】
2014032576.tif 000014
【図１３】
2014032576.tif 000015