LVM 스토리지 관리: 6개월 운영 경험과 성능 최적화 회고

1. LVM을 다시 보게 된 6개월

LVM(Logical Volume Manager)은 새롭지도, 화려하지도 않습니다. 그런데 운영해보면 오래 살아남은 이유가 보이더라고요. 지난 6개월 동안 홈랩과 소규모 내부 서비스에서 VM 이미지, 컨테이너 볼륨, 로그, 백업 데이터를 나눠 운영하면서 얻은 결론은 단순했습니다. LVM은 스토리지 문제를 자동으로 해결하는 기술이 아니라, 운영자가 디스크 변경을 덜 위험하게 수행하도록 도와주는 계층입니다.

처음에는 저도 “요즘은 ZFS, btrfs, Ceph도 있는데 굳이 이걸?”이라고 생각했습니다. 하지만 단일 Linux 서버에서 디스크를 추가하고, 특정 서비스의 공간만 늘리고, 마운트 경로를 유지하면서 용량 계획을 바꾸는 일은 생각보다 자주 생깁니다. 단순 파티션만 쓰면 재파티셔닝이나 데이터 이동이 부담스럽고, 분산 스토리지는 과한 경우가 많습니다. 이 중간 지점에서 꽤 실용적이었습니다.

이 글은 명령어 모음이 아닙니다. 13년 가까이 서버를 만지면서 느낀 기준으로, 어디까지를 볼륨 관리에 맡기고 어디서부터 파일시스템, 백업, RAID, 모니터링의 문제로 봐야 하는지 정리했습니다. 특히 “LV는 커졌는데 df는 그대로인 상황”, “스냅샷을 백업처럼 오래 들고 있다가 위험해지는 상황”, “iostat 숫자를 어떻게 해석해야 하는지”처럼 실제 운영에서 자주 부딪히는 실패 모드를 중심으로 썼습니다.

홈랩 서버에서 물리 디스크, PV, VG, LV, 파일시스템, 마운트 경로가 어떤 계층으로 연결되는지 한눈에 보는 개요 이미지입니다.

2. 스토리지 관리에서 먼저 잡아야 할 책임 경계

처음 배울 때는 보통 PV, VG, LV 개념부터 외웁니다. 틀린 접근은 아니지만, 운영에서는 용어보다 책임 경계를 먼저 잡는 편이 훨씬 안전했습니다.

PV(Physical Volume)는 LVM에 편입한 실제 디스크나 파티션입니다. VG(Volume Group)는 여러 PV를 묶은 저장소 풀이고, LV(Logical Volume)는 그 풀에서 잘라낸 논리 디스크입니다. 여기에 ext4, XFS 같은 파일시스템을 만들고, 마지막으로 특정 경로에 마운트합니다. 장애 분석은 이 순서를 거꾸로 따라가면 덜 헷갈립니다.

가장 중요한 오해는 이것입니다. LVM은 백업도 아니고, RAID도 아니고, 고가용성 솔루션도 아닙니다. 디스크 하나가 죽었을 때 데이터를 보존하려면 RAID, 복제, 검증된 백업이 필요합니다. 이 선을 넘겨 기대하면 사고가 납니다.

3. 새 디스크를 붙일 때 실제로 쓰는 절차

가장 많이 반복한 작업은 새 디스크를 추가하고 기존 데이터 LV를 확장하는 일이었습니다. 아래 예시는 /dev/sdb를 새 디스크로 가정합니다. 실제 서버에서는 장치명이 바뀔 수 있으니, 명령어를 그대로 붙여넣기 전에 반드시 lsblk, blkid, findmnt로 확인해야 합니다. 저는 작업 전후 출력까지 운영 메모에 남깁니다.

# 0) 현재 디스크, 파일시스템, 마운트 상태 확인
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL
sudo blkid
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS

# 1) 현재 상태를 작업 로그에 남기기
sudo pvs -o pv_name,vg_name,pv_size,pv_free
sudo vgs -o vg_name,vg_size,vg_free,vg_extent_size
sudo lvs -a -o lv_name,vg_name,lv_size,segtype,devices

