director는 HOT(Heat Orchestration Templates)를 Overcloud 배포 계획의 템플릿 형식으로 사용합니다. DestinationRule 형식의 템플릿은 대부분 YAML 형식으로 표시됩니다. 템플릿의 목적은 heat가 생성하는 리소스 컬렉션 및 리소스 구성인 스택 을 정의하고 생성하는 것입니다. 리소스는 OpenStack의 오브젝트이며 컴퓨팅 리소스, 네트워크 구성, 보안 그룹, 스케일링 규칙 및 사용자 정의 리소스를 포함할 수 있습니다.

Heat 템플릿의 구조에는 세 가지 주요 섹션이 있습니다.

다음은 기본 heat 템플릿의 예입니다.

heat_template_version: 2013-05-23

description: > A very basic Heat template.

parameters:
  key_name:
    type: string
    default: lars
    description: Name of an existing key pair to use for the instance
  flavor:
    type: string
    description: Instance type for the instance to be created
    default: m1.small
  image:
    type: string
    default: cirros
    description: ID or name of the image to use for the instance

resources:
  my_instance:
    type: OS::Nova::Server
    properties:
      name: My Cirros Instance
      image: { get_param: image }
      flavor: { get_param: flavor }
      key_name: { get_param: key_name }

output:
  instance_name:
    description: Get the instance's name
    value: { get_attr: [ my_instance, name ] }

이 템플릿은 리소스 유형인 OS::Nova::Server 를 사용하여 특정 플레이버, 이미지 및 키가 있는 my_instance 라는 인스턴스를 생성합니다. 스택은 My Cirros Instance 라고 하는 instance_name 의 값을 반환할 수 있습니다.

Heat에서 템플릿을 처리할 때 템플릿의 스택과 리소스 템플릿의 하위 스택 세트를 생성합니다. 이렇게 하면 템플릿으로 정의한 기본 스택에서 종료되는 스택 계층이 생성됩니다. 다음 명령을 사용하여 스택 계층을 볼 수 있습니다.

$ openstack stack list --nested

환경 파일은 Heat 템플릿에 대한 사용자 지정을 제공하는 특수한 유형의 템플릿입니다. 여기에는 세 가지 주요 부분이 포함됩니다.

기본 환경 파일의 예는 다음과 같습니다.

resource_registry:
  OS::Nova::Server::MyServer: myserver.yaml

parameter_defaults:
  NetworkName: my_network

parameters:
  MyIP: 192.168.0.1

예를 들어 특정 Heat 템플릿(my_template.yaml)에서 스택을 생성할 때 이 환경 파일(my_env.yaml)이 포함될 수 있습니다. my_env.yaml 파일은 OS::Nova::Server::MyServer 라는 새 리소스 유형을 생성합니다. myserver.yaml 파일은 기본 제공 파일을 덮어쓰는 이 리소스 유형에 대한 구현을 제공하는 Heat 템플릿 파일입니다. OS::Nova::Server::MyServer 리소스를 my_template.yaml 파일에 포함할 수 있습니다.

MyIP 는 이 환경 파일과 함께 배포하는 기본 Heat 템플릿에만 매개변수를 적용합니다. 이 예제에서는 my_template.yaml 의 매개변수에만 적용됩니다.

NetworkName 은 기본 Heat 템플릿(이 예제에서는 my_template.yaml)과 기본 템플릿이 포함된 리소스와 관련된 템플릿(예: OS::Nova::Server::MyServer 리소스 및 myserver.yaml 템플릿)에 모두 적용됩니다.

director에는 Overcloud의 핵심 heat 템플릿 컬렉션이 포함되어 있습니다. 이 컬렉션은 /usr/share/openstack-tripleo-heat-templates 에 저장됩니다.

이 컬렉션에는 많은 heat 템플릿과 환경 파일이 있습니다. 그러나 이 템플릿 컬렉션에서 유의해야 할 주요 파일과 디렉터리는 다음과 같습니다.

배포 명령(openstack overcloud deploy)은 -e 옵션을 사용하여 환경 파일을 포함하여 Overcloud를 사용자 지정합니다. 환경 파일은 필요한 수만큼 추가할 수 있습니다. 차후에 실행되는 환경 파일에 정의된 매개변수와 리소스가 우선순위를 갖기 때문에 환경 파일의 순서가 중요합니다. 예를 들어 두 개의 환경 파일이 있을 수 있습니다.

resource_registry:
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/template-1.yaml

parameter_defaults:
  RabbitFDLimit: 65536
  TimeZone: 'Japan'

resource_registry:
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/template-2.yaml

parameter_defaults:
  TimeZone: 'Hongkong'

그런 다음 포함된 두 환경 파일을 모두 사용하여 배포합니다.

$ openstack overcloud deploy --templates -e environment-file-1.yaml -e environment-file-2.yaml

이 예제에서는 두 환경 파일에 공통 리소스 유형(OS::TripleO::NodeExtraConfigPost)과 공통 매개변수(TimeZone)가 포함되어 있습니다. openstack overcloud deploy 명령은 다음 프로세스를 통해 실행됩니다.

그러면 Overcloud의 기본 구성이 다음과 같이 변경됩니다.

이를 통해 여러 환경 파일의 값 없이 Overcloud에 대한 사용자 지정 구성을 정의할 수 있습니다.

오버클라우드를 생성할 때 director는 /usr/share/openstack-tripleo-heat-templates 에 있는 코어 Heat 템플릿 세트를 사용합니다. 이 핵심 템플릿 컬렉션을 사용자 정의하려면 Git 워크플로를 사용하여 변경 사항을 추적하고 업데이트를 병합합니다. 다음 git 프로세스를 사용하여 사용자 정의 템플릿 컬렉션을 관리할 수 있습니다.

이렇게 하면 최신 코어 템플릿 컬렉션이 포함된 초기 마스터 분기가 생성됩니다. 이 분기를 사용자 정의 분기의 기준으로 사용하고 새 템플릿 버전을 이 분기에 병합합니다.

이렇게 하면 커밋으로 변경 사항이 my-customizations 분기에 추가됩니다. 마스터 분기가 업데이트되면 마스터 사용자 지정을 다시 기반으로 하여 git이 업데이트된 템플릿 컬렉션에 이러한 커밋을 추가할 수 있습니다. 이를 통해 사용자 정의를 추적하고 향후 템플릿 업데이트에서 재생하는 데 도움이 됩니다.

이제 master 분기에 코어 템플릿 컬렉션의 최신 버전이 포함됩니다. 이제 이 업데이트된 컬렉션에서 my-customization 분기를 리베이스할 수 있습니다.

이렇게 하면 my-customizations 분기가 업데이트되고 이 분기에 수행된 사용자 지정 커밋이 재생됩니다.

리베이스 중 git에서 충돌을 보고하는 경우 다음 절차를 사용하십시오.

시간대(puppet/services/time/timezone.yaml)를 설정하는 Heat 템플릿에는 TimeZone 매개변수가 포함되어 있습니다. TimeZone 매개변수를 비워 두면 오버클라우드는 시간을 기본값으로 UTC 로 설정합니다. director는 시간대 데이터베이스 /usr/share/zoneinfo/ 에 정의된 표준 시간대 이름을 인식합니다. 예를 들어 시간대를 Japan 으로 설정하려면 /usr/share/zoneinfo 의 내용을 검사하여 적절한 항목을 찾습니다.

$ ls /usr/share/zoneinfo/
Africa      Asia       Canada   Cuba   EST      GB       GMT-0      HST      iso3166.tab  Kwajalein  MST      NZ-CHAT   posix       right      Turkey     UTC       Zulu
America     Atlantic   CET      EET    EST5EDT  GB-Eire  GMT+0      Iceland  Israel       Libya      MST7MDT  Pacific   posixrules  ROC        UCT        WET
Antarctica  Australia  Chile    Egypt  Etc      GMT      Greenwich  Indian   Jamaica      MET        Navajo   Poland    PRC         ROK        Universal  W-SU
Arctic      Brazil     CST6CDT  Eire   Europe   GMT0     Hongkong   Iran     Japan        Mexico     NZ       Portugal  PST8PDT     Singapore  US         zone.tab

위에 나열된 출력에는 표준 시간대 파일과 추가 표준 시간대 파일이 포함된 디렉터리가 포함됩니다. 예를 들어, 일본은 이 결과에서 개별 표준 시간대 파일이지만 아프리카 는 추가 표준 시간대 파일이 포함된 디렉토리입니다.

$ ls /usr/share/zoneinfo/Africa/
Abidjan      Algiers  Bamako  Bissau       Bujumbura   Ceuta    Dar_es_Salaam  El_Aaiun  Harare        Kampala   Kinshasa    Lome        Lusaka  Maseru     Monrovia  Niamey       Porto-Novo  Tripoli
Accra        Asmara   Bangui  Blantyre     Cairo       Conakry  Djibouti       Freetown  Johannesburg  Khartoum  Lagos       Luanda      Malabo  Mbabane    Nairobi   Nouakchott   Sao_Tome    Tunis
Addis_Ababa  Asmera   Banjul  Brazzaville  Casablanca  Dakar    Douala         Gaborone  Juba          Kigali    Libreville  Lubumbashi  Maputo  Mogadishu  Ndjamena  Ouagadougou  Timbuktu    Windhoek

환경 파일에 항목을 추가하여 시간대를 Japan 로 설정합니다.

parameter_defaults:
  TimeZone: 'Japan'

OpenStack Networking(neutron) API(puppet/services/neutron-api.yaml)에 대한 Heat 템플릿에는 3개의 고가용성(L3HA)을 활성화 및 비활성화하는 매개변수가 포함되어 있습니다. 매개변수의 기본값은 false 입니다. 그러나 환경 파일에서 다음을 사용하여 활성화할 수 있습니다.

parameter_defaults:
  NeutronL3HA: true

OpenStack Telemetry(ceilometer) 서비스에는 시계열 데이터 스토리지(gnocchi)를 위한 구성 요소가 포함되어 있습니다. puppet/services/ceilometer-base.yaml Heat 템플릿을 사용하면 gnocchi 와 표준 데이터베이스를 전환할 수 있습니다. 다음 중 하나로 설정하는 CeilometerMeterDispatcher 매개변수를 사용하여 이 작업을 수행합니다.

표준 데이터베이스로 전환하려면 환경 파일에 다음을 추가합니다.

parameter_defaults:
  CeilometerMeterDispatcher: database

특정 구성의 경우 RabbitMQ 서버의 파일 설명자 제한을 늘려야 할 수 있습니다. puppet/services/rabbitmq.yaml Heat 템플릿을 사용하면 RabbitFDLimit 매개변수를 필요한 제한으로 설정할 수 있습니다. 환경 파일에 다음을 추가합니다.

parameter_defaults:
  RabbitFDLimit: 65536

경우에 따라 배포 중에 매개변수를 처음 설정한 다음 업데이트 또는 확장 작업과 같은 향후 배포 작업에 대한 매개 변수를 비활성화해야 할 수 있습니다. 예를 들어 오버클라우드 생성 중에 사용자 지정 RPM을 포함하려면 다음이 포함됩니다.

parameter_defaults:
  DeployArtifactURLs: ["http://www.example.com/myfile.rpm"]

향후 배포에서 이 매개변수를 비활성화해야 하는 경우 매개변수를 제거하는 것만으로는 충분하지 않습니다. 대신 매개변수를 빈 값으로 설정합니다.

parameter_defaults:
  DeployArtifactURLs: []

이렇게 하면 후속 배포 작업에 매개변수가 더 이상 설정되지 않습니다.

Red Hat OpenStack Platform director는 설정에 필요한 많은 매개 변수를 제공합니다. 경우에 따라 설정할 특정 옵션과 해당 director 매개변수를 식별하는 데 어려움이 있을 수 있습니다. director를 통해 설정할 옵션이 있는 경우 다음 워크플로우를 사용하여 옵션을 확인하고 특정 오버클라우드 매개변수에 매핑합니다.

다음 표는 최종 매핑을 보여줍니다.

즉, 오버클라우드 환경 파일에서 KeystoneNotificationFormat 을 설정하면 오버클라우드 구성 중에 keystone.conf 파일에 notification_format 옵션이 설정됩니다.

director는 Overcloud 초기 생성 시 모든 노드에서 구성을 수행하는 메커니즘을 제공합니다. director는 OS::TripleO::NodeUserData 리소스 유형을 사용하여 호출할 수 있는 cloud-init 를 통해 이를 수행합니다.

이 예제에서는 모든 노드에서 사용자 지정 IP 주소로 네임서버를 업데이트합니다. 먼저 각 노드의 resolv.conf 를 특정 이름 서버에 추가하는 스크립트를 실행하는 기본 heat 템플릿(/home/stack/templates/nameserver.yaml)을 생성해야 합니다. OS::TripleO::MultipartMime 리소스 유형을 사용하여 구성 스크립트를 보낼 수 있습니다.

heat_template_version: 2014-10-16

description: >
  Extra hostname configuration

resources:
  userdata:
    type: OS::Heat::MultipartMime
    properties:
      parts:
      - config: {get_resource: nameserver_config}

  nameserver_config:
    type: OS::Heat::SoftwareConfig
    properties:
      config: |
        #!/bin/bash
        echo "nameserver 192.168.1.1" >> /etc/resolv.conf

outputs:
  OS::stack_id:
    value: {get_resource: userdata}

다음으로 heat 템플릿을 OS::TripleO::NodeUserData 리소스 유형으로 등록하는 환경 파일(/home/stack/templates/firstboot.yaml)을 생성합니다.

resource_registry:
  OS::TripleO::NodeUserData: /home/stack/templates/nameserver.yaml

첫 번째 부팅 구성을 추가하려면 Overcloud를 처음 생성할 때 다른 환경 파일과 함께 환경 파일을 스택에 추가합니다. 예를 들면 다음과 같습니다.

$ openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/firstboot.yaml \
    ...

-e 는 환경 파일을 Overcloud 스택에 적용합니다.

그러면 처음 생성되어 부팅될 때 모든 노드에 구성이 추가됩니다. Overcloud 스택 업데이트와 같은 이러한 템플릿에 대한 후속 포함은 이 스크립트를 실행하지 않습니다.

Overcloud는 OpenStack 구성 요소의 핵심 구성에 Puppet을 사용합니다. director는 첫 번째 부팅이 완료된 후 코어 구성이 시작되기 전에 특정 노드 역할에 사용자 정의 구성을 제공하는 후크 세트를 제공합니다. 이러한 후크에는 다음이 포함됩니다.

이 예제에서는 먼저 변수 이름 서버가 있는 노드의 resolv.conf 에 쓰는 스크립트를 실행하는 기본 heat 템플릿(/home/stack/templates/nameserver.yaml)을 생성합니다.

