11. スティックテーブルとピア

スティックテーブルの保存内容とピアレプリケーションの宣言

リファレンス

HAProxyのスティックテーブルは、特定の型のキーにさまざまな情報やメトリクスを関連付け、最後の更新から一定期間保持する仕組みです。キーの値を行番号とし、各列が異なる項目を表す、複数列のテーブルの一行と考えることができます。

スティックテーブルは当初、クライアントとサーバーの間でセッションを持続させるため、その対応付けの情報を保存する目的で設計されました。クライアントが接続またはリクエストを送信すると、識別子（送信元アドレス、Cookie、URLパラメーター）でそのクライアントを識別し、選択したサーバーをその識別子に関連付けて、設定可能な期間スティックテーブルに保存します。これにより、同じクライアントからの後続アクセスを、アプリケーションセッションを作成した同じサーバーへ自動的に振り分けられます。

現在のスティックテーブルには、サーバー番号だけでなく、特定のクライアントの活動に関するメトリクス（リクエスト数／レート、接続数／レート、バイト数／レートなど）、任意のイベントカウンター（“General Purpose Counters”、略して"gpc"）、特定の特徴を持つクライアントにラベルを付けるタグ（“General Purpose Tag”、略して"gpt"）も保存できます。

スティックテーブルは、クライアントとサーバーの対応付けに使う"stick"ディレクティブ、メトリクスを集めるためにどのテーブルでどのキーを追跡するかを指定する"track-sc"ルール、さらに、指定したキーを即座に検索して特定のメトリクスやデータを取得する各種サンプル取得関数やコンバーターから参照できます。原則として、テーブルの更新（gpt/gpc/メトリクス）および対応付け情報の検索は、アクセスしたエントリーを更新して有効期限を延長します。一方、サンプル取得関数やコンバーターによる単なる検索は、データを取り出すだけで、エントリーの有効期限を延長しません。

この仕組みを拡張可能にし、HAProxyのリロードやフェイルオーバーにも対応させるため、セクション11.2 の"Peers"機構を通じて、“peers"と呼ぶ他のノードとスティックテーブルの更新を共有できます。ピアとの通信を細かく調整するため、一部のテーブルはピアからの情報を受信するだけにしたり、ピアからの更新を別のテーブルへ転送したりすることもできます。

最後に、スティックテーブルはプロキシセクション（フロントエンド、バックエンド）で"stick-table"キーワードを使って宣言できます。この場合、各セクションに一つだけ定義でき、名前はセクション名になります。また、peersセクションで"table"キーワードにテーブル名を続けて宣言することもでき、この場合は同じ"peers"セクションに複数のスティックテーブルを定義できます。複数のスティックテーブルが必要な場合、通常は、共有する予定であればpeersセクションで宣言するか、“stick-table"定義だけを含むバックエンドセクションを追加で作成する方法を推奨します。

11.1. stick-tableの宣言

プロキシセクション（“frontend”、“backend”、“listen”）と"peers"セクションにおけるスティックテーブルの宣言はよく似ています。違いは、peersセクションでは名前が必須で、“peers"オプションを取らない点です。

“frontend”、“backend”、“listen"セクションの場合：

stick-table type <type> size <size> [expire <expire>] [nopurge] [recv-only] [write-to <wtable>] [srvkey <srvkey>] [store <data_type>]* [brates-factor <factor>] [peers <peersect>]

“peers"セクションの場合：

table <name> type <type> size <size> [expire <expire>] [nopurge] [recv-only] [write-to <wtable>] [srvkey <srvkey>] [store <data_type>]* [brates-factor <factor>]

引数（必須のものを先に記載し、以降はアルファベット順）：

