KVM / libvirt 호스트와 게스트간에 공유되는 LVM 볼륨 그룹 : 이것은 나쁜 생각입니까?


12

방금 4 개의 SATA II 하드 드라이브를 포함하고 CentOS 5.5 x86_64를 실행하는 반짝이는 새로운 KVM / libvirt 기반 가상 머신 호스트를 만들었습니다.

디스크를 qcow 이미지로 작성하는 일반적인 방법 대신 libvirt 스토리지 풀로 관리되는 LVM 볼륨 그룹에서 논리 볼륨으로 가상 머신 디스크작성 하기로 결정했습니다 .

결정할 수없는 것은 VM 호스트의 볼륨 그룹 또는 전용 볼륨 그룹에서 가상 머신 논리 볼륨을 생성해야하는지 여부입니다.

어떤 방법을 선택해야하며 그 이유는 무엇입니까?


방법 1 : VM 호스트의 볼륨 그룹 사용

이행:

  • 파일 시스템을 md0포함하는 작은 RAID1/boot
  • md1LVM 볼륨 그룹을 포함하는 나머지 공간을 차지하는 대형 RAID10 vghost. vghostVM 호스트의 루트 파일 시스템 및 스왑 파티션을 포함합니다.
  • vghost필요 에 따라 가상 머신 디스크를 논리 볼륨으로 생성

장점 :

  • VM 호스트의 루트 파일 시스템에 공간이 부족 vghost하면 비교적 쉽게 더 많은 공간을 할당 할 수 있습니다
  • 시스템이 이미 시작되어 실행 중입니다 (하지만 다시 시작할 필요는 없습니다)

단점 :

이 방법이 효과가 있다는 사실을 알았지 만 이것이 어떻게 든 나쁜 생각이라는 느낌을 떨칠 수는 없습니다. 나는 그것을 느낀다 :

  • 이것은 어떻게 든 보안 위험이 될 수 있습니다
  • 앞으로 어느 시점에서 설정에 제한이있을 수 있으며 전용 그룹을 사용하기를 바랍니다.
  • 시스템 (CentOS, libvirt 등)은 실제로 이와 같이 사용되도록 설계되지 않을 수 있으므로 VM 호스트의 파일 및 / 또는 파일 시스템을 실수로 손상 / 분실 할 수 있습니다

방법 2 : 전용 볼륨 그룹 사용

이행:

  • VM 호스트에 포함하기에 충분한 크기 (예 : 5-10GB)를 제외하고 방법 1 md0과 동일 및 동일md1md1
  • md2남은 공간을 차지하는 대형 RAID10 . 논리 볼륨을 가상 머신에서 독점적으로 사용 md2하는 LVM 볼륨 그룹을 포함합니다.vgvms

장점 :

  • vgvms호스트 OS를 망칠 염려없이 땜질 할 수 있습니다
  • 이것은 더 우아하고 안전한 솔루션처럼 보입니다.

단점 :

  • VM 호스트의 파일 시스템에 공간이 부족하면 파일 시스템의 일부 (예 : / usr 또는 / var)를로 옮겨야합니다. vgvms매우 좋지 않습니다.
  • 호스트 OS를 다시 설치해야합니다 (앞서 언급했듯이 실제로는 신경 쓰지 않습니다)

업데이트 # 1 :

방법 2에서 VM 호스트 디스크 공간 부족이 걱정되는 이유 중 하나는 VM 호스트가 가상 컴퓨터에서 모든 서비스를 실행할 수있을만큼 강력한 지 알 수 없기 때문입니다. 가상 머신에서 호스트 OS로 일부 / 모든 서비스를 마이그레이션해야 할 수도 있습니다.

VM 호스트 하드웨어 사양 :

  • 페놈 II 955 X4 블랙 에디션 프로세서 (3.2GHz, 4 코어 CPU)
  • 2x4GB Kingston PC3-10600 DDR3 RAM
  • 기가 바이트 GA-880GM-USB3 메인 보드
  • 4 개의 WD Caviar RE3 500GB SATA II HDD (7200rpm)
  • Antec BP500U Basiq 500W ATX 전원 공급 장치
  • CoolerMaster CM 690 케이스

업데이트 # 2 :

