다른 VM의 기본 이미지로 사용하기에 더 나은 이미지 형식 (raw 또는 qcow2)은 무엇입니까?


25

기본 이미지를 사용하고 있으며 많은 VM을 만드는 데 기반합니다. 그리고 이제 기본 이미지에 사용하기에 더 나은 qcow2 또는 raw를 알고 싶습니다. 또한 전체 디스크를 복제하는 대신이 기본 이미지를 사용하면 어떤 이점이 있는지 알려주십시오. 속도는 한 가지 요소가 될 수 있지만 효율성 측면에서 기본 이미지를 사용한 다음 해당 기본 이미지를 사용하여 VM을 만드는 데 문제가 있습니까?

편집 1 :

나는 몇 가지 실험을 수행하고 여기에 이미지 설명을 입력하십시오여기에 이미지 설명을 입력하십시오여기에 이미지 설명을 입력하십시오

첫 번째는 기본 이미지와 오버레이가 모두 qcow2 인 경우입니다. 두 번째 baseimage는 원시이지만 오버레이는 qcow2이고 세 번째 경우에는 각 원시 디스크 이미지를 각 VM에 제공합니다. 놀랍게도, 마지막 경우는 다른 두 경우에 비해 훨씬 더 효율적입니다.

실험 설정 : 
baseimage의 OS : Ubuntu Server 14.04 64 비트.
호스트 OS : Ubuntu 12.04 64bit
램 : 8GB
프로세서 : 인텔 ® 코어 ™ i5-4440 CPU @ 3.10GHz × 4 
디스크 : 500GB 

x 축 : 동시에 부팅 된 VM 수. 1에서 시작하여 최대 15까지 증가합니다.

y 축 : : "x"개의 컴퓨터를 부팅하는 총 시간입니다.

그래프에서 전체 디스크 이미지를 VM에 제공하는 것이 다른 두 가지 방법보다 훨씬 효율적인 것으로 보입니다.

편집 2 : 여기에 이미지 설명을 입력하십시오

각 VM에 개별 원시 이미지를 제공하는 경우에 해당합니다. 캐시 플러시를 수행 한 후 이것이 그래프입니다. raw baseimage + qcow overlay와 거의 비슷합니다.

감사.


1
qcow2 대신 원시 기본 이미지와 오버레이 QED를 사용합니다. QED는 qcow2보다 빠르며 의도적으로 손상 될 가능성이 적습니다.
Matt

@Matt는 편집 된 질문에 대해 의견을 말하십시오.
AB

성능 차이가 흥미 롭습니다. qed로 시도해 볼 수 있습니까? qcow2 구현에서 경합 / 잠금 문제 일 수 있습니다. 나는 그것이 몇 가지 문제가 있다고 믿기 때문에 그들이 qed를 발명했습니다.
Matt

1
@Matt 나는 원시 baseimage-qed 오버레이와 원시 baseimage-qcow2 오버레이로 확인했습니다. 그러나 qed는이 설정에서 qcow2보다 훨씬 느립니다.
AB

답변:


18

특정 사용 사례 (기본 이미지 + qcow2 오버레이)의 경우 RAW 형식이 선호됩니다.

  1. 더 빠릅니다. 메타 데이터가 연결되어 있지 않으므로 최대한 빠릅니다. 반면, Qcow2에는 실제 데이터를 맞추기 전에 교차해야하는 두 개의 간접 계층이 있습니다.
  2. 오버레이 레이어는 Qcow2 파일이어야하므로 항상 유용한 스냅 샷 기능을 잃지 않습니다 (RAW 이미지는 자체적으로 스냅 샷을 지원하지 않습니다)

기본 이미지 + qcow2 오버레이와 여러 개의 전체 사본 중에서 선택하는 것은 우선 순위에 따라 다릅니다.

  1. 완벽한 성능을 위해서는 폴로 케이트 된 RAW 이미지를 사용하십시오. 스냅 샷을 지원하지 않는 단점이 있습니다. 대부분의 환경에서 지불하기에는 너무 높은 가격입니다
  2. 유연성과 공간 효율성을 위해 RAW 기본 이미지 + Qcow2 오버레이를 사용하십시오.

어쨌든 Qcow2 파일이 다소 취약하다는 것을 알았습니다.

