序章

このチュートリアルでは、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）を使用してサーバーを同期します。

両方のサーバーで、次のコマンドを使用してタイムゾーンセレクターを開きます。

  1. sudo dpkg-reconfigure tzdata

希望のタイムゾーンを選択します。 たとえば、 America/New_York.

次に、apt-getを更新します。

  1. sudo apt-get update

次に、をインストールします ntp このコマンドでパッケージ化します。

  1. sudo apt-get -y install ntp

これで、サーバーのクロックがNTPを使用して同期されるはずです。 NTPの詳細については、次のチュートリアルを確認してください：タイムゾーンとネットワークタイムプロトコルの同期の構成。

ファイアウォールを構成する

Corosyncはポート間でUDPトランスポートを使用します 5404 と 5406. ファイアウォールを実行している場合は、それらのポートでの通信がサーバー間で許可されていることを確認してください。

たとえば、使用している場合 iptables、これらのポートでのトラフィックを許可することができます eth1 （プライベートネットワークインターフェイス）次のコマンドを使用します。

  1. sudo iptables -A INPUT  -i eth1 -p udp -m multiport --dports 5404,5405,5406 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

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

  1. sudo apt-get install pacemaker

CorosyncはPacemakerパッケージの依存関係としてインストールされることに注意してください。

これでCorosyncとPacemakerがインストールされましたが、何か便利なことをする前に構成する必要があります。

Corosyncを構成する

Corosyncは、サーバーがクラスターとして通信できるように構成する必要があります。

クラスタ認証キーを作成する

ノードがクラスターに参加できるようにするために、Corosyncは各ノードが同一のクラスター認証キーを所有していることを要求します。

プライマリサーバーに、 haveged パッケージ：

  1. sudo apt-get install haveged

このソフトウェアパッケージを使用すると、サーバー上のエントロピーの量を簡単に増やすことができます。これは、 corosync-keygen 脚本。

プライマリサーバーで、 corosync-keygen 脚本：

  1. sudo corosync-keygen

これにより、128バイトのクラスター認証キーが生成され、次のように書き込まれます。 /etc/corosync/authkey.

今ではもう必要ありません haveged パッケージ、プライマリサーバーから削除しましょう：

  1. sudo apt-get remove --purge haveged

  2. sudo apt-get clean

プライマリサーバーで、 authkey セカンダリサーバーへ：

  1. sudo scp /etc/corosync/authkey username@secondary_ip:/tmp

セカンダリサーバーで、 authkey ファイルを適切な場所に配置し、そのアクセス許可をルートに制限します。

  1. sudo mv /tmp/authkey /etc/corosync

  2. sudo chown root: /etc/corosync/authkey

  3. sudo chmod 400 /etc/corosync/authkey

これで、両方のサーバーの認証キーが同じになります。 /etc/corosync/authkey ファイル。

Corosyncクラスターを構成する

目的のクラスターを起動して実行するには、これらを設定する必要があります

両方のサーバーで、 corosync.conf お気に入りのエディタで編集するためのファイル（ vi):

  1. sudo vi /etc/corosync/corosync.conf

これは、サーバーがクラスターとして通信できるようにするCorosync構成ファイルです。 強調表示された部分を適切な値に置き換えてください。 bindnetaddr 現在作業しているサーバーのプライベートIPアドレスに設定する必要があります。 他の2つの強調表示された項目は、指定されたサーバーのプライベートIPアドレスに設定する必要があります。 を除いて bindnetaddr、ファイルは両方のサーバーで同一である必要があります。

の内容を置き換えます corosync.conf この構成では、ご使用の環境に固有の変更が加えられます。

/etc/corosync/corosync.conf
  1. totem {

  2.   version: 2

  3.   cluster_name: lbcluster

  4.   transport: udpu

  5.   interface {

  6.     ringnumber: 0

  7.     bindnetaddr: server_private_IP_address

  8.     broadcast: yes

  9.     mcastport: 5405

  10.   }

  11. }

  12. 

  13. quorum {

  14.   provider: corosync_votequorum

  15.   two_node: 1

  16. }

  17. 

  18. nodelist {

  19.   node {

  20.     ring0_addr: primary_private_IP_address

  21.     name: primary

  22.     nodeid: 1

  23.   }

  24.   node {

  25.     ring0_addr: secondary_private_IP_address

  26.     name: secondary

  27.     nodeid: 2

  28.   }

  29. }

  30. 

  31. logging {

  32.   to_logfile: yes

  33.   logfile: /var/log/corosync/corosync.log

  34.   to_syslog: yes

  35.   timestamp: on

  36. }

トーテムセクション（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を構成する必要があります。

両方のサーバーで、 pcmk エディターを使用してCorosyncサービスディレクトリ内のファイル。 使用します vi:

  1. sudo vi /etc/corosync/service.d/pcmk