heat_template_version: 2014-10-16

description: >
  Extra hostname configuration

parameters:
  server:
    type: string
  nameserver_ip:
    type: string
  DeployIdentifier:
    type: string

resources:
  CustomExtraConfigPre:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template: |
            #!/bin/sh
            echo "nameserver _NAMESERVER_IP_" > /etc/resolv.conf
          params:
            _NAMESERVER_IP_: {get_param: nameserver_ip}

  CustomExtraDeploymentPre:
    type: OS::Heat::SoftwareDeployment
    properties:
      server: {get_param: server}
      config: {get_resource: CustomExtraConfigPre}
      actions: ['CREATE','UPDATE']
      input_values:
        deploy_identifier: {get_param: DeployIdentifier}

outputs:
  deploy_stdout:
    description: Deployment reference, used to trigger pre-deploy on changes
    value: {get_attr: [CustomExtraDeploymentPre, deploy_stdout]}

이 예제에서 resources 섹션에는 다음이 포함됩니다.

다음으로 heat 템플릿을 역할 기반 리소스 유형에 등록하는 환경 파일(/home/stack/templates/pre_config.yaml)을 생성합니다. 예를 들어 컨트롤러 노드에만 적용하려면 ControllerExtraConfigPre 후크를 사용합니다.

resource_registry:
  OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/nameserver.yaml

parameter_defaults:
  nameserver_ip: 192.168.1.1

설정을 적용하려면 Overcloud를 생성하거나 업데이트할 때 다른 환경 파일과 함께 환경 파일을 스택에 추가합니다. 예를 들면 다음과 같습니다.

$ openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/pre_config.yaml \
    ...

이는 코어 구성이 초기 Overcloud 생성 또는 후속 업데이트에서 시작되기 전에 모든 컨트롤러 노드에 적용됩니다.

Overcloud는 OpenStack 구성 요소의 핵심 구성에 Puppet을 사용합니다. director는 첫 번째 부팅 후 및 코어 구성이 시작되기 전에 모든 노드 유형을 구성하는 후크를 제공합니다.

이 예제에서는 먼저 스크립트를 실행하여 각 노드의 resolv.conf 를 변수 이름 서버에 추가하는 기본 heat 템플릿(/home/stack/templates/nameserver.yaml)을 생성합니다.

heat_template_version: 2014-10-16

description: >
  Extra hostname configuration

parameters:
  server:
    type: string
  nameserver_ip:
    type: string
  DeployIdentifier:
    type: string

resources:
  CustomExtraConfigPre:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template: |
            #!/bin/sh
            echo "nameserver _NAMESERVER_IP_" >> /etc/resolv.conf
          params:
            _NAMESERVER_IP_: {get_param: nameserver_ip}

  CustomExtraDeploymentPre:
    type: OS::Heat::SoftwareDeployment
    properties:
      server: {get_param: server}
      config: {get_resource: CustomExtraConfigPre}
      actions: ['CREATE','UPDATE']
      input_values:
        deploy_identifier: {get_param: DeployIdentifier}

outputs:
  deploy_stdout:
    description: Deployment reference, used to trigger pre-deploy on changes
    value: {get_attr: [CustomExtraDeploymentPre, deploy_stdout]}

이 예제에서 resources 섹션에는 다음이 포함됩니다.

다음으로 heat 템플릿을 OS::TripleO::NodeExtraConfig 리소스 유형으로 등록하는 환경 파일(/home/stack/templates/pre_config.yaml)을 생성합니다.

resource_registry:
  OS::TripleO::NodeExtraConfig: /home/stack/templates/nameserver.yaml

parameter_defaults:
  nameserver_ip: 192.168.1.1

설정을 적용하려면 Overcloud를 생성하거나 업데이트할 때 다른 환경 파일과 함께 환경 파일을 스택에 추가합니다. 예를 들면 다음과 같습니다.

$ openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/pre_config.yaml \
    ...

이는 코어 구성이 초기 Overcloud 생성 또는 후속 업데이트에서 시작되기 전에 모든 노드에 적용됩니다.

Overcloud 생성을 완료했지만 초기 생성 또는 Overcloud 후속 업데이트 시 모든 역할에 구성을 추가하려는 상황이 발생할 수 있습니다. 이 경우 다음과 같은 구성 후 후크를 사용합니다.

이 예제에서는 먼저 스크립트를 실행하여 각 노드의 resolv.conf 를 변수 이름 서버에 추가하는 기본 heat 템플릿(/home/stack/templates/nameserver.yaml)을 생성합니다.

heat_template_version: 2014-10-16

description: >
  Extra hostname configuration

parameters:
  servers:
    type: json
  nameserver_ip:
    type: string
  DeployIdentifier:
    type: string

resources:
  CustomExtraConfig:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template: |
            #!/bin/sh
            echo "nameserver _NAMESERVER_IP_" >> /etc/resolv.conf
          params:
            _NAMESERVER_IP_: {get_param: nameserver_ip}

  CustomExtraDeployments:
    type: OS::Heat::SoftwareDeploymentGroup
    properties:
      servers:  {get_param: servers}
      config: {get_resource: CustomExtraConfig}
      actions: ['CREATE','UPDATE']
      input_values:
        deploy_identifier: {get_param: DeployIdentifier}

이 예제에서 resources 섹션에는 다음이 포함됩니다.

다음으로 heat 템플릿을 OS::TripleO::NodeExtraConfigPost: 리소스 유형으로 등록하는 환경 파일(/home/stack/templates/post_config.yaml)을 생성합니다.

resource_registry:
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/nameserver.yaml

parameter_defaults:
  nameserver_ip: 192.168.1.1

설정을 적용하려면 Overcloud를 생성하거나 업데이트할 때 다른 환경 파일과 함께 환경 파일을 스택에 추가합니다. 예를 들면 다음과 같습니다.

$ openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/post_config.yaml \
    ...

이는 코어 구성이 초기 Overcloud 생성 또는 후속 업데이트에서 완료된 후 모든 노드에 적용됩니다.

Heat 템플릿 컬렉션에는 특정 노드 유형에 추가 구성을 전달하는 매개변수 세트가 포함되어 있습니다. 이러한 매개변수는 노드의 Puppet 구성에 대한 설정을 hieradata로 저장합니다. 이러한 매개변수는 다음과 같습니다.

배포 후 구성 프로세스에 구성을 추가하려면 parameter_defaults 섹션에 이러한 매개변수가 포함된 환경 파일을 생성합니다. 예를 들어 컴퓨팅 호스트의 예약된 메모리를 1024MB로 늘리고 VNC 키맵을 일본어로 설정하려면 다음을 수행합니다.

parameter_defaults:
  NovaComputeExtraConfig:
    nova::compute::reserved_host_memory: 1024
    nova::compute::vnc_keymap: ja

openstack overcloud deploy 를 실행하는 경우 이 환경 파일을 포함합니다.

Heat 템플릿 컬렉션을 사용하여 개별 노드에 대해 Puppet hieradata를 설정할 수 있습니다. 이를 수행하려면 노드의 인트로스펙션 데이터 일부로 저장된 시스템 UUID를 가져와야 합니다.

$ openstack baremetal introspection data save 9dcc87ae-4c6d-4ede-81a5-9b20d7dc4a14 | jq .extra.system.product.uuid

그러면 시스템 UUID가 출력됩니다. 예를 들면 다음과 같습니다.

"F5055C6C-477F-47FB-AFE5-95C6928C407F"

노드별 hieradata를 정의하는 환경 파일에서 이 시스템 UUID를 사용하고 per_node.yaml 템플릿을 사전 구성 후크에 등록합니다. 예를 들면 다음과 같습니다.

resource_registry:
  OS::TripleO::ComputeExtraConfigPre: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/per_node.yaml
parameter_defaults:
  NodeDataLookup: '{"F5055C6C-477F-47FB-AFE5-95C6928C407F": {"nova::compute::vcpu_pin_set": [ "2", "3" ]}}'

openstack overcloud deploy 를 실행하는 경우 이 환경 파일을 포함합니다.

per_node.yaml 템플릿은 각 시스템 UUID에 해당하는 노드에 heiradata 파일 세트를 생성하고 사용자가 정의한 hieradata를 포함합니다. UUID가 정의되지 않은 경우 결과 hieradata 파일이 비어 있습니다. 이전 예에서 per_node.yaml 템플릿은 OS::TripleO::ComputeExtraConfigPre 후크에 따라 모든 컴퓨팅 노드에서 실행되지만 시스템 UUID F5055C6C-477F-47FB-AFE5-9528C407F 가 hieradata를 수신하는 컴퓨팅 노드만 사용됩니다.

이를 통해 각 노드를 특정 요구 사항에 맞게 조정할 수 있습니다.

경우에 따라 Overcloud 노드에 일부 추가 구성 요소를 설치하고 구성해야 할 수 있습니다. 기본 구성이 완료된 후 노드에 적용되는 사용자 정의 Puppet 매니페스트를 사용하여 이를 수행할 수 있습니다. 기본 예로 각 노드에 motd 를 설치할 수 있습니다. 수행 프로세스는 먼저 Puppet 구성을 시작하는 Heat 템플릿(/home/stack/templates/custom_puppet_config.yaml)을 생성하는 것입니다.

heat_template_version: 2014-10-16

description: >
  Run Puppet extra configuration to set new MOTD

parameters:
  servers:
    type: json

resources:
  ExtraPuppetConfig:
    type: OS::Heat::SoftwareConfig
    properties:
      config: {get_file: motd.pp}
      group: puppet
      options:
        enable_hiera: True
        enable_facter: False

  ExtraPuppetDeployments:
    type: OS::Heat::SoftwareDeploymentGroup
    properties:
      config: {get_resource: ExtraPuppetConfig}
      servers: {get_param: servers}

여기에는 템플릿 내에 /home/stack/templates/motd.pp 가 포함되어 구성을 위해 노드에 전달합니다. motd.pp 파일 자체에는 motd 를 설치하고 구성하는 Puppet 클래스가 포함되어 있습니다.

다음으로 heat 템플릿을 OS::TripleO::NodeExtraConfigPost: 리소스 유형으로 등록하는 환경 파일(/home/stack/templates/puppet_post_config.yaml)을 생성합니다.

resource_registry:
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/custom_puppet_config.yaml

마지막으로 Overcloud 스택을 생성하거나 업데이트할 때 다른 환경 파일과 함께 이 환경 파일을 포함합니다.

$ openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/puppet_post_config.yaml \
    ...

이는 motd.pp 의 설정을 Overcloud의 모든 노드에 적용합니다.

Heat 템플릿 컬렉션에서 등록 파일을 복사합니다.

$ cp -r /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration ~/templates/.

~/templates/rhel-registration/environment-rhel-registration.yaml 을 편집하고 등록 방법 및 세부 정보에 맞게 다음 값을 수정합니다.

배포 명령(openstack overcloud deploy)은 -e 옵션을 사용하여 환경 파일을 추가합니다. ~/templates/rhel-registration/environment-rhel-registration.yaml 및 ~/templates/rhel-registration/rhel-registration-resource-registry.yaml 을 모두 추가합니다. 예를 들면 다음과 같습니다.

$ openstack overcloud deploy --templates [...] -e /home/stack/templates/rhel-registration/environment-rhel-registration.yaml -e /home/stack/templates/rhel-registration/rhel-registration-resource-registry.yaml

다음에서는 my-openstack 활성화 키를 사용하여 오버클라우드 노드를 Red Hat 고객 포털에 등록하고 1a85f9223e3d5e43013e3d6e8ff506fd 풀에 등록합니다.

parameter_defaults:
  rhel_reg_auto_attach: ""
  rhel_reg_activation_key: "my-openstack"
  rhel_reg_org: "1234567"
  rhel_reg_pool_id: "1a85f9223e3d5e43013e3d6e8ff506fd"
  rhel_reg_repos: "rhel-7-server-rpms,rhel-7-server-extras-rpms,rhel-7-server-rh-common-rpms,rhel-ha-for-rhel-7-server-rpms,rhel-7-server-openstack-10-rpms,rhel-7-server-rhceph-2-osd-rpms,rhel-7-server-rhceph-2-mon-rpms,rhel-7-server-rhceph-2-tools-rpms"
  rhel_reg_method: "portal"
  rhel_reg_sat_repo: ""
  rhel_reg_base_url: ""
  rhel_reg_environment: ""
  rhel_reg_force: ""
  rhel_reg_machine_name: ""
  rhel_reg_password: ""
  rhel_reg_release: "7.7"
  rhel_reg_sat_url: ""
  rhel_reg_server_url: ""
  rhel_reg_service_level: ""
  rhel_reg_user: ""
  rhel_reg_type: ""
  rhel_reg_http_proxy_host: ""
  rhel_reg_http_proxy_port: ""
  rhel_reg_http_proxy_username: ""
  rhel_reg_http_proxy_password: ""

다음에서는 overcloud 노드를 sat6.example.com의 Red Hat Satellite 6 Server에 등록하고 my-openstack 활성화 키를 사용하여 1a85f9223e3d5e43013e3d6e8ff506fd 풀에 등록합니다. 이 경우 활성화 키는 활성화할 리포지토리도 제공합니다.

parameter_defaults:
  rhel_reg_activation_key: "my-openstack"
  rhel_reg_org: "1"
  rhel_reg_pool_id: "1a85f9223e3d5e43013e3d6e8ff506fd"
  rhel_reg_method: "satellite"
  rhel_reg_sat_url: "http://sat6.example.com"
  rhel_reg_sat_repo: "rhel-7-server-satellite-tools-6.2-rpms"
  rhel_reg_repos: ""
  rhel_reg_auto_attach: ""
  rhel_reg_base_url: ""
  rhel_reg_environment: ""
  rhel_reg_force: ""
  rhel_reg_machine_name: ""
  rhel_reg_password: ""
  rhel_reg_release: "7.7"
  rhel_reg_server_url: ""
  rhel_reg_service_level: ""
  rhel_reg_user: ""
  rhel_reg_type: ""
  rhel_reg_http_proxy_host: ""
  rhel_reg_http_proxy_port: ""
  rhel_reg_http_proxy_username: ""
  rhel_reg_http_proxy_password: ""

다음에서는 overcloud 노드를 sat5.example.com의 Red Hat Satellite 5 Server에 등록하고 my-openstack 활성화 키를 사용하고 서브스크립션을 자동으로 연결합니다. 이 경우 활성화 키는 활성화할 리포지토리도 제공합니다.

