JP2019518258A

JP2019518258A - 時間ベース調節可能負荷バランシング

Info

Publication number: JP2019518258A
Application number: JP2018546688A
Authority: JP
Inventors: ジューシアオピン
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2016-03-29
Filing date: 2017-03-28
Publication date: 2019-06-27
Also published as: WO2017172820A1; CN107241380B; US20170286167A1; EP3437273A4; CN107241380A; EP3437273A1

Abstract

実行期間、及び該実行期間に実行される負荷バランシング方法を含む少なくとも１つの時限タスクを取得して記録することによって、複数の期間の定義に基づいて種々の負荷バランシング方法の作成を実施し、かつ実行期間において対応する負荷バランシング方法を実行する、時間ベース調節可能負荷バランシング方法及びデバイスが提供される。さらに、現在の時刻が１つの時限タスクの実行期間に入っているかどうかが判定され、はいの場合に、時限タスクに対応する負荷バランシング方法が取得され、複数のサーバ間での負荷バランシングは、時限タスクに対応する実行期間が終了するまで、対応する負荷バランシング方法に基づいて処理されることによって、ユーザの柔軟なコンフィギュレーションを実装する。ユーザ要求を満たす負荷バランシング方法は、複雑なユーザシナリオに柔軟に適用されることで、負荷バランシングの利用可能性を向上させる。

Description

関連特許出願の相互参照
本出願は、開示全体が参照により本明細書に組み込まれる、「ＴＩＭＥ−ＢＡＳＥＤＡＤＪＵＳＴＡＢＬＥＬＯＡＤＢＡＬＡＮＣＩＮＧＭＥＴＨＯＤＡＮＤＤＥＶＩＣＥ」という名称の、２０１６年３月２９日に出願された中国特許出願第２０１６１０１８８４８１．２号の優先権を主張するものである。

本開示は、コンピュータの分野に関し、とりわけ、時間ベース調節可能負荷バランシングの技術に関する。

現在、取引量が増加するにつれて、閲覧者数及びデータトラフィックも急速に増加しており、単一のサーバではその処理能力のボトルネックにより、要求を満たすことができない。従って、複数のサーバによって構成されるサーバクラスタが使用され、負荷バランシング技術を導入して、リソース及び負荷を効率的にスケジューリングすることで大量のデータトラフィックをクラスタ内の複数のサーバに分配する。さらに、ユーザが使用を選択するための対応する負荷バランシングストラテジが作成される。

ユーザには、負荷バランシングストラテジを使用する時に、いくつかの要件がある場合がある。例えば、ユーザのトラフィックは、労働時間中トラフィックが大きくなるが、夜にはトラフィックは小さくなるような、明確な時間特徴を有する。固定帯域幅に応じて料金が支払われる場合に、トラフィックが全体的に夜には使用されないことがあり、トラフィックに応じて料金が支払われる場合に、大量のトラフィックの場合には費用は非常に高くなることがある。別の例には、ユーザが、帯域幅が改善を必要とすることを要求する期間に大きな格上げを望む場合が含まれる。しかしながら、この期間後、帯域幅を元に戻す必要がある。複数のユーザがある期間の大きな格上げを要求する場合に、負荷バランシングの容量がその要求をサポートできるかどうかを、前もって計算する必要がある。ユーザによって現在使用されている負荷バランシングストラテジのコンフィギュレーションは、柔軟性が十分ではなく、ユーザによって使用されるトラフィックの条件を予め決めることができない。

この「発明の概要」は、「詳細な説明」において以下のさらに説明される選抜した概念を簡略化された形式で紹介するために提供される。この「発明の概念」は、特許請求される主題の重要な特徴または本質的な特徴全てを特定することは意図されてもいないし、特許請求される主題の範囲を判断する際に役立つものとしてのみ使用されることも意図されていない。例えば、「技法（複数可）または技術的な解決策（複数可）」という用語は、前文脈によって、かつ本開示全体を通して認められるような装置（複数可）、システム（複数可）、方法（複数可）、及び／またはコンピュータ可読命令を指す場合がある。

本開示の目的は、ユーザの柔軟なコンフィギュレーションを実施し、かつユーザによって使用されるトラフィックを予断するためにさまざまな期間を定めることによって種々の負荷バランシング方法がもたらされるような、時間ベース調節可能負荷バランシング方法及びデバイスを提供することである。

本開示の一態様によると、
少なくとも１つの時限タスクであって、実行期間、及び該実行期間に実行される負荷バランシング方法を含む時限タスクを取得して記録することと、
現在の時刻が１つの時限タスクの実行期間に入っているかどうかを判定し、はいの場合に、時限タスクに対応する負荷バランシング方法を取得し、時限タスクに対応する実行期間が終了するまで、対応する負荷バランシング方法に基づいて複数のサーバ間で負荷バランシングを処理することと、を含む、時間ベース調節可能負荷バランシング方法が提供される。

さらに、少なくとも１つの時限タスクを取得しかつ記録することは、
ユーザリクエストを取得することであって、該ユーザリクエストは、リクエスト期間、及びリクエスト期間に実行される負荷バランシング方法を含む、取得することと、ユーザリクエストに基づいて少なくとも１つの時限タスクを生成することと、リクエスト期間に基づいて時限タスクの実行期間を判断することと、ユーザリクエストに基づいて、実行期間に実行される負荷バランシング方法を決定することと、を含む。

例えば、ユーザリクエストに基づいて、実行期間に実行される負荷バランシング方法を決定することは、
ユーザリクエストに基づいて負荷バランシングの性能パラメータ情報を取得することと、負荷バランシングの性能パラメータ情報に基づいて、実行期間に実行される負荷バランシング方法を決定することと、を含む。

例えば、性能パラメータ情報は、以下のうちの少なくとも１つ、すなわち、帯域幅量、作成可能な接続の数、及び、１秒当たりの新たな作成可能な接続の数のうちの少なくとも１つを含む。

例えば、ユーザリクエストに基づいて、実行期間に実行される負荷バランシング方法を決定することは、
取得された負荷バランシングの性能パラメータ情報が負荷バランシングの既存のサービス能力の性能パラメータ情報を超える場合に、時限タスクの生成を停止することと、アラーム通知情報を返すことと、を含む。

例えば、時限タスクを取得することは、
リクエスト期間と実行期間とが重複期間を有する場合に、重複期間に基づいて時限タスクの実行期間を更新することと、更新された実行期間に基づいて時限タスクを更新することと、をさらに含む。

例えば、時間ベース調節可能負荷バランシング方法は、時限タスクに対応する実行期間が終了すると、負荷バランシング方法を削除し、次の実行期間に対応する次の負荷バランシング方法を取得することをさらに含む。

例えば、時限タスクは、以下のいずれか、すなわち、
周期的かつ循環的に実行される第１の時限タスク、
一度実行される第２の時限タスク、及び、
一度実行される第１の時限タスクと周期的かつ循環的に実行される第２の時限タスクとを連係させる第３の時限タスクのいずれかを含む。

本開示の別の態様によると、
少なくとも１つの時限タスクを取得して記録する取得装置であって、時限タスクは、実行期間、及び、実行期間に実行される負荷バランシング方法を含む、取得装置と、
現在の時刻が１つの時限タスクの実行期間に入っているかどうかを判定し、はいの場合に、時限タスクに対応する負荷バランシング方法を取得し、時限タスクに対応する実行期間が終了するまで、対応する負荷バランシング方法に基づいて複数のサーバ間で負荷バランシングを処理する実行装置と、を含む、時間ベース調節可能負荷バランシングデバイスが提供される。

