고가용성 서비스 관리

절차

1. 실행 중인 HA 환경에서 stack 사용자로 언더클라우드에 로그인합니다.

2. 오버클라우드 노드의 IP 주소를 확인합니다.

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

   Copy to Clipboard Toggle word wrap

3. 오버클라우드 노드 중 하나에 로그인합니다.

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

   Copy to Clipboard Toggle word wrap

   & lt;node_ip >를 로그인하려는 노드의 IP 주소로 바꿉니다.

프로세스

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

   $ ssh tripleo-admin@overcloud-controller-0

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

   출력 예:

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

   Copy to Clipboard Toggle word wrap

   출력의 주요 섹션에서는 클러스터에 대한 다음 정보를 보여줍니다.

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

프로세스

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

   $ ssh tripleo-admin@overcloud-controller-0

   Copy to Clipboard Toggle word wrap

2. 다음 옵션 중 하나를 사용합니다.

   • pcs resource show 명령을 --full 옵션으로 실행하여 가상 IP를 사용하는 모든 리소스를 표시합니다.

     $ sudo pcs resource show --full

     Copy to Clipboard Toggle word wrap

     출력 예:

      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

     Copy to Clipboard Toggle word wrap

     각 IP 주소는 처음에 특정 컨트롤러 노드에 연결됩니다. 예를 들어 192.168.1.150 은 overcloud-controller-0 에서 시작됩니다. 그러나 해당 컨트롤러 노드가 실패하면 클러스터의 다른 컨트롤러 노드에 IP 주소가 다시 할당됩니다.

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

     Expand

     표 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	컨트롤러 노드의 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

     Show more

   • VIP를 사용하는 리소스의 이름과 함께 pcs resource show 명령을 실행하여 특정 VIP 주소를 확인합니다. 이 예제에서는 ip-192.168.1.150:

     $ sudo pcs resource show ip-192.168.1.150

     Copy to Clipboard Toggle word wrap

     출력 예:

      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)

     Copy to Clipboard Toggle word wrap

절차

1. 보려는 IP 주소에 할당된 컨트롤러 노드에 로그인하고 네트워크 인터페이스에서 ip addr show 명령을 실행합니다. 이 예제에서는 vlan100 입니다.

   $ ip addr show vlan100

   Copy to Clipboard Toggle word wrap

   출력 예:

     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

   Copy to Clipboard Toggle word wrap

2. netstat 명령을 실행하여 IP 주소를 청취하는 모든 프로세스를 표시합니다. 이 예 192.168.1.150.haproxy:

   $ sudo netstat -tupln | grep "192.168.1.150.haproxy"

   Copy to Clipboard Toggle word wrap

   출력 예:

   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

   Copy to Clipboard Toggle word wrap
   참고

   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 port 8000: heat_cfn
   • TCP 포트 80: Horizon

   • 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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

   출력 예:

    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

   Copy to Clipboard Toggle word wrap

   출력에는 pcs status 명령 출력의 다음 섹션이 표시되어 있습니다.

   • my-ipmilan-for-controller: 각 컨트롤러 노드의 펜싱 유형(stonith:fence_ipmilan)과 IPMI 서비스가 중지되었는지 또는 실행 중인지를 표시합니다.
   • PCSD 상태: 세 개의 컨트롤러 노드가 모두 현재 온라인 상태임을 표시합니다.
   • 데몬 상태: corosync,pacemaker, pcsd 세 개의 Pacemaker 데몬의 상태를 표시합니다. 이 예제에서는 세 가지 서비스가 모두 활성 상태이며 활성화됩니다.

프로세스

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

2. 클러스터가 실행 중인지 확인합니다.

   $ sudo pcs status

   Copy to Clipboard Toggle word wrap

   출력 예:

   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

   Copy to Clipboard Toggle word wrap

3. STONITH가 비활성화되었는지 확인합니다.

   $ sudo pcs property show

   Copy to Clipboard Toggle word wrap

   출력 예:

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

   Copy to Clipboard Toggle word wrap

