LFCS 스토리지 핵심 개념

LVM, VFS, 파일시스템, 원격 스토리지, swap, autofs, 스토리지 성능을 시험 관점으로 정리한다

이 문서는 공식 Storage 7개 competency의 개념 층이다. 포맷·LVM·swap command를 실행하기 전에 실습 환경에서 OS disk와 폐기 가능한 보조 disk를 구분하고 snapshot 복원을 확인한다.

작성·검증 상태: AI가 구조화와 설명 초안을 보조했다. destructive command는 개념 예시이며, device·filesystem type·mount 상태를 실습 VM에서 다시 확인한 뒤 실행한다.

이 영역을 끝내는 순서

  1. device → LVM/network block → filesystem/swap → VFS mount → application path 계층을 설명한다.
  2. 스토리지 안내형 lab에서 빈 disk와 2노드 fixture를 사용한다.
  3. 초기화한 뒤 영문 단계별 실전을 풀이 없이 수행한다.
  4. device 이름·size·filesystem type·mount option을 바꿔 다시 수행한다.

완료 기준은 mount 성공 한 번이 아니라 layer별 size·UUID·active state, fstab 재적용, 실제 read/write와 기존 disk 보존을 함께 증명하는 것이다.

이 문서는 LFCS 스토리지 공식 competency를 기준으로 한다. 장치명과 성능 수치는 환경마다 다르므로 계층을 먼저 식별하고 실제 출력으로 판단한다.

1) LVM (Logical Volume Management)

핵심 개념

  • LVM은 물리 장치(PV) → 볼륨 그룹(VG) → 논리 볼륨(LV) → 파일시스템 계층으로 설계한다.
  • pvcreate는 장치 위 메타데이터 영역을 만들고, vgcreate가 물리 집합을 묶어 논리적 풀(pool)을 만든다.
  • LV 확장은 lvextend/lvresize로 먼저 볼륨 크기를 늘리고, 그다음 파일시스템에 맞는 확장 명령을 수행한다.
  • LV 이름 충돌·중복 마운트·오탐 장치 선택이 가장 흔한 실수다.

핵심 명령

  • lsblk -f, blkid, pvs, vgs, lvs
  • pvcreate /dev/sdX, vgcreate vg01 /dev/sdX
  • lvcreate -L 5G -n lv_data vg01
  • lvextend -L +2G /dev/vg01/lv_data, lvresize -l +100%FREE /dev/vg01/lv_data
  • lvdisplay, vgdisplay, lvremove(삭제 전 대상·백업 확인)

검증

  1. pvs, vgs, lvs로 PV/VG/LV의 UUID, 크기, 사용률을 먼저 확인한다.
  2. lsblk -fp에서 PV 단말이 LV 마운트 경로와 어떻게 연결되는지 확인한다.
  3. 변경 전후에 findmnt/mount | grep /dev/vg로 실제 마운트 대상을 점검한다.

실수/위험

  • 대상 장치가 활성 파티션/루트 볼륨일 때 실수로 pvcreate 적용 시 복구가 어렵다.
  • extend 전 resize 대상 파일시스템 타입별 절차를 생략하면 마운트 실패나 오염이 생길 수 있다.
  • vgreduce/lvremove는 되돌리기 어려우므로 실습 전에 백업·스냅샷 정책을 둔다.

배포판 차이

  • Rocky/RHEL은 LVM 명칭·버전이 비슷하지만 명령 세트는 동일하며, package 구성이 배포판마다 다를 수 있다.
  • Debian/Ubuntu는 lvm2 설치 상태와 /etc/lvm/lvm.conf 기본값 차이가 있을 수 있다.

2) VFS와 파일시스템 마운트 계층

핵심 개념

  • VFS(Virtual Filesystem Switch)는 실제 파일시스템 종류와 무관하게 동일한 API를 커널에 제공한다.
  • 장치 파일, 파티션, 파일시스템, 마운트 포인트의 대응을 정확히 알아야 장치 오식별을 줄인다.
  • UUID는 디바이스명(/dev/sda1)보다 마운트 안정성이 높아 fstab에서 권장한다.
  • /proc/self/mounts, findmnt는 현재 마운트 트리를 정규화해 보여 준다.

