고급 오버클라우드 사용자 정의
Red Hat OpenStack Platform director를 사용하여 고급 기능을 구성하는 방법
초록
1장. 소개 링크 복사링크가 클립보드에 복사되었습니다!
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 서비스 옵션.
이 가이드에서는 director를 통해 오버클라우드를 보강하는 방법을 설명합니다. 이때 director는 노드를 등록하고 Overcloud 생성에 필요한 서비스를 구성했습니다. 이제 이 가이드의 방법을 사용하여 오버클라우드를 사용자 지정할 수 있습니다.
이 가이드의 예제는 Overcloud 구성을 위한 선택적 단계입니다. 이러한 단계는 Overcloud에 추가 기능을 제공하는 데만 필요합니다. 사용자 환경의 요구 사항에 적용되는 단계만 사용합니다.
2장. Heat 템플릿 이해 링크 복사링크가 클립보드에 복사되었습니다!
이 가이드의 사용자 지정 구성은 Heat 템플릿 및 환경 파일을 사용하여 Overcloud의 특정 측면을 정의합니다. 이 장에서는 Heat 템플릿에 대한 기본적인 소개를 통해 Red Hat OpenStack Platform director의 맥락에서 이러한 템플릿의 구조와 형식을 이해할 수 있습니다.
2.1. Heat 템플릿 링크 복사링크가 클립보드에 복사되었습니다!
RHOSP(Red Hat OpenStack Platform) director는 HOT(Heat Orchestration Templates)를 오버클라우드 배포 계획의 템플릿 형식으로 사용합니다. HOT 형식의 템플릿은 일반적으로 YAML 형식으로 표시됩니다. 템플릿의 목적은 heat에서 생성하는 리소스 컬렉션과 리소스의 구성인 스택을 정의하고 생성하는 것입니다. 리소스는 RHOSP의 개체이며 컴퓨팅 리소스, 네트워크 구성, 보안 그룹, 확장 규칙 및 사용자 지정 리소스를 포함할 수 있습니다.
RHOSP에서 heat 템플릿 파일을 사용자 지정 템플릿 리소스로 사용하려면 파일 확장자가 .yaml 또는. template 이어야 합니다.
Heat 템플릿에는 세 가지 주요 섹션이 있습니다.
- 매개 변수
-
이러한 설정은 heat로 전달되어 스택을 사용자 지정합니다. heat 매개변수를 사용하여 기본값을 사용자 지정할 수도 있습니다. 이러한 설정은 템플릿의
parameters섹션에 정의되어 있습니다. - Resources
-
이는 스택의 일부로 만들고 구성할 특정 오브젝트입니다. RHOSP(Red Hat OpenStack Platform)에는 모든 구성 요소에 걸쳐 있는 핵심 리소스 세트가 포함되어 있습니다. 이러한 값은 템플릿의
resources섹션에 정의되어 있습니다. - 출력 결과
-
이는 스택을 만든 후 heat에서 전달되는 값입니다. heat API 또는 클라이언트 도구를 통해 이러한 값에 액세스할 수 있습니다. 이러한 값은 템플릿의
output섹션에 정의되어 있습니다.
다음은 기본 Heat 템플릿의 예입니다.
이 템플릿은 리소스 유형 유형을 사용합니다. OS::Nova::Server 특정 플레이버, 이미지 및 키를 사용하여 my_instance 라는 인스턴스를 만듭니다. 스택은 My Cirros Instance 라는 instance_name 값을 반환할 수 있습니다.
Heat에서 템플릿을 처리하면 템플릿의 스택과 리소스 템플릿의 하위 스택 세트를 생성합니다. 이렇게 하면 템플릿으로 정의한 기본 스택에서 내림되는 스택의 계층 구조가 생성됩니다. 다음 명령을 사용하여 스택 계층 구조를 볼 수 있습니다.
openstack stack list --nested
$ openstack stack list --nested
2.2. 환경 파일 링크 복사링크가 클립보드에 복사되었습니다!
환경 파일은 heat 템플릿에 대한 사용자 지정을 제공하는 특수 유형의 템플릿입니다. 여기에는 다음 세 가지 주요 부분이 포함됩니다.
- 리소스 레지스트리
-
이 섹션에서는 다른 heat 템플릿에 연결된 사용자 지정 리소스 이름을 정의합니다. 이를 통해 핵심 리소스 컬렉션 내에 존재하지 않는 사용자 지정 리소스를 생성할 수 있습니다. 이러한 값은 환경 파일의
resource_registry섹션에 정의되어 있습니다. - 매개 변수
-
이는 최상위 템플릿의 매개 변수에 적용하는 일반적인 설정입니다. 예를 들어 리소스 레지스트리 매핑과 같이 중첩 스택을 배포하는 템플릿이 있는 경우 매개 변수는 중첩된 리소스에 대한 템플릿은 아닌 최상위 템플릿에만 적용됩니다. 매개 변수는 환경 파일의
parameters섹션에 정의됩니다. - 매개변수 기본값
-
이러한 매개 변수는 모든 템플릿에서 매개 변수의 기본값을 수정합니다. 예를 들어 리소스 레지스트리 매핑과 같이 중첩된 스택을 배포하는 heat 템플릿이 있는 경우 매개변수 기본값은 모든 템플릿에 적용됩니다. 매개 변수 기본값은 환경 파일의
parameter_defaults섹션에 정의됩니다.
오버클라우드에 대한 사용자 지정 환경 파일을 생성할 때 매개변수 대신 parameter_defaults 를 사용합니다. 따라서 매개 변수가 Overcloud의 모든 스택 템플릿에 적용됩니다.
기본 환경 파일의 예:
heat 템플릿my_ 이 포함될 수 있습니다. template.yaml에서 스택을 생성할 때 환경 파일 my_env.yamlmy_env.yaml 파일은 OS::Nova::Server::MyServer 라는 새 리소스 유형을 생성합니다. myserver.yaml 파일은 내장된 모든 리소스 유형을 재정의하는 이 리소스 유형의 구현을 제공하는 heat 템플릿 파일입니다. my_template.yaml 파일에 OS::Nova::Server::MyServer 리소스를 포함할 수 있습니다.
MyIP 는 이 환경 파일로 배포하는 기본 heat 템플릿에만 매개 변수를 적용합니다. 이 예제에서는 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- 이 파일은 Overcloud 환경을 생성하는 기본 템플릿 파일입니다. 이 파일은 Jinja2 구문을 사용하여 템플릿의 특정 섹션을 반복하여 사용자 지정 역할을 생성합니다. Jinja2 형식은 Overcloud 배포 프로세스 중에 YAML로 렌더링됩니다.
overcloud-resource-registry-puppet.j2.yaml- 이 파일은 Overcloud 환경을 생성하는 기본 환경 파일입니다. Overcloud 이미지에 저장된 Puppet 모듈에 대한 구성 세트를 제공합니다. director가 각 노드에 오버클라우드 이미지를 쓰고 나면 heat는 이 환경 파일에 등록된 리소스를 사용하여 각 노드의 Puppet 구성을 시작합니다. 이 파일은 Jinja2 구문을 사용하여 템플릿의 특정 섹션을 반복하여 사용자 지정 역할을 생성합니다. Jinja2 형식은 Overcloud 배포 프로세스 중에 YAML로 렌더링됩니다.
roles_data.yaml- 이 파일은 Overcloud에서 역할을 정의하고 서비스를 각 역할에 매핑하는 파일입니다.
network_data.yaml-
이 파일은 오버클라우드의 네트워크와 서브넷, 할당 풀, VIP 상태 등의 속성을 정의하는 파일입니다. 기본
network_data파일에는 기본 네트워크가 포함되어 있습니다. 외부, 내부 API, 스토리지, 스토리지 관리, 테넌트 및 관리. 사용자 지정network_data파일을 생성하고-n옵션을 사용하여openstack overcloud deploy명령에 추가할 수 있습니다. plan-environment.yaml- 이 파일은 오버클라우드 계획의 메타데이터를 정의하는 파일입니다. 여기에는 계획 이름, 사용할 기본 템플릿, Overcloud에 적용할 환경 파일이 포함됩니다.
capabilities-map.yaml-
이는 오버클라우드 계획에 대한 환경 파일 매핑입니다. 이 파일을 사용하여 Director web UI에서 환경 파일을 설명하고 활성화합니다. Overcloud 계획의
환경디렉터리에서 감지되지만capabilities-map.yaml에 정의되지 않은 사용자 지정 환경 파일은 2의 기타 하위 탭에 나열되어 있습니다. 2 배포 구성 > 웹 UI의 전체 설정 지정. 환경-
오버클라우드 생성에 사용할 수 있는 추가 heat 환경 파일이 포함되어 있습니다. 이러한 환경 파일을 사용하면 결과 RHOSP(Red Hat OpenStack Platform) 환경에 추가 기능을 사용할 수 있습니다. 예를 들어 디렉터리에는 Cinder NetApp 백엔드 스토리지(cinder
-netapp-config.yaml)를 활성화하기 위한 환경 파일이 포함되어 있습니다.capabilities-map.yaml 파일에 정의되지 않은 이 디렉터리에서 감지된 환경 파일은 2의 기타 하위 탭에 나열되어 있습니다.2 director의 웹 UI에서 배포 구성 > 전체 설정 지정. network- 격리된 네트워크 및 포트를 만드는 데 도움이 되는 heat 템플릿 세트입니다.
Puppet-
대부분 Puppet을 사용한 구성으로 구동되는 템플릿입니다.
overcloud-resource-registry-puppet.j2.yaml환경 파일은 이 디렉터리의 파일을 사용하여 각 노드에서 Puppet 구성의 애플리케이션을 구동합니다. puppet/services- 이 디렉터리는 구성 가능 서비스 아키텍처의 모든 서비스에 대한 heat 템플릿이 포함된 디렉터리입니다.
extraconfig- 추가 기능을 활성화하는 템플릿입니다.
firstboot-
director가 처음에 노드를 생성할 때 사용하는
first_boot스크립트 예제를 제공합니다.
2.4. 계획 환경 메타데이터 링크 복사링크가 클립보드에 복사되었습니다!
계획 환경 메타데이터 파일을 사용하면 오버클라우드 계획에 대한 메타데이터를 정의할 수 있습니다. 이 정보는 오버클라우드 플랜을 가져오고 내보낼 때 사용되며 플랜에서 오버클라우드 생성 중에 사용됩니다.
계획 환경 메타데이터 파일에는 다음과 같은 매개변수가 포함되어 있습니다.
- 버전
- 템플릿의 버전입니다.
- name
- 계획 파일을 저장하는 데 사용되는 OpenStack Object Storage(swift)의 Overcloud 계획 및 컨테이너 이름입니다.
- template
-
Overcloud 배포에 사용할 코어 상위 템플릿입니다. 이는
overcloud.yaml.j2 템플릿의 렌더링된 버전인 overcloud.yaml입니다. - 환경
-
사용할 환경 파일 목록을 정의합니다. path 하위 매개 변수를 사용하여 각 환경 파일의
경로를지정합니다. - parameter_defaults
-
오버클라우드에서 사용할 매개변수 세트입니다. 이 기능은 표준 환경 파일의
parameter_defaults섹션과 동일한 방식으로 작동합니다. - 암호
-
Overcloud 암호에 사용할 매개 변수 세트입니다. 이 기능은 표준 환경 파일의
parameter_defaults섹션과 동일한 방식으로 작동합니다. 일반적으로 director는 임의로 생성된 암호로 이 섹션을 자동으로 채웁니다. - workflow_parameters
- OpenStack Workflow(mistral) 네임스페이스에 매개 변수 집합을 제공할 수 있습니다. 이를 사용하여 특정 오버클라우드 매개변수를 계산하고 자동으로 생성할 수 있습니다.
다음은 계획 환경 파일의 구문 예입니다.
-p 옵션을 사용하여 openstack overcloud deploy 명령을 사용하여 계획 환경 메타데이터 파일을 포함할 수 있습니다. 예를 들면 다음과 같습니다.
(undercloud) $ openstack overcloud deploy --templates \ -p /my-plan-environment.yaml \ [OTHER OPTIONS]
(undercloud) $ openstack overcloud deploy --templates \
-p /my-plan-environment.yaml \
[OTHER OPTIONS]
다음 명령을 사용하여 기존 오버클라우드 계획의 계획 메타데이터를 볼 수도 있습니다.
(undercloud) $ openstack object save overcloud plan-environment.yaml --file -
(undercloud) $ openstack object save overcloud plan-environment.yaml --file -
2.5. 기능 맵 링크 복사링크가 클립보드에 복사되었습니다!
기능 맵은 계획 및 해당 종속 항목의 환경 파일 매핑을 제공합니다. 이 파일을 사용하여 director의 웹 UI를 통해 환경 파일을 설명하고 활성화합니다. Overcloud 계획에서 감지되지만 capabilities-map.yaml 에 나열되지 않은 사용자 지정 환경 파일은 2 배포 구성 > 웹 UI의 전체 설정 지정 2 의 기타 하위 탭에 나열되어 있습니다.
기본 파일은 /usr/share/openstack-tripleo-heat-templates/capabilities-map.yaml 에 있습니다.
다음은 기능 맵의 구문 예입니다.
- 1
topics매개 변수에는 UI 배포 구성에 섹션 목록이 포함되어 있습니다. 각 주제는 단일 환경 옵션 화면으로 표시되며, environment_groups 매개 변수로 정의된 여러 환경그룹이 포함되어 있습니다. 각 항목에는 일반 텍스트제목과설명이있을 수 있습니다.- 2
environment_groups매개 변수는 UI의 배포 구성에 있는 환경 파일 그룹을 나열합니다. 예를 들어 스토리지 주제에서 Ceph 관련 환경 파일을 위한 환경 그룹이 있을 수 있습니다. 각 환경 그룹에는 일반 텍스트제목과설명이있을 수 있습니다.- 3
environments매개 변수는 환경 그룹에 속하는 모든 환경 파일을 보여줍니다.file매개 변수는 환경 파일의 위치입니다. 각 환경 항목에는 일반 텍스트제목과설명이있을 수 있습니다.- 4 5
requires매개 변수는 환경 파일의 종속성 목록입니다. 이 예에서environment_file_1.yaml및environment_file_2.yaml모두dependent_environment_file.yaml도 활성화해야 합니다.
Red Hat OpenStack Platform은 이 파일을 사용하여 director UI에 기능에 대한 액세스를 추가합니다. 최신 버전의 Red Hat OpenStack Platform이 이 파일을 재정의할 수 있으므로 이 파일을 수정하지 않는 것이 좋습니다.
2.6. 오버클라우드 생성 시 환경 파일 포함 링크 복사링크가 클립보드에 복사되었습니다!
배포 명령(openstack overcloud deploy)은 -e 옵션을 사용하여 환경 파일을 포함하여 오버클라우드를 사용자 지정합니다. 환경 파일은 필요한 수만큼 추가할 수 있습니다. 차후에 실행되는 환경 파일에 정의된 매개변수와 리소스가 우선순위를 갖기 때문에 환경 파일의 순서가 중요합니다. 예를 들어 다음 두 개의 환경 파일이 있을 수 있습니다.
environment-file-1.yaml
environment-file-2.yaml
resource_registry: OS::TripleO::NodeExtraConfigPost: /home/stack/templates/template-2.yaml parameter_defaults: TimeZone: 'Hongkong'
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 --templates -e environment-file-1.yaml -e environment-file-2.yaml
이 예에서 두 환경 파일에는 공통 리소스 유형(OS::TripleO::NodeExtraConfigPost)과 공통 매개 변수(TimeZone)가 포함됩니다. openstack overcloud deploy 명령은 다음 프로세스를 통해 실행됩니다.
-
--template옵션에 따라 코어 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.7. 사용자 지정된 코어 Heat 템플릿 사용 링크 복사링크가 클립보드에 복사되었습니다!
오버클라우드를 생성할 때 director는 /usr/share/openstack-tripleo-heat-templates 에 있는 코어 Heat 템플릿 세트를 사용합니다. 이 핵심 템플릿 컬렉션을 사용자 지정하려면 Git 워크플로를 사용하여 변경 사항을 추적하고 업데이트를 병합합니다. 다음 git 프로세스를 사용하여 사용자 지정 템플릿 컬렉션을 관리합니다.
사용자 정의 템플릿 컬렉션 초기화
다음 절차에 따라 Heat 템플릿 컬렉션이 포함된 초기 Git 리포지토리를 생성합니다.
템플릿 컬렉션을
스택사용자 디렉터리에 복사합니다. 이 예제에서는 컬렉션을~/templates디렉터리에 복사합니다.cd ~/templates cp -r /usr/share/openstack-tripleo-heat-templates .
$ cd ~/templates $ cp -r /usr/share/openstack-tripleo-heat-templates .Copy to Clipboard Copied! Toggle word wrap Toggle overflow 사용자 지정 템플릿 디렉터리로 변경하고 Git 리포지토리를 초기화합니다.
cd openstack-tripleo-heat-templates git init .
$ cd openstack-tripleo-heat-templates $ git init .Copy to Clipboard Copied! Toggle word wrap Toggle overflow Git 사용자 이름 및 이메일 주소를 구성합니다.
git config --global user.name "<USER_NAME>" git config --global user.email "<EMAIL_ADDRESS>"
$ git config --global user.name "<USER_NAME>" $ git config --global user.email "<EMAIL_ADDRESS>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow <USER_NAME>을 사용하려는 사용자 이름으로 바꿉니다.<EMAIL_ADDRESS>를 이메일 주소로 바꿉니다.초기 커밋을 위한 모든 템플릿을 스테이징합니다.
git add *
$ git add *Copy to Clipboard Copied! Toggle word wrap Toggle overflow 초기 커밋을 생성합니다.
git commit -m "Initial creation of custom core heat templates"
$ git commit -m "Initial creation of custom core heat templates"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
이렇게 하면 최신 코어 템플릿 컬렉션을 포함하는 초기 master 분기가 생성됩니다. 이 분기를 사용자 지정 분기의 기반으로 사용하고 새 템플릿 버전을 이 분기에 병합합니다.
사용자 정의 분기 생성 및 변경 사항 커밋
사용자 지정 분기를 사용하여 코어 템플릿 컬렉션에 변경 사항을 저장합니다. 다음 절차에 따라 my-customizations 분기를 생성하고 사용자 지정을 추가합니다.
my-customizations분기를 생성하여 해당 분기로 전환합니다.git checkout -b my-customizations
$ git checkout -b my-customizationsCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 사용자 지정 분기의 파일을 편집합니다.
git에서 변경 사항을 스테이징합니다.
git add [edited files]
$ git add [edited files]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 사용자 정의 분기의 변경 사항을 커밋합니다.
git commit -m "[Commit message for custom changes]"
$ git commit -m "[Commit message for custom changes]"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
그러면 my-customizations 분기에 대한 커밋으로 변경 사항이 추가됩니다. master 분기가 업데이트되면 마스터에서 my-customizations 를 다시 평가 하여 git에서 이러한 커밋을 업데이트된 템플릿 컬렉션에 추가할 수 있습니다. 이렇게 하면 사용자 지정을 추적하고 향후 템플릿 업데이트에서 재생하는 데 도움이 됩니다.
사용자 정의 템플릿 컬렉션 업데이트:
언더클라우드를 업데이트할 때 openstack-tripleo-heat-templates 패키지도 업데이트할 수 있습니다. 이 경우 다음 절차를 사용하여 사용자 정의 템플릿 컬렉션을 업데이트합니다.
openstack-tripleo-heat-templates패키지 버전을 환경 변수로 저장합니다.export PACKAGE=$(rpm -qv openstack-tripleo-heat-templates)
$ export PACKAGE=$(rpm -qv openstack-tripleo-heat-templates)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 템플릿 컬렉션 디렉터리로 변경하고 업데이트된 템플릿의 새 분기를 생성합니다.
cd ~/templates/openstack-tripleo-heat-templates git checkout -b $PACKAGE
$ cd ~/templates/openstack-tripleo-heat-templates $ git checkout -b $PACKAGECopy to Clipboard Copied! Toggle word wrap Toggle overflow 분기의 모든 파일을 제거하고 새 버전으로 바꿉니다.
git rm -rf * cp -r /usr/share/openstack-tripleo-heat-templates/* .
$ git rm -rf * $ cp -r /usr/share/openstack-tripleo-heat-templates/* .Copy to Clipboard Copied! Toggle word wrap Toggle overflow 초기 커밋을 위한 모든 템플릿을 추가합니다.
git add *
$ git add *Copy to Clipboard Copied! Toggle word wrap Toggle overflow 패키지 업데이트에 대한 커밋을 생성합니다.
git commit -m "Updates for $PACKAGE"
$ git commit -m "Updates for $PACKAGE"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 분기를 master에 병합합니다. Git 관리 시스템(예: GitLab)을 사용하는 경우 관리 워크플로를 사용합니다. Git을 로컬로 사용하는 경우
master분기로 전환하여 병합하고git merge명령을 실행합니다.git checkout master git merge $PACKAGE
$ git checkout master $ git merge $PACKAGECopy to Clipboard Copied! Toggle word wrap Toggle overflow
이제 master 분기에 최신 버전의 코어 템플릿 컬렉션이 포함됩니다. 이제 이 업데이트된 컬렉션에서 my-customization 분기를 다시 평가할 수 있습니다.
사용자 정의 분기 변경
다음 절차를 사용하여 my-customization 분기를 업데이트합니다.
my-customizations분기로 변경합니다.git checkout my-customizations
$ git checkout my-customizationsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 마스터에서분기를 다시베이스합니다.git rebase master
$ git rebase masterCopy to Clipboard Copied! Toggle word wrap Toggle overflow
그러면 my-customizations 분기를 업데이트하고 이 분기에 대한 사용자 지정 커밋을 재생합니다.
git가 리베이스 중에 충돌을 보고하는 경우 다음 절차를 사용하십시오.
충돌이 포함된 파일을 확인합니다.
git status
$ git statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 식별된 템플릿 파일의 충돌을 해결합니다.
해결된 파일 추가
git add [resolved files]
$ git add [resolved files]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 업데이트를 계속합니다.
git rebase --continue
$ git rebase --continueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
사용자 정의 템플릿 배포
다음 절차를 사용하여 사용자 지정 템플릿 컬렉션을 배포합니다.
my-customization분기로 전환되었는지 확인합니다.git checkout my-customizations
git checkout my-customizationsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 로컬 템플릿 디렉터리를 지정하려면
--templates옵션과 함께openstack overcloud deploy명령을 실행합니다.openstack overcloud deploy --templates /home/stack/templates/openstack-tripleo-heat-templates [OTHER OPTIONS]
$ openstack overcloud deploy --templates /home/stack/templates/openstack-tripleo-heat-templates [OTHER OPTIONS]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
디렉터리 없이 --templates 옵션을 지정하는 경우 director는 기본 템플릿 디렉터리( )를 사용합니다.
/usr/share/openstack-tripleo-heat-templates
Red Hat은 heat 템플릿 컬렉션을 수정하는 대신 4장. 구성 후크 에서 방법을 사용하는 것이 좋습니다.
2.8. 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 파일에는 다음 스니펫이 포함되어 있습니다.
director가 Jinja2 구문을 렌더링하면 director가 roles_data.yaml 파일에 정의된 역할을 반복하고 {{role.name}}Count 매개 변수를 역할 이름으로 채웁니다. 기본 roles_data.yaml 파일에는 5개의 역할이 포함되어 있으며, 결과적으로 이 예제에서 다음 매개변수가 생성됩니다.
-
ControllerCount -
ComputeCount -
BlockStorageCount -
ObjectStorageCount -
CephStorageCount
렌더링된 매개변수의 예는 다음과 같습니다.
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)를 사용합니다. director는 network-isolation.j2.yaml 파일을 network -isolation.yaml 로 렌더링합니다. openstack overcloud deploy 명령을 실행하는 경우 -e 옵션을 사용하여 렌더링된 network-isolation.yaml 파일의 이름을 포함합니다.
openstack ovecloud deploy --templates \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml
...
$ openstack ovecloud 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)를 사용합니다. director는 사용자 지정 코어 템플릿 내에서 network-isolation.j2.yaml 파일을 network-isolation.yaml 에 렌더링합니다. openstack overcloud deploy 명령을 실행하는 경우 -e 옵션을 사용하여 렌더링된 network-isolation.yaml 파일의 이름을 포함합니다.
openstack ovecloud deploy --templates /home/stack/tripleo-heat-templates \
-e /home/stack/tripleo-heat-templates/environments/network-isolation.yaml
...
$ openstack ovecloud 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 로 렌더링 되지 않습니다. 이로 인해 배포가 실패합니다.
3장. 매개 변수 링크 복사링크가 클립보드에 복사되었습니다!
director의 템플릿 컬렉션에 있는 각 Heat 템플릿에는 parameters 섹션이 포함되어 있습니다. 이 섹션에서는 특정 Overcloud 서비스와 관련된 모든 매개 변수를 정의합니다. 여기에는 다음이 포함됩니다.
-
overcloud.j2.yaml- 기본 기본 매개변수 -
roles_data.yaml- 구성 가능 역할에 대한 기본 매개변수 -
Puppet/services/*.yaml- 특정 서비스에 대한 기본 매개변수
다음 방법을 사용하여 이러한 매개변수의 값을 수정할 수 있습니다.
- 사용자 지정 매개 변수에 대한 환경 파일을 만듭니다.
-
사용자 지정 매개 변수를 환경 파일의
parameter_defaults섹션에 포함합니다. -
openstack overcloud deploy명령을 사용하여 환경 파일을 포함합니다.
다음 몇 섹션에는 puppet/services 디렉터리의 서비스에 대한 특정 매개 변수를 구성하는 방법을 보여주는 예제가 포함되어 있습니다.
3.1. 예 1: 시간대 구성 링크 복사링크가 클립보드에 복사되었습니다!
시간대(puppet/services/time/timezone.yaml)를 설정하는 Heat 템플릿에는 TimeZone 매개변수가 포함되어 있습니다. TimeZone 매개변수를 비워 두면 오버클라우드에서 시간을 기본값으로 UTC 로 설정합니다.
시간대 목록을 가져오려면 timedatectl list-timezones 명령을 실행합니다. 다음 예제 명령은 아시아의 시간대를 검색합니다.
sudo timedatectl list-timezones|grep "Asia"
$ sudo timedatectl list-timezones|grep "Asia"
시간대를 식별한 후 환경 파일에서 TimeZone 매개변수를 설정합니다. 다음 예제 환경 파일은 TimeZone 값을 Asia/Tokyo 로 설정합니다.
parameter_defaults: TimeZone: 'Asia/Tokyo'
parameter_defaults:
TimeZone: 'Asia/Tokyo'
3.2. 예 2: 네트워킹 분산 가상 라우팅(DVR) 활성화 링크 복사링크가 클립보드에 복사되었습니다!
OpenStack Networking(neutron) API(puppet/services/neutron-api.yaml)에 대한 Heat 템플릿에는 DVR(Distributed Virtual Routing)을 활성화 및 비활성화하는 매개 변수가 포함되어 있습니다. 매개 변수의 기본값은 false 입니다. 그러나 환경 파일에서 다음을 사용하여 활성화할 수 있습니다.
parameter_defaults: NeutronEnableDVR: true
parameter_defaults:
NeutronEnableDVR: true
3.3. 예 3: RabbitMQ 파일 설명자 제한 구성 링크 복사링크가 클립보드에 복사되었습니다!
특정 구성의 경우 RabbitMQ 서버의 파일 설명자 제한을 늘려야 할 수 있습니다. puppet/services/rabbitmq.yaml Heat 템플릿을 사용하면 RabbitFDLimit 매개변수를 필요한 제한으로 설정할 수 있습니다. 환경 파일에 다음을 추가합니다.
parameter_defaults: RabbitFDLimit: 65536
parameter_defaults:
RabbitFDLimit: 65536
3.4. 예 4: 매개 변수 활성화 및 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
배포 중에 매개 변수를 초기에 설정한 다음 업데이트 또는 확장 작업과 같은 향후 배포 작업에 대한 매개 변수를 비활성화해야 하는 경우도 있습니다. 예를 들어 오버클라우드 생성 중에 사용자 지정 RPM을 포함하려면 다음을 포함합니다.
parameter_defaults: DeployArtifactURLs: ["http://www.example.com/myfile.rpm"]
parameter_defaults:
DeployArtifactURLs: ["http://www.example.com/myfile.rpm"]
이후 배포에서 이 매개변수를 비활성화해야 하는 경우 매개 변수를 제거하는 것만으로는 충분하지 않습니다. 대신 매개변수를 빈 값으로 설정합니다.
parameter_defaults: DeployArtifactURLs: []
parameter_defaults:
DeployArtifactURLs: []
이렇게 하면 후속 배포 작업에 더 이상 매개변수가 설정되지 않습니다.
3.5. 예 5: 역할 기반 매개변수 링크 복사링크가 클립보드에 복사되었습니다!
[ROLE]Parameters 매개 변수를 사용하여 [ROLE] 을 구성 가능 역할로 교체하여 특정 역할에 대한 매개 변수를 설정합니다.
예를 들어 director는 컨트롤러 및 컴퓨팅 노드 모두에 logrotate 를 구성합니다. 컨트롤러 및 컴퓨팅 노드에 대해 다른 DestinationRule 매개변수를 설정하려면 'ControllerParameters' 및 'ComputeParameters' 매개변수가 모두 포함된 환경 파일을 생성하고 각 특정 역할에 대해 DestinationRule 매개변수를 설정합니다.
3.6. 수정할 매개 변수 식별 링크 복사링크가 클립보드에 복사되었습니다!
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 변수의 director의 핵심 Heat 템플릿 컬렉션을 확인합니다. 일반적으로
puppet/services/*의 템플릿은 동일한 서비스의 Puppet 모듈에 해당합니다. 예를 들어puppet/services/keystone.yaml템플릿은keystone모듈에 hieradata를 제공합니다.- Heat 템플릿에서 Puppet 변수의 hieradata를 설정하는 경우 템플릿에서 수정할 director 기반 매개 변수도 공개해야 합니다.
- Heat 템플릿에서 Puppet 변수에 hieradata를 설정하지 않으면 구성 후크를 사용하여 환경 파일을 사용하여 hieradata를 전달합니다. hieradata 사용자 지정에 대한 자세한 내용은 4.5절. “Puppet: 역할에 맞는 Hieradata 사용자 정의” 을 참조하십시오.
동일한 사용자 지정 hieradata 해시의 여러 인스턴스를 정의하지 마십시오. 동일한 사용자 지정 hieradata의 여러 인스턴스로 인해 Puppet 실행 중에 충돌하여 구성 옵션에 대해 예기치 않은 값이 설정될 수 있습니다.
워크플로우 예
OpenStack ID(keystone)에 대한 알림 형식을 변경할 수 있습니다. 워크플로를 사용하면 다음을 수행할 수 있습니다.
-
구성할 OpenStack 매개 변수를 식별합니다(
notification_format). keystonePuppet 모듈을 검색하여notification_format설정을 검색합니다. 예를 들면 다음과 같습니다.grep notification_format /etc/puppet/modules/keystone/manifests/*
$ grep notification_format /etc/puppet/modules/keystone/manifests/*Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 경우 keystone 모듈은
keystone::notification_format변수를 사용하여 이 옵션을 관리합니다.이 변수에 대해
keystone서비스 템플릿을 검색합니다. 예를 들면 다음과 같습니다.grep "keystone::notification_format" /usr/share/openstack-tripleo-heat-templates/puppet/services/keystone.yaml
$ grep "keystone::notification_format" /usr/share/openstack-tripleo-heat-templates/puppet/services/keystone.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력에는
KeystoneNotificationFormat매개변수를 사용하여 director가keystone::notification_formathieradata를 설정하는 것을 보여줍니다.
다음 표는 최종 매핑을 보여줍니다.
| director 매개변수 | Puppet Hieradata | OpenStack Identity(keystone) 옵션 |
|---|---|---|
|
|
|
|
즉, Overcloud 환경 파일에서 KeystoneNotificationFormat 을 설정하면 Overcloud 구성 중에 keystone.conf 파일에 notification_format 옵션이 설정됩니다.
4장. 구성 후크 링크 복사링크가 클립보드에 복사되었습니다!
구성 후크는 Overcloud 배포 프로세스에 고유한 구성 기능을 삽입하는 방법을 제공합니다. 여기에는 기본 Overcloud 서비스 구성 전후에 사용자 정의 구성을 삽입하는 후크와 Puppet 기반 구성을 수정하고 포함하기 위한 후크가 포함됩니다.
4.1. 첫 번째 부팅: 첫 번째 부팅 구성 사용자 정의 링크 복사링크가 클립보드에 복사되었습니다!
director는 Overcloud를 처음 생성할 때 모든 노드에서 구성을 수행하는 메커니즘을 제공합니다. director는 OS::TripleO::NodeUserData 리소스 유형을 사용하여 호출할 수 있는 cloud-init 를 통해 이 작업을 수행합니다.
이 예제에서는 모든 노드의 사용자 지정 IP 주소로 이름 서버를 업데이트합니다. 먼저 스크립트를 실행하여 각 노드의 resolv )을 생성해야 합니다. .conf를 특정 이름 서버에 추가하는 기본 heat 템플릿(/home/stack/templates/nameserver.yamlOS::TripleO::MultipartMime 리소스 유형을 사용하여 구성 스크립트를 보낼 수 있습니다.
다음으로 heat 템플릿을 OS::TripleO::NodeUserData 리소스 유형으로 등록하는 환경 파일(/home/stack/templates/firstboot.yaml)을 만듭니다.
resource_registry: OS::TripleO::NodeUserData: /home/stack/templates/nameserver.yaml
resource_registry:
OS::TripleO::NodeUserData: /home/stack/templates/nameserver.yaml
첫 번째 부팅 구성을 추가하려면 Overcloud를 처음 생성할 때 다른 환경 파일과 함께 스택에 환경 파일을 추가합니다. 예를 들면 다음과 같습니다.
openstack overcloud deploy --templates \
...
-e /home/stack/templates/firstboot.yaml \
...
$ openstack overcloud deploy --templates \
...
-e /home/stack/templates/firstboot.yaml \
...
-e 는 오버클라우드 스택에 환경 파일을 적용합니다.
그러면 처음 생성될 때 모든 노드에 구성이 추가되고 처음으로 부팅됩니다. 이후 오버클라우드 스택 업데이트와 같은 이러한 템플릿은 이러한 스크립트를 실행하지 않습니다.
OS::TripleO::NodeUserData 를 하나의 heat 템플릿에만 등록할 수 있습니다. 후속 사용은 사용할 heat 템플릿을 재정의합니다.
4.2. 구성 전: 특정 오버클라우드 역할 사용자 정의 링크 복사링크가 클립보드에 복사되었습니다!
이 문서의 이전 버전에서는 OS::TripleO::Tasks::*PreConfig 리소스를 사용하여 역할별로 사전 구성 후크를 제공했습니다. director의 Heat 템플릿 컬렉션에는 이러한 후크를 전용으로 사용해야 하므로 사용자 지정 용도로 사용해서는 안 됩니다. 대신 아래에 설명된 OS::TripleO::*ExtraConfigPre 후크를 사용합니다.
Overcloud는 OpenStack 구성 요소의 핵심 구성에 Puppet을 사용합니다. director는 첫 번째 부팅이 완료된 후 코어 구성이 시작되기 전에 특정 노드 역할에 대한 사용자 정의 구성을 제공하는 후크 세트를 제공합니다. 이러한 후크에는 다음이 포함됩니다.
- 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 템플릿(/home/stack/templates/nameserver.yaml
이 예제에서 resources 섹션에는 다음이 포함됩니다.
- CustomExtraConfigPre
-
소프트웨어 구성을 정의합니다. 이 예제에서는 Bash
스크립트를정의하고 Heat에서_NAMESERVER_IP_를nameserver_ip매개 변수에 저장된 값으로 바꿉니다. - CustomExtraDeploymentPre
그러면
CustomExtraConfigPre리소스의 소프트웨어 구성인 소프트웨어 구성이 실행됩니다. 다음을 확인합니다.-
config매개변수는CustomExtraConfigPre리소스에 대한 참조를 만들어 Heat에서 적용할 구성을 알 수 있습니다. -
server매개 변수는 Overcloud 노드 맵을 검색합니다. 이 매개 변수는 상위 템플릿에서 제공하며 이 후크의 템플릿에서 필요합니다. -
actions매개 변수는 구성을 적용할 시기를 정의합니다. 이 경우 오버클라우드를 생성하거나 업데이트하는 경우에만 구성을 적용합니다. 가능한 작업에는CREATE,UPDATE,DELETE,SUSPEND,RESUME등이 있습니다. -
input_values에는 상위 템플릿에서DeployIdentifier를 저장하는deploy_identifier라는 매개 변수가 포함되어 있습니다. 이 매개 변수는 각 배포 업데이트의 리소스에 타임스탬프를 제공합니다. 이렇게 하면 리소스가 후속 오버클라우드 업데이트에 다시 적용됩니다.
-
다음으로 heat 템플릿을 역할 기반 리소스 유형에 등록하는 환경 파일(/home/stack/templates/pre_config.yaml)을 생성합니다. 예를 들어 컨트롤러 노드에만 적용하려면 ControllerExtraConfigPre 후크를 사용합니다.
resource_registry: OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/nameserver.yaml parameter_defaults: nameserver_ip: 192.168.1.1
resource_registry:
OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/nameserver.yaml
parameter_defaults:
nameserver_ip: 192.168.1.1
구성을 적용하려면 Overcloud를 생성하거나 업데이트할 때 다른 환경 파일과 함께 스택에 환경 파일을 추가합니다. 예를 들면 다음과 같습니다.
openstack overcloud deploy --templates \
...
-e /home/stack/templates/pre_config.yaml \
...
$ openstack overcloud deploy --templates \
...
-e /home/stack/templates/pre_config.yaml \
...
이는 초기 Overcloud 생성 또는 후속 업데이트에서 코어 구성이 시작되기 전에 모든 컨트롤러 노드에 구성을 적용합니다.
각 리소스를 후크당 하나의 Heat 템플릿에만 등록할 수 있습니다. 후속 사용량은 사용할 Heat 템플릿을 재정의합니다.
4.3. 구성 전: 모든 오버클라우드 역할 사용자 정의 링크 복사링크가 클립보드에 복사되었습니다!
Overcloud는 OpenStack 구성 요소의 핵심 구성에 Puppet을 사용합니다. director는 첫 번째 부팅이 완료된 후 코어 구성이 시작되기 전에 모든 노드 유형을 구성하는 후크를 제공합니다.
- OS::TripleO::NodeExtraConfig
- 핵심 Puppet 구성 전에 모든 노드 역할에 적용되는 추가 구성입니다.
이 예제에서는 먼저 스크립트를 실행하여 각 노드의 resolv )을 생성합니다.
.conf를 변수 이름 서버로 추가하는 기본 heat 템플릿(/home/stack/templates/nameserver.yaml
이 예제에서 resources 섹션에는 다음이 포함됩니다.
- CustomExtraConfigPre
-
소프트웨어 구성을 정의합니다. 이 예제에서는 Bash
스크립트를정의하고 Heat에서_NAMESERVER_IP_를nameserver_ip매개 변수에 저장된 값으로 바꿉니다. - CustomExtraDeploymentPre
그러면
CustomExtraConfigPre리소스의 소프트웨어 구성인 소프트웨어 구성이 실행됩니다. 다음을 확인합니다.-
config매개변수는CustomExtraConfigPre리소스에 대한 참조를 만들어 Heat에서 적용할 구성을 알 수 있습니다. -
server매개 변수는 Overcloud 노드 맵을 검색합니다. 이 매개 변수는 상위 템플릿에서 제공하며 이 후크의 템플릿에서 필요합니다. -
actions매개 변수는 구성을 적용할 시기를 정의합니다. 이 경우 오버클라우드를 생성하거나 업데이트하는 경우에만 구성을 적용합니다. 가능한 작업에는CREATE,UPDATE,DELETE,SUSPEND,RESUME등이 있습니다. -
input_values매개 변수에는 상위 템플릿에서DeployIdentifier를 저장하는deploy_identifier라는 하위 매개 변수가 포함되어 있습니다. 이 매개 변수는 각 배포 업데이트의 리소스에 타임스탬프를 제공합니다. 이렇게 하면 리소스가 후속 오버클라우드 업데이트에 다시 적용됩니다.
-
다음으로 heat 템플릿을 OS::TripleO::NodeExtraConfig 리소스 유형으로 등록하는 환경 파일(/home/stack/templates/pre_config.yaml)을 만듭니다.
resource_registry: OS::TripleO::NodeExtraConfig: /home/stack/templates/nameserver.yaml parameter_defaults: nameserver_ip: 192.168.1.1
resource_registry:
OS::TripleO::NodeExtraConfig: /home/stack/templates/nameserver.yaml
parameter_defaults:
nameserver_ip: 192.168.1.1
구성을 적용하려면 Overcloud를 생성하거나 업데이트할 때 다른 환경 파일과 함께 스택에 환경 파일을 추가합니다. 예를 들면 다음과 같습니다.
openstack overcloud deploy --templates \
...
-e /home/stack/templates/pre_config.yaml \
...
$ openstack overcloud deploy --templates \
...
-e /home/stack/templates/pre_config.yaml \
...
이는 초기 Overcloud 생성 또는 후속 업데이트에서 코어 구성이 시작되기 전에 모든 노드에 구성이 적용됩니다.
OS::TripleO::NodeExtraConfig 를 하나의 Heat 템플릿에만 등록할 수 있습니다. 후속 사용량은 사용할 Heat 템플릿을 재정의합니다.
4.4. 구성 후: 모든 오버클라우드 역할 사용자 정의 링크 복사링크가 클립보드에 복사되었습니다!
이 문서의 이전 버전에서는 OS::TripleO::Tasks::*PostConfig 리소스를 사용하여 역할별로 사후 구성 후크를 제공했습니다. director의 Heat 템플릿 컬렉션에는 이러한 후크를 전용으로 사용해야 하므로 사용자 지정 용도로 사용해서는 안 됩니다. 대신 아래에 설명된 OS::TripleO::NodeExtraConfigPost 후크를 사용합니다.
오버클라우드 생성을 완료했지만 초기 생성 또는 오버클라우드의 후속 업데이트 시 모든 역할에 구성을 추가하려는 경우 발생할 수 있습니다. 이 경우 다음 구성 후 후크를 사용합니다.
- OS::TripleO::NodeExtraConfigPost
- 핵심 Puppet 구성 후 모든 노드 역할에 적용되는 추가 구성입니다.
이 예제에서는 먼저 스크립트를 실행하여 각 노드의 resolv )을 생성합니다.
.conf를 변수 이름 서버로 추가하는 기본 heat 템플릿(/home/stack/templates/nameserver.yaml
이 예제에서 resources 섹션에는 다음이 포함됩니다.
- CustomExtraConfig
-
소프트웨어 구성을 정의합니다. 이 예제에서는 Bash
스크립트를정의하고 Heat에서_NAMESERVER_IP_를nameserver_ip매개 변수에 저장된 값으로 바꿉니다. - CustomExtraDeployments
그러면
CustomExtraConfig리소스의 소프트웨어 구성인 소프트웨어 구성이 실행됩니다. 다음을 확인합니다.-
config매개변수는CustomExtraConfig리소스에 대한 참조를 만들어 Heat에서 적용할 구성을 알 수 있습니다. -
servers매개 변수는 Overcloud 노드 맵을 검색합니다. 이 매개 변수는 상위 템플릿에서 제공하며 이 후크의 템플릿에서 필요합니다. -
actions매개 변수는 구성을 적용할 시기를 정의합니다. 이 경우 Overcloud가 생성될 때만 구성을 적용합니다. 가능한 작업에는CREATE,UPDATE,DELETE,SUSPEND,RESUME등이 있습니다. -
input_values에는 상위 템플릿에서DeployIdentifier를 저장하는deploy_identifier라는 매개 변수가 포함되어 있습니다. 이 매개 변수는 각 배포 업데이트의 리소스에 타임스탬프를 제공합니다. 이렇게 하면 리소스가 후속 오버클라우드 업데이트에 다시 적용됩니다.
-
다음으로 heat 템플릿을 OS::TripleO::NodeExtraConfigPost: 리소스 유형으로 등록하는 환경 파일(/home/stack/templates/post_config.yaml)을 생성합니다.
resource_registry: OS::TripleO::NodeExtraConfigPost: /home/stack/templates/nameserver.yaml parameter_defaults: nameserver_ip: 192.168.1.1
resource_registry:
OS::TripleO::NodeExtraConfigPost: /home/stack/templates/nameserver.yaml
parameter_defaults:
nameserver_ip: 192.168.1.1
구성을 적용하려면 Overcloud를 생성하거나 업데이트할 때 다른 환경 파일과 함께 스택에 환경 파일을 추가합니다. 예를 들면 다음과 같습니다.
openstack overcloud deploy --templates \
...
-e /home/stack/templates/post_config.yaml \
...
$ openstack overcloud deploy --templates \
...
-e /home/stack/templates/post_config.yaml \
...
이는 초기 Overcloud 생성 또는 후속 업데이트에서 코어 구성이 완료된 후 모든 노드에 구성이 적용됩니다.
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 키맵을 Japanese로 설정하려면 다음을 실행합니다.
parameter_defaults:
ComputeExtraConfig:
nova::compute::reserved_host_memory: 1024
nova::compute::vnc_keymap: ja
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
$ openstack baremetal introspection data save 9dcc87ae-4c6d-4ede-81a5-9b20d7dc4a14 | jq .extra.system.product.uuid
이렇게 하면 시스템 UUID가 출력됩니다. 예를 들면 다음과 같습니다.
"F5055C6C-477F-47FB-AFE5-95C6928C407F"
"F5055C6C-477F-47FB-AFE5-95C6928C407F"
노드별 hieradata를 정의하고 per_node.yaml 템플릿을 사전 구성 후크에 등록하는 환경 파일에서 이 시스템 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" ]}}'
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에 해당하는 노드에 heiradata 파일 세트를 생성하고 사용자가 정의한 hieradata를 포함합니다. UUID가 정의되지 않은 경우 결과 hieradata 파일이 비어 있습니다. 이전 예에서 per_node.yaml 템플릿은 OS::TripleO::ComputeExtraConfigPre 후크에 따라 모든 컴퓨팅 노드에서 실행되지만 시스템 UUID F5055C6C-477F-47FB-AFE5-95C6928C407F 가 있는 컴퓨팅 노드만 hieradata를 수신합니다.
이렇게 하면 각 노드를 특정 요구 사항에 맞게 조정할 수 있습니다.
NodeDataLookup에 대한 자세한 내용은 Deploy ing an Overcloud with Containerized Red Hat Ceph 가이드의 Ceph Storage Cluster Setting 구성을 참조하십시오.
4.7. Puppet: 사용자 정의 매니페스트 적용 링크 복사링크가 클립보드에 복사되었습니다!
특정 상황에서는 오버클라우드 노드에 추가 구성 요소를 설치하고 구성해야 할 수 있습니다. 기본 구성이 완료된 후 의 노드에 적용되는 사용자 지정 Puppet 매니페스트를 사용하여 이 작업을 수행할 수 있습니다. 기본 예제에서는 motd 를 각 노드에 설치할 수 있습니다. 이 작업을 수행하는 프로세스는 먼저 Puppet 구성을 시작하는 Heat 템플릿(/home/stack/templates/custom_puppet_config.yaml)을 생성하는 것입니다.
여기에는 템플릿 내에 /home/stack/templates/motd.pp 이 포함되어 구성을 위해 노드에 전달합니다. motd.pp 파일 자체에는 motd를 설치하고 구성하는 Puppet 클래스가 포함되어 있습니다 .
다음으로 heat 템플릿을 OS::TripleO::NodeExtraConfigPost: 리소스 유형으로 등록하는 환경 파일(/home/stack/templates/puppet_post_config.yaml)을 생성합니다.
resource_registry: OS::TripleO::NodeExtraConfigPost: /home/stack/templates/custom_puppet_config.yaml
resource_registry:
OS::TripleO::NodeExtraConfigPost: /home/stack/templates/custom_puppet_config.yaml
마지막으로 오버클라우드 스택을 생성하거나 업데이트할 때 다른 환경 파일과 함께 이 환경 파일을 추가합니다.
openstack overcloud deploy --templates \
...
-e /home/stack/templates/puppet_post_config.yaml \
...
$ openstack overcloud deploy --templates \
...
-e /home/stack/templates/puppet_post_config.yaml \
...
그러면 motd.pp 의 구성이 Overcloud의 모든 노드에 적용됩니다.
동일한 사용자 지정 hieradata 해시의 여러 인스턴스를 정의하지 마십시오. 동일한 사용자 지정 hieradata의 여러 인스턴스로 인해 Puppet 실행 중에 충돌하여 구성 옵션에 대해 예기치 않은 값이 설정될 수 있습니다.
5장. 오버클라우드 등록 링크 복사링크가 클립보드에 복사되었습니다!
오버클라우드는 Red Hat Content Delivery Network, Red Hat Satellite Server 5 또는 Red Hat Satellite Server 6에 노드를 등록할 수 있는 방법을 제공합니다.
5.1. 환경 파일로 오버클라우드 등록 링크 복사링크가 클립보드에 복사되었습니다!
Heat 템플릿 컬렉션에서 등록 파일을 복사합니다.
cp -r /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration ~/templates/.
$ cp -r /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration ~/templates/.
~/templates/rhel-registration/environment-rhel-registration.yaml 파일을 편집하고 등록 메서드 및 세부 정보에 적용되는 매개변수 값을 변경합니다.
일반 매개변수
- rhel_reg_method
-
등록 방법을 선택합니다.
portal,satellite또는disable중 하나입니다. - rhel_reg_type
-
등록할 유닛 유형입니다.
시스템으로등록하려면 비워 두십시오 - rhel_reg_auto_attach
-
이 시스템에 호환 가능한 서브스크립션을 자동으로 첨부합니다. 활성화하려면
true로 설정합니다. 이 기능을 비활성화하려면 이 매개 변수를 비워 둡니다. - rhel_reg_service_level
- 자동 첨부에 사용할 서비스 수준입니다.
- rhel_reg_release
- 자동 첨부를 위한 릴리스 버전을 설정하려면 이 매개변수를 사용합니다. Red Hat 서브스크립션 관리자의 기본값을 사용하려면 비워 두십시오.
- rhel_reg_pool_id
-
사용하려는 서브스크립션 풀 ID입니다. 서브스크립션을 자동 첨부하지 않는 경우 이 옵션을 사용합니다. 이 ID를 찾으려면 언더클라우드 노드에서
sudo subscription-manager list --available --all --matches="*OpenStack*"을 실행하고 결과풀 ID값을 사용합니다. - rhel_reg_sat_url
-
오버클라우드 노드를 등록할 Satellite Server의 기본 URL입니다. Satellite Server HTTP URL 대신 이 매개 변수의 HTTPS URL을 사용합니다. 예를 들어 https://satellite.example.com 대신 http://satellite.example.com을 사용합니다. 오버클라우드 생성 프로세스에서는 이 URL을 사용하여 Red Hat Satellite Server 5 또는 Red Hat Satellite Server 6을 사용 중인지 확인합니다. Red Hat Satellite Server 6을 사용하는 경우 오버클라우드는
katello-ca-consumer-latest.noarch.rpm파일을 가져오고subscription-manager에 등록하고katello-agent를 설치합니다. Red Hat Satellite Server 5를 사용하는 경우 오버클라우드는RHN-ORG-TRUSTED-SSL-CERT파일을 가져오고rhnreg_ks에 등록합니다. - rhel_reg_server_url
- 사용하려는 서브스크립션 서비스의 호스트 이름입니다. 고객 포털 서브스크립션 관리의 기본값은 subscription.rhn.redhat.com입니다. 이 옵션을 사용하지 않는 경우 시스템은 고객 포털 서브스크립션 관리에 등록됩니다. 서브스크립션 서버 URL은 https://hostname:port/prefix 형식을 사용합니다.
- rhel_reg_base_url
- 업데이트를 수신하는 데 사용할 콘텐츠 전달 서버의 호스트 이름입니다. 기본값은 https://cdn.redhat.com 입니다. Satellite 6은 자체 콘텐츠를 호스팅하므로 Satellite 6에 등록된 시스템에 URL을 사용해야 합니다. 콘텐츠의 기본 URL에서는 https://hostname:port/prefix 형식을 사용합니다.
- rhel_reg_org
-
등록에 사용하려는 조직입니다. 이 ID를 찾으려면 언더클라우드 노드에서
sudo subscription-manager orgs를 실행합니다. 메시지가 표시되면 Red Hat 자격 증명을 입력하고 결과키값을 사용합니다. - rhel_reg_environment
- 선택한 조직 내에서 사용하려는 환경입니다.
- rhel_reg_repos
- 활성화할 쉼표로 구분된 리포지토리 목록입니다.
- rhel_reg_activation_key
- 등록에 사용할 활성화 키입니다. 등록에 활성화 키를 사용하는 경우 등록에 사용할 조직도 지정해야 합니다.
- rhel_reg_user; rhel_reg_password
- 등록에 사용할 사용자 이름과 암호입니다. 가능한 경우 등록에 활성화 키를 사용합니다.
- rhel_reg_machine_name
- 등록에 사용할 시스템 이름입니다. 노드의 호스트 이름을 사용하려면 이 비워 두십시오.
- rhel_reg_force
-
노드를 다시 등록할 때 등록 옵션을 강제 적용하려면
true로 설정합니다. - rhel_reg_sat_repo
-
Red Hat Satellite 6 서버 관리 툴(예:
katello-agent)이 포함된 리포지토리입니다. 리포지토리 이름이 Satellite Server 버전에 해당하고 리포지토리가 Satellite Server에 동기화되었는지 확인합니다. 예를 들어rhel-7-server-satellite-tools-6.2-rpms는 Red Hat Satellite 6.2에 해당합니다.
업그레이드 매개 변수
- UpdateOnRHELRegistration
-
True로 설정하면 등록이 완료되면 오버클라우드 패키지 업데이트가 트리거됩니다. 기본적으로False로 설정합니다.
HTTP 프록시 매개 변수
- rhel_reg_http_proxy_host
-
HTTP 프록시의 호스트 이름입니다. 예:
proxy.example.com - rhel_reg_http_proxy_port
-
HTTP 프록시 통신용 포트입니다. 예를 들면 다음과 같습니다.
8080. - rhel_reg_http_proxy_username
- HTTP 프록시에 액세스할 사용자 이름입니다.
- rhel_reg_http_proxy_password
- HTTP 프록시에 액세스할 암호입니다.
프록시 서버를 사용하는 경우 모든 오버클라우드 노드에 rhel_reg_http_proxy_host 매개 변수에 정의된 호스트 경로가 있는지 확인합니다. 이 호스트의 경로가 없으면 subscription-manager 가 시간 초과되고 배포 실패가 발생합니다.
배포 명령(openstack overcloud deploy)은 -e 옵션을 사용하여 환경 파일을 추가합니다. ~/templates/rhel-registration/environment-rhel-registration.yaml 및 ~/templates/rhel-registration/rhel-registration-resource-registry.yaml 을 둘 다 추가합니다. 예를 들면 다음과 같습니다.
openstack overcloud deploy --templates [...] -e /home/stack/templates/rhel-registration/environment-rhel-registration.yaml -e /home/stack/templates/rhel-registration/rhel-registration-resource-registry.yaml
$ openstack overcloud deploy --templates [...] -e /home/stack/templates/rhel-registration/environment-rhel-registration.yaml -e /home/stack/templates/rhel-registration/rhel-registration-resource-registry.yaml
등록은 OS::TripleO::NodeExtraConfig Heat 리소스로 설정됩니다. 즉, 등록에는 이 리소스만 사용할 수 있습니다. 자세한 내용은 4.2절. “구성 전: 특정 오버클라우드 역할 사용자 정의”를 참조하십시오.
5.2. 예 1: 고객 포털에 등록 링크 복사링크가 클립보드에 복사되었습니다!
다음은 my-openstack 활성화 키를 사용하여 오버클라우드 노드를 Red Hat 고객 포털에 등록하고 1a85f9223e3d5e43013e3e8ff506fd 풀을 서브스크립션합니다.
5.3. 예 2: Red Hat Satellite 6 Server에 등록 링크 복사링크가 클립보드에 복사되었습니다!
다음은 sat6.example.com의 Red Hat Satellite 6 Server에 오버클라우드 노드를 등록하고 my-openstack 활성화 키를 사용하여 풀 1a85f9223e3d5e43013e3d6e8ff506fd 에 가입합니다. 이 경우 활성화 키는 활성화할 리포지토리도 제공합니다.
5.4. 예 3: Red Hat Satellite 5 Server에 등록 링크 복사링크가 클립보드에 복사되었습니다!
다음은 sat5.example.com의 Red Hat Satellite 5 Server에 오버클라우드 노드를 등록하고 my-openstack 활성화 키를 사용하여 서브스크립션을 자동으로 연결합니다. 이 경우 활성화 키는 활성화할 리포지토리도 제공합니다.
5.5. 예 4: HTTP 프록시를 통한 등록 링크 복사링크가 클립보드에 복사되었습니다!
다음 샘플 매개변수는 원하는 등록 방법에 대한 HTTP 프록시 설정을 설정합니다.
5.6. 고급 등록 방법 링크 복사링크가 클립보드에 복사되었습니다!
경우에 따라 다른 서브스크립션 유형에 다른 역할을 등록해야 할 수 있습니다. 예를 들어 컨트롤러 노드만 OpenStack Platform 서브스크립션에 서브스크립션하고 Ceph Storage 노드를 Ceph Storage 서브스크립션에 가입하려고 할 수 있습니다. 이 섹션에서는 다양한 역할에 별도의 서브스크립션을 할당하는 데 도움이 되는 몇 가지 고급 등록 방법을 제공합니다.
구성 후크
한 가지 방법은 역할별 스크립트를 작성하고 역할별 후크를 사용하여 포함하는 것입니다. 예를 들어 다음 코드 조각을 OS::TripleO::ControllerExtraConfigPre 리소스의 템플릿에 추가하여 컨트롤러 노드만 이러한 서브스크립션 세부 정보를 수신할 수 있습니다.
이 스크립트는 subscription-manager 명령 집합을 사용하여 시스템을 등록하고, 서브스크립션을 연결하며, 필요한 리포지토리를 활성화합니다.
후크에 대한 자세한 내용은 4장. 구성 후크 을 참조하십시오.
Ansible 기반 구성
director의 동적 인벤토리 스크립트를 사용하여 특정 역할에 대한 Ansible 기반 등록을 수행할 수 있습니다. 예를 들어 다음 플레이를 사용하여 컨트롤러 노드를 등록하려고 할 수 있습니다.
이 플레이에는 세 가지 작업이 포함되어 있습니다. - 활성화 키를 사용하여 노드 등록 - 자동 사용 리포지토리 비활성화 - 컨트롤러 노드와 관련된 리포지토리만 활성화합니다. 리포지토리는 repos 변수를 사용하여 나열됩니다.
오버클라우드를 배포한 후 Ansible이 오버클라우드에 대해 플레이북(ansible-osp-registration.yml)을 실행하도록 다음 명령을 실행할 수 있습니다.
ansible-playbook -i /usr/bin/tripleo-ansible-inventory ansible-osp-registration.yml
$ ansible-playbook -i /usr/bin/tripleo-ansible-inventory ansible-osp-registration.yml
이 명령은 다음을 수행합니다. - 동적 인벤토리 스크립트를 실행하여 호스트 및 그룹 목록을 가져옵니다. - 플레이북의 hosts 매개 변수에 정의된 그룹의 노드에 플레이북 작업을 적용합니다. 이 경우에는 Controller 그룹입니다.
오버클라우드에서 실행 중인 Ansible 자동화에 대한 자세한 내용은 Director 설치 및 사용 가이드의 "Ansible 자동화 실행" 을 참조하십시오.
6장. Ansible 기반 오버클라우드 등록 링크 복사링크가 클립보드에 복사되었습니다!
이 기능은 이번 릴리스에서 기술 프리뷰로 제공되므로 Red Hat에서 완전히 지원되지 않습니다. 테스트 용도로만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.
5장. 오버클라우드 등록 의 rhel-registration 방법에 대한 대안으로 director는 Ansible 기반 방법을 사용하여 오버클라우드 노드를 Red Hat Customer Portal 또는 Red Hat Satellite 6 서버에 등록할 수 있습니다. 이 방법은 오버클라우드에서 Ansible 기반구성(config-download)을 활성화하는 데 사용합니다.
6.1. RHSM(Red Hat Subscription Manager) 구성 가능 서비스 링크 복사링크가 클립보드에 복사되었습니다!
The rhsm 구성 가능 서비스는 Ansible을 통해 오버클라우드 노드를 등록하는 방법을 제공합니다. 기본 roles_data 파일의 각 역할에는 기본적으로 비활성화된 OS::TripleO::Services::Rhsm 리소스가 포함되어 있습니다. 서비스를 활성화하려면 리소스를 rhsm 구성 가능 서비스 파일에 등록합니다. 예를 들면 다음과 같습니다.
resource_registry: OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/extraconfig/services/rhsm.yaml
resource_registry:
OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/extraconfig/services/rhsm.yaml
The rhsm 구성 가능 서비스는 RhsmVars 매개변수를 허용하므로 등록과 관련된 여러 하위 매개변수를 정의할 수 있습니다. 예를 들면 다음과 같습니다.
역할별 매개변수(예: ControllerParameter 매개변수를 사용하여 다른 노드 유형에 특정 리포지토리를 활성화할 때 유연성을 제공할 수도 있습니다.
s)와 함께 RhsmVar s
다음 섹션은 Rhsm 목록입니다.
구성 가능 서비스와 함께 사용할 수 있는 하위 매개변수
6.2. RhsmVars 하위 매개변수 링크 복사링크가 클립보드에 복사되었습니다!
rhsm | 설명 |
|---|---|
|
|
등록 방법을 선택합니다. |
|
|
등록에 사용할 조직입니다. 이 ID를 찾으려면 언더클라우드 노드에서 |
|
|
사용할 서브스크립션 풀 ID입니다. 서브스크립션을 자동 첨부하지 않는 경우 이 옵션을 사용합니다. 이 ID를 찾으려면 언더클라우드 노드에서 |
|
| 등록에 사용할 활성화 키입니다. |
|
|
이 시스템에 호환 가능한 서브스크립션을 자동으로 첨부합니다. 활성화하려면 |
|
| 오버클라우드 노드를 등록할 Satellite 서버의 기본 URL입니다. |
|
| 활성화할 리포지토리 목록입니다. |
|
| 등록할 사용자 이름입니다. 가능한 경우 등록에 활성화 키를 사용합니다. |
|
| 등록할 암호입니다. 가능한 경우 등록에 활성화 키를 사용합니다. |
|
|
HTTP 프록시의 호스트 이름입니다. 예: |
|
|
HTTP 프록시 통신용 포트입니다. 예를 들면 다음과 같습니다. |
|
| HTTP 프록시에 액세스할 사용자 이름입니다. |
|
| HTTP 프록시에 액세스할 암호입니다. |
이제 the rhsm 구성 가능 서비스 작동 방식과 구성 방법에 대해 이해했으므로 다음 절차를 사용하여 고유한 등록 세부 정보를 구성할 수 있습니다.
6.3. rhsm 구성 가능 서비스를 사용하여 오버클라우드 등록 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에 따라 구성 가능 서비스를 활성화하고 구성하는 환경 파일을 생성합니다. director는 이 환경 파일을 사용하여 노드를 등록하고 서브스크립션합니다.
절차
-
환경 파일(
templates/rhsm.yml)을 만들어 구성을 저장합니다. 환경 파일에 구성을 포함합니다. 예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow resource_registry는 각 역할에서 사용할 수 있는OS::TripleO::Services::Rhsm리소스와rhsm구성 가능 서비스를 연결합니다.RhsmVars변수는 Red Hat 등록을 구성하기 위해 매개 변수를 Ansible에 전달합니다.- 환경 파일 저장
특정 오버클라우드 역할에 대한 등록 세부 정보도 제공할 수 있습니다. 다음 섹션에서는 이 예제를 제공합니다.
6.4. 다른 역할에 rhsm 구성 가능 서비스 적용 링크 복사링크가 클립보드에 복사되었습니다!
역할별로 the rhsm 구성 가능 서비스를 적용할 수 있습니다. 예를 들어 컨트롤러 노드에 하나의 구성 세트를 적용하고 다른 구성 세트를 컴퓨팅 노드에 적용할 수 있습니다.
절차
-
환경 파일(
templates/rhsm.yml)을 만들어 구성을 저장합니다. 환경 파일에 구성을 포함합니다. 예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow resource_registry는 각 역할에서 사용할 수 있는OS::TripleO::Services::Rhsm리소스와rhsm구성 가능 서비스를 연결합니다.ControllerParameters및ComputeParameters둘 다 고유한RhsmVars매개변수를 사용하여 서브스크립션 세부 정보를 해당 역할에 전달합니다.- 환경 파일 저장
6.5. Red Hat Satellite Server에 오버클라우드 등록 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat 고객 포털 대신 Red Hat Satellite에 노드를 등록하도록 rhsm 구성 가능 서비스를 활성화하고 구성하는 환경 파일을 생성합니다.
절차
-
templates/rhsm.yml이라는 환경 파일을 생성하여 구성을 저장합니다. 환경 파일에 구성을 포함합니다. 예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow resource_registry는 각 역할에서 사용할 수 있는OS::TripleO::Services::Rhsm리소스와rhsm구성 가능 서비스를 연결합니다.RhsmVars변수는 Red Hat 등록을 구성하기 위해 매개 변수를 Ansible에 전달합니다.- 환경 파일을 저장합니다.
다음 절차에서는 오버클라우드 에서rhsm 을 활성화하고 구성합니다. 그러나 5장. 오버클라우드 등록 의 rhel-registration 방법을 사용하는 경우 Ansible 기반 방법으로 전환하려면 비활성화해야 합니다. rhel-registration 방법에서 Ansible 기반 방법으로 전환하려면 다음 절차를 사용합니다.
6.6. rhsm 구성 가능 서비스로 전환 링크 복사링크가 클립보드에 복사되었습니다!
Overcloud 등록을 처리하는 bash 스크립트를 실행하는 rhel-registration 메서드입니다. 이 메서드의 스크립트 및 환경 파일은 /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
-
-
향후 배포 작업에 환경 파일 for
rhsmcomposable 서비스 매개변수를 추가합니다.
이 메서드는 rhel-registration 매개변수를 rhsm 서비스 매개변수로 교체하고 다음과 같이 서비스를 활성화하는 Heat 리소스를 변경합니다.
resource_registry: OS::TripleO::NodeExtraConfig: rhel-registration.yaml
resource_registry:
OS::TripleO::NodeExtraConfig: rhel-registration.yaml
다음으로 변경합니다.
resource_registry: OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/extraconfig/services/rhsm.yaml
resource_registry:
OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/extraconfig/services/rhsm.yaml
rhel-registration 메서드에서 rhsm 메서드로 세부 정보를 전환하는 데 도움이 되도록 다음 표를 사용하여 매개변수 및 해당 값을 매핑합니다.
6.7. rhel-registration to rhsm mappings 링크 복사링크가 클립보드에 복사되었습니다!
rhel-registration | rhsm / RhsmVars |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
이제 rhsm 서비스에 대한 환경 파일을 구성했으므로 다음 오버클라우드 배포 작업을 통해 이 파일을 포함할 수 있습니다.
6.8. rhsm 구성 가능 서비스를 사용하여 오버클라우드 배포 링크 복사링크가 클립보드에 복사되었습니다!
다음 프로세스에서는 오버클라우드에 your rhsm 구성을 적용하는 방법을 보여줍니다.
절차
openstack overcloud deploy명령을 실행하는 경우config-download옵션 및 환경 파일과rhsm.yml환경 파일을 포함합니다.openstack overcloud deploy \ <other cli args> \ -e /usr/share/openstack-tripleo-heat-templates/environments/config-download-environment.yaml \ --config-download \ -e ~/templates/rhsm.yamlopenstack overcloud deploy \ <other cli args> \ -e /usr/share/openstack-tripleo-heat-templates/environments/config-download-environment.yaml \ --config-download \ -e ~/templates/rhsm.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이렇게 하면 오버클라우드의 Ansible 구성 및 Ansible 기반 등록이 활성화됩니다.
- Overcloud 배포가 완료될 때까지 기다립니다.
오버클라우드 노드에서 서브스크립션 세부 정보를 확인합니다. 예를 들어 컨트롤러 노드에 로그인하고 다음 명령을 실행합니다.
sudo subscription-manager status sudo subscription-manager list --consumed
$ sudo subscription-manager status $ sudo subscription-manager list --consumedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7장. 구성 가능 서비스 및 사용자 지정 역할 링크 복사링크가 클립보드에 복사되었습니다!
Overcloud는 일반적으로 컨트롤러 노드, 컴퓨팅 노드 및 다양한 스토리지 노드 유형과 같은 사전 정의된 역할의 노드로 구성됩니다. 이러한 각 기본 역할에는 director 노드의 코어 Heat 템플릿 컬렉션에 정의된 서비스 세트가 포함되어 있습니다. 그러나 핵심 Heat 템플릿의 아키텍처에서는 다음을 수행하는 방법을 제공합니다.
- 사용자 지정 역할 만들기
- 각 역할에서 서비스 추가 및 제거
이를 통해 다양한 역할에 서비스 조합을 생성할 수 있습니다. 이 장에서는 사용자 지정 역할, 구성 가능 서비스 및 이를 사용하는 방법에 대해 살펴봅니다.
7.1. 지원되는 역할 아키텍처 링크 복사링크가 클립보드에 복사되었습니다!
사용자 지정 역할 및 구성 가능한 서비스를 사용할 때 다음과 같은 아키텍처를 사용할 수 있습니다.
- 아키텍처 1 - 기본 아키텍처
-
기본
roles_data파일을 사용합니다. 모든 컨트롤러 서비스는 하나의 컨트롤러 역할 내에 포함됩니다. - 아키텍처 2 - 지원되는 독립 실행형 역할
-
/usr/share/openstack-tripleo-heat-templates/roles에서 사전 정의된 파일을 사용하여 사용자 지정roles_data파일'을 생성합니다. 7.2.3절. “지원되는 사용자 지정 역할”을 참조하십시오. - 아키텍처 3 - 맞춤형 구성 가능 서비스
-
고유한
역할을생성하고 이를 사용하여 사용자 지정roles_data파일을 생성합니다. 제한된 수의 구성 가능 서비스 조합만 테스트 및 검증되었으며 Red Hat은 모든 구성 가능한 서비스 조합을 지원할 수 없습니다.
7.2. 역할 링크 복사링크가 클립보드에 복사되었습니다!
7.2.1. roles_data 파일 검사 링크 복사링크가 클립보드에 복사되었습니다!
Overcloud 생성 프로세스는 roles_data 파일을 사용하여 역할을 정의합니다. roles_data 파일에는 YAML 형식의 역할 목록이 포함되어 있습니다. 다음은 roles_data 구문의 단축된 예입니다.
코어 Heat 템플릿 컬렉션에는 /usr/share/openstack-tripleo-heat-templates/roles_data.yaml에 있는 기본 포함되어 있습니다. 기본 파일은 다음 역할 유형을 정의합니다.
roles_data 파일이
-
컨트롤러 -
Compute -
BlockStorage -
ObjectStorage -
CephStorage.
openstack overcloud deploy 명령에는 배포 중에 이 파일이 포함됩니다. r 인수를 사용하여 이 파일을 사용자 지정 roles_data 파일로 재정의할 수 있습니다. 예를 들면 다음과 같습니다.
openstack overcloud deploy --templates -r ~/templates/roles_data-custom.yaml
$ openstack overcloud deploy --templates -r ~/templates/roles_data-custom.yaml
7.2.2. roles_data 파일 생성 링크 복사링크가 클립보드에 복사되었습니다!
사용자 지정 roles_data 파일을 수동으로 생성할 수 있지만 개별 역할 템플릿을 사용하여 파일을 자동으로 생성할 수도 있습니다. director는 역할 템플릿을 관리하고 사용자 지정 roles_data 파일을 자동으로 생성하는 여러 명령을 제공합니다.
기본 역할 템플릿을 나열하려면 openstack overcloud role list 명령을 사용합니다.
역할의 YAML 정의를 보려면 openstack overcloud role show 명령을 사용합니다.
openstack overcloud role show Compute
$ openstack overcloud role show Compute
사용자 지정 roles_data 파일을 생성하려면 openstack overcloud roles generate 명령을 사용하여 사전 정의된 여러 역할을 하나의 파일에 결합합니다. 예를 들어 다음 명령은 Controller,Compute 및 Networker 역할을 단일 파일에 결합합니다.
openstack overcloud roles generate -o ~/roles_data.yaml Controller Compute Networker
$ openstack overcloud roles generate -o ~/roles_data.yaml Controller Compute Networker
o는 생성할 파일의 이름을 정의합니다.
이렇게 하면 사용자 지정 roles_data 파일이 생성됩니다. 그러나 이전 예제에서는 모두 동일한 네트워킹 에이전트를 포함하는 Controller 및 Networker 역할을 사용합니다. 즉, 네트워킹 서비스가 컨트롤러에서 Networker 역할로 확장됩니다. Overcloud에서 컨트롤러 노드와 네트워크 노드 간에 네트워킹 서비스에 대한 부하를 분산합니다.
이 Networker 역할을 독립 실행형으로 만들려면 고유한 사용자 지정 컨트롤러 역할과 필요한 다른 역할을 만들 수 있습니다. 이를 통해 사용자 지정 역할에서 roles_data 파일을 쉽게 생성할 수 있습니다.
코어 Heat 템플릿 컬렉션의 디렉터리를 stack 사용자의 홈 디렉터리에 복사합니다.
cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
$ 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
$ 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 을 사용할 수 있습니다.
7.2.3. 지원되는 사용자 지정 역할 링크 복사링크가 클립보드에 복사되었습니다!
다음 표는 /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를 사용하는 컨트롤러 역할. 이 역할은 데이터베이스, 메시징 및 네트워크 기능을 처리합니다. |
|
|
| 모든 핵심 서비스가 로드된 컨트롤러 역할. 이 역할은 데이터베이스, 메시징 및 네트워크 기능을 처리합니다. |
|
|
| 독립 실행형 데이터베이스 역할. 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을 사용하여 사용자 지정 역할 배포의 추가 단계를 참조하십시오. |
|
|
|
OpenStack Compute(nova) 제어 에이전트를 자체적으로 실행하는 독립 실행형 |
|
|
| Swift 오브젝트 스토리지 노드 역할. |
|
|
| 모든 지표 및 알람 서비스가 포함된 원격 분석 역할. |
|
7.2.4. 역할 매개 변수 검사 링크 복사링크가 클립보드에 복사되었습니다!
각 역할은 다음 매개변수를 사용합니다.
- name
-
(필수) 공백이나 특수 문자가 없는 일반 텍스트 이름인 역할의 이름입니다. 선택한 이름이 다른 리소스와 충돌하지 않는지 확인합니다. 예를 들어
Network 대신를 사용합니다.Networker - description
- (선택 사항) 역할에 대한 일반 텍스트 설명입니다.
- tags
(선택 사항) 역할 속성을 정의하는 YAML 태그 목록입니다. 이 매개변수를 사용하여
컨트롤러와기본 태그 둘 다로기본역할을 정의합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
기본 역할에 태그를 지정하지 않으면 정의된 첫 번째 역할이 기본 역할이 됩니다. 이 역할이 Controller 역할인지 확인합니다.
- 네트워크
역할에 구성할 네트워크의 YAML 목록입니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 기본 네트워크에는
External,InternalApi,Storage, StorageMgmt,Tenant및Management가 포함됩니다.- CountDefault
- (선택 사항) 이 역할에 배포할 기본 노드 수를 정의합니다.
- HostnameFormatDefault
(선택 사항) 역할에 대한 기본 호스트 이름 형식을 정의합니다. 기본 명명 규칙은 다음 형식을 사용합니다.
[STACK NAME]-[ROLE NAME]-[NODE ID]
[STACK NAME]-[ROLE NAME]-[NODE ID]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예를 들어 기본 컨트롤러 노드의 이름은 다음과 같습니다.
overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ...
overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - disable_constraints
- (선택 사항) director와 함께 배포할 때 OpenStack Compute(nova) 및 OpenStack Image Storage(glance) 제약 조건을 비활성화할지 여부를 정의합니다. 사전 프로비저닝된 노드가 있는 오버클라우드를 배포할 때 사용합니다. 자세한 내용은 Director 설치 및 사용 가이드 의 "사전 프로비저닝된 노드를 사용하여 기본 Overcloud 구성" 을 참조하십시오.
- disable_upgrade_deployment
- (선택 사항) 특정 역할에 대한 업그레이드를 비활성화할지 여부를 정의합니다. 이렇게 하면 역할에서 개별 노드를 업그레이드하고 서비스 가용성을 보장할 수 있습니다. 예를 들어 Compute 및 Swift Storage 역할은 이 매개 변수를 사용합니다.
- update_serial
(선택 사항) OpenStack 업데이트 옵션 중에 동시에 업데이트할 노드 수를 정의합니다. 기본
roles_data.yaml파일에서 다음을 수행합니다.-
기본값은 Controller, Object Storage 및 Ceph Storage 노드의 경우
1입니다. -
Compute 및 Block Storage 노드의 기본값은
25입니다.
사용자 지정 역할에서 이 매개변수를 생략하면 기본값은
1입니다.-
기본값은 Controller, Object Storage 및 Ceph Storage 노드의 경우
- ServicesDefault
- (선택 사항) 노드에 포함할 기본 서비스 목록을 정의합니다. 자세한 내용은 7.3.2절. “구성 가능한 서비스 아키텍처 검사”를 참조하십시오.
이러한 매개 변수는 새 역할을 생성하고 포함할 서비스를 정의하는 방법을 제공합니다.
openstack overcloud deploy 명령은 roles_data 파일의 매개 변수를 Jinja2 기반 템플릿에 통합합니다. 예를 들어 특정 지점에서 overcloud.j2.yaml Heat 템플릿은 roles_data.yaml 의 역할 목록을 반복하고 각 역할과 관련된 매개 변수와 리소스를 생성합니다.
overcloud.j2.yaml Heat 템플릿의 각 역할에 대한 리소스 정의가 다음 코드 조각으로 표시됩니다.
이 코드 조각은 Jinja2 기반 템플릿이 {{role.name}} 변수를 통합하여 각 역할의 이름을 OS::Heat::ResourceGroup 리소스로 정의하는 방법을 보여줍니다. 그런 다음 roles_data 파일의 각 name 매개변수를 사용하여 각각의 OS::Heat::ResourceGroup 리소스 이름을 지정합니다.
7.2.5. 새 역할 생성 링크 복사링크가 클립보드에 복사되었습니다!
이 예에서 목표는 OpenStack 대시보드( Horizonizon 역할을 생성하는 것입니다. 이 경우 새 )만 호스팅하는 새 Horizon역할 정보가 포함된 사용자 지정 역할 디렉터리를 생성합니다.
기본 역할 디렉터리의 사용자 지정 사본을 생성합니다.
cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
$ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
~/roles/Horizon.yaml 이라는 새 파일을 생성하고 기본 및 핵심 OpenStack 대시보드 서비스를 포함하는 새 Horizon 역할을 만듭니다. 예를 들면 다음과 같습니다.
또한 기본 Overcloud에 항상 Horizon 노드를 포함하도록 CountDefault 를 1 로 설정하는 것이 좋습니다.
기존 오버클라우드에서 서비스를 확장하는 경우 기존 서비스를 Controller 역할에 유지합니다. 새 오버클라우드를 생성하고 OpenStack 대시보드를 독립 실행형 역할에 유지하려면 컨트롤러 역할 정의에서 OpenStack 대시보드 구성 요소를 제거합니다.
roles 디렉터리를 소스로 사용하여 새 파일을 생성합니다.
roles _data
openstack overcloud roles generate -o roles_data-horizon.yaml \ --roles-path ~/roles \ Controller Compute Horizon
$ openstack overcloud roles generate -o roles_data-horizon.yaml \
--roles-path ~/roles \
Controller Compute Horizon
특정 노드에 태그를 지정할 수 있도록 이 역할에 대한 새 플레이버를 정의해야 할 수 있습니다. 이 예에서는 다음 명령을 사용하여 Horizon 플레이버를 생성합니다.
openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 horizon openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="horizon" horizon openstack flavor set --property resources:VCPU=0 --property resources:MEMORY_MB=0 --property resources:DISK_GB=0 --property resources:CUSTOM_BAREMETAL=1 horizon
$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 horizon
$ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="horizon" horizon
$ openstack flavor set --property resources:VCPU=0 --property resources:MEMORY_MB=0 --property resources:DISK_GB=0 --property resources:CUSTOM_BAREMETAL=1 horizon
다음 명령을 사용하여 노드를 새 플레이버에 태그합니다.
openstack baremetal node set --property capabilities='profile:horizon,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13
$ openstack baremetal node set --property capabilities='profile:horizon,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13
다음 환경 파일 스니펫을 사용하여 Horizon 노드 수 및 플레이버를 정의합니다.
parameter_defaults: OvercloudHorizonFlavor: horizon HorizonCount: 1
parameter_defaults:
OvercloudHorizonFlavor: horizon
HorizonCount: 1
openstack overcloud deploy 명령을 실행할 때 새 roles_data 파일 및 환경 파일을 포함합니다. 예를 들면 다음과 같습니다.
openstack overcloud deploy --templates -r ~/templates/roles_data-horizon.yaml -e ~/templates/node-count-flavor.yaml
$ openstack overcloud deploy --templates -r ~/templates/roles_data-horizon.yaml -e ~/templates/node-count-flavor.yaml
배포가 완료되면 컨트롤러 노드 1개, 컴퓨팅 노드 1개, Networker 노드 1개로 구성된 3노드 Overcloud가 생성됩니다. 오버클라우드의 노드 목록을 보려면 다음 명령을 실행합니다.
openstack server list
$ openstack server list
7.3. 구성 가능 서비스 링크 복사링크가 클립보드에 복사되었습니다!
7.3.1. 지침 및 제한 사항 링크 복사링크가 클립보드에 복사되었습니다!
구성 가능 노드 아키텍처에 대한 다음 지침 및 제한 사항을 확인합니다.
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:서비스가 포함된 사용자 지정 역할을 확장하거나 축소할 수 없습니다.:PacemakerRemote
일반 제한 사항:
- 메이저 버전 업그레이드 중에 사용자 정의 역할 및 구성 가능 서비스를 변경할 수 없습니다.
- Overcloud를 배포한 후에는 역할에 대한 서비스 목록을 수정할 수 없습니다. Overcloud 배포 후 서비스 목록을 수정하면 배포 오류가 발생하고 노드에 서비스를 분리할 수 있습니다.
7.3.2. 구성 가능한 서비스 아키텍처 검사 링크 복사링크가 클립보드에 복사되었습니다!
코어 heat 템플릿 컬렉션에는 구성 가능 서비스 템플릿의 두 세트가 포함되어 있습니다.
-
Puppet/services에는 구성 가능 서비스를 구성하는 기본 템플릿이 포함되어 있습니다. -
docker/services에는 주요 OpenStack Platform 서비스에 대한 컨테이너화된 템플릿이 포함되어 있습니다. 이러한 템플릿은 일부 기본 템플릿의 보강 기능을 하며 기본 템플릿으로 다시 참조합니다.
각 템플릿에는 목적을 식별하는 설명이 포함되어 있습니다. 예를 들어 ntp.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.
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.
이러한 서비스 템플릿은 RHOSP 배포와 관련된 리소스로 등록됩니다. 즉, overcloud-resource-registry-puppet.j2.yaml 파일에 정의된 고유한 heat 리소스 네임스페이스를 사용하여 각 리소스를 호출할 수 있습니다. 모든 서비스는 리소스 유형에 OS::TripleO::Services 네임스페이스를 사용합니다.
일부 리소스는 기본 구성 가능 서비스 템플릿을 직접 사용합니다.
resource_registry: ... OS::TripleO::Services::Ntp: puppet/services/time/ntp.yaml ...
resource_registry:
...
OS::TripleO::Services::Ntp: puppet/services/time/ntp.yaml
...
그러나 핵심 서비스에는 컨테이너가 필요하며 컨테이너화된 서비스 템플릿을 사용합니다. 예를 들어 keystone 컨테이너화된 서비스는 다음을 사용합니다.
resource_registry: ... OS::TripleO::Services::Keystone: docker/services/keystone.yaml ...
resource_registry:
...
OS::TripleO::Services::Keystone: docker/services/keystone.yaml
...
이러한 컨테이너화된 템플릿은 일반적으로 Puppet 구성을 포함하기 위해 기본 템플릿으로 다시 참조합니다. 예를 들어 docker/services/keystone.yaml 템플릿은 기본 템플릿의 출력을 KeystoneBase 매개변수에 저장합니다.
KeystoneBase: type: ../../puppet/services/keystone.yaml
KeystoneBase:
type: ../../puppet/services/keystone.yaml
컨테이너화된 템플릿은 기본 템플릿의 기능과 데이터를 통합할 수 있습니다.
overcloud.j2.yaml heat 템플릿에는 roles_data.yaml 파일에서 각 사용자 지정 역할에 대한 서비스 목록을 정의하는 Jinja2 기반 코드 섹션이 포함되어 있습니다.
기본 역할의 경우 다음 서비스 목록 매개변수가 생성됩니다. ControllerServices,ComputeServices,BlockStorageServices,ObjectStorageServices 및 CephStorageServices.
roles_data.yaml 파일에서 각 사용자 지정 역할에 대한 기본 서비스를 정의합니다. 예를 들어 기본 Controller 역할에는 다음 내용이 포함됩니다.
그런 다음 이러한 서비스는 ControllerServices 매개변수의 기본 목록으로 정의됩니다.
환경 파일을 사용하여 서비스 매개변수의 기본 목록을 재정의할 수도 있습니다. 예를 들어 환경 파일에서 ControllerServices 를 parameter_default 로 정의하여 roles_data.yaml 파일의 서비스 목록을 재정의할 수 있습니다.
7.3.3. 역할에서 서비스 추가 및 제거 링크 복사링크가 클립보드에 복사되었습니다!
서비스를 추가하거나 제거하는 기본 방법은 노드 역할에 대한 기본 서비스 목록 복사본을 생성한 다음 서비스를 추가하거나 제거하는 것입니다. 예를 들어 컨트롤러 노드에서 OpenStack Orchestration(heat)을 제거하려고 할 수 있습니다. 이 경우 기본 역할 디렉터리의 사용자 지정 사본을 생성합니다.
cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
$ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
~/roles/Controller.yaml 파일을 편집하고 ServicesDefault 매개변수의 서비스 목록을 수정합니다. OpenStack Orchestration 서비스로 스크롤하여 제거합니다.
새 roles_data 파일을 생성합니다. 예를 들면 다음과 같습니다.
openstack overcloud roles generate -o roles_data-no_heat.yaml \ --roles-path ~/roles \ Controller Compute Networker
$ 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 overcloud deploy --templates -r ~/templates/roles_data-no_heat.yaml
이렇게 하면 컨트롤러 노드에 OpenStack Orchestration 서비스가 설치되지 않고 Overcloud가 배포됩니다.
또한 사용자 지정 환경 파일을 사용하여 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
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
7.3.4. 비활성 서비스 활성화 링크 복사링크가 클립보드에 복사되었습니다!
일부 서비스는 기본적으로 비활성화되어 있습니다. 이러한 서비스는 overcloud-resource-registry-puppet.j2.yaml 파일에서 null 작업(OS::Heat::None)으로 등록됩니다. 예를 들어 블록 스토리지 백업 서비스(cinder-backup)가 비활성화됩니다.
OS::TripleO::Services::CinderBackup: OS::Heat::None
OS::TripleO::Services::CinderBackup: OS::Heat::None
이 서비스를 활성화하려면 puppet/services 디렉터리의 해당 Heat 템플릿에 리소스를 연결하는 환경 파일을 포함합니다. 일부 서비스에는 환경 디렉터리에 사전 정의된 환경 파일이 있습니다. 예를 들어 블록 스토리지 백업 서비스는 다음이 포함된 environments/cinder-backup.yaml 파일을 사용합니다.
resource_registry: OS::TripleO::Services::CinderBackup: ../docker/services/pacemaker/cinder-backup.yaml ...
resource_registry:
OS::TripleO::Services::CinderBackup: ../docker/services/pacemaker/cinder-backup.yaml
...
이렇게 하면 기본 null 작업 리소스를 재정의하고 서비스를 활성화합니다. openstack overcloud deploy 명령을 실행할 때 이 환경 파일을 포함합니다.
openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml
$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml
비활성화된 서비스를 활성화하는 방법에 대한 또 다른 예는 OpenStack Data Processing 가이드 의 설치를 참조하십시오. 이 섹션에서는 Overcloud에서 OpenStack Data Processing 서비스(sahara)를 활성화하는 방법에 대한 지침을 설명합니다.
7.3.5. 서비스가 없는 일반 노드 생성 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat OpenStack Platform은 OpenStack 서비스를 구성하지 않고 일반 Red Hat Enterprise Linux 7 노드를 생성할 수 있는 기능을 제공합니다. 이는 핵심 Red Hat OpenStack Platform 환경 외부에서 소프트웨어를 호스팅해야 하는 경우에 유용합니다. 예를 들어 OpenStack Platform은 Kibana 및 Sensu와 같은 모니터링 툴과의 통합을 제공합니다( 모니터링 툴 구성 가이드참조). Red Hat은 모니터링 툴 자체를 지원하지 않지만 director는 이러한 툴을 호스팅할 일반 Red Hat Enterprise Linux 7 노드를 생성할 수 있습니다.
일반 노드에서는 기본 Red Hat Enterprise Linux 7 이미지가 아닌 기본 overcloud-full 이미지를 계속 사용합니다. 즉, 노드에 일부 Red Hat OpenStack Platform 소프트웨어가 설치되어 있지만 활성화 또는 구성되지 않습니다.
일반 노드를 생성하려면 ServicesDefault 목록 없이 새 역할이 필요합니다.
- name: Generic
- name: Generic
사용자 지정 roles_data 파일( 기존 roles_data_with_generic.yaml)에 역할을 포함합니다.Controller 및 Compute 역할을 유지해야 합니다.
또한 환경 파일(generic-node-params.yaml)을 포함하여 필요한 일반 Red Hat Enterprise Linux 7 노드 수와 프로비저닝할 노드를 선택할 때 플레이버를 지정할 수도 있습니다. 예를 들면 다음과 같습니다.
parameter_defaults: OvercloudGenericFlavor: baremetal GenericCount: 1
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
$ openstack overcloud deploy --templates -r ~/templates/roles_data_with_generic.yaml -e ~/templates/generic-node-params.yaml
이렇게 하면 컨트롤러 노드 1개, 컴퓨팅 노드 1개, 일반 Red Hat Enterprise Linux 7 노드 1개가 있는 3-노드 환경이 배포됩니다.
8장. 컨테이너화된 서비스 링크 복사링크가 클립보드에 복사되었습니다!
director는 핵심 OpenStack Platform 서비스를 오버클라우드에 컨테이너로 설치합니다. 이 섹션에서는 컨테이너화된 서비스의 작동 방식에 대한 몇 가지 배경 정보를 제공합니다.
8.1. 컨테이너화된 서비스 아키텍처 링크 복사링크가 클립보드에 복사되었습니다!
director는 핵심 OpenStack Platform 서비스를 오버클라우드에 컨테이너로 설치합니다. 컨테이너화된 서비스의 템플릿은 /usr/share/openstack-tripleo-heat-templates/docker/services/ 에 있습니다. 이러한 템플릿은 각 구성 가능 서비스 템플릿을 참조합니다. 예를 들어 OpenStack ID(keystone) 컨테이너화된 서비스 템플릿(docker/services/keystone.yaml)에는 다음 리소스가 포함되어 있습니다.
유형은 해당 OpenStack ID(keystone) 구성 가능 서비스를 참조하고 해당 템플릿에서 출력 데이터를 가져옵니다. 컨테이너화된 서비스는 이 데이터를 자체 컨테이너 특정 데이터와 병합합니다.
컨테이너화된 서비스를 사용하는 모든 노드는 OS::TripleO::Services::Docker 서비스를 활성화해야 합니다. 사용자 지정 역할 구성에 대한 roles_data.yaml 파일을 생성할 때 컨테이너화된 서비스로 기본 구성 가능 서비스를 사용하여 OS::TripleO::Services::Docker 서비스를 포함합니다. 예를 들어 Keystone 역할은 다음 역할 정의를 사용합니다.
8.2. 컨테이너화된 서비스 매개변수 링크 복사링크가 클립보드에 복사되었습니다!
컨테이너화된 각 서비스 템플릿에는 director의 OpenStack Orchestration(heat) 서비스에 전달되는 데이터 집합을 정의하는 outputs 섹션이 포함되어 있습니다. 표준 구성 가능 서비스 매개변수( 7.2.4절. “역할 매개 변수 검사”참조) 외에도 템플릿에는 컨테이너 구성과 관련된 매개변수 세트가 포함되어 있습니다.
puppet_config서비스를 구성할 때 Puppet에 전달할 데이터입니다. 초기 오버클라우드 배포 단계에서 director는 실제 컨테이너화된 서비스가 실행되기 전에 서비스를 구성하는 데 사용되는 컨테이너 세트를 생성합니다. 이 매개 변수에는 다음 하위 매개 변수가 포함됩니다. +
-
config_volume- 구성을 저장하는 마운트된 Docker 볼륨입니다. -
puppet_tags- 구성 중에 Puppet에 전달할 태그입니다. 이러한 태그는 OpenStack Platform에서 Puppet 실행을 특정 서비스의 구성 리소스로 제한하는 데 사용됩니다. 예를 들어 OpenStack ID(keystone) 컨테이너화된 서비스는keystone_config태그를 사용하여 구성 컨테이너에서 필요한 모든keystone_configPuppet 리소스만 실행되도록 합니다. -
step_config- Puppet에 전달되는 구성 데이터입니다. 일반적으로 이는 참조된 구성 가능 서비스에서 상속됩니다. -
config_image- 서비스를 구성하는 데 사용되는 컨테이너 이미지입니다.
-
kolla_config- 구성 파일 위치, 디렉터리 권한 및 컨테이너에서 실행할 명령을 정의하여 서비스를 시작하는 컨테이너별 데이터 집합입니다.
docker_config서비스의 구성 컨테이너에서 실행할 작업. 모든 작업은 director에서 스테이징된 배포를 수행하는 데 도움이 되는 단계로 그룹화됩니다. 단계는 다음과 같습니다. +
- 1단계 - 로드 밸런서 구성
- 2단계 - 핵심 서비스(데이터베이스, Redis)
- 3 단계 - OpenStack Platform 서비스의 초기 구성
- 4 단계 - 일반 OpenStack Platform 서비스 구성
- 5단계 - 서비스 활성화
host_prep_tasks- 컨테이너화된 서비스를 수용하도록 베어 메탈 노드에 대한 작업 준비.
8.3. OpenStack Platform 컨테이너 수정 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat은 Red Hat Container Catalog(registry.redhat.io)를 통해 사전 빌드된 컨테이너 이미지 세트를 제공합니다. 이러한 이미지를 수정하고 계층을 추가할 수 있습니다. 이는 인증된 타사 드라이버의 RPM을 컨테이너에 추가하는 데 유용합니다.
수정된 OpenStack Platform 컨테이너 이미지에 대한 지속적인 지원을 보장하려면 결과 이미지가 "Red Hat Container Support Policy" 를 준수하는지 확인하십시오.
이 예에서는 최신 openstack-keystone 이미지를 사용자 지정하는 방법을 보여줍니다. 그러나 이러한 지침은 다른 이미지에도 적용할 수 있습니다.
수정하려는 이미지를 가져옵니다. 예를 들어
openstack-keystone이미지의 경우 다음을 수행합니다.sudo docker pull registry.redhat.io/rhosp13/openstack-keystone:latest
$ sudo docker pull registry.redhat.io/rhosp13/openstack-keystone:latestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 원본 이미지의 기본 사용자를 확인합니다. 예를 들어
openstack-keystone이미지의 경우 다음을 수행합니다.sudo docker run -it registry.redhat.io/rhosp13/openstack-keystone:latest whoami root
$ sudo docker run -it registry.redhat.io/rhosp13/openstack-keystone:latest whoami rootCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고openstack-keystone이미지는root를 기본 사용자로 사용합니다. 다른 이미지에서는 특정 사용자를 사용합니다. 예를 들어openstack-glance-api는 기본 사용자에게glance를 사용합니다.Dockerfile을 생성하여 기존 컨테이너 이미지에 추가 계층을 빌드합니다. 다음은 Container Catalog에서 최신 OpenStack Identity(keystone) 이미지를 가져와서 사용자 지정 RPM 파일을 이미지에 설치하는 예입니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 새 이미지를 빌드하고 태그를 지정합니다. 예를 들어
/home/stack/keystone디렉터리에 로컬Dockerfile을 저장하고 언더클라우드의 로컬 레지스트리에 태그를 지정하려면 다음을 수행합니다.docker build /home/stack/keystone -t "192.168.24.1:8787/rhosp13/openstack-keystone-acme:rev1"
$ docker build /home/stack/keystone -t "192.168.24.1:8787/rhosp13/openstack-keystone-acme:rev1"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 결과 이미지를 언더클라우드의 로컬 레지스트리로 내보냅니다.
docker push 192.168.24.1:8787/rhosp13/openstack-keystone-acme:rev1
$ docker push 192.168.24.1:8787/rhosp13/openstack-keystone-acme:rev1Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
오버클라우드 컨테이너 이미지 환경 파일(일반적으로
overcloud_images.yaml)을 편집하고 사용자 지정 컨테이너 이미지를 사용하도록 적절한 매개변수를 변경합니다.
Container Catalog는 전체 소프트웨어 스택이 빌드된 컨테이너 이미지를 게시합니다. Container Catalog에서 업데이트 및 보안 수정 사항으로 컨테이너 이미지를 릴리스하면 기존 사용자 정의 컨테이너에 이러한 업데이트가 포함되지 않으므로 카탈로그에서 새 이미지 버전을 사용하여 다시 빌드해야 합니다.
8.4. 벤더 플러그인 배포 링크 복사링크가 클립보드에 복사되었습니다!
타사 하드웨어를 블록 스토리지 백엔드로 사용하려면 벤더 플러그인을 배포해야 합니다. 다음 예제에서는 Dell EMC 하드웨어를 블록 스토리지 백엔드로 사용하기 위해 벤더 플러그인을 배포하는 방법을 보여줍니다.
registry.connect.redhat.com카탈로그에 로그인합니다.docker login registry.connect.redhat.com
$ docker login registry.connect.redhat.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 플러그인을 다운로드합니다.
docker pull registry.connect.redhat.com/dellemc/openstack-cinder-volume-dellemc-rhosp13
$ docker pull registry.connect.redhat.com/dellemc/openstack-cinder-volume-dellemc-rhosp13Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenStack 배포와 관련된 언더클라우드 IP 주소를 사용하여 이미지를 로컬 언더클라우드 레지스트리로 태그하고 푸시합니다.
docker tag registry.connect.redhat.com/dellemc/openstack-cinder-volume-dellemc-rhosp13 192.168.24.1:8787/dellemc/openstack-cinder-volume-dellemc-rhosp13 docker push 192.168.24.1:8787/dellemc/openstack-cinder-volume-dellemc-rhosp13
$ docker tag registry.connect.redhat.com/dellemc/openstack-cinder-volume-dellemc-rhosp13 192.168.24.1:8787/dellemc/openstack-cinder-volume-dellemc-rhosp13 $ docker push 192.168.24.1:8787/dellemc/openstack-cinder-volume-dellemc-rhosp13Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 매개변수가 포함된 추가 환경 파일을 사용하여 오버클라우드를 배포합니다.
parameter_defaults: DockerCinderVolumeImage: 192.168.24.1:8787/dellemc/openstack-cinder-volume-dellemc-rhosp13
parameter_defaults: DockerCinderVolumeImage: 192.168.24.1:8787/dellemc/openstack-cinder-volume-dellemc-rhosp13Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9장. 기본 네트워크 격리 링크 복사링크가 클립보드에 복사되었습니다!
이 장에서는 표준 네트워크 격리 구성을 사용하여 오버클라우드를 구성하는 방법을 보여줍니다. 여기에는 다음이 포함됩니다.
-
네트워크 격리(
/usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml)를 활성화하기 위해 렌더링된 환경 파일입니다. -
네트워크 기본값을 구성하는 복사된 환경 파일(
/usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml). -
IP 범위, 서브넷, 가상 IP 등의 네트워크 설정을 정의하는 network
_data파일. 이 예에서는 기본값의 복사본을 생성하고 자체 네트워크에 맞게 편집하는 방법을 보여줍니다. - 각 노드의 NIC 레이아웃을 정의하는 템플릿입니다. 오버클라우드 코어 템플릿 컬렉션에는 다양한 사용 사례에 대한 기본값 세트가 포함되어 있습니다.
-
NIC를 활성화하는 환경 파일입니다. 이 예에서는 environment
디렉터리에있는 기본 파일을 사용합니다. - 네트워킹 매개 변수를 사용자 지정할 추가 환경 파일입니다.
openstack overcloud netenv validate 명령을 실행하여 network-environment.yaml 파일의 구문의 유효성을 검사합니다. 또한 이 명령은 계산, 컨트롤러, 스토리지 및 구성 가능한 역할 네트워크 파일의 개별 nic-config 파일을 확인합니다. f 또는 --file 옵션을 사용하여 검증할 파일을 지정합니다.
openstack overcloud netenv validate -f ~/templates/network-environment.yaml
$ openstack overcloud netenv validate -f ~/templates/network-environment.yaml
이 장의 다음 내용은 이러한 각 측면을 정의하는 방법을 보여줍니다.
9.1. 네트워크 격리 링크 복사링크가 클립보드에 복사되었습니다!
Overcloud는 기본적으로 provisioning 네트워크에 서비스를 할당합니다. 그러나 director는 오버클라우드 네트워크 트래픽을 격리된 네트워크로 나눌 수 있습니다. 분리된 네트워크를 사용하기 위해 오버클라우드에는 이 기능을 활성화하는 환경 파일이 포함되어 있습니다. 코어 heat 템플릿의 environments/network-isolation.j2.yaml 파일은 구성 가능한 네트워크 파일에 있는 각 네트워크의 모든 포트 및 VIP를 정의하는 Jinja2 파일입니다. 렌더링되면 network-isolation.yaml 파일이 전체 리소스 레지스트리와 동일한 위치에 생성됩니다.
이 파일의 첫 번째 섹션에는 OS::TripleO::Network::* 리소스에 대한 리소스 레지스트리 선언이 있습니다. 기본적으로 이러한 리소스는 네트워크를 생성하지 않는 OS::Heat::None 리소스 유형을 사용합니다. 이러한 리소스를 각 네트워크의 YAML 파일로 리디렉션하면 이러한 네트워크를 생성할 수 있습니다.
다음 여러 섹션에서는 각 역할의 노드의 IP 주소를 생성합니다. 컨트롤러 노드에는 각 네트워크에 IP가 있습니다. 계산 및 스토리지 노드에는 각각 네트워크의 하위 집합에 IP가 있습니다.
10장. 사용자 지정 구성 가능 네트워크 및 11장. 사용자 정의 네트워크 인터페이스 템플릿 과 같은 오버클라우드 네트워킹의 기타 기능은 이 네트워크 격리 환경 파일을 사용합니다. 따라서 배포 명령을 사용하여 렌더링된 파일의 이름을 포함해야 합니다. 예를 들면 다음과 같습니다.
openstack overcloud deploy --templates \
...
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
...
$ openstack overcloud deploy --templates \
...
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
...
9.2. 격리된 네트워크 구성 수정 링크 복사링크가 클립보드에 복사되었습니다!
기본 network_data.yaml 파일을 복사하고 복사본을 수정하여 기본 격리된 네트워크를 구성합니다.
절차
기본
network_data파일을 복사합니다.cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.
$ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.Copy to Clipboard Copied! Toggle word wrap Toggle overflow network_data.yaml파일의 로컬 사본을 편집하고 네트워킹 요구 사항에 맞게 매개변수를 수정합니다. 예를 들어 내부 API 네트워크에는 다음과 같은 기본 네트워크 세부 정보가 포함되어 있습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
각 네트워크에 대해 다음을 편집합니다.
-
VLAN은 이 네트워크에 사용할 VLAN ID를 정의합니다. -
ip_subnet및ip_allocation_pools는 네트워크의 기본 서브넷 및 IP 범위를 설정합니다. -
게이트웨이는네트워크의 게이트웨이를 설정합니다. 주로 외부 네트워크의 기본 경로를 정의하는 데 사용되지만 필요한 경우 다른 네트워크에 사용할 수 있습니다.
n 옵션을 사용하여 배포와 함께 사용자 지정 network_data 파일을 포함합니다. n 옵션을 사용하지 않으면 배포 명령에서 기본 네트워크 세부 정보를 사용합니다.
9.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을 렌더링합니다.
기본 컴퓨팅 노드의 경우 스토리지, 내부 API 및 테넌트 네트워크에 대한 네트워크 정보만 렌더링합니다.
11장. 사용자 정의 네트워크 인터페이스 템플릿 기본 Jinja2 기반 템플릿을 사용자 지정의 기준으로 사용할 수 있는 표준 YAML 버전으로 렌더링하는 방법을 살펴봅니다.
9.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.
9.5. 기본 네트워크 격리 활성화 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 기본 NIC 템플릿 중 하나를 사용하여 기본 네트워크 격리를 활성화하는 방법을 보여줍니다. 이 경우 VLANs 템플릿(Single-nic-vlans)이 있는 단일NIC입니다.
절차
openstack overcloud deploy명령을 실행할 때 에 대해 렌더링된 환경 파일 이름을 포함해야 합니다.-
사용자 지정
network_data파일. - 기본 네트워크 격리의 렌더링된 파일 이름입니다.
- 렌더링된 기본 네트워크 환경 파일의 파일 이름입니다.
- 렌더링된 기본 네트워크 인터페이스 구성의 파일 이름
- 구성과 관련된 추가 환경 파일입니다.
-
사용자 지정
예를 들면 다음과 같습니다.
10장. 사용자 지정 구성 가능 네트워크 링크 복사링크가 클립보드에 복사되었습니다!
이 장에서는 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 서비스 매핑을 사용자 지정합니다.
openstack overcloud netenv validate 명령을 실행하여 network-environment.yaml 파일의 구문의 유효성을 검사합니다. 또한 이 명령은 계산, 컨트롤러, 스토리지 및 구성 가능한 역할 네트워크 파일의 개별 nic-config 파일을 확인합니다. f 또는 --file 옵션을 사용하여 검증할 파일을 지정합니다.
openstack overcloud netenv validate -f ~/templates/network-environment.yaml
$ openstack overcloud netenv validate -f ~/templates/network-environment.yaml
이 장의 다음 내용은 이러한 각 측면을 정의하는 방법을 보여줍니다.
10.1. 구성 가능 네트워크 링크 복사링크가 클립보드에 복사되었습니다!
오버클라우드는 기본적으로 다음 사전 정의된 네트워크 세그먼트 세트를 사용합니다.
- 컨트롤 플레인
- 내부 API
- 스토리지
- 스토리지 관리
- 테넌트
- 외부
- 관리 (선택 사항)
구성 가능 네트워크를 사용하면 다양한 서비스에 대한 네트워크를 추가할 수 있습니다. 예를 들어 NFS 트래픽 전용 네트워크가 있는 경우 여러 역할에 제공할 수 있습니다.
director는 배포 및 업데이트 단계에서 사용자 지정 네트워크 생성을 지원합니다. 이러한 추가 네트워크는 Ironic 베어 메탈 노드, 시스템 관리 또는 다양한 역할에 맞는 별도의 네트워크를 생성하는 데 사용할 수 있습니다. 또한 트래픽이 네트워크 간에 라우팅되는 분할 배포를 위해 여러 네트워크 세트를 생성할 수도 있습니다.
단일 데이터 파일(network_data.yaml)은 배포할 네트워크 목록을 관리합니다. 이 파일을 -n 옵션을 사용하여 배포 명령에 포함합니다. 이 옵션을 사용하지 않으면 배포 시 기본 파일(/usr/share/openstack-tripleo-heat-templates/network_data.yaml)을 사용합니다.
10.2. 구성 가능 네트워크 추가 링크 복사링크가 클립보드에 복사되었습니다!
구성 가능 네트워크를 사용하여 다양한 서비스의 네트워크를 추가합니다. 예를 들어 스토리지 백업 트래픽 전용 네트워크가 있는 경우 네트워크를 여러 역할에 제공할 수 있습니다.
절차
기본
network_data파일을 복사합니다.cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.
$ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.Copy to Clipboard Copied! Toggle word wrap Toggle overflow network_data.yaml파일의 로컬 사본을 편집하고 새 네트워크의 섹션을 추가합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
사람이 읽을 수 있는 네트워크의 이름을 설정합니다. 이 매개변수는 유일한 필수 매개변수입니다. 가독성을 위해 이름을 정규화하려면
name_lower매개변수를 사용합니다(예:InternalApi를internal_api로 변경하려는 경우).name매개 변수를 수정하지 마십시오. -
VIP: true는 새 네트워크에 가상 IP 주소(VIP)를 만듭니다. 이 IP는Service-to-network 매핑 매개 변수(Service-to-network mapping 매개변수)에 나열된 서비스의 대상 IP로 사용됩니다.VIP는 Pacemaker를 사용하는 역할에서만 사용됩니다. Overcloud의 부하 분산 서비스는 이러한 IP의 트래픽을 해당 서비스 엔드포인트로 리디렉션합니다. -
ip_subnet,allocation_pools및gateway_ip는 네트워크의 기본 IPv4 서브넷, IP 범위 및 게이트웨이를 설정합니다.
-
사람이 읽을 수 있는 네트워크의 이름을 설정합니다. 이 매개변수는 유일한 필수 매개변수입니다. 가독성을 위해 이름을 정규화하려면
n 옵션을 사용하여 배포와 함께 사용자 지정 network_data 파일을 포함합니다. n 옵션을 사용하지 않으면 배포 명령에서 기본 네트워크 집합을 사용합니다.
10.3. 역할에 구성 가능한 네트워크 포함 링크 복사링크가 클립보드에 복사되었습니다!
구성 가능 네트워크를 사용자 환경에 정의된 오버클라우드 역할에 할당할 수 있습니다. 예를 들어 Ceph Storage 노드에 사용자 지정 StorageBackup 네트워크를 포함할 수 있습니다.
절차
custon
roles_data파일이 아직 없는 경우 기본값을 홈 디렉터리에 복사합니다.cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/.
$ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
사용자 지정
roles_data파일을 편집합니다. 구성 가능 네트워크를 추가하려는 역할로 스크롤하고 네트워크 이름을 네트워크 목록에 추가합니다
.예를 들어 네트워크를 Ceph Storage 역할에 추가하려면 다음 스니펫을 가이드로 사용합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 사용자 지정 네트워크를 해당 역할에 추가한 후 파일을 저장합니다.
openstack overcloud deploy 명령을 실행할 때 -r 옵션을 사용하여 roles_data 파일을 포함합니다. r 옵션을 사용하지 않으면 배포 명령은 해당 할당된 네트워크에 기본 역할 세트를 사용합니다.
10.4. 구성 가능한 네트워크에 OpenStack 서비스 할당 링크 복사링크가 클립보드에 복사되었습니다!
각 OpenStack 서비스는 리소스 레지스트리의 기본 네트워크 유형에 할당됩니다. 이러한 서비스는 네트워크 유형의 할당된 네트워크 내의 IP 주소에 바인딩됩니다. OpenStack 서비스는 이러한 네트워크 간에 나뉩니다. 실제 실제 네트워크는 네트워크 환경 파일에 정의된 대로 다를 수 있습니다. 환경 파일에서 새 네트워크 맵(예: /home/stack/templates/service-reassignments.yaml )을 정의하여 OpenStack 서비스를 다른 네트워크 유형에 다시 할당할 수 있습니다. ServiceNetMap 매개변수는 각 서비스에 사용할 네트워크 유형을 결정합니다.
예를 들어 강조 표시된 섹션을 수정하여 스토리지 관리 네트워크 서비스를 스토리지 백업 네트워크에 다시 할당할 수 있습니다.
parameter_defaults:
ServiceNetMap:
SwiftMgmtNetwork: storage_backup
CephClusterNetwork: storage_backup
parameter_defaults:
ServiceNetMap:
SwiftMgmtNetwork: storage_backup
CephClusterNetwork: storage_backup
이러한 매개 변수를 storage_backup 으로 변경하면 스토리지 관리 네트워크가 아닌 스토리지 백업 네트워크에 이러한 서비스가 수행됩니다. 즉, 스토리지 관리 네트워크가 아니라 스토리지 백업 네트워크에 대해 parameter_defaults 세트를 정의하면 됩니다.
director는 사용자 정의 ServiceNetMap 매개변수 정의를 ServiceNetMapDefaults 에서 가져온 기본값을 미리 정의된 목록으로 병합하고 기본값을 재정의합니다. 그런 다음 director는 다양한 서비스에 대한 네트워크 할당을 구성하는 데 사용되는 사용자 지정을 포함하는 전체 목록을 반환합니다.
서비스 매핑은 Pacemaker를 사용하는 노드의 경우 network_data 파일에서 vip: true 를 사용하는 네트워크에만 적용됩니다. 오버클라우드의 로드 밸런서는 VIP의 트래픽을 특정 서비스 엔드포인트로 리디렉션합니다.
전체 기본 서비스 목록은 /usr/share/openstack-tripleo-heat-templates/network/service_net_map.j2.yaml 내의 ServiceNetMapDefaults 매개변수에서 확인할 수 있습니다.
10.5. 사용자 지정 구성 가능 네트워크 활성화 링크 복사링크가 클립보드에 복사되었습니다!
기본 NIC 템플릿 중 하나를 사용하여 사용자 지정 구성 가능한 네트워크를 활성화합니다. 이 예제에서는 VLANs 템플릿(net-single-nic-with-vlans)과 함께 Single NIC를 사용합니다.
절차
openstack overcloud deploy명령을 실행할 때 다음을 포함해야 합니다.-
사용자 지정
network_data파일. -
네트워크-역할 할당이 있는 사용자 지정
roles_data파일. - 렌더링된 기본 네트워크 격리 구성의 파일 이름입니다.
- 렌더링된 기본 네트워크 환경 파일의 파일 이름입니다.
- 렌더링된 기본 네트워크 인터페이스 구성의 파일 이름입니다.
- 서비스 재할당과 같은 네트워크 관련 추가 환경 파일.
-
사용자 지정
예를 들면 다음과 같습니다.
이렇게 하면 추가 사용자 지정 네트워크를 포함하여 오버클라우드의 노드에 구성 가능한 네트워크가 배포됩니다.
관리 네트워크와 같은 새 사용자 지정 네트워크를 도입하는 경우 템플릿을 다시 렌더링해야 합니다. roles_data.yaml 파일에 네트워크 이름을 추가하는 것만으로는 충분하지 않습니다.
10.6. 기본 네트워크 이름 변경 링크 복사링크가 클립보드에 복사되었습니다!
network_data.yaml 파일을 사용하여 기본 네트워크의 사용자가 볼 수 있는 이름을 수정할 수 있습니다.
- InternalApi
- 외부
- 스토리지
- StorageMgmt
- 테넌트
이러한 이름을 변경하려면 name 필드를 수정하지 마십시오. 대신 name_lower 필드를 네트워크의 새 이름으로 변경하고 새 이름으로 ServiceNetMap을 업데이트합니다.
절차
network_data.yaml파일에서 이름을 변경할 각 네트워크의name_lower매개변수에 새 이름을 입력합니다.- name: InternalApi name_lower: MyCustomInternalApi
- name: InternalApi name_lower: MyCustomInternalApiCopy to Clipboard Copied! Toggle word wrap Toggle overflow service_net_map매개변수의 기본값을 포함합니다._replace 매개변수에 name_lower- name: InternalApi name_lower: MyCustomInternalApi service_net_map_replace: internal_api
- name: InternalApi name_lower: MyCustomInternalApi service_net_map_replace: internal_apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11장. 사용자 정의 네트워크 인터페이스 템플릿 링크 복사링크가 클립보드에 복사되었습니다!
이 장에서는 9장. 기본 네트워크 격리 에 설명된 개념과 절차에 대해 설명합니다. 이 장의 목적은 사용자 환경의 노드에 맞게 사용자 지정 네트워크 인터페이스 템플릿 세트를 생성하는 방법을 보여줍니다. 여기에는 다음이 포함됩니다.
-
네트워크 격리를 활성화하는 환경 파일(
/usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml). -
네트워크 기본값(
/usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml)을 구성하는 환경 파일입니다. - 각 노드의 NIC 레이아웃을 정의하는 템플릿입니다. 오버클라우드 코어 템플릿 컬렉션에는 다양한 사용 사례에 대한 기본값 세트가 포함되어 있습니다. 이 경우 사용자 지정 템플릿의 기본 사항을 렌더링합니다.
-
NIC를 활성화하는 사용자 지정 환경 파일입니다. 이 예에서는 사용자 지정 인터페이스 템플릿을 참조하는 사용자 지정 환경 파일(
/home/stack/templates/custom-network-configuration.yaml)을 사용합니다. - 네트워킹 매개 변수를 사용자 지정할 추가 환경 파일입니다.
-
네트워크를 사용자 지정하는 경우 사용자 지정
network_data파일. -
추가 또는 사용자 지정 구성 가능한 네트워크를 생성하는 경우 사용자 지정
network_data파일 및 사용자 지정roles_data파일.
openstack overcloud netenv validate 명령을 실행하여 network-environment.yaml 파일의 구문의 유효성을 검사합니다. 또한 이 명령은 계산, 컨트롤러, 스토리지 및 구성 가능한 역할 네트워크 파일의 개별 nic-config 파일을 확인합니다. f 또는 --file 옵션을 사용하여 검증할 파일을 지정합니다.
openstack overcloud netenv validate -f ~/templates/network-environment.yaml
$ openstack overcloud netenv validate -f ~/templates/network-environment.yaml
11.1. 사용자 지정 네트워크 아키텍처 링크 복사링크가 클립보드에 복사되었습니다!
기본 NIC 템플릿이 특정 네트워크 구성에 적합하지 않을 수 있습니다. 예를 들어 특정 네트워크 레이아웃에 맞는 자체 사용자 지정 NIC 템플릿을 생성할 수 있습니다. 에서 제어 서비스와 데이터 서비스를 분리하여 NIC를 분리할 수 있습니다. 이 경우 다음과 같은 방식으로 서비스를 NIC 할당에 매핑할 수 있습니다.
NIC1 (프로비저닝):
- 프로비저닝/컨트롤 플레인
NIC2 (Control Group)
- 내부 API
- 스토리지 관리
- 외부(공용 API)
NIC3 (데이터 그룹)
- 테넌트 네트워크(VXLAN 터널링)
- 테넌트 VLAN/프로바이더 VLAN
- 스토리지
- 외부 VLAN (유동 IP/SNAT)
NIC4 (관리)
- 관리
11.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
$ cd /usr/share/openstack-tripleo-heat-templates $ ./tools/process-templates.py -o ~/openstack-tripleo-heat-templates-renderedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이렇게 하면 모든 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
$ ./tools/process-templates.py -o ~/openstack-tripleo-heat-templates-rendered -n /home/stack/network_data.yaml -r /home/stack/roles_data.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 여러 NIC 예제를 복사합니다.
cp -r ~/openstack-tripleo-heat-templates-rendered/network/config/multiple-nics/ ~/templates/custom-nics/
$ cp -r ~/openstack-tripleo-heat-templates-rendered/network/config/multiple-nics/ ~/templates/custom-nics/Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
custom-nics에 설정된 템플릿을 편집하여 자체 네트워크 구성에 맞게 편집할 수 있습니다.
11.3. 네트워크 인터페이스 아키텍처 링크 복사링크가 클립보드에 복사되었습니다!
11.2절. “사용자 정의를 위한 기본 네트워크 인터페이스 템플릿 렌더링” 에서 렌더링하는 사용자 정의 NIC 템플릿에는 매개변수 및 리소스 섹션이 포함되어 있습니다.
매개 변수
parameters 섹션에는 네트워크 인터페이스에 대한 모든 네트워크 구성 매개 변수가 포함되어 있습니다. 여기에는 서브넷 범위 및 VLAN ID와 같은 정보가 포함됩니다. Heat 템플릿이 상위 템플릿에서 값을 상속하므로 이 섹션은 변경되지 않은 상태로 유지됩니다. 그러나 네트워크 환경 파일을 사용하여 일부 매개변수의 값을 수정할 수 있습니다.
Resources
resources 섹션은 기본 네트워크 인터페이스 구성이 발생하는 위치입니다. 대부분의 경우 resources 섹션은 편집이 필요한 유일한 섹션입니다. 각 resources 섹션은 다음 헤더로 시작합니다.
이렇게 하면 노드에서 네트워크 속성을 구성하는 데 사용할 os )가 실행됩니다. -net-config의 구성 파일을 생성하는 스크립트(run-os-net-config.shnetwork_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 에 있습니다.
11.4. 네트워크 인터페이스 참조 링크 복사링크가 클립보드에 복사되었습니다!
네트워크 인터페이스 구성에는 다음 매개변수가 포함됩니다.
인터페이스
단일 네트워크 인터페이스를 정의합니다. 구성은 실제 인터페이스 이름("eth0", "eth1", "enp0s25") 또는 번호가 매겨진 인터페이스 집합("nic1", "nic2", "nic3")을 사용하여 각 인터페이스를 정의합니다.
예를 들면 다음과 같습니다.
- type: interface
name: nic2
- type: interface
name: nic2
| 옵션 | 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}
- type: vlan
vlan_id:{get_param: ExternalNetworkVlanID}
addresses:
- ip_netmask: {get_param: ExternalIpSubnet}
| 옵션 | 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의 본딩을 정의합니다. 이는 이중화 및 대역폭 증가에 도움이 됩니다.
예를 들면 다음과 같습니다.
| 옵션 | 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 값을 유지합니다.
예를 들면 다음과 같습니다.
OVS 브리지는 구성 데이터를 가져오기 위해 Neutron 서버에 연결합니다. OpenStack 제어 트래픽(일반적으로 컨트롤 플레인 및 내부 API 네트워크)이 OVS 브리지에 배치되면 OVS가 업그레이드되거나 관리자 또는 프로세스에서 OVS 브리지를 다시 시작할 때마다 Neutron 서버에 대한 연결이 손실됩니다. 이로 인해 일부 다운타임이 발생합니다. 이러한 상황에서 다운타임을 허용하지 않는 경우, 제어 그룹 네트워크를 OVS 브리지가 아닌 별도의 인터페이스 또는 본딩에 배치해야 합니다.
- 프로비저닝 인터페이스의 VLAN에 내부 API 네트워크를 배치하고 두 번째 인터페이스의 OVS 브리지에 내부 API 네트워크를 배치하면 최소 설정을 달성할 수 있습니다.
- 본딩을 사용하려면 2개 이상의 본딩(4개의 네트워크 인터페이스)이 필요합니다. 제어 그룹은 Linux 본딩(Linux 브리지)에 배치되어야 합니다. 스위치에서 PXE 부팅을 위한 단일 인터페이스로 LACP 폴백을 지원하지 않는 경우 이 솔루션에는 최소 5개의 NIC가 필요합니다.
| 옵션 | 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 매개 변수에 커널 기반 본딩 옵션을 포함시켜야 합니다. Linux 본딩 옵션에 대한 자세한 내용은 7.7.1을 참조하십시오. Red Hat Enterprise Linux 7 네트워킹 가이드의 본딩 모듈 지시문
예를 들면 다음과 같습니다.
nic2 에서는 primary: true 를 사용합니다. 이렇게 하면 본딩에서 nic2 의 MAC 주소를 사용합니다.
| 옵션 | Default | 설명 |
|---|---|---|
| name | 본딩 이름 | |
| use_dhcp | False | DHCP를 사용하여 IP 주소 가져오기 |
| use_dhcpv6 | False | DHCP를 사용하여 v6 IP 주소 가져오기 |
| 주소 | 본딩에 할당된 IP 주소 목록 | |
| routes | 본딩에 할당된 경로 목록입니다. routes을 참조하십시오. | |
| mtu | 1500 | 연결의 최대 전송 단위 (MTU) |
| 주 | False | 인터페이스를 기본 인터페이스로 정의합니다. |
| 멤버 | 본딩에서 사용할 인터페이스 오브젝트 시퀀스 | |
| bonding_options | 본딩 생성 시 옵션 집합입니다. Linux 본딩 옵션에 대한 자세한 내용은 7.7.1을 참조하십시오. Red Hat Enterprise Linux 7 네트워킹 가이드의 본딩 모듈 지시문 | |
| defroute | True |
DHCP 서비스에서 제공하는 기본 경로를 사용합니다. |
| persist_mapping | False | 시스템 이름이 아닌 장치 별칭 구성 쓰기 |
| dhclient_args | 없음 | DHCP 클라이언트로 전달할 인수 |
| dns_servers | 없음 | 본딩에 사용할 DNS 서버 목록 |
linux_bridge
여러 인터페이스,linux_bond 및 vlan 오브젝트를 함께 연결하는 Linux 브리지를 정의합니다. 외부 브리지는 매개 변수에 두 개의 특수 값도 사용합니다.
-
bridge_name- 외부 브리지 이름으로 바뀝니다. -
interface_name- 외부 인터페이스로 바뀝니다.
예를 들면 다음과 같습니다.
| 옵션 | 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, 브리지 또는 본딩에 적용할 경로 목록을 정의합니다.
예를 들면 다음과 같습니다.
| 옵션 | Default | 설명 |
|---|---|---|
| ip_netmask | 없음 | 대상 네트워크의 IP 및 넷마스크. |
| default | False |
이 경로를 기본 경로로 설정합니다. |
| next_hop | 없음 | 대상 네트워크에 연결하는 데 사용되는 라우터의 IP 주소입니다. |
11.5. 네트워크 인터페이스 레이아웃 예 링크 복사링크가 클립보드에 복사되었습니다!
컨트롤러 노드 NIC 템플릿 예제의 다음 코드 조각은 OVS 브리지와 별도로 제어 그룹을 유지하도록 사용자 지정 네트워크 시나리오를 구성하는 방법을 보여줍니다.
이 템플릿은 4개의 네트워크 인터페이스를 사용하고 번호가 매겨진 인터페이스인 nic1을 nic 4 에 할당합니다. nic3 에서 스토리지 및 테넌트 네트워크를 호스팅하는 OVS 브리지를 만듭니다. 결과적으로 다음과 같은 레이아웃이 생성됩니다.
NIC1 (프로비저닝):
- 프로비저닝/컨트롤 플레인
NIC2 (Control Group)
- 내부 API
- 스토리지 관리
- 외부(공용 API)
NIC3 (데이터 그룹)
- 테넌트 네트워크(VXLAN 터널링)
- 테넌트 VLAN/프로바이더 VLAN
- 스토리지
- 외부 VLAN (유동 IP/SNAT)
NIC4 (관리)
- 관리
11.6. 사용자 지정 네트워크의 네트워크 인터페이스 템플릿 고려 사항 링크 복사링크가 클립보드에 복사되었습니다!
구성 가능 네트워크를 사용하는 경우 process-templates.py 스크립트는 정적 템플릿을 렌더링하여 network_data.yaml 및 roles _data. 포함합니다. 렌더링된 NIC 템플릿에 다음 항목이 포함되어 있는지 확인합니다.
yaml 파일에 정의된 네트워크 및 역할을
- 사용자 지정 구성 가능 네트워크를 포함하여 각 역할에 대한 정적 파일입니다.
- 각 역할에 대한 각 정적 파일에는 올바른 네트워크 정의가 포함되어 있습니다.
각 정적 파일에는 네트워크를 역할에 사용하지 않아도 사용자 지정 네트워크의 모든 매개 변수 정의가 필요합니다. 렌더링된 템플릿에 이러한 매개 변수가 포함되어 있는지 확인합니다. 예를 들어 StorageBackup 네트워크가 Ceph 노드에만 추가되면 모든 역할에 대한 NIC 구성 템플릿의 parameters 섹션에 이 정의도 포함되어야 합니다.
필요한 경우 VLAN ID 및/또는 게이트웨이 IP에 대한 매개변수 정의를 포함할 수도 있습니다.
사용자 지정 네트워크의 IpSubnet 매개변수는 각 역할의 매개 변수 정의에 표시됩니다. 그러나 Ceph 역할이 StorageBackup 네트워크를 사용하는 유일한 역할일 수 있으므로 Ceph 역할의 NIC 구성 템플릿만 템플릿의 network_config 섹션에 있는 StorageBackup 매개 변수를 사용합니다.
11.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
resource_registry:
OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/custom-nics/controller.yaml
parameter_defaults 섹션에는 각 네트워크 유형에 대한 네트워크 옵션을 정의하는 매개 변수 목록이 포함되어 있습니다.
11.8. 네트워크 환경 매개변수 링크 복사링크가 클립보드에 복사되었습니다!
다음 표는 네트워크 환경 파일의 parameter_defaults 섹션에서 NIC 템플릿의 기본 매개변수 값을 재정의하는 데 사용할 수 있는 매개변수 목록입니다.
| 매개변수 | 설명 | 유형 |
|---|---|---|
|
| 기본적으로 컨트롤러 노드 이외의 역할에 대한 기본 경로로 사용되는 컨트롤 플레인의 라우터 IP 주소입니다. 라우터 대신 IP masquerade를 사용하는 경우 Undercloud 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 플러그인에 구성할 플랫 네트워크를 정의합니다. 외부 네트워크 생성을 허용하려면 기본값은 "datacentre"입니다. 예를 들면 다음과 같습니다. | string |
|
|
사용할 논리적 브릿지와 물리적 브리지 매핑. 기본적으로 호스트( | string |
|
|
네트워크 격리를 사용하지 않는 경우 네트워크 노드의 | string |
|
|
t: OpenStack Networking(neutron)의 테넌트 네트워크 유형. 여러 값을 지정하려면 쉼표로 구분된 목록을 사용합니다. 지정된 첫 번째 유형은 사용 가능한 모든 네트워크가 모두 사용될 때까지 사용되고 다음 유형이 사용됩니다. 예를 들면 다음과 같습니다. | string |
|
| neutron 테넌트 네트워크의 터널 유형입니다. 여러 값을 지정하려면 쉼표로 구분된 문자열을 사용합니다. 예를 들면 다음과 같습니다. NeutronTunnelTypes: 'gre,vxlan' | 문자열 / 쉼표로 구분된 목록 |
|
|
테넌트 네트워크 할당에 사용할 수 있는 GRE 터널 ID 범위입니다. 예를 들면 다음과 같습니다. | string |
|
|
테넌트 네트워크 할당에 사용할 수 있는 VXLAN VNI ID 범위입니다. 예를 들면 다음과 같습니다. | string |
|
| 터널링된 모든 네트워크를 활성화 또는 완전히 비활성화할지 여부를 정의합니다. 튜닝된 네트워크를 생성하지 않으려면 이 기능을 활성화하십시오. 기본값은 enabled입니다. | 부울 |
|
|
지원할 ML2 및 Open vSwitch VLAN 매핑 범위. 기본값은 | string |
|
|
neutron 테넌트 네트워크의 메커니즘 드라이버입니다. 기본값은 "openvswitch"입니다. 여러 값을 지정하려면 쉼표로 구분된 문자열을 사용합니다. 예를 들면 다음과 같습니다. | 문자열 / 쉼표로 구분된 목록 |
11.9. 사용자 지정 네트워크 환경 파일 예 링크 복사링크가 클립보드에 복사되었습니다!
다음 코드 조각은 NIC 템플릿을 활성화하고 사용자 정의 매개변수를 설정하는 데 사용할 수 있는 환경 파일의 예입니다.
11.10. 사용자 정의 NIC를 통한 네트워크 격리 활성화 링크 복사링크가 클립보드에 복사되었습니다!
네트워크 분리 및 사용자 지정 NIC 템플릿을 사용하여 Overcloud를 배포하려면 오버클라우드 배포 명령의 모든 관련 네트워킹 환경 파일을 포함합니다.
절차
openstack overcloud deploy명령을 실행할 때 다음을 포함해야 합니다.-
사용자 지정
network_data파일. - 기본 네트워크 격리의 렌더링된 파일 이름입니다.
- 렌더링된 기본 네트워크 환경 파일의 파일 이름입니다.
- 사용자 지정 NIC 템플릿에 대한 리소스 참조가 포함된 사용자 지정 환경 네트워크 구성입니다.
- 구성과 관련된 추가 환경 파일입니다.
-
사용자 지정
예를 들면 다음과 같습니다.
-
먼저
network-isolation.yaml파일을 포함하고network-environment.yaml파일을 포함합니다. 후속custom-network-configuration.yaml은 이전 두 파일의OS::TripleO::[ROLE]::Net::SoftwareConfig리소스를 덮어씁니다. -
구성 가능한 네트워크를 사용하는 경우 이 명령으로
network_data및roles_data파일을 포함합니다.
12장. 추가 네트워크 구성 링크 복사링크가 클립보드에 복사되었습니다!
이 장에서는 11장. 사용자 정의 네트워크 인터페이스 템플릿 에 설명된 개념 및 절차에서 설명하고 오버클라우드 네트워크의 일부를 구성하는 데 도움이 되는 몇 가지 추가 정보를 제공합니다.
12.1. 사용자 정의 인터페이스 구성 링크 복사링크가 클립보드에 복사되었습니다!
개별 인터페이스에는 수정이 필요할 수 있습니다. 다음 예제에서는 두 번째 NIC를 사용하여 DHCP 주소가 있는 인프라 네트워크에 연결하고 본딩에 세 번째 및 네 번째 NIC를 사용하는 데 필요한 수정 사항을 보여줍니다.
네트워크 인터페이스 템플릿에서는 실제 인터페이스 이름(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, eth1 등과 같은 ethX -
enoX인터페이스(예:eno0,eno1) 등. 일반적으로 온보드 인터페이스입니다. -
enX인터페이스, enp3s0, enp3s1,, 등과 같은 영숫자로 정렬됩니다. 일반적으로 애드온 인터페이스입니다.ens3
번호가 매겨진 NIC 스키마는 스위치에 연결된 케이블이 있는 경우 라이브 인터페이스(예:)만 고려합니다. 인터페이스가 4개이고 인터페이스가 6개인 일부 호스트가 있는 경우 nic1을 nic 4 에 사용하고 각 호스트에 4개의 케이블만 연결해야 합니다.
물리적 인터페이스를 특정 별칭으로 하드 코딩할 수 있습니다. 이를 통해 nic1 또는 nic 2 등으로 매핑될 물리적 NIC를 미리 결정할 수 있습니다. MAC 주소를 지정된 별칭에 매핑할 수도 있습니다.
일반적으로 os-net-config 는 UP 상태로 이미 연결된 인터페이스만 등록합니다. 그러나 사용자 지정 매핑 파일을 사용하여 인터페이스를 하드 코딩하는 경우 DOWN 상태인 경우에도 인터페이스가 등록됩니다.
인터페이스는 환경 파일을 사용하여 별칭에 매핑됩니다. 이 예에서 각 노드에는 nic1 및 nic 2 에 대한 사전 정의된 항목이 있습니다.
NetConfigDataLookup 구성을 사용하려면 NodeUserData 리소스 레지스트리에 os-net-config-mappings.yaml 파일도 포함해야 합니다.
그런 다음 결과 구성이 os-net-config 에 의해 적용됩니다. 각 노드에서 /etc/os-net-config/mapping.yaml 파일의 interface_mapping 섹션에서 적용된 구성을 확인할 수 있습니다.
12.2. 경로 및 기본 경로 구성 링크 복사링크가 클립보드에 복사되었습니다!
두 가지 방법 중 하나로 호스트의 기본 경로를 설정할 수 있습니다. 인터페이스에서 DHCP를 사용하고 DHCP 서버에서 게이트웨이 주소를 제공하는 경우 시스템은 해당 게이트웨이의 기본 경로를 사용합니다. 그렇지 않으면 정적 IP를 사용하여 인터페이스에서 기본 경로를 설정할 수 있습니다.
Linux 커널은 여러 기본 게이트웨이를 지원하지만 가장 낮은 메트릭이 있는 게이트웨이만 사용합니다. DHCP 인터페이스가 여러 개인 경우 예측할 수 없는 기본 게이트웨이가 발생할 수 있습니다. 이 경우 기본 경로를 사용하는 인터페이스 이외의 인터페이스에 대해 defroute: false 를 설정하는 것이 좋습니다.
예를 들어 DHCP 인터페이스(nic3)를 기본 경로로지정할 수 있습니다. 다음 YAML을 사용하여 다른 DHCP 인터페이스(nic2)에서 기본 경로를 비활성화합니다.
defroute 매개 변수는 DHCP를 통해 얻은 경로에만 적용됩니다.
고정 IP가 있는 인터페이스에서 고정 경로를 설정하려면 서브넷의 경로를 지정합니다. 예를 들어 내부 API 네트워크의 172.17.0.1의 게이트웨이를 통해 10.1.2.0/24 서브넷으로 경로를 설정할 수 있습니다.
12.3. 점보 프레임 구성 링크 복사링크가 클립보드에 복사되었습니다!
MTU(최대 전송 단위) 설정은 단일 이더넷 프레임으로 전송되는 최대 데이터 양을 결정합니다. 더 큰 값을 사용하면 각 프레임이 헤더 형태로 데이터가 추가되기 때문에 오버헤드가 줄어듭니다. 기본값은 1500이며 더 높은 값을 사용하려면 점보 프레임을 지원하도록 스위치 포트를 구성해야 합니다. 대부분의 스위치는 9000 MTU를 지원하지만, 기본적으로 1500용으로 구성되어 있습니다.
VLAN의 MTU는 실제 인터페이스의 MTU를 초과할 수 없습니다. 본딩 및/또는 인터페이스에 MTU 값을 포함해야 합니다.
스토리지, 스토리지 관리, 내부 API 및 테넌트 네트워크는 모두 점보 프레임의 이점을 제공합니다. 테스트에서 프로젝트의 네트워킹 처리량은 VXLAN 터널과 함께 점보 프레임을 사용할 때 상당히 개선되었습니다.
프로비저닝 인터페이스, 외부 인터페이스 및 유동 IP 인터페이스는 1500의 기본 MTU에 두는 것이 좋습니다. 그렇지 않으면 연결 문제가 발생할 수 있습니다. 라우터는 일반적으로 계층 3 경계 간에 점보 프레임을 전달할 수 없기 때문입니다.
12.4. 트렁크된 인터페이스에서 기본 VLAN 구성 링크 복사링크가 클립보드에 복사되었습니다!
트렁크된 인터페이스 또는 본딩에 기본 VLAN에 네트워크가 있는 경우 IP 주소가 브리지에 직접 할당되고 VLAN 인터페이스가 없습니다.
예를 들어 외부 네트워크가 기본 VLAN에 있는 경우 본딩된 구성은 다음과 같습니다.
주소(및 라우팅) 문을 브리지로 이동할 때 브리지에서 해당 VLAN 인터페이스를 제거합니다. 적용 가능한 모든 역할을 변경합니다. 외부 네트워크는 컨트롤러에만 있으므로 컨트롤러 템플릿만 변경해야 합니다. 반면 스토리지 네트워크는 모든 역할에 연결되어 있으므로 스토리지 네트워크가 기본 VLAN에 있으면 모든 역할을 수정해야 합니다.
12.5. netfilter가 추적하는 최대 연결 수 증가 링크 복사링크가 클립보드에 복사되었습니다!
RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스(neutron)는 netfilter 연결 추적을 사용하여 상태 저장 방화벽을 빌드하고 가상 네트워크에서 NAT(네트워크 주소 변환)를 제공합니다. 커널 공간이 최대 연결 제한에 도달하도록 할 수 있는 상황이 있으며 nf_conntrack: 테이블 전체와 같은 오류가 발생하여 패킷을 삭제할 수 있습니다. 연결 추적(conntrack)의 제한을 늘리고 이러한 유형의 오류를 방지할 수 있습니다. RHOSP 배포에서 하나 이상의 역할 또는 모든 노드에서 conntrack 제한을 늘릴 수 있습니다.
사전 요구 사항
- 성공적인 RHOSP 언더클라우드 설치
절차
-
언더클라우드 호스트에
stack사용자로 로그인합니다. 언더클라우드 인증 정보 파일을 소싱합니다.
source ~/stackrc
$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 사용자 지정 YAML 환경 파일을 생성합니다.
예제
vi /home/stack/templates/my-environment.yaml
$ vi /home/stack/templates/my-environment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 환경 파일에는 키워드
parameter_defaults및ExtraSysctl509 가 포함되어야 합니다. netfilter가 변수net.nf_conntrack_max에서 추적할 수 있는 최대 연결 수의 새 값을 입력합니다.예제
이 예제에서는 RHOSP 배포의 모든 호스트에 conntrack 제한을 설정할 수 있습니다.
parameter_defaults: ExtraSysctlSettings: net.nf_conntrack_max: value: 500000parameter_defaults: ExtraSysctlSettings: net.nf_conntrack_max: value: 500000Copy to Clipboard Copied! Toggle word wrap Toggle overflow <role>Parameter매개변수를 사용하여 특정 역할에 대한 conntrack 제한을 설정합니다.parameter_defaults: <role>Parameters: ExtraSysctlSettings: net.nf_conntrack_max: value: <simultaneous_connections>parameter_defaults: <role>Parameters: ExtraSysctlSettings: net.nf_conntrack_max: value: <simultaneous_connections>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <role>을 역할 이름으로 바꿉니다.예를 들어
컨트롤러 매개 변수를 사용하여 컨트롤러역할에 대한 conntrack 제한을 설정하거나ComputeParameters를 사용하여 Compute 역할의 conntrack 제한을 설정합니다.<simultaneous_connections>를 허용하려는 동시 연결 수로 바꿉니다.예제
이 예제에서는 RHOSP 배포의 Controller 역할에 대해서만 conntrack 제한을 설정할 수 있습니다.
parameter_defaults: ControllerParameters: ExtraSysctlSettings: net.nf_conntrack_max: value: 500000parameter_defaults: ControllerParameters: ExtraSysctlSettings: net.nf_conntrack_max: value: 500000Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고net.nf_conntrack_max의 기본값은500000연결입니다. 최대값은 다음과 같습니다.4294967295.
배포 명령을 실행하고 핵심 heat 템플릿, 환경 파일 및 이 새 사용자 지정 환경 파일을 포함합니다.
중요후속 환경 파일에 정의된 매개변수 및 리소스가 우선하므로 환경 파일의 순서가 중요합니다.
예제
openstack overcloud deploy --templates \ -e /home/stack/templates/my-environment.yaml
$ openstack overcloud deploy --templates \ -e /home/stack/templates/my-environment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
13장. 네트워크 인터페이스 연결 링크 복사링크가 클립보드에 복사되었습니다!
이 장에서는 사용자 지정 네트워크 구성에 사용할 수 있는 몇 가지 본딩 옵션을 정의합니다.
13.1. LACP(Network Interface Bonding and Link Aggregation Control Protocol) 링크 복사링크가 클립보드에 복사되었습니다!
여러 물리적 NIC를 함께 번들하여 본딩이라는 단일 논리 채널을 구성할 수 있습니다. 고가용성 시스템의 중복성 또는 처리량이 증가하도록 본딩을 구성할 수 있습니다.
결합된 인터페이스에서 SR-IOV(단일 루트 I/O 가상화) 사용은 지원되지 않습니다.
Red Hat OpenStack Platform은 Linux 본딩, OVS(Open vSwitch) 커널 본딩 및 OVS-DPDK 본딩을 지원합니다.
본딩은 선택적 LACP(링크 집계 제어 프로토콜)와 함께 사용할 수 있습니다. LACP는 부하 분산 및 내결함성을 위한 동적 본딩을 생성하는 협상 프로토콜입니다.
Red Hat은 OvS 커널 본딩(bond type: ovs_bond)을 OvS 커널 본딩에 사용하는 것이 좋습니다. 사용자 모드 본딩(결합 유형: ovs_dpdk_bond)은 커널 모드 브리지(type: ovs_user_bridge)와 달리 사용자 모드 브리지(type: ovs_user_bridge)와 함께 사용해야 합니다. 그러나 동일한 노드에서 ovs_bridge 및 ovs_user_bridge를 결합하지 마십시오.
제어 및 스토리지 네트워크에서는 OVS 또는 neutron 에이전트가 업데이트, 핫픽스 및 기타 이벤트를 위해 OVS 또는 neutron 에이전트를 다시 시작할 때 발생할 수 있는 컨트롤 플레인 중단 가능성이 있으므로 Red Hat은 VLAN 및 LACP와 Linux 본딩을 사용할 것을 권장합니다. Linux 본딩/LACP/VLAN 구성은 OVS 중단 가능성 없이 NIC 관리를 제공합니다.
다음은 하나의 VLAN을 사용한 Linux 본딩 구성의 예입니다.
다음 예는 OVS 브리지에 연결된 Linux 본딩을 보여줍니다.
다음 예는 OVS 사용자 공간 브리지를 보여줍니다.
13.2. Open vSwitch 본딩 옵션 링크 복사링크가 클립보드에 복사되었습니다!
Overcloud는 OVS(Open vSwitch)를 통해 네트워킹을 제공합니다. 다음 표를 사용하여 결합된 인터페이스의 OVS 커널 및 OVS-DPDK에 대한 지원 호환성을 파악합니다. OVS/OVS-DPDK balance-tcp 모드는 기술 프리뷰로만 사용할 수 있습니다.
이 지원에는 Open vSwitch 2.9 이상이 필요합니다.
| OVS 본드 모드 | 애플리케이션 | 참고 | 호환되는 LACP 옵션 |
| active-backup | 고가용성(active-passive) | 활성, 수동 또는 꺼짐 | |
| balance-slb | 처리량 증가 (활성-활성) |
| 활성, 수동 또는 꺼짐 |
| balance-tcp (기술 프리뷰만 해당) | 권장되지 않음 (활성-활성) |
| 활성 또는 패시브 |
다음 예와 같이 BondInterfaceOvsOptions 매개변수를 사용하여 네트워크 환경 파일에서 본딩된 인터페이스를 구성할 수 있습니다.
parameter_defaults: BondInterfaceOvsOptions: "bond_mode=balance-slb"
parameter_defaults:
BondInterfaceOvsOptions: "bond_mode=balance-slb"
13.3. Linux 본딩 옵션 링크 복사링크가 클립보드에 복사되었습니다!
네트워크 인터페이스 템플릿에서 Linux 본딩과 함께 LACP를 사용할 수 있습니다.
-
모드- LACP 활성화. -
lacp_rate- LACP 패킷이 1초 또는 30초마다 전송되는지 여부를 정의합니다. -
updelay- 트래픽에 사용하기 전에 인터페이스를 활성화해야 하는 최소 시간을 정의합니다(이로 인해 포트가 중단을 줄이는 데 도움이 됩니다). -
miimon- 드라이버의 MIIMON 기능을 사용하여 포트 상태를 모니터링하는 데 사용되는 간격(밀리초)입니다.
Linux 본딩 옵션에 대한 자세한 내용은 7.7.1을 참조하십시오. Red Hat Enterprise Linux 7 네트워킹 가이드 의 본딩 모듈 지시문
13.4. OVS 본딩 옵션 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에서는 이러한 옵션과 하드웨어에 따라 몇 가지 대안을 설명합니다.
|
|
트래픽 패턴이 변경될 때 주기적으로 리밸런싱을 통해 소스 MAC 주소와 출력 VLAN을 기반으로 밸런싱을 조정합니다. |
|
| 이 모드에서는 활성 연결이 실패하면 대기 NIC가 네트워크 작업을 다시 시작하는 활성/대기 페일오버를 제공합니다. 실제 스위치에는 하나의 MAC 주소만 표시됩니다. 이 모드에서는 특별한 스위치 지원이나 구성이 필요하지 않으며 링크가 별도의 스위치에 연결될 때 작동합니다. 이 모드에서는 로드 밸런싱을 제공하지 않습니다. |
|
|
LACP(링크 집계 제어 프로토콜) 동작을 제어합니다. 특정 스위치만 LACP를 지원합니다. 스위치가 LACP를 지원하지 않는 경우 |
|
| 대체로 bond_mode=active-backup으로 전환하도록 LACP 동작을 설정합니다. |
|
| LACP 하트비트를 1초(빠른) 또는 30초(slow)로 설정합니다. 기본값은 느립니다. |
|
| miimon heartbeats(miimon) 또는 모니터 캐리어(carrier)를 사용하도록 링크 탐지를 설정합니다. 기본값은 캐리어입니다. |
|
| miimon을 사용하는 경우 하트비트 간격(밀리초)을 설정합니다. |
|
| 플랩을 방지하려면 링크를 활성화해야 합니다. |
|
| 본딩 멤버 간 리밸런싱 간격(밀리초)입니다. 본딩 멤버 간의 리밸런싱 흐름을 비활성화하려면 이 값을 0으로 설정합니다. |
14장. 노드 배치 제어 링크 복사링크가 클립보드에 복사되었습니다!
director의 기본 동작은 일반적으로 프로필 태그를 기반으로 각 역할에 대해 노드를 임의로 선택하는 것입니다. 그러나 director는 특정 노드 배치를 정의하는 기능을 제공합니다. 이는 다음을 수행하는 유용한 방법입니다.
-
controller-0, controller-1등 특정 노드 ID 할당 - 사용자 정의 호스트 이름 할당
- 특정 IP 주소 할당
- 특정 가상 IP 주소 할당
네트워크에 예측 가능한 IP 주소, 가상 IP 주소 및 포트를 수동으로 설정하면 풀 할당의 필요성이 줄어듭니다. 그러나 새 노드를 쉽게 확장할 수 있도록 각 네트워크에 대한 할당 풀을 유지하는 것이 좋습니다. 정적으로 정의된 모든 IP 주소가 할당 풀 외부에 속하는지 확인합니다. 할당 풀 설정에 대한 자세한 내용은 11.7절. “사용자 지정 네트워크 환경 파일” 을 참조하십시오.
14.1. 특정 노드 ID 할당 링크 복사링크가 클립보드에 복사되었습니다!
이 절차에서는 특정 노드에 노드 ID를 할당합니다. 노드 ID의 예로는 controller-0,controller,-1, compute -0compute-1 등이 있습니다.
첫 번째 단계는 계산 스케줄러가 배포에 일치하는 노드별 기능으로 ID를 할당하는 것입니다. 예를 들면 다음과 같습니다.
openstack baremetal node set --property capabilities='node:controller-0,boot_option:local' <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%'
parameter_defaults:
ControllerSchedulerHints:
'capabilities:node': 'controller-%index%'
이러한 스케줄러 힌트를 사용하려면 Overcloud 생성 중에 overcloud deploy 명령에 ' scheduler_hints_env.yaml' 환경 파일을 포함합니다.
다음 매개 변수를 통해 각 역할에 대해 동일한 접근 방식을 사용할 수 있습니다.
-
컨트롤러 노드의 ControllerSchedulerHints입니다. -
컴퓨팅 노드의
ComputeSchedulerHints입니다. -
블록 스토리지 노드의
BlockStorageSchedulerHints입니다. -
오브젝트 스토리지 노드의
ObjectStorageSchedulerHints입니다. -
Ceph Storage 노드의 CephStorageSchedulerHints. -
[ROLE] 사용자 정의 역할을 위한 스케줄 힌트입니다.[ROLE]을 역할 이름으로 바꿉니다.
노드 배치는 프로필 일치보다 우선합니다. 스케줄링 실패를 방지하려면 프로필 일치(컴퓨팅, 제어 등)용으로 설계된 플레이버가 아닌 배포에 기본 baremetal 플레이버를 사용합니다. 예를 들면 다음과 같습니다.
openstack overcloud deploy ... --control-flavor baremetal --compute-flavor baremetal ...
$ openstack overcloud deploy ... --control-flavor baremetal --compute-flavor baremetal ...
14.2. 사용자 지정 호스트 이름 할당 링크 복사링크가 클립보드에 복사되었습니다!
14.1절. “특정 노드 ID 할당” 의 노드 ID 설정과 함께 director는 각 노드에 특정 사용자 지정 호스트 이름을 할당할 수도 있습니다. 이 기능은 시스템이 있는 위치(예: rack2-row12)를 정의해야 하거나 인벤토리식별자 또는 사용자 지정 호스트 이름이 필요한 기타 상황을 정의해야 하는 경우에 유용합니다.
노드 이름을 배포한 후에는 이름을 바꾸지 마십시오. 배포 후 노드 이름을 변경하면 인스턴스 관리 문제가 발생합니다.
노드 호스트 이름을 사용자 지정하려면 14.1절. “특정 노드 ID 할당” 의 ' scheduler_hints_env.yaml' 파일과 같은 환경 파일에서 HostnameMap 매개변수를 사용합니다. 예를 들면 다음과 같습니다.
parameter_defaults 섹션에 HostnameMap 을 정의하고 각 매핑을 HostnameFormat 매개 변수(예: overcloud-controller-0)를 사용하여 정의하는 원래 호스트 이름으로 설정하고 두 번째값은 해당 노드에 대해 원하는 사용자 지정 호스트 이름(예: overcloud-controller-prod-123-0)입니다.
노드 ID 배치와 함께 이 방법을 사용하면 각 노드에 사용자 지정 호스트 이름이 있습니다.
14.3. 예측 가능한 IP 할당 링크 복사링크가 클립보드에 복사되었습니다!
결과 환경을 추가로 제어하기 위해 director는 각 네트워크에서 특정 IP를 사용하여 Overcloud 노드를 할당할 수 있습니다. 코어 Heat 템플릿 컬렉션에서 environments/ips-from-pool-all.yaml 환경 파일을 사용합니다.
이 파일을 stack 사용자의 templates 디렉터리에 복사합니다.
cp /usr/share/openstack-tripleo-heat-templates/environments/ips-from-pool-all.yaml ~/templates/.
$ cp /usr/share/openstack-tripleo-heat-templates/environments/ips-from-pool-all.yaml ~/templates/.
ips-from-pool-all.yaml 파일에는 두 개의 주요 섹션이 있습니다.
첫 번째는 기본값을 재정의하는 resource_registry 참조 집합입니다. 이를 통해 director에 노드 유형의 지정된 포트에 특정 IP를 사용하도록 지시합니다. 각 리소스를 수정하여 해당 템플릿의 절대 경로를 사용합니다. 예를 들면 다음과 같습니다.
OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external_from_pool.yaml OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api_from_pool.yaml OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_from_pool.yaml OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt_from_pool.yaml OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant_from_pool.yaml
OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external_from_pool.yaml
OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api_from_pool.yaml
OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_from_pool.yaml
OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt_from_pool.yaml
OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant_from_pool.yaml
기본 구성은 사전 할당된 IP를 사용하도록 모든 노드 유형의 모든 네트워크를 설정합니다. 특정 네트워크 또는 노드 유형이 기본 IP 할당을 대신 사용하도록 허용하려면 환경 파일에서 해당 노드 유형 또는 네트워크와 관련된 resource_registry 항목을 제거하면 됩니다.
두 번째 섹션은 실제 IP 주소가 할당되는 parameter_defaults입니다. 각 노드 유형에는 연결된 매개변수가 있습니다.
-
컨트롤러 노드의 ControllerIP. -
컴퓨팅 노드
의 ComputeIP. -
Ceph Storage 노드의 CephStorageIP. -
블록 스토리지 노드
의 BlockStorageIP. -
오브젝트 스토리지 노드의
SwiftStorageIPs. -
[ROLE]사용자 정의 역할을 위한IP입니다.[ROLE]을 역할 이름으로 바꿉니다.
각 매개 변수는 네트워크 이름에서 주소 목록에 대한 맵입니다. 각 네트워크 유형에는 해당 네트워크에 노드가 있을 만큼의 주소가 있어야 합니다. director에서 주소를 순서대로 할당합니다. 각 유형의 첫 번째 노드는 각 목록에서 첫 번째 주소를 수신하고 두 번째 노드는 각 목록에서 두 번째 주소를 수신합니다.
예를 들어 오버클라우드에 세 개의 Ceph Storage 노드가 포함된 경우 CephStorageIPs 매개변수는 다음과 같을 수 있습니다.
첫 번째 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 주소가 네트워크 환경 파일에 정의된 각 네트워크의 할당 풀 외부에 속하는지 확인합니다( 11.7절. “사용자 지정 네트워크 환경 파일”참조). 예를 들어 internal_api 할당이 InternalApiAllocationPools 범위 밖에 속하는지 확인합니다. 이렇게 하면 자동으로 선택한 IP와의 충돌이 방지됩니다. 마찬가지로 표준 예측 가능한 VIP 배치( 14.4절. “예측 가능한 가상 IP 할당”참조) 또는 외부 로드 밸런싱에 대한 IP 할당이 VIP 구성과 충돌하지 않는지 확인합니다( 23.2절. “외부 로드 밸런싱 구성”참조).
Overcloud 노드가 삭제되면 IP 목록의 항목을 제거하지 마십시오. IP 목록은 기본 Heat 인덱스를 기반으로 하며, 노드를 삭제해도 변경되지 않습니다. 목록에 지정된 항목이 더 이상 사용되지 않음을 나타내려면 IP 값을 DELETED 또는 UNUSED 와 같은 값으로 바꿉니다. 항목은 변경 또는 추가만 IP 목록에서 제거해서는 안 됩니다.
배포 중에 이 구성을 적용하려면 openstack overcloud deploy 명령을 사용하여 ips-from-pool-all.yaml 환경 파일을 포함합니다.
네트워크 분리를 사용하는 경우 network 파일을 포함합니다.
-isolation.yaml 파일 뒤에 ips-from-pool-all.yaml
예를 들면 다음과 같습니다.
openstack overcloud deploy --templates \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e ~/templates/ips-from-pool-all.yaml \ [OTHER OPTIONS]
$ openstack overcloud deploy --templates \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
-e ~/templates/ips-from-pool-all.yaml \
[OTHER OPTIONS]
14.4. 예측 가능한 가상 IP 할당 링크 복사링크가 클립보드에 복사되었습니다!
director는 각 노드에 대해 예측 가능한 IP 주소를 정의하는 것 외에도 클러스터형 서비스에 대해 예측 가능한 VIP(가상 IP)를 정의하는 유사한 기능도 제공합니다. 이 작업을 수행하려면 11.7절. “사용자 지정 네트워크 환경 파일” 에서 네트워크 환경 파일을 편집하고 parameter_defaults 섹션에 VIP 매개변수를 추가합니다.
해당 할당 풀 범위 외부에서 이러한 IP를 선택합니다. 예를 들어 InternalApi IP 주소를 선택합니다.
AllocationPools 범위에 없는 InternalApiVirtualFixedIP s의
이 단계는 기본 내부 로드 밸런싱 구성을 사용하는 오버클라우드 전용입니다. 외부 로드 밸런서에 VIP를 할당하는 경우 Overcloud용 전용 External Load Balancing 가이드의 절차를 사용합니다.
15장. 오버클라우드 공개 엔드 포인트에서 SSL/TLS 활성화 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 오버클라우드는 암호화되지 않은 엔드포인트를 서비스에 사용합니다. 즉, 공용 API 엔드포인트에 SSL/TLS를 활성화하려면 오버클라우드 구성에 추가 환경 파일이 필요합니다. 다음 장에서는 SSL/TLS 인증서를 구성하고 오버클라우드 생성의 일부로 포함하는 방법을 보여줍니다.
이 프로세스는 공용 API 엔드포인트에 대해 SSL/TLS만 활성화합니다. Internal 및 Admin API는 암호화되지 않은 상태로 유지됩니다.
이 프로세스를 수행하려면 공용 API의 엔드포인트를 정의하기 위해 네트워크 격리가 필요합니다.
15.1. 서명 호스트 초기화 링크 복사링크가 클립보드에 복사되었습니다!
서명 호스트는 새 인증서를 생성하고 인증 기관을 통해 서명하는 호스트입니다. 선택한 서명 호스트에서 SSL 인증서를 생성한 적이 없는 경우 새 인증서에 서명할 수 있도록 호스트를 초기화해야 할 수 있습니다.
/etc/pki/CA/index.txt 파일은 서명된 모든 인증서의 레코드를 저장합니다. 이 파일이 있는지 확인합니다. 없는 경우 빈 파일을 생성합니다.
sudo touch /etc/pki/CA/index.txt
$ sudo touch /etc/pki/CA/index.txt
/etc/pki/CA/serial 파일은 서명할 다음 인증서에 사용할 다음 일련번호를 식별합니다. 이 파일이 있는지 확인합니다. 존재하지 않는 경우 새 시작 값으로 새 파일을 생성합니다.
echo '1000' | sudo tee /etc/pki/CA/serial
$ echo '1000' | sudo tee /etc/pki/CA/serial
15.2. 인증 기관 생성 링크 복사링크가 클립보드에 복사되었습니다!
일반적으로는 외부 인증 기관을 통해 SSL/TLS 인증서에 서명합니다. 경우에 따라 고유한 인증 기관을 사용하려고 할 수 있습니다. 예를 들어 내부 전용 인증 기관을 사용할 수 있습니다.
예를 들어 인증 기관 역할을 할 키와 인증서 쌍을 생성합니다.
sudo openssl genrsa -out ca.key.pem 4096 sudo openssl req -key ca.key.pem -new -x509 -days 7300 -extensions v3_ca -out ca.crt.pem
$ sudo openssl genrsa -out ca.key.pem 4096
$ sudo openssl req -key ca.key.pem -new -x509 -days 7300 -extensions v3_ca -out ca.crt.pem
openssl req 명령은 기관에 대한 특정 세부 정보를 요청합니다. 다음 세부 정보를 입력합니다.
이렇게 하면 ca.crt.pem 이라는 인증 기관 파일이 생성됩니다.
15.3. 클라이언트에 인증 기관 추가 링크 복사링크가 클립보드에 복사되었습니다!
외부 클라이언트가 SSL/TLS를 사용하여 통신하려는 경우 Red Hat OpenStack Platform 환경에 액세스해야 하는 각 클라이언트에 인증 기관 파일을 복사합니다. 클라이언트에 복사되고 나면 클라이언트에서 다음 명령을 실행하여 인증 기관 신뢰 번들에 추가합니다.
sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/ sudo update-ca-trust extract
$ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
$ sudo update-ca-trust extract
예를 들어 언더클라우드에는 생성 중에 오버클라우드 엔드포인트와 통신할 수 있도록 인증 기관 파일 사본이 필요합니다.
15.4. SSL/TLS 키 생성 링크 복사링크가 클립보드에 복사되었습니다!
다음 명령을 실행하여 언더클라우드 또는 오버클라우드 인증서를 생성하는 데 다른 지점에서 사용하는 SSL/TLS 키(server.key.pem)를 생성합니다.
openssl genrsa -out server.key.pem 2048
$ openssl genrsa -out server.key.pem 2048
15.5. SSL/TLS 인증서 서명 요청 생성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 오버클라우드에 대한 인증서 서명 요청을 생성합니다. 사용자 지정을 위해 기본 OpenSSL 구성 파일을 복사합니다.
cp /etc/pki/tls/openssl.cnf .
$ cp /etc/pki/tls/openssl.cnf .
사용자 지정 openssl.cnf 파일을 편집하고 오버클라우드에 사용할 SSL 매개변수를 설정합니다. 수정할 매개변수 유형의 예제는 다음과 같습니다.
commonName_default 를 다음 중 하나로 설정합니다.
-
IP를 사용하여 SSL/TLS를 통해 액세스하는 경우 공용 API에 대해 가상 IP를 사용합니다. 환경 파일에서
PublicVirtualFixedIPs매개변수를 사용하여 이 VIP를 설정합니다. 자세한 내용은 14.4절. “예측 가능한 가상 IP 할당”의 내용을 참조하십시오. 예측 가능한 VIP를 사용하지 않는 경우 director는ExternalAllocationPools매개변수에 정의된 범위에서 첫 번째 IP 주소를 할당합니다. - 정규화된 도메인 이름을 사용하여 SSL/TLS를 통해 액세스하는 경우 대신 도메인 이름을 사용합니다.
동일한 공용 API IP 주소를 IP 항목으로 포함하고 alt_names 섹션에 DNS 항목을 포함합니다. DNS를 사용하는 경우 서버의 호스트 이름을 동일한 섹션에 DNS 항목으로 포함합니다. openssl.cnf 에 대한 자세한 내용을 보려면 man openssl.cnf 를 실행합니다.
다음 명령을 실행하여 인증서 서명 요청(server.csr.pem)을 생성합니다.
openssl req -config openssl.cnf -key server.key.pem -new -out server.csr.pem
$ openssl req -config openssl.cnf -key server.key.pem -new -out server.csr.pem
-key 옵션에 대해 15.4절. “SSL/TLS 키 생성” 에서 생성한 SSL/TLS 키를 포함해야 합니다.
다음 섹션에서 server.csr.pem 파일을 사용하여 SSL/TLS 인증서를 생성합니다.
15.6. SSL/TLS 인증서 생성 링크 복사링크가 클립보드에 복사되었습니다!
다음 명령은 언더클라우드 또는 오버클라우드에 대한 인증서를 생성합니다.
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
$ 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
이 명령에서는 다음을 사용합니다.
-
v3 확장을 지정하는 구성 파일입니다. 이 파일을
-config옵션으로 추가합니다. -
인증서를 생성하고 인증 기관을 통해 서명하기 위한 15.5절. “SSL/TLS 인증서 서명 요청 생성” 의 인증서 서명 요청입니다. 이 파일을
-in옵션으로 추가합니다. -
15.2절. “인증 기관 생성” 에서 생성한 인증 기관. 이 인증 기관을
-cert옵션으로 추가합니다. -
15.2절. “인증 기관 생성” 에서 생성한 인증 기관 개인 키입니다. 이 파일을
-keyfile옵션으로 추가합니다.
그러면 server.crt.pem이라는 인증서가 생성됩니다. 이 인증서를 15.4절. “SSL/TLS 키 생성” 의 SSL/TLS 키와 함께 사용하여 SSL/TLS를 활성화합니다.
15.7. SSL/TLS 활성화 링크 복사링크가 클립보드에 복사되었습니다!
Heat 템플릿 컬렉션에서 enable-tls.yaml 환경 파일을 복사합니다.
cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml ~/templates/.
$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml ~/templates/.
이 파일을 편집하여 해당 매개변수에 대해 다음과 같이 변경합니다.
- SSLCertificate
인증서 파일(server
.crt.pem)의 내용을SSLCertificate매개 변수에 복사합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - SSLIntermediateCertificate
중간 인증서가 있는 경우 중간 인증서의 내용을
SSLIntermediateCertificate 매개변수로복사합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요인증서 콘텐츠에는 모든 새 행에 대해 동일한 들여쓰기 수준이 필요합니다.
- SSLKey
개인 키(server
.key.pem)의 콘텐츠를SSLKey매개 변수에 복사합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요개인 키 콘텐츠에는 모든 새 행에 대해 동일한 들여쓰기 수준이 필요합니다.
- OS::TripleO::NodeTLSData
OS::TripleO::NodeTLSData:의 리소스 경로를 절대 경로로 변경합니다.resource_registry: OS::TripleO::NodeTLSData: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/tls/tls-cert-inject.yaml
resource_registry: OS::TripleO::NodeTLSData: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/tls/tls-cert-inject.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
15.8. 루트 인증서 삽입 링크 복사링크가 클립보드에 복사되었습니다!
인증서 서명자가 오버클라우드 이미지의 기본 신뢰 저장소에 없는 경우 인증 기관을 오버클라우드 이미지에 삽입해야 합니다. heat 템플릿 컬렉션에서 inject-trust-anchor.yaml 환경 파일을 복사합니다.
cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/inject-trust-anchor.yaml ~/templates/.
$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/inject-trust-anchor.yaml ~/templates/.
이 파일을 편집하여 해당 매개변수에 대해 다음과 같이 변경합니다.
- SSLRootCertificate
루트 인증 기관 파일(
ca.crt.pem)의 콘텐츠를SSLRootCertificate매개 변수에 복사합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요인증 기관 콘텐츠에는 모든 새 행에 대해 동일한 들여쓰기 수준이 필요합니다.
- OS::TripleO::NodeTLSCAData
OS::TripleO::NodeTLSCAData:의 리소스 경로를 절대 경로로 변경합니다.resource_registry: OS::TripleO::NodeTLSCAData: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/tls/ca-inject.yaml
resource_registry: OS::TripleO::NodeTLSCAData: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/tls/ca-inject.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
여러 CA를 삽입하려면 inject-trust-anchor-hiera.yaml 환경 파일을 사용할 수 있습니다. 예를 들어 언더클라우드와 오버클라우드 모두에 대한 CA를 동시에 삽입할 수 있습니다.
15.9. DNS 끝점 구성 링크 복사링크가 클립보드에 복사되었습니다!
DNS 호스트 이름을 사용하여 SSL/TLS를 통해 오버클라우드에 액세스하는 경우 custom-domain.yaml 파일을 /home/stack/templates 에 복사해야 합니다. 이 파일은 /usr/share/tripleo-heat-templates/environments/predictable-placement/ 에서 찾을 수 있습니다.
필요한 경우 사용자 지정 네트워크의 매개 변수를 추가하여 모든 필드에 대해 호스트 및 도메인 이름을 구성합니다.
참고이 환경 파일이 초기 배포에 포함되지 않은 경우 TLS-everywhere 아키텍처로 재배포할 수 없습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 새 환경 파일이나 기존 환경 파일에서 매개 변수 기본값 아래 사용할 DNS 서버 목록을 추가합니다.
parameter_defaults: DnsServers: ["10.0.0.254"] ....
parameter_defaults: DnsServers: ["10.0.0.254"] ....Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.10. 오버클라우드 생성 중 환경 파일 추가 링크 복사링크가 클립보드에 복사되었습니다!
배포 명령(openstack overcloud deploy)은 -e 옵션을 사용하여 환경 파일을 추가합니다. 이 섹션의 환경 파일을 다음 순서로 추가합니다.
-
SSL/TLS(enable
-tls.yaml)를 활성화하는환경 파일 -
DNS 호스트 이름을 설정할 환경 파일 (
cloudname.yaml) -
루트 인증 기관을 삽입할 환경 파일(
inject-trust-anchor.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 이름을 사용하는 경우
예를 들면 다음과 같습니다.
openstack overcloud deploy --templates [...] -e /home/stack/templates/enable-tls.yaml -e ~/templates/cloudname.yaml -e ~/templates/inject-trust-anchor.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml
$ openstack overcloud deploy --templates [...] -e /home/stack/templates/enable-tls.yaml -e ~/templates/cloudname.yaml -e ~/templates/inject-trust-anchor.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml
15.11. SSL/TLS 인증서 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
나중에 인증서를 업데이트해야 하는 경우:
-
enable-tls.yaml파일을 편집하고SSLCertificate, SSLKey및SSLIntermediateCertificate매개변수를 업데이트합니다. -
인증 기관이 변경된 경우
inject-trust-anchor.yaml파일을 편집하고SSLRootCertificate매개변수를 업데이트합니다.
새 인증서 내용이 준비되면 배포 명령을 다시 실행합니다. 예를 들면 다음과 같습니다.
openstack overcloud deploy --templates [...] -e /home/stack/templates/enable-tls.yaml -e ~/templates/cloudname.yaml -e ~/templates/inject-trust-anchor.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml
$ openstack overcloud deploy --templates [...] -e /home/stack/templates/enable-tls.yaml -e ~/templates/cloudname.yaml -e ~/templates/inject-trust-anchor.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml
16장. ID 관리를 사용하여 내부 및 공개 끝점에서 SSL/TLS 활성화 링크 복사링크가 클립보드에 복사되었습니다!
특정 오버클라우드 끝점에서 SSL/TLS를 활성화할 수 있습니다. 필요한 인증서 수로 인해 director는 Red Hat IdM(Identity Management) 서버와 통합되어 인증 기관 역할을 하며 오버클라우드 인증서를 관리합니다. 이 프로세스에는 novajoin 을 사용하여 Overcloud 노드를 IdM 서버에 등록해야 합니다.
OpenStack 구성 요소에서 TLS 지원 상태를 확인하려면 TLS 활성화 상태 매트릭스 를 참조하십시오.
16.1. 언더클라우드를 CA에 추가합니다 링크 복사링크가 클립보드에 복사되었습니다!
오버클라우드를 배포하기 전에 CA(인증 기관)에 언더클라우드를 추가해야 합니다.
언더클라우드 노드에서
python-novajoin패키지를 설치합니다.sudo yum install python-novajoin
$ sudo yum install python-novajoinCopy to Clipboard Copied! Toggle word wrap Toggle overflow 언더클라우드 노드에서
novajoin-ipa-setup스크립트를 실행하여 배포에 맞게 값을 조정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 섹션에서는 결과로 생성된 OTP(One-Time Password)를 사용하여 언더클라우드를 등록합니다.
16.2. IdM에 언더클라우드 추가 링크 복사링크가 클립보드에 복사되었습니다!
이 절차에서는 언더클라우드를 IdM에 등록하고 novajoin을 구성합니다. undercloud.conf ([ DEFAULT] 섹션 내)에서 다음 설정을 구성합니다.
novajoin 서비스는 기본적으로 비활성화되어 있습니다. 활성화하려면 다음을 수행합니다.
[DEFAULT] enable_novajoin = true
[DEFAULT] enable_novajoin = trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow IdM을 사용하여 언더클라우드 노드를 등록하려면 OTP(일회 암호)를 설정해야 합니다.
ipa_otp = <otp>
ipa_otp = <otp>Copy to Clipboard Copied! Toggle word wrap Toggle overflow neutron의 DHCP 서버에서 제공하는 오버클라우드의 도메인 이름이 IdM 도메인(소문자의 kerberos 영역)과 일치하는지 확인합니다.
overcloud_domain_name = <domain>
overcloud_domain_name = <domain>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 언더클라우드에 적절한 호스트 이름을 설정합니다.
undercloud_hostname = <undercloud FQDN>
undercloud_hostname = <undercloud FQDN>Copy to Clipboard Copied! Toggle word wrap Toggle overflow IdM을 언더클라우드의 이름 서버로 설정합니다.
undercloud_nameservers = <IdM IP>
undercloud_nameservers = <IdM IP>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 대규모 환경의 경우 novajoin 연결 시간 제한 값을 검토해야 합니다.
undercloud.conf에서 undercloud-timeout.yaml이라는 새 파일에 참조를 추가합니다.hieradata_override = /home/stack/undercloud-timeout.yaml
hieradata_override = /home/stack/undercloud-timeout.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow undercloud-timeout.yaml에 다음 옵션을 추가합니다. 시간 제한 값을 초 단위로 지정할 수 있습니다(예:5):nova::api::vendordata_dynamic_connect_timeout: <timeout value> nova::api::vendordata_dynamic_read_timeout: <timeout value>
nova::api::vendordata_dynamic_connect_timeout: <timeout value> nova::api::vendordata_dynamic_read_timeout: <timeout value>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
undercloud.conf파일을 저장합니다. 언더클라우드 배포 명령을 실행하여 기존 언더클라우드에 변경 사항을 적용합니다.
openstack undercloud install
$ openstack undercloud installCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
키 탭 파일에서언더클라우드의 키 항목을 확인합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 호스트 원칙을 사용하여 시스템
/etc/krb.keytab파일을 테스트합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow nova 원칙을 사용하여 novajoin
/etc/novajoin/krb.keytab파일을 테스트합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16.3. 오버클라우드 DNS 설정 링크 복사링크가 클립보드에 복사되었습니다!
IdM 환경을 자동으로 감지하고 등록하기 쉬운 경우 DNS 서버로 IdM을 사용하는 것이 좋습니다.
언더클라우드에 연결합니다.
source ~/stackrc
$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow IdM을 DNS 이름 서버로 사용하도록 컨트롤 플레인 서브넷을 구성합니다.
openstack subnet set ctlplane-subnet --dns-nameserver <idm_server_address>
$ openstack subnet set ctlplane-subnet --dns-nameserver <idm_server_address>Copy to Clipboard Copied! Toggle word wrap Toggle overflow IdM 서버를 사용하도록 환경 파일에서
DnsServers매개변수를 설정합니다.parameter_defaults: DnsServers: ["<idm_server_address>"]
parameter_defaults: DnsServers: ["<idm_server_address>"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 일반적으로 이 매개변수는 사용자 지정
network-environment.yaml파일에 정의됩니다.
16.4. novajoin을 사용하도록 오버클라우드 설정 링크 복사링크가 클립보드에 복사되었습니다!
IdM 통합을 활성화하려면
/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
$ cp /usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml \ /home/stack/templates/custom-domain.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow /home/stack/templates/custom-domain.yaml환경 파일을 편집하고 배포에 맞게CloudDomain및CloudName*값을 설정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 오버클라우드 배포 프로세스에 다음 환경 파일을 포함합니다.
-
/usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml -
/usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml /home/stack/templates/custom-domain.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 \
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 \Copy to Clipboard Copied! Toggle word wrap Toggle overflow 결과적으로 배포된 Overcloud 노드가 IdM을 사용하여 자동으로 등록됩니다.
-
이렇게 하면 내부 엔드포인트에 TLS만 설정됩니다. 외부 엔드포인트의 경우
/usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml환경 파일과 함께 TLS를 추가하는 일반 수단을 사용할 수 있습니다(사용자 정의 인증서 및 키를 추가하려면 수정해야 함). 결과적으로openstack deploy명령은 다음과 유사합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 또는 IdM을 사용하여 공용 인증서를 발급할 수도 있습니다. 이 경우
/usr/share/openstack-tripleo-heat-templates/environments/services/haproxy-public-tls-certmonger.yaml환경 파일을 사용해야 합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17장. TLS를 사용하도록 기존 배포 변환 링크 복사링크가 클립보드에 복사되었습니다!
TLS 암호화를 사용하도록 기존 오버클라우드 및 언더클라우드 끝점을 구성할 수 있습니다. 이 접근 방식에서는 novajoin 을 사용하여 배포를 Red Hat IdM(Identity Management)과 통합하고 DNS, Kerberos 및 certmonger에 액세스할 수 있습니다. 각 오버클라우드 노드는 certmonger 클라이언트를 사용하여 각 서비스의 인증서를 검색합니다.
TLS에 대한 자세한 내용은 보안 및 강화 가이드를 참조하십시오.
17.1. 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
-
Red Hat OpenStack Platform 13의 경우 버전
z8이상을 실행해야 합니다. - 기존 IdM 배포가 있어야 하며 OpenStack 배포에 DNS 서비스를 제공해야 합니다.
- 기존 배포에서는 공용 엔드포인트에 FQDN을 사용해야 합니다. 기본 구성은 IP 주소 기반 엔드포인트를 사용할 수 있으므로 IP 주소 기반 인증서를 생성합니다. 이러한 단계를 진행하기 전에 FQDN으로 변경해야 합니다.
이 절차 기간에는 오버클라우드 및 Undercloud 서비스를 사용할 수 없습니다.
17.2. 끝점 검토 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 기존 Red Hat OpenStack Platform 13 오버클라우드는 TLS를 사용하여 특정 끝점을 암호화하지 않습니다. 예를 들어 이 출력에는 https 대신 http 를 사용하는 URL이 포함되어 있습니다. 이러한 URL은 암호화되지 않습니다.
다음 섹션에서는 TLS를 사용하여 이러한 엔드포인트를 암호화하는 방법에 대해 설명합니다.
17.3. 알려진 문제에 대한 해결 방법 적용 링크 복사링크가 클립보드에 복사되었습니다!
현재 TLS Everywhere 내부 업그레이드에 대한 알려진 문제가 있으며 이로 인해 오버클라우드 노드는 IdM에 등록할 수 없습니다. 이 문제를 해결하려면 오버클라우드 배포를 실행하기 전에 모든 오버클라우드 노드에서 /etc/ipa/ca.crt/ 를 삭제합니다. 자세한 내용은 https://bugzilla.redhat.com/show_bug.cgi?id=1732564 의 내용을 참조하십시오.
예를 들어 다음 스크립트는 해결 방법을 적용하는 한 가지 방법입니다. 배포에 맞게 수정해야 할 수도 있습니다.
17.4. TLS를 사용하도록 끝점 구성 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 기존 배포에 대해 TLS 엔드포인트 암호화를 활성화하는 방법과 엔드포인트가 올바르게 구성되었는지 확인하는 방법을 설명합니다.
어디에서든 TLS를 활성화할 때 도메인의 구조에 따라 다양한 업그레이드 경로를 사용할 수 있습니다. 다음 예제에서는 샘플 도메인 이름을 사용하여 업그레이드 경로를 설명합니다.
-
기존 공용 엔드포인트 인증서를 재사용하고, Overcloud 도메인(
lab.local)이 IdM 도메인( lab.local)과 일치하는내부및관리엔드포인트의 모든 위치에서 TLS를 활성화합니다. -
IdM에서 새 공용 엔드포인트 인증서를 발급하고, 오버클라우드 도메인(
lab.local)이 IdM 도메인( lab.local)과 일치하는내부및관리끝점의 모든 위치에서 TLS를 사용하도록 허용합니다. -
기존 공용 엔드포인트 인증서를 재사용하고, Overcloud 도메인(site
1.lab.local)이 IdM 도메인( lab.local)의 하위 도메인인TLS를 활성화합니다.내부및관리끝점의 모든 위치에서 -
IdM에서 새 공용 엔드포인트 인증서를 발급하고, Overcloud 도메인(site
1.lab.local)이 IdM 도메인( lab.local)의 하위 도메인인TLS를 사용하도록 허용합니다.내부및관리끝점의 모든 위치에서
이 섹션의 다음 절차에서는 위에서 설명한 다양한 조합을 사용하여 이 통합을 구성하는 방법에 대해 설명합니다.
17.4.1. IdM과 동일한 도메인을 사용하여 배포에 언더클라우드 통합 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 IdM과 동일한 도메인을 사용하는 배포에 언더클라우드 통합을 구성하는 방법을 설명합니다.
Red Hat OpenStack Platform은 novajoin 을 사용하여 Red Hat IdM(Identity Management)과 통합되어 암호화 인증서를 발급하고 관리합니다. 이 절차에서는 언더클라우드를 IdM에 등록하고, 토큰을 생성하고, 언더클라우드 설정에서 토큰을 활성화한 다음, 언더클라우드 및 오버클라우드 배포 스크립트를 다시 실행합니다. 예를 들면 다음과 같습니다.
IdM과의 통합을 위해
python-novajoin을 설치합니다.sudo yum install python-novajoin
[stack@undercloud-0 ~]$ sudo yum install python-novajoinCopy to Clipboard Copied! Toggle word wrap Toggle overflow novajoin구성 스크립트를 실행하고 IdM 배포에 대한 구성 세부 정보를 제공합니다. 예를 들면 다음과 같습니다.sudo novajoin-ipa-setup --principal admin --password ComplexRedactedPassword \ --server ipa.lab.local --realm lab.local --domain lab.local \ --hostname undercloud-0.lab.local --precreate ... 0Uvua6NyIWVkfCSTOmwbdAobsqGH2GONRJrW24MoQ4wg
[stack@undercloud-0 ~]$ sudo novajoin-ipa-setup --principal admin --password ComplexRedactedPassword \ --server ipa.lab.local --realm lab.local --domain lab.local \ --hostname undercloud-0.lab.local --precreate ... 0Uvua6NyIWVkfCSTOmwbdAobsqGH2GONRJrW24MoQ4wgCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이 출력에는 IdM용 OTP(한 번 암호)가 포함되어 있습니다. 이 값은 배포에 다른 값이 됩니다.
novajoin을 사용하도록 Undercloud를 구성하고, 일회성 암호(OTP)를 추가하고, DNS에 IdM IP 주소를 사용하고, Overcloud 도메인을 설명합니다. 배포를 위해 이 예제를 조정해야 합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 언더클라우드에
novajoin서비스를 설치합니다.openstack undercloud install
[stack@undercloud ~]$ openstack undercloud installCopy to Clipboard Copied! Toggle word wrap Toggle overflow Overcloud IP 주소를 DNS에 추가합니다. 배포에 맞게 이 예제를 수정해야 합니다.
참고: 오버클라우드의
network-environment.yaml을 확인하고 각 네트워크 범위 내에서 VIP를 선택합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 모든 끝점에 대한
public_vip.yaml매핑을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.4.2. IdM과 동일한 도메인을 사용하고 기존 공용 끝점 인증서를 유지하는 배포에 대해 오버클라우드 통합 구성 링크 복사링크가 클립보드에 복사되었습니다!
openstack overcloud deploy명령(유효한 설정 포함)에 다음 매개변수가 있는지 확인한 다음 배포 명령을 다시 실행합니다.- ' --NTP-server' - 아직 설정되지 않은 경우 환경에 맞게 NTP 서버를 지정합니다. IdM 서버가 ntp를 실행해야 합니다.
-
cloud-names.yaml- 초기 배포 명령에서 FQDN(IP 아님)을 포함합니다. -
enable-tls.yaml- 새 오버클라우드 인증서가 포함되어 있습니다. 예를 들어 https://github.com/openstack/tripleo-heat-templates/blob/master/environments/ssl/enable-tls.yaml 참조하십시오. -
public_vip.yaml- dns가 일치하도록 엔드포인트를 특정 ip에 매핑합니다. -
enable-internal-tls.yaml- 내부 엔드포인트에 TLS를 활성화합니다. -
tls-everywhere-endpoints-dns.yaml- DNS 이름을 사용하여 TLS 엔드포인트를 구성합니다. 이 파일의 내용을 검토하여 구성 범위를 확인할 수 있습니다. -
haproxy-internal-tls-certmonger.yaml- certmonger는 haproxy의 내부 인증서를 관리합니다. inject-trust-anchor.yaml- 루트 인증 기관을 추가합니다. 인증서가 기본적으로 사용되는 일반 세트의 일부가 아닌 CA 체인을 사용하는 경우에만 필요합니다(예: 자체 서명 사용).예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고
17.4.3. IdM과 동일한 도메인을 사용하는 배포용 오버클라우드 통합 구성 및 기존 공용 끝점 인증서를 IdM 생성 인증서로 교체 링크 복사링크가 클립보드에 복사되었습니다!
openstack overcloud deploy명령(유효한 설정 포함)에 다음 매개변수가 있는지 확인한 다음 배포 명령을 다시 실행합니다.- ' --NTP-server' - 아직 설정되지 않은 경우 환경에 맞게 NTP 서버를 지정합니다. IdM 서버가 ntp를 실행해야 합니다.
-
cloud-names.yaml- 초기 배포 명령에서 FQDN(IP 아님)을 포함합니다. -
enable-tls.yaml- 새 오버클라우드 인증서가 포함되어 있습니다. 예를 들어 https://github.com/openstack/tripleo-heat-templates/blob/master/environments/ssl/enable-tls.yaml 참조하십시오. -
public_vip.yaml- dns가 일치하도록 엔드포인트를 특정 ip에 매핑합니다. -
enable-internal-tls.yaml- 내부 엔드포인트에 TLS를 활성화합니다. -
tls-everywhere-endpoints-dns.yaml- DNS 이름을 사용하여 TLS 엔드포인트를 구성합니다. 이 파일의 내용을 검토하여 구성 범위를 확인할 수 있습니다. -
haproxy-public-tls-certmonger.yaml- certmonger는 haproxy에서 내부 및 공용 인증서를 관리합니다. inject-trust-anchor.yaml- 루트 인증 기관을 추가합니다. 인증서가 기본적으로 사용되는 일반 세트의 일부가 아닌 CA 체인을 사용하는 경우에만 필요합니다(예: 자체 서명 사용).예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고이러한 환경 파일의 예는 https://github.com/openstack/tripleo-heat-templates/tree/master/environments/ssl 에서 찾을 수 있습니다.
템플릿 enable-internal-tls.j2.yaml 은 오버클라우드 배포 명령에서 enable-internal-tls.yaml 로 참조됩니다.
또한 enable-tls.yaml 의 이전 공용 엔드포인트 인증서는 certmonger로 haproxy-public-tls-certmonger.yaml 로 교체되지만 업그레이드 프로세스에서 이 파일을 참조해야 합니다.
17.4.4. IdM 하위 도메인을 사용하는 배포를 위해 언더클라우드 통합 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 IdM 하위 도메인을 사용하는 배포를 위해 언더클라우드 통합을 구성하는 방법을 설명합니다.
Red Hat OpenStack Platform은 novajoin 을 사용하여 Red Hat IdM(Identity Management)과 통합되어 암호화 인증서를 발급하고 관리합니다. 이 절차에서는 언더클라우드를 IdM에 등록하고, 토큰을 생성하고, 언더클라우드 설정에서 토큰을 활성화한 다음, 언더클라우드 및 오버클라우드 배포 스크립트를 다시 실행합니다. 예를 들면 다음과 같습니다.
IdM과의 통합을 위해
python-novajoin을 설치합니다.[stack@undercloud-0 ~]$Copy to Clipboard Copied! Toggle word wrap Toggle overflow novajoin구성 스크립트를 실행하고 IdM 배포에 대한 구성 세부 정보를 제공합니다. 예를 들면 다음과 같습니다.sudo novajoin-ipa-setup --principal admin --password ComplexRedactedPassword \ --server ipa.lab.local --realm lab.local --domain lab.local \ --hostname undercloud-0.site1.lab.local --precreate ... 0Uvua6NyIWVkfCSTOmwbdAobsqGH2GONRJrW24MoQ4wg
[stack@undercloud-0 ~]$ sudo novajoin-ipa-setup --principal admin --password ComplexRedactedPassword \ --server ipa.lab.local --realm lab.local --domain lab.local \ --hostname undercloud-0.site1.lab.local --precreate ... 0Uvua6NyIWVkfCSTOmwbdAobsqGH2GONRJrW24MoQ4wgCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이 출력에는 IdM용 OTP(한 번 암호)가 포함되어 있습니다. 이 값은 배포에 다른 값이 됩니다.
novajoin을 사용하도록 언더클라우드를 구성하고 DNS 및 NTP용 OTP, IdM IP 및 오버클라우드 도메인을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow novajoin을 사용하도록 언더클라우드를 구성하고 DNS 및 오버클라우드 도메인에 OTP, IdM IP를 추가합니다.vi hiera_override.yaml nova::metadata::novajoin::api::ipa_domain: site1.lab.local ...
[stack@undercloud-0 ~]$ vi hiera_override.yaml nova::metadata::novajoin::api::ipa_domain: site1.lab.local ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 언더클라우드에
novajoin서비스를 설치합니다.openstack undercloud install
[stack@undercloud ~]$ openstack undercloud installCopy to Clipboard Copied! Toggle word wrap Toggle overflow Overcloud IP 주소를 DNS에 추가합니다. 배포에 맞게 이 예제를 수정해야 합니다.
참고: 오버클라우드의
network-environment.yaml을 확인하고 각 네트워크 범위 내에서 VIP를 선택합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 각 엔드포인트에 대한
public_vip.yaml매핑을 생성합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 각 엔드포인트에 대해
extras.yaml매핑을 생성합니다. 예를 들면 다음과 같습니다.parameter_defaults: MakeHomeDir: True IdMNoNtpSetup: false IdMDomain: redhat.local DnsSearchDomains: ["site1.redhat.local","redhat.local"]
parameter_defaults: MakeHomeDir: True IdMNoNtpSetup: false IdMDomain: redhat.local DnsSearchDomains: ["site1.redhat.local","redhat.local"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.4.5. IdM 하위 도메인을 사용하고 기존 공용 끝점 인증서를 유지하는 배포에 언더클라우드 통합 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 IdM 하위 도메인을 사용하고 기존 공용 엔드포인트 인증서를 유지하는 배포를 위해 Undercloud 통합을 구성하는 방법을 설명합니다.
openstack overcloud deploy명령(유효한 설정 포함)에 다음 매개변수가 있는지 확인한 다음 배포 명령을 다시 실행합니다.- ' --NTP-server' - 아직 설정되지 않은 경우 환경에 맞게 NTP 서버를 지정합니다. IdM 서버가 ntp를 실행해야 합니다.
-
cloud-names.yaml- 초기 배포 명령에서 FQDN(IP 아님)을 포함합니다. -
enable-tls.yaml- 새 오버클라우드 인증서가 포함되어 있습니다. 예를 들어 https://github.com/openstack/tripleo-heat-templates/blob/master/environments/ssl/enable-tls.yaml 참조하십시오. -
public_vip.yaml- dns가 일치하도록 엔드포인트가 특정 ip에 매핑됩니다. - 'extras.yaml ' - 로그인 시 홈 디렉토리를 만들고, ntp 설정, 기본 IdM 도메인 및 dns에서 resolv.conf를 검색하는 설정이 포함되어 있습니다.
-
enable-internal-tls.yaml- 내부 엔드포인트에 TLS를 활성화합니다. -
tls-everywhere-endpoints-dns.yaml- DNS 이름을 사용하여 TLS 엔드포인트를 구성합니다. 이 파일의 내용을 검토하여 구성 범위를 확인할 수 있습니다. -
haproxy-internal-tls-certmonger.yaml- certmonger는 haproxy의 내부 인증서를 관리합니다. inject-trust-anchor.yaml- 루트 인증 기관을 추가합니다. 인증서가 기본적으로 사용되는 일반 세트의 일부가 아닌 CA 체인을 사용하는 경우에만 필요합니다(예: 자체 서명 사용).예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고
17.4.6. IdM 하위 도메인을 사용하는 배포에 언더클라우드 통합 구성 및 기존 공용 끝점 인증서를 IdM 생성 인증서로 교체 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 IdM 하위 도메인을 사용하는 배포에 언더클라우드 통합을 구성하는 방법과 기존 공용 엔드포인트 인증서를 IdM 생성 인증서로 바꾸는 방법을 설명합니다.
openstack overcloud deploy명령(유효한 설정 포함)에 다음 매개변수가 있는지 확인한 다음 배포 명령을 다시 실행합니다.- ' --NTP-server' - 아직 설정되지 않은 경우 환경에 맞게 NTP 서버를 지정합니다. IdM 서버가 ntp를 실행해야 합니다.
-
cloud-names.yaml- 초기 배포 명령에서 FQDN(IP 아님)을 포함합니다. -
enable-tls.yaml- 새 오버클라우드 인증서가 포함되어 있습니다. 예를 들어 https://github.com/openstack/tripleo-heat-templates/blob/master/environments/ssl/enable-tls.yaml 참조하십시오. -
public_vip.yaml- dns가 일치하도록 엔드포인트를 특정 ip에 매핑합니다. - 'extras.yaml ' - 로그인 시 홈 디렉토리를 만들고, ntp 설정, 기본 IdM 도메인 및 dns에서 resolv.conf를 검색하는 설정이 포함되어 있습니다.
-
enable-internal-tls.yaml- 내부 엔드포인트에 TLS를 활성화합니다. -
tls-everywhere-endpoints-dns.yaml- DNS 이름을 사용하여 TLS 엔드포인트를 구성합니다. 이 파일의 내용을 검토하여 구성 범위를 확인할 수 있습니다. -
haproxy-public-tls-certmonger.yaml- certmonger는 haproxy에서 내부 및 공용 인증서를 관리합니다. inject-trust-anchor.yaml- 루트 인증 기관을 추가합니다. 인증서가 기본적으로 사용되는 일반 세트의 일부가 아닌 CA 체인을 사용하는 경우에만 필요합니다(예: 자체 서명 사용).예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고
이 예에서 enable-internal-tls.j2.yaml 템플릿은 오버클라우드 deploy 명령에서 enable-internal-tls.yaml 로 참조됩니다. 또한 enable-tls.yaml 의 이전 공용 엔드포인트 인증서는 haproxy-public-tls-certmonger.yaml을 사용하여 certmonger 로 교체되지만 이 파일은 업그레이드 프로세스에서 계속 참조해야 합니다.
17.5. TLS 암호화 확인 링크 복사링크가 클립보드에 복사되었습니다!
오버클라우드 재배포가 완료되면 모든 엔드포인트가 이제 TLS로 암호화되었는지 확인합니다. 이 예제에서 모든 끝점은 TLS 암호화를 사용하고 있음을 나타내는 https 를 사용하도록 구성됩니다.
18장. 디버그 모드 링크 복사링크가 클립보드에 복사되었습니다!
오버클라우드의 특정 서비스에 대해 DEBUG 수준 로깅 모드를 활성화하고 비활성화할 수 있습니다. 서비스에 대한 디버그 모드를 구성하려면 각 디버그 매개 변수를 설정합니다.
예를 들어 OpenStack Identity(keystone)는 KeystoneDebug 매개 변수를 사용합니다. debug.yaml 환경 파일을 생성하여 디버그 매개 변수를 저장하고 parameter_defaults 섹션에 KeystoneDebug 매개변수를 설정합니다.
parameter_defaults: KeystoneDebug: True
parameter_defaults:
KeystoneDebug: True
KeystoneDebug 매개변수를 True 로 설정하면 /var/log/containers/keystone/keystone.log 표준 keystone 로그 파일이 DEBUG 수준 로그를 사용하여 업데이트됩니다.
디버그 매개변수의 전체 목록은 Overcloud Parameters 가이드의 "Debug Parameters" 를 참조하십시오.
19장. 스토리지 설정 링크 복사링크가 클립보드에 복사되었습니다!
이 장에서는 오버클라우드의 스토리지 옵션을 구성하는 몇 가지 방법에 대해 간단히 설명합니다.
기본적으로 오버클라우드는 OpenStack Storage(cinder)에서 제공하는 OpenStack Compute(nova) 및 LVM 블록 스토리지에서 제공하는 로컬 임시 스토리지를 사용합니다. 그러나 이러한 옵션은 엔터프라이즈급 오버클라우드에서는 지원되지 않습니다. 대신 이 장의 스토리지 옵션 중 하나를 사용합니다.
19.1. NFS 스토리지 구성 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 NFS 공유를 사용하도록 오버클라우드를 구성하는 방법에 대해 설명합니다. 설치 및 구성 프로세스는 코어 heat 템플릿 컬렉션의 기존 환경 파일 수정을 기반으로 합니다.
Red Hat은 인증된 스토리지 백엔드 및 드라이버를 사용하는 것이 좋습니다. 이 기능은 인증된 스토리지 백엔드 및 드라이버에 비해 기능이 제한되기 때문에 일반 NFS 백엔드에서 제공되는 NFS를 사용하지 않는 것이 좋습니다. 예를 들어 일반 NFS 백엔드는 볼륨 암호화 및 볼륨 다중 연결과 같은 기능을 지원하지 않습니다. 지원되는 드라이버에 대한 자세한 내용은 Red Hat Ecosystem Catalog 를 참조하십시오.
NFS 백엔드 또는 NetApp NFS 블록 스토리지 백엔드에서 NAS 보안이라는 NetApp 기능을 지원하는지 여부를 제어하는 여러 director heat 매개변수가 있습니다.
- CinderNetappNasSecureFileOperations
- CinderNetappNasSecureFilePermissions
- CinderNasSecureFileOperations
- CinderNasSecureFilePermissions
Red Hat에서는 정상적인 볼륨 작업을 방해하기 때문에 이 기능을 활성화하지 않는 것이 좋습니다. director는 기본적으로 이 기능을 비활성화하고 Red Hat OpenStack Platform에서는 해당 기능을 지원하지 않습니다.
블록 스토리지 및 계산 서비스의 경우 NFS 버전 4.0 이상을 사용해야 합니다.
코어 heat 템플릿 컬렉션에는 /usr/share/openstack-tripleo-heat-templates/environments/ 에 일련의 환경 파일이 포함되어 있습니다. 이러한 환경 파일을 사용하면 director가 생성한 오버클라우드에서 지원되는 일부 기능에 대한 사용자 지정 구성을 생성할 수 있습니다. 여기에는 스토리지를 구성하도록 설계된 환경 파일이 포함됩니다. 이 파일은 /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml 에 있습니다.
stack사용자의 템플릿 디렉터리에 파일을 복사합니다.cp /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml ~/templates/.
$ cp /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml ~/templates/.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 매개변수를 수정합니다.
- CinderEnableIscsiBackend
-
iSCSI 백엔드를 활성화합니다.
false로 설정합니다. - CinderEnableRbdBackend
-
Ceph Storage 백엔드를 활성화합니다.
false로 설정합니다. - CinderEnableNfsBackend
-
NFS 백엔드를 활성화합니다.
true로 설정합니다. - NovaEnableRbdBackend
-
Nova 임시 스토리지를 위한 Ceph Storage를 활성화합니다.
false로 설정합니다. - GlanceBackend
-
Glance에 사용할 백엔드를 정의합니다. 이미지에
파일기반 스토리지를 사용하려면 파일로 설정합니다. 오버클라우드는 Glance를 위해 마운트된 NFS 공유에 이러한 파일을 저장합니다. - CinderNfsMountOptions
- 볼륨 스토리지의 NFS 마운트 옵션입니다.
- CinderNfsServers
- 볼륨 스토리지에 마운트할 NFS 공유입니다. 예를 들면 192.168.122.1:/export/cinder입니다.
- GlanceNfsEnabled
-
GlanceBackend를file로 설정하면GlanceNfsEnabled를 사용하면 모든 컨트롤러 노드가 이미지에 액세스할 수 있도록 공유 위치에 NFS를 통해 이미지를 저장할 수 있습니다. 비활성화된 경우 오버클라우드는 컨트롤러 노드의 파일 시스템에 이미지를 저장합니다.true로 설정합니다. - GlanceNfsShare
- 이미지 스토리지용으로 마운트할 NFS 공유입니다. 예를 들면 192.168.122.1:/export/glance입니다.
- GlanceNfsOptions
이미지 스토리지의 NFS 마운트 옵션입니다.
환경 파일에는 Red Hat OpenStack Platform 블록 스토리지(cinder) 및 이미지(glance) 서비스에 대한 다양한 스토리지 옵션을 구성하는 매개변수가 포함되어 있습니다. 다음 예제에서는 NFS 공유를 사용하도록 오버클라우드를 구성하는 방법을 보여줍니다.
환경 파일의 옵션은 다음과 유사해야 합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이러한 매개변수는 heat 템플릿 컬렉션의 일부로 통합됩니다. 예제 코드에 표시된 대로 설정하면 블록 스토리지 및 이미지 서비스에서 사용할 두 개의 NFS 마운트 지점이 생성됩니다.
중요이미지 서비스가
/옵션을var/lib 디렉터리에 액세스할 수 있도록 context=system_u:object_r:glance_var_lib_t:s0GlanceNfsOptions매개 변수에 포함합니다. 이 SELinux 콘텐츠가 없으면 이미지 서비스에서 마운트 지점에 쓸 수 없습니다.
- 오버클라우드를 배포할 때 파일을 포함합니다.
19.2. Ceph Storage 구성 링크 복사링크가 클립보드에 복사되었습니다!
director는 Red Hat Ceph Storage를 Overcloud에 통합하는 두 가지 기본 방법을 제공합니다.
- 자체 Ceph Storage 클러스터를 사용하여 오버클라우드 생성
- director는 Overcloud를 생성하는 동안 Ceph Storage 클러스터를 생성할 수 있습니다. director는 Ceph OSD를 사용하여 데이터를 저장하는 Ceph Storage 노드 집합을 생성합니다. 또한 director는 Overcloud의 컨트롤러 노드에 Ceph Monitor 서비스를 설치합니다. 즉, 조직이 세 개의 고가용성 컨트롤러 노드를 사용하여 Overcloud를 생성하면 Ceph 모니터도 고가용성 서비스가 됩니다. 자세한 내용은 Deploying an Overcloud with Containerized Red Hat Ceph 가이드를 참조하십시오.
- 기존 Ceph 스토리지를 오버클라우드에 통합
- 기존 Ceph Storage 클러스터가 이미 있는 경우 오버클라우드 배포 중에 이를 통합할 수 있습니다. 즉, Overcloud 구성 외부에서 클러스터를 관리하고 확장할 수 있습니다. 자세한 내용은 Integrating an Overcloud with an Existing Red Hat Ceph Cluster 가이드를 참조하십시오.
19.3. 외부 오브젝트 스토리지 클러스터 사용 링크 복사링크가 클립보드에 복사되었습니다!
컨트롤러 노드에서 기본 Object Storage 서비스 배포를 비활성화하여 외부 Object Storage(swift) 클러스터를 재사용할 수 있습니다. 이렇게 하면 오브젝트 스토리지의 프록시 및 스토리지 서비스를 모두 비활성화하고 지정된 외부 Swift 엔드포인트를 사용하도록 haproxy 및 keystone을 구성합니다.
외부 Object Storage(swift) 클러스터의 사용자 계정은 직접 관리해야 합니다.
외부 Object Storage 클러스터의 엔드포인트 IP 주소와 외부 Object Storage proxy-server.conf 파일의 authtoken 암호가 필요합니다. openstack endpoint list 명령을 사용하여 이 정보를 찾을 수 있습니다.
외부 Swift 클러스터가 있는 director를 배포하려면 다음을 수행합니다.
다음 콘텐츠를 사용하여
swift-external-params.yaml이라는 새 파일을 생성합니다.-
EXTERNAL.IP:PORT를 외부 프록시의 IP 주소 및 포트로 바꿉니다. AUTHTOKEN을SwiftPassword행의 외부 프록시의authtoken암호로 교체합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
-
이 파일을
swift-external-params.yaml로 저장합니다. 이러한 추가 환경 파일을 사용하여 Overcloud를 배포합니다.
openstack overcloud deploy --templates \ -e [your environment files] -e /usr/share/openstack-tripleo-heat-templates/environments/swift-external.yaml -e swift-external-params.yaml
openstack overcloud deploy --templates \ -e [your environment files] -e /usr/share/openstack-tripleo-heat-templates/environments/swift-external.yaml -e swift-external-params.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.4. 이미지 가져오기 방법 및 공유 스테이징 영역 구성 링크 복사링크가 클립보드에 복사되었습니다!
OpenStack Image 서비스(glance)의 기본 설정은 OpenStack 설치 시 사용되는 Heat 템플릿에 의해 결정됩니다. 이미지 서비스 Heat 템플릿은 tht/puppet/services/glance-api.yaml 입니다.
상호 운용 가능한 이미지 가져오기를 사용하면 두 가지 이미지 가져오기 방법이 있습니다.
- web-download 및
- glance-direct.
web-download 방법을 사용하면 URL에서 이미지를 가져올 수 있습니다. glance-direct 방법을 사용하면 로컬 볼륨에서 이미지를 가져올 수 있습니다.
19.4.1. glance-settings.yaml 파일 생성 및 배포 링크 복사링크가 클립보드에 복사되었습니다!
환경 파일을 사용하여 가져오기 매개 변수를 구성합니다. 이러한 매개변수는 Heat 템플릿에 설정된 기본값을 재정의합니다. 예제 환경 콘텐츠는 상호 운용 가능한 이미지 가져오기에 대한 매개 변수를 제공합니다.
GlanceBackend,GlanceNfsEnabled 및 GlanceNfsShare 매개 변수는 Advanced Overcloud Customization Guide 의 Storage Configuration(스토리지 구성) 섹션에 정의되어 있습니다.
상호 운용 가능한 이미지 가져오기를 위한 두 개의 새 매개 변수는 가져오기 방법과 공유 NFS 스테이징 영역을 정의합니다.
- GlanceEnabledImportMethods
- 사용 가능한 가져오기 방법, web-download(기본값) 및 glance-direct를 정의합니다. 이 행은 web-download 이외의 추가 방법을 활성화하려는 경우에만 필요합니다.
- GlanceStagingNfsShare
- glance-direct 가져오기 방법에서 사용하는 NFS 스테이징 영역을 구성합니다. 이 공간은 고가용성 클러스터 설정의 노드 간에 공유할 수 있습니다. GlanceNfsEnabled를 true로 설정해야 합니다.
설정을 구성하려면 다음을 수행합니다.
- 라는 새 파일을 만듭니다(예: glance-settings.yaml). 이 파일의 내용은 위의 예제와 유사해야 합니다.
openstack overcloud deploy명령을 사용하여 파일을 OpenStack 환경에 추가합니다.openstack overcloud deploy --templates -e glance-settings.yaml
$ openstack overcloud deploy --templates -e glance-settings.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 환경 파일 사용에 대한 자세한 내용은 Advanced Overcloud Customization Guide 의 Overcloud Creation에서 환경 파일 포함 섹션을 참조하십시오.
19.5. 이미지 서비스의 cinder 백엔드 구성 링크 복사링크가 클립보드에 복사되었습니다!
GlanceBackend 매개 변수는 이미지 서비스에서 이미지를 저장하는 데 사용하는 백엔드를 설정합니다.
프로젝트에 대해 생성할 수 있는 기본 최대 볼륨 수는 10입니다.
절차
cinder를 이미지 서비스 백엔드로 구성하려면 환경 파일에 다음을 추가합니다.parameter_defaults: GlanceBackend: cinder
parameter_defaults: GlanceBackend: cinderCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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_auth_address = http://172.17.1.19:5000/v3 cinder_store_project_name = service cinder_store_user_name = glance cinder_store_password = ****secret****Copy to Clipboard Copied! Toggle word wrap Toggle overflow 사용자 정의 사용자 이름 또는
cinder_store_매개변수의 사용자 지정 값을 사용하려면ExtraConfig 설정을 parameter_defaults에 추가하고 사용자 정의 값을 전달합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.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'
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개의 디스크 장치를 연결할 수 있습니다.
19.7. 타사 스토리지 구성 링크 복사링크가 클립보드에 복사되었습니다!
director에는 타사 스토리지 프로바이더를 구성하는 데 도움이 되는 몇 가지 환경 파일이 포함되어 있습니다. 여기에는 다음이 포함됩니다.
- 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에 있습니다.전체 구성 정보는 Dell EMC PS 시리즈 백엔드 가이드를 참조하십시오.
- NetApp Block Storage
NetApp 스토리지 어플라이언스를 블록 스토리지(cinder) 서비스의 백엔드로 배포합니다.
환경 파일은
/usr/share/openstack-tripleo-heat-templates/environments/storage/cinder-netapp-config.yaml에 있습니다.전체 구성 정보는 NetApp 블록 스토리지 백엔드 가이드를 참조하십시오.
20장. 보안 개선 사항 링크 복사링크가 클립보드에 복사되었습니다!
다음 섹션에서는 오버클라우드의 보안을 강화하기 위한 몇 가지 제안 사항을 제공합니다.
20.1. 오버클라우드 방화벽 관리 링크 복사링크가 클립보드에 복사되었습니다!
각 핵심 OpenStack Platform 서비스에는 구성 가능 서비스 템플릿에 방화벽 규칙이 포함되어 있습니다. 이렇게 하면 각 오버클라우드 노드에 대한 기본 방화벽 규칙 세트가 자동으로 생성됩니다.
오버클라우드 Heat 템플릿에는 추가 방화벽 관리에 도움이 되는 매개변수 세트가 포함되어 있습니다.
- ManageFirewall
-
방화벽 규칙을 자동으로 관리할지 여부를 정의합니다. Puppet에서 각 노드에서 방화벽을 자동으로 구성할 수 있도록 하려면
true로 설정합니다. 방화벽을 수동으로 관리하려면false로 설정합니다. 기본값은true입니다. - PurgeFirewallRules
-
새 Linux 방화벽 규칙을 구성하기 전에 기본 Linux 방화벽 규칙을 제거할지 여부를 정의합니다. 기본값은
false입니다.
ManageFirewall 을 true 로 설정하면 배포에 추가 방화벽 규칙을 생성할 수 있습니다. 오버클라우드의 환경 파일에서 구성 후크를 사용하여 tripleo::firewall::firewall_rules hieradata를 설정합니다( 4.5절. “Puppet: 역할에 맞는 Hieradata 사용자 정의”참조). 이 hieradata는 방화벽 규칙 이름과 해당 매개 변수를 키로 포함하는 해시이며, 모두 선택 사항입니다.
- port
- 규칙에 연결된 포트입니다.
- dport
- 규칙에 연결된 대상 포트입니다.
- sport
- 규칙과 연결된 소스 포트입니다.
- Proto
-
규칙과 연결된 프로토콜입니다. 기본값은
tcp입니다. - 작업
-
규칙과 연결된 작업 정책입니다. 기본값은
accept입니다. - 건너뛰기
-
로 이동할 체인입니다. 있는 경우
작업을재정의합니다. - 상태
-
규칙과 관련된 상태 배열입니다. 기본값은
['NEW']입니다. - 소스
- 규칙과 연결된 소스 IP 주소입니다.
- iniface
- 규칙에 연결된 네트워크 인터페이스입니다.
- 체인
-
규칙과 연결된 체인입니다. 기본값은
INPUT입니다. - 대상
- 규칙에 연결된 대상 CIDR입니다.
다음 예제에서는 방화벽 규칙 형식의 구문을 보여줍니다.
이는 ExtraConfig 를 통해 모든 노드에 2개의 추가 방화벽 규칙을 적용합니다.
각 규칙 이름은 해당 iptables 규칙의 주석이 됩니다. 또한 각 규칙 이름은 3자리 접두사로 시작되어 Puppet이 최종 iptables 파일에서 정의된 모든 규칙을 정렬하는 데 도움이 됩니다. 기본 OpenStack Platform 규칙은 000~200 범위의 접두사를 사용합니다.
20.2. SNMP(Simple Network Management Protocol) 문자열 변경 링크 복사링크가 클립보드에 복사되었습니다!
director는 오버클라우드에 대한 기본 읽기 전용 SNMP 설정을 제공합니다. 네트워크 장치에 대해 학습하는 권한이 없는 사용자의 위험을 완화하도록 SNMP 문자열을 변경하는 것이 좋습니다.
오버클라우드의 환경 파일에서 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
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
parameter_defaults:
ExtraConfig:
snmp::com2sec: mysecurestring
snmp::com2sec6: myv6securestring
그러면 모든 노드에서 읽기 전용 SNMP 커뮤니티 문자열이 변경됩니다.
자세한 내용은 the snmpd.conf 도움말 페이지를 참조하십시오.
20.3. HAProxy에 대한 SSL/TLS 암호화 방식 및 규칙 변경 링크 복사링크가 클립보드에 복사되었습니다!
오버클라우드에서 SSL/TLS를 활성화한 경우( 15장. 오버클라우드 공개 엔드 포인트에서 SSL/TLS 활성화참조) HAProxy 설정에 사용되는 SSL/TLS 암호화 방식 및 규칙을 강화할 수 있습니다. 이는 POODLE 취약점과 같은 SSL/TLS 취약점을 방지하는 데 도움이 됩니다.
오버클라우드의 환경 파일에서 ExtraConfig 후크를 사용하여 다음 hieradata를 설정합니다.
- tripleo::haproxy::ssl_cipher_suite
- HAProxy에서 사용할 암호화 방식 세트입니다.
- tripleo::haproxy::ssl_options
- HAProxy에서 사용할 SSL/TLS 규칙입니다.
예를 들면 다음 암호화 방식 및 규칙을 사용할 수 있습니다.
-
암호:
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA -AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256 :ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE- ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE- ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES128-SHA256:A ES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS -
규칙:
no-sslv3 no-tls-tickets
다음 콘텐츠를 사용하여 환경 파일을 생성합니다.
parameter_defaults:
ExtraConfig:
tripleo::haproxy::ssl_cipher_suite: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
tripleo::haproxy::ssl_options: no-sslv3 no-tls-tickets
parameter_defaults:
ExtraConfig:
tripleo::haproxy::ssl_cipher_suite: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
tripleo::haproxy::ssl_options: no-sslv3 no-tls-tickets
암호화 방식 컬렉션은 연속된 한 행으로 되어 있습니다.
오버클라우드 생성을 통해 이 환경 파일을 포함합니다.
20.4. Open vSwitch 방화벽 사용 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat OpenStack Platform director에서 OVS(Open vSwitch) 방화벽 드라이버를 사용하도록 보안 그룹을 구성할 수 있습니다. NeutronOVSFirewallDriver 매개변수를 사용하면 사용할 방화벽 드라이버를 지정할 수 있습니다.
-
iptables_hybrid- iptables/하이브리드 기반 구현을 사용하도록 neutron을 구성합니다. -
openvswitch- OVS 방화벽 흐름 기반 드라이버를 사용하도록 neutron을 구성합니다.
openvswitch 방화벽 드라이버는 성능이 향상되고 게스트를 프로젝트 네트워크에 연결하는 데 사용되는 인터페이스 및 브리지 수를 줄입니다.
멀티캐스트 트래픽은 iptables 방화벽 드라이버와 OVS(Open vSwitch) 방화벽 드라이버에서 다르게 처리됩니다. 기본적으로 iptables를 사용하면 VRRP 트래픽이 거부되며 VRRP 트래픽이 끝점에 도달하기 위해 보안 그룹 규칙에서 VRRP를 활성화해야 합니다. OVS에서는 모든 포트가 동일한 OpenFlow 컨텍스트를 공유하며, 멀티캐스트 트래픽을 포트당 개별적으로 처리할 수 없습니다. 보안 그룹은 모든 포트(예: 라우터의 포트)에 적용되지 않으므로 OVS는 NORMAL 작업을 사용하고 RFC 4541에서 지정하는 모든 포트에 멀티캐스트 트래픽을 전달합니다.
iptables_hybrid 옵션은 OVS-DPDK와 호환되지 않습니다.
network-environment.yaml 파일에서
NeutronOVSFirewallDriver 매개변수를 구성합니다.
NeutronOVSFirewallDriver: openvswitch
NeutronOVSFirewallDriver: openvswitch
-
NeutronOVSFirewallDriver: 보안 그룹을 구현할 때 사용할 방화벽 드라이버의 이름을 구성합니다. 가능한 값은 시스템 구성에 따라 다릅니다. 예를 들면noop,openvswitch,iptables_hybrid가 있습니다. 기본값은iptables_hybrid에 해당하는 빈 문자열입니다.
20.5. 보안 루트 사용자 액세스 사용 링크 복사링크가 클립보드에 복사되었습니다!
Overcloud 이미지에는 root 사용자의 강화된 보안이 자동으로 포함되어 있습니다. 예를 들어 배포된 각 Overcloud 노드는 root 사용자에 대한 직접 SSH 액세스를 자동으로 비활성화합니다. 다음 방법을 통해 오버클라우드 노드에서 root 사용자에게 계속 액세스할 수 있습니다.
-
Undercloud 노드의
stack사용자에 로그인합니다. -
각 오버클라우드 노드에는
heat-admin사용자 계정이 있습니다. 이 사용자 계정에는 언더클라우드의 공용 SSH 키가 포함되어 있으며, 언더클라우드에서 오버클라우드 노드로의 암호 없이 SSH 액세스를 제공합니다. 언더클라우드 노드에서heat-admin사용자를 사용하여 SSH를 통해 선택한 Overcloud 노드에 로그인합니다. -
sudo -i를 사용하여root 사용자로 전환합니다.
루트 사용자 보안 감소
일부 상황에는 root 사용자에 대한 직접 SSH 액세스가 필요할 수 있습니다. 이 경우 각 오버클라우드 노드의 root 사용자에 대한 SSH 제한 사항을 줄일 수 있습니다.
이 메서드는 디버깅 목적으로만 사용됩니다. 프로덕션 환경에서는 사용하지 않는 것이 좋습니다.
방법은 첫 번째 부팅 구성 후크를 사용합니다( 4.1절. “첫 번째 부팅: 첫 번째 부팅 구성 사용자 정의”참조). 환경 파일에 다음 콘텐츠를 배치합니다.
resource_registry: OS::TripleO::NodeUserData: /usr/share/openstack-tripleo-heat-templates/firstboot/userdata_root_password.yaml parameter_defaults: NodeRootPassword: "p@55w0rd!"
resource_registry:
OS::TripleO::NodeUserData: /usr/share/openstack-tripleo-heat-templates/firstboot/userdata_root_password.yaml
parameter_defaults:
NodeRootPassword: "p@55w0rd!"
다음을 확인합니다.
-
OS::TripleO::NodeUserData리소스는 첫 번째 부팅cloud-init단계에서root사용자를 구성하는 템플릿을 참조합니다. -
NodeRootPassword매개 변수는root사용자의 암호를 설정합니다. 이 매개 변수의 값을 원하는 암호로 변경합니다. 환경 파일에는 보안 위험으로 간주되는 일반 텍스트 문자열로 암호가 포함되어 있습니다.
오버클라우드 생성 시 openstack overcloud deploy 명령을 사용하여 이 환경 파일을 포함합니다.
21장. 네트워크 플러그인 구성 링크 복사링크가 클립보드에 복사되었습니다!
director에는 타사 네트워크 플러그인을 설정하는 데 도움이 되는 환경 파일이 포함되어 있습니다.
21.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/
$ cp /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-cfab.yaml /home/stack/templates/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 절대 경로를 사용하도록
resource_registry를 편집합니다.resource_registry: OS::TripleO::Services::NeutronML2FujitsuCfab: /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-plugin-ml2-fujitsu-cfab.yaml
resource_registry: OS::TripleO::Services::NeutronML2FujitsuCfab: /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-plugin-ml2-fujitsu-cfab.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow /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] ...
$ openstack overcloud deploy --templates -e /home/stack/templates/neutron-ml2-fujitsu-cfab.yaml [OTHER OPTIONS] ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
21.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/
$ cp /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-fossw.yaml /home/stack/templates/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 절대 경로를 사용하도록
resource_registry를 편집합니다.resource_registry: OS::TripleO::Services::NeutronML2FujitsuFossw: /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-plugin-ml2-fujitsu-fossw.yaml
resource_registry: OS::TripleO::Services::NeutronML2FujitsuFossw: /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-plugin-ml2-fujitsu-fossw.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow /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] ...
$ openstack overcloud deploy --templates -e /home/stack/templates/neutron-ml2-fujitsu-fossw.yaml [OTHER OPTIONS] ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22장. ID 구성 링크 복사링크가 클립보드에 복사되었습니다!
director에는 ID 서비스(keystone) 설정을 구성하는 데 도움이 되는 매개변수가 포함되어 있습니다.
22.1. 지역 이름 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 오버클라우드의 리전 이름은 regionOne 으로 지정됩니다. 환경 파일을 KeystoneRegion 항목을 추가하여 변경할 수 있습니다. 이 설정은 배포 후 변경할 수 없습니다.
parameter_defaults: KeystoneRegion: 'SampleRegion'
parameter_defaults:
KeystoneRegion: 'SampleRegion'
23장. 기타 구성 링크 복사링크가 클립보드에 복사되었습니다!
23.1. 오버클라우드 노드에서 커널 구성 링크 복사링크가 클립보드에 복사되었습니다!
OpenStack Platform director에는 오버클라우드 노드에서 커널을 구성하는 매개변수가 포함되어 있습니다.
- ExtraKernelModules
로드할 커널 모듈. 모듈 이름은 빈 값이 있는 해시 키로 나열됩니다.
ExtraKernelModules: <MODULE_NAME>: {}ExtraKernelModules: <MODULE_NAME>: {}Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ExtraKernelPackages
ExtraKernelModule에서 커널 모듈을 로드하기 전에 설치할 커널 관련 패키지입니다. 패키지 이름은 빈 값을 사용하여 해시 키로 나열됩니다.ExtraKernelPackages: <PACKAGE_NAME>: {}ExtraKernelPackages: <PACKAGE_NAME>: {}Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ExtraSysctlSettings
적용할 sysctl 설정 해시입니다. value 키를 사용하여 각 매개 변수의
값을 설정합니다.ExtraSysctlSettings: <KERNEL_PARAMETER>: value: <VALUE>ExtraSysctlSettings: <KERNEL_PARAMETER>: value: <VALUE>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
이 예에서는 환경 파일에서 이러한 매개변수의 구문을 보여줍니다.
23.2. 외부 로드 밸런싱 구성 링크 복사링크가 클립보드에 복사되었습니다!
Overcloud는 여러 컨트롤러를 고가용성 클러스터로 함께 사용하여 OpenStack 서비스의 운영 성능을 극대화합니다. 또한 클러스터에서 OpenStack 서비스에 액세스할 수 있는 부하 분산을 제공하여 컨트롤러 노드에 트래픽을 균등하게 분산하고 각 노드의 서버 과부하를 줄입니다. 외부 로드 밸런서를 사용하여 이 배포를 수행할 수도 있습니다. 예를 들어 조직에서 자체 하드웨어 기반 로드 밸런서를 사용하여 컨트롤러 노드에 대한 트래픽 배포를 처리할 수 있습니다.
외부 로드 밸런싱 구성에 대한 자세한 내용은 전체 지침은 Overcloud 전용 External Load Balancing 가이드를 참조하십시오.
23.3. IPv6 네트워킹 구성 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 Overcloud는 IPv4)를 사용하여 서비스 엔드포인트를 구성합니다. 그러나 Overcloud는 IPv6 인프라를 지원하는 조직에 유용한 IPv6) 엔드포인트도 지원합니다. director에는 IPv6 기반 오버클라우드 생성에 도움이 되는 환경 파일 세트가 포함되어 있습니다.
Overcloud에서 IPv6 구성에 대한 자세한 내용은 전용 IPv6 네트워킹 for the Overcloud 가이드를 참조하십시오.