Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

8장. 사전 프로비저닝된 노드를 사용하여 기본 오버클라우드 구성

이 장에서는 사전 프로비저닝된 노드를 사용하여 OpenStack Platform 환경을 구성하기 위한 기본 설정 단계를 설명합니다. 이 시나리오는 여러 방식에서 표준 오버클라우드 생성 시나리오와 다릅니다.

외부 툴을 사용하여 노드를 프로비저닝하고 director가 오버클라우드 구성만 제어하도록 할 수 있습니다.
director의 프로비저닝 방법에 의존하지 않고 노드를 사용할 수 있습니다. 이는 전원 관리 제어 없이 오버클라우드를 생성하거나 DHCP/PXE 부팅 제한이 있는 네트워크를 사용하는 경우 유용합니다.
director에서 노드 관리에 OpenStack Compute(nova), OpenStack Bare Metal(ironic) 또는 OpenStack Image(glance)를 사용하지 않습니다.
사전 프로비저닝된 노드에서는 사용자 지정 파티션 레이아웃을 사용합니다.

이 시나리오는 사용자 지정 기능이 없는 기본 구성을 제공합니다. 하지만 Advanced Overcloud Customization 가이드의 지침에 따라 이 기본 오버클라우드에 고급 옵션을 추가하고 사양에 맞게 사용자 지정할 수 있습니다.

중요

사전 프로비저닝된 노드를 오버클라우드의 director 프로비저닝 노드와 혼합하는 것은 지원되지 않습니다.

요구 사항

4장. 언더클라우드 설치 에서 생성한 director 노드
노드에 사용할 베어 메탈 시스템 세트. 필요한 노드 수는 생성하려는 오버클라우드 유형에 따라 다릅니다(Overcloud 역할에 대한 내용은 3.1절. “노드 배포 역할 계획” 참조). 또한 이러한 머신은 각 노드 유형에 설정된 요구 사항을 준수해야 합니다. 이러한 요구 사항은 2.4절. “오버클라우드 요구 사항” 에서 참조하십시오. 이러한 노드에는 Red Hat Enterprise Linux 7.5 이상을 호스트 운영 체제로 설치해야 합니다. 최신 버전을 사용하는 것이 좋습니다.
사전 프로비저닝된 노드를 관리하기 위한 하나의 네트워크 연결. 이 시나리오를 수행하려면 오케스트레이션 에이전트 구성을 위해 노드에 SSH 액세스가 중단되지 않도록 해야 합니다.

컨트롤 플레인 네트워크에 대한 하나의 네트워크 연결. 이 네트워크에는 두 가지 시나리오가 있습니다.

프로비저닝 네트워크를 컨트롤 플레인으로 사용(기본 시나리오). 이 네트워크는 일반적으로 사전 프로비저닝된 노드에서 director로 연결되는 3 계층(L3) 라우팅 가능한 네트워크 연결입니다. 이 시나리오의 예는 다음 IP 주소 할당을 사용합니다.

표 8.1. 프로비저닝 네트워크 IP 할당

별도 네트워크 사용. director의 프로비저닝 네트워크가 라우팅 불가능한 개인 네트워크인 경우 서브넷에서 노드의 IP 주소를 정의하고 공용 API 엔드포인트를 통해 director와 통신할 수 있습니다. 이 시나리오에는 특정 주의 사항이 있습니다. 이 장은 8.6절. “오버클라우드 노드에 별도의 네트워크 사용” 의 뒷부분에서 조사합니다.

이 예에 있는 다른 모든 네트워크 유형에서도 OpenStack 서비스에 컨트롤 플레인 네트워크를 사용합니다. 하지만 다른 네트워크 트래픽 유형에 대해 추가 네트워크를 생성할 수 있습니다.
노드가 Pacemaker 리소스를 사용하는 경우 서비스 사용자 hacluster 및 서비스 그룹 haclient의 UID/GID는 189여야 합니다. 이는 CVE-2018-16877 때문입니다. Pacemaker를 운영 체제와 함께 설치한 경우 설치 시 이러한 ID가 자동으로 생성됩니다. ID 값을 잘못 설정한 경우에는 OpenStack minor update / fast-forward upgrade can fail on the controller nodes at pacemaker step with "Could not evaluate: backup_cib"의 절차에 따라 ID 값을 변경합니다.
일부 서비스가 잘못된 IP 주소에 바인딩되고 배포 실패가 발생하지 않게 하려면 /etc/hosts 파일에 node-name=127.0.0.1 매핑이 포함되지 않도록합니다.

이 프로세스의 후반 단계에서 director는 오버클라우드 노드에 stack 사용자로 SSH 액세스가 필요합니다.

각 오버클라우드 노드에서 stack 이라는 사용자를 생성하고 각 노드에 암호를 설정합니다. 예를 들어 컨트롤러 노드에서 다음을 사용합니다.
```
[root@controller-0 ~]# useradd stack
[root@controller-0 ~]# passwd stack  # specify a password
```

sudo 사용 시 이 사용자가 암호를 요구하지 않도록 합니다.

[root@controller-0 ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
[root@controller-0 ~]# chmod 0440 /etc/sudoers.d/stack

사전 프로비저닝된 모든 노드에 stack 사용자를 생성 및 구성했으면 director 노드에서 각 오버클라우드 노드로 stack 사용자의 공용 SSH 키를 복사합니다. 예를 들어 director의 공용 SSH 키를 컨트롤러 노드에 복사하려면 다음을 수행합니다.
```
[stack@director ~]$ ssh-copy-id stack@192.168.24.2
```