4. 사용하려는 펜싱 에이전트에 따라 다음 옵션 중 하나를 선택합니다.

   • IPMI 또는 RHV 펜싱 에이전트를 사용하는 경우 fencing.yaml 환경 파일을 생성합니다.

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

     Copy to Clipboard Toggle word wrap
     참고

     이 명령은 ilo 및 drac 전원 관리 세부 정보를 동일한 IPMI로 변환합니다.

   • STONITH Block Device (SBD), fence_kdump 또는 Redfish와 같은 다른 펜싱 에이전트를 사용하거나 사전 프로비저닝된 노드를 사용하는 경우 수동으로 fencing.yaml 파일을 생성합니다.

5. SBD 펜싱만 해당: fencing.yaml 파일에 다음 매개변수를 추가합니다.

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

   Copy to Clipboard Toggle word wrap
   참고

   이 단계는 초기 오버클라우드 배포에만 적용됩니다. 기존 오버클라우드에서 SBD 펜싱을 활성화하는 방법에 대한 자세한 내용은 RHEL 7 및 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>

   Copy to Clipboard Toggle word wrap

   & lt;parameter& gt; 및 < value >를 펜싱 에이전트에 필요한 실제 매개변수 및 값으로 바꿉니다.

7. overcloud deploy 명령을 실행하고 배포와 관련된 fencing.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

   Copy to Clipboard Toggle word wrap

8. SBD 펜싱만 해당: 워치독 타이머 장치 간격을 설정하고 간격이 올바르게 설정되었는지 확인합니다.

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

   Copy to Clipboard Toggle word wrap

검증

1. 오버클라우드에 heat-admin 사용자로 로그인하고 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

   Copy to Clipboard Toggle word wrap

   이 예에서 Pacemaker는 fencing.yaml 파일에 지정된 각 컨트롤러 노드에 STONITH 리소스를 사용하도록 구성되어 있습니다.

   참고

   제어하는 동일한 노드에서 fence-resource 프로세스를 구성해서는 안 됩니다.

2. 펜싱 리소스 속성을 확인합니다. STONITH 속성 값은 fencing.yaml 파일의 값과 일치해야 합니다.

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

   Copy to Clipboard Toggle word wrap

절차

1. stack 사용자로 컨트롤러 노드에 로그인하고 인증 정보 파일을 가져옵니다.

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

3. 다른 컨트롤러 노드에서 Pacemaker 로그 파일에서 펜싱 이벤트를 찾습니다.

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

   Copy to Clipboard Toggle word wrap

   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>

   Copy to Clipboard Toggle word wrap
3. 웹 브라우저에서 10.200.0.6:1993 으로 이동하여 stats auth 행의 인증 정보를 입력하여 HAProxy 통계 페이지를 확인합니다.

절차

1. director 호스트에 stack 사용자로 로그인하고 director 인증 정보를 가져옵니다.

   $ source ~/stackrc

   Copy to Clipboard Toggle word wrap

2. 노드 정의 템플릿 instackenv.json 을 생성하고 환경에 따라 다음 예제를 복사하여 편집합니다.

   {
       "nodes":[
           {
               "mac":[
                   "bb:bb:bb:bb:bb:bb"
               ],
               "cpu":"4",
               "memory":"6144",
               "disk":"40",
               "arch":"x86_64",
               "pm_type":"ipmi",
               "pm_user":"admin",
               "pm_password":"p@55w0rd!",
               "pm_addr":"192.0.2.205"
           },
           {
               "mac":[
                   "cc:cc:cc:cc:cc:cc"
               ],
               "cpu":"4",
               "memory":"6144",
               "disk":"40",
               "arch":"x86_64",
               "pm_type":"ipmi",
               "pm_user":"admin",
               "pm_password":"p@55w0rd!",
               "pm_addr":"192.0.2.206"
           },
           {
               "mac":[
                   "dd:dd:dd:dd:dd:dd"
               ],
               "cpu":"4",
               "memory":"6144",
               "disk":"40",
               "arch":"x86_64",
               "pm_type":"ipmi",
               "pm_user":"admin",
               "pm_password":"p@55w0rd!",
               "pm_addr":"192.0.2.207"
           },
           {
               "mac":[
                   "ee:ee:ee:ee:ee:ee"
               ],
               "cpu":"4",
               "memory":"6144",
               "disk":"40",
               "arch":"x86_64",
               "pm_type":"ipmi",
               "pm_user":"admin",
               "pm_password":"p@55w0rd!",
               "pm_addr":"192.0.2.208"
           }
       ]
   }

   Copy to Clipboard Toggle word wrap