parameter_defaults:
  rhel_reg_auto_attach: ""
  rhel_reg_activation_key: "my-openstack"
  rhel_reg_org: "1"
  rhel_reg_method: "satellite"
  rhel_reg_sat_url: "http://sat5.example.com"
  rhel_reg_repos: ""
  rhel_reg_base_url: ""
  rhel_reg_environment: ""
  rhel_reg_force: ""
  rhel_reg_machine_name: ""
  rhel_reg_password: ""
  rhel_reg_pool_id: ""
  rhel_reg_release: "7.7"
  rhel_reg_server_url: ""
  rhel_reg_service_level: ""
  rhel_reg_user: ""
  rhel_reg_type: ""
  rhel_reg_sat_repo: ""
  rhel_reg_http_proxy_host: ""
  rhel_reg_http_proxy_port: ""
  rhel_reg_http_proxy_username: ""
  rhel_reg_http_proxy_password: ""

Overcloud 생성 프로세스는 역할 데이터가 포함된 템플릿을 사용하여 역할을 정의합니다. 기본 템플릿은 /usr/share/openstack-tripleo-heat-templates/roles_data.yaml 에 있으며 Controller,Compute,BlockStorage,ObjectStorage, CephStorage 와 같은 모든 기본 역할 유형을 정의합니다.

각 역할에는 다음 매개변수가 포함되어 있습니다.

이러한 옵션은 새 역할을 생성하고 포함할 서비스를 정의하는 수단을 제공합니다.

openstack overcloud deploy 명령은 roles_data.yaml 파일의 매개변수를 overcloud.j2.yaml Heat 템플릿에 통합합니다. 특정 시점에서 overcloud.j2.yaml Heat 템플릿은 roles_data.yaml 에서 역할 목록을 반복하고 각 역할과 관련된 매개변수와 리소스를 생성합니다.

예를 들어 overcloud.j2.yaml Heat 템플릿의 각 역할에 대한 리소스 정의는 다음 스니펫으로 표시됩니다.

  {{role.name}}:
    type: OS::Heat::ResourceGroup
    depends_on: Networks
    properties:
      count: {get_param: {{role.name}}Count}
      removal_policies: {get_param: {{role.name}}RemovalPolicies}
      resource_def:
        type: OS::TripleO::{{role.name}}
        properties:
          CloudDomain: {get_param: CloudDomain}
          ServiceNetMap: {get_attr: [ServiceNetMap, service_net_map]}
          EndpointMap: {get_attr: [EndpointMap, endpoint_map]}
...

이 스니펫에서는 Jinja2 기반 템플릿이 {{role.name}} 변수를 통합하여 각 역할의 이름을 OS::Heat::ResourceGroup 리소스로 정의하는 방법을 보여줍니다. 차례로 roles_data.yaml 의 각 name 매개변수를 사용하여 각 OS::Heat::ResourceGroup 리소스의 이름을 지정합니다.

코어 Heat 템플릿 컬렉션에는 puppet/services 하위 디렉터리에 있는 구성 가능 서비스 템플릿 컬렉션이 포함되어 있습니다. 다음 명령을 사용하여 이러한 서비스를 볼 수 있습니다.

$ ls /usr/share/openstack-tripleo-heat-templates/puppet/services

각 서비스 템플릿에는 목적을 식별하는 설명이 포함되어 있습니다. 예를 들어 keystone.yaml 서비스 템플릿에는 다음 설명이 포함되어 있습니다.

description: >
 OpenStack Identity (`keystone`) service configured with Puppet

이러한 서비스 템플릿은 Red Hat OpenStack Platform 배포와 관련된 리소스로 등록됩니다. 즉, overcloud-resource-registry-puppet.j2.yaml 파일에 정의된 고유한 Heat 리소스 네임스페이스를 사용하여 각 리소스를 호출할 수 있습니다. 모든 서비스는 리소스 유형에 OS::TripleO::Services 네임스페이스를 사용합니다. 예를 들어 keystone.yaml 서비스 템플릿은 OS::TripleO::Services::Keystone 리소스 유형에 등록됩니다.

grep "OS::TripleO::Services::Keystone" /usr/share/openstack-tripleo-heat-templates/overcloud-resource-registry-puppet.j2.yaml
  OS::TripleO::Services::Keystone: puppet/services/keystone.yaml

overcloud.j2.yaml Heat 템플릿에는 roles_data.yaml 파일에서 각 사용자 지정 역할에 대한 서비스 목록을 정의하는 Jinja2 기반 코드의 섹션이 포함되어 있습니다.

{{role.name}}Services:
  description: A list of service resources (configured in the Heat
               resource_registry) which represent nested stacks
               for each service that should get installed on the {{role.name}} role.
  type: comma_delimited_list
  default: {{role.ServicesDefault|default([])}}

기본 역할의 경우 ControllerServices,ComputeServices,BlockStorageServices,ObjectStorageServices, CephStorageServices , CephStorageServices 등의 서비스 목록 매개변수가 생성됩니다.

roles_data.yaml 파일에서 각 사용자 지정 역할에 대한 기본 서비스를 정의합니다. 예를 들어 default Controller 역할에는 다음 내용이 포함됩니다.

- name: Controller
  CountDefault: 1
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephMon
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::CephRgw
    - OS::TripleO::Services::CinderApi
    - OS::TripleO::Services::CinderBackup
    - OS::TripleO::Services::CinderScheduler
    - OS::TripleO::Services::CinderVolume
    - OS::TripleO::Services::Core
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Keystone
    - OS::TripleO::Services::GlanceApi
    - OS::TripleO::Services::GlanceRegistry
...

그런 다음 이러한 서비스는 ControllerServices 매개변수의 기본 목록으로 정의됩니다.

환경 파일을 사용하여 서비스 매개변수의 기본 목록을 덮어쓸 수도 있습니다. 예를 들어, ControllerServices 를 환경 파일에서 parameter_default 로 정의하여 roles_data.yaml 파일의 서비스 목록을 덮어쓸 수 있습니다.

일부 서비스는 기본적으로 비활성화되어 있습니다. 이러한 서비스는 overcloud-resource-registry-puppet.j2.yaml 파일에 null 작업(OS::Heat::None)으로 등록됩니다. 예를 들어 Block Storage 백업 서비스(cinder-backup)는 비활성화되어 있습니다.

  OS::TripleO::Services::CinderBackup: OS::Heat::None

이 서비스를 활성화하려면 puppet/services 디렉터리에 있는 해당 Heat 템플릿에 리소스를 연결하는 환경 파일을 포함합니다. 일부 서비스에는 환경 디렉터리에 사전 정의된 환경 파일이 있습니다. 예를 들어 Block Storage 백업 서비스는 다음을 포함하는 environments/cinder-backup.yaml 파일을 사용합니다.

resource_registry:
  OS::TripleO::Services::CinderBackup: ../puppet/services/pacemaker/cinder-backup.yaml
...

이렇게 하면 기본 null 작업 리소스를 재정의하고 서비스를 활성화합니다. openstack overcloud deploy 명령을 실행할 때 이 환경 파일을 포함합니다.

$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml

서비스를 추가하거나 제거하는 기본 방법은 노드 역할에 대한 기본 서비스 목록의 사본을 생성한 다음 서비스를 추가하거나 제거해야 합니다. 예를 들어 컨트롤러 노드에서 OpenStack Orchestration(heat)을 제거하는 것이 좋습니다. 이 경우 기본 roles_data.yaml 파일의 사용자 정의 사본을 생성합니다.

$ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml ~/templates/roles_data-no_heat.yaml

roles_data 파일을 편집하고 컨트롤러의 ServicesDefault 매개변수에 대한 서비스 목록을 수정합니다. OpenStack Orchestration 서비스로 스크롤하여 삭제합니다.

    - OS::TripleO::Services::GlanceApi
    - OS::TripleO::Services::GlanceRegistry
    - OS::TripleO::Services::HeatApi            # Remove this service
    - OS::TripleO::Services::HeatApiCfn         # Remove this service
    - OS::TripleO::Services::HeatApiCloudwatch  # Remove this service
    - OS::TripleO::Services::HeatEngine         # Remove this service
    - OS::TripleO::Services::MySQL
    - OS::TripleO::Services::NeutronDhcpAgent

openstack overcloud deploy 명령을 실행할 때 이 새로운 roles_data 파일을 포함합니다. 예를 들면 다음과 같습니다.

$ openstack overcloud deploy --templates -r ~/templates/roles_data-no_heat.yaml

그러면 컨트롤러 노드에 OpenStack Orchestration 서비스가 설치되지 않은 Overcloud가 배포됩니다.

resource_registry:
  OS::TripleO::Services::HeatApi: OS::Heat::None
  OS::TripleO::Services::HeatApiCfn: OS::Heat::None
  OS::TripleO::Services::HeatApiCloudwatch: OS::Heat::None
  OS::TripleO::Services::HeatEngine: OS::Heat::None

이 예제에서 목표는 OpenStack Networking(중성자) 에이전트를 호스팅하는 새 Networker 역할을 생성하는 것입니다. 이 경우 새 역할 정보가 포함된 사용자 지정 roles_data 파일을 생성합니다.

기본 roles_data.yaml 파일의 사용자 정의 사본을 생성합니다.

$ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml ~/templates/roles_data-network_node.yaml

새 roles_data 파일을 편집하고 기본 및 핵심 OpenStack Networking 서비스가 포함된 새 Networker 역할을 만듭니다. 예를 들면 다음과 같습니다.

- name: Networker
  CountDefault: 1
  HostnameFormatDefault: '%stackname%-networker-%index%'
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::NeutronDhcpAgent
    - OS::TripleO::Services::NeutronL3Agent
    - OS::TripleO::Services::NeutronMetadataAgent
    - OS::TripleO::Services::NeutronOvsAgent
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::VipHosts

기본 Overcloud에 항상 Networking 노드가 포함되도록 CountDefault 를 1 로 설정하는 것도 좋습니다.

기존 오버클라우드에서 서비스를 스케일링하는 경우 기존 서비스를 Controller 역할에 유지합니다. 새 오버클라우드를 생성하고 OpenStack Networking 에이전트가 독립 실행형 역할만 유지하려면 Controller 역할 정의에서 OpenStack Networking 에이전트를 삭제합니다.

- name: Controller
  CountDefault: 1
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephMon
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::CephRgw
    - OS::TripleO::Services::CinderApi
    - OS::TripleO::Services::CinderBackup
    - OS::TripleO::Services::CinderScheduler
    - OS::TripleO::Services::CinderVolume
    - OS::TripleO::Services::Core
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Keystone
    - OS::TripleO::Services::GlanceApi
    - OS::TripleO::Services::GlanceRegistry
    - OS::TripleO::Services::HeatApi
    - OS::TripleO::Services::HeatApiCfn
    - OS::TripleO::Services::HeatApiCloudwatch
    - OS::TripleO::Services::HeatEngine
    - OS::TripleO::Services::MySQL
    - OS::TripleO::Services::NeutronDhcpAgent       # Remove this service
    - OS::TripleO::Services::NeutronL3Agent         # Remove this service
    - OS::TripleO::Services::NeutronMetadataAgent   # Remove this service
    - OS::TripleO::Services::NeutronApi
    - OS::TripleO::Services::NeutronCorePlugin
    - OS::TripleO::Services::NeutronOvsAgent        # Remove this service
    - OS::TripleO::Services::RabbitMQ
...

특정 노드에 태그를 지정할 수 있도록 이 역할에 새 플레이버를 정의해야 할 수 있습니다. 이 예제에서는 다음 명령을 사용하여 네트워크 플레이버를 생성합니다.

$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 networker
$ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="networker" networker

다음 명령을 사용하여 새 플레이버에 노드를 태그합니다.

$ openstack baremetal node set --property capabilities='profile:networker,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13

다음 환경 파일 스니펫을 사용하여 Networker 노드 수 및 플레이버를 정의합니다.

parameter_defaults:
  OvercloudNetworkerFlavor: networker
  NetworkerCount: 1

openstack overcloud deploy 명령을 실행할 때 새 roles_data 파일 및 환경 파일을 포함합니다. 예를 들면 다음과 같습니다.

$ openstack overcloud deploy --templates -r ~/templates/roles_data-network_node.yaml -e ~/templates/node-count-flavor.yaml

배포가 완료되면 컨트롤러 노드 1개, 컴퓨팅 노드 1개, Networker 노드로 구성된 3-노드 Overcloud가 생성됩니다. Overcloud의 노드 목록을 보려면 다음 명령을 실행합니다.

$ nova list

Red Hat OpenStack Platform은 OpenStack 서비스를 구성하지 않고 일반 Red Hat Enterprise Linux 7 노드를 생성할 수 있는 기능을 제공합니다. 이는 핵심 Red Hat OpenStack Platform 환경 외부에서 소프트웨어를 호스팅해야 하는 경우에 유용합니다. 예를 들어 OpenStack Platform은 Kibana 및 Sensu와 같은 모니터링 툴과 통합을 제공합니다( 12장. 모니터링 도구 설정참조). Red Hat은 모니터링 툴 자체를 지원하지 않지만 director는 이러한 툴을 호스팅하는 일반 Red Hat Enterprise Linux 7 노드를 생성할 수 있습니다.

일반 노드를 생성하려면 ServicesDefault 목록이 없는 새 역할이 필요합니다.

- name: Generic

사용자 지정 roles_data 파일(roles_data_with_generic.yaml)에 역할을 포함합니다. 기존 컨트롤러 및 컴퓨팅 역할을 유지합니다.

환경 파일(Generic-node-params.yaml)을 포함하여 필요한 일반 Red Hat Enterprise Linux 7 노드 수와 프로비저닝할 노드를 선택할 때 플레이버를 지정할 수도 있습니다. 예를 들면 다음과 같습니다.

parameter_defaults:
  OvercloudGenericFlavor: baremetal
  GenericCount: 1

openstack overcloud deploy 명령을 실행할 때 역할 파일과 환경 파일을 모두 포함합니다. 예를 들면 다음과 같습니다.

$ openstack overcloud deploy --templates -r ~/templates/roles_data_with_generic.yaml -e ~/templates/generic-node-params.yaml

그러면 컨트롤러 노드 1개, 컴퓨팅 노드 1개, 일반적인 Red Hat Enterprise Linux 7 노드가 각각 하나씩 있는 3-노드 환경이 배포됩니다.

Ceph OSD 서비스는 일반적으로 자체 Ceph Storage 노드에서 실행됩니다. 그러나 구성 가능 서비스는 대신 컴퓨팅 노드에서 Ceph OSD 서비스를 구성하는 방법을 제공합니다.

예를 들어 각 역할의 기본 서비스 목록에는 다음이 포함됩니다.

