▲

GN⁺: Ceph: 1 TiB/s를 향한 여정

 (ceph.io)
4P by neo 10달전 | favorite | 댓글 1개

Ceph: 1TiB/s로 가는 여정

  • Ceph 클러스터의 성능 개선 여정을 담은 기사로, 긴 디버깅과 성능 최적화 과정을 거쳐 1TiB/s의 데이터 처리 속도를 달성한 이야기.
  • Clyso라는 회사가 NVMe 기반의 10페타바이트 Ceph 클러스터 구축을 돕는 과정에서 발생한 다양한 기술적 문제와 해결책을 공유.
  • 고객사의 네트워크는 매우 빠르며, 이더넷 설정 중 가장 빠른 것 중 하나임.

감사의 말

  • Clyso의 고객사에게 감사를 표하며, 이들의 협력 덕분에 Ceph 커뮤니티와 경험을 공유할 수 있었음.
  • IBM/Red Hat과 삼성이 비교 테스트에 사용된 하드웨어를 제공해준 것에 대한 감사도 표함.
  • Ceph 기여자들에게도 Ceph를 훌륭한 소프트웨어로 만들기 위한 노력에 대한 감사를 전함.

클러스터 설정

  • 고객사는 17개 랙에 걸쳐 34개의 듀얼 소켓 2U 노드를 제안했으나, Clyso는 더 작은 노드를 사용하는 다양한 구성을 제안함.
  • 최종적으로 Dell 아키텍처를 선택하여 비용을 절감하고, 더 빠른 메모리 처리량, 더 많은 CPU 자원, 더 높은 네트워크 처리량을 제공함.
  • 노드 실패 시 클러스터 복구에 미치는 영향을 절반으로 줄임.

테스트 설정

  • CBT를 사용하여 임시 Ceph 클러스터를 배포하고 FIO 테스트를 실행함.
  • 라이브러리 기반 FIO 테스트를 사용하여 클러스터를 작은 단위로 나누고 이전 결과와 비교함.
  • 3X 복제와 6+2 손실 보정을 테스트하고, 메시지 버전 2를 암호화된 모드와 보안 모드로 테스트함.

PG 수에 대한 주의

  • PG 수가 성능에 미치는 영향을 실험적으로 테스트함.
  • 높은 PG 수가 성능에 긍정적인 영향을 미칠 수 있으나, 실제 생산 환경에서는 다른 설정과 함께 고려해야 함.

시작이 어려웠던 점

  • 하드웨어에 처음 로그인한 후, 예상보다 낮은 성능으로 인해 문제 해결에 어려움을 겪음.
  • 초기 성능 테스트는 좋았으나, 여러 OSD를 사용한 테스트에서 성능 저하가 발생함.

기묘한 동작

  • 다양한 OSD 테스트 조합을 실행하며 성능에 이상한 패턴이 있음을 발견함.
  • 시스템이 멀티-OSD 테스트 후 성능이 저하되었다가 몇 시간 후에 다시 회복되는 현상을 관찰함.

세 가지 해결책

  • CPU c-state 전환으로 인한 지연 문제를 해결하여 성능을 약간 향상시킴.
  • IOMMU를 비활성화하여 성능을 크게 향상시킴.
  • RocksDB 컴파일 플래그 문제를 해결하여 4K 랜덤 쓰기 성능을 두 배로 향상시킴.

2024년 첫 주

  • 새해 첫날 다른 클러스터의 대규모 장애로 인해 성능 테스트에 집중하지 못함.
  • 금요일에 성능 테스트를 재개하여 클러스터가 높은 부하 하에서도 잘 동작함을 확인함.

운명의 미소

  • 성능 테스트 결과가 좋아지면서 클러스터가 선형적으로 확장됨을 확인함.
  • 63개의 노드로 구성된 클러스터에서 635GiB/s의 데이터 처리 속도를 달성함.

부분적으로 작동하는 죽음의 별

  • 클라이언트 노드가 부족하여 OSD 노드와 FIO 프로세스를 공유해야 했음.
  • 이러한 설정에서도 950GiB/s에 가까운 성능을 달성함.

1TiB/s 도달

  • OSD 샤드 수와 메신저 스레드 수를 조정하여 1TiB/s의 데이터 처리 속도를 달성함.

수면; 손실 보정

  • 3X 복제로 테스트한 후, 고객사가 사용할 6+2 손실 보정으로 클러스터를 재구성하여 테스트함.
  • 읽기 성능은 500GiB/s 이상, 쓰기 성능은 거의 400GiB/s에 달함.

