2장. Director 아키텍처

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

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

Bare Metal Provisioning은 노드의 전원 관리를 제어하고 인트로스펙션 메커니즘을 사용하여 하드웨어 정보 또는 팩트를 수집합니다. director는 인트로스펙션 프로세스의 정보를 사용하여 컨트롤러 노드, 컴퓨팅 노드, Storage 노드와 같은 다양한 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"

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 템플릿 컬렉션도 포함되어 있습니다. heat를 사용하여 director는 이 템플릿 컬렉션을 읽고 오버클라우드 스택을 오케스트레이션합니다.

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

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

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

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

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