원문 보기: https://dawoum.duckdns.org/wiki/Logical_Volume_Manager_(Linux)
리눅스에서, Logical Volume Manager (LVM)는 리눅스 커널에 대한 논리적 볼륨 관리를 제공하는 장치 매퍼 프레임워크입니다. 대부분의 최신 리눅스 배포판은 루트 파일 시스템을 논리적 볼륨에 둘 수 있을 정도로 LVM을 인식합니다.
Heinz Mauelshagen은 Sistina Software에서 근무하던 1998년에 원래 LVM 코드를 작성했으며, 이 코드의 주요 설계 지침은 HP-UX의 볼륨 관리자에서 따왔습니다.
Introduction
LVM은 마땅한 사용처가 없어서 사용해 보지 않은 기술 중 하나입니다. 최근 하드 디스크의 베드 블록으로 인해, 전체 2T의 디스크를 베드가 있는 뒤쪽 부분을 버리고 앞쪽 부분 1T을 잘라서 1년 넘게 사용했습니다. 그 후에 1T 부분에서 또 다시 문제가 발생해서, 굳이 베드 위치는 확인하지 않았지만, 맨 끝의 490G 정도를 잘라서 베드 테스트 후에 사용 중입니다.
이러다 보니, 다음에 사용 중인 맨 끝 부분에서 문제가 발생하면, 아마도 200G 정도씩 10개를 잘라서 베드가 없는 부분을 사용할 예정입니다.
이 디스크는 어느 순간 접근이 되지 않을 수도 있기 때문에, 임시 데이트를 저장하는 용도로 사용 중이고, 현재는 60G 정도를 사용 중입니다.
어쨌든, 과거의 경험으로는 대체로 500G 내외로 주로 사용했기 때문에, 200G 정도로 나누어서 문제 없는 한 부분을 사용하는 것보다 2개 정도를 붙여서 400G의 한 파티션으로 사용하는 것이 좋을 것으로 생각됩니다.
따라서, 그때가 되면, 이 기술을 이용해 볼 것이기 때문에, 미리 정리해 둡니다.
아래는 여기의 내용 중에 일부를 발췌한 것입니다:
- pvcreate /dev/sdb2
- pvcreate /dev/sdb5
- vgcreate myvg /dev/sdb2
- vgextend myvg /dev/sdb5
- lvcreate -L 400G -n mylv myvg
- mkfs -t ext4 /dev/myvg/mylv
Kernel options
아래는 필요한 커널 옵션입니다. 이것은 젠투 위키에서 가져왔고, 리눅스 커널 4.9 버전에 대한 내용이라서 그 이후 커널에서는 보다 많은 옵션이 생겼습니다.
Device Drivers --->
Multiple devices driver support (RAID and LVM) --->
<*> Device mapper support
<*> Crypt target support
<*> Snapshot target
<*> Mirror target
<*> Multipath target
<*> I/O Path Selector based on the number of in-flight I/Os
<*> I/O Path Selector based on the service time
Uses
LVM은 다음 목적에 대해 사용됩니다:
- 여러 개의 물리적 볼륨이나 전체 하드 디스크로 구성된 단일 논리적 볼륨을 생성하여 (RAID 0과 약간 비슷하지만, JBOD와 더 비슷함), 동적 볼륨 크기 조정을 허용합니다.
- 핫 스와핑을 결합하여 다운타임이나 서비스 중단 없이 디스크를 추가하고 교체하도록 허용함으로써 대규모 하드 디스크 팜을 관리합니다.
- 소규모 시스템 (예를 들어, 데스크탑)에서, 설치 시점에 파티션 크기를 추정할 필요 없이 LVM을 사용하면 필요에 따라 파일 시스템 크기를 쉽게 조정할 수 있습니다.
- 논리 볼륨의 스냅샷을 찍어 일관된 백업을 수행합니다.
- 하나의 비밀번호로 여러 개의 물리적 파티션을 암호화합니다.
LVM은 하드 디스크와 파티션의 꼭대기의 얇은 소프트웨어 계층으로 여겨질 수 있으며, 하드 드라이브 교체, 재파티셔닝과 백업을 관리하기 위한 연속성과 사용 편의성을 추상화합니다.
Features
Basic functionality
- 볼륨 그룹 (VG)은 새로운 물리적 볼륨 (PV)을 흡수하거나 기존 볼륨을 꺼냄으로써 온라인에서 크기를 조정할 수 있습니다.
- 논리 볼륨 (LV)은 익스텐트를 연결하거나 익스텐트를 잘라내는 방식으로 온라인에서 크기를 조정할 수 있습니다.
- LV는 PV 사이로 이동할 수 있습니다.
- 쓰기 시 복사 (CoW) 기능을 활용한, 논리 볼륨 (LVM1)의 읽기 전용 스냅샷의 생성, 또는 읽기/쓰기 스냅샷 생성 (LVM2)
- VG는 분할된 부분을 가로지르는 LV가 없는 한 그 자리에서 분할되거나 병합될 수 있습니다. 이것은 전체 LV를 오프라인 저장소로 마이그레이션하거나 오프라인 저장소에서 마이그레이션할 때 유용할 수 있습니다.
- LVM 대상은 관리 편의를 위해 태그가 지정될 수 있습니다.
- lvmetad 데몬의 사용을 통해 놓여있는 장치가 사용 가능해짐에 따라 VG와 LV를 활성화할 수 있습니다.
Advanced functionality
- 하이브리드 볼륨은 dm-cache 타켓을 사용하여 생성될 수 있으며, 이를 통해 플래시-기반 SSD와 같은 하나 이상의 빠른 저장 장치가 하나 이상의 느린 하드 디스크 드라이브에 대한 캐시 역할을 할 수 있습니다.
- 씬 프로비저닝된 LV는 풀에서 할당될 수 있습니다.
- 최신 버전의 장치 매퍼에서, LVM은 lvm.conf에서 devices/multipath_component_detection=1이 설정되었으면 dm-multipath 장치를 백업하는 개별 경로를 무시할 만큼 나머지 장치 매퍼와 통합됩니다. 이렇게 하면 LVM이 다중-경로 장치 대신 개별 경로에서 볼륨을 활성화하지 못합니다.
RAID
- RAID 1, 5, 및 6을 포함한 RAID 기능을 포함하도록 LV를 생성할 수 있습니다.
- RAID 0과 유사하게 전체 LV 또는 일부를 여러 PV에 걸쳐 스트라이프할 수 있습니다.
- RAID 1 백엔드 장치 (PV)는 "write-mostly"로 구성될 수 있으며, 필요하지 않는 한 그러한 장치에 대한 읽기가 방지됩니다.
- lvchange --raidmaxrecoveryrate 및 lvchange --raidminrecoveryrate를 사용하여 복구율을 제한하면 RAID 기능이 포함된 LV를 재구축하는 동안 허용 가능한 I/O 성능을 유지할 수 있습니다.
High availability
LVM은 역시 PV를 보관하는 디스크가 여러 호스트 컴퓨터 사이에 공유되는 공유 스토리지 클러스터에서 작동하지만, 잠금 형식을 통해 메타데이터 접근을 중재하는 추가 데몬이 필요할 수 있습니다.
CLVM 분산 잠금 관리자는 동시 LVM 메타데이터 접근을 중개하기 위해 사용됩니다. 클러스터 노드가 LVM 메타데이터를 수정해야 할 때마다, 클러스터에서 다른 clvmd 데몬과 지속적으로 연락하고 특정 대상의 집합에 대한 잠금을 얻고자 하는 의사를 전달할 수 있는 지역 clvmd로부터 권한을 확보해야 합니다. HA-LVM 클러스터-인식은 고가용성 기능을 제공하는 응용 프로그램에 맡겨집니다. LVM의 부분에 대해, HA-LVM은 CLVM을 잠금 메커니즘으로 사용하거나, 기본 파일 잠금을 계속 사용하고 적절한 태그를 가지는 LVM 대상에만 접근을 제한함으로써 "충돌"을 줄일 수 있습니다. 이 간단한 해결책은 경합을 완화하는 것이 아니라 피하기 때문에, 동시 접근이 허용되지 않으므로, HA-LVM은 액티브-패시브 구성에서만 유용한 것으로 고려됩니다. lvmlockd 2017년 기준, 분산 잠금 관리자에 의존 없이, LVM 객체의 잠금을 LVM의 나머지 부분에 투명하게 만듦으로써 clvmd를 대체하도록 설계된 안정적인 LVM 구성 요소가 출시되었습니다. 그것은 2016년 동안 엄청난 개발이 이루어졌습니다.
위에 설명된 메커니즘은 LVM의 저장소에 접근하는 문제만 해결합니다. 그러한 LV 꼭대기에 있도록 선택된 파일 시스템은 자체적으로 클러스터링을 지원해야 하거나 (예를 들어, GFS2 또는 VxF), 언제든지 단일 클러스터 노드에서만 마운트해야 합니다 (예를 들어, 액티브-패시브 구성).
Volume group allocation policy
LVM VG는 그것에서 생성된 새 볼륨에 대한 기본 할당 정책을 포함해야 합니다. 이것은 나중에 lvconvert -A 명령을 사용하여 각 LV에 대해 변경되거나, vgchange --alloc를 통해 VG 자체에서 변경될 수 있습니다. 조각화를 최소화하기 위해, LVM은 먼저 가장 엄격한 정책 (연속)을 시도하고 그런-다음 할당이 마침내 성공할 때까지 LVM 대상에 대해 정의된 가장 자유로운 정책으로 진행할 것입니다.
RAID 구성에서, 거의 모든 정책은 격리에서 각 레그에 적용됩니다. 예를 들어, LV에 cling의 정책이 있더라도, 파일 시스템을 확장해는것은 RAID 설정에서 다른 레그 중 하나에 의해 이미 사용되면 PV를 사용하여 LVM을 초래하지 않을 것입니다. RAID 기능을 갖는 LV는 각 레그를 다른 PV에 배치하여, 다른 PV를 임의의 다른 주어진 레그에서 사용할 수 없게 만듭니다. 만약 이것이 사용 가능한 유일한 옵션이라면, LV의 확장은 실패합니다. 이런 의미에서, cling의 숨겨진 논리는 어레이의 각 개별 레그를 확장하는 데만 적용할 것입니다.
사용 가능한 할당 정책은 다음과 같습니다:
- Contiguous – 주어진 LV에서 모든 LE를 인접되고 정렬되도록 강제합니다. 이렇게 하면 조각화가 제거되지만 LV 확장성을 크게 감소시킵니다.
- Cling – LV에 의해 이미 사용된 PV에만 새 LE를 할당되도록 강제합니다. 이것은 다른 LV도 해당 PV에 익스텐트를 가질 가능성을 줄임으로써, 장치가 다운될 경우 조각화를 완화하고 특정 LV의 취약성을 줄이는 데 도움이 될 수 있습니다.
- Normal – PE의 거의-무차별적 선택을 의미하지만, (RAID 설정의 레그와 같은) 병렬 레그를 물리적 장치를 공유하는 것에서 유지하기 위해 시도할 것입니다.
- Anywhere – 어떠한 제한도 부과하지 않습니다. RAID 설정에서 매우 위험한데, 왜냐하면 그것이 격리 요구 사항을 무시하고, RAID의 대부분 이점을 훼손하기 때문입니다. 선형 볼륨에 대해, 그것은 조각화를 증가한 결과를 초래할 수 있습니다.
Implementation
전형적으로, 각 물리적 볼륨의 첫 번째 메가바이트에는 "LVM 헤더" 또는 "LVM 헤드"라고 참조되는 대부분 ASCII-인코딩된 구조가 포함됩니다. 원래, LVM 헤드는 중복성 (부분적인 하드웨어 오류의 경우)을 위해 각 PV의 첫 번째 메가바이트와 마지막 메가바이트에 쓰도록 사용됩니다; 어쨌든, 이것은 나중에 첫 번째 메가바이트로만 변경되었습니다. 각 PV의 헤더는 모든 다른 PV와 LV의 UUID, 및 PE에서 LE로의 할당 맵을 포함하여, 전체 볼륨 그룹의 레이아웃의 완전한 사본입니다. 이렇게 하면 PV가 손실되면 데이터 복구가 간소화됩니다.
리눅스 커널의 2.6-시리즈에서, LVM은 가상 블록 장치를 만들고 그 컨텐츠를 다른 블록 장치에 매핑하기 위한 간단한 블록-수준 체계, 장치 매퍼의 관점에서 구현됩니다. 이를 통해 LVM을 구현하는 데 필요한 상대적으로 디버깅-하기-어려운 커널 코드의 총양을 최소화할 수 있습니다. 그것은 역시 I/O 리다이렉션 서비스를 다른 볼륨 관리자 (예를 들어, EVMS)와 공유되도록 허용합니다. 임의의 LVM-특정 코드는 사용자-공간 도구로 푸시되며, 이 도구는 단지 이들 매핑을 조작하고 각 호출 시 디스크 메타데이터에서 그것들의 상태를 재구성합니다.
볼륨 그룹을 온라인으로 전환하기 위해, "vgchange" 도구를 사용하십시오:
- 모든 사용 가능한 블록 장치에서 PV를 검색합니다.
- 발견된 각 PV에서 메타데이터 헤더를 구문 분석합니다.
- 모든 표시 가능한 볼륨 그룹의 레이아웃을 계산합니다.
- 온라인으로 전환될 볼륨 그룹에서 각 논리 볼륨을 반복합니다, 그리고:
- 온라인으로 전환될 논리 볼륨의 모든 PV가 표시되는지 확인합니다.
- 새로운 빈 장치 매핑을 만듭니다.
- 논리 볼륨이 속한 PV의 데이터 영역에 ("선형" 대상을 갖는) 그것을 매핑합니다.
같은 볼륨 그룹의 PV 사이에 온라인 논리 볼륨을 이동하기 위해, "pvmove" 도구를 사용하십시오:
- 대상에 대한 새롭고 빈 장치 매핑을 만듭니다.
- "미러" 대상을 원본과 목적지 맵에 적용합니다. 커널은 미러를 "저하됨" 모드로 시작하고 원본에서 목적지로 동기화 속으로 그것을 가져오기 위해 데이터를 복사하여 동기화합니다.
- 미러가 동기화될 때, 원본 매핑을 목적지로 바꾸고, 그 후에 원본을 파기합니다.
이들 장치 매퍼 연산은 응용 프로그램이나 파일 시스템이 놓여있는 저장소가 이동하고 있다는 사실을 인식하지 못한 채 투명하게 수행됩니다.
Caveats
- 리눅스 커널 2.6.31까지,[15] 쓰기 장벽이 지원되지 않았습니다 (2.6.33에서 완전히 지원됩니다). 이것은 ext3와 XFS와 같은 저널링 파일 시스템에 의해 제공되는 파일 시스템 손상에 대항하는 보장이 일부 상황 아래에서 무효화됨을 의미합니다.
- 2015년 기준, LVM에 대한 온라인 또는 오프라인 조각-모으기 프로그램은 존재하지 않습니다. 이것은 볼륨이 확장되고 위에-언급된 할당 정책을 적용함으로써 오직 발생하는 조각화에 의해 다소 완화됩니다. 어쨌든, 조각화는 여전히 발생하고, 이를 줄이려면, 비-연속 익스텐트를 식별하고 pvmove 명령을 사용하여 수동으로 재정렬해야 합니다.
- 대부분의 LVM 설정에서, LVM 헤드의 오직 하나의 사본이 각 PV에 저장되며, 이는 볼륨을 실패한 디스크 섹터에 더 취약하도록 만들 수 있습니다. 이 행위는 vgconvert --pvmetadatacopies를 사용하여 덮어쓸 수 있습니다. LVM이 첫 번째 사본을 사용하여 적절한 헤더를 읽을 수 없으면, 백업 헤더에 대해 볼륨의 끝을 확인합니다. 대부분의 리눅스 배포판은 /etc/lvm/backup에 실행 중인 백업을 보관하며, 이는 vgcfgrestore 명령을 사용하여 손상된 LVM 헤드를 수동으로 다시 쓰도록 활성화합니다.
Further reading
- Lewis, AJ (2006-11-27). "LVM HOWTO". Linux Documentation Project. Retrieved 2008-03-04..
- Template:US patent reference (fundamental patent).
- "RedHat Linux: What is Logical Volume Manager or LVM?". techmagazinez.com. 6 August 2013. Archived from the original on 10 August 2013. Retrieved 4 September 2013.
- "LVM2 Resource Page". sourceware.org. 8 June 2012. Retrieved 4 September 2013.
- "How-To: Install Ubuntu on LVM partitions". Debuntu.org. 28 July 2007. Retrieved 4 September 2013.
- "Logical Volume Manager". markus-gattol.name. 13 July 2013.