KVM / libvirt sunucusu ve misafirleri arasında paylaşılan LVM hacim grubu: bu kötü bir fikir mi?

4 SATA II sabit sürücü içeren ve CentOS 5.5 x86_64 çalıştıran yeni, parlak, yeni bir KVM / libvirt tabanlı sanal makine ana bilgisayarı oluşturdum.

Diskleri qcow görüntüleri olarak oluşturma alıştırması yerine, libvirt depolama havuzu olarak yönetilen bir LVM birim grubunda mantıksal birimler olarak sanal makine diskleri oluşturmaya karar verdim .

Karar veremediğim , sanal makine mantıksal birimlerini VM ana bilgisayarının birim grubunda mı yoksa özel bir birim grubunda mı oluşturmam gerektiğidir.

Hangi yöntemi seçmeliyim ve neden?

Yöntem 1: VM ana bilgisayarının birim grubunu kullanma

Uygulama:

• dosya sistemini md0içeren küçük RAID1/boot
• md1LVM hacim grubu içeren kalan alanı kaplayan büyük RAID10 vghost. vghostVM ana bilgisayarının kök dosya sistemini ve takas bölümünü içerir
• vghostgerektiği gibi mantıksal birimler olarak sanal makine diskleri oluşturun

Artıları:

• VM ana bilgisayarının kök dosya sisteminde yer kalmazsa, vghostgöreli kolaylıkla daha fazla alan ayırabilirim
• Sistem zaten çalışıyor ve çalışıyor (ancak baştan başlamak önemli değil)

Eksileri:

Bu yöntemin işe yaradığını görünce, bunun bir şekilde kötü bir fikir olduğu hissini sallayamıyorum. Hissediyorum:

• bu bir şekilde bir güvenlik riski olabilir
• gelecekte bir noktada kurulumla ilgili bazı sınırlamalar bulabilirim ve özel bir grup kullanmamı isterdim
• sistem (CentOS, libvirt vb.) gerçekten bu şekilde kullanılmak üzere tasarlanmamış olabilir ve bu nedenle bir noktada VM ana bilgisayarının dosyalarını ve / veya dosya sistemini yanlışlıkla bozabilir / kaybedebilirim

Yöntem 2: Özel bir birim grubu kullanma

Uygulama:

• Aynı md0ve md1metot 1'de olduğu gibi, marka hariç md1sadece yeterince büyük VM ana bilgisayar için içerecek şekilde (örn. 5 10GB)
• md2kalan alanı kaplayan büyük RAID10 . mantıksal hacimleri yalnızca sanal makineler tarafından kullanılacak md2bir LVM hacim grubu içerirvgvms

Artıları:

• vgvmsAna işletim sistemini bozma korkusu olmadan tamir edebilirim
• bu daha zarif ve güvenli bir çözüm gibi görünüyor

Eksileri:

• VM ana bilgisayarının dosya sisteminde yer vgvmskalmazsa , dosya sisteminin bazı bölümlerini (örn. / usr veya / var) üzerine taşımak zorunda kalırdım , ki bu pek hoş görünmüyor.
• Ana bilgisayar işletim sistemini yeniden yüklemeliyim (daha önce belirttiğim gibi yapmayı gerçekten önemsemiyorum)

GÜNCELLEME # 1:

Yöntem 2'de VM ana bilgisayar disk alanının tükenmesinden endişe etmemin bir nedeni, VM ana makinesinin tüm hizmetleri sanal makinelerde çalıştıracak kadar güçlü olup olmadığını bilmememdir. Bazı / tüm hizmetleri sanal makinelerden ana bilgisayar işletim sistemine geçirmek zorunda kalabilirim.

VM ana bilgisayar donanım özellikleri:

• Phenom II 955 X4 Black Edition işlemci (3.2GHz, 4 çekirdekli CPU)
• 2x4GB Kingston PC3-10600 DDR3 RAM
• Gigabyte GA-880GM-USB3 anakart
• 4x WD Caviar RE3 500GB SATA II HDD'ler (7200rpm)
• Antec BP500U Basiq 500W ATX güç kaynağı
• CoolerMaster CM 690 kılıf

GÜNCELLEME # 2:

Sistem Yöntem 1'de bir libvirt depolama havuzu olarak ana VG kullanmak için tasarlanmamış olabilir hissediyorum nedenlerinden biri virt-manager fark bazı davranışlarıdır:

• eklendikten sonra, VG'yi etkinleştiremediğinden şikayet etti (açıkçası, ana işletim sisteminin zaten etkinleştirmiş olması nedeniyle)
• kaldırıldığında, VG'yi devre dışı bırakamadığı için bunu reddetti (açıkçası, çünkü ana bilgisayar işletim sistemi hala kök ve takas LV'lerini kullanıyor)

İyi düşünülmüş bir soru!

Yöntem 2 ile giderdim, ama bu daha çok kişisel bir tercih. Bana göre, Yöntem 2 Eksileri çok önemli değil. Ana bilgisayar OS'sinin 5-10GB bölümünü büyüttüğünü görmüyorum, üzerine fazladan şeyler yüklemeye başlamadığınız sürece, gerçekten yapmamanız gerekir. Basitlik ve güvenlik adına, ana bilgisayar işletim sistemi gerçekten çıplak bir minimum kurulum olmalıdır, yönetim için gereken minimum minimum dışında hiçbir şey çalıştırmamalıdır (örn. Sshd).

