Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

파트너 통합

Red Hat OpenStack Platform 8

OpenStack Platform 환경에서 인증된 타사 소프트웨어 및 하드웨어 통합

OpenStack Documentation Team

초록

이 가이드에서는 인증된 타사 구성 요소를 Red Hat OpenStack Platform 환경에 통합하는 방법에 대한 지침을 제공합니다. 여기에는 오버클라우드 이미지에 이러한 구성 요소를 추가하고 director를 사용하여 배포 구성을 생성하는 작업이 포함됩니다.

1장. 소개
링크 복사

이 문서는 Red Hat OpenStack Platform 파트너가 OpenStack Platform 환경의 배포 라이프사이클을 설치하고 관리하는 데 사용되는 툴로 Red Hat OpenStack Platform director와 솔루션을 통합할 수 있도록 돕기 위해 작성되었습니다. director와의 통합을 통해 기술을 원활하게 채택할 수 있습니다. 리소스를 최적화하고 배포 시간을 단축하고 라이프사이클 관리 비용을 절감할 수 있는 광범위한 이점을 찾을 수 있습니다.

OpenStack Platform director 통합은 기존 엔터프라이즈 관리 시스템 및 프로세스와의 풍부한 통합을 제공하기 위한 강력한 전환입니다. Red Hat 제품 포트폴리오 내에서 CloudForms와 같은 툴은 director의 통합을 파악하고 서비스 배포 관리를 위한 광범위한 노출을 제공할 것으로 예상됩니다.

1.1. 파트너 통합 개요
링크 복사

이 가이드에서는 파트너가 director가 Overcloud의 일부로 구성하는 방식으로 소프트웨어 및 하드웨어 솔루션을 통합할 수 있도록 지원하는 것을 목표로 합니다. 이 작업은 특정 통합 작업을 수행하는 방법을 보여주는 여러 섹션으로 분류된 워크플로우를 따릅니다.

  • 아키텍처 - director가 오버클라우드 생성 및 설정을 수행하는 데 사용하는 몇 가지 기술을 검토합니다.
  • 오버클라우드 이미지 - director는 노드 유형의 기반으로 Overcloud의 각 노드에 기본 이미지를 씁니다. 이 섹션에서는 드라이버 또는 소프트웨어를 포함할 수 있도록 배포 전에 이러한 이미지를 수정하는 방법을 설명합니다. 이는 업스트림에 기여하기 전에 드라이버 및 구성을 테스트하는 데 유용합니다.
  • 설정 - director는 주로 Puppet 모듈을 사용하여 Overcloud에서 각 서비스를 구성합니다. 이 섹션에서는 Puppet 모듈이 작동하는 방식과 이를 사용하여 Overcloud를 구성하는 방법을 보여줍니다.
  • 오케스트레이션 - director는 Heat 템플릿 세트를 사용하여 Overcloud를 생성 및 구성합니다. 여기에는 사용자 지정 환경 파일과 Heat 템플릿이 포함되어 Overcloud 구성 동작을 수정할 수도 있습니다. 이 섹션에서는 Overcloud의 사용자 지정 구성을 활성화하기 위해 이러한 템플릿을 생성하는 방법을 중점적으로 설명합니다. 여기에는 이전 장의 Puppet 구성도 포함됩니다.
  • 통합 지점 - director가 배포하는 이미지에는 구성에 필요한 OpenStack 구성 요소 및 일련의 Puppet 모듈이 포함되어 있습니다. 이 섹션에서는 구성 요소 드라이버 및 Puppet 모듈을 제공하기 위한 업스트림 프로젝트 중 일부에 대해 설명합니다. 이를 통해 Red Hat은 이를 테스트하고 향후 Red Hat OpenStack Platform 배포에 포함할 수 있습니다.
  • 예 - 이 장에서는 이전 장의 지식을 바탕으로 실제 공급 업체가 현재 director를 사용하여 프로젝트를 Overcloud에 통합하는 방법을 보여줍니다. 여기에는 몇 가지 실용적인 네트워크 및 스토리지 예제가 포함됩니다. 이 섹션은 유사한 벤더가 Red Hat OpenStack Platform의 에코시스템에 자체 제품을 통합하는 데 유용합니다.

1.2. 파트너 통합 요구 사항
링크 복사

의미 있는 통합 작업을 director로 완료하기 전에 여러 사전 요구 사항을 충족해야 합니다. 이러한 요구 사항은 기술 통합에 국한되지 않으며 다양한 수준의 파트너 솔루션 문서도 포함됩니다. 목표는 Red Hat 엔지니어링, 파트너 관리자 및 지원 리소스가 작업을 효과적으로 지원할 수 있도록 전체 통합을 완전히 공유하는 것입니다.

첫 번째 요구 사항은 Red Hat OpenStack Platform 솔루션 인증과 관련이 있습니다. OpenStack Platform director에 포함되려면 파트너 솔루션을 먼저 Red Hat OpenStack Platform으로 인증해야 합니다.

2장. 아키텍처
링크 복사

director는 기본 OpenStack API를 사용하여 OpenStack 환경 자체를 구성, 배포 및 관리합니다. 즉, director와 통합하려면 이러한 기본 OpenStack API 및 지원 구성 요소와 통합해야 합니다. 이러한 API를 활용할 때의 주요 이점은 문서화가 잘 되어 있으며, 업스트림에서 광범위한 통합 테스트를 거치고, 성숙하고, OpenStack에 대한 기본 지식이 있는 사람들을 위해 director가 더 쉽게 작동하는 방식을 이해하는 것입니다. 또한 director는 핵심 OpenStack 기능 개선 사항, 보안 패치 및 버그 수정을 자동으로 상속합니다.

Red Hat OpenStack Platform director는 완전한 OpenStack 환경을 설치하고 관리하기 위한 툴셋입니다. 주로 "OpenStack-On-OpenStack"의 약어인 OpenStack 프로젝트 TripleO를 기반으로 합니다. 이 프로젝트는 OpenStack 구성 요소를 활용하여 완전히 작동하는 OpenStack 환경을 설치합니다. 여기에는 OpenStack 노드로 사용할 베어 메탈 시스템을 프로비저닝하고 제어하는 새로운 OpenStack 구성 요소가 포함됩니다. 따라서 단순하면서도 강력한 완전한 Red Hat OpenStack Platform 환경을 간단하게 설치할 수 있습니다.

Red Hat OpenStack Platform director는 Undercloud와 Overcloud의 두 가지 주요 개념을 사용합니다. 이 director 자체는 단일 시스템 OpenStack 환경을 구성하는 OpenStack 구성 요소의 하위 집합(예: Undercloud)으로 구성됩니다. Undercloud는 워크로드를 실행하기 위한 프로덕션 수준 클라우드를 생성할 수 있는 관리 시스템 역할을 합니다. 이 프로덕션 수준 클라우드는 Overcloud입니다. Overcloud 및 Undercloud에 대한 자세한 내용은 Director 설치 및 사용 가이드를 참조하십시오.

director는 Overcloud 구성 생성을 위한 툴, 유틸리티 및 예제 템플릿이 포함되어 있습니다. director는 설정 데이터, 매개 변수 및 네트워크 토폴로지 정보를 캡처한 다음 Ironic, Heat, Puppet과 같은 구성 요소와 함께 이 정보를 사용하여 Overcloud 설치를 오케스트레이션합니다.

파트너는 다양한 요구 사항이 있습니다. director의 아키텍처를 이해하면 주어진 통합 작업의 구성 요소를 이해하는 데 도움이 됩니다.

2.1. 핵심 구성 요소
링크 복사

이 섹션에서는 Red Hat OpenStack Platform director의 핵심 구성 요소 중 일부를 살펴보고 Overcloud 생성에 기여하는 방법을 설명합니다.

2.1.1. Ironic
링크 복사

Ironic은 셀프 서비스 프로비저닝을 통해 최종 사용자에게 전용 베어 메탈 호스트를 제공합니다. director는 Ironic을 사용하여 오버클라우드에서 베어 메탈 하드웨어의 라이프사이클을 관리합니다. Ironic에는 베어 메탈 노드를 정의하는 자체 기본 API가 있습니다. director를 사용하여 OpenStack 환경을 프로비저닝하려는 관리자는 특정 드라이버를 사용하여 Ironic에 노드를 등록해야 합니다. 주요 지원되는 드라이버는 대부분의 하드웨어에 IPMI 전원 관리 기능에 대한 지원이 포함되어 있으므로 IPMI(Intelligent Platform Management Interface)입니다. 그러나 Ironic에는 HP iLO, Cisco UCS 또는 Dell DRAC와 같은 벤더별도 포함되어 있습니다. Ironic은 노드의 전원 관리를 제어하고 검색 메커니즘을 사용하여 하드웨어 정보 또는 팩트 를 수집합니다. director는 검색 프로세스에서 얻은 정보를 사용하여 노드를 컨트롤러 노드, 컴퓨팅 노드, 스토리지 노드와 같은 다양한 OpenStack 환경 역할과 일치시킵니다. 예를 들어 10개의 디스크가 있는 검색된 노드는 스토리지 노드로 프로비저닝될 가능성이 큽니다.

하드웨어에 대한 director 지원이 필요한 파트너는 Ironic에 드라이버 지원 서비스가 있어야 합니다.

2.1.2. Heat
링크 복사

Heat는 애플리케이션 스택 오케스트레이션 엔진 역할을 합니다. 이를 통해 조직은 클라우드에 배포하기 전에 지정된 애플리케이션의 요소를 정의할 수 있습니다. 여기에는 구성을 위한 매개변수 세트와 함께 여러 인프라 리소스(예: 인스턴스, 네트워크, 스토리지 볼륨, 탄력적 IP 등)가 포함된 스택 템플릿을 생성해야 합니다. Heat는 지정된 종속성 체인을 기반으로 이러한 리소스를 생성하고, 가용성을 모니터링하며, 필요한 경우 확장합니다. 이러한 템플릿을 사용하면 애플리케이션 스택을 이식할 수 있고 예상 결과를 반복할 수 있습니다.

director는 기본 OpenStack Heat API를 사용하여 Overcloud 배포와 관련된 리소스를 프로비저닝하고 관리합니다. 여기에는 노드 역할별로 프로비저닝할 노드 수, 각 노드에 대해 구성할 소프트웨어 구성 요소, director에서 이러한 구성 요소 및 노드 유형을 구성하는 순서와 같은 정확한 세부 정보가 포함됩니다. director는 또한 Heat를 사용하여 배포 문제를 해결하고 배포 후 쉽게 변경합니다.

다음 예제는 컨트롤러 노드의 매개변수를 정의하는 Heat 템플릿의 스니펫입니다. 

NeutronExternalNetworkBridge:
    description: Name of bridge used for external network traffic.
    type: string
    default: 'br-ex'
NeutronBridgeMappings:
    description: >
      The OVS logical->physical bridge mappings to use. See the Neutron
      documentation for details. Defaults to mapping br-ex - the external
      bridge on hosts - to a physical name 'datacentre' which can be used
      to create provider networks (and we use this for the default floating
      network) - if changing this either use different post-install network
      scripts or be sure to keep 'datacentre' as a mapping network name.
    type: string
    default: "datacentre:br-ex"
Copy to Clipboard Toggle word wrap

Heat는 director에 포함된 템플릿을 사용하여 노드의 전원을 켜기 위해 Ironic이라는 호출을 포함하는 Overcloud를 쉽게 생성할 수 있습니다. 표준 Heat 툴을 사용하여 진행 중인 Overcloud의 리소스(및 해당 상태)를 볼 수 있습니다. 예를 들어 Heat 툴을 사용하여 Overcloud를 중첩된 애플리케이션 스택으로 표시할 수 있습니다.

Heat는 프로덕션 OpenStack 클라우드를 선언하고 생성하기 위한 포괄적이고 강력한 구문을 제공합니다. 그러나 파트너 통합을 위해서는 사전 이해와 성능이 필요합니다. 모든 파트너 통합 사용 사례에는 Heat 템플릿이 필요합니다.

2.1.3. Puppet
링크 복사

Puppet은 구성 관리 및 적용 툴입니다. 이는 시스템의 최종 상태를 설명하고 이러한 방식으로 유지하는 메커니즘으로 사용됩니다. 이 끝 상태를 Puppet 매니페스트에 정의합니다. Puppet은 다음 두 가지 모델을 지원합니다.

  • 매니페스트 형식의 명령이 로컬로 실행되는 독립 실행형 모드
  • Puppet Master라는 중앙 서버에서 매니페스트를 검색하는 서버 모드입니다.

관리자는 새 매니페스트를 노드에 업로드하고 로컬로 실행하거나 Puppet 마스터를 수정하여 클라이언트/서버 모델에서 변경하는 두 가지 방법을 변경합니다.

