3장. 오버클라우드 플래닝
다음 섹션에서는 Red Hat OpenStack Platform 환경의 여러 측면을 플래닝하는 몇 가지 지침을 제공합니다. 여기에는 노드 역할 정의, 네트워크 토폴로지 플래닝 및 스토리지가 포함됩니다.
3.1. 노드 배포 역할 플래닝
director는 오버클라우드 빌드에 대한 여러 기본 노드 유형을 제공합니다. 이러한 노드 유형은 다음과 같습니다.
- Controller
환경을 제어하기 위한 주요 서비스를 제공합니다. 대시보드(horizon), 인증(keystone), 이미지 스토리지(glance), 네트워킹(neutron), 오케스트레이션(heat) 및 고가용성 서비스(Controller 노드를 두 개 이상 사용하는 경우)가 여기에 포함됩니다. Red Hat OpenStack Platform 환경에는 다음 중 하나가 필요합니다.
- 기본 환경을 위한 노드 한 개
- 고가용성 환경을 위한 노드 세 개
노드가 두 개 있거나 4개 이상 있는 환경은 지원되지 않습니다.
- Compute
- 하이퍼바이저 역할을 하고 환경에서 가상 머신을 실행하는 데 필요한 처리 기능을 제공하는 물리적 서버입니다. 기본 Red Hat OpenStack Platform 환경에는 Compute 노드가 적어도 한 개 이상 필요합니다.
- Ceph-Storage
- Red Hat Ceph Storage를 제공하는 호스트입니다. 추가 Ceph Storage 호스트는 클러스터에서 확장될 수 있습니다. 이 배포 역할은 선택 사항입니다.
- Cinder-Storage
- OpenStack의 Cinder 서비스에 외부 블록 스토리지를 제공하는 호스트입니다. 이 배포 역할은 선택 사항입니다.
- Swift-Storage
- OpenStack의 Swift 서비스에 외부 오브젝트 스토리지를 제공하는 호스트입니다. 이 배포 역할은 선택 사항입니다.
다음 표에서는 다른 오버클라우드 구성 예와 각 시나리오에 사용되는 노드 유형을 정의합니다.
Controller |
Compute |
Ceph-Storage |
Swift-Storage |
Cinder-Storage |
합계 | |
소규모 오버클라우드 |
1 |
1 |
- |
- |
- |
2 |
중간 규모 오버클라우드 |
1 |
3 |
- |
- |
- |
4 |
추가 Object Storage 및 Block Storage가 있는 중간 규모의 오버클라우드 |
1 |
3 |
- |
1 |
1 |
6 |
고가용성이 있는 중간 규모의 오버클라우드 |
3 |
3 |
- |
- |
- |
6 |
고가용성 및 Ceph Storage가 있는 중간 규모의 오버클라우드 |
3 |
3 |
3 |
- |
- |
9 |
또한 개별 서비스를 사용자 정의 역할로 분할할 것인지 고려하십시오. 작성 가능한 역할 아키텍처에 대한 자세한 내용은 오버클라우드 고급 사용자 정의 가이드에서 8장. 작성 가능한 역할 및 서비스를 참조하십시오.
3.2. 네트워크 플래닝
역할 및 서비스를 적절하게 매핑하여 서로 올바르게 통신할 수 있도록 해당 환경의 네트워킹 토폴로지와 서브넷을 계획하는 것이 중요합니다. Red Hat OpenStack Platform은 자율적으로 작동하고 소프트웨어 기반 네트워크, 정적 및 유동 IP 주소, DHCP를 관리하는 neutron 네트워킹 서비스를 사용합니다. director는 오버클라우드 환경의 각 Controller 노드에 이 서비스를 배포합니다.
Red Hat OpenStack Platform은 환경의 여러 서브넷에 할당된 별도의 네트워크 트래픽 유형에 다양한 서비스를 매핑합니다. 이러한 네트워크 트래픽 유형은 다음과 같습니다.
네트워크 유형 |
설명 |
사용 용도 |
IPMI |
노드의 전원 관리에 사용되는 네트워크입니다. 이 네트워크는 언더클라우드 설치 전에 사전 정의됩니다. |
모든 노드 |
프로비저닝/컨트롤 플레인 |
director는 이 네트워크 트래픽 유형을 사용하여 PXE 부팅 시 새 노드를 배포하고, 오버클라우드 베어 메탈 서버에 OpenStack Platform 설치를 오케스트레이션합니다. 이 네트워크는 언더클라우드 설치 전에 사전 정의됩니다. |
모든 노드 |
내부 API |
내부 API 네트워크는 API 통신, RPC 메시지 및 데이터베이스 통신을 사용하는 OpenStack 서비스 간 통신에 사용됩니다. |
Controller, Compute, Cinder Storage, Swift Storage |
테넌트 |
Neutron은 VLAN 세그멘테이션(각 테넌트 네트워크가 네트워크 VLAN임) 또는 터널링(VXLAN 또는 GRE를 통해)을 사용하여 각 테넌트에 고유한 네트워크를 제공합니다. 네트워크 트래픽은 각 테넌트 네트워크 내에서 분할됩니다. 각 테넌트 네트워크에는 이와 연결된 IP 서브넷이 있으며, 네트워크 네임스페이스로 인해 여러 테넌트 네트워크에서 충돌을 일으키지 않고 동일한 주소 범위를 사용할 수 있습니다. |
Controller, Compute |
Storage |
Block Storage, NFS, iSCSI 등입니다. 성능상의 이유로 완전히 별도의 스위치 패브릭으로 분리하는 것이 좋습니다. |
모든 노드 |
스토리지 관리 |
OpenStack Object Storage(swift)는 이 네트워크를 사용하여 참여하는 복제 노드 간에 데이터 오브젝트를 동기화합니다. 프록시 서비스는 사용자 요청과 기존 스토리지 계층 사이의 중간 인터페이스 역할을 합니다. 프록시는 들어오는 요청을 수신하고 필요한 복제본을 찾아서 요청된 데이터를 검색합니다. Ceph 백엔드를 사용하는 서비스는 Ceph와 직접 상호 작용하지 않지만, 프런트엔드 서비스를 사용하므로 스토리지 관리 네트워크를 통해 연결됩니다. RBD 드라이버는 예외로, 이 트래픽은 Ceph에 직접 연결됩니다. |
Controller, Ceph Storage, Cinder Storage, Swift Storage |
외부 네트워크 |
OpenStack 대시보드(horizon)를 실행하여 그래픽 시스템 관리, OpenStack 서비스 용 공용 API를 호스팅하는 인스턴스로 들어오는 네트워크 트래픽의 SNAT 처리를 수행합니다. 외부 네트워크가 개인 IP 주소를 사용하는 경우(RFC-1918에 따라) 인터넷에서 들어오는 트래픽에 대해 NAT를 수행해야 합니다. |
Controller |
유동 IP |
수신 트래픽이 유동 IP 주소와 테넌트 네트워크의 인스턴스에 실제로 할당된 IP 주소 간에 1:1 IP 주소 매핑을 사용하는 인스턴스에 연결할 수 있습니다. 외부 네트워크와는 분리된 VLAN에서 유동 IP를 호스팅하는 경우 유동 IP VLAN을 Controller 노드로 트렁크 연결을 사용하고 오버클라우드 생성 후 Neutron을 통해 VLAN을 추가할 수 있습니다. 그러면 여러 브리지에 연결된 유동 IP 네트워크를 여러 개 생성할 수 있습니다. VLAN은 트렁크 연결되지만, 인터페이스로 구성되지는 않습니다. 대신 neutron이 각 유동 IP 네트워크에 대해 선택한 브리지에서 VLAN 세그멘테이션 ID로 OVS 포트를 생성합니다. |
Controller |
관리 |
SSH 액세스, DNS 트래픽 및 NTP 트래픽과 같은 시스템 관리 기능을 제공합니다. 또한 이 네트워크는 Controller 노드 이외의 노드에 대해 게이트웨이 역할을 합니다. |
모든 노드 |
일반적인 Red Hat OpenStack Platform 설치에서는 종종 네트워크 유형의 수가 물리적 네트워크 연결 수를 초과합니다. 모든 네트워크를 적절한 호스트에 연결하기 위해 오버클라우드에서는 VLAN 태그를 사용하여 인터페이스마다 두 개 이상의 네트워크를 제공합니다. 대부분의 네트워크는 서브넷이 분리되어 있지만, 일부는 인터넷 액세스 또는 인프라 네트워크 연결에 라우팅을 제공할 레이어 3 게이트웨이가 필요합니다.
배포 시 neutron VLAN 모드(터널링이 비활성화된 상태)를 사용하려는 경우에도 프로젝트 네트워크(GRE 또는 VXLAN으로 터널링됨)를 배포하는 것이 좋습니다. 이 경우 배포 시 약간의 사용자 정의 작업이 필요하며, 이후에 유틸리티 네트워크 또는 가상화 네트워크로 터널 네트워크를 사용할 수 있는 옵션은 그대로 유지됩니다. VLAN을 사용하여 테넌트 네트워크를 만들지만, 테넌트 VLAN을 사용하지 않고 네트워크를 특별한 용도로 사용하기 위한 VXLAN 터널을 만들 수도 있습니다. 테넌트 VLAN을 사용한 배포에 VXLAN 기능을 추가할 수 있지만, 서비스 중단 없이 기존 오버클라우드에 테넌트 VLAN을 추가할 수 없습니다.
director는 이러한 트래픽 유형 중 6개의 유형을 특정 서브넷이나 VLAN에 매핑하는 방법을 제공합니다. 이러한 트래픽 유형은 다음과 같습니다.
- 내부 API
- Storage
- 스토리지 관리
- 테넌트 네트워크
- 외부 네트워크
- 관리
할당되지 않은 네트워크는 모두 프로비저닝 네트워크와 동일한 서브넷에 자동으로 할당됩니다.
아래 다이어그램은 네트워크가 별도 VLAN으로 분리된 네트워크 토폴로지 예를 보여줍니다. 각 오버클라우드 노드는 본딩에 두 가지 인터페이스(nic2
및 nic3
)를 사용하여 해당 VLAN을 통해 이러한 네트워크를 제공합니다. 또한 각 오버클라우드 노드는 nic1
을 사용하여 기본 VLAN을 통해 프로비저닝 네트워크로 언더클라우드와 통신합니다.
다음 표는 다른 네트워크 레이아웃을 매핑하는 네트워크 트래픽 예를 제공합니다.
매핑 |
총 인터페이스 수 |
총 VLAN 수 | |
외부 액세스 권한이 있는 플랫 네트워크 |
네트워크 1 - 프로비저닝, 내부 API, 스토리지, 스토리지 관리, 테넌트 네트워크 네트워크 2 - 외부, 유동 IP(오버클라우드 생성 후 매핑됨) |
2 |
2 |
분리된 네트워크 |
네트워크 1 - 프로비저닝 네트워크 2 - 내부 API 네트워크 3 - 테넌트 네트워크 네트워크 4 - 스토리지 네트워크 5 - 스토리지 관리 네트워크 6 - 스토리지 관리 네트워크 7 - 외부, 유동 IP(오버클라우드 생성 후 매핑됨) |
3(본딩된 2개의 인터페이스 포함) |
7 |
3.3. 스토리지 플래닝
director는 오버클라우드 환경에 여러 스토리지 옵션을 제공합니다. 이러한 옵션은 다음과 같습니다.
- Ceph Storage 노드
director가 Red Hat Ceph Storage를 사용하여 확장 가능한 스토리지 노드 집합을 생성합니다. 오버클라우드는 각종 노드를 다음의 목적으로 사용합니다.
- 이미지 - Glance는 VM의 이미지를 관리합니다. 이미지는 변경할 수 없습니다. OpenStack에서는 이미지를 바이너리 Blob으로 처리하고 그에 따라 이미지를 다운로드합니다. glance를 사용하여 이미지를 Ceph 블록 장치에 저장할 수 있습니다.
- 볼륨 - Cinder 볼륨은 블록 장치입니다. OpenStack에서는 볼륨을 사용하여 VM을 부팅하거나, 실행 중인 VM에 볼륨을 연결합니다. OpenStack에서는 Cinder 서비스를 사용하여 볼륨을 관리합니다. Cinder를 사용하면 이미지의 CoW (copy-on-write) 복제본을 사용하여 VM을 부팅할 수 있습니다.
게스트 디스크 - 게스트 디스크는 게스트 운영 체제 디스크입니다. 기본적으로 nova로 가상 머신을 부팅하면 해당 디스크가 하이퍼바이저의 파일 시스템에 파일로 표시됩니다(일반적으로
/var/lib/nova/instances/<uuid>/
아래). cinder를 사용하지 않고 Ceph 내에서 모든 가상 머신을 직접 부팅할 수 있으며, 라이브 마이그레이션 프로세스를 통해 쉽게 유지보수 작업을 수행할 수 있으므로 유용합니다. 또한 하이퍼바이저가 중지되는 경우 편리하게nova evacuate
를 트리거하고 다른 위치에서 가상 머신을 중단 없이 실행할 수 있습니다.중요Ceph에서는 가상 머신 디스크를 호스팅할 QCOW2를 지원하지 않습니다. Ceph에서 가상 머신을 부팅하려면(ephemeral 백엔드 또는 볼륨에서 부팅) glance 이미지 포맷이
RAW
여야 합니다.
자세한 내용은 Red Hat Ceph Storage 아키텍처 가이드를 참조하십시오.
- Swift Storage 노드
- director에서 외부 오브젝트 스토리지 노드를 생성합니다. 이는 오버클라우드 환경의 컨트롤러 노드를 확장하거나 교체해야 하지만 고가용성 클러스터 외부에서 오브젝트 스토리지를 유지해야 하는 경우에 유용합니다.