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

이 장에서는 선택한 오버클라우드를 생성한 후 수행하는 기능 중 몇 가지에 대해 살펴봅니다.

9.1. 오버클라우드 배포 상태 확인

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

절차

  1. stackrc 파일을 소싱합니다.

    $ source ~/stackrc
  2. 배포 상태 명령을 실행합니다.

    $ openstack overcloud status

    이 명령의 출력 상태가 표시됩니다.

    +-----------+---------------------+---------------------+-------------------+
    | Plan Name |       Created       |       Updated       | Deployment Status |
    +-----------+---------------------+---------------------+-------------------+
    | overcloud | 2018-05-03 21:24:50 | 2018-05-03 21:27:59 |   DEPLOY_SUCCESS  |
    +-----------+---------------------+---------------------+-------------------+

    오버클라우드에서 다른 이름을 사용하는 경우 --plan 인수를 사용하여 다른 이름이 있는 오버클라우드를 선택하십시오.

    $ openstack overcloud status --plan my-deployment

9.2. 컨테이너화된 서비스 관리

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

컨테이너 및 이미지 나열

실행 중인 컨테이너 나열하려면 다음 명령을 실행합니다:

$ sudo docker ps

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

$ sudo docker ps --all

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

$ sudo docker images

컨테이너 속성 검사

컨테이너 또는 컨테이너 이미지 속성을 확인하려면 docker inspect 명령을 사용합니다. 예를 들어 keystone 컨테이너를 조사하는 방법은 다음과 같습니다.

$ sudo docker inspect keystone

기본 컨테이너 작업 관리

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

$ sudo docker restart keystone

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

$ sudo docker stop keystone

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

$ sudo docker start keystone
참고

컨테이너를 다시 시작한 후에 컨테이너 내의 서비스 구성 파일에 대한 모든 변경 사항을 되돌립니다. 이는 컨테이너가 /var/lib/config-data/puppet-generated/에서 노드의 로컬 파일 시스템에 있는 파일을 기준으로 서비스 구성을 다시 생성하기 때문입니다. 예를 들어 keystone 컨테이너 내의 /etc/keystone/keystone.conf를 편집하고 컨테이너를 다시 시작하는 경우 컨테이너가 노드의 로컬 파일 시스템에서 /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf를 사용하여 구성을 다시 생성합니다. 이는 다시 시작하기 전에 컨테이너 내에 만들어진 모든 변경 사항을 덮어씁니다.

컨테이너 모니터링

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

$ sudo docker logs keystone

컨테이너 액세스

컨테이너화된 서비스 쉘에 들어가려면 docker exec 명령을 사용하여 /bin/bash를 시작합니다. 예를 들어 keystone 컨테이너 쉘에 들어가는 방법은 다음과 같습니다.

$ sudo docker exec -it keystone /bin/bash

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

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

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

# exit

언더클라우드 및 오버클라우드에서 swift-ring-builder 활성화

Object Storage(swift) 빌드의 지속성을 고려하여 swift-ring-builderswift_object_server 명령은 더 이상 언더클라우드 노드 또는 오버클라우드 노드에 패키지로 제공되지 않습니다. 그러나 컨테이너에서 명령을 계속 사용할 수 있습니다. 각 컨테이너에서 명령을 실행하려면 다음을 사용합니다.

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절. “컨테이너화된 서비스 오류”를 참조하십시오.

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

9.4. 오버클라우드 외부 네트워크 생성

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

기본 VLAN 사용

이 절차에서는 외부 네트워크에 전용 인터페이스 또는 기본 VLAN이 설정되어 있다고 가정합니다.

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 물리적 네트워크에 매핑합니다. 기본적으로 datacentrebr-ex 브리지에 매핑됩니다. 오버클라우드 생성 중에 사용자 정의 neutron 설정을 사용하지 않은 경우 이 옵션을 기본값으로 둡니다.

기본 이외의 VLAN 사용

기본 VLAN을 사용하지 않는 경우 다음 명령을 사용하여 네트워크를 VLAN에 할당합니다.

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

9.5. 추가 유동 IP 네트워크 생성

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

  • 네트워크 환경 파일에 NeutronExternalNetworkBridge"''"로 설정되어 있습니다.
  • 배포 중에 추가 브릿지를 매핑했습니다. 예를 들어 br-floating이라는 새 브릿지를 floating 물리적 네트워크에 매핑하려면 환경 파일에서 다음을 사용하십시오.

    parameter_defaults:
      NeutronBridgeMappings: "datacentre:br-ex,floating:br-floating"

오버클라우드 생성 후 유동 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

9.6. 오버클라우드 공급자 네트워크 생성

공급자 네트워크는 배포된 오버클라우드 외부에 있는 네트워크에 물리적으로 연결된 네트워크입니다. 이 네트워크는 기존 인프라 네트워크이거나 유동 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을 사용하는 트래픽이 공급자 네트워크로 라우팅됩니다.

9.7. 기본 오버클라우드 플레이버 생성

