7.3. 구성 가능 서비스

구성 가능 노드 아키텍처에 대한 다음 지침 및 제한 사항을 확인합니다.

Pacemaker에서 관리하지 않는 서비스의 경우 다음을 수행합니다.

Pacemaker에서 관리하는 서비스의 경우 다음을 수행합니다.

일반 제한 사항:

코어 heat 템플릿 컬렉션에는 구성 가능 서비스 템플릿의 두 세트가 포함되어 있습니다.

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

description: >
  NTP service deployment using puppet, this YAML file
  creates the interface between the HOT template
  and the puppet manifest that actually installs
  and configure NTP.

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

일부 리소스는 기본 구성 가능 서비스 템플릿을 직접 사용합니다.

resource_registry:
  ...
  OS::TripleO::Services::Ntp: puppet/services/time/ntp.yaml
  ...

그러나 핵심 서비스에는 컨테이너가 필요하며 컨테이너화된 서비스 템플릿을 사용합니다. 예를 들어 keystone 컨테이너화된 서비스는 다음을 사용합니다.

resource_registry:
  ...
  OS::TripleO::Services::Keystone: docker/services/keystone.yaml
  ...

이러한 컨테이너화된 템플릿은 일반적으로 Puppet 구성을 포함하기 위해 기본 템플릿으로 다시 참조합니다. 예를 들어 docker/services/keystone.yaml 템플릿은 기본 템플릿의 출력을 KeystoneBase 매개변수에 저장합니다.

KeystoneBase:
  type: ../../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.

roles_data.yaml 파일에서 각 사용자 지정 역할에 대한 기본 서비스를 정의합니다. 예를 들어 기본 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 파일의 서비스 목록을 재정의할 수 있습니다.

서비스를 추가하거나 제거하는 기본 방법은 노드 역할에 대한 기본 서비스 목록 복사본을 생성한 다음 서비스를 추가하거나 제거하는 것입니다. 예를 들어 컨트롤러 노드에서 OpenStack Orchestration(heat)을 제거하려고 할 수 있습니다. 이 경우 기본 역할 디렉터리의 사용자 지정 사본을 생성합니다.

$ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.

~/roles/Controller.yaml 파일을 편집하고 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

새 roles_data 파일을 생성합니다. 예를 들면 다음과 같습니다.

$ openstack overcloud roles generate -o roles_data-no_heat.yaml \
  --roles-path ~/roles \
  Controller Compute Networker

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

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

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

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

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

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

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

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

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

- name: Generic

사용자 지정 roles_data 파일(roles_data_with_generic.yaml)에 역할을 포함합니다. 기존 Controller 및 Compute 역할을 유지해야 합니다.

또한 환경 파일(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 노드 1개가 있는 3-노드 환경이 배포됩니다.