web-dev-qa-db-ja.com

負荷分散（HAProxyまたはその他）-スティッキーセッション

私はアプリを複数のサーバーにスケールアウトする作業を行っています。1つの要件は、クライアントが常に同じサーバーと通信していることです（サーバー間で効率的にバウンスするには、ライブデータが多すぎます）。

私の現在のセットアップは小さなサーバークラスターです（Linodeを使用）。 「バランスソース」を使用してHAProxyを実行しているフロントエンドノードがあるため、IPは常に同じノードを指します。

「バランスソース」があまり均等に分布していないことに気づきました。私の現在のテストセットアップ（2つのバックエンドサーバー）では、80〜100のソースIPのサンプルサイズを使用する場合、1つのサーバーに3〜4倍の接続があることがよくあります。

よりバランスの取れた配布を実現する方法はありますか？明らかにスティッキーセッションは「完璧な」バランスを禁止しますが、25/75分割よりも40/60分割の方が望ましいでしょう。

load-balancingcluster-computinghaproxy
18
Michael Marsee

HAProxyは、Cookieの変更または挿入をサポートして、cookieパラメーターでセッションの永続性を提供します。

バックエンドセクションまたはリッスンセクションのいずれかに、以下を追加します。

cookie COOKIENAME prefix

この例では、サーバーの名前をCOOKIENAMEというCookieに追加することにより、既存のCookieを変更します。クライアントにはserver1~someotherdataのようなものが表示されますが、アプリケーションにはsomeotherdataの部分しか表示されません。したがって、これを既存のCookieで使用できます。さらに、この方法では、そのCookieが存在する場合にのみセッションの永続性を適用できます。つまり、サイトの静的な部分の周囲で人々のバランスを均等にし、必要な場合にのみスティッキネスを適用できますが、そのCookie名をセッションに追加します。

また、サーバーに名前を付けて、サーバーの行が次のようになるようにします。

server server1 1.2.3.4 cookie server1

詳細は HAProxy構成ガイド にあります。また、appsession構成パラメーターも使用できるようです。

これを行ったら、リストから独自のバランス方法を選択できます。私はroundrobinを使用する傾向がありますが、スティッキーセッションを考慮に入れると、leastconnの方がバランスが良くなる可能性があります。

参照セクションを見つけやすくするためのドキュメントの詳細：

cookie <name> [ rewrite | insert | prefix ] [ indirect ] [ nocache ]
              [ postonly ] [ preserve ] [ domain <domain> ]*
              [ maxidle <idle> ] [ maxlife <life> ]
  Enable cookie-based persistence in a backend.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
25
Richard Benson

HA-Proxyでバランシングアルゴリズムを調整できますが、いくつか利用可能なものがあります。例えばのようにラウンドロビンまたはleastconn。

ただし、一般的に、コンテンツが提供されるユーザーのドメインに応じてバランスを調整する必要があります。ほとんどの場合、経験的なテストを行い、調査結果に従って決定を繰り返す必要があります。

0
fyr