type <type> この必須引数はキーの型を<type>に設定します。通常は単一の語ですが、独自の引数を持つ場合もあります。
- ip この型は避け、“ipv4"や"ipv6"など、より明確な型を使うことを推奨します。バージョン3.2より前は、IPv4を設定する唯一の方法でした。3.2では"ip"は"ipv4"の別名であり、“ipv4"を使うことを推奨します。将来のバージョンでは、“ip"は代わりに"ipv6"に対応するようになります。これは、3.2より前から3.2以降への移行を容易にすることだけを目的としています。
- ipv4 この型で宣言したテーブルは、IPv4アドレスだけを保存します。この形式は非常にコンパクト（エントリーあたり約50バイト）で、ほぼオーバーヘッドなしで非常に高速にエントリーを検索・保存できます。主にクライアントの送信元IPアドレスの保存に使います。
- ipv6 “type ipv6"で宣言したテーブルは、IPv6アドレスだけを保存します。この形式は非常にコンパクト（エントリーあたり約60バイト）で、ほぼオーバーヘッドなしで非常に高速にエントリーを検索・保存できます。主にクライアントの送信元IPアドレスの保存に使います。
- integer “type integer"で宣言したテーブルは32ビット整数を保存します。たとえば、リクエストに含まれるクライアント識別子を表すことができます。
- string [len <len>] “type string"で宣言したテーブルは、最大<len>文字の部分文字列を保存します。パターン抽出機構が提供する文字列が<len>より長ければ、保存前に切り詰めます。マッチングでは、テーブル内の文字列と抽出したパターンの最大<len>文字を比較します。指定しない場合、文字列は自動的に32文字に制限されます。長さを増やすと、メモリ使用量に無視できない影響が出る場合があります。
- binary [len <len>] “type binary"で宣言したテーブルは、<len>バイトのバイナリブロックを保存します。パターン抽出機構が提供するブロックが<len>より大きければ、保存前に切り詰めます。サンプル式が提供するブロックが<len>より短ければ、0で埋めます。指定しない場合、ブロックは自動的に32バイトに制限されます。長さを増やすと、メモリ使用量に無視できない影響が出る場合があります。
size <size> この必須引数は、テーブルに格納できるエントリー数の上限を<size>に設定します。この値はメモリ使用量に直接影響します。上記のキーサイズ、必要に応じて保存するメトリクス、文字列があればそのサイズに加えて、エントリーあたり約50バイトを見込んでください。サイズには、それぞれ2^10、2^20、2^30倍を表す接尾辞"k”、“m”、“g"を使えます。
expire <delay> テーブル内のエントリーについて、最後の作成、’track-sc’による更新、または’stick match’や’stick on’ルールによるマッチからの最大保持期間を定義します。有効期限までの時間<delay>は、各種タイムアウトと同じ標準の時間形式で指定し、デフォルトの単位はミリ秒です。最大期間は24日を少し超える程度です。詳しくはセクション2.5 を参照してください。指定しない場合、セッションは自動的に期限切れになりませんが、テーブルが満杯になると、新しいエントリーの作成時に最も古いエントリーを削除します。有効期限を指定しない場合は、必ず"nopurge"パラメーターを使わないでください。注意：’table_*‘コンバーターは検索を行いますが、’track-sc’を必要としないため、アクセスによる有効期限の更新は行いません。
brates-factor <factor> 入出力バイトレートに適用する係数を指定します。個々のバイトの代わりに、バイトのブロックを数えます。内部ではレートを32ビットカウンターで表すため、期間あたり約40億に制限されます。このパラメーターを使うと、定義した期間でこの4Gの上限を超えるレートを扱えます。係数は0より大きく、1024以下でなければなりません。
nopurge テーブルが満杯になったとき、古いエントリーの削除を拒否することを示します。指定しない場合、HAProxyがエントリーを保存しようとした時点でテーブルが満杯なら、最も古いエントリーをいくつか削除し、新しいエントリーのための空きを作ります。通常はこれが望ましい動作です。特定の状況では、古いエントリーを削除する代わりに、新しいエントリーを拒否したい場合があります。たとえば、保存するデータ量がハードウェアの限界を大きく超え、接続済みのクライアントを拒否するより、新しいクライアントにアクセスを提供しないほうがよい場合です。このパラメーターを使う場合は、“expire"パラメーターを必ず適切に設定してください（上記参照）。
recv-only このテーブルを更新には使わず、関心のあるリモートピアからデータを取得する目的だけで使うことを示します。このキーワードを使うと、“conn_cur"などのローカル専用の値も取得できます。これらはローカルピアがテーブルに加えるローカル更新と競合するため、デフォルトでは学習しません。このオプションは、テーブルを更新する追跡ルールや方式に関与しないテーブル、つまり、情報の取得にだけ使うリモートテーブルにのみ意味があります。
peers <peersect> 作成、変更、更新したエントリーは、同期のためにセクション<peersect>のピアへ送信します。また、このセクションのピアから学習したキーも、テーブルに挿入または更新します。さらに起動時には、このセクションで"local peer"として指定した、古いプロセスのインスタンスからエントリーの学習を試みることがあります。
srvkey <srvkey> スティックテーブル内で各サーバーをどのように識別するかを指定します。有効な値は"name"と"addr"です。“name"の場合は、サーバーの<name>引数（テンプレートで生成される場合もあります）を使います。“addr"の場合は、ポートを含む現在のネットワークアドレスでサーバーを識別します。“addr"は、ピア間で共有するスティックテーブルのサーバーアドレスをサービスディスカバリーで生成し、ある対応付けトークンに対してピア間で一貫して同じホストを使いたい場合に、特に便利です。
store <data_type> スティックテーブルに追加情報を保存するために使います。ACLで利用して、スティックテーブルにマッチするクライアントの活動に関する各種条件を制御できます。ここで項目を指定するごとに、追加データを収めるため、各エントリーのサイズが増えます。一つのエントリーに複数のデータ型を保存できます。“store"キーワードの後にカンマ区切りで複数のデータ型を指定するか、“store"キーワードと一つ以上のデータ型を繰り返し指定できます。自動的に検出して有効にする"server_id"型を除き、保存するデータ型はすべて明示的に宣言しなければなりません。ACLが保存していないデータ型を参照した場合、そのACLは単にマッチしません。一部のデータ型には引数が必要で、型の直後に丸括弧で囲んで渡さなければなりません。対応するデータ型と引数は以下を参照してください。
write-to <wtable> ピアからの更新を元のテーブルに加えて書き込む、別のスティックテーブルの名前を指定します。<wtable>は、定義中のテーブルと同じ型で、キーの長さも同じでなければならず、元のテーブル自身を転送先にはできません。元のテーブルがピア経由でエントリーの更新を受け取るたびに、HAProxyは対応する<wtable>のエントリーを更新しようとします。エントリーがなければ作成し、すでにあれば値とタイマーを更新します。リモートテーブルで処理済みの値が、ローカルの転送先テーブルの算術演算に干渉しないように、server_id、server_key、gptなど、算術演算に関与しない型だけを<wtable>に書き込みます（つまり、共有する累積カウンターが無限に増えることを防ぎます）。このオプションの一般的な用途は、ピアクラスター構成でサーバーへの固定のためのstickルールを使えるようにすることです。マッチするキーをリモートテーブルから学習できるためです。

