스파인 리프프팅 네트워킹


Red Hat OpenStack Platform 16.1

Red Hat OpenStack Platform director를 사용하여 라우팅된 스파인-리프형 네트워크 구성

OpenStack Documentation Team

초록

이 가이드에서는 오버클라우드에서 라우팅된 스파인-리프 네트워크를 구성하는 방법에 대한 기본 시나리오를 제공합니다. 여기에는 언더클라우드 구성, 기본 구성 파일 작성, 노드에 대한 역할 생성 등이 포함됩니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견을 보내 주십시오. Red Hat이 어떻게 이를 개선하는지 알려주십시오.

DDF(직접 문서 피드백) 기능 사용

특정 문장, 단락 또는 코드 블록에 대한 직접 주석은 피드백 추가 DDF 기능을 사용하십시오.

  1. 다중 페이지 HTML 형식으로 설명서를 봅니다.
  2. 문서 오른쪽 상단에 Feedback (피드백) 버튼이 표시되는지 확인합니다.
  3. 주석 처리하려는 텍스트 부분을 강조 표시합니다.
  4. 피드백 추가를 클릭합니다.
  5. 주석을 사용하여 Add Feedback (피드백 추가) 필드를 작성합니다.
  6. 선택 사항: 설명서 팀이 문제에 대한 자세한 내용을 문의할 수 있도록 이메일 주소를 추가하십시오.
  7. Submit(제출)을 클릭합니다.

1장. 소개

이 가이드에서는 Red Hat OpenStack Platform 환경의 스파인-리프형 네트워크 토폴로지를 구성하는 방법에 대해 설명합니다. 여기에는 전체 엔드 투 엔드 시나리오와 자체 환경 내에서 더 광범위한 네트워크 토폴로지를 복제하는 데 도움이 되는 예제 파일이 포함됩니다.

1.1. 스파인-리프형 네트워킹

Red Hat OpenStack Platform에는 라우팅된 스파인-리프형 데이터 센터 토폴로지에 네트워킹을 조정하는 데 사용할 수 있는 구성 가능한 네트워크 아키텍처가 있습니다. 라우팅된 스파인-리프의 실제 적용에서 리프는 그림 1.1, "Routed 스파인-리프 예제" 와 같이 일반적으로 데이터 센터 랙에서 구성 가능한 컴퓨팅 또는 스토리지 역할로 표시됩니다. Leaf 0 랙에는 Undercloud 노드, 컨트롤러 노드 및 컴퓨팅 노드가 있습니다. 구성 가능 네트워크는 구성 가능 역할에 할당된 노드에 제공됩니다. 다음 다이어그램에는 다음 구성이 포함되어 있습니다.

  • Storagelea af 네트워크는 Ceph 스토리지 및 컴퓨팅 노드에 제공됩니다.
  • Networklea af는 작성하려는 네트워크의 예를 나타냅니다.

그림 1.1. 라우팅된 스파인-리프형 예

1.2. 스파인-리프형 네트워크 토폴로지

스파인-리프 시나리오에서는 OpenStack Networking(neutron) 기능을 사용하여 단일 네트워크의 세그먼트 내에서 여러 서브넷을 정의합니다. 각 네트워크는 Leaf 0의 역할을 하는 기본 네트워크를 사용합니다. director는 Leaf 1 및 Leaf 2 서브넷을 기본 네트워크의 세그먼트로 생성합니다.

이 시나리오에서는 다음 네트워크를 사용합니다.

Expand
표 1.1. Riv 0 네트워크 (기본 네트워크)
네트워크연결된 역할서브넷

provisioning / Ctlplane / Leaf0

Controller, ComputeLeaf0, CephStorageLeaf0

192.168.10.0/24

스토리지

Controller, ComputeLeaf0, CephStorageLeaf0

172.16.0.0/24

StorageMgmt

Controller, CephStorageLeaf0

172.17.0.0/24

InternalApi

Controller, ComputeLeaf0

172.18.0.0/24

테넌트 [1]

Controller, ComputeLeaf0

172.19.0.0/24

외부

컨트롤러

10.1.1.0/24

[1] 테넌트 네트워크는 프로젝트 네트워크라고도 합니다.

Expand
표 1.2. 네트워크 리프팅 1개
네트워크연결된 역할서브넷

프로비저닝 / Ctlplane / Leaf1

ComputeLeaf1, CephStorageLeaf1

192.168.11.0/24

StorageLeaf1

ComputeLeaf1, CephStorageLeaf1

172.16.1.0/24

StorageMgmtLeaf1

CephStorageLeaf1

172.17.1.0/24

InternalApiLeaf1

ComputeLeaf1

172.18.1.0/24

TenantLeaf1 [1]

ComputeLeaf1

172.19.1.0/24

[1] 테넌트 네트워크는 프로젝트 네트워크라고도 합니다.

Expand
표 1.3. 리프팅 2 네트워크
네트워크연결된 역할서브넷

프로비저닝 / Ctlplane / Leaf2

ComputeLeaf2, CephStorageLeaf2

192.168.12.0/24

StorageLeaf2

ComputeLeaf2, CephStorageLeaf2

172.16.2.0/24

StorageMgmtLeaf2

CephStorageLeaf2

172.17.2.0/24

InternalApiLeaf2

ComputeLeaf2

172.18.2.0/24

TenantLeaf2 [1]

ComputeLeaf2

172.19.2.0/24

[1] 테넌트 네트워크는 프로젝트 네트워크라고도 합니다.

그림 1.2. 스파인-리프형 네트워크 토폴로지

1.3. 스파인-리프형 요구 사항

L3 라우팅 아키텍처가 있는 네트워크에 오버클라우드를 배포하려면 다음 사전 요구 사항 단계를 완료합니다.

계층-3 라우팅
다른 L2 세그먼트 간 트래픽을 활성화하도록 네트워크 인프라의 라우팅을 구성합니다. 이 라우팅을 정적 또는 동적으로 구성할 수 있습니다.
DHCP-Relay
언더클라우드에 로컬로 지정되지 않은 각 L2 세그먼트에서 dhcp-relay 를 제공해야 합니다. 언더클라우드가 연결된 프로비저닝 네트워크 세그먼트에서 DHCP 요청을 언더클라우드로 전달해야 합니다.
참고

Undercloud에서는 두 개의 DHCP 서버를 사용합니다. 베어 메탈 노드 인트로스펙션용 한 개와 Overcloud 노드 배포를 위한 다른 항목. dhcp-relay 를 구성할 때 DHCP 릴레이 구성을 읽고 요구 사항을 이해해야 합니다.

1.4. 스파인-리프형 제한 사항

  • Controller 역할과 같은 일부 역할은 가상 IP 주소와 클러스터링을 사용합니다. 이 기능의 메커니즘을 사용하려면 이러한 노드 간 L2 네트워크 연결이 필요합니다. 이러한 노드를 동일한 풀 내에 배치해야 합니다.
  • 네트워크 노드에 유사한 제한 사항이 적용됩니다. 네트워크 서비스는 VRRP(Virtual Router Redundancy Protocol)를 사용하여 네트워크에서 고가용성 기본 경로를 구현합니다. VRRP는 가상 라우터 IP 주소를 사용하므로 마스터 및 백업 노드를 동일한 L2 네트워크 세그먼트에 연결해야 합니다.
  • 테넌트 또는 프로바이더 네트워크를 VLAN 분할과 사용하는 경우 모든 Networker 노드와 컴퓨팅 노드 간에 특정 VLAN을 공유해야 합니다.
참고

여러 네트워크 노드 세트를 사용하여 네트워크 서비스를 구성할 수 있습니다. 각 네트워크 노드 집합은 해당 네트워크의 경로를 공유하고 VRRP는 각 네트워크 노드 세트 내에서 고가용성 기본 경로를 제공합니다. 이 유형의 구성에서는 네트워크를 공유하는 모든 Networker 노드가 동일한 L2 네트워크 세그먼트에 있어야 합니다.

2장. 언더클라우드에서 라우팅된 스파인-리프형 구성

이 섹션에서는 구성 가능한 네트워크를 사용하여 라우팅된 스파인-리프형을 수용하도록 언더클라우드를 구성하는 방법에 대해 설명합니다.

2.1. 스파인 리프링 프로비저닝 네트워크 구성

스파인 사이클 인프라에 대한 프로비저닝 네트워크를 구성하려면 undercloud.conf 파일을 편집하고 다음 절차에 포함된 관련 매개변수를 설정합니다.