さらに、取得装置は、
ユーザリクエストを取得するリクエスト取得ユニットであって、ユーザリクエストは、リクエスト期間、及びリクエスト期間に実行される負荷バランシング方法を含む、リクエスト取得ユニットと、
ユーザリクエストに基づいて少なくとも１つの時限タスクを生成し、リクエスト期間に基づいて時限タスクの実行期間を決定する生成ユニットと、
ユーザリクエストに基づいて、実行期間に実行される負荷バランシング方法を決定する決定ユニットと、を含む。

例えば、決定ユニットはさらに、
ユーザリクエストに基づいて負荷バランシングの性能パラメータ情報を取得し、負荷バランシングの性能パラメータ情報に基づいて、実行期間に実行される負荷バランシング方法を決定する。

例えば、性能パラメータ情報は、以下のうちの少なくとも１つ、すなわち、
帯域幅量、
作成可能な接続の数、及び、
１秒当たりの新たな作成可能な接続の数のうちの少なくとも１つを含む。

例えば、決定ユニットはさらに、
取得された負荷バランシングの性能パラメータ情報が負荷バランシングの既存のサービス能力の性能パラメータ情報を超える場合に、時限タスクの生成を停止し、アラーム通知情報を返す。

例えば、取得装置は、
リクエスト期間と既存の時限タスクの実行期間とが重複期間を有する場合に、重複期間に基づいて既存の時限タスクの実行期間を更新する第１の更新ユニットを含む。

例えば、取得装置は、
更新された実行期間に基づいて既存の時限タスクを更新する第２の更新ユニットをさらに含み、時限タスクは、一度実行される時限タスク、または周期的かつ循環的に実行される時限タスクである。

例えば、実行装置はさらに、
時限タスクに対応する実行期間が終了すると、負荷バランシング方法を削除し、次の実行期間に対応する次の負荷バランシング方法を取得する。

本開示の別の態様によると、１つまたは複数のプロセッサによって実行される時、プロセッサに、
時限タスクを取得することであって、時限タスクは、実行期間、及び、実行期間に実行される負荷バランシング方法を含む、取得することと、
現在の時刻が実行期間に入っているかを判定することと、
時限タスクに対応する負荷バランシング方法を取得することと、
時限タスクに対応する実行期間が終了するまで、時限タスクに対応する負荷バランシング方法に基づいて複数のサーバ間で負荷バランシングを処理することと、を含む動作を行わせるコンピュータ実行可能命令を記憶した１つまたは複数のメモリが提供される。

従来の技法と比較すると、本開示の例示の実施形態による、時間ベース調節可能負荷バランシング方法及びデバイスは、少なくとも１つの時限タスクであって、実行期間、及び、実行期間に実行される負荷バランシング方法を含む時限タスクを取得して記録し、ユーザリクエストに基づいて負荷バランシングの性能パラメータ情報を取得し、次いで、負荷バランシングの性能パラメータ情報に基づいて、実行期間に実行される負荷バランシング方法を決定する。従って、複数の期間を定めることによって種々の負荷バランシング方法が作成され、対応する負荷バランシング方法が実行期間に実行される。さらに、現在の時刻が１つの時限タスクの実行期間に入っているかどうかが判定され、はいの場合に、時限タスクに対応する負荷バランシング方法が取得され、複数のサーバ間での負荷バランシングは、時限タスクに対応する実行期間が終了するまで、対応する負荷バランシング方法に基づいて処理されることによって、ユーザの柔軟なコンフィギュレーションを実装する。ユーザ要求を満たす負荷バランシング方法は、複雑なユーザシナリオに柔軟に適用されることで、負荷バランシングの利用可能性を向上させる。

本開示の特徴、目的、及び利点は、下記の図面と併せて、非限定的な例示の実施形態の詳細な説明を参照することによって、より明白になるであろう。

本開示の一態様による、時間ベース調節可能負荷バランシングデバイスの概略的な構造図である。本開示の一態様による例示の実施形態における取得装置１１０の概略的な構造図である。対応する期間における既存の時限タスク及びストラテジを示す図である。本開示の一態様による、時限タスクを更新する例示の実施形態の概略図である。本開示の別の態様による、時間ベース調節可能負荷バランシング方法の概略的なフローチャートである。本開示の別の態様による例示の実施形態におけるステップＳ４０２の方法の概略的なフローチャートである。

添付の図面における同一のまたは同様の参照番号は、同一のまたは同様の構成要素を表す。

詳細な説明
本開示について、添付の図面を参照して以下にさらに詳細に説明する。

図１は、本開示の一態様による、時間ベース調節可能負荷バランシングデバイスの概略的な構造図である。デバイス１００は、１つまたは複数のプロセッサ（複数可）１０２またはデータ処理ユニット（複数可）及びメモリ１０４を含む。デバイス１００はさらに、１つまたは複数の入力／出力インターフェース（複数可）１０６、及びネットワークインタフェース（複数可）１０８を含んでもよい。メモリ１０４はコンピュータ可読媒体の例である。

コンピュータ可読媒体は、揮発性及び不揮発性、取り外し可能及び取り外し不可能な媒体を含み、情報を記憶するためのいかなる方法または技術も使用できる。情報は、コンピュータ可読命令、データ構造、及びプログラムまたは他のデータのモジュールであってもよい。コンピュータの記憶媒体の例は、相変化メモリ（ＰＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、他のタイプのＲＡＭ、ＲＯＭ、電気的消去可能プログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリもしくは他のメモリ技術、コンパクトディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学記憶装置、カセットテープ、テープディスク記憶装置もしくは他の磁気記憶デバイス、または、計算デバイスにアクセス可能な情報を記憶するものとすることができるその他の非送信媒体を含むが、これらに限定されない。本明細書における定義に従って、コンピュータ可読媒体は、一時的なコンピュータ可読媒体（一時的な媒体）、例えば、変調されたデータ信号及びキャリアを含まない。

メモリ１０４は、取得装置１１０及び実行装置１１２を含む複数のモジュールまたはユニットを格納してもよい。取得装置１１０は、少なくとも１つの時限タスクであって、実行期間、及び実行期間に実行される負荷バランシング方法を含む時限タスクを取得しかつ記録する。実行装置１１２は、現在の時刻が１つの時限タスクの実行期間に入っているかどうかを判定し、はいの場合に、時限タスクに対応する負荷バランシング方法を取得し、時限タスクに対応する実行期間が終了するまで、対応する負荷バランシング方法に基づいて複数のサーバ間の負荷バランシングを処理する。