“store"ディレクティブでエントリーに関連付けられるデータ型を以下に示します。多数のデータ型を保存すると、必要なメモリが大きくなる場合があることを忘れないでください。実際、以下の指標をすべて各エントリーに保存すると、エントリーあたり数百バイト、100万エントリーのテーブルでは数百MBが必要になる可能性があります。このため、各型について、引数の後の角括弧内におおよその保存サイズを示します。

引数：

bytes_in_cnt [8バイト] クライアントからサーバーへのバイト数です。このエントリーにマッチしたクライアントから受信した累積バイト数を数える、正の64ビット整数です。ヘッダーも含みます。写真や動画サーバーでアップロード機能の悪用を制限するために使えます。データがhaproxyへ入る時点で測定するため、カウントは圧縮の影響を受けません。
bytes_in_rate(<period>) [12バイト] クライアントからサーバーへのバイトレートカウンターです。平均を測定する期間の長さをミリ秒で表す、整数パラメーター<period>を取ります。その期間の平均受信バイトレートを、期間あたりのバイト数で報告します。大量のデータを高速にアップロードするユーザーの検出に使えます。警告：大規模なアップロードでは、終了時にアップロード量を一度にカウントする場合があり、平均転送速度が滑らかにならず、急上昇することがあります。“option contstats"である程度平滑化できますが、完全ではありません。より公平に扱うにはbyte_in_cntの使用を推奨します。
bytes_out_cnt [8バイト] サーバーからクライアントへのバイト数です。このエントリーにマッチしたクライアントへ送信した累積バイト数を数える、正の64ビット整数です。ヘッダーも含みます。サイト全体を吸い上げるボットの悪用を制限するために使えます。データがhaproxyへ入る時点で測定するため、カウントは圧縮の影響を受けません。
bytes_out_rate(<period>) [12バイト] サーバーからクライアントへのバイトレートカウンターです。平均を測定する期間の長さをミリ秒で表す、整数パラメーター<period>を取ります。その期間の平均送信バイトレートを、期間あたりのバイト数で報告します。大量のデータを高速にダウンロードするユーザーの検出に使えます。警告：大規模な転送では、終了時に転送量を一度にカウントする場合があり、平均転送速度が滑らかにならず、急上昇することがあります。“option contstats"である程度平滑化できますが、まだ完全ではありません。より公平に扱うにはbyte_out_cntの使用を推奨します。
conn_cnt [4バイト] 接続数です。このエントリーにマッチしたクライアントから受信した接続の総数を数える、正の32ビット整数です。接続が受け入れられたことを意味するのではなく、受信したことだけを示します。
conn_cur [4バイト] 現在の接続数です。このエントリーの同時接続数を保存する、正の32ビット整数です。着信接続がエントリーにマッチすると増え、接続が終了すると減ります。これにより、エントリーの正確な同時接続数をいつでも把握できます。ローカルの数を無視すると意味のない値になるため、この型はデフォルトでは他のピアから学習しません。ただし、recv-onlyと組み合わせると、ピアが観測した同時接続数を学習できます。
conn_rate(<period>) [12バイト] 接続の頻度カウンターです。平均を測定する期間の長さをミリ秒で表す、整数パラメーター<period>を取ります。その期間の平均着信接続レートを、期間あたりの接続数で報告します。結果は整数で、ACLでマッチできます。接続を受け入れたか拒否したかは、測定に影響しません。
glitch_cnt [4バイト] フロント側の異常動作数です。フロント接続で報告された異常動作の累積数を数える、正の32ビット整数です。異常動作とは、プロトコルの観点から見て珍しい、または予期しないクライアントの動作であり、大きな欠陥を持つクライアント、場合によっては攻撃者を示す可能性があります。このため、このカウンターは、そのような状況でどう対応するかを決める助けになります。
glitch_rate(<period>) [12バイト] 異常動作の頻度カウンターです。平均を測定する期間の長さをミリ秒で表す、整数パラメーター<period>を取ります。その期間のフロント側の平均異常動作レートを報告します。HAProxyがそのように判定したものについて、プロトコルの観点から珍しい、または予期しない動作をする、不具合のあるクライアントや攻撃者候補の検出に使えます。
gpc(<nb>) [4 * <nb>バイト] <nb>個の汎用カウンター要素の配列です。正の32ビット整数の配列で、何でも数えることができます。多くの場合、エントリーの増分カウンターとして使い、たとえば上限に達したことを記録して何らかのアクションを起動します。ピアの更新メッセージをバッファー内に収められるよう、配列はgpc0からgpc99までの最大100要素に制限されます。いずれかを更新するたびにすべてのデータ／カウンターを送るため、カウンターが多いと、ピアプロトコルのデータサイズとトラフィック負荷が増えることを考慮してください。このdata_typeを使うと、同じテーブルで従来のdata_types ‘gpc0’と’gpc1’は使えません。‘gpc’配列のdata_typeでは、‘gpc0’と’gpc1’に関するすべてのサンプル取得関数とアクションが、この配列の先頭二要素に適用されます。
gpc_rate(<nb>,<period>) [12 * <nb>バイト] ある期間における汎用カウンターの増分レートの配列です。要素は正の32ビット整数で、任意の用途に使えます。<gpc>と同じくイベントを数えますが、累積数を保持する代わりに、カウンターが増加するレートを保持します。主に、特定のイベント（特定のURLへのリクエストなど）の発生頻度を測定します。ピアの更新メッセージをバッファー内に収められるよう、配列は最大100要素に制限されます。gpc_rate(100,<period>)でgpc0_rateからgpc99_rateまでを保存できます。配列は1要素未満にできません。gpc0_rateだけを保存するにはgpc_rate(1,<period>)を使います。いずれかを更新するたびにすべてのデータ／カウンターを送るため、カウンターが多いと、ピアプロトコルのデータサイズとトラフィック負荷が増えることを考慮してください。このdata_typeを使うと、同じテーブルで従来のdata_types ‘gpc0_rate’と’gpc1_rate’は使えません。‘gpc_rate’配列のdata_typeでは、‘gpc0’と’gpc1’に関するすべての取得関数とアクションが、この配列の先頭二要素に適用されます。
gpc0 [4バイト] 最初の汎用カウンターです。正の32ビット整数で、任意の用途に使えます。主にエントリーへ特別なタグを付け、たとえば、今後のマッチングでも把握しておく必要がある特定の動作を検出したことを記録します。
gpc0_rate(<period>) [12バイト] ある期間における最初の汎用カウンターの増分レートです。正の32ビット整数で、任意の用途に使えます。<gpc0>と同じくイベントを数えますが、累積数を保持する代わりに、カウンターが増加するレートを保持します。主に、特定のイベント（特定のURLへのリクエストなど）の発生頻度を測定します。
gpc1 [4バイト] 二番目の汎用カウンターです。正の32ビット整数で、任意の用途に使えます。主にエントリーへ特別なタグを付け、たとえば、今後のマッチングでも把握しておく必要がある特定の動作を検出したことを記録します。
gpc1_rate(<period>) [12バイト] ある期間における二番目の汎用カウンターの増分レートです。正の32ビット整数で、任意の用途に使えます。<gpc1>と同じくイベントを数えますが、累積数を保持する代わりに、カウンターが増加するレートを保持します。主に、特定のイベント（特定のURLへのリクエストなど）の発生頻度を測定します。
gpt(<nb>) [4 * <nb>バイト] <nb>個の汎用タグ要素の配列です。正の32ビット整数の配列で、任意の用途に使えます。主にエントリーへ特別なタグを付け、たとえば、今後のマッチングでも把握しておく必要がある特定の動作を検出したことを記録します。ピアの更新メッセージをバッファー内に収められるよう、配列は最大100要素に制限されます。gpt(100)でgpt0からgpt99までを保存できます。配列は1要素未満にできません。gpt0タグだけを保存するにはgpt(1)を使います。いずれかを更新するたびにすべてのデータ／カウンターを送るため、カウンターが多いと、ピアプロトコルのデータサイズとトラフィック負荷が増えることを考慮してください。このdata_typeを使うと、同じテーブルで従来のdata_type ‘gpt0’は使えません。‘gpt’配列のdata_typeでは、‘gpt0’に関するすべての取得関数とアクションが、この配列の先頭要素に適用されます。
gpt0 [4バイト] 最初の汎用タグです。正の32ビット整数で、任意の用途に使えます。主にエントリーへ特別なタグを付け、たとえば、今後のマッチングでも把握しておく必要がある特定の動作を検出したことを記録します。
http_req_cnt [4バイト] HTTPリクエスト数です。このエントリーにマッチしたクライアントから受信したHTTPリクエストの総数を数える、正の32ビット整数です。リクエストが有効かどうかは関係ありません。クライアント側でkeep-aliveを使う場合は、セッションとは異なる点に注意してください。
http_req_rate(<period>) [12バイト] リクエストの頻度カウンターです。平均を測定する期間の長さをミリ秒で表す、整数パラメーター<period>を取ります。その期間の平均HTTPリクエストレートを、期間あたりのリクエスト数で報告します。結果は整数で、ACLでマッチできます。リクエストが有効かどうかは関係ありません。クライアント側でkeep-aliveを使う場合は、セッションとは異なる点に注意してください。
http_err_cnt [4バイト] HTTPリクエストのエラー数です。このエントリーにマッチしたクライアントに起因するHTTPリクエストのエラー総数を数える、正の32ビット整数です。不正または切り詰められたリクエスト、拒否またはtarpitしたリクエスト、認証失敗をエラーとして数えます。サーバーが4xxを返した場合も、クライアントが引き起こしたエラー（脆弱性スキャンなど）なので、そのリクエストをエラーとして数えます。
http_err_rate(<period>) [12バイト] HTTPリクエストの頻度カウンターです。平均を測定する期間の長さをミリ秒で表す、整数パラメーター<period>を取ります。その期間の平均HTTPリクエストエラーレートを、期間あたりのリクエスト数で報告します（何をエラーと数えるかは上記のhttp_err_cntを参照）。結果は整数で、ACLでマッチできます。
http_fail_cnt [4バイト] HTTPレスポンスの失敗数です。このエントリーにマッチしたサーバーに起因するHTTPレスポンスの失敗総数を数える、正の32ビット整数です。不正または切り詰められたレスポンス、および501と505を除くすべての5xxレスポンスをエラーとして数えます。パスやURIと組み合わせ、サービスの障害を検出する用途を想定しています。
http_fail_rate(<period>) [12バイト] HTTPレスポンスの失敗頻度カウンターです。平均を測定する期間の長さをミリ秒で表す、整数パラメーター<period>を取ります。その期間の平均HTTPレスポンス失敗レートを、期間あたりのリクエスト数で報告します（何を失敗と数えるかは上記のhttp_fail_cntを参照）。結果は整数で、ACLでマッチできます。
server_id [4バイト] リクエストを割り当てたサーバーの数値IDを保持する整数です。“stick match”、“stick store”、“stick on"ルールで使います。参照すると自動的に有効になります。学習した情報に基づく対応付けには制約があり、たとえば再起動時に情報を転送するようピアを適切に設定しない限り（設定を推奨）、学習した関連付けがすべて再起動で失われることを理解しておく必要があります。一般には、他の対応付けの仕組みを補うには有用ですが、常に唯一の仕組みとして適しているわけではありません。
sess_cnt [4バイト] セッション数です。このエントリーにマッチしたクライアントから受信したセッションの総数を数える、正の32ビット整数です。セッションとは、レイヤー4のルール（“tcp-request connection”）で受け入れられた接続です。
sess_rate(<period>) [12バイト] セッションの頻度カウンターです。平均を測定する期間の長さをミリ秒で表す、整数パラメーター<period>を取ります。その期間の平均着信セッションレートを、期間あたりのセッション数で報告します。結果は整数で、ACLでマッチできます。