# 2) 새 디스크를 PV로 초기화
# 주의: /dev/sdb 안의 기존 데이터는 LVM 메타데이터로 덮일 수 있습니다.
sudo pvcreate /dev/sdb

# 3) 기존 VG에 새 PV 추가
sudo vgextend vg_data /dev/sdb

# 4) LV와 파일시스템을 함께 확장
# -r은 fsadm을 통해 파일시스템 확장까지 시도합니다.
sudo lvextend -r -L +100G /dev/vg_data/lv_app

# 5) 작업 후 계층별로 확인
sudo lvs -a -o lv_name,lv_size,data_percent,metadata_percent,segtype,devices
sudo vgs -o vg_name,vg_size,vg_free
df -hT /srv/app

lvextend -r은 실수를 줄여주는 좋은 옵션입니다. 다만 “항상 알아서 된다”는 뜻은 아닙니다. 파일시스템 종류, 마운트 상태, 관련 도구 설치 여부에 따라 실패할 수 있거든요. 그래서 저는 확장 후 lvs와 df -hT를 꼭 같이 봅니다. 하나는 볼륨 계층, 다른 하나는 서비스가 실제로 체감하는 파일시스템 계층입니다.

새 디스크를 PV로 만들고 VG에 붙인 뒤 LV와 파일시스템을 확장하는 흐름을 단계별로 보여주는 이미지입니다.

4. 이름 규칙은 장애 대응 속도입니다

6개월 동안 가장 크게 체감한 것은 기능 자체보다 명명 규칙과 마운트 규칙의 중요성이었습니다. 급한 상황에서 lv01, data2, newdisk 같은 이름을 보면 손이 멈춥니다. 이 볼륨이 VM용인지, 로그용인지, 백업용인지 바로 알 수 없기 때문입니다.

저는 VG에는 물리적 성격이나 서버 내 역할을, LV에는 서비스 역할을 넣었습니다. 예를 들면 vg_ssd, vg_bulk, lv_vm, lv_log, lv_backup처럼 구분했습니다. SSD와 HDD를 같은 VG에 섞는 것도 가능하지만, 특별한 이유가 없으면 피합니다. 성능 병목을 추적할 때 판단이 흐려지더라고요.

5. Linux 성능보다 먼저 확인한 문제: LV는 커졌는데 df는 그대로

한 번은 로그 디렉터리 공간이 꽉 차서 급하게 LV를 늘렸습니다. lvs로 보면 분명히 커졌는데 애플리케이션은 계속 쓰기 오류를 냈습니다. 원인은 단순했습니다. LV 확장만 끝났고 파일시스템 확장이 끝나지 않았던 겁니다. 알고 나면 간단한데, 장애 중에는 이런 기본이 제일 잘 미끄러집니다.

# 문제 상황 진단 루틴
findmnt /srv/app
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS

df -hT /srv/app

sudo lvs -a -o lv_path,lv_size,segtype,devices
sudo vgs -o vg_name,vg_size,vg_free

# ext4라면 디바이스 기준으로 확장
# 온라인 확장이 가능한 상태라면 마운트 중에도 수행할 수 있습니다.
sudo resize2fs /dev/vg_data/lv_app

# XFS라면 마운트 포인트 기준으로 확장
# XFS는 축소를 지원하지 않는다는 점도 용량 설계 때 고려해야 합니다.
sudo xfs_growfs /srv/app

df -hT /srv/app
sudo lvs -o lv_path,lv_size

판단 기준은 명확합니다. lvs의 LV 크기는 늘었는데 df -hT의 파일시스템 크기가 그대로라면 파일시스템 확장이 빠진 것입니다. ext4는 resize2fs, XFS는 xfs_growfs를 확인합니다. 특히 XFS는 확장할 때 디바이스 경로가 아니라 마운트 포인트를 넘긴다는 점이 초반에 헷갈리기 쉽습니다.

여기서 더 중요한 교훈은 XFS의 축소 불가입니다. ext4는 오프라인 축소가 가능하지만, XFS는 일반적으로 축소를 지원하지 않습니다. 그래서 XFS 기반 LV를 크게 잡아버리면 나중에 줄여서 다른 곳에 나누기가 어렵습니다. 로그나 백업처럼 증가 방향이 뚜렷한 데이터에는 XFS가 편했지만, 크기 변경을 자주 실험하는 볼륨에는 더 신중하게 접근했습니다.

