Kubernetes

⚓ k8s에서 Minio+Ceph의 이중 복제를 SeaweedFS+Longhorn으로 해결

팬더17 2026. 7. 19. 16:29

이중복제 발생 : Minio + Ceph RBD 

k8s에서 Minio를 특정 노드에 고정돼서 사용하고 싶지 않으면, Ceph를 사용해서 Ceph의 RBD 볼륨을 PVC로 사용해야한다.

그래서 Minio + local PVC가 아니라 이중복제가 발생한다. Minio도 자체적으로 EC를 진행해서 PVC에 데이터 조각을 분산해서 저장하고 패리티 분산도 진행한다. 그런데 minio는 Ceph가 데이터를 복제하는 것을 모르기에 Ceph가 또 물리 디스크의 데이터를 3중 복제하면서 이중복제가 발생한다.

 

Minio 공식문서에서도 direct-attached 로컬 디스크(JBOD) 위에 배포하는것을 권장한다. 물리 디스크를 그대로 물려서 Minio만의 복제 로직만 동작하게 하는 것이다.

 

그래서 이것을 해결하고자 Minio의 Statfulset + local PV를 사용할 수 있지만, 이러면 노드가 죽었을 때 S3의 패리티 수 이상만큼 장애 발생 시 서비스가 중단되며, 빠르게 노드를 수동으로 복구해줘야한다는 단점이 있다. 즉, k8s의 stateless의 장점을 충분히 활용하지 못하는 것이다.

 

이중복제 문제점 : Minio + Ceph RBD

 

1. 디스크 낭비 : MinIO가 1.5배(4+2 EC) 복제를 하고 Ceph 3중 복제를 하기에 실질 저장 공간 배율은 3 × 1.5 = 4.5TB가 필요하다. 1TB의 데이터를 저장하기 위해서 물리 디스크가 4.5TB 필요한 것이다. 만약 Minio EC 복제 설정 값을 더 크게하면 오버헤드가 더 커진다. 예를 들어서 8+4EC도 있다.

 

2. 네트워크 오버헤드 및 레이어 과다 : Ceph 자체도 RADOS → OSD → PG 매핑 등 내부 레이어가 이미 많은 시스템인데, 그 위에 MinIO의 분산 로직까지 얹히니 전체 I/O 경로가 불필요하고, 하나의 쓰기 요청이 두 번의 독립적인 분산 복제 프로토콜을 거치게된다.

 

3. 설계 철학 충돌

Minio와 Ceph 둘 다 내가 최종 스토리지 계층으로 데이터 내구성을 책임진다는 전제여서 서로의 위/아래에 쌓이는 걸 권장하지 않음 (Minio 공식문서에 적혀 있는 내용이랑 동일한 말)

이중복제 해결 : Longhorn + SeaweedFS

Minio는 분산 모드로 띄우면 무조건 EC 복제를 하기 때문에 끌 수가 없다. 그런데 SeaweedFS는 볼륨(collection) 단위로 replication 설정을 조절할 수 있어서 000으로 설정하면 데이터 복제를 끌 수 있다. 그러면 Longhorn 한 곳에서만 3중 복제를 하기 때문에 오버헤드를 줄일 수 있다. 그러면서 k8s의 stateless인 장점인 PVC를 그대로 사용할 수 있다. 노드가 죽어도 pod가 다른 노드로 띄울 수 있고 PVC도 그대 마운트하면 되기 때문이다. 그래서 노드 장애 시 어느 정도 시간을 벌 수 있다.

 

정리하자면, Minio + Ceph RDB가 각각 자체 복제를 하기에, SeaweedFS 쪽 복제를 의도적으로 끄고 Longhorn 3중 복제만 유지한다.