director의 여러 영역에서 Puppet을 사용합니다.

  • 언더클라우드 호스트에서 Puppet을 사용하여 undercloud.conf 에 명시된 구성에 따라 패키지를 설치 및 구성합니다.
  • openstack-puppet-modules 패키지를 기본 Overcloud 이미지에 삽입합니다. 이러한 Puppet 모듈은 배포 후 구성에 사용할 수 있습니다. 기본적으로 모든 OpenStack 서비스가 포함된 이미지를 생성하고 각 노드에 사용합니다.
  • Heat를 통해 추가 Puppet 매니페스트 및 매개변수를 노드에 제공하고 Overcloud 배포 후 구성을 적용합니다. 여기에는 활성화 및 시작할 서비스와 노드 유형에 따라 적용할 OpenStack 구성이 포함됩니다.

  • 노드에 Puppet hieradata 를 제공합니다. Puppet 모듈과 매니페스트는 매니페스트를 일관되게 유지하기 위해 사이트 또는 노드별 매개변수에서 무료로 제공됩니다. hieradata는 Puppet 모듈로 푸시하고 다른 영역에서 참조할 수 있는 매개 변수화된 값의 형태로 작동합니다. 예를 들어 매니페스트 내부에서 MySQL 암호를 참조하려면 이 정보를 hieradata로 저장하고 매니페스트 내에서 참조합니다.

    hieradata 보기: 

    [root@localhost ~]# grep mysql_root_password hieradata.yaml # View the data in the hieradata file
openstack::controller::mysql_root_password: ‘redhat123'
    Copy to Clipboard Toggle word wrap

    Puppet 매니페스트에서 이를 참조합니다. 

    [root@localhost ~]# grep mysql_root_password example.pp # Now referenced in the Puppet manifest
