GlusterFS 구축. 여러 서버의 디스크를 하나의 파일시스템처럼 제공하는 작업입니다. 그러나 단순히 패키지를 설치하고 두 노드를 묶는 것만으로 고가용성이 완성되지는 않습니다. 복제 수, quorum, 장애 도메인, 백업, 패키지 지원 기간까지 함께 설계해야 데이터 손실과 split-brain 위험을 줄일 수 있습니다.

이 글은 세 서버에 전체 데이터를 복제하는 Replica 3 실습을 기준으로 GlusterFS 구축 순서를 설명합니다. 모든 명령과 설정 예시는 코드 블록으로 분리했으며, 각 단계마다 확인 명령과 중단 조건을 넣었습니다. 운영 환경에서는 아래 예시를 그대로 붙여 넣기 전에 장치명, 네트워크 대역, 패키지 공급자의 지원 범위를 먼저 검증하십시오.

GlusterFS 구축 구조와 Replica 3 파일 복제 및 quorum 흐름
GlusterFS는 파일 단위로 여러 brick에 복제하며, Replica 3은 세 데이터 사본의 과반 판단을 활용할 수 있습니다.

GlusterFS 구축 전에 확인할 현재 버전과 지원 범위

공식 다운로드 디렉터리에서 확인되는 최신 커뮤니티 릴리스는 11.1입니다. 다만 공식 릴리스 정책은 주 버전의 유지 기간을 약 12개월로 설명하므로, 2026년 신규 운영 시스템에 11.1을 무조건 권장할 수는 없습니다. 배포판 또는 상용 공급자가 보안 업데이트를 제공하는지 확인하고, 지원 경로가 없다면 Ceph·NFS HA·클라우드 파일 서비스 같은 대안도 함께 평가해야 합니다. 이 글의 명령은 검증된 EL9 계열 저장소가 이미 준비되었다는 전제의 실습 예시입니다.

GlusterFS 구축 예시 토폴로지

역할 호스트 관리 IP brick 경로
Gluster 서버 1 gluster01 10.20.30.11 /bricks/brick1/gv0
Gluster 서버 2 gluster02 10.20.30.12 /bricks/brick1/gv0
Gluster 서버 3 gluster03 10.20.30.13 /bricks/brick1/gv0
클라이언트 client01 10.20.30.21 /mnt/gv0
  • 세 서버는 서로 다른 장애 도메인에 두고 시간 동기화와 정방향·역방향 이름 해석을 확인합니다.
  • 운영체제와 brick 데이터는 별도 디스크 또는 별도 논리 볼륨으로 분리합니다.
  • Replica 3은 세 개의 전체 데이터 사본을 저장하므로 원본 데이터의 약 세 배 용량이 필요합니다.
  • 복제는 삭제·암호화·애플리케이션 오류도 전파하므로 별도 백업이 반드시 필요합니다.

모든 노드에서 이름 해석과 시간 동기화 확인

getent hosts gluster01 gluster02 gluster03
chronyc tracking
timedatectl status

예시 호스트 매핑

10.20.30.11  gluster01
10.20.30.12  gluster02
10.20.30.13  gluster03

GlusterFS 구축 1단계: 전용 brick 디스크 준비

다음 단계는 장치의 기존 데이터를 지울 수 있습니다. 먼저 각 서버에서 실제 장치명과 마운트 여부를 확인하고, 백업 및 변경 승인을 확보하십시오. 예시의 장치명은 /dev/sdb이며 환경에 맞게 바꿔야 합니다.

lsblk -f
findmnt --real
sudo wipefs --no-act /dev/sdb
아래 mkfs 명령은 대상 장치의 기존 파일시스템을 파괴합니다. lsblk·findmnt·wipefs –no-act 결과를 사람이 확인하기 전에는 실행하지 마십시오.
sudo mkfs.xfs -f -i size=512 /dev/sdb
sudo mkdir -p /bricks/brick1
sudo blkid /dev/sdb

blkid에서 확인한 UUID를 사용해 각 서버의 /etc/fstab에 다음과 같은 항목을 추가합니다.

UUID=<각-서버의-실제-UUID> /bricks/brick1 xfs defaults,noatime 0 2
sudo mount -a
findmnt /bricks/brick1
df -hT /bricks/brick1
sudo mkdir -p /bricks/brick1/gv0

GlusterFS 구축 2단계: 패키지와 glusterd 서비스 확인

EL9 계열에서는 저장소가 glusterfs-server 패키지를 실제로 제공하는지 먼저 조회합니다. 패키지가 없거나 출처·서명이 불명확하면 임의의 오래된 RPM을 내려받지 말고 여기서 중단하십시오.