例：

# Keep track of counters of up to 1 million IP addresses over 5 minutes
# and store a general purpose counter and the average connection rate
# computed over a sliding window of 30 seconds.
stick-table type ip size 1m expire 5m store gpc0,conn_rate(30s)

関連項目：“stick match”、“stick on”、“stick store-request”、“track-sc”、時間形式についてはセクション2.5 、ピアについてはセクション11.2 、帯域制限についてはセクション9.7 、ACLについてはセクション7 。

11.2. ピアの宣言

スティックテーブル内の任意のデータ型のエントリーを、TCP接続を通じて、複数のHAProxyインスタンス間でマルチマスター方式で伝播できます。各インスタンスは、ローカルでの更新と挿入をリモートピアへ送ります。送られた値は、集約せずにリモートの値を上書きします。

例外は"conn_cur"データ型です。これはローカルの値を反映するものなので、デフォルトではピアから学習しません。以前のバージョンではデフォルトで同期していましたが、active-active構成では負の値になり、リロードやactive-passiveの切り替えでは値が増え続けることが知られていました。ローカルに存在する以上の接続数をローカルの値が反映してしまうためです。ただし、ピアからこの値を学習することが有用な構成もあります。たとえば、テーブルを書き込み操作や更新には使わず、データの学習や監視にだけ使う受動的なリモートテーブルの場合です。これを実現するには、テーブルの宣言に"recv-only"キーワードを追加します。いずれの場合も、監視システムが観測できるよう、“conn_cur"情報は常に送信します。

