1.2. 성능 및 확장
Red Hat Advanced Cluster Management for Kubernetes는 특정 확장성 및 성능 데이터를 확인하기 위해 테스트되었습니다. 테스트된 주요 영역은 클러스터 확장성 및 검색 성능입니다.
이 정보를 사용하여 환경을 계획하는 데 도움이 될 수 있습니다.
참고: 데이터는 테스트 시 랩 환경의 결과를 기반으로 합니다. 환경, 네트워크 속도 및 제품 변경 사항에 따라 결과가 다를 수 있습니다.
1.2.1. 최대 관리형 클러스터 수
Red Hat Advanced Cluster Management에서 관리할 수 있는 최대 클러스터 수는 다음과 같은 여러 요인에 따라 다릅니다.
- 배포된 정책 및 애플리케이션 수와 같은 요인에 따라 클러스터의 리소스 수입니다.
- 확장에 사용되는 Pod 수와 같은 hub 클러스터 구성
다음 표에서는 이 테스트 중에 사용된 Amazon Web Services 클라우드 플랫폼의 클러스터 구성 정보를 보여줍니다.
| 노드 | 플레이버 | vCPU | RAM(GiB) | 디스크 유형 | 디스크 크기(GiB) | 수량 | 리전 |
|---|---|---|---|---|---|---|---|
| Master | m5.2xlarge | 8 | 32 | gp2 | 100 | 3 | us-east-1 |
| 작업자 또는 인프라 | m5.2xlarge | 8 | 32 | gp2 | 100 | 노드 3개 또는 5개 | us-east-1 |
인프라 노드에 대한 자세한 내용은 인프라 노드에 Red Hat Advanced Cluster Management hub 클러스터 설치를 참조하십시오. 또한 인프라 머신 세트 생성을 참조하십시오.
1.2.2. 검색 확장성
검색 구성 요소의 확장성은 데이터 저장소의 성능에 따라 다릅니다. 검색 성능을 분석할 때 다음 변수가 중요합니다.
- 물리적 메모리
- 쓰기 처리량 (Cache 복구 시간)
- 쿼리 실행 시간
1.2.2.1. 물리적 메모리
검색은 데이터를 메모리 내로 유지하여 빠른 응답 시간을 달성합니다. 필요한 메모리는 Kubernetes 리소스 수 및 클러스터의 관계에 비례합니다.
| 클러스터 | Kubernetes 리소스 | 관계 | 관찰된 크기(감시 데이터 포함) |
|---|---|---|---|
| 1 중간 | 5000 | 9500 | 50 Mi |
| 5 중간 | 25,000 | 75,000 | 120 Mi |
| 15 중간 | 75,000 | 20,0000 | 492 Mi |
| 30 중간 | 150,000 | 450,000 | 1GI |
| 50개 중간 | 250,000 | 750,000 | 2GI |
1.2.2.2. 쓰기 처리량(캐시 복구 시간)
대부분의 정상 상태의 클러스터는 적은 수의 리소스 업데이트를 생성합니다. RedisGraph의 데이터를 지우면 가장 높은 업데이트가 발생하여 원격 수집기가 동시에 전체 상태를 동기화합니다. 데이터 저장소를 지우면 다른 수의 관리형 클러스터에 대해 복구 시간이 측정됩니다.
| 클러스터 | Kubernetes 리소스 | 관계 | 시뮬레이션에서 평균 복구 시간 |
|---|---|---|---|
| 1 중간 | 5000 | 9500 | 2초 미만 |
| 5 중간 | 25,000 | 75,000 | 15초 미만 |
| 15 중간 | 75,000 | 200,000 | 2분 40초 |
| 30 중간 | 150,000 | 450,000 | 5-8분 |
참고: 허브에 대한 네트워크 연결이 느린 클러스터의 시간이 증가할 수 있습니다. 이전에 명시된 쓰기 처리량 정보는 지속성 이 비활성화된 경우에만 적용됩니다.
1.2.2.3. 쿼리 실행 고려 사항
쿼리의 결과를 실행하고 반환하는 데 걸리는 시간에 영향을 줄 수 있는 몇 가지 사항이 있습니다. 환경을 계획 및 구성할 때 다음 항목을 고려하십시오.
키워드를 검색하는 것은 효율적이지 않습니다.
RedHat을 검색하고 많은 수의 클러스터를 관리하는 경우 검색 결과를 얻는 데 시간이 더 걸릴 수 있습니다.- 첫 번째 검색은 사용자 역할 기반 액세스 제어 규칙을 수집하는 데 추가 시간이 걸리기 때문에 이후 검색보다 오래 걸립니다.
요청을 완료하는 데 걸리는 시간은 사용자가 액세스할 수 있는 네임스페이스 및 리소스 수에 비례합니다.
참고: 다른 사용자와 검색 쿼리를 저장하고 공유하는 경우 반환된 결과는 해당 사용자의 액세스 수준에 따라 달라집니다. 역할 액세스에 대한 자세한 내용은 OpenShift Container Platform 설명서에서 RBAC를 사용하여 권한 정의 및 적용을 참조하십시오.
- 관리자가 아닌 사용자가 모든 네임스페이스 또는 모든 관리 클러스터에 액세스할 수 있는 요청으로 최악의 성능이 확인됩니다.
1.2.3. 관찰성을 위한 스케일링
관찰 서비스를 활성화하고 사용하려면 환경을 계획해야 합니다. 나중에 리소스 사용은 관찰 가능 구성 요소가 설치된 OpenShift Container Platform 프로젝트용입니다. 사용할 값은 모든 관찰 가능 구성 요소에 대한 합계입니다.
참고: 데이터는 테스트 시 랩 환경의 결과를 기반으로 합니다. 환경, 네트워크 속도 및 제품 변경 사항에 따라 결과가 다를 수 있습니다.
1.2.3.1. 샘플 관찰 가능 환경
샘플 환경에서 허브 클러스터 및 관리 클러스터는 Amazon Web Services 클라우드 플랫폼에 있으며 다음과 같은 토폴로지 및 구성이 있습니다.
| 노드 | 플레이버 | vCPU | RAM(GiB) | 디스크 유형 | 디스크 크기(GiB) | 수량 | 리전 |
|---|---|---|---|---|---|---|---|
| 마스터 노드 | m5.4xlarge | 16 | 64 | gp2 | 100 | 3 | sa-east-1 |
| 작업자 노드 | m5.4xlarge | 16 | 64 | gp2 | 100 | 3 | sa-east-1 |
관찰성 배포는 고가용성 환경을 위해 구성됩니다. 고가용성 환경에서 각 Kubernetes 배포에는 두 개의 인스턴스가 있으며 각 StatefulSet에는 세 개의 인스턴스가 있습니다.
샘플 테스트 중에 지표를 푸시하기 위해 다른 수의 관리형 클러스터가 시뮬레이션되며 각 테스트는 24시간 동안 지속됩니다. 다음 처리량을 확인합니다.
1.2.3.2. 쓰기 처리량
| Pods | 간격(분) | min당 시계열 |
|---|---|---|
| 400 | 1 | 83000 |
1.2.3.3. CPU 사용량(밀리코어)
테스트 중에 CPU 사용량이 안정적입니다.
| 크기 | CPU 사용량 |
|---|---|
| 클러스터 10개 | 400 |
| 클러스터 20개 | 800 |
1.2.3.4. RSS 및 작업 세트 메모리
RSS 및 작업 세트 메모리에 대한 다음 설명을 확인합니다.
-
메모리 사용량 RSS: 지표
container_memory_rss에서 테스트 중에 안정적으로 유지됩니다. -
메모리 사용량 작업 세트: 메트릭
container_memory_working_set_bytes는 테스트와 함께 증가합니다.
다음 결과는 24 시간 테스트에서 가져온 것입니다.
| 크기 | 메모리 사용량 RSS | 메모리 사용량 작업 세트 |
|---|---|---|
| 클러스터 10개 | 9.84 | 4.93 |
| 클러스터 20개 | 13.10 | 8.76 |
1.2.3.5. thanos-receive 구성 요소에 대한 영구 볼륨
중요: 지표는 보존 시간(4일)에 도달할 때까지 thanos-receive 에 저장됩니다. 다른 구성 요소에는 thanos-receive 구성 요소만큼 많은 볼륨이 필요하지 않습니다.
디스크 사용량이 테스트와 함께 증가합니다. 데이터는 1일 후 디스크 사용량을 나타내므로 최종 디스크 사용량이 4배 증가합니다.
다음 디스크 사용량을 확인합니다.
| 크기 | 디스크 사용량(GiB) |
|---|---|
| 클러스터 10개 | 2 |
| 클러스터 20개 | 3 |
1.2.3.6. 네트워크 전송
테스트 중에 네트워크 전송은 안정성을 제공합니다. 크기 및 네트워크 전송 값을 참조하십시오.
| 크기 | 인바운드 네트워크 전송 | 아웃바운드 네트워크 전송 |
|---|---|---|
| 클러스터 10개 | 초당 6.55MBS | 초당 5.80MBS |
| 클러스터 20개 | 초당 13.08MBS | 초당 10.9MBS |
1.2.3.7. Amazon Simple Storage Service (S3)
Amazon Simple Storage Service(S3)의 총 사용량이 증가합니다. 지표 데이터는 기본 보존 시간(5일)에 도달할 때까지 S3에 저장됩니다. 다음 디스크 사용량을 참조하십시오.
| 크기 | 디스크 사용량(GiB) |
|---|---|
| 클러스터 10개 | 16.2 |
| 클러스터 20개 | 23.8 |
1.2.4. hub 클러스터 크기 조정
각 Red Hat Advanced Cluster Management for Kubernetes 클러스터는 고유하며 다음 지침은 배포 크기를 샘플로 제공합니다. 권장 사항은 크기와 목적에 따라 분류됩니다. Red Hat Advanced Cluster Management는 지원 서비스의 규모 및 배치에 다음과 같은 차원을 적용합니다.
- 가용성 영역은 클러스터 전체에서 잠재적인 오류 도메인을 격리합니다. 일반적인 클러스터에는 3개 이상의 가용성 영역에 거의 동일한 작업자 노드 용량이 있어야 합니다.
- vCPU 예약 및 제한: 컨테이너에 할당할 작업자 노드에서 vCPU 용량을 설정합니다. vCPU는 Kubernetes 컴퓨팅 단위와 동일합니다. 자세한 내용은 Kubernetes CPU 메커니즘을 참조하십시오.
- 컨테이너에 할당할 작업자 노드에서 메모리 용량을 설정하는 메모리 예약 및 제한입니다.
- 제품에서 관리하고 Kubernetes에서 사용하는 etcd 클러스터에 저장된 영구 데이터입니다.
중요: OpenShift Container Platform의 경우 세 가지 가용성 영역에 클러스터의 마스터 노드를 배포합니다.
1.2.4.1. 제품 환경
참고: 다음 요구 사항은 최소 요구사항이 아닙니다.
표 1.1. 제품 환경
| 노드 유형 | 가용성 영역 | etcd | 예약된 총 메모리 | 예약된 총 CPU |
|---|---|---|---|---|
| Master | 3 | 3 | OpenShift Container Platform 크기 조정 지침 | OpenShift Container Platform 크기 조정 지침 |
| 작업자 또는 인프라 | 3 | 1 | 12GB | 6 |
OpenShift Container Platform 클러스터는 Red Hat Advanced Cluster Management 외에도 클러스터 기능을 지원하기 위해 추가 서비스를 실행합니다. 자세한 내용은 인프라 노드에 Red Hat Advanced Cluster Management hub 클러스터 설치를 참조하십시오.
1.2.4.1.1. 추가 서비스의 OpenShift Container Platform
표 1.2. 추가 서비스
| Service | 노드 수 | 가용성 영역 | 인스턴스 크기 | vCPU | 메모리 | 스토리지 크기 | Resources |
|---|---|---|---|---|---|---|---|
| Amazon Web Services의 OpenShift Container Platform | 3 | 3 | m5.xlarge | 4 | 16GB | 120GB | 자세한 내용은 OpenShift Container Platform 제품 설명서의 Amazon Web Services 정보를 참조하십시오. 또한 머신 유형에 대해 자세히 알아보십시오. |
| Google Cloud Platform의 OpenShift Container Platform | 3 | 3 | N1-standard-4 (0.95-6.5GB) | 4 | 15GB | 120GB | 할당량에 대한 자세한 내용은 Google Cloud Platform 제품 설명서를 참조하십시오. 또한 머신 유형에 대해 자세히 알아보십시오. |
| Microsoft Azure의 OpenShift Container Platform | 3 | 3 | Standard_D4_v3 | 4 | 16GB | 120GB | 자세한 내용은 다음 제품 설명서 를 참조하십시오. |
| VMware vSphere의 OpenShift Container Platform | 3 | 3 | 4개 ( 소켓당 2개 코어) | 16GB | 120GB | 자세한 내용은 다음 제품 설명서 를 참조하십시오. | |
| IBM Z 시스템의 OpenShift Container Platform | 3 | 3 | 10 | 16GB | 100GB | 자세한 내용은 OpenShift Container Platform 설명서에서 IBM Z 시스템에 클러스터 설치를 참조하십시오. IBM Z 시스템은 동시 멀티스레딩(SMT)을 구성할 수 있는 기능을 제공하며 각 코어에서 실행할 수 있는 vCPU 수를 확장합니다. SMT를 구성한 경우 하나의 물리적 코어(IFL)는 두 개의 논리 코어(스레드)를 제공합니다. 하이퍼바이저는 두 개 이상의 vCPU를 제공할 수 있습니다. SMT(동시 멀티스레딩) 또는 하이퍼 스레딩이 활성화되지 않은 경우 하나의 vCPU는 하나의 물리적 코어와 동일합니다. 활성화하면 다음과 같은 공식을 사용하여 해당 비율을 계산합니다. (코어 당 스레드 수 × 코어 수) × 소켓 수 = vCPU 수 SMT에 대한 자세한 내용은 Simultaneous multithreading 을 참조하십시오. | |
| IBM Power 시스템의 OpenShift Container Platform | 3 | 3 | 16 | 16GB | 120GB | 자세한 내용은 OpenShift Container Platform 설명서의 Power 시스템에 클러스터 설치를 참조하십시오. IBM Power 시스템은 동시 멀티스레딩(SMT)을 구성할 수 있는 기능을 제공하며 각 코어에서 실행할 수 있는 vCPU 수를 확장합니다. SMT를 구성한 경우 SMT 수준은 16 vCPU 요구 사항을 충족하는 방법을 결정합니다. 가장 일반적인 구성은 다음과 같습니다. SMT-8에서 실행 중인 코어 두 개(IBM PowerVM을 실행하는 시스템의 기본 구성)는 필요한 16개의 vCPU를 제공합니다. SMT-4에서 실행되는 코어 4개는 필요한 16개의 vCPU를 제공합니다. SMT에 대한 자세한 내용은 Simultaneous multithreading 을 참조하십시오. | |
| OpenShift Container Platform 온-프레미스 | 3 | 4 | 16GB | 120GB | 자세한 내용은 다음 제품 설명서 를 참조하십시오. OpenShift Container Platform 베어 메탈에 Red Hat Advanced Cluster Management for Kubernetes hub 클러스터를 설치하고 지원할 수 있습니다. 허브 클러스터는 컴팩트한 베어 메탈 토폴로지에서 실행할 수 있으며, 여기에는 3개의 스케줄링 가능한 컨트롤 플레인 노드와 0개의 추가 작업자가 있습니다. |
1.2.4.1.2. 단일 노드 OpenShift Container Platform 클러스터 생성 및 관리
3500 단일 노드 OpenShift Container Platform 클러스터를 생성하고 관리하는 데 필요한 요구사항의 예를 참조하십시오. Red Hat Advanced Cluster Management를 사용하여 단일 노드 OpenShift (SNO) 클러스터를 생성하고 허브 클러스터가 있는 SNO 클러스터를 관리하기 위한 최소 요구사항을 참조하십시오.
표 1.3. 마스터 (예약 가능)
| 노드 수 | 메모리(사용 가능한 클러스터 사용) | 메모리(단일 노드 최대) | CPU 클러스터 max | CPU 단일 노드 max |
|---|---|---|---|---|
| 3 | 289GB | 110GB | 90 | 44 |
참고: 스케일 결과는 2023년 1월 4일의 Red Hat 성능 및 스케일 랩 결과를 반영합니다.