高可用性デプロイメントと使用方法

手順

1. 動作中の HA 環境で、アンダークラウドに stack ユーザーとしてログインします。

2. オーバークラウドノードの IP アドレスを特定します。

   $ source ~/stackrc
   (undercloud) $ openstack server list
    +-------+------------------------+---+----------------------+---+
    | ID    | Name                   |...| Networks             |...|
    +-------+------------------------+---+----------------------+---+
    | d1... | overcloud-controller-0 |...| ctlplane=*10.200.0.11* |...|
    ...

3. オーバークラウドノードのいずれかにログインします。

   (undercloud) $ ssh heat-admin@<node_IP>

   <node_ip> は、ログインするノードの IP アドレスに置き換えます。

手順

1. 任意のコントローラーノードに heat-admin ユーザーとしてログインします。

   $ ssh heat-admin@overcloud-controller-0

2. pcs status コマンドを実行します。

   [heat-admin@overcloud-controller-0 ~]  $ sudo pcs status

   出力例:

   Cluster name: tripleo_cluster
   Stack: corosync
   Current DC: overcloud-controller-1 (version 2.0.1-4.el8-0eb7991564) - 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
   37 resources configured
   
   Online: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
   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 ]
   
   Full list of resources:
   [...]

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

   • Cluster name: クラスターの名前。
   • [NUM] nodes configured: クラスターを設定するノードの数
   • [NUM] resources configured: クラスターに設定されているリソースの数
   • Online: 現在オンライン状態の Controller ノードの名前
   • GuestOnline: 現在オンライン状態のゲストノードの名前。各ゲストノードは、複合バンドルセットのリソースで設定されています。バンドルセットの詳細は、「Pacemaker リソースバンドルとコンテナー」 を参照してください。

手順

1. 任意のコントローラーノードに heat-admin ユーザーとしてログインします。

   $ ssh heat-admin@overcloud-controller-0

2. 以下のオプションのいずれかを使用します。

   • --full オプションを指定して pcs resource show コマンドを実行し、仮想 IP を使用する全リソースを表示します。

     $ sudo pcs resource show --full

     出力例:

      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 アドレスと、各 IP アドレスの初期の割り当てをまとめています。

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

     IP アドレス	説明	割り当て元
     10.200.0.6	コントローラーの仮想 IP アドレス	dhcp_start および dhcp_end の範囲の部分は、undercloud.conf ファイルで 10.200.0.5-10.200.0.24 に設定されます。
     192.168.1.150	パブリック IP アドレス	network-environment.yaml ファイルの ExternalAllocationPools 属性
     172.16.0.10	コントローラーノード上の OpenStack API サービスへのアクセスを提供します。	network-environment.yaml ファイルの InternalApiAllocationPools
     172.16.0.11	コントローラーノード上の Radis サービスへのアクセスを提供します。	network-environment.yaml ファイルの InternalApiAllocationPools
     172.18.0.10	Glance API および Swift プロキシーのサービスへのアクセスを提供するストレージの仮想 IP アドレス	network-environment.yaml ファイルの StorageAllocationPools 属性
     172.19.0.10	ストレージ管理へのアクセスを提供します。	network-environment.yaml ファイルの StorageMgmtAlloctionPools

   • 特定の仮想 IP を使用するリソースの名前を指定して pcs resource show コマンドを実行して、その仮想 IP のアドレスを表示します (以下の例では ip-192.168.1.150)。

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

手順

1. 表示する IP アドレスに割り当てられているコントローラーノードにログインし、ネットワークインターフェイスで ip addr show コマンドを実行します (以下の例では vlan100)。

   $ 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

2. netstat コマンドを実行し、その IP アドレスをリッスンしているすべてのプロセスを表示します (以下の例では 192.168.1.150.haproxy)。

   $ 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

   注記

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