- name: Compute
  CountDefault: 1
  HostnameFormatDefault: '%stackname%-novacompute-%index%'
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephClient
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::NovaCompute
    - OS::TripleO::Services::NovaLibvirt
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::ComputeNeutronCorePlugin
    - OS::TripleO::Services::ComputeNeutronOvsAgent
    - OS::TripleO::Services::ComputeCeilometerAgent
    - OS::TripleO::Services::ComputeNeutronL3Agent
    - OS::TripleO::Services::ComputeNeutronMetadataAgent
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::NeutronSriovAgent
    - OS::TripleO::Services::OpenDaylightOvs
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::VipHosts

- name: CephStorage
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephOSD
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::VipHosts

Ceph Storage 역할에는 Compute 역할에 공통된 서비스가 포함되어 있으므로 이를 무시할 수 있습니다. 하나의 서비스는 OS::TripleO::Services::CephOSD.

기본 roles_data 파일의 사용자 지정 버전을 생성합니다.

$ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml ~/templates/roles_data-ceph_osd_on_compute.yaml

파일을 편집하여 OS::TripleO::Services::CephOSD 를 Compute 서비스 목록에 추가합니다.

- name: Compute
  CountDefault: 1
  HostnameFormatDefault: '%stackname%-novacompute-%index%'
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephClient
    - OS::TripleO::Services::CephOSD
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::NovaCompute
    - OS::TripleO::Services::NovaLibvirt
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::ComputeNeutronCorePlugin
    - OS::TripleO::Services::ComputeNeutronOvsAgent
    - OS::TripleO::Services::ComputeCeilometerAgent
    - OS::TripleO::Services::ComputeNeutronL3Agent
    - OS::TripleO::Services::ComputeNeutronMetadataAgent
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::NeutronSriovAgent
    - OS::TripleO::Services::OpenDaylightOvs
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::VipHosts

Overcloud가 외부 Ceph Storage 클러스터와 통합되지 않기 때문에 Compute 서비스 목록에서 OS::TripleO::Services::CephExternal 서비스를 안전하게 제거할 수도 있습니다.

openstack overcloud deploy 명령을 실행할 때 이 역할 파일을 포함합니다. 예를 들면 다음과 같습니다.

$ openstack overcloud deploy --templates -r ~/templates/roles_data-ceph_osd_on_compute.yaml -e ~/template/storage-environment.yaml

이 명령에는 Ceph Storage 관련 매개변수가 포함된 스토리지(storage-environment.yaml)용 사용자 지정 환경 파일도 포함되어 있습니다.

Overcloud 배포 후 컴퓨팅 노드에 Ceph OSD 설치를 확인합니다. 컴퓨팅 노드에 로그인하고 다음을 실행합니다.

[root@overcloud-novacompute-0 ~]# ps ax | grep ceph
17437 ?    Ss   0:00 /bin/bash -c ulimit -n 32768; /usr/bin/ceph-osd -i 0 --pid-file /var/run/ceph/osd.0.pid -c /etc/ceph/ceph.conf --cluster ceph -f
17438 ?    Sl   0:00 /usr/bin/ceph-osd -i 0 --pid-file /var/run/ceph/osd.0.pid -c /etc/ceph/ceph.conf --cluster ceph -f

구성 가능 서비스의 기본 아키텍처에서는 코어 Red Hat OpenStack Platform Services를 포함하는 모놀리식 컨트롤러를 사용합니다. 이러한 기본 서비스는 director의 Heat 템플릿 컬렉션(/usr/share/openstack-tripleo-heat-templates/roles_data.yaml)에 포함된 역할 파일에 정의되어 있습니다.

- name: Controller
  ServicesDefault:
    - OS::TripleO::Services::Apache
    - OS::TripleO::Services::AodhApi
    - OS::TripleO::Services::AodhEvaluator
    - OS::TripleO::Services::AodhListener
    - OS::TripleO::Services::AodhNotifier
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CeilometerAgentCentral
    - OS::TripleO::Services::CeilometerAgentNotification
    - OS::TripleO::Services::CeilometerApi
    - OS::TripleO::Services::CeilometerCollector
    - OS::TripleO::Services::CeilometerExpirer
    - OS::TripleO::Services::CephClient
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::CephMon
    - OS::TripleO::Services::CephRgw
    - OS::TripleO::Services::CinderApi
    - OS::TripleO::Services::CinderBackup
    - OS::TripleO::Services::CinderScheduler
    - OS::TripleO::Services::CinderVolume
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::GlanceApi
    - OS::TripleO::Services::GlanceRegistry
    - OS::TripleO::Services::GnocchiApi
    - OS::TripleO::Services::GnocchiMetricd
    - OS::TripleO::Services::GnocchiStatsd
    - OS::TripleO::Services::HAproxy
    - OS::TripleO::Services::HeatApi
    - OS::TripleO::Services::HeatApiCfn
    - OS::TripleO::Services::HeatApiCloudwatch
    - OS::TripleO::Services::HeatEngine
    - OS::TripleO::Services::Horizon
    - OS::TripleO::Services::IronicApi
    - OS::TripleO::Services::IronicConductor
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Keepalived
    - OS::TripleO::Services::Keystone
    - OS::TripleO::Services::ManilaApi
    - OS::TripleO::Services::ManilaBackendCephFs
    - OS::TripleO::Services::ManilaBackendGeneric
    - OS::TripleO::Services::ManilaBackendNetapp
    - OS::TripleO::Services::ManilaScheduler
    - OS::TripleO::Services::ManilaShare
    - OS::TripleO::Services::Memcached
    - OS::TripleO::Services::MongoDb
    - OS::TripleO::Services::MySQL
    - OS::TripleO::Services::NeutronApi
    - OS::TripleO::Services::NeutronCorePlugin
    - OS::TripleO::Services::NeutronCorePluginML2OVN
    - OS::TripleO::Services::NeutronCorePluginMidonet
    - OS::TripleO::Services::NeutronCorePluginNuage
    - OS::TripleO::Services::NeutronCorePluginOpencontrail
    - OS::TripleO::Services::NeutronCorePluginPlumgrid
    - OS::TripleO::Services::NeutronDhcpAgent
    - OS::TripleO::Services::NeutronL3Agent
    - OS::TripleO::Services::NeutronMetadataAgent
    - OS::TripleO::Services::NeutronOvsAgent
    - OS::TripleO::Services::NovaApi
    - OS::TripleO::Services::NovaConductor
    - OS::TripleO::Services::NovaConsoleauth
    - OS::TripleO::Services::NovaIronic
    - OS::TripleO::Services::NovaScheduler
    - OS::TripleO::Services::NovaVncProxy
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::OpenDaylightApi
    - OS::TripleO::Services::OpenDaylightOvs
    - OS::TripleO::Services::Pacemaker
    - OS::TripleO::Services::RabbitMQ
    - OS::TripleO::Services::Redis
    - OS::TripleO::Services::SaharaApi
    - OS::TripleO::Services::SaharaEngine
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::SwiftProxy
    - OS::TripleO::Services::SwiftRingBuilder
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts

컨트롤러 노드의 서비스를 두 개의 별도의 역할로 분할할 수 있습니다.

나머지 기본 역할(Compute, Ceph Storage, Object Storage, Block Storage)은 영향을 받지 않습니다.

다음 표는 분할 컨트롤러 아키텍처를 생성하는 가이드로 사용합니다.

- name: Controller
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::CephClient
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::CinderBackup
    - OS::TripleO::Services::CinderVolume
    - OS::TripleO::Services::HAproxy
    - OS::TripleO::Services::Keepalived
    - OS::TripleO::Services::ManilaBackendGeneric
    - OS::TripleO::Services::ManilaBackendNetapp
    - OS::TripleO::Services::ManilaBackendCephFs
    - OS::TripleO::Services::ManilaShare
    - OS::TripleO::Services::Memcached
    - OS::TripleO::Services::MySQL
    - OS::TripleO::Services::Pacemaker
    - OS::TripleO::Services::RabbitMQ
    - OS::TripleO::Services::Redis

- name: ControllerSystemd
  ServicesDefault:
    - OS::TripleO::Services::Apache
    - OS::TripleO::Services::AodhApi
    - OS::TripleO::Services::AodhEvaluator
    - OS::TripleO::Services::AodhListener
    - OS::TripleO::Services::AodhNotifier
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CeilometerAgentCentral
    - OS::TripleO::Services::CeilometerAgentNotification
    - OS::TripleO::Services::CeilometerApi
    - OS::TripleO::Services::CeilometerCollector
    - OS::TripleO::Services::CeilometerExpirer
    - OS::TripleO::Services::CephClient
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::CephMon
    - OS::TripleO::Services::CephRgw
    - OS::TripleO::Services::CinderApi
    - OS::TripleO::Services::CinderScheduler
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::GlanceApi
    - OS::TripleO::Services::GlanceRegistry
    - OS::TripleO::Services::GnocchiApi
    - OS::TripleO::Services::GnocchiMetricd
    - OS::TripleO::Services::GnocchiStatsd
    - OS::TripleO::Services::HeatApi
    - OS::TripleO::Services::HeatApiCfn
    - OS::TripleO::Services::HeatApiCloudwatch
    - OS::TripleO::Services::HeatEngine
    - OS::TripleO::Services::Horizon
    - OS::TripleO::Services::IronicApi
    - OS::TripleO::Services::IronicConductor
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Keystone
    - OS::TripleO::Services::ManilaApi
    - OS::TripleO::Services::ManilaScheduler
    - OS::TripleO::Services::MongoDb
    - OS::TripleO::Services::NeutronApi
    - OS::TripleO::Services::NeutronCorePlugin
    - OS::TripleO::Services::NeutronCorePluginML2OVN
    - OS::TripleO::Services::NeutronCorePluginMidonet
    - OS::TripleO::Services::NeutronCorePluginNuage
    - OS::TripleO::Services::NeutronCorePluginOpencontrail
    - OS::TripleO::Services::NeutronCorePluginPlumgrid
    - OS::TripleO::Services::NeutronDhcpAgent
    - OS::TripleO::Services::NeutronL3Agent
    - OS::TripleO::Services::NeutronMetadataAgent
    - OS::TripleO::Services::NeutronOvsAgent
    - OS::TripleO::Services::NovaApi
    - OS::TripleO::Services::NovaConductor
    - OS::TripleO::Services::NovaConsoleauth
    - OS::TripleO::Services::NovaIronic
    - OS::TripleO::Services::NovaScheduler
    - OS::TripleO::Services::NovaVncProxy
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::OpenDaylightApi
    - OS::TripleO::Services::OpenDaylightOvs
    - OS::TripleO::Services::SaharaApi
    - OS::TripleO::Services::SaharaEngine
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::SwiftProxy
    - OS::TripleO::Services::SwiftRingBuilder
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts

다음 표에는 Red Hat OpenStack Platform에서 구성 가능 서비스 아키텍처를 사용하여 생성하고 확장할 수 있는 사용자 정의 역할 컬렉션이 나열되어 있습니다. 이러한 컬렉션을 개별 역할로 그룹화하고 이를 사용하여 이전 아키텍처와 함께 서비스를 분리하고 분할합니다.

모든 역할은 다음과 같은 공통 서비스 세트를 사용합니다.

오버클라우드에 포함할 역할을 선택한 후 기본 컨트롤러 역할에서 관련 서비스( 일반 서비스제외)를 삭제합니다. 예를 들어 독립 실행형 Keystone 역할을 생성하는 경우 컨트롤러 노드에서 OS::TripleO::Services::Apache 및 OS::TripleO::Services::Keystone 서비스를 제거합니다. 유일한 예외는 사용자 정의 역할 지원이 제한된 서비스입니다( 표 6.1. “사용자 정의 역할 지원”참조).

다음 표에서 역할을 클릭하여 연결된 서비스를 확인합니다.

- name: CephMon
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::CephMon

- name: CephStorage
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::CephOSD

    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::CephRgw
    - OS::TripleO::Services::CephClient

- name: CinderApi
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::CinderApi
    - OS::TripleO::Services::CinderScheduler

- name: ControllerPcmk
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::CephClient
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::CinderBackup
    - OS::TripleO::Services::CinderVolume
    - OS::TripleO::Services::HAproxy
    - OS::TripleO::Services::Keepalived
    - OS::TripleO::Services::ManilaBackendGeneric
    - OS::TripleO::Services::ManilaBackendNetapp
    - OS::TripleO::Services::ManilaBackendCephFs
    - OS::TripleO::Services::ManilaShare
    - OS::TripleO::Services::Memcached
    - OS::TripleO::Services::MySQL
    - OS::TripleO::Services::Pacemaker
    - OS::TripleO::Services::RabbitMQ
    - OS::TripleO::Services::Redis
    - OS::TripleO::Services::VipHosts

- name: Glance
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::CephClient
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::GlanceApi
    - OS::TripleO::Services::GlanceRegistry

- name: Heat
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::HeatApi
    - OS::TripleO::Services::HeatApiCfn
    - OS::TripleO::Services::HeatApiCloudwatch
    - OS::TripleO::Services::HeatEngine

- name: Horizon
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::Apache
    - OS::TripleO::Services::Horizon

    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::IronicApi
    - OS::TripleO::Services::IronicConductor
    - OS::TripleO::Services::NovaIronic

- name: Keystone
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::Apache
    - OS::TripleO::Services::Keystone

    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::ManilaApi
    - OS::TripleO::Services::ManilaScheduler

- name: Networker
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::NeutronDhcpAgent
    - OS::TripleO::Services::NeutronL3Agent
    - OS::TripleO::Services::NeutronMetadataAgent
    - OS::TripleO::Services::NeutronOvsAgent

- name: NeutronApi
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::NeutronApi
    - OS::TripleO::Services::NeutronCorePlugin
    - OS::TripleO::Services::NeutronCorePluginML2OVN
    - OS::TripleO::Services::NeutronCorePluginMidonet
    - OS::TripleO::Services::NeutronCorePluginNuage
    - OS::TripleO::Services::NeutronCorePluginOpencontrail
    - OS::TripleO::Services::NeutronCorePluginPlumgrid

- name: Nova
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::NovaApi
    - OS::TripleO::Services::NovaConductor
    - OS::TripleO::Services::NovaConsoleauth
    - OS::TripleO::Services::NovaScheduler
    - OS::TripleO::Services::NovaVncProxy

- name: Compute
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::CephClient
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::ComputeCeilometerAgent
    - OS::TripleO::Services::ComputeNeutronCorePlugin
    - OS::TripleO::Services::ComputeNeutronL3Agent
    - OS::TripleO::Services::ComputeNeutronMetadataAgent
    - OS::TripleO::Services::ComputeNeutronOvsAgent
    - OS::TripleO::Services::NeutronSriovAgent
    - OS::TripleO::Services::NovaCompute
    - OS::TripleO::Services::NovaLibvirt
    - OS::TripleO::Services::OpenDaylightOvs

