GlusterFS vs DRBD: 두 기술은 모두 네트워크를 통해 데이터를 복제하지만 대체 관계는 아닙니다. GlusterFS는 여러 brick 위에 파일 네임스페이스를 제공하는 분산 파일시스템이고, DRBD는 파일시스템 아래에서 블록 장치를 복제합니다. 먼저 애플리케이션이 필요한 접근 의미를 정하지 않으면 잘못된 제품을 고르게 됩니다.
이 글은 ‘파일 서버면 GlusterFS, 데이터베이스면 DRBD’처럼 단순화하지 않습니다. 쓰기 완료 시점, 동시 마운트, 네트워크 분할, quorum, fencing, heal, 장애 조치 책임을 비교하고 실제 상태 점검 명령과 선택 체크리스트를 제공합니다.
GlusterFS vs DRBD: 아키텍처 차이
| 항목 | GlusterFS Replica | DRBD 9 |
|---|---|---|
| 복제 계층 | 파일·디렉터리와 메타데이터 | 블록 장치의 변경 블록 |
| I/O 경로 | 클라이언트/FUSE가 여러 brick과 통신 | 로컬 블록 I/O를 커널 모듈이 peer에 전달 |
| 상위 파일시스템 | GlusterFS 자체가 공유 네임스페이스 제공 | ext4·XFS 또는 조건부 클러스터 파일시스템 필요 |
| 일반 접근 모델 | 여러 클라이언트가 동시 마운트 | single-primary Active-Passive가 대표적 |
| 확장 방식 | replica set을 분산해 용량·클라이언트 확장 | DRBD 9는 여러 peer 복제를 지원하지만 분산 파일시스템은 아님 |
| 복구 단위 | 파일별 heal과 split-brain 판정 | dirty bitmap 기반 블록 재동기화 |
한 문장으로 구분하기
- 여러 서버가 같은 파일 트리를 동시에 읽고 써야 하면 GlusterFS의 공유 파일 의미를 검토합니다.
- 한 서비스의 로컬 블록 장치를 다른 노드로 넘겨 이어서 실행하려면 DRBD single-primary를 검토합니다.
- 두 경우 모두 복제는 백업이 아니며 삭제·랜섬웨어·논리 오류도 복제될 수 있습니다.
GlusterFS vs DRBD: 쓰기 완료와 지연
GlusterFS replica volume은 클라이언트가 AFR 계층을 통해 replica set의 brick에 파일 작업을 전달합니다. 장애 뒤에는 heal이 필요할 수 있고, 서로 다른 분할에서 같은 파일이 바뀌면 어느 복사본이 정본인지 자동 판단하지 못하는 split-brain이 생길 수 있습니다. replica 수만 늘린다고 quorum 정책이 자동으로 완성되지는 않습니다.
DRBD의 Protocol C는 로컬과 원격 디스크 쓰기가 확인된 뒤 상위 계층에 완료를 반환하는 동기 복제입니다. 단일 노드 손실에 대한 RPO를 줄이는 대신 왕복 지연과 두 스토리지의 쓰기 지연이 애플리케이션에 반영됩니다. Protocol A·B는 완료 기준이 다르므로 이름만 보고 ‘DRBD는 항상 동기식’이라고 단정하면 안 됩니다.
GlusterFS vs DRBD: 동시 접근의 정확한 의미
GlusterFS는 여러 클라이언트가 볼륨을 마운트하도록 설계됐지만 brick의 하부 디렉터리를 애플리케이션이 직접 읽고 쓰는 방식은 지원되는 공유 접근 경로가 아닙니다. 반드시 Gluster 클라이언트 프로토콜을 거쳐야 AFR의 일관성·heal 메타데이터가 유지됩니다.
DRBD single-primary에서는 ext4나 XFS 같은 일반 파일시스템을 한 Primary에서만 마운트하는 구성이 표준적입니다. DRBD는 dual-primary도 지원하지만 동시 마운트에는 GFS2·OCFS2 같은 분산 잠금 기반 클러스터 파일시스템과 fencing이 필요합니다. 일반 XFS를 두 노드에서 동시에 마운트하면 파일시스템이 손상될 수 있습니다.
GlusterFS vs DRBD: quorum과 split-brain
replica 2는 네트워크 분할에서 일관성과 가용성을 동시에 최대화할 수 없습니다. Gluster 공식 문서는 replica 3 또는 arbiter volume과 client quorum을 split-brain 위험을 줄이는 방식으로 설명합니다. arbiter는 전체 데이터의 세 번째 복사본이 아니라 메타데이터를 이용해 어느 쪽이 정본인지 판정하는 투표 역할을 합니다.
GlusterFS 읽기 전용 상태 점검
sudo gluster peer status
sudo gluster volume list
sudo gluster volume info <VOLNAME>
sudo gluster volume status <VOLNAME> detailheal과 split-brain 목록 확인
sudo gluster volume heal <VOLNAME> info summary
sudo gluster volume heal <VOLNAME> info
sudo gluster volume heal <VOLNAME> info split-brainsplit-brain 해결에서 크기나 최신 시간만 보고 source brick을 고르면 정상 데이터를 덮어쓸 수 있습니다. 애플리케이션 소유자와 정본을 판정하고 백업을 확보한 뒤 파일별 복구 절차를 적용합니다.
quorum 관련 현재 옵션 확인
sudo gluster volume get <VOLNAME> cluster.quorum-type
sudo gluster volume get <VOLNAME> cluster.quorum-count
sudo gluster volume get <VOLNAME> cluster.server-quorum-type
sudo gluster volume get <VOLNAME> all | grep -Ei 'quorum|arbiter'DRBD 9의 역할·프로토콜·quorum
DRBD 리소스는 Primary 또는 Secondary 역할을 갖습니다. single-primary가 일반적인 HA 패턴이지만 DRBD 9는 두 노드 전용이 아니며 한 리소스를 여러 호스트에 복제할 수 있습니다. 다만 노드가 늘면 연결, 메타데이터, 재동기화와 quorum 설계도 복잡해지므로 ‘지원 가능’과 ‘운영에 적합’을 구분해야 합니다.
DRBD 상태와 복제 진행률 확인
sudo drbdadm status
sudo drbdsetup status --statistics
cat /proc/drbd
journalctl -k -b | grep -i drbd설정 변경 전 dry-run
sudo drbdadm -d adjust <RESOURCE>
sudo drbdadm dump <RESOURCE>DRBD는 surviving Secondary를 스스로 Primary로 승격해 애플리케이션을 시작하지 않습니다. Pacemaker, DRBD Reactor 또는 엄격한 수동 절차가 서비스 중지, 파일시스템 언마운트, 역할 전환, 마운트, VIP·서비스 시작 순서를 관리해야 합니다.
quorum과 역할 상태 확인
sudo drbdsetup status --verbose --statistics
sudo drbdadm status <RESOURCE>
# Pacemaker를 함께 쓴다면
sudo crm_mon -1ArfGlusterFS vs DRBD: 장애 조치가 다른 이유
| 단계 | GlusterFS | DRBD |
|---|---|---|
| 장애 감지 | 클라이언트가 brick 연결 실패 감지 | peer 연결·디스크 상태 변경 감지 |
| 쓰기 허용 판단 | AFR client quorum과 volume 상태 | 역할, disk state, DRBD quorum |
| 데이터 경로 전환 | 클라이언트가 살아 있는 brick과 통신 | cluster manager가 승격·마운트·서비스 시작 |
| 복구 | 파일 단위 heal 및 split-brain 판정 | 블록 재동기화와 역할 재편입 |
| 필수 외부 요소 | 정상적인 복수 volfile server, 모니터링 | 대개 cluster manager와 fencing |
즉 GlusterFS의 경로 회피와 DRBD의 서비스 failover는 같은 ‘자동 전환’이 아닙니다. 전자는 분산 파일 클라이언트의 I/O 경로이고, 후자는 블록 장치 위의 파일시스템과 애플리케이션까지 순서대로 이동시키는 클러스터 작업입니다.
GlusterFS vs DRBD: 워크로드별 선택
| 요구사항 | 우선 검토 | 판단 이유와 주의점 |
|---|---|---|
| 여러 웹 노드가 같은 업로드 파일 공유 | GlusterFS | 동시 파일 접근에 적합하지만 작은 파일 성능과 heal을 검증 |
| 로컬 파일시스템을 쓰는 단일 DB의 Active-Passive | DRBD | Protocol C와 cluster manager를 검토하고 DB 고유 복제와도 비교 |
| 수평 확장 오브젝트 스토리지 | 둘 다 재검토 | S3 호환 오브젝트 스토리지가 접근 의미에 더 적합할 수 있음 |
| VM 라이브 마이그레이션 | 조건부 DRBD | dual-primary·클러스터 FS·fencing 또는 전용 가상화 통합 필요 |
| 읽기 전용 대용량 배포물 | GlusterFS 또는 오브젝트 스토리지 | 캐시·CDN·배포 파이프라인도 함께 비교 |
| 백업과 장기 보존 | 둘 다 단독으로 부족 | 버전·불변성·오프사이트 복구가 있는 별도 백업 필요 |
선택 전에 답할 질문
- 여러 노드가 동시에 같은 파일시스템을 써야 합니까, 한 노드만 써도 됩니까?
- 허용 가능한 RPO와 RTO는 얼마이며 동기 복제 지연을 감당할 수 있습니까?
- 네트워크 분할 때 가용성과 일관성 중 어느 쪽을 우선합니까?
- quorum과 fencing을 위한 독립된 세 번째 투표 경로가 있습니까?
- 정상 복제, degraded 쓰기, 재동기화 중 성능을 각각 측정했습니까?
- 삭제·손상·랜섬웨어에 대비한 독립 백업과 실제 복구 테스트가 있습니까?
운영 점검 체크리스트
- 복제 링크를 서비스 트래픽과 분리하고 지연·손실·대역폭을 모니터링합니다.
- 정상 상태뿐 아니라 한 노드 장애, 링크 단절, 재부팅, 재동기화 중 서비스 동작을 시험합니다.
- GlusterFS는 heal backlog와 split-brain, DRBD는 role·disk·connection·quorum 상태를 경보화합니다.
- 운영자가 임의로 양쪽을 쓰기 가능하게 만드는 force 절차를 평상시 runbook에서 제거합니다.
- 복제와 별도로 보존 기간이 있는 불변·오프사이트 백업을 운영하고 복원을 정기 검증합니다.
공식 문서와 관련 가이드
- GlusterFS 볼륨 구성 공식 문서
- GlusterFS heal·split-brain 공식 문서
- GlusterFS arbiter·quorum 공식 문서
- DRBD 9 공식 사용자 가이드
- GlusterFS 기존 구축 가이드
- DRBD·Pacemaker 구축 가이드
정리
GlusterFS vs DRBD: 선택의 핵심은 제품 이름이 아니라 파일 공유와 블록 failover 중 필요한 접근 의미입니다. GlusterFS는 파일 단위 분산 네임스페이스와 heal을, DRBD는 블록 복제와 명시적인 역할 전환을 제공합니다. 어느 쪽이든 quorum·fencing·관측·독립 백업을 포함한 전체 장애 모델로 설계해야 고가용성이라는 목표를 달성할 수 있습니다.