프로덕션 KVM 하이퍼 바이저의 경우 기본적으로 두 가지 다른 설정을 사용합니다.

  1. 성능이 1 위인 경우 가상 머신에 직접 연결된 LVM 볼륨을 사용하고 LVM 스냅 샷 기능을 사용하여 일관된 백업을 수행합니다.
  2. 유연성 향상을 위해 일부 성능을 희생 할 수있는 곳에서는 하나의 큰 LVM Thin Provisioned Volume + XFS + RAW 이미지를 사용합니다.

또 다른 가능성은 일반 LVM 볼륨 + XFS + RAW 이미지를 사용하는 것입니다. 유일한 단점은 일반 (씬이 아닌) LVM 스냅 샷이 매우 느리고 사용량이 많은 일반 LVM 볼륨을 스냅 샷하면 성능이 저하된다는 것입니다 (스냅 샷 수명 동안). 어쨌든 스냅 샷을 산발적으로 사용하려는 경우 더 간단하고 안전한 방법 일 수 있습니다.

일부 참조 :
KVM I / RHEL 6 O의 속도 저하
RHEL 6.1 및 페도라 16에 KVM의 스토리지 성능 및 Qcow2의 prellocation
은 Red Hat Enterprise Linux 6.2에서 KVM 스토리지 성능 및 캐시 설정
LVM 얇은 볼륨 설명


위에서 언급했듯이 : 간접 레이어가 없기 때문에 개별 RAW 이미지가 더 빨라집니다. 그러나 스냅 샷 (이미지 수준)과 공간 효율성을 포기해야합니다. 또한 세 번째 결과가 호스트 캐시에 의해 왜곡되었다는 인상을 받고 있습니다. 각 실행 사이에 "sync; echo 3> / proc / sys / vm / drop_caches"를 발행하는 모든 테스트를 다시 실행하십시오.
shodanshok

사실 나는 똑같은 생각을하고있었습니다. 그러나 실제로 사용하는 경우에도 동일한 흐름을 따릅니다.
AB

실제로는 아님 :이 테스트 환경에서는 가상 머신을 사용하지 않고 부팅하기 만하면됩니다. 실제로는 부팅 후 가상 머신이 사용되어 캐시를 오염시킵니다. 일반적으로 합리적인 사용 사례를 벤치마킹하는 것이 가장 좋습니다.
shodanshok

캐싱이 왜 그래프 1과 그래프 2에서 그다지 큰 역할을하지 않는지 아십니까 (예 : Qcow2 기본 이미지 + Qcow2 오버레이 및 Raw 기본 이미지 + Qcow2 오버레이).
AB

6

리눅스를 사용하는 경우 크기에 관계없이 raw동일한 혜택을 사용할 수 있습니다 qcow2.

... 파일 시스템이 구멍을 지원하는 경우 (예 : Linux의 경우 ext2 또는 ext3 또는 Windows의 경우 NTFS) 작성된 섹터 만 공간을 예약합니다.

https://docs.fedoraproject.org/en-US/Fedora/18/html/Virtualization_Administration_Guide/sect-Virtualization-Tips_and_tricks-Using_qemu_img.html

원시 원시 디스크 이미지 형식 (기본값). 가장 빠른 파일 기반 형식 일 수 있습니다. 파일 시스템이 구멍을 지원하는 경우 (예 : Linux의 경우 ext2 또는 ext3 또는 Windows의 경우 NTFS) 작성된 섹터 만 공간을 예약합니다. qemu-img info를 사용하여 Unix / Linux에서 이미지 또는 ls -ls에 사용 된 실제 크기를 얻으십시오.


좋은 지적! 그러나 백업 / 복사 / 압축에서는 원시 이미지 파일의 전체 크기가 사용됩니다. 디스크에 4MB 만 할당하는 20GB의 원시 파일이 20MB로 압축되었습니다
MrCalvin

이것은 나에게 완전히 새로운 것이었다. Proxmox VE에 가상 디스크가 30GB 인 VM이 있고 디스크의 크기가 호스트 파일 시스템에 있음을 알 수 있습니다. 그러나 호스트 파일 시스템의 전체 사용량은 << 10GB입니다. 이것이 바로 내가 찾던 이유입니다.
cljk
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.