가상 머신 이미지에서 LVM 파티션을 사용해야합니까?

VM 이미지 (예 : KVM 이미지)를 만들 때 파티션에 LVM을 사용해야합니까? 예를 들어 이미지에 LVM 파티션이있는 경우 qcow2 이미지를 호스트에 마운트하려는 경우 복잡성이 추가되는 것 같습니다.

반면에 LVM 파티션의 장점은 실제 이미지보다 VM을 오프라인으로 전환하고 파티션 크기를 조정하는 것이 훨씬 쉽기 때문에 VM 이미지에서 그다지 중요하지 않은 것 같습니다.

"의존합니다."

제어하는 환경 (vmware 또는 kvm 등)에 있고 디스크 성능 QoS에 대해 직접 결정할 수있는 경우 VM 내부에서 LVM을 사용하지 않는 것이 좋습니다. 하이퍼 바이저 수준에서는 얻을 수 없었던 유연성을 많이 사지 않습니다.

하이퍼 바이저는 이미 이러한 작업을 효과적으로 수행하고 있습니다. 파일 시스템의 크기를 임의로 조정하려면 (좋은 아이디어) 각 파일 시스템마다 별도의 가상 디스크를 작성하십시오.

이 길을 따라 갈 때 생각할 수있는 한 가지. 이런 식으로 가상 디스크에 파티션을 배치 할 필요조차 없습니다. 예를 들어 /home;에 대한 가상 디스크를 만들 수 있습니다 . 그것은 /dev/vdc당신의 VM 안에 있습니다. 파일 시스템을 만들 때 mke2fs -j /dev/vdc파티션을 지정하는 대신 무언가를하십시오 .

이것은 좋은 생각이지만 ... 대부분의 도구 (및 다른 관리자)는 모든 디스크에서 파티션을 볼 것으로 기대합니다. 디스크에 단일 파티션을 배치하고 완료하는 것이 좋습니다. 그러나 파일 시스템 크기를 조정할 때 한 단계 더 나아가 야합니다. 파티션을 올바르게 정렬하는 것을 잊지 마십시오. 첫 번째 파티션을 1MB로 시작하는 것이 좋습니다.

-하이퍼 바이저 수준에서이 작업을 수행하면 파티션 크기를 조정하기 위해 VM을 재부팅해야 할 수도 있습니다. LVM을 사용하면 가상 디스크를 핫 추가 (하이퍼 바이저 / OS 조합으로 허용한다고 가정)하고 재부팅없이 파일 시스템을 확장 할 수 있습니다. 이것은 확실히 플러스입니다.

한편 클라우드 공급자를 사용하는 경우 더 미묘합니다.

Azure, GCP 또는 소규모 플레이어에 대해 잘 모르므로 도울 수 없습니다.

AWS를 사용하면 위의 조언을 따를 수 있으며 종종 괜찮습니다. EBS 볼륨 (가상 디스크)의 크기를 즉석에서 늘리고 파티션 크기 등을 조정할 수 있습니다.

그러나 일반적인 경우 모든 것을 하나의 큰 EBS 볼륨에 배치하고 LVM (또는 일반 파티션)을 사용하는 것이 좋습니다. Amazon은 각 볼륨에 대한 IOPS 제한을 제공합니다. 기본적으로이 제한은 볼륨 크기에 따라 조정됩니다. 예를 들어, gp2볼륨의 경우 GiB 당 3 IOPS (최소 100 IOPS)가 제공됩니다. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html을 참조 하십시오.

대부분의 워크로드의 경우 현재 필요에 따라 모든 파일 시스템에서 사용 가능한 모든 IOPS를 사용할 수 있습니다. 따라서 하나의 큰 EBS 볼륨을 만들고 모든 IOPS를 하나의 버킷에 넣고 파티션 / LVM으로 설정하는 것이 좋습니다.

예:

각각 100GB 크기의 독립적 인 파일 시스템 / 스왑 영역이있는 3 개의 디스크. 각각 300 IOPS를 얻습니다. 각 디스크의 성능은 300 IOPS로 제한됩니다.

디스크 1 개, 크기 300GB. 디스크의 LVM 파티션은 각각 100GB입니다. 디스크는 900 IOPS를 얻습니다. 모든 파티션은 900 IOPS를 모두 사용할 수 있습니다.

논리 볼륨은 즉시 생성, 크기 조정, 삭제가 더 쉽습니다.
은 "LVM이나하지"문제는 항상 같은 대답을 가지고 그것은 의존한다 :
당신이 디스크 (들)의 유연성을 필요로하는 경우 그것은 의미가 있습니다, 파티션 (들) 수준.
LVM에서 제공하는 유연성이 필요하지 않거나 다른 LVM 기능 을 활용하지 않으려는 경우에는 의미가 없습니다.

