cola16k

CephFS를 서버의 로컬 디렉터리처럼 연결해 쓰면 애플리케이션 구성이 단순해집니다. 대신 부팅 때 확인할 순서가 생깁니다. 로컬 디스크가 먼저 올라와야 하고, 네트워크를 통해 Ceph에 도달할 수 있어야 하며, 그 뒤에 애플리케이션이 해당 경로를 사용해야 합니다.

수동으로 마운트하면 되는데 부팅 과정에서는 실패하는 상황이라면, 마운트 옵션뿐 아니라 언제 마운트를 시도하는지도 살펴볼 필요가 있습니다. 홈랩에 적용된 설정은 x-systemd.automount로 접근 시점에 마운트를 요청하는 방식입니다. 5월 19일에는 마운트 장애를 분석하고 automount를 적용한 뒤 재부팅 후 동작을 확인했습니다. 6월 1일에는 마운트 옵션을, 6월 18일에는 NetBird와 CephFS의 시작 순서 및 RKE2 서비스 의존성을 검토했습니다. 마지막으로 7월 8일에는 fstab 설정과 재부팅 전 점검 절차를 정리했습니다.

7월 8일 검토 범위는 systemctl daemon-reload, 마운트 해제·재마운트, findmnt 확인과 automount 재시작 절차까지입니다. 이날 최종 재부팅까지 성공했다는 기록은 확인되지 않았습니다.

2026년 10월 14일 추가 확인: 워커 노드에서 현재 구성과 CephFS 마운트 상태를 다시 확인했습니다. 아래의 실제 설정 및 WordPress 저장 경로 설명에는 이 확인 결과를 반영했습니다.

network-online이 모든 준비를 뜻하지는 않는다

network-online.target은 시스템의 네트워크 준비 상태를 부팅 순서에 반영하는 지점입니다. 하지만 특정 Ceph MON·MDS·OSD까지 통신할 수 있는지 매번 검사하는 장치는 아닙니다. VPN을 거쳐 접속한다면 VPN 서비스 시작과 실제 경로 준비 사이에도 차이가 날 수 있습니다.

따라서 부팅 직후 한 번의 마운트 시도에 모든 것을 맡기는 구성에서는 시점 차이가 문제가 될 수 있습니다. Automount는 디렉터리 접근을 계기로 실제 마운트를 요청하도록 바꿉니다. 네트워크 장애를 고쳐 주는 기능은 아니지만, 아직 사용하지 않는 파일시스템까지 부팅 초기에 모두 연결할 필요를 줄여 줍니다.

실제 설정에서 핵심 옵션만 추려 보기

10월 14일 추가로 확인한 워커의 CephFS 설정에는 _netdev, nofail, x-systemd.automount, x-systemd.idle-timeout=0, x-systemd.mount-timeout=180이 들어 있습니다. CephFS 아래가 아니라 그 부모인 /_DATA는 로컬 Btrfs 마운트라서, 부모 경로가 먼저 준비되도록 의존성도 지정했습니다.

다음은 그 구조를 설명하기 위해 주소·파일시스템명·인증 경로를 바꾼 예시입니다. 실제 운영 파일의 복사본이 아닙니다. secretfile에는 해당 CephX 사용자의 키가 들어 있는 파일을 지정하고, 접근 범위에 맞는 권한을 부여해야 합니다.

# /etc/fstab — 아래 항목은 한 줄로 작성합니다.
192.0.2.11:3300,192.0.2.12:3300,192.0.2.13:3300:/ /_DATA/cephfs ceph name=app,fs=examplefs,secretfile=/etc/ceph/client.app.secret,_netdev,nofail,noatime,x-systemd.automount,x-systemd.idle-timeout=0,x-systemd.mount-timeout=180,x-systemd.requires-mounts-for=/_DATA,x-systemd.after=network-online.target 0 0

실제 환경에는 기존 문법인 mds_namespace가 남아 있습니다. 위 예시는 현재 mount.ceph 문서의 fs 표기를 사용했습니다. Ceph 클라이언트와 커널 버전에 맞는 문법인지 확인한 뒤 적용해야 합니다.