- name: Opendaylight
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::OpenDaylightApi
    - OS::TripleO::Services::OpenDaylightOvs

    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::SaharaApi
    - OS::TripleO::Services::SaharaEngine

- name: SwiftApi
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::SwiftProxy
    - OS::TripleO::Services::SwiftRingBuilder

- name: ObjectStorage
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::SwiftRingBuilder
    - OS::TripleO::Services::SwiftStorage

- name: Telemetry
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::VipHosts
    - OS::TripleO::Services::Apache
    - OS::TripleO::Services::AodhApi
    - OS::TripleO::Services::AodhEvaluator
    - OS::TripleO::Services::AodhListener
    - OS::TripleO::Services::AodhNotifier
    - OS::TripleO::Services::CeilometerAgentCentral
    - OS::TripleO::Services::CeilometerAgentNotification
    - OS::TripleO::Services::CeilometerApi
    - OS::TripleO::Services::CeilometerCollector
    - OS::TripleO::Services::CeilometerExpirer
    - OS::TripleO::Services::GnocchiApi
    - OS::TripleO::Services::GnocchiMetricd
    - OS::TripleO::Services::GnocchiStatsd
    - OS::TripleO::Services::MongoDb

다음 표에는 Red Hat OpenStack Platform에서 사용 가능한 모든 구성 가능 서비스 목록이 나와 있습니다.

Overcloud 네트워크 구성에는 네트워크 인터페이스 템플릿 세트가 필요합니다. 이러한 템플릿을 사용자 지정하여 역할에 따라 노드 인터페이스를 구성합니다. 이러한 템플릿은 YAML 형식의 표준 Heat 템플릿입니다( 2.1절. “Heat 템플릿”참조). director에는 시작할 예제 템플릿 세트가 포함되어 있습니다.

이 예에서는 기본 본딩 NIC 예제 구성을 기준으로 사용합니다. /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans 에 있는 버전을 복사합니다.

$ cp -r /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans ~/templates/nic-configs

이렇게 하면 각 역할에 연결된 네트워크 인터페이스 구성을 정의하는 heat 템플릿 로컬 세트가 생성됩니다. 각 템플릿에는 표준 매개변수,리소스, 출력 섹션이 포함되어 있습니다. 이 예제에서는 resources 섹션만 편집합니다. 각 resources 섹션은 다음으로 시작합니다.

resources:
OsNetConfigImpl:
  type: OS::Heat::StructuredConfig
  properties:
    group: os-apply-config
    config:
      os_net_config:
        network_config:

이렇게 하면 os-apply-config 명령 및 os-net-config 하위 명령에 대한 요청이 생성되고 노드의 네트워크 속성을 구성합니다. network_config 섹션에는 type에 따라 정렬된 사용자 지정 인터페이스 구성이 포함되어 있으며 여기에는 다음이 포함됩니다.

이러한 각 항목에 대한 전체 매개변수 목록은 부록 C. 네트워크 인터페이스 매개변수 를 참조하십시오.

이 예제에서는 기본 본딩 인터페이스 구성을 사용합니다. 예를 들어 /home/stack/templates/nic-configs/controller.yaml 템플릿은 다음 network_config 를 사용합니다.

resources:
  OsNetConfigImpl:
    type: OS::Heat::StructuredConfig
    properties:
      group: os-apply-config
      config:
        os_net_config:
          network_config:
            - type: interface
              name: nic1
              use_dhcp: false
              addresses:
                - ip_netmask:
                    list_join:
                      - '/'
                      - - {get_param: ControlPlaneIp}
                        - {get_param: ControlPlaneSubnetCidr}
              routes:
                - ip_netmask: 169.254.169.254/32
                  next_hop: {get_param: EC2MetadataIp}
            - type: ovs_bridge
              name: {get_input: bridge_name}
              dns_servers: {get_param: DnsServers}
              members:
                - type: ovs_bond
                  name: bond1
                  ovs_options: {get_param: BondInterfaceOvsOptions}
                  members:
                    - type: interface
                      name: nic2
                      primary: true
                    - type: interface
                      name: nic3
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: ExternalNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: ExternalIpSubnet}
                  routes:
                    - default: true
                      next_hop: {get_param: ExternalInterfaceDefaultRoute}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: InternalApiNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: InternalApiIpSubnet}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: StorageNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: StorageIpSubnet}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: StorageMgmtNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: StorageMgmtIpSubnet}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: TenantNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: TenantIpSubnet}
                - type: vlan
                  device: bond1
                  vlan_id: {get_param: ManagementNetworkVlanID}
                  addresses:
                    - ip_netmask: {get_param: ManagementIpSubnet}

이 템플릿은 브리지(일반적으로 br-ex라는 외부 브리지)를 정의하고 두 개의 번호가 지정된 인터페이스인 nic2 및 nic3 에서 bond1 이라는 본딩된 인터페이스를 만듭니다. 브리지에는 bond1 을 상위 장치로 사용하는 태그된 여러 VLAN 장치도 포함되어 있습니다. 템플릿에는 director(nic1)에 다시 연결되는 인터페이스도 포함됩니다.

네트워크 인터페이스 템플릿의 예는 부록 B. 네트워크 인터페이스 템플릿 예 을 참조하십시오.

이러한 매개변수의 대부분은 get_param 함수를 사용합니다. 네트워크를 위해 특별히 만든 환경 파일에서 이러한 항목을 정의합니다.

- type: interface
  name: nic4
  use_dhcp: false
  defroute: false

네트워크 환경 파일은 Overcloud의 네트워크 환경을 설명하고 이전 섹션의 네트워크 인터페이스 구성 템플릿을 가리키는 Heat 환경 파일입니다. IP 주소 범위와 함께 네트워크의 서브넷 및 VLAN을 정의할 수 있습니다. 그런 다음 로컬 환경에 대한 이러한 값을 사용자 지정할 수 있습니다.

director에는 시작할 환경 파일 세트가 포함되어 있습니다. 각 환경 파일은 /usr/share/openstack-tripleo-heat-templates/network/config/ 의 예제 네트워크 인터페이스 파일에 해당합니다.

이 시나리오에서는 /usr/share/openstack-tripleo-heat-templates/environments/net-bond-with-vlans.yaml 파일의 수정된 버전을 사용합니다. 이 파일을 stack 사용자의 templates 디렉터리에 복사합니다.

$ cp /usr/share/openstack-tripleo-heat-templates/environments/net-bond-with-vlans.yaml /home/stack/templates/network-environment.yaml

환경 파일에는 다음과 같은 수정된 섹션이 포함되어 있습니다.

resource_registry:
  OS::TripleO::BlockStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/cinder-storage.yaml
  OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/templates/nic-configs/compute.yaml
  OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/nic-configs/controller.yaml
  OS::TripleO::ObjectStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/swift-storage.yaml
  OS::TripleO::CephStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/ceph-storage.yaml

parameter_defaults:
  InternalApiNetCidr: 172.16.0.0/24
  TenantNetCidr: 172.17.0.0/24
  StorageNetCidr: 172.18.0.0/24
  StorageMgmtNetCidr: 172.19.0.0/24
  ManagementNetCidr: 172.20.0.0/24
  ExternalNetCidr: 10.1.1.0/24
  InternalApiAllocationPools: [{'start': '172.16.0.10', 'end': '172.16.0.200'}]
  TenantAllocationPools: [{'start': '172.17.0.10', 'end': '172.17.0.200'}]
  StorageAllocationPools: [{'start': '172.18.0.10', 'end': '172.18.0.200'}]
  StorageMgmtAllocationPools: [{'start': '172.19.0.10', 'end': '172.19.0.200'}]
  ManagementAllocationPools: [{'start': '172.20.0.10', 'end': '172.20.0.200'}]
  # Leave room for floating IPs in the External allocation pool
  ExternalAllocationPools: [{'start': '10.1.1.10', 'end': '10.1.1.50'}]
  # Set to the router gateway on the external network
  ExternalInterfaceDefaultRoute: 10.1.1.1
  # Gateway router for the provisioning network (or Undercloud IP)
  ControlPlaneDefaultRoute: 192.0.2.254
  # The IP address of the EC2 metadata server. Generally the IP of the Undercloud
  EC2MetadataIp: 192.0.2.1
  # Define the DNS servers (maximum 2) for the overcloud nodes
  DnsServers: ["8.8.8.8","8.8.4.4"]
  InternalApiNetworkVlanID: 201
  StorageNetworkVlanID: 202
  StorageMgmtNetworkVlanID: 203
  TenantNetworkVlanID: 204
  ManagementNetworkVlanID: 205
  ExternalNetworkVlanID: 100
  NeutronExternalNetworkBridge: "''"
  # Customize bonding options if required
  BondInterfaceOvsOptions:
    "bond_mode=balance-slb"

resource_registry 섹션에는 각 노드 역할의 사용자 지정 네트워크 인터페이스 템플릿에 대한 수정된 링크가 포함되어 있습니다. 다음 형식을 사용하여 이 섹션에서 사용자 지정 역할에 대한 네트워크 인터페이스 템플릿에 대한 링크도 포함합니다.

[ROLE] 을 역할 이름으로 바꾸고 [FILE] 을 네트워크 인터페이스 템플릿 위치로 바꿉니다.

parameter_defaults 섹션에는 각 네트워크 유형에 대한 네트워크 옵션을 정의하는 매개변수 목록이 포함되어 있습니다. 이러한 옵션에 대한 자세한 내용은 부록 A. 네트워크 환경 옵션 을 참조하십시오.

이 시나리오에서는 각 네트워크에 대한 옵션을 정의합니다. 모든 네트워크 유형에서는 호스트 및 가상 IP에 IP 주소를 할당하는 데 사용되는 개별 VLAN 및 서브넷을 사용합니다. 위의 예에서 Internal API 네트워크의 할당 풀은 172.16.0.10에서 시작하며 VLAN 201을 사용하여 172.16.0.200으로 이동합니다. 이로 인해 사용자 환경에서 VLAN 201을 사용하는 동안 172.16.0.10 및 172.16.0.200에서 시작하는 정적 및 가상 IP가 할당됩니다.

외부 네트워크는 Horizon 대시보드 및 공용 API를 호스팅합니다. 클라우드 관리 및 유동 IP 모두에 External 네트워크를 사용하는 경우 VM 인스턴스의 유동 IP로 사용할 IP 풀이 있는지 확인합니다. 이 예에서는 외부 네트워크에 할당된 10.1.1.10에서 10.1.1.50의 IP만 있으므로 IP 주소는 10.1.1.51 이상에서 유동 IP 주소에 사용할 수 없습니다. 또는 유동 IP 네트워크를 별도의 VLAN에 배치하고 생성한 후 Overcloud를 사용하도록 구성합니다.

BondInterfaceOvsOptions 옵션은 nic2 및 nic3 을 사용하여 결합된 인터페이스에 대한 옵션을 제공합니다. 본딩 옵션에 대한 자세한 내용은 부록 D. 본딩 옵션 을 참조하십시오.

각 OpenStack 서비스는 리소스 레지스트리의 기본 네트워크 유형에 할당됩니다. 그런 다음 이러한 서비스는 네트워크 유형의 할당된 네트워크 내의 IP 주소에 바인딩됩니다. OpenStack 서비스는 이러한 네트워크로 구분되지만 실제 물리적 네트워크 수는 네트워크 환경 파일에 정의된 대로 다를 수 있습니다. 네트워크 환경 파일(/home/stack/templates/network-environment.yaml)에 새 네트워크 맵을 정의하여 OpenStack 서비스를 다른 네트워크 유형에 다시 할당할 수 있습니다. ServiceNetMap 매개변수는 각 서비스에 사용되는 네트워크 유형을 결정합니다.

예를 들어 강조 표시된 섹션을 수정하여 스토리지 관리 네트워크 서비스를 스토리지 네트워크에 다시 할당할 수 있습니다.

parameter_defaults:
  ServiceNetMap:
    SwiftMgmtNetwork: storage # Changed from storage_mgmt
    CephClusterNetwork: storage # Changed from storage_mgmt

이러한 매개변수를 스토리지로 변경하면 스토리지 관리 네트워크 대신 이러한 서비스가 스토리지 네트워크에 배치됩니다. 즉, 스토리지 관리 네트워크가 아닌 Storage 네트워크의 parameter_defaults 세트만 정의해야 합니다.

director는 사용자 정의 ServiceNetMap 매개변수 정의를 ServiceNetMapDefaults 에서 가져온 사전 정의된 기본값 목록에 병합하고 기본값을 덮어씁니다. 그런 다음 director는 다양한 서비스에 대한 네트워크 할당을 설정하는 데 사용되는 ServiceNetMap 으로 다시 사용자 지정을 포함하여 전체 목록을 반환합니다.

네트워크 및 포트의 환경 파일의 resource_registry 섹션에 있는 설정은 일반적으로 변경할 필요가 없습니다. 네트워크 목록은 네트워크 서브 세트만 원하는 경우 변경할 수 있습니다.

격리된 네트워크를 사용하려면 서버에 각 네트워크에 IP 주소가 있어야 합니다. 언더클라우드에서 neutron을 사용하여 격리된 네트워크에서 IP 주소를 관리할 수 있으므로 각 네트워크에 대해 neutron 포트 생성을 활성화해야 합니다. 환경 파일에서 리소스 레지스트리를 덮어쓸 수 있습니다.

먼저, 다음은 배포할 수 있는 기본 네트워크 및 포트의 전체 집합입니다.

