TOC

Ubuntu 14.04でCorosync、Pacemaker、Floating IPを使用して高可用性セットアップを作成する方法

前書き

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

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

Goal

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

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

image：https：//assets.digitalocean.com/articles/high_availability/ha-diagram-animated.gif [アクティブ/パッシブ図]

この目標を達成するには、次の手順に従います。

  • トラフィックを受信する2つのドロップレットを作成します

  • フローティングIPを作成し、それをドロップレットの1つに割り当てます

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

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

  • フローティングIP再割り当てクラスターリソースの構成

  • フェールオーバーをテストする

  • Nginxクラスターリソースの構成

前提条件

フローティングIPの再割り当てを自動化するには、DigitalOcean APIを使用する必要があります。 つまり、Personal Access Token（PAT）を生成する必要があります。PATは、https：//www.digitalocean.com/communityに従って_read_および_write_アクセスを使用してDigitalOceanアカウントの認証に使用できるAPIトークンです。 APIチュートリアルの/ tutorials / how-to-use-the-digitalocean-api-v2＃how-to-generate-a-personal-access-token [個人アクセストークンの生成方法]セクション。 PATはクラスター内の両方のサーバーに追加されるスクリプトで使用されるため、参照用にDigitalOceanアカウントへのフルアクセスを許可するため、安全な場所に保管してください。

このチュートリアルでは、APIに加えて、次のDigitalOcean機能を利用します。

詳細については、リンクされたチュートリアルをご覧ください。

液滴を作成する

最初のステップは、同じデータセンター内でプライベートネットワークが有効になっている2つのUbuntuドロップレットを作成することです。これは上記のプライマリサーバーとセカンダリサーバーとして機能します。 このセットアップ例では、簡単に参照できるように「primary」および「secondary」という名前を付けます。 Nginxを両方のDropletにインストールし、インデックスページをそれらを一意に識別する情報で置き換えます。 これにより、HAセットアップが機能していることを示す簡単な方法が得られます。 実際のセットアップでは、サーバーでNginxやHAProxyなど、選択したWebサーバーまたはロードバランサーを実行する必要があります。

2つのUbuntu 14.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アドレスを介していずれかのDropletにアクセスすると、Dropletのホスト名とIPアドレスを含む基本的なWebページが表示されます。これは、Floating IPがどのDropletを指すかをテストするのに役立ちます。

フローティングIPを作成する

DigitalOceanコントロールパネルのトップメニューで[ネットワーク]をクリックし、サイドメニューで[*フローティングIP *]をクリックします。

image：https：//assets.digitalocean.com/site/ControlPanel/fip_no_floating_ips.png [フローティングIPなし]

プライマリ*ドロップレットにフローティングIPを割り当ててから、 Assign Floating IP *ボタンをクリックします。

フローティングIPが割り当てられたら、そのIPアドレスをメモします。 WebブラウザでフローティングIPアドレスにアクセスして、割り当てられたドロップレットに到達できることを確認します。

http://

プライマリドロップレットのインデックスページが表示されます。

DNSの構成（オプション）

ドメイン名を使用してHAセットアップにアクセスできるようにする場合は、DNSに* Aレコード*を作成して、ドメインがフローティングIPアドレスを指すようにします。 ドメインでDigitalOceanのネームサーバーを使用している場合は、https：//www.digitalocean.com/community/tutorials/how-to-set-up-a-host-name-with-digitalocean#step-three%E2%80%94configureに従ってください-DigitalOceanを使用してホスト名を設定する方法のチュートリアルの-your-domain [ステップ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の詳細については、次のチュートリアルをご覧ください：https://www.digitalocean.com/community/tutorials/additional-recommended-steps-for-new-ubuntu-14-04-servers#configure-timezones-and-network -time-protocol-synchronization [タイムゾーンとネットワークタイムプロトコルの同期を構成する]。

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

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で各ノードが同一のクラスター認証キーを所有している必要があります。

  • primary *サーバーで、 `+ haveged +`パッケージをインストールします：

sudo apt-get install haveged

このソフトウェアパッケージにより、サーバーのエントロピーの量を簡単に増やすことができます。これは、 `+ corosync-keygen +`スクリプトで必要です。

  • primary *サーバーで、 `+ corosync-keygen +`スクリプトを実行します。

sudo corosync-keygen

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

`+ haveged +`パッケージが不要になったので、* primary *サーバーから削除しましょう。

sudo apt-get remove --purge haveged
sudo apt-get clean

  • primary *サーバーで、 `+ authkey +`をセカンダリサーバーにコピーします。

sudo scp /etc/corosync/authkey @:/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 +`の内容をこの設定に置き換え、環境に固有の変更を加えます：

/etc/corosync/corosync.conf

totem {
 version: 2
 cluster_name: lbcluster
 transport: udpu
 interface {
   ringnumber: 0
   bindnetaddr:
   broadcast: yes
   mcastport: 5405
 }
}

quorum {
 provider: corosync_votequorum
 two_node: 1
}

nodelist {
 node {
   ring0_addr:
   name: primary
   nodeid: 1
 }
 node {
   ring0_addr:
   name: secondary
   nodeid: 2
 }
}

logging {
 to_logfile: yes
 logfile: /var/log/corosync/corosync.log
 to_syslog: yes
 timestamp: on
}

  • totem *セクション（1〜11行目）は、Corosyncがクラスターメンバーシップに使用するTotemプロトコルを指し、クラスターメンバーが相互に通信する方法を指定します。 このセットアップでは、重要な設定には「+ transport：udpu 」（ユニキャストモードを指定）と「 bindnetaddr +」（Corosyncがバインドするネットワークアドレスを指定）が含まれます。

  • quorum *セクション（行13〜16）は、これが2ノードクラスタであることを指定しているため、クォーラムに必要なノードは1つだけです（ + two_node：1 +）。 これは、クォーラムを達成するにはクラスター内に少なくとも3つのノードが必要であるという事実の回避策です。 この設定により、2ノードクラスターがコーディネーター（DC）を選択できるようになります。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 +`に変更します。