mysql_root_password  => hiera(‘openstack::controller::mysql_root_password')
    Copy to Clipboard Toggle word wrap

패키지 설치 및 서비스 사용이 필요한 파트너 통합 서비스는 요구 사항을 충족하기 위해 Puppet 모듈을 생성하는 것을 고려해야 합니다. 예를 들어 현재 Openstack Puppet 모듈을 가져오는 방법에 대한 자세한 내용은 4.2절. “OpenStack Puppet 모듈 가져오기” 을 참조하십시오.

2.1.4. tripleo 및 TripleO Heat 템플릿
링크 복사

앞에서 언급했듯이 director는 업스트림 TripleO 프로젝트를 기반으로 합니다. 이 프로젝트는 다음과 같은 OpenStack 서비스 세트를 결합합니다.

  • Overcloud 이미지 저장(Glance)
  • Overcloud 오케스트레이션(Heat)
  • 베어 메탈 머신 프로비저닝 (Ironic)

tripleo에는 Red Hat 지원 Overcloud 환경을 정의하는 Heat 템플릿 컬렉션도 포함되어 있습니다. director는 Heat를 사용하여 이 템플릿 컬렉션을 읽고 Overcloud 스택을 오케스트레이션합니다. Heat는 이러한 핵심 Heat 템플릿에서 특정 리소스에 대한 소프트웨어 설정도 시작합니다. 이 소프트웨어 구성은 일반적으로 Bash 스크립트 또는 Puppet 매니페스트입니다.

일반적인 소프트웨어 구성은 다음 두 가지 주요 Heat 리소스를 사용합니다.

  • 구성을 정의하는 리소스(OS::Heat::SoftwareConfig)
  • 노드에서 구성을 구현하는 리소스(OS::Heat::SoftwareDeployment)

예를 들어 Heat 템플릿 컬렉션에서 컴퓨팅 노드의 배포 후 템플릿(puppet/compute-post.yaml)에는 다음 섹션이 포함되어 있습니다. 

resources:

  ComputePuppetConfig:
    type: OS::Heat::SoftwareConfig
    properties:
      group: puppet
      options:
        enable_debug: {get_param: ConfigDebug}
      outputs:
      - name: result
      config:
        get_file: manifests/overcloud_compute.pp

  ComputePuppetDeployment:
    type: OS::Heat::StructuredDeployments
    properties:
      servers:  {get_param: servers}
      config: {get_resource: ComputePuppetConfig}
      input_values:
        update_identifier: {get_param: NodeConfigIdentifiers}
Copy to Clipboard Toggle word wrap

ComputePuppetConfig 리소스는 컴퓨팅 노드 구성이 포함된 Puppet 매니페스트(puppet/manifests/overcloud_compute.pp)를 로드합니다. ComputePuppetDeployment 리소스는 ComputePuppetConfig 의 구성을 Compute 노드로 정의하는서버 목록(server: {get_param: servers})에 적용합니다. Puppet이 전체 매니페스트를 성공적으로 적용하면 노드는 ComputePuppetDeployment 이 성공 또는 실패인지를 다시 보고합니다.

이 소프트웨어 구성 데이터 흐름은 director를 통해 타사 솔루션을 통합하는 방법을 이해하는 데 중요합니다. 이 가이드에서는 이 데이터 흐름을 사용하여 코어 구성 전후에 Overcloud에 사용자 지정 구성을 포함하는 방법을 보여줍니다. 사용자 지정 구성을 구현하는 데 사용되는 소프트웨어 구성 데이터 흐름의 예는 다음을 참조하십시오.

3장. 오버클라우드 이미지
링크 복사

Red Hat OpenStack Platform director는 Overcloud용 이미지를 제공합니다. 이 컬렉션의 QCOW 이미지에는 컴퓨팅, 컨트롤러 및 스토리지 노드와 같은 다양한 Overcloud 역할을 형성하는 기본 소프트웨어 구성 요소 세트가 포함되어 있습니다. 경우에 따라 필요에 맞게 Overcloud 이미지의 특정 측면을 수정하여 노드에 추가 구성 요소를 설치할 수 있습니다.

이 문서에서는 virt-customize 툴을 사용하여 기존 Overcloud 이미지를 수정하여 기존 컨트롤러 노드를 보강하는 일련의 작업에 대해 설명합니다. 예를 들어 이러한 절차를 사용하여 초기 이미지와 함께 제공되지 않는 추가 ml2 플러그인, Cinder 백엔드 또는 모니터링 에이전트를 설치할 수 있습니다.

3.1. 오버클라우드 이미지 가져오기
링크 복사

director에는 Overcloud 노드를 프로비저닝하기 위한 여러 디스크 이미지가 필요합니다. 여기에는 다음이 포함됩니다.

  • 검색 커널 및 램디스크 - PXE 부팅을 통해 베어 메탈 시스템 검색에 사용됩니다.
  • 배포 커널 및 램디스크 - 시스템 프로비저닝 및 배포에 사용됩니다.
  • Overcloud 커널, 램디스크 및 전체 이미지 - 노드의 하드 디스크에 기록된 기본 오버클라우드 시스템입니다.

Red Hat 고객 포털의 Red Hat OpenStack Platform 다운로드 페이지에서 https://access.redhat.com/downloads/content/191/ver=7/rhel---7/7/x86_64/product-downloads. 고객 포털의 이 위치에는 TAR 아카이브의 이미지가 포함되어 있습니다. 이러한 이미지 아카이브를 디렉터리 호스트(/home/ stack / images /)의 stack 사용자 홈에 있는 images 디렉터리에 다운로드하고 아카이브에서 이미지를 추출합니다. 

$ cd ~/images
$ for tarfile in *.tar; do tar -xf $tarfile; done
Copy to Clipboard Toggle word wrap

3.2. director에 virt-customize 설치
링크 복사

libguestfs-tools 패키지에는 virt-customize 툴이 포함되어 있습니다. rhel-7-server-rpms 리포지토리에서 libguestfs-tools 를 설치합니다. 

$ sudo yum install libguestfs-tools
Copy to Clipboard Toggle word wrap

3.3. 오버클라우드 이미지 검사
링크 복사

overcloud-full.qcow2 의 내용을 살펴보려고 할 수 있습니다. qemu-system-x86_64 명령을 사용하여 가상 머신 인스턴스를 생성합니다. 

$ sudo qemu-system-x86_64 --kernel overcloud-full.vmlinuz --initrd overcloud-full.initrd -m 1024 --append root=/dev/sda --enable-kvm overcloud-full.qcow2
Copy to Clipboard Toggle word wrap

또는 virt-manager 에서 다음 부팅 옵션을 사용합니다.

  • 커널 경로: /overcloud-full.vmlinuz
  • initrd 경로: /overcloud-full.initrd
  • 커널 인수: root=/dev/sda

3.4. 루트 암호 설정
링크 복사

이미지에 root 사용자의 암호를 설정합니다. 

$ virt-customize -a overcloud-full.qcow2 --root-password password:test
[  0.0] Examining the guest ...
[ 18.0] Setting a random seed
[ 18.0] Setting passwords
[ 19.0] Finishing off
Copy to Clipboard Toggle word wrap

이를 통해 콘솔을 통해 노드에 대한 관리 수준 액세스를 제공합니다.

3.5. 이미지 등록
링크 복사

사용자 지정과 관련된 Red Hat 리포지토리를 활성화하려면 이미지를 일시적으로 등록합니다. 

$ virt-customize -a overcloud-full.qcow2 --run-command 'subscription-manager register --username=[username] --password=[password]'
[  0.0] Examining the guest ...
[ 10.0] Setting a random seed
[ 10.0] Running: subscription-manager register --username=[username] --password=[password]
[ 24.0] Finishing off
Copy to Clipboard Toggle word wrap

[username] 및 [password] 를 Red Hat 고객 계정 세부 정보로 교체하십시오. 이렇게 하면 이미지에서 다음 명령이 실행됩니다. 

subscription-manager register --username=[username] --password=[password]
Copy to Clipboard Toggle word wrap

그러면 오버클라우드 이미지가 Red Hat Content Delivery Network에 등록됩니다.

3.6. 서브스크립션 연결 및 Red Hat 리포지토리 활성화
링크 복사

계정의 서브스크립션에서 풀 ID 목록을 찾습니다. 

$ sudo subscription-manager list
Copy to Clipboard Toggle word wrap

서브스크립션 풀 ID를 선택하고 이미지에 연결합니다. 

$ virt-customize -a overcloud-full.qcow2 --run-command 'subscription-manager attach --pool [subscription-pool]'
[  0.0] Examining the guest ...
[ 12.0] Setting a random seed
[ 12.0] Running: subscription-manager attach --pool [subscription-pool]
[ 52.0] Finishing off
Copy to Clipboard Toggle word wrap

[subscription-pool] 을 선택한 서브스크립션 풀 ID로 교체해야 합니다. 이렇게 하면 이미지에서 다음 명령이 실행됩니다. 

subscription-manager attach --pool [subscription-pool]
Copy to Clipboard Toggle word wrap

그러면 다음 명령을 사용하여 Red Hat 리포지토리를 활성화할 수 있는 풀이 이미지에 추가됩니다. 

$ subscription-manager repos --enable=[repo-id]
Copy to Clipboard Toggle word wrap

3.7. 사용자 정의 리포지토리 파일 복사
링크 복사

타사 소프트웨어를 이미지에 추가하려면 추가 리포지토리가 필요합니다. 예를 들어 다음은 OpenDaylight 리포지토리 콘텐츠를 사용하도록 구성이 포함된 리포지토리 파일의 예입니다. 

$ cat opendaylight.repo

[opendaylight]
name=OpenDaylight Repository
baseurl=https://nexus.opendaylight.org/content/repositories/opendaylight-yum-epel-6-x86_64/
gpgcheck=0
Copy to Clipboard Toggle word wrap

리포지토리 파일을 이미지에 복사합니다. 

$ virt-customize -a overcloud-full.qcow2 --upload opendaylight.repo:/etc/yum.repos.d/
[  0.0] Examining the guest ...
[ 12.0] Setting a random seed
[ 12.0] Copying: opendaylight.repo to /etc/yum.repos.d/
[ 13.0] Finishing off
Copy to Clipboard Toggle word wrap

copy-in 옵션은 Overcloud 이미지의 /etc/yum.repos.d/ 에 리포지토리 파일을 복사합니다.

중요: Red Hat은 인증되지 않은 벤더의 소프트웨어에 대한 지원을 제공하지 않습니다. 설치하려는 소프트웨어가 지원되는지 Red Hat 지원 담당자에게 확인하십시오.

3.8. RPM 설치
링크 복사

virt-customize 명령을 사용하여 이미지에 패키지를 설치합니다. 

$ virt-customize -a overcloud-full.qcow2 --install opendaylight
[  0.0] Examining the guest ...
[ 11.0] Setting a random seed
[ 11.0] Installing packages: opendaylight
[ 91.0] Finishing off
Copy to Clipboard Toggle word wrap

--install 옵션을 사용하면 설치할 패키지를 지정할 수 있습니다.

3.9. 서브스크립션 풀 정리
링크 복사

이미지를 사용자 정의하는 데 필요한 패키지를 설치한 후 서브스크립션을 제거하고 이미지를 등록 취소합니다. 

$ virt-customize -a overcloud-full.qcow2 --run-command 'subscription-manager remove --all'
[  0.0] Examining the guest ...
[ 12.0] Setting a random seed
[ 12.0] Running: subscription-manager remove --all
[ 18.0] Finishing off
Copy to Clipboard Toggle word wrap

이렇게 하면 이미지에서 모든 서브스크립션 풀이 제거됩니다.

3.10. 이미지 등록 해제
링크 복사

마지막으로 이미지를 등록 취소합니다. 따라서 Overcloud 배포 프로세스에서 이미지를 노드에 배포하고 각각 개별적으로 등록할 수 있습니다. 

$ virt-customize -a overcloud-full.qcow2 --run-command 'subscription-manager unregister'
[  0.0] Examining the guest ...
[ 11.0] Setting a random seed
[ 11.0] Running: subscription-manager unregister
[ 17.0] Finishing off
Copy to Clipboard Toggle word wrap

3.11. Director에 이미지 업로드
링크 복사

이미지를 수정한 후 director에 업로드합니다. 명령줄에서 director에 액세스할 수 있도록 stackrc 파일을 소싱해야 합니다. 

$ source stackrc
$ openstack overcloud image upload --image-path /home/stack/images/
Copy to Clipboard Toggle word wrap

그러면 bm-deploy-kernel,bm-deploy-ramdisk, overcloud-full ,overcloud-full -initrd, overcloud-full-vmlinuz. 배포용 이미지 및 Overcloud입니다. 이 스크립트는 director의 PXE 서버에 검색 이미지도 설치합니다. 다음 명령을 사용하여 CLI의 이미지 목록을 확인합니다. 

$ openstack image list
+--------------------------------------+------------------------+
| ID                                   | Name                   |
+--------------------------------------+------------------------+
| 765a46af-4417-4592-91e5-a300ead3faf6 | bm-deploy-ramdisk      |
| 09b40e3d-0382-4925-a356-3a4b4f36b514 | bm-deploy-kernel       |
| ef793cd0-e65c-456a-a675-63cd57610bd5 | overcloud-full         |
| 9a51a6cb-4670-40de-b64b-b70f4dd44152 | overcloud-full-initrd  |
| 4f7e33f4-d617-47c1-b36f-cbe90f132e5d | overcloud-full-vmlinuz |
+--------------------------------------+------------------------+
Copy to Clipboard Toggle word wrap

이 목록에는 검색 PXE 이미지(discovery-ramdisk.*)가 표시되지 않습니다. director는 이러한 파일을 /httpboot에 복사합니다. 

[stack@host1 ~]$ ls /httpboot -l
total 151636
-rw-r--r--. 1 ironic ironic       269 Sep 19 02:43 boot.ipxe
-rw-r--r--. 1 root   root         252 Sep 10 15:35 discoverd.ipxe
-rwxr-xr-x. 1 root   root     5027584 Sep 10 16:32 discovery.kernel
-rw-r--r--. 1 root   root   150230861 Sep 10 16:32 discovery.ramdisk
drwxr-xr-x. 2 ironic ironic      4096 Sep 19 02:45 pxelinux.cfg
Copy to Clipboard Toggle word wrap

4장. 설정
링크 복사

이 장에서는 OpenStack Puppet 모듈에 추가를 제공하는 방법을 설명합니다. 여기에는 Puppet 모듈 개발에 대한 몇 가지 기본 지침이 포함되어 있습니다.

4.1. Puppet 기본 학습
링크 복사

다음 섹션에서는 Puppet의 구문과 Puppet 모듈 구조를 이해하는 데 도움이 되는 몇 가지 기본 사항을 제공합니다.

4.1.1. Puppet 모듈 분석 검사
링크 복사

OpenStack 모듈에 기여하기 전에 Puppet 모듈을 생성하는 구성 요소를 이해해야 합니다.

manifests

매니페스트는 리소스 및 해당 특성 집합을 정의하는 코드를 포함하는 파일입니다. 리소스는 시스템의 구성 가능한 부분입니다. 리소스의 예로는 패키지, 서비스, 파일, 사용자 및 그룹, SELinux 구성, SSH 키 인증, cron 작업이 있습니다. 매니페스트는 속성에 대해 키-값 쌍 세트를 사용하여 각 필수 리소스를 정의합니다. 예를 들면 다음과 같습니다. 

  package { 'httpd':
    ensure => installed,
  }
Copy to Clipboard Toggle word wrap

이 선언은 httpd 패키지가 설치되었는지 확인합니다. 그렇지 않은 경우 매니페스트는 yum을 실행하고 설치합니다. 매니페스트는 모듈의 매니페스트 디렉터리에 있습니다. 또한 Puppet 모듈은 테스트 매니페스트에 테스트 디렉터리를 사용합니다. 이러한 매니페스트는 공식 매니페스트에 포함된 특정 클래스를 테스트하는 데 사용됩니다.

클래스
클래스는 매니페스트에서 여러 리소스를 통합하는 메서드 역할을 합니다. 예를 들어 HTTP 서버를 설치하고 구성하는 경우 다음 세 가지 리소스가 포함된 클래스를 생성할 수 있습니다. 하나는 HTTP 서버 패키지를 설치하는 하나, 하나는 HTTP 서버를 구성하는 것과 다른 하나는 서버를 시작하거나 활성화하는 것입니다. 구성을 적용하는 다른 모듈의 클래스도 참조할 수 있습니다. 예를 들어 웹 서버가 필요한 애플리케이션을 구성해야 하는 경우 HTTP 서버에 대해 이전에 언급한 클래스를 참조할 수 있습니다.
정적 파일

모듈은 Puppet이 시스템의 특정 위치에 복사할 수 있는 정적 파일을 포함할 수 있습니다. 이러한 위치 및 권한과 같은 기타 속성은 매니페스트의 파일 리소스 선언을 통해 정의됩니다.

정적 파일은 모듈의 files 디렉터리에 있습니다.

Cryostattemplates

구성 파일에 사용자 지정 콘텐츠가 필요한 경우가 있습니다. 이 경우 사용자는 정적 파일 대신 템플릿을 생성합니다. 정적 파일과 마찬가지로 템플릿은 매니페스트에 정의되어 있으며 시스템의 위치에 복사됩니다. 차이점은 템플릿을 통해 Ruby 표현식이 사용자 지정된 콘텐츠 및 변수 입력을 정의할 수 있다는 것입니다. 예를 들어 사용자 지정 가능한 포트로 httpd를 구성하려면 구성 파일에 대한 템플릿에는 다음이 포함됩니다. 

Listen <%= @httpd_port %>
Copy to Clipboard Toggle word wrap

이 경우 httpd_port 변수는 이 템플릿을 참조하는 매니페스트에 정의되어 있습니다.

템플릿은 모듈의 templates 디렉터리에 있습니다.

플러그인

플러그인을 사용하면 Puppet의 핵심 기능 이상으로 확장되는 측면을 사용할 수 있습니다. 예를 들어 플러그인을 사용하여 사용자 지정 팩트, 사용자 정의 리소스 또는 새 기능을 정의할 수 있습니다. 예를 들어 데이터베이스 관리자는 PostgreSQL 데이터베이스에 대한 리소스 유형이 필요할 수 있습니다. 그러면 PostgreSQL을 설치한 후 데이터베이스 관리자가 PostgreSQL을 새 데이터베이스 세트로 채우는 데 도움이 될 수 있습니다. 결과적으로 데이터베이스 관리자는 PostgreSQL 설치 및 데이터베이스가 나중에 생성되도록 하는 Puppet 매니페스트만 생성해야 합니다.

플러그인은 모듈의 lib 디렉터리에 있습니다. 여기에는 플러그인 유형에 따라 하위 디렉터리 세트가 포함됩니다. 예를 들면 다음과 같습니다.

  • /lib/facter - 사용자 지정 팩트의 위치입니다.
  • /lib/puppet/type - 속성의 키-값 쌍을 간략하게 설명하는 사용자 정의 리소스 유형 정의의 위치입니다.
  • /lib/puppet/provider - 리소스를 제어하기 위해 리소스 유형 정의와 함께 사용되는 사용자 정의 리소스 공급자의 위치입니다.
  • /lib/puppet/parser/functions - 사용자 지정 기능의 위치입니다.

4.1.2. 서비스 설치
링크 복사

일부 소프트웨어에는 패키지 설치가 필요합니다. Puppet 모듈에서 수행할 수 있는 기능 중 하나입니다. 여기에는 특정 패키지에 대한 구성을 정의하는 리소스 정의가 필요합니다.

예를 들어 mymodule 모듈을 통해 httpd 패키지를 설치하려면 mymodule 모듈의 Puppet 매니페스트에 다음 내용을 추가합니다. 

class mymodule::httpd {
  package { 'httpd':
    ensure => installed,
  }
}
Copy to Clipboard Toggle word wrap

이 코드는 httpd 라는 mymodule 의 하위 클래스를 정의한 다음 httpd 패키지에 대한 패키지 리소스 선언을 정의합니다. ensure => installed 속성은 패키지가 설치되어 있는지 확인하도록 Puppet에 지시합니다. 설치되지 않은 경우 Puppet은 yum 을 실행하여 설치합니다.

4.1.3. 서비스 시작 및 활성화
링크 복사

패키지를 설치한 후 서비스를 시작하려고 할 수 있습니다. service 라는 다른 리소스 선언을 사용합니다. 이를 위해서는 다음 콘텐츠를 사용하여 매니페스트를 편집해야 합니다. 

class mymodule::httpd {
  package { 'httpd':
    ensure => installed,
  }
  service { 'httpd':
    ensure => running,
    enable => true,
    require => Package["httpd"],
  }
}
Copy to Clipboard Toggle word wrap

다음과 같은 몇 가지 작업을 수행할 수 있습니다.

  • ensure => running 속성은 서비스가 실행 중인지 확인합니다. 그렇지 않은 경우 Puppet에서 활성화합니다.
  • enable => true 속성은 시스템이 부팅될 때 실행되도록 서비스를 설정합니다.
  • require => Package["httpd"] 속성은 하나의 리소스 선언과 다른 리소스 선언 간의 순서 관계를 정의합니다. 이 경우 httpd 패키지가 설치되면 httpd 서비스가 시작됩니다. 이렇게 하면 서비스와 해당 패키지 간에 종속성이 생성됩니다.

4.1.4. 서비스 구성
링크 복사

이전 두 단계에서는 Puppet을 통해 서비스를 설치하고 활성화하는 방법을 보여줍니다. 그러나 서비스에 일부 사용자 지정 구성을 제공할 수 있습니다. 이 예에서 HTTP 서버는 이미 포트 80에 웹 호스트를 제공하는 /etc/httpd/conf/httpd.conf 에 몇 가지 기본 구성을 제공합니다. 이 섹션에서는 사용자 지정 포트에 추가 웹 호스트를 제공하기 위해 몇 가지 추가 구성을 추가합니다.

이 경우 템플릿 파일을 사용하여 HTTP 구성 파일을 저장합니다. 이는 사용자 정의 포트에 변수 입력이 필요하기 때문입니다. 모듈의 templates 디렉터리에 다음 내용이 포함된 myserver.conf.erb 라는 파일을 추가합니다. 

Listen <%= @httpd_port %>
NameVirtualHost *:<%= @httpd_port %>
<VirtualHost *:<%= @httpd_port %>>
  DocumentRoot /var/www/myserver/
  ServerName *:<%= @fqdn %>>
  <Directory "/var/www/myserver/">
    Options All Indexes FollowSymLinks
    Order allow,deny
    Allow from all
  </Directory>
</VirtualHost>
Copy to Clipboard Toggle word wrap

이 템플릿은 Apache 웹 서버 구성에 대한 표준 구문을 따릅니다. 유일한 차이점은 모듈에서 변수를 삽입하는 Ruby 이스케이프 문자의 포함입니다. 예를 들어 웹 서버 포트를 지정하는 데 사용하는 httpd_port 입니다.

시스템의 정규화된 도메인 이름을 저장하는 변수인 fqdn 도 포함됩니다. 이를 시스템 사실 이라고 합니다. 시스템 사실은 각 시스템의 Puppet 카탈로그를 생성하기 전에 각 시스템에서 수집됩니다. Puppet은 facter 명령을 사용하여 이러한 시스템 팩트를 수집하고 팩트를 실행하여 이러한 사실 목록을 볼 수도 있습니다.

이 파일을 저장한 후 모듈의 Puppet 매니페스트에 리소스를 추가합니다. 

class mymodule::httpd {
  package { 'httpd':
    ensure => installed,
  }
  service { 'httpd':
    ensure => running,
    enable => true,
    require => Package["httpd"],
  }
  file {'/etc/httpd/conf.d/myserver.conf':
  notify => Service["httpd"],
    ensure => file,
    require => Package["httpd"],
    content => template("mymodule/myserver.conf.erb"),
  }
  file { "/var/www/myserver":
    ensure => "directory",
  }
}
Copy to Clipboard Toggle word wrap

이렇게 하면 다음이 수행됩니다.

  • 서버 구성 파일(/etc/httpd/conf.d/myserver.conf)에 대한 파일 리소스 선언을 추가합니다. 이 파일의 내용은 이전에 만든 myserver.conf.erb 템플릿입니다. 또한 이 파일을 추가하기 전에 httpd 패키지가 설치되었는지 확인합니다.
  • 두 번째 파일 리소스 선언도 추가합니다. 웹 서버에 대한 디렉토리(/var/www/myserver)를 생성합니다.
  • 또한 notify => Service["httpd"] 특성을 사용하여 구성 파일과 httpd 서비스 간의 관계를 추가합니다. 그러면 설정 파일에서 모든 변경 사항이 있는지 확인합니다. 파일이 변경되면 Puppet에서 서비스를 다시 시작합니다.

4.2. OpenStack Puppet 모듈 가져오기
링크 복사

Red Hat OpenStack Platform은 Github 의 openstack 그룹에서 얻을 수 있는 공식 OpenStack Puppet 모듈을 사용합니다. 브라우저를 https://github.com/openstack 로 이동하고 필터 섹션에서 puppet 을 검색합니다. 모든 Puppet 모듈은 puppet- 접두사를 사용합니다.

이 예제에서는 다음 명령을 사용하여 복제할 수 있는 공식 OpenStack 블록 스토리지(cinder)를 확인합니다. 

$ git clone https://github.com/openstack/puppet-cinder.git
Copy to Clipboard Toggle word wrap

그러면 Cinder용 Puppet 모듈의 복제본이 생성됩니다.

4.3. Puppet 모듈에 대한 구성 추가
링크 복사

OpenStack 모듈은 주로 핵심 서비스를 구성하는 것을 목표로 합니다. 대부분의 경우 백엔드,에이전트 또는 플러그인 으로 알려진 추가 서비스를 구성하는 추가 매니페스트도 포함되어 있습니다. 예를 들어 cinder 모듈에는 NFS, iSCSI, Red Hat Ceph Storage 등을 비롯한 다양한 스토리지 장치에 대한 구성 옵션이 포함된 backends 라는 디렉터리가 포함되어 있습니다.

예를 들어 manifests/backends/nfs.pp 파일에는 다음 구성이 포함되어 있습니다. 

define cinder::backend::nfs (
  $volume_backend_name  = $name,
  $nfs_servers          = [],
  $nfs_mount_options    = undef,
  $nfs_disk_util        = undef,
  $nfs_sparsed_volumes  = undef,
  $nfs_mount_point_base = undef,
  $nfs_shares_config    = '/etc/cinder/shares.conf',
  $nfs_used_ratio       = '0.95',
  $nfs_oversub_ratio    = '1.0',
  $extra_options        = {},
) {

  file {$nfs_shares_config:
    content => join($nfs_servers, "\n"),
    require => Package['cinder'],
    notify  => Service['cinder-volume']
  }

  cinder_config {
    "${name}/volume_backend_name":  value => $volume_backend_name;
    "${name}/volume_driver":        value =>
      'cinder.volume.drivers.nfs.NfsDriver';
    "${name}/nfs_shares_config":    value => $nfs_shares_config;
    "${name}/nfs_mount_options":    value => $nfs_mount_options;
    "${name}/nfs_disk_util":        value => $nfs_disk_util;
    "${name}/nfs_sparsed_volumes":  value => $nfs_sparsed_volumes;
    "${name}/nfs_mount_point_base": value => $nfs_mount_point_base;
    "${name}/nfs_used_ratio":       value => $nfs_used_ratio;
    "${name}/nfs_oversub_ratio":    value => $nfs_oversub_ratio;
  }

  create_resources('cinder_config', $extra_options)

}
Copy to Clipboard Toggle word wrap

다음과 같은 몇 가지 작업을 수행할 수 있습니다.

  • define 문에서는 cinder::backend::nfs 라는 정의된 유형을 생성합니다. 정의된 유형은 클래스와 유사합니다. 주요 차이점은 Puppet에서 정의된 유형을 여러 번 평가합니다. 예를 들어 여러 NFS 백엔드가 필요할 수 있으므로 구성에는 각 NFS 공유에 대해 여러 평가가 필요합니다.
  • 다음 몇 줄에서는 이 구성 및 기본값에 매개 변수를 정의합니다. 사용자가 새 값을 cinder::backend::nfs 정의된 유형으로 전달하면 기본값을 덮어씁니다.
  • file 함수는 파일 생성을 호출하는 리소스 선언입니다. 이 파일에는 NFS 공유 목록과 이 파일의 이름이 매개 변수에 정의되어 있습니다($nfs_shares_config = '/etc/cinder/shares.conf'). 추가 속성을 확인합니다.
  • content 속성은 $nfs_servers 매개 변수를 사용하여 목록을 생성합니다.
  • require 속성은 cinder 패키지가 설치되어 있는지 확인합니다.
  • notify 속성은 cinder-volume 서비스가 재설정되도록 지시합니다.

  • cinder_config 함수는 모듈에 있는 lib/puppet/ 디렉터리의 플러그인을 사용하는 리소스 선언입니다. 이 플러그인은 /etc/cinder/cinder.conf 파일에 구성을 추가합니다. 이 리소스의 각 행에는 cinder.conf 파일의 관련 섹션에 구성 옵션이 추가됩니다. 예를 들어 $name 매개 변수가 mynfs 인 경우 다음 속성입니다. 

      "${name}/volume_backend_name":  value => $volume_backend_name;
  "${name}/volume_driver":        value =>
    'cinder.volume.drivers.nfs.NfsDriver';
  "${name}/nfs_shares_config":    value => $nfs_shares_config;
    Copy to Clipboard Toggle word wrap

    다음을 cinder.conf 파일에 저장합니다. 

    [mynfs]
volume_backend_name=mynfs
volume_driver=cinder.volume.drivers.nfs.NfsDriver
nfs_shares_config=/etc/cinder/shares.conf
    Copy to Clipboard Toggle word wrap
  • create_resources 함수는 해시를 리소스 세트로 변환합니다. 이 경우 매니페스트는 $extra_options 해시를 백엔드의 추가 구성 옵션 세트로 변환합니다. 이를 통해 매니페스트의 핵심 매개변수에 포함되지 않은 구성 옵션을 추가할 수 있는 유연한 방법이 제공됩니다.

이는 하드웨어의 OpenStack 드라이버를 구성하는 매니페스트를 포함하는 것이 중요합니다. 매니페스트는 director가 하드웨어와 관련된 설정 옵션을 포함하는 간단한 방법을 제공합니다. 이는 director가 하드웨어를 사용하도록 오버클라우드를 구성하는 기본 통합 지점 역할을 합니다.

4.4. Puppet 구성에 Hiera 데이터 추가
링크 복사

Puppet에는 노드별 구성을 제공하는 키/값 시스템 역할을 하는 Hiera 라는 도구가 포함되어 있습니다. 이러한 키와 해당 값은 일반적으로 /etc/puppet/hieradata 에 있는 파일에 저장됩니다. /etc/puppet/hiera.yaml 파일은 Puppet이 hieradata 디렉터리의 파일을 읽는 순서를 정의합니다.

Overcloud를 구성할 때 Puppet은 이 데이터를 사용하여 특정 Puppet 클래스의 기본값을 덮어씁니다. 예를 들어 puppet-cinder 의 cinder::backend::nfs 의 기본 NFS 마운트 옵션은 정의되지 않습니다. 

  $nfs_mount_options    = undef,
Copy to Clipboard Toggle word wrap

그러나 cinder::backend::nfs 정의된 유형을 호출하는 고유한 매니페스트를 생성하고 이 옵션을 Hiera 데이터로 교체할 수 있습니다. 

  cinder::backend::nfs { $cinder_nfs_backend:
    nfs_mount_options   => hiera('cinder_nfs_mount_options'),
  }
Copy to Clipboard Toggle word wrap

즉, nfs_mount_options 매개변수는 cinder_nfs_mount_options 키의 Hiera 데이터 값을 사용합니다. 

cinder_nfs_mount_options: rsize=8192,wsize=8192
Copy to Clipboard Toggle word wrap

또는 Hiera 데이터를 사용하여 NFS 구성의 모든 평가에 적용하도록 cinder::backend::nfs::nfs_mount_options 매개변수를 직접 덮어쓸 수 있습니다. 예를 들면 다음과 같습니다. 

cinder::backend::nfs::nfs_mount_options: rsize=8192,wsize=8192
Copy to Clipboard Toggle word wrap

위의 Hiera 데이터는 cinder::backend::nfs 의 각 평가에서 이 매개 변수를 덮어씁니다.

5장. 오케스트레이션
링크 복사

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

이 장에서는 고유한 템플릿 파일을 생성할 수 있도록 HOT 구문을 이해하기 위한 몇 가지 기본 사항을 제공합니다.

5.1. Heat 템플릿 기본 학습
링크 복사

5.1.1. Heat 템플릿 이해
링크 복사

The structure of a Heat template has three main sections:
Copy to Clipboard Toggle word wrap
매개 변수
이러한 설정은 Heat에 전달되는 설정이며, 스택을 사용자 지정하는 방법과 전달된 값이 없는 매개 변수의 기본값을 제공합니다. 이러한 값은 템플릿의 parameters 섹션에 정의되어 있습니다.
Resources
이는 스택의 일부로 만들고 구성할 특정 오브젝트입니다. OpenStack에는 모든 구성 요소에 걸쳐 있는 핵심 리소스 세트가 포함되어 있습니다. 이러한 값은 템플릿의 resources 섹션에 정의되어 있습니다.
출력 결과
스택 생성 후 Heat에서 전달된 값입니다. Heat API 또는 클라이언트 툴을 통해 이러한 값에 액세스할 수 있습니다. 이러한 값은 템플릿의 output 섹션에 정의되어 있습니다.

다음은 기본 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 ] }
Copy to Clipboard Toggle word wrap

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

