7장. 확장성 및 성능 최적화
7.1. 스토리지 최적화
스토리지를 최적화하면 모든 리소스에서 스토리지 사용을 최소화할 수 있습니다. 관리자는 스토리지를 최적화하여 기존 스토리지 리소스가 효율적으로 작동하도록 합니다.
7.1.1. 사용 가능한 영구 스토리지 옵션
OpenShift Container Platform 환경을 최적화할 수 있도록 영구 스토리지 옵션에 대해 알아보십시오.
표 7.1. 사용 가능한 스토리지 옵션
| 스토리지 유형 | 설명 | 예 |
|---|---|---|
| 블록 |
| AWS EBS 및 VMware vSphere는 OpenShift Container Platform에서 기본적으로 동적 PV(영구 볼륨) 프로비저닝을 지원합니다. |
| 파일 |
| RHEL NFS, NetApp NFS [1] 및 Vendor NFS |
| 개체 |
| AWS S3 |
- NetApp NFS는 Trident 플러그인을 사용할 때 동적 PV 프로비저닝을 지원합니다.
7.1.2. 권장되는 구성 가능한 스토리지 기술
다음 표에는 지정된 OpenShift Container Platform 클러스터 애플리케이션에 권장되는 구성 가능한 스토리지 기술이 요약되어 있습니다.
표 7.2. 권장되는 구성 가능한 스토리지 기술
| 스토리지 유형 | 블록 | 파일 | 개체 |
|---|---|---|---|
|
1
2 3 Prometheus는 메트릭에 사용되는 기본 기술입니다. 4 물리적 디스크, VM 물리적 디스크, VMDK, NFS를 통한 루프백, AWS EBS 및 Azure Disk에는 적용되지 않습니다.
5 메트릭의 경우 RWX( 6 로깅은 로그 저장소의 영구 스토리지 구성 섹션에서 권장되는 스토리지 솔루션을 검토하십시오. NFS 스토리지를 영구 볼륨으로 사용하거나 Gluster와 같은 NAS를 통해 데이터가 손상될 수 있습니다. 따라서 OpenShift Container Platform Logging에서 Elasticsearch 스토리지 및 10.0.0.1Stack 로그 저장소에 NFS가 지원되지 않습니다. 로그 저장소당 하나의 영구 볼륨 유형을 사용해야 합니다. 7 OpenShift Container Platform의 PV 또는 PVC를 통해서는 오브젝트 스토리지가 사용되지 않습니다. 앱은 오브젝트 스토리지 REST API와 통합해야 합니다. | |||
| ROX1 | 제공됨4 | 제공됨4 | 예 |
| RWX2 | 없음 | 예 | 예 |
| Registry | 구성 가능 | 구성 가능 | 권장 |
| 확장 레지스트리 | 구성 불가능 | 구성 가능 | 권장 |
| Metrics3 | 권장 | 구성 가능5 | 구성 불가능 |
| Elasticsearch 로깅 | 권장 | 구성 가능6 | 지원되지 않음6 |
| CloudEvent Logging | 구성 불가능 | 구성 불가능 | 권장 |
| 앱 | 권장 | 권장 | 구성 불가능7 |
확장된 레지스트리는 두 개 이상의 포드 복제본이 실행되는 OpenShift 이미지 레지스트리입니다.
7.1.2.1. 특정 애플리케이션 스토리지 권장 사항
테스트에서는 RHEL(Red Hat Enterprise Linux)의 NFS 서버를 핵심 서비스용 스토리지 백엔드로 사용하는 데 문제가 있는 것을 보여줍니다. 여기에는 OpenShift Container Registry and Quay, 스토리지 모니터링을 위한 Prometheus, 로깅 스토리지를 위한 Elasticsearch가 포함됩니다. 따라서 RHEL NFS를 사용하여 핵심 서비스에서 사용하는 PV를 백업하는 것은 권장되지 않습니다.
마켓플레이스의 다른 NFS 구현에는 이러한 문제가 나타나지 않을 수 있습니다. 이러한 OpenShift Container Platform 핵심 구성 요소에 대해 완료된 테스트에 대한 자세한 내용은 개별 NFS 구현 공급업체에 문의하십시오.
7.1.2.1.1. 레지스트리
비 확장/HA(고가용성) OpenShift 이미지 레지스트리 클러스터 배포에서는 다음을 수행합니다.
- 스토리지 기술에서 RWX 액세스 모드를 지원할 필요가 없습니다.
- 스토리지 기술에서 쓰기 후 읽기 일관성을 보장해야 합니다.
- 기본 스토리지 기술은 오브젝트 스토리지, 블록 스토리지 순입니다.
- 프로덕션 워크로드가 있는 OpenShift 이미지 레지스트리 클러스터 배포에는 파일 스토리지를 사용하지 않는 것이 좋습니다.
7.1.2.1.2. 확장 레지스트리
확장/HA OpenShift 이미지 레지스트리 클러스터 배포에서는 다음을 수행합니다.
- 스토리지 기술은 RWX 액세스 모드를 지원해야 합니다.
- 스토리지 기술에서 쓰기 후 읽기 일관성을 보장해야 합니다.
- 기본 스토리지 기술은 오브젝트 스토리지입니다.
- Red Hat OpenShift Data Foundation(ODF), Amazon Simple Storage Service(Amazon S3), GCS(Google Cloud Storage), Microsoft Azure Blob Storage 및 OpenStack Swift가 지원됩니다.
- 오브젝트 스토리지는 S3 또는 Swift와 호환되어야 합니다.
- vSphere, 베어 메탈 설치 등 클라우드 이외의 플랫폼에서는 구성 가능한 유일한 기술이 파일 스토리지입니다.
- 블록 스토리지는 구성 불가능합니다.
7.1.2.1.3. 지표
OpenShift Container Platform 호스트 지표 클러스터 배포에서는 다음 사항에 유의합니다.
- 기본 스토리지 기술은 블록 스토리지입니다.
- 오브젝트 스토리지는 구성 불가능합니다.
프로덕션 워크로드가 있는 호스트 지표 클러스터 배포에는 파일 스토리지를 사용하지 않는 것이 좋습니다.
7.1.2.1.4. 로깅
OpenShift Container Platform 호스트 로깅 클러스터 배포에서는 다음 사항에 유의합니다.
Loki Operator:
- 기본 스토리지 기술은 S3 호환 오브젝트 스토리지입니다.
- 블록 스토리지는 구성 불가능합니다.
OpenShift Elasticsearch Operator:
- 기본 스토리지 기술은 블록 스토리지입니다.
- 오브젝트 스토리지는 지원되지 않습니다.
로깅 버전 5.4.3부터 OpenShift Elasticsearch Operator는 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 받지 않으며 제거됩니다. OpenShift Elasticsearch Operator를 사용하여 기본 로그 스토리지를 관리하는 대신 Loki Operator를 사용할 수 있습니다.
7.1.2.1.5. 애플리케이션
애플리케이션 사용 사례는 다음 예에 설명된 대로 애플리케이션마다 다릅니다.
- 동적 PV 프로비저닝을 지원하는 스토리지 기술은 마운트 대기 시간이 짧고 정상 클러스터를 지원하는 노드와 관련이 없습니다.
- 애플리케이션 개발자는 애플리케이션의 스토리지 요구사항을 잘 알고 있으며 제공된 스토리지로 애플리케이션을 작동시켜 애플리케이션이 스토리지 계층을 스케일링하거나 스토리지 계층과 상호 작용할 때 문제가 발생하지 않도록 하는 방법을 이해하고 있어야 합니다.
7.1.2.2. 다른 특정 애플리케이션 스토리지 권장 사항
etcd 와 같은 집약적 워크로드에서는 RAID 구성을 사용하지 않는 것이 좋습니다. RAID 구성으로 etcd 를 실행하는 경우 워크로드에 성능 문제가 발생할 위험이 있을 수 있습니다.
- RHOSP(Red Hat OpenStack Platform) Cinder: RHOSP Cinder는 ROX 액세스 모드 사용 사례에 적합합니다.
- 데이터베이스: 데이터베이스(RDBMS, NoSQL DB 등)는 전용 블록 스토리지를 사용하는 경우 성능이 최대화되는 경향이 있습니다.
- etcd 데이터베이스에는 대규모 클러스터를 활성화하기 위해 충분한 스토리지와 적절한 성능 용량이 있어야 합니다. 충분한 스토리지 및 고성능 환경을 설정하는 모니터링 및 벤치마킹 툴에 대한 정보는 권장 etcd 관행에 설명되어 있습니다.
7.1.3. 데이터 스토리지 관리
다음 표에는 OpenShift Container Platform 구성 요소가 데이터를 쓰는 기본 디렉터리가 요약되어 있습니다.
표 7.3. OpenShift Container Platform 데이터를 저장하는 기본 디렉터리
| 디렉터리 | 참고 | 크기 조정 | 예상 증가 |
|---|---|---|---|
| /var/log | 모든 구성 요소의 로그 파일입니다. | 10~30GB입니다. | 로그 파일이 빠르게 증가할 수 있습니다. 크기는 디스크를 늘리거나 로그 회전을 사용하여 관리할 수 있습니다. |
| /var/lib/etcd | 데이터베이스를 저장할 때 etcd 스토리지에 사용됩니다. | 20GB 미만입니다. 데이터베이스는 최대 8GB까지 증가할 수 있습니다. | 환경과 함께 천천히 증가합니다. 메타데이터만 저장합니다. 추가로 메모리가 8GB 증가할 때마다 추가로 20~25GB가 증가합니다. |
| /var/lib/containers | CRI-O 런타임의 마운트 옵션입니다. Pod를 포함한 활성 컨테이너 런타임에 사용되는 스토리지 및 로컬 이미지 스토리지입니다. 레지스트리 스토리지에는 사용되지 않습니다. | 16GB 메모리가 있는 노드의 경우 50GB가 증가합니다. 이 크기 조정은 최소 클러스터 요구사항을 결정하는 데 사용하면 안 됩니다. 추가로 메모리가 8GB 증가할 때마다 추가로 20~25GB가 증가합니다. | 컨테이너 실행 용량에 의해 증가가 제한됩니다. |
| /var/lib/kubelet | Pod용 임시 볼륨 스토리지입니다. 런타임 시 컨테이너로 마운트된 외부 요소가 모두 포함됩니다. 영구 볼륨에서 지원하지 않는 환경 변수, kube 보안 및 데이터 볼륨이 포함됩니다. | 변동 가능 | 스토리지가 필요한 Pod가 영구 볼륨을 사용하는 경우 최소입니다. 임시 스토리지를 사용하는 경우 빠르게 증가할 수 있습니다. |
7.1.4. Microsoft Azure의 스토리지 성능 최적화
OpenShift Container Platform 및 Kubernetes는 디스크 성능에 민감하며 특히 컨트롤 플레인 노드의 etcd에 더 빠른 스토리지를 사용하는 것이 좋습니다.
워크로드가 집약적인 프로덕션 Azure 클러스터 및 클러스터의 경우 컨트롤 플레인 머신용 가상 머신 운영 체제 디스크는 5000 IOPS / 200MBps의 테스트된 권장 최소 처리량을 유지할 수 있어야 합니다. 이 처리량은 최소 1 TiB Premium SSD (P30)를 보유하여 제공할 수 있습니다. Azure 및 Azure Stack Hub에서 디스크 성능은 SSD 디스크 크기에 직접 따라 달라집니다. Standard_D8s_v3 가상 머신 또는 기타 유사한 머신 유형 및 5000 IOPS 대상에서 지원하는 처리량을 달성하려면 최소 P30 디스크가 필요합니다.
짧은 대기 시간과 높은 IOPS 및 처리량은 데이터를 읽을 때 호스트 캐싱을 ReadOnly 로 설정해야 합니다. VM 메모리 또는 로컬 SSD 디스크에 있는 캐시에서 데이터를 읽는 것은 Blob 스토리지에 있는 디스크에서 데이터를 읽는 것보다 훨씬 빠릅니다.
