第4章 Pacemaker の使用

図1.1「director を使用してデプロイした OpenStack HA 環境」 に記載した OpenStack 設定では、大半の OpenStack サービスは 3 つのコントローラーノードで実行されます。これらのサービスの高可用性機能を確認するには、heat-admin ユーザーとしてコントローラーのいずれかにログインして、Pacemaker が制御するサービスを確認します。

Pacemaker pcs status のコマンドの出力には、Pacemaker の全般的な情報、仮想 IP アドレス、サービス、および Pacemaker に関するその他の情報が含まれています。

Red Hat Enterprise Linux の Pacemaker に関する一般情報については、以下のリンクを参照してください。

4.1. Pacemaker の全般的な情報

以下の例は、pcs status コマンドで出力される Pacemaker の全般的な情報のセクションを示しています。 

$ sudo pcs status
    Cluster name: tripleo_cluster 1
    Stack: corosync
    Current DC: overcloud-controller-1 (version 1.1.16-12.el7_4.5-94ff4df) - partition with quorum

    Last updated: Thu Feb  8 14:29:21 2018
    Last change: Sat Feb  3 11:37:17 2018 by root via cibadmin on overcloud-controller-2

    12 nodes configured 2
    37 resources configured 3

    Online: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ] 4
    GuestOnline: [ galera-bundle-0@overcloud-controller-0 galera-bundle-1@overcloud-controller-1 galera-bundle-2@overcloud-controller-2 rabbitmq-bundle-0@overcloud-controller-0 rabbitmq-bundle-1@overcloud-controller-1 rabbitmq-bundle-2@overcloud-controller-2 redis-bundle-0@overcloud-controller-0 redis-bundle-1@overcloud-controller-1 redis-bundle-2@overcloud-controller-2 ] 5

    Full list of resources:
[...]

この出力の主要なセクションでは、クラスターに関する以下の情報が表示されます。

1
クラスター名
2
クラスターを構成するノードの数
3
クラスターに設定されているリソースの数
4
現在オンライン状態のコントローラーノードの名前
5
現在オンライン状態のゲストノードの名前。各ゲストノードは、複合バンドルセットのリソースで構成されています。バンドルセットの詳細については、「Pacemaker で設定された OpenStack サービス」を参照してください。

4.2. Pacemaker で設定された仮想 IP アドレス

各 IPaddr2 リソースは、クライアントがサービスへのアクセスを要求するために使用する仮想 IP アドレスを設定します。その IP アドレスに割り当てられているコントローラーノードでエラーが発生すると、IP アドレスは別のコントローラーに再割り当てされます。

この例では、特定の仮想 IP アドレスをリッスンするように現在設定されている各コントローラーノードを確認できます。 

 ip-10.200.0.6	(ocf::heartbeat:IPaddr2):	Started overcloud-controller-1
 ip-192.168.1.150	(ocf::heartbeat:IPaddr2):	Started overcloud-controller-0
 ip-172.16.0.10	(ocf::heartbeat:IPaddr2):	Started overcloud-controller-1
 ip-172.16.0.11	(ocf::heartbeat:IPaddr2):	Started overcloud-controller-0
 ip-172.18.0.10	(ocf::heartbeat:IPaddr2):	Started overcloud-controller-2
 ip-172.19.0.10	(ocf::heartbeat:IPaddr2):	Started overcloud-controller-2

この出力では、各 IP アドレスが最初に特定のコントローラーに接続されます。たとえば、192.168.1.150 は overcloud-controller-0 で開始されます。ただし、そのコントローラーでエラーが発生すると、IP アドレスはクラスター内の他のコントローラーに再割り当てされます。

以下の表には、この例の IP アドレスと、各アドレスが最初に割り当てられた方法をまとめています。

表4.1 IP アドレスの説明と割り当て元

IP アドレス説明割り当て元

192.168.1.150

パブリック IP アドレス

network-environment.yaml ファイルの ExternalAllocationPools 属性

10.200.0.6

コントローラーの仮想 IP アドレス

dhcp_start および dhcp_end の範囲の部分は、undercloud.conf ファイルで 10.200.0.5-10.200.0.24 に設定されます。

172.16.0.10

コントローラー上の OpenStack API サービスへのアクセスを提供します

network-environment.yaml ファイルの InternalApiAllocationPools

172.18.0.10

Glance API および Swift プロキシーのサービスへのアクセスを提供するストレージの仮想 IP アドレス

