왜 RAID만으로는 부족한가
오브젝트 스토리지를 운영하다 보면 디스크 장애는 예외가 아니라 상수다. 전통적인 하드웨어 RAID는 컨트롤러 종속성이 크고, 리빌드 중 두 번째 디스크가 죽으면 볼륨 전체가 날아간다. 또한 RAID는 비트 로트(silent data corruption)를 탐지하지 못한다. MinIO는 애플리케이션 레벨에서 이레이저 코딩(Erasure Coding)을 수행해 디스크·노드 단위 장애를 견디고, 읽기 시점마다 체크섬을 검증한다.
이레이저 코딩 기본 개념
MinIO는 Reed-Solomon 코드를 사용한다. 하나의 오브젝트를 데이터 샤드(k)와 패리티 샤드(m)로 나눠 여러 드라이브에 분산 저장한다. 전체 n = k + m 중에서 최소 k개의 샤드만 살아있으면 원본을 복원할 수 있다. 즉 m개까지의 드라이브 손실을 허용한다.
기본 정책은 EC:M/2 수준으로, 세트(erasure set) 크기의 절반을 패리티로 둘 수도 있다. 패리티가 많을수록 내구성은 오르지만 사용 가능 용량은 줄어든다.
| 구성 (data:parity) | 허용 손실 | 공간 효율 |
|---|---|---|
| 4:2 | 드라이브 2개 | 66% |
| 6:2 | 드라이브 2개 | 75% |
| 8:4 | 드라이브 4개 | 50% |
배포 시 패리티 설계
MinIO는 서버 풀 안에서 드라이브를 자동으로 이레이저 세트로 묶는다. 세트 크기는 4~16 사이에서 결정되며, 스토리지 클래스로 패리티 수를 조정한다. 프로덕션에서는 노드 단위 장애까지 고려해 세트가 여러 호스트에 분산되도록 드라이브 수를 맞추는 것이 핵심이다.
export MINIO_STORAGE_CLASS_STANDARD=EC:4
export MINIO_STORAGE_CLASS_RRS=EC:2
# 4개 노드 x 4 드라이브 = 16 드라이브, 세트 크기 16, 패리티 4
minio server \
http://node{1...4}/mnt/disk{1...4} \
--console-address ":9001"버킷별로 오브젝트 헤더 x-amz-storage-class에 REDUCED_REDUNDANCY를 지정하면 RRS(EC:2) 정책이 적용되어 덜 중요한 데이터의 공간 효율을 높일 수 있다.
디스크 장애 감지와 상태 확인
드라이브가 죽으면 MinIO는 해당 샤드를 건너뛰고 남은 샤드로 읽기를 계속 처리한다. 장애 여부는 힐(heal) 상태와 관리 API로 확인한다.
# 서버·드라이브 상태 요약
mc admin info myminio
# 특정 버킷의 힐 진행 상황
mc admin heal -r myminio/mybucket --verbose
# 드라이브 온라인/오프라인 카운트만 추출
mc admin info myminio --json \
| jq '.info.servers[] | {endpoint, drives: (.drives | length),
offline: [.drives[] | select(.state!="ok")] | length}'디스크 교체와 힐링 절차
물리 디스크를 교체할 때는 새 디스크를 이전과 동일한 마운트 경로에 빈 상태로 붙여야 한다. MinIO는 마운트 지점을 기준으로 세트를 인식하므로, 포맷만 하고 파일시스템을 마운트한 뒤 프로세스를 재시작하면 자동으로 힐링이 시작된다.
# 1) 새 디스크 파일시스템 생성 (XFS 권장)
mkfs.xfs -f /dev/sdd
# 2) 원래 경로로 마운트
mount /dev/sdd /mnt/disk4
echo '/dev/sdd /mnt/disk4 xfs defaults,noatime 0 2' >> /etc/fstab
# 3) 해당 노드의 minio 재시작 후 힐 확인
systemctl restart minio
mc admin heal -r --recursive myminio힐링은 백그라운드에서 점진적으로 진행되며, 스캔·복원 속도는 mc admin config set myminio heal로 조정한다.
운영 시 주의점
첫째, 힐링 중에는 IO 부하가 올라가므로 야간이나 트래픽이 낮은 시간대에 대량 복원을 유도하는 편이 안전하다. 둘째, 절대 새 디스크에 기존 데이터를 수동으로 복사해 넣지 마라. 세트 일관성이 깨진다. 셋째, 세트 크기 절반 이상의 드라이브가 동시에 죽으면 해당 세트의 데이터는 복구 불가이므로, 세트가 여러 노드에 걸치도록 초기 토폴로지를 반드시 검증해야 한다. 넷째, EC는 논리적 삭제나 실수로 인한 덮어쓰기는 막지 못한다. 버전 관리와 오브젝트 락, 그리고 별도 사이트로의 복제를 병행해야 진짜 내구성이 확보된다.
정리
이레이저 코딩은 하드웨어 RAID보다 유연하고 비트 로트까지 탐지하지만, 만능은 아니다. 패리티 설계는 용량과 내구성의 트레이드오프이며, 세트의 노드 분산과 힐링 운영, 그리고 백업·복제 전략까지 함께 설계할 때 비로소 신뢰할 수 있는 스토리지가 된다.