本明細書において、デバイス１００は、ユーザ機器、または、ネットワークを介してユーザ機器及びネットワークデバイスを統合することによって構成されるデバイスを含んでもよいが、これらに限定されない。ユーザ機器は、スマートフォン及びＰＤＡなどのタッチパッドによってユーザとのマンマシンインタラクションを実行することができる任意のモバイル電子製品も含んでもよいが、これに限定されない。モバイル電子製品は、アンドロイドオペレーティングシステム及びｉＯＳオペレーティングシステムなどの任意のオペレーティングシステムも使用してもよい。この場合に、ネットワークデバイスは、事前設定または事前記憶された命令に従って数値計算及び情報処理を自動的に行うことが可能な電子デバイスを含み、このハードウェアは、マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＳＰ）、及び埋め込みデバイスなどを含むが、これらに限定されない。ネットワークは、インターネット、広域ネットワーク、メトロポリタンエリアネットワーク、ローカルエリアネットワーク、ＶＰＮネットワーク、及びワイヤレスＡｄＨｏｃネットワークなどを含むが、これらに限定されない。例えば、デバイス１００はまた、ユーザ機器もしくはユーザ機器とネットワークデバイス、タッチ端末、または、ネットワークを通してタッチ端末と統合されるネットワークデバイスによって形成されるデバイス上で実行するスクリプトプログラムであってもよい。明確には、デバイス１００が単なる例であること、また本開示に適用可能である場合に他の既存の、または将来的に可能なデバイス１００も、本開示の保護範囲に含まれ、参照により本明細書に組み込まれるものとすることを、当業者であれば理解するはずである。

前述の装置の動作は連続的なものであり、本明細書において、「連続的」という言い回しは、前述の装置が、リアルタイムに、または事前設定された、またはリアルタイムに調節された動作モードに従って別個に動作することを意味することを、当業者であれば理解するはずである。例えば、取得装置１１０は、少なくとも１つの時限タスクを連続的に取得して記録し、実行装置１１２は、現在の時刻が１つの時限タスクの実行期間に入っているかどうかを連続的に判定し、はいの場合に、時限タスクに対応する負荷バランシング方法を取得し、時限タスクに対応する実行期間が終了するまで、かつ、デバイス１００が負荷バランシング調節作業を完了する、または作業を停止するまで、対応する負荷バランシング方法に基づいて複数のサーバ間の負荷バランシングを処理する。

本開示の例示の実施形態による時間ベース調節可能負荷バランシングのためのデバイス１００は、対応する負荷バランシング方法が、ユーザのリクエストによるリクエストの実行期間に実行されることを可能にすることによって、ユーザの要求を満たすようにユーザの柔軟なコンフィギュレーションを実装し、一方で負荷バランシングの利用可能性を高める。

具体的な解決策の実施態様において、負荷バランシングストラテジを使用して、ユーザのアクセスリクエストに応じて、リクエストを処理するために対応してなされた負荷バランシングストラテジに準じたバックエンドサーバを選択すること、また、記述を容易にするために、負荷バランシング方法と負荷バランシングストラテジ（ＳＬＢストラテジ）とが例示の実施形態において入れ替えて使用されることを、当業者であれば理解するはずである。

具体的には、取得装置１１０は、少なくとも１つの時限タスクであって、実行期間と実行期間に実行される負荷バランシング方法とを含む時限タスクを取得して記録する。

本明細書において、サーバ負荷分散装置（ＳＬＢ）は、トラフィックを複数のクラウドサーバに分散させる負荷バランシングサービスであり、負荷バランシングは、トラフィック分散によってアプリケーションシステムの外部サービス能力を拡張させ、かつ、単一障害点を排除することによって、アプリケーションシステムの有用性を改善してもよい。本開示の例示の実施形態では、ＳＬＢコントローラは、ＳＬＢストラテジをＳＬＢ転送サーバに送出する。時間ベースストラテジを実施するために、タイムサーバはＳＬＢコントローラ上に構築される必要があり、時間に関係があるストラテジは全て、タイムサーバに送られてもよく、タイムサーバは、時間ストラテジに応じて、対応する転送ストラテジを転送サーバに送出する。上記の例示の実施形態において、取得装置１１０がタイムサーバを含んでもよく、タイムサーバが、一度実行される時限タスク、及び循環的に実行される時限タスクを実施し、ここで、時限タスクが、ある期間に、ユーザによって選択された、実行されるべき負荷バランシングストラテジを実行していることに留意するべきである。少なくとも１つの時限タスクは、ユーザリクエストの期間情報、及び該期間に実行されるＳＬＢストラテジの情報を取得することによって生成され、対応するＳＬＢストラテジは時限タスクに基づいてリクエストの期間に実行される。例えば、ユーザは、このトラフィック使用条件に従って、０６：００から１８：００までの期間にＳＬＢストラテジａ３０２を選択し、翌日の１８：００から０６：００までの期間にＳＬＢストラテジｂ３０４を選択し、選択された期間のリクエスト情報、及び対応する期間に実行されるＳＬＢストラテジの情報はタイムサーバに送られ、２つの時限タスクが生成される。時限タスクａは、タイムサーバが０６：００から１８：００までの期間にＳＬＢストラテジａ３０２を実行するために使用され、時限タスクｂは、タイムサーバが翌日の１８：００から０６：００までの期間にＳＬＢストラテジｂ３０４を実行するために使用される。

時限タスクを取得して記録する方法が単なる例であり、本開示に適用可能である場合は他の既存の、または将来的に可能な、時限タスクを取得して記録する方法も本開示の保護範囲に含まれ、参照により本明細書に組み込まれるものとなることを、当業者であれば理解するはずである。

具体的には、実行装置１１２は、現在の時刻が１つの時限タスクの実行期間に入っているかどうかを判定し、はいの場合に、時限タスクに対応する負荷バランシング方法を取得し、時限タスクに対応する実行期間が終了するまで、対応する負荷バランシング方法に基づいて複数のサーバ間の負荷バランシングを処理する。

前述の例によると、ユーザが、このトラフィック使用条件に従って、０６：００から１８：００までの期間にＳＬＢストラテジａを選択し、翌日の１８：００から０６：００までの期間にＳＬＢストラテジｂを選択した後、タイムサーバは、ユーザによって選択された期間のリクエスト情報、及び対応する期間に実行されるＳＬＢストラテジの情報を取得し、転送ストラテジに従って、取得された情報を転送サーバに転送することによって、複数のサーバ間で負荷バランシングを実施する。複数の時限タスクが実行される時、現在の時刻が選択された期間に入っているかどうかを判定することが必要とされ、現在の時刻が６：００から１８：００までの期間に属する場合に、ＳＬＢストラテジａが実行されて１８：００の時点で終了し、その後、翌日の１８：００から０６：００までの次の期間に入り、ＳＬＢストラテジｂが、該期間に対応する時限タスクｂが終了するまで、この期間において常に実行される。

例えば、図２は、本開示の一態様による例示の実施形態における取得装置１１０の概略的な構造図である。図２の例において、取得装置１１０は、リクエスト取得ユニット２０２、生成ユニット２０４、及び決定ユニット２０６を含む。ここで、リクエスト取得ユニット２０２はユーザリクエストを取得し、ユーザリクエストは、リクエスト期間、及びリクエスト期間に実行される負荷バランシング方法を含み、生成ユニット２０４はユーザリクエストに基づいて少なくとも１つの時限タスクを生成し、リクエスト期間に基づいて時限タスクの実行期間を決定し、決定ユニット２０６は、ユーザリクエストに基づいて、実行期間に実行される負荷バランシング方法を決定する。

具体的な例示の実施形態において、リクエスト取得ユニット２０２は、ユーザによって選択された期間の情報、及び該期間に使用されるＳＬＢストラテジの情報を取得し、生成ユニット２０４は、取得されたリクエスト情報に応じて対応する時限タスクを生成し、かつ時限タスクを実行する期間を決定し、決定ユニット２０６は、ユーザによって必要とされるＳＬＢストラテジが実行期間に実行されるか、すなわち、対応するＳＬＢストラテジがそれぞれの期間に実行されるかを判定し、ＳＬＢストラテジは該期間の時刻が開始する時に追加され、ＳＬＢストラテジは該期間が終了すると削除され、新たなストラテジが、次の期間に入る時に再び追加された後に実行されることで、ユーザの柔軟なコンフィギュレーションがユーザの要求に応じて完了するようにする。