network-environment.yaml ファイルの StorageAllocationPools 属性

172.16.0.11

コントローラー上の Radis サービスへのアクセスを提供します

network-environment.yaml ファイルの InternalApiAllocationPools

172.19.0.10

ストレージ管理へのアクセスを提供します。

network-environment.yaml ファイルの StorageMgmtAlloctionPools

pcs コマンドを使用して Pacemaker によって管理される特定の IP アドレスについての情報を確認することができます。たとえば、タイムアウトの情報やネットマスク ID を確認することができます。

以下の例は、ip-192.168.1.150 のパブリック IP アドレスでコマンドを実行した場合の pcs コマンドの出力を示しています。 

$ sudo pcs resource show ip-192.168.1.150
 Resource: ip-192.168.1.150 (class=ocf provider=heartbeat type=IPaddr2)
  Attributes: ip=192.168.1.150 cidr_netmask=32
  Operations: start interval=0s timeout=20s (ip-192.168.1.150-start-timeout-20s)
              stop interval=0s timeout=20s (ip-192.168.1.150-stop-timeout-20s)
              monitor interval=10s timeout=20s (ip-192.168.1.150-monitor-interval-10s)

現在、192.168.1.150 のアドレスをリッスンするように割り当てられたコントローラーにログインしている場合には、以下のコマンドを実行して、コントローラーがアクティブな状態であることと、各種サービスがそのアドレスをアクティブにリッスンしていることを確認することができます。 

$ ip addr show vlan100
  9: vlan100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether be:ab:aa:37:34:e7 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.151/24 brd 192.168.1.255 scope global vlan100
       valid_lft forever preferred_lft forever
    inet 192.168.1.150/32 brd 192.168.1.255 scope global vlan100
       valid_lft forever preferred_lft forever

$ sudo netstat -tupln | grep "192.168.1.150.*haproxy"
tcp        0      0 192.168.1.150:8778          0.0.0.0:*               LISTEN      61029/haproxy
tcp        0      0 192.168.1.150:8042          0.0.0.0:*               LISTEN      61029/haproxy
tcp        0      0 192.168.1.150:9292          0.0.0.0:*               LISTEN      61029/haproxy
tcp        0      0 192.168.1.150:8080          0.0.0.0:*               LISTEN      61029/haproxy
tcp        0      0 192.168.1.150:80            0.0.0.0:*               LISTEN      61029/haproxy
tcp        0      0 192.168.1.150:8977          0.0.0.0:*               LISTEN      61029/haproxy
tcp        0      0 192.168.1.150:6080          0.0.0.0:*               LISTEN      61029/haproxy
tcp        0      0 192.168.1.150:9696          0.0.0.0:*               LISTEN      61029/haproxy
tcp        0      0 192.168.1.150:8000          0.0.0.0:*               LISTEN      61029/haproxy
tcp        0      0 192.168.1.150:8004          0.0.0.0:*               LISTEN      61029/haproxy
tcp        0      0 192.168.1.150:8774          0.0.0.0:*               LISTEN      61029/haproxy
tcp        0      0 192.168.1.150:5000          0.0.0.0:*               LISTEN      61029/haproxy
tcp        0      0 192.168.1.150:8776          0.0.0.0:*               LISTEN      61029/haproxy
tcp        0      0 192.168.1.150:8041          0.0.0.0:*               LISTEN      61029/haproxy

ip コマンドの出力には、vlan100 のインターフェースが 192.168.1.150 と 192.168.1.151 の両方の IPv4 アドレスをリッスンしていることが示されています。

netstat コマンドの出力には、192.168.1.150 インタフェースをリッスンしているすべてのプロセスが表示されています。ポート 123 でリッスンしている ntpd プロセスに加えて、192.168.1.150 を特にリッスンしているその他唯一のプロセスは haproxy です。

注記
0.0.0.0のように、すべてのローカルアドレスをリッスンしているプロセスは、192.168.1.150 からも利用できます。これらのプロセスには、sshd、mysqld、dhclient、ntpd などがあります。

netstat コマンドの出力に表示されるポート番号は、HAProxy がリッスンしている特定のサービスを識別するのに役立ちます。これらのポート番号が表しているサービスは、 /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg ファイルで確認できます。

