web-dev-qa-db-ja.com

KVM / libvirtホストとゲスト間で共有されるLVMボリュームグループ：これは悪い考えですか？

4つのSATA IIハードドライブを含み、CentOS 5.5 x86_64を実行している、光沢のある新しいKVM/libvirtベースの仮想マシンホストを構築しました。

Qcowイメージとしてディスクを作成する通常の方法ではなく、libvirtストレージプールとして管理されるLVMボリュームグループで仮想マシンディスクを論理ボリュームとして作成するにすることにしました。

決定できないことは、仮想マシンの論理ボリュームをVMホストのボリュームグループに作成するか、専用のボリュームグループに作成するかです。

どの方法を選択する必要がありますか、そしてその理由は何ですか？

方法1：VMホストのボリュームグループを使用する

実装：

  • 小さなRAID1 md0を含む/boot ファイルシステム
  • 大RAID10 md1は、LVMボリュームグループvghostを含む残りのスペースを占有しています。 vghostにはVMホストのルートファイルシステムとスワップパーティションが含まれます
  • 必要に応じて、vghostに論理ボリュームとして仮想マシンディスクを作成します

長所：

  • VMホストのルートファイルシステムのスペースが不足している場合、vghostから比較的簡単に追加のスペースを割り当てることができます
  • システムはすでに稼働しています（ただし、最初からやり直すことは大したことではありません）

短所：

この方法がうまくいくように見えるという事実を否定して、私はこれがどういうわけか悪い考えであるという気持ちを揺るがすことができません。私はそのように感じる：

  • これはどういうわけかセキュリティリスクになるかもしれません
  • 将来のある時点で、セットアップにいくつかの制限が見つかる可能性があり、専用グループを使用したい
  • システム（CentOS、libvirtなど）は、実際にはこのように使用するように設計されていない可能性があるため、ある時点で誤ってVMホストのファイルまたはファイルシステム、あるいはその両方を破損/失う可能性があります。

方法2：専用のボリュームグループを使用する

実装：

  • 同じmd0およびmd1 make 1を除いて、方法1と同じですmd1 VMホスト（たとえば、5〜10GB）を格納するのに十分な大きさ）
  • 大RAID10 md2残りのスペースを占めています。 md2にはLVMボリュームグループvgvmsが含まれ、その論理ボリュームは仮想マシンによって排他的に使用されます

長所：

  • ホストOSを壊すことを恐れずにvgvmsをいじる
  • これはよりエレガントで安全なソリューションのようです

短所：

  • VMホストのファイルシステムのスペースが不足した場合、そのファイルシステムの一部（たとえば、/ usrまたは/ var）をvgvmsに移動する必要があります。非常に素晴らしい。
  • ホストOSを再インストールする必要があります（前述のとおり、これは本当に気にしません）。

更新＃1：

方法2でVMホストのディスク容量が不足することを心配している理由の1つは、VMホストが十分に強力であるかどうかわからないためですすべてのサービスを仮想マシンで実行します。つまり、一部またはすべてのサービスを仮想マシンからホストOSに移行する必要がある場合があります。

VMホストのハードウェア仕様：

  • Phenom II 955 X4 Black Editionプロセッサ（3.2 GHz、4コアCPU）
  • 2x4GB Kingston PC3-10600 DDR3 RAM
  • ギガバイトGA-880GM-USB3マザーボード
  • 4x WD Caviar RE3 500GB SATA II HDD（7200rpm）
  • Antec BP500U Basiq 500W ATX電源
  • CoolerMaster CM 690ケース

更新＃2：

方法1でシステムがホストVGをlibvirtストレージプールとして使用するように設計されていない可能性があると思う1つの理由は、virt-managerで気付いたいくつかの動作です。

  • 追加時に、VGをアクティブ化できなかったと報告されました（明らかに、ホストOSがすでにそれをアクティブ化しているため）
  • 削除時に、VGを非アクティブ化できなかったためにそうすることを拒否しました（明らかに、ホストOSがまだルートとスワップLVを使用しているためです）
centosstoragelvmsoftware-raidkvm-virtualization
12
mosno

