高可用性部署和使用量

流程

1. 在正在运行的 HA 环境中，以 stack 用户身份登录 undercloud。

2. 确定 overcloud 节点的 IP 地址：

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

3. 登录到其中一个 overcloud 节点：

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

   将 <node_ip > 替换为您要登录到的节点的 IP 地址。

流程

1. 以 heat-admin 用户身份登录任何 Controller 节点。

   $ 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] 节点配置 ：为集群配置的节点数量。
   • [NUM] 资源配置 : 为集群配置的资源数量。
   • 在线 ：当前在线的 Controller 节点的名称。
   • GuestOnline ：当前在线的客户机节点的名称。每个客户机节点包含一个复杂的 Bundle Set 资源。有关捆绑包集的更多信息，请参阅 第 3.1 节 “Pacemaker 资源捆绑包和容器”。

流程

1. 以 heat-admin 用户身份登录任何 Controller 节点。

   $ 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 地址最初都附加到特定的 Controller 节点。例如，192. 168.150 在 overcloud-controller-0 上启动。但是，如果该 Controller 节点失败，IP 地址会被重新分配给集群中的其他 Controller 节点。

     下表描述了示例输出中的 IP 地址，并显示每个 IP 地址的原始分配。

     表 3.1. IP 地址描述和分配源

     IP 地址	描述	从中分配
     10.200.0.6	控制器虚拟 IP 地址	在 undercloud.conf 文件中，dhcp_start 和 dhcp_end 范围的一部分设置为 10.200.0.5-10.200.0.24
     192.168.1.150	公共 IP 地址	network-environment.yaml 文件中的 ExternalAllocationPools 属性
     172.16.0.10	提供对 Controller 节点上的 OpenStack API 服务的访问	network-environment.yaml 文件中的 InternalApiAllocationPools
     172.16.0.11	提供对 Controller 节点上的 Redis 服务的访问	network-environment.yaml 文件中的 InternalApiAllocationPools
     172.18.0.10	提供对 Glance API 和 Swift 代理服务访问权限的存储虚拟 IP 地址	network-environment.yaml 文件中的 StorageAllocationPools 属性
     172.19.0.10	提供对存储管理的访问	network-environment.yaml 文件中的 StorageMgmtAlloctionPools

   • 使用使用该 VIP 的资源名称运行 pcs resource show 命令来查看特定的 VIP 地址，在本例中为 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 地址的 Controller 节点，并在网络接口上运行 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 文件中定义的大多数服务侦听所有三个 Controller 节点上的 192.168.1.150 IP 地址。但是，只有 controller-0 节点正在从外部侦听 192.168.1.150 IP 地址。

     因此，如果 controller-0 节点失败，HAProxy 只需要将 192.168.1.150 重新分配给另一个 Controller 节点，所有其他服务都将已在回退 Controller 节点上运行。

流程

1. 以 heat-admin 用户身份登录任何 Controller 节点。

   $ 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 ：显示每个 Controller 节点的隔离类型(stonith:fence_ipmilan)，以及 IPMI 服务是否停止或正在运行。
   • PCSD 状态 ：显示所有三个 Controller 节点当前在线。
   • 守护进程状态 ：包含三个 Pacemaker 守护进程的状态： corosync、pacemaker 和 pcsd。在示例中，所有三个服务都处于活动状态并启用。

流程

1. 以 heat-admin 用户身份登录每个 Controller 节点。

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 隔离代理，请生成 fence.yaml 环境文件：

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

     注意

     此命令将 ilo 和 drac 电源管理详情转换为 IPMI 等效。

   • 如果您使用不同的隔离代理，如 STONITH 块设备(SBD)、fence_kdump 或 Redfish，或者使用预置备节点，请手动创建 fence.yaml 文件。

5. 仅限 SBD 隔离 ：在 fence.yaml 文件中添加以下参数：

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

   注意

   此步骤仅适用于初始 overcloud 部署。有关如何在现有 overcloud 上启用 SBD 隔离的更多信息，请参阅 在 RHEL 7 和 8 中启用 sbd 隔离。

6. 仅多层隔离：将特定于 level 的参数添加到生成的 fence.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& gt; 和 <value > 替换为隔离代理所需的实际参数和值。

7. 运行 overcloud deploy 命令，并包含 fence.yaml 文件以及与部署相关的任何其他环境文件：

   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 隔离：设置 watchdog 计时器设备间隔，并检查间隔是否已正确设置。

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

验证

1. 以 heat-admin 用户身份登录 overcloud，并确保 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 配置为对 fence.yaml 文件中指定的每个 Controller 节点使用 STONITH 资源。

   注意

   您不能在它控制的同一节点上配置 fence-resource 进程。

2. 检查隔离资源属性。STONITH 属性值必须与 fence.yaml 文件中的值匹配 ：

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

流程

1. 以 stack 用户身份登录 Controller 节点，并提供凭据文件：

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

2. 进入 root 用户并关闭到 Controller 节点的所有连接：

   $ 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. 在不同的 Controller 节点上，在 Pacemaker 日志文件中找到隔离事件：

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

   如果 STONITH 服务对 Controller 执行隔离操作，则日志文件会显示隔离事件。

4. 等待几分钟，然后通过运行 pcs status 命令验证重启的 Controller 节点是否在集群中再次运行。如果您在输出中看到重启的 Controller 节点，隔离功能可以正常工作。

流程

1. 在安装了 HAProxy 的任何 Controller 节点上打开 /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. 从 Controller 节点，运行 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 集群的健康和完整性。

流程

1. 登录到资源失败的 Controller 节点。

2. 使用 grep 选项运行 pcs status 命令以获取服务的状态：

   # 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.