핵심 명령

  • lsblk -o NAME,TYPE,SIZE,FSTYPE,UUID,MOUNTPOINT
  • blkid, findmnt, findmnt -r /var, mount, findmnt -t ext4,xfs
  • id -u, stat -c '%t:%T' /path
  • mount -a, mount -o rw,noatime /dev/... /mnt/test
  • systemctl daemon-reload(fstab/automount/유닛 연동 시)

검증

  1. blkid와 findmnt에서 UUID가 장치 식별과 fstab 엔트리와 일치하는지 확인한다.
  2. mountpoint -q /mnt/test로 마운트 상태를 검사하고, findmnt /mnt/test로 실제 소스-타입을 확인한다.
  3. systemctl 또는 재부팅 없이 마운트만 변경한다면 mount -a 결과와 에러를 검토한다.

실수/위험

  • /etc/fstab에 잘못된 장치명이나 마운트 옵션을 넣으면 부팅이 지연되거나 emergency mode로 진입할 수 있다.
  • rw 권한 오용, discard 오남용은 SSD/Thin provisioning에서 성능 저하를 유발한다.
  • 마운트 지점에 이미 파일이 존재할 때 강제 마운트하면 데이터 접근성이 바뀐다.

배포판 차이

  • systemd 기반 배포판은 부팅 마운트 경로 정책이 엄격하고, 유닛 연동이 강하다.
  • Debian/Ubuntu 계열은 동일 mount 옵션도 기본 패키지 유무(nfs-common, autofs, sysstat)에 따라 다르게 동작할 수 있다. nfs-utils는 Rocky/RHEL 계열 패키지명이다.

3) 파일시스템 (ext4 / XFS 비교 포함)

핵심 개념

  • ext4는 e2fsck·resize2fs, XFS는 xfs_repair·xfs_growfs처럼 점검·확장 도구가 다르다.
  • XFS는 마운트된 파일시스템을 확장할 수 있지만 일반적인 축소는 지원하지 않는다. ext4 축소는 가능하더라도 오프라인 작업과 여유 공간 확인이 필요하다.
  • mkfs는 포맷이므로 실운영 볼륨에는 사전 점검(마운트 해제/백업) 없이 사용하지 않는다.
  • 레이블(e2label, xfs_admin -L)과 UUID는 장기 안정성에 중요하다.

핵심 명령

  • mkfs.ext4 /dev/vg01/lv_data, mkfs.xfs /dev/vg01/lv_data
  • blkid /dev/vg01/lv_data, e2label, xfs_admin -l /dev/...
  • tune2fs -l /dev/..., xfs_info /dev/..., xfs_repair -n, e2fsck -fn
  • resize2fs /dev/..., xfs_growfs /mountpoint

검증

  1. blkid -o full과 findmnt -o SOURCE,FSTYPE,UUID,TARGET으로 파일시스템 타입·UUID를 추적한다.
  2. 신규 생성 파일시스템에서 fsck 계열은 오프라인/읽기 전용 점검으로 사전 확인한다.
  3. 마운트 후 df -hT, df -i로 타입별 용량/ inode 가용을 비교한다.

실수/위험

  • XFS 파일시스템에 대해 ext4 복구 도구를 쓰면 데이터 손실 위험이 크다.
  • XFS는 온라인 성장은 용이하나 shrink는 기본적으로 지원되지 않는다.
  • ext4도 대용량에선 inode 과소분할로 df -i 경고를 유발할 수 있다.

배포판 차이

  • RHEL/Rocky는 기본적으로 xfsprogs와 e2fsprogs가 같이 제공되는 경우가 많다.
  • Debian 계열은 버전별 도구 옵션(예: 디폴트 옵션 플래그) 차이가 있어 출력형식/동작 결과 비교가 필요하다.

4) 원격 파일시스템 / 네트워크 블록 디바이스