Yöntem 1 Eksileri de gerçekten bir sorun değil, IMO. Ek bir güvenlik riski olacağını düşünmüyorum, çünkü köklü bir VM bir şekilde kendi bölümünü kırabilir ve diğer bölümlere bulaşabilir / zarar verebilirse, ana bir işletim sisteminin ayrı bir VG'ye sahip olması herhangi bir fark yaratmayabilir. Diğer iki Eksileri doğrudan deneyimlerden konuşabileceğim bir şey değil, ama bağırsaklarım CentOS, LVM ve libvirt'in onlar için endişelenmeyecek kadar esnek ve sağlam olduğunu söylüyor.

EDIT - Güncelleme 1'e Yanıt

Bu günlerde, sanallaştırmanın performans isabeti çok düşük, özellikle de bunun için yerleşik desteğe sahip işlemciler kullanıyor, bu yüzden bir hizmeti konuk VM'den ana işletim sistemine taşımak hiç de faydalı olmayacak. Sen belki "çıplak metal" konulu çalıştırarak% 10 hız artışı olsun, ama küçük, sıkı ve güvenli bilgisayar OS sahip olmanın yararlarını kaybederler ve potansiyel olarak tüm sunucunun istikrarı etkileyecek. Buna değmez IMO.

Bunun ışığında hala Yöntem 2'yi tercih ederim.

Güncelleme 2'ye Yanıt

Görünüşe göre libvirt'in depolamayı düzenlediğini varsayması, Yöntem 2 lehine başka bir nokta. Benim tavsiyem: Yöntem 2'ye gidin.

Belirli bir LV'yi herhangi bir zamanda okuma / yazma modunda kullanmaya çalıştığı sürece, aynı VG'yi ev sahibi ve misafirler için kullanmak mümkündür. Birden çok sistem aynı LV'ye yazmaya çalışırsa, dosya sisteminde bozulma ortaya çıkar.

Buna bir göz atmak, belki tamircilik yapmak ve bu projenin bahsettiğiniz şeyi nasıl yaptığını görmek isteyebilirsiniz.

ProxmoxVE, RHEL'in daha ağır karşılığı yerine pervvlit uygulaması kullanan çıplak metal bir KVM konağıdır. Her iki senaryoyu da uygular.

Sanal diskler .raw ve seyrek, .qcow'a benzer ancak daha hızlıdır.

Qcow ve vmdk disk görüntü formatları da destekleniyor, ancak LVM sınırlamaları olabileceğini düşünüyorum. Onları kullanmıyorum, bu yüzden fazla bir şey söyleyemem.

LVM depolama alanı düğümdeki VM'ler arasında paylaşılır ve DRBD cihazları olabilir.

İşletim sisteminin VG alanını paylaşma konusunda, tek endişe yedeklemeler sırasında anlık görüntü boyutudur. Burada bu değer bir yapılandırma dosyasında değiştirilebilir ve bazen insanların değiştirmek zorunda olduğu forumlarda görüyorum, ancak varsayılanlar bana birkaç yıl boyunca iyi hizmet etti - hatta büyük sanal disklerle bile.

PVE'nin LVM depolama detayları:

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

VG'ler şu şekilde düzenlenir:

Lvm2 meta veri türünü kullanarak "LDatastore1" birim grubu bulundu

Lvm2 meta veri türünü kullanarak "LDatastore0" birim grubu bulundu

Lvm2 meta veri türü kullanılarak birim grubu "pve" bulundu

Bunlar benim LV'lerim:

AKTİF '/ dev / LDatastore1 / vm-9098-disk-1' [4.00 GB] devralma

AKTİF '/ dev / LDatastore1 / vm-7060-disk-1' [2.00 GB] devralma

AKTİF '/ dev / LDatastore1 / vm-5555-disk-1' [8.00 GB] devralma

AKTİF '/ dev / LDatastore0 / vm-4017-disk-1' [8,00 GB] devralma

AKTİF '/ dev / LDatastore0 / vm-4017-disk-2' [512.00 GB] devralma

AKTİF '/ dev / LDatastore0 / vm-7057-disk-1' [32.00 GB] devralma

AKTİF '/ dev / LDatastore0 / vm-7055-disk-1' [32.00 GB] devralma

AKTİF '/ dev / LDatastore0 / vm-6030-disk-1' [80.01 GB] devralma

AKTİF '/ dev / pve / takas' [3.62 GB] miras

AKTİF '/ dev / pve / root' [7,25 GB] devralma

AKTİF '/ dev / pve / data' [14.80 GB] miras

Bu, 6 7200 rpm Seagate Barracuda SATA disklerinden yapılmış RAID10'daki LVM'dir:

CPU BOGOMIPS: 53199.93

REGEX / İKİNCİ: 824835

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

ARABELLEBİLİR OKUMA: 315.17 MB / sn.

ORTALAMA ARAMA ZAMANI: 7,18 ms

FSYNCS / İKİNCİ: 2439.31

Ve bu, tek bir Intel X25-E SATA SSD'de LVM, VM'lerin yaşadığı yukarıda belirtilen / dev / pve / verilerle aynı VG:

CPU BOGOMIPS: 53203.97

REGEX / İKİNCİ: 825323

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

ARABELLEBİLEN OKUMALAR: 198.52 MB / sn.

ORTALAMA ARAMA ZAMANI: 0,26 ms

FSYNCS / İKİNCİ: 1867.56