Red Hat Summit3.2. 컴퓨팅 리소스
컴퓨팅 리소스는 OpenStack 클라우드의 핵심입니다. 따라서 Red Hat OpenStack Platform 배포를 설계할 때 물리적 및 가상 리소스 할당, 배포, 페일오버 및 추가 장치를 고려하는 것이 좋습니다.
3.2.1. 일반 고려 사항
- 각 하이퍼바이저의 프로세서, 메모리 및 스토리지 수
프로세서 코어 및 스레드의 수는 컴퓨팅 노드에서 실행할 수 있는 작업자 스레드 수에 직접적인 영향을 미칩니다. 따라서 서비스를 기반으로 설계를 결정하고 모든 서비스에 대해 균형 있는 인프라를 기반으로 해야 합니다.
워크로드 프로필에 따라 나중에 클라우드에 추가 컴퓨팅 리소스 풀을 추가할 수 있습니다. 경우에 따라 특정 인스턴스 플레이버의 요구가 개별 하드웨어 설계를 무효화하지 않을 수 있으며, 대신 상품화된 시스템을 선호하는 경우가 있습니다.
두 경우 모두 공통 인스턴스 요청을 서비스할 수 있는 하드웨어 리소스를 할당하여 설계를 시작합니다. 전체 아키텍처에 하드웨어 설계를 추가하려는 경우 나중에 이 작업을 수행할 수 있습니다.
- 프로세서 유형
프로세서 선택은 특히 다른 프로세서의 기능과 성능 특성을 비교할 때 하드웨어 설계에서 매우 중요한 고려 사항입니다.
프로세서는 하드웨어 지원 가상화 및 메모리 페이징 또는 EPT 섀도우팅 기술과 같은 가상화된 컴퓨팅 호스트를 위한 특정 기능을 포함할 수 있습니다. 이러한 기능은 클라우드 VM의 성능에 큰 영향을 미칠 수 있습니다.
- 리소스 노드
- 클라우드의 하이퍼바이저가 아닌 리소스 노드의 Compute 요구 사항을 고려해야 합니다. 리소스 노드에는 Object Storage, Block Storage 및 Networking 서비스를 실행하는 컨트롤러 노드와 노드가 포함됩니다.
- 리소스 풀
필요에 따라 여러 리소스 풀을 할당하는 Compute 설계를 사용합니다. 이 설계는 클라우드에서 애플리케이션 리소스 사용량을 극대화합니다. 각 리소스 풀은 특정 인스턴스 플레이버 또는 플레이버 그룹을 서비스해야 합니다.
여러 리소스 풀을 설계하면 인스턴스가 컴퓨팅 하이퍼바이저에 예약될 때마다 사용 가능한 하드웨어 사용을 극대화하기 위해 각 노드 리소스 세트가 할당됩니다. 이를 일반적으로 binpack이라고 합니다.
리소스 풀의 노드 간에 일관된 하드웨어 설계를 사용하면 bin 패키징을 지원하는 데 도움이 됩니다. 컴퓨팅 리소스 풀에 대해 선택한 하드웨어 노드는 공통 프로세서, 메모리 및 스토리지 레이아웃을 공유해야 합니다. 일반적인 하드웨어 설계를 선택하면 배포, 지원 및 노드 라이프사이클 유지 관리가 쉬워집니다.
- 오버 커밋 비율
OpenStack을 사용하면 사용자가 컴퓨팅 노드에서 CPU 및 RAM을 오버 커밋할 수 있으므로 클라우드에서 실행되는 인스턴스 수를 늘리는 데 도움이 됩니다. 그러나 초과 커밋을 통해 인스턴스의 성능을 줄일 수 있습니다.
오버 커밋 비율은 사용 가능한 물리적 리소스와 비교하여 사용 가능한 가상 리소스의 비율입니다.
- 기본 CPU 할당 비율은 16:1이면 스케줄러는 모든 물리적 코어에 대해 최대 16개의 가상 코어를 할당합니다. 예를 들어 물리적 노드에 12개의 코어가 있는 경우 스케줄러는 최대 192개의 가상 코어를 할당할 수 있습니다. 인스턴스당 일반적인 플레이버 정의 4개의 가상 코어를 사용하면 이 비율은 물리적 노드에 48개의 인스턴스를 제공할 수 있습니다.
- 1.5:1의 기본 RAM 할당 비율은 인스턴스와 연결된 전체 RAM 양이 물리적 노드에서 사용 가능한 RAM보다 1.5배 미만인 경우 스케줄러에서 물리적 노드에 인스턴스를 할당하는 것을 의미합니다.
설계 단계에서 CPU 및 메모리에 대한 오버 커밋 비율을 조정하는 것은 컴퓨팅 노드의 하드웨어 레이아웃에 직접적인 영향을 미치기 때문에 중요합니다. 하드웨어 노드를 서비스 인스턴스에 대한 컴퓨팅 리소스 풀로 설계할 때 노드에서 사용 가능한 프로세서 코어 수와 전체 용량에서 실행되는 서비스 인스턴스에 필요한 디스크 및 메모리를 고려하십시오.
예를 들어, m1.overcloud 인스턴스는 1개의 vCPU, 20GB의 임시 스토리지, 2,048MB의 RAM을 사용합니다. 코어가 10개이고 CPU가 각각 2개인 서버의 경우 하이퍼 스레딩이 켜집니다.
- 기본 CPU 과다 할당 비율은 16:1인 경우 640(2 × 10 × 2 × 16) 총 m1.windows 인스턴스를 허용합니다.
- 1.5:1의 기본 메모리 오버 커밋 비율은 서버에 최소 853GB(640 × 2,048MB / 1.5)가 필요함을 의미합니다.
메모리의 노드 크기를 조정할 때 서비스 운영 체제 및 서비스 요구 사항에 필요한 추가 메모리도 고려해야 합니다.
3.2.2. 플레이버
생성된 각 인스턴스에는 인스턴스 크기와 용량을 결정하는 플레이버 또는 리소스 템플릿이 제공됩니다. 플레이버는 보조 임시 스토리지, 스왑 디스크, 사용을 제한하는 메타데이터 또는 특수 프로젝트 액세스를 지정할 수도 있습니다. 기본 플레이버에는 이러한 추가 속성이 정의되어 있지 않습니다. 인스턴스 플레이버를 사용하면 일반적인 사용 사례가 예측할 수 있고 크기가 조정되지 않기 때문에 용량 예측을 측정할 수 있습니다.
가상 머신을 물리적 호스트에 쉽게 패키징할 수 있도록 기본 플레이버 선택에서는 모든 측면에서 가장 큰 플레이버의 절반 크기를 두 번째로 큰 플레이버로 제공합니다. 플레이버에는 vCPU의 절반, half the Cryostat 및 임시 디스크 공간의 절반이 있습니다. 이후의 각 가장 큰 플레이버는 이전 플레이버의 절반 크기입니다.
다음 다이어그램은 일반적인 용도의 컴퓨팅 디자인과 CPU 최적화 팩된 서버의 플레이버 할당을 시각적으로 보여줍니다.
상용 서버 하드웨어의 일반적인 구성에 기본 플레이버를 사용하는 것이 좋습니다. 활용도를 극대화하려면 플레이버를 사용자 지정하거나 새 플레이버를 생성하여 사용 가능한 하드웨어에 인스턴스 크기를 조정해야 할 수 있습니다.
가능한 경우 플레이버를 각 플레이버에 대해 하나의 vCPU로 제한합니다. 유형 1 하이퍼바이저는 하나의 vCPU로 구성된 VM에 CPU 시간을 더 쉽게 예약할 수 있다는 점에 유의해야 합니다. 예를 들어 4개의 vCPU로 구성된 VM에 CPU 시간을 예약하는 하이퍼바이저는 vCPU 1개만 필요한 경우에도 4개의 물리적 코어를 사용할 수 있을 때까지 기다려야 합니다.
워크로드 특성은 특히 작업에서 CPU, RAM 또는 HDD 요구 사항의 다른 비율을 표시하는 경우 하드웨어 선택 및 플레이버 구성에 영향을 미칠 수 있습니다. 플레이버에 대한 자세한 내용은 인스턴스 및 이미지 관리를 참조하십시오.
3.2.3. vCPU-to-physical CPU 코어 비율
Red Hat OpenStack Platform의 기본 할당 비율은 물리적 또는 하이퍼스레딩 코어당 16 vCPU입니다.
다음 표에는 시스템에 예약된 4GB를 포함하여 사용 가능한 총 메모리를 기반으로 물리적 호스트에서 적절하게 실행할 수 있는 최대 VM 수가 나열되어 있습니다.
| 총 RAM | VMs | 총 vCPU |
|---|---|---|
| 64GB | 14 | 56 |
| 96GB | 20 | 80 |
| 128GB | 29 | 116 |
예를 들어, 초기 그린필드를 60개 인스턴스로 계획하려면 3+1 컴퓨팅 노드가 필요합니다. 일반적으로 메모리 병목 현상이 CPU 병목 현상보다 더 일반적입니다. 그러나 필요한 경우 할당 비율을 물리적 코어당 8개의 vCPU로 줄일 수 있습니다.
3.2.4. 메모리 오버헤드
KVM 하이퍼바이저에는 공유할 수 없는 메모리를 포함하여 적은 양의 VM 메모리 오버헤드가 필요합니다. QEMU/KVM 시스템의 공유 가능한 메모리는 각 하이퍼바이저에 대해 200MB로 반올림할 수 있습니다.
| vRAM | 물리적 메모리 사용량(상세) |
|---|---|
| 256 | 310 |
| 512 | 610 |
| 1024 | 1080 |
| 2048 | 2120 |
| 4096 | 4180 |
일반적으로 VM당 100mb의 하이퍼바이저 오버헤드를 추정할 수 있습니다.
3.2.5. 초과 서브스크립션
메모리는 하이퍼바이저 배포의 제한 요소입니다. 각 물리적 호스트에서 실행할 수 있는 VM 수는 호스트에서 액세스할 수 있는 메모리 양에 따라 제한됩니다. 예를 들어 256GB의 RAM과 200 1GB 이상의 인스턴스를 사용하여 쿼드 코어 CPU를 배포하면 성능이 저하됩니다. 따라서 인스턴스에 배포할 CPU 코어 및 메모리의 최적 비율을 신중하게 결정해야 합니다.
3.2.6. 밀도
- 인스턴스 밀도
- 컴퓨팅 중심 아키텍처에서는 인스턴스 밀도가 낮기 때문에 CPU 및 RAM 초과 서브스크립션 비율도 낮습니다. 특히 설계에서 듀얼 소켓 하드웨어 설계를 사용하는 경우 인스턴스 밀도가 낮은 경우 예상되는 규모를 지원하기 위해 더 많은 호스트가 필요할 수 있습니다.
- 호스트 밀도
- 쿼드 소켓 플랫폼을 사용하여 듀얼 소켓 설계의 상위 호스트 수를 처리할 수 있습니다. 이 플랫폼은 호스트 밀도를 줄임으로써 랙 수를 늘립니다. 이 구성은 네트워크 요구 사항, 전원 연결 수에 영향을 미칠 수 있으며 충당 요구 사항에도 영향을 미칠 수 있습니다.
- 전원 및 혼합 밀도
- 전력 및 연쇄 밀도를 줄이는 것은 오래된 인프라를 사용하는 데이터 센터의 중요한 고려 사항입니다. 예를 들어, 2U, 3U 또는 4U 서버 설계에 대한 전력 및 단정밀도 요구 사항은 호스트 밀도가 낮기 때문에 블레이드, 슬라이 또는 1U 서버 설계보다 낮을 수 있습니다.
3.2.7. 컴퓨팅 하드웨어
- Blade 서버
- 대부분의 블레이드 서버는 듀얼 소켓, 멀티 코어 CPU를 지원할 수 있습니다. CPU 제한을 초과하지 않으려면 전체 대역폭 또는 전체 하이라이트 를 선택합니다. 이러한 블레이드 유형은 또한 서버 밀도를 줄일 수 있습니다. 예를 들어 HP BladeSystem 또는 Dell PowerEdge M1000e와 같은 고밀도 블레이드 서버는 10개의 랙 단위로만 16개의 서버를 지원합니다. half-height 블레이드는 전체 하이프 블레이드보다 두 배 더 밀도가 낮기 때문에 10 개의 랙 단위당 8 개의 서버 만 생성됩니다.
- 1U 서버
1U 랙 장치만 사용하는 랙 마운트된 서버는 블레이드 서버 솔루션보다 더 높은 서버 밀도를 제공할 수 있습니다. 하나의 랙에 있는 1U 서버의 40 단위를 사용하여 랙(ToR) 스위치의 상단 공간을 제공할 수 있습니다. 한 랙에서 32개의 전체 대역폭 블레이드 서버만 사용할 수 있습니다.
그러나 주요 벤더의 1U 서버에는 듀얼 소켓, 멀티 코어 CPU 구성만 있습니다. 1U 랙 마운트 폼패드에서 더 높은 CPU 구성을 지원하려면 원래 설계 제조업체( Cryostat) 또는 두 번째 계층 제조업체에서 시스템을 구입하십시오.
- 2U 서버
- 2U 랙 마운트된 서버는 쿼드 소켓, 멀티 코어 CPU 지원을 제공하지만 이에 해당하는 서버 밀도가 감소합니다. 2U 랙 마운트된 서버는 1U 랙 마운트 서버가 제공하는 밀도의 절반을 제공합니다.
- 대규모 서버
- 4U 서버와 같은 더 큰 랙으로 마운트된 서버는 더 많은 CPU 용량을 제공하고 일반적으로 4개 또는 8개의 CPU 소켓을 지원합니다. 이러한 서버는 확장성이 뛰어나지만 서버 밀도가 훨씬 낮기 때문에 더 많은 비용이 듭니다.
- 슬라이딩 서버
슬라이딩 서버는 단일 2U 또는 3U 인클로저에서 여러 독립 서버를 지원하는 랙으로 마운트된 서버입니다. 이러한 서버는 일반적인 1U 또는 2U 랙이 마운트된 서버보다 높은 밀도를 제공합니다.
예를 들어, 많은 슬라이딩 서버는 총 8개의 CPU 소켓에 대해 2U에 4개의 독립적인 듀얼 소켓 노드를 제공합니다. 그러나 개별 노드의 듀얼 소켓 제한으로 인해 추가 비용 및 구성 복잡성을 상쇄하기에 충분하지 않을 수 있습니다.
3.2.8. 추가 장치
컴퓨팅 노드에 대해 다음과 같은 추가 장치를 고려할 수 있습니다.
- 고성능 컴퓨팅 작업을 위한 그래픽 처리 단위(GPU).
-
암호화 루틴에 대한 엔트로피 부족을 방지하기 위해 하드웨어 기반 임의 번호 생성기입니다. 인스턴스 이미지 속성과 함께 를 사용하여 임의 번호 생성기 장치를 인스턴스에 추가할 수 있습니다.
/dev/random은 기본 엔트로피 소스입니다. - 데이터베이스 관리 시스템의 읽기/쓰기 시간을 최대화하기 위한 임시 스토리지용 SSD입니다.
- 호스트 집계는 하드웨어와 같은 유사한 특성을 공유하는 호스트를 그룹화하여 작동합니다. 특수 하드웨어를 클라우드 배포에 추가하면 각 노드의 비용에 추가할 수 있으므로 모든 컴퓨팅 노드에 추가 사용자 지정이 필요한지 아니면 하위 집합에만 필요한지 여부를 고려하십시오.