핵심 개념

  • 원격 파일시스템: NFS는 파일 레벨 접근을 네트워크로 확장한다.
  • iSCSI는 블록 레벨로 원격 LUN을 로컬 블록 장치처럼 다루며, 성능/보안/네트워크 경로에 더 민감하다.
  • 네트워크 디바이스는 이름 기반 동적 탐색이 흔해 /etc/fstab에서 UUID/영구 옵션이 안전하다.

핵심 명령

  • NFS: showmount -e, mount -t nfs -o rw, umount, exportfs
  • rpcinfo -p, systemctl status nfs-server, systemctl restart nfs-server
  • iSCSI: iscsiadm -m discovery -t sendtargets -p <ip>:<port>, iscsiadm -m node -T iqn..... -p <ip>:<port> --op update -n node.startup -v automatic, systemctl status iscsid, systemctl status iscsi
  • multipath -ll(환경에 따라 다중 경로 사용 시)

검증

  1. NFS: mount | grep nfs, showmount -e, 마운트한 경로에 테스트 파일 생성 가능 여부로 접근 권한을 본다.
  2. iSCSI: iscsiadm -m session, lsblk에서 /dev/sdX로 세션이 인식됐는지 확인한다.
  3. 두 경우 모두 dmesg | tail 또는 journalctl -u iscsid/journalctl -u nfs-server로 연결 오류를 추적한다.

실수/위험

  • NFS의 root_squash와 client·server UID/GID 불일치를 이해하지 못하면 예상과 다른 권한 결과가 생길 수 있다.
  • iSCSI 로그인 전에 대상 LUN 경로를 잘못 지정하면 OS 디바이스가 충돌하거나 중복 마운트된다.
  • 방화벽·route·MTU 문제는 timeout이나 세션 단절을 만들 수 있다. stale file handle은 서버에서 export된 객체가 교체·삭제되는 등 파일 handle이 더 이상 유효하지 않을 때 별도로 진단한다.

배포판 차이

  • RHEL 계열은 nfs-utils/iscsi-initiator-utils 구성 관습이 명시적으로 드러난다.
  • Debian/Ubuntu는 패키지/서비스 이름, 기본 포트/방화벽 정책에 차이가 있어 설치/활성화 순서를 확인한다.

5) swap

핵심 개념

  • swap은 메모리 압박 완화 목적의 보조 저장소이며 RAM 용량 대체가 아니다.
  • swappiness, vm.swappiness, zswap 정책은 워크로드별로 영향이 크다.
  • swap 파일과 swap 파티션/볼륨 중 어떤 방식이든 priority와 오염 범위를 관리해야 한다.

핵심 명령

  • free -h, swapon --show, cat /proc/swaps
  • mkswap /dev/vg01/lv_swap, swapon /dev/vg01/lv_swap
  • swapoff -a, swapon -a(점검 시 오프라인 순서 신중)
  • fallocate -l 1G /swapfile; chmod 600 /swapfile; mkswap /swapfile; swapon /swapfile(파일시스템 지원 여부 확인)
  • sysctl vm.swappiness

검증

  1. free -h에서 swap 사용량/총량 추세를 확인한다.
  2. swapon --show --bytes로 위치·우선순위·크기를 확인한다.
  3. /etc/fstab 등록 시 부팅 후 swapon -s를 재확인해 영구 적용 여부를 점검한다.

실수/위험

  • 루트 디스크의 여유 공간이 부족한데 큰 swap 파일을 무리하게 생성하면 df 경고를 악화시킨다.
  • swapoff는 장시간 동작 프로세스에 영향을 줄 수 있으므로 유지보수 창에서 수행한다.
  • CoW 파일시스템 등에서는 swapfile 생성 방식과 지원 조건이 다를 수 있으므로 해당 파일시스템 문서를 확인한다.

배포판 차이

  • vm.swappiness, zswap과 cloud image의 기본 swap 구성은 배포판·이미지 정책에 따라 다르므로 현재 값을 먼저 확인한다.

6) automount(autofs)