例えば、決定ユニット２０６は、ユーザリクエストに基づいて、負荷バランシングの性能パラメータ情報を求め、次いで負荷バランシングの性能パラメータ情報に基づいて、実行期間に実行される負荷バランシング方法を決定する。

例えば、性能パラメータ情報は、以下のうちの少なくとも１つ、すなわち、帯域幅量、作成可能な接続の数、及び、１秒当たりの新たな作成可能な接続の数のうちの少なくとも１つを含む。例えば、ユーザは、１か月の格上げを望み、帯域幅がこの月において増大されることを必要とし、必要とされた帯域幅は、ユーザのリクエストに応じて、以前のＡからＢに変更され、この月において帯域幅Ｂをユーザに分配し、かつ他の月の期間に帯域幅Ａを分配するＳＬＢストラテジを実行することを決定する。別の例として、ある企業のサーバは、ある期間に、接続させることができるパーソナルコンピュータ（ＰＣ）の数を調節する必要があり、必要とされる期間におけるＳＬＢストラテジは作成可能な接続の数のリクエストに応じて決定される。代替的には、対応して調節されるＳＬＢストラテジは、サーバによって必要とされる、１秒当たりの新たな作成可能な接続の数のリクエストに応じて決定される。帯域幅量、作成可能な接続の数、及び、１秒当たりの新たな作成可能な接続の数が、負荷バランシングによって外部に提供されるリソースであり、ユーザによって所有されるＳＬＢ性能パラメータとして使用されてもよいことに留意するべきである。負荷バランシングによってユーザサーバに分散されたリソースは、時間に基づいて作成されたＳＬＢストラテジによって調節されるため、ＳＬＢを使用するユーザの要求を満たす。例えば、ユーザのトラフィックが大きい時に帯域幅を増大させ、ユーザのトラフィックが小さい時に帯域幅を減少させることで、かかる柔軟なストラテジによってユーザの費用が節約される。

例えば、決定ユニット２０６はさらに、取得された、負荷バランシングの性能パラメータ情報が負荷バランシングの既存のサービス能力の性能パラメータ情報を超える場合に、時限タスクの生成を停止し、アラーム通知情報を返す。

本明細書において、負荷バランシングのサービス能力を決定することは、転送サーバの容量、及び、時限タスクを実行するストラテジによって参照されるサービス能力に基づく。例えば、帯域幅、作成可能な接続の数、及び、１秒当たりの新しい作成可能な接続の数などの性能パラメータである。全てのユーザによって選択されたＳＬＢストラテジによって参照されるサービス能力の合計が転送サーバの容量を超える場合に、管理者に、例えば、ユーザによって参照されるサービス能力を制限する、または転送サーバの容量を拡張するといった対応する措置を講じるように通知するアラームが発せられる。この場合に、ユーザによって参照されるサービス能力を制限することは、現在生成されている時限タスクを停止すること、すなわち、対応する期間において負荷バランシング容量を満たさないＳＬＢストラテジの実行を停止すること、及び、要求を満たすために新たな時限タスクを生成するために実際の状況に応じてＳＬＢストラテジａ３０２を調節することであってもよい。

例えば、取得装置１１０はさらに、（図２に示されない）第１の更新ユニット、及び（図２に示されない）第２の更新ユニットを含む。ここで、第１の更新ユニットは、リクエスト期間と既存の時限タスクの実行期間とが重複期間を有する場合に、重複期間に基づいて既存の時限タスクの実行期間を更新し、第２の更新ユニットは、更新された実行期間に基づいて既存の時限タスクを更新し、時限タスクは、一度実行される時限タスク、または周期的かつ循環的に実行される時限タスクである。

具体的な例示の実施形態では、例えば、既存の時限タスク、及び図３（ａ）に示される対応する期間におけるストラテジにおいて、ストラテジａ３０２は期間Ａ３０４において実行され、ストラテジｂ３０６は期間Ｂ３０８において実行される。ユーザが突然、要求、例えば、図３（ｂ）に示されるように、期間Ｃ３１２においてストラテジｃ３１０を実行する要求を示す時、期間Ｃ３１２の１つの部分は、期間Ａ３０４に属し、他の部分は期間Ｂ３０８に属し、重複した期間が存在する。この場合に、既存の時限タスクの実行期間は、更新される必要がある、すなわち、期間Ａ３０４においてＳＬＢストラテジａ３０２を最初に実行し、かつ期間Ｂ３０８においてＳＬＢストラテジｂ３０４を実行することは、期間Ａ’３１４においてＳＬＢストラテジａ３０２を実行すること、次の期間Ｃ３１２においてＳＬＢストラテジｃ３１０を実行すること、及びその後の期間Ｂ’３１６においてＳＬＢストラテジｂ３０４を実行することに更新される。ストラテジａ及びストラテジｂに対応する時限タスクの実行期間が変更され、そしてこのように、ユーザの選択リクエストに応じて、ユーザが必要とするＳＬＢストラテジが柔軟に構成されることで、負荷バランシングは種々の環境に対してより柔軟になり、かつより良く適応するようになり、それによって、負荷バランシングの利用可能性が拡張されることが分かる。さらに、既存の時限タスクは、更新された期間に応じて更新される。例えば、ストラテジａ３０２の時限タスクは期間Ａ’３１４において一度実行され、ストラテジｃ３１０は期間Ｃ３１２において循環的に実行される。

例えば、実行装置１１２は、時限タスクに対応する実行期間が終了すると、既存の負荷バランシング方法を削除し、次の実行期間に対応する負荷バランシング方法を取得する。

本明細書において、ある期間に対応する時限タスクは、期間が開始する時点で取得され、この時限タスクは、期間が終了する時点で終了し、該期間における対応するＳＬＢストラテジは削除され、次の実行期間における対応するＳＬＢストラテジが取得される。例えば、具体的な例示の実施形態では、ユーザは３月に帯域幅を増大させる必要があり、そして、ＳＬＢストラテジ１が３月の前に実行され、この以前のＳＬＢストラテジ１は３月が始まる時に削除され、３月に対応するＳＬＢストラテジ２が取得される、すなわち、３月の期間の負荷バランシングストラテジが調節されることで、ユーザのコンフィギュレーションが柔軟性を有するようにする。

例えば、時限タスクは、以下のいずれか、すなわち、周期的かつ循環的に実行される時限タスク、一度実行される時限タスク、及び、一度実行される時限タスクと周期的かつ循環的に実行される時限タスクとを連係させる時限タスクのいずれかを含む。

例えば、時間ベースＳＬＢストラテジは以下の方法で作成されてもよい。

