Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

1.3. Load Balancer Add-On スケジューリング機能の概要

Load Balancer Add-On を使う利点の一つは、柔軟性のある IP レベルの負荷分散を実サーバーのプールで実行できることです。この柔軟な負荷分散は Load Balancer Add-Onの設定時に選択できるスケジューリングアルゴリズムの多様性により実現しています。DNS の階層性質やクライアントマシンによるキャッシングが不均衡な負荷につながる ラウンドロビン DNS などの柔軟性に乏しい方法に比べ、Load Balancer Add-On の負荷分散は非常に優れています。また、ネットワークパケットレベルでの負荷分散により計算オーバーヘッドが最小限に抑えられ拡張性が高まるため、LVS ルーターが使用する低レベルのフィルタリングの方がアプリケーションレベルの要求転送より優れていると言えます。
スケジューリング機能を使用すると、サービス要求をルーティングする際にアクティブルーター側で実サーバーのアクティビティや、オプションで管理者が割り当てた 重み 要素などを考慮させることができます。重み割り当てを使うことで各マシンに任意の優先順位が与えられます。この形式のスケジューリング機能を使うと、各種ハードウェアとソフトウェアの組み合わせを使用した複数の実サーバーから成るグループを作成することができ、アクティブルーターが負荷を各実サーバーに均等に分散することができます。
Load Balancer Add-Onのスケジューリングのメカニズムは IP 仮想サーバー または IPVS モジュールと呼ばれるカーネルパッチの集合で提供されます。このモジュールにより 、ひとつの IP アドレスで複数のサーバーが正しく動作するよう設計されている layer 4 (L4) トランスポート層の切り替えが可能になります。
実サーバーへのパケットを効率的に追跡、ルーティングするため、IPVS はカーネル内に IPVS テーブル を構築します。アクティブ LVS ルーターにより仮想サーバーアドレスとプール内の実サーバー間での要求のリダイレクトに使用されます。IPVS テーブルはクラスターメンバーの可用性に応じてそのメンバーの追加や削除を行う ipvsadm というユーティリティで継続的に更新されます。

1.3.1. スケジューリングのアルゴリズム

IPVS テーブルの構造は管理者が仮想サーバーに選択するスケジューリングアルゴリズムによって異なります。クラスター化できるサービスタイプとこれらのサービスのスケジューリングでの柔軟性を最大限に利用するため、Red Hat Enterprise Linux では以下のようなスケジューリングアルゴリズムを提供しています。スケジューリングアルゴリズムの割り当て方については 「VIRTUAL SERVER サブセクション」 を参照してください。
Round-Robin Scheduling
要求を順番に実サーバーのプールに振り分けます。このアルゴリズムを使うと、処理能力や負荷に関係なくすべての実サーバーが平等に扱われます。このモデルはラウンドロビン DNS に似ていますが、ホストベースではなくネットワーク接続をベースにするためより細かな調整が可能です。また、Load Balancer Add-On のラウンドロビンスケジューリングはキャッシュされた DNS クエリーが原因で負荷分散が偏ることもありません。
Weighted Round-Robin Scheduling
要求を順番に実サーバーのプールに振り分けますが、より処理能力の高いサーバーに対して多くのジョブを振り分けます。処理能力はユーザーが割り当てた重み要素で示され、動的な負荷情報で上方修正または下方修正されます。実サーバーに重みを付ける方法については 「サーバーの重み付けとスケジューリング」 を参照してください。
プール内の実サーバー間で処理能力に大幅な違いがある場合は、重み付きラウンドロビンスケジューリングが適しています。ただし、要求負荷が大きく変化する場合は、重みの大きいサーバーが割り当て以上の要求に応じる可能性があります。
Least-Connection
実際の接続が少ない実サーバーにより多くの要求を振り分けます。IPVS テーブルで実サーバーへのライブ接続を継続的に追跡するため、Least-Connection は動的なスケジューリングアルゴリズムになります。要求負荷の変化が大きい場合に適しています。このアルゴリズムは各メンバーノードの処理能力がほぼ同じで大差がないような実サーバープールに最適です。サーバーグループの処理能力が異なる場合は weighted least-connection スケジューリングの方が適しています。
Weighted Least-Connections (デフォルト)
処理能力に対して相対的に実際の接続が少ないサーバーにより多くの要求を振り分けます。処理能力はユーザーが割り当てた重み要素で示され、動的な負荷情報で上方修正または下方修正されます。実サーバーのプールに異なる処理能力のハードウェアがある場合には、重みを付けることで理想的なアルゴリズムになります。実サーバーへの重みの付け方については 「サーバーの重み付けとスケジューリング」 を参照してください。
Locality-Based Least-Connection Scheduling
接続先 IP に対して相対的に実際の接続が少ないサーバーにより多くの要求を振り分けます。プロキシキャッシュサーバーのクラスターでの使用を目的として設計されています。任意の IP アドレスのパケットをその IP アドレスのサーバーに送信します。ただし、そのサーバーの負荷がその処理能力を超えている一方、別のサーバーの負荷は処理能力の半分に留まっている場合は、IP アドレスを負荷の一番少ない実サーバーに割り当てます。
Locality-Based Least-Connection Scheduling with Replication Scheduling
接続先 IP に対して相対的に実際の接続が少ないサーバーにより多くの要求を振り分けます。このアルゴリズムもプロキシキャッシュサーバーのクラスターでの使用を目的として設計されています。Locality-Based Least-Connection スケジューリングとの違いは、目的 IP アドレスを実サーバーノードのサブセットにマッピングする点です。要求はマッピングされたサブセット内で接続数が最少となるサーバーにルーティングされます。接続先 IP のノードがすべて処理能力を越えてしまっている場合は、実サーバーのプール全体で接続が一番少ないサーバーをその接続先 IP の実サーバーサブセットに追加して、その接続先 IP アドレスの新しいサーバーを複製します。一方、過剰な複製を防ぐため、負荷の最も高いノードが実サーバーのサブセットから外されます。
Destination Hash Scheduling
静的なハッシュテーブル内の接続先 IP を検索して、実サーバーのプールに要求を振り分けます。プロキシキャッシュサーバーのクラスターでの使用を目的として設計されています。
Source Hash Scheduling
静的なハッシュテーブル内のソース IP を検索して、実サーバーのプールに要求を振り分けます。複数のファイアウォールが設定される LVS ルーター向けに設計されています。