高可用性 (HA) のデプロイメントでは、コアコンテナー、アクティブ/パッシブ、systemd、プレーンコンテナー の 4 つのタイプのサービスがあります。コアコンテナーとアクティブ/パッシブのサービスは Pacemaker によって起動/管理されます。その他のサービスはすべて、systemd で systemctl コマンドを使用するか、Docker で docker コマンドを使用して、直接管理されます。

director を使用して HA デプロイメントを完全にオーケストレーションする場合には、director が使用するテンプレートと Puppet モジュールにより、HA 全サービスが設定され、特に HA に向けて正しく起動されます。また、HA の問題をトラブルシュートする場合には、HA フレームワーク、docker コマンド、systemctl コマンドのいずれかを使用してサービスと対話する必要があります。

以下の例は、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:
[...]

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

各 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 アドレスと、各アドレスが最初に割り当てられた方法をまとめています。

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 です。

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

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

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

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

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

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

$ 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)

$ 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

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

[...]
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)
[...]

リソースが何らかの形で失敗した場合には、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 を再有効化する必要があります。その他の場合には、問題を追跡/修正してからリソースをクリーンアップする必要があります。詳細は、「コントローラー上のリソースの問題修正」を参照してください。

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 つのサービスすべてがアクティブかつ有効化されています。

コントローラーノードがヘルスチェックに失敗すると、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 の管理』の「フェンシングの設定」を参照してください。

director により、HA デプロイメントではすべて、HAProxy Stats もデフォルトで有効になります。この機能により、データ転送、接続、サーバーの状態などについての詳細情報を HAProxy Stats のページで確認することができます。

また、director は、HAProxy Stats ページにアクセスするための IP:Port アドレスも設定します。このアドレスを確認するには、HAProxy がインストールされている任意のノードで /var/lib/config-data/haproxy/etc/haproxy/haproxy.cfg ファイルを開くと、listen haproxy.stats セクションにこの情報が記載されています。以下に例を示します。

listen haproxy.stats
  bind 10.200.0.6:1993
  mode http
  stats enable
  stats uri /
  stats auth admin:<haproxy-stats-password>

この場合は、ブラウザーで 10.200.0.6:1993 にナビゲートして、stats auth の行から認証情報を入力すると、HAProxy Stats のページが表示されます。

HAProxy に関する詳しい情報は、「HAProxy の設定」 (『ロードバランサーの管理』)を参照してください。

haproxy.cfg ファイルで使用可能な設定に関する詳しい情報は、haproxy パッケージがインストールされている任意のシステム (例: コントローラーノードなど) の /usr/share/doc/haproxy-_VERSION/configuration.txt_ のドキュメントを参照してください。

MariaDB Galera Cluster のトラブルシューティングを行う際には、ホスト名の解決を確認することができます。デフォルトでは、director は Galera リソースを IP アドレスにではなく hostname にバインドします。^[1]そのため、ホスト名の解決を妨げている問題 (例: 設定の誤りや DNS のエラーなど) があると、Pacemaker が Galera リソースを適切に管理できなくなる可能性があります。

ホスト名の解決の問題がないことを確認した後には、クラスター自体の整合性をチェックしてください。そのためには、各コントローラーノードのデータベースで、Write Set Replication のステータスを確認します。

MySQL にアクセスするには、オーバークラウドのデプロイメント中に director によって設定されたパスワードを使用します。MySQL の root パスワードを取得するには、hiera コマンドを使用します。

$ sudo hiera -c /etc/puppet/hiera.yaml "mysql::server::root_password"
*<MYSQL-HIERA-PASSWORD>*

Write Set Replication の情報は、各ノードの MariaDB データベースに保管されます。関連する変数はそれぞれ wsrep_ のプレフィックスを使用します。そのため、この情報はデータベースクライアントで直接問い合わせることができます。

$ sudo mysql -B --password="<MYSQL-HIERA-PASSWORD>" -e "SHOW GLOBAL STATUS LIKE 'wsrep_%';"
    +------------------------+-------+
    | Variable_name          | Value |
    +------------------------+-------+
    | wsrep_protocol_version | 5     |
    | wsrep_last_committed   | 202   |
    | ...                    | ...   |
    | wsrep_thread_count     | 2     |
    +------------------------+-------+

MariaDB Galera Cluster の正常性と整合性を検証するには、まず最初にクラスターが正しいノード数を報告するかどうかを確認してから、各ノードで以下の点をチェックします。

MariaDB Galera Cluster の問題を調査する際には、クラスター自体の整合性を確認することができます。クラスターの整合性を検証するには、各コントローラーノード上の特定の wsrep_ データベース変数を確認する必要があります。データベースの変数を確認するには、次のコマンドを実行します。

$ sudo mysql -B --password="<MYSQL-HIERA-PASSWORD>" -e "SHOW GLOBAL STATUS LIKE 'VARIABLE';"

VARIABLE は確認する wsrep_ データベース変数に置き換えてください。たとえば、ノードの cluster state UUID を確認するには、以下のコマンドを実行します。

$ sudo mysql -B --password="<MYSQL-HIERA-PASSWORD>" -e "SHOW GLOBAL STATUS LIKE 'wsrep_cluster_state_uuid';"
    +--------------------------+--------------------------------------+
    | Variable_name            | Value                                |
    +--------------------------+--------------------------------------+
    | wsrep_cluster_state_uuid | e2c9a15e-5485-11e0-0800-6bbb637e7211 |
    +--------------------------+--------------------------------------+

以下の表には、クラスターの整合性と関連するさまざまな wsrep_ データベース変数をまとめています。

Galera クラスターの問題を特定のノードに切り分けすることができる場合には、その他の wsrep_ データベース変数が具体的な問題を解く手がかりとなる可能性があります。これらの変数は、「データベースクラスターの整合性」に記載のクラスターのチェックと同様の方法で確認することができます。

$ sudo mysql -B --password="<MYSQL-HIERA-PASSWORD>" -e "SHOW GLOBAL STATUS LIKE 'VARIABLE';"

VARIABLE は以下の値のいずれかに置き換えます。

クラスターおよびそのクラスター内の個々のノードが正常な状態で安定している場合には、レプリケーションのスループットを確認して、パフォーマンスのベンチマークを行うことができます。この作業は、「データベースクラスターノード」および「データベースクラスターの整合性」と同様に wsrep_ データベースの変数をチェックすることによって行います。

$ sudo mysql -B --password="<MYSQL-HIERA-PASSWORD>" -e "SHOW STATUS LIKE 'VARIABLE';"

VARIABLE は以下の値のいずれかに置き換えます。

それらの変数のいずれかをクエリーするときには毎回、FLUSH STATUS コマンドを実行すると値がリセットされます。クラスターのレプリケーションのベンチマークを行うには、それらの値を複数回クエリーして、その変化を確認する必要があります。この変化は、フロー制御 がクラスターのパフォーマンスにどの程度影響を及ぼしているかを判断するのに役立てることができます。

フロー制御とは、クラスターがレプリケーションを制御するのに使用するメカニズムです。ローカル受信 Write Set キューが一定の閾値を超えると、ノードがそのキューに追い付くために、フロー制御がレプリケーションを一時停止します。詳しくは、Galera Cluster のサイトで、「Flow Control」のセクションを参照してください。

異なる値およびベンチマークを最適化するには、以下の変数をチェックします。

クラスターによって管理されているリソースに関する失敗したアクションは、pcs status コマンドで表示されます。多くの異なる問題が発生する可能性があります。一般的には、以下の方法で問題に対処することができます。