(57)【要約】【課題】異常により負荷が低いサーバを選択することなく負荷分散を行う。【解決手段】試験装置２が接続するＬＮＳを指定して対象サイトのｒａｄｉｕｓサーバ２０に定期的に接続試験を行い、接続試験が失敗した場合に、ｐｒｏｘｙ−ｒａｄｉｕｓサーバ１にＬＮＳの状態を通知し、ｐｒｏｘｙ−ｒａｄｉｕｓサーバ１が通知を受けてＬＮＳ状態テーブルの該当ＬＮＳの状態を変更し、ＬＮＳ状態テーブルを参照して異常ＬＮＳを除いた接続先ＬＮＳリストを生成する。これにより、異常ＬＮＳへの新規接続を回避するとともに、接続先ＬＮＳリストを用いて正常なＬＮＳの負荷分散を行うことができる。【選択図】図１
2013191127.tif 000002
【特許請求の範囲】
【請求項１】
複数のサーバから１つのサーバを選択して通信経路を確立するネットワーク装置が前記サーバの選択時に参照する接続先サーバリストを生成する負荷分散装置と前記サーバの正常性を試験する試験装置とを備える負荷分散システムであって、
前記負荷分散装置は、
前記複数のサーバそれぞれの状態を記載したサーバ状態リストを保持する記憶手段と、
前記試験装置から前記サーバの状態を受信して前記サーバ状態リストを更新する更新手段と、
前記サーバ状態リストを参照して正常な状態の前記サーバのみを記載した前記接続先サーバリストを生成し、前記ネットワーク装置に送信する生成手段と、を有し、
前記試験装置は、
前記複数のサーバそれぞれに対して接続試験を行う接続手段と、
前記接続試験により検知した前記サーバの状態を前記負荷分散装置に通知する通知手段と、を有すること
を特徴とする負荷分散システム。
【請求項２】
複数のサーバから１つのサーバを選択して通信経路を確立するネットワーク装置が前記サーバの選択時に参照する接続先サーバリストを生成する負荷分散装置と前記サーバの正常性を試験する試験装置による負荷分散方法であって、
前記負荷分散装置による、
前記試験装置から前記サーバの状態を受信して記憶手段に保持された前記複数のサーバそれぞれの状態を記載したサーバ状態リストを更新するステップと、
前記サーバ状態リストを参照して正常な状態の前記サーバのみを記載した前記接続先サーバリストを生成し、前記ネットワーク装置に送信するステップと、を有し、
前記試験装置による、
前記複数のサーバそれぞれに対して接続試験を行うステップと、
前記接続試験により検知した前記サーバの状態を前記負荷分散装置に通知するステップと、を有すること
を特徴とする負荷分散方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のサーバから１つのサーバを選択して通信経路を確立する際の負荷分散技術に関する。
【背景技術】
【０００２】
Ｌ２ＴＰを使ったＶＰＮを介して端末を所定サイトに接続する場合、端末がＬＡＣ（Ｌ２ＴＰ  Ａｃｃｅｓｓ  Ｃｏｎｃｅｎｔｒａｔｏｒ）に接続要求を送信し、ＬＡＣが適切なＬＮＳ（Ｌ２ＴＰ  Ｎｅｔｗｏｒｋ  Ｓｅｒｖｅｒ）を選択しＬ２ＴＰトンネルを張って端末と所定サイトとの間の通信経路を確立する。
【０００３】
現在、Ｌ２ＴＰによるＶＰＮ接続システムにおいて、ＬＡＣが複数のＬＮＳから１台のＬＮＳを選択する場合、自ＬＡＣから見てセッション数が一番少ないＬＮＳを選択することで負荷分散を行っている。この負荷分散方式は、ＬＮＳ及び接続先サイト側のネットワークが正常な場合においては、セッション数が一番少ない（＝負荷の少ない）ＬＮＳを通るため、ＬＮＳの負荷分散になり安定的な接続環境を提供できている。
【０００４】
ここで、上記の負荷分散方式を具体的に説明する。図８はＬＡＣと複数のＬＮＳからなるＶＰＮ接続システムの例を示す図である。サイトＡ（ａａａ．ｃｏｍ）のユーザが端末１０からＬＡＣに対して接続要求を送信すると（ステップＳ１０１）、ＬＡＣがｐｒｏｘｙ−ｒａｄｉｕｓサーバに対してサイトＡの接続先ＬＮＳリストを要求し（ステップＳ１０２）、ｐｒｏｘｙ−ｒａｄｉｕｓサーバは、サイトＡの接続先ＬＮＳリストをＬＡＣに払い出す（ステップＳ１０３）。接続先ＬＮＳリストには、サイトＡのＬＮＳ１００，２００，３００が記載されている。そして、ＬＡＣは、接続先ＬＮＳリストの中からセッション数が一番少ないＬＮＳ３００を選択して接続する。その後、サイトＡのｒａｄｉｕｓサーバ２０とｒａｄｉｕｓ認証を行って端末１０がサイトＡに接続される。
【０００５】
なお、特許文献１には、ＬＮＳの稼働情報（ＣＰＵ使用率、メモリ使用率など）を取得して負荷分散を行う発明が記載されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００５−２２８０３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ＬＮＳが完全停止状態ではない故障時（例えば、ＬＮＳのサイト側ネットワークやＬＮＳの一部のプロセスの故障、ＬＮＳが再起動を繰り返すなど不安定な状態）において、当該ＬＮＳのセッションはゼロか他のＬＮＳと比べて少ない状態となる。図８に示す例では、ＬＮＳ３００のサイト側ネットワークに故障が発生しており、ＬＮＳ１００，２００，３００のセッション数はそれぞれ３本、２本、０本である。このとき、上述した負荷分散方式によると、セッション数が一番すくないＬＮＳ３００へ優先的に接続するため、ＬＡＣからの接続要求は故障しているＬＮＳ３００に集中し、結果、他に接続可能なＬＮＳ１００，２００があるにもかかわらず、全ユーザからの新規接続が不能となるという問題があった。
【０００８】
ＬＮＳの正常性の確認方法は、ネットワーク監視装置からのｐｉｎｇやＳＮＭＰによる死活監視があるが、この方法では、Ｌ２ＴＰレベルの正常性確認、ＬＮＳ〜接続先サイト間の正常性確認ができないという問題があった。
【０００９】
本発明は、上記に鑑みてなされたものであり、異常により負荷が低いサーバを選択することなく負荷分散を行うことを目的とする。
【課題を解決するための手段】
【００１０】
第１の本発明に係る負荷分散システムは、複数のサーバから１つのサーバを選択して通信経路を確立するネットワーク装置が前記サーバの選択時に参照する接続先サーバリストを生成する負荷分散装置と前記サーバの正常性を試験する試験装置とを備える負荷分散システムであって、前記負荷分散装置は、前記複数のサーバそれぞれの状態を記載したサーバ状態リストを保持する記憶手段と、前記試験装置から前記サーバの状態を受信して前記サーバ状態リストを更新する更新手段と、前記サーバ状態リストを参照して正常な状態の前記サーバのみを記載した前記接続先サーバリストを生成し、前記ネットワーク装置に送信する生成手段と、を有し、前記試験装置は、前記複数のサーバそれぞれに対して接続試験を行う接続手段と、前記接続試験により検知した前記サーバの状態を前記負荷分散装置に通知する通知手段と、を有することを特徴とする。
【００１１】
第２の本発明に係る負荷分散方法は、複数のサーバから１つのサーバを選択して通信経路を確立するネットワーク装置が前記サーバの選択時に参照する接続先サーバリストを生成する負荷分散装置と前記サーバの正常性を試験する試験装置による負荷分散方法であって、前記負荷分散装置による、前記試験装置から前記サーバの状態を受信して記憶手段に保持された前記複数のサーバそれぞれの状態を記載したサーバ状態リストを更新するステップと、前記サーバ状態リストを参照して正常な状態の前記サーバのみを記載した前記接続先サーバリストを生成し、前記ネットワーク装置に送信するステップと、を有し、前記試験装置による、前記複数のサーバそれぞれに対して接続試験を行うステップと、前記接続試験により検知した前記サーバの状態を前記負荷分散装置に通知するステップと、を有することを特徴とする。
【発明の効果】
【００１２】
本発明によれば、異常により負荷が低いサーバを選択することなく負荷分散を行うことができる。
【図面の簡単な説明】
【００１３】
【図１】本実施の形態における負荷分散システムを含む全体構成図である。
【図２】ＬＮＳ状態リストの例を示す図である。
【図３】ＬＮＳ管理リストの例を示す図である。
【図４】試験接続のためのアカウント情報の例を示す図である。
【図５】試験装置が接続確認を行い、ＬＮＳ状態リストを更新する処理の流れを示すフローチャートである。
【図６】ＬＮＳ状態リストと接続先ＬＮＳリストの例を示す図である。
【図７】接続確認が失敗したＬＮＳが復活したときにＬＮＳ状態リストを更新する処理の流れを示すフローチャートである。
【図８】ＬＡＣと複数のＬＮＳからなるＶＰＮ接続システムの例を示す図である。
【発明を実施するための形態】
【００１４】
以下、本発明の実施の形態について図面を用いて説明する。
【００１５】
図１は、本実施の形態における負荷分散システムを含む全体構成図である。本実施の形態における負荷分散システムは、ｐｒｏｘｙ−ｒａｄｉｕｓサーバ１、試験装置２、記憶装置３、ＬＡＣ、および複数のＬＮＳ１００，２００，３００を有する。
【００１６】
ｐｒｏｘｙ−ｒａｄｉｕｓサーバ１は、ＬＡＣからの問い合わせに応じて、記憶装置３に格納したＬＮＳ状態リスト、ＬＮＳ管理リストを参照し、所望サイトのＬＮＳのうち、状態がＡＣＴＩＶＥなＬＮＳの情報（ＬＮＳのＩＰアドレスなど）を記載した接続先ＬＮＳリストを返す。図２に、ＬＮＳ状態リストの例を示す。ＬＮＳ状態リストには、各ＬＮＳ１００，２００，３００の状態（ＡＣＴＩＶＥ，ＤＯＷＮ）が保持される。ＡＣＴＩＶＥはそのＬＮＳが利用できることを示し、ＤＯＷＮはそのＬＮＳが利用できないことを示す。図３に、ＬＮＳ管理リストの例を示す。ＬＮＳ管理リストには、各ＬＮＳ１００，２００，３００の識別子、ＩＰアドレスなどの情報が保持される。
【００１７】
また、ｐｒｏｘｙ−ｒａｄｉｕｓサーバ１は、試験装置２からＬＮＳの状態の通知を受けて、記憶装置３に格納したＬＮＳ状態リストの状態を更新する。
【００１８】
試験装置２は、定期的に、接続するＬＮＳを指定して対象サイトのｒａｄｉｕｓサーバ２０に試験接続し、ＬＮＳ及びＬＮＳと対象サイト間のネットワークの正常性を確認して、接続結果（ＬＮＳの状態）をｐｒｏｘｙ−ｒａｄｉｕｓサーバ１に通知する。図４に、試験装置２が保持する試験接続のためのアカウント情報の例を示す。アカウント情報には、試験接続を行う対象サイトのｒａｄｉｕｓサーバ２０の認証で用いるユーザＩＤ、パスワードなどが記載される。アカウント情報は、試験装置２とｒａｄｉｕｓサーバ２０で保持される。
【００１９】
ＬＡＣは、ユーザの端末１０から接続要求を受け付けて、ｐｒｏｘｙ−ｒａｄｉｕｓサーバ１にユーザが接続を希望するサイトの接続先ＬＮＳリストを要求し、接続先ＬＮＳリストの中からセッション数が一番少ないＬＮＳを選択して接続する。
【００２０】
ＬＮＳは、ＬＡＣとの間でＬ２ＴＰトンネルを確立し、ユーザの端末１０を所望サイトに接続する。
【００２１】
次に、本実施の形態における負荷分散システムの動作について説明する。
【００２２】
まず、ＬＮＳが故障したときのＬＮＳ状態リスト更新処理について説明する。
【００２３】
図５は、試験装置が接続確認を行い、ＬＮＳ状態リストを更新する処理の流れを示すフローチャートである。
【００２４】
まず、試験装置２がＬＮＳを一つ選択し、選択したＬＮＳを指定して対象サイトのｒａｄｉｕｓサーバ２０に接続を試みる（ステップＳ１１）。
【００２５】
ｒａｄｉｕｓサーバ２０でｒａｄｉｕｓ認証を行い（ステップＳ１２）、認証結果がＯＫの場合は、別のＬＮＳを選択し（ステップＳ１３）、ステップＳ１１に戻り新たに選択したＬＮＳを指定して接続を試みる。
【００２６】
対象サイトのｒａｄｉｕｓサーバ２０に接続できないなど、認証結果がＮＧの場合は、ＮＧの回数が所定の回数（ここでは３回）に達したか否かを判定し（ステップＳ１４）、所定の回数に達していないときは、数分待機した後（ステップＳ１５）、ステップＳ１１に戻り同じＬＮＳを指定して接続を試みる。
【００２７】
認証結果がＮＧの回数が所定の回数に達した場合は、アラームを発出するとともに（ステップＳ１６）、対象サイトのｒａｄｉｕｓサーバ２０に接続ができなかったＬＮＳの情報（ホスト名、識別子など）をｐｒｏｘｙ−ｒａｄｉｕｓサーバ１へ通知する（ステップＳ１７）。
【００２８】
通知を受け取ったｐｒｏｘｙ−ｒａｄｉｕｓサーバ１は、ＬＮＳ状態リストの該当ＬＮＳの状態をＡＣＴＩＶＥからＤＯＷＮに変更し（ステップＳ１８）、接続先ＬＮＳリストから該当ＬＮＳを削除する（ステップＳ１９）。
【００２９】
図６は、ＬＮＳ状態リストと接続先ＬＮＳリストの例を示す図である。図６（ａ）は、ＬＮＳ１００，２００，３００の全てがＡＣＴＩＶＥなＬＮＳ状態リスト（図上側）とそのＬＮＳ状態リストから作成される接続先ＬＮＳリスト（図下側）を示し、図６（ｂ）は、ＬＮＳ３００がＤＯＷＮとなったＬＮＳ状態リスト（図上側）とそのＬＮＳ状態リストから作成される接続先ＬＮＳリスト（図下側）を示す。図６に示す接続先ＬＮＳリストには、ａａａ．ｃｏｍ，ａｂｃ．ｃｏｍ，ｘｙｚ．ｃｏｍの３つのサイトのＬＮＳが記載されている。
【００３０】
図６（ｂ）のように、ＬＮＳ３００の状態がＤＯＷＮとなると、接続先ＬＮＳリストからＬＮＳ３００のＩＰアドレス（１００．１．１．３０）が削除される。図６（ｂ）の接続先ＬＮＳリストでは、ａａａ．ｃｏｍ，ａｂｃ．ｃｏｍのサイトのＬＮＳ３００が削除される。
【００３１】
続いて、ＬＮＳが復活したときのＬＮＳ状態リスト更新処理について説明する。
【００３２】
図７は、接続確認が失敗したＬＮＳが復活したときにＬＮＳ状態リストを更新する処理の流れを示すフローチャートである。
【００３３】
図５のステップＳ１６で試験装置２がアラームを発出し、所定時間（ここでは３０分）待機した後（ステップＳ２１）、該当ＬＮＳを指定して対象サイトのｒａｄｉｕｓサーバ２０に接続を試みる（ステップＳ２２）。
【００３４】
ｒａｄｉｕｓサーバ２０でｒａｄｉｕｓ認証を行い（ステップＳ２３）、認証結果がＮＧの場合は、ステップＳ２１に戻り所定時間待機する。
【００３５】
認証結果がＯＫの場合、該当ＬＮＳを指定して対象サイトのｒａｄｉｕｓサーバ２０に接続ができた旨をｐｒｏｘｙ−ｒａｄｉｕｓサーバ１へ通知する（ステップＳ２４）。
【００３６】
通知を受け取ったｐｒｏｘｙ−ｒａｄｉｕｓサーバ１は、ＬＮＳ状態リストの該当ＬＮＳの状態をＤＯＷＮからＡＣＴＩＶＥに変更し（ステップＳ２５）、接続先ＬＮＳリストの該当ＬＮＳを復活させる（ステップＳ２６）。
【００３７】
以上説明したように、本実施の形態によれば、試験装置２が接続するＬＮＳを指定して対象サイトのｒａｄｉｕｓサーバ２０に定期的に接続試験を行い、接続試験が失敗した場合に、ｐｒｏｘｙ−ｒａｄｉｕｓサーバ１にＬＮＳの状態を通知し、ｐｒｏｘｙ−ｒａｄｉｕｓサーバ１が通知を受けてＬＮＳ状態リストの該当ＬＮＳの状態を変更し、ＬＮＳ状態リストを参照して異常ＬＮＳを除いた接続先ＬＮＳリストを生成することにより、異常ＬＮＳへの新規接続を回避するとともに、接続先ＬＮＳリストを用いて正常なＬＮＳの負荷分散を行うことができる。また、試験装置２がＬＮＳの正常性を検出し、ｐｒｏｘｙ−ｒａｄｉｕｓサーバ１が異常ＬＮＳを接続先ＬＮＳリストから取り除くので、人手によるコンフィグ設定変更などの対処が不要であり、さらに、ＬＡＣ、ＬＮＳには機能追加、設定追加が不要である。
【００３８】
なお、本実施例では、Ｌ２ＴＰを使ったＶＰＮを例に説明したが、これに限定するものではなく、Ｌ２ＴＰ以外のＶＰＮにも適用可能である。
【符号の説明】
【００３９】
１…ｐｒｏｘｙ−ｒａｄｉｕｓサーバ
２…試験装置
３…記憶装置
１０…端末
２０…ｒａｄｉｕｓサーバ
【図１】
2013191127.tif 000003
【図２】
2013191127.tif 000004
【図３】
2013191127.tif 000005
【図４】
2013191127.tif 000006
【図５】
2013191127.tif 000007
【図６】
2013191127.tif 000008
【図７】
2013191127.tif 000009
【図８】
2013191127.tif 000010