序章

このチュートリアルでは、CorosyncとPacemakerをフローティングIPとともに使用して、DigitalOcean上に高可用性(HA)サーバーインフラストラクチャを作成する方法を示します。

Corosyncは、クラスターメンバーシップおよびメッセージング機能(メッセージングレイヤーとも呼ばれる)をクライアントサーバーに提供するオープンソースプログラムです。 Pacemakerは、オープンソースのクラスターリソースマネージャー(CRM)であり、クラスターによって管理され、高可用性を実現するリソースとサービスを調整するシステムです。 本質的に、Corosyncはサーバーがクラスターとして通信できるようにし、Pacemakerはクラスターの動作を制御する機能を提供します。

ゴール

完了すると、HAセットアップはアクティブ/パッシブ構成の2台のUbuntu14.04サーバーで構成されます。 これは、障害が検出されない限り、ユーザーがWebサービスにアクセスする方法であるフローティングIPをポイントして、プライマリ(アクティブ)サーバーをポイントすることによって実現されます。 Pacemakerがプライマリサーバーが利用できないことを検出した場合、セカンダリ(パッシブ)サーバーは、DigitalOceanAPIを介してフローティングIPを自身に再割り当てするスクリプトを自動的に実行します。 したがって、フローティングIPへの後続のネットワークトラフィックはセカンダリサーバーに転送されます。セカンダリサーバーはアクティブサーバーとして機能し、着信トラフィックを処理します。

この図は、説明されているセットアップの概念を示しています。

Active/passive Diagram

注:このチュートリアルでは、ゲートウェイレベルでのアクティブ/パッシブ高可用性の設定についてのみ説明します。 つまり、フローティング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ドロップレット、primarysecondaryを作成します。 セットアップ例に従う場合は、次の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をクリックします。

No Floating IPs

プライマリドロップレットにフローティング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は、ポート54045406の間でUDPトランスポートを使用します。 ファイアウォールを実行している場合は、それらのポートでの通信がサーバー間で許可されていることを確認してください。

たとえば、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. quorum {
  13. provider: corosync_votequorum
  14. two_node: 1
  15. }
  16. nodelist {
  17. node {
  18. ring0_addr: primary_private_IP_address
  19. name: primary
  20. nodeid: 1
  21. }
  22. node {
  23. ring0_addr: secondary_private_IP_address
  24. name: secondary
  25. nodeid: 2
  26. }
  27. }
  28. logging {
  29. to_logfile: yes
  30. logfile: /var/log/corosync/corosync.log
  31. to_syslog: yes
  32. timestamp: on
  33. }

トーテムセクション(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を使用します:

  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に設定しました。 PacemakerがCorosyncの後に開始するように、Corosyncよりも高い開始優先度(デフォルトでは19)を指定することが重要です。

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

  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 ]

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

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

  1. sudo crm_mon

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

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

これで、Pacemakerの基本的なプロパティを構成する準備が整いました。 すべての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再割り当てスクリプトをassign-ipと呼びます。 FloatIP OCFリソースエージェントをインストールしたら、リソース自体を定義できます。これをFloatIPと呼びます。

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

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

両方のサーバーで、assign-ipPythonスクリプトをダウンロードします。

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

次に、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(アドレス)

これで、FloatIP OCFリソースエージェントを使用して、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リソースエージェント(ocf:digitalocean:floatip)を使用して、「FloatIP」と呼ばれる汎用タイプのクラスターリソースであるプリミティブリソースが作成されます。 do_tokenfloating_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アドレスに置き換えてください。

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

Pacemakerのステータスを確認すると、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

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

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

次のコマンドを使用して、「Nginx-clone」というNginxリソースのクローンリソースを作成します。

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

結論

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

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