Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
5장. 오버클라우드 플래닝
다음 섹션에서는 Red Hat OpenStack Platform 환경의 여러 측면을 플래닝하는 몇 가지 지침을 제공합니다. 여기에는 노드 역할 정의, 네트워크 토폴로지 플래닝 및 스토리지가 포함됩니다.
5.1. 노드 역할
director는 오버클라우드 빌드에 대한 여러 기본 노드 유형을 제공합니다. 이러한 노드 유형은 다음과 같습니다.
- Controller
환경을 제어하기 위한 주요 서비스를 제공합니다. 대시보드(horizon), 인증(keystone), 이미지 스토리지(glance), 네트워킹(neutron), 오케스트레이션(heat) 및 고가용성 서비스가 여기에 포함됩니다. Red Hat OpenStack Platform 환경에는 고가용성 환경을 위한 3개의 컨트롤러 노드가 필요합니다.
참고하나의 노드로 구성된 환경은 테스트 목적으로 사용할 수 있습니다. 두 개의 노드 또는 세 개 이상의 노드로 구성된 환경은 지원되지 않습니다.
- Compute
- 하이퍼바이저 역할을 하고 환경에서 가상 머신을 실행하는 데 필요한 처리 기능을 제공하는 물리 서버입니다. 기본 Red Hat OpenStack Platform 환경에는 Compute 노드가 적어도 한 개 이상 필요합니다.
- Ceph Storage
- Red Hat Ceph Storage를 제공하는 호스트입니다. 추가 Ceph Storage 호스트는 클러스터에서 확장될 수 있습니다. 이 배포 역할은 선택 사항입니다.
- Swift Storage
- OpenStack의 Swift 서비스에 외부 오브젝트 스토리지를 제공하는 호스트입니다. 이 배포 역할은 선택 사항입니다.
다음 표에서는 다른 오버클라우드 구성 예와 각 시나리오에 사용되는 노드 유형을 정의합니다.
표 5.1. 시나리오에 사용되는 노드 배포 역할
|
Controller |
Compute |
Ceph Storage |
Swift Storage |
합계 | |
|
소규모 오버클라우드 |
3 |
1 |
- |
- |
4 |
|
중간 규모 오버클라우드 |
3 |
3 |
- |
- |
6 |
|
추가 오브젝트 스토리지가 있는 중간 규모의 오버클라우드 |
3 |
3 |
- |
3 |
9 |
|
Ceph Storage 클러스터가 있는 중간 규모의 오버클라우드 |
3 |
3 |
3 |
- |
9 |
또한 개별 서비스를 사용자 지정 역할로 나눌 것인지 검토하십시오. 구성 가능한 역할 아키텍처에 대한 자세한 내용은 Advanced Overcloud Customization 가이드에서 "Composable Services and Custom Roles"를 참조하십시오.
5.2. 오버클라우드 네트워크
역할 및 서비스를 적절하게 매핑하여 서로 올바르게 통신할 수 있도록 해당 환경의 네트워킹 토폴로지와 서브넷을 계획하는 것이 중요합니다. Red Hat OpenStack Platform은 자율적으로 작동하고 소프트웨어 기반 네트워크, 정적 및 유동 IP 주소, DHCP를 관리하는 Openstack Networking(neutron) 서비스를 사용합니다.
기본적으로 director는 연결에 프로비저닝/컨트롤 플레인을 사용하도록 노드를 구성합니다. 그러나 사용자 지정하여 서비스를 할당할 수 있는 일련의 구성 가능한 네트워크로 네트워크 트래픽을 분리할 수 있습니다.
일반적인 Red Hat OpenStack Platform 설치에서는 종종 네트워크 유형의 수가 물리적 네트워크 연결 수를 초과합니다. 모든 네트워크를 적절한 호스트에 연결하기 위해 오버클라우드에서는 VLAN 태그를 사용하여 인터페이스마다 두 개 이상의 네트워크를 제공합니다. 대부분의 네트워크는 서브넷이 분리되어 있지만, 일부는 인터넷 액세스 또는 인프라 네트워크 연결에 라우팅을 제공할 레이어 3 게이트웨이가 필요합니다. VLAN을 사용하여 네트워크 트래픽 유형을 분리하는 경우 802.1Q 표준을 지원하는 스위치를 사용하여 태그가 지정된 VLAN을 제공하십시오.
배포 시 neutron VLAN 모드(터널링이 비활성화된 상태)를 사용하려는 경우에도 프로젝트 네트워크(GRE 또는 VXLAN으로 터널링됨)를 배포하는 것이 좋습니다. 이 경우 배포 시 약간의 사용자 정의 작업이 필요하며, 이후에 유틸리티 네트워크 또는 가상화 네트워크로 터널 네트워크를 사용할 수 있는 옵션은 그대로 유지됩니다. VLAN을 사용하여 테넌트 네트워크를 만들지만, 테넌트 VLAN을 사용하지 않고 네트워크를 특별한 용도로 사용하기 위한 VXLAN 터널을 만들 수도 있습니다. 테넌트 VLAN을 사용한 배포에 VXLAN 기능을 추가할 수 있지만, 서비스 중단 없이 기존 오버클라우드에 테넌트 VLAN을 추가할 수 없습니다.
또한 director는 분리된 구성 가능 네트워크를 사용하여 NIC를 구성하는 데 필요한 템플릿 집합을 제공합니다. 기본 구성은 다음과 같습니다.
- 단일 NIC 구성 - 기본 VLAN과 다른 오버클라우드 네트워크 유형에 서브넷을 사용하는 태그된 VLAN에서 프로비저닝 네트워크용 NIC 1개
- 연결된 NIC 구성 - 기본 VLAN의 프로비저닝 네트워크용 NIC 1개와 다른 오버클라우드 네트워크 유형에 대해 태그가 지정된 VLAN에 연결된 NIC 2개
- 다중 NIC 구성 - 각 NIC에서 다른 오버클라우드 네트워크 유형에 서브넷 사용
고유의 템플릿을 작성하여 특정 NIC구성을 매핑할 수도 있습니다.
네트워크 구성을 검토하는 경우 다음과 같은 세부사항을 고려하는 것도 중요합니다.
- 오버클라우드 생성 중에 모든 오버클라우드 머신에 단일 이름을 사용하여 NIC를 참조합니다. 혼동하지 않도록 각 오버클라우드 노드에서 각각의 해당 네트워크에 대해 동일한 NIC를 사용하는 것이 좋습니다. 예를 들어 프로비저닝 네트워크에는 주 NIC를 사용하고, OpenStack 서비스에는 보조 NIC를 사용하십시오.
- 프로비저닝 NIC로 PXE를 부팅하도록 모든 오버클라우드 시스템을 설정하고, 외부 NIC(및 시스템의 다른 모든 NIC)에서 PXE 부팅을 비활성화하십시오. 또한 프로비저닝 NIC에 PXE 부팅이 하드 디스크 및 CD/DVD 드라이브보다 우선하도록 부팅 순서를 최상위 위치로 지정합니다.
- 모든 오버클라우드 베어 메탈 시스템에는 IPMI(Intelligent Platform Management Interface)와 같은 지원되는 전원 관리 인터페이스가 필요합니다. 이를 통해 director에서 각 노드의 전원 관리를 제어할 수 있습니다.
- 각 오버클라우드 시스템에 대해 프로비저닝 NIC의 MAC 주소, IPMI NIC의 IP 주소, IPMI 사용자 이름 및 IPMI 비밀번호를 기록해 두십시오. 이 정보는 나중에 오버클라우드 노드를 설정할 때 유용합니다.
- 외부 인터넷에서 인스턴스에 액세스할 필요가 있는 경우 공용 네트워크에서 유동 IP 주소를 할당하고 이 주소를 인스턴스와 연결할 수 있습니다. 인스턴스는 해당 개인 IP를 보유하고 있지만, 네트워크 트래픽에서 NAT를 사용하여 유동 IP 주소를 통과합니다. 유동 IP 주소는 여러 개인 IP 주소가 아니라 단일 인스턴스에만 할당할 수 있습니다. 하지만 유동 IP 주소는 단일 테넌트에서만 사용하도록 지정되어 있으므로 테넌트가 필요에 따라 특정 인스턴스와 연결하거나 연결을 해제할 수 있습니다. 이 구성을 사용하면 해당 인프라가 외부 인터넷에 노출되므로 적합한 보안 관행을 준수하고 있는지 확인해야 합니다.
- 하나의 브리지는 단일 인터페이스 또는 단일 본딩만을 멤버로 하면 Open vSwitch에서 네트워크 루프 발생 위험을 완화할 수 있습니다. 여러 개의 본딩이나 인터페이스가 필요한 경우 여러 브리지를 구성할 수 있습니다.
- 오버클라우드 노드가 Red Hat Content Delivery Network 및 네트워크 시간 서버와 같은 외부 서비스에 연결할 수 있도록 DNS 호스트 이름 확인을 사용하는 것이 좋습니다.
5.3. 오버클라우드 스토리지
모든 드라이버 또는 백엔드 유형의 백엔드 cinder-volume을 사용하는 게스트 인스턴스에서 LVM을 사용하면 성능, 볼륨 가시성 및 가용성에 문제가 발생할 수 있습니다. 이러한 문제는 LVM 필터를 사용하여 해결할 수 있습니다. 자세한 내용은 Storage Guide에서 2.1섹션 백엔드 및 KCS 문서 3213311, "Using LVM on a cinder volume exposes the data to the compute host"를 참조하십시오.
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을 부팅할 수 있습니다.
- 파일 시스템 - Manila 공유는 파일 시스템에서 지원합니다. OpenStack 사용자는 Manila 서비스를 사용하여 공유를 관리합니다. Manila를 사용하면 Ceph Storage 노드의 데이터로 CephFS 파일 시스템에서 지원하는 공유를 관리할 수 있습니다.
게스트 디스크 - 게스트 디스크는 게스트 운영 체제 디스크입니다. 기본적으로 nova로 가상 머신을 부팅하면 해당 디스크가 하이퍼바이저의 파일 시스템에 파일로 표시됩니다(일반적으로
/var/lib/nova/instances/<uuid>/아래). cinder를 사용하지 않고 Ceph 내에서 모든 가상 머신을 부팅할 수 있으며, 이 경우 라이브 마이그레이션 프로세스를 통해 쉽게 유지보수 작업을 수행할 수 있습니다. 또한 하이퍼바이저가 중지되는 경우 편리하게nova evacuate를 트리거하고 다른 위치에서 가상 머신을 실행할 수 있습니다.중요지원되는 이미지 형식에 대한 내용은 Instances and Images 가이드의 Image Service 장을 참조하십시오.
자세한 내용은 Red Hat Ceph Storage Architecture 가이드를 참조하십시오.
- Swift Storage 노드
- director에서 외부 오브젝트 스토리지 노드를 생성합니다. 이는 오버클라우드 환경의 컨트롤러 노드를 확장하거나 교체해야 하지만 고가용성 클러스터 외부에서 오브젝트 스토리지를 유지해야 하는 경우에 유용합니다.
5.4. 오버클라우드 보안
OpenStack Platform 구현의 보안은 네트워크 환경의 보안에 따라 좌우됩니다. 네트워킹 환경에서 적합한 보안 원칙에 따라 네트워크 액세스가 적절히 제어되는지 확인하십시오. 예를 들면 다음과 같습니다.
- 네트워크 세그멘테이션을 사용하여 네트워크 트래픽을 줄이고 중요한 데이터를 격리합니다. 플랫 네트워크는 보안 수준이 훨씬 낮습니다.
- 서비스 액세스 및 포트를 최소로 제한합니다.
- 적절한 방화벽 규칙과 암호를 사용합니다.
- SELinux를 활성화합니다.
시스템 보안에 대한 자세한 내용은 다음 문서를 참조하십시오.
5.5. 오버클라우드 고가용성
고가용성 오버클라우드를 배포하기 위해 director는 여러 개의 컨트롤러 노드, 컴퓨팅 노드, 스토리지 노드가 단일 클러스터로 작동하도록 설정합니다. 노드 오류가 발생하는 경우 해당 노드의 유형에 따라 자동 펜싱 및 다시 시작 프로세스가 트리거됩니다. 오버클라우드 고가용성 아키텍처 및 서비스에 대한 내용은 Understanding Red Hat OpenStack Platform High Availability를 참조하십시오.
director(인스턴스 HA)를 사용하여 컴퓨팅 인스턴스의 고가용성을 구성할 수도 있습니다. 이 메커니즘은 노드에 문제가 발생하는 경우 컴퓨팅 노드의 인스턴스를 자동으로 비우기 및 다시 시작합니다. 인스턴스 HA에 대한 요구 사항은 일반 오버클라우드 요구 사항과 동일하지만 몇 가지 추가 단계를 수행하여 배포를 위해 환경을 준비해야 합니다. 인스턴스 HA가 작동하는 방법 및 설치 지침에 대한 자세한 내용은 High Availability for Compute Instances 가이드를 참조하십시오.
5.6. 컨트롤러 노드 요구 사항
컨트롤러 노드는 Red Hat OpenStack Platform 환경에서 Horizon 대시보드, 백엔드 데이터베이스 서버, Keystone 인증, 고가용성 서비스와 같은 핵심 서비스를 호스팅합니다.
- 프로세서
- Intel 64 또는 AMD64 CPU 확장을 지원하는 64비트 x86 프로세서
- 메모리
최소 메모리 용량은 32GB입니다. 하지만 권장 메모리 용량은 vCPU 수(CPU 코어 수와 하이퍼 스레딩 값을 곱한 값)에 따라 다릅니다. 다음 계산을 참고하십시오.
Controller의 최소 RAM 계산:
- vCPU마다 1.5GB 메모리를 사용합니다. 예를 들어 48개의 vCPU가 있는 머신에는 72GB의 RAM이 있어야 합니다.
Controller의 권장 RAM 계산:
- vCPU마다 3GB 메모리를 사용합니다. 예를 들어 48개의 vCPU가 있는 머신에는 144GB RAM이 있어야 합니다.
메모리 요구 사항 측정에 대한 자세한 내용은 Red Hat Customer Portal에서 "고가용성 컨트롤러에 대한 Red Hat OpenStack Platform 하드웨어 요구 사항"을 참조하십시오.
- 디스크 스토리지 및 레이아웃
최소 40GB의 스토리지가 필요합니다. Telemetry(
gnocchi) 및 Object Storage(swift) 서비스는 모두 Controller에 설치되고 root 디스크를 사용하도록 구성됩니다. 이러한 기본값은 상용 하드웨어에 내장되는 소형 오버클라우드 배포에 적합합니다. 이는 개념 검증 및 테스트의 표준 환경입니다. 이러한 기본값을 사용하면 워크로드 용량 및 성능 측면에서는 떨어지지만 최소의 플래닝으로 오버클라우드 배포가 가능합니다.하지만 엔터프라이즈 환경에서는 Telemetry가 스토리지에 지속적으로 액세스하므로 이 경우 심각한 성능 장애가 발생할 수 있습니다. 그러면 디스크 I/O가 과도하게 사용되고 다른 모든 Controller 서비스의 성능에 심각한 영향을 미칩니다. 이러한 유형의 환경에서는 오버클라우드를 계획하고 적절하게 구성해야 합니다.
Red Hat은 Telemetry와 Object Storage에 대한 여러 설정 권장 사항을 제공합니다. 자세한 내용은 Deployment Recommendations for Specific Red Hat OpenStack Platform Services에서 참조하십시오.
- 네트워크 인터페이스 카드
- 최소 2개의 1GB의 네트워크 인터페이스 카드. 연결된 인터페이스에 사용하거나 태그된 VLAN 트래픽을 위임하기 위해서는 추가 네트워크 인터페이스 카드를 사용하십시오.
- 전원 관리
- 각 Controller 노드에는 서버의 마더보드에서 IPMI(Intelligent Platform Management Interface) 기능과 같은 지원되는 전원 관리 인터페이스가 필요합니다.
5.7. Compute 노드 요구 사항
Compute 노드는 가상 머신 인스턴스가 시작된 후 이를 실행하는 역할을 합니다. Compute 노드는 하드웨어 가상화를 지원해야 합니다. 또한 호스팅하는 가상 머신 인스턴스의 요구 사항을 지원하기에 충분한 메모리 및 디스크 공간이 있어야 합니다.
- 프로세서
- Intel 64 또는 AMD64 CPU 확장 기능을 지원하고, AMD-V 또는 Intel VT 하드웨어 가상화 확장 기능이 활성화된 64비트 x86 프로세서. 이 프로세서에 최소 4개의 코어가 탑재되어 있는 것이 좋습니다.
- IBM POWER 8 프로세서
- 메모리
- 최소 6GB RAM으로 가상 머신 인스턴스에서 사용하려는 메모리 크기에 따라 기본 메모리 요구 사항에 RAM을 추가합니다.
- 디스크 공간
- 최소 40GB의 사용 가능한 디스크 공간
- 네트워크 인터페이스 카드
- 최소 1GB의 네트워크 인터페이스 카드 한 개. 프로덕션 환경에서는 적어도 두 개 이상의 NIC를 사용하는 것이 좋습니다. 연결된 인터페이스에 사용하거나 태그된 VLAN 트래픽을 위임하기 위해서는 추가 네트워크 인터페이스를 사용하십시오.
- 전원 관리
- 각 Compute 노드에는 서버 마더보드의 IPMI(Intelligent Platform Management Interface) 기능과 같이 지원되는 전원 관리 인터페이스가 필요합니다.
5.8. Ceph Storage 노드 요구 사항
Ceph Storage 노드는 Red Hat OpenStack Platform 환경에 스토리지 오브젝트를 제공합니다.
- 프로세서
- Intel 64 또는 AMD64 CPU 확장을 지원하는 64비트 x86 프로세서
- 메모리
- Red Hat에서는 일반적으로 OSD 호스트당 16GB의 RAM과 OSD 데몬당 추가 2GB의 RAM으로 기준선을 정하는 것을 권장합니다.
- 디스크 레이아웃
크기 조정은 필요한 스토리지에 따라 다릅니다. Red Hat Ceph Storage 노드의 권장 설정에는 다음과 같은 레이아웃의 디스크가 3개 이상 필요합니다.
-
/dev/sda- root 디스크입니다. director가 주요 오버클라우드 이미지를 디스크에 복사합니다. 사용 가능한 디스크 공간이 40GB 이상이어야 합니다. -
/dev/sdb- 저널 디스크. 이 디스크는 Ceph OSD 저널용 파티션으로 나뉩니다(예:/dev/sdb1,/dev/sdb2,/dev/sdb3등). 저널 디스크는 일반적으로 시스템 성능을 지원하기 위한 SSD(솔리드 스테이트 드라이브)입니다. /dev/sdc이후 - OSD 디스크. 스토리지 요구 사항에 따라 필요한 만큼 디스크를 사용하십시오.참고Red Hat OpenStack Platform director는
ceph-ansible을 사용하지만 Ceph Storage 노드의 root 디스크에 OSD 설치를 지원하지 않습니다. 즉, 지원되는 Ceph Storage 노드에 대해 적어도 두 개 이상의 디스크가 필요합니다.
-
- 네트워크 인터페이스 카드
- 최소 1개의 1Gbps 네트워크 인터페이스 카드. 프로덕션 환경에서는 적어도 두 개 이상의 NIC를 사용하는 것이 좋습니다. 연결된 인터페이스에 사용하거나 태그된 VLAN 트래픽을 위임하기 위해서는 추가 네트워크 인터페이스 카드를 사용하십시오. 대량의 트래픽에 서비스를 제공하는 OpenStack Platform 환경을 구축하는 경우 스토리지 노드에 10Gbps 인터페이스를 사용하는 것이 좋습니다.
- 전원 관리
- 각 Controller 노드에는 서버의 마더보드에서 IPMI(Intelligent Platform Management Interface) 기능과 같은 지원되는 전원 관리 인터페이스가 필요합니다.
Ceph Storage 클러스터를 통한 오버클라우드 설치에 대한 자세한 내용은 Deploying an Overcloud with Containerized Red Hat Ceph 가이드를 참조하십시오.
5.9. Object Storage 노드 요구 사항
Object Storage 노드는 오버클라우드에 오브젝트 스토리지 계층을 제공합니다. Object Storage 프록시는 Controller 노드에 설치됩니다. 스토리지 계층에는 노드마다 여러 개의 디스크가 있는 베어 메탈 노드가 필요합니다.
- 프로세서
- Intel 64 또는 AMD64 CPU 확장을 지원하는 64비트 x86 프로세서
- 메모리
- 메모리 요구 사항은 스토리지 공간의 크기에 따라 다릅니다. 가장 좋은 방법은 1TB의 하드 디스크 공간마다 최소 1GB의 메모리를 사용하는 것입니다. 최적의 성능을 위해 특히 워크로드가 작은 파일(100GB 미만)의 경우에는 1TB의 하드 디스크 공간마다 2GB를 사용하는 것이 좋습니다.
- 디스크 공간
스토리지 요구 사항은 워크로드에 필요한 용량에 따라 다릅니다. 계정 및 컨테이너 데이터를 저장하기 위해서는 SSD 드라이브를 사용하는 것이 좋습니다. 오브젝트에 대한 계정과 컨테이너 데이터의 용량 비율은 약 1%입니다. 예를 들어 100TB의 모든 하드 드라이브 용량마다 계정과 컨테이너 데이터에 1TB의 SSD 용량을 준비하도록 합니다.
하지만 이는 저장된 데이터 유형에 따라 다릅니다. 주로 작은 오브젝트를 저장하는 경우 더 많은 SSD 공간을 사용하고, 큰 오브젝트(비디오, 백업)의 경우에는 더 적은 SSD 공간을 사용하십시오.
- 디스크 레이아웃
권장 노드 구성에는 다음과 비슷한 디스크 레이아웃이 필요합니다.
-
/dev/sda- root 디스크. director가 주요 오버클라우드 이미지를 디스크에 복사합니다. -
/dev/sdb- 계정 데이터에 사용됩니다. -
/dev/sdc- 컨테이너 데이터에 사용됩니다. -
/dev/sdd이후 - 오브젝트 서버 디스크. 스토리지 요구 사항에 따라 필요한 디스크 수를 사용하십시오.
-
- 네트워크 인터페이스 카드
- 최소 2개의 1GB의 네트워크 인터페이스 카드. 연결된 인터페이스에 사용하거나 태그된 VLAN 트래픽을 위임하기 위해서는 추가 네트워크 인터페이스 카드를 사용하십시오.
- 전원 관리
- 각 Controller 노드에는 서버의 마더보드에서 IPMI(Intelligent Platform Management Interface) 기능과 같은 지원되는 전원 관리 인터페이스가 필요합니다.
5.10. 오버클라우드 리포지토리
언더클라우드를 설치 및 구성하려면 다음과 같은 리포지토리가 필요합니다.
표 5.2. 코어 리포지토리
| 이름 | 리포지토리 | 요구 사항 설명 |
|---|---|---|
|
Red Hat Enterprise Linux 7 Server(RPMs) |
|
x86_64 시스템용 기본 운영 체제 리포지토리 |
|
Red Hat Enterprise Linux 7 Server - Extras(RPMs) |
|
Red Hat OpenStack Platform 종속성을 포함 |
|
Red Hat Enterprise Linux 7 Server - RH Common(RPMs) |
|
Red Hat OpenStack Platform 배포 및 구성을 위한 툴을 포함 |
|
Red Hat Satellite Tools for RHEL 7 Server RPMs x86_64 |
|
Red Hat Satellite 6 호스트를 관리하는 툴입니다. |
|
Red Hat Enterprise Linux High Availability(for RHEL 7 Server)(RPMs) |
|
Red Hat Enterprise Linux용 고가용성 툴입니다. Controller 노드 고가용성에 사용됩니다. |
|
Red Hat OpenStack Platform 14 for RHEL 7(RPM) |
|
핵심 Red Hat OpenStack Platform 리포지토리입니다. |
표 5.3. Ceph 리포지토리
| 이름 | 리포지토리 | 요구 사항 설명 |
|---|---|---|
|
Red Hat Ceph Storage OSD 3 for Red Hat Enterprise Linux 7 Server (RPMs) |
|
(Ceph Storage 노드용) Ceph Storage Object Storage 데몬용 리포지토리입니다. Ceph Storage 노드에 설치됩니다. |
|
Red Hat Ceph Storage MON 3 for Red Hat Enterprise Linux 7 Server(RPMs) |
|
(Ceph Storage 노드용) Ceph Storage 모니터 데몬용 리포지토리입니다. Ceph Storage 노드를 사용하는 OpenStack 환경의 Controller 노드에 설치됩니다. |
|
Red Hat Ceph Storage Tools 3 for Red Hat Enterprise Linux 7 Server(RPMs) |
|
노드가 Ceph Storage 클러스터와 통신할 수 있는 툴을 제공합니다. 오버클라우드를 Ceph Storage 클러스터와 함께 배포하는 경우 모든 노드에 대해 이 리포지토리를 활성화해야 합니다. |
표 5.4. NFV 리포지토리
| 이름 | 리포지토리 | 요구 사항 설명 |
|---|---|---|
|
Enterprise Linux for Real Time for NFV (RHEL 7 Server)(RPMs) |
|
NFV용 실시간 KVM(RT-KVM) 리포지토리로, 실시간 커널을 활성화하는 패키지가 포함되어 있습니다. 이 리포지토리는 RT-KVM을 대상으로 하는 모든 컴퓨팅 노드에 대해 활성화해야 합니다. 참고: 이 리포지토리에 액세스하려면 |
IBM POWER 리포지토리
이러한 리포지토리는 POWER PC 아키텍처의 Openstack Platform에 사용됩니다. 코어 리포지토리의 리포지토리 대신 이 리포지토리를 사용하십시오.
| 이름 | 리포지토리 | 요구 사항 설명 |
|---|---|---|
|
Red Hat Enterprise Linux for IBM Power, little endian |
|
ppc64le 시스템용 기본 운영 체제 리포지토리 |
|
Red Hat OpenStack Platform 14 for RHEL 7(RPM) |
|
ppc64le 시스템용 Red Hat OpenStack Platform 코어 리포지토리 |