/ etc / default / corosync

START=

保存して終了。 これで、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()
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()
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

前のコマンドで、Pacemakerの開始優先度を「20」に設定します。 PacemakerがCorosyncの後に起動するように、Corosyncの開始優先度（デフォルトでは「19」）を指定することが重要です。

それでは、Pacemakerを起動しましょう。

sudo service pacemaker start

Pacemakerと対話するには、 `+ crm +`ユーティリティを使用します。

`+ crm +`でPacemakerをチェックします：

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 （Designated Coordinator）を `+ 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

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

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

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

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

assign-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 = / usr / local / bin / assign-ip +。 ただし、このスクリプトは、 `+ FloatIP +`リソースを別のノードに移動する必要がある場合に、FloatIP OCFリソースエージェントから呼び出されます。

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

FloatIP OCFリソースエージェントをダウンロード

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

*両方のサーバー*で、次のコマンドで `+ digitalocean +`リソースエージェントプロバイダーディレクトリを作成します。

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

*両方のサーバー*で、FloatIP OCF Resource Agentをダウンロードします：

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

続行する前に、リソースエージェントの内容を自由に確認してください。 `+ start `コマンドで呼び出された場合、それを呼び出すノードのドロップレットIDを（メタデータ経由で）検索し、フローティングIPをドロップレットIDに割り当てるbashスクリプトです。 また、呼び出し側のドロップレットにフローティングIPが割り当てられているかどうかを返すことで、「 status」および「+ monitor of」コマンドに応答します。

次のOCFパラメーターが必要です。

  • * do_token：*：フローティングIPの再割り当てに使用するDigitalOcean APIトークン、つまり DigitalOcean Personal Access Token

  • * floating_ip：*：再割り当てが必要な場合に備えて、フローティングIP（アドレス）

これで、FloatIP OCFリソースエージェントを使用して、 `+ FloatIP +`リソースを定義できます。

FloatIPリソースを追加

FloatIP OCFリソースエージェントをインストールしたら、 `+ FloatIP +`リソースを設定できます。

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

sudo crm configure primitive FloatIP ocf:digitalocean:floatip \
 params do_token= \
 floating_ip=

これにより、先ほど作成したFloatIP OCF Resource Agent（ + ocf：digitalocean：floatip +）を使用して、「FloatIP」と呼ばれる一般的なタイプのクラスターリソースであるプリミティブリソースが作成されます。 パラメータとして渡すには、「+ do_token 」と「 floating_ip +」が必要であることに注意してください。 これらは、フローティングIPを再割り当てする必要がある場合に使用されます。

クラスターのステータス（ + sudo crm status +`または `+ sudo crm_mon +）を確認すると、ノードの1つで `+ FloatIP +`リソースが定義され、開始されていることがわかります。

crm_mon:...
2 Nodes configured
1 Resource configured

Online: [ primary secondary ]

FloatIP    (ocf::digitalocean:floatip):    Started

すべてが適切にセットアップされたと仮定すると、アクティブ/パッシブHAセットアップができているはずです！ 現状では、 `+ FloatIP `が起動されているノードがオフラインまたは ` standby `モードになった場合、フローティングIPはオンラインサーバーに再割り当てされます。 現在、この例の出力でアクティブノード（* primary *）が使用できなくなった場合、クラスターは* secondary *ノードに「 FloatIP +」リソースを開始し、自身のフローティングIPアドレスを要求するように指示します。 再割り当てが行われると、フローティングIPは新しくアクティブな*セカンダリ*サーバーにユーザーを誘導します。

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

高可用性のテスト

高可用性の設定が機能することをテストすることが重要です。それでは、それを実行しましょう。

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

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

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

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

while true; do curl ; sleep 1; done

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

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

sudo reboot

しばらくすると、プライマリサーバーが使用できなくなります。 ターミナルで実行されている `+ curl +`ループの出力に注意してください。 次のような出力が表示されるはずです。

curl loop output:Droplet: , IP Address:
...
curl: (7) Failed to connect to  port 80: Connection refused
Droplet: , IP Address:
...

つまり、*セカンダリ*サーバーのIPアドレスを指すように、フローティングIPアドレスを再割り当てする必要があります。 これは、正常な自動フェールオーバーが発生したため、HAセットアップが機能していることを意味します。

プライマリサーバーの障害とフローティングIPの再割り当てが完了するまでの間にフローティングIPにアクセスしようとすると、「接続拒否」エラーが表示される場合と表示されない場合があります。

Pacemakerのステータスを確認すると、セカンダリ*サーバーで + FloatIP +`リソースが開始されていることがわかります。 また、 primary *サーバーは一時的に `+ OFFLINE`としてマークされますが、再起動が完了してクラスターに再参加するとすぐに

Related