Grup volume LVM dibagi antara host KVM / libvirt dan tamu: apakah ini ide yang buruk?


12

Saya baru saja membangun host mesin virtual berbasis KVM / libvirt baru yang mengkilap, berisi 4 hard drive SATA II, dan menjalankan CentOS 5.5 x86_64.

Saya telah memutuskan untuk membuat disk mesin virtual sebagai volume logis dalam grup volume LVM yang dikelola sebagai kumpulan penyimpanan libvirt, alih-alih praktik yang biasa membuat disk sebagai gambar qcow.

Yang tidak bisa saya putuskan adalah apakah saya harus membuat volume logis mesin virtual dalam grup volume host VM, atau dalam grup volume khusus.

Metode mana yang harus saya pilih, dan mengapa?


Metode 1: Gunakan grup volume host VM

Penerapan:

  • RAID1 kecil yang md0berisi /bootsistem file
  • RAID10 besar md1menempati ruang yang tersisa, yang berisi grup volume LVM vghost. vghostberisi sistem file root host VM dan partisi swap
  • buat disk mesin virtual sebagai volume logis vghostsesuai kebutuhan

Pro:

  • jika sistem file root host VM kehabisan ruang, saya dapat mengalokasikan lebih banyak ruang dari vghostdengan relatif mudah
  • Sistem sudah berjalan dan berjalan (tetapi bukan masalah besar untuk memulai kembali)

Cons:

Mengabaikan fakta bahwa metode ini tampaknya berhasil, saya tidak dapat menghilangkan perasaan bahwa ini adalah ide yang buruk. Aku merasakannya:

  • ini entah bagaimana bisa menjadi risiko keamanan
  • di beberapa titik di masa depan saya mungkin menemukan beberapa batasan dengan pengaturan, dan berharap bahwa saya menggunakan grup khusus
  • sistem (CentOS, libvirt, dll.) mungkin tidak benar-benar dirancang untuk digunakan seperti ini, dan karena itu pada titik tertentu saya mungkin secara korup merusak / kehilangan file host VM dan / atau filesystem

Metode 2: Gunakan grup volume khusus

Penerapan:

  • sama md0dan md1seperti pada Metode 1, kecuali buat md1cukup besar untuk menampung VM host (mis. 5 hingga 10GB)
  • RAID10 besar md2menempati ruang yang tersisa. md2berisi grup volume LVM vgvms, yang volume logisnya digunakan secara eksklusif oleh mesin virtual

Pro:

  • Saya bisa bermain-main vgvmstanpa takut merusak OS host
  • ini sepertinya solusi yang lebih elegan dan aman

Cons:

  • jika filesystem VM host kehabisan ruang, saya harus memindahkan bagian dari filesystem-nya (mis. / usr atau / var) vgvms, yang sepertinya tidak terlalu bagus.
  • Saya harus menginstal ulang OS host (yang seperti yang dinyatakan sebelumnya saya tidak keberatan melakukan)

PEMBARUAN # 1:

Salah satu alasan mengapa saya khawatir kehabisan ruang disk host VM dalam Metode 2 adalah karena saya tidak tahu apakah host VM cukup kuat untuk menjalankan semua layanan di mesin virtual, yaitu. Saya mungkin harus memigrasi beberapa / semua layanan dari mesin virtual ke OS host.

Spesifikasi perangkat keras host VM:

  • Prosesor Phenom II 955 X4 Black Edition (3.2GHz, 4-core CPU)
  • 2x3GB Kingston PC3-10600 DDR3 RAM
  • Motherboard Gigabyte GA-880GM-USB3
  • 4x WD Caviar RE3 500GB SATA II HDD (7200rpm)
  • Antec BP500U Basiq 500W ATX power supply
  • Casing CoolerMaster CM 690

PEMBARUAN # 2:

