2장. 아키텍처

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개의 디스크가 있는 검색된 노드는 스토리지 노드로 프로비저닝될 가능성이 큽니다.

View larger image

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

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

View larger image

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"

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"

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

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

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

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

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

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

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

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

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

예를 들어 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}

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}

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

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