3. HA サービスの設定ファイルを開くことで、デフォルトのポート番号の割り当てとリッスンするサービスを確認します (以下の例では /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 を別のコントローラーノードに再割り当てするだけで、他のサービスはすべてフォールバックコントローラーノードですでに実行されている状態となります。

手順

1. 任意のコントローラーノードに heat-admin ユーザーとしてログインします。

   $ ssh heat-admin@overcloud-controller-0

2. pcs status コマンドを実行します。

   [heat-admin@overcloud-controller-0 ~]  $ sudo pcs status

   出力例:

    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

   この出力には、pcs status コマンドの出力の以下のセクションが表示されます。

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

手順

1. それぞれのコントローラーノードに heat-admin ユーザーとしてログインします。

2. クラスターが動作状態にあることを確認します。

   $ sudo pcs status

   出力例:

   Cluster name: openstackHA
   Last updated: Wed Jun 24 12:40:27 2015
   Last change: Wed Jun 24 11:36:18 2015
   Stack: corosync
   Current DC: lb-c1a2 (2) - partition with quorum
   Version: 1.1.12-a14efad
   3 Nodes configured
   141 Resources configured

3. STONITH が無効になっていることを確認します。

   $ sudo pcs property show

   出力例:

   Cluster Properties:
   cluster-infrastructure: corosync
   cluster-name: openstackHA
   dc-version: 1.1.12-a14efad
   have-watchdog: false
   stonith-enabled: false

4. 使用するフェンシングエージェントに応じて、以下のオプションのいずれかを選択します。

   • IPMI または RHV のフェンシングエージェントを使用する場合は、fencing.yaml 環境ファイルを生成します。

     (undercloud) $ openstack overcloud generate fencing --output fencing.yaml nodes.json

     注記

     このコマンドにより、ilo および drac の電源管理情報が等価な IPMI 版に変換されます。

   • STONITH Block Device (SBD)、fence_kdump、あるいは Redfish 等の別のフェンシングエージェントを使用する場合、または事前にプロビジョニングされたノードを使用する場合は、手動で fencing.yaml ファイルを作成します。

5. SBD フェンシングのみ: 以下のパラメーターを fencing.yaml ファイルに追加します。

   parameter_defaults:
     ExtraConfig:
       pacemaker::corosync::enable_sbd: true

   注記

   このステップは、初回のオーバークラウドデプロイメントにのみ適用されます。既存のオーバークラウドで SBD フェンシングを有効にする方法の詳細は、RHEL 7 と RHEL 8 での sbd フェンシングの有効化 を参照してください。

6. マルチレイヤーフェンシングのみ: 生成された fencing.yaml ファイルにレベル固有のパラメーターを追加します。

   parameter_defaults:
     EnableFencing: true
     FencingConfig:
       devices:
         level1:
         - agent: [VALUE]
           host_mac: "aa:bb:cc:dd:ee:ff"
           params:
             <parameter>: <value>
         level2:
         - agent: fence_agent2
           host_mac: "aa:bb:cc:dd:ee:ff"
           params:
             <parameter>: <value>

   <parameter> および <value> を、フェンシングエージェントが必要とする実際のパラメーターおよび値に置き換えてください。

7. fencing.yaml ファイルおよびデプロイメントに該当するその他の環境ファイルを指定して、overcloud deploy コマンドを実行します。

   openstack overcloud deploy --templates \
   -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
   -e ~/templates/network-environment.yaml \
   -e ~/templates/storage-environment.yaml --ntp-server pool.ntp.org --neutron-network-type vxlan --neutron-tunnel-types vxlan \
   -e fencing.yaml

8. SBD フェンシングのみ: ウォッチドッグタイマーデバイスの間隔を設定し、間隔が正しく設定されていることを確認します。

   # pcs property set stonith-watchdog-timeout=<interval>
   # pcs property show

検証

1. heat-admin ユーザーとしてオーバークラウドにログインし、Pacemaker がリソースマネージャーとして設定されていることを確認します。

   $ source stackrc
   $ openstack server list | grep controller
   $ ssh heat-admin@<controller-x_ip>
   $ sudo pcs status | grep fence
   stonith-overcloud-controller-x (stonith:fence_ipmilan): Started overcloud-controller-y

   この例では、Pacemaker は、fencing.yaml ファイルで指定された各コントローラーノードに STONITH リソースを使用するように設定されています。

   注記

   制御するのと同じノードに fence-resource プロセスを設定することはできません。

2. フェンシングリソースの属性を確認します。STONITH 属性の値は、fencing.yaml ファイルの値と一致している必要があります。

   $ sudo pcs stonith show <stonith-resource-controller-x>

手順

1. stack ユーザーとしてコントローラーノードにログインし、source コマンドで認証情報ファイルを読み込みます。

   $ source stackrc
   $ openstack server list | grep controller
   $ ssh heat-admin@<controller-x_ip>

2. root ユーザーに切り替え、コントローラーノードへの接続をすべて閉じます。

   $ sudo -i
   iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT &&
   iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT &&
   iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 5016 -j ACCEPT &&
   iptables -A INPUT -p udp -m state --state NEW -m udp --dport 5016 -j ACCEPT &&
   iptables -A INPUT ! -i lo -j REJECT --reject-with icmp-host-prohibited &&
   iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT &&
   iptables -A OUTPUT -p tcp --sport 5016 -j ACCEPT &&
   iptables -A OUTPUT -p udp --sport 5016 -j ACCEPT &&
   iptables -A OUTPUT ! -o lo -j REJECT --reject-with icmp-host-prohibited

3. 別のコントローラーノードから、Pacemaker のログファイルでフェンシングイベントの有無を確認します。

   $ ssh heat-admin@<controller-x_ip>
   $ less /var/log/cluster/corosync.log
   (less): /fenc*

   STONITH サービスがコントローラーでフェンシングアクションを実行していれば、ログファイルにフェンシングイベントが記録されます。

4. 数分間待ってから pcs status コマンドを実行して、再起動したコントローラーノードがクラスター内で再度実行されていることを確認します。再起動したコントローラーノードが出力に表示される場合には、フェンシングが正しく機能しています。

手順

1. HAProxy がインストールされている任意のコントローラーノードで /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg ファイルを開きます。

2. listen haproxy.stats セクションを探します。

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

3. Web ブラウザーで 10.200.0.6:1993 に移動し、stats auth 行の認証情報を入力して HAProxy Stats ページを表示します。

手順

1. コントローラーノードから hiera コマンドを実行し、MariaDB データベースの root パスワードを取得します。

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

2. ノードで実行される MariaDB コンテナーの名前を取得します。

   $ sudo podman ps | grep -i galera
   a403d96c5026  undercloud.ctlplane.localdomain:8787/rhosp-rhel8/openstack-mariadb:16.0-106            /bin/bash /usr/lo...  3 hours ago  Up 3 hours ago         galera-bundle-podman-0

3. 各ノードの MariaDB データベースから、Write Set のレプリケーション情報を取得します。

   $ sudo podman exec galera-bundle-podman-0 sudo mysql -B --password="[MYSQL-HIERA-PASSWORD]" -e "SHOW GLOBAL STATUS LIKE 'wsrep_%';"
       +----------------------------+----------+
       | Variable_name              | Value    |
       +----------------------------+----------+
       | wsrep_applier_thread_count | 1        |
       | wsrep_apply_oooe           | 0.018672 |
       | wsrep_apply_oool           | 0.000630 |
       | wsrep_apply_window         | 1.021942 |
       | ...                        | ...      |
       +----------------------------+----------+

   関連する変数はそれぞれ wsrep の接頭辞を使用します。

4. クラスターが正しいノード数を報告することを確認して、MariaDB Galera Cluster の健全性および整合性を検証します。

手順

1. リソースに異常が発生しているコントローラーノードにログインします。

2. pcs status コマンドに grep オプションを付けて実行して、サービスのステータスを確認します。

   # sudo pcs status | grep cinder
     Podman container: openstack-cinder-volume [192.168.24.1:8787/rh-osbs/rhosp161-openstack-cinder-volume:pcmklatest]
       openstack-cinder-volume-podman-0     (ocf::heartbeat:podman):        Started controller-1

3. リソースのログイベントを表示します。

   # sudo less /var/log/containers/stdouts/openstack-cinder-volume.log
   [...]
   2021-04-12T12:32:17.607179705+00:00 stderr F ++ cat /run_command
   2021-04-12T12:32:17.609648533+00:00 stderr F + CMD='/usr/bin/cinder-volume --config-file /usr/share/cinder/cinder-dist.conf --config-file /etc/cinder/cinder.conf'
   2021-04-12T12:32:17.609648533+00:00 stderr F + ARGS=
   2021-04-12T12:32:17.609648533+00:00 stderr F + [[ ! -n '' ]]
   2021-04-12T12:32:17.609648533+00:00 stderr F + . kolla_extend_start
   2021-04-12T12:32:17.611214130+00:00 stderr F +++ stat -c %U:%G /var/lib/cinder
   2021-04-12T12:32:17.616637578+00:00 stderr F ++ [[ cinder:kolla != \c\i\n\d\e\r\:\k\o\l\l\a ]]
   2021-04-12T12:32:17.616722778+00:00 stderr F + echo 'Running command: '\''/usr/bin/cinder-volume --config-file /usr/share/cinder/cinder-dist.conf --config-file /etc/cinder/cinder.conf'\'''
   2021-04-12T12:32:17.616751172+00:00 stdout F Running command: '/usr/bin/cinder-volume --config-file /usr/share/cinder/cinder-dist.conf --config-file /etc/cinder/cinder.conf'
   2021-04-12T12:32:17.616775368+00:00 stderr F + exec /usr/bin/cinder-volume --config-file /usr/share/cinder/cinder-dist.conf --config-file /etc/cinder/cinder.conf

4. 出力およびログからの情報に基づいて、異常が発生したリソースを修正します。

5. pcs resource cleanup コマンドを実行し、リソースのステータスおよび異常回数をリセットします。

   $ sudo pcs resource cleanup openstack-cinder-volume
     Resource: openstack-cinder-volume successfully cleaned up

手順

1. systemctl status コマンドを実行し、リソースのステータスおよび最近のログイベントを表示します。

   [heat-admin@controller-0 ~]$ sudo systemctl status tripleo_nova_conductor
   ● tripleo_nova_conductor.service - nova_conductor container
      Loaded: loaded (/etc/systemd/system/tripleo_nova_conductor.service; enabled; vendor preset: disabled)
      Active: active (running) since Mon 2021-04-12 10:54:46 UTC; 1h 38min ago
    Main PID: 5125 (conmon)
       Tasks: 2 (limit: 126564)
      Memory: 1.2M
      CGroup: /system.slice/tripleo_nova_conductor.service
              └─5125 /usr/bin/conmon --api-version 1 -c cc3c63b54e0864c94ac54a5789be96aea1dd60b2f3216b37c3e020c76e7887d4 -u cc3c63b54e0864c94ac54a5789be96aea1dd60b2f3216b37c3e020c76e7887d4 -r /usr/bin/runc -b /var/lib/containers/storage/overlay-containers/cc3c63b54e0864c94ac54a5789be96aea1dd60b2f3216b37c3e02>
   
   Apr 12 10:54:42 controller-0.redhat.local systemd[1]: Starting nova_conductor container...
   Apr 12 10:54:46 controller-0.redhat.local podman[2855]: nova_conductor
   Apr 12 10:54:46 controller-0.redhat.local systemd[1]: Started nova_conductor container.

2. リソースのログイベントを表示します。

   # sudo less /var/log/containers/tripleo_nova_conductor.log

3. 出力およびログからの情報に基づいて、異常が発生したリソースを修正します。

4. リソースを再起動して、サービスのステータスを確認します。

   # systemctl restart tripleo_nova_conductor
   # systemctl status tripleo_nova_conductor
   ● tripleo_nova_conductor.service - nova_conductor container
      Loaded: loaded (/etc/systemd/system/tripleo_nova_conductor.service; enabled; vendor preset: disabled)
      Active: active (running) since Thu 2021-04-22 14:28:35 UTC; 7s ago
     Process: 518937 ExecStopPost=/usr/bin/podman stop -t 10 nova_conductor (code=exited, status=0/SUCCESS)
     Process: 518653 ExecStop=/usr/bin/podman stop -t 10 nova_conductor (code=exited, status=0/SUCCESS)
     Process: 519063 ExecStart=/usr/bin/podman start nova_conductor (code=exited, status=0/SUCCESS)
    Main PID: 519198 (conmon)
       Tasks: 2 (limit: 126564)
      Memory: 1.1M
      CGroup: /system.slice/tripleo_nova_conductor.service
              └─519198 /usr/bin/conmon --api-version 1 -c 0d6583beb20508e6bacccd5fea169a2fe949471207cb7d4650fec5f3638c2ce6 -u 0d6583beb20508e6bacccd5fea169a2fe949471207cb7d4650fec5f3638c2ce6 -r /usr/bin/runc -b /var/lib/containe>
   
   Apr 22 14:28:34 controller-0.redhat.local systemd[1]: Starting nova_conductor container...
   Apr 22 14:28:35 controller-0.redhat.local podman[519063]: nova_conductor
   Apr 22 14:28:35 controller-0.redhat.local systemd[1]: Started nova_conductor container.