8장. 사전 프로비저닝된 노드를 사용하여 기본 오버클라우드 구성

이 장에서는 OpenStack Platform 환경 구성에 사전 프로비저닝된 노드를 사용하기 위한 기본 구성 단계를 설명합니다. 이 시나리오는 여러 방식에서 표준 오버클라우드 생성 시나리오와 다릅니다.

  • 외부 툴을 사용하여 노드를 프로비저닝하고 director가 오버클라우드 구성만 제어하도록 할 수 있습니다.
  • director의 프로비저닝 방법에 의존하지 않고 노드를 사용할 수 있습니다. 이는 전원 관리 제어 없이 오버클라우드를 생성하거나 DHCP/PXE 부팅 제한이 있는 네트워크를 사용하는 경우 유용합니다.
  • director에서 노드 관리에 OpenStack Compute(nova), OpenStack Bare Metal(ironic) 또는 OpenStack Image(glance)를 사용하지 않습니다.
  • 사전 프로비저닝된 노드에서는 QCOW2 overcloud-full 이미지를 사용하지 않는 사용자 지정 파티션 레이아웃을 사용할 수 있습니다.

이 시나리오는 사용자 지정 기능이 없는 기본 구성을 제공합니다. 하지만 고급 구성 옵션을 이 기본 오버클라우드에 추가하고 Advanced Overcloud Customization 가이드의 지침을 사용하여 사양에 맞게 사용자 지정할 수 있습니다.

중요

사전 프로비저닝된 노드를 오버클라우드의 director에서 프로비저닝된 노드와 혼합하는 기능은 지원되지 않습니다.

요구 사항

  • 4장. Director 설치에서 생성한 director 노드
  • 노드의 베어 메탈 머신 집합이 필요합니다. 필요한 노드 수는 생성하려는 오버클라우드 유형에 따라 다릅니다. 해당 머신은 각 노드 유형에 설정된 요구 사항도 준수해야 합니다. 이러한 노드에는 Red Hat Enterprise Linux 7.5 이상의 호스트 운영 체제를 설치해야 하며, 최신 버전을 사용하는 것이 좋습니다.
  • 사전 프로비저닝된 노드를 관리하기 위한 하나의 네트워크 연결. 이 시나리오를 수행하려면 오케스트레이션 에이전트 구성을 위해 노드에 SSH 액세스가 중단되지 않도록 해야 합니다.
  • 컨트롤 플레인 네트워크에 대한 하나의 네트워크 연결. 이 네트워크에는 두 가지 시나리오가 있습니다.

    • 프로비저닝 네트워크를 컨트롤 플레인으로 사용(기본 시나리오). 이 네트워크는 일반적으로 사전 프로비저닝된 노드에서 director로 연결되는 3 계층(L3) 라우팅 가능한 네트워크 연결입니다. 이 시나리오의 예는 다음 IP 주소 할당을 사용합니다.

      표 8.1. 프로비저닝 네트워크 IP 할당

      노드 이름IP 주소

      Director

      192.168.24.1

      Controller

      192.168.24.2

      Compute

      192.168.24.3

    • 별도 네트워크 사용. director의 프로비저닝 네트워크가 라우팅 불가능한 개인 네트워크인 경우 서브넷에서 노드의 IP 주소를 정의하고 공용 API 엔드포인트를 통해 director와 통신할 수 있습니다. 이 시나리오에는 특정한 주의 사항이 있으며, 이 장에서는 8.5절. “오버클라우드 노드에 별도의 네트워크 사용”에서 나중에 검토합니다.
  • 이 예에 있는 다른 모든 네트워크 유형에서도 OpenStack 서비스에 컨트롤 플레인 네트워크를 사용합니다. 하지만 다른 네트워크 트래픽 유형에 대해 추가 네트워크를 생성할 수 있습니다.

