TOC

Ubuntu 14.04でCorosync、Pacemaker、Floating IPを使用して高可用性HAProxyセットアップを作成する方法

前書き

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

image：https：//assets.digitalocean.com/articles/high_availability/ha-diagram-animated.gif [高可用性HAProxyセットアップ]

前提条件

このガイドを完了するには、https：//www.digitalocean.com/community/tutorials/how-to-create-a-high-availability-setup-with-corosync-pacemaker-and-を完了する必要があります。 floating-ips-on-ubuntu-14-04 [Ubuntu 14.04でCorosync、Pacemaker、およびフローティングIPを使用して高可用性セットアップを作成する方法]チュートリアル（オプションの* Add Nginx Resource セクションをスキップする必要があります）。 これにより、2つのドロップレットが得られます。これらは、 primary および secondary *と呼ばれ、それらの間で移行できるフローティングIPを備えています。 これらのサーバーを総称して「ロードバランサー」と呼びます。 これらは、ロードバランサであるHAProxyをインストールするドロップレットです。

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

これらの各サーバーでは、 `+ sudo +`アクセスで設定された非rootユーザーが必要です。 これらのユーザーのセットアップ方法については、https：//www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04 [Ubuntu 14.04初期サーバーセットアップガイド]を参照してください。

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

最初のステップは、上記の* app-1 および app-2 *サーバーとして機能するロードバランサーと同じデータセンターに、プライベートネットワークを有効にした2つのUbuntuドロップレットを作成することです。 Nginxを両方のDropletにインストールし、インデックスページをそれらを一意に識別する情報で置き換えます。 これにより、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アドレスに置き換えます（メタデータサービスを参照して）。 いずれかのDropletにアクセスすると、Dropletのホスト名とパブリックIPアドレスを含む基本的なWebページが表示されます。これは、ロードバランサーがトラフィックを転送しているアプリサーバーのテストに役立ちます。

サーバーネットワーク情報の収集

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

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

  • アプリサーバー：プライベートIPアドレス

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

プライベートIPアドレスを見つける

Dropletのプライベート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アドレスを見つける

  • anchor IP *は、Floating 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アドレスをコピーします。

アプリサーバーの構成

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

Note

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

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

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

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

サーバーのプライベートIPアドレスでのみリクエストをリッスンするようにNginxを構成します。 さらに、2つのロードバランサーのプライベートIPアドレスからのリクエストのみを処理します。 これにより、ユーザーはロードバランサーを介してアプリサーバーにアクセスする必要があります（フローティングIPアドレスを介してのみアクセスできるように構成します）。

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

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

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

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

server {
   listen :80;

   . . .

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

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

   allow ;
   allow ;
   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

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

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

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

curl

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

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

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

上記の動作が実証されたら、次に進みます。 バックエンドアプリサーバーの設定が完了しました。

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

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

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

前提条件のチュートリアルに従ってNginxクラスターリソースを追加した場合は、ロードバランサーのいずれかでこれらのコマンドを使用して `+ 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リポジトリにないHAProxy 1.6をインストールします。 ただし、PPAを使用する場合は、次のコマンドでパッケージマネージャーを使用してHAProxy 1.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    :80
   default_backend app_pool

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

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

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

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

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

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

エラーが報告されていない場合は、次を入力してサービスを再起動します。

sudo service haproxy restart

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

変更のテスト

もう一度 `+ curl`でテストすることで、設定が有効であることを確認できます。

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

curl 127.0.0.1
curl
curl

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

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

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

curl

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

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

同じcurl要求を再度実行します。

curl

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

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

この動作がシステムの動作と一致する場合、ロードバランサーは正しく構成されています。ロードバランサーサーバーが両方のバックエンドアプリサーバー間でトラフィックを分散していることをテストできました。 また、前提条件であるCorosync、Pacemaker、Floating IPを使用したHAセットアップチュートリアルでセットアップしたように、フローティングIPはロードバランサーサーバーのいずれかに既に割り当てられている必要があります。

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

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

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

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

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を監視し、HAProxyが利用できなくなった場合に再起動するようにクラスターに指示します。

+ sudo crm_mon`または + sudo crm status`を使用して、クラスターリソースのステータスを確認します。

crm_mon:...
Online: [ primary secondary ]

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

残念ながら、Pacemakerはリソース制約を定義していないため、個別のノードで `+ haproxy `および ` FloatIP +`リソースを開始することを決定する場合があります。 HAProxyサービスが他のドロップレットで実行されている間に、フローティングIPが1つのドロップレットを指している可能性があるため、これは問題です。 フローティング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 +`が両方のノードで開始されました。

最後のステップは、コロケーション抑制を設定し、アクティブな `+ haproxy-clone `リソースを持つノードで ` FloatIP +`リソースを実行するように指定することです。 「FloatIP-haproxy」というコロケーション抑制を作成するには、次のコマンドを使用します。

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

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

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 *）は、Floating IPが現在割り当てられているロードバランサーサーバーです。 このサーバーを「アクティブロードバランサーサーバー」と呼びます。

フローティングIPへのリクエストを自動化する

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

while true; do curl ; sleep 2; done

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

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

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

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

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

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

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

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

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

両方のアプリサーバーで「+ tail +」コマンドを実行し続けます。

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

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

sudo reboot

ここで、両方のアプリサーバーのNginxアクセスログに注意してください。 フローティングIPフェールオーバーの発生後、アクセスログには、アプリサーバーが以前とは異なるIPアドレスでアクセスされていることが示されます。 ログは、* secondary *ロードバランサーサーバーがリクエストを送信していることを示す必要があります。

Output. . .
- - [05/Nov/2015:14:27:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
- - [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:
Droplet: app-2, IP Address:
...

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

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

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

両方の* appサーバー*で、エディターで `+ 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アドレス）をデフォルトのアクセスログエントリに追加します。 また、 ` $ remote_addr +`を含めています。これは、リバースプロキシロードバランサーのIPアドレスです（つまり、 アクティブなロードバランサーサーバー）。

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

*両方のアプリサーバー*で、 `+ default +`サーバー設定を開きます。

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

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

/ etc / nginx / sites-available / defaultに追加します

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

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

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

sudo service nginx restart

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

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

ログに問題がなければ、準備は完了です！

結論

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

フローティングIPおよびCorosync / Pacemaker構成は、ロードバランシングレイヤーでの単一障害点を排除し、プライマリロードバランサーが完全に失敗した場合でもサービスが機能し続けることを可能にします。 この構成は非常に柔軟であり、HAProxyサーバーの背後で優先アプリケーションスタックを設定することにより、独自のアプリケーション環境に適合させることができます。

Related