Ceph Blog(https://ceph.io/en/news/blog/)를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://ceph.io/en/news/blog/2025/benchmarking-object-part1/
소개: 보안 객체 스토리지에 성능이 중요한 이유
오늘날 기업들은 수십 페타바이트에 달하는 방대한 양의 데이터를 관리하는 것뿐만 아니라, 하이브리드 및 멀티클라우드 환경에서 데이터를 안전하게 보호해야 하는 책임까지 안고 있습니다. 오브젝트 스토리지 시스템(특히 Ceph)은 S3 호환 액세스, 네이티브 중복성, 그리고 다양한 엔터프라이즈 기능을 제공하여 이러한 과제를 해결하는 데 필요한 확장성과 유연성을 제공합니다.
전송 중 및 저장 중 암호화가 Ceph Object Gateway(RGW) 배포를 통해 구성되고 계층화됨에 따라 대기 시간, 처리량 및 리소스 활용에 미치는 영향을 이해하는 것이 필수적입니다.
이 블로그 시리즈에서는 IBM Storage Ceph 성능 및 상호 운용성 팀이 수행한 포괄적인 성능 벤치마킹 결과를 소개합니다. 테스트 케이스 실행 및 데이터 수집을 주도해 주신 Jay Rajput 님께 특별히 감사드립니다. 저희 평가는 실제 워크로드가 다양한 암호화, 데이터 보호 및 수평적 확장 구성과 어떻게 상호 작용하는지에 중점을 두고 설계자, 관리자, 개발자 모두에게 실질적인 통찰력을 제공합니다.
하드웨어 및 소프트웨어 설정
우리는 RGW, OSD, Monitor, Manager 및 Ingress 서비스를 함께 배치하여 프로덕션 등급 Ceph 클러스터에서 테스트했습니다.
하드웨어 사양
| 요소 | 역할(들) | 수량 | CPU | 숫양 | 저장 |
|---|---|---|---|---|---|
| 델 R760 | 모니터, 관리자, OSD, RGW, Ingress | 12 | 2× Intel Xeon Gold 6438N(64스레드) | 512GB | 24 × 3.84TB NVMe |
| 델 R660 | 벤치마킹 클라이언트, 모니터링 | 13 | 2× Intel Xeon Gold 5418Y(48스레드) | 384GB | 2 × 3.84TB NVMe |
각 테스트 클러스터 구성(4노드, 8노드, 12노드)은 일관된 OSD 밀도(노드당 24개)와 노드당 4개의 RGW 데몬을 유지했으며, Ingress 기반 부하 분산을 위한 전용 VIP를 사용했습니다.
| Ceph 클러스터 설정 | 세부 |
|---|---|
| 클러스터 크기 | 4노드, 8노드, 12노드 |
| 총 OSD 수 | 96, 192, 288 |
| OSD | 노드당 24개 |
| RGW | 노드당 4개 |
| 입구 | 노드당 VIP 1개 |
| RGW 데이터 풀 | 레플리카 3, EC 2+2, 4+2, 8+3 |
| OSD당 PG 복제본 수 | ~400 |
| 공동 배치된 Ceph Daemons | 모니터, 관리자, OSD, RGW, Ingress |
| 버킷 샤드당 객체 수 | 기본값: 100K |
소프트웨어 버전 매트릭스
| 요소 | 버전/참고사항 |
|---|---|
| 세프 | 19.2.0-52 |
| 엘벤초 | 3.0-26(벤치마킹 도구) |
| 하시코프 볼트 | 1.19.1(SSE 키 관리용) |
| 프로메테우스 + 그라파나 | 모니터링 스택 |
| RHEL | BIOS 프로필이 “성능”으로 설정된 9.5 |
Ceph 클러스터 구성
| Ceph 클러스터 구성 | 값 |
|---|---|
| 스크럽/딥 스크럽 | 장애가 있는 |
| 세프 밸런서 | 장애가 있는 |
| 진행 모듈 | 장애가 있는 |
| PG 자동 스케일러 | 장애가 있는 |
| OSDMAP_플래그 | 음소거됨 |
| 동적 버킷 재분할 | 장애가 있는 |
PG 카운트¶
| 클러스터 크기 | OSD 카운트 | OSD당 대상 PG 복제본 | 풀 유형 | PG Count(인덱스/데이터 풀) |
|---|---|---|---|---|
| 4 노드 | 96 | 400 | EC 2+2 / 복제됨 | 512 / 8192 |
| 8 노드 | 192 | 400 | EC 2+2 | 1024 / 32768 |
| 8 노드 | 192 | 400 | EC 4+2 | 1024 / 16384 |
| 8 노드 | 192 | 400 | EC 8+3 | 1024 / 8192 |
| 12 노드 | 288 | 400 | EC 2+2 | 1024 / 32768 |
| 12 노드 | 288 | 400 | EC 4+2 | 1024 / 16384 |
| 12 노드 | 288 | 400 | EC 8+3 | 1024 / 8192 |
네트워크 아키텍처 및 하드웨어 연결
컴퓨팅/스토리지 설정을 보완하기 위해 네트워크는 클러스터의 높은 처리량 성능을 뒷받침합니다.
- 리프-스파인 토폴로지: 스파인 1개(QFX5120)와 리프 스위치 3개(QFX5120)로 구성된 100GE 리프-스파인 네트워크를 운영하여 확장 가능하고 지연 시간이 짧은 설계를 구현했습니다. 이를 통해 성능 저하 없이 현재의 포트 밀도는 물론 향후 업그레이드 경로(예: 트루 스파인 추가 및 기존 스파인 용도 변경)를 확보할 수 있습니다.
- LACP를 통한 서버당 듀얼 100Gbps 업링크: 각 Ceph 노드는 LACP를 사용하여 본딩된 단일 NIC의 두 개의 100GE 포트를 활용하여 중복성과 링크 집계를 위해 두 리프 스위치에 연결합니다.
- 노드당 제한: 각 Ceph 스토리지 노드에는 최대 100Gbps의 총 처리량을 지원하는 Intel NIC가 장착되어 있습니다. 단, 두 개의 포트가 LACP를 통해 연결 및 사용 가능하더라도 마찬가지입니다. 즉, 최적의 조건에서 노드당 처리량은 최대 12.5GB/s로 제한됩니다.
- 클러스터 전체 스위칭 용량: QFX5120 스파인 1개와 QFX5120 리프 스위치 3개로 구성된 리프-스파인 토폴로지는 12개의 스토리지 노드 전체에 걸쳐 완벽한 회선 속도 연결을 제공합니다. 각 리프는 4개의 노드에 연결되고 100Gbps의 속도로 스파인에 업링크합니다. 이를 통해 이론상 총 클러스터 스위칭 용량은 약 150GB/s에 달합니다. 대용량 객체 벤치마크에서 시스템은 약 111GB/s의 총 처리량을 달성하여, 특히 대용량 객체 읽기 집약적인 워크로드에서 물리적 네트워크 한계에 도달했음을 보여주었습니다.
테스트 방법론
우리는 성능과 보안을 위해 Ceph Object Gateway(RGW)를 배포하는 방법에 대한 기본적인 질문에 답하기 위해 성능 평가를 설계했습니다.
- TLS(SSL)는 RGW 처리량과 지연 시간에 어떤 영향을 미칩니까?
- 서버 측 암호화(SSE-S3/KMS)는 얼마나 많은 오버헤드를 발생시키나요?
- 내부 데몬 통신(msgr v2)을 보호하면 CPU 사용률에 영향을 미칩니까?
- EC 프로필(2+2, 4+2, 8+3)은 3배 복제와 어떻게 비교됩니까?
- HAProxy 기반 Ingress와 직접 액세스를 사용할 경우 성능에 어떤 영향이 있습니까?
- 성능은 노드 수와 동시성에 따라 어떻게 확장됩니까?
각 테스트 케이스는 64KiB에서 1GiB까지 다양한 객체 크기를 가진 PUT 및 GET 워크로드에서 반복되었습니다. Elbencho는 스레드 수가 128개인 클라이언트-서버 모드로 사용되었으며(SSE testis는 64개 스레드를 사용), 최대 8명의 동시 클라이언트를 실행했습니다. 각 Elbencho 클라이언트는 개별 버킷을 사용합니다. 버킷은 버킷당 11개의 기본 샤딩 수를 사용하여 미리 생성되었습니다. 1GiB보다 큰 객체에는 멀티파트 업로드가 사용되었습니다.
| 탑재량 크기 | 작업 부하 범주 | 대표자 |
|---|---|---|
| ≤ 64KB | 작은 물체 | 썸네일, 원격 측정 및 소규모 메타데이터 파일 |
| 1MB | 중간 크기의 물체 | 문서, 이메일, 첨부 파일 |
| ≥ 32MB | 큰 물체 | 백업, HD 미디어, ML 데이터 세트 |
요약
IBM Storage Ceph는 IBM Storage Ceph Ready Node 와 같은 100GE 네트워킹을 갖춘 최첨단 올플래시 인프라에 구축될 때 탁월한 성능과 유연성을 보여줍니다 . 기업이 수십억 개의 객체와 수 페타바이트 규모의 워크로드로 확장함에 따라, 높은 IOPS, 낮은 지연 시간, 메타데이터 중심 워크로드부터 높은 처리량과 대역폭을 많이 사용하는 워크로드까지 다양한 데이터 패턴을 처리하는 Ceph의 역량이 더욱 중요해지고 있습니다.
대형 개체 작업 부하(처리량 중심)
32MiB를 초과하는 객체의 경우, 클러스터는 최대 12개의 스토리지 노드까지 거의 선형적인 확장을 달성했으며, 최대 PUT 처리량은 65GiB/s, GET 처리량은 약 115GiB/s에 달했습니다. 이 지점을 넘어서면 개별 노드에서 100GiB/s의 NIC 포화 상태가 주요 병목 현상이 되었습니다. 이는 대용량 객체 워크로드가 현재 노드의 가용 리소스에서 더 높은 처리량 결과를 얻을 수 있는 여지가 여전히 남아 있기 때문에 향후 벤치마크 테스트에서 더 높은 대역폭의 NIC가 유리할 것임을 시사합니다. NIC의 공칭 포트 속도의 합과 두 개 이상의 포트가 사용 중일 때 처리할 수 있는 대역폭의 차이는 유의해야 합니다. 다중 포트 NIC에서는 후자가 전자보다 작을 수 있기 때문입니다.
대용량 객체의 경우, 완전 전송 중 보안 구성(TLS + msgr v2)은 적정 오버헤드로 높은 처리량을 유지했습니다. 이는 Ceph 객체 게이트웨이(RGW)가 대규모 보안 데이터 파이프라인에 적합함을 보여줍니다. 서버 측 암호화(SSE)를 활성화하여 저장 객체 암호화를 제공하는 경우 성능 향상의 여지가 있습니다.
소규모 개체 워크로드(IOPS 및 지연 시간 중심)
소규모 객체 테스트(64KiB)는 Ceph 객체 게이트웨이(RGW)가 동시성 및 클러스터 크기를 증가시키면서 IOPS를 효율적으로 확장할 수 있음을 보여주었습니다. 64KiB 객체로 구성된 시스템은 이레이저 코딩을 사용하여 12노드 클러스터에서 최대 391K GET IOPS와 86K PUT IOPS를 달성했습니다.
특히 높은 동시성 하에서 소규모 객체 워크로드에 대한 최적의 성능을 발휘하려면 강력한 CPU 용량과 풍부한 RGW 스레딩을 갖춘 인프라에 배포하는 것이 필수적입니다. 이를 통해 Ceph Object Gateway가 병렬 처리 기능을 최대한 활용할 수 있습니다.
다음은 무엇인가 ¶
이 게시물에서는 테스트베드와 방법론을 소개하고 주요 결과를 강조합니다. 이 시리즈의 다음 게시물에서는 각 성능 축을 자세히 살펴보고, TLS와 SSE가 RGW 처리량에 미치는 영향, 이레이저 코딩과 복제를 비교했을 때의 확장 동작, 동시성과 데몬 밀도가 지연 시간에 미치는 영향 등을 살펴보겠습니다. 프로덕션 등급 테스트에서 직접 가져온 자세한 그래프와 아키텍처 지침을 확인할 수 있습니다. AI 파이프라인, 백업 또는 멀티테넌트 클라우드 서비스를 위한 보안 객체 스토리지를 구축하는 경우, 앞으로 더 많은 것을 발견할 수 있을 것입니다.
2부를 여기에서 읽어보세요 .
저자는 이 게시물을 작성하는 데 시간을 할애하여 커뮤니티를 지원해 준 IBM에 감사드리고 싶습니다.