3. stack 사용자의 홈 디렉터리인 /home/stack/instackenv.json 에 파일을 저장한 다음 노드를 director에 등록하고 노드를 director에 등록합니다.

   $ openstack overcloud node import ~/instackenv.json

   Copy to Clipboard Toggle word wrap

4. 커널 및 램디스크 이미지를 모든 노드에 할당합니다.

   $ openstack overcloud node configure

   Copy to Clipboard Toggle word wrap

5. 각 노드의 하드웨어 속성을 검사합니다.

   $ openstack overcloud node introspect --all-manageable

   Copy to Clipboard Toggle word wrap
   중요

   노드는 manageable 상태에 있어야 합니다. 이 프로세스가 완료되었는지 확인합니다. 베어 메탈 노드의 경우 이 프로세스는 일반적으로 15분 정도 걸립니다.

6. 노드 목록을 가져와서 UUID를 확인합니다.

   $ openstack baremetal node list

   Copy to Clipboard Toggle word wrap

7. 각 노드의 properties/capabilities 매개변수에 profile 옵션을 추가하여 각 노드를 특정 프로필에 수동으로 태그합니다. 예를 들어 컨트롤러 프로필과 하나의 노드를 사용하도록 3개의 노드를 태그하여 컴퓨팅 프로필을 사용하려면 다음 명령을 사용합니다.

   $ openstack baremetal node set 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 --property capabilities='profile:control,boot_option:local'
   $ openstack baremetal node set 6faba1a9-e2d8-4b7c-95a2-c7fbdc12129a --property capabilities='profile:control,boot_option:local'
   $ openstack baremetal node set 5e3b2f50-fcd9-4404-b0a2-59d79924b38e --property capabilities='profile:control,boot_option:local'
   $ openstack baremetal node set 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13 --property capabilities='profile:compute,boot_option:local'

   Copy to Clipboard Toggle word wrap

   profile:compute 및 profile:control 옵션은 노드를 각 프로필에 태그합니다.

절차

1. 각 역할에 대한 노드 인터페이스를 구성하려면 다음 네트워크 인터페이스 템플릿을 사용자 정의합니다.

   • 각 역할에 대해 VLAN을 사용하여 단일 NIC를 구성하려면 다음 디렉터리의 예제 템플릿을 사용합니다.

     /usr/share/openstack-tripleo-heat-templates/network/config/single-nic-vlans

     Copy to Clipboard Toggle word wrap

   • 각 역할에 대해 본딩된 NIC를 구성하려면 다음 디렉터리의 예제 템플릿을 사용합니다.

     /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans

     Copy to Clipboard Toggle word wrap
2. /home/stack/network-environment.yaml 에서 파일을 복사하고 환경에 따라 콘텐츠를 편집하여 네트워크 환경 파일을 생성합니다.

절차

1. 자체 서명된 인증서를 사용하거나 인증서 서명자가 오버클라우드 이미지의 기본 신뢰 저장소에 없는 경우 heat 템플릿 컬렉션의 inject-trust-anchor.yaml 환경 파일을 복사하여 오버클라우드 이미지에 인증서를 삽입합니다.

   $ cp -r /usr/share/openstack-tripleo-heat-templates/environments/inject-trust-anchor.yaml ~/templates/

   Copy to Clipboard Toggle word wrap

2. 텍스트 편집기에서 파일을 열고 루트 인증 기관 파일의 내용을 SSLRootCertificate 매개변수에 복사합니다.

   parameter_defaults:
     SSLRootCertificate: |
     -----BEGIN CERTIFICATE-----
     MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGSIb3DQEBCwUAMFgxCzAJBgNV
     ...
     sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQbIxEpIzrgvp
     -----END CERTIFICATE-----

   Copy to Clipboard Toggle word wrap
   중요

   인증 기관 콘텐츠에는 모든 새 행에 대해 동일한 들여쓰기 수준이 필요합니다.