以下の一覧には、ポート番号とそれらに割り当てられたデフォルトのサービスの例をいくつか示しています。

  • TCP ポート 6080: nova_novncproxy
  • TCP ポート 9696: neutron
  • TCP ポート 8000: heat_cfn
  • TCP ポート 80: horizon
  • TCP ポート 8776: cinder

現在、haproxy.cfg ファイルで定義されているサービスの大半は、3 つのコントローラーすべてで 192.168.1.150 の IP アドレスをリッスンしています。ただし、192.168.1.150 の IP アドレスを外部でリッスンしているのは controller-0 ノードのみです。

このため、controller-0 ノードでエラーが発生した場合には、HAProxy は 192.168.1.150 を別のコントローラーに再割り当てするだけで、他のサービスはすべてフォールバックコントローラーノードですでに実行されている状態となります。

4.3. Pacemaker で設定された OpenStack サービス

Red Hat OpenStack Platform 12 以降のクラスターで管理されるサービスの大半は、バンドルセット リソースまたは バンドルとして設定されています。これらのサービスは、各コントローラーノードで同じ方法で開始することができ、常に各コントローラーで実行するように設定されます。

バンドル
すべてのコントローラノードで同じ コンテナー を設定および複製し、必要なストレージパスをコンテナーディレクトリーにマッピングして、リソース自体に関連する特定の属性を設定する バンドル リソース
コンテナー
コンテナーは、haproxy のような単純なシステムベースのサービスから、異なるノード上のサービスの状態を制御および設定する特定のリソースエージェントを必要とする Galera のような複雑なサービスまで、さまざまな種類のリソースを実行できます。
警告
  • バンドルまたはコンテナーを管理するための docker または systemctl コマンドの使用はサポートされていません。これらのコマンドは、サービスのステータスを確認に使用できますが、これらのサービスに対してアクションを実行するには Pacemaker のみを使用する必要があります。
  • Pacemaker によって制御される Docker コンテナーでは、RestartPolicy が Docker によって no に設定されます。これは、docker デーモンではなく、Pacemaker がコンテナーの起動と停止のアクションを制御するようにするためです。

4.3.1. 簡易バンドルセットリソース (簡易バンドル)

簡易バンドルセットリソースまたは 簡易バンドル は、コンテナーのセットで、各コンテナーには全コントローラーノードに渡ってデプロイされる、同じ Pacemaker サービスが含まれます。

以下の例は、pcs status コマンドのバンドル設定を示しています。 

https://gitlab.cee.redhat.com/rhci-documentation/docs-Red_Hat_Enterprise_Virtualization/commit/bfc429f884809a197e9800312f65514c0691b175

各バンドルでは、以下の情報を確認することができます。

  • Pacemaker がサービスに割り当てた名前
  • バンドルに関連付けられたコンテナーの参照
  • 異なるコントローラーで実行されているレプリカとそれらのステータスの一覧

4.3.1.1. 簡易バンドルの設定

haproxy-bundle サービスなど、特定のバンドルサービスの詳細を確認するには、pcs resource show コマンドを使用します。以下に例を示します。 

$ sudo pcs resource show haproxy-clone
Bundle: haproxy-bundle
 Docker: image=192.168.24.1:8787/rhosp12/openstack-haproxy:pcmklatest network=host options="--user=root --log-driver=journald -e KOLLA_CONFIG_STRATEGY=COPY_ALWAYS" replicas=3 run-command="/bin/bash /usr/local/bin/kolla_start"
 Storage Mapping:
  options=ro source-dir=/var/lib/kolla/config_files/haproxy.json target-dir=/var/lib/kolla/config_files/config.json (haproxy-cfg-files)
  options=ro source-dir=/var/lib/config-data/puppet-generated/haproxy/ target-dir=/var/lib/kolla/config_files/src (haproxy-cfg-data)
  options=ro source-dir=/etc/hosts target-dir=/etc/hosts (haproxy-hosts)
  options=ro source-dir=/etc/localtime target-dir=/etc/localtime (haproxy-localtime)
  options=ro source-dir=/etc/pki/ca-trust/extracted target-dir=/etc/pki/ca-trust/extracted (haproxy-pki-extracted)
  options=ro source-dir=/etc/pki/tls/certs/ca-bundle.crt target-dir=/etc/pki/tls/certs/ca-bundle.crt (haproxy-pki-ca-bundle-crt)
  options=ro source-dir=/etc/pki/tls/certs/ca-bundle.trust.crt target-dir=/etc/pki/tls/certs/ca-bundle.trust.crt (haproxy-pki-ca-bundle-trust-crt)
  options=ro source-dir=/etc/pki/tls/cert.pem target-dir=/etc/pki/tls/cert.pem (haproxy-pki-cert)
  options=rw source-dir=/dev/log target-dir=/dev/log (haproxy-dev-log)

