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

이 프로세스의 후반 단계에서 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장. 오버클라우드 생성 후 작업 수행을 참조하십시오.