Ubuntu 14.04でCorosync、Pacemaker、およびフローティングIPを使用して高可用性HAProxyセットアップを作成する方法

投稿日: 2019-11-08 2022-04-20
タグ: High Availability, Load Balancing, Networking, Scaling, ubuntu

序章

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

High Availability HAProxy setup

ノート： 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アドレスを検索する

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アドレスを検索する

アンカー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アドレスを認識しません。

Output
curl: (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つ

getdocs

13036