次に、Pacemakerサービスを追加します。

service {
  name: pacemaker
  ver: 1
}

保存して終了。 これはCorosync構成に含まれ、PacemakerがCorosyncを使用してサーバーと通信できるようにします。

デフォルトでは、Corosyncサービスは無効になっています。 両方のサーバーで、編集して変更します /etc/default/corosync:

  1. sudo vi /etc/default/corosync

の値を変更します START に yes:

/ etc / default / corosync
START=yes

保存して終了。 これで、Corosyncサービスを開始できます。

両方のサーバーで、次のコマンドを使用してCorosyncを起動します。

  1. sudo service corosync start

Corosyncが両方のサーバーで実行されたら、それらを一緒にクラスター化する必要があります。 これは、次のコマンドを実行して確認できます。

  1. 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がシステムの起動時に起動できるようにします。

  1. sudo update-rc.d pacemaker defaults 20 01

前のコマンドで、ペースメーカーの開始優先度をに設定しました 20. Corosyncよりも高い開始優先度を指定することが重要です（これは 19 デフォルトで）、PacemakerがCorosyncの後に起動するようにします。

それでは、ペースメーカーを起動しましょう。

  1. sudo service pacemaker start

Pacemakerと対話するには、 crm 効用。

ペースメーカーを確認してください crm:

  1. 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 ]

この出力について注意すべき点がいくつかあります。 まず、 Current DC （指定コーディネーター）をいずれかに設定する必要があります primary (1) また secondary (2). 次に、2ノードが構成されているおよび0リソースが構成されている必要があります。 第三に、両方のノードをonlineとしてマークする必要があります。 オフラインとマークされている場合は、30秒待ってから、ステータスをもう一度確認して、自動的に修正されるかどうかを確認してください。

この時点から、別のSSHウィンドウ（いずれかのクラスターノードに接続されている）でインタラクティブCRMモニターを実行することをお勧めします。 これにより、各ノードのステータスと各リソースが実行されている場所をリアルタイムで更新できます。

  1. sudo crm_mon

このコマンドの出力は、の出力と同じに見えます。 crm status それが継続的に実行されることを除いて。 終了する場合は、を押します Ctrl-C.

クラスタープロパティの構成

これで、Pacemakerの基本的なプロパティを構成する準備が整いました。 すべてのペースメーカー（crm）コマンドは、すべてのメンバーノード間ですべてのクラスター関連の変更を自動的に同期するため、どちらのノードサーバーからでも実行できます。

2ノードのクラスターをセットアップしているため、目的のセットアップでは、STONITH（多くのクラスターが障害のあるノードを削除するために使用するモード）を無効にします。 これを行うには、いずれかのサーバーで次のコマンドを実行します。

  1. sudo crm configure property stonith-enabled=false

また、ログ内のクォーラム関連のメッセージを無効にします。

  1. sudo crm configure property no-quorum-policy=ignore

この場合も、この設定は2ノードクラスターにのみ適用されます。

Pacemakerの構成を確認する場合は、次のコマンドを実行します。

  1. sudo crm configure show

これにより、アクティブなペースメーカー設定がすべて表示されます。 現在、これには2つのノードと、設定したSTONITHプロパティとクォーラムプロパティのみが含まれます。

フローティングIP再割り当てリソースエージェントの作成

Pacemakerが実行および構成されたので、Pacemakerが管理するためのリソースを追加する必要があります。 はじめに述べたように、リソースは、クラスターが高可用性を実現するために担当するサービスです。 Pacemakerでは、リソースを追加するには、リソースエージェントを使用する必要があります。これは、管理されるサービスへのインターフェイスとして機能します。 Pacemakerには、共通サービス用のいくつかのリソースエージェントが付属しており、カスタムリソースエージェントを追加できます。

このセットアップでは、Webサーバープライマリおよびセカンダリによって提供されるサービスがアクティブ/パッシブセットアップで高可用性であることを確認する必要があります。つまり、フローティングIPが常に利用可能なサーバーを指していることを確認する方法。 これを有効にするには、各ノードが実行できるリソースエージェントを設定して、ノードがフローティングIPを所有しているかどうかを判断し、必要に応じて、スクリプトを実行してフローティングIPを自身にポイントする必要があります。 リソースエージェントを「FloatIPOCF」と呼び、FloatingIP再割り当てスクリプトを「FloatingIP再割り当てスクリプト」と呼びます。 assign-ip. FloatIP OCFリソースエージェントをインストールしたら、リソース自体を定義できます。これを次のように参照します。 FloatIP.

割り当てIPスクリプトをダウンロードする