절차

  1. stack 사용자로 언더클라우드에 로그인합니다.
  2. undercloud.conf 파일이 없는 경우 샘플 템플릿 파일을 복사합니다.

    [stack@director ~]$ cp /usr/share/python-tripleoclient/undercloud.conf.sample ~/undercloud.conf
    Copy to Clipboard Toggle word wrap
  3. undercloud.conf 파일을 편집합니다.
  4. [DEFAULT] 섹션에서 다음 값을 설정합니다.

    1. fat 0에서 local_ip 를 언더클라우드 IP로 설정합니다.

      local_ip = 192.168.10.1/24
      Copy to Clipboard Toggle word wrap
    2. undercloud_public_host 를 언더클라우드의 외부 IP 주소로 설정합니다.

      undercloud_public_host = 10.1.1.1
      Copy to Clipboard Toggle word wrap
    3. undercloud_admin_host 를 Undercloud의 관리 IP 주소로 설정합니다. 이 IP 주소는 일반적으로 gra0에 있습니다.

      undercloud_admin_host = 192.168.10.2
      Copy to Clipboard Toggle word wrap
    4. local_interface 를 로컬 네트워크의 브리지로 설정합니다.

      local_interface = eth1
      Copy to Clipboard Toggle word wrap
    5. enable_routed_networkstrue로 설정합니다.

      enable_routed_networks = true
      Copy to Clipboard Toggle word wrap
    6. subnets 매개 변수를 사용하여 서브넷 목록을 정의합니다. 라우팅된 스파인 및 리프린트의 각 L2 세그먼트에 대해 하나의 서브넷을 정의합니다.

      subnets = leaf0,leaf1,leaf2
      Copy to Clipboard Toggle word wrap
    7. local_subnet 매개변수를 사용하여 언더클라우드에 로컬로 실제 L2 세그먼트와 연결된 서브넷을 지정합니다.

      local_subnet = leaf0
      Copy to Clipboard Toggle word wrap
    8. undercloud_nameservers 의 값을 설정합니다.

      undercloud_nameservers = 10.11.5.19,10.11.5.20
      Copy to Clipboard Toggle word wrap
      작은 정보

      /etc/resolv.conf를 확인하여 언더클라우드 이름 서버에 사용되는 DNS 서버의 현재 IP 주소를 찾을 수 있습니다.

  5. subnets 매개변수에 정의된 각 서브넷의 새 섹션을 생성합니다.

    [leaf0]
    cidr = 192.168.10.0/24
    dhcp_start = 192.168.10.10
    dhcp_end = 192.168.10.90
    inspection_iprange = 192.168.10.100,192.168.10.190
    gateway = 192.168.10.1
    masquerade = False
    
    [leaf1]
    cidr = 192.168.11.0/24
    dhcp_start = 192.168.11.10
    dhcp_end = 192.168.11.90
    inspection_iprange = 192.168.11.100,192.168.11.190
    gateway = 192.168.11.1
    masquerade = False
    
    [leaf2]
    cidr = 192.168.12.0/24
    dhcp_start = 192.168.12.10
    dhcp_end = 192.168.12.90
    inspection_iprange = 192.168.12.100,192.168.12.190
    gateway = 192.168.12.1
    masquerade = False
    Copy to Clipboard Toggle word wrap
  6. undercloud.conf 파일을 저장합니다.
  7. 언더클라우드 설치 명령을 실행합니다.

    [stack@director ~]$ openstack undercloud install
    Copy to Clipboard Toggle word wrap

이 구성은 provisioning 네트워크 또는 컨트롤 플레인에 세 개의 서브넷을 생성합니다. 오버클라우드는 각 네트워크를 사용하여 각각의 환경에 맞게 시스템을 프로비저닝합니다.

DHCP 요청을 언더클라우드에 올바르게 릴레이하려면 DHCP 릴레이를 구성해야 할 수 있습니다.

2.2. DHCP 릴레이 구성

요청을 전달할 원격 네트워크 세그먼트에 연결된 스위치, 라우터 또는 서버에서 DHCP 릴레이 서비스를 실행합니다.

참고

언더클라우드에서 DHCP 릴레이 서비스를 실행하지 마십시오.

언더클라우드는 provisioning 네트워크에서 두 개의 DHCP 서버를 사용합니다.

  • 인트로스펙션 DHCP 서버입니다.
  • 프로비저닝 DHCP 서버.

언더클라우드의 DHCP 서버에 DHCP 요청을 전달하도록 DHCP 릴레이를 구성해야 합니다.

DHCP 요청을 지원하는 장치와 함께 UDP 브로드캐스트를 사용하여 언더클라우드 프로비저닝 네트워크가 연결된 L2 네트워크 세그먼트로 릴레이할 수 있습니다. 또는 DHCP 요청을 특정 IP 주소로 릴레이하는 UDP 유니캐스트를 사용할 수 있습니다.

참고

특정 장치 유형에서 DHCP 릴레이 구성은 이 문서의 범위를 벗어납니다. 참고로 이 문서에서는 ISC DHCP 소프트웨어의 구현을 사용하여 DHCP 릴레이 구성 예를 제공합니다. 자세한 내용은 매뉴얼 페이지 dhcrelay(8)를 참조하십시오.

중요

DHCP 옵션 79는 일부 릴레이, 특히 DHCPv6 주소를 제공하는 릴레이와 원래 MAC 주소를 통과하지 않는 릴레이에 필요합니다. 자세한 내용은 RFC6939 를 참조하십시오.

브로드캐스트 DHCP 릴레이

이 메서드는 UDP 브로드캐스트 트래픽을 사용하여 DHCP 서버 또는 서버가 있는 L2 네트워크 세그먼트로 DHCP 요청을 릴레이합니다. 네트워크 세그먼트의 모든 장치는 브로드캐스트 트래픽을 수신합니다. UDP 브로드캐스트를 사용하는 경우 언더클라우드의 두 DHCP 서버는 모두 릴레이된 DHCP 요청을 수신합니다. 구현에 따라 인터페이스 또는 IP 네트워크 주소를 지정하여 이를 구성할 수 있습니다.

인터페이스
DHCP 요청이 릴레이되는 L2 네트워크 세그먼트에 연결된 인터페이스를 지정합니다.
IP 네트워크 주소
DHCP 요청이 릴레이되는 IP 네트워크의 네트워크 주소를 지정합니다.

유니캐스트 DHCP 릴레이

이 메서드는 UDP 유니캐스트 트래픽을 사용하여 DHCP 요청을 특정 DHCP 서버로 중계합니다. UDP 유니캐스트를 사용하는 경우 DHCP 릴레이를 제공하여 DHCP 요청을 언더클라우드의 인트로스펙션에 사용되는 인터페이스에 할당된 IP 주소 및 OpenStack Networking(neutron) 서비스에서 생성하는 네트워크 네임스페이스의 IP 주소 모두에 릴레이하도록 DHCP 릴레이를 제공하는 장치를 구성해야 합니다 .

세부 검사에 사용되는 인터페이스는 undercloud.conf 파일에서 inspection_interface 로 정의된 인터페이스입니다. 이 매개변수를 설정하지 않은 경우 언더클라우드의 기본 인터페이스는 br-ctlplane 입니다.

참고

세부 검사를 위해 br-ctlplane 인터페이스를 사용하는 것이 일반적입니다. undercloud.conf 파일에서 local_ip 로 정의한 IP 주소는 br-ctlplane 인터페이스에 있습니다.

Neutron DHCP 네임스페이스에 할당된 IP 주소는 undercloud.conf 파일의 local_subnet 에 대해 구성하는 IP 범위에서 사용할 수 있는 첫 번째 주소입니다. IP 범위의 첫 번째 주소는 구성에서 dhcp_start 로 정의하는 주소입니다. 예를 들어 다음 구성을 사용하는 경우 192.168.10.10 은 IP 주소입니다.

[DEFAULT]
local_subnet = leaf0
subnets = leaf0,leaf1,leaf2

[leaf0]
cidr = 192.168.10.0/24
dhcp_start = 192.168.10.10
dhcp_end = 192.168.10.90
inspection_iprange = 192.168.10.100,192.168.10.190
gateway = 192.168.10.1
masquerade = False
Copy to Clipboard Toggle word wrap
주의

