負荷分散スケジューリングアルゴリズムを見てみましょう

[[122758]]

ロード ホストは、スケジューリング メソッドまたはアルゴリズムと呼ばれる多くの負荷分散メソッドを提供できます。

ラウンドロビン

このアプローチでは、受信した要求をサーバー クラスター内の各マシン (つまり、アクティブ サーバー) にラウンドロビン方式で分散します。このアプローチを使用する場合、仮想サービスにマークされたすべてのサーバーのリソース容量とアプリケーション負荷は同様になるはずです。すべてのサーバーのパフォーマンスが同じか類似している場合、このアプローチを選択すると、サーバーの負荷が類似するようになります。この前提に基づくと、ラウンドロビン スケジューリングは、リクエストを割り当てるシンプルで効果的な方法です。ただし、さまざまなサーバーの状況でこの方法を選択すると、サーバーが現在のリクエストを処理できなくなった場合でも、次のラウンドでは能力の弱いサーバーもラウンドロビンされることになります。これにより、処理能力の低いサーバーに過負荷がかかる可能性があります。

加重ラウンドロビン

このアルゴリズムは、単純なラウンドロビン スケジューリング アルゴリズムの欠点を解決します。つまり、着信要求はクラスター内のサーバーに順番に割り当てられますが、各サーバーに事前に割り当てられた重みが考慮されます。管理者は、サーバーの処理能力に基づいて各サーバーの重みを定義するだけです。たとえば、最適な容量を持つサーバー A に与えられる重みは 100 ですが、最適な容量を持つサーバー A に与えられる重みは 50 です。つまり、サーバー B が最初のリクエストを受信する前に、サーバー A が 2 つのリクエストを連続して受信することになります。

最小接続

上記の両方のアプローチが考慮していないのは、システムが特定の時点で維持されている接続の数を知る方法がないことです。そのため、サーバー B がサーバー A よりも少ない接続を受信するが、サーバー B のユーザーのオープン接続がより長く続くために過負荷になるという状況が発生する可能性があります。つまり、接続数、つまりサーバーの負荷は累積されることになります。この潜在的な問題は、「最小接続」アルゴリズムを使用することで回避されます。つまり、受信リクエストは、各サーバーに現在開いている接続の数に基づいて分散されます。つまり、最もアクティブな接続が少ないサーバーが、次の着信要求を自動的に受信します。原理は基本的に単純なラウンドロビンと同じです。つまり、仮想サービスを持つすべてのサーバーは同様のリソース容量を持つ必要があります。トラフィック レートが低い構成環境では、各サーバーのトラフィックは同じではなく、最初のサーバーが優先されることに注意してください。これは、すべてのサーバーが同一の場合、最初のサーバーに継続的にアクティブなトラフィックがあるまでは最初のサーバーが優先され、それ以外の場合は最初のサーバーが常に最初に選択されるためです。

最小接続スロースタート時間

最小接続数および加重最小接続数のスケジュール方法では、サーバーがオンライン環境に最初に追加されるときに、接続数が制限され、ゆっくりと増加する期間をサーバーに対して構成できます。これにより、起動直後に割り当てられた接続が多すぎてサーバーが過負荷にならないようにするための「移行期間」がサーバーに提供されます。この値は L7 構成インターフェイスで設定されます。

重み付け最小接続

サーバーのリソース容量が変化する場合は、「重み付け最小接続」アプローチがより適切です。サーバーの状況に合わせて管理者がカスタマイズした重みによって決定されるアクティブな接続の数は、最小接続と重みの両方を活用するため、通常、サーバーを非常にバランスよく利用することができます。一般的に、これは接続数とサーバーの重みの比率を使用するため、非常に公平な分散であり、クラスター内で最も高い比率を持つサーバーが次のリクエストを自動的に受信します。ただし、トラフィックの少ない状況でこのアプローチを使用する場合は、「最小接続」アプローチの注意事項を参照してください。

エージェントベースの適応型バランシング

上記の方法に加えて、ロード ホストには、サーバーの状態とサーバーの重みを定期的に監視する適応ロジックが含まれています。非常に強力な「プロキシベースの適応型負荷分散」方式では、負荷ホストがすべてのサーバーの負荷状態を次の方法で定期的に検出します。各サーバーは、サーバーの実際の負荷状態を示す 0 から 99 までの数字 (0 = ***、99 = 過負荷、101 = 障害、102 = 管理者が無効) を含む include ファイルを提供する必要があり、サーバーは isomorphic http get メソッドを使用してこのファイルを取得します。同時に、クラスター内のサーバーの場合、バイナリ ファイルの形式で独自の負荷状態を提供することもサーバーのジョブの 1 つですが、サーバーが独自の負荷状態を計算する方法に制限はありません。サーバー全体の負荷に応じて、次の 2 つの戦略から選択できます。通常の操作では、スケジューリング アルゴリズムは、サーバー負荷値とサーバーに割り当てられた接続数の比率を収集して重み比を計算します。したがって、サーバーが過負荷になった場合、重みはシステムを通じて透過的に再調整されます。加重ラウンドロビン スケジューリング方式と同様に、誤った割り当てを記録して、異なるサーバーに異なる重みを効果的に割り当てることができます。ただし、トラフィックが非常に少ない環境では、サーバーによって報告される負荷値は代表的なサンプルを形成しないため、これらの値に基づいて負荷を分散すると、制御が失われ、コマンドが振動することになります。したがって、この場合、静的重量比に基づいて荷重分布を計算する方が合理的なアプローチです。すべてのサーバーの負荷が管理者によって定義された下限を下回る場合、負荷ホストは自動的に加重ラウンドロビン方式に切り替えてリクエストを分散します。負荷が管理者によって定義された下限を上回る場合、負荷ホストは適応型方式に戻ります。

固定加重

*** 重みは、他のサーバーの重み値が非常に低い場合にのみ使用されます。ただし、重みが最も高いサーバーがダウンした場合は、次に優先度の高いサーバーがクライアントにサービスを提供します。このように、各実サーバーの重みは、サーバーの優先度に基づいて設定する必要があります。

重み付け応答

トラフィックは、加重ラウンドロビン方式を使用してスケジュールされます。加重ラウンドロビンで使用される重みは、サーバーの有効性チェックの応答時間に基づいて計算されます。各有効性チェックには、正常に応答するまでにかかった時間を示すための時間が計測されます。ただし、この方法では、サーバーのハートビート検出はマシンの速度に基づいていると想定していますが、この想定が常に当てはまるとは限らないことに注意してください。仮想サービス上のすべてのサーバーの応答時間の合計が加算され、この値を使用して単一のサービス物理サーバーの重みが計算されます。この重み値は約 15 秒ごとに計算されます。

ソース IP ハッシュ

このメソッドは、要求元 IP のハッシュ値を生成し、このハッシュ値を使用して正しい実サーバーを検索します。つまり、同じホストの場合、対応するサーバーは常に同じになります。この方法を使用すると、ソース IP を保存する必要はありません。ただし、このアプローチではサーバーの負荷が不均衡になる可能性があることに注意してください。