방법 1에서 시스템이 호스트 VG를 libvirt 스토리지 풀로 사용하도록 설계되지 않았다고 생각하는 한 가지 이유는 virt-manager에서 발견 한 동작입니다.

  • 추가하면 VG를 활성화 할 수 없다고 불평했습니다 (분명히 호스트 OS가 이미 활성화했기 때문에)
  • 제거 할 때 VG를 비활성화 할 수 없기 때문에 거부했습니다 (분명히 호스트 OS가 여전히 루트 및 스왑 LV를 사용하고 있기 때문에)

귀하의 솔루션 # 1이 매우 좋은 대답이 될만한 질문 (# 272324)을 만들었습니다! 그리고 이것은 내가 비슷한 설정에서했던 것과 똑같습니다. 그러나 게스트 내의 diskIO가 호스트에서 동일한 LV를 "루프 마운트"하는 것보다 느리다는 문제가 있습니다.
stolsvik

답변:


3

잘 생각 된 질문!

방법 2를 사용 하겠지만 개인적인 취향에 가깝습니다. 나에게 방법 2 단점은별로 문제가되지 않습니다. 추가 설치를 시작하지 않으면 호스트 OS가 5-10GB 파티션을 능가하는 것을 보지 못합니다. 단순성과 보안을 위해 호스트 OS는 실제로 최소한의 설치가되어야하며 관리에 필요한 최소한의 것 (예 : sshd)을 제외한 아무것도 실행하지 않아야합니다.

방법 1 단점도 실제로 문제가되지는 않습니다. IMO. 루팅 된 VM이 파티션에서 벗어날 수 있고 다른 파티션을 감염 / 손상 할 수있는 경우 별도의 VG에 호스트 OS가 있으면 아무런 차이가 없을 수 있으므로 추가적인 보안 위험이 있다고 생각하지 않습니다. 다른 두 가지 단점은 직접적인 경험을 통해 말할 수있는 것이 아니지만 CentOS, LVM 및 libvirt는 유연하고 강력하여 걱정할 필요가 없습니다.

편집-업데이트 1에 대한 응답

요즘 가상화 지원 성능이 매우 낮습니다. 특히 지원 기능이 내장 된 프로세서를 사용하면 게스트 VM에서 호스트 OS로 서비스를 이동하는 것이 가치가 있다고 생각하지 않습니다. 당신은 은 "베어 메탈"를 실행하여 10 %의 속도 향상을 얻을 수 있지만, 작은, 꽉, 보안 호스트 OS를 가지고있는 혜택을 상실, 잠재적으로 전체 서버의 안정성에 영향을 미칠 것입니다. 그만한 가치가 없습니다.

이것에 비추어, 나는 여전히 방법 2를 선호 할 것이다.

업데이트 2에 대한 응답

libvirt가 스토리지가 배치되었다고 가정하는 특정 방법은 방법 2에 유리한 또 다른 지점입니다. 내 권장 사항은 다음과 같습니다. 방법 2로 이동하십시오.


감사. 나는 내 질문에 2 가지 업데이트를 추가했으며, 왜 당신이 해결 한 몇 가지 단점을 나열했는지 설명합니다. 업데이트로 의견이 전혀 바뀌지 않습니까?
mosno

@mosno : 업데이트에 대한 응답으로 내 답변을 업데이트했습니다.
Steven 월요일

답변 해 주셔서 감사합니다. 모두 도움이되었으며 답변을받을 사람을 선택하기가 어려웠습니다. 나는 질문을 처리하기 위해 최선의 노력을 다하고 있다고 생각하기 때문에 Steven을 선택하고 있습니다. 기록을 위해, 방법 2가 더 낫다는 데 동의하지만, 방법 1이 작동하고 시간 제약 때문에 방법 1을 유지하기로 선택했습니다.
mosno

1
또한이 방법의 한계를 탐구하는 것이 교육적이라고 생각하기 때문에 지금은 방법 1을 유지하고 있습니다. 예를 들어, 게스트 OS에서 LVM PG를 장치에 직접 생성하면 (예 : 파티션 / dev / vda1 대신 장치 / dev / vda) 호스트 OS의 pvscan이 게스트의 PV를 나열한다는 것을 알았습니다. / dev / vda가 아닌 / dev / vda1을 사용하십시오).
mosno

1

언제든지 하나의 시스템 만 주어진 LV를 읽기 / 쓰기 모드로 사용하려고 시도하는 한 호스트 및 게스트에 동일한 VG를 사용하는 것이 가능합니다. 여러 시스템이 동일한 LV에 쓰려고하면 파일 시스템이 손상됩니다.


이를 관리하기 위해 복잡성이 상당히 높아졌습니다. 영리하다. 너무 영리하다.
유닉스 수위