sudo dnf repolist
sudo dnf repoquery --info glusterfs-server
sudo dnf install -y glusterfs-server glusterfs-fuse
rpm -q glusterfs-server glusterfs-fuse
glusterfs --version
sudo systemctl enable --now glusterd
sudo systemctl --no-pager --full status glusterd
sudo journalctl -u glusterd -b --no-pager | tail -n 80

GlusterFS 구축 3단계: 방화벽은 저장소 네트워크로 제한

Gluster 10부터 brick 포트는 설정된 base-port와 max-port 범위에서 무작위로 선택됩니다. 관리 포트 24007~24008과 실제로 사용할 brick 포트 범위를 스토리지 서브넷에만 허용하십시오. 아래 범위는 예시이며, brick 수와 glusterd 설정을 맞춘 뒤 변경 창에서 적용해야 합니다.

sudo grep -E 'base-port|max-port' /etc/glusterfs/glusterd.vol
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --permanent --zone=internal \
  --add-rich-rule='rule family=ipv4 source address=10.20.30.0/24 port port=24007-24008 protocol=tcp accept'
sudo firewall-cmd --permanent --zone=internal \
  --add-rich-rule='rule family=ipv4 source address=10.20.30.0/24 port port=49152-49200 protocol=tcp accept'
sudo firewall-cmd --reload
sudo firewall-cmd --zone=internal --list-all
SELinux나 firewalld를 끄는 방식으로 문제를 우회하지 마십시오. 정책 차단이 의심되면 감사 로그와 설치 패키지가 제공하는 SELinux 정책을 확인하고, 허용 범위는 Gluster 노드와 클라이언트 네트워크로 제한합니다.

GlusterFS 구축 4단계: trusted storage pool 구성

gluster01에서 나머지 두 서버를 probe하고, 호스트 이름이 일관되게 기록되도록 gluster02에서도 gluster01을 한 번 probe합니다. 모든 peer가 Connected가 되기 전에는 볼륨을 만들지 않습니다.

# gluster01에서 실행
sudo gluster peer probe gluster02
sudo gluster peer probe gluster03
sudo gluster peer status
sudo gluster pool list
# gluster02에서 실행
sudo gluster peer probe gluster01
sudo gluster peer status

GlusterFS 구축 5단계: Replica 3 볼륨 생성과 검증

Replica 3은 파일을 세 brick에 복제합니다. 단순 distributed volume은 용량은 늘지만 복제본이 없어 한 brick 장애가 해당 파일의 손실로 이어질 수 있으므로, 고가용성을 의도했다면 volume create 출력의 Type과 brick 배열을 반드시 확인합니다.

sudo gluster volume create gv0 replica 3 transport tcp \
  gluster01:/bricks/brick1/gv0 \
  gluster02:/bricks/brick1/gv0 \
  gluster03:/bricks/brick1/gv0

sudo gluster volume info gv0
sudo gluster volume start gv0
sudo gluster volume status gv0 detail

볼륨을 시작한 뒤 세 brick이 모두 Online인지 확인합니다. force 옵션은 잘못된 경로와 토폴로지 경고까지 무시할 수 있으므로, 원인을 이해하지 못한 상태에서는 사용하지 않습니다.

6. 클라이언트 마운트와 재부팅 검증

클라이언트에는 glusterfs-fuse를 설치합니다. 첫 volfile 서버가 응답하지 않을 때를 대비해 다른 두 서버를 backup-volfile-servers로 지정하되, 이 옵션이 데이터 복제 자체를 대신하는 것은 아닙니다.

sudo dnf install -y glusterfs-fuse
sudo mkdir -p /mnt/gv0
sudo mount -t glusterfs gluster01:/gv0 /mnt/gv0 \
  -o backup-volfile-servers=gluster02:gluster03
findmnt /mnt/gv0
df -hT /mnt/gv0

재부팅 후 자동 마운트가 필요하면 클라이언트의 /etc/fstab에 다음 항목을 추가합니다.

gluster01:/gv0 /mnt/gv0 glusterfs defaults,_netdev,backup-volfile-servers=gluster02:gluster03 0 0
sudo umount /mnt/gv0
sudo mount -a
findmnt /mnt/gv0
sudo touch /mnt/gv0/.mount-test
stat /mnt/gv0/.mount-test

7. 쓰기·복제·장애 복구 시험

운영 데이터를 올리기 전에 별도 테스트 파일로 기본 쓰기와 복제를 확인합니다. brick 경로를 애플리케이션이 직접 읽거나 쓰면 Gluster 메타데이터를 우회하므로, 클라이언트는 반드시 Gluster 마운트 지점을 사용해야 합니다.

date -Is | sudo tee /mnt/gv0/healthcheck.txt
sha256sum /mnt/gv0/healthcheck.txt
sudo gluster volume status gv0
sudo gluster volume heal gv0 info summary

