언더클라우드는 주요 director 노드로 OpenStack 환경(오버클라우드)을 구성하는 OpenStack 노드를 프로비저닝하고 관리하는 구성 요소가 포함된 단일 시스템 OpenStack 설치 노드입니다. 언더클라우드의 구성 요소는 다음과 같은 여러 기능을 제공합니다.

오버클라우드는 언더클라우드를 사용하여 생성된 Red Hat OpenStack Platform 환경으로 OpenStack Platform 환경을 기반으로 다양한 노드 역할이 포함됩니다. 언더클라우드에는 다음과 같은 기본 오버클라우드 노드 역할이 포함됩니다.

Red Hat OpenStack Platform director는 Controller 노드 클러스터를 사용하여 OpenStack Platform 환경에 고가용성 서비스를 제공합니다. director에서는 각 Controller 노드에 중복 구성 요소 세트를 설치하여 하나의 단일 서비스로 관리합니다. 이 유형의 클러스터 구성은 단일 Controller 노드에 작동 오류가 발생하는 경우 폴백 기능을 제공하므로 OpenStack 사용자에게 어느 정도의 중단없는 서비스가 제공됩니다.

OpenStack Platform director는 일부 주요 소프트웨어를 사용하여 Controller 노드에서 구성 요소를 관리합니다.

OpenStack을 사용하는 대규모 조직에서는 일반적으로 수많은 클라이언트를 지원합니다. 각 OpenStack 클라이언트에는 블록 스토리지 리소스를 사용할 때 고유한 요구 사항이 있을 수 있습니다. glance(이미지), cinder(볼륨) 및/또는 nova(Compute)를 단일 노드에 배포하면 수많은 클라이언트가 있는 대규모 배포인 경우 관리가 불가능해질 수 있습니다. 이러한 문제는 OpenStack을 외부적으로 확장하여 해결할 수 있습니다.

하지만 실질적으로는 Red Hat OpenStack Platform 스토리지 계층을 수십 테라바이트에서 펩타바이트(또는 엑사바이트) 스토리지로 확장할 수 있도록 Red Hat Ceph Storage와 같은 솔루션을 사용하여 스토리지 계층을 가상화해야 하는 요구 사항도 존재합니다. Red Hat Ceph Storage는 상용 하드웨어에서 실행되는 동안 이 스토리지 가상화 계층에 고가용성 및 고성능 기능을 제공합니다. 가상화에는 성능 저하가 나타나는 것처럼 보일 수 있지만, Ceph 스트라이프는 클러스트에서 오브젝트로서의 장치 이미지를 차단합니다. 이는 큰 Ceph 블록 장치 이미지가 독립 실행형 디스크보다 성능이 뛰어나다는 것을 의미합니다. 또한 Ceph 블록 장치는 성능 향상을 위해 캐싱, copy-on-write 복제 및 copy-on-read 복제를 지원합니다.

Red Hat Ceph Storage에 대한 자세한 내용은 Red Hat Ceph Storage를 참조하십시오.

다음 사항에 유의하십시오.

director를 호스팅하는 언더클라우드 시스템은 오버클라우드에 있는 모든 노드에 대한 프로비저닝 및 관리를 제공합니다.

$ yum install libvirt-client libvirt-daemon qemu-kvm libvirt-daemon-driver-qemu libvirt-daemon-kvm virt-install bridge-utils rsync

$ virt-install --name undercloud --memory=16384 --vcpus=4 --location /var/lib/libvirt/images/rhel-server-7.3-x86_64-dvd.iso --disk size=100 --network bridge=br-ex --network bridge=br-ctlplane --graphics=vnc --hvm --os-variant=rhel7

--initrd-inject=/root/ks.cfg --extra-args "ks=file:/ks.cfg"

$ virsh snapshot-create-as --domain undercloud --disk-only --atomic --quiesce

$ rsync --sparse -avh --progress /var/lib/libvirt/images/undercloud.qcow2 1.qcow2

$ virsh blockcommit undercloud vda --active --verbose --pivot

언더클라우드 호스트에는 최소 두 개의 네트워크가 필요합니다.

이는 필요한 최소 네트워크 수를 나타냅니다. 하지만, director가 다른 Red Hat OpenStack Platform 네트워크 트래픽을 다른 네트워크로 분리할 수 있습니다. Red Hat OpenStack Platform은 네트워크 분리에 실제 인터페이스와 태그된 VLAN을 모두 지원합니다.

다음 사항에 유의하십시오.

다음 섹션에서는 오버클라우드 설치 시 개별 시스템과 노드에 대한 요구 사항을 자세히 설명합니다.

언더클라우드와 오버클라우드 모두 Red Hat Content Delivery Network를 통해 또는 Red Hat Satellite 5 또는 6를 통해 Red Hat 리포지토리에 액세스해야 합니다. Red Hat Satellite 서버를 사용하는 경우 필수 리포지토리를 해당 OpenStack Platform 환경에 동기화합니다. 다음 CDN 채널 이름 목록을 가이드로 사용하십시오.

director는 오버클라우드 빌드에 대한 여러 기본 노드 유형을 제공합니다. 이러한 노드 유형은 다음과 같습니다.

다음 표에서는 다른 오버클라우드 구성 예와 각 시나리오에 사용되는 노드 유형을 정의합니다.

또한 개별 서비스를 사용자 정의 역할로 분할할 것인지 고려하십시오. 작성 가능한 역할 아키텍처에 대한 자세한 내용은 오버클라우드 고급 사용자 정의 가이드에서 8장. 작성 가능한 역할 및 서비스를 참조하십시오.

역할 및 서비스를 적절하게 매핑하여 서로 올바르게 통신할 수 있도록 해당 환경의 네트워킹 토폴로지와 서브넷을 계획하는 것이 중요합니다. Red Hat OpenStack Platform은 자율적으로 작동하고 소프트웨어 기반 네트워크, 정적 및 유동 IP 주소, DHCP를 관리하는 neutron 네트워킹 서비스를 사용합니다. director는 오버클라우드 환경의 각 Controller 노드에 이 서비스를 배포합니다.

Red Hat OpenStack Platform은 환경의 여러 서브넷에 할당된 별도의 네트워크 트래픽 유형에 다양한 서비스를 매핑합니다. 이러한 네트워크 트래픽 유형은 다음과 같습니다.

일반적인 Red Hat OpenStack Platform 설치에서는 종종 네트워크 유형의 수가 물리적 네트워크 연결 수를 초과합니다. 모든 네트워크를 적절한 호스트에 연결하기 위해 오버클라우드에서는 VLAN 태그를 사용하여 인터페이스마다 두 개 이상의 네트워크를 제공합니다. 대부분의 네트워크는 서브넷이 분리되어 있지만, 일부는 인터넷 액세스 또는 인프라 네트워크 연결에 라우팅을 제공할 레이어 3 게이트웨이가 필요합니다.

director는 이러한 트래픽 유형 중 6개의 유형을 특정 서브넷이나 VLAN에 매핑하는 방법을 제공합니다. 이러한 트래픽 유형은 다음과 같습니다.

할당되지 않은 네트워크는 모두 프로비저닝 네트워크와 동일한 서브넷에 자동으로 할당됩니다.

아래 다이어그램은 네트워크가 별도 VLAN으로 분리된 네트워크 토폴로지 예를 보여줍니다. 각 오버클라우드 노드는 본딩에 두 가지 인터페이스(nic2 및 nic3)를 사용하여 해당 VLAN을 통해 이러한 네트워크를 제공합니다. 또한 각 오버클라우드 노드는 nic1을 사용하여 기본 VLAN을 통해 프로비저닝 네트워크로 언더클라우드와 통신합니다.

다음 표는 다른 네트워크 레이아웃을 매핑하는 네트워크 트래픽 예를 제공합니다.

director는 오버클라우드 환경에 여러 스토리지 옵션을 제공합니다. 이러한 옵션은 다음과 같습니다.

director 설치 프로세스를 진행하려면 root가 아닌 사용자가 명령을 실행해야 합니다. 다음 명령을 사용하여 stack이라는 사용자를 생성하고 암호를 설정하십시오.

[root@director ~]# useradd stack
[root@director ~]# passwd stack  # specify a password

sudo 사용 시 이 사용자가 암호를 요구하지 않도록 합니다.

[root@director ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
[root@director ~]# chmod 0440 /etc/sudoers.d/stack

새로운 stack 사용자로 전환합니다.

[root@director ~]# su - stack
[stack@director ~]$

director 설치를 stack 사용자로 계속 진행합니다.

director에서 시스템 이미지와 Heat 템플릿을 사용하여 오버클라우드 환경을 생성합니다. 이러한 파일을 구성된 대로 유지하려면 다음과 같이 이미지 및 템플릿에 디렉터리를 생성하는 것이 좋습니다.

$ mkdir ~/images
$ mkdir ~/templates

이 가이드의 다른 섹션에서는 이 두 디렉터리를 사용하여 특정 파일을 저장합니다.

director에는 설치 및 구성 프로세스에 대해 정규화된 도메인 이름이 필요합니다. 따라서, director 호스트의 호스트 이름을 설정해야 하는 경우가 있습니다. 다음 명령으로 호스트의 호스트 이름을 확인하십시오.

$ hostname    # Checks the base hostname
$ hostname -f # Checks the long hostname (FQDN)

필요한 경우 hostnamectl을 사용하여 호스트 이름을 설정합니다.

$ sudo hostnamectl set-hostname manager.example.com
$ sudo hostnamectl set-hostname --transient manager.example.com

director에는 /etc/hosts에 시스템의 호스트 이름 및 기본 이름도 입력해야 합니다. 예를 들어, 시스템 이름이 manager.example.com으로 지정된 경우 /etc/hosts에 다음과 같은 항목이 필요합니다.

127.0.0.1   manager.example.com manager localhost localhost.localdomain localhost4 localhost4.localdomain4

Red Hat OpenStack Platform director를 설치하려면 먼저, Red Hat Subscription Manager를 사용하여 호스트 시스템을 등록하고 필수 채널에 등록합니다.

이러한 리포지토리에는 director 설치에 필요한 패키지가 들어 있습니다.

시스템에서 업데이트를 수행하여 최신 기본 시스템 패키지가 사용되는지 확인합니다.

$ sudo yum update -y
$ sudo reboot

이제 시스템에서 director를 설치할 준비가 되었습니다.

다음 명령을 사용하여 director 설치 및 구성에 필요한 필수 명령줄 툴을 설치합니다.

$ sudo yum install -y python-tripleoclient

이렇게 하면 director 설치에 필요한 모든 패키지가 설치됩니다.

director 설치 프로세스에는 네트워크 구성을 결정하는 특정 설정이 필요합니다. 이 설정은 stack 사용자의 홈 디렉터리에 있는 템플릿에undercloud.conf로 저장되어 있습니다.

Red Hat에서는 설치에 필요한 설정을 결정하는 데 도움이 되는 기본 템플릿을 제공합니다. 이 템플릿을 stack 사용자의 홈 디렉터리에 복사합니다.

$ cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf

undercloud.conf 파일에는 언더클라우드를 구성하는 설정이 들어 있습니다. 매개 변수를 생략하거나 주석 처리하는 경우 언더클라우드 설치에 기본값이 사용됩니다.

템플릿에는 [DEFAULT] 섹션과 [auth] 섹션이 포함되어 있습니다. [DEFAULT] 섹션에는 다음 매개 변수가 들어 있습니다.

[auth] 섹션에는 다음 매개 변수가 들어 있습니다.

네트워크에 따라 이러한 매개 변수에 대한 값을 변경하십시오. 완료되면 파일을 저장하고 다음 명령을 실행하십시오.

$ openstack undercloud install

이 명령은 director의 구성 스크립트를 실행합니다. director가 추가 패키지를 설치하고, undercloud.conf의 설정에 맞게 해당 서비스를 구성합니다. 이 스크립트는 완료하는 데 몇 분이 걸립니다.

구성 스크립트는 완료 시 다음 두 파일을 생성합니다.

이 구성은 모든 OpenStack Platform 서비스를 자동으로 시작합니다. 다음 명령을 사용하여 활성화된 서비스를 확인하십시오.

$ sudo systemctl list-units openstack-*

stack 사용자를 초기화하여 명령줄 툴을 사용하려면 다음 명령을 실행하십시오.

$ source ~/stackrc

이제 director의 명령줄 툴을 사용할 수 있습니다.

director에는 오버클라우드 노드를 프로비저닝할 다음과 같은 여러 디스크 이미지가 필요합니다.

이러한 이미지는 rhosp-director-images 및 rhosp-director-images-ipa 패키지에서 가져옵니다.

$ sudo yum install rhosp-director-images rhosp-director-images-ipa

stack 사용자 홈(/home/stack/images)의 images 디렉터리에 압축된 파일을 풉니다.

$ cd ~/images
$ for i in /usr/share/rhosp-director-images/overcloud-full-latest-11.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-11.0.tar; do tar -xvf $i; done

이러한 이미지를 director로 가져옵니다.

$ openstack overcloud image upload --image-path /home/stack/images/

이렇게 하면 bm-deploy-kernel, bm-deploy-ramdisk, overcloud-full, overcloud-full-initrd, overcloud-full-vmlinuz 이미지가 director에 업로드됩니다. 이러한 이미지는 배포 및 오버클라우드의 이미지입니다. 스크립트는 director의 PXE 서버에 introspection 이미지도 설치합니다.

CLI에서 이미지 목록을 확인합니다.

$ openstack image list
+--------------------------------------+------------------------+
| ID                                   | Name                   |
+--------------------------------------+------------------------+
| 765a46af-4417-4592-91e5-a300ead3faf6 | bm-deploy-ramdisk      |
| 09b40e3d-0382-4925-a356-3a4b4f36b514 | bm-deploy-kernel       |
| ef793cd0-e65c-456a-a675-63cd57610bd5 | overcloud-full         |
| 9a51a6cb-4670-40de-b64b-b70f4dd44152 | overcloud-full-initrd  |
| 4f7e33f4-d617-47c1-b36f-cbe90f132e5d | overcloud-full-vmlinuz |
+--------------------------------------+------------------------+

이 목록에는 introspection PXE 이미지가 표시되지 않습니다. director에서는 이러한 파일을 /httpboot에 복사합니다.

[stack@host1 ~]$ ls -l /httpboot
total 341460
-rwxr-xr-x. 1 root              root                5153184 Mar 31 06:58 agent.kernel
-rw-r--r--. 1 root              root              344491465 Mar 31 06:59 agent.ramdisk
-rw-r--r--. 1 ironic-inspector  ironic-inspector        337 Mar 31 06:23 inspector.ipxe

오버클라우드 노드에는 DNS를 통해 호스트 이름을 확인할 수 있도록 네임 서버가 필요합니다. 네트워크 분리가 없는 표준 오버클라우드의 경우 언더클라우드의 neutron 서브넷을 사용하여 네임 서버가 정의됩니다. 환경의 네임 서버를 정의하려면 다음 명령을 사용하십시오.

$ openstack subnet list
$ openstack subnet set --dns-nameserver [nameserver1-ip] --dns-nameserver [nameserver2-ip] [subnet-uuid]

서브넷을 표시하여 네임 서버를 확인합니다.

$ openstack subnet show [subnet-uuid]
+-------------------+-----------------------------------------------+
| Field             | Value                                         |
+-------------------+-----------------------------------------------+
| ...               |                                               |
| dns_nameservers   | 8.8.8.8                                       |
| ...               |                                               |
+-------------------+-----------------------------------------------+

Red Hat은 언더클라우드 호스트와 Red Hat OpenStack Platform director에서 중요한 데이터를 백업하는 프로세스를 제공합니다. 언더클라우드 백업에 대한 자세한 내용은 "Director 언더클라우드 백업 및 복원" 가이드를 참조하십시오.

이렇게 하면 언더클라우드 설정이 완료됩니다. 다음 장에서는 노드 등록, 검사 및 여러 노드 역할 태그 지정을 비롯하여 오버클라우드의 기본적인 설정에 대해 설명합니다.

director에는 수동으로 만든 노드 정의 템플릿이 필요합니다. 이 파일(instackenv.json)은 JSON 포맷 파일을 사용하며, 노드의 하드웨어 및 전원 관리 정보가 포함되어 있습니다. 예를 들면 노드 두 개를 등록할 템플릿은 다음과 같이 표시될 수 있습니다.

{
    "nodes":[
        {
            "mac":[
                "bb:bb:bb:bb:bb:bb"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.168.24.205"
        },
        {
            "mac":[
                "cc:cc:cc:cc:cc:cc"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.168.24.206"
        }
    ]
}

이 템플릿은 다음 속성을 사용합니다.

템플릿을 생성한 후 파일을 stack 사용자의 홈 디렉터리(/home/stack/instackenv.json)에 저장한 후 다음 명령을 사용하여 director로 가져옵니다.

$ openstack overcloud node import ~/instackenv.json

이렇게 하면 템플릿을 가져와서 템플릿의 각 노드가 director에 등록됩니다.

노드 등록 및 설정이 완료되면 CLI에서 이러한 노드 목록을 확인합니다.

$ openstack baremetal node list

director는 각 노드에서 introspection 프로세스를 실행할 수 있습니다. 이 프로세스를 실행하면 각 노드가 PXE를 통해 introspection 에이전트가 부팅됩니다. 이 에이전트는 노드에서 하드웨어 데이터를 수집하여 director에 다시 보냅니다. 그러면 director에서 이 introspection 데이터를 director에서 실행되는 OpenStack Object Storage(swift) 서비스에 저장합니다. director는 프로필 태그, 벤치마킹 및 root 디스크 수동 할당과 같은 여러 목적에 하드웨어 정보를 사용합니다.

다음 명령을 실행하여 각 노드의 하드웨어 속성을 확인합니다.

$ openstack overcloud node introspect --all-manageable --provide

다른 터미널 창에서 다음 명령을 사용하여 introspection 진행 상황을 모니터링합니다.

$ sudo journalctl -l -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasq -u openstack-ironic-conductor -f

introspection이 완료되면 모든 노드가 active 상태로 변경됩니다.

$ openstack baremetal node manage [NODE UUID]
$ openstack overcloud node introspect [NODE UUID] --provide

introspection이 완료되면 노드가 active 상태로 변경됩니다.

$ for node in $(openstack baremetal node list --fields uuid -f value) ; do openstack baremetal node manage $node ; done
$ openstack overcloud node introspect --all-manageable --provide

introspection이 완료되면 모든 노드가 active 상태로 변경됩니다.

각 노드의 하드웨어 등록 및 검사 후 특정 프로필에 노드를 태그합니다. 이러한 프로파일 태그는 노드가 플레이버에 일치된 다음 해당 플레이버가 배포 역할에 할당됩니다. 다음 예는 Controller 노드에 대한 역할, 플레이버, 프로파일 및 노드 사이의 관계를 보여줍니다.

기본 프로파일 플레이버 compute, control, swift-storage, ceph-storage, block-storage는 언더클라우드 설치 중에 생성되며, 대부분의 환경에서 변경없이 사용할 수 있습니다.

노드를 특정 프로파일에 태그하려면 profile 옵션을 각 노드의 properties/capabilities 매개 변수에 추가합니다. 예를 들어 노드를 Controller 및 Compute 프로파일에 각각 태그하려면 다음 명령을 사용합니다.

$ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13
$ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0

profile:compute 및 profile:control 옵션을 추가하면 두 개의 노드가 각각 해당하는 프로파일에 태그됩니다.

이러한 명령은 또한 각 노드 부팅 방법을 정의하는 boot_option:local 매개 변수를 설정합니다. 하드웨어에 따라 노드가 기본 BIOS 모드 대신 UEFI를 사용하여 부팅되도록 하기 위해 boot_mode 매개 변수를 uefi에 추가해야 할 수도 있습니다. 자세한 내용은 D.2절. “UEFI 부팅 모드”를 참조하십시오.

노드 태그를 완료한 후 할당된 프로파일 또는 가능한 프로파일을 확인합니다.

$ openstack overcloud profiles list

$ openstack flavor create --id auto --ram 4096 --disk 40 --vcpus 1 networker
$ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="networker" networker

이 새 프로파일에 노드를 할당합니다.

$ openstack baremetal node set --property capabilities='profile:networker,boot_option:local' dad05b82-0c74-40bf-9d12-193184bfc72d

일부 노드에서는 여러 디스크를 사용할 수 있습니다. 이러한 경우 director에서 프로비저닝 중에 root 디스크에 사용할 디스크를 식별해야 합니다. director가 root 디스크를 쉽게 식별할 수 있도록 다음과 같은 속성을 사용할 수 있습니다.

이 예에서는 root 장치를 식별하는 디스크의 일련 번호를 사용하여 오버클라우드 이미지를 배포할 드라이브를 지정합니다.

각 노드의 하드웨어 introspection에서 디스크 정보를 확인합니다. 다음 명령은 노드의 디스크 정보를 표시합니다.

$ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"

예를 들면 하나의 노드의 데이터에서 세 개의 디스크가 표시될 수 있습니다.

[
  {
    "size": 299439751168,
    "rotational": true,
    "vendor": "DELL",
    "name": "/dev/sda",
    "wwn_vendor_extension": "0x1ea4dcc412a9632b",
    "wwn_with_extension": "0x61866da04f3807001ea4dcc412a9632b",
    "model": "PERC H330 Mini",
    "wwn": "0x61866da04f380700",
    "serial": "61866da04f3807001ea4dcc412a9632b"
  }
  {
    "size": 299439751168,
    "rotational": true,
    "vendor": "DELL",
    "name": "/dev/sdb",
    "wwn_vendor_extension": "0x1ea4e13c12e36ad6",
    "wwn_with_extension": "0x61866da04f380d001ea4e13c12e36ad6",
    "model": "PERC H330 Mini",
    "wwn": "0x61866da04f380d00",
    "serial": "61866da04f380d001ea4e13c12e36ad6"
  }
  {
    "size": 299439751168,
    "rotational": true,
    "vendor": "DELL",
    "name": "/dev/sdc",
    "wwn_vendor_extension": "0x1ea4e31e121cfb45",
    "wwn_with_extension": "0x61866da04f37fc001ea4e31e121cfb45",
    "model": "PERC H330 Mini",
    "wwn": "0x61866da04f37fc00",
    "serial": "61866da04f37fc001ea4e31e121cfb45"
  }
]

이 예에서는 root 장치를 일련 번호가 61866da04f380d001ea4e13c12e36ad6인 디스크 2로 설정합니다. 이를 위해 노드 정의에 root_device 매개 변수를 변경해야 합니다.

$ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0

이를 통해 director가 root 디스크로 사용할 특정 디스크를 쉽게 식별할 수 있습니다. 오버클라우드 생성을 시작하면 director가 이 노드를 프로비저닝하고 오버클라우드 이미지를 이 디스크에 작성합니다.

언더클라우드에는 오버클라우드 만들기 플랜 기능을 하는 Heat 템플릿 세트가 포함되어 있습니다. 고급 오버클라우드 사용자 정의 가이드를 사용하여 오버클라우드의 고급 기능을 사용자 정의할 수 있습니다.

사용자 정의를 사용하지 않는 경우 기본 오버클라우드를 계속 배포할 수 있습니다. 자세한 내용은 5.6절. “CLI 툴로 오버클라우드 생성”에서 참조하십시오.

OpenStack 환경 생성의 최종 단계는 openstack overcloud deploy 명령을 실행하여 이 환경을 생성하는 것입니다. 이 명령을 실행하기 전에 주요 옵션 및 사용자 정의 환경 파일을 포함하는 방법을 숙지하고 있어야 합니다. 다음 섹션에서는 openstack overcloud deploy 명령 및 이 명령과 관련된 옵션에 대해 설명합니다.

일부 명령줄 매개 변수는 더 이상 사용되지 않으며, 대신 환경 파일의 parameter_defaults 섹션에 포함하는 Heat 템플릿 매개 변수가 사용됩니다. 다음 표에는 더 이상 사용되지 않는 매개 변수와 그에 상응하는 Heat 템플릿 매개 변수가 매핑되어 있습니다.

이러한 매개 변수는 Red Hat OpenStack Platform의 이후 버전에서 삭제될 예정입니다.

$ openstack help overcloud deploy

-e에 오버클라우드를 사용자 정의할 환경 파일이 포함되어 있습니다. 필요에 따라 환경 파일을 추가할 수 있지만, 나중에 실행되는 환경 파일에 정의된 매개 변수와 리소스가 우선 순위를 갖기 때문에 환경 파일의 순서가 중요합니다. 다음 목록을 환경 파일 순서의 예로 사용하십시오.

-e 옵션을 사용하여 오버클라우드에 추가된 환경 파일은 오버클라우드 스택 정의의 일부가 됩니다. 다음 명령은 추가된 사용자 정의 환경 파일을 사용하여 오버클라우드 생성을 시작하는 방법의 예입니다.

$ openstack overcloud deploy --templates \
  -e ~/templates/node-info.yaml\
  -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 \

이 명령에는 다음 추가 옵션이 포함되어 있습니다.

director를 사용하려면 8장. 오버클라우드 생성 후 작업 수행에 재배포 및 배포 후 기능에 대한 이러한 환경 파일이 필요합니다. 이러한 파일이 포함되지 않은 경우 오버클라우드가 손상될 수 있습니다.

오버클라우드 설정을 나중에 수정하려는 경우 다음을 수행해야 합니다.

오버클라우드 설정을 직접 편집하지 마십시오. 오버클라우드 스택을 director로 업데이트할 때 수동 설정을 director의 설정이 덮어쓰기하므로 설정을 직접 편집하지 마십시오.

$ ls -1 ~/templates
00-node-info.yaml
10-network-isolation.yaml
20-network-environment.yaml
30-storage-environment.yaml
40-rhel-registration.yaml

다음 배포 명령을 실행하여 디렉터리를 추가합니다.

$ openstack overcloud deploy --templates --environment-directory ~/templates

예를 들면 응답 파일에 다음이 포함될 수 있습니다.

templates: /usr/share/openstack-tripleo-heat-templates/
environments:
  - ~/templates/00-node-info.yaml
  - ~/templates/10-network-isolation.yaml
  - ~/templates/20-network-environment.yaml
  - ~/templates/30-storage-environment.yaml
  - ~/templates/40-rhel-registration.yaml

다음 배포 명령을 실행하여 응답 파일을 추가합니다.

$ openstack overcloud deploy --answers-file ~/answers.yaml

openstack overcloud deploy 명령을 사용하지 않고, director에서 가져온 플랜을 관리할 수도 있습니다.

새 플랜을 생성하려면 stack 사용자로 다음 명령을 실행합니다.

$ openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates my-overcloud

이 명령을 실행하면 코어 Heat 템플릿 컬렉션의 플랜이 /usr/share/openstack-tripleo-heat-templates에 생성됩니다. director는 입력된 내용을 기반으로 하여 플랜에 이름을 지정합니다. 이 예의 경우 my-overcloud입니다. director는 이 이름을 오브젝트 스토리지 컨테이너, 워크플로우 환경 및 오버클라우드 스택 이름에 대한 레이블로 사용합니다.

다음 명령을 사용하여 환경 파일의 매개 변수를 추가합니다.

$ openstack overcloud parameters set my-overcloud ~/templates/my-environment.yaml

다음 명령을 사용하여 플랜을 배포합니다.

$ openstack overcloud plan deploy my-overcloud

다음 명령을 사용하여 기존 플랜을 삭제합니다.

$ openstack overcloud plan delete my-overcloud

오버클라우드 생성 또는 스택 업데이트를 실행하기 전에 Heat 템플릿 및 환경 파일에서 오류를 확인합니다.

$ openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates overcloud-validation
$ mkdir ~/overcloud-validation
$ cd ~/overcloud-validation
$ swift download overcloud-validation

다음에 나오는 검증 테스트에 ~/overcloud-validation에 있는 렌더링된 템플릿을 사용하십시오.

$ openstack orchestration template validate --show-nested --template ~/overcloud-validation/overcloud.yaml -e ~/overcloud-validation/overcloud-resource-registry-puppet.yaml -e [ENVIRONMENT FILE] -e [ENVIRONMENT FILE]

이 명령은 템플릿에서 구문 오류를 식별합니다. 템플릿 구문의 검증이 성공적으로 수행되면 출력에 결과 오버클라우드 템플릿의 미리보기가 표시됩니다.

오버클라우드 생성 절차가 시작되고 director에서 노드를 프로비저닝합니다. 이 프로세스는 완료하는 데 시간이 걸립니다. 오버클라우드 생성 상태를 보려면 별도의 터미널을 stack 사용자로 열고 다음을 실행합니다.

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

openstack stack list --nested 명령을 실행하면 오버클라우드 생성의 현재 단계가 표시됩니다.

director에서는 director 호스트에서 오버클라우드와 상호 작용을 설정하고 인증을 지원하는 스크립트를 생성합니다. director는 overcloudrc 파일을 stack 사용자의 홈 director에 저장합니다. 이 파일을 사용하려면 다음 명령을 실행합니다.

$ source ~/overcloudrc

이 명령을 실행하면 director 호스트의 CLI에서 오버클라우드와 상호 작용하는 데 필요한 환경 변수가 로드됩니다. director 호스트와의 상호 작용으로 돌아가려면 다음 명령을 실행합니다.

$ source ~/stackrc

오버클라우드의 각 노드에는 heat-admin이라고 하는 사용자가 포함되어 있습니다. stack 사용자는 각 노드에 있는 이 사용자에 대해 SSH 액세스 권한을 갖습니다. SSH로 노드에 액세스하려면 원하는 노드의 IP 주소를 확인합니다.

$ nova list

다음으로 heat-admin 사용자와 노드의 IP 주소를 사용하여 노드에 연결합니다.

$ ssh heat-admin@192.168.24.23

이제 명령줄 툴을 사용한 오버클라우드 생성이 완료되었습니다. 생성 이후 기능에 대해서는 8장. 오버클라우드 생성 후 작업 수행을 참조하십시오.

사용자는 SSL을 통해 director의 웹 UI에 액세스합니다. 예를 들어 언더클라우드의 IP 주소가 192.168.24.1이면 UI에 액세스할 주소는 https://192.168.24.1입니다. 웹 UI는 처음에 다음 필드가 포함된 로그인 화면을 표시합니다.

UI에 로그인하면 UI에서 OpenStack Identity Public API에 액세스하고 다른 공용 API 서비스의 엔드포인트를 가져옵니다. 이러한 서비스에는 다음이 포함됩니다.

클라이언트 시스템은 해당 엔드포인트에 액세스해야 하기 때문에 UI는 이러한 공용 API와 직접 상호 작용합니다. director는 SSL/TLS 암호화 경로를 통해 이러한 엔드포인트를 공용 VIP(undercloud.conf 파일의 undercloud_public_host)에 노출합니다. 각 경로는 서비스에 대응합니다. 예를 들면 https://192.168.24.2:443/keystone은 OpenStack Identity 공용 API에 매핑됩니다.

엔드포인트를 변경하거나 엔드포인트 액세스에 다른 IP를 사용하려는 경우 director UI가 /var/www/openstack-tripleo-ui/dist/tripleo_ui_config.js 파일에서 설정을 읽습니다. 이 파일은 다음 매개 변수를 사용합니다.

다음은 192.168.24.2가 언더클라우드의 공용 VIP인 tripleo_ui_config.js 파일의 예입니다.

window.tripleOUiConfig = {
  'keystone': 'https://192.168.24.2:443/keystone/v2.0',
  'heat': 'https://192.168.24.2:443/heat/v1/%(tenant_id)s',
  'ironic': 'https://192.168.24.2:443/ironic',
  'mistral': 'https://192.168.24.2:443/mistral/v2',
  'swift': 'https://192.168.24.2:443/swift/v1/AUTH_%(tenant_id)s',
  'zaqar-websocket': 'wss://192.168.24.2:443/zaqar',
  "zaqar_default_queue": "tripleo"
};

UI는 다음 세 가지 섹션으로 구성되어 있습니다.

director UI에는 오버클라우드 구성 전 플랜이 필요합니다. 이 플랜은 일반적으로 /usr/share/openstack-tripleo-heat-templates의 언더클라우드에 있는 것과 같은 Heat 템플릿 컬렉션입니다. 또한 하드웨어 및 환경 요구 사항에 맞게 플랜을 사용자 정의할 수 있습니다. 오버클라우드 사용자 정의에 대한 자세한 내용은 고급 오버클라우드 사용자 정의 가이드를 참조하십시오.

플랜에는 오버클라우드 설정에 대한 네 가지 주요 단계가 표시됩니다.

언더클라우드 설치 및 설정을 실행하면 플랜이 자동으로 업로드됩니다. 여러 플랜을 웹 UI에 가져올 수도 있습니다. 배포 플랜 화면에서 배포 관리를 클릭하면 현재 플랜 테이블이 표시됩니다.

새로운 플랜 생성을 클릭하면 다음 정보를 묻는 창이 표시됩니다.

director의 Heat 템플릿 컬렉션을 클라이언트 머신에 복사해야 하는 경우 파일을 압축하여 복사합니다.

$ cd /usr/share/openstack-tripleo-heat-templates/
$ tar -cf ~/overcloud.tar *
$ scp ~/overcloud.tar user@10.0.0.55:~/.

director UI에 플랜이 업로드되면 플랜이 Plans 테이블에 표시되어 설정할 수 있습니다. 배포 플랜을 클릭합니다.

오버클라우드 구성의 첫 단계는 노드를 등록하는 것입니다. 다음을 통해 노드 등록 프로세스를 시작합니다.

이렇게 하면 노드 등록 창이 표시됩니다.

director에는 등록할 노드 목록이 필요하며 다음 두 가지 방법 중 하나를 사용하여 제공할 수 있습니다.

수동 등록을 위해 제공해야 하는 세부 사항은 다음과 같습니다.

노드 정보를 입력한 후 창 하단에 있는 노드 등록을 클릭합니다.

director가 노드를 등록합니다. 완료되면 UI를 사용하여 노드에서 introspection을 수행할 수 있습니다.

director UI에서 각 노드의 introspection 프로세스를 실행할 수도 있습니다. 이 프로세스를 실행하면 각 노드가 PXE로 introspection 에이전트를 부팅합니다. 이 에이전트는 노드에서 하드웨어 데이터를 수집하고 director에 다시 보냅니다. 그러면 director가 이 introspection 데이터를 director에서 실행 중인 OpenStack Object Storage(swift) 서비스에 저장합니다. director는 프로필 태그, 벤치마킹, 수동 root 디스크 할당과 같은 다양한 목적으로 하드웨어 정보를 사용합니다.

introspection 프로세스를 시작하려면 다음 단계를 수행합니다:

introspection 프로세스가 완료되면 프로비저닝 상태가 manageable로 설정된 노드를 모두 선택한 다음 노드 제공 버튼을 클릭합니다. 프로비저닝 상태가available로 변경될 때까지 기다립니다.

이제 노드를 프로비저닝할 준비가 되었습니다.

배포 플랜 화면에서는 업로드된 플랜을 사용자 정의할 수 있습니다. 2 배포 설정 지정에서 설정 편집 링크를 클릭하여 기본 오버클라우드 설정을 변경합니다.

다음 두 개의 기본 탭이 있는 창이 표시됩니다.

각 노드의 하드웨어 등록 및 검사 후 특정 프로필에 태그합니다. 이러한 프로필은 노드를 특정 유형 및 배포 역할과 일치시킵니다.

노드를 역할에 할당하려면 배포 플랜 화면에서 3 역할 구성 및 노드 할당 섹션으로 스크롤합니다. 선택한 역할에 대해 노드 할당을 클릭합니다. 역할에 할당할 노드를 선택할 수 있는 창이 표시됩니다. 역할 노드를 선택했으면 선택 노드를 할당/할당 해제를 클릭합니다.

이러한 노드가 역할에 할당되면 완료를 클릭하여 배포 플랜 화면으로 돌아갑니다.

오버클라우드에 포함시키려는 각 역할에 대해 이 작업을 완료합니다.

각 노드 역할은 역할별 매개 변수를 구성하는 방법을 제공합니다. 배포 플랜 화면에서 3 역할 구성 및 노드 할당 역할로 스크롤합니다. 역할 이름 옆에 있는 역할 매개 변수 편집 아이콘(연필 아이콘)을 클릭합니다.

다음 두 가지 기본 탭이 표시된 창이 나타납니다.

오버클라우드 플랜이 구성되면 오버클라우드 배포를 시작할 수 있습니다. 이를 위해서는 4 배포 섹션으로 스크롤하여 검증 및 배포를 클릭합니다.

언더클라우드에 대한 모든 검증을 실행하지 않았거나 통과하지 않은 경우 경고 메시지가 표시됩니다. 배포를 실행하기 전에 언더클라우드 호스트가 요구 사항을 충족하는지 확인하십시오.

배포할 준비가 되었으면 배포를 클릭합니다.

UI에서는 오버클라우드의 생성 진행률을 정기적으로 모니터링하고 현재 진행률을 나타내는 진행률 표시줄을 표시합니다. 자세한 정보 보기 링크는 오버클라우드의 현재 OpenStack Orchestration 스택 로그를 표시합니다.

오버클라우드 배포가 완료될 때까지 기다립니다.

오버클라우드 생성 프로세스가 완료되면 4 배포 섹션에 현재 오버클라우드 상태 및 다음 세부 사항이 표시됩니다.

이 정보를 사용하여 오버클라우드에 액세스합니다.

이렇게 하면 director의 UI를 통한 오버클라우드 생성이 완료됩니다. 생성 후 기능에 대한 자세한 내용은 8장. 오버클라우드 생성 후 작업 수행을 참조하십시오.

이 프로세스의 후반 단계에서 director는 오버클라우드 노드에 stack 사용자로 SSH 액세스가 가능해야 합니다.

각 노드는 Red Hat 서브스크립션에 액세스할 수 있어야 합니다. 다음 절차는 각 노드를 Red Hat Content Delivery Network에 등록하는 방법을 보여줍니다. 각 노드에서 다음 단계를 수행하십시오.

이제 노드에서 오버클라우드를 사용할 준비가 되었습니다.

사전 프로비저닝된 각 노드는 OpenStack Orchestration(heat) 에이전트를 사용하여 director와 통신합니다. 각 노드의 에이전트는 director를 폴링하여 각 노드에 맞게 조정된 메타데이터를 가져옵니다. 이 메타데이터를 사용하여 에이전트가 각 노드를 구성할 수 있습니다.

각 노드에 오케스트레이션 초기 에이전트 패키지를 설치합니다.

[root@controller ~]# sudo yum -y install python-heat-agent*

director가 SSL/TLS를 사용하는 경우 사전 프로비저닝된 노드에 director의 SSL/TLS 인증서에 서명하는 데 사용된 인증 기관 파일이 필요합니다. 해당 인증 기관을 사용하는 경우 각 오버클라우드 노드에서 다음을 수행합니다.

이렇게 하면 오버클라우드 노드에서 SSL/TLS를 통해 director의 공용 API에 액세스할 수 있습니다.

사전 프로비저닝된 오버클라우드 노드는 표준 HTTP 요청을 사용하여 director에서 메타데이터를 가져옵니다. 따라서 모든 오버클라우드 노드는 다음 중 하나에 액세스하려면 L3 권한이 필요합니다.

director는 컨트롤 플레인 네트워크를 사용하여 표준 오버클라우드를 관리하고 구성합니다. 노드가 사전 프로비저닝된 오버클라우드의 경우 director가 사전 프로비저닝된 노드와 통신할 수 있도록 네트워크 구성을 일부 수정해야 할 수 있습니다.

표준 오버클라우드 생성 중에 director는 OpenStack Networking(neutron) 포트를 생성하여 프로비저닝/컨트롤 플레인 네트워크의 오버클라우드 노드에 IP 주소를 자동으로 할당합니다. 하지만 이로 인해 director에서 다른 IP 주소를 각 노드에 대해 수동으로 구성된 주소에 할당할 수 있습니다. 이 경우 예측 가능한 IP 주소 할당 방법을 사용하여 director에서 컨트롤 플레인에 사전 프로비저닝된 IP 할당을 사용하도록 강제 적용합니다.

예측 가능한 IP 주소 할당 방법의 예는 다음 IP가 할당된 환경 파일을 사용합니다 (ctlplane-assignments.yaml).

resource_registry:
  OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml

parameter_defaults:
  DeployedServerPortMap:
    controller-ctlplane:
      fixed_ips:
        - ip_address: 192.168.24.2
      subnets:
        - cidr: 24
    compute-ctlplane:
      fixed_ips:
        - ip_address: 192.168.24.3
      subnets:
        - cidr: 24

이 예에서 OS::TripleO::DeployedServer::ControlPlanePort 리소스는 매개변수 집합을 director에 전달하고, 사전 프로비저닝된 노드의 IP 할당을 정의합니다. DeployedServerPortMap 매개 변수는 각 오버클라우드 노드에 해당하는 IP 주소와 서브넷 CIDR을 정의합니다. 매핑은 다음을 정의합니다.

이 장의 후반 단계에서는 결과 환경 파일(ctlplane-assignments.yaml)을 openstack overcloud deploy 명령의 일부로 사용합니다.

기본적으로 director는 프로비저닝 네트워크를 오버클라우드 컨트롤 플레인으로 사용합니다. 하지만 이 네트워크가 분리되어 라우팅이 불가능한 경우 구성 중에 노드에서 director의 내부 API와 통신할 수 없습니다. 이 경우 노드에 대해 별도의 네트워크를 정의하고, 공용 API로 director와 통신하도록 구성해야 할 수 있습니다.

이 시나리오에는 다음과 같은 여러 요구 사항이 있습니다.

이 섹션의 예에서는 기본 시나리오와 다른 IP 주소 할당을 사용합니다.

다음 섹션에서는 오버클라우드 노드에 별도의 네트워크가 필요한 경우 추가 설정 방법에 대해 설명합니다.

undercloud.conf의 hieradata_override를 사용하면 언더클라우드 구성에 대한 추가 Puppet hieradata를 지정할 수 있습니다. OpenStack Orchestration과 관련된 hieradata를 수정하려면 다음 단계를 수행하십시오.

이렇게 하면 오케스트레이션 메타데이터 서버가 director의 공용 API에서 URL을 사용하도록 전환됩니다.

resource_registry:
  OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
  OS::TripleO::Network::Ports::ControlPlaneVipPort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
  OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml 1

parameter_defaults:
  NeutronPublicInterface: eth1
  EC2MetadataIp: 192.168.100.1 2
  ControlPlaneDefaultRoute: 192.168.100.1
  DeployedServerPortMap:
    control_virtual_ip:
      fixed_ips:
        - ip_address: 192.168.100.1
      subnets:
        - cidr: 24
    controller0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.100.2
      subnets:
        - cidr: 24
    compute0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.100.3
      subnets:
        - cidr: 24

오버클라우드 배포에는 5.6절. “CLI 툴로 오버클라우드 생성”의 표준 CLI 메서드를 사용합니다. 사전 프로비저닝된 노드의 경우 배포 명령에 핵심 Heat 템플릿 컬렉션의 일부 추가 옵션 및 환경 파일이 필요합니다.

다음은 사전 프로비저닝된 아키텍처에 고유한 환경 파일을 사용한 오버클라우드 배포 명령 예입니다.

[stack@director ~]$ source ~/stackrc
[stack@director ~]$ openstack overcloud deploy \
  [other arguments] \
  --disable-validations \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-bootstrap-environment-rhel.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-pacemaker-environment.yaml \
  -r /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-server-roles-data.yaml

이 명령은 오버클라우드 구성을 시작합니다. 하지만 오버클라우드 노드 리소스가 CREATE_IN_PROGRESS 단계에 들어가면 배포 스택이 일시 중지됩니다.

2017-01-14 13:25:13Z [overcloud.Compute.0.Compute]: CREATE_IN_PROGRESS  state changed
2017-01-14 13:25:14Z [overcloud.Controller.0.Controller]: CREATE_IN_PROGRESS  state changed

이러한 일시 중지는 director가 오버클라우드 노드에서 오케스트레이션 에이전트가 메타데이터 서버를 폴링할 때까지 기다리기 때문에 발생합니다. 다음 섹션에는 메타데이터 서버 폴링을 시작할 노드를 구성하는 방법이 나와 있습니다.

이제 배포가 진행 중이지만, CREATE_IN_PROGRESS 단계에서 일시 중지됩니다. 다음 단계는 director에서 메타데이터 서버를 폴링하도록 오버클라우드 노드에서 오케스트레이션 에이전트를 구성하는 것입니다. 다음 두 가지 방법으로 이 작업을 수행할 수 있습니다.

[stack@director ~]$ source ~/stackrc

또한 스크립트에 노드 역할과 해당 IP 주소를 정의할 몇 가지 추가 환경 변수가 필요합니다. 이러한 환경 변수는 다음과 같습니다.

다음 명령은 이러한 환경 변수를 설정하는 방법을 보여줍니다.

[stack@director ~]$ export OVERCLOUD_ROLES="ControllerDeployedServer ComputeDeployedServer"
[stack@director ~]$ export ControllerDeployedServer_hosts="192.168.100.2"
[stack@director ~]$ export ComputeDeployedServer_hosts="192.168.100.3"

다음 스크립트를 실행하여 각 오버클라우드 노드에서 오케스트레이션 에이전트를 구성합니다.

[stack@director ~]$ /usr/share/openstack-tripleo-heat-templates/deployed-server/scripts/get-occ-config.sh

스크립트는 다음을 수행합니다.

스크립트가 완료되면 오버클라우드 노드가 director에서 오케스트레이션 서비스 폴링을 시작합니다. 스택 배포가 계속 진행됩니다.

[stack@director ~]$ source ~/stackrc
[stack@director ~]$ for STACK in $(openstack stack resource list -n5 --filter name=deployed-server -c stack_name -f value overcloud) ; do STACKID=$(echo $STACK | cut -d '-' -f2,4 --output-delimiter " ") ; echo "== Metadata URL for $STACKID ==" ; openstack stack resource metadata $STACK deployed-server | jq -r '.["os-collect-config"].request.metadata_url' ; echo ; done

다음은 각 노드에 대한 스택 이름과 메타데이터 URL을 표시한 것입니다.

== Metadata URL for ControllerDeployedServer 0 ==
http://192.168.24.1:8080/v1/AUTH_6fce4e6019264a5b8283e7125f05b764/ov-edServer-ts6lr4tm5p44-deployed-server-td42md2tap4g/43d302fa-d4c2-40df-b3ac-624d6075ef27?temp_url_sig=58313e577a93de8f8d2367f8ce92dd7be7aac3a1&temp_url_expires=2147483586

== Metadata URL for ComputeDeployedServer 0 ==
http://192.168.24.1:8080/v1/AUTH_6fce4e6019264a5b8283e7125f05b764/ov-edServer-wdpk7upmz3eh-deployed-server-ghv7ptfikz2j/0a43e94b-fe02-427b-9bfe-71d2b7bb3126?temp_url_sig=8a50d8ed6502969f0063e79bb32592f4203a136e&temp_url_expires=2147483586

각 오버클라우드 노드에서 다음을 수행합니다.

서비스를 구성하고 다시 시작하면 오케스트레이션 에이전트가 오버클라우드 구성에 대해 director의 오케스트레이션 서비스를 폴링합니다. 배포 스택은 해당 생성을 계속 진행하여 각 노드에 대한 스택이 CREATE_COMPLETE로 변경됩니다.

오버클라우드 구성 프로세스가 시작됩니다. 이 과정은 완료하는 데 시간이 걸립니다. 오버클라우드 생성 상태를 보려면 별도의 터미널을 stack 사용자로 열고 다음을 실행합니다.

$ source ~/stackrc
$ heat stack-list --show-nested

heat stack-list --show-nested 명령은 오버클라우드 생성의 현재 단계를 표시합니다.

director에서는 director 호스트에서 오버클라우드와 상호 작용을 설정하고 인증을 지원하는 스크립트를 생성합니다. director는 overcloudrc 파일을 stack 사용자의 홈 director에 저장합니다. 이 파일을 사용하려면 다음 명령을 실행합니다.

$ source ~/overcloudrc

이렇게 하면 director 노드에서 CLI의 오버클라우드와 상호 작용하는 데 필요한 환경 변수가 로드됩니다. director 노드와의 상호 작용으로 돌아가려면 다음을 실행합니다.

$ source ~/stackrc

사전 프로비저닝된 노드를 확장하는 프로세스는 9장. 오버클라우드 확장의 표준 확장 절차와 비슷합니다. 하지만 사전 프로비저닝된 노드가 OpenStack Bare Metal(ironic) 및 OpenStack Compute(nova)의 표준 등록 및 관리 프로세스를 사용하지 않으므로 사전 프로비저닝된 새 노드를 추가하는 프로세스는 다릅니다.

노드를 확장하는 일반적인 프로세스는 다음과 같습니다.

스택에서 오버클라우드 노드를 제거한 경우 이러한 노드의 전원을 끕니다. 표준 배포의 director에 있는 베어 메탈 서비스에서 이 기능을 제어합니다. 하지만 프로비저닝된 노드를 사용하는 경우 이러한 노드를 수동으로 종료하거나 각 물리적 시스템에 대해 전원 관리 컨트롤을 사용해야 합니다. 스택에서 노드를 제거한 후 노드의 전원을 끄지 않으면 작동 상태로 남아 있어 오버클라우드 환경의 일부로 재연결할 수 있습니다.

제거된 노드의 전원을 끈 후 기본 운영 체제 구성으로 다시 프로비저닝하면 이후에 오버클라우드에 연결되지 않을 수 있습니다.

사전 프로비저닝된 노드를 사용하는 전체 오버클라우드를 제거하면 표준 오버클라우드와 같은 절차를 사용합니다. 자세한 내용은 8.11절. “오버클라우드 제거”를 참조하십시오.

오버클라우드 제거 후 모든 노드의 전원을 끄고 기본 운영 체제 구성으로 다시 프로비저닝합니다.

이렇게 하면 사전 프로비저닝된 노드를 사용한 오버클라우드 생성이 완료됩니다. 생성 이후 기능에 대해서는 8장. 오버클라우드 생성 후 작업 수행을 참조하십시오.

오버클라우드에는 인스턴스에 대한 테넌트 네트워크가 필요합니다. overcloud를 소싱하고 Neutron에 초기 테넌트 네트워크를 생성합니다. 예를 들면 다음과 같습니다.

$ source ~/overcloudrc
$ openstack network create default
$ openstack subnet create default --network default --gateway 172.20.1.1 --subnet-range 172.20.0.0/16

이렇게 하면 default라고 하는 기본 Neutron 네트워크가 생성됩니다. 오버클라우드에서 내부 DHCP 메커니즘을 사용하여 이 네트워크에서 IP 주소를 자동으로 할당합니다.

생성된 네트워크를 확인합니다.

$ openstack network list
+-----------------------+-------------+--------------------------------------+
| id                    | name        | subnets                              |
+-----------------------+-------------+--------------------------------------+
| 95fadaa1-5dda-4777... | default     | 7e060813-35c5-462c-a56a-1c6f8f4f332f |
+-----------------------+-------------+--------------------------------------+

유동 IP 주소를 인스턴스에 할당할 수 있도록 오버클라우드에서 외부 네트워크를 생성해야 합니다.

overcloud에서 소스를 생성하고 Neutron에 외부 네트워크를 만듭니다. 예를 들면 다음과 같습니다.

$ source ~/overcloudrc
$ openstack network create public --external --provider-network-type flat --provider-physical-network datacentre
$ openstack subnet create public --network public --dhcp --allocation-pool start=10.1.1.51,end=10.1.1.250 --gateway 10.1.1.1 --subnet-range 10.1.1.0/24

이 예에서 public이라는 이름으로 네트워크를 생성합니다. 오버클라우드에는 기본 유동 IP 풀에 대해 이러한 특정 이름이 필요합니다. 이는 8.5절. “오버클라우드 검증”의 검증 테스트에서도 중요합니다.

또한 이 명령은 네트워크를 datacentre 물리적 네트워크에 매핑합니다. 기본적으로 datacentre는 br-ex 브리지에 매핑됩니다. 오버클라우드 생성 중에 사용자 정의 neutron 설정을 사용하지 않은 경우 이 옵션을 기본값으로 둡니다.

$ source ~/overcloudrc
$ openstack network create public --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 104
$ openstack subnet create public --network public --dhcp --allocation-pool start=10.1.1.51,end=10.1.1.250 --gateway 10.1.1.1 --subnet-range 10.1.1.0/24

provider:segmentation_id 값은 사용할 VLAN을 정의합니다. 이 경우 104를 사용할 수 있습니다.

생성된 네트워크를 확인합니다.

$ openstack network list
+-----------------------+-------------+--------------------------------------+
| id                    | name        | subnets                              |
+-----------------------+-------------+--------------------------------------+
| d474fe1f-222d-4e32... | public      | 01c5f621-1e0f-4b9d-9c30-7dc59592a52f |
+-----------------------+-------------+--------------------------------------+

다음 조건을 충족하면 유동 IP 네트워크에서 br-ex가 아닌 모든 브리지를 사용할 수 있습니다.

오버클라우드 생성 후 유동 IP 네트워크를 생성합니다.

$ source ~/overcloudrc
$ openstack network create ext-net --external --provider-physical-network floating --provider-network-type vlan --provider-segment 105
$ openstack subnet create ext-subnet --network ext-net --dhcp --allocation-pool start=10.1.2.51,end=10.1.2.250 --gateway 10.1.2.1 --subnet-range 10.1.2.0/24

공급자 네트워크는 배포된 오버클라우드 외부에 있는 네트워크에 물리적으로 연결된 네트워크입니다. 이 네트워크는 기존 인프라 네트워크이거나 유동 IP 대신 라우팅을 통해 인스턴스에 직접 외부 액세스를 제공하는 네트워크입니다.

공급자 네트워크를 생성할 때 브리지 매핑을 사용하는 물리적 네트워크와 연결합니다. 이는 유동 IP 네트워크 생성과 비슷합니다. Compute 노드가 VM 가상 네트워크 인터페이스를 연결된 네트워크 인터페이스에 직접 연결하므로, 공급자 네트워크를 Controller와 Compute 노드에 모두 추가합니다.

예를 들어 원하는 공급자 네트워크가 br-ex 브리지의 VLAN이면 다음 명령을 사용하여 VLAN 201의 공급자 네트워크를 추가합니다.

$ source ~/overcloudrc
$ openstack network create provider_network --provider-physical-network datacentre --provider-network-type vlan --provider-segment 201 --share

이 명령은 공유된 네트워크를 생성합니다. 또한 --share를 지정하지 않고 테넌트를 지정할 수 있습니다. 이 네트워크는 지정된 테넌트에서만 사용할 수 있습니다. 공급자 네트워크를 외부로 표시하는 경우 운영자만 해당 네트워크에 포트를 생성할 수 있습니다.

neutron에서 DHCP 서비스를 테넌트 인스턴스에 제공하도록 하려면 공급자 네트워크에 서브넷을 추가합니다.

$ source ~/overcloudrc
$ openstack subnet create provider-subnet --network  provider_network --dhcp --allocation-pool start=10.9.101.50,end=10.9.101.100 --gateway 10.9.101.254 --subnet-range 10.9.101.0/24

다른 네트워크에서 공급자 네트워크를 통해 외부적으로 액세스해야 할 수 있습니다. 이 경우 다른 네트워크에서 공급자 네트워크를 통해 트래픽을 라우팅할 수 있도록 새 라우터를 생성합니다.

$ openstack router create external
$ openstack router set --external-gateway provider_network external

다른 네트워크를 이 라우터에 연결합니다. 예를 들어 subnet1이라는 서브넷이 있는 경우 다음 명령을 사용하여 해당 서브넷을 라우터에 연결할 수 있습니다.

$ openstack router add subnet external subnet1

이렇게 하면 subnet1이 라우팅 테이블에 추가되고, subnet1을 사용하는 트래픽이 공급자 네트워크로 라우팅됩니다.

오버클라우드는 일련의 통합 테스트를 수행하도록 설정된 OpenStack Integration Test Suite (tempest) 툴셋을 사용합니다. 이 섹션에서는 통합 테스트 실행 준비에 대한 정보를 제공합니다. OpenStack Integration Test Suite 사용에 대한 전체 지침은 OpenStack Integration Test Suite 가이드를 참조하십시오.

$ source ~/stackrc
$ sudo ovs-vsctl add-port br-ctlplane vlan201 tag=201 -- set interface vlan201 type=internal
$ sudo ip l set dev vlan201 up; sudo ip addr add 172.16.0.201/24 dev vlan201

OpenStack Integration Test Suite를 실행하기 전에 오버클라우드에 heat_stack_owner 역할이 있는지 확인합니다.

$ source ~/overcloudrc
$ openstack role list
+----------------------------------+------------------+
| ID                               | Name             |
+----------------------------------+------------------+
| 6226a517204846d1a26d15aae1af208f | swiftoperator    |
| 7c7eb03955e545dd86bbfeb73692738b | heat_stack_owner |
+----------------------------------+------------------+

역할이 없는 경우 역할을 생성합니다.

$ openstack role create heat_stack_owner

$ source ~/stackrc
$ sudo ovs-vsctl del-port vlan201

다른 기능을 추가하도록 오버클라우드를 수정하거나 작동 방식을 변경할 수 있습니다. 오버클라우드를 수정하려면 사용자 정의 환경 파일 및 Heat 템플릿을 수정한 다음, 초기 오버클라우드 생성 시의 openstack overcloud deploy 명령을 다시 실행합니다. 예를 들어 5.6절. “CLI 툴로 오버클라우드 생성”을 사용하여 오버클라우드를 생성한 경우 다음 명령을 다시 실행합니다.

$ source ~/stackrc
$ openstack overcloud deploy --templates \
  -e ~/templates/node-info.yaml \
  -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

director는 heat에서 overcloud 스택을 확인한 다음, 스택의 각 항목을 환경 파일 및 heat 템플릿으로 업데이트합니다. 그러면 오버클라우드가 다시 생성되지는 않지만, 기존 오버클라우드가 변경됩니다.

새 환경 파일을 포함하려면 해당 파일을 -e 옵션과 함께 openstack overcloud deploy 명령에 추가합니다. 예를 들면 다음과 같습니다.

$ source ~/stackrc
$ openstack overcloud deploy --templates \
  -e ~/templates/new-environment.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e ~/templates/network-environment.yaml \
  -e ~/templates/storage-environment.yaml \
  -e ~/templates/node-info.yaml \
  --ntp-server pool.ntp.org

이렇게 하면 환경 파일의 새 매개 변수와 리소스가 스택에 포함됩니다.

기존 OpenStack 환경이 있으며 해당 가상 머신을 Red Hat OpenStack Platform 환경으로 마이그레이션하려는 경우 다음 절차를 사용하십시오.

실행 중인 서버의 스냅샷을 저장하여 새 이미지를 생성하고 해당 이미지를 다운로드합니다.

$ openstack server image create instance_name --name image_name
$ openstack image save image_name --file exported_vm.qcow2

오버클라우드로 내보낸 이미지를 업로드하고 새 인스턴스를 실행합니다.

$ openstack image create imported_image --file exported_vm.qcow2 --disk-format qcow2 --container-format bare
$ openstack server create  imported_instance --key-name default --flavor m1.demo --image imported_image --nic net-id=net_id

상황에 따라 오버클라우드 Compute 노드에서 유지보수를 수행해야 할 수 있습니다. 다운 타임을 방지하려면 Compute 노드에서 VM을 오버클라우드의 다른 Compute 노드로 마이그레이션합니다.

director는 안전한 마이그레이션을 제공하기 위해 모든 Compute 노드를 구성합니다. 모든 Compute 노드에는 마이그레이션 프로세스 중에 다른 Compute 노드에 대한 액세스 권한을 각 호스트의 nova 사용자에게 제공하기 위해 공유 SSH 키도 필요합니다. director는 OS::TripleO::Services::NovaCompute 구성 가능한 서비스를 사용하여 이 키를 생성합니다. 구성 가능한 이 서비스는 기본적으로 모든 Compute 역할에 포함된 기본 서비스 중 하나입니다(고급 오버클라우드 사용자 정의의 "구성 가능한 서비스 및 사용자 정의 역할" 참조).

인스턴스를 마이그레이션하려면 다음을 수행합니다:

이렇게 하면 Compute 노드의 모든 인스턴스가 마이그레이션됩니다. 이제 인스턴스 중단 없이 노드에서 유지보수를 수행할 수 있습니다. Compute 노드를 활성화된 상태로 되돌리려면 다음 명령을 실행합니다.

$ source ~/overcloudrc
$ openstack compute service set [hostname] nova-compute --enable

director에서는 OpenStack Platform 환경에서 Ansible 기반 자동화를 실행하는 기능을 제공합니다. director는 tripleo-ansible-inventory 명령을 사용하여 환경에 노드의 동적 인벤토리를 생성합니다.

노드의 동적 인벤토리를 보려면 stackrc를 소싱한 후 tripleo-ansible-inventory 명령을 실행합니다.

$ souce ~/stackrc
$ tripleo-ansible-inventory --list

--list 옵션은 모든 호스트에 대한 세부 사항을 제공합니다.

이렇게 하면 동적 인벤토리가 JSON 형식으로 출력됩니다.

{"overcloud": {"children": ["controller", "compute"], "vars": {"ansible_ssh_user": "heat-admin"}}, "controller": ["192.168.24.2"], "undercloud": {"hosts": ["localhost"], "vars": {"overcloud_horizon_url": "http://192.168.24.4:80/dashboard", "overcloud_admin_password": "abcdefghijklm12345678", "ansible_connection": "local"}}, "compute": ["192.168.24.3"]}

현재 환경에서 Ansible 플레이북을 실행하려면 ansible 명령을 실행하고 -i 옵션을 사용하여 동적 인벤토리 툴의 전체 경로를 포함합니다. 예를 들면 다음과 같습니다.

ansible [HOSTS] -i /bin/tripleo-ansible-inventory [OTHER OPTIONS]

heat stack-delete overcloud 명령 사용으로 오버클라우드가 실수로 제거되지 않도록 하기 위해 Heat에 특정 작업을 제한할 일련의 정책이 포함되어 있습니다. /etc/heat/policy.json을 편집하고 다음 매개 변수를 검색합니다.

"stacks:delete": "rule:deny_stack_user"

다음과 같이 변경합니다.

"stacks:delete": "rule:deny_everybody"

파일을 저장합니다.

이렇게 하면 오버클라우드가 heat 클라이언트와 함께 제거되지 않습니다. 오버클라우드 제거를 허용하려면 정책을 원래 값으로 되돌립니다.

원하는 경우 전체 오버클라우드를 제거할 수 있습니다.

기존 오버클라우드를 삭제합니다.

$ source ~/stackrc
$ openstack overcloud delete overcloud

오버클라우드 삭제를 확인합니다.

$ openstack stack list

삭제에는 몇 분 정도 시간이 걸립니다.

제거가 완료되면 배포 시나리오의 표준 단계에 따라 오버클라우드를 다시 생성합니다.

director의 노드 풀에 더 많은 노드를 추가하려면 등록할 새 노드 세부 사항이 포함된 새 JSON 파일(예: newnodes.json)을 생성합니다.

{
  "nodes":[
    {
        "mac":[
            "dd:dd:dd:dd:dd:dd"
        ],
        "cpu":"4",
        "memory":"6144",
        "disk":"40",
        "arch":"x86_64",
        "pm_type":"pxe_ipmitool",
        "pm_user":"admin",
        "pm_password":"p@55w0rd!",
        "pm_addr":"192.168.24.207"
    },
    {
        "mac":[
            "ee:ee:ee:ee:ee:ee"
        ],
        "cpu":"4",
        "memory":"6144",
        "disk":"40",
        "arch":"x86_64",
        "pm_type":"pxe_ipmitool",
        "pm_user":"admin",
        "pm_password":"p@55w0rd!",
        "pm_addr":"192.168.24.208"
    }
  ]
}

이러한 매개 변수에 대한 설명은 5.1절. “오버클라우드에 노드 등록”을 참조하십시오.

다음 명령을 실행하여 이러한 노드를 등록합니다.

$ openstack baremetal import --json newnodes.json

새 노드를 등록한 후에 이러한 노드에 대한 introspection 프로세스를 시작합니다. 새로운 각 노드에 대해 다음 명령을 사용합니다.

$ openstack baremetal node manage [NODE UUID]
$ openstack overcloud node introspect [NODE UUID] --provide

이 경우 노드의 하드웨어 속성을 감지하여 벤치마킹합니다.

introspection 프로세스가 완료되면 해당 역할에 대해 각각의 새 노드를 태깅합니다. 예를 들어 Compute 노드의 경우 다음 명령을 사용합니다.

$ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' [NODE UUID]

배포 중에 사용할 부팅 이미지를 설정합니다. bm-deploy-kernel 및 bm-deploy-ramdisk 이미지의 UUID를 확인합니다.

$ openstack image list
+--------------------------------------+------------------------+
| ID                                   | Name                   |
+--------------------------------------+------------------------+
| 09b40e3d-0382-4925-a356-3a4b4f36b514 | bm-deploy-kernel       |
| 765a46af-4417-4592-91e5-a300ead3faf6 | bm-deploy-ramdisk      |
| ef793cd0-e65c-456a-a675-63cd57610bd5 | overcloud-full         |
| 9a51a6cb-4670-40de-b64b-b70f4dd44152 | overcloud-full-initrd  |
| 4f7e33f4-d617-47c1-b36f-cbe90f132e5d | overcloud-full-vmlinuz |
+--------------------------------------+------------------------+

새 노드의 deploy_kernel 및 deploy_ramdisk 설정에 대해 이러한 UUID를 설정합니다.

$ openstack baremetal node set --driver-info deploy_kernel='09b40e3d-0382-4925-a356-3a4b4f36b514' [NODE UUID]
$ openstack baremetal node set --driver-info deploy_ramdisk='765a46af-4417-4592-91e5-a300ead3faf6' [NODE UUID]

오버클라우드를 확장하려면 역할에 필요한 노드 수를 지정하고 openstack overcloud deploy를 다시 실행해야 합니다. 예를 들어 5개의 Compute 노드로 확장하려면 다음을 실행합니다.

$ openstack overcloud deploy --templates --compute-scale 5 [OTHER_OPTIONS]

이렇게 하면 전체 오버클라우드 스택이 업데이트됩니다. 이 경우 스택만 업데이트됩니다. 오버클라우드가 삭제되고 스택이 교체되지는 않습니다.

오버클라우드에서 Compute 노드를 제거해야 하는 경우가 있을 수 있습니다. 예를 들면 문제가 있는 Compute 노드를 교체해야 할 수 있습니다.

다음으로 오버클라우드에서 노드의 Compute 서비스를 비활성화합니다. 그러면 노드에서 새 인스턴스가 예약되지 않습니다.

$ source ~/stack/overcloudrc
$ openstack compute service list
$ openstack compute service set [hostname] nova-compute --disable
$ source ~/stack/stackrc

오버클라우드 노드를 제거하려면 로컬 템플릿 파일을 사용하여 director에서 overcloud 스택으로 업데이트해야 합니다. 먼저, 오버클라우드 스택의 UUID를 확인합니다.

$ openstack stack list

삭제할 노드의 UUID를 확인합니다.

$ openstack server list

다음 명령을 실행하여 스택에서 노드를 삭제하고 그에 따라 플랜을 업데이트합니다.

$ openstack overcloud node delete --stack [STACK_UUID] --templates -e [ENVIRONMENT_FILE] [NODE1_UUID] [NODE2_UUID] [NODE3_UUID]

마지막으로 노드의 Compute 서비스를 제거합니다.

$ source ~/stack/overcloudrc
$ openstack compute service list
$ openstack compute service delete [service-id]
$ source ~/stack/stackrc

노드의 Open vSwitch 에이전트를 제거합니다.

$ source ~/stack/overcloudrc
$ openstack network agent list
$ openstack network agent delete [openvswitch-agent-id]
$ source ~/stack/stackrc

이제 오버클라우드에서 노드를 제거하여 다른 용도로 노드를 다시 프로비저닝할 수 있습니다.

Compute 노드에 장애가 발생하면 해당 노드를 작동하는 노드로 교체할 수 있습니다. Compute 노드 교체에는 다음 프로세스를 사용합니다.

이 프로세스를 수행하면 인스턴스의 가용성에 영향을 주지 않고 노드를 교체할 수 있습니다.

특정 상황에서 고가용성 클러스터의 Controller 노드에 장애가 발생할 수 있습니다. 이러한 경우 클러스터에서 해당 노드를 제거하고 새 Controller 노드로 교체해야 합니다. 또한 노드가 클러스터의 다른 노드에 연결되도록 해야 합니다.

이 섹션에서는 Controller 노드를 교체하는 방법에 대해 설명합니다. 프로세스에는 Controller 노드 교체에 대한 요청으로 오버클라우드를 업데이트하는openstack overcloud deploy 명령을 실행하는 작업이 포함됩니다. 이 프로세스는 완전히 자동으로 수행되지 않습니다. 오버클라우드 스택 업데이트 프로세스 중에 openstack overcloud deploy 명령은 특정 시점에서 오류를 보고하고 오버클라우드 스택 업데이트를 중지합니다. 이 시점에서 프로세스를 수행하려면 일부 수동 조작이 필요합니다. 그런 다음 openstack overcloud deploy 프로세스를 계속할 수 있습니다.

[stack@director ~]$ openstack server list
+--------------------------------------+------------------------+
| ID                                   | Name                   |
+--------------------------------------+------------------------+
| 861408be-4027-4f53-87a6-cd3cf206ba7a | overcloud-compute-0    |
| 0966e9ae-f553-447a-9929-c4232432f718 | overcloud-compute-1    |
| 9c08fa65-b38c-4b2e-bd47-33870bff06c7 | overcloud-compute-2    |
| a7f0f5e1-e7ce-4513-ad2b-81146bc8c5af | overcloud-controller-0 |
| cfefaf60-8311-4bc3-9416-6a824a40a9ae | overcloud-controller-1 |
| 97a055d4-aefd-481c-82b7-4a5f384036d2 | overcloud-controller-2 |
+--------------------------------------+------------------------+

[stack@director ~]$ openstack baremetal node list
+--------------------------------------+------+--------------------------------------+
| UUID                                 | Name | Instance UUID                        |
+--------------------------------------+------+--------------------------------------+
| 36404147-7c8a-41e6-8c72-a6e90afc7584 | None | 7bee57cf-4a58-4eaf-b851-2a8bf6620e48 |
| 91eb9ac5-7d52-453c-a017-c0e3d823efd0 | None | None                                 |
| 75b25e9a-948d-424a-9b3b-f0ef70a6eacf | None | None                                 |
| 038727da-6a5c-425f-bd45-fda2f4bd145b | None | 763bfec2-9354-466a-ae65-2401c13e07e5 |
| dc2292e6-4056-46e0-8848-d6e96df1f55d | None | 2017b481-706f-44e1-852a-2ee857c303c4 |
| c7eadcea-e377-4392-9fc3-cf2b02b7ec29 | None | 5f73c7d7-4826-49a5-b6be-8bfd558f3b41 |
| da3a8d19-8a59-4e9d-923a-6a336fe10284 | None | cfefaf60-8311-4bc3-9416-6a824a40a9ae |
| 807cb6ce-6b94-4cd1-9969-5c47560c2eee | None | c07c13e6-a845-4791-9628-260110829c3a |
+--------------------------------------+------+--------------------------------------+

[stack@director ~]$ openstack baremetal node maintenance set da3a8d19-8a59-4e9d-923a-6a336fe10284

[stack@director ~]$ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 75b25e9a-948d-424a-9b3b-f0ef70a6eacf

[stack@director ~]$ ssh heat-admin@192.168.0.47 "sudo pcs resource unmanage galera"

parameters:
  ControllerRemovalPolicies:
    [{'resource_list': ['1']}]

parameter_defaults:
  CorosyncSettleTries: 5

[stack@director ~]$ openstack overcloud deploy --templates --control-scale 3 -e ~/templates/remove-controller.yaml [OTHER OPTIONS]

[stack@director ~]$ openstack stack list --nested

[stack@director ~]$ openstack overcloud deploy --templates --control-scale 3 [OTHER OPTIONS]

[heat-admin@overcloud-controller-0 ~]$ for i in `sudo pcs status|grep -B2 Stop |grep -v "Stop\|Start"|awk -F"[" '/\[/ {print substr($NF,0,length($NF)-1)}'`; do echo $i; sudo pcs resource cleanup $i; done

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

[heat-admin@overcloud-controller-0 ~]$ exit

[stack@director ~]$ source ~/overcloudrc
[stack@director ~]$ neutron l3-agent-list-hosting-router r1

[stack@director ~]$ neutron agent-list | grep "neutron-l3-agent"

[stack@director ~]$ neutron l3-agent-router-add fd6b3d6e-7d8c-4e1a-831a-4ec1c9ebb965 r1
[stack@director ~]$ neutron l3-agent-router-remove b40020af-c6dd-4f7a-b426-eba7bac9dbc2 r1

[stack@director ~]$ neutron l3-agent-list-hosting-router r1

[stack@director ~]$ neutron agent-list -F id -F host | grep overcloud-controller-1
| ddae8e46-3e8e-4a1b-a8b3-c87f13c294eb | overcloud-controller-1.localdomain |
[stack@director ~]$ neutron agent-delete ddae8e46-3e8e-4a1b-a8b3-c87f13c294eb

[stack@director ~]$ source ~/overcloudrc
[stack@director ~]$ nova service-list | grep "overcloud-controller-1.localdomain"

[stack@director ~]$ nova service-delete 5

[stack@director ~]$ nova service-list | grep consoleauth

[stack@director] ssh heat-admin@192.168.0.47
[heat-admin@overcloud-controller-0 ~]$ pcs resource restart openstack-nova-consoleauth

director에서는 director에서 생성한 클러스터에 있는 Ceph Storage 노드를 교체할 수 있습니다. 오버클라우드 용 Red Hat Ceph Storage에서 자세한 내용을 확인하십시오.

이 섹션에서는 클러스터의 무결성을 유지보수하는 동안 Object Storage 노드를 교체하는 방법을 설명합니다. 이 예에서는 두 개의 노드로 구성된 Object Storage 클러스터에서 overcloud-objectstorage-1 노드를 교체해야 합니다. 이 절차에서는 한 개의 노드를 더 추가한 다음 overcloud-objectstorage-1을 제거하는 것을 목표로 합니다(효율적으로 교체).

director가 오버클라우드에서 Object Storage 노드를 삭제하고 노드 제거를 적용하도록 오버클라우드에서 나머지 노드를 업데이트합니다.

director 노드를 재부팅하려면 다음 프로세스를 따르십시오.

노드가 부팅되면 모든 서비스의 상태를 확인합니다.

$ sudo systemctl list-units "openstack*" "neutron*" "openvswitch*"

오버클라우드 및 해당 노드가 있는지 확인합니다.

$ source ~/stackrc
$ openstack server list
$ openstack baremetal node list
$ openstack stack list

Controller 노드를 재부팅하려면 다음 프로세스를 따르십시오.

Ceph Storage 노드를 재부팅하려면 다음 절차를 따르십시오.

각 Compute 노드를 개별적으로 재부팅하고 OpenStack Platform 환경의 인스턴스 다운타임이 제로가 되도록합니다. 다음 워크플로우에 따라 실행합니다.

모든 Compute 노드 및 해당 UUID를 나열합니다.

$ nova list | grep "compute"

재부팅할 Compute 노드를 선택하고 다음 프로세스를 사용하여 먼저 해당 인스턴스를 마이그레이션합니다.

다음 프로세스를 사용하여 Compute 노드를 재부팅합니다.

Object Storage 노드를 재부팅하려면 다음 프로세스를 따르십시오.

노드 등록 문제는 일반적으로 잘못된 노드 세부 사항 문제로 인해 발생합니다. 이 경우 ironic을 사용하여 등록된 노드 데이터 문제를 해결합니다. 다음은 몇 가지 예입니다.

할당된 포트 UUID를 확인합니다:

$ ironic node-port-list [NODE UUID]

MAC 주소를 업데이트합니다:

$ ironic port-update [PORT UUID] replace address=[NEW MAC]

다음 명령을 실행합니다:

$ ironic node-update [NODE UUID] replace driver_info/ipmi_address=[NEW IPMI ADDRESS]

introspection 프로세스 실행은 끝까지 완료되어야 합니다. 하지만 검색 램디스크가 응답하지 않을 경우 ironic의 검색 데몬(ironic-inspector)이 1시간(기본값) 후에 시간 초과됩니다. 경우에 따라 이는 검색 램디스크의 버그가 원인이 되는 경우도 있지만, 일반적으로는 BIOS 부팅 설정 등 잘못된 환경 구성으로 인해 설정 오류가 발생합니다.

다음은 잘못된 환경 구성이 발생하는 몇 가지 일반적인 시나리오 및 진단/해결 방법에 대한 설명입니다.

$ ironic node-set-provision-state [NODE UUID] manage

그런 다음 검색이 완료되면 프로비저닝 전에 다시 AVAILABLE로 변경합니다.

$ ironic node-set-provision-state [NODE UUID] provide

$ openstack baremetal introspection abort [NODE UUID]

프로세스가 시간 초과될 때까지 기다릴 수 있습니다. 필요한 경우 timeout 설정을 /etc/ironic-inspector/inspector.conf에서 다른 기간(분)으로 변경합니다.

$ sudo systemctl list-units openstack-swift*

OpenStack Workflow(mistral) 서비스는 여러 OpenStack 작업을 워크플로우에 그룹화합니다. Red Hat OpenStack Platform은 이러한 워크플로우 집합을 사용하여 CLI 및 웹 UI에 일반적인 기능을 수행합니다. 여기에는 베어 메탈 노드 제어, 검증 및 플랜 관리 및 오버클라우드 배포가 포함됩니다.

예를 들어 openstack overcloud deploy 명령을 실행할 때 OpenStack Workflow 서비스는 두 개의 워크플로우를 실행합니다. 첫 번째는 배포 플랜을 업로드합니다.

Removing the current plan files
Uploading new plan files
Started Mistral Workflow. Execution ID: aef1e8c6-a862-42de-8bce-073744ed5e6b
Plan updated

두 번째는 오버클라우드 배포를 시작합니다.

Deploying templates in the directory /tmp/tripleoclient-LhRlHX/tripleo-heat-templates
Started Mistral Workflow. Execution ID: 97b64abe-d8fc-414a-837a-1380631c764d
2016-11-28 06:29:26Z [overcloud]: CREATE_IN_PROGRESS  Stack CREATE started
2016-11-28 06:29:26Z [overcloud.Networks]: CREATE_IN_PROGRESS  state changed
2016-11-28 06:29:26Z [overcloud.HeatAuthEncryptionKey]: CREATE_IN_PROGRESS  state changed
2016-11-28 06:29:26Z [overcloud.ServiceNetMap]: CREATE_IN_PROGRESS  state changed
...

$ mistral execution-list | grep "ERROR"

실패한 워크플로우 실행의 UUID를 가져와서(예: 3c87a885-0d37-4af8-a471-1b392264a7f5) 실행 및 해당 출력을 표시합니다.

$ mistral execution-get 3c87a885-0d37-4af8-a471-1b392264a7f5
$ mistral execution-get-output 3c87a885-0d37-4af8-a471-1b392264a7f5

이는 실행에서 실패한 작업에 대한 정보를 제공합니다. mistral execution-get은 또한 실행에 사용된 워크플로우를 표시합니다(예: tripleo.plan_management.v1.update_deployment_plan). 다음 명령을 사용하면 전체 워크플로우 정의를 볼 수 있습니다.

$ mistral execution-get-definition tripleo.plan_management.v1.update_deployment_plan

이 명령은 워크플로우에서 특정 작업이 발생한 위치를 식별하는 데 유용합니다.

비슷한 명령 구문을 사용하여 작업 실행 및 해당 결과를 볼 수도 있습니다.

$ mistral action-execution-list
$ mistral action-execution-get b59245bf-7183-4fcf-9508-c83ec1a26908
$ mistral action-execution-get-output b59245bf-7183-4fcf-9508-c83ec1a26908

이는 문제의 원인이 되는 특정 작업을 식별하는 데 유용합니다.

배포가 실패할 수 있는 세 가지 계층이 있습니다.

오버클라우드 배포가 이러한 수준에서 실패한 경우 OpenStack 클라이언트 및 서비스 로그 파일을 사용하여 실패한 배포를 진단합니다.

$ heat stack-list
+-----------------------+------------+--------------------+----------------------+
| id                    | stack_name | stack_status       | creation_time        |
+-----------------------+------------+--------------------+----------------------+
| 7e88af95-535c-4a55... | overcloud  | CREATE_FAILED      | 2015-04-06T17:57:16Z |
+-----------------------+------------+--------------------+----------------------+

$ ironic node-list

+----------+------+---------------+-------------+-----------------+-------------+
| UUID     | Name | Instance UUID | Power State | Provision State | Maintenance |
+----------+------+---------------+-------------+-----------------+-------------+
| f1e261...| None | None          | power off   | available       | False       |
| f0b8c1...| None | None          | power off   | available       | False       |
+----------+------+---------------+-------------+-----------------+-------------+

$ heat resource-list overcloud

$ heat resource-show overcloud [FAILED RESOURCE]

$ nova list

$ ssh heat-admin@192.168.24.14

$ sudo journalctl -u os-collect-config

$ nova list
$ nova show [SERVER ID]

$ sudo yum install sos

$ sudo sosreport --all-logs

대상 호스트가 이미 사용 중인 할당된 IP 주소이면 검색 및 배포 작업이 실패합니다. 이 문제가 발생하지 않도록 하려면 프로비저닝 네트워크의 포트 스캔을 수행하여 검색 IP 범위 및 호스트 IP 범위를 사용할 수 있는지 확인합니다.

언더클라우드 호스트에서 다음 단계를 수행합니다.

nmap을 설치합니다.

# yum install nmap

nmap을 사용하여 활성 주소에 대한 IP 주소 범위를 스캔합니다. 이 예에서는 192.168.24.0/24 범위를 스캔하고, 이 범위를 프로비저닝 네트워크의 IP 서브넷으로 교체합니다(CIDR 비트마스크 표기 사용).

# nmap -sn 192.168.24.0/24

nmap 스캔 출력을 검토합니다.

예를 들어 언더클라우드의 IP 주소 및 서브넷에 있는 다른 호스트가 표시됩니다. 활성 IP 주소가 undercloud.conf의 IP 범위와 충돌하는 경우 IP 주소 범위를 변경하거나 IP 주소가 사용 가능하도록 설정한 후에 오버클라우드 노드를 introspect하거나 배포해야 합니다.

# nmap -sn 192.168.24.0/24

Starting Nmap 6.40 ( http://nmap.org ) at 2015-10-02 15:14 EDT
Nmap scan report for 192.168.24.1
Host is up (0.00057s latency).
Nmap scan report for 192.168.24.2
Host is up (0.00048s latency).
Nmap scan report for 192.168.24.3
Host is up (0.00045s latency).
Nmap scan report for 192.168.24.5
Host is up (0.00040s latency).
Nmap scan report for 192.168.24.9
Host is up (0.00019s latency).
Nmap done: 256 IP addresses (5 hosts up) scanned in 2.45 seconds

/var/log/nova/nova-conductor.log에 다음 오류가 포함되는 경우가 있습니다.

NoValidHost: No valid host was found. There are not enough hosts available.

이는 nova 스케줄러가 새 인스턴스 부팅에 적합한 베어 메탈 노드를 찾을 수 없음을 의미하며, 결국은 nova에서 찾아야 하는 리소스와 ironic에서 nova에 통지한 리소스가 일치하지 않음을 의미합니다. 이런 경우 다음을 확인하십시오.

오버클라우드 생성 후 나중에 특정 오버클라우드 작업을 수행할 수 있습니다. 예를 들어 사용 가능한 노드를 확장하거나 문제가 발생한 노드를 교체할 수 있습니다. 이러한 작업을 수행할 때 특정 문제가 발생할 수 있습니다. 이 섹션에서는 생성 후 작업 실패 문제를 진단하고 해결하는 몇 가지 방법을 설명합니다.

이 섹션의 지침은 언더클라우드의 성능 향상을 지원하기 위한 것입니다. 필요에 따라 권장사항을 구현하십시오.

문제를 해결할 때 다음 로그를 사용하여 언더클라우드 및 오버클라우드에 대한 정보를 찾습니다.