2.3. keepalived スケジューリングの概要

Keepalived を使用すると、さまざまなスケジューリングアルゴリズムがサポートされるため、実サーバー間でトラフィックを分散する柔軟性が高くなります。階層的な DNS やクライアントマシンのキャッシングによって負荷が不均等になるラウンドロビン DNS などの柔軟性が低い方法よりも、負荷分散に優れています。さらに、ネットワークパケットレベルで負荷分散を行うと計算のオーバーヘッドが最小限になり、スケーラビリティーが向上するため、LVS ルーターが使用する低レベルのフィルタリングは、アプリケーションレベルの要求転送よりも優れています。
割り当てられた加重値を使用すると、各マシンに任意の優先度を提供します。このようなスケジューリングを使用すると、さまざまなハードウェアとソフトウェアの組み合わせを使用して実サーバーのグループを作成でき、アクティブなルーターは負荷を実サーバーへ均等に分散できます。
Keepalived のスケジューリングメカニズムは、IP 仮想サーバー または IPVS モジュールと呼ばれるカーネルパッチの集合によって提供されます。このモジュールは レイヤー 4 (L4) トランスポート層スイッチングを有効にします。これは、単一 IP アドレス上で複数のサーバーとうまく機能するように設計されています。
パケットの追跡や実サーバーへのルーティングを効率的に行うため、IPVS はカーネルに IPVS テーブルを構築します。このテーブルは、アクティブ LVS ルーターによって使用され、要求を仮想サーバーアドレスからプールの実サーバーへリダイレクトしたり、プールの実サーバーから戻したりします。

2.3.1. keepalived スケジューリングアルゴリズム