中断した交換は自動的に検出され、最後に確認した地点から再開します。また、ソフト再起動時には、新しいプロセスが他のピアへの接続を試みる前に、古いプロセスがこのTCP接続で新しいプロセスへ接続し、すべてのエントリーを送ります。これにより、リロード時のレプリケーションは非常に高速になり、大きなテーブルでも通常は一秒未満で完了します。

リモートでのサーバー識別にはサーバーIDを使うため、設定を同様にするか、少なくとも、すべての参加者で各サーバーに同じIDを強制することが重要です。

peers <peersect>

peers <peersect>

<peersect>という名前の新しいピア一覧を作成します。一つ以上のスティックテーブルから参照される独立したセクションです。

bind [<address>]:port [param*]

bind [<address>]:port [param*]
bind /<path> [param*]

この"peers"セクションのローカルピアのバインドパラメーターを定義します。同じ"peers"セクション内で、この行と"peer"行を併用することはできません。

disabled

disabled

peersセクションを無効にします。このセクションに関するリッスンと同期の両方を無効にします。すべての"peers"参照をコメントアウトせずに、スティックテーブルの同期を無効にするために用意されています。

default-bind [param*]

default-bind [param*]

アドレスを除く、ローカルピアのバインドパラメーターを定義します。

default-server [param*]

