Ubuntu14.04でKeepalivedおよびReservedIPを使用して高可用性HAProxyサーバーをセットアップする方法
序章
高可用性は、障害が発生した場合にアプリケーションが作業を自動的に再起動したり、別の対応可能なシステムに再ルーティングしたりできるようにするシステム設計の機能です。 サーバーに関しては、高可用性システムをセットアップするために必要ないくつかの異なるテクノロジーがあります。 作業をリダイレクトできるコンポーネントが必要であり、障害を監視し、中断が検出された場合にシステムを移行するメカニズムが必要です。
The keepalived
デーモンを使用して、サービスまたはシステムを監視し、問題が発生した場合にスタンバイに自動的にフェイルオーバーすることができます。 このガイドでは、使用方法を示します keepalived
ロードバランサーの高可用性を設定します。 2つの対応するロードバランサー間で移動できる予約済みIPアドレスを構成します。 これらはそれぞれ、2つのバックエンドWebサーバー間でトラフィックを分割するように構成されます。 プライマリロードバランサーがダウンした場合、予約済みIPは自動的にセカンドロードバランサーに移動され、サービスを再開できるようになります。
注: DigitalOceanロードバランサーは、フルマネージドで可用性の高いロードバランシングサービスです。 ロードバランサーサービスは、ここで説明する手動の高可用性セットアップと同じ役割を果たすことができます。 そのオプションを評価したい場合は、ロードバランサーの設定に関するガイドに従ってください。
前提条件
このガイドを完了するには、DigitalOceanアカウントに4つのUbuntu14.04サーバーを作成する必要があります。 すべてのサーバーは同じデータセンター内に配置する必要があり、プライベートネットワークを有効にする必要があります。
これらの各サーバーでは、root以外のユーザーを構成する必要があります sudo
アクセス。 Ubuntu 14.04初期サーバーセットアップガイドに従って、これらのユーザーのセットアップ方法を学ぶことができます。
サーバーネットワーク情報の検索
インフラストラクチャコンポーネントの実際の構成を開始する前に、各サーバーに関する情報を収集することをお勧めします。
このガイドを完了するには、サーバーに関する次の情報が必要です。
- ウェブサーバー:プライベートIPアドレス
- ロードバランサープライベートおよびアンカーIPアドレス
プライベートIPアドレスの検索
ドロップレットのプライベートIPアドレスを見つける最も簡単な方法は、 curl
DigitalOceanメタデータサービスからプライベートIPアドレスを取得します。 このコマンドは、ドロップレット内から実行する必要があります。 各ドロップレットに次のように入力します。
- curl 169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address && echo
正しいIPアドレスがターミナルウィンドウに出力されます。
Output10.132.20.236
アンカー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
Webサーバーのインストールと構成
上記のデータを収集したら、サービスの構成に進むことができます。
ノート
このセットアップでは、Webサーバーレイヤー用に選択されたソフトウェアはかなり互換性があります。 このガイドでは、一般的で構成がかなり簡単なNginxを使用します。 Apacheまたは(本番環境に対応した)言語固有のWebサーバーに慣れている場合は、代わりにそれを自由に使用してください。 HAProxyは、直接クライアント接続を処理するのと同じように要求を処理できるバックエンドWebサーバーにクライアント要求を渡すだけです。
まず、バックエンドWebサーバーをセットアップします。 これらのサーバーは両方ともまったく同じコンテンツを提供します。 プライベートIPアドレスを介したWeb接続のみを受け入れます。 これにより、後で構成する2つのHAProxyサーバーのいずれかを介してトラフィックが転送されるようになります。
ロードバランサーの背後にWebサーバーを設定すると、要求の負担をいくつかの同一のWebサーバーに分散できます。 トラフィックのニーズが変化した場合、この層にWebサーバーを追加または削除することで、新しい需要に合わせて簡単に拡張できます。
Nginxのインストール
この機能を提供するために、WebサービングマシンにNginxをインストールします。
でログインすることから始めます sudo
Webサーバーとして使用する2台のマシンのユーザー。 各Webサーバーのローカルパッケージインデックスを更新し、次のように入力してNginxをインストールします。
- sudo apt-get update
- sudo apt-get install nginx
ロードバランサーからのリクエストのみを許可するようにNginxを構成する
次に、Nginxインスタンスを構成します。 サーバーのプライベートIPアドレスでのみリクエストをリッスンするようにNginxに指示します。 さらに、2つのロードバランサーのプライベートIPアドレスからのリクエストのみを処理します。
これらの変更を行うには、各WebサーバーでデフォルトのNginxサーバーブロックファイルを開きます。
- sudo nano /etc/nginx/sites-available/default
まず、変更します listen
ディレクティブ。 変更 listen
ポート80で現在のWebサーバーのプライベートIPアドレスをリッスンするディレクティブ。 余分なものを削除する listen
ライン。 次のようになります。
server {
listen web_server_private_IP:80;
. . .
その後、2つ設定します allow
2つのロードバランサーのプライベートIPアドレスから発信されるトラフィックを許可するディレクティブ。 これをフォローアップします deny all
他のすべてのトラフィックを禁止するルール:
server {
listen web_server_private_IP:80;
allow load_balancer_1_private_IP;
allow load_balancer_2_private_IP;
deny all;
. . .
終了したら、ファイルを保存して閉じます。
次のように入力して、行った変更が有効なNginx構文を表していることをテストします。
- sudo nginx -t
問題が報告されていない場合は、次のように入力してNginxデーモンを再起動します。
- sudo service nginx restart
変更のテスト
Webサーバーが正しく制限されていることをテストするには、次を使用してリクエストを行うことができます curl
さまざまな場所から。
Webサーバー自体で、次のように入力して、ローカルコンテンツの簡単なリクエストを試すことができます。
- curl 127.0.0.1
Nginxサーバーブロックファイルに設定した制限のため、このリクエストは実際には拒否されます。
Outputcurl: (7) Failed to connect to 127.0.0.1 port 80: Connection refused
これは予想されたものであり、実装しようとした動作を反映しています。
これで、ロードバランサーのいずれかから、WebサーバーのパブリックIPアドレスのいずれかをリクエストできます。
- curl web_server_public_IP
繰り返しますが、これは失敗するはずです。 Webサーバーはパブリックインターフェイスをリッスンしていません。さらに、パブリックIPアドレスを使用すると、ロードバランサーからのリクエストで許可されたプライベートIPアドレスがWebサーバーに表示されません。
Outputcurl: (7) Failed to connect to web_server_public_IP port 80: Connection refused
ただし、WebサーバーのプライベートIPアドレスを使用して要求を行うように呼び出しを変更すると、正しく機能するはずです。
- curl web_server_private_IP
デフォルトのNginx index.html
ページを返す必要があります:
Output<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
. . .
両方のロードバランサーから両方のWebサーバーにこれをテストします。 プライベートIPアドレスに対する各要求は成功する必要がありますが、パブリックアドレスに対して行われる各要求は失敗する必要があります。
上記の動作が実証されたら、次に進むことができます。 これで、バックエンドWebサーバーの構成が完了しました。
HAProxyをインストールして設定する
次に、HAProxyロードバランサーを設定します。 これらはそれぞれWebサーバーの前に配置され、2つのバックエンドサーバー間でリクエストを分割します。 これらのロードバランサーは完全に冗長です。 常に1つだけがトラフィックを受信します。
HAProxy構成は、両方のWebサーバーに要求を渡します。 ロードバランサーは、アンカーIPアドレスでリクエストをリッスンします。 前述のように、これは、ドロップレットに接続されたときに予約済みIPアドレスがバインドするIPアドレスです。 これにより、予約済みIPアドレスから発信されたトラフィックのみが転送されます。
HAProxyをインストールする
ロードバランサーで実行する必要がある最初のステップは、 haproxy
パッケージ。 これはデフォルトのUbuntuリポジトリにあります。 ロードバランサーのローカルパッケージインデックスを更新し、次のように入力してHAProxyをインストールします。
- sudo apt-get update
- sudo apt-get install haproxy
HAProxyを構成する
HAProxyを処理するときに変更する必要がある最初の項目は、 /etc/default/haproxy
ファイル。 そのファイルをエディターで今すぐ開きます。
- sudo nano /etc/default/haproxy
このファイルは、HAProxyが起動時に起動するかどうかを決定します。 サーバーの電源を入れるたびにサービスを自動的に開始する必要があるため、次の値を変更する必要があります。 ENABLED
「1」へ:
# Set ENABLED to 1 if you want the init script to start haproxy.
ENABLED=1
# Add extra flags here.
#EXTRAOPTS="-de -m 16"
上記の編集を行った後、ファイルを保存して閉じます。
次に、メインのHAProxy構成ファイルを開くことができます。
- sudo nano /etc/haproxy/haproxy.cfg
調整する必要がある最初の項目は、HAProxyが動作するモードです。 TCP、つまりレイヤー4の負荷分散を構成します。 これを行うには、を変更する必要があります mode
の行 default
セクション。 ログを処理する直後のオプションも変更する必要があります。
. . .
defaults
log global
mode tcp
option tcplog
. . .
ファイルの最後で、フロントエンド構成を定義する必要があります。 これにより、HAProxyが着信接続をリッスンする方法が決まります。 HAProxyをロードバランサーのアンカーIPアドレスにバインドします。 これにより、予約済みIPアドレスから発信されたトラフィックをリッスンできるようになります。 わかりやすくするために、フロントエンドを「www」と呼びます。 また、トラフィックを渡すデフォルトのバックエンドを指定します(これはすぐに構成します)。
. . .
defaults
log global
mode tcp
option tcplog
. . .
frontend www
bind load_balancer_anchor_IP:80
default_backend nginx_pool
次に、バックエンドセクションを構成できます。 これにより、HAProxyが受信するトラフィックを渡すダウンストリームの場所が指定されます。 この場合、これは、構成した両方のNginxWebサーバーのプライベートIPアドレスになります。 従来のラウンドロビンバランシングを指定し、モードを再び「tcp」に設定します。
. . .
defaults
log global
mode tcp
option tcplog
. . .
frontend www
bind load_balancer_anchor_IP:80
default_backend nginx_pool
backend nginx_pool
balance roundrobin
mode tcp
server web1 web_server_1_private_IP:80 check
server web2 web_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 address port 80: Connection refused
ただし、ロードバランサーのアンカーIPアドレスにリクエストを送信すると、正常に完了するはずです。
- curl load_balancer_anchor_IP
デフォルトのNginxが表示されます index.html
2つのバックエンドWebサーバーのいずれかからルーティングされたページ:
Output<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
. . .
この動作がシステムの動作と一致する場合は、ロードバランサーが正しく構成されています。
キープアライブのビルドとインストール
現在、実際のサービスが稼働しています。 ただし、アクティブなロードバランサーで問題が発生した場合にトラフィックをリダイレクトする方法がないため、インフラストラクチャはまだ高可用性ではありません。 これを修正するために、 keepalived
ロードバランサーサーバー上のデーモン。 これは、アクティブなロードバランサーが使用できなくなった場合にフェイルオーバー機能を提供するコンポーネントです。
のバージョンがあります keepalived
Ubuntuのデフォルトのリポジトリにありますが、古く、設定が機能しなくなるいくつかのバグがあります。 代わりに、最新バージョンのをインストールします keepalived
ソースから。
始める前に、ソフトウェアをビルドするために必要な依存関係を把握する必要があります。 The build-essential
メタパッケージは必要なコンパイルツールを提供しますが、 libssl-dev
パッケージには、SSL開発ライブラリが含まれています。 keepalived
に対して構築する必要があります:
- sudo apt-get install build-essential libssl-dev
依存関係が設定されたら、tarballをダウンロードできます。 keepalived
. このページにアクセスして、ソフトウェアの最新バージョンを見つけてください。 最新バージョンを右クリックして、リンクアドレスをコピーします。 サーバーに戻り、ホームディレクトリに移動して使用します wget
コピーしたリンクを取得するには:
- cd ~
- wget http://www.keepalived.org/software/keepalived-1.2.19.tar.gz
使用 tar
アーカイブを展開するコマンド。 結果のディレクトリに移動します。
- tar xzvf keepalived*
- cd keepalived*
次のように入力して、デーモンをビルドしてインストールします。
- ./configure
- make
- sudo make install
これで、デーモンが両方のロードバランサーシステムにインストールされます。
キープアライブアップスタートスクリプトを作成する
The keepalived
インストールにより、すべてのバイナリとサポートファイルがシステム上の所定の場所に移動しました。 ただし、含まれていなかったのは、Ubuntu14.04システムのUpstartスクリプトでした。
を処理できる非常に単純なUpstartスクリプトを作成できます keepalived
サービス。 というファイルを開きます keepalived.conf
以内 /etc/init
開始するディレクトリ:
- sudo nano /etc/init/keepalived.conf
内部では、機能の簡単な説明から始めることができます keepalived
提供します。 付属の説明を使用します man
ページ。 次に、サービスを開始および停止するランレベルを指定します。 このサービスをすべての通常の状態(ランレベル2〜5)でアクティブにし、他のすべてのランレベル(たとえば、再起動、電源オフ、またはシングルユーザーモードが開始されたとき)で停止する必要があります。
description "load-balancing and high-availability service"
start on runlevel [2345]
stop on runlevel [!2345]
このサービスは、Webサービスを引き続き利用できるようにするために不可欠であるため、障害が発生した場合にこのサービスを再開します。 次に、実際のを指定できます exec
サービスを開始する回線。 追加する必要があります --dont-fork
Upstartが追跡できるようにするオプション pid
正しく:
description "load-balancing and high-availability service"
start on runlevel [2345]
stop on runlevel [!2345]
respawn
exec /usr/local/sbin/keepalived --dont-fork
終了したら、ファイルを保存して閉じます。
キープアライブ構成ファイルを作成する
Upstartファイルを配置したら、構成に進むことができます keepalived
.
サービスは、で構成ファイルを探します /etc/keepalived
ディレクトリ。 両方のロードバランサーに今すぐそのディレクトリを作成します。
- sudo mkdir -p /etc/keepalived
プライマリロードバランサーの構成の作成
次に、プライマリサーバーとして使用するロードバランサーサーバーで、メインを作成します keepalived
構成ファイル。 デーモンは、というファイルを探します keepalived.conf
の内側 /etc/keepalived
ディレクトリ:
- sudo nano /etc/keepalived/keepalived.conf
内部では、HAProxyサービスのヘルスチェックを定義することから始めます。 vrrp_script
ブロック。 これにより、 keepalived
ロードバランサーの障害を監視して、プロセスがダウンしていることを通知し、対策の回復を開始できるようにします。
チェックはとても簡単です。 2秒ごとに、 haproxy
まだ主張している pid
:
vrrp_script chk_haproxy {
script "pidof haproxy"
interval 2
}
次に、というブロックを開きます vrrp_instance
. これは、次の方法を定義する主要な構成セクションです。 keepalived
高可用性を実装します。
まずは次のように伝えます keepalived
ピアと通信する eth1
、私たちのプライベートインターフェース。 プライマリサーバーを構成しているので、 state
「MASTER」への設定。 これは初期値です keepalived
デーモンがピアに接続して選挙を行うことができるまで使用します。
選挙中、 priority
オプションは、どのメンバーが選出されるかを決定するために使用されます。 決定は、この設定で最も多いサーバーの数に基づいて行われます。 プライマリサーバーには「200」を使用します。
vrrp_script chk_nginx {
script "pidof nginx"
interval 2
}
vrrp_instance VI_1 {
interface eth1
state MASTER
priority 200
}
次に、両方のノードで共有されるこのクラスターグループにIDを割り当てます。 この例では「33」を使用します。 設定する必要があります unicast_src_ip
プライマリロードバランサーのプライベートIPアドレスに。 設定します unicast_peer
セカンダリロードバランサーのプライベートIPアドレスへ:
vrrp_script chk_haproxy {
script "pidof haproxy"
interval 2
}
vrrp_instance VI_1 {
interface eth1
state MASTER
priority 200
virtual_router_id 33
unicast_src_ip primary_private_IP
unicast_peer {
secondary_private_IP
}
}
次に、簡単な認証を設定できます keepalived
互いに通信するデーモン。 これは、連絡先のピアが正当であることを確認するための基本的な手段にすぎません。 作成する authentication
サブブロック。 内部で、設定してパスワード認証を指定します auth_type
. のために auth_pass
パラメータ、両方のノードで使用される共有シークレットを設定します。 残念ながら、最初の8文字だけが重要です。
vrrp_script chk_haproxy {
script "pidof haproxy"
interval 2
}
vrrp_instance VI_1 {
interface eth1
state MASTER
priority 200
virtual_router_id 33
unicast_src_ip primary_private_IP
unicast_peer {
secondary_private_IP
}
authentication {
auth_type PASS
auth_pass password
}
}
次に教えます keepalived
ファイルの上部に作成した、ラベルの付いたチェックを使用するには chk_haproxy
、ローカルシステムの状態を判断します。 最後に、 notify_master
スクリプト。このノードがペアの「マスター」になるたびに実行されます。 このスクリプトは、予約済みIPアドレスの再割り当てをトリガーする役割を果たします。 このスクリプトをすぐに作成します。
vrrp_script chk_haproxy {
script "pidof haproxy"
interval 2
}
vrrp_instance VI_1 {
interface eth1
state MASTER
priority 200
virtual_router_id 33
unicast_src_ip primary_private_IP
unicast_peer {
secondary_private_IP
}
authentication {
auth_type PASS
auth_pass password
}
track_script {
chk_haproxy
}
notify_master /etc/keepalived/master.sh
}
上記の情報を設定したら、ファイルを保存して閉じます。
セカンダリロードバランサーの構成の作成
次に、セカンダリロードバランサーでコンパニオンスクリプトを作成します。 でファイルを開きます /etc/keepalived/keepalived.conf
セカンダリサーバー:
- sudo nano /etc/keepalived/keepalived.conf
内部では、使用するスクリプトはプライマリサーバーのスクリプトとほぼ同じです。 変更する必要がある項目は次のとおりです。
state
:選択が行われる前にノードがバックアップ状態に初期化されるように、これをセカンダリサーバーで「バックアップ」に変更する必要があります。priority
:これは、プライマリサーバーよりも低い値に設定する必要があります。 このガイドでは、値「100」を使用します。unicast_src_ip
:これは、セカンダリサーバーのプライベートIPアドレスである必要があります。unicast_peer
:これには、プライマリサーバーのプライベートIPアドレスが含まれている必要があります。
これらの値を変更すると、セカンダリサーバーのスクリプトは次のようになります。
vrrp_script chk_haproxy {
script "pidof haproxy"
interval 2
}
vrrp_instance VI_1 {
interface eth1
state BACKUP
priority 100
virtual_router_id 33
unicast_src_ip secondary_private_IP
unicast_peer {
primary_private_IP
}
authentication {
auth_type PASS
auth_pass password
}
track_script {
chk_haproxy
}
notify_master /etc/keepalived/master.sh
}
スクリプトを入力して適切な値を変更したら、ファイルを保存して閉じます。
予約済みIP移行スクリプトを作成する
次に、ローカルの場合はいつでも、予約済みIPアドレスを現在のドロップレットに再割り当てするために使用できるスクリプトのペアを作成する必要があります。 keepalived
インスタンスがマスターサーバーになります。
予約済みIP割り当てスクリプトをダウンロードする
まず、DigitalOcean APIを使用して予約済みIPアドレスをドロップレットに再割り当てするために使用できる汎用Pythonスクリプト( DigitalOceanコミュニティマネージャーによって記述された)をダウンロードします。 このファイルをにダウンロードする必要があります /usr/local/bin
ディレクトリ:
- cd /usr/local/bin
- sudo curl -LO http://do.co/assign-ip
このスクリプトを使用すると、次のコマンドを実行して既存の予約済みIPを再割り当てできます。
- python /usr/local/bin/assign-ip reserved_ip droplet_ID
これは、次のような環境変数がある場合にのみ機能します DO_TOKEN
アカウントの有効なDigitalOceanAPIトークンに設定します。
DigitalOceanAPIトークンを作成する
上記のスクリプトを使用するには、アカウントにDigitalOceanAPIトークンを作成する必要があります。
コントロールパネルで、上部の「API」リンクをクリックします。 APIページの右側で、[新しいトークンを生成]をクリックします。
次のページで、トークンの名前を選択し、[トークンの生成]ボタンをクリックします。
APIページに、新しいトークンが表示されます。
トークンnowをコピーします。 セキュリティ上の理由から、後でこのトークンを再度表示する方法はありません。 このトークンを紛失した場合は、トークンを破棄して別のトークンを作成する必要があります。
インフラストラクチャの予約済みIPを構成する
次に、サーバーに使用する予約済みIPアドレスを作成して割り当てます。
DigitalOceanコントロールパネルで、[ネットワーク]タブをクリックし、[予約済みIP]ナビゲーション項目を選択します。 最初の割り当てのメニューからプライマリロードバランサーを選択します。
新しい予約済みIPアドレスがアカウントに作成され、指定されたドロップレットに割り当てられます。
Webブラウザで予約済みIPにアクセスすると、バックエンドWebサーバーの1つから提供されるデフォルトのNginxページが表示されます。
予約済みIPアドレスをコピーします。 以下のスクリプトでこの値が必要になります。
ラッパースクリプトを作成する
これで、ラッパースクリプトを作成するために必要なアイテムができました。 /usr/local/bin/assign-ip
正しいクレデンシャルを持つスクリプト。
次のように入力して、ロードバランサーの両方にファイルを作成します。
- sudo nano /etc/keepalived/master.sh
内部では、と呼ばれる変数を割り当ててエクスポートすることから始めます DO_TOKEN
作成したAPIトークンを保持します。 その下に、という変数を割り当てることができます IP
予約済みIPアドレスを保持します:
export DO_TOKEN='digitalocean_api_token'
IP='reserved_ip_addr'
次に、 curl
現在使用しているサーバーのドロップレットIDをメタデータサービスに要求します。 これは、という変数に割り当てられます ID
. また、このドロップレットに現在予約済みIPアドレスが割り当てられているかどうかも確認します。 そのリクエストの結果をという変数に保存します HAS_RESERVED_IP
:
export DO_TOKEN='digitalocean_api_token'
IP='reserved_ip_addr'
ID=$(curl -s http://169.254.169.254/metadata/v1/id)
HAS_RESERVED_IP=$(curl -s http://169.254.169.254/metadata/v1/reserved_ip/ipv4/active)
これで、上記の変数を使用して、 assign-ip
脚本。 予約済みIPがまだドロップレットに関連付けられていない場合にのみスクリプトを呼び出します。 これにより、API呼び出しを最小限に抑え、マスターステータスがサーバー間で急速に切り替わる場合にAPIへのリクエストの競合を防ぐことができます。
予約済みIPですでにイベントが進行中の場合を処理するために、再試行します。 assign-ip
スクリプトを数回。 以下では、各呼び出しの間隔を3秒にして、スクリプトを10回実行しようとします。 予約済みIPの移動が成功すると、ループはすぐに終了します。
export DO_TOKEN='digitalocean_api_token'
IP='reserved_ip_addr'
ID=$(curl -s http://169.254.169.254/metadata/v1/id)
HAS_RESERVED_IP=$(curl -s http://169.254.169.254/metadata/v1/reserved_ip/ipv4/active)
if [ $HAS_RESERVED_IP = "false" ]; then
n=0
while [ $n -lt 10 ]
do
python /usr/local/bin/assign-ip $IP $ID && break
n=$((n+1))
sleep 3
done
fi
終了したら、ファイルを保存して閉じます。
ここで、スクリプトを実行可能にする必要があります。 keepalived
それを呼び出すことができます:
- sudo chmod +x /etc/keepalived/master.sh
キープアライブサービスを起動し、フェイルオーバーをテストします
The keepalived
これで、デーモンとそのすべてのコンパニオンスクリプトが完全に構成されているはずです。 次のように入力することで、両方のロードバランサーでサービスを開始できます。
- sudo start keepalived
サービスは各サーバーで起動し、そのピアに接続して、構成した共有シークレットで認証する必要があります。 各デーモンはローカルHAProxyプロセスを監視し、リモートからのシグナルをリッスンします keepalived
処理する。
現在予約済みIPアドレスが割り当てられているプライマリロードバランサーは、各バックエンドNginxサーバーに順番にリクエストを送信します。 通常適用されるいくつかの単純なセッションスティッキネスがあり、Webブラウザーを介して要求を行うときに同じバックエンドを取得する可能性が高くなります。
プライマリロードバランサーでHAProxyをオフにするだけで、簡単な方法でフェイルオーバーをテストできます。
- sudo service haproxy stop
ブラウザで予約済みIPアドレスにアクセスすると、ページが見つからなかったことを示すエラーが一時的に表示される場合があります。
http://reserved_IP_addr
ページを数回更新すると、すぐにデフォルトのNginxページが返されます。
HAProxyサービスはプライマリロードバランサーでまだダウンしているため、これはセカンダリロードバランサーが引き継いだことを示しています。 使用する keepalived
、セカンダリサーバーは、サービスの中断が発生したことを判別できました。 次に、「マスター」状態に移行し、DigitalOceanAPIを使用して予約済みIPを要求しました。
これで、プライマリロードバランサーでHAProxyを再度起動できます。
- sudo service haproxy start
プライマリロードバランサーは、予約済みIPアドレスの制御をすぐに回復しますが、これはユーザーにはかなり透過的である必要があります。
移行の視覚化
ロードバランサー間の移行をより適切に視覚化するために、移行中にサーバーログの一部を監視できます。
使用されているプロキシサーバーに関する情報はクライアントに返されないため、ログを表示するのに最適な場所は、実際のバックエンドWebサーバーからです。 これらの各サーバーは、どのクライアントがアセットを要求するかについてのログを維持する必要があります。 Nginxサービスの観点からは、クライアントは実際のクライアントに代わってリクエストを行うロードバランサーです。
Webサーバーのログを追跡する
各バックエンドWebサーバーで、次のことができます。 tail
the /var/log/nginx/access.log
位置。 これにより、サーバーに対して行われた各リクエストが表示されます。 ロードバランサーはラウンドロビンローテーションを使用してトラフィックを均等に分割するため、各バックエンドWebサーバーは行われたリクエストの約半分を確認する必要があります。
幸い、クライアントアドレスはアクセスログの最初のフィールドです。 簡単な方法で値を抽出できます awk
指図。 NginxWebサーバーの両方で以下を実行します。
- sudo tail -f /var/log/nginx/access.log | awk '{print $1;}'
これらは、ほとんど単一のアドレスを表示する可能性があります。
Output. . .
primary_lb_private_IP
primary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
サーバーのIPアドレスを参照すると、これらは主にプライマリロードバランサーからのものであることがわかります。 HAProxyが実装する単純なセッションの粘着性のために、実際の配布は少し異なる可能性があることに注意してください。
維持する tail
両方のWebサーバーで実行されているコマンド。
予約済みIPへのリクエストを自動化
これで、ローカルマシンで、2秒に1回、予約済みIPアドレスのWebコンテンツを要求します。 これにより、ロードバランサーの変更が発生したことを簡単に確認できます。 ローカル端末で、次のように入力します(使用されているロードバランサーに関係なく同じである必要があるため、実際の応答は破棄されます)。
- while true; do curl -s -o /dev/null reserved_IP; sleep 2; done
Webサーバーでは、新しいリクエストが届くのを確認し始める必要があります。 Webブラウザを介して行われるリクエストとは異なり、シンプル curl
リクエストは同じセッションの粘着性を示しません。 バックエンドWebサーバーへのリクエストがより均等に分割されていることがわかります。
プライマリロードバランサーでHAProxyサービスを中断する
これで、プライマリロードバランサーのHAProxyサービスを再びシャットダウンできます。
- sudo service haproxy stop
数秒後、Webサーバーで、IPのリストがプライマリロードバランサーのプライベートIPアドレスからセカンダリロードバランサーのプライベートIPアドレスに移行するのを確認する必要があります。
Output. . .
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
新しいリクエストはすべて、セカンダリロードバランサーから行われます。
次に、プライマリロードバランサーでHAProxyインスタンスを再起動します。
- sudo service haproxy start
クライアントリクエストが数秒以内にプライマリロードバランサーのプライベートIPアドレスに戻るのがわかります。
Output. . .
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
プライマリサーバーは予約済みIPアドレスの制御を取り戻し、インフラストラクチャのメインロードバランサーとしての役割を再開しました。
実際のクライアントIPアドレスをログに記録するようにNginxを構成する
ご覧のとおり、Nginxアクセスログには、すべてのクライアントリクエストが、最初にリクエストを行ったクライアントの実際のIPアドレスではなく、現在のロードバランサーのプライベートIPアドレスからのものであることが示されています(つまり、 ローカルマシン)。 ロードバランサーサーバーではなく、元のクライアントのIPアドレスをログに記録すると便利なことがよくあります。 これは、すべてのバックエンドWebサーバーでNginx構成にいくつかの変更を加えることで簡単に実現できます。
両方のWebサーバーで、 nginx.conf
エディター内のファイル:
- sudo nano /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アドレスです(つまり、 アクティブなロードバランサーサーバー)。
次に、この新しいログ形式を使用するには、デフォルトのサーバーブロックに行を追加する必要があります。
両方のWebサーバーで、 default
サーバー構成:
- sudo nano /etc/nginx/sites-available/default
以内 server
ブロック(真下 listen
ディレクティブは適切な場所です)、次の行を追加します。
access_log /var/log/nginx/access.log haproxy_log;
保存して終了。 これは、Nginxにアクセスログを使用して書き込むように指示します haproxy_log
上で作成したログ形式。
両方のWebサーバーで、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サーバーがバックエンド上のWebサーバーのプールに負荷を分散できるため、この構成は適切に機能します。 需要の拡大または縮小に応じて、このプールを簡単に拡張できます。
予約済みIPと keepalived
構成により、負荷分散レイヤーでの単一障害点が排除され、プライマリロードバランサーに完全な障害が発生した場合でもサービスが機能し続けることができます。 この構成はかなり柔軟性があり、HAProxyサーバーの背後に優先Webスタックを設定することで、独自のアプリケーション環境に適合させることができます。