resource_registry:
  # This section is usually not modified, if in doubt stick to the defaults
  # TripleO overcloud networks
  OS::TripleO::Network::External: /usr/share/openstack-tripleo-heat-templates/network/external.yaml
  OS::TripleO::Network::InternalApi: /usr/share/openstack-tripleo-heat-templates/network/internal_api.yaml
  OS::TripleO::Network::StorageMgmt: /usr/share/openstack-tripleo-heat-templates/network/storage_mgmt.yaml
  OS::TripleO::Network::Storage: /usr/share/openstack-tripleo-heat-templates/network/storage.yaml
  OS::TripleO::Network::Tenant: /usr/share/openstack-tripleo-heat-templates/network/tenant.yaml
  OS::TripleO::Network::Management: /usr/share/openstack-tripleo-heat-templates/network/management.yaml

  # Port assignments for the VIPs
  OS::TripleO::Network::Ports::ExternalVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
  OS::TripleO::Network::Ports::InternalApiVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
  OS::TripleO::Network::Ports::StorageVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
  OS::TripleO::Network::Ports::StorageMgmtVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml
  OS::TripleO::Network::Ports::TenantVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
  OS::TripleO::Network::Ports::ManagementVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml
  OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/vip.yaml

  # Port assignments for the controller role
  OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
  OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
  OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
  OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml
  OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
  OS::TripleO::Controller::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml

  # Port assignments for the compute role
  OS::TripleO::Compute::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
  OS::TripleO::Compute::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
  OS::TripleO::Compute::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
  OS::TripleO::Compute::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml

  # Port assignments for the ceph storage role
  OS::TripleO::CephStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
  OS::TripleO::CephStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml
  OS::TripleO::CephStorage::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml

  # Port assignments for the swift storage role
  OS::TripleO::SwiftStorage::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
  OS::TripleO::SwiftStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
  OS::TripleO::SwiftStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml
  OS::TripleO::SwiftStorage::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml

  # Port assignments for the block storage role
  OS::TripleO::BlockStorage::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
  OS::TripleO::BlockStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
  OS::TripleO::BlockStorage::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml
  OS::TripleO::BlockStorage::Ports::ManagementPort: /usr/share/openstack-tripleo-heat-templates/network/ports/management.yaml

이 파일의 첫 번째 섹션에는 OS::TripleO::Network::* 리소스에 대한 리소스 레지스트리 선언이 있습니다. 기본적으로 이러한 리소스는 네트워크를 생성하지 않는 OS::Heat::None 리소스 유형을 사용합니다. 이러한 리소스를 각 네트워크의 YAML 파일로 리디렉션하면 이러한 네트워크를 생성할 수 있습니다.

다음 여러 섹션에서는 각 역할에 있는 노드의 IP 주소를 생성합니다. 컨트롤러 노드에는 각 네트워크에 IP가 있습니다. 컴퓨팅 및 스토리지 노드에 각각 네트워크의 하위 집합에 IP가 있습니다.

기본 파일에는 기본 역할에 대한 포트 할당만 포함되어 있습니다. 사용자 지정 역할에 대한 포트 할당을 구성하려면 다른 리소스 정의와 동일한 규칙을 사용하고 네트워크/포트 디렉터리의 적절한 Heat 템플릿에 연결합니다.

[ROLE] 을 역할 이름으로 교체합니다.

사전 구성된 네트워크 중 하나 없이 배포하려면 역할에 대한 네트워크 정의 및 해당 포트 정의를 비활성화합니다. 예를 들어 storage_mgmt.yaml 에 대한 모든 참조는 OS::Heat::None 으로 교체할 수 있습니다.

resource_registry:
  # This section is usually not modified, if in doubt stick to the defaults
  # TripleO overcloud networks
  OS::TripleO::Network::External: /usr/share/openstack-tripleo-heat-templates/network/external.yaml
  OS::TripleO::Network::InternalApi: /usr/share/openstack-tripleo-heat-templates/network/internal_api.yaml
  OS::TripleO::Network::StorageMgmt: OS::Heat::None
  OS::TripleO::Network::Storage: /usr/share/openstack-tripleo-heat-templates/network/storage.yaml
  OS::TripleO::Network::Tenant: /usr/share/openstack-tripleo-heat-templates/network/tenant.yaml

  # Port assignments for the VIPs
  OS::TripleO::Network::Ports::ExternalVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
  OS::TripleO::Network::Ports::InternalApiVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
  OS::TripleO::Network::Ports::StorageVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
  OS::TripleO::Network::Ports::StorageMgmtVipPort: OS::Heat::None
  OS::TripleO::Network::Ports::TenantVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml
  OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/vip.yaml

  # Port assignments for the controller role
  OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external.yaml
  OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
  OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
  OS::TripleO::Controller::Ports::StorageMgmtPort: OS::Heat::None
  OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml

  # Port assignments for the compute role
  OS::TripleO::Compute::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
  OS::TripleO::Compute::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
  OS::TripleO::Compute::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml

  # Port assignments for the ceph storage role
  OS::TripleO::CephStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
  OS::TripleO::CephStorage::Ports::StorageMgmtPort: OS::Heat::None

  # Port assignments for the swift storage role
  OS::TripleO::SwiftStorage::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
  OS::TripleO::SwiftStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
  OS::TripleO::SwiftStorage::Ports::StorageMgmtPort: OS::Heat::None

  # Port assignments for the block storage role
  OS::TripleO::BlockStorage::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml
  OS::TripleO::BlockStorage::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml
  OS::TripleO::BlockStorage::Ports::StorageMgmtPort: OS::Heat::None

parameter_defaults:
  ServiceNetMap:
    ApacheNetwork: internal_api
    NeutronTenantNetwork: tenant
    CeilometerApiNetwork: internal_api
    AodhApiNetwork: internal_api
    GnocchiApiNetwork: internal_api
    MongodbNetwork: internal_api
    CinderApiNetwork: internal_api
    CinderIscsiNetwork: storage
    GlanceApiNetwork: internal_api
    GlanceRegistryNetwork: internal_api
    IronicApiNetwork: ctlplane
    IronicNetwork: ctlplane
    KeystoneAdminApiNetwork: ctlplane # allows undercloud to config endpoints
    KeystonePublicApiNetwork: internal_api
    ManilaApiNetwork: internal_api
    NeutronApiNetwork: internal_api
    HeatApiNetwork: internal_api
    HeatApiCfnNetwork: internal_api
    HeatApiCloudwatchNetwork: internal_api
    NovaApiNetwork: internal_api
    NovaColdMigrationNetwork: ctlplane
    NovaMetadataNetwork: internal_api
    NovaVncProxyNetwork: internal_api
    NovaLibvirtNetwork: internal_api
    SwiftStorageNetwork: storage # Changed from storage_mgmt
    SwiftProxyNetwork: storage
    SaharaApiNetwork: internal_api
    HorizonNetwork: internal_api
    MemcachedNetwork: internal_api
    RabbitmqNetwork: internal_api
    RedisNetwork: internal_api
    MysqlNetwork: internal_api
    CephClusterNetwork: storage # Changed from storage_mgmt
    CephMonNetwork: storage
    CephRgwNetwork: storage
    PublicNetwork: external
    OpendaylightApiNetwork: internal_api
    CephStorageHostnameResolveNetwork: storage
    ControllerHostnameResolveNetwork: internal_api
    ComputeHostnameResolveNetwork: internal_api
    ObjectStorageHostnameResolveNetwork: internal_api
    BlockStorageHostnameResolveNetwork: internal_api

OS::Heat::None 을 사용하면 네트워크 또는 포트가 생성되지 않으므로 스토리지 관리 네트워크의 서비스는 기본적으로 프로비저닝 네트워크로 설정됩니다. 이는 스토리지 네트워크와 같은 다른 네트워크로 스토리지 관리 서비스를 이동하도록 ServiceNetMap 에서 변경될 수 있습니다.

다음 절차에서는 특정 노드에 노드 ID를 할당합니다. 노드 ID의 예로는 controller-0,controller-1,compute-0,compute-1 등이 있습니다.

첫 번째 단계는 Nova 스케줄러가 배포 시 일치하는 노드별 기능으로 ID를 할당하는 것입니다. 예를 들면 다음과 같습니다.

openstack baremetal node set --property capabilities='node:controller-0,boot_option:local' <id>

이렇게 하면 기능 node:controller-0 을 노드에 할당합니다. 모든 노드에 대해 0부터 시작하여 고유한 연속 인덱스를 사용하여 이 패턴을 반복합니다. 지정된 역할(Controller, Compute 또는 각 스토리지 역할)에 대한 모든 노드가 동일한 방식으로 태그되는지 또는 Nova 스케줄러가 기능과 올바르게 일치하지 않는지 확인합니다.

다음 단계는 스케줄러 힌트를 사용하여 각 노드의 기능과 일치하는 Heat 환경 파일(예: scheduler_hints_env.yaml)을 생성하는 것입니다. 예를 들면 다음과 같습니다.

parameter_defaults:
  ControllerSchedulerHints:
    'capabilities:node': 'controller-%index%'

이러한 스케줄러 힌트를 사용하려면 Overcloud 생성 중에 overcloud deploy 명령에 ' scheduler_hints_env.yaml' 환경 파일을 포함합니다.

다음 매개변수를 통해 각 역할에 대해 동일한 접근 방식을 사용할 수 있습니다.

$ openstack overcloud deploy ... --control-flavor baremetal --compute-flavor baremetal ...

8.1절. “특정 노드 ID 할당” 의 노드 ID 구성과 함께 director는 각 노드에 특정 사용자 지정 호스트 이름을 할당할 수도 있습니다. 이 기능은 시스템이 있는 위치(예: rack2-row12), 인벤토리 식별자 또는 사용자 지정 호스트 이름이 필요한 다른 상황을 정의해야 하는 경우에 유용합니다.

노드 호스트 이름을 사용자 지정하려면 8.1절. “특정 노드 ID 할당” 의 ' scheduler_hints_env.yaml' 파일과 같은 환경 파일에서 HostnameMap 매개변수를 사용합니다. 예를 들면 다음과 같습니다.

parameter_defaults:
  ControllerSchedulerHints:
    'capabilities:node': 'controller-%index%'
  NovaComputeSchedulerHints:
    'capabilities:node': 'compute-%index%'
  HostnameMap:
    overcloud-controller-0: overcloud-controller-prod-123-0
    overcloud-controller-1: overcloud-controller-prod-456-0
    overcloud-controller-2: overcloud-controller-prod-789-0
    overcloud-compute-0: overcloud-compute-prod-abc-0

HostnameMap 을 parameter_defaults 섹션에 정의하고 각 매핑을 HostnameFormat 매개변수를 사용하여 Heat에서 정의하는 원래 호스트 이름으로 설정합니다(예: overcloud-controller-0) 및 두 번째 값은 해당 노드에 대해 원하는 사용자 지정 호스트 이름(예: overcloud-controller-prod-123-0)입니다.

노드 ID 배치와 함께 이 방법을 사용하면 각 노드에 사용자 정의 호스트 이름이 있습니다.

생성된 환경을 추가로 제어하기 위해 director는 Overcloud 노드에 각 네트워크의 특정 IP도 할당할 수 있습니다. 코어 Heat 템플릿 컬렉션에서 environments/ips-from-pool-all.yaml 환경 파일을 사용합니다. 이 파일을 stack 사용자의 templates 디렉터리에 복사합니다.

$ cp /usr/share/openstack-tripleo-heat-templates/environments/ips-from-pool-all.yaml ~/templates/.

ips-from-pool-all.yaml 파일에는 두 개의 주요 섹션이 있습니다.

첫 번째는 기본값을 재정의하는 resource_registry 참조 세트입니다. 이를 통해 director에 노드 유형의 지정된 포트에 특정 IP를 사용하도록 지시합니다. 각 템플릿의 절대 경로를 사용하도록 각 리소스를 수정합니다. 예를 들면 다음과 같습니다.

  OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external_from_pool.yaml
  OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api_from_pool.yaml
  OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_from_pool.yaml
  OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt_from_pool.yaml
  OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant_from_pool.yaml

기본 구성은 사전 할당된 IP를 사용하도록 모든 노드 유형의 모든 네트워크를 설정합니다. 특정 네트워크 또는 노드 유형이 대신 기본 IP 할당을 사용하도록 허용하려면 환경 파일에서 해당 노드 유형 또는 네트워크와 관련된 resource_registry 항목을 제거하기만 하면 됩니다.

두 번째 섹션은 parameter_defaults로, 실제 IP 주소가 할당됩니다. 각 노드 유형에는 연결된 매개변수가 있습니다.

각 매개변수는 네트워크 이름을 주소 목록에 매핑한 것입니다. 각 네트워크 유형에는 해당 네트워크에 노드가 있을 만큼 많은 주소가 있어야 합니다. director는 주소를 순서대로 할당합니다. 각 유형의 첫 번째 노드는 각 목록의 첫 번째 주소를 수신하며, 두 번째 노드는 각 목록에서 두 번째 주소를 수신합니다.

예를 들어 Overcloud에 세 개의 Ceph Storage 노드가 포함된 경우 CephStorageIPs 매개변수는 다음과 같을 수 있습니다.

CephStorageIPs:
  storage:
  - 172.16.1.100
  - 172.16.1.101
  - 172.16.1.102
  storage_mgmt:
  - 172.16.3.100
  - 172.16.3.101
  - 172.16.3.102

첫 번째 Ceph Storage 노드는 172.16.1.100 및 172.16.3.100의 두 가지 주소를 수신합니다. 두 번째는 172.16.1.101 및 172.16.3.101을 수신하고 세 번째는 172.16.1.102 및 172.16.3.102를 수신합니다. 다른 노드 유형에도 동일한 패턴이 적용됩니다.

선택한 IP 주소가 네트워크 환경 파일에 정의된 각 네트워크의 할당 풀 외부에 있는지 확인합니다( 7.2절. “네트워크 환경 파일 생성”참조). 예를 들어 internal_api 할당이 InternalApiAllocationPools 범위 외부에 있는지 확인합니다. 이렇게 하면 자동으로 선택한 IP와의 충돌이 발생하지 않습니다. 마찬가지로 표준 예측 가능한 VIP 배치( 8.4절. “예측 가능한 가상 IP 할당”참조) 또는 외부 로드 밸런싱에 대해 IP 할당이 VIP 구성과 충돌하지 않도록 합니다( 14.1절. “외부 로드 밸런싱 구성”참조).

배포 중에 이 구성을 적용하려면 openstack overcloud deploy 명령을 사용하여 ips-from-pool-all.yaml 환경 파일을 포함합니다.

예를 들면 다음과 같습니다.

$ openstack overcloud deploy --templates \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e ~/templates/ips-from-pool-all.yaml \
  [OTHER OPTIONS]

각 노드의 예측 가능한 IP 주소를 정의하는 것 외에도 director는 클러스터형 서비스에 대한 예측 가능한 가상 IP(VIP)를 정의하는 유사한 기능을 제공합니다. 이를 수행하려면 7.2절. “네트워크 환경 파일 생성” 에서 네트워크 환경 파일을 편집하고 parameter_defaults 섹션에 VIP 매개변수를 추가합니다.

parameter_defaults:
  ...
  # Predictable VIPs
  ControlFixedIPs: [{'ip_address':'192.168.201.101'}]
  InternalApiVirtualFixedIPs: [{'ip_address':'172.16.0.9'}]
  PublicVirtualFixedIPs: [{'ip_address':'10.1.1.9'}]
  StorageVirtualFixedIPs: [{'ip_address':'172.18.0.9'}]
  StorageMgmtVirtualFixedIPs: [{'ip_address':'172.19.0.9'}]
  RedisVirtualFixedIPs: [{'ip_address':'172.16.0.8'}]