よく考え抜かれた質問！

私は方法2で行きますが、それは個人的な好みのほうです。私にとって、方法2の短所はそれほど問題ではありません。ホストOSが5〜10 GBのパーティションを超えることはありません。ただし、ホストOSに余分なもののインストールを開始しない限り、本当にそうするべきではありません。簡素化とセキュリティのために、ホストOSは実際には最小限の最小限のインストールであり、管理に必要な最小限（sshdなど）以外は何も実行しないでください。

IMOの方法1の短所もそれほど問題ではありません。ルート化されたVMが何らかの理由でそのパーティションから抜け出し、他のパーティションに感染/損傷し、別のホストOSにホストOSを持っている場合）なので、余分なセキュリティリスクはないと思います。他の2つの短所は、直接の経験から話せるものではありませんが、CentOS、LVM、およびlibvirtは柔軟性があり、十分に堅牢であるため、心配する必要はありません。

編集-更新1への応答

最近では、仮想化のパフォーマンスへの影響は非常に低く、特にサポートが組み込まれているプロセッサーを使用しているため、サービスをゲストからホストOSに移動することは考えられませんVMあなたmight「ベアメタル」で実行すると10％の速度向上が得られますが、小さくてタイトで安全なホストOSを使用する利点が失われ、安定性に影響を与える可能性がありますサーバー全体の価値がありますIMO.

これを踏まえて、私はまだ方法2を支持します。

更新2への応答

Libvirtがストレージがレイアウトされていると想定する特定の方法は、方法2を支持するもう1つのポイントのようです。私の推奨は、方法2を使用することです。

3
Steven Monday

一度に1つのシステムのみが特定のLVを読み取り/書き込みモードで使用しようとする限り、ホストとゲストに同じVGを使用することが可能です。複数のシステムが同じLVに書き込もうとすると、ファイルシステムが破損します。

1
Ignacio Vazquez-Abrams

あなたはこれを見て、おそらくいじくり回して、このプロジェクトがあなたが話していることをどのように実行するのかを見たいかもしれません。

ProxmoxVEはベアメタルですKVM RHELのより重いものではなく、libvirtのPerl実装を使用するホストです。両方のシナリオを実装します。

仮想ディスクは.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です。

アクティブ '/ dev/LDatastore1/vm-9098-disk-1' [4.00 GB]継承

アクティブ '/ dev/LDatastore1/vm-7060-disk-1' [2.00 GB]継承

アクティブ '/ dev/LDatastore1/vm-5555-disk-1' [8.00 GB]継承

アクティブ '/ dev/LDatastore0/vm-4017-disk-1' [8.00 GB]継承

アクティブ '/ dev/LDatastore0/vm-4017-disk-2' [512.00 GB]継承

アクティブ '/ dev/LDatastore0/vm-7057-disk-1' [32.00 GB]継承

アクティブ '/ dev/LDatastore0/vm-7055-disk-1' [32.00 GB]継承

アクティブ '/ dev/LDatastore0/vm-6030-disk-1' [80.01 GB]継承

アクティブ '/ dev/pve/swap' [3.62 GB]継承

アクティブ '/ dev/pve/root' [7.25 GB]継承

アクティブ '/ dev/pve/data' [14.80 GB]継承

これは、6つの7200 rpm Seagate Barracuda SATAドライブで構成されるRAID10上のLVMです。

CPU BOGOMIPS：53199.93

正規表現/ 2番目：824835

HDサイズ：19.69 GB（/ dev/mapper/LDatastore0-testlv）

バッファ付き読み取り：315.17 MB /秒

平均シークタイム：7.18 ms

FSYNCS/SECOND：2439.31

そして、これは単一のIntel X25-E SATA SSD上のLVMであり、VMが存在する前述の/ dev/pve/dataと同じVGです。

CPU BOGOMIPS：53203.97

正規表現/ 2番目：825323

HDサイズ：7.14 GB（/ dev/mapper/pve-root）

バッファ付き読み取り：198.52 MB /秒

平均シークタイム：0.26 ms

FSYNCS/SECOND：1867.56

1
NginUS