１）期間に応じて循環させるストラテジ、例えば、２４時間以内のＳＬＢストラテジは、１日を単位として使用することによって定められ、これらのストラテジは１日ごとに循環する、または、７×２４時間以内のＳＬＢストラテジは、１週間を単位として使用することによって定められ、これらのストラテジは１週間ごとに循環する、または、３０日以内のＳＬＢストラテジは１か月を単位として使用することによって定められ、これらのストラテジは１か月ごとに循環する。取得装置１１０は、周期的に循環させる必要がある期間情報、及び対応するＳＬＢストラテジを取得後、対応する期限タスクを生成し、ここで、期限タスクは、要求に応じて周期的かつ循環的に実行される。期間に応じて循環するストラテジを作成する方法は、単なる例であり、対応するＳＬＢストラテジは循環期間として任意の時間単位を使用することによって循環させてもよく、周期的かつ循環的に実行される他の既存の、または将来的に可能な時限タスクも、本開示に適用可能である場合は本開示の保護範囲に含まれ、参照によって本明細書に組み込まれるものとすることに留意するべきである。

２）それぞれの期間が異なるストラテジを有し、異なるＳＬＢストラテジは異なる期間に対応しており、ある期間におけるストラテジは循環しない。すなわち、期間情報及び対応するＳＬＢストラテジが取得された後、ある期間に対応する期限タスクが生成され、期限が終了すると、対応するストラテジは削除され、該期限におけるストラテジは循環的に実行されない。例えば、具体的なシナリオでは、９：００から１７：００までの期間は作業時間であり、帯域幅を増大させる必要があるため、ＳＬＢストラテジ２が使用され、翌日の２２：００から０６：００までの期間において、帯域幅を減少させる必要があるため、ＳＬＢストラテジ３が使用され、他の期間においてはストラテジ１が実行される。従って、生成される時限タスクは全て、一度実行され、すなわち、対応する時限タスクは、ストラテジ２が９：００から１７：００までの期間において実行された後に終了させ、対応する時限タスクは、ストラテジ３が翌日の２２：００から０６：００までの期間に実行された後に終了させる。別の例として、ユーザが支払いを行う時、１か月の期限の請求書が生成され、ユーザは、何らかの理由によってある月の第１の期間において固定帯域幅を選択し、かつ残りの期間においてトラフィックベース課金方法を使用する必要があるため、ユーザの要求に応じて、時限タスクａが第１の期間に一度実行され、ここで、時限タスクａは第１の期間において固定帯域幅に従って課金するストラテジであり、課金の方法は期間が終了すると変更される。時限タスクｂがまた、残りの期間において一度実行され、ここで、時限タスクｂは、残りの期間におけるトラフィックに応じて課金するストラテジを指し、時限タスクｂは期間が終了すると停止され、トラフィックに応じて課金するストラテジは削除され、新たな期間、及び該期間に対応するストラテジが取得される。

３）組み合わせたストラテジが作成され、この場合に、異なるストラテジは異なる期間において使用され、循環的に実行されるストラテジもある期間において定められてよい。例えば、ユーザは、１か月の（例えば、１１月に）トラフィックの大きな格上げを必要とし、この月において大きな帯域幅が設定され、ストラテジａが他の月において実行され、ストラテジｂが帯域幅を増大させるために１１月の期間に実行される。しかしながら、この月の期間において、循環的なストラテジも定められている場合があり、異なる期間において必要とされる異なる帯域幅量に応じて、例えば、ストラテジｂ’１はこの月の昼の期間に実行され、ストラテジｂ’２は夜の期間に実行される。周期的かつ循環的に実行される時限タスクと、一度実行される時限タスクを連係させる時限タスクは、ユーザの選択リクエストに応じて実施される。

上記の例示の実施形態において、ユーザによって選択される複数のＳＬＢストラテジが取得された後に負荷バランシングがサービスのために調節されると、全てのユーザによって使用されるストラテジによって参照されるサービス能力の合計が転送サーバのサービス能力を超えることができないようにすることが満たされるものとし、合計が転送サーバのサービス能力を超える場合に、アラームを発し、かつ対応する措置を講じるように通知情報を送ることが必要であることに留意するべきである。

時間ベースＳＬＢストラテジの作成方法が単なる例であり、本開示に適用可能である場合は他の既存の、または将来的に可能な作成方法も本開示の保護範囲に含まれ、参照により本明細書に組み込まれるものとなることを、当業者であれば理解するはずである。

図４は、本開示の別の態様による、時間ベース調節可能負荷バランシング方法の概略的なフローチャートである。本方法は、ステップＳ４０２及びステップＳ４０４を含む。ステップＳ４０２では、少なくとも１つの時限タスクを取得して記録し、時限タスクは実行期間、及び実行期間に実行される負荷バランシング方法を含む。ステップＳ４０４では、現在の時刻が１つの時限タスクの実行期間に入っているかどうかを判定し、はいの場合に、時限タスクに対応する負荷バランシング方法を取得し、時限タスクに対応する実行期間が終了するまで、複数のサーバ間の負荷バランシングを、対応する負荷バランシング方法に基づいて処理する。

本開示の例示の実施形態による時間ベース調節可能負荷バランシング方法は、対応する負荷バランシング方法が、ユーザのリクエストによるリクエストの実行期間に実行されることによって、ユーザの要求を満たすようにユーザの柔軟なコンフィギュレーションが実装され、一方で負荷バランシングの利用可能性が高められる。

具体的な解決策の実施態様では、負荷バランシングストラテジを使用して、ユーザのアクセスリクエストに応じて、リクエストを処理するために対応してなされた負荷バランシングストラテジに準じたバックエンドサーバを選択すること、また記述を容易にするために、負荷バランシング方法及び負荷バランシングストラテジ（ＳＬＢストラテジ）は例示の実施形態において入れ替えて使用されることを、当業者であれば理解するはずである。

具体的には、ステップＳ４０２では、少なくとも１つの時限タスクを取得して記録し、時限タスクは、実行期間、及び実行期間に実行される負荷バランシング方法を含む。

ここで、サーバ負荷分散装置（ＳＬＢ）は、トラフィックを複数のクラウドサーバに分散させる負荷バランシングサービスであり、負荷バランシングは、トラフィック分散によってアプリケーションシステムの外部サービス能力を拡張させ、かつ、単一障害点を排除することによって、アプリケーションシステムの有用性を改善してもよい。本開示の例示の実施形態では、ＳＬＢコントローラは、ＳＬＢストラテジをＳＬＢ転送サーバに送出する。時間ベースストラテジを実施するために、タイムサーバはＳＬＢコントローラ上に構築される必要があり、時間に関係があるストラテジは全て、タイムサーバに送られてもよく、タイムサーバは、時間ストラテジに応じて、対応して転送するストラテジを転送サーバに送出する。上記の例示の実施形態において、タイムサーバがステップＳ４０２において作成され、タイムサーバが、一度実行される時限タスク、及び循環的に実行される時限タスクを実施し、ここで、時限タスクが、ある期間に、ユーザによって選択された、実行されることになる負荷バランシングストラテジを実行していることに、留意するべきである。少なくとも１つの時限タスクが、ユーザリクエストの期間情報、及び該期間に実行されるＳＬＢストラテジの情報を取得することによって生成され、対応するＳＬＢストラテジが時限タスクに基づいてリクエストの期間に実行される。例えば、ユーザは、このトラフィック使用条件に従って、０６：００から１８：００までの期間にＳＬＢストラテジａ３０２を選択し、翌日の１８：００から０６：００までの期間にＳＬＢストラテジｂ３０４を選択し、選択された期間のリクエスト情報、及び対応する期間に実行されるＳＬＢストラテジの情報はタイムサーバに送られ、２つの時限タスクが生成される。時限タスクａは、タイムサーバが０６：００から１８：００までの期間にＳＬＢストラテジａ３０２を実行するために使用され、時限タスクｂは、タイムサーバが翌日の１８：００から０６：００までの期間にＳＬＢストラテジｂ３０４を実行するために使用される。

