고가용성 배포 및 사용

절차

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 tripleo-admin@<node_IP>

   <node_ip> 를 로그인할 노드의 IP 주소로 바꿉니다.

절차

1. 모든 컨트롤러 노드에 tripleo-admin 사용자로 로그인합니다.

   $ ssh tripleo-admin@overcloud-controller-0

2. pcs status 명령을 실행합니다.

   [tripleo-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:
   [...]

   출력의 주요 섹션에는 클러스터에 대한 다음 정보가 표시됩니다.

   • 클러스터 이름: 클러스터의 이름입니다.
   • [NUM] 노드가 구성되어 있습니다. 클러스터에 구성된 노드 수입니다.
   • [NUM] 리소스가 구성됩니다. 클러스터에 구성된 리소스 수입니다.
   • 온라인: 현재 온라인 상태인 컨트롤러 노드의 이름입니다.
   • GuestOnline: 현재 온라인 상태인 게스트 노드의 이름입니다. 각 게스트 노드는 복잡한 Bundle Set 리소스로 구성됩니다. 번들 세트에 대한 자세한 내용은 3.1절. “Pacemaker 리소스 번들 및 컨테이너” 을 참조하십시오.

절차

1. 모든 컨트롤러 노드에 tripleo-admin 사용자로 로그인합니다.

   $ ssh tripleo-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 주소가 클러스터의 다른 Controller 노드에 다시 할당됩니다.

     다음 표에서는 예제 출력의 IP 주소를 설명하고 각 IP 주소의 원래 할당을 보여줍니다.

     표 3.1. IP 주소 설명 및 할당 소스

     IP 주소	설명	할당된 from
     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	컨트롤러 노드에서 OpenStack API 서비스에 대한 액세스 제공	network-environment.yaml 파일의 InternalApiAllocationPools
     172.16.0.11	컨트롤러 노드의 Redis 서비스에 대한 액세스 제공	network-environment.yaml 파일의 InternalApiAllocationPools
     172.18.0.10	Glance API 및 Swift Proxy 서비스에 대한 액세스를 제공하는 스토리지 가상 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 주소에 할당된 컨트롤러 노드에 로그인하고 네트워크 인터페이스에서 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 포트 8443: heat_cfn
   • TCP 포트 80: 수평

   • TCP 포트 8776: cinder

     이 예에서 haproxy.cfg 파일에 정의된 대부분의 서비스는 세 개의 컨트롤러 노드 모두에서 192.168.1.150 IP 주소를 수신 대기합니다. 그러나 controller-0 노드만 192.168.1.150 IP 주소로 외부적으로 수신 대기 중입니다.

     따라서 controller-0 노드가 실패하면 HAProxy는 다른 컨트롤러 노드에 192.168.1.150 을 다시 할당하고 다른 모든 서비스는 대체 컨트롤러 노드에서 이미 실행 중입니다.

절차

1. 모든 컨트롤러 노드에 tripleo-admin 사용자로 로그인합니다.

   $ ssh tripleo-admin@overcloud-controller-0

2. pcs status 명령을 실행합니다.

   [tripleo-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 상태: 현재 세 개의 컨트롤러 노드가 모두 온라인 상태임을 보여줍니다.
   • 데몬 상태: 세 개의 Pacemaker 데몬의 상태( corosync,pacemaker, pcsd )를 표시합니다. 이 예제에서는 세 개의 서비스가 모두 활성화되어 활성화되어 있습니다.

절차

1. 각 컨트롤러 노드에 tripleo-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 환경 파일을 생성합니다.

     $ openstack overcloud generate fencing --output fencing.yaml nodes.json

     참고

     이 명령은 ilo 및 drac 전원 관리 세부 정보를 IPMI 동등한 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 및 8에서 스브드 펜싱 활성화를 참조하십시오.

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. 오버클라우드 배포 명령을 실행하고 펜싱.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 펜싱만 해당됩니다. 워치독 타이머 장치 간격을 설정하고 간격이 올바르게 설정되어 있는지 확인합니다.

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

검증

1. stack 사용자로 오버클라우드에 로그인하고 Pacemaker가 리소스 관리자로 구성되었는지 확인합니다.

   $ source stackrc
   $ openstack server list | grep controller
   $ ssh tripleo-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 stackrc
   $ openstack server list | grep controller
   $ ssh tripleo-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 tripleo-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. 웹 브라우저에서 10.200.0.6:1993 으로 이동하여 stats auth 행에서 자격 증명을 입력하여 HAProxy EgressIPs 페이지를 확인합니다.

절차

1. 컨트롤러 노드에서 hiera 명령을 실행하여 MariaDB 데이터베이스 루트 암호를 가져옵니다.

   $ 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 데이터베이스에서 쓰기 세트 복제 정보를 가져옵니다.

   $ 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. 리소스가 실패한 컨트롤러 노드에 로그인합니다.

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 명령을 실행하여 리소스 상태 및 최근 로그 이벤트를 표시합니다.

   [tripleo-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.