Salah satu alasan mengapa saya merasa bahwa sistem mungkin tidak dirancang untuk menggunakan host VG sebagai kumpulan penyimpanan libvirt di Metode 1 adalah beberapa perilaku yang saya perhatikan di virt-manager:

  • setelah ditambahkan, ia mengeluh bahwa ia tidak dapat mengaktifkan VG (jelas, karena OS host sudah mengaktifkannya)
  • setelah dihapus, ia menolak untuk melakukannya karena tidak dapat menonaktifkan VG (jelas, karena OS host masih menggunakan root dan menukar LVs)

Saya membuat pertanyaan (# 272324) di mana solusi Anda # 1 akan menjadi jawaban yang sangat bagus! Dan inilah tepatnya yang saya gunakan untuk pengaturan serupa - dan sejauh ini saya cukup senang dengannya. Namun saya punya masalah di mana diskIO dalam Guest jauh lebih lambat daripada jika "loop-mounting" LV yang sama di Host.
stolsvik

Jawaban:


3

Pertanyaan yang dipikirkan dengan matang!

Saya akan menggunakan Metode 2, tetapi itu lebih merupakan pilihan pribadi. Bagi saya, Metode 2 Kontra tidak banyak masalah. Saya tidak melihat OS host melebihi partisi 5-10GB, kecuali jika Anda mulai menginstal hal-hal tambahan di atasnya, yang seharusnya tidak Anda lakukan. Demi kesederhanaan dan keamanan, OS host harus benar-benar instalasi minimal, tidak menjalankan apa pun kecuali minimum yang diperlukan untuk administrasi (misalnya sshd).

Metode 1 Kontra juga bukan masalah, IMO. Saya tidak berpikir akan ada risiko keamanan tambahan, karena jika VM yang di-root entah bagaimana dapat keluar dari partisi dan menginfeksi / merusak partisi lain, memiliki OS host pada VG terpisah mungkin tidak ada bedanya. Dua lainnya Kontra bukan sesuatu yang saya dapat berbicara dengan dari pengalaman langsung, tetapi saya nyali mengatakan bahwa CentOS, LVM, dan libvirt fleksibel dan cukup kuat untuk tidak khawatir tentang mereka.

EDIT - Respons terhadap Pembaruan 1

Saat ini, kinerja virtualisasi sangat rendah, terutama menggunakan prosesor dengan dukungan bawaan untuk itu, jadi saya tidak berpikir memindahkan layanan dari VM tamu ke host OS akan layak dilakukan. Anda mungkin mendapatkan peningkatan kecepatan 10% dengan menjalankan "bare metal", tetapi Anda akan kehilangan manfaat memiliki OS host yang kecil, kencang, aman, dan berpotensi berdampak pada stabilitas seluruh server. Tidak layak, IMO.

Mengingat hal ini, saya masih akan menyukai Metode 2.

Respons terhadap Pembaruan 2

Tampaknya cara khusus yang diasumsikan oleh libvirt penyimpanan adalah titik lain yang mendukung Metode 2. Rekomendasi saya adalah: lanjutkan dengan Metode 2.


Terima kasih. Saya telah menambahkan 2 pembaruan untuk pertanyaan saya, yang selanjutnya menjelaskan mengapa saya telah mendaftarkan beberapa kontra yang telah Anda tangani. Apakah pembaruan itu mengubah opini Anda sama sekali?
mosno

@mosno: Memperbarui jawaban saya untuk menanggapi pembaruan Anda.
Steven Monday

Terima kasih semuanya atas jawaban Anda, semua telah membantu saya dan sulit untuk memilih jawaban siapa yang akan diterima. Saya memilih Steven karena saya merasa itu membuat upaya terbaik untuk menjawab pertanyaan yang diajukan. Sebagai catatan, sementara saya setuju Metode 2 mungkin lebih baik, saya memilih untuk tetap menggunakan Metode 1 karena berfungsi dan karena keterbatasan waktu.
mosno

1
Juga, saya tinggal dengan Metode 1 untuk saat ini karena saya pikir akan mendidik untuk mengeksplorasi keterbatasan metode ini. Sebagai contoh, saya belajar bahwa jika dalam OS tamu Anda membuat LVM PG langsung ke perangkat (mis. Perangkat / dev / vda bukan partisi / dev / vda1), maka pvscan OS host mencantumkan PV tamu (yaitu. gunakan / dev / vda1, bukan / dev / vda).
mosno

1

Selama hanya satu sistem yang mencoba menggunakan LV yang diberikan dalam mode baca / tulis kapan saja, layak untuk menggunakan VG yang sama untuk host dan tamu. Jika beberapa sistem mencoba menulis ke LV yang sama maka kerusakan pada sistem file akan terjadi.


pasti ada peningkatan tingkat kompleksitas untuk mengelola ini. Ini pintar .. mungkin terlalu pintar.
The Unix Janitor

@ user37899: ini adalah cara yang biasa untuk menangani LVM
Javier

terima kasih, tetapi saya mengerti itu; Saya tidak berencana melakukan itu.
mosno

ketika saya melakukan "lvscan" pada OS host, ia melaporkan LV tamu sebagai "AKTIF". Tuan rumah tidak memiliki LV yang terpasang. Apakah LV hanya dalam keadaan "AKTIF" merupakan "mode baca / tulis", atau maksud Anda mount secara eksplisit ke sistem file host?
mosno

Maksud saya mount r / w eksplisit.
Ignacio Vazquez-Abrams

1

Anda mungkin ingin melihat ini, mungkin bermain-main & melihat bagaimana proyek ini melakukan apa yang Anda bicarakan.

ProxmoxVE adalah host KVM bare-metal yang menggunakan implementasi perl libvirt daripada rekan yang lebih berat RHEL. Ini mengimplementasikan kedua skenario.

Disk virtual .raw dan jarang, mirip dengan .qcow tetapi lebih cepat.

Format gambar disk qcow & vmdk juga didukung tetapi saya pikir mungkin ada batasan LVM yang terlibat. Saya tidak menggunakannya jadi saya tidak bisa mengatakan banyak tentang itu.

Penyimpanan LVM dibagi antara VM pada node, dan dapat berupa perangkat DRBD.

Sedangkan untuk berbagi ruang VG OS, satu-satunya batasan yang harus diperhatikan adalah ukuran foto selama pencadangan. Di sini nilai ini dapat diubah dalam file konfigurasi, dan kadang-kadang saya melihat di forum di mana orang harus mengubahnya, tetapi standarnya telah membantu saya dengan baik selama beberapa tahun sekarang - bahkan dengan disk virtual besar.

Detail penyimpanan LVM PVE:

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

Beginilah VG disusun:

Ditemukan grup volume "LDatastore1" menggunakan metadata tipe lvm2

Ditemukan grup volume "LDatastore0" menggunakan metadata tipe lvm2

Grup volume yang ditemukan "pve" menggunakan metadata tipe lvm2

Ini adalah LV saya:

ACTIVE '/ dev / LDatastore1 / vm-9098-disk-1' [4,00 GB] mewarisi

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

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

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

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

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

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

ACTIVE '/ dev / LDatastore0 / vm-6030-disk-1' [80.01 GB] mewarisi

ACTIVE '/ dev / pve / swap' [3,62 GB] mewarisi

ACTIVE '/ dev / pve / root' [7,25 GB] mewarisi

AKTIF '/ dev / pve / data' [14,80 GB] mewarisi

Ini adalah LVM pada RAID10 yang terbuat dari 6 SATA Seagate Barracuda SATA 6.700:

CPU BOGOMIPS: 53199,93

REGEX / DETIK: 824835

UKURAN HD: 19,69 GB (/ dev / mapper / LDatastore0-testlv)

BACA BUFFERED: 315,17 MB / detik

AVERAGE SEEK TIME: 7,18 ms

FSYNCS / KEDUA: 2439.31

Dan ini adalah LVM pada satu SSD Intel X25-E SATA, VG yang sama dengan data / dev / pve / di mana VM tinggal:

BOGOMIPS CPU: 53203.97

REGEX / DETIK: 825323

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

BACA BUFFERED: 198,52 MB / detik

AVERAGE SEEK TIME: 0,26 ms

FSYNCS / KEDUA: 1867.56

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.