具体的には、ステップＳ４０４において、現在の時刻が１つの時限タスクの実行期間に入っているかどうかを判定し、はいの場合に、時限タスクに対応する負荷バランシング方法を取得し、時限タスクに対応する実行期間が終了するまで、複数のサーバ間の負荷バランシングを、対応する負荷バランシング方法に基づいて処理する。

前述の例によると、ユーザが、このトラフィック使用条件に従って、０６：００から１８：００までの期間にＳＬＢストラテジａ３０２を選択し、翌日の１８：００から０６：００までの期間にＳＬＢストラテジｂ３０４を選択した後、タイムサーバは、ユーザによって選択された期間のリクエスト情報、及び対応する期間に実行されるＳＬＢストラテジの情報を取得し、転送ストラテジに従って、取得された情報を転送サーバに転送することによって、複数のサーバ間の負荷バランシングを実施する。複数の時限タスクが実行される時、現在の時刻が選択された期間に入っているかどうかを判定することが必要とされ、現在の時刻が６：００から１８：００までの期間に属する場合に、ＳＬＢストラテジａ３０２が実行され、かつ１８：００の時点になるまでに終了し、その後、翌日の１８：００から０６：００までの次の期間に入り、ＳＬＢストラテジｂ３０４が、該期間に対応する時限タスクｂが終了するまで、この期間において常に実行される。

例えば、図５は、本開示の別の態様による例示の実施形態におけるステップＳ４０２の方法の概略的なフローチャートである。ステップＳ４０２は、ステップＳ５０２、ステップＳ５０４、及びステップＳ５０６を含む。ここで、ステップＳ５０２では，ユーザリクエストを取得し、ユーザリクエストは、リクエスト期間、及びリクエスト期間に実行される負荷バランシング方法を含み、次いで、ステップＳ５０４では、少なくとも１つの時限タスクをユーザリクエストに基づいて生成し、時限タスクの実行期間をリクエスト期間に基づいて判断し、最後に、ステップＳ５０６では、実行期間に実行される負荷バランシング方法を、ユーザリクエストに基づいて決定する。

具体的な例示の実施形態において、ステップＳ５０２では、ユーザによって選択された期間の情報、及び該期間に使用されるＳＬＢストラテジの情報を取得し、次いでステップＳ５０４を行い、ここで、取得されたリクエスト情報による、対応する時限タスクを生成し、時限タスクを実行する期間を決定した後、ステップＳ５０６を行って、ユーザによって必要とされるＳＬＢストラテジを実行期間に実行する、すなわち、対応するＳＬＢストラテジをそれぞれの期間に実行すると決定し、ＳＬＢストラテジを該期間の時刻が開始する時に追加し、ＳＬＢストラテジをその時点が終了すると削除し、新たなストラテジを、次の期間に入る時に再び追加した後に実行することで、ユーザの柔軟なコンフィギュレーションをユーザの要求に応じて完了するようにする。

例えば、ステップＳ５０６は、ユーザリクエストに基づいて、負荷バランシングの性能パラメータ情報を決定すること、及び、負荷バランシングの性能パラメータ情報に基づいて、実行期間に実行される負荷バランシング方法を決定することを含む。

例えば、性能パラメータ情報は、以下のうちの少なくとも１つ、すなわち、帯域幅量、作成可能な接続の数、及び、１秒当たりの新たな作成可能な接続の数のうちの少なくとも１つを含む。例えば、ユーザは、１か月の格上げを望み、帯域幅がこの月において増大されることを必要とし、必要とされた帯域幅は、ユーザのリクエストに応じて、以前のＡからＢに変更され、この月において帯域幅Ｂをユーザに分配し、かつ他の月の期間に帯域幅Ａを分配するＳＬＢストラテジを実行することが決定される。別の例として、ある企業のサーバは、ある期間に、接続させることができるパーソナルコンピュータ（ＰＣ）の数を調節する必要があり、必要とされる期間におけるＳＬＢストラテジは、作成可能な接続の数のリクエストに応じて決定される。代替的には、対応して調節されるＳＬＢストラテジは、サーバによって必要とされる、１秒当たりの新たな作成可能な接続の数のリクエストに応じて決定される。帯域幅量、作成可能な接続の数、及び、１秒当たりの新たな作成可能な接続の数が、負荷バランシングによって外部に提供されるリソースであり、ユーザによって所有されるＳＬＢ性能パラメータとして使用されてもよいことに、留意するべきである。負荷バランシングによってユーザサーバに分散されたリソースは、時間に基づいて作成されたＳＬＢストラテジによって調節されるため、ＳＬＢを使用するユーザの要求を満たす。例えば、ユーザのトラフィックが大きい時に帯域幅を増大させ、ユーザのトラフィックが小さい時に帯域幅を減少させることで、かかる柔軟なストラテジによってユーザの費用が節約される。

例えば、ステップＳ５０６は、取得された、負荷バランシングの性能パラメータ情報が負荷バランシングの既存のサービス能力の性能パラメータ情報を超える場合に、時限タスクの生成を停止し、アラーム通知情報を返すことをさらに含む。

本明細書において、負荷バランシングのサービス能力を決定することは、転送サーバの容量、及び、時限タスクを実行するストラテジによって参照されるサービス能力、例えば、帯域幅、作成可能な接続の数、及び、１秒当たりの新たな作成可能な接続の数などの性能パラメータに基づく。全てのユーザによって選択されたＳＬＢストラテジによって参照されるサービス能力の合計が転送サーバの容量を超える場合に、管理者に、例えば、ユーザによって参照されるサービス能力を限定する、または転送サーバの容量を拡張するといった対応する措置を講じるように通知するアラームが発せられる。この場合に、ユーザによって参照されるサービス能力を制限することは、現在生成されている時限タスクを停止すること、すなわち、対応する期間において負荷バランシング容量を満たさないＳＬＢストラテジの実行を停止すること、及び、要求を満たすために新たな時限タスクを生成するための実際の状況に応じて、ＳＬＢストラテジを調節することであってもよい。

例えば、ステップＳ４０２は、リクエスト期間と既存の時限タスクの実行期間とが重複期間を有する場合に、重複期間に基づいて既存の時限タスクの実行期間を更新すること、及び、その後、更新された実行期間に基づいて既存の時限タスクを更新することをさらに含み、時限タスクは、一度実行される時限タスク、または周期的かつ循環的に実行される時限タスクである。