DHCP 네임스페이스의 IP 주소가 자동으로 할당됩니다. 대부분의 경우 이 주소는 IP 범위의 첫 번째 주소입니다. 이 경우 언더클라우드에서 다음 명령을 실행합니다.

$ openstack port list --device-owner network:dhcp -c "Fixed IP Addresses"
+----------------------------------------------------------------------------+
| Fixed IP Addresses                                                         |
+----------------------------------------------------------------------------+
| ip_address='192.168.10.10', subnet_id='7526fbe3-f52a-4b39-a828-ec59f4ed12b2' |
+----------------------------------------------------------------------------+
$ openstack subnet show 7526fbe3-f52a-4b39-a828-ec59f4ed12b2 -c name
+-------+--------+
| Field | Value  |
+-------+--------+
| name  | leaf0  |
+-------+--------+
Copy to Clipboard Toggle word wrap

dhcrelay 구성의 예

다음 예제에서 dhcp 패키지의 dhcrelay 명령은 다음 구성을 사용합니다.

  • 수신 DHCP 요청을 릴레이할 인터페이스: eth1,eth2, eth3.
  • 네트워크 세그먼트의 Undercloud DHCP 서버를 인터페이스로 연결합니다. eth0.
  • 인트로스펙션에 사용되는 DHCP 서버가 IP 주소에서 수신 대기 중입니다. 192.168.10.1.
  • 프로비저닝에 사용되는 DHCP 서버는 IP 주소 192.168.10.10 에서 수신 대기 중입니다.

그러면 다음과 같은 dhc relay 명령이 생성됩니다.

  • dhcrelay 버전 4.2.x:

    $ sudo dhcrelay -d --no-pid 192.168.10.10 192.168.10.1 \
      -i eth0 -i eth1 -i eth2 -i eth3
    Copy to Clipboard Toggle word wrap
  • dhcrelay 버전 4.3.x 이상:

    $ sudo dhcrelay -d --no-pid 192.168.10.10 192.168.10.1 \
      -iu eth0 -id eth1 -id eth2 -id eth3
    Copy to Clipboard Toggle word wrap

Cisco IOS 라우팅 스위치 구성의 예

이 예에서는 다음 Cisco IOS 구성을 사용하여 다음 작업을 수행합니다.

  • provisioning 네트워크에 사용할 VLAN을 구성합니다.
  • IP 주소 를 추가합니다.
  • IP 주소에서 수신 대기하는 인트로스펙션 DHCP 서버로 UDP 및 BOOTP 요청을 전달합니다. 192.168.10.1.
  • UDP 및 BOOTP 요청을 IP 주소 192.168.10.10 에서 수신 대기하는 프로비저닝 DHCP 서버로 전달합니다.
interface vlan 2
ip address 192.168.24.254 255.255.255.0
ip helper-address 192.168.10.1
ip helper-address 192.168.10.10
!
Copy to Clipboard Toggle word wrap

이제 provisioning 네트워크를 구성했으므로 나머지 오버클라우드 리프 네트워크를 구성할 수 있습니다.

2.3. 리프 네트워크를 위한 플레이버 및 태그 지정 노드 생성

각 네트워크의 각 역할에는 노드를 해당 라벨에 태그할 수 있도록 플레이버 및 역할 할당이 필요합니다. 각 플레이버를 만들고 역할에 할당하려면 다음 단계를 완료합니다.

절차

  1. stackrc 파일을 소싱합니다.

    [stack@director ~]$ source ~/stackrc
    Copy to Clipboard Toggle word wrap
  2. 각 사용자 지정 역할에 대한 플레이버를 만듭니다.

    $ ROLES="control compute_leaf0 compute_leaf1 compute_leaf2 ceph-storage_leaf0 ceph-storage_leaf1 ceph-storage_leaf2"
    $ for ROLE in $ROLES; do openstack flavor create --id auto --ram <ram_size_mb> --disk <disk_size_gb> --vcpus <no_vcpus> $ROLE ; done
    $ for ROLE in $ROLES; do openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property resources:DISK_GB='0' --property resources:MEMORY_MB='0' --property resources:VCPU='0' $ROLE ; done
    Copy to Clipboard Toggle word wrap
    • & lt;ram_size_mb >를 베어 메탈 노드의 RAM(MB)으로 바꿉니다.
    • & lt;disk_size_gb >을 베어 메탈 노드의 디스크 크기(GB)로 바꿉니다.
    • & lt;no_vcpus >를 베어 메탈 노드의 CPU 수로 바꿉니다.
  3. 노드 목록을 검색하여 UUID를 확인합니다.

    (undercloud)$ openstack baremetal node list
    Copy to Clipboard Toggle word wrap
  4. 사용자 정의 리소스 클래스를 사용하여 각 베어 메탈 노드를 리프 네트워크 및 역할에 태그합니다.

    (undercloud)$ openstack baremetal node set \
     --resource-class baremetal.LEAF-ROLE <node>
    Copy to Clipboard Toggle word wrap

    & lt;node& gt;를 베어 메탈 노드의 ID로 바꿉니다.

    예를 들어 다음 명령을 입력하여 노드에 UUID 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13 을 사용하여 Leaf2의 Compute 역할에 태그를 지정합니다.

    (undercloud)$ openstack baremetal node set \
     --resource-class baremetal.COMPUTE-LEAF2 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13
    Copy to Clipboard Toggle word wrap
  5. 각 리프 네트워크 역할 플레이버를 사용자 지정 리소스 클래스와 연결합니다.

    (undercloud)$ openstack flavor set \
     --property resources:CUSTOM_BAREMETAL_LEAF_ROLE=1 \
    <custom_role>
    Copy to Clipboard Toggle word wrap

    베어 메탈 프로비저닝 서비스 노드의 리소스 클래스에 해당하는 사용자 정의 리소스 클래스의 이름을 확인하려면 리소스 클래스를 대문자로 변환하고 각 문장 표시를 밑줄로 교체하고 접두사 CUSTOM_.

    참고

    플레이버는 베어 메탈 리소스 클래스의 하나의 인스턴스만 요청할 수 있습니다.

  6. node-info.yaml 파일에서 각 사용자 정의 리프 역할에 사용할 플레이버와 각 사용자 정의 리프 역할에 할당할 노드 수를 지정합니다. 예를 들어 다음 구성은 사용할 플레이버와 사용자 지정 리프 역할 compute_leaf0,compute_leaf1,compute_leaf2,ceph-storage_leaf0, ceph-storage_leaf1 ,ceph-storage_leaf1 에 할당할 노드 수를 지정합니다.

    parameter_defaults:
      OvercloudControllerFlavor: control
      OvercloudComputeLeaf0Flavor: compute_leaf0
      OvercloudComputeLeaf1Flavor: compute_leaf1
      OvercloudComputeLeaf2Flavor: compute_leaf2
      OvercloudCephStorageLeaf0Flavor: ceph-storage_leaf0
      OvercloudCephStorageLeaf1Flavor: ceph-storage_leaf1
      OvercloudCephStorageLeaf2Flavor: ceph-storage_leaf2
      ControllerLeaf0Count: 3
      ComputeLeaf0Count: 3
      ComputeLeaf1Count: 3
      ComputeLeaf2Count: 3
      CephStorageLeaf0Count: 3
      CephStorageLeaf1Count: 3
      CephStorageLeaf2Count: 3
    Copy to Clipboard Toggle word wrap

2.4. 베어 메탈 노드 포트를 컨트롤 플레인 네트워크 세그먼트에 매핑

L3 라우팅 네트워크에서 배포를 활성화하려면 베어 메탈 포트에서 physical_network 필드를 구성해야 합니다. 각 베어 메탈 포트는 OpenStack Bare Metal(ironic) 서비스의 베어 메탈 노드와 연결됩니다. 실제 네트워크 이름은 언더클라우드 구성의 subnets 옵션에 포함할 이름입니다.

참고

undercloud.conf 파일에서 local_subnet 으로 지정된 서브넷의 실제 네트워크 이름은 항상 ctlplane 입니다.