3. OS::TripleO::NodeTLSCAData: 매개변수의 리소스 URL을 절대 URL로 변경합니다.

   resource_registry:
     OS::TripleO::NodeTLSCAData: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/tls/ca-inject.yaml

   Copy to Clipboard Toggle word wrap

4. 선택 사항: DNS 호스트 이름을 사용하여 SSL/TLS를 통해 오버클라우드에 액세스하는 경우 새 환경 파일 ~/templates/cloudname.yaml 을 생성하고 오버클라우드 끝점의 호스트 이름을 정의합니다.

   parameter_defaults:
     CloudName: overcloud.example.com

   Copy to Clipboard Toggle word wrap

   overcloud.example.com 을 오버클라우드 엔드포인트의 DNS 호스트 이름으로 교체합니다.

절차

1. 외부 로드 밸런서에 대한 모든 환경 및 구성 파일을 사용하여 오버클라우드를 배포합니다.

   $ openstack overcloud deploy --templates /
     -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml /
     -e ~/network-environment.yaml /
     -e /usr/share/openstack-tripleo-heat-templates/environments/external-loadbalancer-vip.yaml /
     -e ~/external-lb.yaml --control-scale 3 --compute-scale 1 --control-flavor control --compute-flavor compute /
     -e <SSL/TLS endpoint environment file> /
     -e <DNS hostname environment file> /
     -e <root certificate injection environment file> /
     -e <additional_options_if_needed>

   Copy to Clipboard Toggle word wrap

   대괄호 <&gt ; 의 값을 사용자 환경에 정의된 파일 경로로 바꿉니다.

   중요

   이 예제에 나열된 순서대로 네트워크 환경 파일을 명령에 추가해야 합니다.

   이 명령에는 다음 환경 파일이 포함됩니다.

   • network-isolation.yaml: 네트워크 격리 구성 파일
   • network-environment.yaml: 네트워크 구성 파일
   • external-loadbalancer-vip.yaml: 외부 로드 밸런싱 가상 IP 주소 구성 파일.

   • external-lb.yaml: 외부 로드 밸런서 구성 파일 이 파일에 대해 다음 옵션을 설정하고 사용자 환경의 값을 조정할 수도 있습니다.

     • --control-scale 3: 컨트롤러 노드를 3 개로 확장합니다.
     • --compute-scale 3: 컴퓨팅 노드를 3개로 확장합니다.
     • --control-flavor control: 컨트롤러 노드에 특정 플레이버를 사용합니다.
     • --compute-flavor compute: 컴퓨팅 노드에 특정 플레이버를 사용합니다.

   • SSL/TLS 환경 파일:

     • SSL/TLS 끝점 환경 파일: public endpoinst에 연결하는 방법을 정의하는 환경 파일입니다. tls-endpoints-public-dns.yaml 또는 tls-endpoints-public-ip.yaml 을 사용합니다.
     • (선택 사항) DNS 호스트 이름 환경 파일: DNS 호스트 이름을 설정할 환경 파일입니다.
     • 루트 인증서 삽입 환경 파일: 루트 인증 기관을 삽입하는 환경 파일입니다.

   오버클라우드 배포 프로세스 중에 Red Hat OpenStack Platform director가 노드를 프로비저닝합니다. 이 프로세스를 완료하는 데 시간이 다소 걸립니다.

2. 오버클라우드 배포의 상태를 보려면 다음 명령을 입력합니다.

   $ source ~/stackrc
   $ openstack stack list --nested

   Copy to Clipboard Toggle word wrap

절차

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

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   각 관련 변수는 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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap
4. 출력 및 로그의 정보를 기반으로 실패한 리소스를 수정합니다.

5. pcs resource cleanup 명령을 실행하여 리소스의 상태 및 실패 수를 재설정합니다.

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

   Copy to Clipboard Toggle word wrap

절차

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.

   Copy to Clipboard Toggle word wrap

2. 리소스의 로그 이벤트를 확인합니다.

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

   Copy to Clipboard Toggle word wrap
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.

   Copy to Clipboard Toggle word wrap