はじめに
クラウドサービスで利用できる仮想サーバーには、可用性を担保できる機能が標準で搭載されていることが多いと思います。IBM Cloudでもホスト障害時には他のホストで自動的に再起動するといった方式が採用されていますが、要件によっては個別にクラスターを組むことも考慮する必要があります。
今回は、新たにIBM CloudのVPC上の仮想サーバー(Virtual Server for VPC)でサポートされるようになったRed Hat High Availability Clusterを構成し、その機能を確認してみたいと思います。
Red Hat High Availability Clusterとは？
Red Hat High Availability Clusterは、RHEL上で稼働するサービスを対象とした信頼性や可用性を提供するクラスター機能です。サービスが稼働するサーバーに障害を検知した場合に、正常に稼働する待機系のサーバーにサービスを自動的にフェイルオーバーする、Active/Standby型のクラスターを構成することが可能です。
クラスターを組むためには、通常のRHELのライセンスに加えて、High Availability Add-Onと呼ばれるアドオン製品を購入する必要があります。このアドオン製品には複数のコンポーネントが含まれており、それぞれを組み合わせて設定することでサービスフェイルオーバーの自動化を実現します。
今回登場するコンポーネントには下記のようなものがあります。
- Pacemaker
- Pacemakerは、リソースという形で各種サービスの状態を定義し、リソースの監視、起動、停止などを実施するクラスターソフトウェアです。対象のリソースへの操作はリソースエージェントと呼ばれるスクリプトを実行することで実施され、その対象は仮想基盤、IPアドレス、ストレージ、ミドルウェア、アプリケーション等多岐に渡ります。
- pcs
- Pacemakerの管理ツールで、主にCLIで操作可能です。
- リソースエージェント
- Pacemakerが対象のリソースへの操作を行うために実行されるスクリプトです。管理対象として様々なサービスに対応したリソースエージェントがあらかじめ用意されていますが、このリソースエージェントは必要に応じて自分で新規に追加することも可能であり、クラスターの監視対象のサービスとして追加することが可能です。
- フェンスエージェント
- 定義したリソースまたはサーバの障害を検知した場合、クラスタから障害が発生したサーバーを切り離す処理を実行するためのスクリプトです。フェンスを実施するデバイスごとに異なるエージェントが利用されるため、環境に合ったフェンスエージェントをインストールする必要があります。
今回目指す構成
シンプルな構成ですが、2台のRHEL9サーバーを用意し、それぞれ1号機(ytada-rhel-ha-test-1)、2号機(ytada-rhel-ha-test-2)とします。共有ストレージとして、NFSストレージであるFile Storage for VPCを利用し、両方のサーバーから参照できるように構成します。
サブネットは10.50.4.0/24を作成し、それぞれのコンポーネントにIPアドレスを割り当て、クラスター構成時のVIP(Virtual IP)として10.50.4.100を指定しました。
外部からサーバーにアクセスするためにClient VPN for VPCを構成します。このVPNサーバーは、プライベート側のサブネットとして192.168.100.0/24に接続されています。また、サーバーから外部へのアクセスにはPublic Gatewayを使用します。これにより、サーバー自体はGlobal IP(IBM CloudではFloating IP)を持つことなくセキュアに外部へ接続する構成を実現します。
今回は、サーバー上で稼働するサービスとしてApache HTTP Serverを起動してWebサイトをホスティングし、IPアドレスの変更なくフェイルオーバーが実現できることを確認します。
環境構築開始
では早速環境を作成していきます。クラスターの構成がメインの内容になりますので、IBM Cloudの各サービスのオーダーについては注意点を記載するのみにとどめたいと思います。
事前準備
まずは必要なリソースを用意します。IBM Cloudのアカウント、およびVPC、サブネットは作成しておいてください。
詳細についてはIBM Cloudのチュートリアルなどをご確認ください。
セキュリティーグループの作成
サーバー等をオーダーする前に、必要なセキュリティーグループを作成しておきます。私の場合は下記のようなインバウンドトラフィックを許可しました。なお、アウトバウンドのトラフィックについては前述した通りPublic Gateway経由での通信となりますので、全てのプロトコルを許可しています。アプリケーションで利用するポート番号の変更が必要な場合は、適宜状況に合わせて修正ください。
| プロトコル | ソース | 宛先 | ポート番号 | 用途等 |
|---|---|---|---|---|
| TCP | 192.168.100.0/24 (VPN Server) |
全て | 22(SSH) | 自身の端末からのSSHアクセス |
| TCP | 192.168.100.0/24 (VPN Server) |
全て | 80(HTTP) | 自身の端末からApacheへの アクセス |
| ICMP | 192.168.100.0/24 (VPN Server) |
全て | Type/Code: 全て | 自身の端末からのPingアクセス |
| 全て | このセキュリティーグループ自体 | 全て | - | クラスターを構成するサーバー、ファイルストレージ同士のアクセス |
Red Hat High Availability Clusterを構成する上で必要となるポートについてはこちらに記載がありますので、必要最低限のポートのみを開ける場合は参照してください。
firewalldなどを含め、OS側でのファイアウォールが設定されている場合にはそちらでもポートを有効化する必要があります。
仮想サーバーの作成
2台のVirtual Server for VPCをオーダーします。注意が必要なのはOSイメージとして、SAP HANAをサポートしているストック・イメージを選択する点です。
前述の通り、HA Clusterを構成するためには通常のRHELのライセンスに加えて、High Availability Add-Onと呼ばれるアドオン製品を購入する必要があります。IBM CloudではSAP HANA用のイメージにHA Cluster用のリポジトリーが含まれているため、SAP HANAをサポートしているストック・イメージを選択することでRed Hat High Availability Clusterを利用することができるようになります。私はibm-redhat-9-4-amd64-sap-hana-3を選択しました。
[root@ytada-rhel-ha-test-1 ~]# dnf repolist
Updating Subscription Management repositories.
repo id repo name
...
rhel-9-for-x86_64-highavailability-rpms Red Hat Enterprise Linux 9 for x86_64 - High Availability (RPMs)
...
Reserved IPの作成
今回は、VIP(Virtual IP)を利用してIPアドレスを変更することなく待機系のサーバーにフェイルオーバーする構成を想定しています。VIPは、同じサブネットの中でサーバーに割り当てられていないIPアドレスが必要となります。「インフラストラクチャー」->「ネットワーク」->「サブネット」から該当のサブネットを選択し、「予約済みIP」タブで「作成」をクリックすることで予約することができます。今回は10.50.4.100を指定しました。
File Storage for VPCの作成
カタログから「File Storage for VPC」を選択してオーダーを開始します。今回は検証用ですので、必要最低限のスペックとして50GB/100IOPSを選択しました。
また、マウントターゲットとして今回はサーバーと同じサブネットを選択し、セキュリティーグループもサーバーと同じものを選択することでサーバーと確実に接続できるように設定しました。(上述した通り、同じセキュリティーグループ内の通信は全て許可しているため)
VPN for VPCの作成
今回はClient-to-Site型を利用しました。構築手順についてはこちらの公式ドキュメントに記載があります。また、下記のQiita記事も大変参考になります。構築に際しては考慮点なども幾つかございますので、公式のドキュメントを一通り読むことをお勧めいたします。
最後に、VPN経由でそれぞれのサーバーにアクセスできることを確認し、準備は完了です。
Pacemakerを利用したクラスターの作成
では、High Availability Add-Onに含まれているコンポーネントであるPacemakerを活用してクラスターを構成します。クラスターの基本的な構成手順は下記に記載がありますが、フェンスエージェントなど、IBM Cloud固有の設定項目もあるので注意が必要です。
なお、実行するコマンドには1号機、2号機の両方でコマンドの実行が必要なものと、1号機、2号機のどちらかでコマンドを実行すれば良いものがあります。コマンドのタイトルに記載してありますので、適宜参照ください。
Pacemakerのインストール
まずは下記のコマンドでクラスターの両ノードPacemakerをインストールします。
# HA Clusterのリポジトリーを有効化します。
$ subscription-manager repos --enable=rhel-9-for-x86_64-highavailability-rpms
# Pacemakerをインストールします。
$ dnf install pcs pacemaker
次に、pcsコマンド用のユーザー設定を実施します。下記の例ではユーザーIDをhaclusterとして設定しています。また、パスワードは全てのノードで同じものを利用することが推奨されています。
$ passwd hacluster
最後に、pcsdデーモンを起動します。また、システムの起動時に自動でpcsdデーモンが起動するように有効化します。
$ systemctl start pcsd.service
$ systemctl enable pcsd.service
High Availability Clusterの作成
クラスターを作成します。今回はホスト名の名前解決を特に設定していないためIPアドレスで直接ノードを指定していますが、hostsファイルやDNSを設定している場合はホスト名を利用するのが良いでしょう。
クラスターの全ノードに対して、haclusterユーザーを認証します。
# 1号機のhaclusterユーザーを認証します。
$ pcs host auth 10.50.4.15 10.50.4.16
クラスターmy_clusterを作成し、稼働します。また、この操作によってクラスター設定ファイルがクラスターの両ノードに伝搬されます。
$ pcs cluster setup my_cluster --start 10.50.4.15 10.50.4.16
No addresses specified for host '10.50.4.15', using '10.50.4.15'
No addresses specified for host '10.50.4.16', using '10.50.4.16'
...
Sending 'corosync authkey', 'pacemaker authkey' to '10.50.4.15', '10.50.4.16'
10.50.4.15: successful distribution of the file 'corosync authkey'
10.50.4.15: successful distribution of the file 'pacemaker authkey'
10.50.4.16: successful distribution of the file 'corosync authkey'
10.50.4.16: successful distribution of the file 'pacemaker authkey'
Sending 'corosync.conf' to '10.50.4.15', '10.50.4.16'
10.50.4.15: successful distribution of the file 'corosync.conf'
10.50.4.16: successful distribution of the file 'corosync.conf'
Cluster has been successfully set up.
Starting cluster on hosts: '10.50.4.15', '10.50.4.16'...
# サーバーの起動時にクラスターを有効化します。
$ pcs cluster enable --all
10.50.4.15: Cluster Enabled
10.50.4.16: Cluster Enabled
# クラスターの状態を確認します。
$ pcs cluster status
Cluster Status:
Cluster Summary:
* Stack: corosync (Pacemaker is running)
* Current DC: 10.50.4.16 (version 2.1.7-5.2.el9_4-0f7f88312) - partition with quorum
* Last updated: Sat Nov 30 14:50:59 2024 on 10.50.4.15
* Last change: Sat Nov 30 14:50:21 2024 by hacluster via hacluster on 10.50.4.16
* 2 nodes configured
* 0 resource instances configured
Node List:
* Online: [ 10.50.4.15 10.50.4.16 ]
PCSD Status:
10.50.4.15: Online
10.50.4.16: Online
両方のノードがオンラインになっていたらクラスターの作成は完了です。(稼働まで少し時間がかかる場合があるみたいです。)
フェンスエージェントの導入
次に、IBM CloudのVirtual Server for VPCに対して実行可能なフェンスエージェントを導入します。導入の方法についてはこちらに記載があります。(URLの閲覧にはRed Hatの有効なサブスクリプションが適用されたアカウントが必要です。)
前述した通り、サーバーやリソースに障害が発生したことを検知した場合、障害が発生している仮想サーバーを自動的に切り離す処理を実施するスクリプトです。
# IBM Cloud CLIをインストールします。
$ curl -fsSL https://clis.cloud.ibm.com/install/linux | sh
# CLIのインストールが完了後、ログインを実施します。
$ ibmcloud login
$ ibmcloud target -g <resource group>
# IBM CloudのAPI Keyを作成します。
$ ibmcloud iam api-key-create <key name>
ここで作成するAPI Keyは、コマンドの実行結果として1度しか表示されません。この後のコマンドで使いますので、必ずコピーしておくようにしてください。また、API Keyは1つあれば十分ですので、1号機か2号機のどちらかで実行してください。
[root@ytada-rhel-ha-test-1 ~]# ibmcloud iam api-key-create api-key-rhel-ha-1
Creating API key api-key-rhel-ha-1 under xxxxxxxxxxxxxxxxxxx as YTADA@jp.ibm.com...
OK
API key api-key-rhel-ha-1 was created
Please preserve the API key! It cannot be retrieved after it's created.
ID ApiKey-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx
Name api-key-rhel-ha-1
Description -
Locked false
CRN crn:v1:bluemix:public:iam-identity::xxxxxxxxxxxx::apikey:ApiKey-xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx
Created At 2024-11-30T14:16+0000
Version 1-fd0753fb3dc7423d1863f66d2db97cd7
Disabled false
Leaked false
Action when leaked disable
Session supported false
API Key xxxxxxxxxxxxxx -> この値をコピーしておく
フェンスエージェントのインストールを実施します。
# IBM CloudのVirtual Server for VPC用のフェンスエージェントをインストールします。
$ yum install fence-agents-ibm-vpc
# フェンスエージェントがインストールされ、IBM Cloudのアカウントと正しく接続されていることを確認します。
$ fence_ibm_vpc --apikey <apikey> --region jp-tok -o list
上記コマンドの実行結果として、ログインしたアカウントの仮想サーバーの一覧が表示されればOKです。
<2号機のインスタンスID>,ytada-rhel-ha-test-2
<1号機のインスタンスID>,ytada-rhel-ha-test-1
...
最後に、実際のフェンスエージェントの動きを確認します。ノードIDとして、先程のサーバー一覧に表示されていた仮想サーバーのインスタンスIDをコマンドで指定します。
# 'ibmvpcfence'という名称のstonishデバイスを作成します。
$ pcs --force stonith create ibmvpcfence fence_ibm_vpc apikey=<apikey> region=jp-tok pcmk_host_map="node1:<1号機のインスタンスID>;node2:<2号機のインスタンスID>"
# フェンシングデバイスを表示し、正しく作成できていることを確認します。
$ pcs stonith config ibmvpcfence
Resource: ibmvpcfence (class=stonith type=fence_ibm_vpc)
Attributes: ibmvpcfence-instance_attributes
apikey=xxxxxxxxxxxxxxxxxxxxxxxxxxx
pcmk_host_map=node1:xxxx_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx;node2:xxxx_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx
region=jp-tok
Operations:
monitor: ibmvpcfence-monitor-interval-60s
interval=60s
# 実際のフェンス処理を実行して、テストを行います。
$ pcs stonith fence node2
Node: node2 fenced
フェンス処理を実行したところ、2号機が自動的に再起動されました。それと同時に、今まで2号機が稼働系とクラスターに認識されていましたが、稼働系は1号機に切り替わっています。
$ pcs cluster status
Cluster Status:
Cluster Summary:
* Stack: corosync (Pacemaker is running)
* Current DC: 10.50.4.15 (version 2.1.7-5.2.el9_4-0f7f88312) - partition with quorum
* Last updated: Sat Nov 30 15:01:03 2024 on 10.50.4.15
* Last change: Sat Nov 30 14:54:50 2024 by root via root on 10.50.4.15
* 2 nodes configured
* 1 resource instance configured
Node List:
* Online: [ 10.50.4.15 10.50.4.16 ]
PCSD Status:
10.50.4.15: Online
10.50.4.16: Online
2号機自体は再起動が完了した後、(おそらく正常に稼働していることが確認され、)ステータスはOnlineにもどりました。
Active/Passive Apache HTTP Serverの構成
クラスターの作成が完了したので、次は実際にサービスを稼働させ、フェイルオーバーができることを確認します。Active/Passive(Standby)型のクラスターを構成し、各サービスをどちらかのクラスターノードで稼働させます。アクティブになっているノードに障害が発生した際に、自動的にパッシブ側のノードにフェイルオーバーが行われること、また、サービス停止が最小限に抑えられていることを確認します。
Apache HTTP Serverのインストール
まずはApache HTTP Serverをインストールし、Webサイトの設定を行います。また、今回は共有ストレージとしてFile Storage for VPCというNFSストレージを用意しています。Webサイトの公開ディレクトリである/var/www/ディレクトリに対して共有ストレージのNFSファイルシステムをマウントすることで、共有ストレージ上でWebページを公開するように設定を行います。
基本的にはこちらの手順を参考に設定を進めています。
# Apacheと、wgetをインストールします。
$ dnf install -y httpd wget
# ApacheのリソースエージェントがApacheのステータスを取得できるようにステータスサーバーを有効にします。
$ cat <<-END > /etc/httpd/conf.d/status.conf
<Location /server-status>
SetHandler server-status
Require local
</Location>
END
File Storage for VPCを/var/www/にマウントし、Webページを用意します。マウントを実施するストレージのディレクトリーは、IBM Cloudのポータル上で「マウントパス」として表示されているものになります。該当のファイルストレージの詳細ページから「マウント・ターゲット」を選択すると見ることができます。
$ mount -t nfs4 -o sec=sys 10.50.4.17:/xxxxxxxx_xxxx_xxxx_xxxx_xxxxxxxxxxxx /var/www/
$ mkdir /var/www/html
$ mkdir /var/www/cgi-bin
$ mkdir /var/www/error
$ restorecon -R /var/www
$ cat <<-END >/var/www/html/index.html
<html>
<body>Hello</body>
</html>
END
$ umount /var/www
リソースの作成
クラスターで管理を実施するリソースを作成します。リソースエージェントを指定してPacemakerのリソースを作成することで、各リソースはクラスターの管理下に置かれ、監視が開始されます。また、アクティブノードでの障害発生時にはそれぞれのリソースが自動的にパッシブノード側で稼働するため、フェイルオーバーを実現することができるようになります。
今回は、下記のリソースを作成しました。
- NFSファイルシステム
- 共有ストレージとして利用するFile Storage for VPCを管理するリソース
- マウントポイントを指定しておくことで、フェイルオーバー時には自動的にパッシブノードにマウントを実行する
- Virtual IP
- VIP用に予約したIPアドレス(10.50.4.100)を管理するリソース
- フェイルオーバー時にはVIPとして指定したIPアドレスをパッシブノードのvNICに対して自動的に付与する
- あくまでOSレベルでのIPアドレスの管理であることに注意
- Secondary IP
- IBM CloudのVIP用のReserved IPを管理するリソース
- フェイルオーバー時にはパッシブノードとなる仮想サーバーに対して、vNICの2次IPアドレスにVIPを自動的に付与する
- Apache
- 先程設定したApache HTTP Server用のリソース
ここで非常に重要なのは、IPアドレスの自動フェイルオーバーを考慮する際に、あらかじめ用意されているIPaddr2リソースを作成するだけではサーバーに疎通できないことです。サーバーにVIPで疎通するには、OSに正しくIPアドレスが付与されているだけではなく、IBM Cloud内でVIPが該当のサーバーに正しくルーティングされる必要があります。
VIPをサーバーにルーティングするにはいくつかの方法がありますが、今回はVNIの2次IPアドレス(Secondary IP Addresses)としてVIPを付与することでIBM Cloud側でVIPを正しく認識できるように設定しました。
また、それに伴い必要となるリソースエージェントは自身で作成し、自動的にパッシブノード側に付け替えることができるようにしています。詳細については下記の記事にまとめていますので、参照してください。
PacemakerのResource Agentを自作し、Red Hat High Availability ClusterからIBM Cloudのリソースを管理する
上記4つのリソースを作成します。リソースは全てha_test_groupというリソースグループを指定しました。これにより、同じノードで全てのリソースが稼働することを保証します。
また、リソースにはグループ内で順序が設定されており、上から起動し、逆の順序で停止します。サービス間に依存性がある場合等には起動順序にもご注意ください。デフォルトではリソースが追加された順番で設定されますが、--after、--beforeオプションを付与してリソースを作成することで任意の順序で作成することが可能です。
# fs_nfsという名称のFilesystemリソースを作成します。
$ pcs resource create fs_nfs ocf:heartbeat:Filesystem device="10.50.4.17:/xxxxxxxx_xxxx_xxxx_xxxx_xxxxxxxxxxxx" directory="/var/www" fstype="nfs" op monitor interval=10s --group ha_test_group
# vipという名称のIPaddr2リソースを作成します。
$ pcs resource create vip ocf:heartbeat:IPaddr2 ip=10.50.4.100 cidr_netmask=24 op monitor interval=10s --group ha_test_group
# controll_ripという名称のibmcloud-secondary-ipリソースを作成します。
$ pcs resource create controll_rip ocf:ytada:ibmcloud-secondary-ip op monitor interval=10s timeout=60s op start timeout=60s op stop timeout=60s --group ha_test_group
# websiteという名称のapacheリソースを作成します。
$ pcs resource create website ocf:heartbeat:apache configfile="/etc/httpd/conf/httpd.conf" statusurl="http://127.0.0.1/server-status" op monitor interval=10s --group ha_test_group
リソースの作成が完了したらクラスターのステータスを確認し、全てのリソースが同じノードで稼働していることを確認します。
$ pcs status
Cluster name: my_cluster
Cluster Summary:
* Stack: corosync (Pacemaker is running)
* Current DC: 10.50.4.15 (version 2.1.7-5.2.el9_4-0f7f88312) - partition with quorum
* Last updated: Sun Dec 8 16:00:15 2024 on 10.50.4.15
* Last change: Sun Dec 8 15:59:51 2024 by root via root on 10.50.4.15
* 2 nodes configured
* 5 resource instances configured
Node List:
* Online: [ 10.50.4.15 10.50.4.16 ]
Full List of Resources:
* ibmvpcfence (stonith:fence_ibm_vpc): Started 10.50.4.15
* Resource Group: ha_test_group:
* fs_nfs (ocf:heartbeat:Filesystem): Started 10.50.4.16
* vip (ocf:heartbeat:IPaddr2): Started 10.50.4.16
* controll_rip (ocf:ytada:ibmcloud-secondary-ip): Started 10.50.4.16
* website (ocf:heartbeat:apache): Started 10.50.4.16
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
全てのリソースがStartedになっていれば正常に稼働しています。正しく稼働していることを確認するため、自身のPC端末からVIPである10.50.4.100にアクセスしてください。
$ curl 10.50.4.100
<html>
<body>Hello</body>
</html>
ブラウザでも先程作成したページが表示されます。
ちなみに、この状態で1号機に直接アクセスしてもサービスが起動していないため接続ができません。2号機は正しくアクセス可能です。
$ curl 10.50.4.15
curl: (7) Failed to connect to 10.50.4.15 port 80 after 14 ms: Couldn't connect to server
フェイルオーバーの確認
最後に、フェイルオーバーが正しくできることを確認します。現在稼働しているアクティブノード(上記の場合は2号機)をスタンバイノードとして設定し、一時的にクラスターから切り離します。
$ pcs node standby 10.50.4.16
$ pcs status
Cluster name: my_cluster
Cluster Summary:
* Stack: corosync (Pacemaker is running)
* Current DC: 10.50.4.15 (version 2.1.7-5.2.el9_4-0f7f88312) - partition with quorum
* Last updated: Sun Dec 8 16:43:16 2024 on 10.50.4.15
* Last change: Sun Dec 8 16:42:50 2024 by root via root on 10.50.4.15
* 2 nodes configured
* 5 resource instances configured
Node List:
* Node 10.50.4.16: standby
* Online: [ 10.50.4.15 ]
Full List of Resources:
* ibmvpcfence (stonith:fence_ibm_vpc): Started 10.50.4.15
* Resource Group: ha_test_group:
* fs_nfs (ocf:heartbeat:Filesystem): Started 10.50.4.15
* vip (ocf:heartbeat:IPaddr2): Started 10.50.4.15
* controll_rip (ocf:ytada:ibmcloud-secondary-ip): Started 10.50.4.15
* website (ocf:heartbeat:apache): Started 10.50.4.15
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
無事にパッシブノードだった1号機にフェイルオーバーが実施されました。VIPである10.50.4.100に対してcurlを送り続けたところ、数秒程度の接続断がありました。
$ curl 10.50.4.100
<html>
<body>Hello</body>
</html>
--- ここで切り離しを実施 ---
$ curl 10.50.4.100
curl: (7) Failed to connect to 10.50.4.100 port 80 after 16 ms: Couldn't connect to server
$ curl 10.50.4.100
curl: (7) Failed to connect to 10.50.4.100 port 80 after 14 ms: Couldn't connect to server
$ curl 10.50.4.100
curl: (7) Failed to connect to 10.50.4.100 port 80 after 22 ms: Couldn't connect to server
$ curl 10.50.4.100
curl: (7) Failed to connect to 10.50.4.100 port 80 after 87 ms: Couldn't connect to server
$ curl 10.50.4.100
curl: (7) Failed to connect to 10.50.4.100 port 80 after 21 ms: Couldn't connect to server
$ curl 10.50.4.100
curl: (7) Failed to connect to 10.50.4.100 port 80 after 18 ms: Couldn't connect to server
$ curl 10.50.4.100
<html>
<body>Hello</body>
</html>
また、VIPがパッシブ側のノードに2次IPとして付与されていることをIBM Cloudのポータルから確認することができます。
フェイルオーバーが確認できたら、スタンバイにしたノードはオンライン状態に戻しておきます。
$ pcs node unstandby 10.50.4.16
$ pcs status
...
Node List:
* Online: [ 10.50.4.15 10.50.4.16 ]
...
両方のノードがオンラインになりました。(オンラインになったからといってリソースがそのノードにフェイルオーバーするわけではありません。)
まとめ
長い記事になってしまいましたが、IBM CloudのVirtual Server for VPCでRed Hat High Availability Clusterを構成し、フェイルオーバーが自動で行われることを確認することができました。
完全にフェールオーバーを自動化するには別記事にまとめたようにIBM Cloud上の設定変更をIBM CloudのCLIやAPIを利用してスクリプトとして記述する必要がありますが、PacemakerのリソースとしてIBM Cloudの設定を管理することができるため、クラスターの枠組みの中にIBM Cloudのサービスも組み込むことが可能です。
皆さんも是非試してみてください。