Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
8.6. 오버클라우드 노드에 별도의 네트워크 사용
기본적으로 director는 프로비저닝 네트워크를 오버클라우드 컨트롤 플레인으로 사용합니다. 하지만 이 네트워크가 분리되어 라우팅이 불가능한 경우 구성 중에 노드에서 director의 내부 API와 통신할 수 없습니다. 이 경우 노드에 대해 별도의 네트워크를 정의하고, 공용 API로 director와 통신하도록 구성해야 할 수 있습니다.
이 시나리오에는 다음과 같은 여러 요구 사항이 있습니다.
- 오버클라우드 노드는 8.5절. “컨트롤 플레인의 네트워킹 구성”의 기본 네트워크 설정을 수용해야 합니다.
- director에서 공용 API 엔드포인트 사용에 대해 SSL/TLS를 활성화해야 합니다. 자세한 내용은 4.9절. “director 설정 매개변수” 및 부록 A. SSL/TLS 인증서 구성을 참조하십시오.
-
director에 대해 FQDN(정규화된 도메인 이름)을 정의해야 합니다. 이 FQDN은 director의 라우팅 가능 IP 주소로 확인되어야 합니다.
undercloud.conf
파일에서undercloud_public_host
매개변수를 사용하여 이 FQDN을 설정합니다.
이 섹션의 예에서는 기본 시나리오와 다른 IP 주소 할당을 사용합니다.
표 8.2. 프로비저닝 네트워크 IP 할당
노드 이름 | IP 주소 또는 FQDN |
---|---|
Director(내부 API) | 192.168.24.1(프로비저닝 네트워크 및 컨트롤 플레인) |
Director(공용 API) | 10.1.1.1 / director.example.com |
오버클라우드 가상 IP | 192.168.100.1 |
Controller 0 | 192.168.100.2 |
Compute 0 | 192.168.100.3 |
다음 섹션에서는 오버클라우드 노드에 별도의 네트워크가 필요한 경우 추가 설정 방법을 설명합니다.
오케스트레이션 구성
언더클라우드에서 SSL/TLS 통신을 활성화하면 director는 대부분의 서비스에 대해 공용 API 엔드포인트를 제공합니다. 그러나 OpenStack Orchestration(heat)은 내부 엔드포인트를 메타데이터의 기본 공급자로 사용합니다. 따라서 오버클라우드 노드를 공용 끝점의 OpenStack Orchestration에 액세스할 수 있도록 언더클라우드에 약간의 수정이 필요합니다. 이 수정에는 director에서 일부 Puppet hieradata를 변경하는 작업이 포함됩니다.
undercloud.conf
의 hieradata_override
를 사용하면 언더클라우드 구성에 대해 추가 Puppet hieradata를 지정할 수 있습니다. 다음 단계를 사용하여 OpenStack Orchestration과 관련된 hieradata를 수정합니다.
-
hieradata_override
파일을 아직 사용하지 않는 경우 새 파일을 생성합니다. 이 예에서는/home/stack/hieradata.yaml
에 있는 하나를 사용합니다. /home/stack/hieradata.yaml
에 다음 hieradata를 포함합니다.heat_clients_endpoint_type: public heat::engine::default_deployment_signal_transport: TEMP_URL_SIGNAL
이렇게 하면 엔드포인트 유형이 기본
internal
에서public
으로 변경되고 OpenStack Object Storage(swift)에서 TempURLs를 사용하도록 신호 방법이 변경됩니다.undercloud.conf
에서hieradata_override
매개변수를 hieradata 파일의 경로로 설정합니다.hieradata_override = /home/stack/hieradata.yaml
-
openstack undercloud install
명령을 다시 실행하여 새 구성 옵션을 구현합니다.
이렇게 하면 오케스트레이션 메타데이터 서버가 director의 공용 API에서 URL을 사용하도록 전환합니다.
IP 주소 할당
IP 할당 방법은 8.5절. “컨트롤 플레인의 네트워킹 구성”과 비슷합니다. 그러나 컨트롤 플레인은 배포된 서버에서 라우팅되지 않으므로 DeployedServerPortMap
매개변수를 사용하여 컨트롤 플레인에 액세스할 가상 IP 주소를 포함하여 선택한 오버클라우드 노드 서브넷에서 IP 주소를 할당합니다. 다음은 8.5절. “컨트롤 플레인의 네트워킹 구성” 의 ctlplane-assignments.yaml
환경 파일의 수정된 버전으로 이 네트워크 아키텍처를 지원합니다.
resource_registry: OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml OS::TripleO::Network::Ports::ControlPlaneVipPort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml 1 parameter_defaults: NeutronPublicInterface: eth1 EC2MetadataIp: 192.168.100.1 2 ControlPlaneDefaultRoute: 192.168.100.1 DeployedServerPortMap: control_virtual_ip: fixed_ips: - ip_address: 192.168.100.1 subnets: - cidr: 24 controller-0-ctlplane: fixed_ips: - ip_address: 192.168.100.2 subnets: - cidr: 24 compute-0-ctlplane: fixed_ips: - ip_address: 192.168.100.3 subnets: - cidr: 24
- 1
RedisVipPort
리소스는network/ports/noop.yaml
에 매핑됩니다. 이 매핑은 기본 Redis VIP 주소가 컨트롤 플레인에서 제공되기 때문입니다. 이 경우noop
를 사용하여 이 컨트롤 플레인 매핑을 비활성화합니다.- 2
EC2MetadataIp
및ControlPlaneDefaultRoute
매개변수는 컨트롤 플레인 가상 IP 주소 값으로 설정됩니다. 기본 NIC 구성 템플릿에는 이러한 매개변수가 필요하므로 ping할 수 있는 IP 주소를 사용하여 배포 중에 수행된 검증을 전달하도록 설정해야 합니다. 또는 이러한 매개변수가 필요하지 않도록 NIC 구성을 사용자 지정합니다.