具体的な例示の実施形態では、例えば、既存の時限タスク、及び図３（ａ）に示される対応する期間におけるストラテジにおいて、ストラテジａ３０２が期間Ａ３０４において実行され、ストラテジｂ３０６が期間Ｂ３０８において実行される。ユーザが突然、要求、例えば、図３（ｂ）に示されるように、期間Ｃ３１２においてストラテジｃ３１０を実行する要求を示す時、期間Ｃ３１２の１つの部分は、期間Ａ３０４に属し、他の部分は期間Ｂ３０８に属し、重複した期間が存在する。この場合に、既存の時限タスクの実行期間は、更新される必要がある、すなわち、期間Ａ３０４においてＳＬＢストラテジａ３０２を最初に実行し、かつ期間Ｂ３０８においてＳＬＢストラテジｂ３０４を実行することは、期間Ａ’３１４においてＳＬＢストラテジａ３０２を実行すること、次の期間Ｃ３１２においてＳＬＢストラテジｃ３１０を実行すること、及びその後の期間Ｂ’３１６においてＳＬＢストラテジｂ３０４を実行することに更新される。ストラテジａ及びストラテジｂに対応する時限タスクの実行期間が変更され、このように、ユーザの選択リクエストに応じて、ユーザが必要とするＳＬＢストラテジが柔軟に構成されることで、負荷バランシングは種々の環境に対してより柔軟になり、かつより良く適応するようになり、それによって、負荷バランシングの利用可能性が拡張されることが分かる。さらに、既存の時限タスクは、更新された期間に応じて更新される。例えば、ストラテジａ３０２の時限タスクは期間Ａ’３１４において一度実行され、ストラテジｃ３１０は期間Ｃ３１２において循環的に実行される。

例えば、ステップＳ４０４は、時限タスクに対応する実行期間が終了すると、既存の負荷バランシング方法を削除し、次の実行期間に対応する負荷バランシング方法を取得することを含む。

例えば、時間ベースＳＬＢ一度実行される時限タスクは以下の方法で作成されてもよい。

１）期間に応じて循環させるストラテジ、例えば、２４時間以内のＳＬＢストラテジは、１日を単位として使用することによって定められ、これらのストラテジは１日ごとに循環する、または、７×２４時間以内のＳＬＢストラテジは、１週間を単位として使用することによって定められ、これらのストラテジは１週間ごとに循環する、または、３０日以内のＳＬＢストラテジは１か月を単位として使用することによって定められ、これらのストラテジは１か月ごとに循環する。取得装置１１０は、周期的に循環させる必要がある期間情報、及び対応するＳＬＢストラテジを取得後に、対応する期限タスクを生成し、ここで、期限タスクは、要求に応じて周期的かつ循環的に実行される。期間に応じて循環させるストラテジを作成する方法は、単なる例であり、対応するＳＬＢストラテジは循環時間として任意の時間単位を使用することによって循環させてもよく、周期的かつ循環的に実行される他の既存の、または将来的に可能な時限タスクも、本開示に適用可能である場合は本開示の保護範囲に含まれ、参照によって本明細書に組み込まれるものとすることに留意するべきである。

２）それぞれの期間は異なるストラテジを有し、異なるＳＬＢストラテジは異なる期間に対応しており、ある期間におけるストラテジは循環しない。すなわち、期間情報及び対応するＳＬＢストラテジが取得された後、ある期間に対応する期限タスクが生成され、期限が終了すると、対応するストラテジは削除され、該期限におけるストラテジは循環的に実行されない。例えば、具体的なシナリオでは、９：００から１７：００までの期間は作業時間であり、帯域幅を増大させる必要があるため、ＳＬＢストラテジ２が使用され、翌日の２２：００から０６：００までの期間において、帯域幅を減少させる必要があるため、ＳＬＢストラテジ３が使用され、他の期間においてはストラテジ１が実行される。従って、生成される時限タスクは全て、一度実行され、すなわち、対応する時限タスクは、ストラテジ２が９：００から１７：００までの期間において実行された後に終了させ、対応する時限タスクは、ストラテジ３が翌日の２２：００から０６：００までの期間に実行された後に終了させる。別の例として、ユーザが支払いを行う時、１か月の期限の請求書が生成され、ユーザは、何らかの理由によってある月の第１の期間において固定帯域幅を選択し、かつ残りの期間においてトラフィックベース課金方法を使用する必要があるため、ユーザの要求に応じて、時限タスクａが第１の期間に一度実行され、ここで、時限タスクａは第１の期間において固定帯域幅に従って課金するストラテジであり、課金方法は、期間が終了すると変更される。時限タスクｂがまた、残りの期間において一度実行され、ここで、時限タスクｂは、残りの期間におけるトラフィックに応じて課金するストラテジを指し、時限タスクｂは期間が終了すると停止され、トラフィックに応じて課金するストラテジは削除され、新たな期間、及び該期間に対応するストラテジが取得される。

３）組み合わせたストラテジが作成され、この場合に、異なるストラテジが異なる期間において使用され、循環的に実行されるストラテジもある期間において定められてよい。例えば、ユーザは、１か月の（例えば、１１月に）トラフィックの大きな格上げを必要とし、この月において大きな帯域幅が設定され、ストラテジａが他の月において実行され、ストラテジｂが帯域幅を増大させるために１１月の期間に実行される。しかしながら、この月の期間において、循環的なストラテジも定められている場合があり、異なる期間において必要とされる異なる帯域幅量に応じて、例えば、ストラテジｂ’１はこの月の昼の期間に実行され、ストラテジｂ’２は夜の期間に実行される。一度実行される時限タスクと周期的かつ循環的に実行される時限タスクとを連係させる時限タスクは、ユーザの選択リクエストに応じて実施される。

上記の例示の実施形態において、ユーザによって選択される複数のＳＬＢストラテジが取得された後、負荷バランシングがサービスのために調節される時、全てのユーザによって使用されるストラテジによって参照されるサービス能力の合計が転送サーバのサービス能力を超えることができないようにすることが満たされるものとし、合計が転送サーバのサービス能力を超える場合に、アラームを発し、かつ対応する措置を講じるように通知情報を送ることが必要であることに留意するべきである。

本開示が、ソフトウェア及び／またはソフトウェアとハードウェアとの組み合わせで実装されてもよく、例えば、特定用途向け集積回路（ＡＳＩＣ）、汎用コンピュータ、またはその他の同様のハードウェアデバイスが本開示を実装するために使用可能であることに留意するべきである。１つの例示の実施形態では、本開示のソフトウェアプログラムは、上述されたステップまたは機能を実現するためにプロセッサによって実行されてもよい。同様に、本開示の（関連のデータ構造を含む）ソフトウェアプログラムは、コンピュータ可読記録媒体、例えば、ＲＡＭメモリ、磁気または光学ドライブまたはフロッピーディスク、及び同様のデバイスに記憶可能である。さらに、本開示のいくつかのステップまたは機能は、ハードウェア、例えば、プロセッサと協働してさまざまなステップまたは機能を行う回路によって実装されてもよい。

さらに、本開示の一部分は、コンピュータプログラム製品、例えば、コンピュータプログラム命令として適用可能であり、コンピュータによって実行される時、本開示による方法及び／または技術的解決策は、コンピュータの動作を通して呼び出され得る、または提供可能である。本開示の方法を呼び出すプログラム命令は、固定された、または取り外し可能な記録媒体に記憶されてもよい、及び／または、ブロードキャスト、または他の信号搬送媒体におけるデータストリームによって送信されてもよい、及び／または、プログラム命令に従って動作するコンピュータデバイスの作業メモリに記憶されてもよい。本明細書において、本開示による例示の実施形態は装置を含み、該装置は、コンピュータプログラム命令を記憶するように構成されたメモリ、及びプログラム命令を実行するように構成されたプロセッサを含み、コンピュータプログラム命令がプロセッサによって実行される時、装置は、本開示の複数の例示の実施形態に基づいて、方法及び／または技術的解決策を実行するようにトリガされる。

