Skip to content

Logical Volume Manager

Wikimedia_-_Lvm.svg.png

리눅스에서 논리 볼륨 관리자(Logical Volume Manager, LVM)는 리눅스 커널에 논리 볼륨 관리 기능을 제공하는 장치 매퍼 대상이다. 현대의 대부분의 리눅스 배포판들은 논리 볼륨 위에 자신만의 루트 파일 시스템을 가질 수 있는 지점에 대하여 LVM을 인식한다.

Heinz Mauelshagen는 HP-UX 볼륨 관리자로부터의 주요 설계 지침을 취하면서 1998년에 LVM 코드 원본을 작성하였다.

Category

  • CentOS:ResizeLVM: CentOS7최소 설치시 기본적으로 잡혀 있는 /home 디렉토리의 용량 크기를 조정하는 방법에 대한 설명.

About LVM

LVM 은 Logical Volume Manager 의 약자로서, 저장장치들을 좀더 효율적이고 유연하게 관리할 수 있는 커널의 부분과 프로그램을 말한다. 처음에는 IBM에서 개발되었는데, 그후에 OSF(현재는 OpenGroup)에서 차용을 하여 OSF/1 operating system 에서 쓰였다. 지금은 HP-UX, Digital Unix operating system, AIX 등의 상용 유닉스에서 쓰고 있다. 리눅스 버전은 현재 HP-UX의 것을 모델로 하여 Sistina Software 사에서 open source로 개발하고 있다.

LVM 을 이해하려면 먼저 Software RAID (Redundant Array of Inexpensive Drives)를 언급해야 하는데, 이 둘은 비슷하면서도 큰 차이가 있다. 비슷한 점은 여러 물리적인 디스크들을 하나의 논리적인 디스크처럼 다룰 수 있게 함으로서 조합방법에 따라 고용량, 고속, 데이터의 무결성을 실현하는 점이다. 하지만 분명하게 다른 점이 있는데. lvm은 raid보다 관리 및 확장이 비교적 쉬운 반면, raid에는 lvm에는 없는 disk mirroring(RAID level 1), Parity Stripe (RAID level 4,5) 등의 방식이 있어서 속도 또는 데이터의 무결성을 보장 받을 수 있다.

그러나 이런 차이점에도 불구하고 lvm가 주목을 받는 이유는 다음과 같다.

  • 쉬운 관리.
  • 서로 다른 많은 디바이스 조합 지원.
  • 직관적인 저장 장치로의 접근.
  • 뛰어난 확장성.
  • 믿을만한 안전성과 효율.
  • 스냅샷 기능 지원.

이와 같은 특징들로 인해 사용자들이 얻는 이득은 많다.

우선, pc 급 시스템 사용자들의 가장 큰 고민 중의 하나가 시스템을 처음 설치할 때에 파티션의 구성을 어떻게 할 것인가 일 것이다. 파티션은 한번 구성해 놓으면 바꾸기가 쉽지 않기 때문이다. 또 파티션이 가득 차기라도 하면 어렵게 백업을 하거나 눈물을 머금고(?) 자료를 지워야 할 경우도 심심치 않게 생기기 마련이다. 하지만 LVM를 쓰면 간단하게 저장공간을 확장, 축소 할 수 있기 때문에 그런 고민을 덜 수 있다.

다른 예로, 중소형 서버에서는 비교적 적은 비용으로 대용량 저장 장치를 구현하는 것이 가능해진다. 그리고, 백업 없이 기존의 환경을 유지한 채 확장이 가능하기 때문에 (물론 백업은 언제나 중요하다.) 유지보수면에서 상당한 이득이 있을 것이다.

중요사항

LVM은 물리적인 볼륨을 논리적으로 바꾸는 역할을 한다. 즉, 파일 시스템 (Filesystem)이 아니다. 간단히 설명해서 하드 디스크의 파티션을 논리적으로 유연하게 관리할 수 있도록 도와준다.

Terms

