[Linux] 유연한 스토리지 관리의 핵심: LVM 이해하기 (PV, VG, LV)

리눅스 시스템을 운영하다 보면 "디스크 용량이 부족한데, 다운타임 없이 공간을 늘릴 수 없을까?"라는 고민에 직면하게 됩니다. 기존의 전통적인 파티션 방식(fdisk, parted 등)에서는 물리적인 디스크의 크기나 파티션 경계를 넘어 용량을 확장하는 것이 매우 어렵습니다.

이러한 물리적 한계를 극복하고 스토리지를 유연하게 관리하기 위해 등장한 기술이 바로 **LVM(Logical Volume Manager)**입니다. LVM의 핵심 3요소인 PV, VG, LV가 각각 어떤 역할을 하고 내부적으로 어떻게 작동하는지 상세히 파헤쳐 보겠습니다.

1. PV (Physical Volume) : 물리적 볼륨

"물리적 디스크를 LVM이 인식할 수 있는 조각으로 만들기"

명명 이유

'Physical Volume'이라는 이름은 하드 디스크(/dev/sda)나 SSD, 혹은 기존 파티션(/dev/sda1)과 같은 '물리적인(Physical)' 저장 매체를 LVM 시스템이 사용할 수 있는 **기본 단위(Volume)**로 초기화했음을 의미합니다.

내부 동작 메커니즘

pvcreate 명령어를 통해 일반 디스크를 PV로 변환하면, LVM은 해당 디스크의 앞부분에 LVM 메타데이터를 기록합니다. 가장 중요한 내부 메커니즘은 디스크 공간을 **PE(Physical Extent)**라는 일정한 크기의 아주 작은 물리적 블록(기본값 4MB) 단위로 잘게 쪼개는 것입니다. 즉, PV는 수많은 PE들의 집합체입니다.

2. VG (Volume Group) : 볼륨 그룹

"여러 디스크를 하나의 거대한 저장소 풀(Pool)로 통합하기"

명명 이유

'Volume Group'은 하나 이상의 PV(물리적 볼륨)들을 논리적으로 묶어낸 **'그룹(Group)'**이기 때문에 붙여진 이름입니다. 디스크의 물리적인 경계를 허물고 자원을 한 곳에 모았다는 목적을 직관적으로 나타냅니다.

내부 동작 메커니즘

VG는 PV들이 제공하는 수많은 PE(Physical Extent)들을 한데 모아 담아두는 거대한 '풀(Pool)' 역할을 합니다. 운영체제는 더 이상 개별 하드 디스크의 용량을 신경 쓰지 않고, 오직 VG 전체의 가용 용량만 확인하게 됩니다. 새로운 하드 디스크(PV)를 컴퓨터에 꽂고 기존 VG에 추가하기만 하면, 전체 저장소 풀의 용량이 즉시 늘어납니다.

3. LV (Logical Volume) : 논리적 볼륨

"필요한 만큼 잘라 쓰는 가상의 파티션"

명명 이유

'Logical Volume'은 하드웨어가 아닌 소프트웨어적으로 만들어진 **'논리적인(Logical)' 파티션(Volume)**을 뜻합니다. 물리적 디스크의 위치나 크기에 종속되지 않고, 관리자가 원하는 크기만큼 자유롭게 생성, 축소, 확장할 수 있기 때문에 이러한 이름이 붙었습니다. 사용자는 이 LV를 포맷하여 실제 파일 시스템으로 사용합니다.

내부 동작 메커니즘

LV를 생성하면 내부적으로 **LE(Logical Extent)**라는 단위가 만들어집니다. LVM의 핵심 기술은 이 **LE와 VG에 있는 PE를 1:1로 매핑(Mapping)**하는 것입니다. 만약 사용자가 LV의 용량을 10GB 확장한다고 명령하면, LVM은 단순히 VG 풀에 남아있는 빈 PE들을 가져와 LV의 LE에 추가로 매핑 연결을 해줄 뿐입니다. 이 매핑 테이블 덕분에 데이터의 물리적 이동 없이도 즉각적인 용량 확장이 가능합니다.

모던 LVM 구축 실습 가이드

최신 리눅스 환경(CentOS 8+, Ubuntu 20.04+ 등)에서 표준적으로 사용하는 구축 명령어 흐름입니다.

# 1. 물리적 디스크를 PV로 초기화
sudo pvcreate /dev/sdb /dev/sdc
 
# 2. 초기화된 2개의 PV를 묶어 'data_vg'라는 이름의 VG 생성
sudo vgcreate data_vg /dev/sdb /dev/sdc
 
# 3. 'data_vg'의 여유 공간 중 50GB를 할당하여 'app_lv'라는 LV 생성
sudo lvcreate -n app_lv -L 50G data_vg
 
# 4. 모던 파일 시스템(ext4 또는 xfs)으로 포맷
sudo mkfs.xfs /dev/data_vg/app_lv
 
# 5. 마운트하여 사용
sudo mkdir -p /app_data
sudo mount /dev/data_vg/app_lv /app_data

⚠️ 도입 전 반드시 고려해야 할 사이드 이펙트 (Side Effects)

LVM은 강력한 유연성을 제공하지만, 아키텍처 특성상 다음과 같은 부작용과 위험성을 인지하고 방어적으로 설계해야 합니다.

1. 단일 장애점(SPOF, Single Point of Failure)의 위험성 증가 여러 개의 물리 디스크(PV)를 하나의 VG로 묶어 사용하는 경우, 그중 단 하나의 디스크만 물리적으로 고장 나더라도 전체 VG 및 연관된 LV의 데이터가 모두 손상될 수 있습니다. 이를 방지하기 위해서는 LVM 자체의 미러링 기능을 사용하거나, 하드웨어/소프트웨어 RAID(예: RAID 1, RAID 5) 위에 LVM을 구성하는 것이 필수적입니다.
2. 복구의 복잡성 파티션 테이블이 손상되었을 때 단순 파티션 방식은 복구 툴을 통해 데이터를 살려낼 확률이 비교적 높습니다. 하지만 LVM은 메타데이터(PE-LE 매핑 정보)가 손상되면 데이터가 물리적 디스크 전반에 흩어져 있기 때문에 복구 난이도가 기하급수적으로 상승합니다. 주기적인 /etc/lvm/archive 백업이 중요합니다.
3. 스냅샷 공간 고갈로 인한 시스템 정지 LVM은 스냅샷(Snapshot) 기능을 제공하여 백업 시 유용하게 사용됩니다. 하지만 스냅샷 볼륨의 용량(COW, Copy-On-Write 영역)이 가득 차게 되면, 원본 LV의 I/O 작업까지 완전히 멈추거나 스냅샷이 깨지는 사이드 이펙트가 발생합니다. 스냅샷은 항상 단기적으로만 유지하고, 충분한 여유 공간을 할당해야 합니다.