Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

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

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

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

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

중요

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

요구 사항

  • 4장. 언더클라우드 설치에서 생성한 director 노드
  • 노드의 베어 메탈 머신 그룹이 필요합니다. 필요한 노드 수는 생성하려는 오버클라우드 유형에 따라 다릅니다 (오버클라우드 역할에 대한 자세한 내용은 3.1절. “노드 배포 역할 플래닝” 참조). 이러한 머신은 각 노드 유형에 설정된 요구 사항을 지켜야 합니다. 요구 사항에 대한 자세한 내용은 2.4절. “오버클라우드 요구 사항”을 참조하십시오. 노드에는 Red Hat Enterprise Linux의 최신 마이너 버전 운영 체제가 필요합니다.
  • 사전 프로비저닝된 노드를 관리하기 위한 하나의 네트워크 연결. 이 시나리오를 수행하려면 오케스트레이션 에이전트 구성을 위해 노드에 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.6절. “오버클라우드 노드에 별도의 네트워크 사용”에서 나중에 검토합니다.
  • 이 예에 있는 다른 모든 네트워크 유형에서도 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 13에 대한 인타이틀먼트 풀을 검색합니다.

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

    [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-13-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-13-for-power-le-rpms
    중요

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

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

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

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

8.3. 노드에 사용자 에이전트 설치

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

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

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

8.4. 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.5. 컨트롤 플레인에 대한 네트워킹 구성

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

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

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.6. 오버클라우드 노드에 별도의 네트워크 사용

기본적으로 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

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

오케스트레이션 구성

director는 언더클라우드에서 SSL/TLS 통신을 활성화한 상태에서 대부분의 서비스에 공용 API 엔드포인트를 제공합니다. 하지만 OpenStack Orchestration(heat)은 내부 엔드포인트를 메타데이터에 대한 기본 공급자로 사용합니다. 따라서 오버클라우드 노드에서 공용 엔드포인트의 OpenStack Orchestration에 액세스할 수 있도록 언더클라우드에서 몇 가지를 수정해야 합니다. 이러한 수정에는 director에서의 일부 Puppet hieradata 변경이 포함됩니다.

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

  1. hieradata_override 파일을 아직 사용 중이 아닌 경우 새로 생성합니다. 이 예에서는 /home/stack/hieradata.yaml에 있는 파일을 사용합니다.
  2. 다음 hieradata를 /home/stack/hieradata.yaml에 포함합니다.

    heat_clients_endpoint_type: public
    heat::engine::default_deployment_signal_transport: TEMP_URL_SIGNAL

    이렇게 하면 엔드포인트 유형이 기본 internal에서 public으로 변경되고, 신호 전달 방법이 OpenStack Object Storage(swift)에서 TempURL을 사용하도록 변경됩니다.

  3. undercloud.conf에서 hieradata_override 매개 변수를 hieradata 파일의 경로로 설정합니다.

    hieradata_override = /home/stack/hieradata.yaml
  4. openstack overcloud install 명령을 다시 실행하여 새 구성 옵션을 구현합니다.

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

IP 주소 할당

IP 할당 방법은 8.5절. “컨트롤 플레인에 대한 네트워킹 구성”과 비슷합니다. 하지만 컨트롤 플레인은 배포된 서버에서 라우팅되지 않으므로 컨트롤 플레인에 액세스할 가상 IP 주소를 포함하여 선택한 오버클라우드 노드 서브넷에서 IP 주소를 할당할 때 DeployedServerPortMap 매개 변수를 사용합니다. 다음은 8.5절. “컨트롤 플레인에 대한 네트워킹 구성”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.7. 사전 프로비저닝된 노드로 오버클라우드 생성

오버클라우드 배포에는 6.7절. “CLI 툴로 오버클라우드 생성”의 표준 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 \
  -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가 오버클라우드 노드에서 오케스트레이션 에이전트가 메타데이터 서버를 폴링할 때까지 기다리기 때문에 발생합니다. 다음 섹션에는 메타데이터 서버 폴링을 시작할 노드를 구성하는 방법이 나와 있습니다.

8.8. 메타데이터 서버 폴링

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

중요

초기 배포에는 자동 구성만 사용하십시오. 노드를 확장하는 경우 자동 구성을 사용하지 마십시오.

자동 설정

director의 핵심 Heat 템플릿 컬렉션에는 오버클라우드 노드에서 Heat 에이전트의 자동 설정을 수행하는 스크립트가 포함되어 있습니다. 이 스크립트를 사용하려면 stack 사용자로 stackrc 파일을 소싱하여 director에서 인증하고 오케스트레이션 서비스에 쿼리해야 합니다.

[stack@director ~]$ source ~/stackrc

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

OVERCLOUD_ROLES
공백으로 구분된 구성할 역할 목록입니다. 이러한 역할은 역할 데이터 파일에 정의된 역할과 연관됩니다.
[ROLE]_hosts
각 역할에는 역할의 노드에 대해 공백으로 구분된 IP 주소 목록과 함께 환경 변수가 필요합니다.

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

(undercloud) $ export OVERCLOUD_ROLES="ControllerDeployedServer ComputeDeployedServer"
(undercloud) $ export ControllerDeployedServer_hosts="192.168.100.2"
(undercloud) $ export ComputeDeployedServer_hosts="192.168.100.3"

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

(undercloud) $ /usr/share/openstack-tripleo-heat-templates/deployed-server/scripts/get-occ-config.sh
참고

이 스크립트는 스크립트를 실행하는 동일한 사용자를 사용하여 SSH를 통해 사전 프로비저닝된 노드에 액세스합니다. 이 경우 스크립트는 stack 사용자로 인증합니다.

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

  • director의 오케스트레이션 서비스에서 각 노드에 대한 메타데이터 URL을 조회합니다.
  • 노드에 액세스하고 특정 메타데이터 URL로 각 노드의 에이전트를 구성합니다.
  • 오케스트레이션 에이전트 서비스를 다시 시작합니다.

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

수동 구성

사전 프로비저닝된 노드에서 오케스트레이션 에이전트를 수동으로 구성하려는 경우 다음 명령을 사용하여 director의 오케스트레이션 서비스에서 각 노드의 메타데이터 URL을 조회합니다.

[stack@director ~]$ source ~/stackrc
(undercloud) $ 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

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

  1. 기존 os-collect-config.conf 템플릿을 제거합니다. 이렇게 하면 에이전트가 수동 변경 사항을 덮어쓰지 않습니다.

    $ sudo /bin/rm -f /usr/libexec/os-apply-config/templates/etc/os-collect-config.conf
  2. 해당 메타데이터 URL을 사용하도록 /etc/os-collect-config.conf 파일을 구성합니다. 예를 들면 Controller 노드에서 다음을 사용합니다.

    [DEFAULT]
    collectors=request
    command=os-refresh-config
    polling_interval=30
    
    [request]
    metadata_url=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
  3. 파일을 저장합니다.
  4. os-collect-config 서비스를 다시 시작합니다.

    [stack@controller ~]$ sudo systemctl restart os-collect-config

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

8.9. 오버클라우드 생성 모니터링

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

[stack@director ~]$ source ~/stackrc
(undercloud) $ heat stack-list --show-nested

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

8.10. 오버클라우드 액세스

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

(undercloud) $ source ~/overcloudrc

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

(overcloud) $

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

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

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

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

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

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

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

  1. 요구 사항에 따라 사전 프로비저닝된 새 노드를 준비합니다.
  2. 노드를 확장합니다. 이러한 지침에 대해서는 11장. 오버클라우드 확장을 참조하십시오.
  3. 배포 명령을 실행한 후 director가 새 노드 리소스를 생성할 때까지 기다립니다. 8.8절. “메타데이터 서버 폴링”의 지침에 따라 director의 오케스트레이션 서버 메타데이터 URL을 폴링하도록 사전 프로비저닝된 노드를 수동으로 구성합니다.

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

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

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

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

참고

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

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

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

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

참고

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

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

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