6. 성능 최적화: LVM 오버헤드보다 I/O 패턴이 먼저 보였습니다

LVM을 쓰면 성능이 크게 떨어진다는 식의 이야기를 종종 봅니다. 제 운영 경험에서는 그렇게 단순하지 않았습니다. 기본적인 linear LV 구성에서는 볼륨 계층 자체보다 디스크 종류, 파일시스템, 동시 작업, 백업 시간대, VM 이미지 포맷, 로그 쓰기 패턴이 더 자주 병목을 만들었습니다. 물론 thin provisioning, snapshot, RAID 타입 LV를 쓰면 관찰해야 할 지표도 늘어납니다.

성능을 볼 때는 단일 숫자를 절대적인 기준으로 삼지 않았습니다. await, %util, r/s, w/s, aqu-sz를 같이 보고, 애플리케이션 로그의 지연 시점과 맞춰봤습니다. 중요한 건 “평소보다 얼마나 달라졌는가”입니다. 정상 상태 기준선이 없으면 장애 시점의 숫자가 큰지 작은지 판단하기 어렵습니다.

# 디스크별 확장 지표를 1초 간격으로 확인
# await: I/O 요청 평균 대기 시간
# %util: 장치가 바쁘게 처리한 시간 비율
# aqu-sz: 평균 큐 길이
iostat -x 1

# 특정 프로세스가 실제로 I/O를 만드는지 확인
sudo iotop -oPa

# CPU 병목과 I/O 대기 구분
sar -u 1 5
sar -d 1 5

# 메모리 부족으로 swap이 개입하는지 확인
free -h
swapon --show
vmstat 1

# LV가 어느 물리 디스크를 쓰는지 확인
sudo lvs -a -o lv_name,lv_size,segtype,devices

%util이 높다고 바로 디스크 고장이나 볼륨 관리 문제로 단정하지는 않았습니다. 야간 백업, 압축 작업, 로그 로테이션, 컨테이너 이미지 정리 작업이 겹치면 일시적으로 지표가 튈 수 있거든요. 반대로 await가 평소보다 길어지고, 큐가 쌓이고, 애플리케이션 응답 지연이 같은 시간대에 나타나면 I/O 병목 가능성이 높습니다. 이때 lvs -o +devices로 해당 LV가 어느 물리 디스크를 쓰는지 확인하면 원인 범위를 빨리 줄일 수 있습니다.

제가 적용한 최적화는 거창하지 않았습니다. VM 이미지와 백업 데이터를 같은 LV에 몰아넣지 않았고, 대량 백업은 서비스 피크 시간과 분리했습니다. 로그가 많은 서비스는 별도 LV로 빼서 폭주 시 영향 범위를 제한했습니다. SSD와 HDD를 같은 VG에 섞지 않았습니다. 이 네 가지가 튜닝 옵션을 만지는 것보다 체감 효과가 컸습니다.

LVM 용량 상태와 디스크 I/O 지표를 함께 보며 병목을 판단하는 운영 대시보드 예시입니다.

7. Snapshot은 보험이 아니라 짧은 안전핀입니다

LVM snapshot은 패키지 업그레이드나 설정 변경 전에 마음을 편하게 해줍니다. 저도 몇 번 도움을 받았습니다. 하지만 스냅샷을 오래 들고 있는 순간부터 성격이 바뀝니다. 임시 보호 장치가 아니라 운영 리스크가 됩니다.

전통적인 snapshot은 원본 볼륨 변경분을 추적합니다. 변경량이 많아질수록 스냅샷 공간을 더 압박하고, 공간이 부족하면 스냅샷이 무효화될 수 있습니다. 그래서 저는 스냅샷을 “작업 전후 몇 시간 안에 제거할 대상”으로만 봅니다. 장기 보관은 백업 시스템의 일입니다.

# 작업 전 스냅샷 생성
sudo lvcreate -L 20G -s -n lv_app_prechange /dev/vg_data/lv_app

# 스냅샷 상태 확인
# data_percent가 계속 증가하는지 봅니다.
sudo lvs -a -o lv_name,origin,lv_size,data_percent,metadata_percent,lv_attr