default-server [param*]

“peers"セクションのサーバーのデフォルトオプションを変更します。

引数：

<param*>  このサーバーのパラメーター一覧です。"default-server"キーワードは
          多数のオプションを受け付け、専用のセクションで詳しく説明しています。
          peersセクションでは、"default-server"行のトランスポートパラメーターを
          サポートします。詳細はセクション5を、一部の制限についてはこの
          セクションの下にある"server"キーワードを参照してください。

関連項目：“server”、およびサーバーオプションについてのセクション5 。

enabled

enabled

“disabled"キーワードで無効にしたpeersセクションを、再び有効にします。

log <target> [len <length>] [format <format>] [sample <ranges>:<sample_size>]

log <target> [len <length>] [format <format>] [sample <ranges>:<sample_size>]
    <facility> [<level> [<minlevel>]]

“peers"セクションは、プロキシと同じ"log"キーワードをサポートし、“peers"リスナーについての情報をログに記録します。詳しくは、プロキシの"log"オプションを参照してください。

peer <peername> [<address>]:port [param*]

peer <peername> [<address>]:port [param*]
peer <peername> /<path> [param*]

peersセクション内にピアを定義します。<peername>をローカルピア名（デフォルトはホスト名、またはコマンドラインの”-L"オプションやglobal設定の"localpeer"で強制した名前）にすると、HAProxyは指定アドレスでリモートピアからの着信接続を待ち受けます。それ以外の場合、アドレスはリモートピアに参加するための接続先を定義し、<peername>はサーバー側でリモートピアを識別・検証するため、プロトコルレベルで使われます。