옵션의 의미는 systemd.mount 문서를 기준으로 구분했습니다. 특히 nofail과 automount는 서로 다른 문제를 다룹니다. 하나는 부팅 의존성, 다른 하나는 마운트를 요청하는 시점에 관한 설정입니다.

automount는 대기 중이어도 정상이다

Automount 유닛과 mount 유닛은 별개입니다. 아직 아무도 접근하지 않았다면 automount가 active (waiting)이고 실제 mount는 비활성일 수 있습니다. 두 상태를 같이 봐야 합니다.

# Bash 예시. fstab 경로를 실제 사용 경로로 바꿉니다.
MOUNT_UNIT=$(systemd-escape --path --suffix=mount /_DATA/cephfs)
AUTO_UNIT=$(systemd-escape --path --suffix=automount /_DATA/cephfs)

systemctl status "$AUTO_UNIT" "$MOUNT_UNIT"
journalctl -b -u "$AUTO_UNIT" -u "$MOUNT_UNIT"
findmnt -T /_DATA/cephfs

# 실제 접근으로 마운트가 요청되는지 확인
ls /_DATA/cephfs
findmnt -T /_DATA/cephfs -o TARGET,SOURCE,FSTYPE

systemd-escape를 쓰면 경로에 하이픈이 있을 때도 유닛 이름을 직접 추측하지 않아도 됩니다. 10월 14일 확인에서는 /_DATA/system-kernel의 automount가 실행 상태였고, 실제 파일시스템 종류도 ceph로 확인됐습니다.

새 설정을 적용할 때는 fstab을 검토한 뒤 systemctl daemon-reload로 생성 유닛을 갱신합니다. 기존 마운트 옵션을 바꾸는 작업은 사용 중인 서비스와 분리해 계획해야 합니다. 운영 중인 경로를 글의 예시대로 바로 unmount·restart하지 않습니다.

VPN 의존성은 mount 쪽에서 검토하기

Ceph까지 VPN을 반드시 거쳐야 한다면 실제 VPN 서비스에 대한 의존성과 준비 상태 검사가 추가로 필요할 수 있습니다. 서비스가 active라는 이유만으로 피어 연결과 라우팅까지 준비됐다고 단정할 수는 없습니다.

의존성을 직접 작성할 때는 .mount와 .automount를 구분합니다. systemd.automount 문서는 automount 유닛에 네트워크 순서 의존성을 직접 넣으면 순환 의존성이 생길 수 있다고 설명합니다. 이번 글에서 과거 장애의 원인을 특정 VPN의 시작 지연으로 확정하지는 않습니다. 현재 설정과 과거 장애 로그는 서로 다른 근거이기 때문입니다.

2026년 10월 14일 추가 확인: WordPress의 hostPath 저장 경로

10월 14일에는 WordPress 이미지 저장 경로도 함께 확인했습니다. Pod 안의 wp-content/uploads는 노드의 CephFS 마운트 아래 디렉터리에 hostPath로 연결돼 있었습니다. 컨테이너의 임시 디렉터리에 저장하는 구조는 아니지만, Kubernetes PVC를 사용하는 구조도 아닙니다.

여기서는 경로가 존재하는지만 보면 부족합니다. CephFS가 연결되지 않은 상태에서 같은 이름의 로컬 폴더가 보이면, 애플리케이션이 의도하지 않은 저장소를 사용하게 될 수 있습니다. Pod가 배치될 각 노드에서 실제 파일시스템을 확인하고, 필요하면 서비스의 마운트 의존성이나 CSI 기반 볼륨 사용을 검토해야 합니다.

Automount가 접근 시점을 조절해 주더라도 애플리케이션이 부팅 직후 바로 파일을 읽으면 마운트도 그때 시작됩니다. 파일 접근 지연·실패를 어떻게 처리할지는 여전히 애플리케이션과 운영 설정의 몫입니다. 현재 적용 상태를 확인하는 데서 더 나아가 재부팅 검증을 한다면, 부팅 완료와 파일 읽기·쓰기 성공을 각각 기록해 두는 것이 좋습니다.