Red Hat Summit4.3. Compute-Focused Architecture
이 릴리스에서 셀은 기술 프리뷰로 사용할 수 있으므로 Red Hat에서 완전히 지원하지 않습니다. 테스트용으로만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.
컴퓨팅 중심 클라우드는 데이터 계산 또는 암호화 및 암호 해독, 메모리 내 캐싱 또는 데이터베이스 서버와 같은 RAM 집약적 워크로드 또는 둘 다와 같은 CPU 집약적인 워크로드를 지원합니다. 이 아키텍처 유형은 일반적으로 스토리지 집약적이거나 네트워크 집약적이지 않으며 컴퓨팅 리소스의 성능이 필요한 고객에게 서비스를 제공합니다.
컴퓨팅 중심 워크로드에는 다음과 같은 사용 사례가 포함됩니다.
- 고성능 컴퓨팅(HPC)
- HDFS 또는 기타 분산 데이터 저장소를 사용한 빅 데이터 분석
- 연속 통합 또는 연속 배포(CI/CD)
- Platform-as-a-Service(Platform-as-a-Service)
- NFV(네트워크 기능 가상화)에 대한 신호 처리
컴퓨팅 중심 OpenStack 클라우드는 일반적으로 클라우드가 영구 블록 스토리지가 필요한 애플리케이션을 호스팅하지 않기 때문에 원시 블록 스토리지 서비스를 사용하지 않습니다. 워크로드가 필요에 따라 사용 가능한 리소스를 많이 사용할 수 있도록 인프라 구성 요소가 공유되지 않습니다. 인프라 구성 요소도 고가용성이어야 합니다. 이 설계에서는 로드 밸런서를 사용합니다. HAProxy를 사용할 수도 있습니다.
설치 및 배포 문서는 5장. 배포 정보 에서 참조하십시오.
4.3.1. 사용 사례 예
조직은 연구 프로젝트에 HPC를 제공하며 유럽의 두 개의 기존 컴퓨팅 센터에 세 번째 컴퓨팅 센터를 추가해야 합니다.
다음 표에는 추가할 각 컴퓨팅 센터의 요구 사항이 나열되어 있습니다.
| 데이터 센터 | 대략적인 용량 |
|---|---|
| Geneva, Switzerland |
|
| Budapest, 헝가리 |
|
4.3.2. 설계 정보
이 아키텍처는 셀을 사용하여 컴퓨팅 리소스를 분리하고 서로 다른 데이터 센터 간의 투명한 확장을 위해 사용합니다. 이 결정은 보안 그룹 및 실시간 마이그레이션 지원에 영향을 미칩니다. 또한 셀 간에 플레이버와 같은 일부 구성 요소를 수동으로 복제해야 합니다. 그러나 셀은 단일 공용 API 끝점을 사용자에게 노출하는 동안 필요한 스케일링을 제공합니다.
클라우드는 두 개의 원래 데이터 센터 각각에 대해 컴퓨팅 셀을 사용하고 새 데이터 센터를 추가할 때마다 새 컴퓨팅 셀을 생성합니다. 각 셀에는 컴퓨팅 리소스를 추가로 분리하기 위한 3개의 가용성 영역과 고가용성을 위해 미러링된 큐로 클러스터링을 위해 구성된 3개 이상의 RabbitMQ 메시지 브로커가 포함되어 있습니다.
HAProxy 로드 밸런서 뒤에 있는 API 셀은 스위스의 데이터 센터에 있습니다. API 셀은 셀 스케줄러의 사용자 지정 변형을 사용하여 API 호출을 컴퓨팅 셀로 보냅니다. 사용자 지정을 사용하면 특정 워크로드가 특정 데이터 센터 또는 셀 RAM 가용성에 따라 모든 데이터 센터로 라우팅할 수 있습니다.
필터를 사용하여 셀의 배치를 처리하는 Compute 스케줄러를 사용자 지정할 수도 있습니다. 예를 들어 ImagePropertiesFilter 는 게스트가 실행하는 운영 체제(예: Linux 또는 Windows)를 기반으로 특수한 처리를 제공합니다.
중앙 데이터베이스 팀은 NetApp 스토리지 백엔드를 사용하여 활성/수동 구성으로 각 셀에서 SQL 데이터베이스 서버를 관리합니다. 백업은 6시간마다 실행됩니다.
4.3.3. 아키텍처 구성 요소
| Component | 설명 |
|---|---|
| Compute | 컨트롤러에서 실행되는 컴퓨팅 관리 및 스케줄링 서비스. Compute 서비스는 각 컴퓨팅 노드에서도 실행됩니다. |
| 대시보드 서비스 | OpenStack 관리를 위한 GUI. |
| ID 서비스 | 기본 인증 및 권한 부여 기능 |
| 이미지 서비스 | API 셀에서 실행되며 오케스트레이션 툴에서 애플리케이션을 배치할 수 있는 작은 Linux 이미지 세트를 유지 관리합니다. |
| 네트워킹 | 네트워킹 서비스. OpenStack 네트워킹에 대한 자세한 내용은 2장. 네트워킹 In-Depth 을 참조하십시오. |
| 모니터링 | 원격 분석 서비스는 미터링을 수행하여 분할되고 복제된 MongoDB 백엔드로 프로젝트 할당량을 조정합니다. API 로드를 분산하려면 Telemetry에서 쿼리할 수 있는 하위 셀에 openstack-nova-api 서비스의 인스턴스를 배포해야 합니다. 이 배포에는 하위 셀에서 ID 및 Image와 같은 지원 서비스 구성도 필요합니다. 캡처하기 위한 특정 중요한 메트릭에는 이미지 디스크 사용률 및 Compute API에 대한 응답 시간이 포함됩니다. |
| 오케스트레이션 서비스 | 새 인스턴스를 자동으로 배포 및 테스트합니다. |
| Telemetry 서비스 | 오케스트레이션 자동 확장 기능을 지원합니다. |
| 오브젝트 스토리지 | 3 PB Ceph 클러스터로 오브젝트를 저장합니다. |
4.3.4. 설계 고려 사항
3장. 설계 에 설명된 기본 설계 고려 사항 및 3.2절. “컴퓨팅 리소스” 에 설명된 컴퓨팅 노드 설계 고려 사항 외에 컴퓨팅 집약적 아키텍처에서는 다음 항목을 고려해야 합니다.
- 워크로드
수명이 짧은 워크로드에는 일련의 컴퓨팅 집약적 작업을 수행하기 위해 다수의 컴퓨팅 인스턴스를 동시에 생성하는 CI-CD(연속 통합 및 연속 배포) 작업이 포함될 수 있습니다. 그러면 환경이 인스턴스를 종료하기 전에 각 인스턴스의 결과 또는 아티팩트를 장기 스토리지로 복사합니다.
Cryostat 클러스터 또는 HPC 클러스터와 같은 장기 워크로드는 일반적으로 대규모 데이터 세트를 수신하고 해당 데이터 세트에서 컴퓨팅 작업을 수행한 다음 결과를 장기 스토리지로 푸시합니다. 계산 작업이 종료되면 다른 작업을 수신할 때까지 인스턴스가 유휴 상태가 됩니다. 장기 워크로드의 환경은 더 크고 복잡한 경우가 많지만 작업 간에 활성 상태를 유지하여 이러한 환경 구축 비용을 상쇄할 수 있습니다.
컴퓨팅 중심 OpenStack 클라우드의 워크로드는 HDFS에서 일부 HDFS 사용을 제외하고 일반적으로 영구 블록 스토리지가 필요하지 않습니다. 공유 파일 시스템 또는 개체 저장소는 초기 데이터 세트를 유지 관리하고 계산 결과를 저장하는 대상 역할을 합니다. IIO(입력 출력) 오버헤드를 방지하면 워크로드 성능을 크게 향상시킬 수 있습니다. 데이터 세트의 크기에 따라 오브젝트 저장소 또는 공유 파일 시스템을 확장해야 할 수 있습니다.
- 확장 계획
클라우드 사용자는 필요에 따라 새 리소스에 즉시 액세스할 수 있습니다. 따라서 일반적인 사용법과 리소스 수요의 갑작스러운 급증을 계획해야합니다. 너무 보수적으로 계획하면 예기치 않은 초과 구독이 발생할 수 있습니다. 너무 공격적으로 계획하면 예기치 않은 클라우드 사용 불필요한 운영 및 유지 관리 비용이 발생할 수 있습니다.
확장 계획의 핵심 요소는 시간이 지남에 따라 클라우드 사용량의 추세를 분석하는 것입니다. 클라우드의 평균 속도 또는 용량 대신 서비스를 제공하는 일관성을 측정합니다. 이 정보는 용량 성능을 모델링하고 클라우드의 현재 및 향후 용량을 결정하는 데 도움이 될 수 있습니다.
모니터링 소프트웨어에 대한 자세한 내용은 3.9절. “추가 소프트웨어” 을 참조하십시오.
- CPU 및 RAM
현재 일반적인 서버 제품에는 최대 12개의 코어가 있는 CPU가 포함되어 있습니다. 또한 일부 Intel CPU는 코어 용량을 두 배로 늘리는 HTT(Hyper-Threading Technology)를 지원합니다. 따라서 HTT가 있는 여러 CPU를 지원하는 서버는 사용 가능한 코어 수를 곱합니다. HTT는 Intel CPU의 병렬 처리를 개선하는 데 사용되는 Intel 독점 멀티 스레딩 구현입니다. 다중 스레드 애플리케이션의 성능을 개선하려면 HTT를 활성화하는 것이 좋습니다.
CPU에서 HTT를 활성화하기로 결정하는 것은 사용 사례에 따라 다릅니다. 예를 들어 HTT를 비활성화하면 강력한 컴퓨팅 환경에 도움이 될 수 있습니다. HTT를 사용하거나 사용하지 않고 로컬 워크로드의 성능 테스트를 실행하면 특정 사례에 더 적합한 옵션을 결정하는 데 도움이 될 수 있습니다.
- 용량 계획
다음 전략 중 하나 이상을 사용하여 컴퓨팅 환경에 용량을 추가할 수 있습니다.
클라우드에 용량을 추가하여 수평으로 확장합니다. 라이브 마이그레이션 기능을 중단할 가능성을 줄이기 위해 추가 노드에서 동일한 CPU 또는 유사한 CPU를 사용해야 합니다. 하이퍼바이저 호스트를 확장하면 네트워크 및 기타 데이터 센터 리소스에도 영향을 미칩니다. 랙 용량에 도달하거나 추가 네트워크 스위치가 필요한 경우 이러한 증가를 고려하십시오.
참고노드를 적절한 가용성 영역 및 호스트 집계에 배치하는 데 필요한 추가 작업을 유의하십시오.
- 사용량을 지원하기 위해 내부 컴퓨팅 호스트 구성 요소의 용량을 늘려 수직으로 확장합니다. 예를 들어 CPU를 CPU로 더 많은 코어로 교체하거나 서버의 RAM을 늘릴 수 있습니다.
평균 워크로드를 평가하고 필요한 경우 초과 커밋 비율을 조정하여 컴퓨팅 환경에서 실행할 수 있는 인스턴스 수를 늘립니다.
중요컴퓨팅 중심 OpenStack 설계 아키텍처에서는 CPU 오버 커밋 비율을 늘리지 마십시오. CPU 초과 커밋 비율을 변경하면 CPU 리소스가 필요한 다른 노드와 충돌할 수 있습니다.
- 컴퓨팅 하드웨어
컴퓨팅 중심 OpenStack 클라우드는 프로세서 및 메모리 리소스에 대해 매우 까다로운 작업을 수행합니다. 따라서 더 많은 CPU 소켓, 더 많은 CPU 코어 및 RAM을 제공할 수 있는 서버 하드웨어에 우선순위를 지정해야 합니다.
네트워크 연결 및 스토리지 용량은 이 아키텍처에서 덜 중요합니다. 하드웨어는 최소 사용자 요구 사항을 충족하기에 충분한 네트워크 연결 및 스토리지 용량을 제공해야 하지만 스토리지 및 네트워킹 구성 요소는 주로 컴퓨팅 클러스터에 데이터 세트를 로드하고 일관된 성능이 필요하지 않습니다.
- 스토리지 하드웨어
오픈 소스 소프트웨어와 함께 상용 하드웨어를 사용하여 스토리지 어레이를 구축할 수 있지만 배포하려면 전문 지식이 필요할 수 있습니다. 서버에서 직접 연결된 스토리지 솔루션과 함께 스케일 아웃 스토리지 솔루션을 사용할 수도 있지만 서버 하드웨어가 스토리지 솔루션을 지원하는지 확인해야 합니다.
스토리지 하드웨어를 설계할 때 다음 요소를 고려하십시오.
- 가용성. 인스턴스를 고가용성 또는 호스트 간 마이그레이션할 수 있어야 하는 경우 임시 인스턴스 데이터에 공유 스토리지 파일 시스템을 사용하여 노드 장애 발생 시 계산 서비스가 중단되지 않도록 합니다.
- 대기 시간. SSD(Solid-state drive) 디스크를 사용하여 인스턴스 스토리지 대기 시간을 최소화하고 CPU 지연을 줄이며 성능을 향상시킵니다. 컴퓨팅 호스트에서 RAID 컨트롤러 카드를 사용하여 기본 디스크 하위 시스템의 성능을 개선하는 것이 좋습니다.
- 성능. 컴퓨팅 중심 클라우드에는 일반적으로 스토리지에 주요 데이터 I/O가 필요하지 않지만 스토리지 성능은 여전히 고려해야 할 중요한 요소입니다. 스토리지 I/O 요청의 대기 시간을 관찰하여 스토리지 하드웨어 성능을 측정할 수 있습니다. 일부 컴퓨팅 집약적 워크로드에서는 스토리지에서 데이터를 가져오는 동안 CPU가 경험하는 지연을 최소화하면 애플리케이션의 전반적인 성능을 크게 향상시킬 수 있습니다.
- 확장 가능성. 스토리지 솔루션의 최대 용량을 결정합니다. 예를 들어, 50PB로 확장되는 솔루션은 10PB로만 확장되는 솔루션보다 확장할 수 있습니다. 이 메트릭은 확장 시 솔루션 성능 척도인 확장성과 관련이 있지만 다릅니다.
- 연결. 연결이 스토리지 솔루션 요구 사항을 충족해야 합니다. 중앙 집중식 스토리지 어레이를 선택하는 경우 하이퍼바이저를 스토리지 어레이에 연결하는 방법을 결정합니다. 연결은 대기 시간과 성능에 영향을 줄 수 있습니다. 따라서 네트워크 특성이 환경의 전체 성능을 높이기 위해 대기 시간을 최소화해야 합니다.
- 네트워크 하드웨어
2장. 네트워킹 In-Depth 에 설명된 기본 네트워크 고려 사항 외에도 다음 요소를 고려하십시오.
- 필요한 포트 수는 네트워크 설계에 필요한 물리적 공간에 영향을 미칩니다. 예를 들어 1U 서버의 각 포트에 대해 48개의 포트가 10GbE 용량을 제공하는 스위치는 2U 서버의 각 포트에 대해 10GbE 용량을 제공하는 스위치보다 포트 밀도가 높습니다. 포트 밀도가 클수록 컴퓨팅 또는 스토리지 구성 요소에 더 많은 랙 공간을 사용할 수 있습니다. 또한 내결함성 도메인 및 전원 밀도도 고려해야 합니다. 비용이 많이 들더라도 기능 요구 사항 이상으로 네트워크를 설계해서는 안되므로 밀도가 높은 스위치도 고려할 수 있습니다.
- 리프스라인 모델과 같은 용량 및 대역폭을 추가하는 데 도움이 되는 확장 가능한 네트워크 모델로 네트워크 아키텍처를 설계해야 합니다. 이러한 유형의 네트워크 설계에서는 대역폭을 추가하고 추가 장비 랙으로 확장할 수 있습니다.
- 필요한 포트 수, 포트 속도 및 포트 밀도를 지원하는 네트워크 하드웨어를 선택하는 것이 중요하며 워크로드 요구 사항이 증가할 때 향후 증가할 수 있습니다. 또한 중복을 제공하는 것이 중요한 네트워크 아키텍처에서 위치를 평가하는 것도 중요합니다. 네트워크 가용성과 중복성은 비용이 많이 들 수 있으므로 추가 비용을 중복 네트워크 스위치 및 호스트 수준에서 본딩된 인터페이스의 이점과 비교해야 합니다.