当業者にとって、本開示は前述の例示的な実施形態の詳細に限定されるものではなく、本開示は、本開示の趣旨または基本的特徴から逸脱することなく、他の具体的な形式で実施可能であることは明らかである。従って、どの観点からでも、例示の実施形態は、限定的なものではなく例示的なものとみなされるものであり、本開示の範囲は、上記の説明によってではなく、添付の特許請求の範囲によって定められるものであるため、本開示は、特許請求の範囲の均等な要素の意味及び範囲内にある全ての変更を包含することが意図される。特許請求の範囲のいずれの参照符号も、関係のある特許請求の範囲を限定するものとみなされるべきではない。さらに、「ｉｎｃｌｕｄｅ（含む）」という言い回しは他のユニットまたはステップを除外せず、かつ単数形のものは複数形のものを除外しないことは明らかである。装置の請求項で述べた複数のユニットまたは装置はまた、ソフトウェアまたはハードウェアを通して、１つのユニットまたは装置によって実施されてもよい。「第１」及び「第２」などの用語は、名称を表すために使用され、いかなる具体的な順序も示さない。

Claims

実行期間、及び前記実行期間に実行される負荷バランシング方法を含む時限タスクを取得することと、
現在の時刻が前記実行期間に入っているかを判定することと、
前記時限タスクに対応する前記負荷バランシング方法を取得することと、
前記時限タスクに対応する前記実行期間が終了するまで、前記時限タスク対応する前記負荷バランシング方法に基づいて複数のサーバ間で負荷バランシングを処理することと、を含む、方法。
前記時限タスクを取得することは、
ユーザリクエストを取得することであって、前記ユーザリクエストは、リクエスト期間、及び前記リクエスト期間に実行される負荷バランシング方法を含む、前記取得することと、
前記ユーザリクエストに基づいて前記時限タスクを生成することと、
前記リクエスト期間に基づいて前記時限タスクの前記実行期間を決定することと、
前記ユーザリクエストに基づいて、前記実行期間に実行される前記負荷バランシング方法を決定することと、を含む、請求項１に記載の方法。
前記ユーザリクエストに基づいて、前記実行期間に実行される前記負荷バランシング方法を決定することは、
前記ユーザリクエストに基づいて負荷バランシングの性能パラメータ情報を取得することと、
前記負荷バランシングの性能パラメータ情報に基づいて、前記実行期間に実行される前記負荷バランシング方法を決定することと、を含む、請求項２に記載の方法。
前記性能パラメータ情報は帯域幅量を含む、請求項３に記載の方法。
前記性能パラメータ情報は作成可能な接続の数を含む、請求項３に記載の方法。
前記性能パラメータ情報は１秒当たりの新たな作成可能な接続の数を含む、請求項３に記載の方法。
前記ユーザリクエストに基づいて、前記実行期間に実行される前記負荷バランシング方法を決定することは、
取得された前記負荷バランシングの性能パラメータ情報が前記負荷バランシングの既存のサービス能力の性能パラメータ情報を超える場合に、前記時限タスクの生成を停止することと、
アラーム通知情報を返すことと、を含む、請求項３に記載の方法。
前記時限タスクを取得することは、
前記リクエスト期間と前記実行期間とが重複期間を有する場合に、前記重複期間に基づいて前記時限タスクの前記実行期間を更新することと、
更新された前記実行期間に基づいて前記時限タスクを更新することと、をさらに含む、請求項２に記載の方法。
前記時限タスクに対応する前記実行期間が終了すると、前記負荷バランシング方法を削除し、次の実行期間に対応する次の負荷バランシング方法を取得することをさらに含む、請求項１に記載の方法。
前記時限タスクは、以下のいずれか、すなわち、
周期的かつ循環的に実行される第１の時限タスク、
一度実行される第２の時限タスク、及び、
一度実行される前記第１の時限タスクと周期的かつ循環的に実行される前記第２の時限タスクとを連係させる第３の時限タスクのいずれかを含む、請求項１に記載の方法。
実行期間、及び、前記実行期間に実行される負荷バランシング方法を含む時限タスクを取得して記録する取得装置と、
現在の時刻が前記実行期間に入っているかを判定し、前記時限タスクに対応する前記負荷バランシング方法を取得し、前記時限タスクに対応する前記実行期間が終了するまで、前記時限タスクに対応する前記負荷バランシング方法に基づいて複数のサーバ間で負荷バランシングを処理する実行装置と、を含む、デバイス。
前記取得装置は、
ユーザリクエストを取得するリクエスト取得ユニットであって、前記ユーザリクエストは、リクエスト期間、及び前記リクエスト期間に実行される負荷バランシング方法を含む、前記リクエスト取得ユニットと、
前記ユーザリクエストに基づいて前記時限タスクを生成し、前記リクエスト期間に基づいて前記時限タスクの前記実行期間を決定する生成ユニットと、
前記ユーザリクエストに基づいて、前記実行期間に実行される前記負荷バランシング方法を決定する決定ユニットと、を含む、請求項１１に記載のデバイス。
前記決定ユニットはさらに、
前記ユーザリクエストに基づいて負荷バランシングの性能パラメータ情報を取得し、
前記負荷バランシングの性能パラメータ情報に基づいて、前記実行期間に実行される前記負荷バランシング方法を決定する、請求項１２に記載のデバイス。
前記性能パラメータ情報は、以下のうちの少なくとも１つ、すなわち、
帯域幅量、
作成可能な接続の数、及び、
１秒当たりの新しい作成可能な接続の数のうちの少なくとも１つを含む、請求項１３に記載のデバイス。
前記判断ユニットはさらに、
取得された前記負荷バランシングの性能パラメータ情報が前記負荷バランシングの既存のサービス能力の性能パラメータ情報を超える場合に、前記時限タスクの生成を停止し、
アラーム通知情報を返す、請求項１２に記載のデバイス。
前記取得装置は、
前記リクエスト期間と既存の前記時限タスクの前記実行期間とが重複期間を有する場合に、前記重複期間に基づいて前記既存の時限タスクの前記実行期間を更新する第１の更新ユニットを含む、請求項１１に記載のデバイス。
前記取得装置は、
更新された前記実行期間に基づいて前記既存の時限タスクを更新する第２の更新ユニットをさらに含み、前記時限タスクは、一度実行される時限タスク、または周期的かつ循環的に実行される時限タスクである、請求項１６に記載のデバイス。
前記実行装置はさらに、
前記時限タスクに対応する前記実行期間が終了すると、前記負荷バランシング方法を削除し、次の実行期間に対応する次の負荷バランシング方法を取得する、請求項１１に記載のデバイス。
前記時限タスクは、以下のいずれか、すなわち、
周期的かつ循環的に実行される第１の時限タスク、
一度実行される第２の時限タスク、及び、
一度実行される前記第１の時限タスクと周期的かつ循環的に実行される前記第２の時限タスクとを連係させる第３の時限タスクのいずれかを含む、請求項１１に記載のデバイス。
１つまたは複数のプロセッサによって実行される時、前記プロセッサに、
時限タスクを取得することであって、前記時限タスクは、実行期間、及び、前記実行期間に実行される負荷バランシング方法を含む、前記取得することと、
現在の時刻が前記実行期間に入っているかを判定することと、
前記時限タスクに対応する前記負荷バランシング方法を取得することと、
前記時限タスクに対応する前記実行期間が終了するまで、前記時限タスクに対応する前記負荷バランシング方法に基づいて複数のサーバ間で負荷バランシングを処理することと、を含む動作を行わせるコンピュータ実行可能命令を記憶した１つまたは複数のメモリ。