他のVMのベースイメージとして使用するのに、Rawとqcow2のどちらが良いイメージ形式ですか


25

baseimageを使用しており、それに基づいて多くのVMを作成しています。そして今、ベースイメージに使用するのにqcow2とrawのどちらが良いかを知りたいです。さらに、ディスク全体のクローンを作成する代わりに、このbaseimageを使用する利点があるかどうか教えてください。速度は1つの要因になりますが、効率の観点から、baseimageを使用し、そのbaseimageを使用してVMを作成することに問題はありますか?

編集1:

実験をして ここに画像の説明を入力してくださいここに画像の説明を入力してくださいここに画像の説明を入力してください

1つ目は、baseimageとoverlayの両方がqcow2である場合です。2番目baseimageはrawであるが、オーバーレイはqcow2であり、3番目のケースでは、各VMに個別のrawディスクイメージを提供しています。驚くべきことに、最後のケースは他の2つのケースに比べてはるかに効率的です。

実験セットアップ: 
baseimageのOS:Ubuntu Server 14.04 64ビット。
ホストOS:Ubuntu 12.04 64ビット
RAM:8GB
プロセッサー:Intel®Core™i5-4440 CPU @ 3.10GHz×4 
ディスク:500 GB 

x軸上:同時に起動されるVMの数。1から始まり、15まで増分されます。

y軸上:マシンの「x」個を起動する合計時間。

グラフから、VMにディスクイメージ全体を提供することは、他の2つの方法よりもはるかに効率的であると思われます。

編集2: ここに画像の説明を入力してください

これは、各VMに個別のrawイメージを提供する場合です。キャッシュをフラッシュした後、これがグラフです。生のbaseimage + qcowオーバーレイとほぼ同じです。

ありがとう。


1
生のベースイメージを使用し、qcow2の代わりにQEDをオーバーレイします。QEDはqcow2よりも高速で、設計によって破損する可能性が低くなります。
マット

@Mattは、編集された質問にコメントしてください。
AB

パフォーマンスの違いは興味深いです。qedで試せますか?qcow2実装の競合/ロックの問題である可能性があります。私は彼らがqedを発明した理由であるいくつかの問題があると信じています。
マット

1
@Matt生のbaseimage-qedオーバーレイと生のbaseimage-qcow2オーバーレイでチェックしました。ただし、この設定では、qedはqcow2よりもかなり低速です。
AB

回答:


18

特定のユースケース(ベースイメージ+ qcow2オーバーレイ)の場合、RAW形式を優先する必要があります。

  1. より高速です。メタデータが関連付けられていないため、可能な限り高速です。一方、Qcow2には、実際のデータに到達する前に交差しなければならない2つの間接層があります
  2. オーバーレイレイヤーはQcow2ファイルである必要があるため、常に便利なスナップショット機能を失うことはありません(RAW画像はそれ自体ではスナップショットをサポートしません)

ベースイメージ+ qcow2オーバーレイと複数のフルコピーのどちらを選択するかは、優先度によって異なります。

  1. 絶対的なパフォーマンスを得るには、fallocated RAW画像を使用します。これにはスナップショットがサポートされていないという欠点があります。ほとんどの環境では高すぎるのでお支払いできません
  2. 柔軟性とスペース効率のために、RAWベースイメージ+ Qcow2オーバーレイを使用します。

とにかく、Qcow2ファイルはやや壊れやすいことがわかりました。

実稼働KVMハイパーバイザーの場合、基本的に2つの異なるセットアップを使用します。

  1. パフォーマンスが1位である場合、仮想マシンに直接接続されたLVMボリュームを使用し、LVMスナップショット機能を使用して一貫性のあるバックアップを作成します
  2. 柔軟性を高めるためにパフォーマンスをいくらか犠牲にする場合は、単一の大きなLVMシンプロビジョニングボリューム+ XFS + RAWイメージを使用します

別の可能性は、通常のLVMボリューム+ XFS + RAWイメージを使用することです。唯一の欠点は、通常の(非シン)LVMスナップショットが非常に遅く、ビジーな通常のLVMボリュームのスナップショットを作成するとパフォーマンスが低下することです(スナップショットの存続期間)。とにかく、スナップショットの散発的な使用のみを使用する場合、これはより簡単で安全な方法です。

参考資料:
RHEL 6 KVMストレージパフォーマンスでのKVM I / Oの
速度低下とRHEL 6.1およびFedora 16でのQcow2の事前割り当て
Red Hat Enterprise Linux 6.2 LVMシンボリュームでのKVMストレージパフォーマンスとキャッシュ設定の
説明


前述のように、間接レイヤーがないため、個々のRAW画像は高速になります。ただし、スナップショット(イメージレベル)とスペース効率を放棄していることに注意してください。さらに、私はあなたの3番目の結果がホストキャッシュによって歪められた印象を受けています。確かに、各実行の間に「sync; echo 3> / proc / sys / vm / drop_caches」を発行するすべてのテストをやり直してください。
shodanshok

実際、私は同じことを考えていました。しかし、実際の使用の場合も同じ流れに従うと思いました。
AB

そうではありません:このテスト環境では、仮想マシンを使用せずに単に起動しています。実際のケースでは、起動後に仮想マシンが使用され、キャッシュが汚染されます。一般的に、合理的なユースケースでベンチマークするのが最善です。
shodanshok

グラフ1とグラフ2でキャッシングがそれほど重要な役割を果たしていない理由、つまりQcow2ベースイメージ+ Qcow2オーバーレイとRawベースイメージ+ Qcow2オーバーレイがあります。
AB

6

Linuxを使用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

raw Rawディスクイメージ形式(デフォルト)。これは、最速のファイルベース形式です。ファイルシステムがホールをサポートしている場合(たとえば、Linuxではext2またはext3、WindowsではNTFSで)、書き込まれたセクターのみがスペースを予約します。qemu-img infoを使用して、イメージで使用される実際のサイズを取得するか、Unix / Linuxでls -lsを使用します。


いい視点ね!ただし、バックアップ/コピー/圧縮では、生のイメージファイルのサイズ全体が使用されるようです。ディスク上に4MBのみを割り当てる20GBのrawファイルが20MBに圧縮されました
MrCalvin

これは私にとって全く新しいものでした。Proxmox VEに30 GBの仮想ディスクを持つVMがあります...そして、ホストファイルシステムでディスクのサイズがあることがわかります。ただし、ホストファイルシステムの使用量はすべて<< 10GBです。今、それが私が探していた理由です。
cljk
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.