절차

  1. stackrc 파일을 소싱합니다.

    $ source ~/stackrc
    Copy to Clipboard Toggle word wrap
  2. 베어 메탈 노드를 확인합니다.

    $ openstack baremetal node list
    Copy to Clipboard Toggle word wrap
  3. 베어 메탈 노드가 등록 또는 manageable 상태인지 확인합니다. 베어 메탈 노드가 이러한 상태에 있지 않은 경우 baremetal 포트에서 physical_network 속성을 설정하는 명령이 실패합니다. 모든 노드를 manageable 상태로 설정하려면 다음 명령을 실행합니다.

    $ for node in $(openstack baremetal node list -f value -c Name); do openstack baremetal node manage $node --wait; done
    Copy to Clipboard Toggle word wrap
  4. 베어 메탈 노드와 연결된 베어 메탈 포트를 확인합니다.

    $ openstack baremetal port list --node <node-uuid>
    Copy to Clipboard Toggle word wrap
  5. 포트의 physical-network 매개 변수를 설정합니다. 아래 예에서 세 개의 서브넷이 구성에서 정의됩니다(pull 0, evaluation1, capsule 2). local_subnet이 idle 0 입니다. local_subnet 의 실제 네트워크는 항상 ctlplane이므로, poll 0 에 연결된 baremetal 포트는 ctlplane을 사용합니다. 나머지 포트는 다른 리프 이름을 사용합니다.

    $ openstack baremetal port set --physical-network ctlplane <port-uuid>
    $ openstack baremetal port set --physical-network leaf1 <port-uuid>
    $ openstack baremetal port set --physical-network leaf2 <port-uuid>
    Copy to Clipboard Toggle word wrap
  6. 오버클라우드를 배포하기 전에 노드를 인트로스펙션합니다. --all-manageable--provide 옵션을 포함하여 노드에 배포에 사용 가능한 상태로 설정합니다.

    $ openstack overcloud node introspect --all-manageable --provide
    Copy to Clipboard Toggle word wrap

2.5. 스파인-리프 프로비저닝 네트워크에 새 리프 추가

새 물리적 사이트 추가를 포함할 수 있는 네트워크 용량을 늘리는 경우 Red Hat OpenStack Platform 스파인-리프 프로비저닝 네트워크에 새 리프와 해당 서브넷을 추가해야 할 수 있습니다. 오버클라우드에서 리프를 프로비저닝하면 해당 언더클라우드 리프가 사용됩니다.

사전 요구 사항

  • RHOSP 배포에서는 스파인-리프형 네트워크 토폴로지를 사용합니다.

절차

  1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.
  2. 언더클라우드 인증 정보 파일을 가져옵니다.

    $ source ~/stackrc
    Copy to Clipboard Toggle word wrap
  3. /home/stack/undercloud.conf 파일에서 다음을 수행합니다.

    1. subnets 매개변수를 찾아서 추가하는 리프에 대한 새 서브넷을 추가합니다.

      서브넷은 라우팅된 스파인 및 리프의 L2 세그먼트를 나타냅니다.

      예제

      이 예에서는 새 리프(leaf3)를 위해 새 서브넷(leaf3)이 추가되었습니다.

      subnets = leaf0,leaf1,leaf2,leaf3
      Copy to Clipboard Toggle word wrap
    2. 추가한 서브넷에 대한 섹션을 만듭니다.

      예제

      이 예에서는 새 서브넷(leaf3)에 대해 섹션 [leaf3] 이 추가되었습니다.

      [leaf0]
      cidr = 192.168.10.0/24
      dhcp_start = 192.168.10.10
      dhcp_end = 192.168.10.90
      inspection_iprange = 192.168.10.100,192.168.10.190
      gateway = 192.168.10.1
      masquerade = False
      
      [leaf1]
      cidr = 192.168.11.0/24
      dhcp_start = 192.168.11.10
      dhcp_end = 192.168.11.90
      inspection_iprange = 192.168.11.100,192.168.11.190
      gateway = 192.168.11.1
      masquerade = False
      
      [leaf2]
      cidr = 192.168.12.0/24
      dhcp_start = 192.168.12.10
      dhcp_end = 192.168.12.90
      inspection_iprange = 192.168.12.100,192.168.12.190
      gateway = 192.168.12.1
      masquerade = False
      
      [leaf3]
      cidr = 192.168.13.0/24
      dhcp_start = 192.168.13.10
      dhcp_end = 192.168.13.90
      inspection_iprange = 192.168.13.100,192.168.13.190
      gateway = 192.168.13.1
      masquerade = False
      Copy to Clipboard Toggle word wrap
  4. undercloud.conf 파일을 저장합니다.
  5. 언더클라우드를 다시 설치하십시오.

    $ openstack undercloud install
    Copy to Clipboard Toggle word wrap

3장. 대체 프로비저닝 네트워크 방법

이 섹션에는 구성 가능한 네트워크로 라우팅된 스파인-리프를 수용하도록 프로비저닝 네트워크를 구성하는 데 사용할 수 있는 다른 방법에 대한 정보가 포함되어 있습니다.

3.1. VLAN 프로비저닝 네트워크

이 예에서 director는 provisioning 네트워크를 통해 새 오버클라우드 노드를 배포하고 L3 토폴로지에서 VLAN 터널을 사용합니다. 자세한 내용은 그림 3.1, "VLAN provisioning network topology" 를 참조하십시오. VLAN 프로비저닝 네트워크를 사용하는 경우 director DHCP 서버는 DHCPOFFER 브로드캐스트를 모든 방편으로 보낼 수 있습니다. 이 터널을 설정하려면 Top-of-Rack(ToR) 루프 스위치 간에 VLAN을 트렁크합니다. 다음 다이어그램에서 Storageleaaf 네트워크는 Ceph 스토리지 및 컴퓨팅 노드에 표시됩니다. Networkleaaf는 구성하려는 모든 네트워크의 예를 나타냅니다.

그림 3.1. VLAN 프로비저닝 네트워크 토폴로지

3.2. VXLAN 프로비저닝 네트워크

이 예에서 director는 프로비저닝 네트워크를 통해 새 오버클라우드 노드를 배포하고 VXLAN 터널을 사용하여 계층 3 토폴로지에 걸쳐 있습니다. 자세한 내용은 그림 3.2, "VXLAN 프로비저닝 네트워크 토폴로지" 를 참조하십시오. VXLAN 프로비저닝 네트워크를 사용하는 경우 director DHCP 서버는 DHCPOFFER 브로드캐스트를 모든 방편으로 보낼 수 있습니다. 이 터널을 설정하려면 상단 ToR(Rack) 리프팅 스위치에서 VXLAN 엔드포인트를 구성합니다.

그림 3.2. VXLAN 프로비저닝 네트워크 토폴로지

4장. 오버클라우드 구성

언더클라우드를 설정한 후에는 일련의 구성 파일을 사용하여 나머지 오버클라우드 리프팅 네트워크를 구성할 수 있습니다. 나머지 오버클라우드 리프 네트워크를 구성하고 오버클라우드를 배포한 후 결과 배포에는 라우팅이 사용 가능한 여러 세트가 있습니다.

4.1. 네트워크 데이터 파일 생성

리프팅 네트워크를 정의하려면 구성 가능 각 네트워크와 해당 특성의 YAML 형식 목록이 포함된 네트워크 데이터 파일을 만듭니다. subnets 매개 변수를 사용하여 기본 네트워크로 추가 Leaf 서브넷을 정의합니다.

절차

  1. stack 사용자의 홈 디렉터리에 새 network_data_spine_leaf.yaml 파일을 만듭니다. 기본 network_data_subnets_routed.yaml 파일을 기준으로 사용합니다.

    $ cp /usr/share/openstack-tripleo-heat-templates/network_data_subnets_routed.yaml /home/stack/network_data_spine_leaf.yaml
    Copy to Clipboard Toggle word wrap
  2. network_data_spine_leaf.yaml 파일에서 YAML 목록을 편집하여 각 기본 네트워크와 각 리프 서브넷을 구성 가능한 네트워크 항목으로 정의합니다. 다음 예제 구문을 사용하여 기본 랩과 두 개의 리프 서브넷을 정의합니다.

    - name: <base_name>
      name_lower: <lowercase_name>
      vip: <true/false>
      vlan: '<vlan_id>'
      ip_subnet: '<network_address>/<prefix>'
      allocation_pools: [{'start': '<start_address>', 'end': '<end_address>'}]
      gateway_ip: '<router_ip_address>'
      subnets:
        <leaf_subnet_name>:
          vlan: '<vlan_id>'
          ip_subnet: '<network_address>/<prefix>'
          allocation_pools: [{'start': '<start_address>', 'end': '<end_address>'}]
          gateway_ip: '<router_ip_address>'
        <leaf_subnet_name>:
          vlan: '<vlan_id>'
          ip_subnet: '<network_address>/<prefix>'
          allocation_pools: [{'start': '<start_address>', 'end': '<end_address>'}]
          gateway_ip: '<router_ip_address>'
    Copy to Clipboard Toggle word wrap

    다음 예제에서는 내부 API 네트워크와 해당 네트워크를 정의하는 방법을 보여줍니다.

    - name: InternalApi
      name_lower: internal_api
      vip: true
      vlan: 10
      ip_subnet: '172.18.0.0/24'
      allocation_pools: [{'start': '172.18.0.4', 'end': '172.18.0.250'}]
      gateway_ip: '172.18.0.1'
      subnets:
        internal_api_leaf1:
          vlan: 11
          ip_subnet: '172.18.1.0/24'
          allocation_pools: [{'start': '172.18.1.4', 'end': '172.18.1.250'}]
          gateway_ip: '172.18.1.1'
        internal_api_leaf2:
          vlan: 12
          ip_subnet: '172.18.2.0/24'
          allocation_pools: [{'start': '172.18.2.4', 'end': '172.18.2.250'}]
          gateway_ip: '172.18.2.1'
    Copy to Clipboard Toggle word wrap
