Ceph Blog(https://ceph.io/en/news/blog/)를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://ceph.io/en/news/blog/2025/automating-ceph-cluster-deployments_part1/
소개¶
빅데이터 시대에 방대한 양의 스토리지를 효율적이고 안정적으로 관리하는 것은 기업에게 중요한 과제입니다. Ceph는 유연성, 확장성, 그리고 견고성을 갖춘 선도적인 소프트웨어 정의 스토리지 솔루션으로 자리매김했습니다. 이러한 기반을 바탕으로 Ceph는 이러한 역량을 더욱 강화하여 엔터프라이즈 환경과의 원활한 통합과 페타바이트급 데이터를 효율적으로 관리할 수 있는 고급 도구를 제공합니다.
이 블로그 게시물 시리즈에서는 Ceph의 최첨단 오케스트레이터 cephadm를 사용하여 Ceph 클러스터를 자동으로 배포하는 방법을 자세히 살펴보겠습니다. 또한, Ansible을 사용하여 인프라를 자동화하는 분들을 위해 Jinja2 템플릿과 Ansible을 활용한 Infrastracture-As-Code 방식을 사용한 예시를 공유합니다.
코드로서의 인프라¶
코드형 인프라(IaC)는 인프라 설정을 코드처럼 처리하여 인프라 관리에 혁신을 가져옵니다. 이를 통해 버전 관리, 테스트, 지속적 통합과 같은 소프트웨어 개발 방식을 인프라 관리에 적용하여 오류 위험을 줄이고 배포 및 확장 속도를 높일 수 있습니다.
Ceph와 Ansible, 그리고 Ansible과 같은 도구 cephadm는 IaC의 실제 활용 사례를 잘 보여줍니다. 이러한 도구를 통해 관리자는 Ceph 클러스터의 원하는 상태를 코드로 정의할 수 있으므로 다양한 환경에서 클러스터를 더욱 쉽게 배포, 관리 및 확장할 수 있습니다.
Ceph 오케스트레이션 도구의 간략한 역사¶
Ceph의 인기가 높아지고 클러스터가 빠르게 성장함에 따라 효과적인 오케스트레이션 도구의 필요성이 점점 더 중요해졌습니다. 지난 몇 년 동안 Ceph 클러스터의 배포 및 관리를 간소화하고 자동화하는 여러 도구가 개발되었습니다. 이러한 도구들을 간략하게 살펴보겠습니다.
ceph-deploy는 Ceph 클러스터 구축을 용이하게 하기 위해 도입된 최초의 도구 중 하나였습니다. 가벼운 명령줄 유틸리티인 이 도구를ceph-deploy통해 관리자는 MON, OSD, MGR과 같은 Ceph 데몬을 구성하는 여러 수동 단계를 자동화하여 기본 Ceph 클러스터를 빠르게 설정할 수 있었습니다.ceph-ansible은 Ceph 배포를 인기 있는 오픈소스 자동화 도구인 Ansible과 통합함으로써 중요한 진전을 이루었습니다. 이러한 접근 방식은 Infrastructure as Code(IaC) 원칙을 수용하여 관리자가 Ansible 플레이북에서 전체 Ceph 클러스터 구성을 정의할 수 있도록 했습니다.cephadm은 다음 섹션에서 자세히 다루겠지만 현재 번들로 제공되는 Ceph 오케스트레이터입니다.
Cephadm 소개¶
이전 버전과 달리, cephadm은 모든 Ceph 데몬을 Docker 또는 Podman을 사용하여 컨테이너로 배포합니다. 이러한 컨테이너화된 접근 방식은 다양한 환경에서 일관성을 보장하고 종속성 관리를 간소화하여 Ceph 클러스터의 배포, 업그레이드 및 확장을 더욱 용이하게 합니다.
Cephadm은 선언적 사양 파일을 사용하여 클러스터의 원하는 상태를 정의함으로써 Ceph 클러스터 관리 방식을 크게 개선했습니다. 이제 관리자는 전체 클러스터 구성을 미리 설명할 수 있으며, Cephadm은 클러스터가 원하는 상태와 일치하는지 지속적으로 확인합니다. 이 프로세스를 컨버전스(convergence) 라고도 합니다 .
Cephadm은 강력한 배포 기능 외에도 Ceph 대시보드와 통합되어 내장된 모니터링 및 알림을 제공하고 자동 업그레이드를 지원하므로 지금까지 Ceph 생태계에서 가장 포괄적이고 사용자 친화적인 오케스트레이션 도구입니다.
Cephadm을 사용한 Ceph 클러스터의 반복적인 자동 배포¶
현대 IT 환경에서는 개발, 테스트, 운영 등 다양한 환경에 걸쳐 스토리지 클러스터를 반복적으로 배포하고 확장해야 하는 상황이 점점 더 많아지고 있습니다. 바로 이 부분에서 Cephadm이 해결책을 제시합니다. Cephadm은 Ceph 클러스터의 배포 및 관리를 자동화하여 기존 분산 스토리지 시스템 구축 과정에서 발생하던 오류 발생 가능성이 높은 수동 프로세스를 제거합니다.
Cephadm의 선언적 접근 방식¶
cephadm의 선언적 서비스 사양 파일을 사용하면 관리자가 Ceph 클러스터의 전체 구성을 버전 관리가 가능한 재사용 가능한 단일 파일로 정의할 수 있습니다. 이 사양 파일은 OSD, 모니터, 관리자의 배치부터 파일, 블록, 개체 서비스의 설정 및 구성까지 모든 것을 설명할 수 있습니다. 이 사양 파일을 적용하면 cephadm은 클러스터를 원하는 상태에 맞게 자동으로 수렴하여 여러 배포 환경에서 일관성을 유지할 수 있습니다.
Cephadm은 Ceph 클러스터 서비스의 배포 및 수명 주기를 제공한다는 점에 유의해야 합니다. 하지만 Ceph Object Storage(RGW) 사용자 생성과 같은 특정 서비스의 모든 2일차 작업은 현재 Cephadm에서 지원하지 않습니다.
코드로서의 인프라(IaC)에 적합¶
cephadm은 코드형 인프라(IaC) 패러다임에 완벽하게 부합합니다. IaC는 인프라 구성을 소프트웨어 코드처럼 처리하여 버전 관리 시스템에 저장하고, 애플리케이션을 자동화하며, 지속적인 배포 파이프라인을 지원합니다. cephadm를 사용하면 사양 파일이 스토리지 인프라를 정의하는 코드 역할을 합니다.
예를 들어, CICD 파이프라인을 사용하여 Git과 같은 버전 제어 시스템에 cephadm 사양 파일을 저장할 수 있습니다. 클러스터 구성이 변경되면 변경 사항이 커밋되고 푸시되며, 업데이트된 사양 파일을 기반으로 Ceph 클러스터를 배포하거나 업데이트하는 자동화된 파이프라인이 트리거됩니다. 이러한 접근 방식은 배포를 간소화하고 스토리지 인프라가 애플리케이션 및 서비스 요구 사항과 항상 동기화되도록 보장합니다.
특정 cephadm 구성 변경 사항에는 해당 서비스를 다시 시작해야 하며, 변경 사항이 적용된 후 적용되도록 자동화 도구를 사용하여 조정해야 합니다.
Ceph 클러스터의 자동 배포를 제공하는 Cephadm 서비스 사양 파일 연습¶
아래는 부트스트랩 프로세스 중에 Ceph 클러스터를 완전히 배포할 수 있도록 하는 Cephadm 사양 파일의 예입니다. 이 기본 예제는 시작을 돕기 위한 것이며, 실제 운영 환경에서는 사양 파일을 추가로 사용자 지정해야 합니다.
service_type: host
hostname: ceph1
addr: 10.10.0.2
location:
root: default
datacenter: DC1
labels:
- osd
- mon
- mgr
---
service_type: host
hostname: ceph2
addr: 10.10.0.3
location:
datacenter: DC1
labels:
- osd
- mon
- rgw
---
service_type: host
hostname: ceph3
addr: 10.10.0.4
location:
datacenter: DC1
labels:
- osd
- mds
- mon
---
service_type: mon
placement:
label: "mon"
---
service_type: mgr
service_name: mgr
placement:
label: "mgr"
---
service_type: osd
service_id: all-available-devices
service_name: osd.all-available-devices
spec:
data_devices:
all: true
limit: 1
placement:
label: "osd"
---
service_type: rgw
service_id: objectgw
service_name: rgw.objectgw
placement:
count: 2
label: "rgw"
spec:
rgw_frontend_port: 8080
rgw_frontend_extra_args:
- "tcp_nodelay=1"
---
service_type: ingress
service_id: rgw.external-traffic
placement:
label: "rgw"
spec:
backend_service: rgw.objectgw
virtual_ips_list:
- 172.18.8.191/24
- 172.18.8.192/24
frontend_port: 8080
monitor_port: 1967
첫 번째 service_type은 host로, 클러스터 내 모든 호스트를 열거하며 호스트명과 IP 주소를 포함합니다. location 필드는 Ceph CRUSH 토폴로지 내 호스트의 위치를 나타내며, 이는 클러스터 전반에 걸친 데이터 배치 및 검색을 안내하는 계층적 구조입니다. 자세한 내용은 이 문서를 참조하십시오.
Cephadm은 호스트에 특정 레이블을 설정함으로써 컨테이너화된 Ceph 서비스를 원하는 노드에 효율적으로 스케줄링하고 배포할 수 있습니다. 특정 노드에 두 개 이상의 레이블이 지정되어 두 개 이상의 Ceph 서비스를 호스팅하는 경우도 있습니다. 이를 통해 리소스 분리가 보장되고 필요한 노드 수가 줄어들어 리소스 사용량이 최적화되고 운영 환경의 비용이 절감됩니다.
클러스터에 추가하는 호스트는 Ceph 클러스터에 성공적으로 가입하기 위해 구성된 일련의 필수 구성 요소가 필요합니다. 이 블로그 시리즈에서는 이러한 필수 구성 요소의 배포를 자동화하는 방법도 다룹니다.
service_type: host hostname: ceph1 addr: 10.10.0.2 location: root: default datacenter: DC1 labels: - osd - mon - mgr
그 다음으로 모니터 및 관리자 서비스 배포가 있습니다. 이들에 대해서는 배치 매개변수만 사용하는 간단한 구성을 적용합니다. 배치 매개변수를 통해 cephadm에 mon 레이블이 지정된 모든 호스트에 모니터 서비스를 배포할 수 있음을 지시합니다.
--- service_type: mon placement: label: "mon" --- service_type: mgr service_name: mgr placement: label: "mgr"
다음으로 OSD 서비스 유형이 있습니다. cephadm의 OSD 서비스 유형은 매우 유연합니다: 상상할 수 있는 거의 모든 OSD 구성을 정의할 수 있습니다. OSD 서비스 사양에 대한 자세한 내용은 이 문서를 참조하세요
이 예시에서는 가능한 가장 간단한 접근법을 사용합니다: 배치 매개변수를 다시 활용하여 시스템에 사용 가능한 모든 여유/사용 가능한 미디어 장치를 OSD로 사용하도록 Cephadm에 지시합니다. OSD 장치는 osd 레이블이 있는 노드에만 구성됩니다.
다음 섹션에서는 메타데이터 서비스(MDS) 데몬을 포함한 Ceph 공유 파일 시스템을 배포하도록 cephfs 서비스를 구성합니다. 모든 서비스 사양 구성 옵션은 이 문서를 참조하세요.
마지막으로 Ceph 객체 게이트웨이(RGW) 서비스를 설정하기 위해 rgw 서비스 유형을 구성합니다. RGW 서비스는 클라이언트를 위한 S3 및 Swift 호환 HTTP RESTful 엔드포인트를 제공합니다. 이 예시에서 배치 섹션에서는 RGW 서비스 개수를 2개로 설정합니다. 이는 Cephadm 스케줄러가 rgw 레이블이 설정된 사용 가능한 두 호스트에 두 개의 RGW 데몬을 스케줄링하도록 의미합니다. tcp_nodelay=1 프론트엔드 옵션은 Nagle 혼잡 제어를 비활성화하여 소형 객체에 대한 RGW 작업의 지연 시간을 개선할 수 있습니다.
--- service_type: mds service_id: cephfs Placement: count: 2 label: "mds" --- service_type: rgw service_id: objectgw service_name: rgw.objectgw placement: count: 2 label: "rgw" rgw_realm: rgw_zone: rgw_zonegroup: spec: rgw_frontend_port: 8080 rgw_frontend_extra_args: - "tcp_nodelay=1"
Ceph는 또한 haproxy와 keepalived를 기반으로 한 기본 제공 로드 밸런서인 인그레스 서비스를 제공합니다. 이 용어는 쿠버네티스 관리자에게 익숙할 수 있습니다. 이 예시에서는 인그레스 서비스를 사용하여 클러스터 내에서 실행 중인 RGW 데몬들 간에 클라이언트 S3 요청을 분산함으로써 객체 서비스에 고가용성(HA)과 로드 밸런싱을 제공합니다. 자세한 정보는 여기에서 확인할 수 있습니다.
rgw 레이블 서비스를 사용하여 haproxy/keepalived 데몬을 RGW 서비스와 함께 배치합니다. 그런 다음 virtual_ips_list 사양 매개변수를 통해 클라이언트가 S3 엔드포인트 API에 액세스하는 데 사용할 플로팅 가상 IP 주소(VIP) 목록을 설정합니다.
---
service_type: ingress
service_id: rgw.external-traffic
placement:
label: "rgw"
spec:
backend_service: rgw.objectgw
virtual_ips_list:
- 172.18.8.191/24
- 172.18.8.192/24
frontend_port: 8080
monitor_port: 1967
모든 서비스 사양을 정의하고 준비한 후에는, 해당 사양 파일을 cephadm 부트스트랩 명령어에 전달하여 파일에 명시된 대로 클러스터를 배포하고 구성해야 합니다. 다음은 –apply-spec 매개변수를 사용하여 클러스터 사양 파일을 전달하는 부트스트랩 명령어의 예시입니다:
# cephadm bootstrap \
--registry-json /root/registry.json \
--dashboard-password-noupdate \
--ssh-user=cephadm \
--mon-ip \
--apply-spec /root/cluster-spec.yaml
다음 단계¶
이 시리즈의 다음 편에서는 Jinja2(J2) 템플릿과 Ansible을 cephadm 서비스 사양 파일과 함께 활용하는 방법을 살펴보겠습니다. 이 접근 방식은 Ceph 클러스터 배포를 위한 Infrastructure as Code(IaC) 프레임워크를 구축하고, Git을 Ceph 구성 관리의 단일 소스로 사용하여 간소화된 CICD(Continuous Delivery) 파이프라인을 구축하는 방법을 보여줍니다.
각주¶
저자는 이 게시물을 작성할 수 있도록 시간을 지원해 준 IBM에 감사드리고 싶습니다.
