Ubuntu14.04でCorosync、Pacemaker、および予約済みIPを使用して高可用性HAProxyセットアップを作成する方法

序章

このチュートリアルでは、予約済みIPとCorosync / Pacemakerクラスタースタックをサポートして、DigitalOceanで高可用性HAProxyロードバランサーのセットアップを作成する方法を示します。 HAProxyロードバランサーはそれぞれ、2つのバックエンドアプリケーションサーバー間でトラフィックを分割するように構成されます。 プライマリロードバランサーがダウンした場合、予約済みIPは自動的にセカンドロードバランサーに移動され、サービスを再開できるようになります。

前提条件

このガイドを完了するには、 Ubuntu 14.04 チュートリアルでCorosync、Pacemaker、および予約済みIPを使用して高可用性セットアップを作成する方法を完了する必要があります（オプションの AddNginxはスキップする必要があります）リソースセクション）。 これにより、プライマリとセカンダリと呼ばれる2つのドロップレットが残り、それらの間で移行できる予約済みIPがあります。 まとめて、これらのサーバーをロードバランサーと呼びます。 これらは、ロードバランサーであるHAProxyをインストールするドロップレットです。

また、HAロードバランサーのセットアップが機能することを示すために、プライベートネットワークを有効にして同じデータセンターに2つの追加のUbuntu14.04ドロップレットを作成できる必要があります。 これらは、HAProxyによって負荷分散されるサーバーです。 Nginxをインストールするこれらのアプリケーションサーバーをapp-1およびapp-2と呼びます。 負荷分散したいアプリケーションサーバーがすでにある場合は、代わりにそれらを自由に使用してください。

これらの各サーバーでは、root以外のユーザーを構成する必要があります sudo アクセス。 Ubuntu 14.04初期サーバーセットアップガイドに従って、これらのユーザーのセットアップ方法を学ぶことができます。

アプリのドロップレットを作成する

最初のステップは、プライベートネットワークを有効にして2つのUbuntuドロップレットをロードバランサーと同じデータセンターに作成することです。これは、説明されているapp-1およびapp-2サーバーとして機能します。その上。 両方のドロップレットにNginxをインストールし、それらのインデックスページをそれらを一意に識別する情報に置き換えます。 これにより、HAロードバランサーのセットアップが機能していることを簡単に示すことができます。 負荷分散したいアプリケーションサーバーがすでにある場合は、このチュートリアルの適切な部分を自由に調整して、それを機能させることができます（セットアップに関係のない部分はスキップしてください）。

セットアップ例に従う場合は、2つのUbuntu 14.04ドロップレット、app-1とapp-2を作成し、次のbashスクリプトをユーザーデータとして使用します。

#!/bin/bash

