負荷分散ホストは多くの負荷分散方法を提供できます。これは私たちがよく言うスケジューリング方法またはアルゴリズムです：
ラウンドロビン（Round Robin）
この方法では、受け取ったリクエストをサーバークラスター内の各マシン、すなわち有効なサーバーに循環のに割り当てます。この方式を使用する場合、仮想サービスに入るとマークされたすべてのサーバーは、同等のリソース容量と同様の負荷のアプリケーションを備えている必要があります。すべてのサーバーが同じまたは同等の性能を持っている場合、この方式を選択するとサーバーの負荷が同じになります。この前提に基づき、ラウンドロビンスケジューリングはシンプルで効果的なリクエスト割り当て方法です。ただし、サーバーが異なる状況では、この方式を選択すると、性能の低いサーバーも次のラウンドでリクエストを受け取ることになります。たとえそのサーバーが現在のリクエストを処理できなくなっていたとしてもです。これにより、性能の低いサーバーが過負荷になる可能性があります。
重み付きラウンドロビン（Weighted Round Robin）
このアルゴリズムは、単純なラウンドロビンスケジューリングアルゴリズムの欠点を解決します。着信リクエストは順番にクラスター内のサーバーに割り当てられますが、各サーバーに事前に割り当てられた重みが考慮されます。管理者は単純にサーバーの処理能力に基づいて各サーバーの重みを定義します。例えば、最も性能の高いサーバーAには重み100が与えられ、最も性能の低いサーバーには重み50が与えられます。これは、サーバーBが最初のリクエストを受け取る前に、サーバーAが連続して2つのリクエストを受け取ることを意味します。
最小接続数（Least Connection）
上記の2つの方法では、システムが特定の時点で維持されている接続数を認識できないという点が考慮されていません。そのため、サーバーBがサーバーAよりも受け取った接続数が少ないにもかかわらず、サーバーBのユーザーが接続を開いている時間が長いために、サーバーBがすでに過負荷になっているという状況が発生する可能性があります。つまり、接続数すなわちサーバーの負荷は累積されるということです。この潜にのな問題は「最小接続数」アルゴリズムによって回避できます。着信リクエストは、各サーバーで現在開かれている接続数に基づいて割り当てられます。つまり、アクティブな接続数が最も少ないサーバーが自動的に次の着信リクエストを受け取ります。基本的には単純なラウンドロビンの原則と同じで、仮想サービスを持つすべてのサーバーのリソース容量は同等である必要があります。注目すべき点は、トラフィック率が低い構成環境では、各サーバーのトラフィックは同じではなく、最初のサーバーが優先されることです。これは、すべてのサーバーが同じである場合、最初のサーバーが優先されるためです。最初のサーバーに継続のなアクティブトラフィックがない限り、常に最初のサーバーが選択されます。
最小接続数スロースタート時間（Least Connection Slow Start Time）
最小接続数および重み付き最小接続数のスケジューリング方法では、サーバーが本番環境に追加されたばかりのときに、期間を設定できます。この期間中、接続数は制限され、ゆっくりと増加します。これによりサーバーに「移行期間」が提供され、起動直後に割り当てられる接続数が多すぎて過負荷になることを防ぎます。この値はL7設定画面で設定します。
重み付き最小接続数（Weighted Least Connection）
サーバーのリソース容量がそれぞれ異なる場合、「重み付き最小接続数」方式がより適切です。管理者がサーバーの状況に応じてカスタマイズした重みによって決定されるアクティブ接続数は、最小接続数と重み付けの両方の利点を活用しているため、一般的にサーバーを非常にバランスよく利用できます。通常、これは非常に公平な割り当て方法です。接続数とサーバーの重みの比率を使用し、クラスター内で比率が最も低いサーバーが自動的に次のリクエストを受け取ります。ただし、低トラフィック環境でこの方法を使用する場合は、「最小接続数」方式の注意事項を参照してください。
エージェントベースの適応型負荷分散（Agent Based Adaptive Balancing）
上記の方法に加えて、負荷分散ホストには、サーバーの状態とそのサーバーの重みを定期的に監視するための適応ロジックが含まれています。非常に強力な「エージェントベースの適応型負荷分散」方式では、負荷分散ホストは次の方法で全サーバーの負荷状況を定期的に検出します。各サーバーは、そのサーバーの実際の負荷状況を示す0〜99の数値を含むファイルを提供する必要があります（0=空き、99=過負荷、101=障害、102=管理者による無効化）。サーバーはHTTP GETメソッドを使用してこのファイルを取得します。同時に、クラスター内のサーバーにとって、自身の負荷状況をバイナリファイルの形式で提供することもサーバーの役割の1つです。ただし、サーバーが自身の負荷状況をどのように計算するかについての制限はありません。サーバーの全体のな負荷状況に応じて、2つの戦略から選択できます。通常の運用では、スケジューリングアルゴリズムは、収集したサーバー負荷値とそのサーバーに割り当てられた接続数の比率に基づいて重み比率を計算します。したがって、サーバーの負荷が大きすぎる場合、重みはシステムによって透過のに再調整されます。重み付きラウンドロビンスケジューリング方式と同様に、不適切な割り当てを記録して、異なるサーバーに異なる重みを効果のに割り当てることができます。しかしながら、トラフィックが非常に少ない環境では、サーバーから報告された負荷値は代表のなサンプルを確立できません。そのような値に基づいて負荷を割り当てると、制御不能や命令の振動が発生する可能性があります。したがって、このような状況では、静的な重み比率に基づいて負荷割り当てを計算する方が合理的です。すべてのサーバーの負荷が管理者が定義した下限値を下回ると、負荷分散ホストは自動的に重み付きラウンドロビン方式に切り替えてリクエストを割り当てます。負荷が管理者が定義した下限値より大きい場合、負荷分散ホストは再び適応型方式に切り替わります。
固定重み付け（Fixed Weighted）
最高の重みは、他のサーバーの重み値がすべて非常に低い場合にのみ使用されます。ただし、最高の重みを持つサーバーがダウンした場合、次の最優先サーバーがクライアントにサービスを提供します。この方式では、各実サーバーの重みはサーバーの優先度に基づいて設定する必要があります。
重み付き応答（Weighted Response）
トラフィックのスケジューリングは重み付きラウンドロビン方式で行われます。重み付きラウンドロビンで使用される重みは、サーバーの可用性チェックの応答時間に基づいて計算されます。各可用性チェックはタイミングが測定され、応答が成功するまでにかかった時間が記録されます。ただし、この方式はサーバーのハートビートチェックがマシンの速度に基づくことを前提としていますが、この前提は常に成り立つとは限らないことに注意する必要があります。仮想サービス上の全サーバーの応答時間の合計が加算され、この値を使用して各物理サーバーの重みが計算されます。この重み値は約15秒ごとに計算されます。
送信元IPハッシュ（Source IP Hash）
この方式では、リクエストの送信元IPのハッシュ値を生成し、このハッシュ値を使用して適切な実サーバーを見つけます。これは、同じホストに対して、対応するサーバーが常に同じであることを意味します。この方式を使用すれば、送信元IPを保存する必要はありません。ただし、この方式ではサーバーの負荷が不均衡になる可能性があることに注意してください。
出典：http://www.codeceo.com/article/balanced-algorithm.html