(57)【要約】      （修正有）【課題】サーバのサービス割り当てとパスのトラフィック割り当てを均衡にするとともにリソースの割り当て効率を改善できる負荷均衡装置及び負荷均衡方法を提供する。【解決手段】サービスのサーバリソース需要とネットワーク伝送リソース需要に基づいてサービスを複数のサービスブロックに分割するとともに前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを複数のリソースブロックに分割し、サーバに対するアイドルサーバリソースとアイドルネットワーク伝送リソースの組み合わせを各リソースブロックと対応付け、データセンターネットワークに進入するサービス要求の属するサービスブロックを識別し、前記サービスブロックと前記リソースブロックとの対応関係に基づいて、前記アイドルサーバリソースとアイドルネットワーク伝送リソースの組み合わせを当該サービス要求に割り当てる。【選択図】図２
2013168934.tif 000002
【特許請求の範囲】
【請求項１】
データセンターネットワークにおいて負荷均衡のリソース割り当てを行なう負荷均衡装置であって、
サービスのサーバリソース需要とネットワーク伝送リソース需要に基づいてサービスを複数のサービスブロックに分割するとともに前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを複数のリソースブロックに分割し、
前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを監視することにより、サーバに対するアイドルサーバリソースとアイドルネットワーク伝送リソースとの組み合わせを各リソースブロックと対応付け、
データセンターネットワークに進入するサービス要求の属するサービスブロックを識別し、前記サービスブロックと前記リソースブロックとの間の対応関係に基づいて、前記アイドルサーバリソースとアイドルネットワーク伝送リソースとの組み合わせを当該サービス要求に割り当てる
ことを特徴とする負荷均衡装置。
【請求項２】
前記サービス要求および監視メッセージを受信するデータ受信ユニットと、
前記データ受信ユニットから受信した前記サービス要求および前記監視メッセージを処理するデータ処理ユニットと、
前記データセンターネットワークのリソース情報およびデータ処理に必要な情報を記憶する記憶装置と、
前記データ処理ユニットの処理結果に基づいて、前記サービス要求を転送するデータ転送ユニットと、を備える
ことを特徴とする請求項１に記載の負荷均衡装置。
【請求項３】
前記監視メッセージは前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースの情報を含み、
前記データ処理ユニットは前記監視メッセージに基づいて各前記アイドルサーバリソースとアイドルネットワーク伝送リソースの組み合わせと前記リソースブロックとの対応関係を更新する
ことを特徴とする請求項２に記載の負荷均衡装置。
【請求項４】
前記負荷均衡装置の初期化プロセスにおいて、前記データ処理ユニットは前記サーバリソース需要の値空間を複数のサブ空間に分割し、前記ネットワーク伝送リソース需要の値空間を複数のサブ空間に分割することにより、前記サーバリソース需要と前記ネットワーク伝送リソース需要から構成された二次元空間を複数のサービスブロックに分割し、
前記データ処理ユニットはアイドルサーバリソースとアイドルネットワーク伝送リソースから構成された二次元空間を、前記複数のサービスブロックにそれぞれ対応する複数のリソースブロックに分割する
ことを特徴とする請求項２に記載の負荷均衡装置。
【請求項５】
前記データ処理ユニットは受信したサービス要求のサービス種別を識別し、当該サービス要求に対応するサービスブロックを判定し、
前記データ処理ユニットは複数のリソースブロックから当該サービス要求の対応するサービスブロック位置に対応するリソースブロックを確定し、当該リソースブロックに対応するアイドルサーバリソースとアイドルネットワーク伝送リソースの組み合わせから当該サービス要求のリソース需要を満たす組み合わせを検索する
ことを特徴とする請求項４に記載の負荷均衡装置。
【請求項６】
前記データ処理ユニットは受信したサービス要求のサービス種別を識別し、当該サービス要求に対応するサービスブロックを判定し、
前記データ処理ユニットは複数のリソースブロックから当該サービス要求の対応するサービスブロック位置に対応するリソースブロックを確定し、当該リソースブロックに対応するアイドルサーバリソースとアイドルネットワーク伝送リソースの組み合わせに当該サービス要求のリソース需要を満たす組み合わせが存在しない場合は、リソース需要を満たす組み合わせが見つかるまでに、当該リソースブロックを中心に近から遠に向かって隣接するリソースブロックに対してスクロース検索を行なう
ことを特徴とする請求項４に記載の負荷均衡装置。
【請求項７】
検索された当該サービス要求のリソース需要を満たす組み合わせが複数である場合、当該サービス要求が前記各組み合わせを利用するときのリソース消費をそれぞれ計算し、最小のリソース消費に対応する組み合わせを選択する
ことを特徴とする請求項５または６に記載の負荷均衡装置。
【請求項８】
前記サーバリソース需要はサーバのＣＰＵ使用率で、前記ネットワーク伝送リソース需要は当該サービスを伝送する際の下り方向バンド幅需要、上り方向バンド幅需要、あるいは上り下り双方向上のバンド幅需要の小値もしくは平均値であり、
前記アイドルサーバリソースはサーバのＣＰＵ未使用率で、前記アイドルネットワーク伝送リソースは当該サーバに関連するパスの下り方向利用可能なバンド幅、上り方向利用可能なバンド幅、または上り下り双方向上の利用可能なバンド幅の小値もしくは平均値である
ことを特徴とする請求項１に記載の負荷均衡装置。
【請求項９】
前記サーバリソース需要はサーバのＣＰＵ使用率で、前記ネットワーク伝送リソース需要は当該サービスを伝送する際の下り方向バンド幅需要と上り方向バンド幅需要であり、
前記アイドルサーバリソースはサーバのＣＰＵ未使用率で、前記アイドルネットワーク伝送リソースは当該サーバに関連するパスの下り方向利用可能なバンド幅と上り方向利用可能なバンド幅である
ことを特徴とする請求項１に記載の負荷均衡装置。
【請求項１０】
前記負荷均衡装置の初期化段階において、前記ＣＰＵ使用率の値空間を複数のサブ空間に分割し、前記当該サービスを伝送するときの下り方向バンド幅需要と上り方向バンド幅需要の値空間をそれぞれ複数のサブ空間に分割することにより、前記ＣＰＵ使用率、前記サ下り方向バンド幅需要及び前記上り方向バンド幅需要から構成された三次元空間を複数のサービスブロックに分割し、
前記ＣＰＵ未使用率、前記下り方向利用可能なバンド幅及び前記上り方向利用可能なバンド幅から構成された三次元空間を前記複数のサービスブロックにそれぞれ対応する複数のリソースブロックに分割する
ことを特徴とする請求項９に記載の負荷均衡装置。
【請求項１１】
データセンターネットワークにおいて負荷均衡のリソース割り当てを行なう負荷均衡方法であって、
サービスのサーバリソース需要とネットワーク伝送リソース需要に基づいてサービスを複数のサービスブロックに分割するとともに前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを複数のリソースブロックに分割する分割ステップと、
前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを監視することにより、サーバに対するアイドルサーバリソースとアイドルネットワーク伝送リソースの組み合わせを各リソースブロックと対応付ける監視ステップと、
データセンターネットワークに進入するサービス要求の属するサービスブロックを識別し、前記サービスブロックと前記リソースブロックとの間の対応関係に基づいて、前記アイドルサーバリソースとアイドルネットワーク伝送リソースとの組み合わせを当該サービス要求に割り当てる割当ステップと、を有する
ことを特徴とする負荷均衡方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は負荷均衡方法に関し、特にデータセンター分野に応用されるとともにネットワークリソースとサーバリソースの利用効率を改善する負荷均衡装置及び負荷均衡方法に関する。
【背景技術】
【０００２】
特許文献１では、リソース管理装置によってリソース情報を収集して負荷均衡装置に配信し、負荷均衡装置によって受信したリソース情報と予め決められたリソース割り当てポリシーに基づいて適切なバッファサーバを選択することで、システムの性能と効率を向上させるコンテンツ配信ネットワークにおける負荷均衡方法が提案されている。そのうち、使用されるリソース情報にはサーバのメモリ容量、メモリ容量使用済みパーセンテージ、ＣＰＵ使用率、サーバ出口総バンド幅及びバンド幅使用率が含まれている。リソース割り当てポリシーの表現形式はサーバノードの選択アルゴリズムであり、出力は利用可能なサーバのシーケンスリストである。例えば、リソース割り当てポリシーは、ＣＰＵ使用率が低いノードを優先的に選択し、各ノードのＣＰＵ使用率差異が一定の範囲内（例えば、５％〜１０％）にある場合は、利用可能なバンド幅が大きいノードを優先的に選択し、各ノードの利用可能なバンド幅の使用率差異が一定の範囲内（例えば５％〜１０％）にある場合は、利用可能な記憶空間が大きいノードを優先的に選択するように設定することができる。
【０００３】
特許文献１で提案された負荷均衡方法においては、サーバのサービス処理能力とサーバの負荷均衡のみを考慮し、当該サーバに到着するネットワークリンクの利用可能なバンド幅は考慮していなかったため、輻輳が発生し易いネットワーク環境において、サービス品質、特に高バンド幅を必要とするサービスに対してサービス品質の有効な保証ができない問題点がある。
【０００４】
特許文献２では、サービスのリソース需要に応じて、オーバレイネットワークにおいてエンドツーエンド（Ｅｎｄ−ｔｏ−Ｅｎｄ）の最適負荷均衡サービスパスを検索してサービスのＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）需要を満たせるオーバレイネットワークにおける負荷均衡方法が提案されている。特許文献２は特許文献１の問題点を改善し、同時にノードの計算リソースとパスの伝送リソースがいずれもサービスのリソース需要を満たすことができるかどうかを考慮し、その中から最適なパスを一つ選択してユーザ要求に応答し、これによりユーザ体験を改善し、ネットワークリソースの利用効率を最適化する。しかしながら、当該特許文献における方法は、現在のサービス需要のための最適なリソース割り当てのみを考慮し、サービスの異なるリソース需要に対する相違性及び全体のリソース利用率の最大化を考慮していなかったため、サービスの動的変化、特に将来のリソース需要に対して不均衡なサービスの突発に適応することが難しい問題点がある。また、それぞれの到着したサービス要求に対して、最適なサービスパスを見つけるために、ネットワークに存在するすべての可能なパスを新たに検索する必要があるため、計算量が大きく、サービス効率が低下してしまう。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】中国特許公開番号１０１４３１５３２Ａ
【特許文献２】中国特許公開番号１０２０５５６６３Ａ
【０００６】
全体のリソース利用効率を最適化し、データセンターネットワークのサービス能力をさらに改善するために、本発明はルーティング意識を有する負荷均衡装置及び方法を提供し、サービス需要とネットワークリソースとの最適なマッチングを考慮にいれて、現在サーバの利用可能な負荷及びパスの利用可能なバンド幅を結び付けて、サーバ及びルーティングの組み合わせをサービスに割り当てる割り当て案を提供する。現在のデータセンター、特にモノのインターネット向けのデータセンターは複数のサービス種別をサポートし、例えば、検索に基づくサービスは低バンド幅と大量の計算リソースを必要とし、ビデオオンデマンドサービスは高バンド幅と少量の計算リソースを必要とし、センサーのサービスは低バンド幅と少量の計算リソースを必要とするように、異なる種類のサービスのサーバリソースとネットワークバンド幅リソースに対する需要にも相違がある。ユーザ行為が予知できないモノのインターネット応用については、サービストラフィックの不均等な分布につれて、あるサービスが集中したリンクにはバンド幅の利用率は高いが互いに接続されているサーバの負荷は非常に軽く、逆に、あるリンクにはバンド幅の利用率は低いが互いに接続されているサーバの負荷は重い可能性がある。前者はサービスの性能を低下させ、後者は大量のバンド幅リソースを無駄にする。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明は、動的データセンターネットワークにおいて異なるリソース需要のサービスに対してそのリソースとマッチング度合が最適なサーバ及びルーティングの組み合わせを選択し、サーバのサービス割り当てとパスのトラフィック割り当てを均衡にするとともにリソースの割り当て効率を改善し、これにより全体のリソース利用を最大化し、ネットワークの処理容量を向上させ、データセンターの建設コストを節約することができる負荷均衡装置及び負荷均衡方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上述の目的を達するための本発明に係わる負荷均衡装置は、データセンターネットワークにおいて負荷均衡のリソース割り当てを行なう負荷均衡装置であって、サービスのサーバリソース需要とネットワーク伝送リソース需要に基づいてサービスを複数のサービスブロックに分割するとともに前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを複数のリソースブロックに分割し、前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを監視することにより、サーバに対するアイドルサーバリソースとアイドルネットワーク伝送リソースとの組み合わせを各リソースブロックと対応付け、データセンターネットワークに進入するサービス要求の属するサービスブロックを識別し、前記サービスブロックと前記リソースブロックとの間の対応関係に基づいて、当該サービス要求に対して前記アイドルサーバリソースとアイドルネットワーク伝送リソースとの組み合わせを割り当てることを特徴とする。
【０００９】
上述の目的を達するための本発明に係わる負荷均衡方法は、データセンターネットワークにおいて負荷均衡のリソース割り当てを行なう負荷均衡方法であって、サービスのサーバリソース需要とネットワーク伝送リソース需要に基づいてサービスを複数のサービスブロックに分割するとともに前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを複数のリソースブロックに分割する分割ステップと、前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを監視することにより、サーバに対するアイドルサーバリソースとアイドルネットワーク伝送リソースとの組み合わせを各リソースブロックと対応付ける監視ステップと、データセンターネットワークに進入するサービス要求の属するサービスブロックを識別し、前記サービスブロックと前記リソースブロックとの間の対応関係に基づいて、当該サービス要求に対して前記アイドルサーバリソースとアイドルネットワーク伝送リソースとの組み合わせを割り当てる割り当てステップと、を含むことを特徴とする。
【図面の簡単な説明】
【００１０】
【図１Ａ】実施例１に係わる集中型負荷均衡装置に基づくデータセンターネットワークの構成図である。
【図１Ｂ】実施例２に係わる分散型負荷均衡装置に基づくデータセンターネットワークの構成図である。
【図１Ｃ】実施例３に係わる非対称パスに基づくデータセンターネットワークの構造図である。
【図２】実施例１に係わるルーティング意識を有する負荷均衡装置の機能実体図である。
【図３】実施例１に係わるパス配置機能を有するスイッチの機能実体図である。
【図４】実施例１に係わるサービス要求転送処理の時系列図である。
【図５】実施例１に係わるパス配置メッセージ処理の時系列図である。
【図６】実施例１に係わる負荷均衡装置の初期化プロセスのフローチャートである。
【図７】実施例１に係わる負荷均衡装置がサービス要求を処理する概略フローチャートである。
【図８】実施例１に係わる負荷均衡装置がサービスの属するサービスブロックを決定するフローチャートである。
【図９】実施例１に係わる負荷均衡装置が利用可能なサーバ／パス集合を決定するフローチャートである。
【図１０】実施例１に係わる時計回りスクロール検索アルゴリズムの実施例のフローチャートである。
【図１１】実施例１に係わる負荷均衡装置が最適なサーバ／パス組み合わせを決定するフローチャートである。
【図１２】実施例１に係わる負荷均衡装置がルーティングを予め計算するフローチャートである。
【図１３】実施例１に係わる負荷均衡装置がサーバ／パス組み合わせリソース消費を計算するフローチャートである。
【図１４Ａ】実施例１に係わる二次元属性に基づくサービスブロック分割ポリシーを示す図である。
【図１４Ｂ】実施例１に係わる二次元属性に基づくサーバ／パスリソースブロック分割ポリシーを示す図である。
【図１４Ｃ】実施例１に係わる二次元属性に基づくサービスブロックとリソースブロックの第一選択マッピングテーブルである。
【図１５Ａ】実施例３に係わる三次元属性に基づくサービスブロック分割ポリシーを示す図である。
【図１５Ｂ】実施例３に係わる三次元属性に基づくサーバ／下りパス／上りパスリソースブロック分割ポリシーを示す図である。
【図１５Ｃ】実施例３に係わる三次元属性に基づくサービスブロックとリソースブロックの第一選択マッピングテーブルである。
【図１６Ａ】実施例１に係わるサーバ／パス記録テーブルである。
【図１６Ｂ】実施例３に係わるサーバ／下りパス／上りパス記録テーブルである。
【図１７Ａ】実施例１に係わるサーバ／パスの現在利用可能な容量テーブル（サービス起動前）である。
【図１７Ｂ】実施例１に係わるサーバ／パスの現在利用可能な容量テーブル（サービス処理中）である。
【図１７Ｃ】実施例３に係わるサーバ／下りパス／上りパスの現在利用可能な容量テーブル（サービス起動前）である。
【図１７Ｄ】実施例３に係わるサーバ／下りパス／上りパスの現在利用可能な容量テーブル（サービス処理中）である。
【図１８】実施例１に係わるサービス分類テーブルである。
【図１９Ａ】実施例１に係わるリソースブロックとサーバ／パス組み合わせ記録テーブル（サービス起動前）である。
【図１９Ｂ】実施例１に係わるリソースブロックとサーバ／パス組み合わせ記録テーブル（サービス処理中）である。
【図１９Ｃ】実施例３に係わるリソースブロックサーバ／下りパス／上りパス組み合わせ記録テーブル（サービス起動前）である。
【図１９Ｄ】実施例３に係わるリソースブロックサーバ／下りパス／上りパス組み合わせ記録テーブル（サービス処理中）である。
【図２０】実施例１に係わるセッション転送テーブルである。
【図２１】実施例１に係わるパス配置メッセージフォーマットを示す図である。
【図２２Ａ】実施例１に係わる静的転送フィルタリングテーブルである。
【図２２Ｂ】実施例１に係わる動的転送フィルタリングテーブルである。
【発明を実施するための形態】
【００１１】
以下、実施例と図面に基づいて、本発明の内容について詳しく説明する。
【００１２】
図１は本発明のデータセンター内部ネットワークの実施例を応用したシステム構成図であり、図１Ａは実施例１に係わる集中型負荷均衡装置のデータセンターネットワークの構成図である。負荷均衡装置はデータセンターネットワークの入口に位置し、すべてのサーバの負荷割り当て及びすべてのパスのバンド幅割り当てを含むデータセンター全体に関連するリソース割り当てを管理する。図１Ａに示すように、当該システムは負荷均衡装置１００、１０１、スイッチ１１０〜１１６のようなスイッチングノード、及びサーバ１２０〜１２５を含み、ここでのサーバは物理サーバ装置であってもよいし、バーチャルマシンであってもよく、ユーザに一つまたは複数のサービス１３０〜１３３を提供する。負荷均衡装置１００、１０１はアクセス側のスイッチングノード１１０、１１３と接続しており、複数の中間スイッチングノード１１１、１１２、１１４、１１５、１１６を介してサーバ１２０〜１２５に接続されている。アクセス側のスイッチングノード１１０、１１３と各サーバ１２０〜１２５との間には一本または複数本のパス１４０、１４１が存在する。ここでのパス１４０、１４１は双方向リンク対称パス、すなわち均衡装置からサーバへの下り方向とサーバから均衡装置への上り方向のリンクは完全に重なり合い、同時に両方向のバンド幅は異なってもよい。負荷均衡装置１００、１０１はデータセンターのロジック入口点としてクライアント端末から送信されたサービス要求を受信し、サービス要求の種別と現在利用可能なリソース情報に基づいて適切なサーバ及び対応するパスの組み合わせを選択して転送し、サービス性能を確保するとともにネットワーク全体のリソースの利用効率と公平を考慮する。現在利用可能なリソース情報は、サーバのＣＰＵ未使用率、利用可能なメモリ容量、余剰接続数、余剰ネットワーク出口バンド幅等、パスの利用可能な最大バンド幅、パス遅延等の情報のような現在利用可能なサーバリソースと現在利用可能なネットワークリソース情報を含む。負荷均衡装置は一般的に主負荷均衡装置１００と予備負荷均衡装置１０１に分類され、一つ独立した物理実体として存在してもよく、負荷均衡の機能をアクセス側のスイッチングノード１１０と１１３に統合してもよい。
【００１３】
図１Ｂは実施例２に係わる分散型負荷均衡装置のデータセンターネットワークの構成図である。実施例２に示すデータセンターネットワークには幾つかのサーバグループをそれぞれ管理する複数の分散型負荷均衡装置が存在し、データセンターの入口に位置している全体負荷均衡装置によって統一管理される。図１Ｂに示すように、サーバ１２０〜１２５は幾つかの小さいサーバグループ１５０、１５１に分けられ、各サーバグループ１５０、１５１内部の負荷割り当ては局部負荷均衡装置１７０、１７１によって管理される。すべての局部負荷均衡装置１７０、１７１はデータセンターネットワーク全体の入口に位置している負荷均衡装置１００、１０１によって統一管理される。クライアント端末からのサービス要求がデータセンターネットワーク入口に到着した場合、負荷均衡装置１００、１０１はサービス要求のために適切なサーバグループ１５０、１５１及び当該サーバグループへのパス１４０、１４１を選択し、サービス要求が選択されたパスに沿って選択されたサーバグループに到着した後に、さらにサーバグループ１５０、１５１の中の局部負荷均衡装置１７０、１７１によって異なるサーバ１２０〜１２５に割り当てられて処理される。ここでのパス１４０、１４１は実施例１におけるパスと特徴が同じであり、同様に双方向リンク対称パスである。
【００１４】
その他の実施例においては、図１Ｃの実施例３に示すように、負荷均衡装置がサービスに割り当てるパスは双方向リンク非対称パスである。すなわち、均衡装置からサーバへの下り方向とサーバから均衡装置への上り方向のリンクは重なり合わず、バンド幅も異なる可能性がある。負荷均衡装置１００、１０１は異なる下りパス１４０と上りパス１４０ｒをサービス種別１３０に割り当てる。サービス要求はパス１４０を経由してサーバ１２０に到着し、サーバ１２０はメッセージに応答してパス１４０ｒを経由してクライアント端末に送信する。
【００１５】
図２は実施例１に係わる負荷均衡装置の機能実体図であり、データ受信ユニット２０１、２０２、データ処理ユニット２１０、記憶装置２３０、およびデータ転送ユニット２５０を含む。そのうちデータ処理ユニット２１０は負荷均衡モジュール２２０と監視モジュール２４０を含む。データ受信ユニット２０１、２０２は主にユーザのサービス要求とデータセンターネットワークの監視メッセージを受信する。データ処理ユニット２１０の中の負荷均衡モジュール２２０は主に受信したサービス要求を処理し、以下のような機能を実行する。すなわち、サービス／リソースブロック分割設定機能２２１はサービスブロックとリソースブロックの分割ポリシー及びそのマッピング関係を予め配置する。サービス識別機能２２２は受信したサービス要求パケットのコンテンツをチェックすることで当該サービス種別を識別し且つどのサービスブロックに属するかを判定する。サーバ／パス組み合わせポリシー決定機能２２３はサービスの属するサービスブロック情報に基づいて予め設定されたポリシーにしたがってリソースブロックから適切なサーバ及びパスの組み合わせを検索する。具体的な検索アルゴリズムについては後で詳しく説明する。パス配置機能２２４は選択したパスが経由するスイッチにパスを配置して情報を転送するよう通知する。具体的なスイッチの作動過程及びパス配置プロセスについては後でさらに詳しく説明する。負荷均衡モジュール２２０は配置情報を記憶装置２３０の関連テーブル、例えば、サービスブロックとリソースブロックの第一選択マッピングテーブル２３２、サーバ／パス記録テーブル２３５及びサービス分類テーブル２３６に記憶し、サービス要求メッセージを処理した後、記憶装置２３０の中の関連テーブル、例えば、セッション転送テーブル２３１などを更新し、選択されたパスに沿って選択されたサーバにサービス要求をデータ転送ユニット２５０に転送させる。データ処理ユニット２１０の中の監視モジュール２４０は主にネットワークの中の一つのスイッチングノード、サーバ装置または集中型機能管理サーバからの監視メッセージを処理する。そのうち、パス監視メッセージ処理２４１はデータ転送ユニット２５０によってネットワークの中のスイッチングノード監視装置にプローブ要求を送信し、スイッチングノード監視装置から送信されたネットワークの利用可能なリソース情報、例えばネットワークポートの利用可能なバンド幅、遅延などを処理する。サーバ監視メッセージ２４２はデータ転送ユニット２５０によってプローブ要求をサーバ監視装置に送信し、サーバ監視装置から送信されたサーバの利用可能なリソース情報、例えばサーバのＣＰＵ未使用率、利用可能なメモリ容量、剰余接続数、剰余ネットワーク出口バンド幅等を処理する。監視モジュール２４０は受信した監視メッセージを処理した後、メモリユニット２３０の中の関連テーブル、例えばサーバ／パスの現在利用可能な容量テーブル２３３、リソースブロックとサーバ／パス組み合わせ記録テーブル２３４等を更新する。通常、サービス要求受信ユニット２０１、監視メッセージ受信ユニット２０２、データ転送ユニット２５０はネットワークインターフェースによって実現し、記憶装置２３０はメモリまたは高速バッファによって実現し、データ処理ユニット２１０はＣＰＵ等のプロセッサによって実現する。
【００１６】
図３は実施例１に係わるパス配置機能を有するスイッチの機能実体図である。主にＭＡＣ層インターフェース３００、ブリッジユニット３１０及び記憶装置３２０を含む。ＭＡＣ層インターフェース３００はデータ受信器３０１とデータ送信器３０２を含む。データ受信器３０１は一般ユーザＭＡＣデータフレーム、ブリッジプロトコルデータユニット（ＢＰＤＵ）、及び負荷均衡装置からのパス配置要求メッセージを受信し、データ送信器３０２は処理済みの一般ユーザＭＡＣデータフレームとパス配置応答メッセージをネットワークに送信する。ブリッジユニット３１０は主にフレーム中継モジュール３１１、転送決定モジュール３１２、ＳＴＰモジュール３１３、ＭＡＣ学習モジュール３１４、パス配置メッセージ処理モジュール３１５及びデータ配信モジュール３１６のような六つの機能モジュールを含む。ＭＡＣ層インターフェース３００は受信したＭＡＣフレームをブリッジデータ配信モジュール３１６に転送し、ブリッジデータ配信モジュール３１６はＭＡＣフレームの種別に基づいてＭＡＣフレームを異なる機能モジュールにさらに処理させる。ブリッジプロトコルデータユニット（ＢＰＤＵ）であればＳＴＰモジュール３１３にさらに処理させ、メッセージ処理結果に基づいてＳＴＰ（Ｓｐａｎｎｉｎｇ  Ｔｒｅｅ  Ｐｒｏｔｏｃｏｌ）モジュール３１３が動的転送フィルタリングテーブル３２２を更新する（図２２Ｂに示すように）。当該動的転送フィルタリングテーブル３２２は主に宛先ＭＡＣアドレスとスイッチ転送ポートの二つのドメインを含む。負荷均衡装置からのパス配置要求メッセージであれば、パス配置情報に基づいて静的転送フィルタリングテーブル３２１をパス配置メッセージ処理モジュール３１５に更新させ（図２２Ａに示すように）、パス配置応答メッセージを負荷均衡装置に送信する。当該静的転送フィルタリングテーブル３２１は主にＶＬＡＮＩＤ、送信元ＭＡＣアドレス、宛先ＭＡＣアドレス、スイッチ入口ポート及び転送ポートを含む。一般ユーザＭＡＣデータフレームであれば、送信元ＭＡＣアドレスをＭＡＣ学習モジュール３１４に学習させるかまたはフレーム中継３１１に中継させ、転送待ちキューがアイドル状態になったときに転送決定モジュール３１２にスイッチ転送ポートを決定させる。転送プロセスは以下の通りである。転送決定モジュール３１２は先ず記憶装置３２０の中の静的転送フィルタリングテーブル３２１に対応する転送記録が存在するかどうかをチェックし、存在する場合、サービス要求を対応する転送記録の中のスイッチ出口ポートに転送し、静的転送フィルタリングテーブル３２１の中から対応する転送記録が見つからなかった場合、動的転送フィルタリングテーブル３２２に基づいて当該データフレーム転送ポートを決定して対応するスイッチ出口ポートに転送する。
【００１７】
図４は実施例１に係わるサービス要求転送処理時系列図の一つの実施例である。クライアント端末１８０は第一のサービス要求４１０をデータセンターネットワークに送信し、負荷均衡装置１００はサービス要求４１０を受信した後に、当該サービス要求のために最適なサーバ／パス組み合わせを計算し、セッション転送情報をセッション転送テーブル２３１に記憶し、当該サービス要求のために転送パス４１１を配置するよう関連スイッチに通知する。配置終了後に負荷均衡装置１００は選択されたパスに沿って選択されたサーバ１２０に当該サービス要求４１３、４１４を送信し、サービス提供に選択されたサーバ１２０はサービス要求メッセージを受信した後に当該サービス要求を処理し、クライアント端末１８０に応答メッセージ４１５、４１６を送信する。クライアント端末１８０がデータセンターネットワークにこの後のサービス要求メッセージ４２０を送信する際に、負荷均衡装置１００はセッション転送テーブル２３１から対応する転送記録を見つけ、記録の中のサーバ／パス組み合わせに沿って当該サービス要求４２１を転送する。サーバ１２０はサービス要求を処理した後に応答メッセージ４２２をクライアント端末に送信する。
【００１８】
図５は実施例１に係わるパス配置メッセージ処理時系列図の一つの実施例である。負荷均衡装置１００は受信したサービス要求のために最適なパスを計算した後に、関連するパス配置メッセージ５０1、５０２をすべてのスイッチ１１０、１１１にブロードキャストする。パス配置メッセージのフォーマットは図２１に示すように、イーサネット(登録商標)ヘッダ２１０１、パス配置プロトコルＩＤ２１０２、パス配置メッセージ種別２１０３、配置スイッチＩＤ２１０４、ＶＬＡＮ  ＩＤ２１０５、セッション送信元ＭＡＣアドレス２１０６、セッション宛先ＭＡＣアドレス２１０７、スイッチ入口ポート２１０８、スイッチ転送ポート２１０９のような領域を含む。スイッチ１１０、１１１はパス配置ブロードキャストメッセージを受信した後に、配置スイッチＩＤ２１０４が本スイッチと同じであるかどうかをチェックし、本スイッチＩＤと一致する場合、パス配置要求におけるセッション転送メッセージに基づいてスイッチの静的転送フィルタリングテーブル３２１を配置し、配置が終了した後にパス配置ＯＫメッセージ５２２を負荷均衡装置に送信する。逆に、本スイッチＩＤと一致しない場合、当該メッセージ５２１を放棄する。その後、当該サービス要求がスイッチ１１１を経由するときに、配置スイッチＩＤ２１０４と本スイッチＩＤが一致する場合、スイッチは配置済みの静的パスに基づいてサービスを対応するポートに転送する。当該サービスが終了した場合、負荷均衡装置１００は対応するパス配置取消要求５３１をスイッチ１１０、１１１にブロードキャストし、関連スイッチ１１１がパス配置取消要求を受信し後に対応する転送記録５３３を転送テーブルから削除し、パス配置取消ＯＫの応答メッセージを負荷均衡装置１００に送信し、関連パス配置５３５を取消したことを負荷均衡装置１００に通知する。その他の実施例において、スイッチ１１１は静的転送フィルタリングテーブル３２１の中の関連転送記録のためにタイマーを設置し、当該セッションのサービス要求送信間隔がある閾値を超えた場合、対応する記録を削除することができる。
【００１９】
以下、図１Ａにおけるデータセンターネットワークトポロジー実施例に基づいて負荷均衡装置の作動プロセスについて詳しく説明する。
【００２０】
サービスが起動する前に、負荷均衡装置は最初に初期化操作を実行し、システムの初期配置を完成させる。
【００２１】
図６は実施例１に係わる負荷均衡装置の初期化フローチャートである。負荷均衡装置におけるデータ処理ユニット２１０は以下のステップを実行する。
【００２２】
ステップ６００において、負荷均衡装置は各サーバに到着する利用可能なパス集合を予め計算する。ルーティングを予め計算する一つの実施例のフローチャートは図１２に示す通りである。先ず、ネットワークトポロジー情報１２００を収集し、リンクのｍｅｔｒｉｃ情報１２０１を収集する。その後、ＣＳＰＦルーティングアルゴリズムを利用して各サーバに到着する利用可能なパス集合１２０２を計算する。本分野において、よく使われているｍｅｔｒｉｃはバンド幅、遅延、パス長さ、信頼性、負荷、通信コストの中の一つであり、複雑なルーティングアルゴリズムについては複数のｍｅｔｒｉｃに基づいてルーティングを選択し、それらを一つ複合のｍｅｔｒｉｃに組み合せる。本発明における以下の説明ではｍｅｔｒｉｃがバンド幅であることを例にして説明をする。
【００２３】
ステップ６０１において、計算結果及び関連情報をサーバ／パス記録テーブル２３５に記憶する。図１６Ａに示すように、当該サーバ／パス記録テーブル２３５は主にサービス種別、サーバＩＤ、総ＣＰＵ、パス／バンド幅リストなどの幾つかの領域を含み、各サーバがサポートするサービス種別、ＩＤ番号、ＣＰＵ総量、利用可能なパスルーティング情報及び各パスの総バンド幅をそれぞれ記録する。パス／バンド幅リスト領域において、パスは双方向リンク対称パスであり、バンド幅は下りリンクバンド幅である。
【００２４】
その他の実施例において、リソース最適化のポリシーによって、バンド幅は、パスの二つの方向における利用可能なバンド幅の小さい値、もしくは平均値、あるいは上りリンクバンド幅などのようなその他の予め定義された値でよい。
【００２５】
リンク非対称パスの実施例３において、パス／バンド幅リストは二つの方向のパス及びバンド幅をそれぞれ含んでよく、対応するサーバ／下りパス／上りパス記録テーブルは図１６Ｂに示す通りである。
【００２６】
ステップ６０２において、サーバ／パスの現在利用可能な容量テーブル２３３を初期化する。当該テーブルは、図１７Ａに示すように、主に各サーバ上の現在利用可能な容量及び当該サーバに到着する各パスの利用可能な容量情報を記録する。サービスが起動する前に、すべてのサーバとパスの利用可能な容量はいずれも総容量である。パス非対称の実施例３において、パスの現在利用可能な容量は下りパスと上りパスの利用可能な容量を含み、対応するサーバ／下りパス／上りパスの現在利用可能な容量テーブルは図１７Ｃ、１７Ｄに示す通りである。
【００２７】
ステップ６０３において、サービスブロックとリソースブロックの分割ポリシー及びそのマッピングテーブルを定義する。当該ステップにおいて行なわれる処理は前記負荷均衡モジュール２２０の中のサービス／リソースブロック分割設定機能２２１に対応する。
【００２８】
サービスブロックの分割ポリシーは、それぞれのサービスのリソース需要に対する大きさＳとＲに基づいてサービスを分類する。ここで、Ｓは当該サービスの処理に必要なサーバリソース、例えばＣＰＵ利用率であり、Ｒは当該サービスの伝送に必要なネットワークリソース、例えば下り方向のネットワークバンド幅である。Ｓの値の範囲が[Ｓｍｉｎ、Ｓｍａｘ]で、Ｒの値の範囲が[Ｒｍｉｎ、Ｒｍａｘ]であるとすると、Ｓの値空間を各サブ空間の長さがそれぞれＳ１、Ｓ２、・・・、ＳｍであるＭ個のサブ空間に分け、Ｒの値空間を各サブ空間の長さがそれぞれＲ１、Ｒ２、・・・、ＲｎであるＮ個のサブ空間に分けて、ＳとＲから構成される二次元平面空間をＭ*Ｎ個の空間ブロックに分割し、それをサービスブロックと称する。各サービスブロックの値範囲はそれぞれ
【００２９】
【数１】
2013168934.tif 000003
である。それぞれの具体的なサービスは必要とするリソースの数値に応じて異なるサービスブロックに入る。よくあるサービス種別を考慮して、例えばテキスト検索、動画ダウンロード、音声通話などのバンド幅需要は通常桁違いの差があるため、ネットワークリソースＲの値空間は対数化処理を行なうことができる。同様に、データ処理の便利のために、サーバリソースＳは正規化処理をして相対値を取ることもできる。サービスブロック分割の一つの実施例は図１４Ａに示すように、ｘ軸はサービスのサーバＣＰＵに対する需要を示し、ｙ軸はサービスの下りネットワークバンド幅に対する需要を示し、合計で３*３＝９個のサービスブロックを形成し、それぞれＲ１１、Ｒ２１、・・・、Ｒ３３である。そのうち、Ｒ１１のリソースに対する需要が最小で、Ｒ３３のリソースに対する需要が最大である。あるサービスの消費するリソースがあるサービスブロックの値範囲を満たす場合、当該サービスは当該サービスブロックに属する。例えば、サービス処理に消費されるＣＰＵリソースパーセンテージが０と０．０１％の間にあり、且つサービス伝送に消費される下りネットワークバンド幅が０と１０３＝１Ｋｂｐｓの間にある場合、当該サービスはＲ１１サービスブロックに入る。
【００３０】
その他の実施例において、サービスのネットワークに対するリソース需要は二つの方向上のバンド幅需要の最大値、もしくは平均値あるいはその他の予め定義された値でよい。
【００３１】
また別の実施例において、例えばパス非対称の実施例３において、サービスのネットワークリソースに対する需要は双方向であってよく、図１５Ａに示すように、サービスのリソースに対する需要の三次元空間ＣＰＵ／下りバンド幅／上りバンド幅に基づいてサービスブロックを分割する。また、サービスのリソースに対する需要空間はさらに多い情報、例えば、メモリ、エネルギー消耗、遅延などのような情報を考慮して、サービスのリソースに対する需要空間をさらに高次元に拡張してもよい。
【００３２】
各サービスの必要なリソースの具体的な数値は過去のデータを統計することにより得られる。各次元上のサブ空間ＭとＮの値はサービスクラスタリングの方法によって確定できる。以下、ネットワークに基づくファジークラスタリング方法を例にして具体的に説明する。先ず、サービスの値空間の各次元をすべてＫ等分して幾つかの均等なグリッドユニットに分割し、グリッドユニットの数は予期したサービスブロックの数Ｍ*Ｎより遥かに大きい。各サービスをリソース需要の大きさに基づいてグリッドユニットにマッピングし、各グリッドユニットの密度即ち当該グリッドユニットに入ったサービスの数を計算し、少なくとも一つのサービスを含むグリッドユニットを有効グリッドユニットと称し、一つのサービスも含まないグリッドユニットを空きグリッドユニットと称する。クラスタリングの前に、各サービスブロックに含まれているサービス数が密度閾値の最小値ＤＥＮＳＩＴＹｍｉｎと密度閾値の最大値ＤＥＮＳＩＴＹｍａｘの間になるように各サービスブロックの密度範囲を設定する。ある有効グリッドユニットの密度が大きすぎた（＞ＤＥＮＳＩＴＹｍａｘ）場合、すべての有効グリッドユニットの密度が予め設定された密度閾値の最大値より小さくなるまでにＫの値を増やしてグリッドユニットを新たに分割する。ある有効グリッドユニットの密度が小さすぎた（＜ＤＥＮＳＩＴＹｍｉｎ）場合、隣接するグリッドユニットを合併することでグリッドユニットの密度を増やす。すべての有効グリッドユニットが密度閾値要求を満たすまでにこのようなプロセス繰り返す。有効グリッドユニットの境界と周囲の空きグリッドユニットを検出し、幾つかの値空間が連続するサービスブロックを連結形成し、その後各サービスブロックの値範囲に基づいて各次元上のＭとＮの値を確定する。
【００３３】
上述のサービスクラスタリングの方法によって各サービスブロックの値範囲を確定するのはただ一つの例であり、当然ながらその他の方法によって分割することも可能である。例えば、等間隔分割の方法によって各サービスブロックの値範囲を均等に確定することも可能であり、このような方法はサービスブロックを分割する際の処理負担を低減することができる。
【００３４】
リソースブロックの分割ポリシーは、サーバのアイドル計算リソース（例えば、ＣＰＵ未使用率）及び接続されたパスのアイドルネットワークリソース（例えば、下りネットワークバンド幅）を幾つかの種類に分類し、システム運転過程において、各サーバ／パス組み合わせは現在所有するアイドルリソースの状況に基づいて異なるリソースブロックに入る。ネットワークにおいてサーバの最大リソースがＮＳｍａｘで、下りパスの最大バンド幅がＮＲｍａｘであるとすると、サーバリソースの値範囲は[０、ＮＳｍａｘ]で、ネットワークバンド幅の値範囲は[０、ＮＲｍａｘ]である。アイドルサーバリソースとアイドルネットワークバンド幅リソースから構成された二次元平面空間をＭ*Ｎ個の空間ブロックに分割し、それをリソースブロックと称する。そのうち、各リソースブロックのそれぞれのサブ空間の値範囲とサービスブロックのそれぞれのサブ空間の値範囲は同じトレンドで確定してもよいし（例えば図１４Ａ、図１４Ｂに示すように）、サービスブロックのそれぞれのサブ空間の値範囲の比例に応じて確定してもよく、さらに等間隔分割の方法などによって均等に確定してもよい。サーバリソースの値空間上のそれぞれのサブ空間の長さが順次ＮＳ１、ＮＳ２、・・・、ＮＳｍで、ネットワークバンド幅の値空間上のそれぞれのサブ空間の長さが順次ＮＲ１、ＮＲ２、・・・、ＮＲｎであるとすると、各リソースブロックの値範囲はそれぞれ、
【００３５】
【数２】
2013168934.tif 000004
である。負荷均衡の目標を考えると、サーバのアイドルリソースの相違はそれほど大きくなく、サーバの中等ビジー状態時のアイドルリソースを中心にＬｏｇ処理を行なえばよい。即ち平均値付近での分類精度を増やせばよい。同様にデータ処理の便利のためには、ネットワークバンド幅リソースの値範囲が大きいため、対数化処理を行なって相対値をとってもよい。リソースブロック分割の一つの実施例は図１４Ｂに示すように、ｘ軸はサービスのサーバの利用可能なＣＰＵに対する利用率パーセンテージを示し、ｙ軸は下りパスの利用可能なネットワークバンド幅リソースを示し、図１４Ａの中のサービスブロックと対応し、合計で３*３＝９個のリソースブロックを形成し、それぞれＳ１１、Ｓ２１、・・・、Ｓ３３である。そのうち、Ｓ１１の中のサーバ及び接続されたパスには利用可能なリソースが最も少ない。即ち、サーバ及び接続されたネットワークには負荷が非常に重い。Ｓ３３の中のサーバ及び接続されたパスには利用可能なリソースが最も多い。即ち、サーバ及び接続されたネットワークには負荷が非常に軽い。サーバ／パス組み合わせにおいて利用可能なリソースがあるリソースブロックの値範囲を満たした場合、当該サーバ／パス組み合わせはこのリソースブロックに属する。例えば、あるサーバの利用可能なＣＰＵリソースパーセンテージが０と３５％の間にあり、且つ接続されたパスバンド幅が０と１０６＝１Ｍｂｐｓの間にある場合、当該サーバ／パス組み合わせはＳ１１リソースブロックに入る。
【００３６】
その他の実施例において、サーバ／パス組み合わせを異なるリソースブロックに分割するときに、ネットワークリソースはパスの双方向上の利用可能なバンド幅の最大値、もしくは平均値あるいはその他の予め定義された値に基づいて分割してよい。
【００３７】
また別の実施例において、例えばパス非対称の実施例３において、サーバ／下りパス／上りパスに基づいてリソースブロックを分割してよい。この際のリソースブロックの値空間は、図１５Ｂに示すように、利用可能なＣＰＵ／下りパスの利用可能なバンド幅／上りパスの利用可能なバンド幅の三次元情報に拡張される。また、リソースブロックの値空間はさらに多い情報、例えば、メモリ、余剰エネルギー、リンクの現在遅延などの情報も考慮して、リソース空間をさらに高次元に拡張してもよい。
【００３８】
サービスブロックとリソースブロックのマッピング規則は、各サービスブロックが複数のリソースブロックの中で当該サービスブロック位置に対応するリソースブロックであるマッピングリソースブロックを第一に選択する。即ち、各サービスブロック上のサービスにサーバとネットワークリソースを割り当てる際に、先ず、第一に選択されたリソースブロック上のサーバ／パス組み合わせを検索する。例えば、図１４Ｃは１４Ａと１４Ｂに対応して二次元属性に基づいて分割した第一選択マッピングテーブルの一つの実施例で、図１５Ｃは１５Ａと１５Ｂに対応して三次元属性に基づいて分割した第一選択マッピングテーブルの別の一つの実施例である。第一選択マッピングリソースブロックにサービスリソース需要を満たすサーバ／パス組み合わせがなかった場合、サービス需要を満たすサーバ／パス組み合わせが検索されるまで、先ず値範囲がサービスリソース需要を満たさないリソースブロックを削除し、残りのリソースブロックを検索領域とし、その後、第一選択リソースブロックを中心に近から遠に向かって一層ずつスクロール検索を展開する。スクロール検索プロセスは以下の通りである。先ず、第一選択リソースブロックに近い第一層の利用可能なリソースブロックの中から一つのリソースブロックをランダムに選択し、当該リソースブロックの中から条件を満たすサーバ／パス組み合わせがあるかどうかを検索し、あった場合は検索を停止し、なかった場合は、当該層の利用可能なリソースブロックの検索が終了するまでに、時計回り順（例えば、図１５ＢにおけるＳ１１１、Ｓ１２１、Ｓ２２１、Ｓ２１１の順）または反時計回り順（例えば、図１５ＢにおけるＳ１１１、Ｓ２１１、Ｓ２２１、Ｓ１２１の順）に、当該層の次のリソースブロックを検索する。条件を満たすサーバ／パス組み合わせが依然として見つからなかった場合、第二層の利用可能なリソースブロックの検索を開始し、検索領域のリソースブロックの検索が終了するまでに、第三層、第四層、・・・を順次検索する。
【００３９】
ステップ６０４において、サービスのリソースに対する需要に基づいてサービス分類テーブル２３６を初期化し、図１８に示すように、各サービスのサービス種別、リソース需要に対する数値及び所属するサービスブロックを記録する。
【００４０】
ステップ６０５において、リソースブロックとサーバ／パス組み合わせ記録テーブル２３４を初期化し、図１９Ａに示すように、当該テーブルは各リソースブロックに属するサーバ／パス組み合わせを記録する。サービスが起動する前に、すべてのサーバとパスはアイドル状態であるため、いずれもリソースブロックＳ３３の中にある。パス非対称の実施例３においては、図１９Ｃに示すように、各リソースブロックには当該リソースブロックに属するサーバ／下りパス／上りパス組み合わせが記録されている。
【００４１】
初期化操作が終了した後に、サービスが起動し、負荷均衡装置は到着したパケットの処理を開始し、各サービス要求のためにサーバとパスを割り当てる。処理プロセスの概要は図７に示す通りである。
【００４２】
ステップ７０１において、受信したパケットをチェックし、そのメッセージ種別を判定する。監視メッセージである場合はステップ７１０に進み、サービス要求メッセージである場合はステップ７０２に進む。
【００４３】
ステップ７１０において、図１７Ｂと図１９Ｂに示すように、受信したサーバまたはネットワークの監視メッセージに基づいてサーバ／パスの現在利用可能な容量テーブル２３３を更新し、現在利用可能な容量情報及びリソースブロックの分割ポリシーに基づいて所属するリソースブロックを更新する。パス非対称の実施例３においては、図１７Ｄと１９Ｄに示すように、現在サーバ／下りパス／上りパスの現在利用可能な容量テーブルに記録された容量情報に基づいて、各リソースブロックの中のサーバ／下りパス／上りパス組み合わせを更新する。
【００４４】
ステップ７０２において、当該サービス要求が新しい接続からのサービス要求であるかどうかをチェックし、当該接続がすでにセッション転送テーブル２３１に存在している場合はステップ７２０に進み、当該記録テーブルから対応するサーバ／パス組み合わせを見つけて転送を行なう。新しい接続要求である場合はステップ７０３に進み、当該サービス要求のために最適なサーバとパスを検索してサービスを提供する。
【００４５】
ステップ７０３において、サービス要求のサービス種別を識別し、サービスの属するサービスブロックを決定する。当該ステップ７０３で行なわれた処理は前記負荷均衡モジュール２２０の中のサービス識別機能２２２に対応する。当該プロセスの一つの実施例は図８に示す通りである。先ず、ステップ８００において、受信したパケット内容をチェックし、パケット内容の属するサービス種別を判定し、その後ステップ８０１において、サービス分類テーブルに基づいて当該サービスが既知のサービス種別であるかどうかを判定する。既知のサービス種別である場合は、ステップ８１０においてサービス分類テーブル２３６に基づいて当該サービス種別の属するサービスブロックを探し、未知のサービス種別である場合は、ステップ８０２〜８０６に記載された方法にしたがって当該サービスの属するサービスブロックを決定する。先ず、ステップ８０２において、予め設定されたポリシーに基づいて当該サービスのために一つのサービスブロック、例えば、ポートの範囲、プロトコルの種別、サービスの優先度等によって、対応するプログラムの過去の情報統計結果に基づいて所属するサービスブロックを設定する。その後、ステップ８０３において当該サービスのトラフィック情報を監視するよう負荷均衡装置もしくは経由するスイッチに通知し、ステップ８０４において当該サービスの占用するリソース情報を監視するようサーバに通知し、ステップ８０５において当該サービスに必要なネットワークバンド幅リソースとサーバ計算リソースを収集し、そのリソースをサービス分類テーブル２３６に追加し、最後にステップ８０６において測定した当該サービスに必要なリソース及びサービスブロック分割ポリシーに基づいて当該サービス種別の属するサービスブロックを決定し、サービス分類テーブル２３６の対応する記録に追加する。
【００４６】
ステップ７０３においてサービスの属するサービスブロックを確定した後に、ステップ７０４において、サービスブロックとリソースブロックの第一選択マッピングテーブル２３２に基づいて当該サービスブロックに対応する第一選択マッピングリソースブロックを探す。当該第一選択マッピングリソースブロックに基づいて、ステップ７０５〜７０６においては当該サービスのために最適なサーバ／パス組み合わせを検索してネットワークとサーバにおけるサービストラフィックの分布を均衡にし、データセンターネットワーク全体のリソース利用率を最適化する。検索アルゴリズムの具体的な実施プロセスは図９〜１１においてさらに詳しく説明する。そのうち、ステップ７０４〜ステップ７０６で行なわれた処理は前記負荷均衡モジュール２２０の中のサーバ／パスポリシー決定機能２２３に対応する。
【００４７】
ステップ７０７において、図２０に示すように、当該サービス要求接続情報および対応する最適なサーバ／パス組み合わせをセッション転送テーブル２３１に記憶する。当該セッション転送テーブルは、主にセッションＩＤ、サービス種別、送信元ＩＰアドレス、宛先ＩＰアドレス、対応するＶＬＡＮ  ＩＤ、送信元ＭＡＣアドレス、宛先ＭＡＣアドレス、および当該サービスの接続のために割り当てられた＜宛先サーバ、経由パス＞の幾つかの領域を含む。次の同一接続からのパケットが到着した場合、当該セッション転送テーブルに基づいて対応するサーバ／パス組み合わせを探して転送を行なえばよく、新たに検索する必要がない。
【００４８】
ステップ７０８において、当該サービスのために割り当てられた最適なパスに基づいて当該パスを配置するよう関連するスイッチに通知する。当該ステップ７０８で行なわれた処理は前記負荷均衡２２０の中のパス配置機能２２４に対応する。
【００４９】
ステップ７０９において、当該パスに沿ってサービス要求を割り当てられたサーバに転送し、その後、割り当てられたサーバにより当該サービス要求のためにサービスを提供する。当該ステップ７０９で行なわれた処理は図２の中のデータ転送ユニットに対応する。
【００５０】
図９〜図１１は検索アルゴリズムの一つの具体的な実施例である。検索プロセスは主に、図９〜図１０に示すように、リソースブロックからサービス需要に適する利用可能なサーバ／パス組み合わせの集合を検索する第一のステップと、図１１に示すように、利用可能な集合から最適なサーバ／パス組み合わせを選抜する第二のステップと、を含む。利用可能なサーバ／パス組み合わせの集合を検索する具体的なプロセスは以下の通りである。
【００５１】
ステップ９００において、サービスブロックとリソースブロックの第一選択マッピングテーブル２３２に基づいて、当該サービスブロックに対応する第一に選択検索するリソースブロックＳｘｙを探し、その後、ステップ９０１において、リソースブロックとサーバ／パス組み合わせ記録テーブル２３４から当該リソースブロックＳｘｙにサーバ／パス組み合わせ記録が存在するかどうかをチェックし、存在する場合はステップ９０２に進む。
【００５２】
ステップ９０２において、リソースブロックＳｘｙに含まれている第一のサーバ／パス組み合わせを選択し、その後、ステップ９０３において、サーバ／パス組み合わせリスト記録に基づいて当該組み合わせの中のサーバが当該サービス要求をサポートするかどうかをチェックし、サポートする場合は、ステップ９０４において当該組み合わせの中の利用可能な容量の絶対値が当該サービスリソースの需要を満たすかどうかをチェックし、当該サービスリソースの需要を満たす場合は、ステップ９０５において、当該サーバ／パス組み合わせを利用可能なサーバ／パスの集合に記憶し、その後ステップ９０６に進み、当該リソースブロックの中のすべてのサーバ／パス組み合わせのチェックを終了し、条件を満たす組み合わせをすべて利用可能なサーバ／パス集合に記憶するまで、同様な方法でリソースブロックＳｘｙの中の次のサーバ／パス組み合わせがサービス需要を満たすかどうかをチェックする。あるサーバ／パス組み合わせがステップ９０３とステップ９０４において需要を満たしていない場合、当該組み合わせをとばしてステップ９０６に進んで次の組み合わせをチェックする。
【００５３】
第一選択マッピングリソースブロックＳｘｙに対応するすべてのサーバ／パス組み合わせの検索が終了した後に、ステップ９０７において利用可能なサーバ／パス集合が空であるかどうかをチェックし、空でない場合は、図１１のプロセスにしたがって当該集合から最適な組み合わせを選抜し、空である場合はステップ９０８に進んで、図１０に示すように、サービス需要を満たすリソースブロックをすべて検索終了するまでに、リソースブロックＳｘｙを中心に近から遠に向かって隣接するリソースブロックに対してスクロール検索を展開する。
【００５４】
図１０は第一選択リソースブロックＳｘｙを中心に近から遠に向かって隣接するリソースブロックに対して時計回りのスクロール検索を展開する一つの実施例である。具体的なプロセスは以下の通りである。
【００５５】
ステップ１０００において、当該サービスのサーバに対するリソース需要はＣｒで、ネットワークバンド幅に対するリソース需要はＢｒであることが分り、ステップ１００１において、当該サービス需要を満たすリソースブロック領域の境界の最小値ＳＭＮを計算し、ＳＵＶ（Ｕ＝Ｍ、Ｍ＋１、・・・、Ｖ＝Ｎ、Ｎ＋１、・・・）の集合をリソースブロック検索領域と確定し、当該領域で利用可能なサーバ／パス組み合わせを検索する。
【００５６】
ステップ１００２においてはステップ１００３〜１００７にしたがってリソースブロックＳｘｙに隣接する第一層のリソースブロックで検索を開始する。先ず、ステップ１００３において、リソースブロック検索領域の範囲によって当該層の中でサービス需要を満たすリソースブロック集合Ｇを確定し、その後ステップ１００４において、リソースブロック集合Ｇから一つのリソースブロックＳｉｊをランダムに選択し、図９に示すプロセスにしたがって、その中から利用可能なサーバ／パス集合を検索する。ステップ１００５において、当該利用可能なサーバ／パス集合の中にサーバ／パス組み合わせの記録が存在するかどうかをチェックし、存在する場合は検索を停止し、存在しない場合はステップ１００６に進み、利用可能なサーバ／パス組み合わせが検索されるまでに、リソースブロック集合Ｇにおいて時計回りの順に次のリソースブロックを順次に検索する。ステップ１００７において、リソースブロック集合Ｇの中のすべてのリソースブロックを検索終了しても利用可能なサーバ／パス組み合わせが見つからなかった場合はステップ１００８に進み、リソースブロック検索領域の中のすべてのリソースブロックを検索終了するまでに、同様な方法で前記第一層のリソースブロックに隣接する第二層のリソースブロックをスクロール検索し、第三層のリソースブロック、第四層のリソースブロック、・・・を順次にスクロール検索する。第二層のリソースブロックをスクロール検索する際に、第一の検索点はＳｘｙとＳｉｊの延長線と当該次の層のリソースブロックとが交差するリソースブロックを選択してもよく、ランダムに選択してもよい。その後時計回りの順に隣接する次のリソースブロックを順次検索する。図１４Ｂの状況を例にすると、リソースブロックＳｘｙがＳ１１の場合、リソースブロックＳｘｙに隣接する第一層のリソースブロックはＳ１２、Ｓ２２及びＳ２１であり、前記第一層のリソースブロックに隣接する第二層のリソースブロックはＳ１３、Ｓ２３、Ｓ３３、Ｓ３２、Ｓ３１である。
【００５７】
隣接するリソースブロックにおいて検索する方法は図１０のプロセスに限らず、反時計回りの順またはランダムの順に検索してもよい。検索する基本原則として、第一は、第一選択リソースブロックＳｘｙの利用可能なリソース数値との差が小さいリソースブロックを優先的に検索し、第二は、周囲のリソースブロックの検索頻度のバランスをできるだけ保ち、あるリソースブロックの過度な検索を避けることである。
【００５８】
検索された利用可能なサーバ／パス集合から最適なサーバ／パス組み合わせを選抜するプロセスは図１１に示す通りで、具体的なプロセスは以下の通りである。
【００５９】
ステップ１１０１において、当該利用可能なサーバ／パス集合から第一のサーバ／パス組み合わせを選択し、現在最小リソース消費が無限大（∞）になるように初期化する。
【００６０】
ステップ１１０２において、当該組み合わせのリソース消費を計算し、計算方法は図１３に示す通りである。要求されるサービスのサーバに対するリソース需要がＣｒ、ネットワークバンド幅に対するリソース需要がＢｒ、当該組み合わせの中のサーバの現在利用可能な容量がＣＡ、パスの現在利用可能なバンド幅がＢＡであるとすると、リソース消費ＬＢｃは下式になる。
【００６１】
ＬＢｃ＝Ｃｒ／ＣＡ+Ｂｒ／ＢＡ
【００６２】
ステップ１１０３において、当該組み合わせのリソース消費が現在最小リソース消費より小さいかどうかをチェックし、現在最小リソース消費より小さい場合は、ステップ１１０４に進み、当該サーバ／パス組み合わせを現在最適な選択に設定し、リソース消費を現在最小リソース消費に設定し、逆の場合は当該組み合わせをとばす。続いて、ステップ１１０５において、当該利用可能なサーバ／パス集合の中に次のサーバ／パス組み合わせが存在するかどうかをチェックし、存在する場合は、当該利用可能なサーバ／パス集合の中のすべてのサーバ／パス組み合わせのチェックが終了するまでに、１１０２〜１１０４と同様のプロセスにしたがってリソース消費を計算し、現在最小リソース消費と現在最適なサーバ／パス組み合わせを選択する。このときに、前記利用可能なサーバ／パス集合をクリアし、現在最適選択を当該サービス要求に割り当てられたサーバとパスとする。
【図１Ａ】
2013168934.tif 000005
【図１Ｂ】
2013168934.tif 000006
【図１Ｃ】
2013168934.tif 000007
【図２】
2013168934.tif 000008
【図３】
2013168934.tif 000009
【図４】
2013168934.tif 000010
【図５】
2013168934.tif 000011
【図６】
2013168934.tif 000012
【図７】
2013168934.tif 000013
【図８】
2013168934.tif 000014
【図９】
2013168934.tif 000015
【図１０】
2013168934.tif 000016
【図１１】
2013168934.tif 000017
【図１２】
2013168934.tif 000018
【図１３】
2013168934.tif 000019
【図１４Ａ】
2013168934.tif 000020
【図１４Ｂ】
2013168934.tif 000021
【図１４Ｃ】
2013168934.tif 000022
【図１５Ａ】
2013168934.tif 000023
【図１５Ｂ】
2013168934.tif 000024
【図１５Ｃ】
2013168934.tif 000025
【図１６Ａ】
2013168934.tif 000026
【図１６Ｂ】
2013168934.tif 000027
【図１７Ａ】
2013168934.tif 000028
【図１７Ｂ】
2013168934.tif 000029
【図１７Ｃ】
2013168934.tif 000030
【図１７Ｄ】
2013168934.tif 000031
【図１８】
2013168934.tif 000032
【図１９Ａ】
2013168934.tif 000033
【図１９Ｂ】
2013168934.tif 000034
【図１９Ｃ】
2013168934.tif 000035
【図１９Ｄ】
2013168934.tif 000036
【図２０】
2013168934.tif 000037
【図２１】
2013168934.tif 000038
【図２２Ａ】
2013168934.tif 000039
【図２２Ｂ】
2013168934.tif 000040