apt-get -y update
apt-get -y install nginx
export HOSTNAME=$(curl -s http://169.254.169.254/metadata/v1/hostname)
export PUBLIC_IPV4=$(curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address)
echo Droplet: $HOSTNAME, IP Address: $PUBLIC_IPV4 > /usr/share/nginx/html/index.html

このユーザーデータはNginxをインストールし、index.htmlの内容をドロップレットのホスト名とパブリックIPアドレスに置き換えます（メタデータサービスを参照することにより）。 いずれかのドロップレットにアクセスすると、ドロップレットのホスト名とパブリックIPアドレスを含む基本的なWebページが表示されます。これは、ロードバランサーがトラフィックを転送しているアプリサーバーをテストするのに役立ちます。

サーバーネットワーク情報を収集する

インフラストラクチャコンポーネントの実際の構成を開始する前に、各サーバーに関する情報を収集することをお勧めします。

このガイドを完了するには、サーバーに関する次の情報が必要です。

• アプリサーバー：プライベートIPアドレス
• ロードバランサープライベートおよびアンカーIPアドレス

プライベートIPアドレスを検索する

ドロップレットのプライベートIPアドレスを見つける最も簡単な方法は、 curl DigitalOceanメタデータサービスからプライベートIPアドレスを取得します。 このコマンドは、ドロップレット内から実行する必要があります。 各ドロップレットに次のように入力します。

curl 169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address && echo

正しいIPアドレスがターミナルウィンドウに出力されます。

Private IP address:
10.132.20.236

4つのドロップレットすべてに対してこの手順を実行し、簡単に参照できる場所にプライベートIPアドレスをコピーします。

アンカーIPアドレスを検索する

アンカーIPは、予約済みIPがDigitalOceanサーバーに接続されたときにバインドするローカルプライベートIPアドレスです。 これは単に通常のエイリアスです eth0 アドレス、ハイパーバイザーレベルで実装されます。

この値を取得する最も簡単でエラーが発生しにくい方法は、DigitalOceanメタデータサービスから直接取得することです。 使用する curl、次のように入力して、各サーバーのこのエンドポイントにアクセスできます。

curl 169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address && echo

アンカーIPは独自の行に印刷されます。

Output
10.17.1.18

両方のロードバランサドロップレットでこの手順を実行し、簡単に参照できる場所にアンカーIPアドレスをコピーします。

アプリサーバーを構成する

上記のデータを収集したら、サービスの構成に進むことができます。

まず、バックエンドアプリサーバーをセットアップします。 これらのサーバーは両方とも、名前とパブリックIPアドレスを提供するだけです。 実際のセットアップでは、これらのサーバーは同じコンテンツを提供します。 プライベートIPアドレスを介したWeb接続のみを受け入れます。 これにより、後で構成する2つのHAProxyサーバーのいずれかを介してトラフィックが排他的に送信されるようになります。

ロードバランサーの背後にアプリサーバーを設定すると、リクエストの負担をいくつかの同一のアプリサーバーに分散できます。 トラフィックのニーズが変化した場合、この層にアプリサーバーを追加または削除することで、新しい需要に合わせて簡単に拡張できます。

ロードバランサーからのリクエストのみを許可するようにNginxを構成する

例に従っていて、アプリサーバーの作成時に提供されたユーザーデータを使用した場合、サーバーにはすでにNginxがインストールされています。 次のステップは、いくつかの構成変更を行うことです。

サーバーのプライベートIPアドレスでのみリクエストをリッスンするようにNginxを構成したいと思います。 さらに、2つのロードバランサーのプライベートIPアドレスからのリクエストのみを処理します。 これにより、ユーザーはロードバランサー（予約済みIPアドレスを介してのみアクセスできるように構成されます）を介してアプリサーバーにアクセスするように強制されます。

これらの変更を行うには、各アプリサーバーでデフォルトのNginxサーバーブロックファイルを開きます。

sudo vi /etc/nginx/sites-available/default

まず、変更します listen ディレクティブ。 変更 listen ポート80で現在のアプリサーバーのプライベートIPアドレスをリッスンするディレクティブ。 余分なものを削除する listen ライン。 次のようになります。

server {
    listen app_server_private_IP:80;

    . . .

真下 listen ディレクティブ、2つ設定します allow 2つのロードバランサーのプライベートIPアドレスから発信されるトラフィックを許可するディレクティブ。 これをフォローアップします deny all 他のすべてのトラフィックを禁止するルール：

    allow load_balancer_1_private_IP;
    allow load_balancer_2_private_IP;
    deny all;

終了したら、ファイルを保存して閉じます。

次のように入力して、行った変更が有効なNginx構文を表していることをテストします。

sudo nginx -t

問題が報告されていない場合は、次のように入力してNginxデーモンを再起動します。

sudo service nginx restart

これらのすべての手順を（適切なアプリサーバーのプライベートIPアドレスを使用して）両方のアプリサーバーで実行することを忘れないでください。

変更のテスト

アプリサーバーが正しく制限されていることをテストするには、次を使用してリクエストを行うことができます curl さまざまな場所から。

アプリサーバー自体で、次のように入力して、ローカルコンテンツの簡単なリクエストを試すことができます。

curl 127.0.0.1

Nginxサーバーブロックファイルに設定した制限のため、このリクエストは実際には拒否されます。

Output
curl: (7) Failed to connect to 127.0.0.1 port 80: Connection refused

これは予想されたものであり、実装しようとした動作を反映しています。

これで、ロードバランサーのいずれかから、アプリサーバーのパブリックIPアドレスのいずれかをリクエストできます。

curl web_server_public_IP

繰り返しますが、これは失敗するはずです。 アプリサーバーはパブリックインターフェイスをリッスンしていません。さらに、パブリックIPアドレスを使用している場合、アプリサーバーはロードバランサーからのリクエストで許可されたプライベートIPアドレスを認識しません。

Output
curl: (7) Failed to connect to app_server_public_IP port 80: Connection refused

ただし、アプリサーバーのプライベートIPアドレスを使用してリクエストを行うように呼び出しを変更すると、正しく機能するはずです。

curl app_server_private_IP

Nginx index.html ページが返されます。 サンプルのユーザーデータを使用した場合、ページには、アクセスされているアプリサーバーの名前とパブリックIPアドレスが含まれている必要があります。

app server index.html
Droplet: app-1, IP Address: 159.203.130.34

両方のロードバランサーから両方のアプリサーバーにこれをテストします。 プライベートIPアドレスに対する各要求は成功する必要がありますが、パブリックアドレスに対して行われる各要求は失敗する必要があります。

上記の動作が実証されたら、次に進むことができます。 これで、バックエンドアプリサーバーの構成が完了しました。

ロードバランサーからNginxを削除します

前提条件のHASetup with Corosync、Pacemaker、and Reserved IPs チュートリアルに従うことで、ロードバランサーサーバーにNginxがインストールされます。 リバースプロキシロードバランサーとしてHAProxyを使用するため、Nginxと関連するクラスターリソースを削除する必要があります。

Nginxクラスターリソースを削除する

前提条件のチュートリアルに従ってNginxクラスターリソースを追加した場合は、停止して削除します Nginx ロードバランサーの1つでこれらのコマンドを使用するリソース：

sudo crm resource stop Nginx
sudo crm configure delete Nginx

これにより、に依存するクラスター設定も削除されます。 Nginx 資源。 たとえば、 clone また colocation それは Nginx リソース、それらも削除されます。

Nginxパッケージを削除する

これで、両方のロードバランサーサーバーでNginxをアンインストールする準備が整いました。

まず、Nginxサービスを停止します。

sudo service nginx stop

次に、次のコマンドでパッケージをパージします。

sudo apt-get purge nginx

Nginx構成ファイルを削除することもできます。

sudo rm -r /etc/nginx

これで、HAProxyをインストールして設定する準備が整いました。

HAProxyをインストールして設定する

次に、HAProxyロードバランサーを設定します。 これらはそれぞれWebサーバーの前に配置され、2つのバックエンドアプリサーバー間でリクエストを分割します。 これらのロードバランサーは、アクティブ-パッシブ構成では完全に冗長になります。 常に1つだけがトラフィックを受信します。

HAProxy構成は、両方のWebサーバーに要求を渡します。 ロードバランサーは、アンカーIPアドレスでリクエストをリッスンします。 前述のように、これは、ドロップレットに接続されたときに予約済みIPアドレスがバインドするIPアドレスです。 これにより、予約済みIPアドレスから発信されたトラフィックのみが転送されます。

HAProxyをインストールする

このセクションは、両方のロードバランサーサーバーで実行する必要があります。

デフォルトのUbuntuリポジトリにないHAProxy1.6をインストールします。 ただし、PPAを使用する場合は、次のコマンドを使用して、パッケージマネージャーを使用してHAProxy1.6をインストールできます。

sudo add-apt-repository ppa:vbernat/haproxy-1.6

ロードバランサーのローカルパッケージインデックスを更新し、次のように入力してHAProxyをインストールします。

sudo apt-get update
sudo apt-get install haproxy

これでHAProxyがインストールされましたが、今すぐ設定する必要があります。

HAProxyを構成する

メインのHAProxy構成ファイルを開きます。

sudo vi /etc/haproxy/haproxy.cfg

を見つける defaults セクションを作成し、その下に次の2行を追加します。

    option forwardfor
    option http-server-close

forwardfor オプションは、HAProxyを追加するように設定します X-Forwarded-For 各リクエストのヘッダー（アプリサーバーにリクエストを最初に送信したIPアドレスを知らせたい場合に便利です）と http-server-close オプションは、接続を閉じながらHAProxyとユーザー間のレイテンシを短縮します。キープアライブ。

次に、ファイルの最後で、フロントエンド構成を定義する必要があります。 これにより、HAProxyが着信接続をリッスンする方法が決まります。 HAProxyをロードバランサーのアンカーIPアドレスにバインドします。 これにより、予約済みIPアドレスから発信されたトラフィックをリッスンできるようになります。 わかりやすくするために、フロントエンドを「http」と呼びます。 デフォルトのバックエンドも指定します。 app_pool、トラフィックを渡すには（これはすぐに構成します）：

frontend http
    bind    load_balancer_anchor_IP:80
    default_backend app_pool

次に、バックエンド構成を定義できます。 これにより、HAProxyが受信するトラフィックを渡すダウンストリームの場所が指定されます。 この場合、これは、構成した両方のNginxアプリサーバーのプライベートIPアドレスになります。

backend app_pool
    server app-1 app_server_1_private_IP:80 check
    server app-2 app_server_2_private_IP:80 check

上記の変更が完了したら、ファイルを保存して終了します。

次のように入力して、行った構成の変更が有効なHAProxy構文を表していることを確認します。

sudo haproxy -f /etc/haproxy/haproxy.cfg -c

エラーが報告されなかった場合は、次のように入力してサービスを再起動します。

sudo service haproxy restart

繰り返しになりますが、このセクションのすべての手順を両方のロードバランサーサーバーで必ず実行してください。

変更のテスト

でテストすることにより、構成が有効であることを確認できます。 curl また。

ロードバランサーサーバーから、ローカルホスト、ロードバランサー自体のパブリックIPアドレス、またはサーバー自体のプライベートIPアドレスを要求してみてください。

curl 127.0.0.1
curl load_balancer_public_IP
curl load_balancer_private_IP

これらはすべて、次のようなメッセージで失敗するはずです。

Output
curl: (7) Failed to connect to IP_address port 80: Connection refused

ただし、ロードバランサーのアンカーIPアドレスにリクエストを送信すると、正常に完了するはずです。

curl load_balancer_anchor_IP

Nginxが表示されるはずです index.html いずれかのアプリサーバーのページ：

app server index.html
Droplet: app-1, IP Address: app1_IP_address

同じcurlリクエストを再度実行します。

curl load_balancer_anchor_IP

あなたは見るべきです index.html HAProxyはデフォルトでラウンドロビン負荷分散を使用するため、他のアプリサーバーのページ：

app server index.html
Droplet: app-2, IP Address: app2_IP_address

この動作がシステムの動作と一致する場合、ロードバランサーは正しく構成されています。 ロードバランサーサーバーが両方のバックエンドアプリサーバー間でトラフィックのバランスを取っていることをテストしました。 また、予約済みIPは、前提条件の HA Setup with Corosync、Pacemaker、およびReserved IP チュートリアルで設定されているため、ロードバランサーサーバーの1つにすでに割り当てられている必要があります。

HAProxyOCFリソースエージェントをダウンロードする

この時点で、基本的なホストレベルのフェイルオーバーが実行されていますが、クラスターリソースとしてHAProxyを追加することで、セットアップを改善できます。 そうすることで、クラスターは、予約済みIPが割り当てられているサーバーでHAProxyが実行されていることを確認できます。 Pacemakerは、HAProxyが実行されていないことを検出すると、サービスを再起動するか、予約済みIPを他のノード（HAProxyを実行している必要があります）に割り当てることができます。

Pacemakerを使用すると、OCFリソースエージェントを特定のディレクトリに配置して追加できます。

両方のロードバランサーサーバーで、次のコマンドを使用してHAProxyOCFリソースエージェントをダウンロードします。

cd /usr/lib/ocf/resource.d/heartbeat
sudo curl -O https://raw.githubusercontent.com/thisismitch/cluster-agents/master/haproxy

両方のロードバランサーサーバーで、実行可能にします。

sudo chmod +x haproxy

続行する前に、リソースの内容を確認してください。 これは、HAProxyサービスの管理に使用できるシェルスクリプトです。

これで、HAProxyOCFリソースエージェントを使用して haproxy クラスタリソース。

haproxyリソースを追加する

HAProxy OCFリソースエージェントがインストールされたら、次の設定を行うことができます。 haproxy クラスタがHAProxyを管理できるようにするリソース。

いずれかのロードバランサーサーバーで、 haproxy このコマンドを使用したプリミティブリソース：

sudo crm configure primitive haproxy ocf:heartbeat:haproxy op monitor interval=15s

指定されたリソースは、クラスターに15秒ごとにHAProxyを監視し、使用できなくなった場合は再起動するように指示します。

を使用してクラスターリソースのステータスを確認します sudo crm_mon また sudo crm status:

crm_mon:
...
Online: [ primary secondary ]

 FloatIP	(ocf::digitalocean:floatip):	Started primary
 Nginx	(ocf::heartbeat:nginx):	Started secondary

残念ながら、ペースメーカーは haproxy と FloatIP リソースの制約を定義していないため、別々のノードにリソースがあります。 HAProxyサービスがもう一方のドロップレットで実行されているときに予約済みIPが一方のドロップレットを指している可能性があるため、これは問題です。 予約済みIPにアクセスすると、高可用性が必要なサービスを実行していないサーバーが表示されます。

この問題を解決するために、 clone リソースを作成します。これは、既存のプリミティブリソースを複数のノードで開始する必要があることを指定します。

のクローンを作成します haproxy このコマンドで「haproxy-clone」と呼ばれるリソース：

sudo crm configure clone haproxy-clone haproxy

クラスタのステータスは次のようになります。

crm_mon:
Online: [ primary secondary ]

FloatIP (ocf::digitalocean:floatip):    Started primary
 Clone Set: haproxy-clone [Nginx]
     Started: [ primary secondary ]

ご覧のとおり、クローンリソース、 haproxy-clone、が両方のノードで開始されました。

最後のステップは、コロケーション拘束を構成して、 FloatIP リソースは、アクティブなノードで実行する必要があります haproxy-clone 資源。 「FloatIP-haproxy」と呼ばれるコロケーション制限を作成するには、次のコマンドを使用します。

sudo crm configure colocation FloatIP-haproxy inf: FloatIP haproxy-clone

crmステータスの出力に違いはありませんが、コロケーションリソースが次のコマンドで作成されたことがわかります。

sudo crm configure show

これで、両方のサーバーでHAProxyが実行されているはずですが、一方のサーバーでFloatIPリソースが実行されています。

いずれかのロードバランサーサーバーでHAProxyサービスを停止してみてください。

sudo service haproxy stop

次の15秒以内に再び起動することに気付くでしょう。

次に、アクティブなロードバランサーサーバー（サーバーのサーバー）を再起動して、HAセットアップをテストします。 FloatIP リソースは現在「開始」されています）。

ロードバランサーの高可用性をテストする

新しい高可用性HAProxyセットアップを使用して、すべてが意図したとおりに機能することをテストする必要があります。

ロードバランサー間の移行をより適切に視覚化するために、移行中にアプリサーバーのNginxログを監視できます。

使用されているプロキシサーバーに関する情報はクライアントに返されないため、ログを表示するのに最適な場所は、実際のバックエンドWebサーバーからです。 これらの各サーバーは、どのクライアントがアセットを要求するかについてのログを維持する必要があります。 Nginxサービスの観点からは、クライアントは実際のクライアントに代わってリクエストを行うロードバランサーです。

クラスタステータスを監視する

今後のテストの実行中に、クラスターノードとリソースのリアルタイムステータスを確認することをお勧めします。 このコマンドを使用して、いずれかのロードバランサーサーバーで実行できます（実行中の場合）。

sudo crm_mon

出力は次のようになります。

crm_mon output:
Last updated: Thu Nov  5 13:51:41 2015
Last change: Thu Nov  5 13:51:27 2015 via cibadmin on primary
Stack: corosync
Current DC: secondary (2) - partition with quorum
Version: 1.1.10-42f2063
2 Nodes configured
3 Resources configured

Online: [ primary secondary ]

FloatIP (ocf::digitalocean:floatip):    Started primary
 Clone Set: haproxy-clone [haproxy]
     Started: [ primary secondary ]

これにより、どのロードバランサーノードがオンラインで、どのノードがオンラインであるかがわかります。 FloatIP と haproxy リソースが開始されます。

そのノードに注意してください FloatIP リソースは Started オンの場合、上記の例の primary は、予約済みIPが現在割り当てられているロードバランサーサーバーです。 このサーバーをアクティブロードバランサーサーバーと呼びます。

予約済みIPへのリクエストを自動化

ローカルマシンでは、2秒に1回、予約済みIPアドレスのWebコンテンツを要求します。 これにより、アクティブなロードバランサーが着信トラフィックをどのように処理しているかを簡単に確認できます。 つまり、トラフィックを送信しているバックエンドアプリサーバーを確認します。 ローカル端末で、次のコマンドを入力します。

while true; do curl reserved_IP_address; sleep 2; done

2秒ごとに、バックエンドアプリサーバーの1つからの応答が表示されます。 指定していないHAProxyのデフォルトのバランスアルゴリズムがround-robinに設定されているため、おそらくapp-1とapp-2が交互になります。 したがって、端末には次のようなものが表示されます。

[secondary_label curl loop output:
Droplet: app-1, IP Address: app_1_IP_address
Droplet: app-2, IP Address: app_2_IP_address
...

このターミナルウィンドウを開いたままにして、リクエストがサーバーに継続的に送信されるようにします。 これらは、次のテスト手順で役立ちます。

Webサーバーのログを追跡する

各バックエンドアプリサーバーで、次のことができます tail the /var/log/nginx/access.log 位置。 これにより、サーバーに対して行われた各リクエストが表示されます。 ロードバランサーはラウンドロビンローテーションを使用してトラフィックを均等に分割するため、各バックエンドアプリサーバーは行われたリクエストの約半分を確認する必要があります。

クライアントアドレスはアクセスログの最初のフィールドであるため、簡単に見つけることができます。 Nginxアプリサーバーの両方で以下を実行します（別々のターミナルウィンドウで）：

sudo tail -f /var/log/nginx/access.log

最初のフィールドには、アクティブなロードバランサーサーバーのプライベートIPアドレスが4秒ごとに表示されます（プライマリロードバランサーであると想定しますが、セカンダリの場合もあります。場合）：

Output
. . .
primary_loadbalancer_IP - - [05/Nov/2015:14:26:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
primary_loadbalancer_IP - - [05/Nov/2015:14:26:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
. . .

維持する tail 両方のアプリサーバーで実行されているコマンド。

プライマリロードバランサーでHAProxyサービスを中断する

次に、 primary ロードバランサーを再起動して、予約済みIPフェイルオーバーが機能することを確認します。

sudo reboot

次に、両方のアプリサーバーのNginxアクセスログに注意してください。 予約済みIPフェイルオーバーが発生した後、アクセスログには、アプリサーバーが以前とは異なるIPアドレスでアクセスされていることが示されていることに注意してください。 ログは、セカンダリロードバランサーサーバーがリクエストを送信していることを示しているはずです。

Output
. . .
secondary_loadbalancer_IP - - [05/Nov/2015:14:27:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
secondary_loadbalancer_IP - - [05/Nov/2015:14:27:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
. . .

これは、プライマリロードバランサーの障害が検出され、リザーブドIPがセカンダリロードバランサーに正常に再割り当てされたことを示しています。

ローカル端末（2秒ごとに予約済みIPにアクセスしている）の出力をチェックして、セカンダリロードバランサーが両方のバックエンドアプリサーバーにリクエストを送信していることを確認することもできます。

[secondary_label curl loop output:
Droplet: app-1, IP Address: app_1_IP_address
Droplet: app-2, IP Address: app_2_IP_address
...

他のロードバランサーが再びオンラインになったら、他の方向でフェイルオーバーを試すこともできます。

実際のクライアントIPアドレスをログに記録するようにNginxを構成する

ご覧のとおり、Nginxアクセスログには、すべてのクライアントリクエストが、最初にリクエストを行ったクライアントの実際のIPアドレスではなく、現在のロードバランサーのプライベートIPアドレスからのものであることが示されています（つまり、 ローカルマシン）。 ロードバランサーサーバーではなく、元のリクエスターのIPアドレスをログに記録すると便利なことがよくあります。 これは、すべてのバックエンドアプリサーバーでNginx構成にいくつかの変更を加えることで簡単に実現できます。

両方のアプリサーバーで、 nginx.conf エディター内のファイル：

sudo vi /etc/nginx/nginx.conf

「ロギング設定」セクションを見つけます（ http ブロック）、次の行を追加します。

log_format haproxy_log 'ProxyIP: $remote_addr - ClientIP: $http_x_forwarded_for - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent "$http_referer" ' '"$http_user_agent"';

保存して終了。 これは、と呼ばれる新しいログ形式を指定します haproxy_log、追加します $http_x_forwarded_for value（元の要求を行ったクライアントのIPアドレス）をデフォルトのアクセスログエントリに設定します。 私たちも含まれています $remote_addr、これはリバースプロキシロードバランサーのIPアドレスです（つまり、 アクティブなロードバランサーサーバー）。

次に、この新しいログ形式を使用するには、デフォルトのサーバーブロックに行を追加する必要があります。

両方のアプリサーバーで、 default サーバー構成：

sudo vi /etc/nginx/sites-available/default

以内 server ブロック（真下 listen ディレクティブは適切な場所です）、次の行を追加します。

        access_log /var/log/nginx/access.log haproxy_log;

保存して終了。 これは、Nginxにアクセスログを使用して書き込むように指示します haproxy_log 最近作成したログ形式。

両方のアプリサーバーで、Nginxを再起動して変更を有効にします。

sudo service nginx restart

これで、Nginxアクセスログに、リクエストを行っているクライアントの実際のIPアドレスが含まれているはずです。 前のセクションで行ったように、アプリサーバーのログを追跡してこれを確認します。 ログエントリは次のようになります。

New Nginx access logs:
. . .
ProxyIP: load_balancer_private_IP - ClientIP: local_machine_IP - - [05/Nov/2015:15:05:53 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
. . .

ログの見栄えが良ければ、準備は完了です。

結論

このガイドでは、可用性が高く、負荷分散されたインフラストラクチャをセットアップする完全なプロセスについて説明しました。 この構成は、アクティブなHAProxyサーバーがバックエンド上のアプリサーバーのプールに負荷を分散できるため、うまく機能します。 需要の拡大または縮小に応じて、このプールを簡単に拡張できます。

予約済みIPとCorosync/Pacemaker構成により、負荷分散レイヤーでの単一障害点が排除され、プライマリロードバランサーに完全な障害が発生した場合でもサービスが機能し続けることができます。 この構成はかなり柔軟性があり、HAProxyサーバーの背後に優先アプリケーションスタックを設定することで、独自のアプリケーション環境に適合させることができます。