haproxy-bundle の例では、HAProxy のリソース設定も確認できます。HAProxy は、選択したサービスへのトラフィックの負荷を分散することによって高可用性サービスを提供しますが、ここでは HAProxy を Pacemaker のバンドルサービスとして設定することによって HAProxy 自体を高可用性に保っています。

この出力例から、バンドルによって Docker コンテナーがいくつかの特定のパラメーターで設定されていることがわかります。

  • image: コンテナーによって使用されるイメージ。アンダークラウドのローカルレジストリーを参照します。
  • network: コンテナーのネットワーク種別。この例では "host" です。
  • options: コンテナーの特定のオプション
  • replicas: クラスター内に作成される必要のあるコンテナーのコピーを数。各バンドルには、3 つのコンテナーが含まれ、コントローラーノード 1 台に 1 つです。
  • run-command: コンテナーの起動に使用するシステムコマンド

Docker コンテナーの仕様に加えて、バンドル設定には、ホスト上のローカルパスをコンテナーにマップする Storage Mapping セクションも含まれています。したがって、ホストからhaproxy の設定を確認するには、/etc/haproxy/haproxy.cfg ファイルの代わりに /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg ファイルを開いてください。

4.3.1.2. 簡易バンドルのステータスの確認

コンテナー内でコマンドを起動する docker コマンドを使用して、バンドルのステータスを確認できます。 

$ sudo docker exec -it haproxy-bundle-docker-0 ps -efww | grep haproxy
root           1       0  0 Feb14 ?        00:00:00 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg
haproxy       10       1  0 Feb14 ?        00:00:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -Ds
haproxy       11      10  0 Feb14 ?        00:07:47 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -Ds

この出力は、コンテナー内でプロセスが実行されていることを示しています。

ホストから直接バンドルのステータスを確認することもできます。 

$ ps -ef | grep haproxy
root       60972   60956  0 Feb14 ?        00:00:00 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg
42454      61023   60972  0 Feb14 ?        00:00:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -Ds
42454      61029   61023  0 Feb14 ?        00:07:49 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -Ds
heat-ad+  223079  871280  0 11:45 pts/0    00:00:00 grep --color=auto haproxy
$ sudo ps -ef | grep [6]0956
root       60956   18734  0 Feb14 ?        00:00:00 /usr/bin/docker-containerd-shim-current 39238c5ecb77[...]
root       60972   60956  0 Feb14 ?        00:00:00 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg
$ sudo docker ps | grep haproxy-bundle
39238c5ecb77        192.168.24.1:8787/rhosp12/openstack-haproxy:pcmklatest                     "/bin/bash /usr/local"   17 hours ago        Up 17 hours                                 haproxy-bundle-docker-0

検出された haproxy コマンドの parent pid 属性 (60956) を使用して、Docker コンテナーの ID (39238c5ecb77) が含まれるメインの Docker プロセスを検索することができます。これは、docker ps コマンドの出力で表示される ID です。

任意のバンドルで同じコマンドを実行して、現在のアクティビティーレベルと、サービスによって実行されているコマンドに関する情報を確認することができます。

4.3.2. 複合バンドルセットのリソース (複合バンドル)

複合バンドルセットリソースまたは 複合バンドル は、簡易バンドルにも含まれる基本的なコンテナーの設定に加えて、リソース 設定を指定する Pacemaker サービスです。

この追加の設定は、実行するコントローラノードによって異なる状態にすることができるサービスである multi-State のリソースを管理するために必要です。

以下の例には、pcs status コマンドで出力される複合バンドルの一覧を示しています。 

Docker container set: rabbitmq-bundle [192.168.24.1:8787/rhosp12/openstack-rabbitmq:pcmklatest]
  rabbitmq-bundle-0    (ocf::heartbeat:rabbitmq-cluster):      Started overcloud-controller-0
  rabbitmq-bundle-1    (ocf::heartbeat:rabbitmq-cluster):      Started overcloud-controller-1
  rabbitmq-bundle-2    (ocf::heartbeat:rabbitmq-cluster):      Started overcloud-controller-2