물리볼륨 (PV; Physical Volume)
물리볼륨 은 일반적으로 하드디스크 파티션이나 RAID 장치와 같이 하드디스크 파티션과 비슷하게 보이는 장치를 지칭한다.
논리볼륨 (LV; Logical Volume)
여러 물리볼륨이 논리볼륨 을 이룬다. LVM에서 논리볼륨은 LVM를 사용하지않는 시스템의 하드디스크 파티션과 유사하다. 논리볼륨은 /home이나 /usr와 같은 파일시스템을 포함할 수 있다.
볼륨그룹 (VG; Volume Group)
이런 논리볼륨이 모여서 볼륨그룹 을 이룬다. LVM에서 볼륨그룹은 LVM을 사용하지않는 시스템의 물리적 하드디스크와 유사하다. 볼륨그룹은 여러 논리볼륨을 모아서 관리상 하나의 단위로 만든다.
물리적 범위 (PE; Physical Extent)
물리볼륨은 PE 라는 기본 단위로 나눠진다. 물리적 범위의 크기는 자유롭지만, 같은 볼륨그룹에 속한 물리볼륨끼리는 같다. 한 물리볼륨안에서 PE는 유일한 번호를 가진다. PE는 LVM이 물리적 저장공간을 가리키는 최소 단위이다.
논리적 범위 (LE; Logical Extent)
각각의 논리볼륨은 LE 라는 가리킬 수 있는 기본 단위들로 나눠진다. 같은 볼륨그룹에서 논리적 범위의 크기는 물리적 범위의 크기와 같다. 또, 한 볼륨그룹안에 있는 모든 논리볼륨의 LE 크기도 당연히 같다.
볼륨그룹 지시자영역 (VGDA; Volume Group Descriptor Area)
아마도 논리볼륨과 볼륨그룹에 대한 모든 메타정보가 저장되는 장소가 궁금할 것이다. LVM을 사용하지 않는 시스템의 비유를 들자면 파티션에 대한 정보는 파티션표에 저장된다. LVM에서 볼륨그룹 지시자영역 (VGDA, Volume Group Descriptor Area) 은 파티션표와 같은 기능을 한다. VGDA는 각 물리볼륨의 처음부분에 저장된다. VGDA에는 다음과 같은 정보가 있다.
  • PV 지시자(descriptor) 한개
  • VG 지시자 한개
  • LV 지시자들
  • 여러 PE 지시자들.

어떻게 LVM이 동작하나

각 PE는 물리볼륨에서 유일한 번호를 가지지만, 논리볼륨에서는 가질 수 없다. 이는 논리볼륨이 여러 물리볼륨으로 구성되므로 PE ID가 겹칠 수 있기 때문이다. 그래서 'LE'와 'LE와 연결된 PE'를 구별할 LE ID가 필요하다. 이미 말했듯이 LE와 PE는 1:1대응한다. 저장공간을 접근하여 실제 자료를 물리적 저장공간에 쓸때 LE ID를 사용한다.

시스템이 부팅할때 LV와 VG들이 활성화되고 VGDA가 메모리로 읽혀진다. VGDA는 LV가 실제로 어디에 저장되있는지 알려준다. 시스템이 저장장치에 접근할때 실제 입출력을 할 물리적 위치를 알아내기위해 (VGDA의 도움으로) 대응 과정을 거친다.

물리적인 디스크는 fdisk로 파티션을 분할 하지만, 논리적인 LVM디스크는 lvcreate 명령어로 분할한다. (logical volume)

List of command

vgs
Report information about volume groups.
vgdisplay
볼륨 그룹(VG)을 출력한다.
vgdisplay -v test
볼륨 그룹(VG)의 상세 정보를 출력한다. (위에선 test볼륨 그룹을 출력한다.)
pvcreate /dev/hda3
인자로 넘겨진 파티션(위에선 /dev/hda3)에 물리 볼륨(PV)을 생성한다.
vgcreate test /dev/hdb2 /dev/hda3
볼륨 그룹(VG)을 생성하며, 인자로 넘겨진 파티션을 해당 그룹에 포함한다.
lvcreate -L 50M -n test-volume test
논리 볼륨(LV)을 생성한다. (위에선 test볼륨 그룹(VG)에, 50M크기로, test-volume이란 이름으로 생성한다.)
이후, 해당 논리 볼륨(LV)에 파일 시스템을 할당할 수 있다. (e.g. mke2fs {volume_path}) 1
lvscan
전체 디스크의 논리 볼륨(LV)을 스캔한다.
lvdisplay
논리 볼륨(LV)을 출력한다.
vgextend my_volume_group /dev/hdc1
/dev/hdc1파티션을 my_volume_group볼륨 그룹에 추가한다.

Remove example

lvm 을 해체하고자 하면 만든 순서의 반대로 진행하면 된다. 

$ lvremove /dev/VG이름/LV이름
$ vgremove /dev/VG이름
$ pvremove /dev/sdb1 /dev/sdb2 /dev/sdc1

Files

/etc/lvm/lvm.conf
LVM관련 설정파일. 필터 등의 설정을 추가할 수 있다.

See also

Favorite site

Manual

References

  1. 볼륨의 경로는 vgdisplay명령으로 LV Path항목에서 확인 가능하다 ↩

  2. Logical_Volume_Manager_-_concepts_and_settings.pdf ↩