중요

Heat 템플릿에는 사용할 구문 버전과 사용 가능한 함수를 정의하는 heat_template_version 매개변수도 필요합니다. 자세한 내용은 공식 Heat 문서를 참조하십시오.

5.1.2. 환경 파일 이해
링크 복사

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

매개 변수
템플릿의 매개변수에 적용하는 일반적인 설정입니다. 이러한 값은 환경 파일의 parameters 섹션에 정의되어 있습니다.
매개변수 기본값
이러한 매개변수는 템플릿에서 매개변수의 기본값을 수정합니다. 이러한 값은 환경 파일의 parameter_defaults 섹션에 정의되어 있습니다.
리소스 레지스트리
이 섹션에서는 사용자 지정 리소스 이름, 다른 Heat 템플릿에 대한 링크를 정의합니다. 이는 기본적으로 코어 리소스 컬렉션 내에 존재하지 않는 사용자 정의 리소스를 생성하는 방법을 제공합니다. 이러한 값은 환경 파일의 resource_registry 섹션에 정의되어 있습니다.

다음은 기본 환경 파일의 예입니다. 

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

parameter_defaults:
  NetworkName: my_network

parameters:
  MyIP: 192.168.0.1
Copy to Clipboard Toggle word wrap

그러면 OS::Nova::Server::MyServer 라는 새 리소스 유형이 생성됩니다. myserver.yaml 파일은 내장된 모든 리소스 유형을 재정의하는 이 리소스 유형에 대한 구현을 제공하는 Heat 템플릿 파일입니다.

5.2. 기본 Director 템플릿 가져오기
링크 복사

director는 Overcloud를 생성하는 데 사용되는 고급 Heat 템플릿 컬렉션을 사용합니다. 이 컬렉션은 openstack -tripleo-heat-templates 리포지토리의 Github 그룹에서 사용할 수 있습니다. 이 템플릿 컬렉션의 복제본을 가져오려면 다음 명령을 실행합니다. 

$ git clone https://github.com/openstack/tripleo-heat-templates.git
Copy to Clipboard Toggle word wrap
참고

이 템플릿 컬렉션의 Red Hat 특정 버전은 컬렉션을 /usr/share/openstack-tripleo-heat-templates 에 설치하는 openstack-tripleo-heat-template 패키지에서 사용할 수 있습니다.

이 컬렉션에는 많은 Heat 템플릿과 환경 파일이 있습니다. 그러나 이 템플릿 컬렉션에서 확인할 세 가지 주요 파일입니다.

