第5章 HAProxy の設定

本章では、可用性の高い環境に HAProxy を導入する際の一般的な設定オプションに焦点を置きながら基本的なセットアップの構成について説明していきます。
HAProxy は、負荷分散を行うための独自のスケジューリングアルゴリズムのセットを持っています。これらのアルゴリズムは 「HAProxy のスケジューリングアルゴリズム」 に記載されています。
HAProxy の設定を行う場合は /etc/haproxy/haproxy.cfg ファイルを編集します。
HAProxy を使ったロードバランサーの設定は 5 つのセクションで構成されます。

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

負荷分散用の HAProxy スケジューリングアルゴリズムは、/etc/haproxy/haproxy.cfg 設定ファイルの backend セクションにある balance パラメーターで編集できます。HAProxy は複数のバックエンドを持つ設定をサポートし、各バックエンドにスケジューリングアルゴリズムを設定できます。
ラウンドロビン (roundrobin)
要求を順番に実サーバーのプールで分配します。このアルゴリズムを使用すると、容量や負荷に関係なく実サーバーはすべて同等に扱われます。このスケジューリングモデルはラウンドロビン DNS と似ていますが、ホストベースではなくネットワークベースであるため、粒度がより細かくなります。さらに、ロードバランサーのラウンドロビンスケジューリングでは、キャッシュされた DNS クエリーが原因で負荷が不均等になることはありません。しかし、HAProxy ではこのスケジューラーを使用するとサーバーの加重値をオンザフライで設定できるため、バックエンドごとにアクティブなサーバーの数が 4095 に制限されます。
静的ラウンドロビン (static-rr)
ラウンドロビンと同様に、要求を順番に実サーバーのプールで分配しますが、サーバーの加重値を動的に設定できません。しかし、サーバーの加重値が静的であるため、アクティブなサーバーの数はバックエンドごとに制限されません。
最小接続 (leastconn)
アクティブな接続の数が少ない実サーバーにより多くの要求を分配します。セッションや接続の長さが異なる動的な環境に適したスケジューラーです。また、このスケジューラーを使用すると管理者は加重値をオンザフライで調整できるため、異なる容量のサーバーが複数ある環境にも適しています。
ソース (source)
要求するソース IP アドレスをハッシュ化し、稼働するすべてのサーバーの加重値で割って要求を取得するサーバーを決定し、要求をサーバーに分配します。すべてのサーバーが稼働中である場合、ソース IP 要求は一貫して同じ実サーバーによって処理されます。稼働中のサーバーの数や加重値に変更があった場合、ハッシュまたは加重値の結果が変わるため、セッションが別のサーバーに移動される可能性があります。
URI (uri)
URI 全体 (または URI の設定可能な部分) をハッシュ化し、稼働するすべてのサーバーの加重値で割ってサーバーへ要求を分配します。アクティブなサーバーがすべて稼働中である場合、宛先 IP 要求は一貫して同じ実サーバーによって処理されます。このスケジューラーを追加設定するには、URI のディレクトリー部分の最初にある文字列の長さでハッシュ化の結果を算出し、URI のディレクトリーの深さ (URI のスラッシュによる) でハッシュ化の結果を算出します。
URL パラメーター (url_param)
ソース URL 要求の特定のパラメーター文字列を検索し、ハッシュの計算を稼働中のすべてのサーバーの加重値で割って、サーバーへの要求を分配します。URL にパラメーターがない場合、スケジューラーはラウンドロビンスケジューリングをデフォルトとして使用します。POST パラメーターを基にした修飾子が使用されたり、ハッシュ化の結果を算出する前に管理者が特定パラメーターの重さに割り当てる最大オクテットの数を基にした待機制限が使用されることがあります。
ヘッダー名 (hdr)
各リソース HTTP 要求の特定のヘッダー名をチェックし、ハッシュの計算を稼働中のサーバーすべての加重値で割って、サーバーへ要求を分配します。ヘッダーがない場合は、スケジューラーはデフォルトでラウンドロビンスケジューリングを使用します。
RDP クッキー (rdp-cookie)
各 TCP 要求に対して RDP クッキーを検索し、ハッシュの計算を稼働中のサーバーすべての加重値で割って、サーバーへ要求を分配します。ヘッダーがない場合、スケジューラーはデフォルトでラウンドロビンスケジューリングを使用します。この方法はセッションの整合性を維持するため、永続化に適しています。