이 가이드의 검증(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

명령 옵션

ram
ram 옵션은 플레이버의 최대 RAM을 정의하는 데 사용됩니다.
disk
disk 옵션은 플레이버의 하드 디스크 공간을 정의하는 데 사용됩니다.
vcpus
vcpus 옵션은 플레이버의 가상 CPU 수를 정의하는 데 사용됩니다.

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

9.8. 오버클라우드 검증

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

Integration Test Suite를 실행하기 전

언더클라우드에서 이 테스트를 실행하는 경우 언더클라우드 호스트에서 오버클라우드의 내부 API 네트워크에 액세스할 수 있는지 확인합니다. 예를 들면 172.16.0.201/24 주소를 사용하여 내부 API 네트워크(ID: 201)에 액세스할 언더클라우드 호스트에 임시 VLAN을 추가합니다.

$ 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

Integration Test Suite를 실행한 후

검증을 완료한 후 오버클라우드의 내부 API에 대한 임시 연결을 제거합니다. 이 예에서는 다음 명령을 사용하여 이전에 생성한 VLAN을 언더클라우드에서 제거합니다.

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

9.9. 오버클라우드 환경 수정

다른 기능을 추가하도록 오버클라우드를 수정하거나 작동 방식을 변경할 수 있습니다. 오버클라우드를 수정하려면 사용자 정의 환경 파일 및 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가 나중에 이러한 수정 사항을 덮어쓸 수 있습니다.

9.10. 동적 인벤토리 스크립트 실행

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

절차

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

    $ source ~/stackrc
    (undercloud) $ 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"]}
  2. 현재 환경에서 Ansible 플레이북을 실행하려면 ansible 명령을 실행하고 -i 옵션을 사용하여 동적 인벤토리 툴의 전체 경로를 포함합니다. 예를 들면 다음과 같습니다.

    (undercloud) $ ansible [HOSTS] -i /bin/tripleo-ansible-inventory [OTHER OPTIONS]
    • [HOSTS]를 사용할 호스트 유형으로 변경합니다. 예를 들면 다음과 같습니다.

      • 모든 Controller 노드인 경우 controller
      • 모든 Compute 노드인 경우 compute
      • 모든 오버클라우드 하위 노드인 경우 overcloud. 예: controllercompute
      • 언더클라우드인 경우 undercloud
      • 모든 노드인 경우 "*"
    • [OTHER OPTIONS]를 추가 Ansible 옵션으로 변경합니다. 몇 가지 유용한 옵션은 다음과 같습니다.

      • --ssh-extra-args='-o StrictHostKeyChecking=no': 호스트 키 검사에서 확인을 바이패스합니다.
      • -u [USER]: Ansible 자동화를 실행하는 SSH 사용자를 변경합니다. 오버클라우드에 대한 기본 SSH 사용자는 동적 인벤토리에서 ansible_ssh_user 매개 변수를 사용하여 자동으로 정의됩니다. -u 옵션은 이 매개 변수를 재정의합니다.
      • -m [MODULE]: 특정Ansible 모듈을 사용합니다. 기본값은 Linux 명령을 실행하는 command입니다.
      • -a [MODULE_ARGS]: 선택한 모듈에 대한 인수를 정의합니다.
중요

오버클라우드에서 Ansible 자동화는 표준 오버클라우드 스택 외부에 속합니다. 즉, 후속 openstack overcloud deploy 명령을 실행하면 오버클라우드 노드에서 OpenStack Platform 서비스에 대한 Ansible 기반 구성을 덮어쓸 수 있습니다.

9.11. 가상 머신을 오버클라우드로 가져오기

기존 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
중요

각 VM 디스크를 기존 OpenStack 환경에서 새 Red Hat OpenStack Platform으로 복사합니다. QCOW를 사용한 스냅샷은 원래 계층 시스템이 손실됩니다.

9.12. Compute 노드에서 인스턴스 마이그레이션

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

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

절차

  1. 언더클라우드에서 Compute 노드를 선택하여 비활성화합니다.

    $ source ~/overcloudrc
    (overcloud) $ openstack compute service list
    (overcloud) $ openstack compute service set [hostname] nova-compute --disable
  2. Compute 노드에 모든 인스턴스를 나열합니다.

    (overcloud) $ openstack server list --host [hostname] --all-projects
  3. 다음 명령 중 하나를 사용하여 인스턴스를 마이그레이션합니다.

    1. 인스턴스를 선택한 특정 호스트로 마이그레이션합니다.

      (overcloud) $ openstack server migrate [instance-id] --live [target-host]--wait
    2. nova-scheduler에서 대상 호스트를 자동으로 선택하도록 합니다.

      (overcloud) $ nova live-migration [instance-id]
    3. 한 번에 모든 인스턴스를 실시간 마이그레이션합니다.

      $ nova host-evacuate-live [hostname]
      참고

      nova 명령으로 인해 몇 가지 사용 중단 경고가 표시될 수 있으며, 이러한 경고는 무시해도 됩니다.

  4. 마이그레이션이 완료될 때까지 기다립니다.
  5. 마이그레이션을 성공적으로 완료했음을 확인합니다.

    (overcloud) $ openstack server list --host [hostname] --all-projects
  6. 선택한 Compute 노드에 남은 항목이 없을 때까지 인스턴스를 계속 마이그레이션합니다.

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

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

9.13. 오버클라우드 삭제 방지

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

"stacks:delete": "rule:deny_stack_user"

다음과 같이 변경합니다.

"stacks:delete": "rule:deny_everybody"

파일을 저장합니다.

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

9.14. 오버클라우드 제거

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

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

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

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

(undercloud) $ openstack stack list

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

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

9.15. 토큰 플러시 간격 확인

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

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


Red Hat의 최신 제품 문서 번역을 신속하게 제공하기 위해 이 페이지에는 영어 원본을 한국어로 자동 번역한 내용이 포함되어 있을 수 있습니다. [자세한 내용보기]