overcloud-without-mergepy.yaml
이는 Overcloud 환경을 생성하는 데 사용되는 기본 템플릿 파일입니다.
overcloud-resource-registry-puppet.yaml
이는 Overcloud 환경을 생성하는 데 사용되는 기본 환경 파일입니다. Overcloud 이미지에 저장된 Puppet 모듈의 구성 세트를 제공합니다. director가 각 노드에 Overcloud 이미지를 쓰면 Heat는 이 환경 파일에 등록된 리소스를 사용하여 각 노드의 Puppet 설정을 시작합니다.
overcloud-resource-registry.yaml
이는 Overcloud 환경을 생성하는 데 사용되는 표준 환경 파일입니다. overcloud-resource-registry-puppet.yaml은 이 파일을 기반으로 합니다. 이 파일은 사용자 지정 환경의 구성에 사용됩니다.

director는 처음 두 개의 파일을 사용하여 Overcloud 생성을 구동합니다. 이 컬렉션의 다른 모든 파일에는 overcloud-resource-registry-puppet.yaml 파일과 관련된 일부 하위 항목이 있거나, 배포에 추가할 수 있는 자체 환경 파일과 관련된 추가 기능을 제공합니다.

environments
오버클라우드 생성과 함께 사용할 수 있는 추가 Heat 환경 파일이 포함되어 있습니다. 이러한 환경 파일을 사용하면 결과 OpenStack 환경에 추가 기능을 사용할 수 있습니다. 예를 들어 디렉터리에는 Cinder NetApp 백엔드 스토리지(cinder-netapp-config.yaml)를 활성화하기 위한 환경 파일이 포함되어 있습니다.
extraconfig
추가 기능을 활성화하는 데 사용되는 템플릿입니다. 예를 들어 extraconfig/pre_deploy/rhel-registration director는 노드의 Red Hat Enterprise Linux 운영 체제를 Red Hat Content Delivery 네트워크 또는 자체 Red Hat Satellite 서버에 등록할 수 있는 기능을 제공합니다.
firstboot
director가 처음에 노드를 생성할 때 사용하는 first_boot 스크립트 예제를 제공합니다.
network
격리된 네트워크 및 포트를 만드는 데 도움이 되는 Heat 템플릿 세트입니다.
Puppet
템플릿은 주로 puppet을 사용하여 구성으로 구동됩니다. 앞서 언급한 overcloud-resource-registry-puppet.yaml 환경 파일은 이 디렉터리의 파일을 사용하여 각 노드에서 Puppet 구성 애플리케이션을 구동합니다.
validation-scripts
모든 배포 구성에 유용한 검증 스크립트가 포함되어 있습니다.

이를 통해 director가 오버클라우드 생성을 오케스트레이션하는 데 사용하는 템플릿에 대한 일반적인 개요가 제공됩니다. 다음 몇 섹션에서는 오버클라우드 배포에 추가할 수 있는 고유한 사용자 지정 템플릿 및 환경 파일을 생성하는 방법을 보여줍니다.

5.3. 첫 번째 부팅에서 구성 사용자 정의
링크 복사

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

이 예제에서는 모든 노드에서 사용자 지정 IP 주소로 네임서버를 업데이트하는 것을 목표로 합니다. 먼저 스크립트를 실행하여 각 노드의 resolv.conf 를 특정 네임서버로 추가하는 기본 Heat 템플릿(nameserver.yaml)을 만듭니다. OS::TripleO::MultipartMime 리소스 유형을 사용하여 구성 스크립트를 보냅니다. 

heat_template_version: 2014-10-16

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/resolve.conf

outputs:
  OS::stack_id:
    value: {get_resource: userdata}
Copy to Clipboard Toggle word wrap

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

resource_registry:
  OS::TripleO::NodeUserData: nameserver.yaml
Copy to Clipboard Toggle word wrap

이렇게 하면 다음이 수행됩니다.

  1. OS::TripleO::NodeUserData 는 컬렉션의 다른 템플릿에 사용되는 director 기반 Heat 리소스이며 첫 번째 부팅 설정을 모든 노드에 적용합니다. 이 리소스는 cloud-init 에서 사용할 데이터를 전달합니다. 기본 NodeUserData 는 빈 값(firstboot/userdata_default.yaml)을 생성하는 Heat 템플릿을 나타냅니다. 이 경우 firstboot.yaml 환경 파일은 기본값을 자체 nameserver.yaml 파일에 대한 참조로 대체합니다.
  2. nameserver_config 는 처음 부팅할 때 실행할 Bash 스크립트를 정의합니다. OS::Heat::SoftwareConfig 리소스는 적용할 구성으로 정의합니다.
  3. userdata 는 OS::Heat::MultipartMime 리소스를 사용하여 nameserver_config 의 구성을 다중 파트 MIME 메시지로 변환합니다.
  4. 출력은 userdata 에서 MIME 메시지를 가져와서 호출하는 Heat 템플릿/리소스에 제공하는 출력 매개 변수 OS::stack_id 를 제공합니다.

결과적으로 각 노드는 첫 번째 부팅 시 다음 Bash 스크립트를 실행합니다. 

#!/bin/bash
echo "nameserver 192.168.1.1" >> /etc/resolve.conf
Copy to Clipboard Toggle word wrap

이 예에서는 Heat 템플릿이 한 리소스에서 다른 리소스로 구성을 전달하는 방법을 보여줍니다. 또한 환경 파일을 사용하여 새 Heat 리소스를 등록하거나 기존 리소스를 수정하는 방법도 보여줍니다.

5.4. 오버클라우드 구성 전에 구성 사용자 정의
링크 복사

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

OS::TripleO::ControllerExtraConfigPre
핵심 Puppet 구성 전에 컨트롤러 노드에 적용된 추가 구성입니다.
OS::TripleO::ComputeExtraConfigPre
핵심 Puppet 구성 전에 컴퓨팅 노드에 추가 구성이 적용됩니다.
OS::TripleO::CephStorageExtraConfigPre
코어 Puppet 구성 전에 CephStorage 노드에 적용된 추가 구성입니다.
OS::TripleO::NodeExtraConfig
핵심 Puppet 구성 전에 모든 노드 역할에 적용되는 추가 구성입니다.

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

heat_template_version: 2014-10-16

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

resources:
  ExtraPreConfig:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template: |
            #!/bin/sh
            echo "nameserver _NAMESERVER_IP_" >> /etc/resolve.conf
          params:
            _NAMESERVER_IP_: {get_param: nameserver_ip}
  ExtraPreDeployment:
    type: OS::Heat::SoftwareDeployment
    properties:
      config: {get_resource: ExtraPreConfig}
      server: {get_param: server}
      actions: ['CREATE']

outputs:
  deploy_stdout:
    description: Deployment reference, used to trigger post-deploy on changes
    value: {get_attr: [ExtraPreDeployment, deploy_stdout]}
Copy to Clipboard Toggle word wrap
중요

servers 매개 변수는 구성을 적용하기 위한 서버 목록이며 상위 템플릿에서 제공합니다. 이 매개변수는 모든 사전 구성 템플릿에서 필수입니다.

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

resource_registry:
  OS::TripleO::NodeExtraConfig: nameserver.yaml
parameter_defaults:
  nameserver_ip: 192.168.1.1
Copy to Clipboard Toggle word wrap

이렇게 하면 다음이 수행됩니다.

  1. OS::TripleO::NodeExtraConfig 는 Heat 템플릿 컬렉션의 구성 템플릿에 사용되는 director 기반 Heat 리소스입니다. 이 리소스는 *-puppet.yaml 템플릿을 통해 각 노드 유형에 구성을 전달합니다. 기본 NodeExtraConfig 는 빈 값(puppet/extraconfig/pre_deploy/default.yaml)을 생성하는 Heat 템플릿을 나타냅니다. 이 경우 pre_config.yaml 환경 파일은 이 기본값을 자체 nameserver.yaml 파일에 대한 참조로 대체합니다.
  2. 환경 파일은 또한 해당 환경의 parameter_default 값으로 nameserver_ip 를 전달합니다. 이는 이름 서버의 IP 주소를 저장하는 매개변수입니다. 그러면 nameserver.yaml Heat 템플릿에서는 parameters 섹션에 정의된 대로 이 매개변수를 허용합니다.
  3. 템플릿은 OS::Heat::SoftwareConfig 를 통해 ExtraPreConfig 를 구성 리소스로 정의합니다. group: script 속성을 확인합니다. 그룹은 사용할 소프트웨어 구성 도구를 정의합니다. 이 툴은 Heat의 후크를 통해 사용할 수 있습니다. 이 경우 스크립트 후크는 SoftwareConfig 리소스에 정의된 실행 가능한 스크립트를 config 속성으로 실행합니다.

  4. 스크립트 자체는 이름 서버 IP 주소에 /etc/resolve.conf 를 추가합니다. str_replace 속성을 기록하면 template 섹션의 변수를 params 섹션의 매개 변수로 교체할 수 있습니다. 이 경우 NAMESERVER_IP 를 이름 서버 IP 주소로 설정하여 스크립트에서 동일한 변수를 대체합니다. 그러면 다음 스크립트가 생성됩니다. 

    #!/bin/sh
echo "nameserver 192.168.1.1" >> /etc/resolve.conf
    Copy to Clipboard Toggle word wrap

  5. ExtraPreDeployments 는 ExtraPreConfig 구성을 노드에 배포합니다. 다음을 확인합니다.

    • config 속성은 ExtraPreConfig 리소스에 대한 참조를 만들어 Heat에서 적용할 구성을 인식하도록 합니다.
    • servers 속성은 overcloud-without-mergepy.yaml 이 전달하는 Overcloud 노드 맵을 검색합니다.
    • actions 속성은 구성을 적용할 시기를 정의합니다. 이 경우 Overcloud가 생성될 때만 구성을 적용합니다. 가능한 작업에는 CREATE,UPDATE,DELETE,SUSPEND, RESUME 등이 있습니다.

이 예제에서는 구성을 정의하고 코어 구성 전에 OS::Heat::SoftwareConfig 및 OS::Heat::SoftwareDeployments 를 사용하여 배포하는 Heat 템플릿을 생성하는 방법을 보여줍니다. 또한 환경 파일에서 매개 변수를 정의하고 구성의 템플릿에 전달하는 방법도 보여줍니다.

5.5. 오버클라우드 구성 후 구성 사용자 정의
링크 복사

오버클라우드 생성을 완료했지만 초기 생성 또는 Overcloud의 후속 업데이트 시 구성을 추가하려는 경우 발생할 수 있습니다. 이 경우 OS::TripleO::NodeExtraConfigPost 리소스를 사용하여 표준 OS::Heat::SoftwareConfig 유형을 사용하여 구성을 적용합니다. 이는 기본 Overcloud 구성이 완료된 후 추가 구성이 적용됩니다.

이 예제에서는 먼저 스크립트를 실행하여 각 노드의 resolv.conf 를 변수 이름 서버에 추가하는 기본 Heat 템플릿(nameserver.yaml)을 만듭니다. 

heat_template_version: 2014-10-16

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

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

  ExtraDeployments:
    type: OS::Heat::SoftwareDeployments
    properties:
      servers:  {get_param: servers}
      config: {get_resource: ExtraConfig}
      actions: ['CREATE']
Copy to Clipboard Toggle word wrap
중요

servers 매개변수는 구성을 적용하기 위한 서버 목록이며 상위 템플릿(overcloud-without-mergepy.yaml)에서 제공합니다. 이 매개변수는 모든 OS::TripleO::NodeExtraConfigPost 템플릿에서 필수입니다.

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

resource_registry:
  OS::TripleO::NodeExtraConfigPost: nameserver.yaml
parameter_defaults:
  nameserver_ip: 192.168.1.1
Copy to Clipboard Toggle word wrap

이렇게 하면 다음이 수행됩니다.

  1. OS::TripleO::NodeExtraConfigPost 는 컬렉션의 구성 후 템플릿에 사용되는 director 기반 Heat 리소스입니다. 이 리소스는 *-post.yaml 템플릿을 통해 각 노드 유형에 구성을 전달합니다. 기본 NodeExtraConfigPost 는 빈 값을 생성하는 Heat 템플릿(extraconfig/post_deploy/default.yaml)을 나타냅니다. 이 경우 post_config.yaml 환경 파일은 기본값을 자체 nameserver.yaml 파일에 대한 참조로 대체합니다.
  2. 환경 파일은 또한 해당 환경의 parameter_default 값으로 nameserver_ip 를 전달합니다. 이는 이름 서버의 IP 주소를 저장하는 매개변수입니다. 그러면 nameserver.yaml Heat 템플릿에서는 parameters 섹션에 정의된 대로 이 매개변수를 허용합니다.
  3. 템플릿은 OS::Heat::SoftwareConfig 를 통해 ExtraConfig 를 구성 리소스로 정의합니다. group: script 속성을 확인합니다. 그룹은 사용할 소프트웨어 구성 도구를 정의합니다. 이 툴은 Heat의 후크를 통해 사용할 수 있습니다. 이 경우 스크립트 후크는 SoftwareConfig 리소스에 정의된 실행 가능한 스크립트를 config 속성으로 실행합니다.

  4. 스크립트 자체는 이름 서버 IP 주소에 /etc/resolve.conf 를 추가합니다. str_replace 속성을 기록하면 template 섹션의 변수를 params 섹션의 매개 변수로 교체할 수 있습니다. 이 경우 NAMESERVER_IP 를 이름 서버 IP 주소로 설정하여 스크립트에서 동일한 변수를 대체합니다. 그러면 다음 스크립트가 생성됩니다. 

    #!/bin/sh