Docker container set: galera-bundle [192.168.24.1:8787/rhosp12/openstack-mariadb:pcmklatest]
  galera-bundle-0      (ocf::heartbeat:galera):        Master overcloud-controller-0
  galera-bundle-1      (ocf::heartbeat:galera):        Master overcloud-controller-1
  galera-bundle-2      (ocf::heartbeat:galera):        Master overcloud-controller-2
Docker container set: redis-bundle [192.168.24.1:8787/rhosp12/openstack-redis:pcmklatest]
  redis-bundle-0       (ocf::heartbeat:redis): Master overcloud-controller-0
  redis-bundle-1       (ocf::heartbeat:redis): Slave overcloud-controller-1
  redis-bundle-2       (ocf::heartbeat:redis): Slave overcloud-controller-2

この出力では、RabbitMQ とは異なり、Galera と Redis のバンドルは multi-state リソースとしてコンテナー内で実行されていることがわかります。

galera-bundle リソースでは、3 つのコントローラーすべてが Galera master として実行されています。redis-bundle リソースでは、overcloud-controller-0 コンテナーが master として実行されている一方で、他の 2 つのコントローラーはスレーブとして実行されています。

Galera サービスは 3 つのコントローラーすべてで 1 つの制約のセットで実行されていますが、redis サービスはマスターとスレーブのコントローラーで異なる制約下で実行できることを意味します。

以下の例は、pcs resource show galera-bundle コマンドの出力を示しています。 

[...]
Bundle: galera-bundle
 Docker: image=192.168.24.1:8787/rhosp12/openstack-mariadb:pcmklatest masters=3 network=host options="--user=root --log-driver=journald -e KOLLA_CONFIG_STRATEGY=COPY_ALWAYS" replicas=3 run-command="/bin/bash /usr/local/bin/kolla_start"
 Network: control-port=3123
 Storage Mapping:
  options=ro source-dir=/var/lib/kolla/config_files/mysql.json target-dir=/var/lib/kolla/config_files/config.json (mysql-cfg-files)
  options=ro source-dir=/var/lib/config-data/puppet-generated/mysql/ target-dir=/var/lib/kolla/config_files/src (mysql-cfg-data)
  options=ro source-dir=/etc/hosts target-dir=/etc/hosts (mysql-hosts)
  options=ro source-dir=/etc/localtime target-dir=/etc/localtime (mysql-localtime)
  options=rw source-dir=/var/lib/mysql target-dir=/var/lib/mysql (mysql-lib)
  options=rw source-dir=/var/log/mariadb target-dir=/var/log/mariadb (mysql-log-mariadb)
  options=rw source-dir=/dev/log target-dir=/dev/log (mysql-dev-log)
 Resource: galera (class=ocf provider=heartbeat type=galera)
  Attributes: additional_parameters=--open-files-limit=16384 cluster_host_map=overcloud-controller-0:overcloud-controller-0.internalapi.localdomain;overcloud-controller-1:overcloud-controller-1.internalapi.localdomain;overcloud-controller-2:overcloud-controller-2.internalapi.localdomain enable_creation=true wsrep_cluster_address=gcomm://overcloud-controller-0.internalapi.localdomain,overcloud-controller-1.internalapi.localdomain,overcloud-controller-2.internalapi.localdomain
  Meta Attrs: container-attribute-target=host master-max=3 ordered=true
  Operations: demote interval=0s timeout=120 (galera-demote-interval-0s)
              monitor interval=20 timeout=30 (galera-monitor-interval-20)
              monitor interval=10 role=Master timeout=30 (galera-monitor-interval-10)
              monitor interval=30 role=Slave timeout=30 (galera-monitor-interval-30)
              promote interval=0s on-fail=block timeout=300s (galera-promote-interval-0s)
              start interval=0s timeout=120 (galera-start-interval-0s)
              stop interval=0s timeout=120 (galera-stop-interval-0s)
[...]

この出力は、簡易バンドルとは異なり、galera-bundle リソースには、multi-state リソースのあらゆる側面を決定する明示的なリソース設定が含まれていることを示しています。

注記

また、サービスは、同時に複数のコントローラーで実行される可能性がありますが、コントローラー自体は、これらのサービスに実際に到達する必要のある IP アドレスでリッスンしていない場合もあります。

Galera リソースのトラブルシューティングに関する詳しい情報は「6章Galera の使用」を参照してください。

4.4. Pacemaker の Failed Actions

リソースが何らかの形で失敗した場合には、pcs status の出力の Failed actions タイトル下に記載されます。以下は、openstack-cinder-volume サービスが controller-0 上で停止した例です。 

Failed Actions:
* openstack-cinder-volume_monitor_60000 on overcloud-controller-0 'not running' (7): call=74, status=complete, exitreason='none',
	last-rc-change='Wed Dec 14 08:33:14 2016', queued=0ms, exec=0ms

このような場合には、systemd サービスの openstack-cinder-volume を再有効化する必要があります。その他の場合には、問題を追跡/修正してからリソースをクリーンアップする必要があります。詳細は、「コントローラー上のリソースの問題修正」を参照してください。

4.5. コントローラーのその他の Pacemaker 情報

pcs status 出力の最後のセクションでは、電源管理フェンシング (ここでは IPMI) および Pacemaker サービス自体の状態に関する情報が表示されます。 

 my-ipmilan-for-controller-0	(stonith:fence_ipmilan): Started my-ipmilan-for-controller-0
 my-ipmilan-for-controller-1	(stonith:fence_ipmilan): Started my-ipmilan-for-controller-1
 my-ipmilan-for-controller-2	(stonith:fence_ipmilan): Started my-ipmilan-for-controller-2

PCSD Status:
  overcloud-controller-0: Online
  overcloud-controller-1: Online
  overcloud-controller-2: Online

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled openstack-cinder-volume        (systemd:openstack-cinder-volume):      Started overcloud-controller-0

  pcsd: active/enabled

my-ipmilan-for-controller の設定では、各ノードに指定されたフェンシングの種別 (stonith:fence_ipmilan) および IPMI サービスの稼働状態が分かります。PCSD Status は、全 3 コントローラーが現在オンラインであることを示します。また、Pacemaker サービス自体には corosync、pacemaker、pcsdpcsd の 3 つのデーモンで構成されています。この例では、これら 3 つのサービスすべてがアクティブかつ有効化されています。

4.6. フェンシング用のハードウェア

コントローラーノードがヘルスチェックに失敗すると、Pacemaker 指定のコーディネーターとして機能するコントローラーは、Pacemaker stonith サービスを使用して、問題のあるノードをフェンシングします。Stonith は、「Shoot The Other Node In The Head」の略で、基本的に DC はクラスターからノードを除外します。

stonith により、フェンスデバイスが OpenStack Platform HA クラスターでどのように設定されているかを確認するには、以下のコマンドを実行します。 

$ sudo pcs stonith show --full
 Resource: my-ipmilan-for-controller-0 (class=stonith type=fence_ipmilan)
  Attributes: pcmk_host_list=overcloud-controller-0 ipaddr=10.100.0.51 login=admin passwd=abc lanplus=1 cipher=3
  Operations: monitor interval=60s (my-ipmilan-for-controller-0-monitor-interval-60s)
 Resource: my-ipmilan-for-controller-1 (class=stonith type=fence_ipmilan)
  Attributes: pcmk_host_list=overcloud-controller-1 ipaddr=10.100.0.52 login=admin passwd=abc lanplus=1 cipher=3
  Operations: monitor interval=60s (my-ipmilan-for-controller-1-monitor-interval-60s)
 Resource: my-ipmilan-for-controller-2 (class=stonith type=fence_ipmilan)
  Attributes: pcmk_host_list=overcloud-controller-2 ipaddr=10.100.0.53 login=admin passwd=abc lanplus=1 cipher=3
  Operations: monitor interval=60s (my-ipmilan-for-controller-2-monitor-interval-60s)

show --full の一覧では、フェンシングに関連するコントローラーノード 3 つの詳細が表示されます。フェンスデバイスは、IPMI 電源管理 (fence_ipmilan) を使用して、必要に応じてマシンの電源のオン/オフを切り替えます。各ノードの IPMI インターフェースに関する情報には、IPMI インターフェースの IP アドレス (10.100.0.51)、ログインするユーザー名 (admin)、使用するパスワード (abc) が含まれます。各ホストが監視される間隔も (60 秒) 確認することができます。

Pacemaker を使用したフェンシングに関する詳しい情報は、『Red Hat Enterprise Linux 7 High Availability Add-On の管理』の「フェンシングの設定」を参照してください。