계획된 장애 시험은 백업과 복구 계획을 확인한 유지보수 창에서 수행합니다. 한 노드를 격리한 동안 테스트 파일을 추가하고, 노드가 복귀한 뒤 heal 대기 항목이 0으로 수렴하는지 확인합니다. 과반을 잃은 상태에서 쓰기를 강제로 허용하거나 여러 분할 구간에 동시에 쓰지 마십시오.

sudo gluster peer status
sudo gluster volume status gv0 detail
sudo gluster volume heal gv0 info summary
sudo gluster volume heal gv0 info
sudo gluster volume heal gv0 info split-brain

8. heal과 split-brain을 안전하게 처리

heal 대기 항목은 자동 복구 대상이지만, split-brain은 Gluster가 어느 복사본을 정본으로 선택해야 할지 판단하지 못하는 상태입니다. 최신 수정 시간이나 큰 파일을 무조건 정본으로 고르면 정상 데이터를 덮어쓸 수 있습니다. 먼저 애플리케이션 쓰기를 중지하고 백업을 만든 뒤 파일 의미와 체크섬을 비교해야 합니다.

sudo gluster volume heal gv0 info split-brain
sudo getfattr -d -m . -e hex /bricks/brick1/gv0/<문제-파일>
sudo stat /bricks/brick1/gv0/<문제-파일>
sudo sha256sum /bricks/brick1/gv0/<문제-파일>

정본 brick을 사람과 애플리케이션 담당자가 확인한 뒤에만 source-brick 방식으로 해당 파일을 복구합니다. 아래 명령의 호스트·brick·파일 경로는 실제 확인 결과로 바꿉니다.

sudo gluster volume heal gv0 split-brain \
  source-brick gluster01:/bricks/brick1/gv0 /<문제-파일>

sudo gluster volume heal gv0 info split-brain
sudo gluster volume heal gv0 info summary
latest-mtime 또는 bigger-file 정책은 편리하지만 데이터 의미를 보장하지 않습니다. 데이터베이스 파일·가상 머신 이미지처럼 애플리케이션 정합성이 필요한 파일은 서비스를 중지하고 해당 제품의 복구 절차를 우선 적용하십시오.

9. 로그와 상태를 함께 보는 장애 진단

마운트 오류만 보고 서버를 재시작하기 전에 peer, volume, brick 포트, heal, 용량, inode, 로그를 같은 시점에 수집합니다. 특히 /var/lib/glusterd가 가득 차면 관리 데몬이 비정상 동작할 수 있습니다.

sudo gluster pool list
sudo gluster volume info gv0
sudo gluster volume status gv0 detail
sudo gluster volume heal gv0 info summary
df -hT /var/lib/glusterd /bricks/brick1
df -i /var/lib/glusterd /bricks/brick1
sudo ss -lntp | grep -E '24007|24008|4915[2-9]|49200'
sudo journalctl -u glusterd -b --no-pager | tail -n 200

heal 명령 자체가 실패하면 glfsheal 로그와 해당 brick 로그를 확인합니다. 로그 경로와 프로세스 포트는 버전과 패키징에 따라 다를 수 있으므로 volume status 결과와 대조하십시오.

sudo ls -1 /var/log/glusterfs/
sudo tail -n 200 /var/log/glusterfs/glfsheal-gv0.log
sudo find /var/log/glusterfs/bricks -maxdepth 1 -type f -name '*.log' -print

10. 운영 체크리스트

  1. 패키지 공급자의 보안 지원 기간과 업그레이드 경로를 문서화합니다.
  2. 세 서버를 독립된 전원·랙·네트워크 장애 도메인에 배치합니다.
  3. 관리 포트와 brick 포트를 필요한 소스 네트워크에만 허용하고 SELinux를 유지합니다.
  4. peer·brick·heal·split-brain·용량·inode·지연 시간을 지속해서 관측합니다.
  5. 삭제와 랜섬웨어에 대비한 별도 백업을 만들고 정기적으로 복원 시험을 수행합니다.
  6. 노드 교체, 패키지 업그레이드, split-brain 정본 선정 절차를 변경 전에 연습합니다.

매일 또는 모니터링 시스템에서 수집할 최소 항목

sudo gluster peer status
sudo gluster volume status gv0
sudo gluster volume heal gv0 info summary
df -P /bricks/brick1
df -Pi /bricks/brick1

함께 읽을 글

정리

안전한 GlusterFS 구축. 핵심은 명령의 개수가 아니라 실패 조건을 먼저 설계하는 데 있습니다. Replica 3으로 과반 판단이 가능한 토폴로지를 만들고, 전용 brick·제한된 방화벽·일관된 이름 해석·상태 검증·heal 관측을 한 흐름으로 운영해야 합니다. 여기에 독립 백업과 복원 시험, 지원되는 패키지 경로가 더해져야 비로소 운영 가능한 파일 서비스가 됩니다.