echo "nameserver 192.168.1.1" >> /etc/resolve.conf
    Copy to Clipboard Toggle word wrap

  5. ExtraDeployments 는 ExtraConfig 구성을 노드에 배포합니다. 다음을 확인합니다.

    • config 속성은 ExtraConfig 리소스에 대한 참조를 만들어 Heat에서 적용할 구성을 인식하도록 합니다.
    • servers 속성은 overcloud-without-mergepy.yaml 이 전달하는 Overcloud 노드 맵을 검색합니다.
    • actions 속성은 구성을 적용할 시기를 정의합니다. 이 경우 Overcloud가 생성될 때만 구성을 적용합니다. 가능한 작업에는 CREATE,UPDATE,DELETE,SUSPEND, RESUME 등이 있습니다.

이 예제에서는 구성을 정의하고 OS::Heat::SoftwareConfig 및 OS::Heat::SoftwareDeployments 를 사용하여 배포하는 Heat 템플릿을 생성하는 방법을 보여줍니다. 또한 환경 파일에서 매개 변수를 정의하고 구성의 템플릿에 전달하는 방법도 보여줍니다.

5.6. 오버클라우드에 사용자 지정 Puppet 구성 적용
링크 복사

이전에는 새 백엔드의 구성을 OpenStack Puppet 모듈에 추가하는 방법에 대해 논의했습니다. 이 섹션에서는 director가 새 구성의 애플리케이션을 실행하는 방법을 보여줍니다.

Heat 템플릿은 OS::Heat::SoftwareConfig 리소스로 Puppet 구성을 적용할 수 있는 후크를 제공합니다. 프로세스는 Bash 스크립트를 포함 및 실행하는 방법과 유사합니다. 그러나 group: 스크립트 후크 대신 group: puppet hook를 사용합니다.

예를 들어 공식 Cinder Puppet 모듈을 사용하여 NFS Cinder 백엔드를 활성화하는 Puppet 매니페스트(example-puppet-manifest.pp)가 있을 수 있습니다. 

cinder::backend::nfs { 'mynfsserver':
  nfs_servers          => ['192.168.1.200:/storage'],
}
Copy to Clipboard Toggle word wrap

이 Puppet 구성은 cinder::backend::nfs 정의된 유형을 사용하여 새 리소스를 생성합니다. Heat를 통해 이 리소스를 적용하려면 Puppet 매니페스트를 실행하는 기본 Heat 템플릿(puppet-config.yaml)을 생성합니다. 

heat_template_version: 2014-10-16

parameters:
  servers:
    type: json

resources:
  ExtraPuppetConfig:
    type: OS::Heat::SoftwareConfig
    properties:
      group: puppet
      config:
        get_file: example-puppet-manifest.pp
      options:
        enable_hiera: True
        enable_facter: False

  ExtraPuppetDeployment:
    type: OS::Heat::SoftwareDeployments
    properties:
      config: {get_resource: ExtraPuppetConfig}
      servers: {get_param: servers}
      actions: ['CREATE','UPDATE']
Copy to Clipboard Toggle word wrap

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

resource_registry:
  OS::TripleO::NodeExtraConfigPost: puppet_config.yaml
Copy to Clipboard Toggle word wrap

이 예제는 이전 섹션의 스크립트 후크 예제에서 SoftwareConfig 및 SoftwareDeployments 를 사용하는 것과 유사합니다. 그러나 이 예제에는 몇 가지 차이점이 있습니다.

  1. group: puppet 을 설정하여 puppet 후크를 실행합니다.
  2. config 속성은 get_file 속성을 사용하여 추가 구성이 포함된 Puppet 매니페스트를 참조합니다.

  3. options 속성에는 Puppet 구성과 관련된 몇 가지 옵션이 포함되어 있습니다.

    • enable_hiera 옵션을 사용하면 Puppet 구성에서 Hiera 데이터를 사용할 수 있습니다.
    • enable_facter 옵션을 사용하면 Puppet 구성이 facter 명령의 시스템 팩트를 사용할 수 있습니다.

이 예에서는 Overcloud 소프트웨어 구성의 일부로 Puppet 매니페스트를 포함하는 방법을 보여줍니다. 이를 통해 오버클라우드 이미지에 기존 Puppet 모듈의 특정 구성 클래스를 적용할 수 있으므로 특정 소프트웨어 및 하드웨어를 사용하도록 Overcloud를 사용자 지정할 수 있습니다.

5.7. 오버클라우드에서 Hiera Data 수정
링크 복사

앞서 언급했듯이 Puppet은 Hiera 툴을 사용하여 특정 변수에 대한 노드별 값을 제공합니다. 이러한 키와 해당 값은 일반적으로 /etc/puppet/hieradata 에 있는 파일에 저장됩니다. Overcloud에서 이 디렉터리에는 사용자 지정 매개 변수를 추가하는 데 사용하는 추가 Hiera 파일 세트가 포함되어 있습니다.

director의 Heat 템플릿 컬렉션의 매개변수 세트를 사용하여 이 Hiera 데이터를 전달합니다. 이러한 매개변수는 다음과 같습니다.

ExtraConfig
모든 노드에 추가할 구성입니다.
NovaComputeExtraConfig
모든 컴퓨팅 노드에 추가할 구성입니다.
controllerExtraConfig
모든 컨트롤러 노드에 추가할 구성입니다.
BlockStorageExtraConfig
모든 블록 스토리지 노드에 추가할 구성입니다.
ObjectStorageExtraConfig
모든 Object Storage 노드에 추가할 구성
CephStorageExtraConfig
모든 Ceph Storage 노드에 추가할 구성

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

parameter_defaults:
  NovaComputeExtraConfig:
    nova::compute::reserved_host_memory: 1024
Copy to Clipboard Toggle word wrap

그러면 Compute 노드의 /etc/puppet/hieradata 디렉터리에 있는 사용자 지정 Hiera 파일에 nova::compute::reserved_host_memory: 1024 가 추가됩니다.

5.8. Overcloud 배포에 환경 파일 추가
링크 복사

사용자 지정 구성과 관련된 환경 파일 세트를 개발한 후 Overcloud 배포에 이러한 파일을 포함합니다. 즉, -e 옵션과 함께 openstack overcloud deploy 명령 다음에 환경 파일을 실행합니다. 사용자 지정에 필요한 수만큼 -e 옵션을 지정할 수 있습니다. 예를 들면 다음과 같습니다. 

$ openstack overcloud deploy --templates -e network-configuration.yaml -e storage-configuration.yaml -e first-boot.yaml
Copy to Clipboard Toggle word wrap
중요

환경 파일은 연속으로 누적됩니다. 즉, 기본 Heat 템플릿 컬렉션 및 모든 이전 환경 파일 둘 다에 있는 각 후속 파일 스택입니다. 이를 통해 리소스 정의를 재정의할 수 있습니다. 예를 들어 Overcloud 배포의 모든 환경 파일이 NodeExtraConfigPost 리소스를 정의하는 경우 Heat는 마지막 환경 파일에 정의된 NodeExtraConfigPost 를 사용합니다. 따라서 환경 파일의 순서가 중요합니다. 환경 파일이 올바르게 처리되고 스택되도록 정렬해야 합니다.

주의

-e 옵션을 사용하여 Overcloud에 추가된 환경 파일은 Overcloud 스택 정의의 일부가 됩니다. director는 배포 후 또는 재배포 함수에 대해 이러한 환경 파일이 필요합니다. 이러한 파일을 포함하지 않으면 오버클라우드가 손상될 수 있습니다.

[[통합점]] == 통합 지점

이 장에서는 director 통합을 위한 특정 통합 지점을 설명합니다. 여기에는 특정 OpenStack 구성 요소 및 director 또는 Overcloud 통합과의 관계를 확인하는 작업이 포함됩니다. 이 섹션은 모든 OpenStack 통합에 대한 완전한 설명은 아니지만 하드웨어 및 소프트웨어를 Red Hat OpenStack Platform과 통합하기 시작하기에 충분한 정보를 제공해야 합니다.

5.9. Bare Metal Provisioning (Ironic)
링크 복사

OpenStack Bare Metal Provisioning(Ironic) 구성 요소는 director 내에서 노드의 전원 상태를 제어하는 데 사용됩니다. director는 일련의 백엔드 드라이버를 사용하여 특정 베어 메탈 전원 컨트롤러와 연결합니다. 이러한 드라이버는 하드웨어 및 벤더 특정 확장 및 기능을 활성화하는 데 핵심입니다. 가장 일반적인 드라이버는 IPMI 드라이버(pxe_ipmitool)로, IPMI(Intelligent Platform Management Interface)를 지원하는 모든 서버의 전원 상태를 제어합니다.

Ironic과의 통합은 먼저 업스트림 OpenStack 커뮤니티와의 통합을 시작합니다. 업스트림에 허용되는 Ironic 드라이버는 기본적으로 코어 Red Hat OpenStack Platform 제품 및 director에 자동으로 포함됩니다. 그러나 인증 요구 사항에 따라 지원되지 않을 수 있습니다.

하드웨어 드라이버는 지속적인 기능을 유지하기 위해 지속적인 통합 테스트를 수행해야 합니다. 타사 드라이버 테스트 및 적합성에 대한 자세한 내용은 Ironic 테스트 의 OpenStack 커뮤니티 페이지를 참조하십시오.

업스트림 리포지토리:

업스트림 블루프린트:

Puppet 모듈:

Bugzilla 구성 요소:

  • openstack-ironic
  • python-ironicclient
  • python-ironic-oscplugin
  • openstack-ironic-discoverd
  • openstack-puppet-modules
  • openstack-tripleo-heat-templates