@ user37899 : 이것이 LVM을 처리하는 일반적인 방법입니다
Javier

고맙지 만 이해합니다. 나는 그렇게 할 계획이 없었습니다.
mosno

호스트 OS에서 "lvscan"을 수행하면 게스트의 LV가 "ACTIVE"로보고됩니다. 호스트에 LV가 마운트되지 않았습니다. LV가 단순히 "ACTIVE"상태에있는 것이 "읽기 / 쓰기 모드"를 구성합니까, 아니면 호스트의 파일 시스템에 명시 적으로 마운트하는 것을 의미합니까?
mosno

나는 명백한 r / w 마운트를 의미합니다.
Ignacio Vazquez-Abrams 1

1

이것에 대해 살펴보고 싶을 수도 있고 어쩌면이 프로젝트가 어떻게 말하는지 볼 수도 있습니다.

ProxmoxVE는 RHEL의 무거운 제품 대신 libvirt의 perl implememtation을 사용하는 베어 메탈 KVM 호스트입니다. 두 시나리오를 모두 구현합니다.

가상 디스크는 .raw 및 스파 스로 .qcow와 유사하지만 더 빠릅니다.

qcow & vmdk 디스크 이미지 형식도 지원되지만 LVM 제한이 관련 될 수 있습니다. 나는 그것들을 사용하지 않으므로 그것에 대해 많이 말할 수 없습니다.

LVM 저장소는 노드의 VM간에 공유되며 DRBD 장치 일 수 있습니다.

OS의 VG 공간 공유와 관련하여 백업 할 때 스냅 샷 크기 만 고려해야합니다. 여기서이 값은 구성 파일에서 변경 될 수 있으며, 사람들이 변경해야하는 포럼에서 가끔 볼 수 있지만, 기본값은 거대한 가상 디스크에서도 몇 년 동안 나에게 도움이되었습니다.

PVE의 LVM 스토리지 세부 사항 :

http://pve.proxmox.com/wiki/Storage_Model#LVM_Groups_with_Network_Backing

VG를 배치하는 방법은 다음과 같습니다.

메타 데이터 유형 lvm2를 사용하여 볼륨 그룹 "LDatastore1"을 (를) 찾았습니다.

메타 데이터 유형 lvm2를 사용하여 볼륨 그룹 "LDatastore0"을 (를) 찾았습니다.

메타 데이터 유형 lvm2를 사용하여 볼륨 그룹 "pve"를 찾았습니다.

이들은 내 LV입니다.

ACTIVE '/ dev / LDatastore1 / vm-9098-disk-1'[4.00GB] 상속

ACTIVE '/ dev / LDatastore1 / vm-7060-disk-1'[2.00GB] 상속

ACTIVE '/ dev / LDatastore1 / vm-5555-disk-1'[8.00GB] 상속

ACTIVE '/ dev / LDatastore0 / vm-4017-disk-1'[8.00GB] 상속

ACTIVE '/ dev / LDatastore0 / vm-4017-disk-2'[512.00GB] 상속

ACTIVE '/ dev / LDatastore0 / vm-7057-disk-1'[32.00GB] 상속

ACTIVE '/ dev / LDatastore0 / vm-7055-disk-1'[32.00GB] 상속

활성 '/ dev / LDatastore0 / vm-6030-disk-1'[80.01GB] 상속

활성 '/ dev / pve / swap'[3.62GB] 상속

활성 '/ dev / pve / root'[7.25GB] 상속

활성 '/ dev / pve / data'[14.80GB] 상속

이것은 6 7200 rpm Seagate Barracuda SATA 드라이브로 구성된 RAID10의 LVM입니다.

CPU BOGOMIPS : 53199.93

정규식 / 초 : 824835

HD 크기 : 19.69GB (/ dev / mapper / LDatastore0-testlv)

버퍼링 된 읽기 : 315.17MB / 초

평균 검색 시간 : 7.18ms

FSYNCS / 초 : 2439.31

그리고 이것은 단일 Intel X25-E SATA SSD의 LVM이며 VM이 살고있는 앞에서 언급 한 / dev / pve / data와 동일한 VG입니다.

CPU BOGOMIPS : 53203.97

정규식 / 초 : 825323

HD 크기 : 7.14GB (/ dev / mapper / pve-root)

버퍼링 된 읽기 : 198.52MB / 초

평균 검색 시간 : 0.26ms

FSYNCS / 초 : 1867.56

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.