序章

高可用性は、障害が発生した場合にアプリケーションが作業を自動的に再起動したり、別の対応可能なシステムに再ルーティングしたりできるようにするシステム設計の機能です。 サーバーに関しては、高可用性システムをセットアップするために必要ないくつかの異なるテクノロジーがあります。 作業をリダイレクトできるコンポーネントが必要であり、障害を監視し、中断が検出された場合にシステムを移行するメカニズムが必要です。

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アドレスを取得します。 このコマンドは、ドロップレット内から実行する必要があります。 各ドロップレットに次のように入力します。

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

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

Output
10.132.20.236

アンカーIPアドレスの検索

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

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

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

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

Output
10.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をインストールします。

  1. sudo apt-get update
  2. sudo apt-get install nginx

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

次に、Nginxインスタンスを構成します。 サーバーのプライベートIPアドレスでのみリクエストをリッスンするようにNginxに指示します。 さらに、2つのロードバランサーのプライベートIPアドレスからのリクエストのみを処理します。

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

  1. sudo nano /etc/nginx/sites-available/default

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

/ etc / nginx / sites-available / default
server {
    listen web_server_private_IP:80;

    . . .

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

/ etc / nginx / sites-available / default
server {
    listen web_server_private_IP:80;

    allow load_balancer_1_private_IP;
    allow load_balancer_2_private_IP;
    deny all;

    . . .

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

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

  1. sudo nginx -t

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

  1. sudo service nginx restart

変更のテスト

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

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

  1. curl 127.0.0.1

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

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

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

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

  1. curl web_server_public_IP

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

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

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

  1. 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をインストールします。

  1. sudo apt-get update
  2. sudo apt-get install haproxy

HAProxyを構成する

HAProxyを処理するときに変更する必要がある最初の項目は、 /etc/default/haproxy ファイル。 そのファイルをエディターで今すぐ開きます。

  1. sudo nano /etc/default/haproxy

このファイルは、HAProxyが起動時に起動するかどうかを決定します。 サーバーの電源を入れるたびにサービスを自動的に開始する必要があるため、次の値を変更する必要があります。 ENABLED 「1」へ:

/ etc / default / haproxy
# Set ENABLED to 1 if you want the init script to start haproxy.
ENABLED=1
# Add extra flags here.
#EXTRAOPTS="-de -m 16"

上記の編集を行った後、ファイルを保存して閉じます。

次に、メインのHAProxy構成ファイルを開くことができます。

  1. sudo nano /etc/haproxy/haproxy.cfg

調整する必要がある最初の項目は、HAProxyが動作するモードです。 TCP、つまりレイヤー4の負荷分散を構成します。 これを行うには、を変更する必要があります mode の行 default セクション。 ログを処理する直後のオプションも変更する必要があります。

/etc/haproxy/haproxy.cfg
. . .

defaults
    log     global
    mode    tcp
    option  tcplog

. . .

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

/etc/haproxy/haproxy.cfg
. . .

defaults
    log     global
    mode    tcp
    option  tcplog

. . .

frontend www
    bind    load_balancer_anchor_IP:80
    default_backend nginx_pool

次に、バックエンドセクションを構成できます。 これにより、HAProxyが受信するトラフィックを渡すダウンストリームの場所が指定されます。 この場合、これは、構成した両方のNginxWebサーバーのプライベートIPアドレスになります。 従来のラウンドロビンバランシングを指定し、モードを再び「tcp」に設定します。

/etc/haproxy/haproxy.cfg
. . .

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構文を表していることを確認します。

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

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

  1. sudo service haproxy restart

変更のテスト

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

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

  1. curl 127.0.0.1
  2. curl load_balancer_public_IP
  3. curl load_balancer_private_IP

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

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

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

  1. 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 に対して構築する必要があります:

  1. sudo apt-get install build-essential libssl-dev

依存関係が設定されたら、tarballをダウンロードできます。 keepalived. このページにアクセスして、ソフトウェアの最新バージョンを見つけてください。 最新バージョンを右クリックして、リンクアドレスをコピーします。 サーバーに戻り、ホームディレクトリに移動して使用します wget コピーしたリンクを取得するには:

  1. cd ~
  2. wget http://www.keepalived.org/software/keepalived-1.2.19.tar.gz

使用 tar アーカイブを展開するコマンド。 結果のディレクトリに移動します。

  1. tar xzvf keepalived*
  2. cd keepalived*

次のように入力して、デーモンをビルドしてインストールします。

  1. ./configure
  2. make
  3. sudo make install

これで、デーモンが両方のロードバランサーシステムにインストールされます。

キープアライブアップスタートスクリプトを作成する

The keepalived インストールにより、すべてのバイナリとサポートファイルがシステム上の所定の場所に移動しました。 ただし、含まれていなかったのは、Ubuntu14.04システムのUpstartスクリプトでした。

を処理できる非常に単純なUpstartスクリプトを作成できます keepalived サービス。 というファイルを開きます keepalived.conf 以内 /etc/init 開始するディレクトリ:

  1. sudo nano /etc/init/keepalived.conf

内部では、機能の簡単な説明から始めることができます keepalived 提供します。 付属の説明を使用します man ページ。 次に、サービスを開始および停止するランレベルを指定します。 このサービスをすべての通常の状態(ランレベル2〜5)でアクティブにし、他のすべてのランレベル(たとえば、再起動、電源オフ、またはシングルユーザーモードが開始されたとき)で停止する必要があります。

/etc/init/keepalived.conf
description "load-balancing and high-availability service"

start on runlevel [2345]
stop on runlevel [!2345]

このサービスは、Webサービスを引き続き利用できるようにするために不可欠であるため、障害が発生した場合にこのサービスを再開します。 次に、実際のを指定できます exec サービスを開始する回線。 追加する必要があります --dont-fork Upstartが追跡できるようにするオプション pid 正しく:

/etc/init/keepalived.conf
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 ディレクトリ。 両方のロードバランサーに今すぐそのディレクトリを作成します。

  1. sudo mkdir -p /etc/keepalived

プライマリロードバランサーの構成の作成

次に、プライマリサーバーとして使用するロードバランサーサーバーで、メインを作成します keepalived 構成ファイル。 デーモンは、というファイルを探します keepalived.conf の内側 /etc/keepalived ディレクトリ:

  1. sudo nano /etc/keepalived/keepalived.conf

内部では、HAProxyサービスのヘルスチェックを定義することから始めます。 vrrp_script ブロック。 これにより、 keepalived ロードバランサーの障害を監視して、プロセスがダウンしていることを通知し、対策の回復を開始できるようにします。

チェックはとても簡単です。 2秒ごとに、 haproxy まだ主張している pid:

プライマリサーバーの/etc/keepalived/keepalived.conf
vrrp_script chk_haproxy {
    script "pidof haproxy"
    interval 2
}

次に、というブロックを開きます vrrp_instance. これは、次の方法を定義する主要な構成セクションです。 keepalived 高可用性を実装します。

まずは次のように伝えます keepalived ピアと通信する eth1、私たちのプライベートインターフェース。 プライマリサーバーを構成しているので、 state 「MASTER」への設定。 これは初期値です keepalived デーモンがピアに接続して選挙を行うことができるまで使用します。

選挙中、 priority オプションは、どのメンバーが選出されるかを決定するために使用されます。 決定は、この設定で最も多いサーバーの数に基づいて行われます。 プライマリサーバーには「200」を使用します。

プライマリサーバーの/etc/keepalived/keepalived.conf
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アドレスへ:

プライマリサーバーの/etc/keepalived/keepalived.conf
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文字だけが重要です。

プライマリサーバーの/etc/keepalived/keepalived.conf
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アドレスの再割り当てをトリガーする役割を果たします。 このスクリプトをすぐに作成します。

プライマリサーバーの/etc/keepalived/keepalived.conf
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 セカンダリサーバー:

  1. sudo nano /etc/keepalived/keepalived.conf

内部では、使用するスクリプトはプライマリサーバーのスクリプトとほぼ同じです。 変更する必要がある項目は次のとおりです。

  • state:選択が行われる前にノードがバックアップ状態に初期化されるように、これをセカンダリサーバーで「バックアップ」に変更する必要があります。
  • priority:これは、プライマリサーバーよりも低い値に設定する必要があります。 このガイドでは、値「100」を使用します。
  • unicast_src_ip:これは、セカンダリサーバーのプライベートIPアドレスである必要があります。
  • unicast_peer:これには、プライマリサーバーのプライベートIPアドレスが含まれている必要があります。

これらの値を変更すると、セカンダリサーバーのスクリプトは次のようになります。

セカンダリサーバーの/etc/keepalived/keepalived.conf
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 ディレクトリ:

  1. cd /usr/local/bin
  2. sudo curl -LO http://do.co/assign-ip

このスクリプトを使用すると、次のコマンドを実行して既存の予約済みIPを再割り当てできます。

  1. 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 正しいクレデンシャルを持つスクリプト。

次のように入力して、ロードバランサーの両方にファイルを作成します。

  1. sudo nano /etc/keepalived/master.sh

内部では、と呼ばれる変数を割り当ててエクスポートすることから始めます DO_TOKEN 作成したAPIトークンを保持します。 その下に、という変数を割り当てることができます IP 予約済みIPアドレスを保持します:

/etc/keepalived/master.sh
export DO_TOKEN='digitalocean_api_token'
IP='reserved_ip_addr'

次に、 curl 現在使用しているサーバーのドロップレットIDをメタデータサービスに要求します。 これは、という変数に割り当てられます ID. また、このドロップレットに現在予約済みIPアドレスが割り当てられているかどうかも確認します。 そのリクエストの結果をという変数に保存します HAS_RESERVED_IP:

/etc/keepalived/master.sh
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の移動が成功すると、ループはすぐに終了します。

/etc/keepalived/master.sh
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 それを呼び出すことができます:

  1. sudo chmod +x /etc/keepalived/master.sh

キープアライブサービスを起動し、フェイルオーバーをテストします

The keepalived これで、デーモンとそのすべてのコンパニオンスクリプトが完全に構成されているはずです。 次のように入力することで、両方のロードバランサーでサービスを開始できます。

  1. sudo start keepalived

サービスは各サーバーで起動し、そのピアに接続して、構成した共有シークレットで認証する必要があります。 各デーモンはローカルHAProxyプロセスを監視し、リモートからのシグナルをリッスンします keepalived 処理する。

現在予約済みIPアドレスが割り当てられているプライマリロードバランサーは、各バックエンドNginxサーバーに順番にリクエストを送信します。 通常適用されるいくつかの単純なセッションスティッキネスがあり、Webブラウザーを介して要求を行うときに同じバックエンドを取得する可能性が高くなります。

プライマリロードバランサーでHAProxyをオフにするだけで、簡単な方法でフェイルオーバーをテストできます。

  1. sudo service haproxy stop

ブラウザで予約済みIPアドレスにアクセスすると、ページが見つからなかったことを示すエラーが一時的に表示される場合があります。

http://reserved_IP_addr

ページを数回更新すると、すぐにデフォルトのNginxページが返されます。

HAProxyサービスはプライマリロードバランサーでまだダウンしているため、これはセカンダリロードバランサーが引き継いだことを示しています。 使用する keepalived、セカンダリサーバーは、サービスの中断が発生したことを判別できました。 次に、「マスター」状態に移行し、DigitalOceanAPIを使用して予約済みIPを要求しました。

これで、プライマリロードバランサーでHAProxyを再度起動できます。

  1. sudo service haproxy start

プライマリロードバランサーは、予約済みIPアドレスの制御をすぐに回復しますが、これはユーザーにはかなり透過的である必要があります。

移行の視覚化

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

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

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

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

幸い、クライアントアドレスはアクセスログの最初のフィールドです。 簡単な方法で値を抽出できます awk 指図。 NginxWebサーバーの両方で以下を実行します。

  1. 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コンテンツを要求します。 これにより、ロードバランサーの変更が発生したことを簡単に確認できます。 ローカル端末で、次のように入力します(使用されているロードバランサーに関係なく同じである必要があるため、実際の応答は破棄されます)。

  1. while true; do curl -s -o /dev/null reserved_IP; sleep 2; done

Webサーバーでは、新しいリクエストが届くのを確認し始める必要があります。 Webブラウザを介して行われるリクエストとは異なり、シンプル curl リクエストは同じセッションの粘着性を示しません。 バックエンドWebサーバーへのリクエストがより均等に分割されていることがわかります。

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

これで、プライマリロードバランサーのHAProxyサービスを再びシャットダウンできます。

  1. 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インスタンスを再起動します。

  1. 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 エディター内のファイル:

  1. sudo nano /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 value —元の要求を行ったクライアントのIPアドレス—デフォルトのアクセスログエントリ。 私たちも含まれています $remote_addr、これはリバースプロキシロードバランサーのIPアドレスです(つまり、 アクティブなロードバランサーサーバー)。

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

両方のWebサーバーで、 default サーバー構成:

  1. sudo nano /etc/nginx/sites-available/default

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

/ etc / nginx / sites-available/defaultに追加
        access_log /var/log/nginx/access.log haproxy_log;

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

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

  1. 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スタックを設定することで、独自のアプリケーション環境に適合させることができます。