Ubuntu 14.04でCorosync、Pacemaker、およびフローティングIPを使用して高可用性セットアップを作成する方法
序章
このチュートリアルでは、CorosyncとPacemakerをフローティングIPとともに使用して、DigitalOcean上に高可用性(HA)サーバーインフラストラクチャを作成する方法を示します。
Corosyncは、クラスターメンバーシップおよびメッセージング機能(メッセージングレイヤーとも呼ばれる)をクライアントサーバーに提供するオープンソースプログラムです。 Pacemakerは、オープンソースのクラスターリソースマネージャー(CRM)であり、クラスターによって管理され、高可用性を実現するリソースとサービスを調整するシステムです。 本質的に、Corosyncはサーバーがクラスターとして通信できるようにし、Pacemakerはクラスターの動作を制御する機能を提供します。
ゴール
完了すると、HAセットアップはアクティブ/パッシブ構成の2台のUbuntu14.04サーバーで構成されます。 これは、障害が検出されない限り、ユーザーがWebサービスにアクセスする方法であるフローティングIPをポイントして、プライマリ(アクティブ)サーバーをポイントすることによって実現されます。 Pacemakerがプライマリサーバーが利用できないことを検出した場合、セカンダリ(パッシブ)サーバーは、DigitalOceanAPIを介してフローティングIPを自身に再割り当てするスクリプトを自動的に実行します。 したがって、フローティングIPへの後続のネットワークトラフィックはセカンダリサーバーに転送されます。セカンダリサーバーはアクティブサーバーとして機能し、着信トラフィックを処理します。
この図は、説明されているセットアップの概念を示しています。
注:このチュートリアルでは、ゲートウェイレベルでのアクティブ/パッシブ高可用性の設定についてのみ説明します。 つまり、フローティングIPと、ロードバランサーサーバー(プライマリおよびセカンダリ)が含まれます。 さらに、デモンストレーションの目的で、各サーバーでリバースプロキシロードバランサーを構成する代わりに、それぞれのホスト名とパブリックIPアドレスで応答するようにサーバーを構成するだけです。
この目標を達成するために、次の手順に従います。
- トラフィックを受信する2つのドロップレットを作成します
- フローティングIPを作成し、ドロップレットの1つに割り当てます
- Corosyncをインストールして構成します
- Pacemakerをインストールして構成します
- フローティングIP再割り当てクラスターリソースの構成
- フェイルオーバーのテスト
- Nginxクラスターリソースを構成する
前提条件
フローティングIPの再割り当てを自動化するには、DigitalOceanAPIを使用する必要があります。 つまり、Personal Access Token(PAT)を生成する必要があります。これは、DigitalOceanアカウントへの認証に使用できるAPIトークンであり、次の方法で読み取りおよび書き込みアクセスが可能です。 APIチュートリアルのパーソナルアクセストークンの生成方法セクション。 PATは、クラスター内の両方のサーバーに追加されるスクリプトで使用されるため、参照用に、DigitalOceanアカウントへのフルアクセスを許可するため、安全な場所に保管してください。
APIに加えて、このチュートリアルでは次のDigitalOcean機能を利用します。
それらについてもっと知りたい場合は、リンクされたチュートリアルを読んでください。
ドロップレットを作成する
最初のステップは、プライベートネットワークを有効にして2つのUbuntuドロップレットを同じデータセンターに作成することです。これは、上記のプライマリサーバーとセカンダリサーバーとして機能します。 セットアップ例では、簡単に参照できるように「プライマリ」と「セカンダリ」という名前を付けます。 両方のドロップレットにNginxをインストールし、それらのインデックスページをそれらを一意に識別する情報に置き換えます。 これにより、HAセットアップが機能していることを簡単に示すことができます。 実際のセットアップでは、サーバーはNginxやHAProxyなどの選択したWebサーバーまたはロードバランサーを実行する必要があります。
2つのUbuntu14.04ドロップレット、primaryとsecondaryを作成します。 セットアップ例に従う場合は、次の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アドレスを介していずれかのドロップレットにアクセスすると、ドロップレットのホスト名とIPアドレスが記載された基本的なWebページが表示されます。これは、フローティングIPが任意の時点で指しているドロップレットをテストするのに役立ちます。
フローティングIPを作成する
DigitalOceanコントロールパネルで、トップメニューのネットワークをクリックし、次にサイドメニューのフローティングIPをクリックします。
プライマリドロップレットにフローティングIPを割り当て、フローティングIPボタンをクリックします。
フローティングIPが割り当てられたら、そのIPアドレスをメモします。 WebブラウザでフローティングIPアドレスにアクセスして、割り当てられたドロップレットに到達できることを確認します。
http://your_floating_ip
プライマリドロップレットのインデックスページが表示されます。
DNSの構成(オプション)
ドメイン名を介してHAセットアップにアクセスできるようにする場合は、先に進んで、ドメインがフローティングIPアドレスを指すAレコードをDNSに作成します。 ドメインでDigitalOceanのネームサーバーを使用している場合は、DigitalOceanチュートリアルでホスト名を設定する方法のステップ3に従ってください。 それが伝播すると、ドメイン名を介してアクティブなサーバーにアクセスできます。
使用するドメイン名の例はexample.com
です。 現在使用するドメイン名がない場合は、代わりにフローティングIPアドレスを使用してセットアップにアクセスします。
時間同期の構成
複数のサーバーが相互に通信している場合、特にクラスタリングソフトウェアを使用している場合は常に、それらのサーバーのクロックが同期していることを確認することが重要です。 NTP(Network Time Protocol)を使用してサーバーを同期します。
両方のサーバーで、次のコマンドを使用してタイムゾーンセレクターを開きます。
- sudo dpkg-reconfigure tzdata
希望のタイムゾーンを選択します。 たとえば、America/New_York
を選択します。
次に、apt-getを更新します。
- sudo apt-get update
次に、このコマンドを使用してntp
パッケージをインストールします。
- sudo apt-get -y install ntp
これで、サーバーのクロックがNTPを使用して同期されるはずです。 NTPの詳細については、次のチュートリアルを確認してください:タイムゾーンとネットワークタイムプロトコルの同期の構成。
ファイアウォールを構成する
Corosyncは、ポート5404
と5406
の間でUDPトランスポートを使用します。 ファイアウォールを実行している場合は、それらのポートでの通信がサーバー間で許可されていることを確認してください。
たとえば、iptables
を使用している場合、次のコマンドを使用して、これらのポートとeth1
(プライベートネットワークインターフェイス)でのトラフィックを許可できます。
- sudo iptables -A INPUT -i eth1 -p udp -m multiport --dports 5404,5405,5406 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
- sudo iptables -A OUTPUT -o eth1 -p udp -m multiport --sports 5404,5405,5406 -m conntrack --ctstate ESTABLISHED -j ACCEPT
提供されている例よりも制限の厳しいファイアウォールルールを使用することをお勧めします。
CorosyncとPacemakerをインストールします
両方のサーバーで、apt-getを使用してCorosyncとPacemakerをインストールします。
- sudo apt-get install pacemaker
CorosyncはPacemakerパッケージの依存関係としてインストールされることに注意してください。
これでCorosyncとPacemakerがインストールされましたが、何か便利なことをする前に構成する必要があります。
Corosyncを構成する
サーバーがクラスターとして通信できるように、Corosyncを構成する必要があります。
クラスター認証キーの作成
ノードがクラスターに参加できるようにするために、Corosyncは各ノードが同一のクラスター認証キーを所有していることを要求します。
プライマリサーバーに、haveged
パッケージをインストールします。
- sudo apt-get install haveged
このソフトウェアパッケージを使用すると、corosync-keygen
スクリプトで必要とされるサーバー上のエントロピーの量を簡単に増やすことができます。
プライマリサーバーで、corosync-keygen
スクリプトを実行します。
- sudo corosync-keygen
これにより、128バイトのクラスター認証キーが生成され、/etc/corosync/authkey
に書き込まれます。
haveged
パッケージが不要になったので、プライマリサーバーからパッケージを削除しましょう。
- sudo apt-get remove --purge haveged
- sudo apt-get clean
プライマリサーバーで、authkey
をセカンダリサーバーにコピーします。
- sudo scp /etc/corosync/authkey username@secondary_ip:/tmp
セカンダリサーバーで、authkey
ファイルを適切な場所に移動し、そのアクセス許可をルートに制限します。
- sudo mv /tmp/authkey /etc/corosync
- sudo chown root: /etc/corosync/authkey
- sudo chmod 400 /etc/corosync/authkey
これで、両方のサーバーの/etc/corosync/authkey
ファイルに同じ認証キーが必要になります。
Corosyncクラスターを構成する
目的のクラスターを起動して実行するには、これらを設定する必要があります
両方のサーバーで、corosync.conf
ファイルを開いて、お気に入りのエディターで編集します(vi
を使用します)。
- sudo vi /etc/corosync/corosync.conf
これは、サーバーがクラスターとして通信できるようにするCorosync構成ファイルです。 強調表示された部分を適切な値に置き換えてください。 bindnetaddr
は、現在作業しているサーバーのプライベートIPアドレスに設定する必要があります。 他の2つの強調表示された項目は、指定されたサーバーのプライベートIPアドレスに設定する必要があります。 bindnetaddr
を除いて、ファイルは両方のサーバーで同一である必要があります。
corosync.conf
の内容を次の構成に置き換え、ご使用の環境に固有の変更を加えます。
- totem {
- version: 2
- cluster_name: lbcluster
- transport: udpu
- interface {
- ringnumber: 0
- bindnetaddr: server_private_IP_address
- broadcast: yes
- mcastport: 5405
- }
- }
-
- quorum {
- provider: corosync_votequorum
- two_node: 1
- }
-
- nodelist {
- node {
- ring0_addr: primary_private_IP_address
- name: primary
- nodeid: 1
- }
- node {
- ring0_addr: secondary_private_IP_address
- name: secondary
- nodeid: 2
- }
- }
-
- logging {
- to_logfile: yes
- logfile: /var/log/corosync/corosync.log
- to_syslog: yes
- timestamp: on
- }
トーテムセクション(1〜11行目)は、Corosyncがクラスターメンバーシップに使用するトーテムプロトコルを参照し、クラスターメンバーが相互に通信する方法を指定します。 このセットアップでは、重要な設定にはtransport: udpu
(ユニキャストモードを指定)とbindnetaddr
(Corosyncがバインドするネットワークアドレスを指定)が含まれます。
クォーラムセクション(13〜16行目)は、これが2ノードクラスターであることを指定しているため、クォーラムに必要なノードは1つだけです(two_node: 1
)。 これは、クォーラムを達成するにはクラスター内に少なくとも3つのノードが必要であるという事実の回避策です。 この設定により、2ノードクラスターがコーディネーター(DC)を選出できるようになります。これは、任意の時点でクラスターを制御するノードです。
nodelist セクション(18〜29行目)は、クラスター内の各ノードと、各ノードに到達する方法を指定します。 ここでは、プライマリノードとセカンダリノードの両方を構成し、それぞれのプライベートIPアドレスを介して到達できるように指定します。
logging セクション(31〜36行目)は、Corosyncログを/var/log/corosync/corosync.log
に書き込む必要があることを指定しています。 このチュートリアルの残りの部分で問題が発生した場合は、トラブルシューティング中に必ずここを参照してください。
保存して終了。
次に、Pacemakerサービスを許可するようにCorosyncを構成する必要があります。
両方のサーバーで、エディターを使用してCorosyncサービスディレクトリにpcmk
ファイルを作成します。 vi
を使用します:
- sudo vi /etc/corosync/service.d/pcmk
次に、Pacemakerサービスを追加します。
service {
name: pacemaker
ver: 1
}
保存して終了。 これはCorosync構成に含まれ、PacemakerがCorosyncを使用してサーバーと通信できるようにします。
デフォルトでは、Corosyncサービスは無効になっています。 両方のサーバーで、/etc/default/corosync
を編集して変更します。
- sudo vi /etc/default/corosync
START
の値をyes
に変更します。
START=yes
保存して終了。 これで、Corosyncサービスを開始できます。
両方のサーバーで、次のコマンドを使用してCorosyncを起動します。
- sudo service corosync start
Corosyncが両方のサーバーで実行されたら、それらを一緒にクラスター化する必要があります。 これは、次のコマンドを実行して確認できます。
- sudo corosync-cmapctl | grep members
出力は次のようになります。これは、プライマリ(ノード1)とセカンダリ(ノード2)がクラスターに参加したことを示しています。
corosync-cmapctl output:runtime.totem.pg.mrp.srp.members.1.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.1.ip (str) = r(0) ip(primary_private_IP_address)
runtime.totem.pg.mrp.srp.members.1.join_count (u32) = 1
runtime.totem.pg.mrp.srp.members.1.status (str) = joined
runtime.totem.pg.mrp.srp.members.2.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.2.ip (str) = r(0) ip(secondary_private_IP_address)
runtime.totem.pg.mrp.srp.members.2.join_count (u32) = 1
runtime.totem.pg.mrp.srp.members.2.status (str) = joined
Corosyncが正しくセットアップされたので、Pacemakerの構成に移りましょう。
Pacemakerを起動して構成する
これで、Corosyncのメッセージング機能に依存するPacemakerを起動し、基本的なプロパティを構成する準備が整いました。
Pacemakerを有効にして起動します
Pacemakerサービスでは、Corosyncが実行されている必要があるため、デフォルトで無効になっています。
両方のサーバーで、次のコマンドを使用してPacemakerがシステムの起動時に起動できるようにします。
- sudo update-rc.d pacemaker defaults 20 01
前のコマンドで、ペースメーカーの開始優先度を20
に設定しました。 PacemakerがCorosyncの後に開始するように、Corosyncよりも高い開始優先度(デフォルトでは19
)を指定することが重要です。
それでは、ペースメーカーを起動しましょう。
- sudo service pacemaker start
Pacemakerと対話するには、crm
ユーティリティを使用します。
crm
でペースメーカーを確認してください。
- sudo crm status
これにより、次のように出力されます(そうでない場合は、30秒待ってから、コマンドを再実行してください)。
crm status:Last updated: Fri Oct 16 14:38:36 2015
Last change: Fri Oct 16 14:36:01 2015 via crmd on primary
Stack: corosync
Current DC: primary (1) - partition with quorum
Version: 1.1.10-42f2063
2 Nodes configured
0 Resources configured
Online: [ primary secondary ]
この出力について注意すべき点がいくつかあります。 まず、現在のDC (指定コーディネーター)をprimary (1)
またはsecondary (2)
に設定する必要があります。 次に、2ノードが構成されているおよび0リソースが構成されている必要があります。 第三に、両方のノードをonlineとしてマークする必要があります。 オフラインとマークされている場合は、30秒待ってから、ステータスをもう一度確認して、自動的に修正されるかどうかを確認してください。
この時点から、別のSSHウィンドウ(いずれかのクラスターノードに接続されている)でインタラクティブCRMモニターを実行することをお勧めします。 これにより、各ノードのステータスと各リソースが実行されている場所をリアルタイムで更新できます。
- sudo crm_mon
このコマンドの出力は、継続的に実行されることを除いて、crm status
の出力と同じように見えます。 終了する場合は、Ctrl-C
を押してください。
クラスタープロパティの構成
これで、Pacemakerの基本的なプロパティを構成する準備が整いました。 すべてのPacemaker(crm
)コマンドは、すべてのメンバーノード間ですべてのクラスター関連の変更を自動的に同期するため、どちらのノードサーバーからでも実行できることに注意してください。
2ノードのクラスターをセットアップしているため、目的のセットアップでは、STONITH(多くのクラスターが障害のあるノードを削除するために使用するモード)を無効にします。 これを行うには、いずれかのサーバーで次のコマンドを実行します。
- sudo crm configure property stonith-enabled=false
また、ログ内のクォーラム関連のメッセージを無効にします。
- sudo crm configure property no-quorum-policy=ignore
この場合も、この設定は2ノードクラスターにのみ適用されます。
Pacemakerの構成を確認する場合は、次のコマンドを実行します。
- sudo crm configure show
これにより、アクティブなペースメーカー設定がすべて表示されます。 現在、これには2つのノードと、設定したSTONITHプロパティとクォーラムプロパティのみが含まれます。
フローティングIP再割り当てリソースエージェントの作成
Pacemakerが実行および構成されたので、Pacemakerが管理するためのリソースを追加する必要があります。 はじめに述べたように、リソースはクラスターが高可用性を実現するために担当するサービスです。 Pacemakerでは、リソースを追加するには、リソースエージェントを使用する必要があります。これは、管理されるサービスへのインターフェイスとして機能します。 Pacemakerには、共通サービス用のいくつかのリソースエージェントが付属しており、カスタムリソースエージェントを追加できます。
セットアップでは、Webサーバープライマリおよびセカンダリによって提供されるサービスがアクティブ/パッシブセットアップで高可用性であることを確認する必要があります。つまり、フローティングIPが常に利用可能なサーバーを指していることを確認する方法。 これを有効にするには、各ノードが実行できるリソースエージェントを設定して、ノードがフローティングIPを所有しているかどうかを判断し、必要に応じて、スクリプトを実行してフローティングIPを自身にポイントする必要があります。 リソースエージェントを「FloatIPOCF」と呼び、FloatingIP再割り当てスクリプトをassign-ip
と呼びます。 FloatIP OCFリソースエージェントをインストールしたら、リソース自体を定義できます。これをFloatIP
と呼びます。
割り当てIPスクリプトをダウンロード
先ほど述べたように、FloatIP
リソースを別のノードに移動する必要がある場合に備えて、フローティングIPが指しているドロップレットを再割り当てできるスクリプトが必要です。 この目的のために、DigitalOcean APIを使用して、特定のドロップレットIDにフローティングIPを割り当てる基本的なPythonスクリプトをダウンロードします。
両方のサーバーで、assign-ip
Pythonスクリプトをダウンロードします。
- sudo curl -L -o /usr/local/bin/assign-ip http://do.co/assign-ip
両方のサーバーで、実行可能にします。
- sudo chmod +x /usr/local/bin/assign-ip
assign-ip
スクリプトを使用するには、次の詳細が必要です。
- フローティングIP:スクリプトの最初の引数、割り当てられているフローティングIP
- ドロップレットID:スクリプトの2番目の引数、フローティングIPを割り当てる必要のあるドロップレットID
- DigitalOcean PAT(APIトークン):環境変数
DO_TOKEN
として渡され、読み取り/書き込みDigitalOcean PAT
続行する前に、スクリプトの内容を確認してください。
したがって、このスクリプトを手動で実行してフローティングIPを再割り当てする場合は、DO_TOKEN=your_digitalocean_pat /usr/local/bin/assign-ip your_floating_ip droplet_id
のように実行できます。 ただし、このスクリプトは、FloatIP
リソースを別のノードに移動する必要がある場合にFloatIPOCFリソースエージェントから呼び出されます。
次に、Float IPResourceAgentをインストールしましょう。
FloatIPOCFリソースエージェントをダウンロードする
Pacemakerでは、OCFリソースエージェントを特定のディレクトリに配置することにより、それらを追加できます。
両方のサーバーで、次のコマンドを使用してdigitalocean
リソースエージェントプロバイダーディレクトリを作成します。
- sudo mkdir /usr/lib/ocf/resource.d/digitalocean
両方のサーバーで、FloatIPOCFリソースエージェントをダウンロードします。
- sudo curl -o /usr/lib/ocf/resource.d/digitalocean/floatip https://gist.githubusercontent.com/thisismitch/b4c91438e56bfe6b7bfb/raw/2dffe2ae52ba2df575baae46338c155adbaef678/floatip-ocf
両方のサーバーで、実行可能にします。
- sudo chmod +x /usr/lib/ocf/resource.d/digitalocean/floatip
続行する前に、リソースエージェントの内容を確認してください。 これはbashスクリプトであり、start
コマンドで呼び出されると、それを呼び出すノードのドロップレットIDを(メタデータを介して)検索し、フローティングIPをドロップレットIDに割り当てます。 また、status
およびmonitor
コマンドに応答して、呼び出し元のドロップレットにフローティングIPが割り当てられているかどうかを返します。
次のOCFパラメーターが必要です。
- do_token::フローティングIPの再割り当てに使用するDigitalOcean APIトークン、つまり DigitalOceanパーソナルアクセストークン
- float_ip::再割り当てが必要な場合のフローティングIP(アドレス)
これで、FloatIP OCFリソースエージェントを使用して、FloatIP
リソースを定義できます。
FloatIPリソースを追加する
FloatIP OCFリソースエージェントをインストールすると、FloatIP
リソースを構成できるようになります。
どちらのサーバーでも、次のコマンドを使用してFloatIP
リソースを作成します(強調表示された2つのパラメーターを独自の情報で指定してください)。
- sudo crm configure primitive FloatIP ocf:digitalocean:floatip \
- params do_token=your_digitalocean_personal_access_token \
- floating_ip=your_floating_ip
これにより、前に作成したFloatIP OCFリソースエージェント(ocf:digitalocean:floatip
)を使用して、「FloatIP」と呼ばれる汎用タイプのクラスターリソースであるプリミティブリソースが作成されます。 do_token
とfloating_ip
をパラメーターとして渡す必要があることに注意してください。 これらは、フローティングIPを再割り当てする必要がある場合に使用されます。
クラスタのステータス(sudo crm status
またはsudo crm_mon
)を確認すると、FloatIP
リソースが定義されてノードの1つで開始されていることがわかります。
crm_mon:...
2 Nodes configured
1 Resource configured
Online: [ primary secondary ]
FloatIP (ocf::digitalocean:floatip): Started primary
すべてが適切に設定されていると仮定すると、アクティブ/パッシブHAが設定されているはずです。 現状では、FloatIP
が開始されているノードがオフラインになるか、standby
モードになると、フローティングIPがオンラインサーバーに再割り当てされます。 現在、アクティブノード(この例では出力例では primary )が使用できなくなった場合、クラスターは SecondaryノードにFloatIP
リソースを開始し、それ自体のフローティングIPアドレス。 再割り当てが発生すると、フローティングIPはユーザーを新しくアクティブなセカンダリサーバーに誘導します。
現在、フェイルオーバー(Floating IP reassignment)は、アクティブなホストがオフラインになるか、クラスターと通信できない場合にのみトリガーされます。 この設定のより良いバージョンは、Pacemakerによって管理されるべき追加のリソースを指定します。 これにより、クラスターはロードバランサーやWebサーバーソフトウェアなどの特定のサービスの障害を検出できます。 ただし、これを設定する前に、基本的なフェイルオーバーが機能することを確認する必要があります。
高可用性のテスト
高可用性のセットアップが機能することをテストすることが重要なので、今すぐ実行しましょう。
現在、フローティングIPはノードの1つに割り当てられています(プライマリと仮定します)。 IPアドレスまたはそれを指しているドメイン名を介してフローティングIPにアクセスすると、プライマリサーバーのインデックスページが表示されます。 サンプルのユーザーデータスクリプトを使用した場合、次のようになります。
Floating IP is pointing to primary server:Droplet: primary, IP Address: primary_ip_address
これは、フローティングIPが実際にプライマリドロップレットに割り当てられていることを示しています。
次に、新しいローカル端末を開き、curl
を使用して1秒のループでフローティングIPにアクセスしましょう。 これを行うには、次のコマンドを使用しますが、URLをドメインまたはフローティングIPアドレスに置き換えてください。
- while true; do curl floating_IP_address; sleep 1; done
現在、これはプライマリサーバーと同じドロップレット名とIPアドレスを出力します。 プライマリサーバーの電源を切るか、プライマリノードのクラスターステータスをstandby
に変更することでプライマリサーバーに障害が発生した場合、フローティングIPがセカンダリサーバーに再割り当てされるかどうかを確認します。
プライマリサーバーを再起動しましょう。 これを行うには、DigitalOceanコントロールパネルを使用するか、プライマリサーバーで次のコマンドを実行します。
- sudo reboot
しばらくすると、プライマリサーバーが使用できなくなります。 端末で実行されているcurl
ループの出力に注意してください。 次のような出力に注意してください。
curl loop output:Droplet: primary, IP Address: primary_IP_address
...
curl: (7) Failed to connect to floating_IP_address port 80: Connection refused
Droplet: secondary, IP Address: secondary_IP_address
...
つまり、セカンダリサーバーのIPアドレスを指すように、フローティングIPアドレスを再割り当てする必要があります。 これは、自動フェイルオーバーが成功したため、HAセットアップが機能していることを意味します。
Connection refused
エラーが表示される場合と表示されない場合があります。このエラーは、プライマリサーバーの障害とフローティングIPの再割り当ての完了の間にフローティングIPにアクセスしようとした場合に発生する可能性があります。
Pacemakerのステータスを確認すると、FloatIP
リソースがセカンダリサーバーで開始されていることがわかります。 また、プライマリサーバーは一時的にOFFLINE
としてマークする必要がありますが、再起動が完了してクラスターに再参加するとすぐにOnline
リストに参加します。
フェイルオーバーのトラブルシューティング(オプション)
HAセットアップが期待どおりに機能する場合は、このセクションをスキップしてください。 フェイルオーバーが期待どおりに発生しなかった場合は、先に進む前にセットアップを確認する必要があります。 特に、ノードIPアドレス、フローティングIP、APIトークンなど、独自の設定への参照があることを確認してください。
トラブルシューティングに役立つコマンド
セットアップのトラブルシューティングに役立つコマンドを次に示します。
前述のように、crm_mon
ツールは、ノードとリソースのリアルタイムステータスを表示するのに非常に役立ちます。
- sudo crm_mon
また、次のコマンドを使用してクラスター構成を確認できます。
- sudo crm configure show
crm
コマンドがまったく機能しない場合は、Corosyncログで手がかりを確認する必要があります。
- sudo tail -f /var/log/corosync/corosync.log
その他のCRMコマンド
これらのコマンドは、クラスターを構成するときに役立ちます。
次のコマンドを使用して、ノードをstandby
モードに設定できます。これを使用して、ノードが使用できなくなることをシミュレートできます。
- sudo crm node standby NodeName
次のコマンドを使用して、ノードのステータスをstandby
からonline
に変更できます。
- sudo crm node online NodeName
次のコマンドを使用して、リソースを編集し、再構成することができます。
sudo crm configure edit ResourceName
次のコマンドを使用して、リソースを削除できます。リソースは、削除する前に停止する必要があります。
- sudo crm resource stop ResourceName
- sudo crm configure delete ResourceName
最後に、crm
コマンドを単独で実行して、インタラクティブなcrm
プロンプトにアクセスできます。
- crm
インタラクティブなcrm
プロンプトの使用法については説明しませんが、これまでに行ったcrm
構成のすべてを実行するために使用できます。
Nginxリソースの追加(オプション)
フローティングIPフェイルオーバーが機能することを確認したので、クラスターに新しいリソースを追加する方法を見てみましょう。 セットアップ例では、Nginxが高可用性を実現するメインサービスであるため、クラスターが管理するリソースとしてNginxを追加してみましょう。
PacemakerにはNginxリソースエージェントが付属しているため、Nginxをクラスターリソースとして簡単に追加できます。
このコマンドを使用して、「Nginx」と呼ばれる新しいプリミティブクラスターリソースを作成します。
- sudo crm configure primitive Nginx ocf:heartbeat:nginx \
- params httpd="/usr/sbin/nginx" \
- op start timeout="40s" interval="0" \
- op monitor timeout="30s" interval="10s" on-fail="restart" \
- op stop timeout="60s" interval="0"
指定されたリソースは、クラスターに10秒ごとにNginxを監視し、使用できなくなった場合は再起動するように指示します。
sudo crm_mon
またはsudo crm status
を使用して、クラスターリソースのステータスを確認します。
crm_mon:...
Online: [ primary secondary ]
FloatIP (ocf::digitalocean:floatip): Started primary
Nginx (ocf::heartbeat:nginx): Started secondary
残念ながら、Pacemakerは、リソースの制約を定義していないため、Nginx
およびFloatIP
リソースを別々のノードで開始することを決定します。 これは、フローティングIPが1つのドロップレットを指しているのに対し、Nginxサービスは他のドロップレットでのみ実行されることを意味するため、これは問題です。 フローティングIPにアクセスすると、高可用性が必要なサービスを実行していないサーバーが表示されます。
この問題を解決するために、 clone リソースを作成します。これは、既存のプリミティブリソースを複数のノードで開始する必要があることを指定します。
次のコマンドを使用して、「Nginx-clone」というNginx
リソースのクローンリソースを作成します。
- sudo crm configure clone Nginx-clone Nginx
クラスタのステータスは次のようになります。
crm_mon:Online: [ primary secondary ]
FloatIP (ocf::digitalocean:floatip): Started primary
Clone Set: Nginx-clone [Nginx]
Started: [ primary secondary ]
ご覧のとおり、クローンリソースNginx-clone
が両方のノードで開始されています。
最後のステップは、コロケーション拘束を構成して、FloatIP
リソースがアクティブなNginx-clone
リソースを持つノードで実行されるように指定することです。 「FloatIP-Nginx」と呼ばれるコロケーション拘束を作成するには、次のコマンドを使用します。
- sudo crm configure colocation FloatIP-Nginx inf: FloatIP Nginx-clone
crm status
の出力に違いはありませんが、コロケーションリソースが次のコマンドで作成されたことがわかります。
- sudo crm configure show
これで、両方のサーバーでNginxが実行されているはずですが、一方のサーバーでFloatIP
リソースが実行されています。 Nginxサービスを停止し、アクティブサーバーを再起動または電源オフして、HAセットアップをテストする良い機会です。
結論
おめでとう! これで、Corosync、Pacemaker、およびDigitalOceanFloatingIPを使用した基本的なHAサーバーのセットアップが完了しました。
次のステップは、サンプルのNginxセットアップをリバースプロキシロードバランサーに置き換えることです。 この目的のためにNginxまたはHAProxyを使用できます。 ロードバランサーをアンカーIPアドレスにバインドして、ユーザーがフローティングIPアドレスを介してのみ(各サーバーのパブリックIPアドレスを介してではなく)サーバーにアクセスできるようにする必要があることに注意してください。 。 このプロセスの詳細は、 Ubuntu 14.04 チュートリアルで、Corosync、Pacemaker、およびフローティングIPを使用して高可用性HAProxyセットアップを作成する方法です。