참고

언더클라우드에서 이미 이러한 네트워크를 생성했기 때문에 네트워크 데이터 파일에서 컨트롤 플레인 네트워크를 정의하지 않습니다. 그러나 오버클라우드에서 적절하게 NIC를 구성할 수 있도록 매개변수를 수동으로 설정해야 합니다.

참고

컨트롤러 기반 서비스가 포함된 네트워크에 대해 vip: true 를 정의합니다. 이 예에서 InternalApiLeaf0 에는 이러한 서비스가 포함되어 있습니다.

4.2. 역할 데이터 파일 생성

각 프레임에 대해 구성 가능한 각 역할을 정의하고 구성 가능한 네트워크를 각 역할에 연결하려면 다음 단계를 완료합니다.

절차

  1. stack 사용자의 홈 디렉터리에 사용자 지정 역할 디렉터리를 생성합니다.

    $ mkdir ~/roles
    Copy to Clipboard Toggle word wrap
  2. director 코어 템플릿 컬렉션의 기본 컨트롤러, 계산 및 Ceph Storage 역할을 roles 디렉터리에 복사합니다. Compute 및 Ceph Storage의 파일 이름을 Leaf 0에 맞게 변경합니다.

    $ cp /usr/share/openstack-tripleo-heat-templates/roles/Controller.yaml ~/roles/Controller.yaml
    $ cp /usr/share/openstack-tripleo-heat-templates/roles/Compute.yaml ~/roles/Compute0.yaml
    $ cp /usr/share/openstack-tripleo-heat-templates/roles/CephStorage.yaml ~/roles/CephStorage0.yaml
    Copy to Clipboard Toggle word wrap
  3. Leaf 0 Compute 및 Ceph Storage 파일을 Leaf 1 및 Leaf 2 파일의 기준으로 복사합니다.

    $ cp ~/roles/Compute0.yaml ~/roles/Compute1.yaml
    $ cp ~/roles/Compute0.yaml ~/roles/Compute2.yaml
    $ cp ~/roles/CephStorage0.yaml ~/roles/CephStorage1.yaml
    $ cp ~/roles/CephStorage0.yaml ~/roles/CephStorage2.yaml
    Copy to Clipboard Toggle word wrap
  4. Leaf 0, Leaf 1 및 Leaf 2 파일에서 name,HostnameFormatDefaultdeprecated_nic_config_name 매개 변수를 편집하여 해당 Leaf 매개 변수와 정렬되도록 합니다. 예를 들어 Leaf 0 Compute 파일의 매개변수에는 다음과 같은 값이 있습니다.

    - name: ComputeLeaf0
      HostnameFormatDefault: '%stackname%-compute-leaf0-%index%'
      deprecated_nic_config_name: 'computeleaf0.yaml'
    Copy to Clipboard Toggle word wrap

    Leaf 0 Ceph Storage 매개변수의 값은 다음과 같습니다.

    - name: CephStorageLeaf0
      HostnameFormatDefault: '%stackname%-cephstorage-leaf0-%index%'
      deprecated_nic_config_name: 'ceph-strorageleaf0.yaml'
    Copy to Clipboard Toggle word wrap
  5. 각 Leaf 네트워크 매개변수에 맞게 Leaf 1 및 Leaf 2 파일에서 network 매개 변수를 편집합니다. 예를 들어 Leaf 1 Compute 파일의 매개변수에는 다음과 같은 값이 있습니다.

    - name: ComputeLeaf1
      networks:
        InternalApi:
          subnet: internal_api_leaf1
        Tenant:
          subnet: tenant_leaf1
        Storage:
          subnet: storage_leaf1
    Copy to Clipboard Toggle word wrap

    Leaf 1 Ceph Storage 매개변수의 값은 다음과 같습니다.

    - name: CephStorageLeaf1
      networks:
        Storage:
          subnet: storage_leaf1
        StorageMgmt:
          subnet: storage_mgmt_leaf1
    Copy to Clipboard Toggle word wrap
    참고

    이는 Leaf 1 및 Leaf 2에만 적용됩니다. Leaf 0의 network 매개 변수에는 _subnet 접미사가 결합된 각 서브넷의 소문자로 사용되는 기본 서브넷 값이 포함됩니다. 예를 들어 Leaf 0의 내부 API는 internal_api_subnet 입니다.

  6. 역할 구성이 완료되면 다음 명령을 실행하여 전체 역할 데이터 파일을 생성합니다.

    $ openstack overcloud roles generate --roles-path ~/roles -o roles_data_spine_leaf.yaml Controller Compute Compute1 Compute2 CephStorage CephStorage1 CephStorage2
    Copy to Clipboard Toggle word wrap

    이렇게 하면 각 풀 네트워크에 대한 모든 사용자 지정 역할을 포함하는 전체 roles_data_spine_leaf.yaml 파일이 생성됩니다.

각 역할에는 자체 NIC 구성이 있습니다. 스파인-리프형 구성을 구성하기 전에 현재 NIC 구성에 맞게 기본 NIC 템플릿 세트를 생성해야 합니다.

4.3. 사용자 정의 NIC 구성 생성

각 역할에는 고유한 NIC 구성이 필요합니다. NIC 템플릿 기본 세트의 사본을 생성하고 새 템플릿을 해당 NIC 구성 리소스에 매핑하려면 다음 단계를 완료합니다.

