고급 오버클라우드 사용자 정의
Red Hat OpenStack Platform director를 사용하여 고급 기능을 구성하는 방법
OpenStack Documentation Team
rhos-docs@redhat.com
초록
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
Red Hat 문서에 관한 피드백 제공
문서 개선을 위한 의견을 보내 주십시오. Red Hat이 어떻게 이를 개선하는지 알려주십시오.
DDF(직접 문서 피드백) 기능 사용
특정 문장, 단락 또는 코드 블록에 대한 직접 주석은 피드백 추가 DDF 기능을 사용하십시오.
- 다중 페이지 HTML 형식으로 설명서를 봅니다.
- 문서 오른쪽 상단에 Feedback (피드백) 버튼이 표시되는지 확인합니다.
- 주석 처리하려는 텍스트 부분을 강조 표시합니다.
- 피드백 추가를 클릭합니다.
- 주석을 사용하여 Add Feedback (피드백 추가) 필드를 작성합니다.
- 선택 사항: 설명서 팀이 문제에 대한 자세한 내용을 문의할 수 있도록 이메일 주소를 추가하십시오.
- 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 템플릿에만 매개 변수를 적용합니다. 이 예에서 MyIP
는 my_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
명령은 다음 프로세스를 통해 실행됩니다.
- 코어 heat 템플릿 컬렉션에서 기본 구성을 로드합니다.
-
environment-file-1.yaml
의 구성을 적용하여 기본 구성의 일반적인 설정을 재정의합니다. -
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 리포지토리를 생성합니다.
템플릿 컬렉션을
/home/stack/templates
디렉터리에 복사합니다.$ cd ~/templates $ cp -r /usr/share/openstack-tripleo-heat-templates .
사용자 지정 템플릿 디렉터리로 변경하고 Git 리포지토리를 초기화합니다.
$ cd ~/templates/openstack-tripleo-heat-templates $ git init .
Git 사용자 이름 및 이메일 주소를 구성합니다.
$ git config --global user.name "<USER_NAME>" $ git config --global user.email "<EMAIL_ADDRESS>"
<USER_NAME>
을 사용하려는 사용자 이름으로 바꿉니다.<EMAIL_ADDRESS>
를 이메일 주소로 바꿉니다.초기 커밋을 위한 모든 템플릿을 스테이징합니다.
$ git add *
초기 커밋을 생성합니다.
$ git commit -m "Initial creation of custom core heat templates"
이렇게 하면 최신 코어 템플릿 컬렉션이 포함된 초기
master
분기가 생성됩니다. 이 분기를 사용자 지정 분기의 기반으로 사용하고 새 템플릿 버전을 이 분기에 병합합니다.
사용자 지정 분기를 사용하여 코어 템플릿 컬렉션에 변경 사항을 저장합니다. 다음 절차를 사용하여
my-customizations
분기를 생성하고 사용자 지정을 추가합니다.my-customizations
분기를 생성하여 해당 분기로 전환합니다.$ git checkout -b my-customizations
- 사용자 지정 분기의 파일을 편집합니다.
git에서 변경 사항을 스테이징합니다.
$ git add [edited files]
사용자 정의 분기의 변경 사항을 커밋합니다.
$ git commit -m "[Commit message for custom changes]"
그러면
my-customizations
분기에 대한 커밋으로 변경 사항이 추가됩니다.master
분기가 업데이트되면 마스터에서my-customizations
를 다시 평가하여
git에서 이러한 커밋을 업데이트된 템플릿 컬렉션에 추가할 수 있습니다. 이렇게 하면 사용자 지정을 추적하고 향후 템플릿 업데이트에서 재생하는 데 도움이 됩니다.
언더클라우드를 업데이트하면
openstack-tripleo-heat-templates
패키지도 업데이트를 수신할 수 있습니다. 이 경우 사용자 정의 템플릿 컬렉션을 업데이트해야 합니다.openstack-tripleo-heat-templates
패키지 버전을 환경 변수로 저장합니다.$ export PACKAGE=$(rpm -qv openstack-tripleo-heat-templates)
템플릿 컬렉션 디렉터리로 변경하고 업데이트된 템플릿의 새 분기를 생성합니다.
$ cd ~/templates/openstack-tripleo-heat-templates $ git checkout -b $PACKAGE
분기의 모든 파일을 제거하고 새 버전으로 바꿉니다.
$ git rm -rf * $ cp -r /usr/share/openstack-tripleo-heat-templates/* .
초기 커밋을 위한 모든 템플릿을 추가합니다.
$ git add *
패키지 업데이트에 대한 커밋을 생성합니다.
$ git commit -m "Updates for $PACKAGE"
분기를 master에 병합합니다. Git 관리 시스템(예: GitLab)을 사용하는 경우 관리 워크플로를 사용합니다. Git을 로컬로 사용하는 경우
master
분기로 전환하여 병합하고git merge
명령을 실행합니다.$ git checkout master $ git merge $PACKAGE
이제 master
분기에 최신 버전의 코어 템플릿 컬렉션이 포함됩니다. 이제 이 업데이트된 컬렉션에서 my-customization
분기를 다시 평가할 수 있습니다.
my-customization
분기를 업데이트합니다.my-customizations
분기로 변경합니다.$ git checkout my-customizations
마스터에서
분기를 다시베이스합니다.$ git rebase master
그러면
my-customizations
분기를 업데이트하고 이 분기에 대한 사용자 지정 커밋을 재생합니다.
리베이스 중에 발생하는 모든 충돌을 해결합니다.
충돌이 포함된 파일을 확인합니다.
$ git status
- 식별된 템플릿 파일의 충돌을 해결합니다.
해결된 파일을 추가합니다.
$ git add [resolved files]
업데이트를 계속합니다.
$ git rebase --continue
사용자 지정 템플릿 컬렉션을 배포합니다.
my-customization
분기로 전환되었는지 확인합니다.git checkout my-customizations
로컬 템플릿 디렉터리를 지정하려면
--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
.pyprocess-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
- 특정 서비스의 기본 매개변수
다음 방법을 사용하여 이러한 매개변수의 값을 수정할 수 있습니다.
- 사용자 지정 매개 변수에 대한 환경 파일을 만듭니다.
-
사용자 지정 매개 변수를 환경 파일의
parameter_defaults
섹션에 포함합니다. -
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를 사용하여 설정할 옵션이 있는 경우 다음 워크플로우를 사용하여 옵션을 식별하고 특정 오버클라우드 매개변수에 매핑합니다.
- 구성할 옵션을 식별합니다. 옵션을 사용하는 서비스를 기록합니다.
이 옵션에 해당하는 Puppet 모듈을 확인합니다. Red Hat OpenStack Platform용 Puppet 모듈은 director 노드의
/etc/puppet/modules
에 있습니다. 각 모듈은 특정 서비스에 해당합니다. 예를 들어keystone
모듈은 OpenStack ID(keystone)에 해당합니다.- Puppet 모듈에 선택한 옵션을 제어하는 변수가 포함된 경우 다음 단계로 이동합니다.
- Puppet 모듈에 선택한 옵션을 제어하는 변수가 없으면 이 옵션에 대한 hieradata가 없습니다. 가능한 경우 오버클라우드가 배포를 완료한 후 수동으로 옵션을 설정할 수 있습니다.
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 사용자 정의” 을 참조하십시오.
절차
OpenStack Identity(keystone)의 알림 형식을 변경하려면 워크플로우를 사용하고 다음 단계를 완료합니다.
-
구성할 OpenStack 매개 변수(
notification_format
)를 식별합니다. notification_format
설정을 위해keystone
Puppet 모듈을 검색합니다.$ grep notification_format /etc/puppet/modules/keystone/manifests/*
이 경우 keystone 모듈은
keystone
::notification_format
변수를 사용하여 이 옵션을 관리합니다.이 변수에 대해
keystone
서비스 템플릿을 검색합니다.$ grep "keystone::notification_format" /usr/share/openstack-tripleo-heat-templates/deployment/keystone/keystone-container-puppet.yaml
출력에는 director에서
KeystoneNotificationFormat
매개변수를 사용하여keystone::notification_format
hieradata를 설정하는 것을 확인할 수 있습니다.
-
구성할 OpenStack 매개 변수(
다음 표는 최종 매핑을 보여줍니다.
director 매개변수 | Puppet hieradata | OpenStack Identity(keystone) 옵션 |
---|---|---|
|
|
|
오버클라우드 환경 파일에 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 주소로 이름 서버를 업데이트합니다.
절차
스크립트를 실행하여 각 노드에
resolv
을 생성합니다..conf 파일을 특정 이름 서버로 추가하는 기본 heat 템플릿 ~/templates/nameserver.
yamlOS::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}
heat 템플릿을
OS::TripleO::NodeUserData
리소스 유형으로 등록하는 환경 파일~/templates/firstboot.yaml
을 생성합니다.resource_registry: OS::TripleO::NodeUserData: /home/stack/templates/nameserver.yaml
첫 번째 부팅 구성을 오버클라우드에 추가하려면 다른 환경 파일과 함께 스택에 환경 파일을 추가합니다.
$ 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]
을 구성 가능 역할 이름으로 교체합니다.
이 예제에서는 특정 역할의 모든 노드에
변수 이름 서버를 추가합니다.
절차
스크립트를 실행하여 노드의
resolv
을 생성합니다..conf 파일에 변수 이름 서버를 작성하는 기본 heat 템플릿 ~/templates/nameserver.
yamlheat_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
라는 매개 변수가 포함되어 있습니다. 이 매개 변수는 각 배포 업데이트의 리소스에 타임스탬프를 제공하여 후속 오버클라우드 업데이트에 리소스가 다시 적용되도록 합니다.
-
heat가 적용할 구성을 인식하도록
heat 템플릿을 역할 기반 리소스 유형에 등록하는 환경 파일
~/templates/pre_config.yaml
을 생성합니다. 예를 들어 컨트롤러 노드에만 구성을 적용하려면ControllerExtraConfigPre
후크를 사용합니다.resource_registry: OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/nameserver.yaml parameter_defaults: nameserver_ip: 192.168.1.1
다른 환경 파일과 함께 스택에 환경 파일을 추가합니다.
$ openstack overcloud deploy --templates \ ... -e /home/stack/templates/pre_config.yaml \ ...
그러면 초기 오버클라우드 생성 또는 이후 업데이트에서 코어 구성이 시작되기 전에 모든 컨트롤러 노드에 구성이 적용됩니다.
후크당 하나의 heat 템플릿에만 각 리소스를 등록할 수 있습니다. 후속 사용은 사용할 heat 템플릿을 재정의합니다.
4.3. 사전 구성: 모든 오버클라우드 역할 사용자 지정
오버클라우드는 OpenStack 구성 요소의 핵심 구성에 Puppet을 사용합니다. director는 첫 번째 부팅이 완료된 후 코어 구성이 시작되기 전에 모든 노드 유형을 설정하는 데 사용할 수 있는 후크를 제공합니다.
- OS::TripleO::NodeExtraConfig
- 핵심 Puppet 구성 전에 모든 노드 역할에 적용되는 추가 구성입니다.
이 예제에서는 각 노드에 변수 이름 서버를 사용하여 resolv.conf
파일을 추가합니다.
절차
스크립트를 실행하여 각 노드의
resolv
을 생성합니다..conf 파일을 변수 이름 서버로 추가하는 기본 heat 템플릿 ~/templates/nameserver.
yamlheat_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
라는 하위 매개 변수가 포함되어 있습니다. 이 매개 변수는 각 배포 업데이트의 리소스에 타임스탬프를 제공하여 후속 오버클라우드 업데이트에 리소스가 다시 적용되도록 합니다.
-
heat가 적용할 구성을 인식하도록
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
다른 환경 파일과 함께 스택에 환경 파일을 추가합니다.
$ 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
파일을 추가합니다.
절차
스크립트를 실행하여 각 노드의
resolv
을 생성합니다..conf 파일을 변수 이름 서버로 추가하는 기본 heat 템플릿 ~/templates/nameserver.
yamlheat_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
라는 매개 변수가 포함되어 있습니다. 이 매개 변수는 각 배포 업데이트의 리소스에 타임스탬프를 제공하여 후속 오버클라우드 업데이트에 리소스가 다시 적용되도록 합니다.
-
heat가 적용할 구성을 인식하도록
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
다른 환경 파일과 함께 스택에 환경 파일을 추가합니다.
$ 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
- 모든 노드에 추가할 구성입니다.
절차
배포 후 구성 프로세스에 구성을 추가하려면
parameter_defaults
섹션에 이러한 매개 변수를 포함하는 환경 파일을 생성합니다. 예를 들어 Compute 호스트의 예약된 메모리를 1024MB로 늘리고 VNC 키맵을 일본어로 설정하려면ComputeExtraConfig
매개변수에서 다음 항목을 사용합니다.parameter_defaults: ComputeExtraConfig: nova::compute::reserved_host_memory: 1024 nova::compute::vnc_keymap: ja
-
배포와 관련된 기타 환경 파일과 함께
openstack overcloud deploy
명령에 이 환경 파일을 포함합니다.
각 매개 변수를 한 번만 정의할 수 있습니다. 후속 사용은 이전 값을 재정의합니다.
4.6. Puppet: 개별 노드에 대한 hieradata 사용자 정의
heat 템플릿 컬렉션을 사용하여 개별 노드에 Puppet hieradata를 설정할 수 있습니다.
절차
노드의 인트로스펙션 데이터에서 시스템 UUID를 식별합니다.
$ openstack baremetal introspection data save 9dcc87ae-4c6d-4ede-81a5-9b20d7dc4a14 | jq .extra.system.product.uuid
이 명령은 시스템 UUID를 반환합니다. 예를 들면 다음과 같습니다.
"f5055c6c-477f-47fb-afe5-95c6928c407f"
환경 파일을 생성하여 노드별 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" ]}}'
-
배포와 관련된 기타 환경 파일과 함께
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
를 설치할 수 있습니다.
절차
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 클래스가 포함되어 있습니다.
heat 템플릿을
OS::TripleO::NodeExtraConfigPost:
리소스 유형으로 등록하는 환경 파일~templates/puppet_post_config.yaml
을 생성합니다.resource_registry: OS::TripleO::NodeExtraConfigPost: /home/stack/templates/custom_puppet_config.yaml
배포와 관련된 기타 환경 파일과 함께
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 기반 방법으로 전환해야 합니다. 자세한 내용은 ] 및 xref:ref_rhel-registration-to-rhsm-mappings_portal 을 참조하십시오.
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 | 설명 |
---|---|
|
등록 방법을 선택합니다. |
|
등록에 사용하려는 조직입니다. 이 ID를 찾으려면 언더클라우드 노드에서 |
|
사용하려는 서브스크립션 풀 ID입니다. 서브스크립션을 자동 첨부하지 않으려면 이 매개변수를 사용합니다. 이 ID를 찾으려면 언더클라우드 노드에서 |
| 등록에 사용할 활성화 키입니다. |
|
이 매개변수를 사용하여 호환 가능한 서브스크립션을 이 시스템에 자동으로 첨부합니다. 이 기능을 활성화하려면 값을 |
| 콘텐츠를 가져오는 기본 URL입니다. 기본 URL은 Red Hat Content Delivery Network입니다. Satellite 서버를 사용하는 경우 이 값을 Satellite 서버 콘텐츠 리포지토리의 기본 URL로 변경합니다. |
| 등록을 위한 서브스크립션 관리 서비스의 호스트 이름입니다. 기본값은 Red Hat 서브스크립션 관리 호스트 이름입니다. Satellite 서버를 사용하는 경우 이 값을 Satellite 서버 호스트 이름으로 변경합니다. |
| 활성화하려는 리포지토리 목록입니다. |
| 등록할 사용자 이름입니다. 가능한 경우 등록에 활성화 키를 사용합니다. |
| 등록할 암호입니다. 가능한 경우 등록에 활성화 키를 사용합니다. |
| 리포지토리 고정을 위한 Red Hat Enterprise Linux 릴리스. 이는 Red Hat OpenStack Platform의 8.2로 설정됩니다. |
|
HTTP 프록시의 호스트 이름입니다. 예: |
|
HTTP 프록시 통신용 포트입니다. 예를 들면 다음과 같습니다. |
| HTTP 프록시에 액세스할 사용자 이름입니다. |
| HTTP 프록시에 액세스할 암호입니다. |
rhsm_
를 함께 사용할 수 있습니다. If method가
reposportal
로 설정된 경우에만 use rhsm_activation_key
및rhsm_rhsm_method
가 satellite 로 설정되면 either rhsm_activation_key or
만 사용할 수 있습니다.
rhsm_
repos
5.3. rhsm 구성 가능 서비스를 사용하여 오버클라우드 등록
rhsm
구성 가능 서비스를 활성화하고 구성하는 환경 파일을 생성합니다. director는 이 환경 파일을 사용하여 노드를 등록하고 서브스크립션합니다.
절차
-
templates/rhsm.yml
이라는 환경 파일을 만들어 구성을 저장합니다. 환경 파일에 구성을 포함합니다. 예를 들면 다음과 같습니다.
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에 전달합니다.
-
- 환경 파일을 저장합니다.
5.4. 다른 역할에 rhsm 구성 가능 서비스 적용
역할별로 the rhsm
구성 가능 서비스를 적용할 수 있습니다. 예를 들어 컨트롤러 노드, 컴퓨팅 노드 및 Ceph Storage 노드에 다양한 구성 세트를 적용할 수 있습니다.
절차
-
templates/rhsm.yml
이라는 환경 파일을 만들어 구성을 저장합니다. 환경 파일에 구성을 포함합니다. 예를 들면 다음과 같습니다.
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
,ComputeParameters
및CephStorageParameters
매개 변수는 각각 별도의RhsmVars
매개변수를 사용하여 서브스크립션 세부 정보를 해당 역할에 전달합니다.참고CephStorageParameter
매개변수를 설정하여 Red Hat Ceph Storage 서브스크립션 및 Ceph Storage 관련 리포지토리를 사용합니다.s 매개변수 내에서 RhsmVar
srhsm_repos
매개변수에 컨트롤러 및 컴퓨팅 노드에 필요한 EUS(Extended Update Support) 리포지토리 대신 표준 Red Hat Enterprise Linux 리포지토리가 포함되어 있는지 확인합니다.- 환경 파일을 저장합니다.
5.5. 오버클라우드를 Red Hat Satellite Server에 등록
Red Hat 고객 포털 대신 Red Hat Satellite에 노드를 등록하도록 rhsm
구성 가능 서비스를 활성화하고 구성하는 환경 파일을 생성합니다.
절차
-
templates/rhsm.yml
이라는 환경 파일을 만들어 구성을 저장합니다. 환경 파일에 구성을 포함합니다. 예를 들면 다음과 같습니다.
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에 전달합니다.- 환경 파일을 저장합니다.
5.6. rhsm 구성 가능 서비스로 전환
이전 rhel-registration
메서드는 Overcloud 등록을 처리하는 bash 스크립트를 실행합니다. 이 메서드의 스크립트 및 환경 파일은 /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration/
의 코어 heat 템플릿 컬렉션에 있습니다.
rhel-registration
방법에서 구성 가능 서비스로 전환하려면 다음
단계를 완료합니다.
절차
rhel-registration
환경 파일을 향후 배포 작업에서 제외합니다. 대부분의 경우 다음 파일을 제외합니다.-
rhel-registration/environment-rhel-registration.yaml
-
rhel-registration/rhel-registration-resource-registry.yaml
-
사용자 지정
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 ...
-
향후 배포 작업에 환경 파일 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-registration | rhsm / RhsmVars |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.8. rhsm 구성 가능 서비스를 사용하여 오버클라우드 배포
Ansible에서 오버클라우드 노드의 등록 프로세스를 제어하도록 the rhsm
구성 가능 서비스를 사용하여 오버클라우드를 배포합니다.
절차
openstack overcloud deploy
명령을 사용하여rhsm.yml
환경 파일을 포함합니다.openstack overcloud deploy \ <other cli args> \ -e ~/templates/rhsm.yaml
이렇게 하면 오버클라우드의 Ansible 구성 및 Ansible 기반 등록이 활성화됩니다.
- Overcloud 배포가 완료될 때까지 기다립니다.
오버클라우드 노드에서 서브스크립션 세부 정보를 확인합니다. 예를 들어 컨트롤러 노드에 로그인하고 다음 명령을 실행합니다.
$ sudo subscription-manager status $ sudo subscription-manager list --consumed
5.9. Ansible 기반 등록 수동 실행
director 노드에 동적 인벤토리 스크립트를 사용하여 배포된 오버클라우드에 Ansible 기반 수동 등록을 수행할 수 있습니다. 이 스크립트를 사용하여 노드 역할을 호스트 그룹으로 정의한 다음 ansible-playbook
을 사용하여 플레이북을 실행합니다. 다음 예제 플레이북을 사용하여 컨트롤러 노드를 수동으로 등록합니다.
절차
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
변수를 사용하여 나열됩니다.
오버클라우드를 배포한 후 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
파일을 자동으로 생성하는 여러 명령을 제공합니다.
절차
기본 역할 템플릿을 나열합니다.
$ openstack overcloud roles list BlockStorage CephStorage Compute ComputeHCI ComputeOvsDpdk Controller ...
openstack overcloud roles show
명령을 사용하여 YAML 형식으로 역할 정의를 확인합니다.$ openstack overcloud roles show Compute
사용자 지정
roles_data
파일을 생성합니다.openstack overcloud roles generate
명령을 사용하여 사전 정의된 여러 역할을 하나의 파일에 결합합니다. 예를 들어 다음 명령을 실행하여Controller
,Compute
및Networker
역할이 포함된 roles_data.yaml
파일을 생성합니다.$ openstack overcloud roles generate -o ~/roles_data.yaml Controller Compute Networker
출력 파일에서 이름을 정의하는 데
-o
옵션을 사용합니다.이 명령은 사용자 지정
roles_data
파일을 생성합니다. 그러나 이전 예제에서는 모두 동일한 네트워킹 에이전트를 포함하는Controller
및Networker
역할을 사용합니다. 즉, 네트워킹 서비스는컨트롤러
역할에서Networker
역할로 확장되고, 오버클라우드에서컨트롤러
노드와네트워크 노드
간에 네트워킹 서비스의 부하를 분산합니다.이
Networker
역할을 독립 실행형으로 만들려면 고유한 사용자 지정컨트롤러
역할과 필요한 다른 역할을 만들 수 있습니다. 이를 통해 고유한 사용자 지정 역할에서roles_data
파일을 생성할 수 있습니다.코어 heat 템플릿 컬렉션의 디렉터리를
stack
사용자의 홈 디렉터리에 복사합니다.$ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
이 디렉터리에서 사용자 지정 역할 파일을 추가하거나 수정합니다. 역할 하위 명령과 함께
--roles-path
옵션을 사용하여 이 디렉터리를 사용자 지정 역할의 소스로 사용합니다.$ openstack overcloud roles generate -o my_roles_data.yaml \ --roles-path ~/roles \ Controller Compute Networker
이 명령은
~/
파일을 생성합니다.roles 디렉터리의 개별 역할에서 하나의 my_roles
_data.yaml
기본 역할 컬렉션에는 ControllerOpenStack
역할도 포함되어 있으며, 이 역할은 Networker
,Messaging
및 Database
역할에 대한 서비스가 포함되지 않습니다. 독립 실행형 Networker
,Messaging
및 Database
역할과 함께 ControllerOpenStack
을 사용할 수 있습니다.
6.4. 지원되는 사용자 정의 역할
다음 표에는 사용 가능한 사용자 지정 역할에 대한 정보가 나와 있습니다. /usr/share/openstack-tripleo-heat-templates/roles
디렉터리에서 사용자 지정 역할 템플릿을 찾을 수 있습니다.
Role | 설명 | 파일 |
---|---|---|
| OpenStack Block Storage(cinder) 노드. |
|
| 전체 독립 실행형 Ceph Storage 노드. OSD, MON, Object Gateway(RGW), Object Operations(MDS), Manager(MGR) 및 RBD Mirroring이 포함됩니다. |
|
| 독립 실행형 스케일 아웃 Ceph Storage 파일 역할. OSD 및 MDS(Object Operations) 포함. |
|
| 독립형 스케일 아웃 Ceph Storage 오브젝트 역할. OSD 및 개체 게이트웨이(RGW)를 포함합니다. |
|
| Ceph Storage OSD 노드 역할. |
|
| 대체 컴퓨팅 노드 역할. |
|
| DVR이 활성화된 컴퓨팅 노드 역할. |
|
| 하이퍼컨버지드 인프라를 사용하는 계산 노드. 계산 및 Ceph OSD 서비스가 포함되어 있습니다. |
|
|
Compute Instance HA 노드 역할. environment |
|
| Caviumio Smart NIC가 있는 계산 노드. |
|
| Compute OVS DPDK RealTime 역할. |
|
| 컴퓨팅 OVS DPDK 역할. |
|
| ppc64le 서버의 컴퓨팅 역할. |
|
|
실시간 동작을 위해 최적화된 컴퓨팅 역할. 이 역할을 사용하는 경우 |
|
| 컴퓨팅 SR-IOV RealTime 역할. |
|
| 컴퓨팅 SR-IOV 역할. |
|
| 표준 컴퓨팅 노드 역할. |
|
|
데이터베이스, 메시징, 네트워킹 및 OpenStack 계산(nova) 제어 구성 요소를 포함하지 않는 컨트롤러 역할. |
|
| 핵심 컨트롤러 서비스가 로드되었지만 Ceph 스토리지(MON) 구성 요소가 없는 컨트롤러 역할. 이 역할은 Ceph Storage 기능이 아닌 데이터베이스, 메시징 및 네트워크 기능을 처리합니다. |
|
|
OpenStack Compute(nova) 제어 구성 요소를 포함하지 않는 컨트롤러 역할. |
|
|
데이터베이스, 메시징 및 네트워킹 구성 요소를 포함하지 않는 컨트롤러 역할. |
|
| 모든 핵심 서비스가 로드되고 Ceph NFS를 사용하는 컨트롤러 역할. 이 역할은 데이터베이스, 메시징 및 네트워크 기능을 처리합니다. |
|
| 모든 핵심 서비스가 로드된 컨트롤러 역할. 이 역할은 데이터베이스, 메시징 및 네트워크 기능을 처리합니다. |
|
| 일반 Controller 역할과 동일하지만 OVN 메타데이터 에이전트가 배포된 상태에서도 마찬가지입니다. |
|
| 독립 실행형 데이터베이스 역할. Pacemaker를 사용하여 Galera 클러스터로 관리되는 데이터베이스. |
|
| 하이퍼컨버지드 인프라 및 모든 Ceph Storage 서비스가 포함된 계산 노드. OSD, MON, Object Gateway(RGW), Object Operations(MDS), Manager(MGR) 및 RBD Mirroring이 포함됩니다. |
|
| 하이퍼컨버지드 인프라 및 Ceph Storage 파일 서비스가 포함된 계산 노드. OSD 및 MDS(Object Operations) 포함. |
|
| 하이퍼컨버지드 인프라 및 Ceph Storage 블록 서비스가 포함된 계산 노드. OSD, MON, Manager가 포함됩니다. |
|
| 하이퍼컨버지드 인프라 및 Ceph Storage 오브젝트 서비스가 포함된 계산 노드. OSD 및 개체 게이트웨이(RGW)를 포함합니다. |
|
| Ironic Conductor 노드 역할. |
|
| 독립 실행형 메시징 역할. Pacemaker로 관리되는 RabbitMQ. |
|
| 독립 실행형 네트워킹 역할. OpenStack 네트워킹(neutron) 에이전트를 자체적으로 실행합니다. 배포에서 ML2/OVN 메커니즘 드라이버를 사용하는 경우 ML2/OVN으로 사용자 지정 역할 배포 의 추가 단계를 참조하십시오. |
|
| 일반 Networker 역할과 동일하지만 OVN 메타데이터 에이전트가 배포되었습니다. ML2/OVN을 사용하여 사용자 지정 역할 배포 의 추가 단계를 참조하십시오. |
|
|
OpenStack Compute(nova) 제어 에이전트를 자체적으로 실행하는 독립 실행형 |
|
| Swift 오브젝트 스토리지 노드 역할. |
|
| 모든 지표 및 알람 서비스가 포함된 원격 분석 역할. |
|
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
,Tenant
및Management
가 포함됩니다.- 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
입니다.-
기본값은 Controller, Object Storage 및 Ceph Storage 노드의 경우
- 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
역할을 생성할 수 있습니다.
역할 이름은 문자 또는 숫자로 시작하고 문자, 숫자, 하이픈만 포함해야 합니다. 밑줄을 역할 이름에 사용해서는 안 됩니다.
절차
기본
역할
디렉터리의 사용자 지정 사본을 생성합니다.$ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
~/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
노드가 포함되도록CountDefault
를1
로 설정합니다.선택 사항: 기존 오버클라우드에서 서비스를 확장하려면
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 ...
~/roles
디렉터리를 소스로 사용하여 새roles_data-horizon.yaml
파일을 생성합니다.$ openstack overcloud roles generate -o roles_data-horizon.yaml \ --roles-path ~/roles \ Controller Compute Horizon
특정 노드에 태그를 지정할 수 있도록 이 역할에 대한 새 플레이버를 정의합니다. 이 예에서는 다음 명령을 사용하여
Horizon
플레이버를 생성합니다.Horizon
플레이버를 생성합니다.(undercloud)$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 horizon
참고이러한 속성은 인스턴스를 예약하는 데 사용되지 않지만 Compute 스케줄러는 디스크 크기를 사용하여 루트 파티션 크기를 결정합니다.
대시보드 서비스(horizon)를 사용자 정의 리소스 클래스로 지정할 각 베어 메탈 노드에 태그를 지정합니다.
(undercloud)$ openstack baremetal node set --resource-class baremetal.HORIZON <NODE>
<NODE>
를 베어 메탈 노드의 ID로 바꿉니다.Horizon 플레이버를
사용자 지정 리소스 클래스와 연결합니다.(undercloud)$ openstack flavor set --property resources:CUSTOM_BAREMETAL_HORIZON=1 horizon
베어 메탈 노드의 리소스 클래스에 해당하는 사용자 정의 리소스 클래스의 이름을 확인하려면 리소스 클래스를 대문자로 변환하고 문장 부호를 밑줄로 바꾸고, 값 앞에
CUSTOM_
을 추가합니다.참고플레이버는 베어 메탈 리소스 클래스의 인스턴스 하나만 요청할 수 있습니다.
Compute 스케줄러가 인스턴스 예약에 베어 메탈 플레이버 속성을 사용하지 않도록 다음 플레이버 속성을 설정합니다.
(undercloud)$ openstack flavor set --property resources:VCPU=0 --property resources:MEMORY_MB=0 --property resources:DISK_GB=0 horizon
다음 환경 파일 스니펫을 사용하여 Horizon 노드 수 및 플레이버를 정의합니다.
parameter_defaults: OvercloudHorizonFlavor: horizon HorizonCount: 1
배포와 관련된 기타 모든 환경 파일과 함께
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
,ObjectStorageServices
및 CephStorageServices
.
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
매개변수의 기본 목록으로 정의됩니다.
환경 파일을 사용하여 서비스 매개변수의 기본 목록을 재정의할 수도 있습니다. 예를 들어 환경 파일에서 ControllerServices
를 parameter_default
로 정의하여 roles_data.yaml
파일의 서비스 목록을 재정의할 수 있습니다.
6.9. 역할에서 서비스 추가 및 제거
서비스를 추가하거나 제거하는 기본 방법은 노드 역할에 대한 기본 서비스 목록 복사본을 생성한 다음 서비스를 추가하거나 제거하는 것입니다. 예를 들어 컨트롤러 노드에서 OpenStack Orchestration(heat)을 제거할 수 있습니다.
절차
기본
역할
디렉터리의 사용자 지정 사본을 생성합니다.$ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
~/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
새
roles_data
파일을 생성합니다.$ openstack overcloud roles generate -o roles_data-no_heat.yaml \ --roles-path ~/roles \ Controller Compute Networker
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
파일을 사용합니다.
절차
CinderBackup
서비스를cinder-backup
구성이 포함된 heat 템플릿에 연결하는 환경 파일에 항목을 추가합니다.resource_registry: OS::TripleO::Services::CinderBackup: ../podman/services/pacemaker/cinder-backup.yaml ...
이 항목은 기본 null 작업 리소스를 재정의하고 서비스를 활성화합니다.
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 소프트웨어가 설치되어 있지만 활성화 또는 구성되지 않습니다.
절차
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 ...
기존
Controller
및Compute
역할을 유지해야 합니다.환경 파일
generic-node-params.yaml
을 생성하여 필요한 일반 Red Hat Enterprise Linux 8 노드 수와 프로비저닝할 노드를 선택할 때 플레이버를 지정합니다.parameter_defaults: OvercloudGenericFlavor: baremetal GenericCount: 1
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. 컨테이너 이미지 준비
오버클라우드 설치에는 컨테이너 이미지를 가져올 위치와 저장 방법을 결정하는 환경 파일이 필요합니다. 컨테이너 이미지를 준비하는 데 사용할 수 있는 이 환경 파일을 생성하고 사용자 지정하십시오.
오버클라우드의 특정 컨테이너 이미지 버전을 구성해야 하는 경우 이미지를 특정 버전에 고정해야 합니다. 자세한 내용은 오버클라우드의 컨테이너 이미지 고정을 참조하십시오.
절차
-
stack
사용자로 언더클라우드 호스트에 로그인합니다. 기본 컨테이너 이미지 준비 파일을 생성합니다.
$ 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
파일을 사용하여 언더클라우드와 오버클라우드의 컨테이너 이미지 소스를 모두 정의할 수 있습니다.
-
-
containers-prepare-parameter.yaml
을 요구 사항에 맞게 수정합니다.
7.4. 컨테이너 이미지 준비 매개변수
컨테이너를 준비하는 데 필요한 기본 파일(containers-prepare-parameter.yaml
)에는 ContainerImagePrepare
heat 매개변수가 포함되어 있습니다. 이 매개변수는 이미지 세트를 준비하기 위한 다양한 설정을 정의합니다.
parameter_defaults: ContainerImagePrepare: - (strategy one) - (strategy two) - (strategy three) ...
각각의 설정에서 하위 매개변수 세트를 통해 사용할 이미지와 해당 이미지의 사용 방법을 정의할 수 있습니다. 다음 표에는 각 ContainerImagePrepare
전략에 사용할 수 있는 하위 매개변수에 대한 정보가 나와 있습니다.
매개변수 | 설명 |
---|---|
| 전략에서 이미지 이름을 제외하는 정규식 목록입니다. |
|
전략에 포함할 정규식 목록입니다. 기존 이미지와 일치하는 이미지 이름이 하나 이상 있어야 합니다. |
|
대상 이미지 태그에 추가할 문자열입니다. 예를 들어 태그가 16.1.3-5.161인 이미지를 가져와서 |
| 수정할 이미지를 필터링하는 이미지 레이블로 이루어진 사전입니다. 이미지가 정의된 레이블과 일치하면 director에서 그 이미지를 수정 프로세스에 포함합니다. |
| 이미지를 대상 레지스트리로 푸시하기 전 업로드 중에 실행할 ansible 역할 이름의 문자열입니다. |
|
|
| 업로드 프로세스 중 이미지를 푸시할 레지스트리의 네임스페이스를 정의합니다.
Red Hat Container Catalog에서 직접 이미지를 가져오는 동안 프로덕션 환경에서 이 매개변수를
|
| 원본 컨테이너 이미지를 가져온 소스 레지스트리입니다. |
|
초기 이미지를 가져올 위치를 정의하는 |
|
지정된 컨테이너 이미지 메타데이터 레이블의 값을 사용하여 모든 이미지에 대한 태그를 생성하고 해당 태그가 지정된 이미지를 가져옵니다. 예를 들어 |
이미지를 언더클라우드로 내보내는 경우 push
. _destination 대신 push_destination: true
를 사용합니다. UNDERCLOUD_IP:PORTpush_destination: true
방식은 IPv4 및 IPv6 주소 모두에서 일관성 수준을 제공합니다.
set
매개변수에 여러 key: value
정의를 사용할 수 있습니다.
키 | 설명 |
---|---|
| Ceph Storage 컨테이너 이미지의 이름입니다. |
| Ceph Storage 컨테이너 이미지의 네임스페이스입니다. |
| Ceph Storage 컨테이너 이미지의 태그입니다. |
| Ceph Storage Alert Manager 컨테이너 이미지의 이름, 네임스페이스 및 태그입니다. |
| Ceph Storage Grafana 컨테이너 이미지의 이름, 네임스페이스 및 태그입니다. |
| Ceph Storage 노드 내보내기 컨테이너 이미지의 이름, 네임스페이스 및 태그입니다. |
| Ceph Storage Prometheus 컨테이너 이미지의 이름, 네임스페이스 및 태그입니다. |
| 각 OpenStack 서비스 이미지의 접두사입니다. |
| 각 OpenStack 서비스 이미지의 접미사입니다. |
| 각 OpenStack 서비스 이미지의 네임스페이스입니다. |
|
사용할 OpenStack Networking (Neutron) 컨테이너를 결정하는 데 사용할 드라이버입니다. null 값을 사용하여 표준 |
|
소스의 모든 이미지에 대한 특정 태그를 설정합니다. 정의되지 않은 경우 director는 Red Hat OpenStack Platform 버전 번호를 기본값으로 사용합니다. 이 매개변수가 |
컨테이너 이미지는 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에서 검사하는 최신 컨테이너 이미지 릴리스의 레이블 메타데이터에서 태그를 생성합니다. 예를 들어 특정 컨테이너의 레이블에서 다음version
및release
메타데이터를 사용할 수 있습니다."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
매개변수를 생략합니다. -
tag
와tag_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
파일에 ContainerImageRegistryCredentials
및 ContainerImageRegistryLogin
매개변수를 포함합니다.
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_username
및 my_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
이 구성되지 않은 경우 ContainerImageRegistryLogin
을 true
로 설정해야 합니다.
parameter_defaults: ContainerImagePrepare: - push_destination: false set: namespace: registry.redhat.io/... ... ... ContainerImageRegistryCredentials: registry.redhat.io: myuser: 'p@55w0rd!' ContainerImageRegistryLogin: true
하지만 오버클라우드 노드에서 ContainerImageRegistryCredentials
에 정의된 레지스트리 호스트에 네트워크로 연결할 수 없고 ContainerImageRegistryLogin
을 true
로 설정하는 경우, 로그인할 때 배포에 실패할 수 있습니다. 오버클라우드 노드에서 ContainerImageRegistryCredentials
에 정의된 레지스트리 호스트에 네트워크로 연결할 수 없고 push_destination
을 true
로 설정하고 ContainerImageRegistryLogin
을 false
로 설정하여 오버클라우드 노드가 언더클라우드에서 이미지를 가져오도록 합니다.
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.2-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
includes
및 excludes
매개 변수는 정규식을 사용하여 각 항목에 대한 이미지 필터링을 제어합니다. 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을 사용하여 컨테이너 이미지 수정을 지원합니다.
절차
다음 예제에서는
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 ...
/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 하드웨어를 블록 스토리지 백엔드로 사용하기 위해 벤더 플러그인을 배포하는 방법을 보여줍니다.
지원되는 백엔드 어플라이언스 및 드라이버에 대한 자세한 내용은 스토리지 가이드 의 타사 스토리지 공급자를 참조하십시오.
절차
오버클라우드의 새 컨테이너 이미지 파일을 생성합니다.
$ sudo openstack tripleo container image prepare default \ --local-push-destination \ --output-env-file containers-prepare-parameter-dellemc.yaml
- containers-prepare-parameter-dellemc.yaml 파일을 편집합니다.
기본 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}"
공급자 플러그인의 대체 컨테이너 이미지가 포함된
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 ...
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]
-
containers-prepare-parameter-dellemc.yaml
파일을 저장합니다. 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.yaml
및network-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
파일을 복사하고 복사본을 수정하여 기본 격리된 네트워크를 구성합니다.
절차
기본
network_data.yaml
파일을 복사합니다.$ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.
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_subnet
및ip_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 디렉토리 | 설명 | 환경 파일 |
---|---|---|
|
|
|
|
기본 Linux 브리지에 |
|
|
|
|
|
|
|
외부 네트워크 없이 오버클라우드를 배포하기 위한 환경 파일(예: 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
템플릿을 사용합니다.
절차
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. 구성 가능 네트워크 추가
구성 가능 네트워크를 사용하여 다양한 서비스의 네트워크를 추가합니다. 예를 들어 스토리지 백업 트래픽 전용 네트워크가 있는 경우 네트워크를 여러 역할에 제공할 수 있습니다.
절차
기본
network_data.yaml
파일을 복사합니다.$ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.
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
를 사용하여 가독성을 위해 이름을 표준화할 수도 있습니다. 예를 들어InternalApi
를internal_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_pools
및gateway_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
네트워크를 포함할 수 있습니다.
절차
사용자 지정
roles_data.yaml
파일이 없는 경우 기본값을 홈 디렉터리에 복사합니다.$ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/.
-
사용자 지정
roles_data.yaml
파일을 편집합니다. 네트워크를 추가할 역할에 대한
네트워크
목록에 네트워크 이름을 포함합니다. 예를 들어StorageBackup
네트워크를 Ceph Storage 역할에 추가하려면 다음 예제 스니펫을 사용합니다.- name: CephStorage description: | Ceph OSD Storage node role networks: - Storage - StorageMgmt - StorageBackup
- 사용자 지정 네트워크를 해당 역할에 추가한 후 파일을 저장합니다.
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를 사용합니다.
절차
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을 업데이트합니다.
절차
network_data.yaml
파일에서 이름을 변경할 각 네트워크의name_lower
매개변수에 새 이름을 입력합니다.- name: InternalApi name_lower: MyCustomInternalApi
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 구문을 렌더링하고 사용자 지정 구성의 기반으로 렌더링된 템플릿을 사용합니다.
절차
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
여러 NIC 예제를 복사합니다.
$ cp -r ~/openstack-tripleo-heat-templates-rendered/network/config/multiple-nics/ ~/templates/custom-nics/
-
사용자 지정 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 서비스에서 제공하는 기본 경로를 사용합니다. |
persist_mapping | False | 시스템 이름 대신 장치 별칭 구성을 작성합니다. |
dhclient_args | 없음 | DHCP 클라이언트에 전달할 인수입니다. |
dns_servers | 없음 | 인터페이스에 사용할 DNS 서버 목록입니다. |
ethtool_opts |
특정 NIC에서 VXLAN을 사용할 때 처리량을 개선하기 위해 이 옵션을 |
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 서비스에서 제공하는 기본 경로를 사용합니다. |
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 서비스에서 제공하는 기본 경로를 사용합니다. |
persist_mapping | False | 시스템 이름 대신 장치 별칭 구성을 작성합니다. |
dhclient_args | 없음 | DHCP 클라이언트에 전달할 인수입니다. |
dns_servers | 없음 | 본딩에 사용할 DNS 서버 목록입니다. |
ovs_bridge
여러 인터페이스
,ovs_bond
및 vlan
오브젝트를 함께 연결하는 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 서비스에서 제공하는 기본 경로를 사용합니다. |
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"
nic2
는 primary: 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 서비스에서 제공하는 기본 경로를 사용합니다. |
persist_mapping | False | 시스템 이름 대신 장치 별칭 구성을 작성합니다. |
dhclient_args | 없음 | DHCP 클라이언트에 전달할 인수입니다. |
dns_servers | 없음 | 본딩에 사용할 DNS 서버 목록입니다. |
linux_bridge
여러 인터페이스
,linux_bond
및 vlan
오브젝트를 함께 연결하는 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 서비스에서 제공하는 기본 경로를 사용합니다. |
persist_mapping | False | 시스템 이름 대신 장치 별칭 구성을 작성합니다. |
dhclient_args | 없음 | DHCP 클라이언트에 전달할 인수입니다. |
dns_servers | 없음 | 브리지에 사용할 DNS 서버 목록입니다. |
routes
네트워크 인터페이스, VLAN, 브리지 또는 본딩에 적용할 경로 목록을 정의합니다.
예를 들면 다음과 같습니다.
- type: interface name: nic2 ... routes: - ip_netmask: 10.1.2.0/24 gateway_ip: 10.1.2.1
옵션 | Default | 설명 |
---|---|---|
ip_netmask | 없음 | 대상 네트워크의 IP 및 넷마스크. |
default | False |
이 경로를 기본 경로로 설정합니다. |
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: - type: interface name: nic1 mtu: get_param: ControlPlaneMtu use_dhcp: false addresses: - ip_netmask: list_join: - / - - get_param: ControlPlaneIp - get_param: ControlPlaneSubnetCidr routes: list_concat_unique: - get_param: ControlPlaneStaticRoutes - type: ovs_bridge name: bridge_name dns_servers: get_param: DnsServers domain: get_param: DnsSearchDomains members: - type: ovs_bond name: bond1 mtu: get_attr: [MinViableMtu, value] ovs_options: get_param: BondInterfaceOvsOptions members: - type: interface name: nic2 mtu: get_attr: [MinViableMtu, value] primary: true - type: interface name: nic3 mtu: get_attr: [MinViableMtu, value] - type: vlan mtu: get_param: StorageMtu vlan_id: get_param: StorageNetworkVlanID addresses: - ip_netmask: get_param: StorageIpSubnet routes: list_concat_unique: - get_param: StorageInterfaceRoutes - type: vlan mtu: get_param: StorageMgmtMtu vlan_id: get_param: StorageMgmtNetworkVlanID addresses: - ip_netmask: get_param: StorageMgmtIpSubnet routes: list_concat_unique: - get_param: StorageMgmtInterfaceRoutes - type: vlan mtu: get_param: InternalApiMtu vlan_id: get_param: InternalApiNetworkVlanID addresses: - ip_netmask: get_param: InternalApiIpSubnet routes: list_concat_unique: - get_param: InternalApiInterfaceRoutes - type: vlan mtu: get_param: TenantMtu vlan_id: get_param: TenantNetworkVlanID addresses: - ip_netmask: get_param: TenantIpSubnet routes: list_concat_unique: - get_param: TenantInterfaceRoutes - type: vlan mtu: get_param: ExternalMtu vlan_id: get_param: ExternalNetworkVlanID addresses: - ip_netmask: get_param: ExternalIpSubnet routes: list_concat_unique: - get_param: ExternalInterfaceRoutes - - default: true next_hop: get_param: ExternalInterfaceDefaultRoute
이 템플릿은 세 개의 네트워크 인터페이스를 사용하고 번호가 지정된 VLAN 장치인 nic1
에서 nic3
에 태그된 VLAN 장치를 할당합니다. nic2
및 nic3
에서 이 템플릿은 스토리지, 테넌트, 외부 네트워크를 호스팅하는 OVS 브리지를 생성합니다. 결과적으로 다음과 같은 레이아웃이 생성됩니다.
NIC1 (프로비저닝)
- 프로비저닝/컨트롤 플레인
NIC2 및 NIC3 (Management)
- 내부 API
- 스토리지
- 스토리지 관리
- 테넌트 네트워크(VXLAN 터널링)
- 테넌트 VLAN/프로바이더 VLAN
- 외부(공용 API)
- 외부 VLAN (유동 IP/SNAT)
10.6. 사용자 지정 네트워크의 네트워크 인터페이스 템플릿 고려 사항
구성 가능 네트워크를 사용하는 경우 process-templates.py
스크립트는 정적 템플릿을 렌더링하여 network_data.yaml 및 roles _data.
포함합니다. 렌더링된 NIC 템플릿에 다음 항목이 포함되어 있는지 확인합니다.
yaml 파일에 정의된 네트워크
및 역할을
- 사용자 지정 구성 가능 네트워크를 포함하여 각 역할에 대한 정적 파일입니다.
- 각 역할의 정적 파일에서 올바른 네트워크 정의.
각 정적 파일에는 네트워크가 역할에 사용되지 않더라도 사용자 지정 네트워크의 모든 매개 변수 정의가 필요합니다. 렌더링된 템플릿에 이러한 매개변수가 포함되어 있는지 확인합니다. 예를 들어 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 템플릿의 기본 매개변수 값을 재정의하는 데 사용할 수 있는 매개변수 목록입니다.
매개변수 | 설명 | 유형 |
---|---|---|
| 컨트롤러 노드 이외의 역할에 대한 기본 경로로 사용되는 컨트롤 플레인의 라우터 IP 주소입니다. 라우터 대신 IP masquerade를 사용하는 경우 이 값을 언더클라우드 IP로 설정합니다. | string |
|
컨트롤 플레인에서 사용되는 IP 네트워크의 CIDR 넷마스크입니다. 컨트롤 플레인 네트워크에서 192.168.24.0/24를 사용하는 경우 CIDR은 | 문자열 (항상 숫자임) |
|
특정 네트워크의 전체 네트워크 및 CIDR 넷마스크. 기본값은 network_ | string |
|
특정 네트워크의 IP 할당 범위입니다. 기본값은 network_ | 해시 |
|
특정 네트워크의 노드의 VLAN ID입니다. 기본값은 network | 숫자 |
|
역할 또는 다른 네트워크 경로에 대한 기본 경로로 사용할 수 있는 특정 네트워크의 라우터 주소입니다. 기본값은 network_ | string |
| resolv.conf에 추가된 DNS 서버 목록입니다. 일반적으로 최대 2대의 서버를 허용합니다. | 쉼표로 구분된 목록 |
| Overcloud 노드를 프로비저닝하는 데 사용되는 메타데이터 서버의 IP 주소입니다. 이 값을 컨트롤 플레인에 있는 언더클라우드의 IP 주소로 설정합니다. | string |
|
본딩 인터페이스에 대한 옵션. 예를 들어 | string |
|
OpenStack Networking(neutron)에 사용할 외부 브리지 이름의 레거시 값입니다. 이 값은 기본적으로 비어 있습니다. 즉 | string |
|
neutron 플러그인에서 구성할 플랫 네트워크를 정의합니다. 기본값은 외부 네트워크 생성을 허용하는 | string |
|
사용하려는 논리적 브릿지와 물리적 브리지 매핑. 기본값은 호스트( | string |
|
네트워크 분리를 사용하지 않을 때 네트워크 노드의 | string |
|
OpenStack Networking(neutron)의 테넌트 네트워크 유형입니다. 여러 값을 지정하려면 쉼표로 구분된 목록을 사용합니다. 지정한 첫 번째 유형은 사용 가능한 모든 네트워크가 모두 사용될 때까지 사용되는 다음 유형이 사용됩니다. 예를 들어 | string |
|
neutron 테넌트 네트워크의 터널 유형입니다. 여러 값을 지정하려면 쉼표로 구분된 문자열을 사용합니다. 예를 들어 | 문자열 / 쉼표로 구분된 목록 |
|
테넌트 네트워크 할당에 사용하려는 GRE 터널 ID 범위입니다. 예를 들어 | string |
|
테넌트 네트워크 할당에 사용하려는 VXLAN VNI ID 범위입니다. 예를 들면 | string |
|
터널링된 모든 네트워크를 활성화 또는 완전히 비활성화할지 여부를 정의합니다. 나중에 튜닝된 네트워크를 생성하지 않으려면 이 기능을 활성화하십시오. 기본값은 | 부울 |
|
지원할 ML2 및 Open vSwitch VLAN 매핑 범위입니다. 기본값은 | string |
|
neutron 테넌트 네트워크의 메커니즘 드라이버입니다. 기본값은 | 문자열 / 쉼표로 구분된 목록 |
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를 배포하려면 오버클라우드 배포 명령의 모든 관련 네트워킹 환경 파일을 포함합니다.
절차
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.yaml
및roles_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 등) 대신 번호가 지정된 인터페이스(nic
예를 들어 한 호스트에는 1
,nic2
등)를 사용할 때 정확하게 동일할 필요는 없습니다.em1 및 em
2
인터페이스가 있을 수 있지만 다른 한 개에는 eno1
및 eno2
가 있지만 두 호스트의 NIC를 nic1 및 nic
2
로 참조할 수 있습니다.
번호가 매겨진 인터페이스 순서는 명명된 네트워크 인터페이스 유형의 순서에 해당합니다.
-
eth
인터페이스. 일반적으로 온보드 인터페이스입니다.0, eth
1 등과 같은 eth
X -
enoX
인터페이스(예:eno0
,eno1) 등
. 일반적으로 온보드 인터페이스입니다. -
enX
인터페이스, enp3s0, enp3s
1,
, 등과 같은 영숫자로 정렬됩니다. 일반적으로 애드온 인터페이스입니다.ens3
번호가 매겨진 NIC 체계에는 인터페이스에 스위치에 연결된 케이블이 연결된 경우 라이브 인터페이스만 포함됩니다. 4개의 인터페이스와 6개의 인터페이스가 있는 일부 호스트가 있는 경우 nic1을 nic
4
에 사용하고 각 호스트에 4개의 케이블만 연결합니다.
물리적 인터페이스를 특정 별칭으로 하드 코딩하면 어떤 물리적 NIC가 nic1 또는 nic
2
등으로 매핑되는지 미리 확인할 수 있습니다. MAC 주소를 지정된 별칭에 매핑할 수도 있습니다.
일반적으로 os-net-config
는 UP
상태로 이미 연결된 인터페이스만 등록합니다. 그러나 사용자 지정 매핑 파일을 사용하는 인터페이스를 하드 코딩하는 경우 인터페이스가 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}
사전 요구 사항
- 언더클라우드를 성공적으로 설치했습니다. 자세한 내용은 Director 설치 및 사용 가이드의 director 설치를 참조하십시오.
-
openstack-tripleo-heat-templates
디렉터리에서 default.j2
네트워크 인터페이스 템플릿을 렌더링했습니다. 자세한 내용은 10.2절. “사용자 정의를 위한 기본 네트워크 인터페이스 템플릿 렌더링”의 내용을 참조하십시오.
절차
~/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: 192.0.2.1/24 routes: - ip_netmask: 10.1.3.0/24 next_hop: 192.0.2.5 route_options: "metric 10" 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"
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
배포와 관련된 기타 환경 파일과 함께 배포 명령에 사용자 정의 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: get_param: [MaxViableMtu, value] ovs_options: get_param: BondInterfaceOvsOptions members: - type: interface name: nic2 mtu: 9000 primary: true - type: interface name: nic3 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: list_concat_unique - get_param: ExternalInterfaceRoutes - - default: true 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 이상.
절차
커널 버전을 확인합니다.
ovs-appctl -t ovs-vswitchd dpif/show-dp-features br-int
-
출력에
pkt 길이 작업 확인: no
또는 출력에Check pkt length action
문자열이 없거나 RHEL 8.2.0.4 이상으로 업그레이드하거나 점보 프레임이 더 작은 외부 네트워크로 전송하지 마십시오. 출력에
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: list_concat_unique: - get_param: ExternalInterfaceRoutes - - default: true 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 언더클라우드 설치
절차
-
언더클라우드 호스트에
stack
사용자로 로그인합니다. 언더클라우드 인증 정보 파일을 소싱합니다.
$ source ~/stackrc
사용자 지정 YAML 환경 파일을 생성합니다.
예제
$ vi /home/stack/templates/my-environment.yaml
환경 파일에는 키워드
parameter_defaults
및ExtraSysctl
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
.
배포 명령을 실행하고 핵심 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-DPDK 본딩 |
|
|
|
Linux 커널 본딩 |
|
|
|
동일한 노드에서 ovs_bridge
및 ovs_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.4. OVS(Open vSwitch) 본딩 모드에서 LACP(링크 집계 제어 프로토콜) 사용
LACP(링크 집계 제어 프로토콜) 옵션과 본딩을 사용할 수 있습니다. LACP는 부하 분산 및 내결함성을 위한 동적 본딩을 생성하는 협상 프로토콜입니다.
다음 표를 사용하여 LACP 옵션과 함께 OVS 커널 및 OVS-DPDK 본딩 인터페이스에 대한 지원 호환성을 파악합니다.
OVS/OVS-DPDK balance-tcp
모드는 기술 프리뷰로만 사용할 수 있습니다.
OVS 본딩은 업데이트, 핫픽스 및 기타 이벤트로 인해 OVS 또는 neutron 에이전트가 다시 시작될 때 발생할 수 있는 컨트롤 플레인 중단 가능성을 제공하기 때문에 제어 및 스토리지 네트워크에서는 VLAN 및 LACP와 Linux 본딩을 사용할 것을 권장합니다. Linux 본딩/LACP/VLAN 구성은 OVS 중단 가능성 없이 NIC 관리를 제공합니다.
표 12.2. OVS 커널 및 OVS-DPDK 본딩 모드에 대한 LACP 옵션
목표 | OVS 본딩 모드 | 호환되는 LACP 옵션 | 참고 |
고가용성(active-passive) |
|
| |
처리량 증가 (활성-활성) |
|
|
|
|
|
|
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)
를 할당할 수 있습니다.
절차
컴퓨팅 스케줄러가 배포 시 일치하는 노드별 기능으로 ID를 할당합니다.
openstack baremetal node set --property capabilities='node:controller-0,boot_option:local' <id>
이 명령은 기능
node:controller-0
을 노드에 할당합니다. 모든 노드에 대해 0부터 시작하여 고유한 연속 인덱스를 사용하여 이 패턴을 반복합니다. 지정된 역할(Controller, Compute 또는 각 스토리지 역할)의 모든 노드에 동일한 방식으로 태그가 지정되어 있는지 또는 Compute 스케줄러가 기능과 올바르게 일치할 수 없는지 확인합니다.스케줄러 힌트를 사용하여 각 노드의 기능과 일치시키는 Heat 환경 파일(예:
scheduler_hints_env.yaml
)을 생성합니다.parameter_defaults: ControllerSchedulerHints: 'capabilities:node': 'controller-%index%'
다음 매개변수를 사용하여 다른 역할 유형에 대한 스케줄러 힌트를 구성합니다.
-
컨트롤러 노드의 ControllerSchedulerHints
입니다. -
컴퓨팅 노드의
ComputeSchedulerHints
입니다. -
블록 스토리지 노드의
BlockStorageSchedulerHints
입니다. -
오브젝트 스토리지 노드의
ObjectStorageSchedulerHints
입니다. -
Ceph Storage 노드의 CephStorageSchedulerHints
. -
[ROLE] 사용자 정의 역할을 위한 스케줄 힌트입니다
.[ROLE]
을 역할 이름으로 바꿉니다.
-
-
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 주소를 사용하여 오버클라우드 노드를 할당할 수 있습니다.
절차
환경 파일을 생성하여 예측 가능한 IP 주소를 정의합니다.
$ touch ~/templates/predictive_ips.yaml
~/templates/predictive
섹션을 생성하고 다음 구문을 사용하여 각 네트워크의 각 노드에 대한 예측 가능한 IP 주소 지정을 정의합니다._ips.yaml 파일에서 parameter_
defaultsparameter_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 목록에서 제거해서는 안 됩니다.
-
배포 중에 이 구성을 적용하려면
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
IP 주소를 선택합니다.AllocationPools 범위에 없는 InternalApiVirtualFixedIP
s의
이 단계는 기본 내부 로드 밸런싱 구성을 사용하는 오버클라우드에만 사용됩니다. 외부 로드 밸런서를 사용하여 VIP를 할당하려면 오버클라우드 전용 외부 로드 밸런싱 가이드의 절차를 사용하십시오.
14장. 오버클라우드 공용 끝점에서 SSL/TLS 활성화
기본적으로 오버클라우드는 오버클라우드 서비스에 암호화되지 않은 엔드포인트를 사용합니다. 오버클라우드에서 SSL/TLS를 활성화하려면 CA(인증 기관) 솔루션을 사용하는 것이 좋습니다.
CA(인증 기관) 솔루션을 사용하는 경우 인증서 갱신, 인증서 해지 목록(CRL) 및 업계 허용 암호화와 같은 프로덕션 준비 솔루션이 있습니다. Red Hat IdM(Identity Manager)을 CA로 사용하는 방법에 대한 자세한 내용은 Ansible을 사용하여 TLS-e 구현을 참조하십시오.
다음 수동 프로세스를 사용하여 공용 API 엔드포인트에 대해 SSL/TLS만 활성화할 수 있으며 Internal 및 Admin API는 암호화되지 않은 상태로 유지됩니다. CA를 사용하지 않는 경우 SSL/TLS 인증서도 수동으로 업데이트해야 합니다. 자세한 내용은 SSL/TLS 인증서 수동 업데이트를 참조하십시오.
사전 요구 사항
- 공용 API의 엔드포인트를 정의하는 네트워크 격리입니다.
-
openssl-perl
패키지가 설치되어 있습니다. - SSL/TLS 인증서가 있습니다. 자세한 내용은 사용자 정의 SSL/TLS 인증서 구성을 참조하십시오.
14.1. 서명 호스트 초기화
서명 호스트는 새 인증서를 생성하고 인증 기관을 통해 서명하는 호스트입니다. 선택한 서명 호스트에서 SSL 인증서를 생성한 적이 없는 경우 새 인증서에 서명할 수 있도록 호스트를 초기화해야 할 수 있습니다.
절차
/etc/pki/CA/index.txt
파일에는 서명된 모든 인증서의 기록이 포함되어 있습니다. 파일 시스템 경로와index.txt
파일이 있는지 확인합니다.$ sudo mkdir -p /etc/pki/CA $ sudo touch /etc/pki/CA/index.txt
/etc/pki/CA/serial
파일은 서명할 다음 인증서에 사용할 다음 일련번호를 식별합니다. 이 파일이 있는지 확인합니다. 파일이 없는 경우 새 시작 값으로 새 파일을 생성합니다.$ echo '1000' | sudo tee /etc/pki/CA/serial
14.2. 인증 기관 생성
일반적으로는 외부 인증 기관을 통해 SSL/TLS 인증서에 서명합니다. 고유한 인증 기관을 사용하려는 경우도 있습니다. 예를 들어 내부 전용 인증 기관을 사용할 수도 있습니다.
절차
인증 기관 역할을 하는 키와 인증서 쌍을 생성합니다.
$ openssl genrsa -out ca.key.pem 4096 $ openssl req -key ca.key.pem -new -x509 -days 7300 -extensions v3_ca -out ca.crt.pem
-
openssl req
명령은 기관에 대한 특정 세부 정보를 요청합니다. 메시지가 나타나면 해당 세부 정보를 입력합니다. 이 명령을 수행하면ca.crt.pem
이라는 인증 기관 파일이 생성됩니다. 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 환경에 액세스해야 하는 각 클라이언트에 인증 기관 파일을 복사합니다.
절차
클라이언트 시스템에 인증 기관을 복사합니다.
$ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
각 클라이언트에 인증 기관 파일을 복사한 후 각 클라이언트에서 다음 명령을 실행하여 인증 기관 신뢰 번들에 인증서를 추가합니다.
$ sudo update-ca-trust extract
14.4. SSL/TLS 키 생성
OpenStack 환경에서 SSL/TLS를 활성화하려면 인증서를 생성하기 위한 SSL/TLS 키가 필요합니다.
절차
다음 명령을 실행하여 SSL/TLS 키(
server.key.pem
)를 생성합니다.$ openssl genrsa -out server.key.pem 2048
14.5. SSL/TLS 인증서 서명 요청 생성
인증서 서명 요청을 생성하려면 다음 단계를 완료합니다.
절차
기본 OpenSSL 설정 파일을 복사합니다.
$ cp /etc/pki/tls/openssl.cnf .
새
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
명령을 실행합니다.-
IP 주소를 사용하여 SSL/TLS를 통해 director에 액세스하는 경우
다음 명령을 실행하여 인증서 서명 요청(
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
- 인증 기관 개인 키입니다.
절차
다음 명령을 실행하여 언더클라우드 또는 오버클라우드에 대한 인증서를 생성합니다.
$ 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 인증서 및 개인 키에 대한 매개변수가 포함된 환경 파일을 생성해야 합니다.
절차
heat 템플릿 컬렉션에서
enable-tls.yaml
환경 파일을 복사합니다.$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml ~/templates/.
이 파일을 편집하여 해당 매개변수에 대해 다음과 같이 변경합니다.
- 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. 루트 인증서 삽입
인증서 서명자가 오버클라우드 이미지의 기본 신뢰 저장소에 없는 경우 인증 기관을 오버클라우드 이미지에 삽입해야 합니다.
절차
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을 사용합니다.
-
DNS 이름을 사용하여 공용 엔드포인트에 액세스하는 경우
절차
- 다음 배포 명령 스니펫을 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 인증서를 사용하는 경우 다음 단계를 완료합니다.
절차
다음 콘텐츠를 사용하여 heat 템플릿을 편집합니다.
-
enable-tls.yaml
파일을 편집하고SSLCertificate, SSL
Key
및SSLIntermediateCertificate
매개변수를 업데이트합니다. -
인증 기관이 변경된 경우
inject-trust-anchor-hiera.yaml
파일을 편집하고CAMap
매개변수를 업데이트합니다.
-
배포 명령을 다시 실행합니다.
$ 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
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. 매개변수 권장 사항
옵션 | 권장 사항 |
---|---|
| 제공하는 값을 기록해 둡니다. IdM을 사용하도록 Red Hat OpenStack Platform을 구성할 때 이 암호가 필요합니다. |
| 제공하는 값을 기록해 둡니다. 언더클라우드 및 오버클라우드 노드에는 이 IP 주소에 대한 네트워크 액세스가 필요합니다. |
| IdM 서버에 통합 DNS 서비스를 설치하려면 이 옵션을 사용합니다. 언더클라우드 및 오버클라우드 노드는 도메인 이름 확인을 위해 IdM 서버를 사용합니다. |
|
|
| IdM 서버 IP 주소에 대한 역방향 레코드 및 영역을 확인하려면 이 옵션을 사용합니다. 역방향 레코드 또는 영역을 확인할 수 없는 경우 IdM은 역방향 영역을 생성합니다. 이를 통해 IdM 배포가 간소화됩니다. |
| 이러한 옵션 중 하나 또는 둘 다를 사용하여 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
와 같은 명령을 실행해야 합니다. 이러한 절차는 멱등이며 업데이트된 템플릿 및 구성 파일과 일치하도록 기존 배포 구성만 조정합니다.
/etc/resolv.conf
파일을 구성합니다./etc/resolv.conf
의 언더클라우드에 적절한 검색 도메인과 이름 서버를 설정합니다. 예를 들어 배포 도메인이example.com
이고 FreeIPA 서버의 도메인이bigcorp.com
인 경우 /etc/resolv.conf에 다음 행을 추가합니다.search example.com bigcorp.com nameserver $IDM_SERVER_IP_ADDR
필요한 소프트웨어를 설치합니다.
sudo dnf install -y python3-ipalib python3-ipaclient krb5-devel
환경에 고유한 값을 사용하여 환경 변수를 내보냅니다.
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 사용자 자격 증명은 새 호스트 및 서비스를 추가할 수 있는 관리자여야 합니다.
언더클라우드에서
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
undercloud.conf에 다음 매개 변수를 추가합니다.
undercloud_nameservers = $IDM_SERVER_IP_ADDR overcloud_domain_name = example.com
언더클라우드를 배포합니다.
openstack undercloud install
검증
다음 단계를 완료하여 언더클라우드가 올바르게 등록되었는지 확인합니다.
IdM에 호스트를 나열합니다.
$ kinit admin $ ipa host-find
언더클라우드에
/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
오버클라우드를 배포하기 전에 다음과 유사한 내용을 사용하여 YAML 파일
tls-parameters.yaml
을 생성합니다. 선택한 값은 환경에 따라 다릅니다.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
-
DnsServers
매개 변수에는 IdM 서버의 IP 주소를 반영하는 값이 있어야 합니다. -
IdM 서버의 도메인이 클라우드 도메인과 다른 경우
DnsSearchDomains
매개변수에 포함합니다. 예를 들면 다음과 같습니다.DnsSearchDomains: ["example.com", "bigcorp.com"]
-
사전 프로비저닝된 노드가 있는 경우 오버클라우드 노드에 필요한 패키지를 설치하려면
IDMInstallClientPackages
매개변수 값을true
로 설정합니다. -
복제된 IdM 환경을 사용할 때
IdmServer
매개변수에 대해 여러 쉼표로 구분된 값을 설정할 수 있습니다. IdM 복제본에 대한 자세한 내용은 IdM 복제본 설치를 참조하십시오. -
OS::TripleO::Services::IpaClient
매개변수의 표시된 값은enable-internal-tls.yaml
파일의 기본 설정을 재정의합니다.tls-parameters.yaml
파일이openstack overcloud deploy
명령에서enable-internal-tls.yaml
을 따르는지 확인해야 합니다. -
cinder가 active-active로 구성된 DCN(분산 계산 노드) 아키텍처를 실행하는 경우
EnableEtcdInternalTLS
매개변수를true
로 추가하고 설정해야 합니다.
-
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 \ ...
끝점 목록에 대한 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 통합을 진행하기 전에 등록 프로세스를 수행해야 합니다. 등록 프로세스에는 다음 단계가 포함됩니다.
- CA(인증 기관)에 언더클라우드 노드 추가
- IdM에 언더클라우드 노드 추가
- 선택 사항: IdM 서버를 오버클라우드의 DNS 서버로 설정
- 환경 파일 준비 및 오버클라우드 배포
- IdM 및 RHOSP에서 오버클라우드 등록 테스트
- 선택 사항: IdM에 novajoin의 DNS 항목 추가
현재 novajoin에 IdM 등록은 언더클라우드 및 오버클라우드 노드에서만 사용할 수 있습니다. 오버클라우드 인스턴스에 대한 novajoin 통합은 이후 릴리스에서 지원될 예정입니다.
15.4. 인증 기관에 언더클라우드 노드 추가
오버클라우드를 배포하기 전에 언더클라우드 노드에 python3-novajoin
패키지를 설치하고 novajoin-ipa-setup
스크립트를 실행하여 인증 기관(CA)에 언더클라우드를 추가합니다.
절차
언더클라우드 노드에서
python3-novajoin
패키지를 설치합니다.$ sudo dnf install python3-novajoin
언더클라우드 노드에서
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]
섹션에 다음 설정을 구성합니다.
절차
novajoin
서비스를 활성화합니다.[DEFAULT] enable_novajoin = true
IdM을 사용하여 언더클라우드 노드를 등록할 수 있도록 1회성 암호(OTP)를 설정합니다.
ipa_otp = <otp>
neutron의 DHCP 서버에서 제공할 오버클라우드의 도메인 이름을 설정합니다.
overcloud_domain_name = <domain>
언더클라우드의 호스트 이름을 설정합니다.
undercloud_hostname = <undercloud FQDN>
IdM을 언더클라우드의 이름 서버로 설정합니다.
undercloud_nameservers = <IdM IP>
더 큰 환경의 경우 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>
선택 사항: 로컬 openSSL 인증 기관에서 director의 공용 끝점에 대한 SSL 인증서를 생성하도록 하려면
generate_service_certificate
매개변수를true
로 설정합니다.generate_service_certificate = true
-
undercloud.conf
파일을 저장합니다. 언더클라우드 배포 명령을 실행하여 기존 언더클라우드에 변경 사항을 적용합니다.
$ openstack undercloud install
검증
다음 단계를 완료하여 언더클라우드가 올바르게 등록되었는지 확인합니다.
IdM에 호스트를 나열합니다.
$ kinit admin $ ipa host-find
언더클라우드에
/etc/novajoin/krb5.keytab
이 있는지 확인합니다.ls /etc/novajoin/krb5.keytab
15.6. Red Hat IdM(Identity Manager)을 오버클라우드의 DNS 서버로 설정
IdM 환경을 자동으로 감지하고 쉽게 등록하려면 IdM을 DNS 서버로 설정합니다. 이 절차는 선택 사항이지만 권장됩니다.
절차
언더클라우드에 연결합니다.
$ source ~/stackrc
IdM을 DNS 이름 서버로 사용하도록 컨트롤 플레인 서브넷을 구성합니다.
$ openstack subnet set ctlplane-subnet --dns-nameserver <idm_server_address>
IdM 서버를 사용하도록 환경 파일에서
DnsServers
매개변수를 설정합니다.parameter_defaults: DnsServers: ["<idm_server_address>"]
일반적으로 이 매개변수는 사용자 지정
network-environment.yaml
파일에 정의됩니다.
15.7. 환경 파일 준비 및 novajoin 등록으로 오버클라우드 배포
IdM 통합으로 오버클라우드를 배포하려면 환경 파일을 생성하고 편집하여 오버클라우드에 정의된 도메인에 따라 사용자 정의 도메인 매개변수 CloudDomain
및 CloudName
을 사용하도록 오버클라우드를 구성하고 편집합니다. 그런 다음 배포에 필요한 모든 환경 파일과 함께 오버클라우드를 배포합니다.
절차
/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
/home/stack/templates/custom-domain.yaml
환경 파일을 편집하고 배포에 맞게CloudDomain
및CloudName*
값을 설정합니다.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
사용자 환경에 적합한 TLS 구현을 선택합니다.
enable-tls.yaml
환경 파일을 사용하여 사용자 정의 인증서로 외부 끝점을 보호합니다.-
/usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml
을/home/stack/templates
에 복사합니다. -
사용자 정의 인증서 및 키를 포함하도록
/home/stack/enable-tls.yaml
환경 파일을 수정합니다. 배포에 다음 환경 파일을 포함하여 내부 및 외부 엔드포인트를 보호합니다.
- 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 항목을 생성해야 합니다.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
heat 템플릿에 각 오버클라우드 네트워크의 가상 IP 주소 목록을 생성합니다(예:
/home/stack/public_vip.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'}]
필요에 따라 각 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
배포에 다음 환경 파일을 포함하여 내부 및 외부 엔드포인트를 보호합니다.
- enable-internal-tls.yaml
- tls-everywhere-endpoints-dns.yaml
- haproxy-public-tls-certmonger.yaml
- custom-domain.yaml
public_vip.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
로 설정해야 합니다.
절차
-
새 파일(예:
glance-settings.yaml
)을 만듭니다. 예제의 구문을 사용하여 이 파일을 채웁니다. 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의 유효성을 검사합니다.
스키마가 선택됩니다.
- 누락된 스키마: 거부
- 허용 목록이 있고 allowlist: reject에 체계가 없는 경우. 그렇지 않으면 C를 건너뛰고 2로 계속합니다.
- blocklist가 있고 체계가 blocklist: reject에 있는 경우.
호스트 이름이 선택됩니다.
- 누락된 호스트 이름: reject
- 허용 목록이 있고 allowlist: reject에 호스트 이름이 없는 경우. 그렇지 않으면 C를 건너뛰고 3으로 계속합니다.
- blocklist가 있고 blocklist: reject에 호스트 이름이 있는 경우.
URI에 포트가 있는 경우 포트가 확인됩니다.
- 허용 목록이 있고 allowlist: reject에 포트가 없는 경우. 그렇지 않으면 B를 건너뛰고 4까지 계속합니다.
- blocklist가 있고, 포트가 blocklist: reject에 있는 경우.
- 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에 액세스할 수 있습니다. 사용자가 지정할 수 있는 유일한 포트는 80
및 443
입니다. 사용자는 포트를 지정할 필요는 없지만, 포트가 있는 경우 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 스토리지를 사용하도록 오버클라우드를 구성할 수 있습니다.
절차
-
NFS 스토리지를 구성하는 환경 파일을 생성합니다(예:
nfs_storage.yaml
). 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 마운트 옵션이 활성화된 기본값으로
CinderNfsMountOptions
및GlanceNfsOptions
매개변수를 구성하지 마십시오.environments/storage/glance-nfs.yaml
파일에서GlanceNfsOptions
매개변수 값을 확인할 수 있습니다. 동일한 NFS 서버를 공유하도록 여러 서비스를 구성할 때 문제가 발생하는 경우 Red Hat 지원팀에 문의하십시오.다른 환경 파일과 함께 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
절차
stack
사용자로 언더클라우드에 로그인하고stackrc
자격 증명 파일을 가져옵니다.$ source ~/stackrc
새 또는 기존 스토리지 관련 환경 파일에서 외부 NFS 공유에 대한 정보를 추가합니다.
parameter_defaults: CinderImageConversionNfsShare: 192.168.10.1:/convert
참고NFS 마운트 옵션을 제어하는
CinderImageConversionNfsOptions
매개변수의 기본값은 대부분의 환경에 충분합니다.환경과 관련된 기타 환경 파일과 함께 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
명령을 사용하여 이 정보를 찾을 수 있습니다.
절차
다음 콘텐츠를 사용하여
swift-external-params.yaml
이라는 새 파일을 생성합니다.-
EXTERNAL.IP:PORT
를 외부 프록시의 IP 주소 및 포트로 바꿉니다. AUTHTOKEN
을SwiftPassword
행의 외부 프록시의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
-
-
이 파일을
swift-external-params.yaml
로 저장합니다. 다음 외부 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 구성을 참조하십시오.
절차
다음
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 인스턴스를 구성해야 합니다.
-
원격 RGW 인스턴스가 수신 대기하는 기본 포트는
다음 코드를 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
배포와 관련된 기타 환경 파일을 사용하여 추가 환경 파일을 사용하여 오버클라우드를 배포합니다.
openstack overcloud deploy --templates \ -e <your_environment_files> -e /usr/share/openstack-tripleo-heat-templates/environments/swift-external.yaml -e swift-external-params.yaml
검증
-
stack
사용자로 언더클라우드에 로그인합니다. overcloudrc
파일을 소싱합니다.$ source ~/stackrc
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 | +---------+-----------+-------+-------+---------+-----------+---------------+
테스트 컨테이너를 만듭니다.
$ openstack container create <testcontainer> +----------------+---------------+------------------------------------+ | account | container | x-trans-id | +----------------+---------------+------------------------------------+ | AUTH_2852da3cf2fc490081114c434d1fc157 | testcontainer | tx6f5253e710a2449b8ef7e-005f2d29e8 | +----------------+---------------+------------------------------------+
컨테이너에 데이터를 업로드할 수 있는지 확인하기 위해 구성 파일을 생성합니다.
$ openstack object create testcontainer undercloud.conf +-----------------+---------------+----------------------------------+ | object | container | etag | +-----------------+---------------+----------------------------------+ | undercloud.conf | testcontainer | 09fcffe126cac1dbac7b89b8fd7a3e4b | +-----------------+---------------+----------------------------------+
테스트 컨테이너를 삭제합니다.
$ openstack container delete -r <testcontainer>
17.5. 이미지 서비스의 cinder 백엔드 구성
GlanceBackend
매개 변수를 사용하여 이미지 서비스에서 이미지를 저장하는 데 사용하는 백엔드를 설정합니다.
프로젝트에 대해 생성할 수 있는 기본 최대 볼륨 수는 10입니다.
절차
cinder
를 이미지 서비스 백엔드로 구성하려면 환경 파일에 다음 행을 추가합니다.parameter_defaults: GlanceBackend: cinder
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****
사용자 정의 사용자 이름 또는
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 템플릿을 사용하여 이미지 서비스 캐싱을 구성합니다.
절차
환경 파일에서
glance-api.conf heat 템플릿에서
플레이버
값을keystone+cachemanagement
로 자동 설정하는GlanceCacheEnabled
매개변수 값을true
로 설정합니다.parameter_defaults: GlanceCacheEnabled: true
-
오버클라우드를 재배포할 때
openstack overcloud deploy
명령에 환경 파일을 포함합니다. 선택 사항: 오버클라우드를 재배포할 때 대체 빈도로
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 EMC PS 시리즈
블록 스토리지(cinder) 서비스를 위한 단일 Dell EMC PS 시리즈 백엔드 배포.
환경 파일은
/usr/share/openstack-tripleo-heat-templates/environments/cinder-dellps-config.yaml
에 있습니다.- NetApp Block Storage
NetApp 스토리지 어플라이언스를 블록 스토리지(cinder) 서비스의 백엔드로 배포합니다.
환경 파일은
/usr/share/openstack-tripleo-heat-templates/environments/storage/cinder-netapp-config.yaml
에 있습니다.
18장. 보안 개선 사항
다음 섹션에서는 오버클라우드의 보안을 강화하기 위한 몇 가지 제안 사항을 제공합니다.
18.1. 보안 root 사용자 액세스 사용
Overcloud 이미지에는 root
사용자의 강화된 보안이 자동으로 포함되어 있습니다. 예를 들어 배포된 각 Overcloud 노드는 root
사용자에 대한 직접 SSH 액세스를 자동으로 비활성화합니다. 오버클라우드 노드에서 root
사용자에 계속 액세스할 수 있습니다.
절차
-
stack
사용자로 Undercloud 노드에 로그인합니다. -
각 오버클라우드 노드에는
heat-admin
사용자 계정이 있습니다. 이 사용자 계정에는 언더클라우드에서 Overcloud 노드로의 암호 없이 SSH 액세스를 제공하는 언더클라우드 공용 SSH 키가 포함되어 있습니다. Undercloud 노드에서heat-admin
사용자로 SSH를 통해 Overcloud 노드에 로그인합니다. -
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 취약점을 방지할 수 있습니다.
tls-ciphers.yaml
이라는 heat 템플릿 환경 파일을 생성합니다.touch ~/templates/tls-ciphers.yaml
환경 파일의
ExtraConfig
후크를 사용하여tripleo::haproxy::ssl_cipher_suite
및tripleo::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'
참고암호화 방식 컬렉션은 연속된 한 행으로 되어 있습니다.
오버클라우드를 배포할 때 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) 플러그인을 활성화할 수 있습니다.
절차
환경 파일을
templates
하위 디렉터리에 복사합니다.$ cp /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-cfab.yaml /home/stack/templates/
절대 경로를 사용하도록
resource_registry
를 편집합니다.resource_registry: OS::TripleO::Services::NeutronML2FujitsuCfab: /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-plugin-ml2-fujitsu-cfab.yaml
/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
- 구성을 저장할지 여부를 결정합니다. (부울)
-
배포에 템플릿을 적용하려면
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 플러그인을 활성화할 수 있습니다.
절차
환경 파일을
templates
하위 디렉터리에 복사합니다.$ cp /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-fossw.yaml /home/stack/templates/
절대 경로를 사용하도록
resource_registry
를 편집합니다.resource_registry: OS::TripleO::Services::NeutronML2FujitsuFossw: /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-plugin-ml2-fujitsu-fossw.yaml
/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 서버의 포트 번호입니다(숫자)
-
배포에 템플릿을 적용하려면
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
수정
-
언더클라우드 호스트에
stack
사용자로 로그인합니다. stackrc
인증 정보 파일을 소싱합니다.$ source stackrc
다음 내용으로 환경 파일
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"
-
배포 명령에
-e
옵션을 사용하여overcloud-console-tty0.yaml
파일을 포함합니다.
overcloud-full.qcow2
이미지 수정
-
언더클라우드 호스트에
stack
사용자로 로그인합니다. stackrc
인증 정보 파일을 소싱합니다.$ source stackrc
overcloud-full.qcow2
이미지의 커널 인수를 수정하여 하드웨어에 대한 올바른 콘솔을 설정합니다. 예를 들어 콘솔을tty0
으로 설정합니다.$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'grubby --update-kernel=ALL --args="console=tty0"'
이미지를 director로 가져옵니다.
$ openstack overcloud image upload --image-path /home/stack/images/overcloud-full.qcow2
- Overcloud를 배포합니다.
검증
언더클라우드에서 오버클라우드 노드에 로그인합니다.
$ ssh heat-admin@<IP-address>
<IP-address>
를 오버클라우드 노드의 IP 주소로 바꿉니다./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 서비스를 격리하는 작업이 포함됩니다.