각 할당 풀 범위 외부에서 이러한 IP를 선택합니다. 예를 들어 InternalApiAllocationPools 범위에 포함되지 않은 InternalApiVirtualFixedIPs 의 IP 주소를 선택합니다.

이 단계는 기본 내부 부하 분산 설정을 사용하는 오버클라우드에만 해당합니다. 외부 로드 밸런서를 사용하여 VIP를 할당하는 경우 전용 External Load Balancing for the Overcloud 가이드의 절차를 사용하십시오.

서명 호스트는 새 인증서를 생성하여 인증 기관으로 서명하는 호스트입니다. 선택한 서명 호스트에서 SSL 인증서를 생성한 적이 없는 경우 새 인증서에 서명할 수 있도록 호스트를 초기화해야 할 수 있습니다.

/etc/pki/CA/index.txt 파일은 서명된 모든 인증서의 레코드를 저장합니다. 이 파일이 있는지 확인합니다. 없는 경우 빈 파일을 생성합니다.

$ sudo touch /etc/pki/CA/index.txt

/etc/pki/CA/serial 파일은 서명할 다음 인증서에 사용할 다음 일련번호를 식별합니다. 이 파일이 있는지 확인합니다. 존재하지 않는 경우 새 시작 값으로 새 파일을 생성합니다.

$ echo '1000' | sudo tee /etc/pki/CA/serial

일반적으로는 외부 인증 기관을 통해 SSL/TLS 인증서에 서명합니다. 고유한 인증 기관을 사용하려는 경우도 있습니다. 예를 들어 내부 전용 인증 기관을 사용하는 것이 좋습니다.

예를 들어 인증 기관 역할을 할 키와 인증서 쌍을 생성합니다.

$ openssl genrsa -out ca.key.pem 4096
$ openssl req  -key ca.key.pem -new -x509 -days 7300 -extensions v3_ca -out ca.crt.pem

openssl req 명령은 기관에 대한 특정 세부 정보를 요청합니다. 이러한 세부 정보를 입력합니다.

그러면 ca.crt.pem 이라는 인증 기관 파일이 생성됩니다.

외부 클라이언트가 SSL/TLS를 사용하여 통신하려는 경우 Red Hat OpenStack Platform 환경에 액세스해야 하는 각 클라이언트에 인증 기관 파일을 복사합니다. 클라이언트에 복사된 후 클라이언트에서 다음 명령을 실행하여 인증 기관 신뢰 번들에 추가합니다.

$ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
$ sudo update-ca-trust extract

예를 들어, 생성 중에 오버클라우드 끝점과 통신할 수 있도록 언더클라우드에 인증 기관 파일의 사본이 필요합니다.

다음 명령을 실행하여 언더클라우드 또는 오버클라우드 인증서를 생성하기 위해 다른 시점에서 사용하는 SSL/TLS 키(server.key.pem)를 생성합니다.

$ openssl genrsa -out server.key.pem 2048

다음 절차에서는 오버클라우드에 대한 인증서 서명 요청을 생성합니다. 사용자 지정을 위해 기본 OpenSSL 설정 파일을 복사합니다.

$ cp /etc/pki/tls/openssl.cnf .

사용자 정의 openssl.cnf 파일을 편집하고 오버클라우드에 사용할 SSL 매개변수를 설정합니다. 수정할 매개변수 유형의 예제는 다음과 같습니다.

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req

[req_distinguished_name]
countryName = Country Name (2 letter code)
countryName_default = AU
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Queensland
localityName = Locality Name (eg, city)
localityName_default = Brisbane
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = Red Hat
commonName = Common Name
commonName_default = 10.0.0.1
commonName_max = 64