절차

  1. 코어 heat 템플릿 디렉터리로 변경합니다.

    $ cd /usr/share/openstack-tripleo-heat-templates
    Copy to Clipboard Toggle word wrap
  2. tools/process-templates.py 스크립트, 사용자 지정 network_data 파일 및 사용자 지정 roles_data 파일을 사용하여 Jinja2 템플릿을 렌더링합니다.

    $ tools/process-templates.py \
        -n /home/stack/network_data_spine_leaf.yaml \
        -r /home/stack/roles_data_spine_leaf.yaml \
        -o /home/stack/openstack-tripleo-heat-templates-spine-leaf
    Copy to Clipboard Toggle word wrap
  3. 홈 디렉터리로 변경합니다.

    $ cd /home/stack
    Copy to Clipboard Toggle word wrap
  4. 스파인-리프형 템플릿의 기반으로 사용할 기본 NIC 템플릿 중 하나에서 콘텐츠를 복사합니다. 예를 들어 single-nic-vlans NIC 템플릿을 복사합니다.

    $ cp -r openstack-tripleo-heat-templates-spine-leaf/network/config/single-nic-vlans/* /home/stack/templates/spine-leaf-nics/.
    Copy to Clipboard Toggle word wrap
  5. /home/stack/templates/spine-leaf-nics/ 의 각 NIC 구성을 편집하고 구성 스크립트의 위치를 절대 위치로 변경합니다. 다음 코드 조각과 유사한 네트워크 구성 섹션으로 스크롤합니다.

    resources:
      OsNetConfigImpl:
        type: OS::Heat::SoftwareConfig
        properties:
          group: script
          config:
            str_replace:
              template:
                get_file: ../../scripts/run-os-net-config.sh
              params:
                $network_config:
                  network_config:
    Copy to Clipboard Toggle word wrap

    스크립트의 위치를 절대 경로로 변경합니다.

    resources:
      OsNetConfigImpl:
        type: OS::Heat::SoftwareConfig
        properties:
          group: script
          config:
            str_replace:
              template:
                get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh
              params:
                $network_config:
                  network_config:
    Copy to Clipboard Toggle word wrap

    각 Leaf의 각 파일에서 변경한 후 변경 사항을 저장합니다.

    참고

    추가 NIC 변경 사항은 Advanced Overcloud Customization 가이드의 사용자 지정 네트워크 인터페이스 템플릿 을 참조하십시오.

  6. 스파인 -leaf-nics.yaml 이라는 파일을 생성하고 파일을 편집합니다.
  7. 파일에 resource_registry 섹션을 만들고 각 NIC 템플릿에 매핑되는 ::Net::SoftwareConfig 리소스 세트를 추가합니다.

    resource_registry:
      OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/spine-leaf-nics/controller.yaml
      OS::TripleO::ComputeLeaf0::Net::SoftwareConfig: /home/stack/templates/spine-leaf-nics/computeleaf0.yaml
      OS::TripleO::ComputeLeaf1::Net::SoftwareConfig: /home/stack/templates/spine-leaf-nics/computeleaf1.yaml
      OS::TripleO::ComputeLeaf2::Net::SoftwareConfig: /home/stack/templates/spine-leaf-nics/computeleaf2.yaml
      OS::TripleO::CephStorageLeaf0::Net::SoftwareConfig: /home/stack/templates/spine-leaf-nics/ceph-storageleaf0.yaml
      OS::TripleO::CephStorageLeaf1::Net::SoftwareConfig: /home/stack/templates/spine-leaf-nics/ceph-storageleaf1.yaml
      OS::TripleO::CephStorageLeaf2::Net::SoftwareConfig: /home/stack/templates/spine-leaf-nics/ceph-storageleaf2.yaml
    Copy to Clipboard Toggle word wrap

    이러한 리소스 매핑은 배포 중에 기본 리소스 매핑을 재정의합니다.

  8. scaling -leaf-nics.yaml 파일을 저장합니다.
  9. 렌더링된 템플릿 디렉터리를 제거합니다.

    $ rm -rf openstack-tripleo-heat-templates-spine-leaf
    Copy to Clipboard Toggle word wrap

    이 절차에서는 이제 필요한 ::Net::SoftwareConfig 리소스를 매핑하는 NIC 템플릿 세트와 환경 파일을 사용할 수 있게 되었습니다.

  10. openstack overcloud deploy 명령을 실행하면 환경 파일을 다음 순서로 포함해야 합니다.

    1. /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml 을 통해 네트워크를 분리할 수 있습니다. director는 network-isolation.j2.yaml Jinja2 템플릿에서 이 파일을 렌더링합니다.
    2. /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml 은 기본 NIC 리소스 매핑을 포함한 기본 네트워크 환경 파일입니다. director는 network-environment.j2.yaml Jinja2 템플릿에서 이 파일을 렌더링합니다.
    3. 사용자 정의 NIC 리소스 매핑을 포함하고 기본 NIC 리소스 매핑을 재정의하는 /home/stack/templates/spine-leaf-nics.yaml.

      다음 명령 스니펫에서는 순서를 보여줍니다.

      $ openstack overcloud deploy --templates
          ...
          -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
          -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
          -e /home/stack/templates/spine-leaf-nics.yaml \
          ...
      Copy to Clipboard Toggle word wrap
  11. 다음 섹션의 절차를 완료하여 네트워크 환경 파일에 세부 정보를 추가하고 스파인 리프 아키텍처의 특정 측면을 정의합니다. 이 구성을 완료한 후 openstack overcloud deploy 명령에 이 파일을 포함합니다.

4.4. 컨트롤 플레인 매개변수 설정

일반적으로 network _data 파일을 사용하여 격리된 스파인-리프 네트워크에 대한 네트워킹 세부 정보를 정의합니다. 예외는 언더클라우드가 생성하는 컨트롤 플레인 네트워크입니다. 그러나 오버클라우드는 각 리프에 대한 컨트롤 플레인에 액세스해야 합니다. 이 액세스를 활성화하려면 배포에 추가 매개변수를 정의해야 합니다.

이 예에서는 Leaf 0에서 각 컨트롤 플레인 네트워크에 대한 IP, 서브넷 및 기본 경로를 정의합니다.

절차

  1. 스파인 -leaf-ctlplane.yaml 이라는 파일을 생성하고 파일을 편집합니다.
  2. 파일에 parameter_defaults 섹션을 생성하고 각 스파인-리프형 네트워크에 대한 컨트롤 플레인 서브넷 매핑을 추가합니다.

    parameter_defaults:
      ...
      ControllerControlPlaneSubnet: leaf0
      Compute0ControlPlaneSubnet: leaf0
      Compute1ControlPlaneSubnet: leaf1
      Compute2ControlPlaneSubnet: leaf2
      CephStorage0ControlPlaneSubnet: leaf0
      CephStorage1ControlPlaneSubnet: leaf1
      CephStorage2ControlPlaneSubnet: leaf2
    Copy to Clipboard Toggle word wrap
  3. 스파인 -리프형-ctlplane.yaml 파일을 저장합니다.

4.5. 가상 IP 주소의 서브넷 설정

컨트롤러 역할은 일반적으로 각 네트워크에 대한 가상 IP(VIP) 주소를 호스팅합니다. 기본적으로 오버클라우드는 컨트롤 플레인을 제외한 각 네트워크의 기본 서브넷에서 VIP를 사용합니다. 컨트롤 플레인은 표준 언더클라우드 설치 중에 생성된 기본 서브넷 이름인 ctlplane-subnet 을 사용합니다.

이 스파인 리프린트 시나리오에서 기본 기본 프로비저닝 네트워크는 ctlplane-subnet 대신lev 0 입니다. 즉 컨트롤 플레인 VIP가 사용하는 서브넷을 변경하려면 VipSubnetMap 매개변수에 덮어쓰기 값을 추가해야 합니다.

또한 각 네트워크의 VIP가 하나 이상의 네트워크 기본 서브넷을 사용하지 않는 경우, 컨트롤러 노드를 연결하는 L2 네트워크 세그먼트와 연결된 서브넷에서 VIP를 생성하도록 VipSubnetMap 매개변수에 재정의를 추가해야 합니다.

절차:

  1. 스파인 -leaf-vips.yaml 이라는 파일을 생성하고 파일을 편집합니다.
  2. 파일에 parameter_defaults 섹션을 생성하고 요구 사항에 따라 VipSubnetMap 매개변수를 추가합니다.

    • provisioning/ 컨트롤 플레인 네트워크에 evict0 을 사용하는 경우 ctlplane VIP remapping을cup 0으로 설정합니다.

      parameter_defaults:
        VipSubnetMap:
          ctlplane: leaf0
      Copy to Clipboard Toggle word wrap
    • 여러 VIP에 다른 Leaf를 사용하는 경우 이러한 요구 사항에 맞게 VIP 다시 매핑을 설정합니다. 예를 들어 다음 스니펫을 사용하여 모든 VIP에 gem 1을 사용하도록 Vip SubnetMap 매개변수를 구성합니다.

      parameter_defaults:
        VipSubnetMap:
          ctlplane: leaf1
          redis: internal_api_leaf1
          InternalApi: internal_api_leaf1
          Storage: storage_leaf1
          StorageMgmt: storage_mgmt_leaf1
      Copy to Clipboard Toggle word wrap
  3. 스파인-리프-vips.yaml 파일을 저장합니다.

4.6. 별도의 네트워크 매핑

기본적으로 OpenStack Platform에서는 외부 네트워크 액세스를 위해 모든 컨트롤러 및 컴퓨팅 노드가 단일 L2 네트워크에 연결해야 하는 OVN(Open Virtual Network)을 사용합니다. 즉, 컨트롤러 및 계산 네트워크 구성 둘 다 br-ex 브리지를 사용하므로 director가 기본적으로 오버클라우드의 datacentre 네트워크에 매핑됩니다. 일반적으로 이 매핑은 플랫 네트워크 매핑 또는 VLAN 네트워크 매핑에 사용됩니다. 스파인 리프팅 아키텍처에서는 각 Leaf가 엣지 컴퓨팅 시나리오의 경우 대부분 해당 Leaf의 특정 브리지 또는 VLAN을 통해 트래픽을 라우팅하도록 이러한 매핑을 변경할 수 있습니다.

절차

  1. 스파인 -leaf-separate.yaml 이라는 파일을 생성하고 파일을 편집합니다.
  2. span -leaf-separate.yaml 파일에 parameter_defaults 섹션을 생성하고 각 스파인-리프 네트워크에 대한 외부 네트워크 매핑을 포함합니다.

    • 플랫 네트워크 매핑의 경우 NeutronFlatNetworks 매개변수의 각 Leaf를 나열하고 각 Leaf에 대해 NeutronBridgeMappings 매개변수를 설정합니다.

      parameter_defaults:
        NeutronFlatNetworks: leaf0,leaf1,leaf2
        Controller0Parameters:
          NeutronBridgeMappings: "leaf0:br-ex"
        Compute0Parameters:
          NeutronBridgeMappings: "leaf0:br-ex"
        Compute1Parameters:
          NeutronBridgeMappings: "leaf1:br-ex"
        Compute2Parameters:
          NeutronBridgeMappings: "leaf2:br-ex"
      Copy to Clipboard Toggle word wrap
    • VLAN 네트워크 매핑의 경우 추가적으로 NeutronNetworkVLANRanges 를 설정하여 세 개의 Leaf 네트워크에 대해 VLAN을 매핑합니다.

        NeutronNetworkType: 'geneve,vlan'
        NeutronNetworkVLANRanges: 'leaf0:1:1000,leaf1:1:1000,leaf2:1:1000'
      Copy to Clipboard Toggle word wrap
  3. 스파인-리프-separate.yaml 파일을 저장합니다.

4.7. 스파인-리프형 활성화된 오버클라우드 배포

스파인-리프형 오버클라우드 구성을 완료한 경우 다음 단계를 완료하여 각 파일을 검토한 다음 배포 명령을 실행합니다.

절차

  1. /home/stack/template/network_data_spine_leaf.yaml 파일을 검토하고 각 프레임의 각 네트워크 및 서브넷이 포함되어 있는지 확인합니다.

    참고

    현재 네트워크 서브넷 및 allocation_pools 값에 대한 자동 검증이 없습니다. 이러한 값을 일관되게 정의하고 기존 네트워크와 충돌하지 않는지 확인합니다.

  2. /home/stack/templates/roles_data_spine_leaf.yaml 값을 검토하고 각 리프에 대한 역할을 정의했는지 확인합니다.
  3. ~/templates/spine-leaf-nics/ 디렉터리에서 NIC 템플릿을 검토하고 각 출력에서 각 역할에 대한 인터페이스를 올바르게 정의했는지 확인합니다.
  4. 사용자 지정 스파인-leaf-nics.yaml 환경 파일을 검토하고 각 역할의 사용자 지정 NIC 템플릿을 참조하는 resource_registry 섹션이 포함되어 있는지 확인합니다.
  5. /home/stack/templates/nodes_data.yaml 파일을 검토하고 모든 역할에 플레이버와 노드 수가 할당되어 있는지 확인합니다. 또한 각 노드마다 모든 노드에 올바르게 태그가 지정되어 있는지 확인합니다.
  6. openstack overcloud deploy 명령을 실행하여 스파인 리프 구성을 적용합니다. 예를 들면 다음과 같습니다.

    $ openstack overcloud deploy --templates \
        -n /home/stack/templates/network_data_spine_leaf.yaml \
        -r /home/stack/templates/roles_data_spine_leaf.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
        -e /home/stack/templates/spine-leaf-nics.yaml \
        -e /home/stack/templates/spine-leaf-ctlplane.yaml \
        -e /home/stack/templates/spine-leaf-vips.yaml \
        -e /home/stack/templates/spine-leaf-separate.yaml \
        -e /home/stack/templates/nodes_data.yaml \
        -e [OTHER ENVIRONMENT FILES]
    Copy to Clipboard Toggle word wrap
    • network-isolation.yaml 은 동일한 위치(network-isolation.j2.yaml)에 있는 Jinja2 파일의 렌더링 이름입니다. 배포 명령에 이 파일을 포함하여 director가 각 네트워크를 올바른 라벨에 격리하는지 확인합니다. 이렇게 하면 오버클라우드 생성 프로세스 중에 네트워크가 동적으로 생성됩니다.
    • network- isolation.yaml 뒤에 network-environment.yaml 파일을 포함합니다. network-environment.yaml 파일은 구성 가능한 네트워크 매개 변수에 대한 기본 네트워크 구성을 제공합니다.
    • network -environment.yaml 뒤에 스파인-leaf-nics.yaml 파일을 포함합니다. 스파인 -리프-nics.yaml 파일은 network-environment.yaml 파일의 기본 NIC 템플릿 매핑을 재정의합니다.
    • 다른 스파인 폴링 네트워크 환경 파일을 만든 경우 스파인 -리프-nics.yaml 파일 다음에 이러한 환경 파일을 포함합니다.
    • 추가 환경 파일을 추가합니다. 예를 들어 컨테이너 이미지 위치 또는 Ceph 클러스터 구성이 있는 환경 파일은 다음과 같습니다.
  7. 스파인-리프형이 활성화된 Overcloud가 배포될 때까지 기다립니다.

4.8. 스파인-리프 배포에 새 리프 추가

네트워크 용량을 늘리거나 새 물리적 사이트를 추가할 때 RHOSP(Red Hat OpenStack Platform) 스파인-리프(Red Hat OpenStack Platform)의 새 리프가 필요할 수 있습니다.

사전 요구 사항

  • RHOSP 배포에서는 스파인-리프형 네트워크 토폴로지를 사용합니다.

절차

  1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.
  2. 언더클라우드 인증 정보 파일을 가져옵니다.

    $ source ~/stackrc
    Copy to Clipboard Toggle word wrap
  3. /usr/share/openstack-tripleo-heat-templates/network_data_spine_leaf.yaml 파일에서 추가하는 새 리프에 대한 구성 가능 네트워크 항목으로 리프 서브넷을 추가합니다.

    예제

    이 예에서는 새 리프(leaf3)에 대한 서브넷 항목이 추가되었습니다.

    - name: InternalApi
      name_lower: internal_api
      vip: true
      vlan: 10
      ip_subnet: '172.18.0.0/24'
      allocation_pools: [{'start': '172.18.0.4', 'end': '172.18.0.250'}]
      gateway_ip: '172.18.0.1'
      subnets:
        internal_api_leaf1:
          vlan: 11
          ip_subnet: '172.18.1.0/24'
          allocation_pools: [{'start': '172.18.1.4', 'end': '172.18.1.250'}]
          gateway_ip: '172.18.1.1'
        internal_api_leaf2:
          vlan: 12
          ip_subnet: '172.18.2.0/24'
          allocation_pools: [{'start': '172.18.2.4', 'end': '172.18.2.250'}]
          gateway_ip: '172.18.2.1'
        internal_api_leaf3:
          vlan: 13
          ip_subnet: '172.18.3.0/24'
          allocation_pools: [{'start': '172.18.3.4', 'end': '172.18.3.250'}]
          gateway_ip: '172.18.3.1'
    Copy to Clipboard Toggle word wrap
  4. 추가할 새 리프에 대한 역할 데이터 파일을 만듭니다.

    1. 추가 중인 새 리프에 사용할 리프 컴퓨팅 및 리프 Ceph Storage 파일을 복사합니다.

      예제

      이 예에서는 Compute1.yamlCephStorage1.yaml 이 새로운 리프, Compute3.yamlCephStorage3.yaml 로 복사되며, 이를 다시 실행합니다.

      $ cp ~/roles/Compute1.yaml ~/roles/Compute3.yaml
      $ cp ~/roles/CephStorage1.yaml ~/roles/CephStorage3.yaml
      Copy to Clipboard Toggle word wrap
    2. 새 리프 파일에서 이름,HostnameFormatDefaultdeprecated_nic_config_name 매개변수를 편집하여 해당 Leaf 매개변수와 일치하도록 합니다.

      예제

      예를 들어 Leaf 1 Compute 파일의 매개변수에는 다음과 같은 값이 있습니다.

      - name: ComputeLeaf1
        HostnameFormatDefault: '%stackname%-compute-leaf1-%index%'
        deprecated_nic_config_name: 'computeleaf1.yaml'
      Copy to Clipboard Toggle word wrap

      예제

      Leaf 1 Ceph Storage 매개변수의 값은 다음과 같습니다.

      - name: CephStorageLeaf1
        HostnameFormatDefault: '%stackname%-cephstorage-leaf1-%index%'
        deprecated_nic_config_name: 'ceph-strorageleaf1.yaml'
      Copy to Clipboard Toggle word wrap
    3. 새 리프 파일에서 네트워크 매개 변수를 편집하여 해당 Leaf 네트워크 매개 변수와 일치하도록 합니다.

      예제

      예를 들어 Leaf 1 Compute 파일의 매개변수에는 다음과 같은 값이 있습니다.

      - name: ComputeLeaf1
        networks:
          InternalApi:
            subnet: internal_api_leaf1
          Tenant:
            subnet: tenant_leaf1
          Storage:
            subnet: storage_leaf1
      Copy to Clipboard Toggle word wrap

      예제

      Leaf 1 Ceph Storage 매개변수의 값은 다음과 같습니다.

      - name: CephStorageLeaf1
        networks:
          Storage:
            subnet: storage_leaf1
          StorageMgmt:
            subnet: storage_mgmt_leaf1
      Copy to Clipboard Toggle word wrap
    4. 역할 구성이 완료되면 다음 명령을 실행하여 전체 역할 데이터 파일을 생성합니다. 네트워크에 있는 모든 리프와 추가하는 새 리프를 포함합니다.

      예제

      이 예에서는 leaf3이 leaf0, leaf1 및 leaf2에 추가됩니다.

      $ openstack overcloud roles generate --roles-path ~/roles -o roles_data_spine_leaf.yaml Controller Compute Compute1 Compute2 Compute3 CephStorage CephStorage1 CephStorage2 CephStorage3
      Copy to Clipboard Toggle word wrap

      이렇게 하면 각 풀 네트워크에 대한 모든 사용자 지정 역할을 포함하는 전체 roles_data_spine_leaf.yaml 파일이 생성됩니다.

  5. 추가하는 리프에 대한 사용자 정의 NIC 구성을 만듭니다.

    1. 추가 중인 새 리프에 사용할 리프 컴퓨팅 및 리프 Ceph Storage NIC 구성 파일을 복사합니다.

      예제

      이 예에서 computeleaf1.yamlceph-storageleaf1.yaml 은 새로운 리프, computeleaf3.yamlceph-storageleaf3.yaml 용으로 복사됩니다.

      $ cp ~/templates/spine-leaf-nics/computeleaf1.yaml ~/templates/spine-leaf-nics/computeleaf3.yaml
      $ cp ~/templates/spine-leaf-nics/ceph-storageleaf1.yaml ~/templates/spine-leaf-nics/ceph-storageleaf3.yaml
      Copy to Clipboard Toggle word wrap
    2. 파일의 resource_registry 섹션에서 /usr/share/openstack-tripleo-heat-templates/network_data_spine_leaf.yaml 에서 각 NIC 템플릿에 매핑되는 ::Net::SoftwareConfig 리소스 세트를 추가합니다.

      예제

      이 예에서는 새로운 리프 NIC 구성 파일(computeleaf3.yamlceph-storageleaf3.yaml)이 추가되었습니다.

      resource_registry:
        OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/spine-leaf-nics/controller.yaml
        OS::TripleO::ComputeLeaf0::Net::SoftwareConfig: /home/stack/templates/spine-leaf-nics/computeleaf0.yaml
        OS::TripleO::ComputeLeaf1::Net::SoftwareConfig: /home/stack/templates/spine-leaf-nics/computeleaf1.yaml
        OS::TripleO::ComputeLeaf2::Net::SoftwareConfig: /home/stack/templates/spine-leaf-nics/computeleaf2.yaml
        OS::TripleO::ComputeLeaf3::Net::SoftwareConfig: /home/stack/templates/spine-leaf-nics/computeleaf3.yaml
        OS::TripleO::CephStorageLeaf0::Net::SoftwareConfig: /home/stack/templates/spine-leaf-nics/ceph-storageleaf0.yaml
        OS::TripleO::CephStorageLeaf1::Net::SoftwareConfig: /home/stack/templates/spine-leaf-nics/ceph-storageleaf1.yaml
        OS::TripleO::CephStorageLeaf2::Net::SoftwareConfig: /home/stack/templates/spine-leaf-nics/ceph-storageleaf2.yaml
        OS::TripleO::CephStorageLeaf3::Net::SoftwareConfig: /home/stack/templates/spine-leaf-nics/ceph-storageleaf3.yaml
      Copy to Clipboard Toggle word wrap

      이러한 리소스 매핑은 배포 중에 기본 리소스 매핑을 재정의합니다.

      이 절차에서는 이제 필요한 ::Net::SoftwareConfig 리소스를 매핑하는 NIC 템플릿 세트와 환경 파일을 사용할 수 있게 되었습니다. 결국 openstack overcloud deploy 명령을 실행할 때 환경 파일을 다음 순서로 포함해야 합니다.

    3. /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml 을 통해 네트워크를 분리할 수 있습니다.

      director는 network-isolation.j2.yaml Jinja2 템플릿에서 이 파일을 렌더링합니다.

    4. /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml 은 기본 NIC 리소스 매핑을 포함한 기본 네트워크 환경 파일입니다.

      director는 network-environment.j2.yaml Jinja2 템플릿에서 이 파일을 렌더링합니다.

    5. 사용자 정의 NIC 리소스 매핑을 포함하고 기본 NIC 리소스 매핑을 재정의하는 /home/stack/templates/spine-leaf-nics.yaml.

      다음 명령 스니펫에서는 순서를 보여줍니다.

      $ openstack overcloud deploy --templates
          ...
          -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
          -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
          -e /home/stack/templates/spine-leaf-nics.yaml \
          ...
      Copy to Clipboard Toggle word wrap
  6. 컨트롤 플레인 매개변수를 업데이트합니다.

    ~/templates/spine-leaf-ctlplane.yamlparameter_defaults 섹션의 새 리프 네트워크에 대한 컨트롤 플레인 서브넷 매핑을 추가합니다.

    예제

    이 예에서는 새 리프(leaf3) 항목이 추가되었습니다.

    parameter_defaults:
      ...
      ControllerControlPlaneSubnet: leaf0
      Compute0ControlPlaneSubnet: leaf0
      Compute1ControlPlaneSubnet: leaf1
      Compute2ControlPlaneSubnet: leaf2
      Compute3ControlPlaneSubnet: leaf3
      CephStorage0ControlPlaneSubnet: leaf0
      CephStorage1ControlPlaneSubnet: leaf1
      CephStorage2ControlPlaneSubnet: leaf2
      CephStorage3ControlPlaneSubnet: leaf3
    Copy to Clipboard Toggle word wrap
  7. 새 리프 네트워크를 매핑합니다.

    ~/templates/spine-leaf-separate.yamlparameter_defaults 섹션에 새 리프 네트워크에 대한 외부 네트워크 매핑을 포함합니다.

    • 플랫 네트워크 매핑의 경우 NeutronFlatNetworks 매개변수에 새리프( leaf3)를 나열하고 새 리프에 대한 NeutronBridgeMappings 매개변수를 설정합니다.

      parameter_defaults:
        NeutronFlatNetworks: leaf0,leaf1,leaf2, leaf3
        Controller0Parameters:
          NeutronBridgeMappings: "leaf0:br-ex"
        Compute0Parameters:
          NeutronBridgeMappings: "leaf0:br-ex"
        Compute1Parameters:
          NeutronBridgeMappings: "leaf1:br-ex"
        Compute2Parameters:
          NeutronBridgeMappings: "leaf2:br-ex"
        Compute3Parameters:
          NeutronBridgeMappings: "leaf3:br-ex"
      Copy to Clipboard Toggle word wrap
    • VLAN 네트워크 매핑의 경우 새 리프(leaf3) 네트워크에 VLAN을 매핑하도록 NeutronNetworkVLANRanges 를 추가로 설정합니다.

        NeutronNetworkType: 'geneve,vlan'
        NeutronNetworkVLANRanges: 'leaf0:1:1000,leaf1:1:1000,leaf2:1:1000,leaf3:1:1000'
      Copy to Clipboard Toggle word wrap
  8. 4.7절. “스파인-리프형 활성화된 오버클라우드 배포” 의 단계에 따라 스파인-리프가 활성화된 오버클라우드를 다시 배포합니다.

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat
맨 위로 이동