ソフト再起動時、古いインスタンスはローカルピアのアドレスを使って新しいインスタンスに接続し、完全なレプリケーション（学習させる処理）を開始します。

すべてのピアでまったく同じpeers宣言を使い、ローカルピア名の変更にはコマンドライン引数”-L"またはglobal設定の"localpeer"だけを使うことを強く推奨します。これにより、すべてのピアで一貫した設定ファイルを維持しやすくなります。

アドレスパラメーターで環境変数を参照したい場合は、環境変数についてのセクション2.3 を参照してください。

注意：“peer"キーワードは、透過的に"server"キーワードへ置き換えられます（以下の"server"キーワードの説明を参照）。

server <peername> [<address>:<port>] [param*]

server <peername> [<address>:<port>] [param*]
server <peername> [/<path>] [param*]

前述のとおり、“peer"キーワードを"server"キーワードへ置き換えると、5.2にあるトランスポート設定関連のすべての"server"パラメーターを使えます。対象のピアがローカルである場合、アドレスパラメーターを記述してはいけません。アドレスは"bind"行に記述しなければなりません（この"peers"セクションの"bind"キーワードを参照）。

多くの"server"パラメーターは"peers"セクションには関係しません。ピアは本質的に動的なホスト名解決やヘルスチェックをサポートしないため、“init_addr”、“resolvers”、“check”、“agent-check”、“track"などのパラメーターには対応していません。同様に、負荷分散や対応付けもないため、“weight"や"cookie"などのパラメーターは効果を持ちません。