실제로 LV는 virt-server에서 쉽게 액세스 할 수 없기 때문에 LV를 사용하는 것이 좋습니다. 따라서 이러한 파일은 우연히 쉽게 파괴 / 이동할 수 없습니다.

LV의 다른 중요한 기능 :

• 스냅 샷을 만들 수 있습니다
• LV ( iostat)를 기준으로 디스크 IO를 분석 할 수 있습니다
• 크기 조정이 용이
• 스냅 샷을 사용하면 실행중인 시스템의 일관된 복제본을 만들 수 있습니다

복잡성을 줄이기 위해 LV를 디스크가 아닌 파티션으로 사용합니다. 단점은 "디스크"의 마지막 파티션 크기 만 쉽게 조정할 수 있다는 것입니다. 그러나 표준 VM 디스크 레이아웃은이를 고려합니다 (마지막 파티션에는 중요한 응용 프로그램 데이터가 포함됨).

유연성 외에도 LVM 기반 VM 이미지는 파일 시스템을 통해 액세스되지 않기 때문에 오버 헤드가 적습니다. 반면에 파일과 마찬가지로 이미지를 쉽게 이동할 수있는 수단을 제거합니다. 불가능하지는 않지만 조금 더 복잡합니다.

내 자신의 경험 ....

ext4 파일 시스템에 lvm2와 함께 논리 볼륨 (lv)을 사용하고 싶었습니다. 디스크가 아니라 단순히 fs에 대한 파티션되지 않은 원시 디스크로 사용하십시오.

내가 찾은 것은 initrd 단계에서 VM 시작이 중지된다는 것입니다. /etc/fstab항목을 주석 처리 하면 시스템이 부팅됩니다. /etc/fstab의견을 남기는 것은 내가 살기 좋은 해결책이 아니었다. 그래서 일반 디스크 이미지 (여전히 논리 볼륨)를 fdisk생성하고 하나의 파티션으로 분할하여 파일 시스템을 생성했습니다. 더 이상 문제가 없습니다.

내 관련 마운트는 /etc/fstabUUID를 사용 하고 있었습니다.

파일 또는 파일 시스템 사용에 대해 생각했지만 반대했습니다.

필자의 경우 데비안 Jessie 기반 시스템 Devuan을 사용하고 있습니다.

실제로 하이퍼 바이저 수준의 백업 스토리지에는 LVM 만 사용하며 이미지 파일은 새용입니다. 게스트 수준에서도 사용하는 것이 좋습니다. 개별 스토리지 소스 풀링의 이점을 얻지 못하거나 사용 가능한 총 디스크 공간을 늘리는 것이 더 쉽다는 것은 사실입니다 (하이퍼 바이저가 제공하는 크기를 조정하는 것만으로 쉽게 얻을 수 있기 때문에) 때로는 하나의 파일 시스템에 너무 많은 할당 . / opt에서 1 개의 공연을 가져 와서 / var에주는 쉬운 방법을 원할 수 있습니다 (예 :). VM 자체에서 일반 파티션을 수행하는 경우 크기 조정 측면이 훨씬 더 어려워집니다.

여기에있는 다른 좋은 대답 외에도 VM 내에서 LVM을 사용해야하는 유일한 이유는 테스트 환경에서 LVM을 실제로 실험하고 경험해 볼 수 있기를 원하기 때문입니다.

다양한 하우투와 튜토리얼을 살펴보고, 일반적인 LVM 관리 방법을 연습하고, 다양한 실패 시나리오를 설정하고,이를 해결하는 방법을 배울 수 있습니다.

즉, 자기 교육 보조 도구.

편집 : 아래는 더 이상 사실이 아닙니다. VM 디스크 이미지에 LVM에서 제공하는 씬 프로비저닝을 사용하는 가치는 상황에 따라 달라질 수 있습니다.

랩톱에서 Development VM을 실행하고 있습니까? 그렇다면 QCow2를 사용하는 것이 좋습니다.

여러 디스크에서 방대한 양의 스토리지를 사용할 수있는 VM 팜을 관리하고 있습니까? LVM은 해당 스토리지를 관리하는 좋은 방법 일 것입니다.

lvm을 사용 하지 않는 한 가지 이유 는 lvm을 사용하여 스토리지를 오버 커밋 할 수 없기 때문입니다. 100GB의 스토리지로 10 개의 VM을 생성하는 경우 10 개의 VM 중 9 개가 20GB의 파일 시스템 만 사용하더라도 1000GB의 실제 디스크가 필요합니다. 스파 스 디스크 이미지 또는 qcow2 형식 이미지는 게스트가 실제로 사용하는 스토리지 만 할당 할 수 있음을 의미 할 수 있습니다.

이것이 실제로 유용한 지 여부는 스토리지에서 필요한 것에 달려 있습니다.