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

序章

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

ノート： DigitalOceanロードバランサー are a fully-managed, highly available load balancing service. The Load Balancer service can fill the same role as the manual high availability setup described here. Follow our ロードバランサーの設定に関するガイド if you wish to evaluate that option.

前提条件

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

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

これらの各サーバーでは、sudoアクセスで構成されたroot以外のユーザーが必要になります。 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は独自の行に印刷されます。

Output10.17.1.18

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

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

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

ノート

このセットアップでは、Webサーバーレイヤー用に選択されたソフトウェアはかなり互換性があります。このガイドでは、一般的で構成がかなり簡単なNginxを使用します。 Apacheまたは（本番環境に対応した）言語固有のWebサーバーに慣れている場合は、代わりにそれを自由に使用してください。 HAProxyは、直接クライアント接続を処理するのと同じように要求を処理できるバックエンドWebサーバーにクライアント要求を渡すだけです。

まず、バックエンドアプリサーバーをセットアップします。これらのサーバーは両方とも、名前とパブリック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行を削除します。次のようになります。

/ etc / nginx / sites-available / default（1/2）

server {
    listen app_server_private_IP:80;

    . . .

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

/ etc / nginx / sites-available / default（2/2）

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

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

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

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

curl web_server_public_IP

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

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

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

curl app_server_private_IP

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

app server index.htmlDroplet: app-1, IP Address: 159.203.130.34

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

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

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

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

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

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

sudo crm resource stop Nginx
sudo crm configure delete Nginx

これにより、Nginxリソースに依存するクラスター設定も削除されます。たとえば、Nginxリソースを参照するcloneまたはcolocationを作成した場合、それらも削除されます。

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行を追加します。

/etc/haproxy/haproxy.cfg（1/3）

    option forwardfor
    option http-server-close

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

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

/etc/haproxy/haproxy.cfg（2/3）

frontend http
    bind    load_balancer_anchor_IP:80
    default_backend app_pool

注：アンカーIPは、ロードバランサーサーバー間で異なる必要があるHAProxy構成の唯一の部分です。つまり、現在作業しているロードバランサーサーバーのアンカーIPを必ず指定してください。

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

/etc/haproxy/haproxy.cfg（3/3）

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

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

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

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

curl load_balancer_anchor_IP

いずれかのアプリサーバーのNginxindex.htmlページが表示されます。

app server index.htmlDroplet: app-1, IP Address: app1_IP_address

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

curl load_balancer_anchor_IP

HAProxyはデフォルトでラウンドロビン負荷分散を使用するため、他のアプリサーバーのindex.htmlページが表示されます。

app server index.htmlDroplet: app-2, IP Address: app2_IP_address

この動作がシステムの動作と一致する場合、ロードバランサーは正しく構成されています。ロードバランサーサーバーが両方のバックエンドアプリサーバー間でトラフィックのバランスを取っていることをテストしました。また、フローティングIPは、前提条件の HA Setup with Corosync、Pacemaker、およびFloating 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サービスの管理に使用できるシェルスクリプトです。

これで、HAProxy OCFリソースエージェントを使用して、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

残念ながら、Pacemakerは、リソースの制約を定義していないため、haproxyおよびFloatIPリソースを別々のノードで開始することを決定する場合があります。 HAProxyサービスが他のDropletで実行されているときに、Floating IPが1つのDropletを指している可能性があるため、これは問題です。フローティングIPにアクセスすると、高可用性が必要なサービスを実行していないサーバーが表示されます。

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

次のコマンドを使用して、「haproxy-clone」というhaproxyリソースのクローンを作成します。

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秒以内に再び起動することに気付くでしょう。

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

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

新しい高可用性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 floating_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/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ブロック内）を見つけて、次の行を追加します。

/etc/nginx/nginx.confに追加

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値（元の要求を行ったクライアントのIPアドレス）がデフォルトのアクセスログエントリに追加されます。リバースプロキシロードバランサーのIPアドレスである$remote_addrも含まれています（つまり、アクティブなロードバランサーサーバー）。

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

両方のアプリサーバーで、defaultサーバー構成を開きます。

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

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

/ etc / nginx / sites-available/defaultに追加

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

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

両方のアプリサーバーで、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サーバーがバックエンド上のアプリサーバーのプールに負荷を分散できるため、うまく機能します。需要の拡大または縮小に応じて、このプールを簡単に拡張できます。

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