例：

 # The old way.
 peers mypeers
     peer haproxy1 192.168.0.1:1024
     peer haproxy2 192.168.0.2:1024
     peer haproxy3 10.2.0.1:1024

 backend mybackend
     mode tcp
     balance roundrobin
     stick-table type ip size 20k peers mypeers
     stick on src

     server srv1 192.168.0.30:80
     server srv2 192.168.0.31:80

例：
  peers mypeers
     bind 192.168.0.1:1024 ssl crt mycerts/pem
     default-server ssl verify none
     server haproxy1 #local peer
     server haproxy2 192.168.0.2:1024
     server haproxy3 10.2.0.1:1024

shards <shards>

一部の構成では、“peers"セクションで宣言した各ピアへスティックテーブルの全内容を送る代わりに、一部のピアへ内容を分散させたい場合があります。この場合、“shards"はスティックテーブル内容の分散に参加するピア数を指定します。サーバーパラメーター"shard"も参照してください。

table <tablename> type {ip | integer | string [len <length>] | binary [len <length>]}

table <tablename> type {ip | integer | string [len <length>] | binary [len <length>]}

  size `<size>` [expire `<expire>`] [write-to `<wtable>`] [nopurge] [store `<data_type>`]*
  [recv-only]

現在のセクションにスティックテーブルを設定します。この行は、他のセクションの"stick-table"キーワードとまったく同じように解析しますが、ここでは"peers"引数が不要で、テーブルを指定する必須の先頭パラメーターが追加されます。他のセクションとは異なり、“peers"セクションには複数の"table"行を記述できます（上記セクション11.1 にある"table"と"stick-table"キーワードの完全な定義も参照）。

また、異なる"peers"セクションで同じスティックテーブル名が衝突しないよう、“peers"セクションには独自のスティックテーブル名前空間がある点にも注意してください。内部では、スティックテーブル名の前に"peers"セクション名と’/‘を付けて処理します。設定ファイルの別の場所から、“peers"セクションで宣言したテーブルを参照する場合は、次のように、接頭辞を付けた名前を使わなければなりません。

peers mypeers
    peer A ...
    peer B ...
    table t1 ...

frontend fe1
    tcp-request content track-sc0 src table mypeers/t1

CLIからスティックテーブルを参照する場合にも、接頭辞を付けた名前を使わなければなりません。

“peers"プロトコルでは、同じセクションに属する"peers"だけが相互に通信できるため、このような区別は不要です。複数の"peers"セクションで、同じ名前のスティックテーブルを宣言できます。ネットワーク上では、この短いスティックテーブル名を送信します。ただし、バックエンドとして宣言したテーブルと"peers"セクションで宣言したテーブルの名前の衝突を避けるため、接頭辞として’/‘だけを付けます。次の例は変わった構成ですが、サポートされています。

peers mypeers
    peer A ...
    peer B ...
    table t1 type string size 10m store gpc0

backend t1
    stick-table type string size 10m store gpc0 peers mypeers

ここでは、“mypeers"セクションで宣言した"t1"テーブルのグローバル名は"mypeers/t1"です。バックエンドとして宣言した"t1"テーブルのグローバル名は"t1"です。一方、ピアプロトコルのレベルでは、前者の名前は”/t1”、後者はやはり"t1"です。

コメントを読み込むには JavaScript が必要です。 GitHub Discussions を表示。