Ubuntu14.04でキープアライブおよび予約済みIPを使用して高可用性Webサーバーをセットアップする方法

序章

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

The keepalived デーモンを使用して、サービスまたはシステムを監視し、問題が発生した場合にスタンバイに自動的にフェイルオーバーすることができます。 このガイドでは、使用方法を示します keepalived 高可用性Webサービスをセットアップします。 2つの対応するWebサーバー間で移動できる予約済みIPアドレスを構成します。 プライマリサーバーがダウンした場合、予約済みIPは自動的に2番目のサーバーに移動され、サービスを再開できるようになります。

前提条件

このガイドを完了するには、DigitalOceanアカウントに2つのUbuntu14.04サーバーを作成する必要があります。 両方のサーバーが同じデータセンター内に配置され、プライベートネットワークが有効になっている必要があります。

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

開始する準備ができたら、root以外のユーザーで両方のサーバーにログインします。

Nginxをインストールして構成する

その間 keepalived ロードバランサーの監視とフェイルオーバーによく使用されます。運用の複雑さを軽減するために、このガイドではNginxを単純なWebサーバーとして使用します。

まず、各サーバーのローカルパッケージインデックスを更新します。 次に、Nginxをインストールできます。

sudo apt-get update
sudo apt-get install nginx

ほとんどの場合、可用性の高いセットアップでは、両方のサーバーがまったく同じコンテンツを提供する必要があります。 ただし、わかりやすくするために、このガイドではNginxを使用して、2つのサーバーのどちらがいつでもリクエストを処理しているかを示します。 これを行うには、デフォルトを変更します index.html 各ホストのページ。 今すぐファイルを開きます。

sudo nano /usr/share/nginx/html/index.html

最初のサーバーで、ファイルの内容を次のように置き換えます。

<h1>Primary</h1>

2番目のサーバーで、ファイルの内容を次のように置き換えます。

<h1>Secondary</h1>

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

キープアライブのビルドとインストール

次に、をインストールします 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

サーバーのプライベートIPアドレスを収集する

構成ファイルを作成する前に、両方のサーバーのプライベートIPアドレスを見つける必要があります。 DigitalOceanサーバーでは、次のように入力することで、メタデータサービスを介してプライベートIPアドレスを取得できます。

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

Output
10.132.7.107

これは、 iproute2 次のように入力してツールを入力します。

ip -4 addr show dev eth1

あなたが探している価値はここにあります：

Output
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 10.132.7.107/16 brd 10.132.255.255 scope global eth1
       valid_lft forever preferred_lft forever

この値を両方のシステムからコピーします。 以下の構成ファイル内でこれらのアドレスを参照する必要があります。

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

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

sudo nano /etc/keepalived/keepalived.conf

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

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

vrrp_script chk_nginx {
    script "pidof nginx"
    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 以前に取得したprimaryサーバーのプライベートIPアドレスに。 設定します unicast_peer セカンダリサーバーのプライベートIPアドレスへ：

vrrp_script chk_nginx {
    script "pidof nginx"
    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_nginx {
    script "pidof nginx"
    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_nginx、ローカルシステムの状態を判断します。 最後に、 notify_master スクリプト。このノードがペアの「マスター」になるたびに実行されます。 このスクリプトは、予約済みIPアドレスの再割り当てをトリガーする役割を果たします。 このスクリプトをすぐに作成します。

vrrp_script chk_nginx {
    script "pidof nginx"
    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_nginx
    }

    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_nginx {
    script "pidof nginx"
    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_nginx
    }

    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にアクセスすると、「プライマリ」サーバーが表示されます。 index.html ページ：

予約済み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

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

両方のサーバーが正常な状態で、Webブラウザーで予約済みIPにアクセスすると、プライマリサーバーのNginxページに移動する必要があります。

これで、構成のフェイルオーバー機能をテストする準備が整いました。

次のいずれかの条件が発生した場合、フェイルオーバーが発生するはずです。

• プライマリサーバーのNginxヘルスチェックでNginxが実行されていないことが示された場合。この場合、プライマリサーバーの keepalived デーモンは「障害」状態になります。 セカンダリサーバーにマスター状態に移行する必要があることを通知し、予約済みIPを要求します。
• セカンダリサーバーがプライマリサーバーへのキープアライブ接続を失ったとき。 セカンダリサーバーが何らかの理由でプライマリサーバーに到達できない場合、セカンダリサーバーは「マスター」状態に移行し、予約済みIPの要求を試みます。

プライマリサーバーが後で回復した場合、新しい選択が開始されるため、プライマリサーバーはマスター状態に戻り、予約済みIPを再利用します（引き続き最高の優先順位番号が付けられます）。

Nginxの失敗のテスト

プライマリサーバーでNginxサービスを停止することで、最初の条件をテストできます。

sudo service nginx stop

Webブラウザーを更新すると、最初にページが使用できないことを示す応答が返される場合があります。

ただし、ほんの数秒後、ページを数回更新すると、セカンダリサーバーが予約済みIPアドレスを要求していることがわかります。

プライマリサーバーでNginxデーモンを再起動することで、障害から回復できます。

sudo service nginx start

数秒後、ページを更新すると、プライマリサーバーが予約済みIPの所有権を再び取り戻したことがわかります。

サーバー障害のテスト

テストする必要があるもう1つのシナリオは、プライマリサーバーに接続できない場合に、セカンダリがマスター状態に正しく移行するかどうかです。 マスターサーバーを再起動して、これをテストできます。

sudo reboot

ここでも、最初に予約済みIPアドレスでサービスの中断が発生するはずです。

数秒後、セカンダリサーバーがリクエストを取得します。

しばらくして、プライマリサーバーが再起動を完了すると、IPアドレスが再利用されます。

これにより、2番目の障害シナリオが検証されます。

結論

このガイドでは、を使用して高可用性Webサーバー環境を構成しました keepalived、DigitalOcean API、および予約済みIPアドレス。 実際のインフラストラクチャはかなり単純でしたが、この概念は、サービスの可用性と稼働時間が重要なあらゆるタイプのインフラストラクチャに適用できます。