Red Hat Training

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

8.6. 오버클라우드 노드에 별도의 네트워크 사용

기본적으로 director는 프로비저닝 네트워크를 오버클라우드 컨트롤 플레인으로 사용합니다. 하지만 이 네트워크가 분리되어 라우팅이 불가능한 경우 구성 중에 노드에서 director의 내부 API와 통신할 수 없습니다. 이 경우 노드에 대해 별도의 네트워크를 정의하고, 공용 API로 director와 통신하도록 구성해야 할 수 있습니다.

이 시나리오에는 다음과 같은 여러 요구 사항이 있습니다.

이 섹션의 예에서는 기본 시나리오와 다른 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.confhieradata_override 를 사용하면 언더클라우드 구성에 대해 추가 Puppet hieradata를 지정할 수 있습니다. 다음 단계를 사용하여 OpenStack Orchestration과 관련된 hieradata를 수정합니다.

  1. hieradata_override 파일을 아직 사용하지 않는 경우 새 파일을 생성합니다. 이 예에서는 /home/stack/hieradata.yaml 에 있는 하나를 사용합니다.
  2. /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를 사용하도록 신호 방법이 변경됩니다.

  3. undercloud.conf 에서 hieradata_override 매개변수를 hieradata 파일의 경로로 설정합니다.

    hieradata_override = /home/stack/hieradata.yaml
  4. 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
EC2MetadataIpControlPlaneDefaultRoute 매개변수는 컨트롤 플레인 가상 IP 주소 값으로 설정됩니다. 기본 NIC 구성 템플릿에는 이러한 매개변수가 필요하므로 ping할 수 있는 IP 주소를 사용하여 배포 중에 수행된 검증을 전달하도록 설정해야 합니다. 또는 이러한 매개변수가 필요하지 않도록 NIC 구성을 사용자 지정합니다.