Menu Close

고급 오버클라우드 사용자 정의

Red Hat OpenStack Platform 16.1

Red Hat OpenStack Platform director를 사용하여 고급 기능을 구성하는 방법

초록

Red Hat OpenStack Platform director를 사용하여 RHOSP(Red Hat OpenStack Platform) 엔터프라이즈 환경에 대해 고급 기능을 구성합니다. 여기에는 네트워크 격리, 스토리지 구성, SSL 통신 및 일반 구성 방법과 같은 기능이 포함됩니다.

preface

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견을 보내 주십시오. Red Hat이 어떻게 이를 개선하는지 알려주십시오.

DDF(직접 문서 피드백) 기능 사용

특정 문장, 단락 또는 코드 블록에 대한 직접 주석은 피드백 추가 DDF 기능을 사용하십시오.

  1. 다중 페이지 HTML 형식으로 설명서를 봅니다.
  2. 문서 오른쪽 상단에 Feedback (피드백) 버튼이 표시되는지 확인합니다.
  3. 주석 처리하려는 텍스트 부분을 강조 표시합니다.
  4. 피드백 추가를 클릭합니다.
  5. 주석을 사용하여 Add Feedback (피드백 추가) 필드를 작성합니다.
  6. 선택 사항: 설명서 팀이 문제에 대한 자세한 내용을 문의할 수 있도록 이메일 주소를 추가하십시오.
  7. Submit(제출)을 클릭합니다.

1장. 오버클라우드 설정 소개

RHOSP(Red Hat OpenStack Platform) director는 Overcloud라고도 하는 완전한 기능을 갖춘 OpenStack 환경을 프로비저닝하고 생성하는 데 사용할 수 있는 툴 세트를 제공합니다. Director 설치 및 사용 가이드 에서는 기본 Overcloud의 준비 및 구성을 다룹니다. 그러나 프로덕션 수준 오버클라우드에는 추가 구성이 필요할 수 있습니다.

  • 오버클라우드를 기존 네트워크 인프라에 통합하기 위한 기본 네트워크 구성입니다.
  • 특정 OpenStack 네트워크 트래픽 유형의 별도의 VLAN에서 네트워크 트래픽 격리.
  • 공용 엔드 포인트에서 통신을 보호하기 위한 SSL 구성
  • NFS, iSCSI, Red Hat Ceph Storage 및 여러 타사 스토리지 장치와 같은 스토리지 옵션.
  • Red Hat Content Delivery Network 노드 등록 또는 내부 Red Hat Satellite 5 또는 6 서버에 등록.
  • 다양한 시스템 수준 옵션.
  • 다양한 OpenStack 서비스 옵션.
참고

이 가이드의 예제는 오버클라우드를 구성하는 선택적 단계입니다. 다음 단계는 오버클라우드에 추가 기능을 제공하려는 경우에만 필요합니다. 사용자 환경의 요구 사항에 적용되는 단계를 사용합니다.

2장. heat 템플릿 이해

이 가이드의 사용자 지정 구성에서는 heat 템플릿 및 환경 파일을 사용하여 Overcloud의 특정 측면을 정의합니다. 이 장에서는 Red Hat OpenStack Platform director의 맥락에서 이러한 템플릿의 구조와 형식을 이해할 수 있도록 heat 템플릿에 대한 기본적인 소개를 제공합니다.

2.1. Heat 템플릿

director는 HOT(Heat Orchestration Templates)를 오버클라우드 배포 계획의 템플릿 형식으로 사용합니다. HOT 형식의 템플릿은 일반적으로 YAML 형식으로 표시됩니다. 템플릿의 목적은 OpenStack Orchestration(heat)에서 생성하는 리소스 컬렉션 및 리소스의 구성인 스택을 정의하고 생성하는 것입니다. 리소스는 RHOSP(Red Hat OpenStack Platform)의 개체이며 컴퓨팅 리소스, 네트워크 구성, 보안 그룹, 확장 규칙 및 사용자 지정 리소스를 포함할 수 있습니다.

Heat 템플릿에는 다음 세 가지 섹션이 있습니다.

parameters
이러한 설정은 heat로 전달되며, 스택을 사용자 지정하는 방법과 전달된 값이 없는 매개 변수의 기본값을 제공합니다. 이러한 설정은 템플릿의 parameters 섹션에 정의되어 있습니다.
resources
resources 섹션을 사용하여 이 템플릿을 사용하여 스택을 배포할 때 생성할 수 있는 계산 인스턴스, 네트워크 및 스토리지 볼륨과 같은 리소스를 정의합니다. RHOSP(Red Hat OpenStack Platform)에는 모든 구성 요소에 걸쳐 있는 핵심 리소스 세트가 포함되어 있습니다. 이는 스택의 일부로 만들고 구성할 특정 오브젝트입니다. RHOSP에는 모든 구성 요소에 걸쳐 있는 핵심 리소스 세트가 포함되어 있습니다. 이러한 값은 템플릿의 resources 섹션에 정의되어 있습니다.
출력
outputs 섹션을 사용하여 스택을 만든 후 클라우드 사용자가 액세스할 수 있는 출력 매개 변수를 선언합니다. 클라우드 사용자는 이러한 매개 변수를 사용하여 배포된 인스턴스의 IP 주소 또는 스택의 일부로 배포된 웹 애플리케이션의 URL과 같은 스택에 대한 세부 정보를 요청할 수 있습니다.

기본 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 ] }

이 템플릿은 리소스 유형 유형을 사용합니다. OS::Nova::Server: cloud 사용자가 지정하는 특정 플레이버, 이미지 및 키를 사용하여 my_instance 라는 인스턴스를 만듭니다. 스택은 My Cirros Instance 라는 instance_name 값을 반환할 수 있습니다.

Heat에서 템플릿을 처리하면 템플릿의 스택과 리소스 템플릿의 하위 스택 세트를 생성합니다. 이렇게 하면 템플릿으로 정의한 기본 스택에서 내림되는 스택의 계층 구조가 생성됩니다. 다음 명령을 사용하여 스택 계층 구조를 볼 수 있습니다.

$ openstack stack list --nested

2.2. 환경 파일

환경 파일은 heat 템플릿을 사용자 지정하는 데 사용할 수 있는 특수 유형의 템플릿입니다. 코어 heat 템플릿 외에도 배포 명령에 환경 파일을 포함할 수 있습니다. 환경 파일에는 다음 세 가지 섹션이 포함되어 있습니다.

resource_registry
이 섹션에서는 다른 heat 템플릿에 연결된 사용자 지정 리소스 이름을 정의합니다. 이를 통해 핵심 리소스 컬렉션 내에 존재하지 않는 사용자 지정 리소스를 생성할 수 있습니다.
parameters
이는 최상위 템플릿의 매개 변수에 적용하는 일반적인 설정입니다. 예를 들어 리소스 레지스트리 매핑과 같이 중첩 스택을 배포하는 템플릿이 있는 경우 매개 변수는 중첩된 리소스의 템플릿이 아닌 최상위 템플릿에만 적용됩니다.
parameter_defaults
이러한 매개 변수는 모든 템플릿에서 매개 변수의 기본값을 수정합니다. 예를 들어 리소스 레지스트리 매핑과 같이 중첩된 스택을 배포하는 heat 템플릿이 있는 경우 매개변수 기본값은 모든 템플릿에 적용됩니다.
중요

오버클라우드의 사용자 지정 환경 파일을 생성할 때 매개변수 대신 parameter_defaults 를 사용하여 오버클라우드의 모든 스택 템플릿에 적용합니다.

기본 환경 파일의 예:

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

parameter_defaults:
  NetworkName: my_network

parameters:
  MyIP: 192.168.0.1

이 환경 파일(my_env.yaml)은 특정 heat 템플릿(my_template.yaml)에서 스택을 생성할 때 포함될 수 있습니다. my_env.yaml 파일은 OS::Nova::Server::MyServer 라는 새 리소스 유형을 생성합니다. myserver.yaml 파일은 내장된 모든 리소스 유형을 재정의하는 이 리소스 유형의 구현을 제공하는 heat 템플릿 파일입니다. my_template.yaml 파일에 OS::Nova::Server::MyServer 리소스를 포함할 수 있습니다.

my ip 는 이 환경 파일로 배포하는 기본 heat 템플릿에만 매개 변수를 적용합니다. 이 예에서 MyIPmy_template.yaml 의 매개 변수에만 적용됩니다.

NetworkName 은 기본 heat 템플릿 my_template.yaml 과 기본 템플릿에 포함된 리소스(예: 이 예제의 OS::Nova::Server::MyServer 리소스 및 myserver.yaml 템플릿)에 모두 적용됩니다.

참고

RHOSP에서 heat 템플릿 파일을 사용자 지정 템플릿 리소스로 사용하려면 파일 확장자가 .yaml 또는 .template이어야 합니다.

2.3. 코어 오버클라우드 heat 템플릿

director에는 오버클라우드의 코어 heat 템플릿 컬렉션 및 환경 파일 컬렉션이 포함되어 있습니다. 이 컬렉션은 /usr/share/openstack-tripleo-heat-templates 에 저장됩니다.

이 템플릿 컬렉션의 기본 파일과 디렉터리는 다음과 같습니다.

overcloud.j2.yaml
director에서 오버클라우드 환경을 생성하는 데 사용하는 기본 템플릿 파일입니다. 이 파일은 Jinja2 구문을 사용하여 템플릿의 특정 섹션을 반복하여 사용자 지정 역할을 생성합니다. Jinja2 형식은 Overcloud 배포 프로세스 중에 YAML로 렌더링됩니다.
overcloud-resource-registry-puppet.j2.yaml
director에서 오버클라우드 환경을 생성하는 데 사용하는 기본 환경 파일입니다. Overcloud 이미지에 저장된 Puppet 모듈에 대한 구성 세트를 제공합니다. director가 각 노드에 오버클라우드 이미지를 쓰고 나면 heat는 이 환경 파일에 등록된 리소스를 사용하여 각 노드의 Puppet 구성을 시작합니다. 이 파일은 Jinja2 구문을 사용하여 템플릿의 특정 섹션을 반복하여 사용자 지정 역할을 생성합니다. Jinja2 형식은 Overcloud 배포 프로세스 중에 YAML로 렌더링됩니다.
roles_data.yaml
이 파일에는 오버클라우드의 역할 정의가 포함되어 있으며 서비스를 각 역할에 매핑합니다.
network_data.yaml
이 파일에는 오버클라우드의 네트워크 정의와 서브넷, 할당 풀, VIP 상태 등의 속성이 포함되어 있습니다. 기본 network_data.yaml 파일에는 기본 네트워크가 포함되어 있습니다. 외부, 내부 API, 스토리지, 스토리지 관리, 테넌트 및 관리. 사용자 지정 network_data.yaml 파일을 생성하고 -n 옵션을 사용하여 openstack overcloud deploy 명령에 추가할 수 있습니다.
plan-environment.yaml
이 파일에는 오버클라우드 계획에 대한 메타데이터 정의가 포함되어 있습니다. 여기에는 계획 이름, 사용할 기본 템플릿, Overcloud에 적용할 환경 파일이 포함됩니다.
capabilities-map.yaml
이 파일에는 오버클라우드 계획에 대한 환경 파일 매핑이 포함되어 있습니다.
Deployment
이 디렉터리에는 heat 템플릿이 포함되어 있습니다. overcloud-resource-registry-puppet.j2.yaml 환경 파일은 이 디렉터리의 파일을 사용하여 각 노드에서 Puppet 구성의 애플리케이션을 구동합니다.
환경
이 디렉터리에는 오버클라우드 생성에 사용할 수 있는 추가 heat 환경 파일이 있습니다. 이러한 환경 파일을 사용하면 결과 RHOSP(Red Hat OpenStack Platform) 환경에 추가 기능을 사용할 수 있습니다. 예를 들어 디렉터리에는 Cinder NetApp 백엔드 스토리지(cinder-netapp-config.yaml)를 활성화하기 위한 환경 파일이 포함되어 있습니다.
network
이 디렉터리에는 격리된 네트워크 및 포트를 생성하는 데 사용할 수 있는 heat 템플릿 세트가 포함되어 있습니다.
Puppet
이 디렉터리에는 Puppet 구성을 제어하는 템플릿이 포함되어 있습니다. overcloud-resource-registry-puppet.j2.yaml 환경 파일은 이 디렉터리의 파일을 사용하여 각 노드에서 Puppet 구성의 애플리케이션을 구동합니다.
puppet/services
이 디렉터리에는 모든 서비스 구성에 대한 레거시 heat 템플릿이 포함되어 있습니다. 배포 디렉터리의 템플릿은 puppet/services 디렉터리의 대부분의 템플릿을 대체합니다.
extraconfig
이 디렉터리에는 추가 기능을 활성화하는 데 사용할 수 있는 템플릿이 포함되어 있습니다.
firstboot
이 디렉터리에는 director가 처음에 노드를 만들 때 사용하는 first_boot 스크립트 예제가 포함되어 있습니다.

2.4. 환경 메타데이터 계획

계획 환경 메타데이터 파일에서 오버클라우드 계획에 대한 메타데이터를 정의할 수 있습니다. director는 오버클라우드 생성 중에 메타데이터를 적용하고 오버클라우드 계획을 가져오고 내보낼 때 적용합니다.

계획 환경 파일을 사용하여 director가 OpenStack Workflow(Mistral) 서비스로 실행할 수 있는 워크플로를 정의합니다. 계획 환경 메타데이터 파일에는 다음과 같은 매개변수가 포함되어 있습니다.

버전
템플릿의 버전입니다.
name
계획 파일을 저장하는 데 사용할 오버클라우드 계획 및 OpenStack Object Storage(swift)의 컨테이너 이름입니다.
template
오버클라우드 배포에 사용할 코어 상위 템플릿입니다. 이는 overcloud.yaml. j2 템플릿의 렌더링된 버전인 overcloud.yaml 입니다.
환경
사용할 환경 파일 목록을 정의합니다. path 하위 매개 변수를 사용하여 각 환경 파일의 이름과 상대 위치를 지정합니다.
parameter_defaults
오버클라우드에서 사용할 매개변수 세트입니다. 이 기능은 표준 환경 파일의 parameter_defaults 섹션과 동일한 방식으로 작동합니다.
암호
오버클라우드 암호에 사용하려는 매개변수 세트입니다. 이 기능은 표준 환경 파일의 parameter_defaults 섹션과 동일한 방식으로 작동합니다. 일반적으로 director는 이 섹션을 임의로 생성된 암호로 자동으로 채웁니다.
workflow_parameters
이 매개변수를 사용하여 OpenStack Workflow(mistral) 네임스페이스에 매개 변수 집합을 제공합니다. 이를 사용하여 특정 오버클라우드 매개변수를 계산하고 자동으로 생성할 수 있습니다.

다음 코드 조각은 계획 환경 파일의 구문의 예입니다.

version: 1.0
name: myovercloud
description: 'My Overcloud Plan'
template: overcloud.yaml
environments:
- path: overcloud-resource-registry-puppet.yaml
- path: environments/containers-default-parameters.yaml
- path: user-environment.yaml
parameter_defaults:
  ControllerCount: 1
  ComputeCount: 1
  OvercloudComputeFlavor: compute
  OvercloudControllerFlavor: control
workflow_parameters:
  tripleo.derive_params.v1.derive_parameters:
    num_phy_cores_per_numa_node_for_pmd: 2

openstack overcloud deploy 명령을 사용하여 -p 옵션을 사용하여 계획 환경 메타데이터 파일을 포함할 수 있습니다.

(undercloud) $ openstack overcloud deploy --templates \
  -p /my-plan-environment.yaml \
  [OTHER OPTIONS]

다음 명령을 사용하여 기존 오버클라우드 계획의 계획 메타데이터를 볼 수도 있습니다.

(undercloud) $ openstack object save overcloud plan-environment.yaml --file -

2.5. 오버클라우드 생성 시 환경 파일 포함

-e 옵션을 사용하여 배포 명령에 환경 파일을 포함합니다. 환경 파일은 필요한 수만큼 추가할 수 있습니다. 그러나 후속 환경 파일에 정의된 매개변수와 리소스가 우선하므로 환경 파일의 순서가 중요합니다. 예를 들어 일반 리소스 유형 OS::TripleO::NodeExtraConfigPost 및 공통 매개변수 TimeZone 이 포함된 두 개의 환경 파일이 있습니다.

environment-file-1.yaml

resource_registry:
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/template-1.yaml

parameter_defaults:
  RabbitFDLimit: 65536
  TimeZone: 'Japan'

environment-file-2.yaml

resource_registry:
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/template-2.yaml

parameter_defaults:
  TimeZone: 'Hongkong'

배포 명령에 두 환경 파일을 모두 포함합니다.

$ openstack overcloud deploy --templates -e environment-file-1.yaml -e environment-file-2.yaml

openstack overcloud deploy 명령은 다음 프로세스를 통해 실행됩니다.

  1. 코어 heat 템플릿 컬렉션에서 기본 구성을 로드합니다.
  2. environment-file-1.yaml 의 구성을 적용하여 기본 구성의 일반적인 설정을 재정의합니다.
  3. environment-file-2.yaml 의 구성을 적용하여 기본 구성 및 environment-file-1.yaml 의 공통 설정을 재정의합니다.

그러면 오버클라우드의 기본 설정이 다음과 같이 변경됩니다.

  • OS::TripleO::NodeExtraConfigPost 리소스는 environment-file -2.yaml에 정의된 대로 /home/stack/templates/template -2.yaml 로 설정됩니다.
  • timezone 매개변수는 environment-file-2.yaml 에 정의된 대로 Hongkong 으로 설정됩니다.
  • RabbitFDLimit 매개변수는 environment -file-1.yaml 에 정의된 대로 65536 으로 설정됩니다.environment-file-2.yaml 은 이 값을 변경하지 않습니다.

이 메커니즘을 사용하여 여러 환경 파일 충돌의 값 없이 오버클라우드에 대한 사용자 지정 구성을 정의할 수 있습니다.

2.6. 사용자 지정 코어 heat 템플릿 사용

오버클라우드를 생성할 때 director는 /usr/share/openstack-tripleo-heat-templates 에 있는 코어 heat 템플릿 세트를 사용합니다. 이 코어 템플릿 컬렉션을 사용자 지정하려면 다음 Git 워크플로를 사용하여 사용자 정의 템플릿 컬렉션을 관리합니다.

절차

  • heat 템플릿 컬렉션이 포함된 초기 Git 리포지토리를 생성합니다.

    1. 템플릿 컬렉션을 /home/stack/templates 디렉터리에 복사합니다.

      $ cd ~/templates
      $ cp -r /usr/share/openstack-tripleo-heat-templates .
    2. 사용자 지정 템플릿 디렉터리로 변경하고 Git 리포지토리를 초기화합니다.

      $ cd ~/templates/openstack-tripleo-heat-templates
      $ git init .
    3. Git 사용자 이름 및 이메일 주소를 구성합니다.

      $ git config --global user.name "<USER_NAME>"
      $ git config --global user.email "<EMAIL_ADDRESS>"

      <USER_NAME> 을 사용하려는 사용자 이름으로 바꿉니다. <EMAIL_ADDRESS> 를 이메일 주소로 바꿉니다.

    4. 초기 커밋을 위한 모든 템플릿을 스테이징합니다.

      $ git add *
    5. 초기 커밋을 생성합니다.

      $ git commit -m "Initial creation of custom core heat templates"

      이렇게 하면 최신 코어 템플릿 컬렉션이 포함된 초기 master 분기가 생성됩니다. 이 분기를 사용자 지정 분기의 기반으로 사용하고 새 템플릿 버전을 이 분기에 병합합니다.

  • 사용자 지정 분기를 사용하여 코어 템플릿 컬렉션에 변경 사항을 저장합니다. 다음 절차를 사용하여 my-customizations 분기를 생성하고 사용자 지정을 추가합니다.

    1. my-customizations 분기를 생성하여 해당 분기로 전환합니다.

      $ git checkout -b my-customizations
    2. 사용자 지정 분기의 파일을 편집합니다.
    3. git에서 변경 사항을 스테이징합니다.

      $ git add [edited files]
    4. 사용자 정의 분기의 변경 사항을 커밋합니다.

      $ git commit -m "[Commit message for custom changes]"

      그러면 my-customizations 분기에 대한 커밋으로 변경 사항이 추가됩니다. master 분기가 업데이트되면 마스터에서 my-customizations 를 다시 평가 하여 git에서 이러한 커밋을 업데이트된 템플릿 컬렉션에 추가할 수 있습니다. 이렇게 하면 사용자 지정을 추적하고 향후 템플릿 업데이트에서 재생하는 데 도움이 됩니다.

  • 언더클라우드를 업데이트하면 openstack-tripleo-heat-templates 패키지도 업데이트를 수신할 수 있습니다. 이 경우 사용자 정의 템플릿 컬렉션을 업데이트해야 합니다.

    1. openstack-tripleo-heat-templates 패키지 버전을 환경 변수로 저장합니다.

      $ export PACKAGE=$(rpm -qv openstack-tripleo-heat-templates)
    2. 템플릿 컬렉션 디렉터리로 변경하고 업데이트된 템플릿의 새 분기를 생성합니다.

      $ cd ~/templates/openstack-tripleo-heat-templates
      $ git checkout -b $PACKAGE
    3. 분기의 모든 파일을 제거하고 새 버전으로 바꿉니다.

      $ git rm -rf *
      $ cp -r /usr/share/openstack-tripleo-heat-templates/* .
    4. 초기 커밋을 위한 모든 템플릿을 추가합니다.

      $ git add *
    5. 패키지 업데이트에 대한 커밋을 생성합니다.

      $ git commit -m "Updates for $PACKAGE"
    6. 분기를 master에 병합합니다. Git 관리 시스템(예: GitLab)을 사용하는 경우 관리 워크플로를 사용합니다. Git을 로컬로 사용하는 경우 master 분기로 전환하여 병합하고 git merge 명령을 실행합니다.

      $ git checkout master
      $ git merge $PACKAGE

이제 master 분기에 최신 버전의 코어 템플릿 컬렉션이 포함됩니다. 이제 이 업데이트된 컬렉션에서 my-customization 분기를 다시 평가할 수 있습니다.

  • my-customization 분기를 업데이트합니다.

    1. my-customizations 분기로 변경합니다.

      $ git checkout my-customizations
    2. 마스터에서 분기를 다시베이스합니다.

      $ git rebase master

      그러면 my-customizations 분기를 업데이트하고 이 분기에 대한 사용자 지정 커밋을 재생합니다.

  • 리베이스 중에 발생하는 모든 충돌을 해결합니다.

    1. 충돌이 포함된 파일을 확인합니다.

      $ git status
    2. 식별된 템플릿 파일의 충돌을 해결합니다.
    3. 해결된 파일을 추가합니다.

      $ git add [resolved files]
    4. 업데이트를 계속합니다.

      $ git rebase --continue
  • 사용자 지정 템플릿 컬렉션을 배포합니다.

    1. my-customization 분기로 전환되었는지 확인합니다.

      git checkout my-customizations
    2. 로컬 템플릿 디렉터리를 지정하려면 --templates 옵션과 함께 openstack overcloud deploy 명령을 실행합니다.

      $ openstack overcloud deploy --templates /home/stack/templates/openstack-tripleo-heat-templates [OTHER OPTIONS]
참고

디렉터리 없이 --templates 옵션을 지정하는 경우 director는 기본 템플릿 디렉터리(/usr/share/openstack-tripleo-heat-templates )를 사용합니다.

중요

Red Hat은 heat 템플릿 컬렉션을 수정하는 대신 4장. 구성 후크 에서 방법을 사용하는 것이 좋습니다.

2.7. Jinja2 렌더링

/usr/share/openstack-tripleo-heat-templates 의 코어 heat 템플릿에는 j2.yaml 파일 확장자가 있는 여러 파일이 포함되어 있습니다. 이러한 파일에는 Jinja2 템플릿 구문이 포함되어 있으며 director는 이러한 파일을 .yaml 확장자가 있는 정적 heat 템플릿에 렌더링합니다. 예를 들어 기본 overcloud.j2.yaml 파일은 overcloud.yaml 에 렌더링됩니다. director는 생성된 overcloud.yaml 파일을 사용합니다.

Jinja2 지원 heat 템플릿은 Jinja2 구문을 사용하여 반복적인 값에 대한 매개 변수와 리소스를 생성합니다. 예를 들어 overcloud.j2.yaml 파일에는 다음 스니펫이 포함되어 있습니다.

parameters:
...
{% for role in roles %}
  ...
  {{role.name}}Count:
    description: Number of {{role.name}} nodes to deploy
    type: number
    default: {{role.CountDefault|default(0)}}
  ...
{% endfor %}

director가 Jinja2 구문을 렌더링하면 director가 roles_data.yaml 파일에 정의된 역할을 반복하고 {{role.name}}Count 매개 변수를 역할 이름으로 채웁니다. 기본 roles_data.yaml 파일에는 5개의 역할이 포함되어 있으며, 결과적으로 예제에서 다음 매개변수가 생성됩니다.

  • ControllerCount
  • ComputeCount
  • BlockStorageCount
  • ObjectStorageCount
  • CephStorageCount

렌더링된 매개변수의 예는 다음과 같습니다.

parameters:
  ...
  ControllerCount:
    description: Number of Controller nodes to deploy
    type: number
    default: 1
  ...

director는 코어 heat 템플릿의 디렉터리에서만 Jinja2 지원 템플릿과 환경 파일을 렌더링합니다. 다음 사용 사례에서는 Jinja2 템플릿을 렌더링하는 올바른 방법을 보여줍니다.

사용 사례 1: 기본 코어 템플릿

template 디렉터리: /usr/share/openstack-tripleo-heat-templates/

환경 파일: /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.j2.yaml

director는 기본 코어 템플릿 위치(--templates)를 사용하고 network-isolation.j2.yaml 파일을 network -isolation.yaml 로 렌더링합니다. openstack overcloud deploy 명령을 실행하는 경우 -e 옵션을 사용하여 렌더링된 network-isolation.yaml 파일의 이름을 포함합니다.

$ openstack overcloud deploy --templates \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml
    ...

사용 사례 2: 사용자 정의 코어 템플릿

템플릿 디렉터리: /home/stack/tripleo-heat-templates

환경 파일: /home/stack/tripleo-heat-templates/environments/network-isolation.j2.yaml

director는 사용자 지정 코어 템플릿 위치(--templates /home/stack/tripleo-heat-templates)를 사용하고 사용자 지정 코어 템플릿 내에서 network-isolation.j2.yaml 파일을 network-isolation.yaml 로 렌더링합니다. openstack overcloud deploy 명령을 실행하는 경우 -e 옵션을 사용하여 렌더링된 network-isolation.yaml 파일의 이름을 포함합니다.

$ openstack overcloud deploy --templates /home/stack/tripleo-heat-templates \
    -e /home/stack/tripleo-heat-templates/environments/network-isolation.yaml
    ...

활용 사례 3: 사용 올바르지 않음

template 디렉터리: /usr/share/openstack-tripleo-heat-templates/

환경 파일: /home/stack/tripleo-heat-templates/environments/network-isolation.j2.yaml

director는 사용자 지정 코어 템플릿 위치(--templates /home/stack/tripleo-heat-templates)를 사용합니다. 그러나 선택한 network-isolation.j2.yaml 은 사용자 지정 코어 템플릿 내에 없으므로 network-isolation.yaml 로 렌더링되지 않습니다. 이로 인해 배포가 실패합니다.

Jinja2 구문을 정적 템플릿으로 처리

openstack-tripleo -heat-templates의 Jinja2 구문을 정적 템플릿 세트로 렌더링하려면 process-templates.py 스크립트를 사용합니다. process-templates.py 스크립트를 사용하여 openstack-tripleo-heat-templates 컬렉션 사본을 렌더링하려면 openstack-tripleo-heat-templates 디렉터리로 변경합니다.

$ cd /usr/share/openstack-tripleo-heat-templates

tool 디렉터리에 있는 process-templates.py 스크립트를 -o 옵션과 함께 실행하여 정적 복사본을 저장하는 사용자 지정 디렉터리를 정의합니다.

$ ./tools/process-templates.py -o ~/openstack-tripleo-heat-templates-rendered

이렇게 하면 모든 Jinja2 템플릿을 렌더링된 YAML 버전으로 변환하고 결과를 ~/openstack-tripleo-heat-templates-rendered에 저장합니다.

3장. heat 매개변수

director 템플릿 컬렉션의 각 heat 템플릿에는 parameters 섹션이 포함되어 있습니다. 이 섹션에서는 특정 오버클라우드 서비스와 관련된 모든 매개변수에 대한 정의가 포함되어 있습니다. 여기에는 다음이 포함됩니다.

  • overcloud.j2.yaml - 기본 기본 매개변수
  • roles_data.yaml - 구성 가능 역할에 대한 기본 매개변수
  • deployment/*.yaml - 특정 서비스의 기본 매개변수

다음 방법을 사용하여 이러한 매개변수의 값을 수정할 수 있습니다.

  1. 사용자 지정 매개 변수에 대한 환경 파일을 만듭니다.
  2. 사용자 지정 매개 변수를 환경 파일의 parameter_defaults 섹션에 포함합니다.
  3. openstack overcloud deploy 명령을 사용하여 환경 파일을 포함합니다.

3.1. 예 1: 시간대 구성

시간대(puppet/services/time/timezone.yaml)를 설정하는 Heat 템플릿에는 TimeZone 매개변수가 포함되어 있습니다. TimeZone 매개변수를 비워 두면 오버클라우드에서 시간을 기본값으로 UTC 로 설정합니다.

시간대 목록을 가져오려면 timedatectl list-timezones 명령을 실행합니다. 다음 예제 명령은 아시아의 시간대를 검색합니다.

$ sudo timedatectl list-timezones|grep "Asia"

시간대를 식별한 후 환경 파일에서 TimeZone 매개변수를 설정합니다. 다음 예제 환경 파일은 TimeZone 값을 Asia/Tokyo 로 설정합니다.

parameter_defaults:
  TimeZone: 'Asia/Tokyo'

3.2. 예 2: RabbitMQ 파일 설명자 제한 구성

특정 구성의 경우 RabbitMQ 서버의 파일 설명자 제한을 늘려야 할 수 있습니다. deployment/rabbitmq/rabbitmq-container-puppet.yaml heat 템플릿을 사용하여 RabbitFDLimit 매개변수에 새 제한을 설정합니다. 다음 항목을 환경 파일에 추가합니다.

parameter_defaults:
  RabbitFDLimit: 65536

3.3. 예 3: 매개변수 활성화 및 비활성화

배포 중에 매개 변수를 초기에 설정한 다음 업데이트 또는 확장 작업과 같은 향후 배포 작업에 대해 매개 변수를 비활성화해야 할 수 있습니다. 예를 들어 오버클라우드 생성 중에 사용자 지정 RPM을 포함하려면 환경 파일에 다음 항목을 포함합니다.

parameter_defaults:
  DeployArtifactURLs: ["http://www.example.com/myfile.rpm"]

이후 배포에서 이 매개 변수를 비활성화하려면 매개 변수를 제거하는 것만으로는 충분하지 않습니다. 대신 매개변수를 빈 값으로 설정해야 합니다.

parameter_defaults:
  DeployArtifactURLs: []

이렇게 하면 후속 배포 작업에 더 이상 매개변수가 설정되지 않습니다.

3.4. 예 4: 역할 기반 매개변수

[ROLE]Parameters 매개 변수를 사용하여 [ROLE] 을 구성 가능 역할로 교체하여 특정 역할에 대한 매개 변수를 설정합니다.

예를 들어 director는 컨트롤러 및 컴퓨팅 노드 모두에 sshd 를 구성합니다. 컨트롤러 및 컴퓨팅 노드에 대해 다른 sshd 매개변수를 설정하려면 ControllerParameters 매개변수와 Compute Parameters 매개변수가 모두 포함된 환경 파일을 생성하고 각 특정 역할에 대해 sshd 매개변수를 설정합니다.

parameter_defaults:
  ControllerParameters:
    BannerText: "This is a Controller node"
  ComputeParameters:
    BannerText: "This is a Compute node"

3.5. 수정할 매개변수 식별

Red Hat OpenStack Platform director는 설정에 필요한 여러 매개변수를 제공합니다. 설정하려는 특정 옵션과 해당 director 매개변수를 식별하는 데 어려움이 있을 수 있습니다. director를 사용하여 설정할 옵션이 있는 경우 다음 워크플로우를 사용하여 옵션을 식별하고 특정 오버클라우드 매개변수에 매핑합니다.

  1. 구성할 옵션을 식별합니다. 옵션을 사용하는 서비스를 기록합니다.
  2. 이 옵션에 해당하는 Puppet 모듈을 확인합니다. Red Hat OpenStack Platform용 Puppet 모듈은 director 노드의 /etc/puppet/modules 에 있습니다. 각 모듈은 특정 서비스에 해당합니다. 예를 들어 keystone 모듈은 OpenStack ID(keystone)에 해당합니다.

    • Puppet 모듈에 선택한 옵션을 제어하는 변수가 포함된 경우 다음 단계로 이동합니다.
    • Puppet 모듈에 선택한 옵션을 제어하는 변수가 없으면 이 옵션에 대한 hieradata가 없습니다. 가능한 경우 오버클라우드가 배포를 완료한 후 수동으로 옵션을 설정할 수 있습니다.
  3. hieradata 형식으로 Puppet 변수의 코어 Heat 템플릿 컬렉션을 확인합니다. deployment/* 의 템플릿은 일반적으로 동일한 서비스의 Puppet 모듈에 해당합니다. 예를 들어 deployment/keystone/keystone-container-puppet.yaml 템플릿은 keystone 모듈에 hieradata를 제공합니다.

    • heat 템플릿에서 Puppet 변수에 hieradata를 설정하는 경우 템플릿에서 수정할 수 있는 director 기반 매개 변수도 공개해야 합니다.
    • heat 템플릿에서 Puppet 변수에 hieradata를 설정하지 않으면 구성 후크를 사용하여 환경 파일을 사용하여 hieradata를 전달합니다. hieradata 사용자 지정에 대한 자세한 내용은 4.5절. “Puppet: 역할에 대한 hieradata 사용자 정의” 을 참조하십시오.

절차

  1. OpenStack Identity(keystone)의 알림 형식을 변경하려면 워크플로우를 사용하고 다음 단계를 완료합니다.

    1. 구성할 OpenStack 매개 변수(notification_format)를 식별합니다.
    2. notification_format 설정을 위해 keystone Puppet 모듈을 검색합니다.

      $ grep notification_format /etc/puppet/modules/keystone/manifests/*

      이 경우 keystone 모듈은 keystone ::notification_format 변수를 사용하여 이 옵션을 관리합니다.

    3. 이 변수에 대해 keystone 서비스 템플릿을 검색합니다.

      $ grep "keystone::notification_format" /usr/share/openstack-tripleo-heat-templates/deployment/keystone/keystone-container-puppet.yaml

      출력에는 director에서 KeystoneNotificationFormat 매개변수를 사용하여 keystone::notification_format hieradata를 설정하는 것을 확인할 수 있습니다.

다음 표는 최종 매핑을 보여줍니다.

director 매개변수Puppet hieradataOpenStack Identity(keystone) 옵션

KeystoneNotificationFormat

keystone::notification_format

notification_format

오버클라우드 환경 파일에 KeystoneNotificationFormat 을 설정한 다음 오버클라우드 구성 중에 keystone.conf 파일에 notification_format 옵션을 설정합니다.

4장. 구성 후크

구성 후크를 사용하여 고유한 사용자 지정 구성 기능을 오버클라우드 배포 프로세스에 삽입합니다. 후크를 생성하여 기본 오버클라우드 서비스 구성 전후에 사용자 지정 구성을 삽입하고 수정 및 Puppet 기반 구성을 포함하여 후크를 삽입할 수 있습니다.

4.1. 첫 번째 부팅: 첫 번째 부팅 구성 사용자 정의

오버클라우드를 처음 생성한 후 director는 cloud-init 를 사용하여 모든 노드에서 구성을 수행합니다. NodeUserData 리소스 유형을 사용하여 cloud-init 를 호출할 수 있습니다.

OS::TripleO::NodeUserData
모든 노드에 적용할 cloud-init 구성입니다.
OS::TripleO::Controller::NodeUserData
컨트롤러 노드에 적용할 cloud-init 구성입니다.
OS::TripleO::Compute::NodeUserData
컴퓨팅 노드에 적용할 cloud-init 구성입니다.
OS::TripleO::CephStorage::NodeUserData
Ceph Storage 노드에 적용할 cloud-init 구성입니다.
OS::TripleO::ObjectStorage::NodeUserData
Object Storage 노드에 적용할 cloud-init 구성입니다.
OS::TripleO::BlockStorage::NodeUserData
블록 스토리지 노드에 적용할 cloud-init 구성입니다.
OS::TripleO::[ROLE]::NodeUserData
사용자 지정 노드에 적용할 cloud-init 구성입니다. [ROLE] 을 구성 가능 역할 이름으로 교체합니다.

이 예제에서는 모든 노드에서 사용자 지정 IP 주소로 이름 서버를 업데이트합니다.

절차

  1. 스크립트를 실행하여 각 노드에 resolv .conf 파일을 특정 이름 서버로 추가하는 기본 heat 템플릿 ~/templates/nameserver. yaml 을 생성합니다. OS::TripleO::MultipartMime 리소스 유형을 사용하여 구성 스크립트를 보낼 수 있습니다.

    heat_template_version: 2014-10-16
    
    description: >
      Extra hostname configuration
    
    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/resolv.conf
    
    outputs:
      OS::stack_id:
        value: {get_resource: userdata}
  2. heat 템플릿을 OS::TripleO::NodeUserData 리소스 유형으로 등록하는 환경 파일 ~/templates/firstboot.yaml 을 생성합니다.

    resource_registry:
      OS::TripleO::NodeUserData: /home/stack/templates/nameserver.yaml
  3. 첫 번째 부팅 구성을 오버클라우드에 추가하려면 다른 환경 파일과 함께 스택에 환경 파일을 추가합니다.

    $ openstack overcloud deploy --templates \
        ...
        -e /home/stack/templates/firstboot.yaml \
        ...

    그러면 처음 생성될 때 모든 노드에 구성이 추가되고 처음으로 부팅됩니다. 이후 오버클라우드 스택 업데이트와 같은 이러한 템플릿은 이러한 스크립트를 실행하지 않습니다.

중요

NodeUserData 리소스를 리소스당 하나의 heat 템플릿에만 등록할 수 있습니다. 후속 사용은 사용할 heat 템플릿을 재정의합니다.

4.2. 사전 구성: 특정 오버클라우드 역할 사용자 지정

오버클라우드는 OpenStack 구성 요소의 핵심 구성에 Puppet을 사용합니다. director는 첫 번째 부팅이 완료된 후 코어 구성이 시작되기 전에 특정 노드 역할에 대한 사용자 정의 구성을 수행하는 데 사용할 수 있는 후크 세트를 제공합니다. 이러한 후크에는 다음이 포함됩니다.

중요

이 문서의 이전 버전에서는 OS::TripleO::Tasks::*PreConfig 리소스를 사용하여 역할별로 사전 구성 후크를 제공했습니다. Heat 템플릿 컬렉션에는 이러한 후크를 전용으로 사용해야 하므로 사용자 지정 용도로 사용해서는 안 됩니다. 대신 여기에 설명된 OS::TripleO::*ExtraConfigPre 후크를 사용합니다.

OS::TripleO::ControllerExtraConfigPre
핵심 Puppet 구성 전에 컨트롤러 노드에 적용된 추가 구성입니다.
OS::TripleO::ComputeExtraConfigPre
핵심 Puppet 구성 전에 컴퓨팅 노드에 추가 구성이 적용됩니다.
OS::TripleO::CephStorageExtraConfigPre
핵심 Puppet 구성 전에 Ceph Storage 노드에 추가 구성이 적용됩니다.
OS::TripleO::ObjectStorageExtraConfigPre
코어 Puppet 구성 전에 Object Storage 노드에 적용된 추가 구성입니다.
OS::TripleO::BlockStorageExtraConfigPre
핵심 Puppet 구성 전에 블록 스토리지 노드에 추가 구성이 적용됩니다.
OS::TripleO::[ROLE]ExtraConfigPre
코어 Puppet 구성 전에 사용자 지정 노드에 추가 구성이 적용됩니다. [ROLE] 을 구성 가능 역할 이름으로 교체합니다.

이 예제에서는 특정 역할의 모든 노드에 변수 이름 서버를 추가합니다.

절차

  1. 스크립트를 실행하여 노드의 resolv .conf 파일에 변수 이름 서버를 작성하는 기본 heat 템플릿 ~/templates/nameserver. yaml 을 생성합니다.

    heat_template_version: 2014-10-16
    
    description: >
      Extra hostname configuration
    
    parameters:
      server:
        type: string
      nameserver_ip:
        type: string
      DeployIdentifier:
        type: string
    
    resources:
      CustomExtraConfigPre:
        type: OS::Heat::SoftwareConfig
        properties:
          group: script
          config:
            str_replace:
              template: |
                #!/bin/sh
                echo "nameserver _NAMESERVER_IP_" > /etc/resolv.conf
              params:
                _NAMESERVER_IP_: {get_param: nameserver_ip}
    
      CustomExtraDeploymentPre:
        type: OS::Heat::SoftwareDeployment
        properties:
          server: {get_param: server}
          config: {get_resource: CustomExtraConfigPre}
          actions: ['CREATE','UPDATE']
          input_values:
            deploy_identifier: {get_param: DeployIdentifier}
    
    outputs:
      deploy_stdout:
        description: Deployment reference, used to trigger pre-deploy on changes
        value: {get_attr: [CustomExtraDeploymentPre, deploy_stdout]}

    이 예제에서 resources 섹션에는 다음 매개변수가 포함되어 있습니다.

    CustomExtraConfigPre
    소프트웨어 구성을 정의합니다. 이 예제에서는 Bash 스크립트를 정의하고 heat는 _NAMESERVER_IP_nameserver_ip 매개 변수에 저장된 값으로 바꿉니다.
    CustomExtraDeploymentPre

    그러면 CustomExtraConfigPre 리소스의 소프트웨어 구성인 소프트웨어 구성이 실행됩니다. 다음을 확인합니다.

    • heat가 적용할 구성을 인식하도록 config 매개변수는 CustomExtraConfigPre 리소스를 참조합니다.
    • server 매개 변수는 Overcloud 노드 맵을 검색합니다. 이 매개 변수는 상위 템플릿에서 제공하며 이 후크의 템플릿에서 필요합니다.
    • actions 매개 변수는 구성을 적용할 시기를 정의합니다. 이 경우 오버클라우드가 생성될 때 구성을 적용해야 합니다. 가능한 작업에는 CREATE,UPDATE,DELETE,SUSPEND, RESUME 등이 있습니다.
    • input_values 에는 상위 템플릿에서 DeployIdentifier 를 저장하는 deploy_identifier 라는 매개 변수가 포함되어 있습니다. 이 매개 변수는 각 배포 업데이트의 리소스에 타임스탬프를 제공하여 후속 오버클라우드 업데이트에 리소스가 다시 적용되도록 합니다.
  2. heat 템플릿을 역할 기반 리소스 유형에 등록하는 환경 파일 ~/templates/pre_config.yaml 을 생성합니다. 예를 들어 컨트롤러 노드에만 구성을 적용하려면 ControllerExtraConfigPre 후크를 사용합니다.

    resource_registry:
      OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/nameserver.yaml
    
    parameter_defaults:
      nameserver_ip: 192.168.1.1
  3. 다른 환경 파일과 함께 스택에 환경 파일을 추가합니다.

    $ openstack overcloud deploy --templates \
        ...
        -e /home/stack/templates/pre_config.yaml \
        ...

    그러면 초기 오버클라우드 생성 또는 이후 업데이트에서 코어 구성이 시작되기 전에 모든 컨트롤러 노드에 구성이 적용됩니다.

중요

후크당 하나의 heat 템플릿에만 각 리소스를 등록할 수 있습니다. 후속 사용은 사용할 heat 템플릿을 재정의합니다.

4.3. 사전 구성: 모든 오버클라우드 역할 사용자 지정

오버클라우드는 OpenStack 구성 요소의 핵심 구성에 Puppet을 사용합니다. director는 첫 번째 부팅이 완료된 후 코어 구성이 시작되기 전에 모든 노드 유형을 설정하는 데 사용할 수 있는 후크를 제공합니다.

OS::TripleO::NodeExtraConfig
핵심 Puppet 구성 전에 모든 노드 역할에 적용되는 추가 구성입니다.

이 예제에서는 각 노드에 변수 이름 서버를 사용하여 resolv.conf 파일을 추가합니다.

절차

  1. 스크립트를 실행하여 각 노드의 resolv .conf 파일을 변수 이름 서버로 추가하는 기본 heat 템플릿 ~/templates/nameserver. yaml 을 생성합니다.

    heat_template_version: 2014-10-16
    
    description: >
      Extra hostname configuration
    
    parameters:
      server:
        type: string
      nameserver_ip:
        type: string
      DeployIdentifier:
        type: string
    
    resources:
      CustomExtraConfigPre:
        type: OS::Heat::SoftwareConfig
        properties:
          group: script
          config:
            str_replace:
              template: |
                #!/bin/sh
                echo "nameserver _NAMESERVER_IP_" >> /etc/resolv.conf
              params:
                _NAMESERVER_IP_: {get_param: nameserver_ip}
    
      CustomExtraDeploymentPre:
        type: OS::Heat::SoftwareDeployment
        properties:
          server: {get_param: server}
          config: {get_resource: CustomExtraConfigPre}
          actions: ['CREATE','UPDATE']
          input_values:
            deploy_identifier: {get_param: DeployIdentifier}
    
    outputs:
      deploy_stdout:
        description: Deployment reference, used to trigger pre-deploy on changes
        value: {get_attr: [CustomExtraDeploymentPre, deploy_stdout]}

    이 예제에서 resources 섹션에는 다음 매개변수가 포함되어 있습니다.

    CustomExtraConfigPre
    이 매개 변수는 소프트웨어 구성을 정의합니다. 이 예제에서는 Bash 스크립트를 정의하고 heat는 _NAMESERVER_IP_nameserver_ip 매개 변수에 저장된 값으로 바꿉니다.
    CustomExtraDeploymentPre

    이 매개 변수는 CustomExtraConfigPre 리소스의 소프트웨어 구성인 소프트웨어 구성을 실행합니다. 다음을 확인합니다.

    • heat가 적용할 구성을 인식하도록 config 매개변수는 CustomExtraConfigPre 리소스를 참조합니다.
    • server 매개 변수는 Overcloud 노드 맵을 검색합니다. 이 매개 변수는 상위 템플릿에서 제공하며 이 후크의 템플릿에서 필요합니다.
    • actions 매개 변수는 구성을 적용할 시기를 정의합니다. 이 경우 오버클라우드가 생성될 때만 구성을 적용합니다. 가능한 작업에는 CREATE,UPDATE,DELETE,SUSPEND, RESUME 등이 있습니다.
    • input_values 매개 변수에는 상위 템플릿에서 DeployIdentifier 를 저장하는 deploy_identifier 라는 하위 매개 변수가 포함되어 있습니다. 이 매개 변수는 각 배포 업데이트의 리소스에 타임스탬프를 제공하여 후속 오버클라우드 업데이트에 리소스가 다시 적용되도록 합니다.
  2. heat 템플릿을 OS::TripleO::NodeExtraConfig 리소스 유형으로 등록하는 환경 파일 ~/templates/pre_config.yaml 을 생성합니다.

    resource_registry:
      OS::TripleO::NodeExtraConfig: /home/stack/templates/nameserver.yaml
    
    parameter_defaults:
      nameserver_ip: 192.168.1.1
  3. 다른 환경 파일과 함께 스택에 환경 파일을 추가합니다.

    $ openstack overcloud deploy --templates \
        ...
        -e /home/stack/templates/pre_config.yaml \
        ...

    이렇게 하면 초기 오버클라우드 생성 또는 이후 업데이트에서 코어 구성이 시작되기 전에 모든 노드에 구성이 적용됩니다.

중요

OS::TripleO::NodeExtraConfig 를 하나의 heat 템플릿에만 등록할 수 있습니다. 후속 사용은 사용할 heat 템플릿을 재정의합니다.

4.4. 구성 후: 모든 오버클라우드 역할 사용자 지정

중요

이 문서의 이전 버전에서는 OS::TripleO::Tasks::*PostConfig 리소스를 사용하여 역할별로 사후 구성 후크를 제공했습니다. Heat 템플릿 컬렉션에는 이러한 후크를 전용으로 사용해야 하므로 사용자 지정 용도로 사용해서는 안 됩니다. 대신 여기에 설명된 OS::TripleO::NodeExtraConfigPost 후크를 사용합니다.

오버클라우드 생성을 완료했지만 초기 생성 또는 오버클라우드의 후속 업데이트 시 모든 역할에 구성을 추가하려는 경우 발생할 수 있습니다. 이 경우 다음 구성 후 후크를 사용합니다.

OS::TripleO::NodeExtraConfigPost
핵심 Puppet 구성 후 모든 노드 역할에 적용되는 추가 구성입니다.

이 예제에서는 각 노드에 변수 이름 서버를 사용하여 resolv.conf 파일을 추가합니다.

절차

  1. 스크립트를 실행하여 각 노드의 resolv .conf 파일을 변수 이름 서버로 추가하는 기본 heat 템플릿 ~/templates/nameserver. yaml 을 생성합니다.

    heat_template_version: 2014-10-16
    
    description: >
      Extra hostname configuration
    
    parameters:
      servers:
        type: json
      nameserver_ip:
        type: string
      DeployIdentifier:
        type: string
      EndpointMap:
        default: {}
        type: json
    
    resources:
      CustomExtraConfig:
        type: OS::Heat::SoftwareConfig
        properties:
          group: script
          config:
            str_replace:
              template: |
                #!/bin/sh
                echo "nameserver _NAMESERVER_IP_" >> /etc/resolv.conf
              params:
                _NAMESERVER_IP_: {get_param: nameserver_ip}
    
      CustomExtraDeployments:
        type: OS::Heat::SoftwareDeploymentGroup
        properties:
          servers:  {get_param: servers}
          config: {get_resource: CustomExtraConfig}
          actions: ['CREATE','UPDATE']
          input_values:
            deploy_identifier: {get_param: DeployIdentifier}

    이 예제에서 resources 섹션에는 다음 매개변수가 포함되어 있습니다.

    CustomExtraConfig
    소프트웨어 구성을 정의합니다. 이 예제에서는 Bash 스크립트를 정의하고 heat는 _NAMESERVER_IP_nameserver_ip 매개 변수에 저장된 값으로 바꿉니다.
    CustomExtraDeployments

    그러면 CustomExtraConfig 리소스의 소프트웨어 구성인 소프트웨어 구성이 실행됩니다. 다음을 확인합니다.

    • heat가 적용할 구성을 인식하도록 config 매개변수는 CustomExtraConfig 리소스를 참조합니다.
    • servers 매개 변수는 Overcloud 노드 맵을 검색합니다. 이 매개 변수는 상위 템플릿에서 제공하며 이 후크의 템플릿에서 필요합니다.
    • actions 매개 변수는 구성을 적용할 시기를 정의합니다. 이 경우 오버클라우드가 생성될 때 구성을 적용해야 합니다. 가능한 작업에는 CREATE,UPDATE,DELETE,SUSPEND, RESUME 등이 있습니다.
    • input_values 에는 상위 템플릿에서 DeployIdentifier 를 저장하는 deploy_identifier 라는 매개 변수가 포함되어 있습니다. 이 매개 변수는 각 배포 업데이트의 리소스에 타임스탬프를 제공하여 후속 오버클라우드 업데이트에 리소스가 다시 적용되도록 합니다.
  2. heat 템플릿을 OS::TripleO::NodeExtraConfigPost: 리소스 유형으로 등록하는 환경 파일 ~/templates/post_config.yaml 을 생성합니다.

    resource_registry:
      OS::TripleO::NodeExtraConfigPost: /home/stack/templates/nameserver.yaml
    
    parameter_defaults:
      nameserver_ip: 192.168.1.1
  3. 다른 환경 파일과 함께 스택에 환경 파일을 추가합니다.

    $ openstack overcloud deploy --templates \
        ...
        -e /home/stack/templates/post_config.yaml \
        ...

    이렇게 하면 초기 오버클라우드 생성 또는 이후 업데이트 시 코어 구성이 완료된 후 모든 노드에 구성이 적용됩니다.

중요

OS::TripleO::NodeExtraConfigPost 를 하나의 heat 템플릿에만 등록할 수 있습니다. 후속 사용은 사용할 heat 템플릿을 재정의합니다.

4.5. Puppet: 역할에 대한 hieradata 사용자 정의

heat 템플릿 컬렉션에는 특정 노드 유형에 추가 구성을 전달하는 데 사용할 수 있는 매개변수 세트가 포함되어 있습니다. 이러한 매개변수는 노드에서 Puppet 구성에 대한 hieradata로 구성을 저장합니다.

ControllerExtraConfig
모든 컨트롤러 노드에 추가할 구성입니다.
ComputeExtraConfig
모든 컴퓨팅 노드에 추가할 구성입니다.
BlockStorageExtraConfig
모든 블록 스토리지 노드에 추가할 구성입니다.
ObjectStorageExtraConfig
모든 Object Storage 노드에 추가할 구성입니다.
CephStorageExtraConfig
모든 Ceph Storage 노드에 추가할 구성입니다.
[ROLE]ExtraConfig
구성 가능 역할에 추가할 구성입니다. [ROLE] 을 구성 가능 역할 이름으로 교체합니다.
ExtraConfig
모든 노드에 추가할 구성입니다.

절차

  1. 배포 후 구성 프로세스에 구성을 추가하려면 parameter_defaults 섹션에 이러한 매개 변수를 포함하는 환경 파일을 생성합니다. 예를 들어 Compute 호스트의 예약된 메모리를 1024MB로 늘리고 VNC 키맵을 일본어로 설정하려면 ComputeExtraConfig 매개변수에서 다음 항목을 사용합니다.

    parameter_defaults:
      ComputeExtraConfig:
        nova::compute::reserved_host_memory: 1024
        nova::compute::vnc_keymap: ja
  2. 배포와 관련된 기타 환경 파일과 함께 openstack overcloud deploy 명령에 이 환경 파일을 포함합니다.
중요

각 매개 변수를 한 번만 정의할 수 있습니다. 후속 사용은 이전 값을 재정의합니다.

4.6. Puppet: 개별 노드에 대한 hieradata 사용자 정의

heat 템플릿 컬렉션을 사용하여 개별 노드에 Puppet hieradata를 설정할 수 있습니다.

절차

  1. 노드의 인트로스펙션 데이터에서 시스템 UUID를 식별합니다.

    $ openstack baremetal introspection data save 9dcc87ae-4c6d-4ede-81a5-9b20d7dc4a14 | jq .extra.system.product.uuid

    이 명령은 시스템 UUID를 반환합니다. 예를 들면 다음과 같습니다.

    "f5055c6c-477f-47fb-afe5-95c6928c407f"
  2. 환경 파일을 생성하여 노드별 hieradata를 정의하고 per_node.yaml 템플릿을 사전 구성 후크에 등록합니다. NodeDataLookup 매개변수에 구성하려는 노드의 시스템 UUID를 포함합니다.

    resource_registry:
      OS::TripleO::ComputeExtraConfigPre: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/per_node.yaml
    parameter_defaults:
      NodeDataLookup: '{"f5055c6c-477f-47fb-afe5-95c6928c407f": {"nova::compute::vcpu_pin_set": [ "2", "3" ]}}'
  3. 배포와 관련된 기타 환경 파일과 함께 openstack overcloud deploy 명령에 이 환경 파일을 포함합니다.

per_node.yaml 템플릿은 각 시스템 UUID에 해당하는 노드에 hieradata 파일 세트를 생성하고 사용자가 정의한 hieradata를 포함합니다. UUID가 정의되지 않은 경우 결과 hieradata 파일이 비어 있습니다. 이 예에서 per_node.yaml 템플릿은 OS::TripleO::ComputeExtraConfigPre 후크에서 정의한 모든 컴퓨팅 노드에서 실행되지만 시스템 UUID가 f5055c6c-477f-47fb-afe5-95c6928c407f 인 컴퓨팅 노드만 hieradata를 수신합니다.

이 메커니즘을 사용하여 특정 요구 사항에 따라 각 노드를 조정할 수 있습니다.

NodeDataLookup 에 대한 자세한 내용은 컨테이너화된 Red Hat Ceph 가이드를 사용하여 오버클라우드 배포에서 Ceph Storage 노드에서 디스크 레이아웃 변경을 참조하십시오.

4.7. Puppet: 사용자 정의 매니페스트 적용

특정 상황에서는 오버클라우드 노드에 일부 추가 구성 요소를 설치하고 구성할 수 있습니다. 기본 구성이 완료된 후 노드에 적용되는 사용자 정의 Puppet 매니페스트를 사용하여 이 작업을 수행할 수 있습니다. 기본 예에서는 각 노드에 motd 를 설치할 수 있습니다.

절차

  1. Puppet 구성을 시작하는 heat 템플릿 ~/templates/custom_puppet_config.yaml 을 생성합니다.

    heat_template_version: 2014-10-16
    
    description: >
      Run Puppet extra configuration to set new MOTD
    
    parameters:
      servers:
        type: json
      DeployIdentifier:
        type: string
      EndpointMap:
        default: {}
        type: json
    
    resources:
      ExtraPuppetConfig:
        type: OS::Heat::SoftwareConfig
        properties:
          config: {get_file: motd.pp}
          group: puppet
          options:
            enable_hiera: True
            enable_facter: False
    
      ExtraPuppetDeployments:
        type: OS::Heat::SoftwareDeploymentGroup
        properties:
          config: {get_resource: ExtraPuppetConfig}
          servers: {get_param: servers}

    이 예제에는 템플릿에 /home/stack/templates/motd.pp 이 포함되어 있으며 구성을 위해 노드에 전달합니다. motd.pp 파일에는 motd를 설치하고 구성하는 데 필요한 Puppet 클래스가 포함되어 있습니다 .

  2. heat 템플릿을 OS::TripleO::NodeExtraConfigPost: 리소스 유형으로 등록하는 환경 파일 ~templates/puppet_post_config.yaml 을 생성합니다.

    resource_registry:
      OS::TripleO::NodeExtraConfigPost: /home/stack/templates/custom_puppet_config.yaml
  3. 배포와 관련된 기타 환경 파일과 함께 openstack overcloud deploy 명령에 이 환경 파일을 포함합니다.

    $ openstack overcloud deploy --templates \
        ...
        -e /home/stack/templates/puppet_post_config.yaml \
        ...

    그러면 motd.pp 의 구성이 오버클라우드의 모든 노드에 적용됩니다.

5장. Ansible 기반 오버클라우드 등록

director는 Ansible 기반 방법을 사용하여 오버클라우드 노드를 Red Hat Customer Portal 또는 Red Hat Satellite Server에 등록합니다.

이전 Red Hat OpenStack Platform 버전에서 rhel-registration 방법을 사용한 경우 이를 비활성화하고 Ansible 기반 방법으로 전환해야 합니다. 자세한 내용은 5.6절. “rhsm 구성 가능 서비스로 전환”5.7절. “rhel-registration to rhsm mappings”을 참조하십시오.

director 기반 등록 방법 외에도 배포 후 수동으로 등록할 수도 있습니다. 자세한 내용은 참조하십시오. 5.9절. “Ansible 기반 등록 수동 실행”

5.1. RHSM(Red Hat Subscription Manager) 구성 가능 서비스

rhsm 구성 가능 서비스를 사용하여 Ansible을 통해 오버클라우드 노드를 등록할 수 있습니다. 기본 roles_data 파일의 각 역할에는 기본적으로 비활성화된 OS::TripleO::Services::Rhsm 리소스가 포함되어 있습니다. 서비스를 활성화하려면 리소스를 rhsm 구성 가능 서비스 파일에 등록합니다.

resource_registry:
  OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml

The rhsm 구성 가능 서비스는 RhsmVars 매개변수를 사용할 수 있으며, 등록과 관련된 여러 하위 매개변수를 정의하는 데 사용할 수 있습니다.

parameter_defaults:
  RhsmVars:
    rhsm_repos:
      - rhel-8-for-x86_64-baseos-eus-rpms
      - rhel-8-for-x86_64-appstream-eus-rpms
      - rhel-8-for-x86_64-highavailability-eus-rpms
      …​
    rhsm_username: "myusername"
    rhsm_password: "p@55w0rd!"
    rhsm_org_id: "1234567"
    rhsm_release: 8.2

역할별 매개변수(예: ControllerParameter s)와 함께 RhsmVar s 매개변수를 사용하여 다른 노드 유형에 특정 리포지토리를 활성화할 때 유연성을 제공할 수도 있습니다.

5.2. RhsmVars 하위 매개변수

구성 가능 서비스를 구성할 때 다음 하위 매개 변수를 RhsmVars 매개변수 일부로 사용합니다. 사용 가능한 Ansible 매개변수에 대한 자세한 내용은 역할 설명서 를 참조하십시오.

rhsm설명

rhsm_method

등록 방법을 선택합니다. portal,satellite 또는 disable 중 하나입니다.

rhsm_org_id

등록에 사용하려는 조직입니다. 이 ID를 찾으려면 언더클라우드 노드에서 sudo subscription-manager orgs 를 실행합니다. 프롬프트에 Red Hat 자격 증명을 입력하고 결과로 생성된 Key (키) 값을 사용합니다. 조직 ID에 대한 자세한 내용은 Red Hat Subscription Management Organization ID 이해를 참조하십시오.

rhsm_pool_ids

사용하려는 서브스크립션 풀 ID입니다. 서브스크립션을 자동 첨부하지 않으려면 이 매개변수를 사용합니다. 이 ID를 찾으려면 언더클라우드 노드에서 sudo subscription-manager list --available --all --matches="* Red Hat OpenStack*" 을 실행하고 결과 풀 ID 값을 사용합니다.

rhsm_activation_key

등록에 사용할 활성화 키입니다.

rhsm_autosubscribe

이 매개변수를 사용하여 호환 가능한 서브스크립션을 이 시스템에 자동으로 첨부합니다. 이 기능을 활성화하려면 값을 true 로 설정합니다.

rhsm_baseurl

콘텐츠를 가져오는 기본 URL입니다. 기본 URL은 Red Hat Content Delivery Network입니다. Satellite 서버를 사용하는 경우 이 값을 Satellite 서버 콘텐츠 리포지토리의 기본 URL로 변경합니다.

rhsm_server_hostname

등록을 위한 서브스크립션 관리 서비스의 호스트 이름입니다. 기본값은 Red Hat 서브스크립션 관리 호스트 이름입니다. Satellite 서버를 사용하는 경우 이 값을 Satellite 서버 호스트 이름으로 변경합니다.

rhsm_repos

활성화하려는 리포지토리 목록입니다.

rhsm_username

등록할 사용자 이름입니다. 가능한 경우 등록에 활성화 키를 사용합니다.

rhsm_password

등록할 암호입니다. 가능한 경우 등록에 활성화 키를 사용합니다.

rhsm_release

리포지토리 고정을 위한 Red Hat Enterprise Linux 릴리스. 이는 Red Hat OpenStack Platform의 8.2로 설정됩니다.

rhsm_rhsm_proxy_hostname

HTTP 프록시의 호스트 이름입니다. 예: proxy.example.com

rhsm_rhsm_proxy_port

HTTP 프록시 통신용 포트입니다. 예를 들면 다음과 같습니다. 8080.

rhsm_rhsm_proxy_user

HTTP 프록시에 액세스할 사용자 이름입니다.

rhsm_rhsm_proxy_password

HTTP 프록시에 액세스할 암호입니다.

중요

rhsm_ method가 portal 로 설정된 경우에만 use rhsm_activation_key 및rhsm_ repos 를 함께 사용할 수 있습니다. If rhsm_methodsatellite 로 설정되면 either rhsm_activation_key or rhsm_ repos 만 사용할 수 있습니다.

5.3. rhsm 구성 가능 서비스를 사용하여 오버클라우드 등록

rhsm 구성 가능 서비스를 활성화하고 구성하는 환경 파일을 생성합니다. director는 이 환경 파일을 사용하여 노드를 등록하고 서브스크립션합니다.

절차

  1. templates/rhsm.yml 이라는 환경 파일을 만들어 구성을 저장합니다.
  2. 환경 파일에 구성을 포함합니다. 예를 들면 다음과 같습니다.

    resource_registry:
      OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
    parameter_defaults:
      RhsmVars:
        rhsm_repos:
          - rhel-8-for-x86_64-baseos-eus-rpms
          - rhel-8-for-x86_64-appstream-eus-rpms
          - rhel-8-for-x86_64-highavailability-eus-rpms
          …​
        rhsm_username: "myusername"
        rhsm_password: "p@55w0rd!"
        rhsm_org_id: "1234567"
        rhsm_pool_ids: "1a85f9223e3d5e43013e3d6e8ff506fd"
        rhsm_method: "portal"
        rhsm_release: 8.2
    • resource_registry 섹션은 각 역할에서 사용할 수 있는 OS::TripleO::Services::Rhsm 리소스와 rhsm 구성 가능 서비스를 연결합니다.
    • RhsmVars 변수는 Red Hat 등록을 구성하기 위해 매개 변수를 Ansible에 전달합니다.
  3. 환경 파일을 저장합니다.

5.4. 다른 역할에 rhsm 구성 가능 서비스 적용

역할별로 the rhsm 구성 가능 서비스를 적용할 수 있습니다. 예를 들어 컨트롤러 노드, 컴퓨팅 노드 및 Ceph Storage 노드에 다양한 구성 세트를 적용할 수 있습니다.

절차

  1. templates/rhsm.yml 이라는 환경 파일을 만들어 구성을 저장합니다.
  2. 환경 파일에 구성을 포함합니다. 예를 들면 다음과 같습니다.

    resource_registry:
      OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
    parameter_defaults:
      ControllerParameters:
        RhsmVars:
          rhsm_repos:
            - rhel-8-for-x86_64-baseos-eus-rpms
            - rhel-8-for-x86_64-appstream-eus-rpms
            - rhel-8-for-x86_64-highavailability-eus-rpms
            - ansible-2.9-for-rhel-8-x86_64-rpms
            - advanced-virt-for-rhel-8-x86_64-rpms
            - openstack-16.1-for-rhel-8-x86_64-rpms
            - fast-datapath-for-rhel-8-x86_64-rpms
          rhsm_username: "myusername"
          rhsm_password: "p@55w0rd!"
          rhsm_org_id: "1234567"
          rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5"
          rhsm_method: "portal"
          rhsm_release: 8.2
      ComputeParameters:
        RhsmVars:
          rhsm_repos:
            - rhel-8-for-x86_64-baseos-eus-rpms
            - rhel-8-for-x86_64-appstream-eus-rpms
            - rhel-8-for-x86_64-highavailability-eus-rpms
            - ansible-2.9-for-rhel-8-x86_64-rpms
            - advanced-virt-for-rhel-8-x86_64-rpms
            - openstack-16.1-for-rhel-8-x86_64-rpms
            - fast-datapath-for-rhel-8-x86_64-rpms
          rhsm_username: "myusername"
          rhsm_password: "p@55w0rd!"
          rhsm_org_id: "1234567"
          rhsm_pool_ids: "55d251f1490556f3e75aa37e89e10ce5"
          rhsm_method: "portal"
          rhsm_release: 8.2
      CephStorageParameters:
        RhsmVars:
          rhsm_repos:
            - rhel-8-for-x86_64-baseos-rpms
            - rhel-8-for-x86_64-appstream-rpms
            - rhel-8-for-x86_64-highavailability-rpms
            - ansible-2.9-for-rhel-8-x86_64-rpms
            - openstack-16.1-deployment-tools-for-rhel-8-x86_64-rpms
          rhsm_username: "myusername"
          rhsm_password: "p@55w0rd!"
          rhsm_org_id: "1234567"
          rhsm_pool_ids: "68790a7aa2dc9dc50a9bc39fabc55e0d"
          rhsm_method: "portal"
          rhsm_release: 8.2

    resource_registry 는 각 역할에서 사용할 수 있는 OS::TripleO::Services::Rhsm 리소스와 rhsm 구성 가능 서비스를 연결합니다.

    ControllerParameters,ComputeParametersCephStorageParameters 매개 변수는 각각 별도의 RhsmVars 매개변수를 사용하여 서브스크립션 세부 정보를 해당 역할에 전달합니다.

    참고

    CephStorageParameter s 매개변수 내에서 RhsmVar s 매개변수를 설정하여 Red Hat Ceph Storage 서브스크립션 및 Ceph Storage 관련 리포지토리를 사용합니다. rhsm_repos 매개변수에 컨트롤러 및 컴퓨팅 노드에 필요한 EUS(Extended Update Support) 리포지토리 대신 표준 Red Hat Enterprise Linux 리포지토리가 포함되어 있는지 확인합니다.

  3. 환경 파일을 저장합니다.

5.5. 오버클라우드를 Red Hat Satellite Server에 등록

Red Hat 고객 포털 대신 Red Hat Satellite에 노드를 등록하도록 rhsm 구성 가능 서비스를 활성화하고 구성하는 환경 파일을 생성합니다.

절차

  1. templates/rhsm.yml 이라는 환경 파일을 만들어 구성을 저장합니다.
  2. 환경 파일에 구성을 포함합니다. 예를 들면 다음과 같습니다.

    resource_registry:
      OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml
    parameter_defaults:
      RhsmVars:
        rhsm_activation_key: "myactivationkey"
        rhsm_method: "satellite"
        rhsm_org_id: "ACME"
        rhsm_server_hostname: "satellite.example.com"
        rhsm_baseurl: "https://satellite.example.com/pulp/repos"
        rhsm_release: 8.2

    resource_registry 는 각 역할에서 사용할 수 있는 OS::TripleO::Services::Rhsm 리소스와 rhsm 구성 가능 서비스를 연결합니다.

    RhsmVars 변수는 Red Hat 등록을 구성하기 위해 매개 변수를 Ansible에 전달합니다.

  3. 환경 파일을 저장합니다.

5.6. rhsm 구성 가능 서비스로 전환

이전 rhel-registration 메서드는 Overcloud 등록을 처리하는 bash 스크립트를 실행합니다. 이 메서드의 스크립트 및 환경 파일은 /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration/ 의 코어 heat 템플릿 컬렉션에 있습니다.

rhel-registration 방법에서 구성 가능 서비스로 전환하려면 다음 단계를 완료합니다.

절차

  1. rhel-registration 환경 파일을 향후 배포 작업에서 제외합니다. 대부분의 경우 다음 파일을 제외합니다.

    • rhel-registration/environment-rhel-registration.yaml
    • rhel-registration/rhel-registration-resource-registry.yaml
  2. 사용자 지정 roles_data 파일을 사용하는 경우 roles_data 파일의 각 역할에 OS::TripleO::Services::Rhsm 구성 가능 서비스가 포함되어 있는지 확인합니다. 예를 들면 다음과 같습니다.

    - name: Controller
      description: |
        Controller role that has all the controller services loaded and handles
        Database, Messaging and Network functions.
      CountDefault: 1
      ...
      ServicesDefault:
        ...
        - OS::TripleO::Services::Rhsm
        ...
  3. 향후 배포 작업에 환경 파일 for rhsm composable 서비스 매개변수를 추가합니다.

이 메서드는 rhel-registration 매개변수를 rhsm 서비스 매개변수로 교체하고 서비스를 활성화하는 heat 리소스를 변경합니다.

resource_registry:
  OS::TripleO::NodeExtraConfig: rhel-registration.yaml

다음으로 변경합니다.

resource_registry:
  OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml

배포를 통해 /usr/share/openstack-tripleo-heat-templates/environments/rhsm.yaml 환경 파일을 배포하여 서비스를 활성화할 수도 있습니다.

5.7. rhel-registration to rhsm mappings

rhel-registration 방법에서 the rhsm 메서드로 세부 정보를 전환하는 데 도움이 되도록 다음 표를 사용하여 매개변수와 값을 매핑합니다.

rhel-registrationrhsm / RhsmVars

rhel_reg_method

rhsm_method

rhel_reg_org

rhsm_org_id

rhel_reg_pool_id

rhsm_pool_ids

rhel_reg_activation_key

rhsm_activation_key

rhel_reg_auto_attach

rhsm_autosubscribe

rhel_reg_sat_url

rhsm_satellite_url

rhel_reg_repos

rhsm_repos

rhel_reg_user

rhsm_username

rhel_reg_password

rhsm_password

rhel_reg_release

rhsm_release

rhel_reg_http_proxy_host

rhsm_rhsm_proxy_hostname

rhel_reg_http_proxy_port

rhsm_rhsm_proxy_port

rhel_reg_http_proxy_username

rhsm_rhsm_proxy_user

rhel_reg_http_proxy_password

rhsm_rhsm_proxy_password

5.8. rhsm 구성 가능 서비스를 사용하여 오버클라우드 배포

Ansible에서 오버클라우드 노드의 등록 프로세스를 제어하도록 the rhsm 구성 가능 서비스를 사용하여 오버클라우드를 배포합니다.

절차

  1. openstack overcloud deploy 명령을 사용하여 rhsm.yml 환경 파일을 포함합니다.

    openstack overcloud deploy \
        <other cli args> \
        -e ~/templates/rhsm.yaml

    이렇게 하면 오버클라우드의 Ansible 구성 및 Ansible 기반 등록이 활성화됩니다.

  2. Overcloud 배포가 완료될 때까지 기다립니다.
  3. 오버클라우드 노드에서 서브스크립션 세부 정보를 확인합니다. 예를 들어 컨트롤러 노드에 로그인하고 다음 명령을 실행합니다.

    $ sudo subscription-manager status
    $ sudo subscription-manager list --consumed

5.9. Ansible 기반 등록 수동 실행

director 노드에 동적 인벤토리 스크립트를 사용하여 배포된 오버클라우드에 Ansible 기반 수동 등록을 수행할 수 있습니다. 이 스크립트를 사용하여 노드 역할을 호스트 그룹으로 정의한 다음 ansible-playbook 을 사용하여 플레이북을 실행합니다. 다음 예제 플레이북을 사용하여 컨트롤러 노드를 수동으로 등록합니다.

절차

  1. redhat_subscription 모듈을 사용하여 노드를 등록하는 플레이북을 생성합니다. 예를 들어 다음 플레이북은 컨트롤러 노드에 적용됩니다.

    ---
    - name: Register Controller nodes
      hosts: Controller
      become: yes
      vars:
        repos:
          - rhel-8-for-x86_64-baseos-eus-rpms
          - rhel-8-for-x86_64-appstream-eus-rpms
          - rhel-8-for-x86_64-highavailability-eus-rpms
          - ansible-2.9-for-rhel-8-x86_64-rpms
          - openstack-beta-for-rhel-8-x86_64-rpms
          - fast-datapath-for-rhel-8-x86_64-rpms
      tasks:
        - name: Register system
          redhat_subscription:
            username: myusername
            password: p@55w0rd!
            org_id: 1234567
            release: 8.2
            pool_ids: 1a85f9223e3d5e43013e3d6e8ff506fd
        - name: Disable all repos
          command: "subscription-manager repos --disable *"
        - name: Enable Controller node repos
          command: "subscription-manager repos --enable {{ item }}"
          with_items: "{{ repos }}"
    • 이 플레이에는 세 가지 작업이 포함됩니다.

      • 노드를 등록합니다.
      • 자동 활성화 리포지토리를 비활성화합니다.
      • 컨트롤러 노드와 관련된 리포지토리만 활성화합니다. 리포지토리는 repos 변수를 사용하여 나열됩니다.
  2. 오버클라우드를 배포한 후 Ansible이 오버클라우드에 대해 플레이북(ansible-osp-registration.yml)을 실행하도록 다음 명령을 실행할 수 있습니다.

    $ ansible-playbook -i /usr/bin/tripleo-ansible-inventory ansible-osp-registration.yml

    이 명령은 다음 작업을 수행합니다.

    • 동적 인벤토리 스크립트를 실행하여 호스트 및 해당 그룹 목록을 가져옵니다.
    • 플레이북의 hosts 매개 변수에 정의된 그룹의 노드에 플레이북 작업을 적용합니다. 이 경우 Controller 그룹입니다.

6장. 구성 가능 서비스 및 사용자 지정 역할

Overcloud는 일반적으로 컨트롤러 노드, 컴퓨팅 노드 및 다양한 스토리지 노드 유형과 같은 사전 정의된 역할의 노드로 구성됩니다. 이러한 각 기본 역할에는 director 노드의 코어 heat 템플릿 컬렉션에 정의된 일련의 서비스가 포함되어 있습니다. 그러나 특정 서비스 세트가 포함된 사용자 지정 역할을 생성할 수도 있습니다.

이 유연성을 사용하여 다양한 역할에 대해 다양한 서비스 조합을 생성할 수 있습니다. 이 장에서는 사용자 지정 역할, 구성 가능 서비스 및 이를 사용하는 방법에 대해 살펴봅니다.

6.1. 지원되는 역할 아키텍처

사용자 지정 역할 및 구성 가능한 서비스를 사용하는 경우 다음 아키텍처를 사용할 수 있습니다.

기본 아키텍처
기본 roles_data 파일을 사용합니다. 모든 컨트롤러 서비스는 하나의 컨트롤러 역할 내에 포함됩니다.
지원되는 독립 실행형 역할
/usr/share/openstack-tripleo-heat-templates/roles 에서 사전 정의된 파일을 사용하여 사용자 지정 roles_data 파일'을 생성합니다. 자세한 내용은 6.4절. “지원되는 사용자 정의 역할”의 내용을 참조하십시오.
사용자 정의 구성 가능 서비스
고유한 역할을 생성하고 이를 사용하여 사용자 지정 roles_data 파일을 생성합니다. 제한된 수의 구성 가능 서비스 조합만 테스트 및 검증되었으며 Red Hat은 모든 구성 가능한 서비스 조합을 지원할 수 없습니다.

6.2. roles_data 파일 검사

roles_data 파일에는 director가 노드에 배포하는 YAML 형식의 역할 목록이 포함되어 있습니다. 각 역할에는 역할을 구성하는 모든 서비스에 대한 정의가 포함되어 있습니다. 다음 예제 스니펫을 사용하여 roles_data 구문을 파악합니다.

- name: Controller
  description: |
    Controller role that has all the controller services loaded and handles
    Database, Messaging and Network functions.
  ServicesDefault:
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephClient
    ...
- name: Compute
  description: |
    Basic Compute Node role
  ServicesDefault:
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephClient
    ...

코어 heat 템플릿 컬렉션에는 /usr/share/openstack-tripleo-heat-templates/roles_data.yaml에 있는 기본 roles_data 파일이 포함되어 있습니다. 기본 파일에는 다음 역할 유형의 정의가 포함되어 있습니다.

  • 컨트롤러
  • Compute
  • BlockStorage
  • ObjectStorage
  • CephStorage.

openstack overcloud deploy 명령에는 배포 중에 기본 roles_data.yaml 파일이 포함되어 있습니다. 그러나 -r 인수를 사용하여 이 파일을 사용자 지정 roles_data 파일로 덮어쓸 수 있습니다.

$ openstack overcloud deploy --templates -r ~/templates/roles_data-custom.yaml

6.3. roles_data 파일 생성

수동으로 사용자 지정 roles_data 파일을 생성할 수 있지만 개별 역할 템플릿을 사용하여 파일을 자동으로 생성할 수도 있습니다. director는 역할 템플릿을 관리하고 사용자 지정 roles_data 파일을 자동으로 생성하는 여러 명령을 제공합니다.

절차

  1. 기본 역할 템플릿을 나열합니다.

    $ openstack overcloud roles list
    BlockStorage
    CephStorage
    Compute
    ComputeHCI
    ComputeOvsDpdk
    Controller
    ...
  2. openstack overcloud roles show 명령을 사용하여 YAML 형식으로 역할 정의를 확인합니다.

    $ openstack overcloud roles show Compute
  3. 사용자 지정 roles_data 파일을 생성합니다. openstack overcloud roles generate 명령을 사용하여 사전 정의된 여러 역할을 하나의 파일에 결합합니다. 예를 들어 다음 명령을 실행하여 Controller,ComputeNetworker 역할이 포함된 roles_data.yaml 파일을 생성합니다.

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

    출력 파일에서 이름을 정의하는 데 -o 옵션을 사용합니다.

    이 명령은 사용자 지정 roles_data 파일을 생성합니다. 그러나 이전 예제에서는 모두 동일한 네트워킹 에이전트를 포함하는 ControllerNetworker 역할을 사용합니다. 즉, 네트워킹 서비스는 컨트롤러 역할에서 Networker 역할로 확장되고, 오버클라우드에서 컨트롤러 노드와 네트워크 노드 간에 네트워킹 서비스의 부하를 분산합니다.

    Networker 역할을 독립 실행형으로 만들려면 고유한 사용자 지정 컨트롤러 역할과 필요한 다른 역할을 만들 수 있습니다. 이를 통해 고유한 사용자 지정 역할에서 roles_data 파일을 생성할 수 있습니다.

  4. 코어 heat 템플릿 컬렉션의 디렉터리를 stack 사용자의 홈 디렉터리에 복사합니다.

    $ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
  5. 이 디렉터리에서 사용자 지정 역할 파일을 추가하거나 수정합니다. 역할 하위 명령과 함께 --roles-path 옵션을 사용하여 이 디렉터리를 사용자 지정 역할의 소스로 사용합니다.

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

    이 명령은 ~/ roles 디렉터리의 개별 역할에서 하나의 my_roles _data.yaml 파일을 생성합니다.

참고

기본 역할 컬렉션에는 ControllerOpenStack 역할도 포함되어 있으며, 이 역할은 Networker,MessagingDatabase 역할에 대한 서비스가 포함되지 않습니다. 독립 실행형 Networker,MessagingDatabase 역할과 함께 ControllerOpenStack 을 사용할 수 있습니다.

6.4. 지원되는 사용자 정의 역할

다음 표에는 사용 가능한 사용자 지정 역할에 대한 정보가 나와 있습니다. /usr/share/openstack-tripleo-heat-templates/roles 디렉터리에서 사용자 지정 역할 템플릿을 찾을 수 있습니다.

Role설명파일

BlockStorage

OpenStack Block Storage(cinder) 노드.

BlockStorage.yaml

CephAll

전체 독립 실행형 Ceph Storage 노드. OSD, MON, Object Gateway(RGW), Object Operations(MDS), Manager(MGR) 및 RBD Mirroring이 포함됩니다.

CephAll.yaml

CephFile

독립 실행형 스케일 아웃 Ceph Storage 파일 역할. OSD 및 MDS(Object Operations) 포함.

CephFile.yaml

CephObject

독립형 스케일 아웃 Ceph Storage 오브젝트 역할. OSD 및 개체 게이트웨이(RGW)를 포함합니다.

CephObject.yaml

CephStorage

Ceph Storage OSD 노드 역할.

CephStorage.yaml

ComputeAlt

대체 컴퓨팅 노드 역할.

ComputeAlt.yaml

ComputeDVR

DVR이 활성화된 컴퓨팅 노드 역할.

ComputeDVR.yaml

ComputeHCI

하이퍼컨버지드 인프라를 사용하는 계산 노드. 계산 및 Ceph OSD 서비스가 포함되어 있습니다.

ComputeHCI.yaml

ComputeInstanceHA

Compute Instance HA 노드 역할. environment /compute-instanceha.yaml 환경 파일과 함께 를 사용합니다.

ComputeInstanceHA.yaml

ComputeLiquidio

Caviumio Smart NIC가 있는 계산 노드.

ComputeLiquidio.yaml

ComputeOvsDpdkRT

Compute OVS DPDK RealTime 역할.

ComputeOvsDpdkRT.yaml

ComputeOvsDpdk

컴퓨팅 OVS DPDK 역할.

ComputeOvsDpdk.yaml

ComputePPC64LE

ppc64le 서버의 컴퓨팅 역할.

ComputePPC64LE.yaml

ComputeRealTime

실시간 동작을 위해 최적화된 컴퓨팅 역할. 이 역할을 사용하는 경우 overcloud-realtime-compute 이미지를 사용할 수 있어야 하며 역할별 매개 변수 IsolCpusList,NovaComputeCpuDedicatedSetNovaComputeCpuSharedSet 을 실시간 계산 노드의 하드웨어에 따라 설정해야 합니다.

ComputeRealTime.yaml

ComputeSriovRT

컴퓨팅 SR-IOV RealTime 역할.

ComputeSriovRT.yaml

ComputeSriov

컴퓨팅 SR-IOV 역할.

ComputeSriov.yaml

Compute

표준 컴퓨팅 노드 역할.

compute.yaml

ControllerAllNovaStandalone

데이터베이스, 메시징, 네트워킹 및 OpenStack 계산(nova) 제어 구성 요소를 포함하지 않는 컨트롤러 역할. Database,Messaging,NetworkerNovacontrol 역할과 함께 를 사용합니다.

ControllerAllNovaStandalone.yaml

ControllerNoCeph

핵심 컨트롤러 서비스가 로드되었지만 Ceph 스토리지(MON) 구성 요소가 없는 컨트롤러 역할. 이 역할은 Ceph Storage 기능이 아닌 데이터베이스, 메시징 및 네트워크 기능을 처리합니다.

ControllerNoCeph.yaml

ControllerNovaStandalone

OpenStack Compute(nova) 제어 구성 요소를 포함하지 않는 컨트롤러 역할. Novacontrol 역할과 함께 를 사용합니다.

ControllerNovaStandalone.yaml

ControllerOpenstack

데이터베이스, 메시징 및 네트워킹 구성 요소를 포함하지 않는 컨트롤러 역할. Database,MessagingNetworker 역할과 함께 를 사용합니다.

ControllerOpenstack.yaml

ControllerStorageNfs

모든 핵심 서비스가 로드되고 Ceph NFS를 사용하는 컨트롤러 역할. 이 역할은 데이터베이스, 메시징 및 네트워크 기능을 처리합니다.

ControllerStorageNfs.yaml

컨트롤러

모든 핵심 서비스가 로드된 컨트롤러 역할. 이 역할은 데이터베이스, 메시징 및 네트워크 기능을 처리합니다.

controller.yaml

ControllerSriov (ML2/OVN)

일반 Controller 역할과 동일하지만 OVN 메타데이터 에이전트가 배포된 상태에서도 마찬가지입니다.

ControllerSriov.yaml

데이터베이스

독립 실행형 데이터베이스 역할. Pacemaker를 사용하여 Galera 클러스터로 관리되는 데이터베이스.

Database.yaml

HciCephAll

하이퍼컨버지드 인프라 및 모든 Ceph Storage 서비스가 포함된 계산 노드. OSD, MON, Object Gateway(RGW), Object Operations(MDS), Manager(MGR) 및 RBD Mirroring이 포함됩니다.

HciCephAll.yaml

HciCephFile

하이퍼컨버지드 인프라 및 Ceph Storage 파일 서비스가 포함된 계산 노드. OSD 및 MDS(Object Operations) 포함.

HciCephFile.yaml

HciCephMon

하이퍼컨버지드 인프라 및 Ceph Storage 블록 서비스가 포함된 계산 노드. OSD, MON, Manager가 포함됩니다.

HciCephMon.yaml

HciCephObject

하이퍼컨버지드 인프라 및 Ceph Storage 오브젝트 서비스가 포함된 계산 노드. OSD 및 개체 게이트웨이(RGW)를 포함합니다.

HciCephObject.yaml

IronicConductor

Ironic Conductor 노드 역할.

IronicConductor.yaml

메시징

독립 실행형 메시징 역할. Pacemaker로 관리되는 RabbitMQ.

messaging.yaml

Networker

독립 실행형 네트워킹 역할. OpenStack 네트워킹(neutron) 에이전트를 자체적으로 실행합니다. 배포에서 ML2/OVN 메커니즘 드라이버를 사용하는 경우 ML2/OVN으로 사용자 지정 역할 배포 의 추가 단계를 참조하십시오.

Networker.yaml

NetworkerSriov

일반 Networker 역할과 동일하지만 OVN 메타데이터 에이전트가 배포되었습니다. ML2/OVN을 사용하여 사용자 지정 역할 배포 의 추가 단계를 참조하십시오.

NetworkerSriov.yaml

Novacontrol

OpenStack Compute(nova) 제어 에이전트를 자체적으로 실행하는 독립 실행형 nova-control 역할.

novacontrol.yaml

ObjectStorage

Swift 오브젝트 스토리지 노드 역할.

ObjectStorage.yaml

Telemetry

모든 지표 및 알람 서비스가 포함된 원격 분석 역할.

telemetry.yaml

6.5. 역할 매개변수 검사

각 역할에는 다음 매개변수가 포함됩니다.

name
(필수) 공백이나 특수 문자가 없는 일반 텍스트 이름인 역할의 이름입니다. 선택한 이름이 다른 리소스와 충돌하지 않는지 확인합니다. 예를 들어 Network 대신 Network er 를 사용합니다.
description
(선택 사항) 역할에 대한 일반 텍스트 설명입니다.
tags

(선택 사항) 역할 속성을 정의하는 태그의 YAML 목록입니다. 이 매개변수를 사용하여 컨트롤러와 기본 태그 둘 다로 기본 역할을 정의합니다.

- name: Controller
  ...
  tags:
    - primary
    - controller
  ...
중요

기본 역할에 태그를 지정하지 않으면 정의한 첫 번째 역할이 기본 역할이 됩니다. 이 역할이 Controller 역할인지 확인합니다.

네트워크

역할에 구성할 네트워크의 YAML 목록 또는 사전입니다. YAML 목록을 사용하는 경우 각 구성 가능 네트워크를 나열합니다.

  networks:
    - External
    - InternalApi
    - Storage
    - StorageMgmt
    - Tenant

사전을 사용하는 경우 각 네트워크를 구성 가능한 네트워크의 특정 서브넷에 매핑합니다.

  networks:
    External:
      subnet: external_subnet
    InternalApi:
      subnet: internal_api_subnet
    Storage:
      subnet: storage_subnet
    StorageMgmt:
      subnet: storage_mgmt_subnet
    Tenant:
      subnet: tenant_subnet

기본 네트워크에는 External,InternalApi,Storage, Storage Mgmt,TenantManagement 가 포함됩니다.

CountDefault
(선택 사항) 이 역할에 배포할 기본 노드 수를 정의합니다.
HostnameFormatDefault

(선택 사항) 역할에 대한 기본 호스트 이름 형식을 정의합니다. 기본 명명 규칙은 다음 형식을 사용합니다.

[STACK NAME]-[ROLE NAME]-[NODE ID]

예를 들어 기본 컨트롤러 노드의 이름은 다음과 같습니다.

overcloud-controller-0
overcloud-controller-1
overcloud-controller-2
...
disable_constraints
(선택 사항) director와 함께 배포할 때 OpenStack Compute(nova) 및 OpenStack Image Storage(glance) 제약 조건을 비활성화할지 여부를 정의합니다. 사전 프로비저닝된 노드가 있는 오버클라우드를 배포할 때 이 매개변수를 사용합니다. 자세한 내용은 Director 설치 및 사용 가이드의 사전 프로비저닝된 노드로 기본 오버클라우드 설정을 참조하십시오.
update_serial

(선택 사항) OpenStack 업데이트 옵션 중에 동시에 업데이트할 노드 수를 정의합니다. 기본 roles_data.yaml 파일에서 다음을 수행합니다.

  • 기본값은 Controller, Object Storage 및 Ceph Storage 노드의 경우 1 입니다.
  • Compute 및 Block Storage 노드의 기본값은 25 입니다.

사용자 지정 역할에서 이 매개변수를 생략하면 기본값은 1 입니다.

ServicesDefault
(선택 사항) 노드에 포함할 기본 서비스 목록을 정의합니다. 자세한 내용은 6.8절. “구성 가능 서비스 아키텍처 검사”의 내용을 참조하십시오.

이러한 매개 변수를 사용하여 새 역할을 생성하고 역할에 포함할 서비스를 정의할 수도 있습니다.

openstack overcloud deploy 명령은 roles_data 파일의 매개 변수를 Jinja2 기반 템플릿에 통합합니다. 예를 들어 특정 지점에서 overcloud.j2.yaml heat 템플릿은 roles_data.yaml 의 역할 목록을 반복하고 각 역할과 관련된 매개 변수와 리소스를 생성합니다.

예를 들어 다음 코드 조각에는 overcloud.j2.yaml heat 템플릿의 각 역할에 대한 리소스 정의가 포함되어 있습니다.

  {{role.name}}:
    type: OS::Heat::ResourceGroup
    depends_on: Networks
    properties:
      count: {get_param: {{role.name}}Count}
      removal_policies: {get_param: {{role.name}}RemovalPolicies}
      resource_def:
        type: OS::TripleO::{{role.name}}
        properties:
          CloudDomain: {get_param: CloudDomain}
          ServiceNetMap: {get_attr: [ServiceNetMap, service_net_map]}
          EndpointMap: {get_attr: [EndpointMap, endpoint_map]}
...

이 코드 조각은 Jinja2 기반 템플릿이 {{role.name}} 변수를 통합하여 각 역할의 이름을 OS::Heat::ResourceGroup 리소스로 정의하는 방법을 보여줍니다. 그런 다음 roles_data 파일의 각 name 매개변수를 사용하여 각각의 OS::Heat::ResourceGroup 리소스 이름을 지정합니다.

6.6. 새 역할 생성

구성 가능 서비스 아키텍처를 사용하여 배포 요구 사항에 따라 새 역할을 생성할 수 있습니다. 예를 들어 OpenStack 대시보드(horizon)만 호스팅하는 새 Horizon 역할을 생성할 수 있습니다.

참고

역할 이름은 문자 또는 숫자로 시작하고 문자, 숫자, 하이픈만 포함해야 합니다. 밑줄을 역할 이름에 사용해서는 안 됩니다.

절차

  1. 기본 역할 디렉터리의 사용자 지정 사본을 생성합니다.

    $ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
  2. ~/roles/Horizon.yaml 이라는 새 파일을 생성하고 기본 및 핵심 OpenStack 대시보드 서비스가 포함된 새 Horizon 역할을 생성합니다.

    - name: Horizon
      CountDefault: 1
      HostnameFormatDefault: '%stackname%-horizon-%index%'
      ServicesDefault:
        - OS::TripleO::Services::CACerts
        - OS::TripleO::Services::Kernel
        - OS::TripleO::Services::Ntp
        - OS::TripleO::Services::Snmp
        - OS::TripleO::Services::Sshd
        - OS::TripleO::Services::Timezone
        - OS::TripleO::Services::TripleoPackages
        - OS::TripleO::Services::TripleoFirewall
        - OS::TripleO::Services::SensuClient
        - OS::TripleO::Services::FluentdClient
        - OS::TripleO::Services::AuditD
        - OS::TripleO::Services::Collectd
        - OS::TripleO::Services::MySQLClient
        - OS::TripleO::Services::Apache
        - OS::TripleO::Services::Horizon

    기본 오버클라우드에 항상 Horizon 노드가 포함되도록 CountDefault1 로 설정합니다.

  3. 선택 사항: 기존 오버클라우드에서 서비스를 확장하려면 Controller 역할의 기존 서비스를 유지합니다. 새 오버클라우드를 생성하고 OpenStack 대시보드를 독립 실행형 역할에 유지하려면 컨트롤러 역할 정의에서 OpenStack 대시보드 구성 요소를 제거합니다.

    - name: Controller
      CountDefault: 1
      ServicesDefault:
        ...
        - OS::TripleO::Services::GnocchiMetricd
        - OS::TripleO::Services::GnocchiStatsd
        - OS::TripleO::Services::HAproxy
        - OS::TripleO::Services::HeatApi
        - OS::TripleO::Services::HeatApiCfn
        - OS::TripleO::Services::HeatApiCloudwatch
        - OS::TripleO::Services::HeatEngine
        # - OS::TripleO::Services::Horizon                # Remove this service
        - OS::TripleO::Services::IronicApi
        - OS::TripleO::Services::IronicConductor
        - OS::TripleO::Services::Iscsid
        - OS::TripleO::Services::Keepalived
        ...
  4. ~/roles 디렉터리를 소스로 사용하여 새 roles_data-horizon.yaml 파일을 생성합니다.

    $ openstack overcloud roles generate -o roles_data-horizon.yaml \
      --roles-path ~/roles \
      Controller Compute Horizon
  5. 특정 노드에 태그를 지정할 수 있도록 이 역할에 대한 새 플레이버를 정의합니다. 이 예에서는 다음 명령을 사용하여 Horizon 플레이버를 생성합니다.

    1. Horizon 플레이버를 생성합니다.

      (undercloud)$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 horizon
      참고

      이러한 속성은 인스턴스를 예약하는 데 사용되지 않지만 Compute 스케줄러는 디스크 크기를 사용하여 루트 파티션 크기를 결정합니다.

    2. 대시보드 서비스(horizon)를 사용자 정의 리소스 클래스로 지정할 각 베어 메탈 노드에 태그를 지정합니다.

      (undercloud)$ openstack baremetal node set --resource-class baremetal.HORIZON <NODE>

      <NODE> 를 베어 메탈 노드의 ID로 바꿉니다.

    3. Horizon 플레이버를 사용자 지정 리소스 클래스와 연결합니다.

      (undercloud)$ openstack flavor set --property resources:CUSTOM_BAREMETAL_HORIZON=1 horizon

      베어 메탈 노드의 리소스 클래스에 해당하는 사용자 정의 리소스 클래스의 이름을 확인하려면 리소스 클래스를 대문자로 변환하고 문장 부호를 밑줄로 바꾸고, 값 앞에 CUSTOM_ 을 추가합니다.

      참고

      플레이버는 베어 메탈 리소스 클래스의 인스턴스 하나만 요청할 수 있습니다.

    4. Compute 스케줄러가 인스턴스 예약에 베어 메탈 플레이버 속성을 사용하지 않도록 다음 플레이버 속성을 설정합니다.

      (undercloud)$ openstack flavor set --property resources:VCPU=0 --property resources:MEMORY_MB=0 --property resources:DISK_GB=0 horizon
  6. 다음 환경 파일 스니펫을 사용하여 Horizon 노드 수 및 플레이버를 정의합니다.

    parameter_defaults:
      OvercloudHorizonFlavor: horizon
      HorizonCount: 1
  7. 배포와 관련된 기타 모든 환경 파일과 함께 openstack overcloud deploy 명령에 새 roles_data-horizon.yaml 파일 및 환경 파일을 포함합니다.

    $ openstack overcloud deploy --templates -r ~/templates/roles_data-horizon.yaml -e ~/templates/node-count-flavor.yaml

    이 구성에서는 컨트롤러 노드 1개, 컴퓨팅 노드 1개, Networker 노드 1개로 구성된 3노드 오버클라우드가 생성됩니다. 오버클라우드의 노드 목록을 보려면 다음 명령을 실행합니다.

    $ openstack server list

6.7. 지침 및 제한 사항

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

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

  • 독립 실행형 사용자 정의 역할에 서비스를 할당할 수 있습니다.
  • 초기 배포 후 추가 사용자 지정 역할을 생성하고 배포하여 기존 서비스를 확장할 수 있습니다.

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

  • 독립 실행형 사용자 정의 역할에 Pacemaker 관리 서비스를 할당할 수 있습니다.
  • Pacemaker에는 노드 제한이 16개 있습니다. Pacemaker 서비스(OS::TripleO::Services::Pacemaker)를 16개 노드에 할당하는 경우 이후 노드에서 Pacemaker 원격 서비스(OS::TripleO::Services::PacemakerRemote)를 대신 사용해야 합니다. 동일한 역할에 Pacemaker 서비스 및 Pacemaker 원격 서비스가 있을 수 없습니다.
  • Pacemaker 관리 서비스가 포함되지 않은 역할에 Pacemaker 서비스(OS::TripleO::Services::Pacemaker)를 포함하지 마십시오.
  • OS::TripleO::Services::Pacemaker 또는 OS::TripleO::Services: :Pacemaker Remote 서비스가 포함된 사용자 지정 역할을 확장하거나 축소할 수 없습니다.

일반적인 제한 사항:

  • 주요 버전 업그레이드 중에 사용자 정의 역할 및 구성 가능 서비스를 변경할 수 없습니다.
  • 오버클라우드를 배포한 후에는 역할에 대한 서비스 목록을 수정할 수 없습니다. Overcloud 배포 후 서비스 목록을 수정하면 배포 오류가 발생하고 노드에 서비스를 분리할 수 있습니다.

6.8. 구성 가능 서비스 아키텍처 검사

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

  • 배포에 는 주요 OpenStack 서비스를 위한 템플릿이 포함되어 있습니다.
  • Puppet/services 에는 구성 가능 서비스를 구성하기 위한 레거시 템플릿이 포함되어 있습니다. 구성 가능 서비스는 이 디렉터리의 템플릿을 사용하여 호환성을 유지하는 경우도 있습니다. 대부분의 경우 구성 가능 서비스는 배포 디렉터리에서 템플릿을 사용합니다.

각 템플릿에는 목적을 식별하는 설명이 포함되어 있습니다. 예를 들어 deployment/time/ntp-baremetal-puppet.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.

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

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

resource_registry:
  ...
  OS::TripleO::Services::Ntp: deployment/time/ntp-baremetal-puppet.yaml
  ...

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

resource_registry:
  ...
  OS::TripleO::Services::Keystone: deployment/keystone/keystone-container-puppet.yaml
  ...

이러한 컨테이너화된 템플릿은 일반적으로 다른 템플릿을 참조하여 종속성을 포함합니다. 예를 들어 deployment/keystone/keystone-container-puppet.yaml 템플릿은 기본 템플릿의 출력을 ContainersCommon 리소스에 저장합니다.

resources:
  ContainersCommon:
    type: ../containers-common.yaml

그런 다음 컨테이너화된 템플릿은 containers-common.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,ObjectStorageServicesCephStorageServices.

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 매개변수의 기본 목록으로 정의됩니다.

참고

환경 파일을 사용하여 서비스 매개변수의 기본 목록을 재정의할 수도 있습니다. 예를 들어 환경 파일에서 ControllerServicesparameter_default 로 정의하여 roles_data.yaml 파일의 서비스 목록을 재정의할 수 있습니다.

6.9. 역할에서 서비스 추가 및 제거

서비스를 추가하거나 제거하는 기본 방법은 노드 역할에 대한 기본 서비스 목록 복사본을 생성한 다음 서비스를 추가하거나 제거하는 것입니다. 예를 들어 컨트롤러 노드에서 OpenStack Orchestration(heat)을 제거할 수 있습니다.

절차

  1. 기본 역할 디렉터리의 사용자 지정 사본을 생성합니다.

    $ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
  2. ~/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
  3. roles_data 파일을 생성합니다.

    $ openstack overcloud roles generate -o roles_data-no_heat.yaml \
      --roles-path ~/roles \
      Controller Compute Networker
  4. openstack overcloud deploy 명령을 실행할 때 이 새 roles_data 파일을 포함합니다.

    $ openstack overcloud deploy --templates -r ~/templates/roles_data-no_heat.yaml

    이 명령은 컨트롤러 노드에 OpenStack Orchestration 서비스를 설치하지 않고 오버클라우드를 배포합니다.

참고

또한 사용자 지정 환경 파일을 사용하여 roles_data 파일에서 서비스를 비활성화할 수 있습니다. 비활성화하도록 서비스를 리디렉션하여 OS::Heat::None 리소스로 전환합니다. 예를 들면 다음과 같습니다.

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

6.10. 비활성화된 서비스 활성화

일부 서비스는 기본적으로 비활성화되어 있습니다. 이러한 서비스는 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 파일을 사용합니다.

절차

  1. CinderBackup 서비스를 cinder-backup 구성이 포함된 heat 템플릿에 연결하는 환경 파일에 항목을 추가합니다.

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

    이 항목은 기본 null 작업 리소스를 재정의하고 서비스를 활성화합니다.

  2. openstack overcloud deploy 명령을 실행할 때 이 환경 파일을 추가합니다.

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

6.11. 서비스 없이 일반 노드 생성

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

참고

일반 노드에서는 기본 Red Hat Enterprise Linux 8 이미지가 아닌 기본 overcloud-full 이미지를 계속 사용합니다. 즉, 노드에 일부 Red Hat OpenStack Platform 소프트웨어가 설치되어 있지만 활성화 또는 구성되지 않습니다.

절차

  1. ServicesDefault 목록이 포함되지 않은 사용자 정의 roles_data.yaml 파일에 일반 역할을 생성합니다.

    - name: Generic
    - name: Controller
      CountDefault: 1
      ServicesDefault:
        - OS::TripleO::Services::AuditD
        - OS::TripleO::Services::CACerts
        - OS::TripleO::Services::CephClient
        ...
    - name: Compute
      CountDefault: 1
      ServicesDefault:
        - OS::TripleO::Services::AuditD
        - OS::TripleO::Services::CACerts
        - OS::TripleO::Services::CephClient
        ...

    기존 ControllerCompute 역할을 유지해야 합니다.

  2. 환경 파일 generic-node-params.yaml 을 생성하여 필요한 일반 Red Hat Enterprise Linux 8 노드 수와 프로비저닝할 노드를 선택할 때 플레이버를 지정합니다.

    parameter_defaults:
      OvercloudGenericFlavor: baremetal
      GenericCount: 1
  3. 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 8 노드 1개가 있는 3-노드 환경을 배포합니다.

7장. 컨테이너화된 서비스

director는 핵심 OpenStack Platform 서비스를 오버클라우드에 컨테이너로 설치합니다. 이 섹션에서는 컨테이너화된 서비스의 작동 방식에 대한 몇 가지 배경 정보를 제공합니다.

7.1. 컨테이너화된 서비스 아키텍처

director는 핵심 OpenStack Platform 서비스를 오버클라우드에 컨테이너로 설치합니다. 컨테이너화된 서비스의 템플릿은 /usr/share/openstack-tripleo-heat-templates/deployment/ 에 있습니다.

컨테이너화된 서비스를 사용하는 모든 노드에 대해 역할에 OS::TripleO::Services::Podman 서비스를 활성화해야 합니다. 사용자 지정 역할 구성에 roles_data.yaml 파일을 생성할 때 기본 구성 가능 서비스와 함께 OS::TripleO::Services::Podman 서비스를 포함합니다. 예를 들어 IronicConductor 역할은 다음 역할 정의를 사용합니다.

- name: IronicConductor
  description: |
    Ironic Conductor node role
  networks:
    InternalApi:
      subnet: internal_api_subnet
    Storage:
      subnet: storage_subnet
  HostnameFormatDefault: '%stackname%-ironic-%index%'
  ServicesDefault:
    - OS::TripleO::Services::Aide
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::BootParams
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CertmongerUser
    - OS::TripleO::Services::Collectd
    - OS::TripleO::Services::Docker
    - OS::TripleO::Services::Fluentd
    - OS::TripleO::Services::IpaClient
    - OS::TripleO::Services::Ipsec
    - OS::TripleO::Services::IronicConductor
    - OS::TripleO::Services::IronicPxe
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::LoginDefs
    - OS::TripleO::Services::MetricsQdr
    - OS::TripleO::Services::MySQLClient
    - OS::TripleO::Services::ContainersLogrotateCrond
    - OS::TripleO::Services::Podman
    - OS::TripleO::Services::Rhsm
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timesync
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::Tuned

7.2. 컨테이너화된 서비스 매개변수

컨테이너화된 각 서비스 템플릿에는 OpenStack Orchestration(heat) 서비스에 전달된 데이터 집합을 정의하는 outputs 섹션이 포함되어 있습니다. 표준 구성 가능 서비스 매개변수( 6.5절. “역할 매개변수 검사”참조) 외에도 템플릿에는 컨테이너 구성과 관련된 매개변수 세트가 포함되어 있습니다.

puppet_config

서비스를 구성할 때 Puppet에 전달할 데이터입니다. 초기 오버클라우드 배포 단계에서 director는 실제 컨테이너화된 서비스가 실행되기 전에 서비스를 구성하는 데 사용되는 컨테이너 세트를 생성합니다. 이 매개변수에는 다음 하위 매개변수가 포함됩니다.

  • config_volume - 구성을 저장하는 마운트된 볼륨입니다.
  • puppet_tags - 구성 중에 Puppet에 전달할 태그입니다. OpenStack에서는 이러한 태그를 사용하여 Puppet 실행을 특정 서비스의 구성 리소스로 제한합니다. 예를 들어 OpenStack ID(keystone) 컨테이너화된 서비스는 keystone_config 태그를 사용하여 모두 구성 컨테이너에서 실행되는 keystone_config Puppet 리소스만 필요한지 확인합니다.
  • step_config - Puppet에 전달되는 구성 데이터입니다. 일반적으로 이는 참조된 구성 가능 서비스에서 상속됩니다.
  • config_image - 서비스를 구성하는 데 사용되는 컨테이너 이미지입니다.
kolla_config
구성 파일 위치, 디렉터리 권한 및 컨테이너에서 실행할 명령을 정의하여 서비스를 시작하는 컨테이너별 데이터 집합입니다.
docker_config

서비스의 구성 컨테이너에서 실행할 작업입니다. 모든 작업은 director가 스테이징된 배포를 수행할 수 있도록 다음 단계로 그룹화됩니다.

  • 1단계 - 로드 밸런서 구성
  • 2단계 - 핵심 서비스(데이터베이스, Redis)
  • 3 단계 - OpenStack Platform 서비스의 초기 구성
  • 4 단계 - 일반 OpenStack Platform 서비스 구성
  • 5단계 - 서비스 활성화
host_prep_tasks
컨테이너화된 서비스를 수용하도록 베어 메탈 노드에 대한 작업 준비.

7.3. 컨테이너 이미지 준비

오버클라우드 설치에는 컨테이너 이미지를 가져올 위치와 저장 방법을 결정하는 환경 파일이 필요합니다. 컨테이너 이미지를 준비하는 데 사용할 수 있는 이 환경 파일을 생성하고 사용자 지정하십시오.

참고

오버클라우드의 특정 컨테이너 이미지 버전을 구성해야 하는 경우 이미지를 특정 버전에 고정해야 합니다. 자세한 내용은 오버클라우드의 컨테이너 이미지 고정을 참조하십시오.

절차

  1. stack 사용자로 언더클라우드 호스트에 로그인합니다.
  2. 기본 컨테이너 이미지 준비 파일을 생성합니다.

    $ sudo openstack tripleo container image prepare default \
      --local-push-destination \
      --output-env-file containers-prepare-parameter.yaml

    이 명령은 다음과 같은 추가 옵션을 사용합니다.

    • --local-push-destination은 언더클라우드의 레지스트리를 컨테이너 이미지의 위치로 설정합니다. 즉 director가 Red Hat Container Catalog에서 필요한 이미지를 가져와서 언더클라우드의 레지스트리로 푸시합니다. director는 이 레지스트리를 컨테이너 이미지 소스로 사용합니다. Red Hat Container Catalog에서 직접 가져오려면 이 옵션을 생략합니다.
    • --output-env-file은 환경 파일 이름입니다. 이 파일 내용에는 컨테이너 이미지를 준비하는 데 필요한 매개변수가 포함되어 있습니다. 이 경우 파일 이름은 containers-prepare-parameter.yaml입니다.

      참고

      동일한 containers-prepare-parameter.yaml 파일을 사용하여 언더클라우드와 오버클라우드의 컨테이너 이미지 소스를 모두 정의할 수 있습니다.

  3. containers-prepare-parameter.yaml을 요구 사항에 맞게 수정합니다.

7.4. 컨테이너 이미지 준비 매개변수

컨테이너를 준비하는 데 필요한 기본 파일(containers-prepare-parameter.yaml)에는 ContainerImagePrepare heat 매개변수가 포함되어 있습니다. 이 매개변수는 이미지 세트를 준비하기 위한 다양한 설정을 정의합니다.

parameter_defaults:
  ContainerImagePrepare:
  - (strategy one)
  - (strategy two)
  - (strategy three)
  ...

각각의 설정에서 하위 매개변수 세트를 통해 사용할 이미지와 해당 이미지의 사용 방법을 정의할 수 있습니다. 다음 표에는 각 ContainerImagePrepare 전략에 사용할 수 있는 하위 매개변수에 대한 정보가 나와 있습니다.

매개변수설명

excludes

전략에서 이미지 이름을 제외하는 정규식 목록입니다.

includes

전략에 포함할 정규식 목록입니다. 기존 이미지와 일치하는 이미지 이름이 하나 이상 있어야 합니다. includes를 지정하면 excludes는 모두 무시됩니다.

modify_append_tag

대상 이미지 태그에 추가할 문자열입니다. 예를 들어 태그가 16.1.3-5.161인 이미지를 가져와서 modify_append_tag-hotfix 로 설정하면 director는 최종 이미지에 16.1.3-5.161-hotfix로 태그를 지정합니다.

modify_only_with_labels

수정할 이미지를 필터링하는 이미지 레이블로 이루어진 사전입니다. 이미지가 정의된 레이블과 일치하면 director에서 그 이미지를 수정 프로세스에 포함합니다.

modify_role

이미지를 대상 레지스트리로 푸시하기 전 업로드 중에 실행할 ansible 역할 이름의 문자열입니다.

modify_vars

modify_role로 전달할 변수로 이루어진 사전입니다.

push_destination

업로드 프로세스 중 이미지를 푸시할 레지스트리의 네임스페이스를 정의합니다.

  • true로 설정하면 push_destination이 해당 호스트 이름을 사용하는 언더클라우드 레지스트리 네임스페이스로 설정되며, 이것이 권장되는 방법입니다.
  • false로 설정하면 로컬 레지스트리로 푸시되지 않고 노드가 소스에서 직접 이미지를 가져옵니다.
  • 사용자 지정 값으로 설정하면 director가 이미지를 외부 로컬 레지스트리로 푸시합니다.

Red Hat Container Catalog에서 직접 이미지를 가져오는 동안 프로덕션 환경에서 이 매개변수를 false로 설정하면 모든 오버클라우드 노드에서 외부 연결을 통해 Red Hat Container Catalog의 이미지를 동시에 가져옵니다. 이로 인해 대역폭 문제가 발생할 수 있습니다. 컨테이너 이미지를 호스팅하는 Red Hat Satellite 서버에서 이미지를 직접 가져올 때만 false를 사용하십시오.

push_destination 매개변수가 정의되지 않았거나 false로 설정되었는데 원격 레지스트리에 인증이 필요한 경우, ContainerImageRegistryLogin 매개변수를 true로 설정하고 ContainerImageRegistryCredentials 매개변수가 있는 인증 정보를 포함하십시오.

pull_source

원본 컨테이너 이미지를 가져온 소스 레지스트리입니다.

set

초기 이미지를 가져올 위치를 정의하는 key: value 정의로 이루어진 사전입니다.

tag_from_label

지정된 컨테이너 이미지 메타데이터 레이블의 값을 사용하여 모든 이미지에 대한 태그를 생성하고 해당 태그가 지정된 이미지를 가져옵니다. 예를 들어 tag_from_label: {version}-{release}를 설정하면 director는 versionrelease 레이블을 사용하여 새 태그를 구성합니다. 한 컨테이너의 경우 version 을 16.1.3으로 설정하고 릴리스가 5.161 으로 설정될 수 있으므로 태그 16.1.3-5.161이 발생할 수 있습니다. director는 set 사전에 tag가 정의되지 않은 경우에만 이 매개변수를 사용합니다.

중요

이미지를 언더클라우드로 내보내는 경우 push _destination 대신 push_destination: true 를 사용합니다. UNDERCLOUD_IP:PORT. push_destination: true 방식은 IPv4 및 IPv6 주소 모두에서 일관성 수준을 제공합니다.

set 매개변수에 여러 key: value 정의를 사용할 수 있습니다.

설명

ceph_image

Ceph Storage 컨테이너 이미지의 이름입니다.

ceph_namespace

Ceph Storage 컨테이너 이미지의 네임스페이스입니다.

ceph_tag

Ceph Storage 컨테이너 이미지의 태그입니다.

ceph_alertmanager_image

ceph_alertmanager_namespace

ceph_alertmanager_tag

Ceph Storage Alert Manager 컨테이너 이미지의 이름, 네임스페이스 및 태그입니다.

ceph_grafana_image

ceph_grafana_namespace

ceph_grafana_tag

Ceph Storage Grafana 컨테이너 이미지의 이름, 네임스페이스 및 태그입니다.

ceph_node_exporter_image

ceph_node_exporter_namespace

ceph_node_exporter_tag

Ceph Storage 노드 내보내기 컨테이너 이미지의 이름, 네임스페이스 및 태그입니다.

ceph_prometheus_image

ceph_prometheus_namespace

ceph_prometheus_tag

Ceph Storage Prometheus 컨테이너 이미지의 이름, 네임스페이스 및 태그입니다.

name_prefix

각 OpenStack 서비스 이미지의 접두사입니다.

name_suffix

각 OpenStack 서비스 이미지의 접미사입니다.

namespace

각 OpenStack 서비스 이미지의 네임스페이스입니다.

neutron_driver

사용할 OpenStack Networking (Neutron) 컨테이너를 결정하는 데 사용할 드라이버입니다. null 값을 사용하여 표준 neutron-server 컨테이너를 설정합니다. OVN 기반 컨테이너를 사용하려면 ovn으로 설정합니다.

tag

소스의 모든 이미지에 대한 특정 태그를 설정합니다. 정의되지 않은 경우 director는 Red Hat OpenStack Platform 버전 번호를 기본값으로 사용합니다. 이 매개변수가 tag_from_label 값보다 우선합니다.

참고

컨테이너 이미지는 Red Hat OpenStack Platform 버전을 기반으로 멀티 스트림 태그를 사용합니다. 즉, 더 이상 latest 태그가 없음을 의미합니다.

7.5. 컨테이너 이미지 태그 지침

Red Hat Container Registry는 특정 버전 형식을 사용하여 모든 Red Hat OpenStack Platform 컨테이너 이미지에 태그를 지정합니다. 이 형식은 version-release인 각 컨테이너의 레이블 메타데이터를 따릅니다.

버전
Red Hat OpenStack Platform의 주요 및 마이너 버전에 해당합니다. 이러한 버전은 하나 이상의 릴리스를 포함하는 스트림으로 작동합니다.
릴리스
버전 스트림 내 특정 컨테이너 이미지 버전의 릴리스에 해당합니다.

예를 들어 최신 버전의 Red Hat OpenStack Platform이 16.1.3이고 컨테이너 이미지의 릴리스가 5.161 인 경우 컨테이너 이미지의 결과 태그는 16.1.3-5.161입니다.

Red Hat Container Registry에서는 해당 컨테이너 이미지 버전의 최신 릴리스에 연결되는 메이저 및 마이너 version 버전 태그 세트도 사용합니다. 예를 들어 16.1 및 16.1.3 컨테이너 스트림의 최신 릴리스에 대한 링크입니다. 16.1의 새 마이너 릴리스가 발생하면 16.1.3 태그가 16.1.3 스트림 내의 최신 릴리스에 계속 연결됩니다.

ContainerImagePrepare 매개변수에는 다운로드할 컨테이너 이미지를 결정하는 데 사용할 두 개의 하위 매개변수가 포함되어 있습니다. 이러한 하위 매개변수는 set 사전 내의 tag 매개변수와 tag_from_label 매개변수입니다. 다음 지침을 사용하여 tag 또는 tag_from_label을 사용할지 여부를 결정합니다.

  • tag의 기본값은 OpenStack Platform 버전의 주요 버전입니다. 이 버전의 경우 16.1입니다. 이는 항상 최신 마이너 버전 및 릴리스에 해당합니다.

    parameter_defaults:
      ContainerImagePrepare:
      - set:
          ...
          tag: 16.1
          ...
  • OpenStack Platform 컨테이너 이미지의 특정 마이너 버전으로 변경하려면 태그를 마이너 버전으로 설정합니다. 예를 들어 16.1.2로 변경하려면 tag 를 16.1.2로 설정합니다.

    parameter_defaults:
      ContainerImagePrepare:
      - set:
          ...
          tag: 16.1.2
          ...
  • tag를 설정하면 director는 설치 및 업데이트 중에 tag에 설정된 버전의 최신 컨테이너 이미지 release를 항상 다운로드합니다.
  • tag를 설정하지 않으면 director는 최신 주요 버전과 함께 tag_from_label 값을 사용합니다.

    parameter_defaults:
      ContainerImagePrepare:
      - set:
          ...
          # tag: 16.1
          ...
        tag_from_label: '{version}-{release}'
  • tag_from_label 매개변수는 Red Hat Container Registry에서 검사하는 최신 컨테이너 이미지 릴리스의 레이블 메타데이터에서 태그를 생성합니다. 예를 들어 특정 컨테이너의 레이블에서 다음 versionrelease 메타데이터를 사용할 수 있습니다.

      "Labels": {
        "release": "5.161",
        "version": "16.1.3",
        ...
      }
  • tag_from_label의 기본값은 {version}-{release}로, 각 컨테이너 이미지의 버전 및 릴리스 메타데이터 레이블에 해당합니다. 예를 들어 컨테이너 이미지에 버전 용으로 16.1.3이 설정되어 있고 릴리스 용으로 5.161이 설정된 경우 컨테이너 이미지의 결과 태그는 16.1.3-5.161입니다.
  • tag 매개변수는 항상 tag_from_label 매개변수보다 우선합니다. tag_from_label을 사용하려면 컨테이너 준비 구성에서 tag 매개변수를 생략합니다.
  • tagtag_from_label의 주요 차이점은 director가 tag를 사용하여 주요 또는 마이너 버전 태그를 기반으로만 이미지를 가져온다는 것입니다. 이 태그는 버전 스트림 내의 최신 이미지 릴리스에 대한 Red Hat Container Registry 링크인 반면 director는 tag_from_label을 사용하여 director가 태그를 생성하고 해당 이미지를 가져올 수 있도록 각 컨테이너 이미지의 메타데이터 검사를 수행합니다.

7.6. 개인 레지스트리에서 컨테이너 이미지 가져오기

registry.redhat.io 레지스트리에는 이미지에 액세스하여 가져오기 위한 인증이 필요합니다. registry.redhat.io 및 기타 개인 레지스트리로 인증하려면 containers-prepare-parameter.yaml 파일에 ContainerImageRegistryCredentialsContainerImageRegistryLogin 매개변수를 포함합니다.

ContainerImageRegistryCredentials

일부 컨테이너 이미지 레지스트리는 이미지에 액세스하기 위해 인증이 필요합니다. 이 경우 container-prepare-parameter.yaml 환경 파일에서 ContainerImageRegistryCredentials 매개변수를 사용합니다. ContainerImageRegistryCredentials 매개변수는 개인 레지스트리 URL에 따라 여러 키를 사용합니다. 각 개인 레지스트리 URL은 고유한 키와 값 쌍을 사용하여 사용자 이름(키)과 암호(값)를 정의합니다. 이런 방법으로 여러 개인 레지스트리의 인증 정보를 지정할 수 있습니다.

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      namespace: registry.redhat.io/...
      ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      my_username: my_password

예제에서 my_usernamemy_password를 사용자 인증 정보로 교체합니다. 개별 사용자 인증 정보를 사용하는 대신, 레지스트리 서비스 계정을 생성하고 해당 인증 정보를 사용하여 registry.redhat.io 콘텐츠에 액세스하는 것이 좋습니다.

여러 레지스트리에 대한 인증 세부 정보를 지정하려면 ContainerImageRegistryCredentials의 각 레지스트리에 대해 여러 개의 키 쌍 값을 설정합니다.

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      namespace: registry.redhat.io/...
      ...
  - push_destination: true
    set:
      namespace: registry.internalsite.com/...
      ...
  ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      myuser: 'p@55w0rd!'
    registry.internalsite.com:
      myuser2: '0th3rp@55w0rd!'
    '192.0.2.1:8787':
      myuser3: '@n0th3rp@55w0rd!'
중요

기본 ContainerImagePrepare 매개변수는 인증이 필요한 registry.redhat.io에서 컨테이너 이미지를 가져옵니다.

자세한 내용은 Red Hat Container Registry Authentication 을 참조하십시오.

ContainerImageRegistryLogin

ContainerImageRegistryLogin 매개변수는 오버클라우드 노드 시스템이 컨테이너 이미지를 가져오기 위해 원격 레지스트리에 로그인해야 하는지 여부를 제어하는 데 사용합니다. 이러한 상황은 오버클라우드 노드에서 이미지를 호스팅하는 데 언더클라우드를 사용하는 대신 이미지를 직접 가져오도록 할 때 발생합니다.

지정된 설정에 대해 push_destination이 구성되지 않은 경우 ContainerImageRegistryLogintrue로 설정해야 합니다.

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: false
    set:
      namespace: registry.redhat.io/...
      ...
  ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      myuser: 'p@55w0rd!'
  ContainerImageRegistryLogin: true

하지만 오버클라우드 노드에서 ContainerImageRegistryCredentials에 정의된 레지스트리 호스트에 네트워크로 연결할 수 없고 ContainerImageRegistryLogintrue로 설정하는 경우, 로그인할 때 배포에 실패할 수 있습니다. 오버클라우드 노드에서 ContainerImageRegistryCredentials에 정의된 레지스트리 호스트에 네트워크로 연결할 수 없고 push_destinationtrue로 설정하고 ContainerImageRegistryLoginfalse로 설정하여 오버클라우드 노드가 언더클라우드에서 이미지를 가져오도록 합니다.

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      namespace: registry.redhat.io/...
      ...
  ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      myuser: 'p@55w0rd!'
  ContainerImageRegistryLogin: false

7.7. 이미지 준비 항목 계층화

ContainerImagePrepare 매개변수의 값은 YAML 목록입니다. 즉, 여러 항목을 지정할 수 있습니다. 다음 예제에서는 두 개의 항목을 지정하는 경우를 설명합니다. 이때 director는 16.0-44로 태그된 버전을 사용하는 nova-api 이미지를 제외하고 모든 이미지의 최신 버전을 사용합니다.

ContainerImagePrepare:
- tag_from_label: "{version}-{release}"
  push_destination: true
  excludes:
  - nova-api
  set:
    namespace: registry.redhat.io/rhosp-rhel8
    name_prefix: openstack-
    name_suffix: ''
- push_destination: true
  includes:
  - nova-api
  set:
    namespace: registry.redhat.io/rhosp-rhel8
    tag: 16.2-44

includesexcludes 매개 변수는 정규식을 사용하여 각 항목에 대한 이미지 필터링을 제어합니다. includes 설정과 일치하는 이미지가 excludes와 일치하는 이미지보다 우선합니다. 일치하는 이미지로 간주되려면 이미지 이름에 includes 또는 excludes 정규식 값이 포함되어야 합니다.

7.8. 준비 과정에서 이미지 수정

이미지 준비 과정에서 이미지를 수정한 다음, 수정된 이미지로 오버클라우드를 즉시 배포할 수 있습니다.

참고

RHOSP(Red Hat OpenStack Platform) director는 Ceph 컨테이너가 아닌 RHOSP 컨테이너를 준비하는 동안 이미지 수정을 지원합니다.

이미지 수정 시나리오는 다음과 같습니다.

  • 지속적 통합 파이프라인에서 배포 전 테스트 중인 변경 사항으로 이미지가 수정되는 경우입니다.
  • 개발 워크플로우 중에 테스트 및 개발을 위해 로컬 변경 사항을 배포해야 하는 경우입니다.
  • 변경 사항을 배포해야 하지만 이미지 빌드 파이프라인을 통해 사용할 수 없는 경우입니다. 예를 들어 독점 애드온 또는 긴급 수정 사항을 추가할 수 있습니다.

준비 과정에서 이미지를 수정하려면, 수정할 각 이미지에 대해 Ansible 역할을 호출합니다. 이 역할은 소스 이미지를 가져와서 요청된 변경을 수행한 다음 그 결과를 태그합니다. prepare 명령으로 이미지를 대상 레지스트리로 푸시하고 수정된 이미지를 참조하도록 heat 매개변수를 설정할 수 있습니다.

Ansible 역할 tripleo-modify-image는 요청된 역할 인터페이스를 준수하고 수정 사용 사례에 필요한 작업을 수행합니다. ContainerImagePrepare 매개변수의 수정 관련 키를 사용하여 수정을 제어합니다.

  • modify_role은 수정할 각 이미지에 대해 호출할 Ansible 역할을 지정합니다.
  • modify_append_tag는 소스 이미지 태그의 끝에 문자열을 추가합니다. 이렇게 하면 결과 이미지가 수정되었음을 알 수 있습니다. push_destination 레지스트리에 수정된 이미지가 이미 포함되어 있을 경우 이 매개변수를 사용하여 수정을 생략할 수 있습니다. 이미지를 수정할 때마다 modify_append_tag를 변경하십시오.
  • modify_vars는 역할에 전달할 Ansible 변수로 이루어진 사전입니다.

tripleo-modify-image 역할에서 처리할 사용 케이스를 선택하려면 tasks_from 변수를 해당 역할에 필요한 파일로 설정합니다.

이미지를 수정하려면 ContainerImagePrepare 항목을 개발하고 테스트하는 동안 추가 옵션 없이 image prepare 명령을 실행하여 이미지가 예상대로 수정되는지 확인합니다.

sudo openstack tripleo container image prepare \
  -e ~/containers-prepare-parameter.yaml
중요

openstack tripleo container image prepare 명령을 사용하려면 언더클라우드에 실행 중인 image-serve 레지스트리가 포함되어야 합니다. 따라서 image-serve 레지스트리가 설치되지 않으므로 새 언더클라우드를 설치하기 전에 이 명령을 실행할 수 없습니다. 언더클라우드를 성공적으로 설치한 후 이 명령을 실행할 수 있습니다.

7.9. 컨테이너 이미지의 기존 패키지 업데이트

참고

RHOSP(Red Hat OpenStack Platform) director는 Ceph 컨테이너가 아닌 RHOSP 컨테이너의 컨테이너 이미지의 기존 패키지 업데이트를 지원합니다.

절차

  • 다음 예제 ContainerImagePrepare 항목은 언더클라우드 호스트의 dnf 리포지토리 구성을 사용하여 컨테이너 이미지의 모든 패키지에서 업데이트됩니다.

    ContainerImagePrepare:
    - push_destination: true
      ...
      modify_role: tripleo-modify-image
      modify_append_tag: "-updated"
      modify_vars:
        tasks_from: yum_update.yml
        compare_host_packages: true
        yum_repos_dir_path: /etc/yum.repos.d
      ...

7.10. 컨테이너 이미지에 추가 RPM 파일 설치

컨테이너 이미지에 RPM 파일 디렉터리를 설치할 수 있습니다. 이 기능은 핫픽스, 로컬 패키지 빌드 또는 패키지 리포지토리를 통해 사용할 수 없는 패키지를 설치하는 데 유용합니다.

참고

RHOSP(Red Hat OpenStack Platform) director는 Ceph 컨테이너가 아닌 RHOSP 컨테이너의 컨테이너 이미지에 추가 RPM 파일을 설치할 수 있도록 지원합니다.

절차

  • 다음 예제 ContainerImagePrepare 항목은 nova-compute 이미지에만 일부 핫픽스 패키지를 설치합니다.

    ContainerImagePrepare:
    - push_destination: true
      ...
      includes:
      - nova-compute
      modify_role: tripleo-modify-image
      modify_append_tag: "-hotfix"
      modify_vars:
        tasks_from: rpm_install.yml
        rpms_path: /home/stack/nova-hotfix-pkgs
      ...

7.11. 사용자 지정 Dockerfile을 사용하여 컨테이너 이미지 수정

Dockerfile이 포함된 디렉터리를 지정하여 필요한 변경을 수행할 수 있습니다. tripleo-modify-image 역할을 호출하면 FROM 지시문을 변경하고 LABEL 지시문을 추가하는 Dockerfile.modified 파일이 생성됩니다.

참고

RHOSP(Red Hat OpenStack Platform) director는 Ceph 컨테이너가 아닌 RHOSP 컨테이너의 사용자 지정 Dockerfile을 사용하여 컨테이너 이미지 수정을 지원합니다.

절차

  1. 다음 예제에서는 nova-compute 이미지에 대해 사용자 지정 Dockerfile을 실행합니다.

    ContainerImagePrepare:
    - push_destination: true
      ...
      includes:
      - nova-compute
      modify_role: tripleo-modify-image
      modify_append_tag: "-hotfix"
      modify_vars:
        tasks_from: modify_image.yml
        modify_dir_path: /home/stack/nova-custom
      ...
  2. /home/stack/nova-custom/Dockerfile 파일의 예는 다음과 같습니다. USER root 지시문을 실행한 후에는 원본 이미지의 기본 사용자로 다시 전환해야 합니다.

    FROM registry.redhat.io/rhosp-rhel8/openstack-nova-compute:latest
    
    USER "root"
    
    COPY customize.sh /tmp/
    RUN /tmp/customize.sh
    
    USER "nova"

7.12. 벤더 플러그인 배포

일부 타사 하드웨어를 블록 스토리지 백엔드로 사용하려면 벤더 플러그인을 배포해야 합니다. 다음 예제에서는 Dell EMC 하드웨어를 블록 스토리지 백엔드로 사용하기 위해 벤더 플러그인을 배포하는 방법을 보여줍니다.

지원되는 백엔드 어플라이언스 및 드라이버에 대한 자세한 내용은 스토리지 가이드 의 타사 스토리지 공급자를 참조하십시오.

절차

  1. 오버클라우드의 새 컨테이너 이미지 파일을 생성합니다.

    $ sudo openstack tripleo container image prepare default \
        --local-push-destination \
        --output-env-file containers-prepare-parameter-dellemc.yaml
  2. containers-prepare-parameter-dellemc.yaml 파일을 편집합니다.
  3. 기본 Red Hat OpenStack Platform 컨테이너 이미지의 전략에 exclude 매개변수를 추가합니다. 벤더 컨테이너 이미지가 교체할 컨테이너 이미지를 제외하려면 이 매개변수를 사용합니다. 이 예에서 컨테이너 이미지는 cinder-volume 이미지입니다.

    parameter_defaults:
      ContainerImagePrepare:
        - push_destination: true
          excludes:
      	   - cinder-volume
          set:
            namespace: registry.redhat.io/rhosp-rhel8
            name_prefix: openstack-
            name_suffix: ''
            tag: 16.1
            ...
          tag_from_label: "{version}-{release}"
  4. 공급자 플러그인의 대체 컨테이너 이미지가 포함된 ContainerImagePrepare 매개변수에 새 전략을 추가합니다.

    parameter_defaults:
      ContainerImagePrepare:
        ...
        - push_destination: true
          includes:
            - cinder-volume
          set:
            namespace: registry.connect.redhat.com/dellemc
            name_prefix: openstack-
            name_suffix: -dellemc-rhosp16
            tag: 16.1-2
            ...
  5. registry.connect.redhat.com 레지스트리의 인증 세부 정보를 ContainerImageRegistryCredentials 매개변수에 추가합니다.

    parameter_defaults:
      ContainerImageRegistryCredentials:
        registry.redhat.io:
          [service account username]: [service account password]
        registry.connect.redhat.com:
          [service account username]: [service account password]
  6. containers-prepare-parameter-dellemc.yaml 파일을 저장합니다.
  7. openstack overcloud deploy 와 같은 모든 배포 명령을 사용하여 containers-prepare-parameter-dellemc.yaml 파일을 포함합니다.

    $ openstack overcloud deploy --templates
        ...
        -e containers-prepare-parameter-dellemc.yaml
        ...

    director가 오버클라우드를 배포할 때 오버클라우드는 표준 컨테이너 이미지 대신 벤더 컨테이너 이미지를 사용합니다.

    중요
    containers-prepare-parameter-dellemc.yaml 파일은 오버클라우드 배포의 표준 containers-prepare-parameter.yaml 파일을 대체합니다. 오버클라우드 배포에 표준 containers-prepare-parameter.yaml 파일을 포함하지 마십시오. 언더클라우드 설치 및 업데이트에 대한 표준 containers-prepare-parameter.yaml 파일을 유지합니다.

8장. 기본 네트워크 격리

특정 유형의 네트워크 트래픽을 격리하여 호스팅할 수 있도록 분리된 네트워크를 사용하도록 오버클라우드를 구성합니다. RHOSP(Red Hat OpenStack Platform)에는 이 네트워크 격리를 구성하는 데 사용할 수 있는 일련의 환경 파일이 포함되어 있습니다. 네트워킹 매개변수를 추가로 사용자 지정하려면 추가 환경 파일이 필요할 수도 있습니다.

  • 네트워크 격리(/usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml)를 활성화하는 데 사용할 수 있는 환경 파일입니다.

    참고

    director를 사용하여 RHOSP를 배포하기 전에 network-isolation.yamlnetwork-environment.yaml 파일은 Jinja2 형식으로만 제공되며 .j2.yaml 확장명이 있습니다. director는 배포 중에 이러한 파일을 .yaml 버전으로 렌더링합니다.

  • 네트워크 기본값(/usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml)을 구성하는 데 사용할 수 있는 환경 파일입니다.
  • IP 범위, 서브넷, 가상 IP 등의 네트워크 설정을 정의하는 데 사용할 수 있는 network _data 파일입니다. 이 예에서는 기본값의 복사본을 생성하고 자체 네트워크에 맞게 편집하는 방법을 보여줍니다.
  • 각 노드의 NIC 레이아웃을 정의하는 데 사용할 수 있는 템플릿입니다. 오버클라우드 코어 템플릿 컬렉션에는 다양한 사용 사례에 대한 기본값 세트가 포함되어 있습니다.
  • NIC를 활성화하는 데 사용할 수 있는 환경 파일입니다. 이 예에서는 environment 디렉터리에 있는 기본 파일을 사용합니다.

8.1. 네트워크 격리

Overcloud는 기본적으로 provisioning 네트워크에 서비스를 할당합니다. 그러나 director는 오버클라우드 네트워크 트래픽을 격리된 네트워크로 나눌 수 있습니다. 분리된 네트워크를 사용하기 위해 오버클라우드에는 이 기능을 활성화하는 환경 파일이 포함되어 있습니다. 코어 heat 템플릿의 environments/network-isolation.j2.yaml 파일은 구성 가능한 네트워크 파일에 있는 각 네트워크의 모든 포트 및 VIP를 정의하는 Jinja2 파일입니다. 렌더링되면 network-isolation.yaml 파일이 전체 리소스 레지스트리와 동일한 위치에 생성됩니다.

resource_registry:
  # networks as defined in network_data.yaml
  OS::TripleO::Network::Storage: ../network/storage.yaml
  OS::TripleO::Network::StorageMgmt: ../network/storage_mgmt.yaml
  OS::TripleO::Network::InternalApi: ../network/internal_api.yaml
  OS::TripleO::Network::Tenant: ../network/tenant.yaml
  OS::TripleO::Network::External: ../network/external.yaml

  # Port assignments for the VIPs
  OS::TripleO::Network::Ports::StorageVipPort: ../network/ports/storage.yaml
  OS::TripleO::Network::Ports::StorageMgmtVipPort: ../network/ports/storage_mgmt.yaml
  OS::TripleO::Network::Ports::InternalApiVipPort: ../network/ports/internal_api.yaml
  OS::TripleO::Network::Ports::ExternalVipPort: ../network/ports/external.yaml
  OS::TripleO::Network::Ports::RedisVipPort: ../network/ports/vip.yaml

  # Port assignments by role, edit role definition to assign networks to roles.
  # Port assignments for the Controller
  OS::TripleO::Controller::Ports::StoragePort: ../network/ports/storage.yaml
  OS::TripleO::Controller::Ports::StorageMgmtPort: ../network/ports/storage_mgmt.yaml
  OS::TripleO::Controller::Ports::InternalApiPort: ../network/ports/internal_api.yaml
  OS::TripleO::Controller::Ports::TenantPort: ../network/ports/tenant.yaml
  OS::TripleO::Controller::Ports::ExternalPort: ../network/ports/external.yaml

  # Port assignments for the Compute
  OS::TripleO::Compute::Ports::StoragePort: ../network/ports/storage.yaml
  OS::TripleO::Compute::Ports::InternalApiPort: ../network/ports/internal_api.yaml
  OS::TripleO::Compute::Ports::TenantPort: ../network/ports/tenant.yaml

  # Port assignments for the CephStorage
  OS::TripleO::CephStorage::Ports::StoragePort: ../network/ports/storage.yaml
  OS::TripleO::CephStorage::Ports::StorageMgmtPort: ../network/ports/storage_mgmt.yaml

이 파일의 첫 번째 섹션에는 OS::TripleO::Network::* 리소스에 대한 리소스 레지스트리 선언이 있습니다. 기본적으로 이러한 리소스는 네트워크를 생성하지 않는 OS::Heat::None 리소스 유형을 사용합니다. 이러한 리소스를 각 네트워크의 YAML 파일로 리디렉션하면 이러한 네트워크를 생성할 수 있습니다.

다음 여러 섹션에서는 각 역할의 노드의 IP 주소를 생성합니다. 컨트롤러 노드에는 각 네트워크에 IP가 있습니다. 계산 및 스토리지 노드에는 각각 네트워크의 하위 집합에 IP가 있습니다.

9장. 사용자 지정 구성 가능 네트워크10장. 사용자 정의 네트워크 인터페이스 템플릿 과 같은 기타 오버클라우드 네트워킹 기능은 network-isolation.yaml 환경 파일을 사용합니다. 따라서 배포 명령에 렌더링된 환경 파일을 포함해야 합니다.

$ openstack overcloud deploy --templates \
    ...
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
    ...

8.2. 격리된 네트워크 구성 수정

기본 network_data.yaml 파일을 복사하고 복사본을 수정하여 기본 격리된 네트워크를 구성합니다.

절차

  1. 기본 network_data.yaml 파일을 복사합니다.

    $ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.
  2. network_data.yaml 파일의 로컬 사본을 편집하고 네트워킹 요구 사항에 맞게 매개변수를 수정합니다. 예를 들어 내부 API 네트워크에는 다음과 같은 기본 네트워크 세부 정보가 포함되어 있습니다.

    - name: InternalApi
      name_lower: internal_api
      vip: true
      vlan: 201
      ip_subnet: '172.16.2.0/24'
      allocation_pools: [{'start': '172.16.2.4', 'end': '172.16.2.250'}]

각 네트워크에 대해 다음 값을 편집합니다.

  • VLAN은 이 네트워크에 사용할 VLAN ID를 정의합니다.
  • ip_subnetip_allocation_pools 는 네트워크의 기본 서브넷 및 IP 범위를 설정합니다.
  • 게이트웨이는 네트워크의 게이트웨이를 설정합니다. 이 값을 사용하여 외부 네트워크의 기본 경로를 정의하거나 필요한 경우 다른 네트워크에 정의합니다.

n 옵션을 사용하여 배포와 함께 사용자 지정 network_data.yaml 파일을 포함합니다. n 옵션을 사용하지 않으면 배포 명령에서 기본 네트워크 세부 정보를 사용합니다.

8.3. 네트워크 인터페이스 템플릿

Overcloud 네트워크 설정에는 네트워크 인터페이스 템플릿 집합이 필요합니다. 이러한 템플릿은 YAML 형식의 표준 heat 템플릿입니다. 각 역할에는 director가 해당 역할 내의 각 노드를 올바르게 구성할 수 있도록 NIC 템플릿이 필요합니다.

모든 NIC 템플릿에는 표준 heat 템플릿과 동일한 섹션이 포함됩니다.

heat_template_version
사용할 구문 버전입니다.
description
템플릿의 문자열 설명입니다.
parameters
템플릿에 포함할 네트워크 매개 변수입니다.
resources
매개 변수에 정의된 매개 변수를 사용하여 네트워크 구성 스크립트에 적용합니다.
출력
구성에 사용되는 최종 스크립트를 렌더링합니다.

/usr/share/openstack-tripleo-heat-templates/network/config 의 기본 NIC 템플릿은 Jinja2 구문을 사용하여 템플릿을 렌더링합니다. 예를 들어 single-nic-vlans 구성의 다음 코드 조각은 각 네트워크에 대해 일련의 VLAN을 렌더링합니다.

{%- for network in networks if network.enabled|default(true) and network.name in role.networks %}
- type: vlan
  vlan_id:
    get_param: {{network.name}}NetworkVlanID
  addresses:
  - ip_netmask:
      get_param: {{network.name}}IpSubnet
{%- if network.name in role.default_route_networks %}

기본 컴퓨팅 노드의 경우 스토리지, 내부 API 및 테넌트 네트워크에 대한 네트워크 정보만 렌더링합니다.

- type: vlan
  vlan_id:
    get_param: StorageNetworkVlanID
  device: bridge_name
  addresses:
  - ip_netmask:
      get_param: StorageIpSubnet
- type: vlan
  vlan_id:
    get_param: InternalApiNetworkVlanID
  device: bridge_name
  addresses:
  - ip_netmask:
      get_param: InternalApiIpSubnet
- type: vlan
  vlan_id:
    get_param: TenantNetworkVlanID
  device: bridge_name
  addresses:
  - ip_netmask:
      get_param: TenantIpSubnet

10장. 사용자 정의 네트워크 인터페이스 템플릿 기본 Jinja2 기반 템플릿을 표준 YAML 버전으로 렌더링하는 방법을 살펴봅니다. 사용자 지정의 기준으로 사용할 수 있습니다.

8.4. 기본 네트워크 인터페이스 템플릿

director에는 대부분의 일반적인 네트워크 시나리오에 맞게 /usr/share/openstack-tripleo-heat-templates/network/config/ 에 템플릿이 포함되어 있습니다. 다음 표에서는 템플릿을 활성화하는 데 사용해야 하는 각 NIC 템플릿 세트와 해당 환경 파일을 간략하게 설명합니다.

참고

NIC 템플릿을 활성화하는 각 환경 파일은 접미사 .j2.yaml 을 사용합니다. 렌더링되지 않은 Jinja2 버전입니다. 배포에 .yaml 접미사를 사용하는 렌더링된 파일 이름을 포함해야 합니다.

NIC 디렉토리설명환경 파일

single-nic-vlans

컨트롤플레인 및 VLAN이 기본 Open vSwitch 브리지에 연결된 단일 NIC(nic1).

environments/net-single-nic-with-vlans.j2.yaml

single-nic-linux-bridge-vlans

기본 Linux 브리지에컨트롤플레인 및 VLAN이 연결된 단일 NIC(nic1)입니다.

environments/net-single-nic-linux-bridge-with-vlans

bond-with-vlans

nic1 에 연결된 컨트롤 플레인. 본딩된 NIC 구성(nic2 및 nic 3) 및 연결된 VLAN이 있는기본 Open vSwitch 브리지.

environments/net-bond-with-vlans.yaml

multiple-nics

nic1 에 연결된 컨트롤 플레인. 순차적으로 각 NIC를 network_data.yaml 파일에 정의된 각 네트워크에 할당합니다. 기본적으로 Storage to nic2, Storage Management to nic3, Internal API to nic4, br-tenant 브리지에서 nic5 에 테넌트, 기본 Open vSwitch 브리지에서 nic6 으로 외부입니다.

environments/net-multiple-nics.yaml

참고

외부 네트워크 없이 오버클라우드를 배포하기 위한 환경 파일(예: net-bond-with-vlans-no-external.yaml ) 및 IPv6 배포(예: net-bond-with-vlans-v6.yaml ). 이러한 인터페이스는 이전 버전과의 호환성을 위해 제공되며 구성 가능한 네트워크에서 작동하지 않습니다.

각 기본 NIC 템플릿 세트에는 role.role.j2.yaml 템플릿이 포함되어 있습니다. 이 파일은 Jinja2를 사용하여 구성 가능 역할에 대한 추가 파일을 렌더링합니다. 예를 들어 오버클라우드에서 Compute, Controller 및 Ceph Storage 역할을 사용하는 경우 배포에서 다음 템플릿과 같이 role.role.j2.yaml 을 기반으로 새 템플릿을 렌더링합니다.

  • compute.yaml
  • controller.yaml
  • ceph-storage.yaml.

8.5. 기본 네트워크 격리 활성화

director에는 기본 네트워크 분리를 활성화하는 데 사용할 수 있는 템플릿이 포함되어 있습니다. 이러한 파일은 /usr/share/openstack-tripleo-heat-templates/environments 다이렉토리에 있습니다. 예를 들어 템플릿을 사용하여 기본 네트워크 격리가 있는 VLAN이 있는 단일 NIC에 오버클라우드를 배포할 수 있습니다. 이 시나리오에서는 net-single-nic-with-vlans 템플릿을 사용합니다.

절차

  1. openstack overcloud deploy 명령을 실행할 때 다음과 같은 렌더링된 환경 파일을 포함해야 합니다.

    • 사용자 지정 network_data.yaml 파일입니다.
    • 렌더링된 기본 네트워크 격리 파일의 이름입니다.
    • 렌더링된 기본 네트워크 환경 파일의 파일 이름입니다.
    • 렌더링된 기본 네트워크 인터페이스 구성 파일의 파일 이름입니다.
    • 구성과 관련된 추가 환경 파일입니다.

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

$ openstack overcloud deploy --templates \
    ...
    -n /home/stack/network_data.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \
    ...

9장. 사용자 지정 구성 가능 네트워크

다른 네트워크에서 특정 네트워크 트래픽을 호스팅하려는 경우 사용자 지정 구성 가능 네트워크를 생성할 수 있습니다. 추가 구성 가능 네트워크를 사용하여 오버클라우드를 구성하려면 다음 파일과 템플릿을 구성해야 합니다.

  • 네트워크 격리를 활성화하는 환경 파일(/usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml).
  • 네트워크 기본값(/usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml)을 구성하는 환경 파일입니다.
  • 기본값 외부에 추가 네트워크를 생성하는 사용자 지정 network_data 파일.
  • 역할에 사용자 지정 네트워크를 할당할 사용자 지정 roles_data 파일입니다.
  • 각 노드의 NIC 레이아웃을 정의하는 템플릿입니다. 오버클라우드 코어 템플릿 컬렉션에는 다양한 사용 사례에 대한 기본값 세트가 포함되어 있습니다.
  • NIC를 활성화하는 환경 파일입니다. 이 예에서는 환경 디렉터리에 있는 기본 파일을 사용합니다.
  • 네트워킹 매개 변수를 사용자 지정할 추가 환경 파일입니다. 이 예에서는 환경 파일을 사용하여 구성 가능한 네트워크에 대한 OpenStack 서비스 매핑을 사용자 지정합니다.
참고

이전 목록의 일부 파일은 Jinja2 형식 파일이며 .j2.yaml 확장자가 있습니다. director는 배포 중에 이러한 파일을 .yaml 버전으로 렌더링합니다.

9.1. 구성 가능 네트워크

오버클라우드는 기본적으로 다음 사전 정의된 네트워크 세그먼트 세트를 사용합니다.

  • 컨트롤 플레인
  • 내부 API
  • 스토리지
  • 스토리지 관리
  • 테넌트
  • 외부
  • 관리 (선택 사항)

구성 가능 네트워크를 사용하여 다양한 서비스의 네트워크를 추가할 수 있습니다. 예를 들어 NFS 트래픽 전용 네트워크가 있는 경우 여러 역할에 제공할 수 있습니다.

director는 배포 및 업데이트 단계에서 사용자 지정 네트워크 생성을 지원합니다. 이러한 추가 네트워크를 Ironic 베어 메탈 노드, 시스템 관리 또는 다양한 역할에 사용할 별도의 네트워크를 생성할 수 있습니다. 또한 트래픽이 네트워크 간에 라우팅되는 분할 배포를 위해 여러 네트워크 세트를 생성할 수도 있습니다.

단일 데이터 파일(network_data.yaml)은 배포할 네트워크 목록을 관리합니다. n 옵션을 사용하여 이 파일을 배포 명령으로 포함합니다. 이 옵션이 없으면 배포 시 기본 /usr/share/openstack-tripleo-heat-templates/network_data.yaml 파일을 사용합니다.

9.2. 구성 가능 네트워크 추가

구성 가능 네트워크를 사용하여 다양한 서비스의 네트워크를 추가합니다. 예를 들어 스토리지 백업 트래픽 전용 네트워크가 있는 경우 네트워크를 여러 역할에 제공할 수 있습니다.

절차

  1. 기본 network_data.yaml 파일을 복사합니다.

    $ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.
  2. network_data.yaml 파일의 로컬 사본을 편집하고 새 네트워크의 섹션을 추가합니다.

    - name: StorageBackup
      name_lower: storage_backup
      vlan: 21
      vip: true
      ip_subnet: '172.21.1.0/24'
      allocation_pools: [{'start': '171.21.1.4', 'end': '172.21.1.250'}]
      gateway_ip: '172.21.1.1'

network_data.yaml 파일에서 다음 매개변수를 사용할 수 있습니다.

name
사람이 읽을 수 있는 네트워크의 이름을 설정합니다. 이 매개변수는 유일한 필수 매개변수입니다. name_lower 를 사용하여 가독성을 위해 이름을 표준화할 수도 있습니다. 예를 들어 InternalApiinternal_api 로 변경합니다.
name_lower
director가 roles_data.yaml 파일에서 역할에 할당된 해당 네트워크에 매핑하는 이름의 소문자를 설정합니다.
vlan
이 네트워크에 사용할 VLAN을 설정합니다.
vip: true
새 네트워크에 가상 IP 주소(VIP)를 만듭니다. 이 IP는Service-to-network 매핑 매개 변수(Service-to-network mapping 매개변수)에 나열된 서비스의 대상 IP로 사용됩니다. VIP는 Pacemaker를 사용하는 역할에서만 사용됩니다. Overcloud 부하 분산 서비스는 이러한 IP의 트래픽을 해당 서비스 엔드포인트로 리디렉션합니다.
ip_subnet
CIDR 형식으로 기본 IPv4 서브넷을 설정합니다.
allocation_pools
IPv4 서브넷의 IP 범위를 설정합니다.
gateway_ip
네트워크의 게이트웨이를 설정합니다.
routes

네트워크에 경로를 추가합니다. 추가 경로가 포함된 JSON 목록을 사용합니다. 각 목록 항목에는 사전 값 매핑이 포함되어 있습니다. 다음 예제 구문을 사용합니다.

  routes: [{'destination':'10.0.0.0/16', 'nexthop':'10.0.2.254'}]
subnets

이 네트워크 내에 속하는 라우팅된 추가 서브넷을 생성합니다. 이 매개 변수는 서브넷에 매핑된 값으로 라우팅된 서브넷의 소문자 이름을 키로, vlan,ip_subnet,allocation_poolsgateway_ip 매개 변수를 포함하는 dict 값을 허용합니다. 다음 예제는 이러한 레이아웃을 보여줍니다.

- name: StorageBackup
  name_lower: storage_backup
  vlan: 200
  vip: true
  ip_subnet: '172.21.0.0/24'
  allocation_pools: [{'start': '171.21.0.4', 'end': '172.21.0.250'}]
  gateway_ip: '172.21.0.1'
  subnets:
    storage_backup_leaf1:
      vlan: 201
      ip_subnet: '172.21.1.0/24'
      allocation_pools: [{'start': '171.21.1.4', 'end': '172.21.1.250'}]
      gateway_ip: '172.19.1.254'

이 매핑은 스파인 스트라이프 배포에서 일반적입니다. 자세한 내용은 Spine Leaf Networking 가이드를 참조하십시오.

n 옵션을 사용하여 배포 명령에 사용자 지정 network_data.yaml 파일을 포함합니다. n 옵션을 사용하지 않으면 배포 명령에서 기본 네트워크 집합을 사용합니다.

9.3. 역할에 구성 가능한 네트워크 포함

구성 가능 네트워크를 사용자 환경에 정의된 오버클라우드 역할에 할당할 수 있습니다. 예를 들어 Ceph Storage 노드에 사용자 지정 StorageBackup 네트워크를 포함할 수 있습니다.

절차

  1. 사용자 지정 roles_data.yaml 파일이 없는 경우 기본값을 홈 디렉터리에 복사합니다.

    $ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/.
  2. 사용자 지정 roles_data.yaml 파일을 편집합니다.
  3. 네트워크를 추가할 역할에 대한 네트워크 목록에 네트워크 이름을 포함합니다. 예를 들어 StorageBackup 네트워크를 Ceph Storage 역할에 추가하려면 다음 예제 스니펫을 사용합니다.

    - name: CephStorage
      description: |
        Ceph OSD Storage node role
      networks:
        - Storage
        - StorageMgmt
        - StorageBackup
  4. 사용자 지정 네트워크를 해당 역할에 추가한 후 파일을 저장합니다.

openstack overcloud deploy 명령을 실행할 때 -r 옵션을 사용하여 사용자 지정 roles_data.yaml 파일을 포함합니다. r 옵션을 사용하지 않으면 배포 명령은 해당 할당된 네트워크에 기본 역할 세트를 사용합니다.

9.4. 구성 가능한 네트워크에 OpenStack 서비스 할당

각 OpenStack 서비스는 리소스 레지스트리의 기본 네트워크 유형에 할당됩니다. 이러한 서비스는 네트워크 유형의 할당된 네트워크 내의 IP 주소에 바인딩됩니다. OpenStack 서비스는 이러한 네트워크 간에 나뉩니다. 실제 실제 네트워크는 네트워크 환경 파일에 정의된 대로 다를 수 있습니다. 환경 파일에서 새 네트워크 맵(예: /home/stack/templates/service-reassignments.yaml )을 정의하여 OpenStack 서비스를 다른 네트워크 유형에 다시 할당할 수 있습니다. ServiceNetMap 매개변수는 각 서비스에 사용할 네트워크 유형을 결정합니다.

예를 들어 강조 표시된 섹션을 수정하여 스토리지 관리 네트워크 서비스를 스토리지 백업 네트워크에 다시 할당할 수 있습니다.

parameter_defaults:
  ServiceNetMap:
    SwiftMgmtNetwork: storage_backup
    CephClusterNetwork: storage_backup

이러한 매개 변수를 storage_backup 으로 변경하면 Storage Management 네트워크 대신 Storage Backup 네트워크에 이러한 서비스가 배치됩니다. 즉, Storage Management 네트워크가 아닌 스토리지 백업 네트워크에 대해서만 parameter_defaults 세트를 정의해야 합니다.

director는 사용자 정의 ServiceNetMap 매개변수 정의를 ServiceNetMapDefaults 에서 가져온 기본값을 미리 정의된 목록으로 병합하고 기본값을 재정의합니다. director는 사용자 지정을 포함한 전체 목록을 다양한 서비스에 대한 네트워크 할당을 구성하는 데 사용되는 ServiceNetMap 에 반환합니다.

서비스 매핑은 Pacemaker를 사용하는 노드의 network_data.yaml 파일에서 vip: true 를 사용하는 네트워크에 적용됩니다. 오버클라우드 로드 밸런서는 VIP의 트래픽을 특정 서비스 엔드포인트로 리디렉션합니다.

참고

/usr/share/openstack-tripleo-heat-templates/network/service_net_map.j2.yaml 파일의 ServiceNetMapDefaults 매개변수에서 기본 서비스 전체 목록을 찾을 수 있습니다.

9.5. 사용자 지정 구성 가능 네트워크 활성화

기본 NIC 템플릿 중 하나를 사용하여 사용자 지정 구성 가능한 네트워크를 활성화합니다. 이 예제에서는 VLANs 템플릿(net-single-nic-with-vlans)과 함께 Single NIC를 사용합니다.

절차

  1. openstack overcloud deploy 명령을 실행할 때 다음 파일을 포함해야 합니다.

    • 사용자 지정 network_data.yaml 파일입니다.
    • 네트워크-역할 할당이 있는 사용자 지정 roles_data.yaml 파일
    • 기본 네트워크 격리의 렌더링된 파일 이름입니다.
    • 렌더링된 기본 네트워크 환경 파일의 파일 이름입니다.
    • 렌더링된 기본 네트워크 인터페이스 구성의 파일 이름입니다.
    • 서비스 재할당과 같은 네트워크 관련 추가 환경 파일.

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

$ openstack overcloud deploy --templates \
    ...
    -n /home/stack/network_data.yaml \
    -r /home/stack/roles_data.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \
    -e /home/stack/templates/service-reassignments.yaml \
    ...

이 예제 명령은 추가 사용자 지정 네트워크를 오버클라우드의 노드에 배포하는 구성 가능 네트워크를 배포합니다.

중요

관리 네트워크와 같은 새 사용자 지정 네트워크를 도입하는 경우 템플릿을 다시 렌더링해야 합니다. roles_data.yaml 파일에 네트워크 이름을 추가하는 것만으로는 충분하지 않습니다.

9.6. 기본 네트워크 이름 변경

network_data.yaml 파일을 사용하여 기본 네트워크의 사용자가 볼 수 있는 이름을 수정할 수 있습니다.

  • InternalApi
  • 외부
  • 스토리지
  • StorageMgmt
  • 테넌트

이러한 이름을 변경하려면 name 필드를 수정하지 마십시오. 대신 name_lower 필드를 네트워크의 새 이름으로 변경하고 새 이름으로 ServiceNetMap을 업데이트합니다.

절차

  1. network_data.yaml 파일에서 이름을 변경할 각 네트워크의 name_lower 매개변수에 새 이름을 입력합니다.

    - name: InternalApi
      name_lower: MyCustomInternalApi
  2. service_net_map _replace 매개변수에 name_ lower 매개변수의 기본값을 포함합니다.

    - name: InternalApi
      name_lower: MyCustomInternalApi
      service_net_map_replace: internal_api

10장. 사용자 정의 네트워크 인터페이스 템플릿

8장. 기본 네트워크 격리 를 구성한 후 환경의 노드에 맞게 사용자 정의 네트워크 인터페이스 템플릿 세트를 생성할 수 있습니다. 예를 들어 다음 파일을 포함할 수 있습니다.

  • 네트워크 격리를 활성화하는 환경 파일(/usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml).
  • 네트워크 기본값(/usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml)을 구성하는 환경 파일입니다.
  • 각 노드의 NIC 레이아웃을 정의하는 템플릿입니다. 오버클라우드 코어 템플릿 컬렉션에는 다양한 사용 사례에 대한 기본값 세트가 포함되어 있습니다. 사용자 지정 NIC 템플릿을 생성하려면 사용자 지정 템플릿의 기본 Jinja2 템플릿을 기본으로 렌더링합니다.
  • NIC를 활성화하는 사용자 지정 환경 파일입니다. 이 예에서는 사용자 지정 인터페이스 템플릿을 참조하는 사용자 지정 환경 파일(/home/stack/templates/custom-network-configuration.yaml)을 사용합니다.
  • 네트워킹 매개 변수를 사용자 지정할 추가 환경 파일입니다.
  • 네트워크를 사용자 지정하면 사용자 지정 network_data.yaml 파일입니다.
  • 추가 또는 사용자 지정 구성 가능한 네트워크, 사용자 지정 network_data.yaml 파일 및 사용자 지정 roles_data.yaml 파일을 생성하는 경우.
참고

이전 목록의 일부 파일은 Jinja2 형식 파일이며 .j2.yaml 확장자가 있습니다. director는 배포 중에 이러한 파일을 .yaml 버전으로 렌더링합니다.

10.1. 사용자 지정 네트워크 아키텍처

기본 NIC 템플릿이 특정 네트워크 구성에 적합하지 않을 수 있습니다. 예를 들어 특정 네트워크 레이아웃에 맞는 자체 사용자 지정 NIC 템플릿을 생성할 수 있습니다. 에서 제어 서비스와 데이터 서비스를 분리하여 NIC를 분리할 수 있습니다. 이 경우 다음과 같은 방식으로 서비스를 NIC 할당에 매핑할 수 있습니다.

  • NIC1 (프로비저닝)

    • 프로비저닝/컨트롤 플레인
  • NIC2 (Control Group)

    • 내부 API
    • 스토리지 관리
    • 외부(공용 API)
  • NIC3 (데이터 그룹)

    • 테넌트 네트워크(VXLAN 터널링)
    • 테넌트 VLAN/프로바이더 VLAN
    • 스토리지
    • 외부 VLAN (유동 IP/SNAT)
  • NIC4 (관리)

    • 관리

10.2. 사용자 정의를 위한 기본 네트워크 인터페이스 템플릿 렌더링

사용자 지정 인터페이스 템플릿 구성을 간소화하려면 기본 NIC 템플릿의 Jinja2 구문을 렌더링하고 사용자 지정 구성의 기반으로 렌더링된 템플릿을 사용합니다.

절차

  1. process-templates.py 스크립트를 사용하여 openstack-tripleo-heat-templates 컬렉션 사본을 렌더링합니다.

    $ cd /usr/share/openstack-tripleo-heat-templates
    $ ./tools/process-templates.py -o ~/openstack-tripleo-heat-templates-rendered

    이렇게 하면 모든 Jinja2 템플릿을 렌더링된 YAML 버전으로 변환하고 결과를 ~/openstack-tripleo-heat-templates-rendered에 저장합니다.

    사용자 지정 네트워크 파일 또는 사용자 지정 역할 파일을 사용하는 경우 각각 -n 및 - r 옵션을 사용하여 이러한 파일을 포함할 수 있습니다.

    $ ./tools/process-templates.py -o ~/openstack-tripleo-heat-templates-rendered -n /home/stack/network_data.yaml -r /home/stack/roles_data.yaml
  2. 여러 NIC 예제를 복사합니다.

    $ cp -r ~/openstack-tripleo-heat-templates-rendered/network/config/multiple-nics/ ~/templates/custom-nics/
  3. 사용자 지정 NIC의 템플릿을 편집하여 고유한 네트워크 구성에 맞게 템플릿 설정을 편집합니다.

10.3. 네트워크 인터페이스 아키텍처

10.2절. “사용자 정의를 위한 기본 네트워크 인터페이스 템플릿 렌더링” 에서 렌더링하는 사용자 정의 NIC 템플릿에는 매개변수리소스 섹션이 포함되어 있습니다.

매개 변수

parameters 섹션에는 네트워크 인터페이스에 대한 모든 네트워크 구성 매개 변수가 포함되어 있습니다. 여기에는 서브넷 범위 및 VLAN ID와 같은 정보가 포함됩니다. heat 템플릿이 상위 템플릿에서 값을 상속하므로 이 섹션은 변경되지 않은 상태로 유지됩니다. 그러나 네트워크 환경 파일을 사용하여 일부 매개 변수의 값을 수정할 수 있습니다.

Resources

resources 섹션은 기본 네트워크 인터페이스 구성이 발생하는 위치입니다. 대부분의 경우 resources 섹션은 수정이 필요한 유일한 섹션입니다. 각 resources 섹션은 다음 헤더로 시작합니다.

resources:
  OsNetConfigImpl:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template:
            get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh
          params:
            $network_config:
              network_config:

이 코드 조각은 노드에 네트워크 속성을 구성하는 데 사용할 os-net-config의 구성 파일을 생성하는 스크립트(run-os-net-config.sh)를 실행합니다. network_config 섹션에는 run-os-net-config.sh 스크립트로 전송된 사용자 지정 네트워크 인터페이스 데이터가 포함되어 있습니다. 이 사용자 지정 인터페이스 데이터를 장치 유형에 따라 시퀀스로 정렬합니다.

중요

사용자 지정 NIC 템플릿을 생성하는 경우 run-os-net-config.sh 스크립트 위치를 각 NIC 템플릿의 절대 경로로 설정해야 합니다. 이 스크립트는 언더클라우드의 /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh 에 있습니다.

10.4. 네트워크 인터페이스 참조

네트워크 인터페이스 구성에는 다음 매개변수가 포함됩니다.

인터페이스

단일 네트워크 인터페이스를 정의합니다. 구성은 실제 인터페이스 이름("eth0", "eth1", "enp0s25") 또는 번호가 매겨진 인터페이스("nic1", "nic2", "nic3")를 사용하여 각 인터페이스를 정의합니다.

  - type: interface
    name: nic2

표 10.1. 인터페이스 옵션

옵션Default설명

name

 

인터페이스 이름입니다.

use_dhcp

False

DHCP를 사용하여 IP 주소를 가져옵니다.

use_dhcpv6

False

DHCP를 사용하여 v6 IP 주소를 가져옵니다.

주소

 

인터페이스에 할당된 IP 주소 목록입니다.

routes

 

인터페이스에 할당된 경로 목록입니다. 자세한 내용은 routes의 내용을 참조하십시오.

mtu

1500

연결의 최대 전송 단위(MTU)입니다.

False

인터페이스를 기본 인터페이스로 정의합니다.

defroute

True

DHCP 서비스에서 제공하는 기본 경로를 사용합니다. use_dhcp 또는 use_dhcp v6 을 활성화하는 경우에만 적용됩니다.

persist_mapping

False

시스템 이름 대신 장치 별칭 구성을 작성합니다.

dhclient_args

없음

DHCP 클라이언트에 전달할 인수입니다.

dns_servers

없음

인터페이스에 사용할 DNS 서버 목록입니다.

ethtool_opts

 

특정 NIC에서 VXLAN을 사용할 때 처리량을 개선하기 위해 이 옵션을 "rx-flow-hash udp4 sdfn" 으로 설정합니다.

VLAN

VLAN을 정의합니다. parameters 섹션에서 전달된 VLAN ID 및 서브넷을 사용합니다.

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

  - type: vlan
    vlan_id:{get_param: ExternalNetworkVlanID}
    addresses:
      - ip_netmask: {get_param: ExternalIpSubnet}

표 10.2. VLAN 옵션

옵션Default설명

vlan_id

 

VLAN ID입니다.

장치

 

VLAN을 연결할 상위 장치입니다. VLAN이 OVS 브리지의 멤버가 아닌 경우 이 매개 변수를 사용합니다. 예를 들어 이 매개 변수를 사용하여 VLAN을 본딩된 인터페이스 장치에 연결합니다.

use_dhcp

False

DHCP를 사용하여 IP 주소를 가져옵니다.

use_dhcpv6

False

DHCP를 사용하여 v6 IP 주소를 가져옵니다.

주소

 

VLAN에 할당된 IP 주소 목록입니다.

routes

 

VLAN에 할당된 경로 목록입니다. 자세한 내용은 routes의 내용을 참조하십시오.

mtu

1500

연결의 최대 전송 단위(MTU)입니다.

False

VLAN을 기본 인터페이스로 정의합니다.

defroute

True

DHCP 서비스에서 제공하는 기본 경로를 사용합니다. use_dhcp 또는 use_dhcp v6 을 활성화하는 경우에만 적용됩니다.

persist_mapping

False

시스템 이름 대신 장치 별칭 구성을 작성합니다.

dhclient_args

없음

DHCP 클라이언트에 전달할 인수입니다.

dns_servers

없음

VLAN에 사용할 DNS 서버 목록입니다.

ovs_bond

두 개 이상의 인터페이스를 함께 결합할 Open vSwitch의 본딩을 정의합니다. 이는 이중화 및 대역폭 증가에 도움이 됩니다.

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

          - type: ovs_bond
            name: bond1
            members:
            - type: interface
              name: nic2
            - type: interface
              name: nic3

표 10.3. ovs_bond 옵션

옵션Default설명

name

 

본딩의 이름입니다.

use_dhcp

False

DHCP를 사용하여 IP 주소를 가져옵니다.

use_dhcpv6

False

DHCP를 사용하여 v6 IP 주소를 가져옵니다.

주소

 

본딩에 할당된 IP 주소 목록입니다.

routes

 

본딩에 할당된 경로 목록입니다. 자세한 내용은 routes의 내용을 참조하십시오.

mtu

1500

연결의 최대 전송 단위(MTU)입니다.

False

인터페이스를 기본 인터페이스로 정의합니다.

멤버

 

본딩에서 사용할 일련의 인터페이스 오브젝트입니다.

ovs_options

 

본딩을 만들 때 OVS에 전달할 옵션 집합입니다.

ovs_extra

 

본딩의 네트워크 구성 파일에서 OVS_EXTRA 매개 변수로 설정할 옵션 집합입니다.

defroute

True

DHCP 서비스에서 제공하는 기본 경로를 사용합니다. use_dhcp 또는 use_dhcp v6 을 활성화하는 경우에만 적용됩니다.

persist_mapping

False

시스템 이름 대신 장치 별칭 구성을 작성합니다.

dhclient_args

없음

DHCP 클라이언트에 전달할 인수입니다.

dns_servers

없음

본딩에 사용할 DNS 서버 목록입니다.

ovs_bridge

여러 인터페이스,ovs_bondvlan 오브젝트를 함께 연결하는 Open vSwitch에 브리지를 정의합니다.

네트워크 인터페이스 유형인 ovs_bridge 는 매개 변수 이름을 사용합니다.

참고

여러 브리지가 있는 경우 bridge _name의 기본 이름을 허용하는 것 이외의 고유한 브리지 이름을 사용해야 합니다. 고유한 이름을 사용하지 않으면 통합 단계에서 두 개의 네트워크 본딩이 동일한 브리지에 배치됩니다.

외부 tripleo 네트워크에 대한 OVS 브리지를 정의하는 경우 배포 프레임워크에서 이러한 값을 각각 외부 브리지 이름 및 외부 인터페이스 이름으로 교체하므로 bridge_name 및 interface_name 값을 유지합니다.

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

      - type: ovs_bridge
        name: bridge_name
        addresses:
        - ip_netmask:
            list_join:
            - /
            - - {get_param: ControlPlaneIp}
              - {get_param: ControlPlaneSubnetCidr}
        members:
          - type: interface
            name: interface_name
      - type: vlan
        device: bridge_name
        vlan_id:
          {get_param: ExternalNetworkVlanID}
        addresses:
          - ip_netmask:
              {get_param: ExternalIpSubnet}
참고

OVS 브리지는 네트워킹 서비스(neutron) 서버에 연결하여 구성 데이터를 가져옵니다. OpenStack 제어 트래픽(일반적으로 컨트롤 플레인 및 내부 API 네트워크가 OVS 브리지에 배치되는 경우, OVS를 업그레이드할 때마다 neutron 서버에 대한 연결이 끊어지거나 관리자 또는 프로세스에서 OVS 브리지를 다시 시작합니다. 이로 인해 다운타임이 발생할 수 있습니다. 이러한 상황에서 다운타임을 허용하지 않는 경우 OVS 브리지가 아닌 별도의 인터페이스 또는 본딩에 Control 그룹 네트워크를 배치해야 합니다.

  • 프로비저닝 인터페이스의 VLAN에 내부 API 네트워크를 배치하고 두 번째 인터페이스의 OVS 브리지에 내부 API 네트워크를 배치할 때 최소한의 설정을 달성할 수 있습니다.
  • 본딩을 구현하려면 최소한 두 개의 본딩(4개의 네트워크 인터페이스)이 필요합니다. Linux 본딩(Linux 브리지)에 제어 그룹을 배치합니다. 스위치에서 PXE 부팅을 위한 단일 인터페이스로 LACP 폴백을 지원하지 않는 경우 이 솔루션에는 최소 5개의 NIC가 필요합니다.

표 10.4. ovs_bridge options

옵션Default설명

name

 

브리지 이름입니다.

use_dhcp

False

DHCP를 사용하여 IP 주소를 가져옵니다.

use_dhcpv6

False

DHCP를 사용하여 v6 IP 주소를 가져옵니다.

주소

 

브리지에 할당된 IP 주소 목록입니다.

routes

 

브리지에 할당된 경로 목록입니다. 자세한 내용은 routes의 내용을 참조하십시오.

mtu

1500

연결의 최대 전송 단위(MTU)입니다.

멤버

 

브리지에서 사용하려는 일련의 인터페이스, VLAN 및 본딩 오브젝트입니다.

ovs_options

 

브리지를 만들 때 OVS에 전달할 옵션 집합입니다.

ovs_extra

 

브리지의 네트워크 구성 파일에서 OVS_EXTRA 매개 변수로 설정할 에 대한 옵션 집합입니다.

defroute

True

DHCP 서비스에서 제공하는 기본 경로를 사용합니다. use_dhcp 또는 use_dhcp v6 을 활성화하는 경우에만 적용됩니다.

persist_mapping

False

시스템 이름 대신 장치 별칭 구성을 작성합니다.

dhclient_args

없음

DHCP 클라이언트에 전달할 인수입니다.

dns_servers

없음

브리지에 사용할 DNS 서버 목록입니다.

linux_bond

두 개 이상의 인터페이스를 함께 결합하는 Linux 본딩을 정의합니다. 이는 이중화 및 대역폭 증가에 도움이 됩니다. bonding _options 매개변수에 커널 기반 본딩 옵션을 포함해야 합니다.

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

      - type: linux_bond
        name: bond1
        members:
        - type: interface
          name: nic2
          primary: true
        - type: interface
          name: nic3
        bonding_options: "mode=802.3ad"

nic2primary: true 를 사용하여 본딩에서 nic2 의 MAC 주소를 사용하는지 확인합니다.

표 10.5. linux_bond 옵션

옵션Default설명

name

 

본딩의 이름입니다.

use_dhcp

False

DHCP를 사용하여 IP 주소를 가져옵니다.

use_dhcpv6

False

DHCP를 사용하여 v6 IP 주소를 가져옵니다.

주소

 

본딩에 할당된 IP 주소 목록입니다.

routes

 

본딩에 할당된 경로 목록입니다. routes을 참조하십시오.

mtu

1500

연결의 최대 전송 단위(MTU)입니다.

False

인터페이스를 기본 인터페이스로 정의합니다.

멤버

 

본딩에서 사용할 일련의 인터페이스 오브젝트입니다.

bonding_options

 

본딩 생성 시 옵션 집합입니다.

defroute

True

DHCP 서비스에서 제공하는 기본 경로를 사용합니다. use_dhcp 또는 use_dhcp v6 을 활성화하는 경우에만 적용됩니다.

persist_mapping

False

시스템 이름 대신 장치 별칭 구성을 작성합니다.

dhclient_args

없음

DHCP 클라이언트에 전달할 인수입니다.

dns_servers

없음

본딩에 사용할 DNS 서버 목록입니다.

linux_bridge

여러 인터페이스,linux_bondvlan 오브젝트를 함께 연결하는 Linux 브리지를 정의합니다. 외부 브리지는 매개 변수에 두 개의 특수 값도 사용합니다.

  • bridge_name - 외부 브리지 이름으로 바뀝니다.
  • interface_name - 외부 인터페이스로 바뀝니다.

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

      - type: linux_bridge
        name: bridge_name
        addresses:
          - ip_netmask:
              list_join:
                - /
                - - {get_param: ControlPlaneIp}
                  - {get_param: ControlPlaneSubnetCidr}
        members:
          - type: interface
            name: interface_name
      - type: vlan
        device: bridge_name
        vlan_id:
          {get_param: ExternalNetworkVlanID}
        addresses:
          - ip_netmask:
              {get_param: ExternalIpSubnet}

표 10.6. linux_bridge options

옵션Default설명

name

 

브리지 이름입니다.

use_dhcp

False

DHCP를 사용하여 IP 주소를 가져옵니다.

use_dhcpv6

False

DHCP를 사용하여 v6 IP 주소를 가져옵니다.

주소

 

브리지에 할당된 IP 주소 목록입니다.

routes

 

브리지에 할당된 경로 목록입니다. 자세한 내용은 routes의 내용을 참조하십시오.

mtu

1500

연결의 최대 전송 단위(MTU)입니다.

멤버

 

브리지에서 사용하려는 일련의 인터페이스, VLAN 및 본딩 오브젝트입니다.

defroute

True

DHCP 서비스에서 제공하는 기본 경로를 사용합니다. use_dhcp 또는 use_dhcp v6 을 활성화하는 경우에만 적용됩니다.

persist_mapping

False

시스템 이름 대신 장치 별칭 구성을 작성합니다.

dhclient_args

없음

DHCP 클라이언트에 전달할 인수입니다.

dns_servers

없음

브리지에 사용할 DNS 서버 목록입니다.

routes

네트워크 인터페이스, VLAN, 브리지 또는 본딩에 적용할 경로 목록을 정의합니다.

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

  - type: interface
    name: nic2
    ...
    routes:
      - ip_netmask: 10.1.2.0/24
        default: true
        next_hop:
          get_param: EC2MetadataIp
옵션Default설명

ip_netmask

없음

대상 네트워크의 IP 및 넷마스크.

default

False

이 경로를 기본 경로로 설정합니다. ip_netmask 설정과 같습니다. 0.0.0.0/0.

next_hop

없음

대상 네트워크에 연결하는 데 사용되는 라우터의 IP 주소입니다.

10.5. 네트워크 인터페이스 레이아웃 예

컨트롤러 노드 NIC 템플릿 예제의 다음 코드 조각은 OVS 브리지와 별도로 제어 그룹을 유지하도록 사용자 지정 네트워크 시나리오를 구성하는 방법을 보여줍니다.

resources:
  OsNetConfigImpl:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template:
            get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh
          params:
            $network_config:
              network_config:

              # NIC 1 - Provisioning
              - type: interface
                name: nic1
                use_dhcp: false
                addresses:
                - ip_netmask:
                    list_join:
                    - /
                    - - get_param: ControlPlaneIp
                      - get_param: ControlPlaneSubnetCidr
                routes:
                - ip_netmask: 169.254.169.254/32
                  next_hop:
                    get_param: EC2MetadataIp

              # NIC 2 - Control Group
              - type: interface
                name: nic2
                use_dhcp: false
              - type: vlan
                device: nic2
                vlan_id:
                  get_param: InternalApiNetworkVlanID
                addresses:
                - ip_netmask:
                    get_param: InternalApiIpSubnet
              - type: vlan
                device: nic2
                vlan_id:
                  get_param: StorageMgmtNetworkVlanID
                addresses:
                - ip_netmask:
                    get_param: StorageMgmtIpSubnet
              - type: vlan
                device: nic2
                vlan_id:
                  get_param: StorageNetworkVlanID
                addresses:
                - ip_netmask:
                    get_param: StorageIpSubnet

              # NIC 3 - Data Group
              - type: ovs_bridge
                name: bridge_name
                dns_servers:
                  get_param: DnsServers
                members:
                - type: interface
                  name: nic3
                  primary: true
                - type: vlan
                  vlan_id:
                    get_param: ExternalNetworkVlanID
                  addresses:
                  - ip_netmask:
                      get_param: ExternalIpSubnet
                  routes:
                  - default: true
                    next_hop:
                      get_param: ExternalInterfaceDefaultRoute
                - type: vlan
                  vlan_id:
                    get_param: TenantNetworkVlanID
                  addresses:
                  - ip_netmask:
                      get_param: TenantIpSubnet

                # NIC 4 - Management
                - type: interface
                  name: nic4
                  use_dhcp: false
                  addresses:
                  - ip_netmask: {get_param: ManagementIpSubnet}
                  routes:
                  - default: true
                    next_hop: {get_param: ManagementInterfaceDefaultRoute}

이 템플릿은 4개의 네트워크 인터페이스를 사용하고 번호가 매겨진 인터페이스인 nic1을 nic 4 에 할당합니다. nic3 에서 이 템플릿은 Storage 및 Tenant 네트워크를 호스팅하는 OVS 브리지를 만듭니다. 결과적으로 다음과 같은 레이아웃이 생성됩니다.

  • NIC1 (프로비저닝)

    • 프로비저닝/컨트롤 플레인
  • NIC2 (Control Group)

    • 내부 API
    • 스토리지
    • 스토리지 관리
  • NIC3 (데이터 그룹)

    • 테넌트 네트워크(VXLAN 터널링)
    • 테넌트 VLAN/프로바이더 VLAN
    • 외부(공용 API)
    • 외부 VLAN (유동 IP/SNAT)
  • NIC4 (관리)

    • 관리

10.6. 사용자 지정 네트워크의 네트워크 인터페이스 템플릿 고려 사항

구성 가능 네트워크를 사용하는 경우 process-templates.py 스크립트는 정적 템플릿을 렌더링하여 network_data.yaml 및 roles _data. yaml 파일에 정의된 네트워크 및 역할을 포함합니다. 렌더링된 NIC 템플릿에 다음 항목이 포함되어 있는지 확인합니다.

  • 사용자 지정 구성 가능 네트워크를 포함하여 각 역할에 대한 정적 파일입니다.
  • 각 역할의 정적 파일에서 올바른 네트워크 정의.

각 정적 파일에는 네트워크가 역할에 사용되지 않더라도 사용자 지정 네트워크의 모든 매개 변수 정의가 필요합니다. 렌더링된 템플릿에 이러한 매개변수가 포함되어 있는지 확인합니다. 예를 들어 Ceph 노드에만 StorageBackup 네트워크를 추가하는 경우 모든 역할에 대한 NIC 구성 템플릿의 parameters 섹션에 이 정의도 포함해야 합니다.

parameters:
  ...
  StorageBackupIpSubnet:
    default: ''
    description: IP address/subnet on the external network
    type: string
  ...

필요한 경우 VLAN ID 및/또는 게이트웨이 IP에 대한 매개변수 정의를 포함할 수도 있습니다.

parameters:
  ...
  StorageBackupNetworkVlanID:
    default: 60
    description: Vlan ID for the management network traffic.
    type: number
  StorageBackupDefaultRoute:
	  description: The default route of the storage backup network.
	  type: string
  ...

사용자 지정 네트워크의 IpSubnet 매개변수는 각 역할의 매개 변수 정의에 표시됩니다. 그러나 Ceph 역할이 StorageBackup 네트워크를 사용하는 유일한 역할일 수 있으므로, Ceph 역할의 NIC 구성 템플릿만 템플릿의 network_config 섹션에 있는 StorageBackup 매개 변수를 사용합니다.

      $network_config:
        network_config:
        - type: interface
          name: nic1
          use_dhcp: false
          addresses:
          - ip_netmask:
              get_param: StorageBackupIpSubnet

10.7. 사용자 지정 네트워크 환경 파일

사용자 지정 네트워크 환경 파일(이 경우 /home/stack/templates/custom-network-configuration.yaml)은 Overcloud 네트워크 환경을 설명하고 사용자 지정 네트워크 인터페이스 구성 템플릿을 가리키는 heat 환경 파일입니다. IP 주소 범위와 함께 네트워크의 서브넷 및 VLAN을 정의할 수 있습니다. 그런 다음 로컬 환경에 대해 이러한 값을 사용자 지정할 수 있습니다.

resource_registry 섹션에는 각 노드 역할에 대한 사용자 지정 네트워크 인터페이스 템플릿에 대한 참조가 포함되어 있습니다. 등록된 각 리소스는 다음 형식을 사용합니다.

  • OS::TripleO::[ROLE]::Net::SoftwareConfig: [FILE]

[ROLE] 은 역할 이름이고 [FILE] 은 해당 특정 역할에 대한 각 네트워크 인터페이스 템플릿입니다. 예를 들면 다음과 같습니다.

resource_registry:
  OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/custom-nics/controller.yaml

parameter_defaults 섹션에는 각 네트워크 유형에 대한 네트워크 옵션을 정의하는 매개 변수 목록이 포함되어 있습니다.

10.8. 네트워크 환경 매개변수

다음 표는 네트워크 환경 파일의 parameter_defaults 섹션에서 NIC 템플릿의 기본 매개변수 값을 재정의하는 데 사용할 수 있는 매개변수 목록입니다.

매개변수설명유형

ControlPlaneDefaultRoute

컨트롤러 노드 이외의 역할에 대한 기본 경로로 사용되는 컨트롤 플레인의 라우터 IP 주소입니다. 라우터 대신 IP masquerade를 사용하는 경우 이 값을 언더클라우드 IP로 설정합니다.

string

ControlPlaneSubnetCidr

컨트롤 플레인에서 사용되는 IP 네트워크의 CIDR 넷마스크입니다. 컨트롤 플레인 네트워크에서 192.168.24.0/24를 사용하는 경우 CIDR은 24 입니다.

문자열 (항상 숫자임)

*NetCidr

특정 네트워크의 전체 네트워크 및 CIDR 넷마스크. 기본값은 network_ data.yaml 파일에서 ip_subnet 네트워크 설정으로 자동 설정됩니다. 예: InternalApiNetCidr: 172.16.0.0/24.

string

*AllocationPools

특정 네트워크의 IP 할당 범위입니다. 기본값은 network_ data.yaml 파일에서 네트워크 allocation_ pools 설정으로 자동 설정됩니다. 예를 들면 InternalApiAllocationPools: [{'start'입니다. '172.16.0.10', 'end': '172.16.0.200'}].

해시

*NetworkVlanID

특정 네트워크의 노드의 VLAN ID입니다. 기본값은 network _data.yaml 파일에서 vlan 네트워크 설정으로 자동 설정됩니다. 예를 들면 InternalApiNetworkVlanID입니다. 201.

숫자

*InterfaceDefaultRoute

역할 또는 다른 네트워크 경로에 대한 기본 경로로 사용할 수 있는 특정 네트워크의 라우터 주소입니다. 기본값은 network_ data.yaml 파일에서 네트워크 gateway_ ip 설정으로 자동 설정됩니다. 예를 들면 InternalApiInterfaceDefaultRoute입니다. 172.16.0.1.

string

DnsServers

resolv.conf에 추가된 DNS 서버 목록입니다. 일반적으로 최대 2대의 서버를 허용합니다.

쉼표로 구분된 목록

EC2MetadataIp

Overcloud 노드를 프로비저닝하는 데 사용되는 메타데이터 서버의 IP 주소입니다. 이 값을 컨트롤 플레인에 있는 언더클라우드의 IP 주소로 설정합니다.

string

BondInterfaceOvsOptions

본딩 인터페이스에 대한 옵션. 예를 들어 BondInterfaceOvsOptions: "bond_mode=balance-slb" 입니다.

string

NeutronExternalNetworkBridge

OpenStack Networking(neutron)에 사용할 외부 브리지 이름의 레거시 값입니다. 이 값은 기본적으로 비어 있습니다. 즉 NeutronBridgeMappings 에서 여러 개의 물리 브리지를 정의할 수 있습니다. 정상적인 상황에서는 이 값을 재정의하지 마십시오.

string

NeutronFlatNetworks

neutron 플러그인에서 구성할 플랫 네트워크를 정의합니다. 기본값은 외부 네트워크 생성을 허용하는 datacentre 입니다. 예를 들어 NeutronFlatNetworks: "datacentre ".

string

NeutronBridgeMappings

사용하려는 논리적 브릿지와 물리적 브리지 매핑. 기본값은 호스트(br-ex)의 외부 브리지를 물리적 이름(datacentre)에 매핑합니다. OpenStack Networking(neutron) 프로바이더 네트워크 또는 유동 IP 네트워크를 생성할 때 논리 이름을 참조하십시오. 예를 들어 NeutronBridgeMappings: "datacentre:br-ex,tenant:br-tenant ".

string

NeutronPublicInterface

네트워크 분리를 사용하지 않을 때 네트워크 노드의 br-ex 에 브리지할 인터페이스를 정의합니다. 일반적으로 두 개의 네트워크만 있는 소규모 배포에서는 사용되지 않습니다. 예를 들면 다음과 같습니다. NeutronPublicInterface: "eth0".

string

NeutronNetworkType

OpenStack Networking(neutron)의 테넌트 네트워크 유형입니다. 여러 값을 지정하려면 쉼표로 구분된 목록을 사용합니다. 지정한 첫 번째 유형은 사용 가능한 모든 네트워크가 모두 사용될 때까지 사용되는 다음 유형이 사용됩니다. 예를 들어 NeutronNetworkType: "vxlan" 입니다. vxlan은 기본 ML2 메커니즘 드라이버인 ML2/OVN 메커니즘 드라이버에서 지원하지 않습니다.

string

NeutronTunnelTypes

neutron 테넌트 네트워크의 터널 유형입니다. 여러 값을 지정하려면 쉼표로 구분된 문자열을 사용합니다. 예를 들어 NeutronTunnelTypes: 'gre,vxlan' 입니다. vxlan은 기본 ML2 메커니즘 드라이버인 ML2/OVN 메커니즘 드라이버에서 지원하지 않습니다.

문자열 / 쉼표로 구분된 목록

NeutronTunnelIdRanges

테넌트 네트워크 할당에 사용하려는 GRE 터널 ID 범위입니다. 예를 들어 NeutronTunnelIdRanges "1:1000" 입니다.

string

NeutronVniRanges

테넌트 네트워크 할당에 사용하려는 VXLAN VNI ID 범위입니다. 예를 들면 NeutronVniRanges입니다. "1:1000".

string

NeutronEnableTunnelling

터널링된 모든 네트워크를 활성화 또는 완전히 비활성화할지 여부를 정의합니다. 나중에 튜닝된 네트워크를 생성하지 않으려면 이 기능을 활성화하십시오. 기본값은 true입니다.

부울

NeutronNetworkVLANRanges

지원할 ML2 및 Open vSwitch VLAN 매핑 범위입니다. 기본값은 datacentre 물리적 네트워크에서 VLAN을 허용하도록 합니다. 여러 값을 지정하려면 쉼표로 구분된 목록을 사용합니다. 예를 들어 NeutronNetworkVLANRanges: "datacentre:1:1000,tenant:100:299,tenant:310:399 ".

string

NeutronMechanismDrivers

neutron 테넌트 네트워크의 메커니즘 드라이버입니다. 기본값은 ovn 입니다. 여러 값을 지정하려면 쉼표로 구분된 문자열을 사용합니다. 예를 들어 NeutronMechanismDrivers: 'openvswitch,l2population' 입니다.

문자열 / 쉼표로 구분된 목록

10.9. 사용자 지정 네트워크 환경 파일 예

다음 코드 조각은 NIC 템플릿을 활성화하고 사용자 정의 매개변수를 설정하는 데 사용할 수 있는 환경 파일의 예입니다.

resource_registry:
  OS::TripleO::BlockStorage::Net::SoftwareConfig:
    /home/stack/templates/nic-configs/cinder-storage.yaml
  OS::TripleO::Compute::Net::SoftwareConfig:
    /home/stack/templates/nic-configs/compute.yaml
  OS::TripleO::Controller::Net::SoftwareConfig:
    /home/stack/templates/nic-configs/controller.yaml
  OS::TripleO::ObjectStorage::Net::SoftwareConfig:
    /home/stack/templates/nic-configs/swift-storage.yaml
  OS::TripleO::CephStorage::Net::SoftwareConfig:
    /home/stack/templates/nic-configs/ceph-storage.yaml

parameter_defaults:
  # Gateway router for the provisioning network (or Undercloud IP)
  ControlPlaneDefaultRoute: 192.0.2.254
  # The IP address of the EC2 metadata server. Generally the IP of the Undercloud
  EC2MetadataIp: 192.0.2.1
  # Define the DNS servers (maximum 2) for the overcloud nodes
  DnsServers: ["8.8.8.8","8.8.4.4"]
  NeutronExternalNetworkBridge: "''"

10.10. 사용자 정의 NIC를 통한 네트워크 격리 활성화

네트워크 분리 및 사용자 지정 NIC 템플릿을 사용하여 Overcloud를 배포하려면 오버클라우드 배포 명령의 모든 관련 네트워킹 환경 파일을 포함합니다.

절차

  1. openstack overcloud deploy 명령을 실행하면 다음 파일을 포함합니다.

    • 사용자 지정 network_data.yaml 파일입니다.
    • 기본 네트워크 격리의 렌더링된 파일 이름입니다.
    • 렌더링된 기본 네트워크 환경 파일의 파일 이름입니다.
    • 사용자 지정 NIC 템플릿에 대한 리소스 참조가 포함된 사용자 지정 환경 네트워크 구성입니다.
    • 구성과 관련된 추가 환경 파일입니다.

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

$ openstack overcloud deploy --templates \
    ...
    -n /home/stack/network_data.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
    -e /home/stack/templates/custom-network-configuration.yaml \
    ...
  • 먼저 network-isolation.yaml 파일을 포함하고 network-environment.yaml 파일을 포함합니다. 후속 custom-network-configuration.yaml 은 이전 두 파일의 OS::TripleO::[ROLE]::Net::SoftwareConfig 리소스를 덮어씁니다.
  • 구성 가능한 네트워크를 사용하는 경우 이 명령으로 network_data.yamlroles_data.yaml 파일을 포함합니다.

11장. 추가 네트워크 구성

이 장에서는 10장. 사용자 정의 네트워크 인터페이스 템플릿 에 설명된 개념과 절차에 따라 진행되며, 오버클라우드 네트워크의 일부를 구성하는 데 도움이 되는 몇 가지 추가 정보를 제공합니다.

11.1. 사용자 정의 인터페이스 구성

개별 인터페이스에는 수정이 필요할 수 있습니다. 다음 예제에서는 두 번째 NIC를 사용하여 DHCP 주소가 있는 인프라 네트워크에 연결하고 본딩에 세 번째 및 네 번째 NIC를 사용하는 데 필요한 수정 사항을 보여줍니다.

network_config:
  # Add a DHCP infrastructure network to nic2
  - type: interface
    name: nic2
    use_dhcp: true
  - type: ovs_bridge
    name: br-bond
    members:
      - type: ovs_bond
        name: bond1
        ovs_options:
          get_param: BondInterfaceOvsOptions
        members:
          # Modify bond NICs to use nic3 and nic4
          - type: interface
            name: nic3
            primary: true
          - type: interface
            name: nic4

네트워크 인터페이스 템플릿에서는 실제 인터페이스 이름(eth0, eth 1,enp0s25) 또는번호가 매겨진 인터페이스 집합(nic1, nic 2, nic 3)을 사용합니다. 역할 내의 호스트의 네트워크 인터페이스는 명명된 인터페이스(eth0,eno2 등) 대신 번호가 지정된 인터페이스(nic1,nic2 등)를 사용할 때 정확하게 동일할 필요는 없습니다. 예를 들어 한 호스트에는 em1 및 em 2 인터페이스가 있을 수 있지만 다른 한 개에는 eno1eno2 가 있지만 두 호스트의 NIC를 nic1 및 nic 2 로 참조할 수 있습니다.

번호가 매겨진 인터페이스 순서는 명명된 네트워크 인터페이스 유형의 순서에 해당합니다.

  • eth 0, eth 1 등과 같은 eth X 인터페이스. 일반적으로 온보드 인터페이스입니다.
  • enoX 인터페이스(예: eno0,eno1) 등. 일반적으로 온보드 인터페이스입니다.
  • enX 인터페이스, enp3s 0, enp3s 1,ens3 , 등과 같은 영숫자로 정렬됩니다. 일반적으로 애드온 인터페이스입니다.

번호가 매겨진 NIC 체계에는 인터페이스에 스위치에 연결된 케이블이 연결된 경우 라이브 인터페이스만 포함됩니다. 4개의 인터페이스와 6개의 인터페이스가 있는 일부 호스트가 있는 경우 nic1을 nic 4 에 사용하고 각 호스트에 4개의 케이블만 연결합니다.

물리적 인터페이스를 특정 별칭으로 하드 코딩하면 어떤 물리적 NIC가 nic1 또는 nic 2 등으로 매핑되는지 미리 확인할 수 있습니다. MAC 주소를 지정된 별칭에 매핑할 수도 있습니다.

참고

일반적으로 os-net-configUP 상태로 이미 연결된 인터페이스만 등록합니다. 그러나 사용자 지정 매핑 파일을 사용하는 인터페이스를 하드 코딩하는 경우 인터페이스가 DOWN 상태인 경우에도 등록됩니다.

인터페이스는 환경 파일을 사용하여 별칭에 매핑됩니다. 이 예에서 각 노드에는 nic1 및 nic 2 에 대한 사전 정의된 항목이 있습니다.

참고

NetConfigDataLookup 구성을 사용하려면 NodeUserData 리소스 레지스트리에 os-net-config-mappings.yaml 파일도 포함해야 합니다.

resource_registry:
  OS::TripleO::NodeUserData: /usr/share/openstack-tripleo-heat-templates/firstboot/os-net-config-mappings.yaml
parameter_defaults:
  NetConfigDataLookup:
    node1:
      nic1: "em1"
      nic2: "em2"
    node2:
      nic1: "00:50:56:2F:9F:2E"
      nic2: "em2"

결과 구성은 os-net-config 에 의해 적용됩니다. 각 노드에서 /etc/os-net-config/ mapping.yaml 파일의 interface_ mapping 섹션에 적용된 구성을 확인할 수 있습니다.

참고

NetConfigDataLookup 매개변수는 사전 프로비저닝된 노드에 배포 중에 적용되지 않습니다. 사전 프로비저닝된 노드에 사용자 지정 인터페이스 매핑을 사용하려면 배포 전에 각 노드에서 /etc/os-net-config/mapping.yaml 파일을 생성해야 합니다. /etc/os-net-config/mapping.yaml 파일에서 다음 예제 인터페이스 매핑을 사용합니다.

interface_mapping:
  nic1: em1
  nic2: em2

11.2. 경로 및 기본 경로 구성

두 가지 방법 중 하나로 호스트의 기본 경로를 설정할 수 있습니다. 인터페이스에서 DHCP를 사용하고 DHCP 서버에서 게이트웨이 주소를 제공하는 경우 시스템은 해당 게이트웨이의 기본 경로를 사용합니다. 그렇지 않으면 정적 IP를 사용하여 인터페이스에서 기본 경로를 설정할 수 있습니다.

Linux 커널은 여러 기본 게이트웨이를 지원하지만 지표가 가장 낮은 게이트웨이만 사용합니다. DHCP 인터페이스가 여러 개인 경우 예측할 수 없는 기본 게이트웨이가 발생할 수 있습니다. 이 경우 기본 경로를 사용하는 인터페이스 이외의 인터페이스에 대해 defroute: false 를 설정하는 것이 좋습니다.

예를 들어 DHCP 인터페이스(nic3)를 기본 경로로지정할 수 있습니다. 다음 YAML 스니펫을 사용하여 다른 DHCP 인터페이스(nic2)에서 기본 경로를 비활성화합니다.

# No default route on this DHCP interface
- type: interface
  name: nic2
  use_dhcp: true
  defroute: false
# Instead use this DHCP interface as the default route
- type: interface
  name: nic3
  use_dhcp: true
참고

defroute 매개 변수는 DHCP를 통해 얻은 경로에만 적용됩니다.

고정 IP가 있는 인터페이스에서 고정 경로를 설정하려면 서브넷의 경로를 지정합니다. 예를 들어 내부 API 네트워크의 172.17.0.1의 게이트웨이를 통해 10.1.2.0/24 서브넷으로 경로를 설정할 수 있습니다.

    - type: vlan
      device: bond1
      vlan_id:
        get_param: InternalApiNetworkVlanID
      addresses:
      - ip_netmask:
          get_param: InternalApiIpSubnet
      routes:
      - ip_netmask: 10.1.2.0/24
        next_hop: 172.17.0.1

11.3. 정책 기반 라우팅 구성

컨트롤러 노드에서 다른 네트워크에서 무제한 액세스를 구성하려면 정책 기반 라우팅을 구성합니다. 정책 기반 라우팅에서는 여러 인터페이스가 있는 호스트에서 소스 주소에 따라 특정 인터페이스를 통해 트래픽을 보낼 수 있는 라우팅 테이블을 사용합니다. 대상이 동일하더라도 다양한 소스에서 다른 네트워크로 들어오는 패킷을 라우팅할 수 있습니다.

예를 들어 기본 경로가 외부 네트워크에 있는 경우에도 패킷의 소스 주소를 기반으로 내부 API 네트워크에 트래픽을 보내도록 경로를 구성할 수 있습니다. 각 인터페이스에 대한 특정 경로 규칙을 정의할 수도 있습니다.

Red Hat OpenStack Platform은 os-net-config 툴을 사용하여 오버클라우드 노드의 네트워크 속성을 구성합니다. os-net-config 툴은 컨트롤러 노드에서 다음 네트워크 라우팅을 관리합니다.

  • /etc/iproute2/rt_tables 파일의 라우팅 테이블
  • /etc/sysconfig/network-scripts/rule-{ifname} 파일의 IPv4 규칙
  • /etc/sysconfig/network-scripts/rule6-{ifname} 파일의 IPv6 규칙
  • 라우팅 테이블 특정 경로의 /etc/sysconfig/network-scripts/route-{ifname}

사전 요구 사항

절차

  1. ~/templates/custom-nics 디렉터리에서 사용자 지정 NIC 템플릿에 route_table인터페이스 항목을 생성하고, 인터페이스의 경로를 정의하며, 배포와 관련된 규칙을 정의합니다.

    $network_config:
      network_config:
    
      - type: route_table
        name: <custom>
        table_id: 200
    
      - type: interface
        name: em1
        use_dhcp: false
        addresses:
          - ip_netmask: {get_param: ExternalIpSubnet}
        routes:
          - ip_netmask: 10.1.3.0/24
            next_hop: {get_param: ExternalInterfaceDefaultRoute}
            table: 200
        rules:
          - rule: "iif em1 table 200"
            comment: "Route incoming traffic to em1 with table 200"
          - rule: "from 192.0.2.0/24 table 200"
            comment: "Route all traffic from 192.0.2.0/24 with table 200"
          - rule: "add blackhole from 172.19.40.0/24 table 200"
          - rule: "add unreachable iif em1 from 192.168.1.0/24"
  2. run-os-net-config.sh 스크립트 위치를 사용자가 생성한 각 사용자 지정 NIC 템플릿의 절대 경로로 설정합니다. 스크립트는 언더클라우드의 /usr/share/openstack-tripleo-heat-templates/network/scripts/ 디렉터리에 있습니다.

    resources:
      OsNetConfigImpl:
        type: OS::Heat::SoftwareConfig
        properties:
          group: script
          config:
            str_replace:
              template:
                get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh
  3. 배포와 관련된 기타 환경 파일과 함께 배포 명령에 사용자 정의 NIC 구성 및 네트워크 환경 파일을 추가합니다.

    $ openstack overcloud deploy --templates \
    -e ~/templates/<custom-nic-template>
    -e <OTHER_ENVIRONMENT_FILES>

검증

  • 컨트롤러 노드에서 다음 명령을 입력하여 라우팅 구성이 올바르게 작동하는지 확인합니다.

    $ cat /etc/iproute2/rt_tables
    $ ip route
    $ ip rule

11.4. 점보 프레임 구성

MTU(최대 전송 단위) 설정은 단일 이더넷 프레임으로 전송되는 최대 데이터 양을 결정합니다. 더 큰 값을 사용하면 각 프레임이 헤더 형태로 데이터가 추가되기 때문에 오버헤드가 줄어듭니다. 기본값은 1500이며 더 높은 값을 사용하려면 점보 프레임을 지원하도록 스위치 포트를 구성해야 합니다. 대부분의 스위치는 9000 MTU를 지원하지만, 기본적으로 1500용으로 구성되어 있습니다.

VLAN의 MTU는 실제 인터페이스의 MTU를 초과할 수 없습니다. 본딩 또는 인터페이스에 MTU 값을 포함해야 합니다.

스토리지, 스토리지 관리, 내부 API 및 테넌트 네트워크는 모두 점보 프레임의 이점을 제공합니다.

주의

라우터는 일반적으로 점보 프레임을 계층 3 경계 간에 전달할 수 없습니다. 연결 문제를 방지하려면 프로비저닝 인터페이스, 외부 인터페이스 및 유동 IP 인터페이스의 기본 MTU를 변경하지 마십시오.

- type: ovs_bond
  name: bond1
  mtu: 9000
  ovs_options: {get_param: BondInterfaceOvsOptions}
  members:
    - type: interface
      name: nic3
      mtu: 9000
      primary: true
    - type: interface
      name: nic4
      mtu: 9000

# The external interface should stay at default
- type: vlan
  device: bond1
  vlan_id:
    get_param: ExternalNetworkVlanID
  addresses:
    - ip_netmask:
        get_param: ExternalIpSubnet
  routes:
    - ip_netmask: 0.0.0.0/0
      next_hop:
        get_param: ExternalInterfaceDefaultRoute

# MTU 9000 for Internal API, Storage, and Storage Management
- type: vlan
  device: bond1
  mtu: 9000
  vlan_id:
    get_param: InternalApiNetworkVlanID
  addresses:
  - ip_netmask:
      get_param: InternalApiIpSubnet

11.5. 점보 프레임 조각화를 위한 ML2/OVN Northbound 경로 MTU 검색 구성

내부 네트워크의 VM에서 점보 프레임을 외부 네트워크로 전송하고 내부 네트워크의 최대 전송 단위(MTU)가 외부 네트워크의 MTU를 초과하는 경우 Northbound 프레임은 외부 네트워크의 용량을 쉽게 초과할 수 있습니다.

ML2/OVS는 이보다 큰 패킷 문제를 자동으로 처리하고 ML2/OVN은 TCP 패킷에 대해 자동으로 처리합니다.

그러나 ML2/OVN 메커니즘 드라이버를 사용하는 배포에서 대규모 Northbound UDP 패킷을 올바르게 처리하려면 추가 구성 단계를 수행해야 합니다.

이러한 단계에서는 전송 애플리케이션이 페이로드를 더 작은 패킷으로 나눌 수 있는 전송 VM에 ICMP "패키지에 필요한" 패킷을 반환하도록 ML2/OVN 라우터를 구성합니다.

참고

east/west 트래픽에서는 RHOSP ML2/OVN 배포에서 east/west 경로에서 가장 작은 MTU보다 큰 패킷 조각화를 지원하지 않습니다. 예를 들면 다음과 같습니다.

  • VM1은 MTU가 1300인 Network1에 있습니다.
  • VM2는 MTU가 1200인 Network2에 있습니다.
  • 크기가 1171 이하인 VM1과 VM2 간의 방향을 ping합니다. 크기가 1171보다 큰 ping은 패킷 손실이 100 %입니다.

    이러한 유형의 조각화에 대한 고객 요구 사항이 확인되지 않아 Red Hat은 지원을 추가할 계획이 없습니다.

사전 요구 사항

  • kernel-4.18.0-193.20.1.el8_2 이상의 RHEL 8.2.0.4 이상.

절차

  1. 커널 버전을 확인합니다.

    ovs-appctl -t ovs-vswitchd dpif/show-dp-features br-int
  2. 출력에 pkt 길이 작업 확인: no 또는 출력에 Check pkt length action 문자열이 없거나 RHEL 8.2.0.4 이상으로 업그레이드하거나 점보 프레임이 더 작은 외부 네트워크로 전송하지 마십시오.
  3. 출력에 pkt 길이 작업 확인: 예, ml2_conf.ini의 [ovn] 섹션에서 다음 값을 설정합니다.

    ovn_emit_need_to_frag = True

11.6. 트렁크된 인터페이스에서 기본 VLAN 구성

트렁크된 인터페이스 또는 본딩에 기본 VLAN에 네트워크가 있는 경우 IP 주소가 브리지에 직접 할당되고 VLAN 인터페이스가 없습니다.

예를 들어 외부 네트워크가 기본 VLAN에 있는 경우 본딩된 구성은 다음과 같습니다.

network_config:
  - type: ovs_bridge
    name: bridge_name
    dns_servers:
      get_param: DnsServers
    addresses:
      - ip_netmask:
          get_param: ExternalIpSubnet
    routes:
      - ip_netmask: 0.0.0.0/0
        next_hop:
          get_param: ExternalInterfaceDefaultRoute
    members:
      - type: ovs_bond
        name: bond1
        ovs_options:
          get_param: BondInterfaceOvsOptions
        members:
          - type: interface
            name: nic3
            primary: true
          - type: interface
            name: nic4
참고

주소 또는 경로 문을 브리지로 이동할 때 브리지에서 해당 VLAN 인터페이스를 제거합니다. 적용 가능한 모든 역할을 변경합니다. 외부 네트워크는 컨트롤러에만 있으므로 컨트롤러 템플릿만 변경해야 합니다. 스토리지 네트워크가 모든 역할에 연결되어 있으므로 스토리지 네트워크가 기본 VLAN에 있는 경우 모든 역할을 수정해야 합니다.

11.7. netfilter가 추적하는 최대 연결 수 증가

RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스(neutron)는 netfilter 연결 추적을 사용하여 상태 저장 방화벽을 빌드하고 가상 네트워크에서 NAT(네트워크 주소 변환)를 제공합니다. 커널 공간이 최대 연결 제한에 도달하도록 할 수 있는 상황이 있으며 nf_conntrack: 테이블 전체와 같은 오류가 발생하여 패킷을 삭제할 수 있습니다. 연결 추적(conntrack)의 제한을 늘리고 이러한 유형의 오류를 방지할 수 있습니다. RHOSP 배포에서 하나 이상의 역할 또는 모든 노드에서 conntrack 제한을 늘릴 수 있습니다.

사전 요구 사항

  • 성공적인 RHOSP 언더클라우드 설치

절차

  1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.
  2. 언더클라우드 인증 정보 파일을 소싱합니다.

    $ source ~/stackrc
  3. 사용자 지정 YAML 환경 파일을 생성합니다.

    예제

    $ vi /home/stack/templates/my-environment.yaml

  4. 환경 파일에는 키워드 parameter_defaultsExtraSysctl 509 가 포함되어야 합니다. netfilter가 변수 net.nf_conntrack_max 에서 추적할 수 있는 최대 연결 수의 새 값을 입력합니다.

    예제

    이 예제에서는 RHOSP 배포의 모든 호스트에 conntrack 제한을 설정할 수 있습니다.

    parameter_defaults:
      ExtraSysctlSettings:
        net.nf_conntrack_max:
          value: 500000

    <role>Parameter 매개변수를 사용하여 특정 역할에 대한 conntrack 제한을 설정합니다.

    parameter_defaults:
      <role>Parameters:
        ExtraSysctlSettings:
          net.nf_conntrack_max:
            value: <simultaneous_connections>
    • <role> 을 역할 이름으로 바꿉니다.

      예를 들어 컨트롤러 매개 변수를 사용하여 컨트롤러 역할에 대한 conntrack 제한을 설정하거나 ComputeParameters 를 사용하여 Compute 역할의 conntrack 제한을 설정합니다.

    • <simultaneous_connections> 를 허용하려는 동시 연결 수로 바꿉니다.

      예제

      이 예제에서는 RHOSP 배포의 Controller 역할에 대해서만 conntrack 제한을 설정할 수 있습니다.

      parameter_defaults:
        ControllerParameters:
          ExtraSysctlSettings:
            net.nf_conntrack_max:
              value: 500000
      참고

      net.nf_conntrack_max 의 기본값은 500000 연결입니다. 최대값은 다음과 같습니다. 4294967295.

  5. 배포 명령을 실행하고 핵심 heat 템플릿, 환경 파일 및 이 새 사용자 지정 환경 파일을 포함합니다.

    중요

    후속 환경 파일에 정의된 매개변수 및 리소스가 우선하므로 환경 파일의 순서가 중요합니다.

    예제

    $ openstack overcloud deploy --templates \
    -e /home/stack/templates/my-environment.yaml

12장. 네트워크 인터페이스 본딩

사용자 지정 네트워크 구성에서 다양한 본딩 옵션을 사용할 수 있습니다.

12.1. 오버클라우드 노드의 네트워크 인터페이스 본딩

여러 물리적 NIC를 함께 번들하여 본딩이라는 단일 논리 채널을 구성할 수 있습니다. 고가용성 시스템의 중복성 또는 처리량이 증가하도록 본딩을 구성할 수 있습니다.

Red Hat OpenStack Platform은 OVS(Open vSwitch) 커널 본딩, OVS-DPDK 본딩 및 Linux 커널 본딩을 지원합니다.

표 12.1. 지원되는 인터페이스 본딩 유형

본딩 유형값 입력허용되는 브릿지 유형허용된 멤버

OVS 커널 본딩

ovs_bond

ovs_bridge

interface

OVS-DPDK 본딩

ovs_dpdk_bond

ovs_user_bridge

ovs_dpdk_port

Linux 커널 본딩

linux_bond

ovs_bridge or linux_bridge

interface

중요

동일한 노드에서 ovs_bridgeovs_user_bridge 를 결합하지 마십시오.

12.2. OVS(Open vSwitch) 본딩 생성

네트워크 인터페이스 템플릿에 OVS 본딩을 만듭니다. 예를 들어 OVS 사용자 공간 브리지의 일부로 본딩을 만들 수 있습니다.

...
          params:
            $network_config:
              network_config:
              - type: ovs_user_bridge
                name: br-ex
                use_dhcp: false
                members:
                - type: ovs_dpdk_bond
                  name: dpdkbond0
                  mtu: 2140
                  ovs_options: {get_param: BondInterfaceOvsOptions}
                  rx_queue:
                    get_param: NumDpdkInterfaceRxQueues
                  members:
                  - type: ovs_dpdk_port
                    name: dpdk0
                    mtu: 2140
                    members:
                    - type: interface
                      name: p1p1
                  - type: ovs_dpdk_port
                    name: dpdk1
                    mtu: 2140
                    members:
                    - type: interface
                      name: p1p2

이 예에서는 두 DPDK 포트에서 본딩을 생성합니다.

ovs_options 매개 변수에는 본딩 옵션이 포함되어 있습니다. BondInterfaceOvsOptions 매개변수를 사용하여 네트워크 환경 파일에서 본딩 옵션을 구성할 수 있습니다.

parameter_defaults:
  BondInterfaceOvsOptions: "bond_mode=balance-slb"

12.3. OVS(Open vSwitch) 본딩 옵션

NIC 템플릿 파일에서 ovs_options heat 매개변수를 사용하여 다양한 OVS(Open vSwitch) 본딩 옵션을 설정할 수 있습니다.

bond_mode=balance-slb
소스 로드 밸런싱(slb)은 소스 MAC 주소 및 출력 VLAN을 기반으로 흐름의 균형을 정하며, 트래픽 패턴 변경 시 주기적으로 재조정됩니다. balance-slb bonding 옵션으로 본딩을 구성하면 원격 스위치에는 구성이 필요하지 않습니다. Networking 서비스(neutron)는 각 소스 MAC 및 VLAN 쌍을 링크에 할당하고 해당 MAC 및 VLAN의 모든 패킷을 해당 링크를 통해 전송합니다. 소스 MAC 주소 및 VLAN 번호를 기반으로 하는 간단한 해시 알고리즘이 사용되며 트래픽 패턴이 변경될 때 주기적인 재조정이 사용됩니다. balance-slb 모드는 Linux bonding 드라이버에서 사용하는 모드 2 본딩과 유사합니다. 스위치가 LACP를 사용하도록 구성되지 않은 경우에도 이 모드를 사용하여 부하 분산을 제공할 수 있습니다.
bond_mode=active-backup
active-backup 본딩 모드를 사용하여 본딩을 구성하면 네트워킹 서비스에서 하나의 NIC를 대기 상태로 유지합니다. edge NIC는 활성 연결이 실패하면 네트워크 작업을 다시 시작합니다. 실제 스위치에는 하나의 MAC 주소만 표시됩니다. 이 모드에서는 스위치 구성이 필요하지 않으며 링크가 별도의 스위치에 연결되어 있을 때 작동합니다. 이 모드에서는 로드 밸런싱을 제공하지 않습니다.
lacp=[active | passive | off]
LACP(링크 집계 제어 프로토콜) 동작을 제어합니다. 특정 스위치만 LACP를 지원합니다. 스위치가 LACP를 지원하지 않는 경우 bond_mode=balance-slb 또는 bond_mode=active-backup 을 사용합니다.
other-config:lacp-fallback-ab=true
LACP가 실패하는 경우 active-backup을 본딩 모드로 설정합니다.
other_config:lacp-time=[fast | slow]
LACP 하트비트를 1초(fast) 또는 30초(낮음)로 설정합니다. 기본값은 느립니다.
other_config:bond-detect-mode=[miimon | carrier]
miimon heartbeats(miimon) 또는 모니터 캐리어(carrier)를 사용하도록 링크 탐지를 설정합니다. 기본값은 캐리어입니다.
other_config:bond-miimon-interval=100
miimon을 사용하는 경우 하트비트 간격(밀리초)을 설정합니다.
bond_updelay=1000
플로팅을 방지하기 위해 링크가 활성화되어야 하는 간격(밀리초)을 설정합니다.
other_config:bond-rebalance-interval=10000
흐름이 본딩 멤버 간에 재조정되는 간격(밀리초)을 설정합니다. 본딩 멤버 간 흐름 재조정을 비활성화하려면 이 값을 0으로 설정합니다.

12.5. Linux 본딩 생성

네트워크 인터페이스 템플릿에 Linux 본딩을 만듭니다. 예를 들어 두 인터페이스를 결합하는 Linux 본딩을 만들 수 있습니다.

...
          params:
            $network_config:
              network_config:
              - type: linux_bond
                name: bond1
                members:
                - type: interface
                  name: nic2
                - type: interface
                  name: nic3
                bonding_options: "mode=802.3ad lacp_rate=[fast|slow] updelay=1000 miimon=100"

bonding_options 매개 변수는 Linux 본딩에 대한 특정 본딩 옵션을 설정합니다.

mode
예제에서 802.3ad 또는 LACP 모드인 본딩 모드를 설정합니다. Linux 본딩 모드에 대한 자세한 내용은 Red Hat Enterprise Linux 8 네트워킹 구성 및 관리 가이드의 "호스팅 모드에 따라 업그레이드 구성" 을 참조하십시오.
lacp_rate
1초마다 또는 30초마다 LACP 패킷이 전송되는지 여부를 정의합니다.
updelay
인터페이스를 트래픽에 사용하기 전에 활성화해야 하는 최소 시간을 정의합니다. 이 최소 구성은 포트 깜박임 발생을 완화하는 데 도움이 됩니다.
miimon
드라이버의 MIIMON 기능을 사용하여 포트 상태를 모니터링하는 데 사용되는 간격(밀리초)입니다.

다음 추가 예제를 가이드로 사용하여 자체 Linux 본딩을 구성합니다.

  • Linux bond는 하나의 VLAN을 사용하여 active-backup 모드로 설정합니다.

    ....
              params:
                $network_config:
                  network_config:
                  - type: linux_bond
                    name: bond_api
                    bonding_options: "mode=active-backup"
                    use_dhcp: false
                    dns_servers:
                      get_param: DnsServers
                    members:
                    - type: interface
                      name: nic3
                      primary: true
                    - type: interface
                      name: nic4
    
                  - type: vlan
                    vlan_id:
                      get_param: InternalApiNetworkVlanID
                    device: bond_api
                    addresses:
                    - ip_netmask:
                        get_param: InternalApiIpSubnet
  • Linux 본딩을 하나의 VLAN을 사용하여 802.3ad LACP 모드로 설정합니다.

    ...
              params:
                $network_config:
                  network_config:
                -  type: ovs_bridge
                    name: br-tenant
                    use_dhcp: false
                    mtu: 9000
                    members:
                      - type: linux_bond
                        name: bond_tenant
                        bonding_options: "mode=802.3ad updelay=1000 miimon=100"
                        use_dhcp: false
                        dns_servers:
                          get_param: DnsServers
                        members:
                        - type: interface
                          name: p1p1
                          primary: true
                        - type: interface
                          name: p1p2
                      - type: vlan
                        device: bond_tenant
                        vlan_id: {get_param: TenantNetworkVlanID}
                        addresses:
                          -
                            ip_netmask: {get_param: TenantIpSubnet}

13장. 노드 배치 제어

기본적으로 director는 노드의 프로필 태그에 따라 각 역할에 대해 임의로 노드를 선택합니다. 그러나 특정 노드 배치를 정의할 수도 있습니다. 이는 다음 시나리오에서 유용합니다.

  • 특정 노드 ID(예: controller-0,controller-1)할당
  • 사용자 정의 호스트 이름 할당
  • 특정 IP 주소 할당
  • 특정 가상 IP 주소 할당
참고

네트워크에 예측 가능한 IP 주소, 가상 IP 주소 및 포트를 수동으로 설정하면 풀 할당의 필요성이 줄어듭니다. 그러나 새 노드를 쉽게 확장할 수 있도록 각 네트워크에 대한 할당 풀을 유지하는 것이 좋습니다. 정적으로 정의된 모든 IP 주소가 할당 풀 외부에 속하는지 확인합니다.

13.1. 특정 노드 ID 할당

특정 노드에 노드 ID(예: controller-0, controller-1, compute-0,compute-1) 를 할당할 수 있습니다 .

절차

  1. 컴퓨팅 스케줄러가 배포 시 일치하는 노드별 기능으로 ID를 할당합니다.

    openstack baremetal node set --property capabilities='node:controller-0,boot_option:local' <id>

    이 명령은 기능 node:controller-0 을 노드에 할당합니다. 모든 노드에 대해 0부터 시작하여 고유한 연속 인덱스를 사용하여 이 패턴을 반복합니다. 지정된 역할(Controller, Compute 또는 각 스토리지 역할)의 모든 노드에 동일한 방식으로 태그가 지정되어 있는지 또는 Compute 스케줄러가 기능과 올바르게 일치할 수 없는지 확인합니다.

  2. 스케줄러 힌트를 사용하여 각 노드의 기능과 일치시키는 Heat 환경 파일(예: scheduler_hints_env.yaml)을 생성합니다.

    parameter_defaults:
      ControllerSchedulerHints:
        'capabilities:node': 'controller-%index%'

    다음 매개변수를 사용하여 다른 역할 유형에 대한 스케줄러 힌트를 구성합니다.

    • 컨트롤러 노드의 ControllerSchedulerHints 입니다.
    • 컴퓨팅 노드의 ComputeSchedulerHints 입니다.
    • 블록 스토리지 노드의 BlockStorageSchedulerHints 입니다.
    • 오브젝트 스토리지 노드의 ObjectStorageSchedulerHints 입니다.
    • Ceph Storage 노드의 CephStorageSchedulerHints.
    • [ROLE] 사용자 정의 역할을 위한 스케줄 힌트입니다. [ROLE] 을 역할 이름으로 바꿉니다.
  3. Overcloud 배포 명령에 scheduler_hints_env.yaml 환경 파일을 포함합니다.
참고

노드 배치는 프로필 일치보다 우선합니다. 스케줄링 실패를 방지하려면 프로필 일치(컴퓨팅,제어)용으로 설계된 플레이버가 아닌 배포에 기본 baremetal 플레이버 를 사용합니다. 환경 파일에서 각 플레이버 매개 변수를 baremetal로 설정합니다.

parameter_defaults:
  OvercloudControllerFlavor: baremetal
  OvercloudComputeFlavor: baremetal

13.2. 사용자 정의 호스트 이름 할당

director는 13.1절. “특정 노드 ID 할당” 의 노드 ID 구성과 함께 각 노드에 특정 사용자 지정 호스트 이름을 할당할 수도 있습니다. 이 기능은 시스템이 있는 위치(예: rack2-row12)를 정의해야 하거나 인벤토리식별자 또는 사용자 지정 호스트 이름이 바람직한 기타 상황을 정의해야 하는 경우에 유용합니다.

중요

노드 이름을 배포한 후에는 이름을 바꾸지 마십시오. 배포 후 노드 이름을 변경하면 인스턴스 관리 문제가 발생합니다.

절차

  • 13.1절. “특정 노드 ID 할당”scheduler_hints_env.yaml 파일과 같은 환경 파일에서 HostnameMap 매개변수를 사용합니다.

    parameter_defaults:
      ControllerSchedulerHints:
        'capabilities:node': 'controller-%index%'
      ComputeSchedulerHints:
        'capabilities:node': 'compute-%index%'
      HostnameMap:
        overcloud-controller-0: overcloud-controller-prod-123-0
        overcloud-controller-1: overcloud-controller-prod-456-0
        overcloud-controller-2: overcloud-controller-prod-789-0
        overcloud-novacompute-0: overcloud-compute-prod-abc-0

    parameter_defaults 섹션에 HostnameMap 을 정의하고 각 매핑을 HostnameFormat 매개 변수(예: overcloud-controller-0)로 정의하는 원래 호스트 이름으로 설정하고 두 번째값은 해당 노드에 대해 원하는 사용자 지정 호스트 이름(overcloud-controller-prod-123-0)입니다.

노드 ID 배치와 함께 이 방법을 사용하여 각 노드에 사용자 지정 호스트 이름이 있는지 확인합니다.

13.3. 예측 가능한 IP 할당

결과 환경을 추가로 제어하기 위해 director에서 각 네트워크에서 특정 IP 주소를 사용하여 오버클라우드 노드를 할당할 수 있습니다.

절차

  1. 환경 파일을 생성하여 예측 가능한 IP 주소를 정의합니다.

    $ touch ~/templates/predictive_ips.yaml
  2. ~/templates/predictive _ips.yaml 파일에서 parameter_ defaults 섹션을 생성하고 다음 구문을 사용하여 각 네트워크의 각 노드에 대한 예측 가능한 IP 주소 지정을 정의합니다.

    parameter_defaults:
      <role_name>IPs:
        <network>:
        - <IP_address>
        <network>:
        - <IP_address>

    각 노드 역할에는 고유한 매개 변수가 있습니다. <role_name>IP를 관련 매개변수로 바꿉니다.

    • 컨트롤러 노드의 ControllerIP.
    • 컴퓨팅 노드 의 ComputeIP.
    • Ceph Storage 노드의 CephStorageIP.
    • 블록 스토리지 노드 의 BlockStorageIP.
    • 오브젝트 스토리지 노드의 SwiftStorageIPs.
    • [ROLE]사용자 정의 역할을 위한 IP입니다. [ROLE] 을 역할 이름으로 바꿉니다.

      각 매개 변수는 네트워크 이름에서 주소 목록에 대한 맵입니다. 각 네트워크 유형에는 해당 네트워크에 노드가 있을 만큼의 주소가 있어야 합니다. director에서 주소를 순서대로 할당합니다. 각 유형의 첫 번째 노드는 각 목록에서 첫 번째 주소를 수신하고 두 번째 노드는 각 목록에서 두 번째 주소를 수신합니다.

      예를 들어 예측 가능한 IP 주소가 있는 오버클라우드에 세 개의 Ceph Storage 노드를 배포하려면 다음 예제 구문을 사용합니다.

      parameter_defaults:
        CephStorageIPs:
          storage:
          - 172.16.1.100
          - 172.16.1.101
          - 172.16.1.102
          storage_mgmt:
          - 172.16.3.100
          - 172.16.3.101
          - 172.16.3.102

      첫 번째 Ceph Storage 노드는 두 개의 주소를 수신합니다. 172.16.1.100 및 172.16.3.100. 두 번째는 172.16.1.101 및 172.16.3.101을 수신하고 세 번째는 172.16.1.102 및 172.16.3.102를 수신합니다. 동일한 패턴은 다른 노드 유형에 적용됩니다.

      컨트롤 플레인에서 예측 가능한 IP 주소를 구성하려면 /usr/share/openstack-tripleo-heat-templates/environments/ips-from-pool-ctlplane.yaml 파일을 stack 사용자의 templates 디렉터리에 복사합니다.

      $ cp /usr/share/openstack-tripleo-heat-templates/environments/ips-from-pool-ctlplane.yaml ~/templates/.

      다음 매개 변수 예제를 사용하여 새 ips-from-pool-ctlplane.yaml 파일을 구성합니다. 컨트롤 플레인 IP 주소 선언을 다른 네트워크에 대한 IP 주소 선언과 결합하고 한 파일만 사용하여 모든 역할에 있는 모든 네트워크에 대한 IP 주소를 선언할 수 있습니다. 스파인/리프형에 대해 예측 가능한 IP 주소를 사용할 수도 있습니다. 각 노드에는 올바른 서브넷의 IP 주소가 있어야 합니다.

      parameter_defaults:
        ControllerIPs:
          ctlplane:
          - 192.168.24.10
          - 192.168.24.11
          - 192.168.24.12
          internal_api:
          - 172.16.1.20
          - 172.16.1.21
          - 172.16.1.22
          external:
          - 10.0.0.40
          - 10.0.0.57
          - 10.0.0.104
        ComputeLeaf1IPs:
          ctlplane:
          - 192.168.25.100
          - 192.168.25.101
          internal_api:
          - 172.16.2.100
          - 172.16.2.101
        ComputeLeaf2IPs:
          ctlplane:
          - 192.168.26.100
          - 192.168.26.101
          internal_api:
          - 172.16.3.100
          - 172.16.3.101

      선택한 IP 주소가 네트워크 환경 파일에 정의된 각 네트워크에 대해 할당 풀 외부에 속하는지 확인합니다. 예를 들어 internal_api 할당이 자동으로 선택된 IP와 충돌하지 않도록 InternalApiAllocationPools 범위를 벗어나는지 확인합니다. 또한 IP 할당이 VIP 구성과 충돌하지 않는지 확인합니다(예: 13.4절. “예측 가능한 가상 IP 할당”참조) 또는 외부 로드 밸런싱( 21.4절. “외부 로드 밸런싱 구성”참조).

      중요

      Overcloud 노드가 삭제되면 IP 목록의 항목을 제거하지 마십시오. IP 목록은 노드를 삭제해도 변경되지 않는 기본 heat 인덱스를 기반으로 합니다. 목록에 지정된 항목이 더 이상 사용되지 않음을 나타내려면 IP 값을 DELETED 또는 UNUSED 와 같은 값으로 바꿉니다. 항목은 변경 또는 추가만 IP 목록에서 제거해서는 안 됩니다.

  3. 배포 중에 이 구성을 적용하려면 openstack overcloud deploy 명령을 사용하여 predictive _ips.yaml 환경 파일을 포함합니다.

    중요

    네트워크 분리를 사용하는 경우 network-isolation .yaml 파일 뒤에 predictive_ips.yaml 파일을 포함합니다.

    $ openstack overcloud deploy --templates \
      -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
      -e ~/templates/predictive_ips.yaml \
      [OTHER OPTIONS]

13.4. 예측 가능한 가상 IP 할당

각 노드에 대해 예측 가능한 IP 주소를 정의하는 것 외에도 클러스터형 서비스에 대해 예측 가능한 VIP(가상 IP)를 정의할 수도 있습니다.

절차

  • 네트워크 환경 파일을 편집하고 parameter_defaults 섹션에 VIP 매개변수를 추가합니다.

    parameter_defaults:
      ...
      # Predictable VIPs
      ControlFixedIPs: [{'ip_address':'192.168.201.101'}]
      InternalApiVirtualFixedIPs: [{'ip_address':'172.16.0.9'}]
      PublicVirtualFixedIPs: [{'ip_address':'10.1.1.9'}]
      StorageVirtualFixedIPs: [{'ip_address':'172.18.0.9'}]
      StorageMgmtVirtualFixedIPs: [{'ip_address':'172.19.0.9'}]
      RedisVirtualFixedIPs: [{'ip_address':'172.16.0.8'}]
      OVNDBsVirtualFixedIPs: [{'ip_address':'172.16.0.7'}]

    해당 할당 풀 범위 외부에서 이러한 IP를 선택합니다. 예를 들어 InternalApi AllocationPools 범위에 없는 InternalApiVirtualFixedIP s의 IP 주소를 선택합니다.

참고

이 단계는 기본 내부 로드 밸런싱 구성을 사용하는 오버클라우드에만 사용됩니다. 외부 로드 밸런서를 사용하여 VIP를 할당하려면 오버클라우드 전용 외부 로드 밸런싱 가이드의 절차를 사용하십시오.

14장. 오버클라우드 공용 끝점에서 SSL/TLS 활성화

기본적으로 오버클라우드는 오버클라우드 서비스에 암호화되지 않은 엔드포인트를 사용합니다. 오버클라우드에서 SSL/TLS를 활성화하려면 SSL/TLS 인증서를 구성하고 오버클라우드 배포 명령에 포함해야 합니다.

참고

이 프로세스는 공용 API 엔드포인트에만 SSL/TLS를 활성화합니다. Internal 및 Admin API는 암호화되지 않은 상태로 유지됩니다.

사전 요구 사항

  • 공용 API의 엔드포인트를 정의하는 네트워크 격리입니다.
  • openssl-perl 패키지가 설치되어 있습니다.

14.1. 서명 호스트 초기화

서명 호스트는 새 인증서를 생성하고 인증 기관을 통해 서명하는 호스트입니다. 선택한 서명 호스트에서 SSL 인증서를 생성한 적이 없는 경우 새 인증서에 서명할 수 있도록 호스트를 초기화해야 할 수 있습니다.

절차

  1. /etc/pki/CA/index.txt 파일에는 서명된 모든 인증서의 기록이 포함되어 있습니다. 파일 시스템 경로와 index.txt 파일이 있는지 확인합니다.

    $ sudo mkdir -p /etc/pki/CA
    $ sudo touch /etc/pki/CA/index.txt
  2. /etc/pki/CA/serial 파일은 서명할 다음 인증서에 사용할 다음 일련번호를 식별합니다. 이 파일이 있는지 확인합니다. 파일이 없는 경우 새 시작 값으로 새 파일을 생성합니다.

    $ echo '1000' | sudo tee /etc/pki/CA/serial

14.2. 인증 기관 생성

일반적으로는 외부 인증 기관을 통해 SSL/TLS 인증서에 서명합니다. 고유한 인증 기관을 사용하려는 경우도 있습니다. 예를 들어 내부 전용 인증 기관을 사용할 수도 있습니다.

절차

  1. 인증 기관 역할을 하는 키와 인증서 쌍을 생성합니다.

    $ openssl genrsa -out ca.key.pem 4096
    $ openssl req  -key ca.key.pem -new -x509 -days 7300 -extensions v3_ca -out ca.crt.pem
  2. openssl req 명령은 기관에 대한 특정 세부 정보를 요청합니다. 메시지가 나타나면 해당 세부 정보를 입력합니다. 이 명령을 수행하면 ca.crt.pem이라는 인증 기관 파일이 생성됩니다.
  3. enable-tls.yaml 파일에서 인증서 위치를 PublicTLSCAFile 매개변수 값으로 설정합니다. 인증서 위치를 PublicTLSCAFile 매개변수 값으로 설정하면 CA 인증서 경로가 clouds.yaml 인증 파일에 추가됩니다.

    parameter_defaults:
        PublicTLSCAFile: /etc/pki/ca-trust/source/anchors/cacert.pem

14.3. 클라이언트에 인증 기관 추가

외부 클라이언트가 SSL/TLS를 사용하여 통신하려는 경우 Red Hat OpenStack Platform 환경에 액세스해야 하는 각 클라이언트에 인증 기관 파일을 복사합니다.

절차

  1. 클라이언트 시스템에 인증 기관을 복사합니다.

    $ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
  2. 각 클라이언트에 인증 기관 파일을 복사한 후 각 클라이언트에서 다음 명령을 실행하여 인증 기관 신뢰 번들에 인증서를 추가합니다.

    $ sudo update-ca-trust extract

14.4. SSL/TLS 키 생성

OpenStack 환경에서 SSL/TLS를 활성화하려면 인증서를 생성하기 위한 SSL/TLS 키가 필요합니다.

절차

  1. 다음 명령을 실행하여 SSL/TLS 키(server.key.pem)를 생성합니다.

    $ openssl genrsa -out server.key.pem 2048

14.5. SSL/TLS 인증서 서명 요청 생성

인증서 서명 요청을 생성하려면 다음 단계를 완료합니다.

절차

  1. 기본 OpenSSL 설정 파일을 복사합니다.

    $ cp /etc/pki/tls/openssl.cnf .
  2. openssl.cnf 파일을 편집하고 director에 사용할 SSL 매개변수를 설정합니다. 수정할 매개변수 유형의 예제는 다음과 같습니다.

    [req]
    distinguished_name = req_distinguished_name
    req_extensions = v3_req
    
    [req_distinguished_name]
    countryName = Country Name (2 letter code)
    countryName_default = AU
    stateOrProvinceName = State or Province Name (full name)
    stateOrProvinceName_default = Queensland
    localityName = Locality Name (eg, city)
    localityName_default = Brisbane
    organizationalUnitName = Organizational Unit Name (eg, section)
    organizationalUnitName_default = Red Hat
    commonName = Common Name
    commonName_default = 192.168.0.1
    commonName_max = 64
    
    [ v3_req ]
    # Extensions to add to a certificate request
    basicConstraints = CA:FALSE
    keyUsage = nonRepudiation, digitalSignature, keyEncipherment
    subjectAltName = @alt_names
    
    [alt_names]
    IP.1 = 192.168.0.1
    DNS.1 = instack.localdomain
    DNS.2 = vip.localdomain
    DNS.3 = 192.168.0.1

    commonName_default를 다음 항목 중 하나로 설정합니다.

    • IP 주소를 사용하여 SSL/TLS를 통해 director에 액세스하는 경우 undercloud.conf 파일의 undercloud_public_host 매개변수를 사용합니다.
    • 정규화된 도메인 이름을 사용하여 SSL/TLS을 통해 director에 액세스하는 경우 도메인 이름을 사용합니다.

    alt_names 섹션을 편집하여 다음 항목을 포함합니다.

    • IP - 클라이언트가 SSL을 통해 director에 액세스하는 데 사용하는 IP 주소 목록입니다.
    • DNS - 클라이언트가 SSL을 통해 director에 액세스하는 데 사용하는 도메인 이름 목록입니다. 또한 공용 API IP 주소를 alt_names 섹션 끝에 DNS 항목으로 추가합니다.
    참고

    openssl.cnf에 대한 자세한 내용을 보려면 man openssl.cnf 명령을 실행합니다.

  3. 다음 명령을 실행하여 인증서 서명 요청(server.csr.pem)을 생성합니다.

    $ openssl req -config openssl.cnf -key server.key.pem -new -out server.csr.pem

    -key 옵션을 사용하여 OpenStack SSL/TLS 키를 지정합니다.

이 명령을 실행하면 인증서 서명 요청인 server.csr.pem 파일이 생성됩니다. 이 파일을 사용하여 OpenStack SSL/TLS 인증서를 생성합니다.

14.6. SSL/TLS 인증서 생성

OpenStack 환경에 대한 SSL/TLS 인증서를 생성하려면 다음과 같은 파일이 필요합니다.

openssl.cnf
v3 확장을 지정하는 사용자 지정 설정 파일입니다.
server.csr.pem
인증서를 생성하고 인증 기관을 통해 서명하는 인증서 서명 요청입니다.
ca.crt.pem
인증서에 서명하는 인증 기관입니다.
ca.key.pem
인증 기관 개인 키입니다.

절차

  1. 다음 명령을 실행하여 언더클라우드 또는 오버클라우드에 대한 인증서를 생성합니다.

    $ sudo openssl ca -config openssl.cnf -extensions v3_req -days 3650 -in server.csr.pem -out server.crt.pem -cert ca.crt.pem -keyfile ca.key.pem

    이 명령은 다음 옵션을 사용합니다.

    -config
    사용자 지정 구성 파일, 즉 v3 확장이 포함된 openssl.cnf 파일을 사용합니다.
    -extensions v3_req
    v3 확장을 활성화합니다.
    -days
    인증서가 만료될 때까지 남은 기간(일)을 정의합니다.
    -in'
    인증서 서명 요청입니다.
    -out
    생성된 서명된 인증서입니다.
    -cert
    인증 기관 파일입니다.
    -keyfile
    인증 기관 개인 키입니다.

이 명령을 실행하면 server.crt.pem이라는 새 인증서가 생성됩니다. 이 인증서를 OpenStack SSL/TLS 키와 함께 사용합니다.

14.7. SSL/TLS 활성화

오버클라우드에서 SSL/TLS를 활성화하려면 SSL/TLS 인증서 및 개인 키에 대한 매개변수가 포함된 환경 파일을 생성해야 합니다.

절차

  1. heat 템플릿 컬렉션에서 enable-tls.yaml 환경 파일을 복사합니다.

    $ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml ~/templates/.
  2. 이 파일을 편집하여 해당 매개변수에 대해 다음과 같이 변경합니다.

    SSLCertificate

    인증서 파일(server.crt.pem)의 내용을 SSLCertificate 매개변수에 복사합니다.

    parameter_defaults:
      SSLCertificate: |
        -----BEGIN CERTIFICATE-----
        MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGS
        ...
        sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQ
        -----END CERTIFICATE-----
    중요

    인증서 콘텐츠에는 모든 새 행에 대해 동일한 들여쓰기 수준이 필요합니다.

    SSLIntermediateCertificate

    중간 인증서가 있는 경우 중간 인증서의 내용을 SSLIntermediateCertificate 매개변수로 복사합니다.

    parameter_defaults:
      SSLIntermediateCertificate: |
        -----BEGIN CERTIFICATE-----
        sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQbIxEpIzrgvpBCwUAMFgxCzAJB
        ...
        MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGSIb3DQE
        -----END CERTIFICATE-----
    중요

    인증서 콘텐츠에는 모든 새 행에 대해 동일한 들여쓰기 수준이 필요합니다.

    SSLKey

    개인 키(server.key.pem)의 콘텐츠를 SSLKey 매개변수로 복사합니다.

    parameter_defaults:
      ...
      SSLKey: |
        -----BEGIN RSA PRIVATE KEY-----
        MIIEowIBAAKCAQEAqVw8lnQ9RbeI1EdLN5PJP0lVO
        ...
        ctlKn3rAAdyumi4JDjESAXHIKFjJNOLrBmpQyES4X
        -----END RSA PRIVATE KEY-----
    중요

    개인 키 콘텐츠에는 모든 새 행에 대해 동일한 들여쓰기 수준이 필요합니다.

14.8. 루트 인증서 삽입

인증서 서명자가 오버클라우드 이미지의 기본 신뢰 저장소에 없는 경우 인증 기관을 오버클라우드 이미지에 삽입해야 합니다.

절차

  1. heat 템플릿 컬렉션에서 inject-trust-anchor-hiera.yaml 환경 파일을 복사합니다.

    $ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/inject-trust-anchor-hiera.yaml ~/templates/.

이 파일을 편집하여 해당 매개변수에 대해 다음과 같이 변경합니다.

CAMap

오버클라우드에 삽입할 각 CA(인증 기관 콘텐츠)를 나열합니다. 오버클라우드에는 언더클라우드 및 오버클라우드의 인증서에 서명하는 데 사용되는 CA 파일이 필요합니다. 루트 인증 기관 파일(ca.crt.pem)의 콘텐츠를 항목으로 복사합니다. 예를 들어 CAMap 매개변수는 다음과 같을 수 있습니다.

parameter_defaults:
  CAMap:
    ...
    undercloud-ca:
      content: |
        -----BEGIN CERTIFICATE-----
        MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCS
        BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBw
        UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBA
        -----END CERTIFICATE-----
    overcloud-ca:
      content: |
        -----BEGIN CERTIFICATE-----
        MIIDBzCCAe+gAwIBAgIJAIc75A7FD++DMA0GCS
        BAMMD3d3dy5leGFtcGxlLmNvbTAeFw0xOTAxMz
        Um54yGCARyp3LpkxvyfMXX1DokpS1uKi7s6CkF
        -----END CERTIFICATE-----
중요

인증 기관 콘텐츠에는 모든 새 행에 대해 동일한 들여쓰기 수준이 필요합니다.

CA Map 매개변수를 사용하여 추가 CA 를 삽입할 수도 있습니다.

14.9. DNS 끝점 구성

DNS 호스트 이름을 사용하여 SSL/TLS를 통해 오버클라우드에 액세스하는 경우 /usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml 파일을 /home/stack/templates 디렉터리에 복사합니다.

참고

이 환경 파일이 초기 배포에 포함되지 않은 경우 TLS-everywhere 아키텍처로 재배포할 수 없습니다.

필요한 경우 사용자 지정 네트워크의 매개 변수를 추가하여 모든 필드에 대해 호스트 및 도메인 이름을 구성합니다.

CloudDomain
호스트의 DNS 도메인.
CloudName
오버클라우드 끝점의 DNS 호스트 이름입니다.
CloudNameCtlplane
프로비저닝 네트워크 끝점의 DNS 이름입니다.
CloudNameInternal
내부 API 끝점의 DNS 이름입니다.
CloudNameStorage
스토리지 끝점의 DNS 이름입니다.
CloudNameStorageManagement
스토리지 관리 끝점의 DNS 이름입니다.
DnsServers
사용할 DNS 서버 목록입니다. 구성된 DNS 서버에는 공용 API의 IP 주소와 일치하는 구성된 CloudName 에 대한 항목이 포함되어야 합니다.

절차

  • 새 환경 파일이나 기존 환경 파일에서 매개 변수 기본값 아래 사용할 DNS 서버 목록을 추가합니다.

    parameter_defaults:
      DnsServers: ["10.0.0.254"]
      ....

14.10. 오버클라우드 생성 중 환경 파일 추가

배포 프로세스에 환경 파일을 포함하려면 배포 명령 openstack overcloud deploy 와 함께 -e 옵션을 사용합니다. 이 섹션의 환경 파일을 다음 순서로 추가합니다.

  • SSL/TLS(enable-tls.yaml)를 활성화하는환경 파일
  • DNS 호스트 이름(custom-domain.yaml)을 설정하는 환경 파일
  • 루트 인증 기관을 삽입할 환경 파일(inject-trust-anchor-hiera.yaml)
  • 공용 끝점 매핑을 설정하는 환경 파일은 다음과 같습니다.

    • DNS 이름을 사용하여 공용 엔드포인트에 액세스하는 경우 /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml을 사용합니다.
    • 공용 엔드포인트에 액세스하는 데 IP 주소를 사용하는 경우 /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-ip.yaml을 사용합니다.

절차

  • 다음 배포 명령 스니펫을 SSL/TLS 환경 파일을 포함하는 방법의 예로 사용합니다.
$ openstack overcloud deploy --templates \
[...]
-e /home/stack/templates/enable-tls.yaml \
-e ~/templates/custom-domain.yaml \
-e ~/templates/inject-trust-anchor-hiera.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml

14.11. SSL/TLS 인증서 수동 업데이트

TLS(TLS-e) 프로세스에서 자동 생성되지 않는 자체 SSL/TLS 인증서를 사용하는 경우 다음 단계를 완료합니다.

절차

  1. 다음 콘텐츠를 사용하여 heat 템플릿을 편집합니다.

    • enable-tls.yaml 파일을 편집하고 SSLCertificate, SSL KeySSLIntermediateCertificate 매개변수를 업데이트합니다.
    • 인증 기관이 변경된 경우 inject-trust-anchor-hiera.yaml 파일을 편집하고 CAMap 매개변수를 업데이트합니다.
  2. 배포 명령을 다시 실행합니다.

    $ openstack overcloud deploy --templates \
    [...]
    -e /home/stack/templates/enable-tls.yaml \
    -e ~/templates/custom-domain.yaml \
    -e ~/templates/inject-trust-anchor-hiera.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml
  3. director에서 각 컨트롤러에 대해 다음 명령을 실행합니다.

    ssh heat-admin@<controller> sudo podman \
    restart $(podman ps --format="{{.Names}}" | grep -w -E 'haproxy(-bundle-.*-[0-9]+)?')

15장. ID 관리를 사용하여 내부 및 공용 끝점에서 SSL/TLS 활성화

특정 오버클라우드 끝점에서 SSL/TLS를 활성화할 수 있습니다. 필요한 인증서 수로 인해 director는 Red Hat IdM(Identity Management) 서버와 통합되어 인증 기관 역할을 하며 오버클라우드 인증서를 관리합니다.

OpenStack 구성 요소에서 TLS 지원 상태를 확인하려면 TLS 활성화 상태 매트릭스 를 참조하십시오.

15.1. OpenStack에 대한 IdM(Identity Management) 서버 권장 사항

Red Hat은 IdM 서버 및 OpenStack 환경을 통합하는 데 도움이 되는 다음 정보를 제공합니다.

IdM 설치를 위해 Red Hat Enterprise Linux 준비에 대한 자세한 내용은 Identity Management 설치를 참조하십시오.

ipa-server-install 명령을 실행하여 IdM을 설치 및 구성합니다. 명령 매개변수를 사용하여 대화형 프롬프트를 건너뛸 수 있습니다. IdM 서버가 Red Hat OpenStack Platform 환경과 통합할 수 있도록 다음 권장 사항을 사용하십시오.

표 15.1. 매개변수 권장 사항

옵션권장 사항

--admin-password

제공하는 값을 기록해 둡니다. IdM을 사용하도록 Red Hat OpenStack Platform을 구성할 때 이 암호가 필요합니다.

--ip-address

제공하는 값을 기록해 둡니다. 언더클라우드 및 오버클라우드 노드에는 이 IP 주소에 대한 네트워크 액세스가 필요합니다.

--setup-dns

IdM 서버에 통합 DNS 서비스를 설치하려면 이 옵션을 사용합니다. 언더클라우드 및 오버클라우드 노드는 도메인 이름 확인을 위해 IdM 서버를 사용합니다.

--auto-forwarders

/etc/resolv.conf 의 주소를 DNS 전달자로 사용하려면 이 옵션을 사용합니다.

--auto-reverse

IdM 서버 IP 주소에 대한 역방향 레코드 및 영역을 확인하려면 이 옵션을 사용합니다. 역방향 레코드 또는 영역을 확인할 수 없는 경우 IdM은 역방향 영역을 생성합니다. 이를 통해 IdM 배포가 간소화됩니다.

--ntp-server, --ntp-pool

이러한 옵션 중 하나 또는 둘 다를 사용하여 NTP 소스를 구성할 수 있습니다. IdM 서버와 OpenStack 환경 모두 올바르고 동기화된 시간이 있어야 합니다.

Red Hat OpenStack Platform 노드와의 통신을 활성화하려면 IdM에 필요한 방화벽 포트를 열어야 합니다. 자세한 내용은 IdM에 필요한 포트 열기를 참조하십시오.

15.2. Ansible을 사용하여 TLS-e 구현

새로운 tripleo-ipa 방법을 사용하여 TLS(TLS-e)라고 하는 오버클라우드 끝점에서 SSL/TLS를 활성화할 수 있습니다. 필요한 인증서 수로 인해 Red Hat OpenStack Platform은 Red Hat IdM(Identity Management)과 통합됩니다. tripleo-ipa 를 사용하여 TLS-e를 구성하는 경우 IdM은 인증 기관입니다.

사전 요구 사항

언더클라우드의 모든 구성 단계(예: stack 사용자 생성)가 완료되었는지 확인합니다. 자세한 내용은 Director 설치 및 사용을 참조하십시오.

절차

다음 절차에 따라 Red Hat OpenStack Platform의 새로운 설치 또는 TLS-e로 구성하려는 기존 배포에 대해 TLS-e를 구현합니다. 사전 프로비저닝된 노드에 TLS-e를 사용하여 Red Hat OpenStack Platform을 배포하는 경우 이 방법을 사용해야 합니다.

참고

기존 환경에 대해 TLS-e를 구현하는 경우 openstack undercloud install, openstack overcloud deploy 와 같은 명령을 실행해야 합니다. 이러한 절차는 멱등이며 업데이트된 템플릿 및 구성 파일과 일치하도록 기존 배포 구성만 조정합니다.

  1. /etc/resolv.conf 파일을 구성합니다.

    /etc/resolv.conf 의 언더클라우드에 적절한 검색 도메인과 이름 서버를 설정합니다. 예를 들어 배포 도메인이 example.com 이고 FreeIPA 서버의 도메인이 bigcorp.com 인 경우 /etc/resolv.conf에 다음 행을 추가합니다.

    search example.com bigcorp.com
    nameserver $IDM_SERVER_IP_ADDR
  2. 필요한 소프트웨어를 설치합니다.

    sudo dnf install -y python3-ipalib python3-ipaclient krb5-devel
  3. 환경에 고유한 값을 사용하여 환경 변수를 내보냅니다.

    export IPA_DOMAIN=bigcorp.com
    export IPA_REALM=BIGCORP.COM
    export IPA_ADMIN_USER=$IPA_USER
    export IPA_ADMIN_PASSWORD=$IPA_PASSWORD
    export IPA_SERVER_HOSTNAME=ipa.bigcorp.com
    export UNDERCLOUD_FQDN=undercloud.example.com
    export USER=stack
    export CLOUD_DOMAIN=example.com
    참고

    IdM 사용자 자격 증명은 새 호스트 및 서비스를 추가할 수 있는 관리자여야 합니다.

  4. 언더클라우드에서 undercloud-ipa-install.yaml ansible 플레이북을 실행합니다.

    ansible-playbook \
    --ssh-extra-args "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" \
    /usr/share/ansible/tripleo-playbooks/undercloud-ipa-install.yaml
  5. undercloud.conf에 다음 매개 변수를 추가합니다.

    undercloud_nameservers = $IDM_SERVER_IP_ADDR
    overcloud_domain_name = example.com
  6. 언더클라우드를 배포합니다.

    openstack undercloud install

검증

다음 단계를 완료하여 언더클라우드가 올바르게 등록되었는지 확인합니다.

  1. IdM에 호스트를 나열합니다.

    $ kinit admin
    $ ipa host-find
  2. 언더클라우드에 /etc/novajoin/krb5.keytab 이 있는지 확인합니다.

    ls /etc/novajoin/krb5.keytab
참고

novajoin 디렉터리 이름은 레거시 명명 목적으로만 사용됩니다.

오버클라우드에서 TLS-e 구성

TLS-e(TLS-e)를 사용하여 오버클라우드를 배포하면 Undercloud 및 Overcloud의 IP 주소가 IdM에 자동으로 등록됩니다.

참고

자동 IP 주소 등록을 비활성화하려면 IDMModifyDNS heat 매개변수를 false로 설정합니다.

parameter_defaults:
    ....
    IdMModifyDNS: false
  1. 오버클라우드를 배포하기 전에 다음과 유사한 내용을 사용하여 YAML 파일 tls-parameters.yaml 을 생성합니다. 선택한 값은 환경에 따라 다릅니다.

    • DnsServers 매개 변수에는 IdM 서버의 IP 주소를 반영하는 값이 있어야 합니다.
    • IdM 서버의 도메인이 클라우드 도메인과 다른 경우 DnsSearchDomains 매개변수에 포함합니다. 예를 들면 다음과 같습니다. DnsSearchDomains: ["example.com", "bigcorp.com"]
    • 사전 프로비저닝된 노드가 있는 경우 오버클라우드 노드에 필요한 패키지를 설치하려면 IDMInstallClientPackages 매개변수 값을 true 로 설정합니다.
    • OS::TripleO::Services::IpaClient 매개변수의 표시된 값은 enable-internal-tls.yaml 파일의 기본 설정을 재정의합니다. tls-parameters.yaml 파일이 openstack overcloud deploy 명령에서 enable-internal-tls.yaml 을 따르는지 확인해야 합니다.
    • cinder가 active-active로 구성된 DCN(분산 계산 노드) 아키텍처를 실행하는 경우 EnableEtcdInternalTLS 매개변수를 true 로 추가하고 설정해야 합니다.

      parameter_defaults:
          DnsSearchDomains: ["example.com"]
          DnsServers: ["192.168.1.13"]
          CloudDomain: example.com
          CloudName: overcloud.example.com
          CloudNameInternal: overcloud.internalapi.example.com
          CloudNameStorage: overcloud.storage.example.com
          CloudNameStorageManagement: overcloud.storagemgmt.example.com
          CloudNameCtlplane: overcloud.ctlplane.example.com
          IdMServer: freeipa-0.redhat.local
          IdMDomain: redhat.local
          IdMInstallClientPackages: False
      
      resource_registry:
            OS::TripleO::Services::IpaClient: /usr/share/openstack-tripleo-heat-templates/deployment/ipa/ipaservices-baremetal-ansible.yaml
  2. Overcloud를 배포합니다. 배포 명령에 tls-parameters.yaml을 포함해야 합니다.

    DEFAULT_TEMPLATES=/usr/share/openstack-tripleo-heat-templates/
    CUSTOM_TEMPLATES=/home/stack/templates
    
    openstack overcloud deploy \
    -e ${DEFAULT_TEMPLATES}/environments/ssl/tls-everywhere-endpoints-dns.yaml \
    -e ${DEFAULT_TEMPLATES}/environments/services/haproxy-public-tls-certmonger.yaml \
    -e ${DEFAULT_TEMPLATES}/environments/ssl/enable-internal-tls.yaml \
    -e ${CUSTOM_TEMPLATES}/tls-parameters.yaml \
    ...
  3. 끝점 목록에 대한 keystone을 쿼리하여 각 끝점이 HTTPS를 사용하고 있는지 확인합니다.

    openstack endpoint list

15.3. novajoin에 Red Hat IdM(Identity Manager)에 노드 등록

novajoin은 배포 프로세스의 일부로 Red Hat IdM(Identity Manager)에 노드를 등록하는 데 사용하는 기본 도구입니다. Red Hat은 TLS-e를 사용하여 언더클라우드 및 오버클라우드를 설정하기 위해 기본 novajoin 솔루션을 통해 새로운 ansible 기반 tripleo-ipa 솔루션을 권장합니다. 자세한 내용은 Ansible을 사용하여 TLS-e 구현에서 참조하십시오.

나머지 IdM 통합을 진행하기 전에 등록 프로세스를 수행해야 합니다. 등록 프로세스에는 다음 단계가 포함됩니다.

  1. CA(인증 기관)에 언더클라우드 노드 추가
  2. IdM에 언더클라우드 노드 추가
  3. 선택 사항: IdM 서버를 오버클라우드의 DNS 서버로 설정
  4. 환경 파일 준비 및 오버클라우드 배포
  5. IdM 및 RHOSP에서 오버클라우드 등록 테스트
  6. 선택 사항: IdM에 novajoin의 DNS 항목 추가
참고

현재 novajoin에 IdM 등록은 언더클라우드 및 오버클라우드 노드에서만 사용할 수 있습니다. 오버클라우드 인스턴스에 대한 novajoin 통합은 이후 릴리스에서 지원될 예정입니다.

15.4. 인증 기관에 언더클라우드 노드 추가

오버클라우드를 배포하기 전에 언더클라우드 노드에 python3-novajoin 패키지를 설치하고 novajoin-ipa-setup 스크립트를 실행하여 인증 기관(CA)에 언더클라우드를 추가합니다.

절차

  1. 언더클라우드 노드에서 python3-novajoin 패키지를 설치합니다.

    $ sudo dnf install python3-novajoin
  2. 언더클라우드 노드에서 novajoin-ipa-setup 스크립트를 실행하고 배포에 맞게 값을 조정합니다.

    $ sudo /usr/libexec/novajoin-ipa-setup \
        --principal admin \
        --password <IdM admin password> \
        --server <IdM server hostname> \
        --realm <realm> \
        --domain <overcloud cloud domain> \
        --hostname <undercloud hostname> \
        --precreate

    결과 OTP(One-Time Password)를 사용하여 Undercloud를 등록합니다.

15.5. Red Hat IdM(Identity Manager)에 언더클라우드 노드 추가

CA(인증 기관)에 언더클라우드 노드를 추가한 후, 언더클라우드를 IdM에 등록하고 novajoin을 구성합니다. undercloud.conf 파일의 [DEFAULT] 섹션에 다음 설정을 구성합니다.

절차

  1. novajoin 서비스를 활성화합니다.

    [DEFAULT]
    enable_novajoin = true
  2. IdM을 사용하여 언더클라우드 노드를 등록할 수 있도록 1회성 암호(OTP)를 설정합니다.

    ipa_otp = <otp>
  3. neutron의 DHCP 서버에서 제공할 오버클라우드의 도메인 이름을 설정합니다.

    overcloud_domain_name = <domain>
  4. 언더클라우드의 호스트 이름을 설정합니다.

    undercloud_hostname = <undercloud FQDN>
  5. IdM을 언더클라우드의 이름 서버로 설정합니다.

    undercloud_nameservers = <IdM IP>
  6. 더 큰 환경의 경우 novajoin 연결 시간 제한 값을 검토하십시오. undercloud.conf 파일에서 undercloud-timeout.yaml이라는 새 파일에 참조를 추가합니다.

    hieradata_override = /home/stack/undercloud-timeout.yaml

    undercloud-timeout.yaml 에 다음 옵션을 추가합니다. 시간 제한 값을 초 단위로 지정할 수 있습니다(예: 5):

    nova::api::vendordata_dynamic_connect_timeout: <timeout value>
    nova::api::vendordata_dynamic_read_timeout: <timeout value>
  7. 선택 사항: 로컬 openSSL 인증 기관에서 director의 공용 끝점에 대한 SSL 인증서를 생성하도록 하려면 generate_service_certificate 매개변수를 true 로 설정합니다.

    generate_service_certificate = true
  8. undercloud.conf 파일을 저장합니다.
  9. 언더클라우드 배포 명령을 실행하여 기존 언더클라우드에 변경 사항을 적용합니다.

    $ openstack undercloud install

검증

다음 단계를 완료하여 언더클라우드가 올바르게 등록되었는지 확인합니다.

  1. IdM에 호스트를 나열합니다.

    $ kinit admin
    $ ipa host-find
  2. 언더클라우드에 /etc/novajoin/krb5.keytab 이 있는지 확인합니다.

    ls /etc/novajoin/krb5.keytab

15.6. Red Hat IdM(Identity Manager)을 오버클라우드의 DNS 서버로 설정

IdM 환경을 자동으로 감지하고 쉽게 등록하려면 IdM을 DNS 서버로 설정합니다. 이 절차는 선택 사항이지만 권장됩니다.

절차

  1. 언더클라우드에 연결합니다.

    $ source ~/stackrc
  2. IdM을 DNS 이름 서버로 사용하도록 컨트롤 플레인 서브넷을 구성합니다.

    $ openstack subnet set ctlplane-subnet --dns-nameserver  <idm_server_address>
  3. IdM 서버를 사용하도록 환경 파일에서 DnsServers 매개변수를 설정합니다.

    parameter_defaults:
      DnsServers: ["<idm_server_address>"]

    일반적으로 이 매개변수는 사용자 지정 network-environment.yaml 파일에 정의됩니다.

15.7. 환경 파일 준비 및 novajoin 등록으로 오버클라우드 배포

IdM 통합으로 오버클라우드를 배포하려면 환경 파일을 생성하고 편집하여 오버클라우드에 정의된 도메인에 따라 사용자 정의 도메인 매개변수 CloudDomainCloudName 을 사용하도록 오버클라우드를 구성하고 편집합니다. 그런 다음 배포에 필요한 모든 환경 파일과 함께 오버클라우드를 배포합니다.

절차

  1. /usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml 환경 파일의 사본을 생성합니다.

    $ cp /usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml \
      /home/stack/templates/custom-domain.yaml
  2. /home/stack/templates/custom-domain.yaml 환경 파일을 편집하고 배포에 맞게 CloudDomainCloudName* 값을 설정합니다.

    parameter_defaults:
      CloudDomain: lab.local
      CloudName: overcloud.lab.local
      CloudNameInternal: overcloud.internalapi.lab.local
      CloudNameStorage: overcloud.storage.lab.local
      CloudNameStorageManagement: overcloud.storagemgmt.lab.local
      CloudNameCtlplane: overcloud.ctlplane.lab.local
  3. 사용자 환경에 적합한 TLS 구현을 선택합니다.

    • enable-tls.yaml 환경 파일을 사용하여 사용자 정의 인증서로 외부 끝점을 보호합니다.

      1. /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml/home/stack/templates 에 복사합니다.
      2. 사용자 정의 인증서 및 키를 포함하도록 /home/stack/enable-tls.yaml 환경 파일을 수정합니다.
      3. 배포에 다음 환경 파일을 포함하여 내부 및 외부 엔드포인트를 보호합니다.

        • enable-internal-tls.yaml
        • tls-every-endpoints-dns.yaml
        • custom-domain.yaml
        • enable-tls.yaml

          openstack overcloud deploy \
            --templates \
            -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \
            -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \
            -e /home/stack/templates/custom-domain.yaml \
            -e /home/stack/templates/enable-tls.yaml
    • haproxy-public-tls-certmonger.yaml 환경 파일을 사용하여 IdM 발행 인증서가 있는 외부 엔드포인트를 보호합니다. 이 구현을 위해 novajoin에서 사용하는 VIP 끝점에 대한 DNS 항목을 생성해야 합니다.

      1. novajoin에서 사용하는 VIP 엔드포인트에 대한 DNS 항목을 생성해야 합니다. '/home/stack/templates의 사용자 지정 network-environment.yaml 파일에 있는 오버클라우드 네트워크를 식별합니다.

        parameter_defaults:
            ControlPlaneDefaultRoute: 192.168.24.1
            ExternalAllocationPools:
            -   end: 10.0.0.149
                start: 10.0.0.101
            InternalApiAllocationPools:
            -   end: 172.17.1.149
                start: 172.17.1.10
            StorageAllocationPools:
            -   end: 172.17.3.149
                start: 172.17.3.10
            StorageMgmtAllocationPools:
            -   end: 172.17.4.149
                start: 172.17.4.10
      2. heat 템플릿에서 각 오버클라우드 네트워크의 가상 IP 주소 목록을 생성합니다(예: /home/stack/public_vib.yaml ).

        parameter_defaults:
            ControlFixedIPs: [{'ip_address':'192.168.24.101'}]
            PublicVirtualFixedIPs: [{'ip_address':'10.0.0.101'}]
            InternalApiVirtualFixedIPs: [{'ip_address':'172.17.1.101'}]
            StorageVirtualFixedIPs: [{'ip_address':'172.17.3.101'}]
            StorageMgmtVirtualFixedIPs: [{'ip_address':'172.17.4.101'}]
            RedisVirtualFixedIPs: [{'ip_address':'172.17.1.102'}]
      3. 필요에 따라 각 VIP 및 영역에 대한 IdM에 DNS 항목을 추가합니다.

        ipa dnsrecord-add lab.local overcloud --a-rec 10.0.0.101
        ipa dnszone-add ctlplane.lab.local
        ipa dnsrecord-add ctlplane.lab.local overcloud --a-rec 192.168.24.101
        ipa dnszone-add internalapi.lab.local
        ipa dnsrecord-add internalapi.lab.local overcloud --a-rec 172.17.1.101
        ipa dnszone-add storage.lab.local
        ipa dnsrecord-add storage.lab.local overcloud --a-rec 172.17.3.101
        ipa dnszone-add storagemgmt.lab.local
        ipa dnsrecord-add storagemgmt.lab.local overcloud --a-rec 172.17.4.101
      4. 배포에 다음 환경 파일을 포함하여 내부 및 외부 엔드포인트를 보호합니다.

        • enable-internal-tls.yaml
        • tls-everywhere-endpoints-dns.yaml
        • haproxy-public-tls-certmonger.yaml
        • custom-domain.yaml
        • public_vib.yaml

          openstack overcloud deploy \
            --templates \
             -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \
             -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \
             -e /usr/share/openstack-tripleo-heat-templates/environments/services/haproxy-public-tls-certmonger.yaml \
             -e /home/stack/templates/custom-domain.yaml \
             -e /home/stack/templates/public-vip.yaml
참고

novajoin을 사용하여 기존 배포에서 TLS-e를 구현할 수 없습니다.

16장. 이미지 가져오기 방법 및 공유 스테이징 영역 구성

OpenStack Image 서비스(glance)의 기본 설정은 Red Hat OpenStack Platform을 설치할 때 사용하는 heat 템플릿에 따라 결정됩니다. 이미지 서비스 heat 템플릿은 deployment/glance/glance-api-container-puppet.yaml 입니다.

다음 방법으로 이미지를 가져올 수 있습니다.

web-download
web-download 방법을 사용하여 URL에서 이미지를 가져옵니다.
glance-direct
glance-direct 방법을 사용하여 로컬 볼륨에서 이미지를 가져옵니다.

16.1. glance-settings.yaml 파일 생성 및 배포

사용자 지정 환경 파일을 사용하여 가져오기 매개 변수를 구성합니다. 이러한 매개변수는 코어 heat 템플릿 컬렉션에 있는 기본값을 재정의합니다. 예제 환경 콘텐츠에는 상호 운용 가능한 이미지 가져오기에 대한 매개변수가 포함되어 있습니다.

parameter_defaults:
  # Configure NFS backend
  GlanceBackend: file
  GlanceNfsEnabled: true
  GlanceNfsShare: 192.168.122.1:/export/glance

  # Enable glance-direct import method
  GlanceEnabledImportMethods: glance-direct,web-download

  # Configure NFS staging area (required for glance-direct import method)
  GlanceStagingNfsShare: 192.168.122.1:/export/glance-staging

GlanceBackend,GlanceNfsEnabled, GlanceNfsShare 매개 변수는 Advanced Overcloud Customization 가이드스토리지 구성 섹션에 정의되어 있습니다.

상호 운용 가능한 이미지 가져오기에 두 개의 새 매개 변수를 사용하여 가져오기 방법과 공유 NFS 스테이징 영역을 정의합니다.

GlanceEnabledImportMethods
사용 가능한 가져오기 방법, web-download(기본값) 및 glance-direct를 정의합니다. 이 매개변수는 web-download 이외의 추가 방법을 활성화하려는 경우에만 필요합니다.
GlanceStagingNfsShare
glance-direct 가져오기 메서드에서 사용하는 NFS 스테이징 영역을 구성합니다. 이 공간은 고가용성 클러스터 구성의 노드 간에 공유할 수 있습니다. 이 매개변수를 사용하려면 GlanceNfsEnabled 매개변수도 true 로 설정해야 합니다.

절차

  1. 새 파일(예: glance-settings.yaml )을 만듭니다. 예제의 구문을 사용하여 이 파일을 채웁니다.
  2. openstack overcloud deploy 명령에 glance-settings.yaml 파일과 배포와 관련된 기타 환경 파일을 포함합니다.

    $ openstack overcloud deploy --templates -e glance-settings.yaml

환경 파일 사용에 대한 자세한 내용은 Advanced Overcloud Customization 가이드의 Overcloud Creation에서 환경 파일 포함 섹션을 참조하십시오.

16.2. 이미지 웹 가져오기 소스 제어

옵션 glance-image-import.conf 파일에 URI 블록리스트 및 허용 목록을 추가하여 웹 가져오기 이미지 다운로드 소스를 제한할 수 있습니다.

다음 세 수준에서 이미지 소스 URI를 허용하거나 차단할 수 있습니다.

  • 스키마 (allowed_schemes, disallowed_schemes)
  • 호스트 (allowed_hosts, disallowed_hosts)
  • 포트 (allowed_ports, disallowed_ports)

모든 수준에서 허용 목록 및 blocklist를 모두 지정하면 허용 목록이 적용되고 블록리스트는 무시됩니다.

이미지 서비스(glance)는 다음 결정 로직을 적용하여 이미지 소스 URI의 유효성을 검사합니다.

  1. 스키마가 선택됩니다.

    1. 누락된 스키마: 거부
    2. 허용 목록이 있고 allowlist: reject에 체계가 없는 경우. 그렇지 않으면 C를 건너뛰고 2로 계속합니다.
    3. blocklist가 있고 체계가 blocklist: reject에 있는 경우.
  2. 호스트 이름이 선택됩니다.

    1. 누락된 호스트 이름: reject
    2. 허용 목록이 있고 allowlist: reject에 호스트 이름이 없는 경우. 그렇지 않으면 C를 건너뛰고 3으로 계속합니다.
    3. blocklist가 있고 blocklist: reject에 호스트 이름이 있는 경우.
  3. URI에 포트가 있는 경우 포트가 확인됩니다.

    1. 허용 목록이 있고 allowlist: reject에 포트가 없는 경우. 그렇지 않으면 B를 건너뛰고 4까지 계속합니다.
    2. blocklist가 있고, 포트가 blocklist: reject에 있는 경우.
  4. URI는 유효한 것으로 허용됩니다.

허용 목록에 포트를 추가하거나 블록 목록에 추가하지 않고 스키마를 허용하면 URI에 포트를 포함하지 않고 해당 스키마에 기본 포트를 사용하는 모든 URI가 허용됩니다. URI에 포트가 포함된 경우 URI는 기본 결정 논리에 따라 검증됩니다.

16.3. 이미지 가져오기 예

예를 들어 FTP의 기본 포트는 21입니다. ftp 는 허용된 스키마이므로 이 URL은 허용됩니다. ftp://example.org/some/resource 그러나 21은 포트 허용 목록에 없으므로 동일한 리소스에 대한 URL이 거부됩니다. ftp://example.org:21/some/resource

allowed_schemes = [http,https,ftp]
disallowed_schemes = []
allowed_hosts = []
disallowed_hosts = []
allowed_ports = [80,443]
disallowed_ports = []

16.4. 기본 이미지 가져오기 blocklist 및 허용 목록 설정

glance-image-import.conf 파일은 다음 기본 옵션이 포함된 선택적 파일입니다.

  • allowed_schemes - [http, https]
  • disallowed_schemes - 빈 목록
  • ALLOWED_HOSTS - 빈 목록
  • disallowed_hosts - 빈 목록
  • allowed_ports - [80, 443]
  • disallowed_ports - 빈 목록

기본값을 사용하는 경우 최종 사용자는 http 또는 https 스키마만 사용하여 URI에 액세스할 수 있습니다. 사용자가 지정할 수 있는 유일한 포트는 80443 입니다. 사용자는 포트를 지정할 필요는 없지만, 포트가 있는 경우 80 또는 443 이어야 합니다.

glance-image-import.conf 파일은 이미지 서비스 소스 코드 트리의 etc/ 하위 디렉터리에 있습니다. Red Hat OpenStack Platform 릴리스에 대한 올바른 분기를 찾고 있는지 확인하십시오.

16.5. VM 시작 위치를 제어하기 위해 이미지 가져오기에 메타데이터 삽입

최종 사용자는 이미지를 이미지 서비스에 업로드하고 이러한 이미지를 사용하여 VM을 시작할 수 있습니다. 이러한 사용자 제공(관리자 이외의) 이미지는 특정 계산 노드 세트에서 시작해야 합니다. 계산 노드에 인스턴스 할당은 이미지 메타데이터 속성으로 제어합니다.

Image property Injection 플러그인은 가져오는 동안 메타데이터 속성을 이미지에 삽입합니다. glance-image-import.conf 파일의 [image_import_opts] 및 [inject_metadata_properties] 섹션을 편집하여 속성을 지정합니다.

Image property Injection 플러그인을 활성화하려면 [image_import_opts] 섹션에 다음 행을 추가합니다.

[image_import_opts]
image_import_plugins = [inject_image_metadata]

특정 사용자 집합에서 제공하는 이미지에 대한 메타데이터 삽입을 제한하려면 ignore_user_roles 매개변수를 설정합니다. 예를 들어 다음 구성을 사용하여 property1 의 값과 속성 2 의 값 두 개를 관리자가 아닌 사용자가 다운로드한 이미지에 삽입합니다.

[DEFAULT]
[image_conversion]
[image_import_opts]
image_import_plugins = [inject_image_metadata]
[import_filtering_opts]
[inject_metadata_properties]
ignore_user_roles = admin
inject = PROPERTY1:value,PROPERTY2:value;another value

ignore_user_roles 매개 변수는 플러그인이 무시하는 ID 서비스(keystone) 역할의 쉼표로 구분된 목록입니다. 즉, 이미지 가져오기 호출을 수행하는 사용자에게 이러한 역할이 있는 경우 플러그인은 이미지에 속성을 삽입하지 않습니다.

매개 변수 주입 은 가져온 이미지의 이미지 레코드에 삽입되는 쉼표로 구분된 속성 및 값 목록입니다. 각 속성과 값은 콜론 (':') 으로 따옴표로 묶어야 합니다.

glance-image-import.conf 파일은 이미지 서비스 소스 코드 트리의 etc/ 하위 디렉터리에 있습니다. Red Hat OpenStack Platform 릴리스에 대한 올바른 분기를 찾고 있는지 확인하십시오.

17장. 스토리지 구성

이 장에서는 오버클라우드의 스토리지 옵션을 구성하는 데 사용할 수 있는 몇 가지 방법에 대해 간단히 설명합니다.

중요

오버클라우드는 기본 스토리지 옵션에 로컬 및 LVM 스토리지를 사용합니다. 이러한 옵션은 엔터프라이즈 수준 오버클라우드에 지원되지 않으므로 이 장에 설명된 스토리지 옵션 중 하나를 사용하도록 오버클라우드를 구성해야 합니다.

17.1. NFS 스토리지 구성

공유 NFS 스토리지를 사용하도록 오버클라우드를 구성할 수 있습니다.

17.1.1. 지원되는 구성 및 제한 사항

지원되는 NFS 스토리지

  • Red Hat은 인증된 스토리지 백엔드 및 드라이버를 사용하는 것이 좋습니다. Red Hat은 인증된 스토리지 백엔드 및 드라이버에 비해 기능이 제한되기 때문에 일반 NFS 백엔드에서 제공하는 NFS 스토리지를 사용하지 않는 것이 좋습니다. 예를 들어 일반 NFS 백엔드는 볼륨 암호화 및 볼륨 다중 연결과 같은 기능을 지원하지 않습니다. 지원되는 드라이버에 대한 자세한 내용은 Red Hat Ecosystem Catalog 에서 참조하십시오.
  • Block Storage(cinder) 및 Compute(nova) 서비스의 경우 NFS 버전 4.0 이상을 사용해야 합니다. RHOSP(Red Hat OpenStack Platform)는 이전 버전의 NFS를 지원하지 않습니다.

지원되지 않는 NFS 구성

  • RHOSP는 일반적인 볼륨 작업을 방해하기 때문에 NetApp 기능 NAS 보안을 지원하지 않습니다. director는 기본적으로 기능을 비활성화합니다. 따라서 NFS 백엔드 또는 NetApp NFS 블록 스토리지 백엔드가 NAS 보안을 지원하는지 여부를 제어하는 다음 heat 매개변수를 편집하지 마십시오.

    • CinderNetappNasSecureFileOperations
    • CinderNetappNasSecureFilePermissions
    • CinderNasSecureFileOperations
    • CinderNasSecureFilePermissions

NFS 공유 사용 시 제한 사항

  • 스왑 디스크가 있는 인스턴스는 백엔드가 NFS 공유인 경우 크기를 변경하거나 다시 빌드할 수 없습니다.

17.1.2. NFS 스토리지 구성

공유 NFS 스토리지를 사용하도록 오버클라우드를 구성할 수 있습니다.

절차

  1. NFS 스토리지를 구성하는 환경 파일을 생성합니다(예: nfs_storage.yaml ).
  2. NFS 스토리지를 구성하려면 새 환경 파일에 다음 매개 변수를 추가합니다.

    parameter_defaults:
      CinderEnableIscsiBackend: false
      CinderEnableNfsBackend: true
      GlanceBackend: file
      CinderNfsServers: 192.0.2.230:/cinder
      GlanceNfsEnabled: true
      GlanceNfsShare: 192.0.2.230:/glance
    참고

    대부분의 RHOSP(Red Hat OpenStack Platform) 환경에 적합한 NFS 마운트 옵션이 활성화된 기본값으로 CinderNfsMountOptionsGlanceNfsOptions 매개변수를 구성하지 마십시오. environments/storage/glance-nfs.yaml 파일에서 GlanceNfsOptions 매개변수 값을 확인할 수 있습니다. 동일한 NFS 서버를 공유하도록 여러 서비스를 구성할 때 문제가 발생하는 경우 Red Hat 지원팀에 문의하십시오.

  3. 다른 환경 파일과 함께 NFS 스토리지 환경 파일을 스택에 추가하고 오버클라우드를 배포합니다.

    (undercloud)$ openstack overcloud deploy --templates \
     -e [your environment files] \
     -e /home/stack/templates/nfs_storage.yaml

17.1.3. 변환을 위한 외부 NFS 공유 구성

Block Storage 서비스(cinder)가 오버클라우드 컨트롤러 노드에서 이미지 형식 변환을 수행하고 공간이 제한되어 있으면 대규모 Image 서비스(glance) 이미지를 변환하면 노드 루트 디스크 공간이 완전히 사용될 수 있습니다. 외부 NFS 공유를 사용하여 노드의 공간이 완전히 채워지지 않도록 할 수 있습니다.

외부 NFS 공유 설정을 제어하는 director heat 매개변수는 다음 두 가지가 있습니다.

  • CinderImageConversionNfsShare
  • CinderImageConversionNfsOptions

절차

  1. stack 사용자로 언더클라우드에 로그인하고 stackrc 자격 증명 파일을 가져옵니다.

    $ source ~/stackrc
  2. 새 또는 기존 스토리지 관련 환경 파일에서 외부 NFS 공유에 대한 정보를 추가합니다.

    parameter_defaults:
      CinderImageConversionNfsShare: 192.168.10.1:/convert
    참고

    NFS 마운트 옵션을 제어하는 CinderImageConversionNfsOptions 매개변수의 기본값은 대부분의 환경에 충분합니다.

  3. 환경과 관련된 기타 환경 파일과 함께 openstack overcloud deploy 명령에 새 설정이 포함된 환경 파일을 포함합니다.

    $ openstack overcloud deploy \
    --templates \
    …
    -e <existing_overcloud_environment_files> \
    -e <new_environment_file> \
    …
    • 을 기존 배포의 일부인 환경 파일 목록으로 바꿉니다 <existing_overcloud_environment_files>.
    • & lt;new_environment_file >을 NFS 공유 구성이 포함된 새 환경 파일 또는 편집된 환경 파일로 바꿉니다.

17.2. Ceph Storage 구성

다음 방법 중 하나를 사용하여 Red Hat Ceph Storage를 Red Hat OpenStack Platform Overcloud에 통합합니다.

자체 Ceph Storage 클러스터를 사용하여 오버클라우드 생성
오버클라우드에서 생성하는 동안 Ceph 스토리지 클러스터를 생성할 수 있습니다. director는 Ceph OSD를 사용하여 데이터를 저장하는 Ceph Storage 노드 집합을 생성합니다. director는 또한 오버클라우드 컨트롤러 노드에 Ceph Monitor 서비스를 설치합니다. 즉, 조직이 세 개의 고가용성 컨트롤러 노드가 있는 Overcloud를 생성하면 Ceph 모니터도 고가용성 서비스가 됩니다. 자세한 내용은 Deploying an Overcloud with Containerized Red Hat Ceph 를 참조하십시오.
기존 Ceph Storage 클러스터를 오버클라우드에 통합
기존 Ceph Storage 클러스터가 있는 경우 배포 중에 이 클러스터를 Red Hat OpenStack Platform 오버클라우드에 통합할 수 있습니다. 즉, 오버클라우드 구성 외부에서 클러스터를 관리하고 확장할 수 있습니다. 자세한 내용은 Integrating an Overcloud with an Existing Red Hat Ceph Cluster 를 참조하십시오.

17.3. 외부 오브젝트 스토리지 클러스터 사용

컨트롤러 노드에서 기본 Object Storage 서비스 배포를 비활성화하여 외부 OpenStack Object Storage(swift) 클러스터를 재사용할 수 있습니다. 이렇게 하면 오브젝트 스토리지의 프록시 및 스토리지 서비스를 모두 비활성화하고 지정된 외부 Object Storage 엔드포인트를 사용하도록 haproxy 및 OpenStack Identify(keystone)를 구성합니다.

참고

외부 Object Storage(swift) 클러스터에서 사용자 계정을 수동으로 관리해야 합니다.

사전 요구 사항

  • 외부 Object Storage 클러스터의 엔드포인트 IP 주소와 외부 Object Storage proxy-server.conf 파일의 authtoken 암호가 필요합니다. openstack endpoint list 명령을 사용하여 이 정보를 찾을 수 있습니다.

절차

  1. 다음 콘텐츠를 사용하여 swift-external-params.yaml 이라는 새 파일을 생성합니다.

    • EXTERNAL.IP:PORT 를 외부 프록시의 IP 주소 및 포트로 바꿉니다.
    • AUTHTOKENSwiftPassword 행의 외부 프록시의 authtoken 암호로 교체합니다.

      parameter_defaults:
        ExternalPublicUrl: 'https://EXTERNAL.IP:PORT/v1/AUTH_%(tenant_id)s'
        ExternalInternalUrl: 'http://192.168.24.9:8080/v1/AUTH_%(tenant_id)s'
        ExternalAdminUrl: 'http://192.168.24.9:8080'
        ExternalSwiftUserTenant: 'service'
        SwiftPassword: AUTHTOKEN
  2. 이 파일을 swift-external-params.yaml 로 저장합니다.
  3. 다음 외부 Object Storage 서비스 환경 파일과 배포와 관련된 기타 환경 파일을 사용하여 오버클라우드를 배포합니다.

    openstack overcloud deploy --templates \
    -e [your environment files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/swift-external.yaml \
    -e swift-external-params.yaml

17.4. 외부 Ceph Object Gateway를 사용하도록 Ceph 개체 저장소 구성

RHOSP(Red Hat OpenStack Platform) director는 외부 Ceph Object Gateway(RGW)를 오브젝트 스토어 서비스로 구성하는 작업을 지원합니다. 외부 RGW 서비스로 인증하려면 ID 서비스(keystone)에서 사용자와 해당 역할을 확인하도록 RGW를 구성해야 합니다.

외부 Ceph Object Gateway를 구성하는 방법에 대한 자세한 내용은 Ceph Object Gateway 사용 가이드에서 Keystone 인증을 사용하도록 Ceph Object Gateway 구성을 참조하십시오.

절차

  1. 다음 parameter_defaults 를 사용자 지정 환경 파일(예: swift-external-params.yaml )에 추가하고 배포에 맞게 값을 조정합니다.

    parameter_defaults:
       ExternalSwiftPublicUrl: 'http://<Public RGW endpoint or loadbalancer>:8080/swift/v1/AUTH_%(project_id)s'
       ExternalSwiftInternalUrl: 'http://<Internal RGW endpoint>:8080/swift/v1/AUTH_%(project_id)s'
       ExternalSwiftAdminUrl: 'http://<Admin RGW endpoint>:8080/swift/v1/AUTH_%(project_id)s'
       ExternalSwiftUserTenant: 'service'
       SwiftPassword: 'choose_a_random_password'
    참고

    예제 코드 스니펫에는 해당 환경에서 사용하는 값과 다를 수 있는 매개변수 값이 포함되어 있습니다.

    • 원격 RGW 인스턴스가 수신 대기하는 기본 포트는 8080 입니다. 포트는 외부 RGW 구성 방법에 따라 다를 수 있습니다.
    • Overcloud에서 생성된 swift 사용자는 SwiftPassword 매개 변수로 정의된 암호를 사용합니다. rgw_keystone_admin_password 를 사용하여 ID 서비스를 인증하도록 동일한 암호를 사용하도록 외부 RGW 인스턴스를 구성해야 합니다.
  2. 다음 코드를 Ceph 구성 파일에 추가하여 ID 서비스를 사용하도록 RGW를 구성합니다. 환경에 맞게 변수 값을 바꿉니다.

        rgw_keystone_api_version = 3
        rgw_keystone_url = http://<public Keystone endpoint>:5000/
        rgw_keystone_accepted_roles = member, Member, admin
        rgw_keystone_accepted_admin_roles = ResellerAdmin, swiftoperator
        rgw_keystone_admin_domain = default
        rgw_keystone_admin_project = service
        rgw_keystone_admin_user = swift
        rgw_keystone_admin_password = <password_as_defined_in_the_environment_parameters>
        rgw_keystone_implicit_tenants = true
        rgw_keystone_revocation_interval = 0
        rgw_s3_auth_use_keystone = true
        rgw_swift_versioning_enabled = true
        rgw_swift_account_in_url = true
    참고

    director는 기본적으로 ID 서비스에 다음 역할 및 사용자를 생성합니다.

    • rgw_keystone_accepted_admin_roles: ResellerAdmin, swiftoperator
    • rgw_keystone_admin_domain: default
    • rgw_keystone_admin_project: service
    • rgw_keystone_admin_user: swift
  3. 배포와 관련된 기타 환경 파일을 사용하여 추가 환경 파일을 사용하여 오버클라우드를 배포합니다.

    openstack overcloud deploy --templates \
    -e <your_environment_files>
    -e /usr/share/openstack-tripleo-heat-templates/environments/swift-external.yaml
    -e swift-external-params.yaml

검증

  1. stack 사용자로 언더클라우드에 로그인합니다.
  2. overcloudrc 파일을 소싱합니다.

    $ source ~/stackrc
  3. ID 서비스(keystone)에 엔드포인트가 있는지 확인합니다.

    $ openstack endpoint list --service object-store
    
    +---------+-----------+-------+-------+---------+-----------+---------------+
    | ID | Region    | Service Name | Service Type | Enabled | Interface | URL |
    +---------+-----------+-------+-------+---------+-----------+---------------+
    | 233b7ea32aaf40c1ad782c696128aa0e | regionOne | swift | object-store | True    | admin     | http://192.168.24.3:8080/v1/AUTH_%(project_id)s |
    | 4ccde35ac76444d7bb82c5816a97abd8 | regionOne | swift | object-store | True    | public    | https://192.168.24.2:13808/v1/AUTH_%(project_id)s |
    | b4ff283f445348639864f560aa2b2b41 | regionOne | swift | object-store | True    | internal  | http://192.168.24.3:8080/v1/AUTH_%(project_id)s |
    +---------+-----------+-------+-------+---------+-----------+---------------+
  4. 테스트 컨테이너를 만듭니다.

    $ openstack container create <testcontainer>
    +----------------+---------------+------------------------------------+
    | account | container | x-trans-id |
    +----------------+---------------+------------------------------------+
    | AUTH_2852da3cf2fc490081114c434d1fc157 | testcontainer | tx6f5253e710a2449b8ef7e-005f2d29e8 |
    +----------------+---------------+------------------------------------+
  5. 컨테이너에 데이터를 업로드할 수 있는지 확인하기 위해 구성 파일을 생성합니다.

    $ openstack object create testcontainer undercloud.conf
    +-----------------+---------------+----------------------------------+
    | object          | container     | etag                             |
    +-----------------+---------------+----------------------------------+
    | undercloud.conf | testcontainer | 09fcffe126cac1dbac7b89b8fd7a3e4b |
    +-----------------+---------------+----------------------------------+
  6. 테스트 컨테이너를 삭제합니다.

    $ openstack container delete -r <testcontainer>

17.5. 이미지 서비스의 cinder 백엔드 구성

GlanceBackend 매개 변수를 사용하여 이미지 서비스에서 이미지를 저장하는 데 사용하는 백엔드를 설정합니다.

중요

프로젝트에 대해 생성할 수 있는 기본 최대 볼륨 수는 10입니다.

절차

  1. cinder 를 이미지 서비스 백엔드로 구성하려면 환경 파일에 다음 행을 추가합니다.

    parameter_defaults:
      GlanceBackend: cinder
  2. cinder 백엔드가 활성화된 경우 기본적으로 다음 매개변수와 값이 설정됩니다.

    cinder_store_auth_address = http://172.17.1.19:5000/v3
    cinder_store_project_name = service
    cinder_store_user_name = glance
    cinder_store_password = ****secret****
  3. 사용자 정의 사용자 이름 또는 cinder_store_ 매개변수의 사용자 지정 값을 사용하려면 ExtraConfig 매개변수를 parameter_defaults 에 추가하고 사용자 정의 값을 포함합니다.

    ExtraConfig:
        glance::config::api_config:
          glance_store/cinder_store_auth_address:
            value: "%{hiera('glance::api::authtoken::auth_url')}/v3"
          glance_store/cinder_store_user_name:
            value: <user-name>
          glance_store/cinder_store_password:
            value: "%{hiera('glance::api::authtoken::password')}"
          glance_store/cinder_store_project_name:
            value: "%{hiera('glance::api::authtoken::project_name')}"

17.6. 하나의 인스턴스에 연결할 최대 스토리지 장치 수 구성

기본적으로 무제한 스토리지 장치를 단일 인스턴스에 연결할 수 있습니다. 최대 장치 수를 제한하려면 max_disk_devices_to_attach 매개 변수를 Compute 환경 파일에 추가합니다. 다음 예제를 사용하여 max_disk_devices_to_attach 값을 "30"으로 변경합니다.

parameter_defaults:
   ComputeExtraConfig:
          nova::config::nova_config:
            compute/max_disk_devices_to_attach:
                value: '30'

지침 및 고려 사항

  • 인스턴스에서 지원하는 스토리지 디스크 수는 디스크에서 사용하는 버스에 따라 다릅니다. 예를 들어 IDE 디스크 버스는 4개의 연결된 장치로 제한됩니다.
  • 활성 인스턴스가 있는 컴퓨팅 노드에서 max_disk_devices_to_attach 를 변경하면 인스턴스에 이미 연결된 장치 수보다 낮은 경우 최대 수가 다시 빌드되지 않을 수 있습니다. 예를 들어 A 인스턴스에 26개의 장치가 연결되어 있고 max_disk_devices_to_attach 를 20으로 변경하면 A 인스턴스를 다시 빌드하는 요청이 실패합니다.
  • 콜드 마이그레이션 중에 구성된 최대 스토리지 장치 수는 마이그레이션하려는 인스턴스의 소스에만 적용됩니다. 이동하기 전에 대상을 확인하지 않습니다. 즉, 컴퓨팅 노드 A에 26개의 연결된 디스크 장치가 있고 컴퓨팅 노드 B에 최대 20개의 연결된 디스크 장치가 구성되어 있으면 컴퓨팅 노드 A에서 컴퓨팅 노드 B로 26개의 연결된 인스턴스를 콜드 마이그레이션합니다. 그러나 구성된 최대 20개를 초과하는 26개의 장치가 이미 연결되어 있으므로 컴퓨팅 노드 B에서 인스턴스를 다시 빌드하기 위한 후속 요청은 실패합니다.
  • 컴퓨팅 노드가 없으므로 구성된 최대값은 보류된 오프로드된 인스턴스에 적용되지 않습니다.
  • 인스턴스에 많은 디스크 장치를 연결하면 인스턴스의 성능이 저하될 수 있습니다. 환경에서 지원할 수 있는 항목의 경계에 따라 최대 수를 조정합니다.
  • 시스템 유형 Q35가 있는 인스턴스는 최대 500개의 디스크 장치를 연결할 수 있습니다.

17.7. 이미지 서비스 캐싱으로 확장성 개선

glance-api 캐싱 메커니즘을 사용하여 이미지 서비스(glance) API 서버에 이미지 복사본을 저장하고 자동으로 검색하여 확장성을 개선합니다. 이미지 서비스 캐싱을 사용하면 glance-api를 여러 호스트에서 실행할 수 있습니다. 즉, 백엔드 스토리지에서 동일한 이미지를 여러 번 검색할 필요가 없습니다. 이미지 서비스 캐싱은 이미지 서비스 작업에 영향을 미치지 않습니다.

Red Hat OpenStack Platform director(tripleo) heat 템플릿을 사용하여 이미지 서비스 캐싱을 구성합니다.

절차

  1. 환경 파일에서 glance-api.conf heat 템플릿에서 플레이버 값을 keystone+cachemanagement 로 자동 설정하는 GlanceCacheEnabled 매개변수 값을 true 로 설정합니다.

    parameter_defaults:
        GlanceCacheEnabled: true
  2. 오버클라우드를 재배포할 때 openstack overcloud deploy 명령에 환경 파일을 포함합니다.
  3. 선택 사항: 오버클라우드를 재배포할 때 대체 빈도로 glance_cache_pruner 를 조정합니다. 다음 예제에서는 5분의 빈도를 보여줍니다.

    parameter_defaults:
      ControllerExtraConfig:
        glance::cache::pruner::minute: '*/5'

    파일 시스템 전체 시나리오를 방지하려면 필요에 따라 빈도를 조정합니다. 대체 빈도를 선택할 때 다음 요소를 포함합니다.

    • 환경에 캐시할 파일의 크기입니다.
    • 사용 가능한 파일 시스템 공간의 양입니다.
    • 환경이 이미지를 캐시하는 빈도입니다.

17.8. 타사 스토리지 구성

코어 heat 템플릿 컬렉션 /usr/share/openstack-tripleo-heat-templates 에 다음 환경 파일이 있습니다.

Dell EMC 스토리지 센터

블록 스토리지(cinder) 서비스를 위한 단일 Dell EMC Storage Center 백엔드 배포.

환경 파일은 /usr/share/openstack-tripleo-heat-templates/environments/cinder-dellsc-config.yaml 에 있습니다.

전체 구성 정보는 Dell 스토리지 센터 백엔드 가이드를 참조하십시오.

Dell EMC PS 시리즈

블록 스토리지(cinder) 서비스를 위한 단일 Dell EMC PS 시리즈 백엔드 배포.

환경 파일은 /usr/share/openstack-tripleo-heat-templates/environments/cinder-dellps-config.yaml 에 있습니다.

전체 구성 정보는 Dell EMC PS 시리즈 백엔드 가이드를 참조하십시오.

NetApp Block Storage

NetApp 스토리지 어플라이언스를 블록 스토리지(cinder) 서비스의 백엔드로 배포합니다.

환경 파일은 /usr/share/openstack-tripleo-heat-templates/environments/storage/cinder-netapp-config.yaml 에 있습니다.

전체 설정 정보는 NetApp Block Storage 백엔드 가이드 를 참조하십시오.

18장. 보안 개선 사항

다음 섹션에서는 오버클라우드의 보안을 강화하기 위한 몇 가지 제안 사항을 제공합니다.

18.1. 보안 root 사용자 액세스 사용

Overcloud 이미지에는 root 사용자의 강화된 보안이 자동으로 포함되어 있습니다. 예를 들어 배포된 각 Overcloud 노드는 root 사용자에 대한 직접 SSH 액세스를 자동으로 비활성화합니다. 오버클라우드 노드에서 root 사용자에 계속 액세스할 수 있습니다.

절차

  1. stack 사용자로 Undercloud 노드에 로그인합니다.
  2. 각 오버클라우드 노드에는 heat-admin 사용자 계정이 있습니다. 이 사용자 계정에는 언더클라우드에서 Overcloud 노드로의 암호 없이 SSH 액세스를 제공하는 언더클라우드 공용 SSH 키가 포함되어 있습니다. Undercloud 노드에서 heat-admin 사용자로 SSH를 통해 Overcloud 노드에 로그인합니다.
  3. sudo -i 를 사용하여 root 사용자로 전환합니다.

18.2. 오버클라우드 방화벽 관리

각 핵심 OpenStack Platform 서비스에는 구성 가능 서비스 템플릿에 방화벽 규칙이 포함되어 있습니다. 이렇게 하면 각 오버클라우드 노드에 대한 기본 방화벽 규칙 세트가 자동으로 생성됩니다.

오버클라우드 heat 템플릿에는 추가 방화벽 관리에 도움이 되는 매개변수 세트가 포함되어 있습니다.

ManageFirewall
방화벽 규칙을 자동으로 관리할지 여부를 정의합니다. Puppet에서 각 노드에서 방화벽을 자동으로 구성할 수 있도록 이 매개 변수를 true 로 설정합니다. 방화벽을 수동으로 관리하려면 false 로 설정합니다. 기본값은 true입니다.
PurgeFirewallRules
새 Linux 방화벽 규칙을 구성하기 전에 기본 Linux 방화벽 규칙을 제거할지 여부를 정의합니다. 기본값은 false입니다.

ManageFirewall 매개변수를 true 로 설정하면 배포에 대한 추가 방화벽 규칙을 생성할 수 있습니다. 오버클라우드의 환경 파일에서 구성 후크( 4.5절. “Puppet: 역할에 대한 hieradata 사용자 정의”참조)를 사용하여 tripleo::firewall::firewall_rules hieradata를 설정합니다. 이 hieradata는 방화벽 규칙 이름과 해당 매개 변수를 키로 포함하는 해시이며, 모두 선택 사항입니다.

port
규칙에 연결된 포트입니다.
dport
규칙에 연결된 대상 포트입니다.
sport
규칙과 연결된 소스 포트입니다.
Proto
규칙과 연결된 프로토콜입니다. 기본값은 tcp 입니다.
작업
규칙과 연결된 작업 정책입니다. 기본값은 accept 입니다.
건너뛰기
로 이동할 체인입니다. 있는 경우 작업을 재정의합니다.
상태
규칙과 관련된 상태 배열입니다. 기본값은 ['NEW'] 입니다.
소스
규칙과 연결된 소스 IP 주소입니다.
iniface
규칙에 연결된 네트워크 인터페이스입니다.
체인
규칙과 연결된 체인입니다. 기본값은 INPUT 입니다.
대상
규칙에 연결된 대상 CIDR입니다.

다음 예제에서는 방화벽 규칙 형식의 구문을 보여줍니다.

ExtraConfig:
  tripleo::firewall::firewall_rules:
    '300 allow custom application 1':
      port: 999
      proto: udp
      action: accept
    '301 allow custom application 2':
      port: 8081
      proto: tcp
      action: accept

이는 ExtraConfig 를 통해 모든 노드에 2개의 추가 방화벽 규칙을 적용합니다.

참고

각 규칙 이름은 해당 iptables 규칙의 주석이 됩니다. 각 규칙 이름은 3자리 접두사로 시작되어 Puppet에서 최종 iptables 파일에서 정의된 모든 규칙을 정렬할 수 있습니다. 기본 Red Hat OpenStack Platform 규칙은 000~200 범위의 접두사를 사용합니다.

18.3. SNMP(Simple Network Management Protocol) 문자열 변경

director는 오버클라우드에 대한 기본 읽기 전용 SNMP 설정을 제공합니다. 네트워크 장치에 대해 학습하는 권한이 없는 사용자의 위험을 완화하도록 SNMP 문자열을 변경하는 것이 좋습니다.

참고

문자열 매개 변수를 사용하여 ExtraConfig 인터페이스를 구성하는 경우 다음 구문을 사용하여 heat 및 Hiera에서 문자열을 부울 값: '"<VALUE>"로 해석하지 않도록 해야 합니다.

오버클라우드의 환경 파일에서 ExtraConfig 후크를 사용하여 다음 hieradata를 설정합니다.

SNMP 기존 액세스 제어 설정

snmp::ro_community
IPv4 읽기 전용 SNMP 커뮤니티 문자열. 기본값은 public 입니다.
snmp::ro_community6
IPv6 읽기 전용 SNMP 커뮤니티 문자열. 기본값은 public 입니다.
snmp::ro_network
RO에서 데몬을 쿼리 할 수 있는 네트워크입니다. 이 값은 문자열 또는 배열일 수 있습니다. 기본값은 127.0.0.1 입니다.
snmp::ro_network6
RO가 IPv6로 데몬을 쿼리 할 수 있는 네트워크입니다. 이 값은 문자열 또는 배열일 수 있습니다. 기본값은 ::1/128 입니다.
tripleo::profile::base::snmp::snmpd_config
안전 위로 the snmpd.conf 파일에 추가할 행 배열입니다. 기본값은 [] 입니다. 사용 가능한 모든 옵션은 SNMP 구성 파일 웹 페이지를 참조하십시오.

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

parameter_defaults:
  ExtraConfig:
    snmp::ro_community: mysecurestring
    snmp::ro_community6: myv6securestring

그러면 모든 노드에서 읽기 전용 SNMP 커뮤니티 문자열이 변경됩니다.

SNMP 보기 기반 액세스 제어 설정(VACM)

snmp::com2sec
IPv4 보안 이름.
snmp::com2sec6
IPv6 보안 이름.

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

parameter_defaults:
  ExtraConfig:
    snmp::com2sec: mysecurestring
    snmp::com2sec6: myv6securestring

그러면 모든 노드에서 읽기 전용 SNMP 커뮤니티 문자열이 변경됩니다.

자세한 내용은 the snmpd.conf 도움말 페이지를 참조하십시오.

18.4. HAProxy에 대한 SSL/TLS 암호화 및 규칙 변경

오버클라우드에서 SSL/TLS를 활성화한 경우 HAProxy 구성에 사용되는 SSL/TLS 암호화 방식 및 규칙 강화를 고려하십시오. SSL/TLS 암호를 강화함으로써 POODLE 취약점과 같은 SSL/TLS 취약점을 방지할 수 있습니다.

  1. tls-ciphers.yaml 이라는 heat 템플릿 환경 파일을 생성합니다.

    touch ~/templates/tls-ciphers.yaml
  2. 환경 파일의 ExtraConfig 후크를 사용하여 tripleo::haproxy::ssl_cipher_suitetripleo::haproxy::ssl_options hieradata에 값을 적용합니다.

    parameter_defaults:
      ExtraConfig:
        tripleo::haproxy::ssl_cipher_suite:: `DHE-RSA-AES128-CCM:DHE-RSA-AES256-CCM:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-AES256-CCM:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305`
    
        tripleo::haproxy::ssl_options:: no-sslv3 no-tls-tickets
    참고

    암호화 방식 컬렉션은 연속된 한 행으로 되어 있습니다.

  3. 오버클라우드를 배포할 때 overcloud deploy 명령을 사용하여 tls-ciphers.yaml 환경 파일을 포함합니다.

    openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/tls-ciphers.yaml
    ...

18.5. Open vSwitch 방화벽 사용

Red Hat OpenStack Platform director에서 OVS(Open vSwitch) 방화벽 드라이버를 사용하도록 보안 그룹을 구성할 수 있습니다. NeutronOVSFirewallDriver 매개변수를 사용하여 사용하려는 방화벽 드라이버를 지정합니다.

  • iptables_hybrid - iptables/hybrid 기반 구현을 사용하도록 네트워킹 서비스(neutron)를 구성합니다.
  • openvswitch - OVS 방화벽 흐름 기반 드라이버를 사용하도록 네트워킹 서비스를 구성합니다.

openvswitch 방화벽 드라이버는 성능이 향상되고 게스트를 프로젝트 네트워크에 연결하는 데 사용되는 인터페이스 및 브리지 수를 줄입니다.

중요

멀티캐스트 트래픽은 iptables 방화벽 드라이버와 OVS(Open vSwitch) 방화벽 드라이버에서 다르게 처리됩니다. 기본적으로 iptables를 사용하면 VRRP 트래픽이 거부되며 VRRP 트래픽이 끝점에 도달하기 위해 보안 그룹 규칙에서 VRRP를 활성화해야 합니다. OVS에서는 모든 포트가 동일한 OpenFlow 컨텍스트를 공유하며, 멀티캐스트 트래픽을 포트당 개별적으로 처리할 수 없습니다. 보안 그룹은 모든 포트(예: 라우터의 포트)에 적용되지 않으므로 OVS는 NORMAL 작업을 사용하고 RFC 4541에서 지정하는 모든 포트에 멀티캐스트 트래픽을 전달합니다.

참고

iptables_hybrid 옵션은 OVS-DPDK와 호환되지 않습니다. openvswitch 옵션은 OVS 하드웨어 오프로드와 호환되지 않습니다.

network-environment.yaml 파일에서 NeutronOVSFirewallDriver 매개변수를 구성합니다.

NeutronOVSFirewallDriver: openvswitch
  • NeutronOVSFirewallDriver : 보안 그룹을 구현할 때 사용할 방화벽 드라이버의 이름을 구성합니다. 가능한 값은 시스템 구성에 따라 다릅니다. 몇 가지 예로 noop,openvswitch, iptables_hybrid 가 있습니다. 빈 문자열의 기본값으로 인해 지원되는 구성이 생성됩니다.

19장. 네트워크 플러그인 구성

director에는 타사 네트워크 플러그인을 설정할 때 사용할 수 있는 환경 파일이 포함되어 있습니다.

19.1. Fujitsu Converged Fabric (C-Fabric)

/usr/share/openstack-tripleo-heat-templates/environments/neutron-✓2-fujitsu-cfabab.yaml에 있는 환경 파일을 사용하여 Fujitsu Converged Fabric(C- Fabric) 플러그인을 활성화할 수 있습니다.

절차

  1. 환경 파일을 templates 하위 디렉터리에 복사합니다.

    $ cp /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-cfab.yaml /home/stack/templates/
  2. 절대 경로를 사용하도록 resource_registry 를 편집합니다.

    resource_registry:
      OS::TripleO::Services::NeutronML2FujitsuCfab: /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-plugin-ml2-fujitsu-cfab.yaml
  3. /home/stack/templates/neutron-ml2-fujitsu-cfab.yaml에서 parameter_defaults 를 검토합니다.

    • NeutronFujitsuCfabAddress - C-Fabric의 telnet IP 주소(문자열)
    • NeutronFujitsuCfabUserName - 사용할 C-Fabric 사용자 이름(문자열)
    • NeutronFujitsuCfabPassword - C-Fabric 사용자 계정의 암호(문자열)
    • NeutronFujitsuCfabPhysicalNetworks - <physical_network>:<vfab_id> phyples로 physical_network 이름 및 해당 vfab ID를 지정합니다. (comma_delimited_list)
    • NeutronFujitsuCfabSharePprofile - 동일한 VLAN ID를 사용하는 neutron 포트 간에 C-Fabric pprofile을 공유할지 여부를 결정합니다. (boolean)
    • NeutronFujitsuCfabPprofilePrefix - pprofile 이름의 접두사 문자열(문자열)
    • NeutronFujitsuCfabsaveConfig - 구성을 저장할지 여부를 결정합니다. (부울)
  4. 배포에 템플릿을 적용하려면 openstack overcloud deploy 명령에 환경 파일을 포함합니다.

    $ openstack overcloud deploy --templates -e /home/stack/templates/neutron-ml2-fujitsu-cfab.yaml [OTHER OPTIONS] ...

19.2. Fujitsu FOS Switch

/usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-fossw.yaml 에 있는 환경 파일을 사용하여 Fujitsu FOS Switch 플러그인을 활성화할 수 있습니다.

절차

  1. 환경 파일을 templates 하위 디렉터리에 복사합니다.

    $ cp /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-fossw.yaml /home/stack/templates/
  2. 절대 경로를 사용하도록 resource_registry 를 편집합니다.

    resource_registry:
      OS::TripleO::Services::NeutronML2FujitsuFossw: /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-plugin-ml2-fujitsu-fossw.yaml
  3. /home/stack/templates/neutron-ml2-fujitsu-fossw.yaml에서 parameter_defaults 를 검토합니다.

    • NeutronFujitsuFosswIps - 모든 FOS 스위치의 IP 주소. (comma_delimited_list)
    • NeutronFujitsuFosswUserName - 사용할 FOS 사용자 이름(문자열)
    • NeutronFujitsuFosswPassword - FOS 사용자 계정의 암호(문자열)
    • NeutronFujitsuFosswPort - SSH 연결에 사용할 포트 번호입니다(숫자)
    • NeutronFujitsuFosswTimeout - SSH 연결의 시간 초과 기간(숫자)
    • NeutronFujitsuFosswUdpDestPort - FOS 스위치의 VXLAN UDP 대상의 포트 번호입니다(숫자)
    • NeutronFujitsuFosswOvsdbVlanidRangeMin - VNI 및 물리적 포트 바인딩에 사용되는 최소 VLAN ID입니다(숫자)
    • NeutronFujitsuFosswOvsdbPort - FOS 스위치의 OVSDB 서버의 포트 번호입니다(숫자)
  4. 배포에 템플릿을 적용하려면 openstack overcloud deploy 명령에 환경 파일을 포함합니다.

    $ openstack overcloud deploy --templates -e /home/stack/templates/neutron-ml2-fujitsu-fossw.yaml [OTHER OPTIONS] ...

20장. ID 구성

director에는 ID 서비스(keystone) 설정을 구성하는 데 도움이 되는 매개변수가 포함되어 있습니다.

20.1. 리전 이름

기본적으로 오버클라우드 리전의 이름은 regionOne 입니다. 환경 파일을 KeystoneRegion 항목을 추가하여 변경할 수 있습니다. 오버클라우드를 배포한 후에는 이 값을 수정할 수 없습니다.

parameter_defaults:
  KeystoneRegion: 'SampleRegion'

21장. 기타 오버클라우드 구성

다음 구성을 사용하여 Overcloud에서 기타 기능을 구성합니다.

21.1. 디버그 모드

오버클라우드의 특정 서비스에 대해 DEBUG 수준 로깅 모드를 활성화하고 비활성화할 수 있습니다.

서비스에 대한 디버그 모드를 구성하려면 각 디버그 매개 변수를 설정합니다. 예를 들어 OpenStack Identity(keystone)는 KeystoneDebug 매개 변수를 사용합니다.

절차

  • 환경 파일의 parameter_defaults 섹션에 매개 변수를 설정합니다.

    parameter_defaults:
      KeystoneDebug: True

KeystoneDebug 매개변수를 True 로 설정하면 /var/log/containers/keystone/keystone.log 표준 keystone 로그 파일이 DEBUG 수준 로그를 사용하여 업데이트됩니다.

디버그 매개변수의 전체 목록은 Overcloud Parameters 가이드의 "Debug Parameters" 를 참조하십시오.

21.2. 오버클라우드 노드에서 커널 구성

Red Hat OpenStack Platform director에는 오버클라우드 노드에서 커널을 구성하는 매개변수가 포함되어 있습니다.

ExtraKernelModules

로드할 커널 모듈. 모듈 이름은 빈 값이 있는 해시 키로 나열됩니다.

  ExtraKernelModules:
    <MODULE_NAME>: {}
ExtraKernelPackages

ExtraKernelModule에서 커널 모듈을 로드하기 전에 설치할 커널 관련 패키지입니다. 패키지 이름은 빈 값을 사용하여 해시 키로 나열됩니다.

  ExtraKernelPackages:
    <PACKAGE_NAME>: {}
ExtraSysctlSettings

적용할 sysctl 설정 해시입니다. value 키를 사용하여 각 매개 변수의 값을 설정합니다.

  ExtraSysctlSettings:
    <KERNEL_PARAMETER>:
      value: <VALUE>

이 예에서는 환경 파일에서 이러한 매개변수의 구문을 보여줍니다.

parameter_defaults:
  ExtraKernelModules:
    iscsi_target_mod: {}
  ExtraKernelPackages:
    iscsi-initiator-utils: {}
  ExtraSysctlSettings:
    dev.scsi.logging_level:
      value: 1

21.3. 서버 콘솔 구성

Overcloud 노드의 콘솔 출력이 항상 서버 콘솔로 전송되지는 않습니다. 서버 콘솔에서 이 출력을 보려면 하드웨어에 올바른 콘솔을 사용하도록 오버클라우드를 구성해야 합니다. 다음 방법 중 하나를 사용하여 이 구성을 수행합니다.

  • 각 오버클라우드 역할에 대해 KernelArgs heat 매개변수를 수정합니다.
  • director에서 Overcloud 노드를 프로비저닝하는 데 사용하는 overcloud-full.qcow2 이미지를 사용자 지정합니다.

사전 요구 사항

  • 성공적인 언더클라우드 설치 자세한 내용은 Director 설치 및 사용 가이드를 참조하십시오.
  • 배포할 준비가 된 오버클라우드 노드

배포 중 heat를 사용하여 KernelArgs 수정

  1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.
  2. stackrc 인증 정보 파일을 소싱합니다.

    $ source stackrc
  3. 다음 내용으로 환경 파일 overcloud-console.yaml 을 생성합니다.

    parameter_defaults:
      <role>Parameters:
        KernelArgs: "console=<console-name>"

    <role> 을 설정하려는 오버클라우드 역할의 이름으로 바꾸고 <console-name> 을 사용하려는 콘솔의 ID로 바꿉니다. 예를 들어 다음 스니펫을 사용하여 tty0 을 사용하도록 기본 역할의 모든 오버클라우드 노드를 구성합니다.

    parameter_defaults:
      ControllerParameters:
        KernelArgs: "console=tty0"
      ComputeParameters:
        KernelArgs: "console=tty0"
      BlockStorageParameters:
        KernelArgs: "console=tty0"
      ObjectStorageParameters:
        KernelArgs: "console=tty0"
      CephStorageParameters:
        KernelArgs: "console=tty0"
  4. 배포 명령에 -e 옵션을 사용하여 overcloud-console-tty0.yaml 파일을 포함합니다.

overcloud-full.qcow2 이미지 수정

  1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.
  2. stackrc 인증 정보 파일을 소싱합니다.

    $ source stackrc
  3. overcloud-full.qcow2 이미지의 커널 인수를 수정하여 하드웨어에 대한 올바른 콘솔을 설정합니다. 예를 들어 콘솔을 tty0 으로 설정합니다.

    $ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'grubby --update-kernel=ALL --args="console=tty0"'
  4. 이미지를 director로 가져옵니다.

    $ openstack overcloud image upload --image-path overcloud-full.qcow2
  5. Overcloud를 배포합니다.

검증

  1. 언더클라우드에서 오버클라우드 노드에 로그인합니다.

    $ ssh heat-admin@<IP-address>

    <IP-address> 를 오버클라우드 노드의 IP 주소로 바꿉니다.

  2. /proc/cmdline 파일의 내용을 검사하고 console= 매개변수가 사용하려는 콘솔의 값으로 설정되어 있는지 확인합니다.

    [heat-admin@controller-0 ~]$ cat /proc/cmdline
    BOOT_IMAGE=(hd0,msdos2)/boot/vmlinuz-4.18.0-193.29.1.el8_2.x86_64 root=UUID=0ec3dea5-f293-4729-b676-5d38a611ce81 ro console=tty0 console=ttyS0,115200n81 no_timer_check crashkernel=auto rhgb quiet

21.4. 외부 로드 밸런싱 구성

오버클라우드는 여러 컨트롤러를 고가용성 클러스터로 함께 사용하여 OpenStack 서비스의 운영 성능을 극대화합니다. 또한 클러스터에서 OpenStack 서비스에 액세스할 수 있는 부하 분산을 제공하여 컨트롤러 노드에 트래픽을 균등하게 분산하고 각 노드의 서버 과부하를 줄입니다. 외부 로드 밸런서를 사용하여 이 배포를 수행할 수도 있습니다. 예를 들어 자체 하드웨어 기반 로드 밸런서를 사용하여 컨트롤러 노드에 대한 트래픽 배포를 처리할 수 있습니다.

외부 로드 밸런싱 구성에 대한 자세한 내용은 전용 External Load Balancing for the Overcloud 가이드를 참조하십시오.

21.5. IPv6 네트워킹 구성

이 섹션에서는 오버클라우드에 대한 네트워크 설정을 검사합니다. 여기에는 특정 네트워크 트래픽을 사용하고 IPv6 옵션으로 오버클라우드를 구성하도록 OpenStack 서비스를 격리하는 작업이 포함됩니다.