JP2013168934A - 負荷均衡装置及び負荷均衡方法 - Google Patents
負荷均衡装置及び負荷均衡方法 Download PDFInfo
- Publication number
- JP2013168934A JP2013168934A JP2013010059A JP2013010059A JP2013168934A JP 2013168934 A JP2013168934 A JP 2013168934A JP 2013010059 A JP2013010059 A JP 2013010059A JP 2013010059 A JP2013010059 A JP 2013010059A JP 2013168934 A JP2013168934 A JP 2013168934A
- Authority
- JP
- Japan
- Prior art keywords
- resource
- service
- server
- idle
- demand
- 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.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】サーバのサービス割り当てとパスのトラフィック割り当てを均衡にするとともにリソースの割り当て効率を改善できる負荷均衡装置及び負荷均衡方法を提供する。
【解決手段】サービスのサーバリソース需要とネットワーク伝送リソース需要に基づいてサービスを複数のサービスブロックに分割するとともに前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを複数のリソースブロックに分割し、サーバに対するアイドルサーバリソースとアイドルネットワーク伝送リソースの組み合わせを各リソースブロックと対応付け、データセンターネットワークに進入するサービス要求の属するサービスブロックを識別し、前記サービスブロックと前記リソースブロックとの対応関係に基づいて、前記アイドルサーバリソースとアイドルネットワーク伝送リソースの組み合わせを当該サービス要求に割り当てる。
【選択図】図2
【解決手段】サービスのサーバリソース需要とネットワーク伝送リソース需要に基づいてサービスを複数のサービスブロックに分割するとともに前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを複数のリソースブロックに分割し、サーバに対するアイドルサーバリソースとアイドルネットワーク伝送リソースの組み合わせを各リソースブロックと対応付け、データセンターネットワークに進入するサービス要求の属するサービスブロックを識別し、前記サービスブロックと前記リソースブロックとの対応関係に基づいて、前記アイドルサーバリソースとアイドルネットワーク伝送リソースの組み合わせを当該サービス要求に割り当てる。
【選択図】図2
Description
本発明は負荷均衡方法に関し、特にデータセンター分野に応用されるとともにネットワークリソースとサーバリソースの利用効率を改善する負荷均衡装置及び負荷均衡方法に関する。
特許文献1では、リソース管理装置によってリソース情報を収集して負荷均衡装置に配信し、負荷均衡装置によって受信したリソース情報と予め決められたリソース割り当てポリシーに基づいて適切なバッファサーバを選択することで、システムの性能と効率を向上させるコンテンツ配信ネットワークにおける負荷均衡方法が提案されている。そのうち、使用されるリソース情報にはサーバのメモリ容量、メモリ容量使用済みパーセンテージ、CPU使用率、サーバ出口総バンド幅及びバンド幅使用率が含まれている。リソース割り当てポリシーの表現形式はサーバノードの選択アルゴリズムであり、出力は利用可能なサーバのシーケンスリストである。例えば、リソース割り当てポリシーは、CPU使用率が低いノードを優先的に選択し、各ノードのCPU使用率差異が一定の範囲内(例えば、5%〜10%)にある場合は、利用可能なバンド幅が大きいノードを優先的に選択し、各ノードの利用可能なバンド幅の使用率差異が一定の範囲内(例えば5%〜10%)にある場合は、利用可能な記憶空間が大きいノードを優先的に選択するように設定することができる。
特許文献1で提案された負荷均衡方法においては、サーバのサービス処理能力とサーバの負荷均衡のみを考慮し、当該サーバに到着するネットワークリンクの利用可能なバンド幅は考慮していなかったため、輻輳が発生し易いネットワーク環境において、サービス品質、特に高バンド幅を必要とするサービスに対してサービス品質の有効な保証ができない問題点がある。
特許文献2では、サービスのリソース需要に応じて、オーバレイネットワークにおいてエンドツーエンド(End−to−End)の最適負荷均衡サービスパスを検索してサービスのQoS(Quality of Service)需要を満たせるオーバレイネットワークにおける負荷均衡方法が提案されている。特許文献2は特許文献1の問題点を改善し、同時にノードの計算リソースとパスの伝送リソースがいずれもサービスのリソース需要を満たすことができるかどうかを考慮し、その中から最適なパスを一つ選択してユーザ要求に応答し、これによりユーザ体験を改善し、ネットワークリソースの利用効率を最適化する。しかしながら、当該特許文献における方法は、現在のサービス需要のための最適なリソース割り当てのみを考慮し、サービスの異なるリソース需要に対する相違性及び全体のリソース利用率の最大化を考慮していなかったため、サービスの動的変化、特に将来のリソース需要に対して不均衡なサービスの突発に適応することが難しい問題点がある。また、それぞれの到着したサービス要求に対して、最適なサービスパスを見つけるために、ネットワークに存在するすべての可能なパスを新たに検索する必要があるため、計算量が大きく、サービス効率が低下してしまう。
全体のリソース利用効率を最適化し、データセンターネットワークのサービス能力をさらに改善するために、本発明はルーティング意識を有する負荷均衡装置及び方法を提供し、サービス需要とネットワークリソースとの最適なマッチングを考慮にいれて、現在サーバの利用可能な負荷及びパスの利用可能なバンド幅を結び付けて、サーバ及びルーティングの組み合わせをサービスに割り当てる割り当て案を提供する。現在のデータセンター、特にモノのインターネット向けのデータセンターは複数のサービス種別をサポートし、例えば、検索に基づくサービスは低バンド幅と大量の計算リソースを必要とし、ビデオオンデマンドサービスは高バンド幅と少量の計算リソースを必要とし、センサーのサービスは低バンド幅と少量の計算リソースを必要とするように、異なる種類のサービスのサーバリソースとネットワークバンド幅リソースに対する需要にも相違がある。ユーザ行為が予知できないモノのインターネット応用については、サービストラフィックの不均等な分布につれて、あるサービスが集中したリンクにはバンド幅の利用率は高いが互いに接続されているサーバの負荷は非常に軽く、逆に、あるリンクにはバンド幅の利用率は低いが互いに接続されているサーバの負荷は重い可能性がある。前者はサービスの性能を低下させ、後者は大量のバンド幅リソースを無駄にする。
本発明は、動的データセンターネットワークにおいて異なるリソース需要のサービスに対してそのリソースとマッチング度合が最適なサーバ及びルーティングの組み合わせを選択し、サーバのサービス割り当てとパスのトラフィック割り当てを均衡にするとともにリソースの割り当て効率を改善し、これにより全体のリソース利用を最大化し、ネットワークの処理容量を向上させ、データセンターの建設コストを節約することができる負荷均衡装置及び負荷均衡方法を提供することを目的とする。
上述の目的を達するための本発明に係わる負荷均衡装置は、データセンターネットワークにおいて負荷均衡のリソース割り当てを行なう負荷均衡装置であって、サービスのサーバリソース需要とネットワーク伝送リソース需要に基づいてサービスを複数のサービスブロックに分割するとともに前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを複数のリソースブロックに分割し、前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを監視することにより、サーバに対するアイドルサーバリソースとアイドルネットワーク伝送リソースとの組み合わせを各リソースブロックと対応付け、データセンターネットワークに進入するサービス要求の属するサービスブロックを識別し、前記サービスブロックと前記リソースブロックとの間の対応関係に基づいて、当該サービス要求に対して前記アイドルサーバリソースとアイドルネットワーク伝送リソースとの組み合わせを割り当てることを特徴とする。
上述の目的を達するための本発明に係わる負荷均衡方法は、データセンターネットワークにおいて負荷均衡のリソース割り当てを行なう負荷均衡方法であって、サービスのサーバリソース需要とネットワーク伝送リソース需要に基づいてサービスを複数のサービスブロックに分割するとともに前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを複数のリソースブロックに分割する分割ステップと、前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを監視することにより、サーバに対するアイドルサーバリソースとアイドルネットワーク伝送リソースとの組み合わせを各リソースブロックと対応付ける監視ステップと、データセンターネットワークに進入するサービス要求の属するサービスブロックを識別し、前記サービスブロックと前記リソースブロックとの間の対応関係に基づいて、当該サービス要求に対して前記アイドルサーバリソースとアイドルネットワーク伝送リソースとの組み合わせを割り当てる割り当てステップと、を含むことを特徴とする。
以下、実施例と図面に基づいて、本発明の内容について詳しく説明する。
図1は本発明のデータセンター内部ネットワークの実施例を応用したシステム構成図であり、図1Aは実施例1に係わる集中型負荷均衡装置のデータセンターネットワークの構成図である。負荷均衡装置はデータセンターネットワークの入口に位置し、すべてのサーバの負荷割り当て及びすべてのパスのバンド幅割り当てを含むデータセンター全体に関連するリソース割り当てを管理する。図1Aに示すように、当該システムは負荷均衡装置100、101、スイッチ110〜116のようなスイッチングノード、及びサーバ120〜125を含み、ここでのサーバは物理サーバ装置であってもよいし、バーチャルマシンであってもよく、ユーザに一つまたは複数のサービス130〜133を提供する。負荷均衡装置100、101はアクセス側のスイッチングノード110、113と接続しており、複数の中間スイッチングノード111、112、114、115、116を介してサーバ120〜125に接続されている。アクセス側のスイッチングノード110、113と各サーバ120〜125との間には一本または複数本のパス140、141が存在する。ここでのパス140、141は双方向リンク対称パス、すなわち均衡装置からサーバへの下り方向とサーバから均衡装置への上り方向のリンクは完全に重なり合い、同時に両方向のバンド幅は異なってもよい。負荷均衡装置100、101はデータセンターのロジック入口点としてクライアント端末から送信されたサービス要求を受信し、サービス要求の種別と現在利用可能なリソース情報に基づいて適切なサーバ及び対応するパスの組み合わせを選択して転送し、サービス性能を確保するとともにネットワーク全体のリソースの利用効率と公平を考慮する。現在利用可能なリソース情報は、サーバのCPU未使用率、利用可能なメモリ容量、余剰接続数、余剰ネットワーク出口バンド幅等、パスの利用可能な最大バンド幅、パス遅延等の情報のような現在利用可能なサーバリソースと現在利用可能なネットワークリソース情報を含む。負荷均衡装置は一般的に主負荷均衡装置100と予備負荷均衡装置101に分類され、一つ独立した物理実体として存在してもよく、負荷均衡の機能をアクセス側のスイッチングノード110と113に統合してもよい。
図1Bは実施例2に係わる分散型負荷均衡装置のデータセンターネットワークの構成図である。実施例2に示すデータセンターネットワークには幾つかのサーバグループをそれぞれ管理する複数の分散型負荷均衡装置が存在し、データセンターの入口に位置している全体負荷均衡装置によって統一管理される。図1Bに示すように、サーバ120〜125は幾つかの小さいサーバグループ150、151に分けられ、各サーバグループ150、151内部の負荷割り当ては局部負荷均衡装置170、171によって管理される。すべての局部負荷均衡装置170、171はデータセンターネットワーク全体の入口に位置している負荷均衡装置100、101によって統一管理される。クライアント端末からのサービス要求がデータセンターネットワーク入口に到着した場合、負荷均衡装置100、101はサービス要求のために適切なサーバグループ150、151及び当該サーバグループへのパス140、141を選択し、サービス要求が選択されたパスに沿って選択されたサーバグループに到着した後に、さらにサーバグループ150、151の中の局部負荷均衡装置170、171によって異なるサーバ120〜125に割り当てられて処理される。ここでのパス140、141は実施例1におけるパスと特徴が同じであり、同様に双方向リンク対称パスである。
その他の実施例においては、図1Cの実施例3に示すように、負荷均衡装置がサービスに割り当てるパスは双方向リンク非対称パスである。すなわち、均衡装置からサーバへの下り方向とサーバから均衡装置への上り方向のリンクは重なり合わず、バンド幅も異なる可能性がある。負荷均衡装置100、101は異なる下りパス140と上りパス140rをサービス種別130に割り当てる。サービス要求はパス140を経由してサーバ120に到着し、サーバ120はメッセージに応答してパス140rを経由してクライアント端末に送信する。
図2は実施例1に係わる負荷均衡装置の機能実体図であり、データ受信ユニット201、202、データ処理ユニット210、記憶装置230、およびデータ転送ユニット250を含む。そのうちデータ処理ユニット210は負荷均衡モジュール220と監視モジュール240を含む。データ受信ユニット201、202は主にユーザのサービス要求とデータセンターネットワークの監視メッセージを受信する。データ処理ユニット210の中の負荷均衡モジュール220は主に受信したサービス要求を処理し、以下のような機能を実行する。すなわち、サービス/リソースブロック分割設定機能221はサービスブロックとリソースブロックの分割ポリシー及びそのマッピング関係を予め配置する。サービス識別機能222は受信したサービス要求パケットのコンテンツをチェックすることで当該サービス種別を識別し且つどのサービスブロックに属するかを判定する。サーバ/パス組み合わせポリシー決定機能223はサービスの属するサービスブロック情報に基づいて予め設定されたポリシーにしたがってリソースブロックから適切なサーバ及びパスの組み合わせを検索する。具体的な検索アルゴリズムについては後で詳しく説明する。パス配置機能224は選択したパスが経由するスイッチにパスを配置して情報を転送するよう通知する。具体的なスイッチの作動過程及びパス配置プロセスについては後でさらに詳しく説明する。負荷均衡モジュール220は配置情報を記憶装置230の関連テーブル、例えば、サービスブロックとリソースブロックの第一選択マッピングテーブル232、サーバ/パス記録テーブル235及びサービス分類テーブル236に記憶し、サービス要求メッセージを処理した後、記憶装置230の中の関連テーブル、例えば、セッション転送テーブル231などを更新し、選択されたパスに沿って選択されたサーバにサービス要求をデータ転送ユニット250に転送させる。データ処理ユニット210の中の監視モジュール240は主にネットワークの中の一つのスイッチングノード、サーバ装置または集中型機能管理サーバからの監視メッセージを処理する。そのうち、パス監視メッセージ処理241はデータ転送ユニット250によってネットワークの中のスイッチングノード監視装置にプローブ要求を送信し、スイッチングノード監視装置から送信されたネットワークの利用可能なリソース情報、例えばネットワークポートの利用可能なバンド幅、遅延などを処理する。サーバ監視メッセージ242はデータ転送ユニット250によってプローブ要求をサーバ監視装置に送信し、サーバ監視装置から送信されたサーバの利用可能なリソース情報、例えばサーバのCPU未使用率、利用可能なメモリ容量、剰余接続数、剰余ネットワーク出口バンド幅等を処理する。監視モジュール240は受信した監視メッセージを処理した後、メモリユニット230の中の関連テーブル、例えばサーバ/パスの現在利用可能な容量テーブル233、リソースブロックとサーバ/パス組み合わせ記録テーブル234等を更新する。通常、サービス要求受信ユニット201、監視メッセージ受信ユニット202、データ転送ユニット250はネットワークインターフェースによって実現し、記憶装置230はメモリまたは高速バッファによって実現し、データ処理ユニット210はCPU等のプロセッサによって実現する。
図3は実施例1に係わるパス配置機能を有するスイッチの機能実体図である。主にMAC層インターフェース300、ブリッジユニット310及び記憶装置320を含む。MAC層インターフェース300はデータ受信器301とデータ送信器302を含む。データ受信器301は一般ユーザMACデータフレーム、ブリッジプロトコルデータユニット(BPDU)、及び負荷均衡装置からのパス配置要求メッセージを受信し、データ送信器302は処理済みの一般ユーザMACデータフレームとパス配置応答メッセージをネットワークに送信する。ブリッジユニット310は主にフレーム中継モジュール311、転送決定モジュール312、STPモジュール313、MAC学習モジュール314、パス配置メッセージ処理モジュール315及びデータ配信モジュール316のような六つの機能モジュールを含む。MAC層インターフェース300は受信したMACフレームをブリッジデータ配信モジュール316に転送し、ブリッジデータ配信モジュール316はMACフレームの種別に基づいてMACフレームを異なる機能モジュールにさらに処理させる。ブリッジプロトコルデータユニット(BPDU)であればSTPモジュール313にさらに処理させ、メッセージ処理結果に基づいてSTP(Spanning Tree Protocol)モジュール313が動的転送フィルタリングテーブル322を更新する(図22Bに示すように)。当該動的転送フィルタリングテーブル322は主に宛先MACアドレスとスイッチ転送ポートの二つのドメインを含む。負荷均衡装置からのパス配置要求メッセージであれば、パス配置情報に基づいて静的転送フィルタリングテーブル321をパス配置メッセージ処理モジュール315に更新させ(図22Aに示すように)、パス配置応答メッセージを負荷均衡装置に送信する。当該静的転送フィルタリングテーブル321は主にVLANID、送信元MACアドレス、宛先MACアドレス、スイッチ入口ポート及び転送ポートを含む。一般ユーザMACデータフレームであれば、送信元MACアドレスをMAC学習モジュール314に学習させるかまたはフレーム中継311に中継させ、転送待ちキューがアイドル状態になったときに転送決定モジュール312にスイッチ転送ポートを決定させる。転送プロセスは以下の通りである。転送決定モジュール312は先ず記憶装置320の中の静的転送フィルタリングテーブル321に対応する転送記録が存在するかどうかをチェックし、存在する場合、サービス要求を対応する転送記録の中のスイッチ出口ポートに転送し、静的転送フィルタリングテーブル321の中から対応する転送記録が見つからなかった場合、動的転送フィルタリングテーブル322に基づいて当該データフレーム転送ポートを決定して対応するスイッチ出口ポートに転送する。
図4は実施例1に係わるサービス要求転送処理時系列図の一つの実施例である。クライアント端末180は第一のサービス要求410をデータセンターネットワークに送信し、負荷均衡装置100はサービス要求410を受信した後に、当該サービス要求のために最適なサーバ/パス組み合わせを計算し、セッション転送情報をセッション転送テーブル231に記憶し、当該サービス要求のために転送パス411を配置するよう関連スイッチに通知する。配置終了後に負荷均衡装置100は選択されたパスに沿って選択されたサーバ120に当該サービス要求413、414を送信し、サービス提供に選択されたサーバ120はサービス要求メッセージを受信した後に当該サービス要求を処理し、クライアント端末180に応答メッセージ415、416を送信する。クライアント端末180がデータセンターネットワークにこの後のサービス要求メッセージ420を送信する際に、負荷均衡装置100はセッション転送テーブル231から対応する転送記録を見つけ、記録の中のサーバ/パス組み合わせに沿って当該サービス要求421を転送する。サーバ120はサービス要求を処理した後に応答メッセージ422をクライアント端末に送信する。
図5は実施例1に係わるパス配置メッセージ処理時系列図の一つの実施例である。負荷均衡装置100は受信したサービス要求のために最適なパスを計算した後に、関連するパス配置メッセージ501、502をすべてのスイッチ110、111にブロードキャストする。パス配置メッセージのフォーマットは図21に示すように、イーサネット(登録商標)ヘッダ2101、パス配置プロトコルID2102、パス配置メッセージ種別2103、配置スイッチID2104、VLAN ID2105、セッション送信元MACアドレス2106、セッション宛先MACアドレス2107、スイッチ入口ポート2108、スイッチ転送ポート2109のような領域を含む。スイッチ110、111はパス配置ブロードキャストメッセージを受信した後に、配置スイッチID2104が本スイッチと同じであるかどうかをチェックし、本スイッチIDと一致する場合、パス配置要求におけるセッション転送メッセージに基づいてスイッチの静的転送フィルタリングテーブル321を配置し、配置が終了した後にパス配置OKメッセージ522を負荷均衡装置に送信する。逆に、本スイッチIDと一致しない場合、当該メッセージ521を放棄する。その後、当該サービス要求がスイッチ111を経由するときに、配置スイッチID2104と本スイッチIDが一致する場合、スイッチは配置済みの静的パスに基づいてサービスを対応するポートに転送する。当該サービスが終了した場合、負荷均衡装置100は対応するパス配置取消要求531をスイッチ110、111にブロードキャストし、関連スイッチ111がパス配置取消要求を受信し後に対応する転送記録533を転送テーブルから削除し、パス配置取消OKの応答メッセージを負荷均衡装置100に送信し、関連パス配置535を取消したことを負荷均衡装置100に通知する。その他の実施例において、スイッチ111は静的転送フィルタリングテーブル321の中の関連転送記録のためにタイマーを設置し、当該セッションのサービス要求送信間隔がある閾値を超えた場合、対応する記録を削除することができる。
以下、図1Aにおけるデータセンターネットワークトポロジー実施例に基づいて負荷均衡装置の作動プロセスについて詳しく説明する。
サービスが起動する前に、負荷均衡装置は最初に初期化操作を実行し、システムの初期配置を完成させる。
図6は実施例1に係わる負荷均衡装置の初期化フローチャートである。負荷均衡装置におけるデータ処理ユニット210は以下のステップを実行する。
ステップ600において、負荷均衡装置は各サーバに到着する利用可能なパス集合を予め計算する。ルーティングを予め計算する一つの実施例のフローチャートは図12に示す通りである。先ず、ネットワークトポロジー情報1200を収集し、リンクのmetric情報1201を収集する。その後、CSPFルーティングアルゴリズムを利用して各サーバに到着する利用可能なパス集合1202を計算する。本分野において、よく使われているmetricはバンド幅、遅延、パス長さ、信頼性、負荷、通信コストの中の一つであり、複雑なルーティングアルゴリズムについては複数のmetricに基づいてルーティングを選択し、それらを一つ複合のmetricに組み合せる。本発明における以下の説明ではmetricがバンド幅であることを例にして説明をする。
ステップ601において、計算結果及び関連情報をサーバ/パス記録テーブル235に記憶する。図16Aに示すように、当該サーバ/パス記録テーブル235は主にサービス種別、サーバID、総CPU、パス/バンド幅リストなどの幾つかの領域を含み、各サーバがサポートするサービス種別、ID番号、CPU総量、利用可能なパスルーティング情報及び各パスの総バンド幅をそれぞれ記録する。パス/バンド幅リスト領域において、パスは双方向リンク対称パスであり、バンド幅は下りリンクバンド幅である。
その他の実施例において、リソース最適化のポリシーによって、バンド幅は、パスの二つの方向における利用可能なバンド幅の小さい値、もしくは平均値、あるいは上りリンクバンド幅などのようなその他の予め定義された値でよい。
リンク非対称パスの実施例3において、パス/バンド幅リストは二つの方向のパス及びバンド幅をそれぞれ含んでよく、対応するサーバ/下りパス/上りパス記録テーブルは図16Bに示す通りである。
ステップ602において、サーバ/パスの現在利用可能な容量テーブル233を初期化する。当該テーブルは、図17Aに示すように、主に各サーバ上の現在利用可能な容量及び当該サーバに到着する各パスの利用可能な容量情報を記録する。サービスが起動する前に、すべてのサーバとパスの利用可能な容量はいずれも総容量である。パス非対称の実施例3において、パスの現在利用可能な容量は下りパスと上りパスの利用可能な容量を含み、対応するサーバ/下りパス/上りパスの現在利用可能な容量テーブルは図17C、17Dに示す通りである。
ステップ603において、サービスブロックとリソースブロックの分割ポリシー及びそのマッピングテーブルを定義する。当該ステップにおいて行なわれる処理は前記負荷均衡モジュール220の中のサービス/リソースブロック分割設定機能221に対応する。
サービスブロックの分割ポリシーは、それぞれのサービスのリソース需要に対する大きさSとRに基づいてサービスを分類する。ここで、Sは当該サービスの処理に必要なサーバリソース、例えばCPU利用率であり、Rは当該サービスの伝送に必要なネットワークリソース、例えば下り方向のネットワークバンド幅である。Sの値の範囲が[Smin、Smax]で、Rの値の範囲が[Rmin、Rmax]であるとすると、Sの値空間を各サブ空間の長さがそれぞれS1、S2、・・・、SmであるM個のサブ空間に分け、Rの値空間を各サブ空間の長さがそれぞれR1、R2、・・・、RnであるN個のサブ空間に分けて、SとRから構成される二次元平面空間をM*N個の空間ブロックに分割し、それをサービスブロックと称する。各サービスブロックの値範囲はそれぞれ
その他の実施例において、サービスのネットワークに対するリソース需要は二つの方向上のバンド幅需要の最大値、もしくは平均値あるいはその他の予め定義された値でよい。
また別の実施例において、例えばパス非対称の実施例3において、サービスのネットワークリソースに対する需要は双方向であってよく、図15Aに示すように、サービスのリソースに対する需要の三次元空間CPU/下りバンド幅/上りバンド幅に基づいてサービスブロックを分割する。また、サービスのリソースに対する需要空間はさらに多い情報、例えば、メモリ、エネルギー消耗、遅延などのような情報を考慮して、サービスのリソースに対する需要空間をさらに高次元に拡張してもよい。
各サービスの必要なリソースの具体的な数値は過去のデータを統計することにより得られる。各次元上のサブ空間MとNの値はサービスクラスタリングの方法によって確定できる。以下、ネットワークに基づくファジークラスタリング方法を例にして具体的に説明する。先ず、サービスの値空間の各次元をすべてK等分して幾つかの均等なグリッドユニットに分割し、グリッドユニットの数は予期したサービスブロックの数M*Nより遥かに大きい。各サービスをリソース需要の大きさに基づいてグリッドユニットにマッピングし、各グリッドユニットの密度即ち当該グリッドユニットに入ったサービスの数を計算し、少なくとも一つのサービスを含むグリッドユニットを有効グリッドユニットと称し、一つのサービスも含まないグリッドユニットを空きグリッドユニットと称する。クラスタリングの前に、各サービスブロックに含まれているサービス数が密度閾値の最小値DENSITYminと密度閾値の最大値DENSITYmaxの間になるように各サービスブロックの密度範囲を設定する。ある有効グリッドユニットの密度が大きすぎた(>DENSITYmax)場合、すべての有効グリッドユニットの密度が予め設定された密度閾値の最大値より小さくなるまでにKの値を増やしてグリッドユニットを新たに分割する。ある有効グリッドユニットの密度が小さすぎた(<DENSITYmin)場合、隣接するグリッドユニットを合併することでグリッドユニットの密度を増やす。すべての有効グリッドユニットが密度閾値要求を満たすまでにこのようなプロセス繰り返す。有効グリッドユニットの境界と周囲の空きグリッドユニットを検出し、幾つかの値空間が連続するサービスブロックを連結形成し、その後各サービスブロックの値範囲に基づいて各次元上のMとNの値を確定する。
上述のサービスクラスタリングの方法によって各サービスブロックの値範囲を確定するのはただ一つの例であり、当然ながらその他の方法によって分割することも可能である。例えば、等間隔分割の方法によって各サービスブロックの値範囲を均等に確定することも可能であり、このような方法はサービスブロックを分割する際の処理負担を低減することができる。
リソースブロックの分割ポリシーは、サーバのアイドル計算リソース(例えば、CPU未使用率)及び接続されたパスのアイドルネットワークリソース(例えば、下りネットワークバンド幅)を幾つかの種類に分類し、システム運転過程において、各サーバ/パス組み合わせは現在所有するアイドルリソースの状況に基づいて異なるリソースブロックに入る。ネットワークにおいてサーバの最大リソースがNSmaxで、下りパスの最大バンド幅がNRmaxであるとすると、サーバリソースの値範囲は[0、NSmax]で、ネットワークバンド幅の値範囲は[0、NRmax]である。アイドルサーバリソースとアイドルネットワークバンド幅リソースから構成された二次元平面空間をM*N個の空間ブロックに分割し、それをリソースブロックと称する。そのうち、各リソースブロックのそれぞれのサブ空間の値範囲とサービスブロックのそれぞれのサブ空間の値範囲は同じトレンドで確定してもよいし(例えば図14A、図14Bに示すように)、サービスブロックのそれぞれのサブ空間の値範囲の比例に応じて確定してもよく、さらに等間隔分割の方法などによって均等に確定してもよい。サーバリソースの値空間上のそれぞれのサブ空間の長さが順次NS1、NS2、・・・、NSmで、ネットワークバンド幅の値空間上のそれぞれのサブ空間の長さが順次NR1、NR2、・・・、NRnであるとすると、各リソースブロックの値範囲はそれぞれ、
その他の実施例において、サーバ/パス組み合わせを異なるリソースブロックに分割するときに、ネットワークリソースはパスの双方向上の利用可能なバンド幅の最大値、もしくは平均値あるいはその他の予め定義された値に基づいて分割してよい。
また別の実施例において、例えばパス非対称の実施例3において、サーバ/下りパス/上りパスに基づいてリソースブロックを分割してよい。この際のリソースブロックの値空間は、図15Bに示すように、利用可能なCPU/下りパスの利用可能なバンド幅/上りパスの利用可能なバンド幅の三次元情報に拡張される。また、リソースブロックの値空間はさらに多い情報、例えば、メモリ、余剰エネルギー、リンクの現在遅延などの情報も考慮して、リソース空間をさらに高次元に拡張してもよい。
サービスブロックとリソースブロックのマッピング規則は、各サービスブロックが複数のリソースブロックの中で当該サービスブロック位置に対応するリソースブロックであるマッピングリソースブロックを第一に選択する。即ち、各サービスブロック上のサービスにサーバとネットワークリソースを割り当てる際に、先ず、第一に選択されたリソースブロック上のサーバ/パス組み合わせを検索する。例えば、図14Cは14Aと14Bに対応して二次元属性に基づいて分割した第一選択マッピングテーブルの一つの実施例で、図15Cは15Aと15Bに対応して三次元属性に基づいて分割した第一選択マッピングテーブルの別の一つの実施例である。第一選択マッピングリソースブロックにサービスリソース需要を満たすサーバ/パス組み合わせがなかった場合、サービス需要を満たすサーバ/パス組み合わせが検索されるまで、先ず値範囲がサービスリソース需要を満たさないリソースブロックを削除し、残りのリソースブロックを検索領域とし、その後、第一選択リソースブロックを中心に近から遠に向かって一層ずつスクロール検索を展開する。スクロール検索プロセスは以下の通りである。先ず、第一選択リソースブロックに近い第一層の利用可能なリソースブロックの中から一つのリソースブロックをランダムに選択し、当該リソースブロックの中から条件を満たすサーバ/パス組み合わせがあるかどうかを検索し、あった場合は検索を停止し、なかった場合は、当該層の利用可能なリソースブロックの検索が終了するまでに、時計回り順(例えば、図15BにおけるS111、S121、S221、S211の順)または反時計回り順(例えば、図15BにおけるS111、S211、S221、S121の順)に、当該層の次のリソースブロックを検索する。条件を満たすサーバ/パス組み合わせが依然として見つからなかった場合、第二層の利用可能なリソースブロックの検索を開始し、検索領域のリソースブロックの検索が終了するまでに、第三層、第四層、・・・を順次検索する。
ステップ604において、サービスのリソースに対する需要に基づいてサービス分類テーブル236を初期化し、図18に示すように、各サービスのサービス種別、リソース需要に対する数値及び所属するサービスブロックを記録する。
ステップ605において、リソースブロックとサーバ/パス組み合わせ記録テーブル234を初期化し、図19Aに示すように、当該テーブルは各リソースブロックに属するサーバ/パス組み合わせを記録する。サービスが起動する前に、すべてのサーバとパスはアイドル状態であるため、いずれもリソースブロックS33の中にある。パス非対称の実施例3においては、図19Cに示すように、各リソースブロックには当該リソースブロックに属するサーバ/下りパス/上りパス組み合わせが記録されている。
初期化操作が終了した後に、サービスが起動し、負荷均衡装置は到着したパケットの処理を開始し、各サービス要求のためにサーバとパスを割り当てる。処理プロセスの概要は図7に示す通りである。
ステップ701において、受信したパケットをチェックし、そのメッセージ種別を判定する。監視メッセージである場合はステップ710に進み、サービス要求メッセージである場合はステップ702に進む。
ステップ710において、図17Bと図19Bに示すように、受信したサーバまたはネットワークの監視メッセージに基づいてサーバ/パスの現在利用可能な容量テーブル233を更新し、現在利用可能な容量情報及びリソースブロックの分割ポリシーに基づいて所属するリソースブロックを更新する。パス非対称の実施例3においては、図17Dと19Dに示すように、現在サーバ/下りパス/上りパスの現在利用可能な容量テーブルに記録された容量情報に基づいて、各リソースブロックの中のサーバ/下りパス/上りパス組み合わせを更新する。
ステップ702において、当該サービス要求が新しい接続からのサービス要求であるかどうかをチェックし、当該接続がすでにセッション転送テーブル231に存在している場合はステップ720に進み、当該記録テーブルから対応するサーバ/パス組み合わせを見つけて転送を行なう。新しい接続要求である場合はステップ703に進み、当該サービス要求のために最適なサーバとパスを検索してサービスを提供する。
ステップ703において、サービス要求のサービス種別を識別し、サービスの属するサービスブロックを決定する。当該ステップ703で行なわれた処理は前記負荷均衡モジュール220の中のサービス識別機能222に対応する。当該プロセスの一つの実施例は図8に示す通りである。先ず、ステップ800において、受信したパケット内容をチェックし、パケット内容の属するサービス種別を判定し、その後ステップ801において、サービス分類テーブルに基づいて当該サービスが既知のサービス種別であるかどうかを判定する。既知のサービス種別である場合は、ステップ810においてサービス分類テーブル236に基づいて当該サービス種別の属するサービスブロックを探し、未知のサービス種別である場合は、ステップ802〜806に記載された方法にしたがって当該サービスの属するサービスブロックを決定する。先ず、ステップ802において、予め設定されたポリシーに基づいて当該サービスのために一つのサービスブロック、例えば、ポートの範囲、プロトコルの種別、サービスの優先度等によって、対応するプログラムの過去の情報統計結果に基づいて所属するサービスブロックを設定する。その後、ステップ803において当該サービスのトラフィック情報を監視するよう負荷均衡装置もしくは経由するスイッチに通知し、ステップ804において当該サービスの占用するリソース情報を監視するようサーバに通知し、ステップ805において当該サービスに必要なネットワークバンド幅リソースとサーバ計算リソースを収集し、そのリソースをサービス分類テーブル236に追加し、最後にステップ806において測定した当該サービスに必要なリソース及びサービスブロック分割ポリシーに基づいて当該サービス種別の属するサービスブロックを決定し、サービス分類テーブル236の対応する記録に追加する。
ステップ703においてサービスの属するサービスブロックを確定した後に、ステップ704において、サービスブロックとリソースブロックの第一選択マッピングテーブル232に基づいて当該サービスブロックに対応する第一選択マッピングリソースブロックを探す。当該第一選択マッピングリソースブロックに基づいて、ステップ705〜706においては当該サービスのために最適なサーバ/パス組み合わせを検索してネットワークとサーバにおけるサービストラフィックの分布を均衡にし、データセンターネットワーク全体のリソース利用率を最適化する。検索アルゴリズムの具体的な実施プロセスは図9〜11においてさらに詳しく説明する。そのうち、ステップ704〜ステップ706で行なわれた処理は前記負荷均衡モジュール220の中のサーバ/パスポリシー決定機能223に対応する。
ステップ707において、図20に示すように、当該サービス要求接続情報および対応する最適なサーバ/パス組み合わせをセッション転送テーブル231に記憶する。当該セッション転送テーブルは、主にセッションID、サービス種別、送信元IPアドレス、宛先IPアドレス、対応するVLAN ID、送信元MACアドレス、宛先MACアドレス、および当該サービスの接続のために割り当てられた<宛先サーバ、経由パス>の幾つかの領域を含む。次の同一接続からのパケットが到着した場合、当該セッション転送テーブルに基づいて対応するサーバ/パス組み合わせを探して転送を行なえばよく、新たに検索する必要がない。
ステップ708において、当該サービスのために割り当てられた最適なパスに基づいて当該パスを配置するよう関連するスイッチに通知する。当該ステップ708で行なわれた処理は前記負荷均衡220の中のパス配置機能224に対応する。
ステップ709において、当該パスに沿ってサービス要求を割り当てられたサーバに転送し、その後、割り当てられたサーバにより当該サービス要求のためにサービスを提供する。当該ステップ709で行なわれた処理は図2の中のデータ転送ユニットに対応する。
図9〜図11は検索アルゴリズムの一つの具体的な実施例である。検索プロセスは主に、図9〜図10に示すように、リソースブロックからサービス需要に適する利用可能なサーバ/パス組み合わせの集合を検索する第一のステップと、図11に示すように、利用可能な集合から最適なサーバ/パス組み合わせを選抜する第二のステップと、を含む。利用可能なサーバ/パス組み合わせの集合を検索する具体的なプロセスは以下の通りである。
ステップ900において、サービスブロックとリソースブロックの第一選択マッピングテーブル232に基づいて、当該サービスブロックに対応する第一に選択検索するリソースブロックSxyを探し、その後、ステップ901において、リソースブロックとサーバ/パス組み合わせ記録テーブル234から当該リソースブロックSxyにサーバ/パス組み合わせ記録が存在するかどうかをチェックし、存在する場合はステップ902に進む。
ステップ902において、リソースブロックSxyに含まれている第一のサーバ/パス組み合わせを選択し、その後、ステップ903において、サーバ/パス組み合わせリスト記録に基づいて当該組み合わせの中のサーバが当該サービス要求をサポートするかどうかをチェックし、サポートする場合は、ステップ904において当該組み合わせの中の利用可能な容量の絶対値が当該サービスリソースの需要を満たすかどうかをチェックし、当該サービスリソースの需要を満たす場合は、ステップ905において、当該サーバ/パス組み合わせを利用可能なサーバ/パスの集合に記憶し、その後ステップ906に進み、当該リソースブロックの中のすべてのサーバ/パス組み合わせのチェックを終了し、条件を満たす組み合わせをすべて利用可能なサーバ/パス集合に記憶するまで、同様な方法でリソースブロックSxyの中の次のサーバ/パス組み合わせがサービス需要を満たすかどうかをチェックする。あるサーバ/パス組み合わせがステップ903とステップ904において需要を満たしていない場合、当該組み合わせをとばしてステップ906に進んで次の組み合わせをチェックする。
第一選択マッピングリソースブロックSxyに対応するすべてのサーバ/パス組み合わせの検索が終了した後に、ステップ907において利用可能なサーバ/パス集合が空であるかどうかをチェックし、空でない場合は、図11のプロセスにしたがって当該集合から最適な組み合わせを選抜し、空である場合はステップ908に進んで、図10に示すように、サービス需要を満たすリソースブロックをすべて検索終了するまでに、リソースブロックSxyを中心に近から遠に向かって隣接するリソースブロックに対してスクロール検索を展開する。
図10は第一選択リソースブロックSxyを中心に近から遠に向かって隣接するリソースブロックに対して時計回りのスクロール検索を展開する一つの実施例である。具体的なプロセスは以下の通りである。
ステップ1000において、当該サービスのサーバに対するリソース需要はCrで、ネットワークバンド幅に対するリソース需要はBrであることが分り、ステップ1001において、当該サービス需要を満たすリソースブロック領域の境界の最小値SMNを計算し、SUV(U=M、M+1、・・・、V=N、N+1、・・・)の集合をリソースブロック検索領域と確定し、当該領域で利用可能なサーバ/パス組み合わせを検索する。
ステップ1002においてはステップ1003〜1007にしたがってリソースブロックSxyに隣接する第一層のリソースブロックで検索を開始する。先ず、ステップ1003において、リソースブロック検索領域の範囲によって当該層の中でサービス需要を満たすリソースブロック集合Gを確定し、その後ステップ1004において、リソースブロック集合Gから一つのリソースブロックSijをランダムに選択し、図9に示すプロセスにしたがって、その中から利用可能なサーバ/パス集合を検索する。ステップ1005において、当該利用可能なサーバ/パス集合の中にサーバ/パス組み合わせの記録が存在するかどうかをチェックし、存在する場合は検索を停止し、存在しない場合はステップ1006に進み、利用可能なサーバ/パス組み合わせが検索されるまでに、リソースブロック集合Gにおいて時計回りの順に次のリソースブロックを順次に検索する。ステップ1007において、リソースブロック集合Gの中のすべてのリソースブロックを検索終了しても利用可能なサーバ/パス組み合わせが見つからなかった場合はステップ1008に進み、リソースブロック検索領域の中のすべてのリソースブロックを検索終了するまでに、同様な方法で前記第一層のリソースブロックに隣接する第二層のリソースブロックをスクロール検索し、第三層のリソースブロック、第四層のリソースブロック、・・・を順次にスクロール検索する。第二層のリソースブロックをスクロール検索する際に、第一の検索点はSxyとSijの延長線と当該次の層のリソースブロックとが交差するリソースブロックを選択してもよく、ランダムに選択してもよい。その後時計回りの順に隣接する次のリソースブロックを順次検索する。図14Bの状況を例にすると、リソースブロックSxyがS11の場合、リソースブロックSxyに隣接する第一層のリソースブロックはS12、S22及びS21であり、前記第一層のリソースブロックに隣接する第二層のリソースブロックはS13、S23、S33、S32、S31である。
隣接するリソースブロックにおいて検索する方法は図10のプロセスに限らず、反時計回りの順またはランダムの順に検索してもよい。検索する基本原則として、第一は、第一選択リソースブロックSxyの利用可能なリソース数値との差が小さいリソースブロックを優先的に検索し、第二は、周囲のリソースブロックの検索頻度のバランスをできるだけ保ち、あるリソースブロックの過度な検索を避けることである。
検索された利用可能なサーバ/パス集合から最適なサーバ/パス組み合わせを選抜するプロセスは図11に示す通りで、具体的なプロセスは以下の通りである。
ステップ1101において、当該利用可能なサーバ/パス集合から第一のサーバ/パス組み合わせを選択し、現在最小リソース消費が無限大(∞)になるように初期化する。
ステップ1102において、当該組み合わせのリソース消費を計算し、計算方法は図13に示す通りである。要求されるサービスのサーバに対するリソース需要がCr、ネットワークバンド幅に対するリソース需要がBr、当該組み合わせの中のサーバの現在利用可能な容量がCA、パスの現在利用可能なバンド幅がBAであるとすると、リソース消費LBcは下式になる。
LBc=Cr/CA+Br/BA
ステップ1103において、当該組み合わせのリソース消費が現在最小リソース消費より小さいかどうかをチェックし、現在最小リソース消費より小さい場合は、ステップ1104に進み、当該サーバ/パス組み合わせを現在最適な選択に設定し、リソース消費を現在最小リソース消費に設定し、逆の場合は当該組み合わせをとばす。続いて、ステップ1105において、当該利用可能なサーバ/パス集合の中に次のサーバ/パス組み合わせが存在するかどうかをチェックし、存在する場合は、当該利用可能なサーバ/パス集合の中のすべてのサーバ/パス組み合わせのチェックが終了するまでに、1102〜1104と同様のプロセスにしたがってリソース消費を計算し、現在最小リソース消費と現在最適なサーバ/パス組み合わせを選択する。このときに、前記利用可能なサーバ/パス集合をクリアし、現在最適選択を当該サービス要求に割り当てられたサーバとパスとする。
Claims (11)
- データセンターネットワークにおいて負荷均衡のリソース割り当てを行なう負荷均衡装置であって、
サービスのサーバリソース需要とネットワーク伝送リソース需要に基づいてサービスを複数のサービスブロックに分割するとともに前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを複数のリソースブロックに分割し、
前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを監視することにより、サーバに対するアイドルサーバリソースとアイドルネットワーク伝送リソースとの組み合わせを各リソースブロックと対応付け、
データセンターネットワークに進入するサービス要求の属するサービスブロックを識別し、前記サービスブロックと前記リソースブロックとの間の対応関係に基づいて、前記アイドルサーバリソースとアイドルネットワーク伝送リソースとの組み合わせを当該サービス要求に割り当てる
ことを特徴とする負荷均衡装置。 - 前記サービス要求および監視メッセージを受信するデータ受信ユニットと、
前記データ受信ユニットから受信した前記サービス要求および前記監視メッセージを処理するデータ処理ユニットと、
前記データセンターネットワークのリソース情報およびデータ処理に必要な情報を記憶する記憶装置と、
前記データ処理ユニットの処理結果に基づいて、前記サービス要求を転送するデータ転送ユニットと、を備える
ことを特徴とする請求項1に記載の負荷均衡装置。 - 前記監視メッセージは前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースの情報を含み、
前記データ処理ユニットは前記監視メッセージに基づいて各前記アイドルサーバリソースとアイドルネットワーク伝送リソースの組み合わせと前記リソースブロックとの対応関係を更新する
ことを特徴とする請求項2に記載の負荷均衡装置。 - 前記負荷均衡装置の初期化プロセスにおいて、前記データ処理ユニットは前記サーバリソース需要の値空間を複数のサブ空間に分割し、前記ネットワーク伝送リソース需要の値空間を複数のサブ空間に分割することにより、前記サーバリソース需要と前記ネットワーク伝送リソース需要から構成された二次元空間を複数のサービスブロックに分割し、
前記データ処理ユニットはアイドルサーバリソースとアイドルネットワーク伝送リソースから構成された二次元空間を、前記複数のサービスブロックにそれぞれ対応する複数のリソースブロックに分割する
ことを特徴とする請求項2に記載の負荷均衡装置。 - 前記データ処理ユニットは受信したサービス要求のサービス種別を識別し、当該サービス要求に対応するサービスブロックを判定し、
前記データ処理ユニットは複数のリソースブロックから当該サービス要求の対応するサービスブロック位置に対応するリソースブロックを確定し、当該リソースブロックに対応するアイドルサーバリソースとアイドルネットワーク伝送リソースの組み合わせから当該サービス要求のリソース需要を満たす組み合わせを検索する
ことを特徴とする請求項4に記載の負荷均衡装置。 - 前記データ処理ユニットは受信したサービス要求のサービス種別を識別し、当該サービス要求に対応するサービスブロックを判定し、
前記データ処理ユニットは複数のリソースブロックから当該サービス要求の対応するサービスブロック位置に対応するリソースブロックを確定し、当該リソースブロックに対応するアイドルサーバリソースとアイドルネットワーク伝送リソースの組み合わせに当該サービス要求のリソース需要を満たす組み合わせが存在しない場合は、リソース需要を満たす組み合わせが見つかるまでに、当該リソースブロックを中心に近から遠に向かって隣接するリソースブロックに対してスクロース検索を行なう
ことを特徴とする請求項4に記載の負荷均衡装置。 - 検索された当該サービス要求のリソース需要を満たす組み合わせが複数である場合、当該サービス要求が前記各組み合わせを利用するときのリソース消費をそれぞれ計算し、最小のリソース消費に対応する組み合わせを選択する
ことを特徴とする請求項5または6に記載の負荷均衡装置。 - 前記サーバリソース需要はサーバのCPU使用率で、前記ネットワーク伝送リソース需要は当該サービスを伝送する際の下り方向バンド幅需要、上り方向バンド幅需要、あるいは上り下り双方向上のバンド幅需要の小値もしくは平均値であり、
前記アイドルサーバリソースはサーバのCPU未使用率で、前記アイドルネットワーク伝送リソースは当該サーバに関連するパスの下り方向利用可能なバンド幅、上り方向利用可能なバンド幅、または上り下り双方向上の利用可能なバンド幅の小値もしくは平均値である
ことを特徴とする請求項1に記載の負荷均衡装置。 - 前記サーバリソース需要はサーバのCPU使用率で、前記ネットワーク伝送リソース需要は当該サービスを伝送する際の下り方向バンド幅需要と上り方向バンド幅需要であり、
前記アイドルサーバリソースはサーバのCPU未使用率で、前記アイドルネットワーク伝送リソースは当該サーバに関連するパスの下り方向利用可能なバンド幅と上り方向利用可能なバンド幅である
ことを特徴とする請求項1に記載の負荷均衡装置。 - 前記負荷均衡装置の初期化段階において、前記CPU使用率の値空間を複数のサブ空間に分割し、前記当該サービスを伝送するときの下り方向バンド幅需要と上り方向バンド幅需要の値空間をそれぞれ複数のサブ空間に分割することにより、前記CPU使用率、前記サ下り方向バンド幅需要及び前記上り方向バンド幅需要から構成された三次元空間を複数のサービスブロックに分割し、
前記CPU未使用率、前記下り方向利用可能なバンド幅及び前記上り方向利用可能なバンド幅から構成された三次元空間を前記複数のサービスブロックにそれぞれ対応する複数のリソースブロックに分割する
ことを特徴とする請求項9に記載の負荷均衡装置。 - データセンターネットワークにおいて負荷均衡のリソース割り当てを行なう負荷均衡方法であって、
サービスのサーバリソース需要とネットワーク伝送リソース需要に基づいてサービスを複数のサービスブロックに分割するとともに前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを複数のリソースブロックに分割する分割ステップと、
前記データセンターネットワークにおけるアイドルサーバリソースとアイドルネットワーク伝送リソースを監視することにより、サーバに対するアイドルサーバリソースとアイドルネットワーク伝送リソースの組み合わせを各リソースブロックと対応付ける監視ステップと、
データセンターネットワークに進入するサービス要求の属するサービスブロックを識別し、前記サービスブロックと前記リソースブロックとの間の対応関係に基づいて、前記アイドルサーバリソースとアイドルネットワーク伝送リソースとの組み合わせを当該サービス要求に割り当てる割当ステップと、を有する
ことを特徴とする負荷均衡方法。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210033677.6 | 2012-02-15 | ||
CN2012100336776A CN103259739A (zh) | 2012-02-15 | 2012-02-15 | 负载均衡设备以及负载均衡方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2013168934A true JP2013168934A (ja) | 2013-08-29 |
Family
ID=48963447
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2013010059A Pending JP2013168934A (ja) | 2012-02-15 | 2013-01-23 | 負荷均衡装置及び負荷均衡方法 |
Country Status (2)
Country | Link |
---|---|
JP (1) | JP2013168934A (ja) |
CN (1) | CN103259739A (ja) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103716251A (zh) * | 2014-01-14 | 2014-04-09 | 三星电子(中国)研发中心 | 用于内容分发网络的负载均衡方法及设备 |
CN103944997A (zh) * | 2014-04-29 | 2014-07-23 | 上海交通大学 | 结合随机抽样和虚拟化技术的负载均衡方法 |
JP2015056087A (ja) * | 2013-09-13 | 2015-03-23 | 株式会社日立製作所 | サーバ負荷分散方法およびプログラム |
WO2018142700A1 (ja) * | 2017-02-02 | 2018-08-09 | 日本電信電話株式会社 | 制御装置、制御方法、及びプログラム |
CN114448987A (zh) * | 2022-03-09 | 2022-05-06 | 深圳市华创智慧健康科技有限公司 | 基于云服务的负荷分散管理方法、装置、设备及介质 |
CN115242732A (zh) * | 2022-08-02 | 2022-10-25 | 嘉兴学院 | 面向智慧医疗的数据中心网络带宽资源调度方法 |
Families Citing this family (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104426936A (zh) * | 2013-08-22 | 2015-03-18 | 中兴通讯股份有限公司 | 一种负载均衡方法及系统 |
CN103647839B (zh) * | 2013-12-18 | 2016-08-17 | 清华大学 | 物联网多任务资源分配方法和系统 |
CN105099939A (zh) * | 2014-04-23 | 2015-11-25 | 株式会社日立制作所 | 在不同数据中心之间执行流量控制的方法和设备 |
CN103929368B (zh) * | 2014-05-05 | 2017-04-26 | 华为技术有限公司 | 多业务单元负载均衡方法及装置 |
CN105100151B (zh) * | 2014-05-14 | 2018-12-07 | 中国移动通信集团公司 | 一种内容分发的方法、设备和系统 |
CN103997526B (zh) * | 2014-05-21 | 2018-05-22 | 中国科学院计算技术研究所 | 一种可扩展负载均衡系统和方法 |
CN104796348B (zh) * | 2015-04-03 | 2018-02-13 | 华为技术有限公司 | 基于sdn的idc网络出口流量均衡调整方法、设备及系统 |
US9935882B2 (en) * | 2015-05-13 | 2018-04-03 | Cisco Technology, Inc. | Configuration of network elements for automated policy-based routing |
CN106375355B (zh) * | 2015-07-20 | 2020-02-28 | 中兴通讯股份有限公司 | 负载均衡处理方法及装置 |
CN106815061B (zh) * | 2015-12-01 | 2020-11-24 | 创新先进技术有限公司 | 一种业务处理方法及装置 |
CN105554444B (zh) * | 2015-12-03 | 2018-07-24 | 深圳市泛海三江电子股份有限公司 | 安防监控系统及方法 |
CN105516347B (zh) * | 2015-12-31 | 2019-03-26 | 浙江大华系统工程有限公司 | 一种流媒体服务器的负载均衡调配的方法及装置 |
CN107454005B (zh) * | 2016-05-31 | 2020-04-24 | 南宁富桂精密工业有限公司 | 数据网络负载动态调整装置以及方法 |
TWI617157B (zh) | 2016-05-31 | 2018-03-01 | 鴻海精密工業股份有限公司 | 負載動態調整裝置以及方法 |
CN106445709A (zh) * | 2016-10-24 | 2017-02-22 | 深圳有麦科技有限公司 | 一种分布式调用服务器的方法及其系统 |
CN106453637B (zh) * | 2016-11-24 | 2018-01-26 | 深圳市小满科技有限公司 | 云平台高效复用服务器资源的方法、装置以及云平台 |
CN106453132A (zh) * | 2016-12-14 | 2017-02-22 | 深圳市深信服电子科技有限公司 | 一种混合云环境下的调度方法以及流控设备 |
US10382280B2 (en) * | 2016-12-28 | 2019-08-13 | Juniper Networks, Inc. | Allocating and advertising available bandwidth due to switching fabric degradation |
US20190044816A1 (en) * | 2017-08-04 | 2019-02-07 | Hewlett Packard Enterprise Development Lp | Filtering responses to discovery requests |
CN107707661B (zh) * | 2017-10-16 | 2020-10-16 | 中国银联股份有限公司 | 一种负载均衡资源管理方法和装置 |
CN107613030A (zh) * | 2017-11-06 | 2018-01-19 | 网宿科技股份有限公司 | 一种处理业务请求的方法和系统 |
CN108600344A (zh) * | 2018-04-09 | 2018-09-28 | 杭州登虹科技有限公司 | 一种网络访问请求调度方法、装置和存储介质 |
CN110881058B (zh) * | 2018-09-06 | 2022-04-12 | 阿里巴巴集团控股有限公司 | 请求调度方法、装置、服务器及存储介质 |
CN111722920A (zh) * | 2019-03-22 | 2020-09-29 | 鼎捷软件股份有限公司 | 负载控制方法 |
CN110442066A (zh) * | 2019-08-16 | 2019-11-12 | 佳源科技有限公司 | 一种基于云端协同的物联网系统 |
CN111381963B (zh) * | 2020-02-28 | 2023-06-09 | 腾讯科技(深圳)有限公司 | 负载均衡方法、装置、计算机可读存储介质和计算机设备 |
CN111756800A (zh) * | 2020-05-21 | 2020-10-09 | 网宿科技股份有限公司 | 一种处理突发流量的方法和系统 |
CN112714062B (zh) * | 2020-12-07 | 2022-04-29 | 山东省计算中心(国家超级计算济南中心) | 一种面向超算用户体验质量的多路径路由方法和装置 |
CN113068267B (zh) * | 2021-04-02 | 2023-03-24 | 中科天智运控(深圳)科技有限公司 | 一种通信卫星信道带宽资源动态分配方法及装置 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100484040C (zh) * | 2007-04-20 | 2009-04-29 | 北京航空航天大学 | 实现网格资源适配的系统、方法 |
CN101783768A (zh) * | 2010-03-08 | 2010-07-21 | 东南大学 | 基于资源预留的网格服务质量保证方法 |
CN102185708B (zh) * | 2011-04-18 | 2014-06-18 | 武汉理工大学 | 基于纳什均衡的网格资源分配方法 |
-
2012
- 2012-02-15 CN CN2012100336776A patent/CN103259739A/zh active Pending
-
2013
- 2013-01-23 JP JP2013010059A patent/JP2013168934A/ja active Pending
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2015056087A (ja) * | 2013-09-13 | 2015-03-23 | 株式会社日立製作所 | サーバ負荷分散方法およびプログラム |
CN103716251A (zh) * | 2014-01-14 | 2014-04-09 | 三星电子(中国)研发中心 | 用于内容分发网络的负载均衡方法及设备 |
CN103944997A (zh) * | 2014-04-29 | 2014-07-23 | 上海交通大学 | 结合随机抽样和虚拟化技术的负载均衡方法 |
CN103944997B (zh) * | 2014-04-29 | 2015-10-07 | 上海交通大学 | 结合随机抽样和虚拟化技术的负载均衡方法 |
WO2018142700A1 (ja) * | 2017-02-02 | 2018-08-09 | 日本電信電話株式会社 | 制御装置、制御方法、及びプログラム |
JPWO2018142700A1 (ja) * | 2017-02-02 | 2019-11-07 | 日本電信電話株式会社 | 制御装置、制御方法、及びプログラム |
US11809895B2 (en) | 2017-02-02 | 2023-11-07 | Nippon Telegraph And Telephone Corporation | Control device, control method, and program |
CN114448987A (zh) * | 2022-03-09 | 2022-05-06 | 深圳市华创智慧健康科技有限公司 | 基于云服务的负荷分散管理方法、装置、设备及介质 |
CN114448987B (zh) * | 2022-03-09 | 2024-01-26 | 深圳市华创智慧健康科技有限公司 | 基于云服务的负荷分散管理方法、装置、设备及介质 |
CN115242732A (zh) * | 2022-08-02 | 2022-10-25 | 嘉兴学院 | 面向智慧医疗的数据中心网络带宽资源调度方法 |
CN115242732B (zh) * | 2022-08-02 | 2023-05-09 | 嘉兴学院 | 面向智慧医疗的数据中心网络带宽资源调度方法 |
Also Published As
Publication number | Publication date |
---|---|
CN103259739A (zh) | 2013-08-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2013168934A (ja) | 負荷均衡装置及び負荷均衡方法 | |
US11876717B2 (en) | Flow-based load balancing | |
JP7417825B2 (ja) | スライスベースルーティング | |
CN104272708B (zh) | 带有到服务器群组的无状态第一级分组分布和到群组内某个服务器的有状态第二级分组分布的二级分组分布 | |
CN106656800B (zh) | 一种路径选取方法及系统、网络加速节点及网络加速系统 | |
US8773992B2 (en) | Methods and apparatus for hierarchical routing in communication networks | |
US6594268B1 (en) | Adaptive routing system and method for QOS packet networks | |
JP3910998B2 (ja) | パケット通信方法 | |
CN109614215B (zh) | 基于深度强化学习的流调度方法、装置、设备及介质 | |
US20050188073A1 (en) | Transmission system, delivery path controller, load information collecting device, and delivery path controlling method | |
JP2013168139A (ja) | 負荷均衡装置、負荷均衡方法及び階層化データセンターシステム | |
JP7313480B2 (ja) | スライスベースネットワークにおける輻輳回避 | |
CN112152935B (zh) | 一种传输路径的确定方法及装置 | |
US10341224B2 (en) | Layer-3 flow control information routing system | |
CN107637030B (zh) | 用于自调整适应性路由的方法和装置 | |
US11146477B2 (en) | Discovery and admission control of forwarding boxes in a software-defined network | |
JP2022532730A (ja) | 仮想サービスネットワークにおけるサービス品質 | |
Fatmi et al. | Distributed multipath routing for data center networks based on stochastic traffic modeling | |
US20150188831A1 (en) | System and Method for Traffic Engineering Using Link Buffer Status | |
Shuai et al. | A cost-based distributed algorithm for load balancing in content delivery network | |
Nithin et al. | Efficient load balancing for multicast traffic in data center networks using SDN | |
Wang et al. | Efficient deployment of virtual network functions to achieve load balance in cloud networks | |
JP7205530B2 (ja) | 伝送装置、方法およびプログラム | |
Airaldi et al. | Congestion control proposal in SDN with random early detection | |
CN114884861B (zh) | 一种基于网内计算的信息传输方法和系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20140908 |