GN⁺의 의견:

  1. 이 기사는 Ceph 클러스터의 성능 최적화 과정을 상세히 설명하며, 복잡한 문제 해결 과정을 통해 높은 성능을 달성한 사례를 보여줌으로써 기술적 통찰력을 제공함.
  2. 고객사와의 협력, 커뮤니티 기여자들의 노력, 그리고 다양한 하드웨어 및 소프트웨어 최적화 전략이 어떻게 실제 세계에서 큰 성과를 낼 수 있는지를 보여줌.
  3. 이 글은 대규모 데이터 스토리지 시스템을 다루는 전문가뿐만 아니라, 성능 최적화에 관심 있는 기술자들에게도 유익한 정보를 제공함.
▲
neo 10달전  [-]
Hacker News 의견
  • CERN의 1TB/s 도달 소식과 Ceph의 역사
    • 한 사용자는 CERN에서 EOS 클러스터를 통해 1TB/s의 속도를 달성했다고 언급하며, 이 클러스터는 주로 HDD를 사용하고 더 많은 노드를 가지고 있다고 설명함. 또한, Ceph가 Dreamhost에서 내부적인 필요에 의해 창안되었고, 이후 Redhat에 의해 인수되었다는 흥미로운 역사를 공유함.
  • 과거 기술 리더의 경험과 Ceph에 대한 호감
    • 한 사용자는 Cisco에서 기술 리더로 일하며 Kubernetes를 베어 메탈에 설정하고 GlusterFS와 Ceph를 실험한 경험을 회상하며, 이러한 실험을 즐겼다고 언급함. 또한, 해당 글을 잘 쓴 것에 대해 칭찬함.
  • 노드 크기 축소에 대한 제안
    • 한 사용자는 현재 시스템의 노드당 에너지 소비가 높다고 지적하며, 노드 크기를 줄이는 엔지니어링 노력이 필요하다고 제안함. 이를 통해 더 적은 노드로도 충분하고, 단일 장애가 10개의 디스크에 영향을 미치는 것을 줄일 수 있다고 주장함.
  • 디지털 데이터 저장량의 역사적 관점
    • 한 사용자는 지난 60년 이내에 전 세계적으로 처음으로 1TiB의 디지털 데이터가 저장된 날이 있었을 것이라고 언급하며, 현재는 매초 그런 양의 데이터를 이동시키고 있다고 놀라움을 표현함.
  • Ceph 클러스터를 통한 Docker 캐시 성능 향상 경험
    • 한 사용자는 Docker 레이어 캐시를 유지하기 위해 Ceph 스토리지 클러스터를 운영하고 있으며, EBS에서 Ceph로 전환한 후 처리량이 크게 향상되었다고 경험을 공유함. 이 사용자는 Ceph가 거의 유지 관리가 필요 없다고 언급함.
  • Kubernetes 내 스토리지 컨트롤러 소프트웨어 문제
    • 한 사용자는 Kubernetes 내에서 동적 스토리지와 관련된 가장 큰 문제가 I/O와 관련된 것이 아니라, 스토리지 컨트롤러 소프트웨어가 실제 문제에 직면했을 때 발생한다고 언급함. 특히, rook/ceph와 Longhorn을 사용할 때 PVC가 오랜 시간이 지난 후에야 연결되는 문제를 경험함.
  • 하드웨어 이론적 한계 대비 1 TiB/s 성능 분석
    • 한 사용자는 1 TiB/s의 성능이 하드웨어의 이론적 한계와 어떻게 비교되는지 분석하고, 네트워크가 병목 현상을 일으키고 있음을 지적함. 또한, Ceph의 복잡성이 CPU에 상당한 부담을 주고 있으며, OSD 스레딩 모델이 최적화되지 않았다고 결론짓고 개선을 희망함.
  • Ceph와 다른 오브젝트 스토리지 엔진 비교 요청
    • 한 사용자는 Ceph와 MinIO, Garage 등 다른 오브젝트 스토리지 엔진과의 비교 및 벤치마크를 보고 싶다고 요청함.
  • Ceph의 트랜잭션 데이터베이스 스토리지 적합성과 IO 지연 시간 문의
    • 한 사용자는 Ceph가 트랜잭션 데이터베이스 스토리지로 적합한지, IO 지연 시간은 어떤지에 대해 질문하며, Oracle의 클러스터 파일 시스템이나 Veritas와 같은 시스템과 경쟁할 수 있는 저렴한 파일 시스템으로 이동하고 싶다는 의견을 나타냄.
답변달기