통합 노트:

  • 업스트림 프로젝트에는 ironic/drivers 디렉터리의 드라이버가 포함되어 있습니다.
  • director는 JSON 파일에 정의된 노드의 대규모 등록을 수행합니다. os-cloud-config 툴(https://github.com/openstack/os-cloud-config/)은 이 파일을 구문 분석하여 노드 등록 세부 정보를 확인하고 등록을 수행합니다. 즉, os-cloud-config 도구, 특히 nodes.py 파일을 지원해야 합니다.

  • director는 Ironic을 사용하도록 자동으로 구성됩니다. 즉, Puppet 설정을 수정하지 않아도 됩니다. 그러나 드라이버가 Ironic에 포함된 경우 드라이버를 /etc/ironic/ironic.conf 파일에 추가해야 합니다. 이 파일을 편집하고 enabled_drivers 매개변수를 검색합니다. 예를 들면 다음과 같습니다. 

    enabled_drivers=pxe_ipmitool,pxe_ssh,pxe_drac
    Copy to Clipboard Toggle word wrap

    이를 통해 Ironic은 드라이버 디렉터리에서 지정된 드라이버 를 사용할 수 있습니다.

5.10. 네트워킹(Neutron)
링크 복사

OpenStack Networking(Neutron)은 클라우드 환경 내에서 네트워크 아키텍처를 생성할 수 있는 기능을 제공합니다. 이 프로젝트는 SDN(Software Defined Networking) 공급업체에 대한 여러 통합 지점을 제공합니다. 이러한 통합 포인트는 일반적으로 플러그인 또는 에이전트의 카테고리에 속합니다.

플러그인 을 사용하면 기존 Neutron 기능을 확장하고 사용자 정의할 수 있습니다. 벤더는 Neutron과 인증된 소프트웨어 및 하드웨어 간의 상호 운용성을 보장하기 위해 플러그인을 작성할 수 있습니다. 대부분의 벤더는 자체 드라이버 통합을 위한 모듈식 백엔드를 제공하는 Neutron의 Modular Layer 2(ml2) 플러그인의 드라이버를 개발하는 것을 목표로 합니다.

에이전트 는 특정 네트워크 기능을 제공합니다. 기본 Neutron 서버(및 해당 플러그인)는 Neutron 에이전트와 통신합니다. 기존 예로는 DHCP를 위한 에이전트, 계층 3 지원, 브리징 지원이 있습니다.

플러그인과 에이전트 모두 다음을 수행할 수 있습니다.

  • OpenStack Platform 솔루션의 일부로 배포를 위해 포함하거나
  • OpenStack Platform 배포 후 Overcloud 이미지에 추가합니다.

자체 인증된 하드웨어 및 소프트웨어를 통합하는 방법을 결정할 수 있도록 기존 플러그인 및 에이전트의 기능을 분석하는 것이 좋습니다. 특히 ml2 플러그인의 일부로 드라이버를 개발하는 것이 좋습니다.

업스트림 리포지토리:

업스트림 블루프린트:

Puppet 모듈:

Bugzilla 구성 요소:

  • openstack-neutron
  • python-neutronclient
  • openstack-puppet-modules
  • openstack-tripleo-heat-templates

통합 노트:

  • 업스트림 neutron 프로젝트에는 다음과 같은 몇 가지 통합 포인트가 포함되어 있습니다.

    • 플러그인은 neutron/plugins/에 있습니다.
    • ml2 플러그인 드라이버는 neutron/plugins/ml2/drivers/에 있습니다.
    • 에이전트는 neutron/agents/에 있습니다.
  • OpenStack Liberty 릴리스 이후 많은 벤더별 ml2 플러그인이 네트워킹 부터 자체 리포지토리로 이동되었습니다. 예를 들어, Cisco 관련 플러그인은 https://github.com/openstack/networking-cisco에 있습니다.

  • puppet-neutron 리포지토리에는 이러한 통합 지점을 구성하기 위한 별도의 디렉터리도 포함되어 있습니다.

    • 플러그인 구성은 manifests/plugins/에 있습니다.
    • ml2 플러그인 드라이버 구성은 manifests/plugins/ml2/에 있습니다.
    • 에이전트 구성은 manifests/agents/에 있습니다.
  • puppet-neutron 리포지토리에는 구성 기능을 위한 다양한 추가 라이브러리가 포함되어 있습니다. 예를 들어 neutron_plugin_ml2 라이브러리는 ml2 플러그인 구성 파일에 속성을 추가하는 함수를 추가합니다.

5.11. 블록 스토리지(Cinder)
링크 복사

OpenStack Block Storage(Cinder)는 OpenStack에서 볼륨을 생성하는 블록 스토리지 장치와 상호 작용하는 API를 제공합니다. 예를 들어 Cinder는 인스턴스에 가상 스토리지 장치를 제공합니다. Cinder는 다양한 스토리지 하드웨어 및 프로토콜을 지원하는 핵심 드라이버 세트를 제공합니다. 예를 들어 일부 핵심 드라이버에는 NFS, iSCSI 및 Red Hat Ceph Storage 지원이 포함됩니다. 벤더에는 추가 인증된 하드웨어를 지원하는 드라이버가 포함될 수 있습니다.

공급업체에는 개발하는 드라이버 및 구성과 함께 두 가지 주요 옵션이 있습니다.

  • OpenStack Platform 솔루션의 일부로 배포를 위해 포함하거나
  • OpenStack Platform 배포 후 Overcloud 이미지에 추가합니다.

자체 인증된 하드웨어 및 소프트웨어를 통합하는 방법을 결정할 수 있도록 기존 드라이버의 기능을 분석하는 것이 좋습니다.

업스트림 리포지토리:

업스트림 블루프린트:

Puppet 모듈:

Bugzilla 구성 요소:

  • openstack-cinder
  • python-cinderclient
  • openstack-puppet-modules
  • openstack-tripleo-heat-templates

통합 노트:

  • 업스트림 cinder 리포지토리에는 cinder/volume/drivers/의 드라이버가 포함되어 있습니다.

  • puppet-cinder 리포지토리에는 드라이버 구성을 위한 두 가지 기본 디렉터리가 포함되어 있습니다.

    • manifests/backend 디렉터리에는 드라이버를 구성하는 정의된 유형 세트가 포함되어 있습니다.
    • manifests/volume 디렉터리에는 기본 블록 스토리지 장치를 구성하는 클래스 세트가 포함되어 있습니다.
  • puppet-cinder 리포지토리에는 Cinder 구성 파일에 속성을 추가하는 cinder_config 라는 라이브러리가 포함되어 있습니다.

5.12. 이미지 스토리지(Glance)
링크 복사

OpenStack Image Storage(Cinder)는 스토리지 유형과 상호 작용하여 이미지 스토리지를 제공하는 API를 제공합니다. Glance는 다양한 스토리지 하드웨어 및 프로토콜을 지원하는 핵심 드라이버 세트를 제공합니다. 예를 들어 코어 드라이버에는 파일, OpenStack Object Storage(Swift), OpenStack Block Storage(Cinder) 및 Red Hat Ceph Storage에 대한 지원이 포함됩니다. 벤더에는 추가 인증된 하드웨어를 지원하는 드라이버가 포함될 수 있습니다.

업스트림 리포지토리:

업스트림 블루프린트:

Puppet 모듈:

Bugzilla 구성 요소:

  • openstack-glance
  • python-glanceclient
  • openstack-puppet-modules
  • openstack-tripleo-heat-templates

통합 노트:

  • Glance에서 이미지 스토리지를 관리하기 위해 integretion 지점이 포함된 Cinder를 사용할 수 있으므로 벤더별 드라이버를 추가할 필요가 없습니다.
  • 업스트림 glance_store 리포지토리에는 glance_store/_drivers 의 드라이버가 포함되어 있습니다.
  • puppet-glance 리포지토리에는 manifests/backend 디렉터리에 드라이버 구성이 포함되어 있습니다.
  • puppet-glance 리포지토리에는 Glance 구성 파일에 속성을 추가하는 glance_api_config 라는 라이브러리가 포함되어 있습니다.

5.13. 공유 파일 시스템(Manila)
링크 복사

OpenStack Shared File System Service(Manila)는 공유 및 분산 파일 시스템 서비스를 위한 API를 제공합니다. 벤더에는 추가 인증된 하드웨어를 지원하는 드라이버가 포함될 수 있습니다.

업스트림 리포지토리:

업스트림 블루프린트:

Puppet 모듈:

Bugzilla 구성 요소:

  • openstack-manila
  • python-manilaclient
  • openstack-puppet-modules
  • openstack-tripleo-heat-templates

통합 노트:

  • 업스트림 manila 리포지토리에는 manila/share/drivers/ 의 드라이버가 포함되어 있습니다.
  • puppet-manila 리포지토리에는 manifests/backend 디렉터리에 드라이버 구성이 포함되어 있습니다.
  • puppet-manila 리포지토리에는 Manila 구성 파일에 속성을 추가하는 manila_config 라는 라이브러리가 포함되어 있습니다.

6장. 예
링크 복사

이 장에서는 Red Hat OpenStack Platform의 일부 벤더 통합 예를 소개합니다.

6.1. Cisco Nexus 1000V
링크 복사

Cisco Nexus 1000V는 가상 머신 액세스를 위해 설계된 네트워크 스위치입니다. 또한 VXLAN, ACL 및 IGMP 스누핑을 사용한 고급 전환 및 보안을 제공합니다. Cisco Nexus 1000V용 ml2 드라이버는 Neutron 서비스와 함께 설치할 수 있는 networking-cisco 리포지토리에 포함되어 있습니다.

Overcloud 이미지에는 Cisco Nexus 1000V를 사용하도록 Neutron을 구성하도록 클래스(neutron::plugins::ml2::cisco:: Cryostat1000v)를 포함하는 Neutron Puppet 모듈(puppet-neutron)이 포함되어 있습니다. 이 클래스는 모듈의 manifests/plugins/ml2/cisco/ Cryostat1000v.pp 매니페스트에 있습니다. 클래스는 기본 매개변수 세트를 사용하여 재정의한 다음 neutron_plugin_ml2 라이브러리를 사용하여 Cisco Nexus 1000V를 사용하도록 ml2 플러그인을 구성합니다. 

neutron_plugin_ml2 {
  'ml2/extension_drivers'                          : value => $extension_drivers;
  'ml2_cisco_n1kv/n1kv_vsm_ips'                    : value => $n1kv_vsm_ip;
  'ml2_cisco_n1kv/username'                        : value => $n1kv_vsm_username;
  'ml2_cisco_n1kv/password'                        : value => $n1kv_vsm_password;
  'ml2_cisco_n1kv/default_policy_profile'          : value => $default_policy_profile;
  'ml2_cisco_n1kv/default_vlan_network_profile'    : value => $default_vlan_network_profile;
  'ml2_cisco_n1kv/default_vxlan_network_profile'   : value => $default_vxlan_network_profile;
  'ml2_cisco_n1kv/poll_duration'                   : value => $poll_duration;
  'ml2_cisco_n1kv/http_pool_size'                  : value => $http_pool_size;
  'ml2_cisco_n1kv/http_timeout'                    : value => $http_timeout;
  'ml2_cisco_n1kv/sync_interval'                   : value => $sync_interval;
  'ml2_cisco_n1kv/max_vsm_retries'                 : value => $max_vsm_retries;
  'ml2_cisco_n1kv/restrict_policy_profiles'        : value => $restrict_policy_profiles;
  'ml2_cisco_n1kv/enable_vif_type_n1kv'            : value => $enable_vif_type_n1kv;
}
Copy to Clipboard Toggle word wrap

director의 Heat 템플릿 컬렉션에는 Cisco Nexus 1000V에 대한 Hiera 데이터를 구성하기 위해 환경 파일과 등록된 템플릿이 포함되어 있습니다. 환경 파일은 environments/cisco-n1kv-config.yaml 에 있으며 다음 기본 콘텐츠가 포함되어 있습니다. 

resource_registry:
  OS::TripleO::ControllerExtraConfigPre: ../puppet/extraconfig/pre_deploy/controller/cisco-n1kv.yaml
  OS::TripleO::ComputeExtraConfigPre: ../puppet/extraconfig/pre_deploy/controller/cisco-n1kv.yaml

parameter_defaults:
  N1000vVSMIP: '192.0.2.50'
  N1000vMgmtGatewayIP: '192.0.2.1'
  N1000vVSMDomainID: '100'
  N1000vVSMHostMgmtIntf: 'br-ex'
Copy to Clipboard Toggle word wrap

resource_registry 는 컨트롤러 및 컴퓨팅 노드(OS::TripleO::ControllerExtraConfigPre 및 OS::TripleO::ComputeExtraConfigPre)에 대한 사전 구성 리소스를 설정하여 puppet/extraconfig/pre_deploy/controller/cisco-n1kv.yaml 을 사전 구성에 사용할 템플릿으로 설정합니다. parameter_defaults 섹션에는 이러한 리소스에 전달할 몇 가지 매개변수가 포함되어 있습니다.

배포에 이 환경 파일을 포함하면 구성 중에 Puppet에서 Neutron Puppet 모듈의 매개 변수에 사용하는 Hiera 데이터가 정의됩니다.

Puppet 구성의 실제 애플리케이션 시작은 자동으로 수행됩니다. Heat 템플릿 컬렉션에는 컨트롤러 및 컴퓨팅 노드를 구성하기 위한 코어 Puppet 매니페스트 세트가 포함되어 있습니다. 이러한 파일에는 Cisco Nexus 1000V Hiera 데이터가 설정되어 있는지 감지하는 논리가 포함되어 있습니다. 배포 시 cisco-n1kv.yaml 을 포함하면 매니페스트에는 neutron::plugins::ml2::cisco:: Cryostat1000v 클래스와 Cisco Nexus 1000V의 VEM 및 VSM 에이전트가 포함됩니다. 

  if 'cisco_n1kv' in hiera('neutron_mechanism_drivers') {
    include neutron::plugins::ml2::cisco::nexus1000v

    class { 'neutron::agents::n1kv_vem':
      n1kv_source          => hiera('n1kv_vem_source', undef),
      n1kv_version         => hiera('n1kv_vem_version', undef),
    }

    class { 'n1k_vsm':
      n1kv_source       => hiera('n1kv_vsm_source', undef),
      n1kv_version      => hiera('n1kv_vsm_version', undef),
    }
  }
Copy to Clipboard Toggle word wrap

즉, Cisco Nexus 1000V를 사용하도록 Overcloud를 구성하려면 몇 가지 단계만 수행해야 합니다.

  1. environment/cisco-n1kv-config.yaml 파일을 로컬 위치에 복사하여 편집할 수 있습니다. 

    $ cp /usr/share/openstack-tripleo-heat-templates/environments/cisco-n1kv-config.yaml ~/templates/.
    Copy to Clipboard Toggle word wrap

  2. cisco-n1kv-config.yaml 파일을 편집합니다.

    • cisco-n1kv.yaml을 참조하는 절대 경로를 사용하도록 resource_registery 섹션을 수정합니다.

    • parameter_defaults 섹션을 수정하여 Cisco Nexus 1000V 매개변수를 추가합니다. 참조하려면 cisco-n1kv.yaml 을 참조하십시오.

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

      resource_registry:
  OS::TripleO::ControllerExtraConfigPre: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/controller/cisco-n1kv.yaml
  OS::TripleO::ComputeExtraConfigPre: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/controller/cisco-n1kv.yaml

parameter_defaults:
  N1000vVSMIP: '192.0.2.50'
  N1000vMgmtGatewayIP: '192.0.2.1'
  N1000vVSMDomainID: '100'
  N1000vVSMHostMgmtIntf: 'br-ex'
  N1000vVSMUser: admin
  N1000vVSMPassword: p@55w0rd!
      Copy to Clipboard Toggle word wrap

  3. 배포에 cisco-n1kv-config.yaml 파일을 포함합니다. 

    $ openstack overcloud deploy --templates -e ~/templates/cisco-n1kv-config.yaml
    Copy to Clipboard Toggle word wrap

이는 Cisco Nexus 1000V 구성을 Overcloud Hiera 데이터의 일부로 정의합니다. 그런 다음 Overcloud는 이 Hieradata를 사용하여 코어 구성 중에 Neutron의 Nexus 1000V ml2 드라이버를 구성합니다.

이 예에서는 director가 인증된 벤더의 네트워크 구성 요소를 Overcloud의 Neutron 서비스와 통합하는 방법을 보여줍니다.

6.2. NetApp Storage
링크 복사

NetApp은 OpenStack 스토리지 구성 요소와의 통합을 위한 여러 솔루션을 제공합니다. 이 예에서는 NetApp Storage가 Cinder와 통합되어 블록 스토리지에 대한 백엔드를 제공하는 방법을 보여줍니다.

Cinder용 드라이버는 프로젝트 자체에 포함되어 있으며 https://github.com/openstack/cinder 의 GitHub에서 공개적으로 사용할 수 있습니다. NetApp Storage용 드라이버는 리포지토리의 cinder/volume/drivers/netapp/ 디렉터리에 있습니다. 즉, 드라이버는 Red Hat OpenStack Platform에 자동으로 포함됩니다.

NetApp의 구성은 Overcloud 이미지에도 포함된 cinder(puppet-cinder)용 Puppet 모듈에 포함되어 있습니다. 구성이 포함된 Puppet 모듈의 매니페스트는 manifests/backend/netapp.pp 에 있습니다. 이 매니페스트는 cinder_config 라이브러리를 사용하여 Cinder 구성 파일에 netapp 설정을 추가합니다. 

cinder_config {
  "${name}/nfs_mount_options":            value => $nfs_mount_options;
  "${name}/volume_backend_name":          value => $volume_backend_name;
  "${name}/volume_driver":                value => 'cinder.volume.drivers.netapp.common.NetAppDriver';
  "${name}/netapp_login":                 value => $netapp_login;
  "${name}/netapp_password":              value => $netapp_password, secret => true;
  "${name}/netapp_server_hostname":       value => $netapp_server_hostname;
  "${name}/netapp_server_port":           value => $netapp_server_port;
  "${name}/netapp_size_multiplier":       value => $netapp_size_multiplier;
  "${name}/netapp_storage_family":        value => $netapp_storage_family;
  "${name}/netapp_storage_protocol":      value => $netapp_storage_protocol;
  "${name}/netapp_transport_type":        value => $netapp_transport_type;
  "${name}/netapp_vfiler":                value => $netapp_vfiler;
  "${name}/netapp_volume_list":           value => $netapp_volume_list;
  "${name}/netapp_vserver":               value => $netapp_vserver;
  "${name}/netapp_partner_backend_name":  value => $netapp_partner_backend_name;
  "${name}/expiry_thres_minutes":         value => $expiry_thres_minutes;
  "${name}/thres_avl_size_perc_start":    value => $thres_avl_size_perc_start;
  "${name}/thres_avl_size_perc_stop":     value => $thres_avl_size_perc_stop;
  "${name}/nfs_shares_config":            value => $nfs_shares_config;
  "${name}/netapp_copyoffload_tool_path": value => $netapp_copyoffload_tool_path;
  "${name}/netapp_controller_ips":        value => $netapp_controller_ips;
  "${name}/netapp_sa_password":           value => $netapp_sa_password, secret => true;
  "${name}/netapp_storage_pools":         value => $netapp_storage_pools;
  "${name}/netapp_eseries_host_type":     value => $netapp_eseries_host_type;
  "${name}/netapp_webservice_path":       value => $netapp_webservice_path;
}
Copy to Clipboard Toggle word wrap

director의 Heat 템플릿 컬렉션에는 NetApp Storage 백엔드의 Hiera 데이터를 구성하는 환경 파일과 등록된 템플릿이 포함되어 있습니다. 환경 파일은 environments/cinder-netapp-config.yaml 에 있으며 다음 기본 콘텐츠가 포함되어 있습니다. 

resource_registry:
  OS::TripleO::ControllerExtraConfigPre: ../puppet/extraconfig/pre_deploy/controller/cinder-netapp.yaml

parameter_defaults:
  CinderEnableNetappBackend: true
  CinderNetappBackendName: 'tripleo_netapp'
  CinderNetappLogin: ''
  CinderNetappPassword: ''
  CinderNetappServerHostname: ''
  CinderNetappServerPort: '80'
  CinderNetappSizeMultiplier: '1.2'
  CinderNetappStorageFamily: 'ontap_cluster'
  CinderNetappStorageProtocol: 'nfs'
  CinderNetappTransportType: 'http'
  CinderNetappVfiler: ''
  CinderNetappVolumeList: ''
  CinderNetappVserver: ''
  CinderNetappPartnerBackendName: ''
  CinderNetappNfsShares: ''
  CinderNetappNfsSharesConfig: '/etc/cinder/shares.conf'
  CinderNetappNfsMountOptions: ''
  CinderNetappCopyOffloadToolPath: ''
  CinderNetappControllerIps: ''
  CinderNetappSaPassword: ''
  CinderNetappStoragePools: ''
  CinderNetappEseriesHostType: 'linux_dm_mp'
  CinderNetappWebservicePath: '/devmgr/v2'
Copy to Clipboard Toggle word wrap

resource_registry 는 컨트롤러 노드(OS::TripleO::ControllerExtraConfigPre)에 대한 사전 구성 리소스(OS::TripleO::ControllerExtraConfigPre )를 설정하여 puppet/extraconfig/pre_deploy/controller/cinder-netapp.yaml 을 사전 구성에 사용할 템플릿으로 사용합니다. parameter_defaults 섹션에는 이러한 리소스에 전달할 몇 가지 매개변수가 포함되어 있습니다.

배포에 이 환경 파일을 포함하면 구성 중에 Puppet에서 Cinder Puppet 모듈의 매개 변수에 사용하는 Hiera 데이터가 정의됩니다.

Puppet 구성의 실제 애플리케이션 시작은 CinderEnableNetappBackend 매개변수에 따라 다릅니다. Heat 템플릿 컬렉션에는 컨트롤러 노드 구성을 위한 코어 Puppet 매니페스트 세트가 포함되어 있습니다. 이러한 파일에는 cinder_enable_netapp_backend Hiera 데이터가 설정되어 있는지 감지하는 논리가 포함되어 있습니다. Hiera 데이터는 사전 구성의 CinderEnableNetappBackend 매개변수를 사용하여 설정됩니다. 배포에 cinder-netapp-config.yaml 을 포함하고 CinderEnableNetappBackend: true 를 남겨 두는 것은 컨트롤러 Puppet 매니페스트에 cinder::backend::netapp 클래스가 포함되어 환경 파일에서 Hiera 데이터 값을 전달한다는 의미입니다. 

  if hiera('cinder_enable_netapp_backend', false) {
    $cinder_netapp_backend = hiera('cinder::backend::netapp::title')

    cinder_config {
      "${cinder_netapp_backend}/host": value => 'hostgroup';
    }

    if hiera('cinder::backend::netapp::nfs_shares', undef) {
      $cinder_netapp_nfs_shares = split(hiera('cinder::backend::netapp::nfs_shares', undef), ',')
    }

    cinder::backend::netapp { $cinder_netapp_backend :
      netapp_login                 => hiera('cinder::backend::netapp::netapp_login', undef),
      netapp_password              => hiera('cinder::backend::netapp::netapp_password', undef),
      netapp_server_hostname       => hiera('cinder::backend::netapp::netapp_server_hostname', undef),
      netapp_server_port           => hiera('cinder::backend::netapp::netapp_server_port', undef),
      netapp_size_multiplier       => hiera('cinder::backend::netapp::netapp_size_multiplier', undef),
      netapp_storage_family        => hiera('cinder::backend::netapp::netapp_storage_family', undef),
      netapp_storage_protocol      => hiera('cinder::backend::netapp::netapp_storage_protocol', undef),
      netapp_transport_type        => hiera('cinder::backend::netapp::netapp_transport_type', undef),
      netapp_vfiler                => hiera('cinder::backend::netapp::netapp_vfiler', undef),
      netapp_volume_list           => hiera('cinder::backend::netapp::netapp_volume_list', undef),
      netapp_vserver               => hiera('cinder::backend::netapp::netapp_vserver', undef),
      netapp_partner_backend_name  => hiera('cinder::backend::netapp::netapp_partner_backend_name', undef),
      nfs_shares                   => $cinder_netapp_nfs_shares,
      nfs_shares_config            => hiera('cinder::backend::netapp::nfs_shares_config', undef),
      netapp_copyoffload_tool_path => hiera('cinder::backend::netapp::netapp_copyoffload_tool_path', undef),
      netapp_controller_ips        => hiera('cinder::backend::netapp::netapp_controller_ips', undef),
      netapp_sa_password           => hiera('cinder::backend::netapp::netapp_sa_password', undef),
      netapp_storage_pools         => hiera('cinder::backend::netapp::netapp_storage_pools', undef),
      netapp_eseries_host_type     => hiera('cinder::backend::netapp::netapp_eseries_host_type', undef),
      netapp_webservice_path       => hiera('cinder::backend::netapp::netapp_webservice_path', undef),
    }
  }
Copy to Clipboard Toggle word wrap

즉, NetApp Storage를 사용하도록 Overcloud를 구성하려면 몇 가지 단계만 필요합니다.

  1. 환경/cinder-netapp-config.yaml 파일을 로컬 위치에 복사하여 편집할 수 있습니다. 

    $ cp /usr/share/openstack-tripleo-heat-templates/environments/cinder-netapp-config.yaml ~/templates/.
    Copy to Clipboard Toggle word wrap

  2. cinder-netapp-config.yaml 파일을 편집합니다.

    • cinder-netapp.yaml을 참조하는 절대 경로를 사용하도록 resource_registery 섹션을 수정합니다.

    • NetApp 매개 변수를 추가하려면 parameter_defaults 섹션을 수정합니다. 참조하려면 cinder-netapp.yaml 을 참조하십시오.

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

      resource_registry:
  OS::TripleO::ControllerExtraConfigPre: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/controller/cinder-netapp.yaml

parameter_defaults:
  CinderEnableNetappBackend: true
  CinderNetappBackendName: 'tripleo_netapp'
  CinderNetappLogin: 'admin'
  CinderNetappPassword: 'p@55w0rd!'
  CinderNetappServerHostname: 'netapp.example.com'
  CinderNetappServerPort: '80'
  CinderNetappSizeMultiplier: '1.2'
  CinderNetappStorageFamily: 'ontap_cluster'
  CinderNetappStorageProtocol: 'nfs'
  CinderNetappTransportType: 'http'
  CinderNetappNfsShares: '192.168.1.200:/storage1,192.168.1.200:/storage2'
  CinderNetappNfsSharesConfig: '/etc/cinder/shares.conf'
  CinderNetappEseriesHostType: 'linux_dm_mp'
  CinderNetappWebservicePath: '/devmgr/v2'
      Copy to Clipboard Toggle word wrap

      CinderEnableNetappBackend 를 true 로 설정된 상태로 둡니다.

  3. 배포에 cinder-netapp-config.yaml 파일을 포함합니다. 

    $ openstack overcloud deploy --templates -e ~/templates/cinder-netapp-config.yaml
    Copy to Clipboard Toggle word wrap

이렇게 하면 NetApp Storage 구성을 Overcloud Hiera 데이터의 일부로 정의합니다. 그런 다음 Overcloud는 이 Hieradata를 사용하여 코어 구성 중에 Cinder의 NetApp 백엔드를 구성합니다.

이 예에서는 director가 인증된 벤더의 스토리지 구성 요소를 Overcloud의 Cinder 서비스와 통합하는 방법을 보여줍니다.

법적 공지
링크 복사

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat