9장. 오버클라우드 생성 후 작업 수행

오버클라우드 배포 상태를 확인하려면 openstack overcloud status 명령을 사용합니다. 이 명령의 출력에는 모든 배포 단계의 결과가 표시됩니다.

OpenStack Platform은 언더클라우드 및 오버클라우드 노드의 컨테이너에서 서비스를 실행합니다. 특정 상황의 경우 호스트에서 개별 서비스를 제어해야 할 수 있습니다. 이 섹션에서는 노드에서 실행하여 컨테이너화된 서비스를 관리할 수 있는 몇 가지 일반적인 docker 명령을 제공합니다. 컨테이너를 관리할 수 있는 docker 사용에 대한 더 종합적인 정보는 컨테이너 시작하기 가이드에서 "Docker 포맷된 컨테이너 사용하기"를 참조하십시오.

$ sudo docker ps

중단되거나 실패한 컨테이너를 나열하려면 --all 옵션을 추가합니다.

$ sudo docker ps --all

컨테이너 이미지를 나열하려면 다음 명령을 실행합니다:

$ sudo docker images

$ sudo docker inspect keystone

$ sudo docker restart keystone

컨테이너화된 서비스를 중단하려면 docker restart 명령을 사용합니다. 예를 들어 keystone 컨테이너를 중단하는 방법은 다음과 같습니다.

$ sudo docker stop keystone

정지된 컨테이너화된 서비스를 시작하려면 docker restart 명령을 사용합니다. 예를 들어 keystone 컨테이너를 시작하는 방법은 다음과 같습니다.

$ sudo docker start keystone

$ sudo docker logs keystone

$ sudo docker exec -it keystone /bin/bash

root 사용자로 keystone 컨테이너 쉘에 들어가려면 다음 명령을 실행합니다.

$ sudo docker exec --user 0 -it <NAME OR ID> /bin/bash

컨테이너를 종료하려면 다음 명령을 실행합니다.

# exit

docker exec -ti -u swift swift_object_server swift-ring-builder /etc/swift/object.builder

해당 명령이 필요한 경우 다음 패키지를 언더클라우드에 stack 사용자로 설치하거나 오버클라우드에 heat-admin 사용자로 설치하십시오.

sudo yum install -y python-swift
sudo yum install -y python2-swiftclient

OpenStack Platform의 컨테이너화된 서비스 문제 해결에 대한 자세한 방법은 16.7.3절. “컨테이너화된 서비스 오류”를 참조하십시오.

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

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

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

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

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

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

overcloud를 소싱하여 Neutron에 외부 네트워크를 만듭니다. 예를 들면 다음과 같습니다.

$ source ~/overcloudrc
(overcloud) $ openstack network create public --external --provider-network-type flat --provider-physical-network datacentre
(overcloud) $ 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 풀에 대해 이러한 특정 이름이 필요합니다. 이는 9.8절. “오버클라우드 검증”의 검증 테스트에서도 중요합니다.

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

$ source ~/overcloudrc
(overcloud) $ openstack network create public --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 104
(overcloud) $ 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를 사용할 수 있습니다.

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

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

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

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

$ source ~/overcloudrc
(overcloud) $ openstack network create ext-net --external --provider-physical-network floating --provider-network-type vlan --provider-segment 105
(overcloud) $ 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
(overcloud) $ openstack network create provider_network --provider-physical-network datacentre --provider-network-type vlan --provider-segment 201 --share

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

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

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

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

(overcloud) $ openstack router create external
(overcloud) $ openstack router set --external-gateway provider_network external

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

(overcloud) $ openstack router add subnet external subnet1

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

이 가이드의 검증(Validation) 단계에서는 설치에 플레이버가 포함된 것으로 간주합니다. 플레이버를 하나 이상 생성하지 않은 경우, 다음 명령을 사용하여 다양한 스토리지 및 처리 기능이 있는 기본 플레이버 집합을 만드십시오.

$ openstack flavor create m1.tiny --ram 512 --disk 0 --vcpus 1
$ openstack flavor create m1.smaller --ram 1024 --disk 0 --vcpus 1
$ openstack flavor create m1.small --ram 2048 --disk 10 --vcpus 1
$ openstack flavor create m1.medium --ram 3072 --disk 10 --vcpus 2
$ openstack flavor create m1.large --ram 8192 --disk 10 --vcpus 4
$ openstack flavor create m1.xlarge --ram 8192 --disk 10 --vcpus 8

$ openstack flavor create --help는 openstack flavor create 명령 세부사항을 알아보는 데 사용됩니다.

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

$ source ~/stackrc
(undercloud) $ sudo ovs-vsctl add-port br-ctlplane vlan201 tag=201 -- set interface vlan201 type=internal
(undercloud) $ 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
(overcloud) $ openstack role list
+----------------------------------+------------------+
| ID                               | Name             |
+----------------------------------+------------------+
| 6226a517204846d1a26d15aae1af208f | swiftoperator    |
| 7c7eb03955e545dd86bbfeb73692738b | heat_stack_owner |
+----------------------------------+------------------+

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

(overcloud) $ openstack role create heat_stack_owner

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

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

$ source ~/stackrc
(undercloud) $ 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
(undercloud) $ 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

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

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

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

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

$ source ~/overcloudrc
(overcloud) $ openstack server image create instance_name --name image_name
(overcloud) $ openstack image save image_name --file exported_vm.qcow2

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

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

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

director는 안전한 마이그레이션을 제공하기 위해 모든 계산 노드를 구성합니다. 모든 계산 노드에는 마이그레이션 프로세스 중 다른 계산 노드에 대한 액세스 권한을 각 호스트의 nova 사용자에게 제공하기 위해 공유 SSH 키가 있어야 합니다. director는 OS::TripleO::Services::NovaCompute 구성 가능한 서비스를 사용하여 이 키를 생성합니다. 구성 가능한 이 서비스는 기본적으로 모든 Compute 역할에 포함된 기본 서비스 중 하나입니다(Advanced Overcloud Customization의 "Composable Services and Custom Roles" 참조).

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

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

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

"stacks:delete": "rule:deny_stack_user"

다음과 같이 변경합니다.

"stacks:delete": "rule:deny_everybody"

파일을 저장합니다.

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

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

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

$ source ~/stackrc
(undercloud) $ openstack overcloud delete overcloud

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

(undercloud) $ openstack stack list

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

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

Identity 서비스(keystone)는 다른 OpenStack 서비스에 대한 액세스 제어에 토큰 기반 시스템을 사용합니다. 일정한 기간이 지나면 데이터베이스에는 많은 양의 사용하지 않은 토큰이 누적됩니다. 기본 cron 작업은 매일 토큰 테이블을 플러시합니다. 환경을 모니터링하고 토큰 플러시 간격을 필요에 따라 조정하는 것이 좋습니다.

오버클라우드의 경우 KeystoneCronToken 값을 사용하여 간격을 조정할 수 있습니다. 자세한 내용은 Overcloud Parameters 가이드를 참조하십시오.