Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
6장. CLI 툴로 기본 오버클라우드 설정
이 장에서는 CLI 툴을 사용하는 OpenStack Platform 환경의 기본적인 설정 단계를 설명합니다. 기본 설정을 사용하는 오버클라우드에는 사용자 지정 기능이 포함되어 있지 않지만 고급 구성 옵션을 이 기본 오버클라우드에 추가하고 Advanced Overcloud Customization 가이드의 지침을 사용하여 사양에 맞게 사용자 지정할 수 있습니다.
6.1. 오버클라우드에 노드 등록
director에는 수동으로 만든 노드 정의 템플릿이 있어야 합니다. 이 파일은 JSON 포맷 및 YAML 포맷을 사용하고, 노드의 하드웨어 및 전원 관리 세부 정보가 포함되어 있습니다.
절차
노드를 나열하는 템플릿을 작성합니다. 예를 들어 JSON 포맷으로 된 템플릿은 다음과 같습니다.
{ "nodes":[ { "mac":[ "bb:bb:bb:bb:bb:bb" ], "name":"node01", "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.168.24.205" }, { "mac":[ "cc:cc:cc:cc:cc:cc" ], "name":"node02", "cpu":"4", "memory":"6144", "disk":"40", "arch":"x86_64", "pm_type":"ipmi", "pm_user":"admin", "pm_password":"p@55w0rd!", "pm_addr":"192.168.24.206" } ] }
YAML로 된 유사한 노드 템플릿의 예는 다음과 같습니다.
nodes: - mac: - "bb:bb:bb:bb:bb:bb" name: "node01" cpu: 4 memory: 6144 disk: 40 arch: "x86_64" pm_type: "ipmi" pm_user: "admin" pm_password: "p@55w0rd!" pm_addr: "192.168.24.205" - mac: - cc:cc:cc:cc:cc:cc name: "node02" cpu: 4 memory: 6144 disk: 40 arch: "x86_64" pm_type: "ipmi" pm_user: "admin" pm_password: "p@55w0rd!" pm_addr: "192.168.24.206"
이 템플릿은 다음 속성을 사용합니다.
- name
- 노드의 논리 이름입니다.
- pm_type
사용할 전원 관리 드라이버입니다. 이 예에서는 전원 관리의 기본 드라이버인 IPMI 드라이버(
ipmi
)를 사용합니다.참고IPMI는 지원되는 기본 전원 관리 드라이버입니다. 지원되는 추가 전원 관리 유형 및 옵션은 부록 B. 전원 관리 드라이버를 참조하십시오. 이러한 전원 관리 드라이버가 예상대로 작동하지 않는 경우 전원 관리에 IPMI를 사용하십시오.
- pm_user; pm_password
- IPMI 사용자 이름 및 암호입니다.
- pm_addr
- IPMI 장치의 IP 주소입니다.
- mac
- (선택 사항) 노드에 있는 네트워크 인터페이스의 MAC 주소 목록입니다. 각 시스템의 프로비저닝 NIC에는 MAC 주소만 사용합니다.
- cpu
- (선택 사항) 노드에 있는 CPU 수입니다.
- memory
- (선택 사항) 메모리 크기(MB)입니다.
- disk
- (선택 사항) 하드 디스크의 크기(GB)입니다.
- arch
(선택 사항) 시스템 아키텍처입니다.
중요다중 아키텍처 클라우드를 빌드하는 경우
x86_64
및ppc64le
아키텍처를 사용하여 노드를 구분하려면arch
키가 필요합니다.
템플릿을 생성한 후 파일을
stack
사용자의 홈 디렉터리(/home/stack/nodes.json
)에 저장하고 다음 명령을 사용하여 director로 가져옵니다.$ source ~/stackrc (undercloud) $ openstack overcloud node import ~/nodes.json
이 명령으로 템플릿을 가져와서 템플릿의 각 노드가 director에 등록됩니다.
노드 등록 및 설정이 완료되면 CLI에서 이러한 노드 목록을 확인합니다.
(undercloud) $ openstack baremetal node list
6.2. 노드의 하드웨어 검사
director는 각 노드에서 인트로스펙션 프로세스를 실행할 수 있습니다. 이 프로세스를 실행하면 각 노드가 PXE를 통해 인트로스펙션 에이전트가 부팅됩니다. 이 에이전트는 노드에서 하드웨어 데이터를 수집하여 director에 다시 보냅니다. 그러면 director에서 이 인트로스펙션 데이터를 director에서 실행되는 OpenStack Object Storage(swift) 서비스에 저장합니다. director는 프로필 태그, 벤치마킹 및 root 디스크 수동 할당과 같은 여러 목적에 하드웨어 정보를 사용합니다.
절차
다음 명령을 실행하여 각 노드의 하드웨어 속성을 확인합니다.
(undercloud) $ openstack overcloud node introspect --all-manageable --provide
-
--all-manageable
옵션은 관리되는 상태의 노드만 인트로스펙션합니다. 이 예에서는 모든 노드가 해당됩니다. -
--provide
옵션은 인트로스펙션 이후 모든 노드를available
상태로 리셋합니다.
-
다른 터미널 창에서 다음 명령을 사용하여 인트로스펙션 진행 상황을 모니터링합니다.
(undercloud) $ sudo journalctl -l -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasq -u openstack-ironic-conductor -f
중요이 프로세스가 완료되었는지 확인합니다. 베어 메탈 노드의 경우 이 프로세스는 일반적으로 15분 정도 걸립니다.
-
인트로스펙션이 완료되면 모든 노드가
available
상태로 변경됩니다.
6.3. 프로필에 노드 태그
각 노드의 하드웨어 등록 및 검사 후 특정 프로필에 노드를 태그합니다. 이러한 프로파일 태그는 노드가 플레이버에 일치된 다음 해당 플레이버가 배포 역할에 할당됩니다. 다음 예는 Controller 노드에 대한 역할, 플레이버, 프로파일 및 노드 사이의 관계를 보여줍니다.
유형 | 설명 |
---|---|
역할 |
|
플레이버 |
|
프로파일 |
|
노드 |
또한 |
기본 프로파일 플레이버 compute
, control
, swift-storage
, ceph-storage
, block-storage
는 언더클라우드 설치 중에 생성되며, 대부분의 환경에서 변경 없이 사용할 수 있습니다.
절차
노드를 특정 프로파일에 태그하려면
profile
옵션을 각 노드의properties/capabilities
매개 변수에 추가합니다. 예를 들어 노드를 Controller 및 Compute 프로파일에 각각 태그하려면 다음 명령을 사용합니다.(undercloud) $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13 (undercloud) $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
profile:compute
및profile:control
옵션을 추가하면 두 개의 노드가 각각 해당하는 프로파일에 태그됩니다.이러한 명령은 각 노드를 부팅하는 방법을 정의하는
boot_option:local
매개 변수도 설정합니다.노드 태그를 완료한 후 할당된 프로파일 또는 가능한 프로파일을 확인합니다.
(undercloud) $ openstack overcloud profiles list
6.4. UEFI 부팅 모드 설정
기본 부팅 모드는 기존 BIOS 모드입니다. 최신 시스템에는 기존 BIOS 모드 대신 UEFI 부팅 모드가 필요할 수 있습니다. 다음 단계를 사용하여 UEFI 모드로 변경합니다.
절차
undercloud.conf
파일에 다음 매개 변수를 설정합니다.ipxe_enabled = True inspection_enable_uefi = True
이 파일을 저장하고 언더클라우드 설치를 실행합니다.
$ openstack undercloud install
설치 스크립트가 완료될 때까지 기다리십시오.
등록된 각 노드의 부팅 모드를
uefi
로 설정합니다. 예를 들어capabilities
속성에서 기존boot_mode
매개 변수를 추가 또는 교체하려면 다음 명령을 실행합니다.$ NODE=<NODE NAME OR ID> ; openstack baremetal node set --property capabilities="boot_mode:uefi,$(openstack baremetal node show $NODE -f json -c properties | jq -r .properties.capabilities | sed "s/boot_mode:[^,]*,//g")" $NODE
참고profile
및boot_option
기능이 유지되고 있는지 확인합니다.+
$ openstack baremetal node show r530-12 -f json -c properties | jq -r .properties.capabilities
각 플레이버의 부팅 모드를
uefi
로 설정합니다.$ openstack flavor set --property capabilities:boot_mode='uefi' control
6.5. 노드의 root 디스크 정의
일부 노드에서는 여러 디스크를 사용할 수 있습니다. 이러한 경우 director에서 프로비저닝 중에 root 디스크에 사용할 디스크를 확인해야 합니다. director가 프로비저닝 프로세스 중 root 디스크에 QCOW2 overcloud-full
이미지를 작성합니다.
director가 root 디스크를 쉽게 식별할 수 있도록 다음과 같은 속성을 사용할 수 있습니다.
-
model
(문자열): 장치 식별자 -
vendor
(문자열): 장치 벤더 -
serial
(문자열): 디스크 일련 번호 -
hctl
(문자열): Host:Channel:Target:Lun (SCSI 용) -
size
(정수): 장치의 크기(GB 단위) -
wwn
(문자열): 고유한 스토리지 식별자 -
wwn_with_extension
(문자열): 벤더 확장이 첨부된 고유한 스토리지 식별자 -
wwn_vendor_extension
(문자열): 고유한 벤더 스토리지 식별자 -
rotational
(부울): 회전 장치인 경우(HDD) True, 그렇지 않은 경우 false(SSD) -
name
(문자열): 장치의 이름(예: /dev/sdb1)
name
은 영구적인 이름이 있는 장치에만 사용합니다. 노드가 부팅될 때 값이 변경될 수 있으므로 name
을 사용하여 다른 장치에 대해 root 디스크를 설정하지 마십시오.
이 예에서는 일련 번호를 사용하여 root 디바이스를 지정하는 방법을 보여줍니다.
절차
각 노드의 하드웨어 인트로스펙션에서 디스크 정보를 확인합니다. 다음 명령은 노드의 디스크 정보를 표시합니다.
(undercloud) $ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"
예를 들면 하나의 노드의 데이터에서 세 개의 디스크가 표시될 수 있습니다.
[ { "size": 299439751168, "rotational": true, "vendor": "DELL", "name": "/dev/sda", "wwn_vendor_extension": "0x1ea4dcc412a9632b", "wwn_with_extension": "0x61866da04f3807001ea4dcc412a9632b", "model": "PERC H330 Mini", "wwn": "0x61866da04f380700", "serial": "61866da04f3807001ea4dcc412a9632b" } { "size": 299439751168, "rotational": true, "vendor": "DELL", "name": "/dev/sdb", "wwn_vendor_extension": "0x1ea4e13c12e36ad6", "wwn_with_extension": "0x61866da04f380d001ea4e13c12e36ad6", "model": "PERC H330 Mini", "wwn": "0x61866da04f380d00", "serial": "61866da04f380d001ea4e13c12e36ad6" } { "size": 299439751168, "rotational": true, "vendor": "DELL", "name": "/dev/sdc", "wwn_vendor_extension": "0x1ea4e31e121cfb45", "wwn_with_extension": "0x61866da04f37fc001ea4e31e121cfb45", "model": "PERC H330 Mini", "wwn": "0x61866da04f37fc00", "serial": "61866da04f37fc001ea4e31e121cfb45" } ]
이 예에서는 root 디바이스를 일련 번호가
61866da04f380d001ea4e13c12e36ad6
인 disk 2로 설정하는 방법을 보여줍니다. 이를 위해 노드 정의에서root_device
매개 변수를 변경해야 합니다.(undercloud) $ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
참고선택한 root 디스크에서 부팅을 포함하도록 각 노드의 BIOS를 설정합니다. 권장 부팅 순서는 네트워크 부팅, root 디스크 부팅 순입니다.
6.6. 아키텍처별 역할 생성
다중 아키텍처 클라우드를 빌드하는 경우 모든 아키텍처별 역할을 roles_data.yaml
에 추가해야 합니다. 다음 예에서는 기본 역할과 함께 ComputePPC64LE
역할을 포함합니다. 역할에 대한 내용은 Creating a Custom Role File 섹션을 참조하십시오.
openstack overcloud roles generate \ --roles-path /usr/share/openstack-tripleo-heat-templates/roles -o ~/templates/roles_data.yaml \ Controller Compute ComputePPC64LE BlockStorage ObjectStorage CephStorage
6.7. 환경 파일
언더클라우드에는 오버클라우드 생성 플랜 기능을 하는 Heat 템플릿 세트가 포함되어 있습니다. 코어 Heat 템플릿 컬렉션의 매개 변수와 리소스를 덮어쓰는 YAML 포맷의 파일인 환경 파일을 사용하여 오버클라우드의 특정 부분을 사용자 지정할 수 있습니다. 필요한 만큼 많은 환경 파일을 추가할 수 있지만, 차후에 실행되는 환경 파일에 정의된 매개 변수와 리소스가 우선순위를 갖기 때문에 환경 파일의 순서가 중요합니다. 다음 목록을 환경 파일 순서의 예로 사용하십시오.
- 각 역할 및 해당 플레이버당 노드의 크기입니다. 오버클라우드 생성에 이 정보를 포함하는 것이 중요합니다.
- 컨테이너화된 OpenStack 서비스의 컨테이너 이미지 위치입니다.
-
heat 템플릿 컬렉션의 초기화 파일(
environments/network-isolation.yaml
) 부터 시작하여 네트워크 분리 파일, 사용자 정의 NIC 설정 파일, 마지막으로 추가 네트워크 설정 순입니다. - 모든 외부 로드 밸런싱 환경 파일
- Ceph Storage, NFS, iSCSI 등과 같은 스토리지 환경 파일
- Red Hat CDN 또는 Satellite 등록의 환경 파일
- 기타 사용자 정의 환경 파일
사용자 지정 환경 파일을 templates
디렉터리와 같은 별도의 디렉터리에 구성하는 것이 좋습니다.
Advanced Overcloud Customization 가이드를 사용하여 오버클라우드의 고급 기능을 사용자 지정할 수 있습니다.
기본 오버클라우드는 블록 스토리지에 지원되지 않는 구성인 로컬 LVM 스토리지를 사용합니다. 블록 스토리지에 Red Hat Ceph Storage와 같은 외부 스토리지 솔루션을 사용하는 것이 좋습니다.
다음의 몇 섹션에서는 오버클라우드에 필요한 환경을 만드는 방법에 대해 설명합니다.
6.8. 노드 수 및 플레이버를 정의하는 환경 만들기
기본적으로 director는 baremetal
플레이버를 사용하여 컨트롤러 노드와 계산 노드 각 1개를 배포합니다. 그러나 이는 개념 검증을 위한 배포에만 적합합니다. 노드와 플레이버 수를 다르게 지정하여 기본 구성을 덮어쓸 수 있습니다. 소규모 프로덕션 환경의 경우 3개 이상의 컨트롤러 노드와 계산 노드 3개를 보유하고 특정 플레이버를 할당하여 노드를 적절한 리소스 사양으로 만들어야 하는 경우가 있을 수 있습니다. 다음 절차에서는 노드 수와 플레이버 할당을 저장하는 node-info.yaml
이라는 환경 파일을 만드는 방법을 보여줍니다.
절차
/home/stack/templates/
디렉터리에node-info.yaml
파일을 생성합니다.(undercloud) $ touch /home/stack/templates/node-info.yaml
필요한 노드 수 및 플레이버를 포함하도록 파일을 편집합니다. 이 예에서는 컨트롤러 노드 3개, 컴퓨팅 노드 3개, Ceph Storage 노드 3개를 배포합니다.
parameter_defaults: OvercloudControllerFlavor: control OvercloudComputeFlavor: compute ControllerCount: 3 ComputeCount: 3
6.9. 언더클라우드 CA를 신뢰하는 환경 파일 생성
언더클라우드에서 TLS를 사용하고 CA가 공개적으로 신뢰되지 않는 경우 다음 절차를 따라야 합니다. 언더클라우드는 SSL 끝점 암호화에 대해 고유의 인증 기관(CA)을 운영합니다. 언더클라우드 끝점에서 나머지 배포에 액세스할 수 있도록 하려면 오버클라우드 노드가 언더클라우드 CA를 신뢰하도록 구성하십시오.
이 접근법이 작동하려면 오버클라우드 노드에 언더클라우드의 공개 끝점에 대한 네트워크 경로가 있어야 합니다. 스파인-리프형 네트워킹을 사용하는 배포에는 이러한 설정을 적용해야 합니다.
다음은 언더클라우드에서 사용할 수 있는 두 가지 유형의 사용자 지정 인증서입니다.
-
사용자 제공 인증서 - 이 정의는 사용자가 자체 인증서를 제공 한 경우 적용됩니다. 자신의 CA에서 가져온 것이거나 자체 서명된 것일 수 있습니다.
undercloud_service_certificate
옵션을 사용하여 전달되며, 이 경우 배포에 따라 자체 서명 인증서 또는 CA를 신뢰해야 합니다. -
자동 생성 인증서 - 이 정의는
certmonger
를 사용하여 자체 로컬 CA를 사용하여 인증서를 생성할 때 적용됩니다. 이는generate_service_certificate
옵션을 사용하여 활성화됩니다. 이 예에서는 CA 인증서(/etc/pki/ca-trust/source/anchors/cm-local-ca.pem
)가 있고, 언더클라우드의 HAProxy 인스턴스가 사용하는 서버 인증서가 있습니다. 이 인증서를 OpenStack에 제공하려면inject-trust-anchor-hiera.yaml
파일에 CA 인증서를 추가해야 합니다.
절차
이 예에서는 /home/stack/ca.crt.pem
에 있는 자체 서명 인증서를 사용합니다. 자동 생성 인증서를 사용하는 경우 대신 /etc/pki/ca-trust/source/anchors/cm-local-ca.pem
을 사용하십시오.
인증서 파일을 열고 인증서 부분만 복사합니다. 키를 포함하지 마십시오.
$ vi /home/stack/ca.crt.pem
필요한 인증서 부분은 다음의 단축된 예와 비슷합니다.
-----BEGIN CERTIFICATE----- MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3 -----END CERTIFICATE-----
다음 내용으로
/home/stack/inject-trust-anchor-hiera.yaml
이라는 새 YAML 파일을 만들고, PEM 파일에서 복사한 인증서를 추가합니다.parameter_defaults: CAMap: ... undercloud-ca: content: | -----BEGIN CERTIFICATE----- MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3 -----END CERTIFICATE-----
참고인증서 문자열이 PEM 형식을 따라야 합니다.
오버클라우드를 배포하는 동안 CA 인증서가 각 오버클라우드 노드에 복사되어 언더클라우드의 SSL 끝점에서 제공하는 암호화를 신뢰하게 됩니다. 환경 파일을 포함하는 방법에 대한 자세한 내용은 6.12절. “오버클라우드 배포에 환경 파일 포함”을 참조하십시오.
6.10. 배포 명령
OpenStack 환경 생성의 최종 단계는 openstack overcloud deploy
명령을 실행하여 이 환경을 생성하는 것입니다. 이 명령을 실행하기 전에 주요 옵션 및 사용자 지정 환경 파일을 포함하는 방법을 숙지하고 있어야 합니다.
openstack overcloud deploy
를 백그라운드 프로세스로 실행하지 마십시오. 백그라운드 프로세스로 시작한 경우 오버클라우드 생성이 배포 도중 중단될 수 있습니다.
6.11. 배포 명령 옵션
다음 표에는 openstack overcloud deploy
명령을 사용할 때의 추가 매개 변수가 나열되어 있습니다.
표 6.1. 배포 명령 옵션
매개 변수 | 설명 |
---|---|
|
배포할 Heat 템플릿이 포함된 디렉터리. 비어 있을 경우 이 명령은 |
|
생성하거나 업데이트할 스택의 이름 |
|
배포 제한 시간(분) |
|
하이퍼바이저에 사용할 가상화 유형 |
|
시간 동기화에 사용할 NTP(Network Time Protocol) 서버. 콤마로 구분된 목록에 여러 개의 NTP 서버를 지정할 수도 있습니다(예: |
|
환경 변수 no_proxy의 사용자 정의 값을 정의합니다. 이 변수는 프록시 통신에서 특정 호스트 이름을 제외합니다. |
|
오버클라우드 노드에 액세스할 SSH 사용자를 정의합니다. 일반적으로 SSH 액세스는 |
|
오버클라우드 배포에 전달할 추가 환경 파일입니다. 두 번 이상 지정할 수 있습니다. |
|
배포에 포함할 환경 파일이 들어 있는 디렉터리. 이 명령은 이러한 환경 파일을 먼저 숫자 순으로 처리한 다음 알파벳 순으로 처리합니다. |
|
오버클라우드 생성 프로세스에서는 일련의 사전 배포 검사를 수행합니다. 이 옵션은 사전 배포 검사에서 치명적이지 않은 오류가 발생할 경우에만 종료됩니다. 오류가 있으면 배포에 실패할 수 있으므로 이 옵션을 사용하는 것이 좋습니다. |
|
오버클라우드 생성 프로세스는 일련의 사전 배포 검사를 수행합니다. 이 옵션은 사전 배포 검사에서 심각하지 않은 경고가 발생할 경우에만 종료됩니다. |
|
오버클라우드에서 검증 확인을 수행하지만, 오버클라우드를 실제로 생성하지는 않습니다. |
|
오버클라우드 배포 후 설정을 건너뜁니다. |
|
오버클라우드 배포 후 설정을 강제 적용합니다. |
|
|
|
인수 및 매개 변수를 사용한 YAML 파일의 경로입니다. |
|
오버클라우드 노드를 고객 포털 또는 Satellite 6에 등록합니다. |
|
오버클라우드 노드에 사용할 등록 방법입니다. Red Hat Satellite 6 또는 Red Hat Satellite 5에는 |
|
등록에 사용할 조직입니다. |
|
시스템이 이미 등록되어 있어도 등록합니다. |
|
오버클라우드 노드를 등록할 Satellite 서버의 기본 URL입니다. Satellite의 HTTPS URL 대신 HTTP URL을 이 매개 변수에 사용합니다. 예를 들어 https://satellite.example.com 대신 http://satellite.example.com을 사용합니다. 오버클라우드 생성 프로세스에서는 이 URL을 사용하여 서버가 Red Hat Satellite 5 서버인지 아니면 Red Hat Satellite 6 서버인지 확인합니다. Red Hat Satellite 6 서버인 경우 오버클라우드는 |
|
등록에 사용할 활성화 키입니다. |
전체 옵션 목록을 표시하려면 다음 명령을 실행하십시오.
(undercloud) $ openstack help overcloud deploy
일부 명령행 매개 변수는 오래되거나 더 이상 사용되지 않으며, 대신 환경 파일의 parameter_defaults
섹션에 포함하는 Heat 템플릿 매개 변수가 사용됩니다. 다음 테이블에는 더 이상 사용되지 않는 매개 변수가 그에 상응하는 Heat 템플릿 매개 변수에 매핑되어 있습니다.
표 6.2. 더 이상 사용되지 않는 CLI 매개 변수와 상응하는 Heat 템플릿 매개 변수의 매핑
매개 변수 | 설명 | Heat 템플릿 매개 변수 |
---|---|---|
|
확장할 Controller 노드 수 |
|
|
확장할 Compute 노드 수 |
|
|
확장할 Ceph Storage 노드 수 |
|
|
확장할 Cinder 노드 수 |
|
|
확장할 Swift 노드 수 |
|
|
Controller 노드에 사용할 플레이버 |
|
|
Compute 노드에 사용할 플레이버 |
|
|
Ceph Storage 노드에 사용할 플레이버 |
|
|
Cinder 노드에 사용할 플레이버 |
|
|
Swift Storage 노드에 사용할 플레이버 |
|
|
neutron 플러그인에 설정할 플랫 네트워크를 정의합니다. 외부 네트워크 생성을 허용하도록 기본적으로 "datacentre"로 설정됩니다. |
|
|
각 하이퍼바이저에 생성할 Open vSwitch 브리지. 기본값은 "br-ex"입니다. 일반적으로 이 값은 변경할 필요가 없습니다. |
|
|
사용할 논리적 브리지와 물리적 브리지의 매핑. 기본적으로 호스트(br-ex)의 외부 브리지가 물리적 이름(datacentre)에 매핑됩니다. 기본 유동 네트워크에 이 기본값을 사용합니다. |
|
|
네트워크 노드의 br-ex에 브리지에 인터페이스를 정의합니다. |
|
|
Neutron의 테넌트 네트워크 유형 |
|
|
Neutron 테넌트 네트워크의 터널 유형. 여러 값을 지정하려면 콤마로 구분된 문자열을 사용합니다. |
|
|
테넌트 네트워크 할당에 사용할 수 있는 GRE 터널 ID 범위 |
|
|
테넌트 네트워크 할당에 사용할 수 있는 VXLAN VNI ID 범위 |
|
|
지원할 Neutron ML2 및 Open vSwitch VLAN 매핑 범위. 기본적으로 datacentre 물리적 네트워크에서 VLAN을 허용하도록 설정되어 있습니다. |
|
|
neutron 테넌트 네트워크의 매커니즘 드라이버. 기본값은 "openvswitch"입니다. 여러 값을 지정하려면 콤마로 구분된 문자열을 사용합니다. |
|
|
VLAN 세그먼트화된 네트워크 또는 플랫 네트워크를 Neutron과 함께 사용하려는 경우 터널링을 비활성화합니다. |
매개 변수 매핑 없음 |
|
오버클라우드 생성 프로세스는 일련의 사전 배포 검사를 수행합니다. 이 옵션은 사전 배포 확인에서 치명적인 오류가 발생할 경우에만 종료됩니다. 오류가 발생하면 배포에 실패할 수 있으므로 이 옵션을 사용하는 것이 좋습니다. |
매개 변수 매핑 없음 |
이러한 매개 변수는 Red Hat OpenStack Platform의 이후 버전에서 삭제될 예정입니다.
6.12. 오버클라우드 배포에 환경 파일 포함
-e
에 오버클라우드를 사용자 정의할 환경 파일이 포함되어 있습니다. 필요에 따라 환경 파일을 추가할 수 있지만, 나중에 실행되는 환경 파일에 정의된 매개 변수와 리소스가 우선 순위를 갖기 때문에 환경 파일의 순서가 중요합니다. 다음 목록은 환경 파일 순서의 예입니다.
- 각 역할 및 해당 플레이버당 노드의 크기입니다. 오버클라우드 생성에 이 정보를 포함하는 것이 중요합니다.
- 컨테이너화된 OpenStack 서비스의 컨테이너 이미지 위치입니다.
-
heat 템플릿 컬렉션의 초기화 파일(
environments/network-isolation.yaml
) 부터 시작하여 네트워크 분리 파일, 사용자 정의 NIC 설정 파일, 마지막으로 추가 네트워크 설정 순입니다. - 모든 외부 로드 밸런싱 환경 파일
- Ceph Storage, NFS, iSCSI 등과 같은 스토리지 환경 파일
- Red Hat CDN 또는 Satellite 등록의 환경 파일
- 기타 사용자 정의 환경 파일
-e
옵션을 사용하여 오버클라우드에 추가된 환경 파일은 오버클라우드 스택 정의의 일부가 됩니다.
다음 명령은 이 시나리오의 앞부분에서 정의한 환경 파일을 사용하여 오버클라우드 생성을 시작하는 방법에 대한 예입니다.
(undercloud) $ openstack overcloud deploy --templates \ -e /home/stack/templates/node-info.yaml\ -e /home/stack/templates/overcloud_images.yaml \ -e /home/stack/inject-trust-anchor-hiera.yaml -r /home/stack/templates/roles_data.yaml \
이 명령에는 다음과 같은 추가 옵션을 사용할 수 있습니다.
- --templates
-
/usr/share/openstack-tripleo-heat-templates
의 Heat 템플릿 컬렉션을 기반으로 하여 오버클라우드를 생성합니다. - -e /home/stack/templates/node-info.yaml
- 각 역할에 사용할 노드 수와 유형을 정의하는 환경 파일을 추가합니다.
- -e /home/stack/templates/overcloud_images.yaml
- 컨테이너 이미지 소스가 포함된 환경 파일을 추가합니다.
- -e /home/stack/inject-trust-anchor-hiera.yaml
- 환경 파일을 추가하여 언더클라우드에 사용자 지정 인증서를 설치합니다.
- -r /home/stack/templates/roles_data.yaml
- (옵션) 사용자 지정 역할 또는 다중 아키텍처 클라우드를 사용하는 경우 생성된 역할 데이터입니다. 자세한 내용은 6.6절. “아키텍처별 역할 생성”을 참조하십시오.
director를 사용하려면 9장. 오버클라우드 생성 후 작업 수행에 재배포 및 배포 후 기능에 대한 이러한 환경 파일이 필요합니다. 이러한 파일이 포함되지 않은 경우 오버클라우드가 손상될 수 있습니다.
오버클라우드 설정을 나중에 수정하려는 경우 다음을 수행해야 합니다.
- 사용자 정의 환경 파일 및 Heat 템플릿에서 매개 변수 수정
-
같은 환경 파일을 지정하고
openstack overcloud deploy
명령을 다시 실행
오버클라우드 설정을 직접 편집하지 마십시오. 오버클라우드 스택을 director로 업데이트할 때 수동 설정을 director의 설정이 덮어쓰기하므로 설정을 직접 편집하지 마십시오.
6.13. 배포 작업 전 오버클라우드 설정 확인
오버클라우드 배포 작업을 실행하기 전에 Heat 템플릿 및 환경 파일에서 오류를 확인합니다.
절차
오버클라우드의 코어 Heat 템플릿은 Jinja2 포맷으로 되어 있습니다. 템플릿을 확인하려면 다음 명령을 사용하여 Jinja2 포맷을 사용하지 않고 버전을 렌더링합니다.
$ cd /usr/share/openstack-tripleo-heat-templates $ ./tools/process-templates.py -o ~/overcloud-validation
다음 명령을 사용하여 템플릿 구문을 확인합니다.
(undercloud) $ openstack orchestration template validate --show-nested \ --template ~/overcloud-validation/overcloud.yaml -e ~/overcloud-validation/overcloud-resource-registry-puppet.yaml \ -e [ENVIRONMENT FILE] \ -e [ENVIRONMENT FILE]
검증을 수행하려면 오버클라우드 특정 리소스를 포함할
overcloud-resource-registry-puppet.yaml
환경 파일이 필요합니다.-e
옵션을 사용하여 이 명령에 환경 파일을 추가하십시오. 또한--show-nested
옵션을 추가하여 중첩된 템플릿에서 매개 변수를 해결합니다.- 이 명령은 템플릿에서 구문 오류를 식별합니다. 템플릿 구문의 검증이 성공적으로 수행되면 출력에 결과 오버클라우드 템플릿의 프리뷰가 표시됩니다.
6.14. 오버클라우드 배포 출력
오버클라우드 생성이 완료되면 오버클라우드를 설정하기 위해 Ansible 플레이 개요가 director에서 제공됩니다.
PLAY RECAP ************************************************************* overcloud-compute-0 : ok=160 changed=67 unreachable=0 failed=0 overcloud-controller-0 : ok=210 changed=93 unreachable=0 failed=0 undercloud : ok=10 changed=7 unreachable=0 failed=0 Tuesday 15 October 2018 18:30:57 +1000 (0:00:00.107) 1:06:37.514 ****** ========================================================================
director는 또한 오버클라우드 액세스에 필요한 세부 정보도 제공합니다.
Ansible passed. Overcloud configuration completed. Overcloud Endpoint: http://192.168.24.113:5000 Overcloud Horizon Dashboard URL: http://192.168.24.113:80/dashboard Overcloud rc file: /home/stack/overcloudrc Overcloud Deployed
6.15. 오버클라우드 액세스
director에서는 director 호스트에서 오버클라우드와 상호 작용을 설정하고 인증을 지원하는 스크립트를 생성합니다. director는 overcloudrc
파일을 stack
사용자의 홈 director에 저장합니다. 이 파일을 사용하려면 다음 명령을 실행합니다.
(undercloud) $ source ~/overcloudrc
이 명령을 실행하면 director 호스트의 CLI에서 오버클라우드와 상호 작용하는 데 필요한 환경 변수가 로드됩니다. 명령 프롬프트에서 다음을 표시하도록 변경합니다.
(overcloud) $
director 호스트와의 상호 작용으로 돌아가려면 다음 명령을 실행합니다.
(overcloud) $ source ~/stackrc (undercloud) $
오버클라우드의 각 노드에는 heat-admin
이라고 하는 사용자가 포함되어 있습니다. stack
사용자는 각 노드에 있는 이 사용자에 대해 SSH 액세스 권한을 갖습니다. SSH로 노드에 액세스하려면 원하는 노드의 IP 주소를 확인합니다.
(undercloud) $ openstack server list
다음으로 heat-admin
사용자와 노드의 IP 주소를 사용하여 노드에 연결합니다.
(undercloud) $ ssh heat-admin@192.168.24.23
6.16. 다음 단계
이제 명령줄 툴을 사용한 오버클라우드 생성이 완료되었습니다. 생성 이후 기능에 대해서는 9장. 오버클라우드 생성 후 작업 수행을 참조하십시오.