IPVS テーブルの構造は、管理者が仮想サーバーに対して選択するスケジューリングアルゴリズムによって異なります。クラスター化できるサービスのタイプや、これらのサービスがスケジュールされる方法で柔軟性を最大限にするため、Keepalived は以下のスケジューリングアルゴリズムをサポートします
ラウンドロビンスケジューリング (Round-Robin Scheduling)
要求を順番に実サーバーのプールで分配します。このアルゴリズムを使用すると、容量や負荷に関係なく実サーバーはすべて同等に扱われます。このスケジューリングモデルはラウンドロビン DNS と似ていますが、ホストベースではなくネットワークベースであるため、粒度がより細かくなります。また、ロードバランサーのラウンドロビンスケジューリングでは、キャッシュされた DNS クエリーが原因で負荷が不均等になることはありません。
加重ラウンドロビンスケジューリング (Weighted Round-Robin Scheduling)
各要求を順番に実サーバーのプールで分散しますが、容量の多いサーバーにより多くのジョブを割り当てます。容量は、ユーザーが割り当てる加重係数によって示され、動的な負荷情報によって調整されます。
プール内の実サーバー間で処理能力に大幅な違いがある場合は、重み付きラウンドロビンスケジューリングが適しています。ただし、要求負荷が大きく変化する場合は、重みの大きいサーバーが割り当て以上の要求に応じる可能性があります。
最小接続 (Least-Connection)
実際の接続が少ない実サーバーにより多くの要求を振り分けます。IPVS テーブルで実サーバーへのライブ接続を継続的に追跡するため、Least-Connection は動的なスケジューリングアルゴリズムになります。要求負荷の変化が大きい場合に適しています。このアルゴリズムは各メンバーノードの処理能力がほぼ同じで大差がないような実サーバープールに最適です。サーバーグループの処理能力が異なる場合は weighted least-connection スケジューリングの方が適しています。
加重最小接続 (Weighted Least-Connections)
容量と比較してより少ないアクティブな接続を持つサーバーにより多くの要求を分散します。容量は、ユーザーが割り当てる加重係数によって示され、動的な負荷情報によって調整されます。実際のサーバープールに異なる容量のハードウェアが含まれる場合、加重が追加されるこのアルゴリズムが適しています。
ローカリティーベースの最小接続スケジューリング (Locality-Based Least-Connection Scheduling)
接続先 IP に対して相対的にアクティブな接続が少ないサーバーにより多くの要求を振り分けます。このアルゴリズムは、プロキシキャッシュサーバーのクラスターで使用するために設計されています。サーバーがキャパシティーを超えておらず、負荷が半分の別のサーバーがない場合、IP アドレスのパケットをそのアドレスのサーバーに送信します。サーバーがキャパシティーを超え、負荷が半分のサーバーがある場合は、IP アドレスを負荷が最も少ない実サーバーに割り当てます。
複製スケジューリングを伴うローカリティベースの最小接続スケジューリング (Locality-Based Least-Connection Scheduling with Replication Scheduling)
接続先 IP に対して相対的にアクティブ接続が少ないサーバーにより多くの要求を振り分けます。このアルゴリズムは、プロキシキャッシュサーバーのクラスターで使用するために設計されています。ローカリティベースの最小接続スケジューリングとの違いは、ターゲットの IP アドレスが実サーバーノードのサブセットにマッピングされる点です。その後に要求は、このサブセット内で接続が最も少ないサーバーに送信されます。接続先 IP のノードがすべてキャパシティーを上回っている場合、実サーバーのプール全体で接続が一番少ないサーバーをその接続先 IP の実サーバーのサブセットに追加することで、接続先 IP アドレス向けに新たなサーバーを複製します。すると、負荷の最も高いノードが実サーバーのサブセットから外され、過剰な複製が抑制されます。
接続先ハッシュスケジューリング (Destination Hash Scheduling)
静的ハッシュテーブル内の接続先 IP を検索して、実サーバーのプールに要求を振り分けます。このアルゴリズムは、プロキシキャッシュサーバーのクラスターで使用するために設計されています。
ソースハッシュスケジューリング (Source Hash Scheduling)
静的ハッシュテーブル内のソース IP を検索して、実サーバーのプールに要求を振り分けます。このアルゴリズムは、複数のファイアウォールがある LVS ルーター向けに設計されています。
最短予測遅延 (Shortest Expected Delay)
サーバー上の接続数を割り当てられた加重値で割った値を基して、最も短い遅延が期待されるサーバーへ接続要求を分配します。
キューなし (Never Queue)
最初に接続要求を見つけ、アイドル状態または接続がないサーバーへ接続要求を送信する 2 面のスケジューラーです。アイドル状態のサーバーがない場合、スケジューラーはデフォルトで 最短予測遅延 (Shortest Expected Delay) と同様に最も遅延が少ないサーバーを選択します。

2.3.2. サーバーの加重値とスケジューリング

ロードバランサーの管理者は、実際のサーバープールの各ノードに加重値を割り当てできます。この加重値は整数値で、加重値を認識するスケジューリングアルゴリズム (加重最小接続など) で考慮されます。また、LVS ルーターが異なる容量を持つハードウェアで負荷を均等にできるようにします。
加重値は、それぞれに対する相対的な割合として機能します。たとえば、ある実サーバーの加重値が 1 で別のサーバーの加重値が 5 の場合、前者が 1 回接続されるごとに後者が 5 回接続されます。実サーバーの加重値のデフォルト値は 1 です。
実サーバープール内でそれぞれ異なるハードウェア構成のノードに重みを付けるとクラスターでの負荷分散をより効率的に行う場合に役立ちますが、 weighted least-connection スケジューリングで仮想サーバーが設定されている際、任意の実サーバーがその実サーバープールに挿入されると、一時的に不均衡が生じる場合があります。例えば、実サーバープールに 3 台のサーバーがあったとします。サーバー A と B に 1 の重みが付けられ、サーバー C には 2 の重みが付けられていたとします。サーバー C が何らかの理由でダウンした場合、放棄された負荷がサーバー A と B に均等に分散されます。しかし、サーバー C がオンラインに復帰すると、LVS ルーター側でサーバー C の接続がまったくないと判断され、サーバー A および B と同等になるまで着信要求をすべてサーバー C に集中的に振り分けることになります。