핵심 개념

  • autofs는 필요 시점에만 마운트를 수행하고, 사용 종료 후 자동 해제한다.
  • 사용자 로그인 시점의 부팅 지연을 줄이거나 다수 NFS/NFSv4 마운트를 관리할 때 유리하다.
  • auto.master(맵 포인트) + 하위 맵(키/위치)이 핵심 구성이다.

핵심 명령

  • systemctl enable --now autofs
  • cat /etc/auto.master, cat /etc/auto.misc(예시)
  • systemctl status autofs, systemctl restart autofs
  • systemctl is-enabled autofs, automount, ls /net/shared
  • showmount -e <nfs-server>(맵 대상 확인)

검증

  1. systemctl is-active autofs와 systemctl status autofs로 데몬 상태를 확인한다.
  2. /etc/auto.master 변경 후 systemctl reload autofs로 반영한다.
  3. trigger 경로 접근 전후를 findmnt로 비교하고, timeout 뒤 자동 해제되는지 확인한다.

실수/위험

  • browse 용도로 민감 경로를 공통 맵에 넣으면 권한 노출 리스크가 증가한다.
  • 맵 파일 오타나 도달할 수 없는 원격 경로는 접근 지연을 만들 수 있다.
  • 자동 해제 시간이 너무 짧으면 장기 session에서 불필요한 재마운트가 반복될 수 있다.

배포판 차이

  • RHEL/Rocky는 autofs와 SELinux 연동 정책이 stricter한 편이라 context/서비스 허용을 함께 봐야 한다.
  • Debian 계열은 init 스크립트 체인보다 systemd 오버라이드가 빠르게 반영되는 경우가 있다.

7) storage 성능, 용량, inode, I/O 지표

핵심 개념

  • 스토리지 이슈를 진단할 때는 용량(block) + inode + 지연(latency) + 활용률(util)을 함께 본다.
  • iostat -xz의 await, avgqu-sz, %util은 유효성이 높지만 하나만으로 결론내리면 안 된다.
  • dmesg, journal, 프로세스별 I/O를 함께 보면 용량 부족인지, I/O 병목인지, 파일시스템 이상인지 구분된다.

핵심 명령

  • df -hT, df -i, du -xhd1 /var
  • lsblk -o NAME,SIZE,ROTA,STATE,MODEL
  • iostat -xz 1 5, vmstat 1 5, pidstat -d 1 5
  • lsof -a +L1 /var, findmnt -n /var
  • sar -n DEV 1 5(네트워크/디바이스 동시 관측)

검증

  1. df -hT와 df -i를 함께 확인해 block 부족인지 inode 부족인지 먼저 구분한다.
  2. iostat -xz에서 대상 디바이스 await 상승과 %util 동시 상승 여부를 확인한다.
  3. pidstat -d로 높은 I/O를 쓰는 프로세스를 특정하고, findmnt 범위를 한정해 디렉터리 집계를 한다.

실수/위험

  • 높은 load average만 보고 디스크만 결론내리면 서비스 계층 병목을 놓친다.
  • cache 또는 서비스 재시작을 먼저 적용하면 원인 구분이 어렵다.
  • 임시 파일 생성으로 용량/inode를 즉시 채워 근거 없는 조치를 정당화할 수 있다.

배포판 차이

  • sysstat(iostat, pidstat, sar) 패키지 유무가 다르므로 기본 설치 여부를 먼저 본다.
  • XFS/ext의 공간/성능 특성이 같아 보여도 기본 마운트 옵션, 저널/알고리즘 정책이 배포판 정책에 따라 다를 수 있다.

정리 체크리스트

Storage 명령군의 시험형 점검 순서

  1. lsblk/blkid/findmnt로 계층과 소스를 먼저 고정한다.
  2. 대상이 마운트/스왑/원격인지 판단하고 변경 대상만 제한한다.
  3. 읽기 전용 점검부터 수행하고, 변경 후 df, df -i, findmnt, journal로 증거를 남긴다.
  4. 실수 위험이 큰 명령(mkfs, pvcreate, lvremove, wipefs)은 unmounted + 백업 확인 + 대상 확정 후에만 수행한다.

참고 자료