2장. Director 아키텍처

베어 메탈 프로비저닝 서비스는 셀프 서비스 프로비저닝을 통해 최종 사용자에게 전용 베어 메탈 호스트를 제공합니다. director는 베어 메탈 프로비저닝을 사용하여 오버클라우드의 베어 메탈 하드웨어의 라이프사이클을 관리합니다. Bare Metal Provisioning에서는 자체 API를 사용하여 베어 메탈 노드를 정의합니다.

director를 사용하여 OpenStack 환경을 프로비저닝하려면 특정 드라이버를 사용하여 노드를 베어 메탈 프로비저닝에 등록해야 합니다. 지원되는 주요 드라이버는 대부분의 하드웨어에 IPMI 전원 관리 기능을 일부 지원하므로 IPMI(Intelligent Platform Management Interface)입니다. 그러나 Bare Metal Provisioning에는 HP iLO, Cisco UCS 또는 Dell DRAC와 같은 벤더별 기능도 포함되어 있습니다.

베어 메탈 프로비저닝은 노드의 전원 관리를 제어하고 인트로스펙션 메커니즘을 사용하여 하드웨어 정보 또는 팩트를 수집합니다. director는 인트로스펙션 프로세스의 정보를 사용하여 노드를 컨트롤러 노드, 컴퓨팅 노드, 스토리지 노드와 같은 다양한 OpenStack 환경 역할과 일치시킵니다. 예를 들어 10개의 디스크가 있는 검색된 노드가 일반적으로 스토리지 노드로 프로비저닝됩니다.

하드웨어에 대한 director 지원이 필요한 경우 베어 메탈 프로비저닝 서비스에 드라이버 적용이 있어야 합니다.

Heat는 애플리케이션 스택 오케스트레이션 엔진입니다. heat를 사용하여 클라우드에 배포하기 전에 애플리케이션의 요소를 정의할 수 있습니다. 구성에 대한 매개 변수 집합을 사용하여 여러 인프라 리소스(예: 인스턴스, 네트워크, 스토리지 볼륨, 탄력적 IP)가 포함된 스택 템플릿을 생성합니다. heat를 사용하여 지정된 종속성 체인을 기반으로 이러한 리소스를 만들고, 가용성에 대한 리소스를 모니터링하고, 필요한 경우 확장합니다. 이러한 템플릿을 사용하여 애플리케이션 스택을 이식 가능하게 만들고 반복 가능한 결과를 얻을 수 있습니다.

director는 기본 OpenStack heat API를 사용하여 오버클라우드 배포와 관련된 리소스를 프로비저닝하고 관리합니다. 여기에는 노드 역할별로 프로비저닝할 노드 수, 각 노드에 구성할 소프트웨어 구성 요소, 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이 포함됩니다. 표준 heat 툴을 사용하여 진행 중인 오버클라우드의 리소스 및 상태를 볼 수 있습니다. 예를 들어 heat 툴을 사용하여 오버클라우드를 중첩된 애플리케이션 스택으로 표시할 수 있습니다. heat 템플릿의 구문을 사용하여 프로덕션 OpenStack 클라우드를 선언하고 생성합니다. 모든 파트너 통합 사용 사례에는 heat 템플릿이 필요하므로 파트너 통합을 위해 사전 이해 및 숙련도가 있어야 합니다.

Puppet은 시스템의 최종 상태를 설명하고 유지 관리하는 데 사용할 수 있는 구성 관리 및 적용 도구입니다. 이 엔드 상태를 Puppet 매니페스트에 정의합니다. Puppet은 다음 두 가지 모델을 지원합니다.

다음 두 가지 방법으로 변경할 수 있습니다.

director는 다음 영역에서 Puppet을 사용합니다.

패키지 설치 및 서비스 사용이 필요한 파트너 통합 서비스는 요구 사항에 맞게 Puppet 모듈을 생성할 수 있습니다. 현재 OpenStack Puppet 모듈 및 예제를 가져오는 방법에 대한 자세한 내용은 4.2절. “OpenStack Puppet 모듈 가져오기” 를 참조하십시오.

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

tripleo에는 Red Hat 지원 오버클라우드 환경을 정의하는 heat 템플릿 컬렉션도 포함되어 있습니다. director는 heat를 사용하여 이 템플릿 컬렉션을 읽고 오버클라우드 스택을 오케스트레이션합니다.

Red Hat OpenStack Platform의 각 측면은 구성 가능 서비스로 나뉩니다. 즉, 다양한 서비스 조합을 사용하는 다양한 역할을 정의할 수 있습니다. 예를 들어 네트워킹 에이전트를 기본 컨트롤러 노드에서 독립 실행형 Networker 노드로 이동할 수 있습니다.

구성 가능 서비스 아키텍처에 대한 자세한 내용은 6장. 구성 가능 서비스 을 참조하십시오.

각 RHOSP(Red Hat OpenStack Platform) 서비스는 컨테이너에서 실행됩니다. 이를 통해 각 서비스를 자체 격리된 네임스페이스 내에서 호스트와 분리하여 유지할 수 있습니다. 다음과 같은 효과가 있습니다.

Red Hat OpenStack Platform은 Kolla 툴셋으로 빌드 및 관리되는 컨테이너 세트를 사용합니다.

Red Hat OpenStack Platform은 Ansible을 사용하여 구성 가능 서비스 업그레이드와 관련하여 특정 기능을 구동합니다. 여기에는 서비스 시작 및 중지 및 데이터베이스 업그레이드 수행과 같은 기능이 포함됩니다. 이러한 업그레이드 작업은 구성 가능 서비스 템플릿 내에 정의됩니다.