第4章 Pacemaker の使用

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

4.1. Pacemaker の一般情報

pcs status の出力の最初の部分には、クラスターの名前、クラスターの最近の変更、現在の DC、クラスター内のノード数、クラスターで設定されたリソース数、クラスター内のノードが表示されます。 

$ sudo pcs status
    Cluster name: tripleo_cluster
    Last updated: Mon Oct  5 13:42:37 2015
    Last change: Mon Oct  5 13:03:06 2015
    Stack: corosync
    Current DC: overcloud-controller-1 (2) - partition with quorum
    Version: 1.1.12-a14efad
    3 Nodes configured
    115 Resources configured
    Online: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]

    Full list of resources:
...

sudo pcs status からの最初の出力では、クラスターの名前は tripleo_cluster で、3 つのノード (overcloud-controller-0、-1、-2) で構成されていることが分かります。これら 3 つのノードはすべて現在オンライン状態です。

また、名前が tripleo_cluster のクラスター内で管理されるように設定されたリソースは、システムのデプロイ方法により変化する可能性があります。この例では、リソースは 115 個あります。

pcs status からの出力の次の部分では、どのリソースが開始されたのか (IP アドレス、サービスなど)、さらにそれらのリソースはどのコントローラーノードで実行されているのかが分かります。以下の項では、その出力例を紹介します。

Pacemaker についてのさらに詳しい情報は、以下のドキュメントを参照してください。

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

各 IPaddr2 リソースは、クライアントがサービスへのアクセスを要求する際に使用する仮想 IP アドレスを設定します。その IP アドレスが割り当てられたコントローラーノードがダウンした場合には、この IP アドレスは別のコントローラーに再度割り当てられます。この例では、各コントローラー (overcloud-controller-0、-1 など) が現在、特定の仮想 IP アドレスをリッスンするように設定されていることが分かります。 

 ip-192.168.1.150	(ocf::heartbeat:IPaddr2):	Started overcloud-controller-0
 ip-10.200.0.6	(ocf::heartbeat:IPaddr2):	Started overcloud-controller-1
 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 アドレスは最初に、特定のコントローラー (例: overcloud-controller-0 上で 192.168.1.150 が起動) にアタッチされる点に注意してください。ただし、そのコントローラーが停止した場合には、その IP アドレスは、このクラスター内の別のコントローラーに再割り当てされます。上記の IP アドレスについての説明と、それらの IP アドレスが最初にどのように割り当てられたのかを以下に記載します。

  • 192.168.1.150: パブリック IP アドレス (network-environment.yaml の ExternalAllocationPools から割り当て)
  • 10.200.0.6: コントローラーの仮想 IP アドレス (undercloud.conf 内に dhcp_start および dhcp_end range 範囲セットの一部は 10.200.0.5-10.200.0.24 に設定)
  • 172.16.0.10: コントローラー上の OpenStack API サービスへのアクセスを提供する IP アドレス (network-environment.yaml の InternalApiAllocationPools から割り当て)
  • 172.16.0.11: コントローラー上の Redis サービスへのアクセスを提供する IP アドレス (network-environment.yaml の InternalApiAllocationPools から割り当て)
  • 172.18.0.10: Glance API および Swift プロキシーサービスへのアクセスを提供するストレージ仮想 IP アドレス (network-environment.yaml の StorageAllocationPools から割り当て)
  • 172.19.0.10: ストレージ管理へのアクセスを提供する IP アドレス (network-environment.yaml の StorageMgmtAlloctionPools から割り当て)

pcs コマンドを使用して、Pacemaker に設定された特定の IPaddr2 アドレスに関する詳細を表示することができます。たとえば、特定の仮想 IP アドレスに関するタイムアウトおよびその他の付属情報を表示するには、IPaddr2 のいずれかで以下を入力します。 

$ 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
    tcp  0  0 192.168.1.150:6080      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:9696      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:8000      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:8003      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:8004      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:8773      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:8774      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:5000      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:8776      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:8777      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:9292      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:8080      0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:80        0.0.0.0:*  LISTEN      4333/haproxy
    tcp  0  0 192.168.1.150:35357     0.0.0.0:*  LISTEN      4333/haproxy
    udp  0  0 192.168.1.150:123       0.0.0.0:*              459/ntpd
    ...
    tcp  0  0 0.0.0.0:22              0.0.0.0:*  LISTEN      2471/sshd
    tcp  0  0 0.0.0.0:4567            0.0.0.0:*  LISTEN      10064/mysqld
    ...
    udp  0  0 0.0.0.0:51475           0.0.0.0:*              545/dhclient
    udp  0  0 0.0.0.0:123             0.0.0.0:*              459/ntpd
    udp  0  0 0.0.0.0:161             0.0.0.0:*              1633/snmpd
    ...

ip コマンドから、vlan100 インターフェースが 192.168.1.150 および 192.168.1.151 IPv4 アドレスの両方をリッスンしていることが分かります。netstat コマンドの出力では、192.168.1.150 インターフェースでリッスンするプロセスすべてが表示されます。ntpd プロセス (ポート 123 をリッスン) 以外に、haproxy プロセスだけが 192.168.1.150 を専用でリッスンするプロセスです。また、すべてのローカルアドレス (0.0.0.0) をリッスンするプロセスも 192.168.1.150 (sshd、mysqld、dhclient、ntpd など) 経由で利用可能である点に注意してください。

netstat の出力で表示されたポート番号により、haproxy がリッスンするサービスが具体的にどれなのかを特定しやすくなります /etc/haproxy/haproxy.cfg ファイルの内容から、これらのポート番号がどのサービスを表しているかを確認してください。以下にいくつか例を示します。

  • TCP ポート 6080: nova_novncproxy
  • TCP ポート 9696: neutron
  • TCP ポート 8000: heat_cfn
  • TCP ポート 8003: heat_cloudwatch
  • TCP ポート 80: horizon

今回は、haproxy.cfg 内には、3 つのコントローラーすべてで 192.168.1.150 を特にリッスンしている 14 のサービスがあります。ただし、現在、実際に 192.168.1.150 を外部でリッスンしているのは controller-0 のみなので、controller-0 が停止した場合には、HAProxy が別のコントローラーに再割当てする必要があるのは 192.168.1.150 のみで、全サービスがすでに実行中となります。

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

大半のサービスは、Clone Set リソース (または clones) として設定されます。この設定では、リソースは各コントローラーで同じ方法で起動され、各コントローラーで常時実行されます。サービスは、複数のノードでアクティブな状態である必要がある場合にクローンされます。そのため、クローンが可能なのは、複数のノードで同時にアクティブにすることが可能なサービス (cluster-aware services) のみとなります。

その他のサービスは、Multi-state リソースとして設定されます。Multi-state リソースは、通常の Clone Set リソースとは異なり、特別なタイプのクローンです。Multi-state リソースは マスター または スレーブ のいずれかの状態が可能です。インスタンスの起動時には、スレーブ の状態である必要があります。それ以外には、いずれの状態名も特別な意味はありませんが、これらの状態により、同じサービスのクローンが異なるルールまたは制約に従って実行することを可能となります。

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

Clone Set リソース (clones)

pcs status からのクローン設定は以下のようになります。 

 Clone Set: haproxy-clone [haproxy]
 	Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
 Clone Set: rabbitmq-clone [rabbitmq]
 	Started: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]

Clone Set リソースごとに、以下の情報を確認することができます。

  • Pacemaker がサービスに割り当てた名前
  • 実際のサービス名
  • サービスが起動または停止されるコントローラー

Clone Set を使用すると、サービスは、全コントローラー上で同じ方法で起動されるようになります。特定のクローンサービス (haproxy サービスなど) に関する詳細を表示するには、pcs resource show コマンドを使用します。以下に例を示します。 

$ sudo pcs resource show haproxy-clone
 Clone: haproxy-clone
  Resource: haproxy (class=systemd type=haproxy)
   Operations: start interval=0s timeout=60s (haproxy-start-timeout-60s)
               monitor interval=60s (haproxy-monitor-interval-60s)
$ sudo systemctl status haproxy
haproxy.service - Cluster Controlled haproxy
   Loaded: loaded (/usr/lib/systemd/system/haproxy.service; disabled)
  Drop-In: /run/systemd/system/haproxy.service.d
           └─50-pacemaker.conf
   Active: active (running) since Tue 2015-10-06 08:58:49 EDT; 1h 52min ago
 Main PID: 4215 (haproxy-systemd)
   CGroup: /system.slice/haproxy.service
           ├─4215 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
           ├─4216 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
           └─4217 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds

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

この出力では、リソースが haproxy という名前の systemd サービスである点に注意してください。また、開始の間隔やタイムアウトの値、監視の間隔なども記載されています。systemctl status コマンドでは、haproxy がアクティブであることが分かります。haproxy サービスの実際に実行中のプロセスは、出力の最後に一覧表示されます。全コマンドラインが表示されているため、設定ファイル (haproxy.cfg) および PID ファイル (haproxy.pid) がこのコマンドと関連付けられていることが分かります。

任意の Clone Set リソースに同じコマンドを実行して、アクティビティーの現在のレベルやサービスが実行するコマンドの詳細を表示します。Pacemaker によって制御される systemd サービスは、systemd では disabled に設定されている点に注意してください。これは、サービスの起動または停止時には、システムのブートプロセスではなく Pacemaker により制御させるようにする必要があるためです。

Clone Set リソースについての詳しい情報は、『High Availability Add-On リファレンス』で「リソースのクローン」の項を参照してください。

マルチステートのリソース (マスター/スレーブ)

Galera および Redis のサービスは、マルチステート リソースとして実行されます。これらの 2 種類のサービスの pcs status 出力例を以下に示します。 

[...]
Master/Slave Set: galera-master [galera]
     Masters: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]

Master/Slave Set: redis-master [redis]
     Masters: [ overcloud-controller-2 ]
     Slaves: [ overcloud-controller-0 overcloud-controller-1 ]
[...]

galera-master リソースでは、3 つのコントローラーはすべて Gelera マスターとして実行されます。redis-master リソースで overcloud-controller-2 がマスターとして、残りの 2 つのコントローラーがスレーブとして実行されています。これは、現在 galera サービスが 3 つのコントローラーで単一の制約セットに従って実行されている一方で、redis はマスターまたはスレーブコントローラー上の異なる制約に従っている可能性があることを意味します。

マルチステート リソースについての詳しい情報は、『High Availability Add-On リファレンス』で「多状態のリソース: 複数モードのリソース」を参照してください。

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 秒) 確認することができます。