先ほど述べたように、フローティングIPが指しているドロップレットを再割り当てできるスクリプトが必要です。 FloatIP リソースを別のノードに移動する必要があります。 この目的のために、DigitalOcean APIを使用して、特定のドロップレットIDにフローティングIPを割り当てる基本的なPythonスクリプトをダウンロードします。

両方のサーバーで、 assign-ip Pythonスクリプト：

  1. sudo curl -L -o /usr/local/bin/assign-ip http://do.co/assign-ip

両方のサーバーで、実行可能にします。

  1. 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. ただし、このスクリプトは、次の場合にFloatIPOCFリソースエージェントから呼び出されます。 FloatIP リソースを別のノードに移動する必要があります。

次に、Float IPResourceAgentをインストールしましょう。

FloatIPOCFリソースエージェントをダウンロードする

Pacemakerを使用すると、OCFリソースエージェントを特定のディレクトリに配置して追加できます。

両方のサーバーで、 digitalocean このコマンドを使用したリソースエージェントプロバイダーディレクトリ：

  1. sudo mkdir /usr/lib/ocf/resource.d/digitalocean

両方のサーバーで、FloatIPOCFリソースエージェントをダウンロードします。

  1. sudo curl -o /usr/lib/ocf/resource.d/digitalocean/floatip https://gist.githubusercontent.com/thisismitch/b4c91438e56bfe6b7bfb/raw/2dffe2ae52ba2df575baae46338c155adbaef678/floatip-ocf

両方のサーバーで、実行可能にします。

  1. 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（アドレス）

これで、FloatIPOCFリソースエージェントを使用して FloatIP 資源。

FloatIPリソースを追加する

FloatIP OCFリソースエージェントをインストールすると、次の設定が可能になります。 FloatIP 資源。

どちらのサーバーでも、 FloatIP このコマンドを使用したリソース（強調表示された2つのパラメーターを独自の情報で指定してください）：

  1. sudo crm configure primitive FloatIP ocf:digitalocean:floatip \

  2.   params do_token=your_digitalocean_personal_access_token \

  3.   floating_ip=your_floating_ip

これにより、先に作成したFloatIP OCFリソースエージェントを使用して、「FloatIP」と呼ばれる汎用タイプのクラスターリソースであるプリミティブリソースが作成されます（ocf:digitalocean: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が設定されているはずです。 現状では、フローティングIPは、ノードがオンラインサーバーに再割り当てされます。 FloatIP 開始されますオフラインまたはになります standby モード。 現在、アクティブノード（この例では出力例では primary ）が使用できなくなった場合、クラスターはSecondaryノードに開始するように指示します。 FloatIP リソースを取得し、それ自体のフローティングIPアドレスを要求します。 再割り当てが発生すると、フローティングIPはユーザーを新しくアクティブなセカンダリサーバーに誘導します。

現在、フェイルオーバー（Floating IP reassignment）は、アクティブなホストがオフラインになるか、クラスターと通信できない場合にのみトリガーされます。 この設定のより良いバージョンは、Pacemakerによって管理されるべき追加のリソースを指定します。 これにより、クラスターはロードバランサーやWebサーバーソフトウェアなどの特定のサービスの障害を検出できます。 ただし、これを設定する前に、基本的なフェイルオーバーが機能することを確認する必要があります。

高可用性のテスト

高可用性のセットアップが機能することをテストすることが重要なので、今すぐ実行しましょう。

現在、フローティングIPはノードの1つに割り当てられています（ primary と仮定します）。 IPアドレスまたはそれを指しているドメイン名を介してフローティングIPにアクセスすると、プライマリサーバーのインデックスページが表示されます。 サンプルのユーザーデータスクリプトを使用した場合、次のようになります。

Floating IP is pointing to primary server:
Droplet: primary, IP Address: primary_ip_address

これは、フローティングIPが実際にプライマリドロップレットに割り当てられていることを示しています。

それでは、新しいローカル端末を開いて使用してみましょう curl 1秒のループでフローティングIPにアクセスします。 これを行うには、次のコマンドを使用しますが、URLをドメインまたはフローティングIPアドレスに置き換えてください。

  1. while true; do curl floating_IP_address; sleep 1; done

現在、これはプライマリサーバーと同じドロップレット名とIPアドレスを出力します。 プライマリサーバーの電源を切るか、プライマリノードのクラスターステータスを次のように変更して、プライマリサーバーに障害が発生した場合 standby、フローティングIPがセカンダリサーバーに再割り当てされるかどうかを確認します。

プライマリサーバーを再起動しましょう。 これを行うには、DigitalOceanコントロールパネルを使用するか、プライマリサーバーで次のコマンドを実行します。

  1. 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にアクセスしようとした場合に発生する可能性があります。

ペースメーカーの状態を確認すると、 FloatIP リソースはセカンダリサーバーで開始されます。 また、プライマリサーバーは一時的に次のようにマークする必要があります OFFLINE しかし、参加します Online 再起動が完了し、クラスターに再参加するとすぐにリストします。