# 작업이 성공했고 롤백 필요가 없으면 즉시 제거
sudo lvremove /dev/vg_data/lv_app_prechange

# 롤백이 필요하면 merge 검토
# 대상 LV가 활성 상태이면 다음 활성화 시점이나 재부팅 시점에 병합될 수 있습니다.
sudo lvconvert --merge /dev/vg_data/lv_app_prechange

스냅샷을 쓸 때 제 규칙은 세 가지입니다. 첫째, 생성 전 vgs로 VG 여유 공간을 확인합니다. 둘째, 생성 후 data_percent를 모니터링합니다. 셋째, 작업이 끝나면 바로 삭제합니다. 스냅샷이 있다는 사실이 백업 검증을 대신해주지는 않습니다.

8. Thin Provisioning은 편하지만 감시 없이는 쓰지 않습니다

LVM thin provisioning은 실제 물리 공간보다 큰 논리 볼륨을 미리 만들어두는 방식입니다. VM을 많이 만들거나 개발 환경처럼 사용량이 천천히 늘어나는 곳에서는 매력적입니다. 하지만 공짜는 아닙니다. thin pool의 data 영역이나 metadata 영역이 부족해지면 일반 LV보다 장애 양상이 더 까다로워질 수 있습니다.

저는 홈랩에서 thin LV를 테스트해봤지만, 중요한 데이터에는 보수적으로 접근했습니다. thin을 쓰려면 최소한 data_percent, metadata_percent를 정기적으로 보고, 임계치에 도달하기 전에 알림이 와야 합니다. 모니터링 없이 thin을 쓰는 건 “언젠가 정리하겠지”라는 마음으로 운영하는 셈이라서, 결국 언젠가는 문제가 됩니다.

# thin pool과 thin LV 상태 확인
sudo lvs -a -o lv_name,lv_size,segtype,data_percent,metadata_percent,lv_attr,devices

# thin pool 자동 확장 설정 위치 확인
sudo grep -n 'thin_pool_autoextend' /etc/lvm/lvm.conf

# lvm.conf에서 검토할 대표 파라미터
# thin_pool_autoextend_threshold: 자동 확장을 시작할 사용률 기준
# thin_pool_autoextend_percent: 자동 확장 시 늘릴 비율
# 설정 변경 후에는 배포판의 lvm 서비스 구성과 dmeventd 동작을 함께 확인해야 합니다.

중요한 점은 파라미터 이름을 아는 것보다 운영 조건을 정하는 것입니다. thin pool 자동 확장을 켜더라도 VG에 남은 공간이 없다면 확장할 수 없습니다. 즉, thin provisioning은 공간 계획을 없애는 기술이 아니라 공간 계획을 더 자주 확인해야 하는 기술에 가깝습니다.

9. 운영 회고: 이런 경우엔 쓰고, 이런 경우엔 다른 선택을 봅니다

6개월간 운영하며 세운 기준은 꽤 분명해졌습니다. 단일 서버에서 데이터 파티션을 자주 조정하고, 서비스별로 공간을 분리하고, 디스크 추가가 종종 발생한다면 LVM은 여전히 좋은 선택입니다. 반대로 여러 서버에 걸친 자동 복제, 장애 조치, 데이터 무결성 검증, 스냅샷 기반 장기 보관까지 기대한다면 이것만으로는 부족합니다.

LVM을 써도 좋은 상황과 피해야 할 상황을 운영 관점에서 비교한 요약 이미지입니다.

10. 운영 체크리스트: 저는 이 순서로 봅니다

장애나 용량 이슈가 생기면 감으로 명령어를 치기보다 같은 순서로 확인하는 편이 안전했습니다. 아래 루틴은 제가 실제로 자주 쓰는 확인 순서입니다. 핵심은 “서비스 경로에서 시작해서 물리 디스크까지 내려가는 것”입니다.

# 1) 서비스가 쓰는 경로가 어디에 붙어 있는지 확인
findmnt /srv/app
df -hT /srv/app

# 2) 블록 디바이스 계층 확인
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS

# 3) LVM 계층 확인
sudo pvs -o pv_name,vg_name,pv_size,pv_free,pv_used
sudo vgs -o vg_name,vg_size,vg_free,lv_count,pv_count
sudo lvs -a -o lv_path,lv_size,segtype,data_percent,metadata_percent,devices

# 4) 커널 로그에서 디스크 오류 확인
sudo dmesg -T | grep -Ei 'error|fail|reset|timeout|I/O'

# 5) I/O 병목 여부 확인
iostat -x 1
sudo iotop -oPa

이 루틴을 정해두면 장애 상황에서 불필요한 추측이 줄어듭니다. 예를 들어 df는 가득 찼는데 vgs에 여유 공간이 있다면 LV 확장으로 해결할 수 있습니다. 반대로 VG 자체가 꽉 찼다면 디스크 추가, 데이터 정리, 백업 이동 중 하나를 선택해야 합니다. dmesg에 I/O 오류가 보인다면 용량 문제가 아니라 물리 디스크나 컨트롤러 문제일 수 있습니다.

11. 자주 묻는 질문

LVM을 쓰면 성능이 많이 떨어지나요?

일반적인 linear LV 구성에서는 LVM 계층 자체보다 디스크 성능, I/O 패턴, 파일시스템, 백업 작업, 애플리케이션 쓰기 방식이 더 크게 체감되는 경우가 많았습니다. 다만 snapshot, thin provisioning, RAID 타입 LV를 쓰면 관리해야 할 지표가 늘어납니다. iostat -x 1, iotop -oPa, lvs -o +devices를 같이 보세요.

운영 중에도 LV 확장이 가능한가요?

가능한 경우가 많습니다. ext4와 XFS는 온라인 확장을 지원하는 대표적인 파일시스템입니다. 다만 축소는 별개 문제입니다. 특히 XFS는 일반적으로 축소를 지원하지 않으므로 처음부터 너무 크게 잡는 결정을 조심해야 합니다. 확장 전에는 장치명, 마운트 경로, 백업 상태를 확인하세요.

LVM snapshot만 있으면 백업은 없어도 되나요?

아니요. 스냅샷은 짧은 작업 보호 장치이고, 백업은 장애 후 복구 전략입니다. 원본 디스크 장애, 실수로 인한 삭제, 장기 보관, 별도 서버 복구까지 생각하면 스냅샷만으로는 부족합니다. 저는 스냅샷을 만들면 제거 예정 시간까지 같이 기록합니다.

SSD와 HDD를 같은 VG에 묶어도 되나요?

기술적으로는 가능합니다. 하지만 저는 특별한 이유가 없으면 분리합니다. 성능 특성이 다른 디스크를 한 VG에 섞으면 특정 LV가 어느 디스크를 쓰는지 계속 확인해야 하고, 병목 원인을 설명하기 어려워집니다. 빠른 저장소와 대용량 저장소는 VG부터 분리하는 편이 운영이 편했습니다.

마무리: 오래됐지만, 기준을 세우면 여전히 강합니다

제 결론은 꽤 실용적인 쪽입니다. 단일 Linux 서버, 홈랩, 소규모 내부 서비스처럼 스토리지 구성이 계속 조금씩 바뀌는 환경이라면 LVM은 아직 충분히 쓸모 있습니다. 특히 서비스별 LV 분리, 경로 유지 확장, 짧은 작업 전 스냅샷, 디스크 추가 대응에서는 단순 파티션보다 운영 부담이 적었습니다.

다만 기대할 것과 기대하지 말 것을 분명히 해야 합니다. LVM은 유연성, 백업은 생존 전략, RAID나 복제는 장애 대응 설계입니다. 저는 작은 서버라면 LVM + 정기 백업 + 용량/I/O 모니터링부터 시작하겠습니다. 여러 서버의 고가용성이 필요해지는 순간에는 LVM 단독 구성을 고집하지 않고 RAID, 원격 복제, 분산 스토리지, 복구 테스트까지 함께 설계하는 쪽을 택하겠습니다.

관련 글로는 Linux 파일시스템 선택 기준, iostat 해석법, 백업 복구 테스트 절차를 함께 연결하면 독자가 다음 단계로 이동하기 좋습니다.