8.1. 노드 구성을 위한 사용자 생성

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

  1. 각 오버클라우드 노드에서 stack이라는 사용자를 생성하고 각 노드에 대한 암호를 설정합니다. 예를 들면 컨트롤러 노드에서 다음을 사용합니다.

    [root@controller ~]# useradd stack
    [root@controller ~]# passwd stack  # specify a password
  2. sudo 사용 시 이 사용자가 암호를 요구하지 않도록 합니다.

    [root@controller ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
    [root@controller ~]# chmod 0440 /etc/sudoers.d/stack
  3. 사전 프로비저닝된 노드에 stack 사용자를 생성하고 구성했으면 director 노드에서 각 오버클라우드 노드로 stack 사용자의 공용 SSH 키를 복사합니다. 예를 들어 director의 공용 SSH 키를 컨트롤러 노드에 복사하려면 다음을 수행합니다.

    [stack@director ~]$ ssh-copy-id stack@192.168.24.2

8.2. 노드의 운영 체제 등록

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

  1. 등록 명령을 실행하고 메시지가 표시되면 고객 포털 사용자 이름과 암호를 입력합니다.

    [root@controller ~]# sudo subscription-manager register
  2. Red Hat OpenStack Platform 14에 대한 인타이틀먼트 풀을 검색합니다.

    [root@controller ~]# sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
  3. 이전 단계에 있는 풀 ID를 사용하여 Red Hat OpenStack Platform 14 인타이틀먼트를 연결합니다.

    [root@controller ~]# sudo subscription-manager attach --pool=pool_id
  4. 모든 기본 리포지토리를 비활성화합니다.

    [root@controller ~]# sudo subscription-manager repos --disable=*
  5. 필수 Red Hat Enterprise Linux 리포지토리를 활성화합니다.

    1. x86_64 시스템의 경우 다음을 실행합니다.

      [root@controller ~]# sudo subscription-manager repos --enable=rhel-7-server-rpms --enable=rhel-7-server-extras-rpms --enable=rhel-7-server-rh-common-rpms --enable=rhel-ha-for-rhel-7-server-rpms --enable=rhel-7-server-openstack-14-rpms --enable=rhel-7-server-rhceph-2-osd-rpms --enable=rhel-7-server-rhceph-2-mon-rpms --enable=rhel-7-server-rhceph-2-tools-rpms
    2. POWER 시스템의 경우 다음을 실행합니다.

      [root@controller ~]# sudo subscription-manager repos --enable=rhel-7-for-power-le-rpms --enable=rhel-7-server-openstack-14-for-power-le-rpms
    중요

    나열된 리포지토리만 활성화합니다. 추가 리포지토리를 사용하면 패키지와 소프트웨어가 충돌할 수 있습니다. 추가 리포지토리를 활성화하지 마십시오.

  6. 시스템을 업데이트하여 기본 시스템 패키지를 최신 상태로 유지합니다.

    [root@controller ~]# sudo yum update -y
    [root@controller ~]# sudo reboot

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

8.3. Director에 대한 SSL/TLS 액세스 구성

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

  1. 인증 기관 파일을 사전 프로비저닝된 각 노드의 /etc/pki/ca-trust/source/anchors/ 디렉터리에 복사합니다.
  2. 각 오버클라우드 노드에서 다음 명령을 실행합니다.

    [root@controller ~]#  sudo update-ca-trust extract

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

8.4. 컨트롤 플레인에 대한 네트워킹 구성

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

  • director의 컨트롤 플레인 네트워크. undercloud.conf 파일의 network_cidr 매개 변수로 정의된 서브넷입니다. 노드에는 이 서브넷에 대한 직접 액세스 권한이나 서브넷으로 라우팅 가능한 액세스 권한이 필요합니다.
  • director의 공용 API 엔드포인트. undercloud.conf 파일의 undercloud_public_host 매개 변수로 지정되어 있습니다. 이 옵션은 컨트롤 플레인에 대한 L3 경로가 없거나, SSL/TLS 통신을 사용하려는 경우 사용할 수 있습니다. 공용 API 엔드포인트를 사용하도록 오버클라우드 노드를 구성하는 추가 설정 단계는 8.5절. “오버클라우드 노드에 별도의 네트워크 사용”을 참조하십시오.

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

네트워크 분리 사용

네트워크를 분리하여 컨트롤 플레인을 포함한 특정 네트워크를 사용하도록 서비스를 그룹화할 수 있습니다. Advanced Overcloud Customization 가이드에 여러 네트워크 분리 방법이 나와 있습니다. 또한 컨트롤 플레인에서 노드에 특정 IP 주소를 정의할 수 있습니다. 네트워크 분리 및 예측 가능한 노드 배치 방법에 대한 자세한 내용은 Advanced Overcloud Customization 가이드에 있는 다음 섹션을 참조하십시오.

참고

네트워크 분리를 사용하는 경우 NIC 템플릿에 언더클라우드 액세스에 사용된 NIC가 포함되지 않도록 하십시오. 이러한 템플릿은 NIC를 재구성할 수 있으며, 이로 인해 배포 중에 연결 및 구성 문제가 발생할 수 있습니다.

IP 주소 할당

네트워크 분리를 사용하지 않는 경우 단일 컨트롤 플레인 네트워크를 사용하여 모든 서비스를 관리할 수 있습니다. 이렇게 하려면 컨트롤 플레인 네트워크 범위 내에 있는 IP 주소를 사용하도록 각 노드에서 컨트롤 플레인 NIC를 수동으로 구성해야 합니다. director의 프로비저닝 네트워크를 컨트롤 플레인으로 사용하는 경우 선택한 오버클라우드 IP 주소가 프로비저닝(dhcp_startdhcp_end)과 인트로스펙션 (inspection_iprange)에 대한 DHCP 범위를 벗어나지 않는지 확인합니다.

표준 오버클라우드 생성 중에 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을 정의합니다. 매핑은 다음을 정의합니다.

  1. 할당 이름은 <node_hostname>-<network> 포맷을 따릅니다. 예: controller-ctlplane, compute-ctlplane
  2. IP 할당 - 다음 매개 변수 패턴을 사용합니다.

    • fixed_ips/ip_address - 컨트롤 플레인의 고정 IP 주소를 정의합니다. 목록에 여러 개의 ip_address 매개 변수를 사용하여 여러 IP 주소를 정의합니다.
    • subnets/cidr - 서브넷의 CIDR 값을 정의합니다.

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

8.5. 오버클라우드 노드에 별도의 네트워크 사용

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

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

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

표 8.2. 프로비저닝 네트워크 IP 할당

노드 이름IP 주소 또는 FQDN

Director(내부 API)

192.168.24.1(프로비저닝 네트워크 및 컨트롤 플레인)

Director(공용 API)

10.1.1.1 / director.example.com

오버클라우드 가상 IP

192.168.100.1

Controller

192.168.100.2

Compute

192.168.100.3

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

IP 주소 할당

IP 할당 방법은 8.4절. “컨트롤 플레인에 대한 네트워킹 구성”과 비슷합니다. 하지만 컨트롤 플레인은 배포된 서버에서 라우팅되지 않으므로 컨트롤 플레인에 액세스할 가상 IP 주소를 포함하여 선택한 오버클라우드 노드 서브넷에서 IP 주소를 할당할 때 DeployedServerPortMap 매개 변수를 사용합니다. 다음은 8.4절. “컨트롤 플레인에 대한 네트워킹 구성”ctlplane-assignments.yaml 환경 파일에 대한 수정된 버전으로 이 네트워크 아키텍처를 사용합니다.

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
1
RedisVipPort 리소스는 network/ports/noop.yaml에 매핑됩니다. 이 매핑은 기본 Redis VIP 주소가 컨트롤 플레인에서 만들어졌기 때문입니다. 이 경우 noop를 사용하여 이 컨트롤 플레인 매핑을 비활성화합니다.
2
EC2MetadataIpControlPlaneDefaultRoute 매개 변수는 컨트롤 플레인 가상 IP 주소 값으로 설정됩니다. 기본 NIC 구성 템플릿에는 이러한 매개 변수가 필요하므로 ping할 수 있는 IP 주소를 사용하여 배포 중에 수행된 검증을 전달하도록 설정해야 합니다. 또는 이러한 매개 변수가 필요하지 않도록 NIC 구성을 사용자 정의합니다.

8.6. 사전 프로비저닝된 노드 호스트 이름 매핑

사전 프로비저닝된 노드를 구성할 때 ansible-playbook이 확인 가능한 호스트에 도달할 수 있도록 Heat 기반 호스트 이름을 실제 호스트 이름에 매핑해야 합니다. HostnameMap을 사용하여 이러한 값을 매핑할 수 있습니다.

절차

  1. 환경 파일(예: hostname-map.yaml)을 생성하고 HostnameMap 매개 변수와 호스트 이름 매핑을 추가합니다. 다음 구문을 사용하십시오.

    parameter_defaults:
      HostnameMap:
        [HEAT HOSTNAME]: [ACTUAL HOSTNAME]
        [HEAT HOSTNAME]: [ACTUAL HOSTNAME]

    [HEAT HOSTNAME]은 항상 [STACK NAME]-[ROLE]-[INDEX] 규칙을 사용합니다. 예시는 다음과 같습니다.

    parameter_defaults:
      HostnameMap:
        overcloud-controller-0: controller-00-rack01
        overcloud-controller-1: controller-01-rack02
        overcloud-controller-2: controller-02-rack03
        overcloud-compute-0: compute-00-rack01
        overcloud-compute-1: compute-01-rack01
        overcloud-compute-2: compute-02-rack01
  2. hostname-map.yaml의 콘텐츠를 저장합니다.

8.7. 사전 프로비저닝된 노드로 오버클라우드 생성

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

  • --disable-validations - 사전 프로비저닝된 인프라에 사용되지 않는 서비스에 대한 기본 CLI 검증을 비활성화합니다. 그러지 않으면 배포에 실패합니다.
  • environments/deployed-server-environment.yaml - 사전 프로비저닝된 인프라를 생성 및 구성하는 기본 환경 파일입니다. 이 환경 파일은 OS::Nova::Server 리소스를 OS::Heat::DeployedServer 리소스로 대체합니다.
  • environments/deployed-server-bootstrap-environment-rhel.yaml - 사전 프로비저닝된 서버에서 부트스트랩 스크립트를 실행할 환경 파일입니다. 이 스크립트는 추가 패키지를 설치하고 오버클라우드 노드에 기본 구성을 제공합니다.
  • environments/deployed-server-pacemaker-environment.yaml - 사전 프로비저닝된 Controller 노드의 Pacemaker 구성에 대한 환경 파일입니다. 이 파일에 등록된 리소스에 대한 네임스페이스는 deployed-server/deployed-server-roles-data.yaml의 Controller 역할 이름을 사용하며, 기본값은 ControllerDeployedServer입니다.
  • deployed-server/deployed-server-roles-data.yaml - 사용자 정의 역할에 대한 예제 파일입니다. 이 파일은 기본 roles_data.yaml을 복제 배포하지만, 각 역할에 대해 disable_constraints: True 매개 변수를 포함하기도 합니다. 이 매개 변수는 생성된 역할 템플릿에서 오케스트레이션 제약 조건을 비활성화합니다. 이러한 제약 조건은 사전 프로비저닝된 인프라에 사용되지 않은 서비스에 대한 것입니다.

    고유한 사용자 정의 역할 파일을 사용하는 경우 disable_constraints: True 매개 변수를 각 역할과 함께 포함해야 합니다. 예를 들면 다음과 같습니다.

    - name: ControllerDeployedServer
      disable_constraints: True
      CountDefault: 1
      ServicesDefault:
        - OS::TripleO::Services::CACerts
        - OS::TripleO::Services::CephMon
        - OS::TripleO::Services::CephExternal
        - OS::TripleO::Services::CephRgw
        ...

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

$ source ~/stackrc
(undercloud) $ 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 \
  -e /home/stack/templates/hostname-map.yaml /
  -r /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-server-roles-data.yaml
  --overcloud-ssh-user stack \
  --overcloud-ssh-key ~/.ssh/id_rsa \
  [OTHER OPTIONS]

--overcloud-ssh-user--overcloud-ssh-key 옵션은 구성 단계 중 각 오버클라우드 노드에 SSH 사용, 초기 tripleo-admin 사용자 생성 및 SSH 키를 /home/tripleo-admin/.ssh/authorized_keys에 삽입하는 데 사용됩니다. SSH 키를 삽입하기 위해 사용자가 --overcloud-ssh-user--overcloud-ssh-key(~/.ssh/id_rsa로 기본 설정)을 사용하여 초기 SSH 연결에 대한 자격 증명을 지정합니다. --overcloud-ssh-key로 지정된 개인 키에 대한 노출을 제한하기 위해 director는 Heat 또는 Mistral과 같은 모든 API 서비스에 이 키를 전달하지 않으며 director의 openstack overcloud deploy 명령만 이 키를 사용하여 tripleo-admin 사용자에 대한 액세스를 활성화합니다.

8.8. 오버클라우드 배포 출력

오버클라우드 생성이 완료되면 오버클라우드를 설정하기 위해 Ansible 플레이 개요가 director에서 제공됩니다.

PLAY RECAP *************************************************************
overcloud-compute-0     : ok=160  changed=67   unreachable=0    failed=0
overcloud-controller-0  : ok=210  changed=93   unreachable=0    failed=0
undercloud              : ok=10   changed=7    unreachable=0    failed=0

Tuesday 15 October 2018  18:30:57 +1000 (0:00:00.107) 1:06:37.514 ******
========================================================================

director는 또한 오버클라우드 액세스에 필요한 세부 정보도 제공합니다.

Ansible passed.
Overcloud configuration completed.
Overcloud Endpoint: http://192.168.24.113:5000
Overcloud Horizon Dashboard URL: http://192.168.24.113:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed

8.9. 오버클라우드 액세스

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

(undercloud) $ source ~/overcloudrc

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

(overcloud) $

director 호스트와의 상호 작용으로 돌아가려면 다음 명령을 실행합니다.

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

8.10. 사전 프로비저닝된 노드 확장

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

사전 프로비저닝된 노드 확장

사전 프로비저닝된 노드가 있는 오버클라우드를 확장할 때 각 노드에서 director의 노드 수에 해당하도록 오케스트레이션 에이전트를 구성해야 합니다.

사전 프로비저닝된 노드를 확장하는 일반 프로세스는 다음과 같습니다.

  1. 요구 사항에 따라 사전 프로비저닝된 새 노드를 준비합니다.
  2. 노드를 확장합니다. 해당 지침은 11장. 오버클라우드 노드 확장을 참조하십시오.
  3. 배포 명령을 실행한 후 director가 새 노드 리소스를 생성하고 설정을 시작할 때까지 기다립니다.

사전 프로비저닝된 노드 축소

사전 프로비저닝된 노드가 있는 오버클라우드를 축소하는 경우 11장. 오버클라우드 노드 확장에 표시된 대로 축소 지침을 따릅니다.

대부분의 확장 작업에서 노드의 UUID 값을 가져와 openstack overcloud node delete에 전달해야 합니다. 해당 UUID를 가져오기 위해 특정 역할에 대한 리소스를 나열합니다.

$ openstack stack resource list overcloud -c physical_resource_id -c stack_name -n5 --filter type=OS::TripleO::<RoleName>Server

위 명령에서 <RoleName>을 축소할 역할의 실제 이름으로 바꿉니다. 예를 들어 ComputeDeployedServer의 경우 다음과 같습니다.

$ openstack stack resource list overcloud -c physical_resource_id -c stack_name -n5 --filter type=OS::TripleO::ComputeDeployedServerServer

명령 출력에 있는 stack_name 열은 각 노드와 연결된 UUID를 확인하는 데 사용됩니다. 다음의 예제 출력에서와 같이 stack_name에는 Heat 리소스 그룹에 있는 노드의 인덱스 정수 값이 포함됩니다.

+------------------------------------+----------------------------------+
| physical_resource_id               | stack_name                       |
+------------------------------------+----------------------------------+
| 294d4e4d-66a6-4e4e-9a8b-           | overcloud-ComputeDeployedServer- |
| 03ec80beda41                       | no7yfgnh3z7e-1-ytfqdeclwvcg      |
| d8de016d-                          | overcloud-ComputeDeployedServer- |
| 8ff9-4f29-bc63-21884619abe5        | no7yfgnh3z7e-0-p4vb3meacxwn      |
| 8c59f7b1-2675-42a9-ae2c-           | overcloud-ComputeDeployedServer- |
| 2de4a066f2a9                       | no7yfgnh3z7e-2-mmmaayxqnf3o      |
+------------------------------------+----------------------------------+

stack_name 열의 인덱스 0, 1 또는 2는 Heat 리소스 그룹의 노드 순서에 해당합니다. physical_resource_id 열의 해당 UUID 값을 openstack overcloud node delete 명령에 전달하십시오.

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

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

참고

먼저 새로운 기본 운영 체제로 다시 프로비저닝하지 않고 오버클라우드에서 이전에 제거된 노드를 재사용하지 마십시오. 축소 프로세스는 오버클라우드 스택에서 노드를 제거만 하고 패키지를 제거하지는 않습니다.

8.11. 사전 프로비저닝된 오버클라우드 제거

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

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

참고

먼저 새로운 기본 운영 체제로 다시 프로비저닝하지 않고 오버클라우드에서 이전에 제거된 노드를 재사용하지 마십시오. 제거 프로세스는 오버클라우드 스택만 삭제하고 패키지를 제거하지는 않습니다.

8.12. 오버클라우드 생성 완료

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


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