このブログの最初の部分では、E2Eクラウドの仮想ロードバランサーノードにHAProxyを設定しました。また、ラウンドロビンポリシーを使用してリクエストをバックエンドWebサーバーにルーティングするようにHAProxyを構成しました。
このブログのこの2番目の最後の部分では、ほとんどのWebサイトに必要ないくつかの高度な構成設定（セッションのスティッキ性、SSLを使用したWebサイトへの安全なアクセス）について説明します。ただし、その前に、ACLを使用して、単一のHAProxyインスタンスが多くのWebアプリケーションを含む大規模なWebサイトにどのように対応できるかを示します。その間に、加重ラウンドロビンポリシーなど、いくつかの追加の構成オプションを提示し、本番環境での展開に関するその他の重要な考慮事項へのポインターで締めくくります。
複数のWebアプリケーション用のロードバランサーの設定
多くの大規模なWebサイトは、Webサーバーの複数のクラスターで構成されており、各クラスターは異なるWebアプリケーションをホストしています。たとえば、メインコンテンツを含むWebサイトと、娯楽のためのWebサイトが存在する場合があります。 HAProxyは、URLパターンとアクセス制御リストに基づいて適切なクラスターにリクエストをルーティングすることができます （ACL）。
この機能を説明するために、最初にE2Eクラウド上に「webserver3」と「webserver4」という名前の2つの新しいWebサーバーノードを作成します。いつものように、ApacheWebサーバーとPHPパッケージを2つの新しいノードにインストールします。次に、2番目のPHPアプリケーションをURL「/fun/films.php」でこれら2つの新しく追加されたノードのみにデプロイします。 。 （2番目のアプリケーションはセッションの永続性を使用し、その機能については次のセクションで説明します。）
つまり、ダッシュボードには次のノード（4つのWebサーバーとロードバランサー）が表示されます。
図1：複数のWebアプリケーション用のWebサーバー
したがって、HAProxyはURL「/fun/films.php」に対するクライアントリクエストをノード「webserver3」と「webserver4」のいずれかにのみルーティングする必要があります。そうしないと、リクエストをまったく処理できません。この要件を満たすために、HAProxy構成（/etc/haproxy/haproxy.cfg）を変更し、2つの新しいWebサーバーノードのみで構成されるもう1つのバックエンド（「films」という名前）を作成します。これは、「サイト」という名前の既存のバックエンドに追加されます。
図2：新しいアプリケーションのバックエンド構成
次に、既存のフロントエンド構成で、以下に示すようにACLを導入します。これは、「/ fun」で始まるURLパスはすべて「films」という名前のバックエンドにルーティングされるのに対し、デフォルトでは、他のすべてのリクエストは「site」という名前の（既存の）バックエンド（ノードで構成される）に到達することを意味します「websrv1」および「websrv2」のみ）。
図3：ACLを使用したフロントエンド構成
図4：ACLを使用したHAProxyの負荷分散
詳細設定
加重ラウンドロビンポリシー ：ACLを変更する際に、ウェイトを導入しました 各サーバーに。本番環境では、サーバーごとに計算能力が異なる場合があるため、重みを使用すると、HAProxyはより強力なサーバーにさらに多くのリクエストをルーティングできます。 （この場合、すべてのWebサーバーノードは類似しており、すべての重みは同じですが、これをテンプレートとして使用し、別のシナリオで微調整することができます。）
サーバーあたりの最大接続数 ：次に、バックエンドサーバーレベルで「maxconn」パラメータも使用しました 、これにより、各サーバーは接続数をその処理能力に適した数に制限できます。グローバルな「maxconn」は、このパラメータのサーバーレベルの値の合計よりも大きくする必要があります（スケーラビリティのためにWebサーバーノードを追加する余地があります）。
セッションの粘着性
新しいPHPアプリケーションはたまたまPHPセッションを使用しています。クライアントがこのアプリケーションにアクセスするたびに、PHPセッションに追加されるお気に入りの映画の名前を（「fav」という名前のHTTP GETパラメーターを介して）提供します。サーバーは、これまでに収集されたお気に入りの映画（各クライアントに固有）のリストで応答します。
- <？php
- session_start（）;
- $ fav =$ _GET [‘fav’];
- if（isset（$ _SESSION [‘favourites’]））{
- $ _SESSION [‘favourites’]。=‘、‘;
- $ _SESSION [‘favourites’]。=$ fav;
- } else {
- $ _SESSION [‘favourites’] =$ fav;
- }
- $ msg =‘私のお気に入りの映画：‘。 $ _SESSION [‘favourites’];
- ？>
私のお気に入りの映画 - <？php
- echo $ msg;
- ？>
PHPセッションはWebサーバーインスタンスに対してローカルである可能性があります（セッションの永続性またはレプリケーションが有効になっていない場合）。そのため、同じクライアントが異なる時間に異なるバックエンドWebサーバーインスタンスにランダムにルーティングされる場合、一連の要求を行うと、そのセッションデータが予測不能になる可能性があります。ただし、クライアントは「スティック」を強制される可能性があります ‘セッションの期間内に単一のWebサーバーインスタンスに。
HAProxyでこれを設定する1つの方法は、関連するバックエンド構成（この場合は「films」）に「appsession」パラメーターを導入することです。さまざまな種類のアプリケーションが、セッション管理にさまざまなHTTPCookieを使用します。 PHPアプリケーションの場合、このCookieの名前は「PHPSESSID」です。 「appsession」を設定することにより、HAProxyは単一のWebサーバーを各に関連付けます 「PHPSESSID」（このセッションが作成されたもの）。同じセッションIDを含む繰り返しのクライアントリクエストを、稼働中またはセッションがタイムアウトしている限り同じウェブサーバーにルーティングします。 。
- appsession PHPSESSIDlen32タイムアウト1時間
もちろん、そのWebサーバーが何らかの理由で利用できなくなった場合、HAProxyは同じセッションIDを持つリクエストを別のアクティブなサーバーインスタンスに自由にルーティングする必要があります。これは、HAProxy構成ファイルの「defaults」セクションに「redispatch」オプションを追加することで確実になります。
- オプションの再発送
テスト
これで、ACLとセッションスティッキネスの両方をテストできます。ロードバランサーノードでHAProxyログを調整できます：
- tail -f /var/log/haproxy.log
また、ノード「webserver3」と「webserver4」のそれぞれでWebサーバーアクセスログを追跡します。
1。 tail -f /var/log/apache2/access.log
2つの異なるクライアントマシンから、ブラウザから次のURLにリクエストを送信します：http：//
リクエストごとに、「fav」という名前のクエリパラメータに異なる値を設定できます。
最初のクライアントから、次の連続したリクエストを送信します：
- http：//
/fun/films.php?fav=avengers - http：//
/fun/films.php?fav=jurassicworld
最初のクライアントのブラウザウィンドウに次のように表示されます：
図5：1つのクライアントセッション
2番目のクライアントから、次の連続したリクエストを送信します：
- http：//
/fun/films.php?fav=race3 - http：//
/fun/films.php?fav=gold
2番目のクライアントのブラウザウィンドウに次のように表示されます：
図6：別のクライアントセッション
各クライアントブラウザに表示される応答から、いずれの場合もセッションが正しく維持されていることは明らかです。 Firefoxでは、WebコンソールからPHPSESSID値を検査することもできます。
HAProxyログとWebサーバーログから次の2つの観察を行うことができます：
- URLパターンが「/fun」のこれらのリクエストは、「films」という名前のバックエンドにのみルーティングされます（ACLポリシー）
- 同じクライアントIPアドレスからのリクエストが同じウェブサーバーノードに届きます（セッションスティッキネス）
図7：スティッキーセッションを使用したHAProxyログ
図8：スティッキーセッションを使用したwebserver3ノードのアクセスログ
図9：スティッキーセッションを使用したwebserver4ノードのアクセスログ
セキュリティ：SSLターミネーション
最後に取り上げたい重要な構成は、セキュリティに関連しています。 Apache WebサーバーはHTTPSをサポートするように構成できますが、フロントエンドにHAProxyがインストールされている場合、クライアント要求は最初にロードバランサーに送信されます。
したがって、HTTPSをサポートするようにHAProxyを設定することをお勧めします。これは4段階のプロセスです：
- 当社のWebサイトのSSL証明書を取得します。実験目的で、 opensslを使用してhaproxy.pemという名前の自己署名証明書を作成しました
- フロントエンドをHTTPSポート（デフォルトでは443）にバインドし、SSL証明書をこのフロントエンドに割り当てます
- HAProxyを有効にして、HTTP経由で送信されたクライアントリクエストをHTTPSポートにリダイレクトします
- 各でHTTPリクエストに必要なヘッダーを追加または設定します 構成されたバックエンドの
上記の最初の3つの手順は、フロントエンドレベルで実装されます。 （フロントエンドの名前を「httptraffic」ではなく「alltraffic」に変更しました。）
図10：SSLのフロントエンド構成
上記の4番目のステップは、各で実装されます。 バックエンド：
図11：SSLのバックエンド構成
通常、X-Forward-PortヘッダーとX-Forward-Protoヘッダーは、HTTPリクエストとHTTPSリクエストの両方が可能な場合に、アプリケーションがURLを正しく構築するのに役立ちます。
ロードバランサーノードでSSLを終了すると、このノードで処理オーバーヘッドが発生します（暗号化された要求をバックエンドにリレーする場合と比較して）。使用されている基本的な暗号化アルゴリズムに関連するパラメーターがあります。値を大きくすると、HAProxyノードの処理オーバーヘッドが増加します。 HAProxy設定の「グローバル」セクションで設定できます：
- tune.ssl.default-dh-param 2048
したがって、SSLで暗号化されたリクエストはロードバランサーで終了し、ロードバランサーは暗号化されていないHTTPリクエストをバックエンドウェブサーバーにルーティングします。
図12：SSLターミネーション
ファイアウォール設定
次のコマンドを実行して、仮想ロードバランサーノード（CentOSで実行）のポート443を開く必要があります：
- iptables -A INPUT -i eth0 -p tcp –dport 443 -m state –state NEW、ESTABLISHED -j ACCEPT
- systemctl restart iptables
テスト
ここで、安全でないHTTP をポイントして、ブラウザ（Firefox）からPHPGreeterアプリケーションにアクセスしようとします。 URL：
http：//
それでも、Firefoxはセキュリティ例外を追加するように要求し、クライアントが安全なHTTPSURLに転送されていることを示します。 。これは、ブラウザ自体のアドレスバーにも表示されます。
図13：SSLを介したWebアプリケーションへのアクセス
マシンイメージの作成と監視
ヒント ：仮想ロードバランサーインスタンスの構成に多くの労力が費やされました。このノードのマシンイメージを保存して、将来、テンプレートとして使用して同様のロードバランサーインスタンスを作成できるようにすることができます。 E2Eクラウドでは、これは最初にHAProxyノードをシャットダウンし、次にダッシュボードからこのノードのイメージを保存することで実現できます。
図14：HAProxyマシンイメージの保存
図15：HAProxyノードからのマシンイメージの作成
オプションで、Webサーバーインスタンスのマシンイメージも保存できます。
Zabbixを使用したモニタリング ：HAProxyノードは、E2Eクラウド上の他の仮想ノードと同様に、Zabbixを使用して監視できます。この機能を利用する必要があります。
図16：ロードバランサーの状態の監視
結論と次のステップ
E2E Cloudは、HAProxyを使用して負荷分散を設定するための仮想ロードバランサーノードを提供します。これらの2つのブログでは、E2EクラウドへのHAProxyのインストールを構成して、セッションの粘着性とHTTPSを介した安全なアクセスを備えたシンプルで大規模なマルチアプリケーションWebサイトのラウンドロビン負荷分散をサポートする方法を確認しました。
本番環境での展開に関するその他の考慮事項に注意して、このブログを終了します。
- まず、仮想ロードバランサーノード（およびオプションでWebサーバーノード）を、適切なDNS設定を使用してドメインに関連付ける必要があります
- したがって、HAProxyインスタンスへの安全なアクセスのためのSSL証明書は、同じドメインに関連付けられている必要があります
- 最後に、ロードバランサーが単一障害点になることはありません。そのため、HAProxyのアクティブ-パッシブ展開が推奨される場合があります。