[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
IP.1 = 10.0.0.1
DNS.1 = 10.0.0.1
DNS.2 = myovercloud.example.com

commonName_default 를 다음 중 하나로 설정합니다.

IP 항목 및 alt_names 섹션에 있는 DNS 항목과 동일한 공용 API IP 주소를 포함합니다. DNS를 사용하는 경우 동일한 섹션에 있는 DNS 항목으로 서버의 호스트 이름을 추가합니다. openssl.cnf 에 대한 자세한 내용은 man openssl.cnf 를 실행합니다.

다음 명령을 실행하여 인증서 서명 요청(server.csr.pem)을 생성합니다.

$ openssl req -config openssl.cnf -key server.key.pem -new -out server.csr.pem

9.4절. “SSL/TLS 키 생성” 에서 -key 옵션에 대해 생성한 SSL/TLS 키를 포함하십시오.

server.csr.pem 파일을 사용하여 다음 섹션에서 SSL/TLS 인증서를 생성합니다.

다음 명령은 언더클라우드 또는 오버클라우드에 대한 인증서를 생성합니다.

$ sudo openssl ca -config openssl.cnf -extensions v3_req -days 3650 -in server.csr.pem -out server.crt.pem -cert ca.crt.pem -keyfile ca.key.pem

이 명령은 다음을 사용합니다.

그러면 server.crt.pem 이라는 인증서가 생성됩니다. 9.4절. “SSL/TLS 키 생성” 의 SSL/TLS 키와 함께 이 인증서를 사용하여 SSL/TLS를 활성화합니다.

Heat 템플릿 컬렉션에서 enable-tls.yaml 환경 파일을 복사합니다.

$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/enable-tls.yaml ~/templates/.

이 파일을 편집하고 해당 매개변수에 대해 다음과 같이 변경합니다.

인증서 서명자가 오버클라우드 이미지의 기본 신뢰 저장소에 없는 경우 인증 기관을 오버클라우드 이미지에 삽입해야 합니다. heat 템플릿 컬렉션에서 inject-trust-anchor.yaml 환경 파일을 복사합니다.

$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/inject-trust-anchor.yaml ~/templates/.

이 파일을 편집하고 해당 매개변수에 대해 다음과 같이 변경합니다.

DNS 호스트 이름을 사용하여 SSL/TLS를 통해 오버클라우드에 액세스하는 경우 새 환경 파일(~/templates/cloudname.yaml)을 생성하여 오버클라우드 끝점의 호스트 이름을 정의합니다. 다음 매개변수를 사용합니다.

이 파일의 내용 예:

parameter_defaults:
  CloudName: overcloud.example.com
  DnsServers: ["10.0.0.254"]

배포 명령(openstack overcloud deploy)은 -e 옵션을 사용하여 환경 파일을 추가합니다. 이 섹션의 환경 파일을 다음 순서로 추가합니다.

예를 들면 다음과 같습니다.

$ openstack overcloud deploy --templates [...] -e /home/stack/templates/enable-tls.yaml -e ~/templates/cloudname.yaml -e ~/templates/inject-trust-anchor.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/tls-endpoints-public-dns.yaml

나중에 인증서를 업데이트해야 하는 경우:

새 인증서 콘텐츠가 준비되면 배포 명령을 재실행합니다. 예를 들면 다음과 같습니다.

$ openstack overcloud deploy --templates [...] -e /home/stack/templates/enable-tls.yaml -e ~/templates/cloudname.yaml -e ~/templates/inject-trust-anchor.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/tls-endpoints-public-dns.yaml

이 섹션에서는 NFS 공유를 사용하도록 Overcloud 구성에 대해 설명합니다. 설치 및 구성 프로세스는 코어 Heat 템플릿 컬렉션의 기존 환경 파일을 수정하는 방법을 기반으로 합니다.

코어 heat 템플릿 컬렉션에는 /usr/share/openstack-tripleo-heat-templates/environments/ 의 환경 파일 세트가 포함되어 있습니다. 이러한 환경 템플릿은 director에서 생성한 Overcloud에서 지원되는 일부 기능을 사용자 정의하는 데 도움이 됩니다. 여기에는 스토리지를 구성하는 데 도움이 되는 환경 파일이 포함됩니다. 이 파일은 /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml 에 있습니다. 이 파일을 stack 사용자의 템플릿 디렉터리에 복사합니다.

$ cp /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml ~/templates/.

환경 파일에는 OpenStack 블록 및 이미지 스토리지 구성 요소인 cinder 및 glance에 대한 다양한 스토리지 옵션을 구성하는 데 도움이 되는 일부 매개 변수가 포함되어 있습니다. 이 예에서는 NFS 공유를 사용하도록 Overcloud를 구성합니다. 다음 매개변수를 수정합니다.

환경 파일의 옵션은 다음과 유사합니다.

parameter_defaults:
  CinderEnableIscsiBackend: false
  CinderEnableRbdBackend: false
  CinderEnableNfsBackend: true
  NovaEnableRbdBackend: false
  GlanceBackend: 'file'

  CinderNfsMountOptions: 'rw,sync'
  CinderNfsServers: '192.0.2.230:/cinder'

  GlanceNfsEnabled: true
  GlanceNfsShare: '192.0.2.230:/glance'
  GlanceNfsOptions: 'rw,sync,context=system_u:object_r:glance_var_lib_t:s0'

이러한 매개변수는 heat 템플릿 컬렉션의 일부로 통합됩니다. 이와 같이 설정하면 cinder 및 glance가 사용할 NFS 마운트 지점 두 개가 생성됩니다.

Overcloud 생성에 포함하기 위해 이 파일을 저장합니다.

director는 Red Hat Ceph Storage를 Overcloud에 통합하는 두 가지 주요 방법을 제공합니다.

Overcloud Ceph Storage 구성에 대한 자세한 내용은 두 시나리오에 대한 전체 지침은 오버클라우드 용 Red Hat Ceph Storage 전용 가이드를 참조하십시오.

director에는 타사 스토리지 공급자를 구성하는 데 도움이 되는 몇 가지 환경 파일이 포함되어 있습니다. 여기에는 다음이 포함됩니다.

컨테이너화된 컴퓨팅 Heat 템플릿의 리소스 스택을 수용하려면 언더클라우드에서 OpenStack Orchestration(heat) 스택의 스택 수준을 늘려야 합니다. 스택 깊이를 늘리려면 다음 단계를 사용합니다.

docker.yaml 파일은 컨테이너화된 컴퓨팅 노드 구성의 기본 환경 파일입니다. resource_registry 의 항목이 포함되어 있습니다.

resource_registry:
  OS::TripleO::ComputePostDeployment: ../docker/compute-post.yaml
  OS::TripleO::NodeUserData: ../docker/firstboot/install_docker_agents.yaml

docker.yaml 파일에는 컴퓨팅 노드를 프로비저닝할 때 표준 overcloud-full 이미지를 다른 이미지(atomic-image)로 대체하는 NovaImage 라는 매개변수 가 포함되어 있습니다. 이 새 이미지 업로드 방법은 11.3절. “Atomic Host 이미지 업로드” 에서 참조하십시오.

docker.yaml 파일에는 또한 컴퓨팅 노드 서비스에 사용할 Docker 레지스트리 및 이미지를 정의하는 parameter_defaults 섹션이 포함되어 있습니다. 이 섹션에서는 기본 registry.access.redhat.com 대신 로컬 레지스트리를 사용하도록 수정할 수 있습니다. 로컬 레지스트리 구성에 대한 자세한 내용은 11.4절. “로컬 레지스트리 사용” 를 참조하십시오.

director에는 이미지 저장소로 atomic-image 로 가져온 Red Hat Enterprise Linux 7 Atomic Host의 Cloud Image 사본이 필요합니다. 이는 오버클라우드 생성 단계에서 컴퓨팅 노드에 기본 OS에 이 이미지가 필요하기 때문입니다.

Red Hat Enterprise Linux 7 Atomic Host 제품 페이지( https://access.redhat.com/downloads/content/271/ver=/rhel---7/7.2.2-2/x86_64/product-software)에서 Cloud Image 사본을 다운로드하여 stack 사용자의 홈 디렉터리의 images 하위 디렉터리에 저장합니다.https://access.redhat.com/downloads/content/271/ver=/rhel---7/7.2.2-2/x86_64/product-software

이미지 다운로드가 완료되면 이미지를 stack 사용자로 director로 가져옵니다.

$ glance image-create --name atomic-image --file ~/images/rhel-atomic-cloud-7.2-12.x86_64.qcow2 --disk-format qcow2 --container-format bare

그러면 이미지를 다른 Overcloud 이미지와 함께 가져옵니다.

$ glance image-list
+--------------------------------------+------------------------+
| ID                                   | Name                   |
+--------------------------------------+------------------------+
| 27b5bad7-f8b2-4dd8-9f69-32dfe84644cf | atomic-image           |
| 08c116c6-8913-427b-b5b0-b55c18a01888 | bm-deploy-kernel       |
| aec4c104-0146-437b-a10b-8ebc351067b9 | bm-deploy-ramdisk      |
| 9012ce83-4c63-4cd7-a976-0c972be747cd | overcloud-full         |
| 376e95df-c1c1-4f2a-b5f3-93f639eb9972 | overcloud-full-initrd  |
| 0b5773eb-4c64-4086-9298-7f28606b68af | overcloud-full-vmlinuz |
+--------------------------------------+------------------------+

기본 구성에서는 이미지 다운로드를 위해 Red Hat의 컨테이너 레지스트리를 사용합니다. 그러나 선택 옵션으로 로컬 레지스트리를 사용하여 Overcloud 생성 프로세스 중에 대역폭을 보존할 수 있습니다.

기존 로컬 레지스트리를 사용하거나 새 레지스트리를 설치할 수 있습니다. 새 레지스트리를 설치하려면 컨테이너 시작하기의 "Docker Formatted 컨테이너 이미지 시작하기" 의 지침을 사용하십시오.

필요한 이미지를 레지스트리로 가져옵니다.

$ sudo docker pull registry.access.redhat.com/rhosp10_tech_preview/openstack-nova-compute:latest
$ sudo docker pull registry.access.redhat.com/rhosp10_tech_preview/openstack-data:latest
$ sudo docker pull registry.access.redhat.com/rhosp10_tech_preview/openstack-nova-libvirt:latest
$ sudo docker pull registry.access.redhat.com/rhosp10_tech_preview/openstack-neutron-openvswitch-agent:latest
$ sudo docker pull registry.access.redhat.com/rhosp10_tech_preview/openstack-openvswitch-vswitchd:latest
$ sudo docker pull registry.access.redhat.com/rhosp10_tech_preview/openstack-openvswitch-db-server:latest
$ sudo docker pull registry.access.redhat.com/rhosp10_tech_preview/openstack-heat-docker-agents:latest

이미지를 가져온 후 적절한 레지스트리 호스트로 태그를 지정합니다.

$ sudo docker tag registry.access.redhat.com/rhosp10_tech_preview/openstack-nova-compute:latest localhost:8787/registry.access.redhat.com/openstack-nova-compute:latest
$ sudo docker tag registry.access.redhat.com/rhosp10_tech_preview/openstack-data:latest localhost:8787/registry.access.redhat.com/openstack-data:latest
$ sudo docker tag registry.access.redhat.com/rhosp10_tech_preview/openstack-nova-libvirt:latest localhost:8787/registry.access.redhat.com/openstack-nova-libvirt:latest
$ sudo docker tag registry.access.redhat.com/rhosp10_tech_preview/openstack-neutron-openvswitch-agent:latest localhost:8787/registry.access.redhat.com/openstack-neutron-openvswitch-agent:latest
$ sudo docker tag registry.access.redhat.com/rhosp10_tech_preview/openstack-openvswitch-vswitchd:latest localhost:8787/registry.access.redhat.com/openstack-openvswitch-vswitchd:latest
$ sudo docker tag registry.access.redhat.com/rhosp10_tech_preview/openstack-openvswitch-db-server:latest localhost:8787/registry.access.redhat.com/openstack-openvswitch-db-server:latest
$ sudo docker tag registry.access.redhat.com/rhosp10_tech_preview/openstack-heat-docker-agents:latest localhost:8787/registry.access.redhat.com/openstack-heat-docker-agents:latest

레지스트리에 푸시합니다.

$ sudo docker push localhost:8787/registry.access.redhat.com/openstack-nova-compute:latest
$ sudo docker push localhost:8787/registry.access.redhat.com/openstack-data:latest
$ sudo docker push localhost:8787/registry.access.redhat.com/openstack-nova-libvirt:latest
$ sudo docker push localhost:8787/registry.access.redhat.com/openstack-neutron-openvswitch-agent:latest
$ sudo docker push localhost:8787/registry.access.redhat.com/openstack-openvswitch-vswitchd:latest
$ sudo docker push localhost:8787/registry.access.redhat.com/openstack-openvswitch-db-server:latest
$ sudo docker push localhost:8787/registry.access.redhat.com/openstack-heat-docker-agents:latest

templates 하위 디렉터리에 기본 docker.yaml 환경 파일의 사본을 생성합니다.

$ cp /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml ~/templates/.

파일을 편집하고 절대 경로를 사용하도록 resource_registry 를 수정합니다.

resource_registry:
  OS::TripleO::ComputePostDeployment: /usr/share/openstack-tripleo-heat-templates/docker/compute-post.yaml
  OS::TripleO::NodeUserData: /usr/share/openstack-tripleo-heat-templates/docker/firstboot/install_docker_agents.yaml

DockerNamespace in parameter_defaults 를 레지스트리 URL로 설정합니다. DockerNamespaceIsRegistry 를 true 로 설정합니다. 예를 들면 다음과 같습니다.

parameter_defaults:
  DockerNamespace: registry.example.com:8787/registry.access.redhat.com
  DockerNamespaceIsRegistry: true

이제 로컬 레지스트리에 필요한 Docker 이미지가 있고 컨테이너화된 Compute 구성이 해당 레지스트리를 사용하도록 설정되어 있습니다.

Overcloud 생성을 실행하는 경우 openstack overcloud deploy 명령과 함께 컨테이너화된 컴퓨팅 노드의 기본 환경 파일(docker.yaml)과 네트워크 환경 파일(docker-network.yaml)을 포함합니다. 예를 들면 다음과 같습니다.

$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/docker-network.yaml [OTHER OPTIONS] ...

컨테이너화된 컴퓨팅 노드는 네트워크 분리와 함께 Overcloud에서 작동합니다. 또한 네트워크 격리 파일(docker-network-isolation.yaml)과 함께 기본 환경 파일이 필요합니다. 7장. 네트워크 격리 에서 네트워크 격리 파일 이전에 이러한 파일을 추가하십시오. 예를 들면 다음과 같습니다.

openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/docker-network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml [OTHER OPTIONS] ...

director는 컨테이너화된 컴퓨팅 노드를 사용하여 Overcloud를 생성합니다.

모니터링 툴은 Red Hat OpenStack Platform 오버클라우드 노드에 배포된 클라이언트와 함께 클라이언트-서버 모델을 사용합니다. Fluentd 서비스는 클라이언트 측 중앙 집중식 로깅(CL)을 제공하며 Sensu 클라이언트 서비스는 클라이언트 측 가용성 모니터링(AM)을 제공합니다.

12.1.1. 중앙 집중식 로깅

중앙 집중식 로깅을 사용하면 전체 OpenStack 환경에서 로그를 볼 수 있는 하나의 중앙 위치가 있습니다. 이러한 로그는 syslog 및 감사 로그 파일, RabbitMQ 및 MariaDB와 같은 인프라 구성 요소, Identity, Compute 등과 같은 OpenStack 서비스와 같은 운영 체제에서 제공됩니다.

중앙 집중식 로깅 툴체는 다음을 포함한 여러 구성 요소로 구성됩니다.

• 로그 수집 에이전트(Fluentd)
• 로그 릴레이/Transformer(Fluentd)
• 데이터 저장소(Elasticsearch)
• API/Presentation Layer (Kibana)

참고

director는 중앙 집중식 로깅을 위한 서버 측 구성 요소를 배포하지 않습니다. Red Hat은 로그 집계기로 실행되는 플러그인이 포함된 Elasticsearch 데이터베이스, Kibana 및 Fluentd를 포함한 서버 측 구성 요소를 지원하지 않습니다.

중앙 집중식 로깅 구성 요소와 상호 작용은 다음 다이어그램에 있습니다.

참고

Blue에 표시된 항목은 Red Hat에서 지원하는 구성 요소를 나타냅니다.

그림 12.1. 높은 수준의 중앙 집중식 로깅 아키텍처

그림 12.2. Red Hat OpenStack Platform을 위한 단일 노드 배포

그림 12.3. Red Hat OpenStack Platform용 HA 배포

12.1.2. 가용성 모니터링

가용성 모니터링을 사용하면 전체 OpenStack 환경에서 모든 구성 요소의 고급 기능을 모니터링할 수 있습니다.

가용성 모니터링 툴체인은 다음을 포함한 여러 구성 요소로 구성됩니다.

• 모니터링 에이전트(Sensu 클라이언트)
• Monitoring Relay/Proxy (RabbitMQ)
• 모니터링 컨트롤러/서버(Sensu 서버)
• API/Presentation Layer (Uchiwa)

참고

director는 가용성 모니터링을 위한 서버 측 구성 요소를 배포하지 않습니다. Red Hat은 Uchiwa, Sensu Server, Sensu API 및 RabbitMQ, 모니터링 노드에서 실행되는 Redis 인스턴스를 비롯한 서버 측 구성 요소를 지원하지 않습니다.

가용성 모니터링 구성 요소와 상호 작용은 다음 다이어그램에 있습니다.

참고

Blue에 표시된 항목은 Red Hat에서 지원하는 구성 요소를 나타냅니다.

그림 12.4. 높은 수준의 가용성 모니터링 아키텍처

그림 12.5. Red Hat OpenStack Platform을 위한 단일 노드 배포

그림 12.6. Red Hat OpenStack Platform용 HA 배포

오버클라우드를 배포하기 전에 각 클라이언트에 적용할 구성 설정을 확인해야 합니다. director의 Heat 템플릿 컬렉션에서 예제 환경 파일을 복사하여 환경에 맞게 수정합니다.

resource_registry:
  OS::TripleO::Services::FluentdClient: ../puppet/services/logging/fluentd-client.yaml

parameter_defaults:
  LoggingServers:
    - host: log0.example.com
      port: 24224
    - host: log1.example.com
      port: 24224

## (note the use of port 24284 for ssl connections)

resource_registry:
  OS::TripleO::Services::FluentdClient: ../puppet/services/logging/fluentd-client.yaml

parameter_defaults:
  LoggingServers:
    - host: 192.0.2.11
      port: 24284
  LoggingUsesSSL: true
  LoggingSharedKey: secret
  LoggingSSLCertificate: |
    -----BEGIN CERTIFICATE-----
    ...certificate data here...
    -----END CERTIFICATE-----

resource_registry:
  OS::TripleO::Services::SensuClient: ../puppet/services/monitoring/sensu-client.yaml

parameter_defaults:
  MonitoringRabbitHost: 10.10.10.10
  MonitoringRabbitPort: 5672
  MonitoringRabbitUserName: sensu
  MonitoringRabbitPassword: sensu
  MonitoringRabbitUseSSL: false
  MonitoringRabbitVhost: "/sensu"
  SensuClientCustomConfig:
    api:
      warning: 10
      critical: 20

$ openstack overcloud deploy --templates  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e network-environment.yaml -e ~/templates/monitoring-environment.yaml -e ~/templates/logging-environment.yaml --control-scale 3 --compute-scale 1 --ntp-server 192.168.122.10

opstools-ansible 플레이북을 사용하여 Red Hat Enterprise Linux 7에 서버 측 구성 요소를 설치할 수 있습니다. 이러한 서버 측 구성 요소에는 Red Hat 지원 클라이언트 측 구성 요소를 보완하는 가용성 모니터링 및 중앙 집중식 로깅 서비스가 포함됩니다. 가장 테스트된 opstools-ansible 시나리오는 CentOS 7에 서버 측 구성 요소를 배포하는 것입니다. 자세한 지침은 README.md:https://github.com/centos-opstools/opstools-ansible에서 확인할 수 있습니다.

Sensu 스택 인프라에 대한 자세한 내용은 Sensu 설명서를 참조하십시오. https://sensuapp.org/docs/latest/overview/architecture.html

Red Hat은 osops-tools-monitoring-oschecks 패키지에 검사 스크립트 세트를 제공합니다. 대부분의 검사 스크립트는 OpenStack 구성 요소에 대한 API 연결만 확인합니다. 그러나 특정 스크립트는 OpenStack Compute(nova), OpenStack Block Storage(cinder), OpenStack Image(glance), OpenStack Networking(neutron)에 대한 추가 OpenStack 리소스 테스트도 수행합니다. 예를 들어 OpenStack Identity(keystone) API 검사에서는 keystone 이 실행 중이면 다음과 같은 결과가 표시됩니다.

OK: Got a token, Keystone API is working.

Uchiwa 대시보드 배포가 있는 경우 Sensu 서버와 함께 사용하여 노드 상태를 검토할 수 있습니다.

이 예에서는 openstack-ceilometer-central 서비스의 모니터링을 테스트합니다.

각 핵심 OpenStack Platform 서비스에는 해당 구성 가능 서비스 템플릿에 방화벽 규칙이 포함되어 있습니다. 이렇게 하면 각 오버클라우드 노드에 대한 기본 방화벽 규칙 세트가 자동으로 생성됩니다.

오버클라우드 Heat 템플릿에는 추가 방화벽 관리에 도움이 되는 매개변수 세트가 포함되어 있습니다.

ManageFirewall 이 true 로 설정된 경우 배포에 대한 추가 방화벽 규칙을 생성할 수 있습니다. 오버클라우드 환경 파일에서 구성 후크를 사용하여 tripleo::firewall::firewall_rules hieradata를 설정합니다. 4.5절. “Puppet: 역할에 대한 Hieradata 사용자 지정” 이 hieradata는 방화벽 규칙 이름과 해당 매개변수를 키로 포함하는 해시이며, 모두 선택 사항입니다.

다음 예제는 방화벽 규칙 형식의 구문을 보여줍니다.

ExtraConfig:
  tripleo::firewall::firewall_rules:
    '300 allow custom application 1':
      port: 999
      proto: udp
      action: accept
    '301 allow custom application 2':
      port: 8081
      proto: tcp
      action: accept

ExtraConfig 를 통해 모든 노드에 두 개의 추가 방화벽 규칙이 적용됩니다.

director는 오버클라우드에 대한 기본 읽기 전용 SNMP 설정을 제공합니다. 네트워크 장치에 대해 학습하지 않은 사용자가 학습할 위험을 줄이기 위해 SNMP 문자열을 변경하는 것이 좋습니다.

오버클라우드 환경 파일에서 ExtraConfig 후크를 사용하여 다음 hieradata를 설정합니다.

예를 들면 다음과 같습니다.

parameter_defaults:
  ExtraConfig:
    snmp::ro_community: mysecurestring
    snmp::ro_community6: myv6securestring

이렇게 하면 모든 노드에서 읽기 전용 SNMP 커뮤니티 문자열이 변경됩니다.

오버클라우드에서 SSL/TLS를 활성화한 경우( 9장. 오버클라우드에서 SSL/TLS 활성화참조) HAProxy 구성에 사용되는 SSL/TLS 암호화 방식 및 규칙을 강화할 수 있습니다. 이는 POODLE 취약점과 같은 SSL/TLS 취약점을 방지하는 데 도움이 됩니다.

오버클라우드 환경 파일에서 ExtraConfig 후크를 사용하여 다음 hieradata를 설정합니다.

예를 들면 다음 암호화 방식 및 규칙을 사용할 수 있습니다.

다음 콘텐츠를 사용하여 환경 파일을 생성합니다.

parameter_defaults:
  ExtraConfig:
    tripleo::haproxy::ssl_cipher_suite: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
    tripleo::haproxy::ssl_options: no-sslv3 no-tls-tickets

오버클라우드 생성과 함께 이 환경 파일을 포함합니다.

Overcloud는 여러 컨트롤러를 고가용성 클러스터로 사용하여 OpenStack 서비스에 대한 최대 작동 성능을 보장합니다. 또한 클러스터는 OpenStack 서비스에 대한 액세스를 위해 부하 분산을 제공하여 트래픽을 컨트롤러 노드에 균등하게 분산하고 각 노드의 서버 과부하를 줄입니다. 이 배포를 수행하기 위해 외부 로드 밸런서를 사용할 수도 있습니다. 예를 들어 조직에서 자체 하드웨어 기반 로드 밸런서를 사용하여 컨트롤러 노드에 대한 트래픽 배포를 처리할 수 있습니다.

외부 로드 밸런싱 구성에 대한 자세한 내용은 전체 지침은 External Load Balancing for the Overcloud 가이드를 참조하십시오.

기본적으로 Overcloud는 IPv4(Internet Protocol version 4)를 사용하여 서비스 끝점을 구성합니다. 그러나 Overcloud는 IPv6 인프라를 지원하는 조직에 유용한 IPv6(Internet Protocol 버전 6) 엔드 포인트를 지원합니다. director에는 IPv6 기반 Overcloud 생성에 도움이 되는 환경 파일 세트가 포함되어 있습니다.

오버클라우드에서 IPv6 설정에 대한 자세한 내용은 전체 지침은 IPv6 Networking for the Overcloud 가이드를 참조하십시오.