フェイルオーバーのトラブルシューティング（オプション）

HAセットアップが期待どおりに機能する場合は、このセクションをスキップしてください。 フェイルオーバーが期待どおりに発生しなかった場合は、先に進む前にセットアップを確認する必要があります。 特に、ノードIPアドレス、フローティングIP、APIトークンなど、独自の設定への参照があることを確認してください。

トラブルシューティングに役立つコマンド

セットアップのトラブルシューティングに役立つコマンドを次に示します。

前述のように、 crm_mon ツールは、ノードとリソースのリアルタイムステータスを表示するのに非常に役立ちます。

  1. sudo crm_mon

また、次のコマンドを使用してクラスター構成を確認できます。

  1. sudo crm configure show

の場合 crm コマンドがまったく機能しない場合は、Corosyncログで手がかりを確認する必要があります。

  1. sudo tail -f /var/log/corosync/corosync.log

その他のCRMコマンド

これらのコマンドは、クラスターを構成するときに役立ちます。

ノードを次のように設定できます standby 次のコマンドを使用して、ノードが使用できなくなることをシミュレートするために使用できるモード。

  1. sudo crm node standby NodeName

ノードのステータスはから変更できます standby に online このコマンドで：

  1. sudo crm node online NodeName

次のコマンドを使用して、リソースを編集し、再構成することができます。

sudo crm configure edit ResourceName

次のコマンドを使用して、リソースを削除できます。リソースは、削除する前に停止する必要があります。

  1. sudo crm resource stop ResourceName

  2. sudo crm configure delete ResourceName

最後に、 crm コマンドを単独で実行して、インタラクティブにアクセスできます crm 促す：

  1. crm

インタラクティブの使用法については説明しません crm プロンプトが表示されますが、すべてを実行するために使用できます crm これまでに行った構成。

Nginxリソースの追加（オプション）

フローティングIPフェイルオーバーが機能することを確認したので、クラスターに新しいリソースを追加する方法を見てみましょう。 セットアップ例では、Nginxが高可用性を実現するメインサービスであるため、クラスターが管理するリソースとしてNginxを追加してみましょう。

PacemakerにはNginxリソースエージェントが付属しているため、Nginxをクラスターリソースとして簡単に追加できます。

このコマンドを使用して、「Nginx」と呼ばれる新しいプリミティブクラスターリソースを作成します。

  1. sudo crm configure primitive Nginx ocf:heartbeat:nginx \

  2.   params httpd="/usr/sbin/nginx" \

  3.   op start timeout="40s" interval="0" \

  4.   op monitor timeout="30s" interval="10s" on-fail="restart" \

  5.   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

残念ながら、ペースメーカーは開始することを決定します Nginx と FloatIP リソースの制約を定義していないため、別々のノードにリソースがあります。 これは、Floating IPが1つのドロップレットを指しているのに対し、Nginxサービスは他のドロップレットでのみ実行されることを意味するため、これは問題です。 フローティングIPにアクセスすると、高可用性が必要なサービスを実行していないサーバーが表示されます。

この問題を解決するために、 clone リソースを作成します。これは、既存のプリミティブリソースを複数のノードで開始する必要があることを指定します。

のクローンリソースを作成します Nginx このコマンドで「Nginx-clone」と呼ばれるリソース：

  1. 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」と呼ばれるコロケーション拘束を作成するには、次のコマンドを使用します。

  1. sudo crm configure colocation FloatIP-Nginx inf: FloatIP Nginx-clone

違いは見られません crm status 出力が表示されますが、コロケーションリソースが次のコマンドで作成されたことがわかります。

  1. sudo crm configure show

これで、両方のサーバーでNginxが実行されているはずですが、一方のサーバーだけでNginxが実行されています。 FloatIP 実行中のリソース。 Nginxサービスを停止し、アクティブサーバーを再起動または電源オフして、HAセットアップをテストする良い機会です。

結論

おめでとう！ これで、Corosync、Pacemaker、およびDigitalOceanFloatingIPを使用した基本的なHAサーバーのセットアップが完了しました。

次のステップは、サンプルのNginxセットアップをリバースプロキシロードバランサーに置き換えることです。 この目的のためにNginxまたはHAProxyを使用できます。 ロードバランサーをアンカーIPアドレスにバインドして、ユーザーがフローティングIPアドレスを介してのみ（各サーバーのパブリックIPアドレスを介してではなく）サーバーにアクセスできるようにする必要があることに注意してください。 。 このプロセスの詳細は、 Ubuntu 14.04 チュートリアルで、Corosync、Pacemaker、およびFloatingIPを使用して高可用性HAProxyセットアップを作成する方法です。