LVM bölümleri sanal makine görüntülerinde kullanılmalı mı?

VM görüntüleri oluştururken bölümler için LVM kullanılmalı mı (ör. KVM görüntüler)? Görüntünün LVM bölümleri varsa, ana bilgisayara bir qcow2 görüntüsü monte etmek istiyorsanız, karmaşıklık katıyor gibi görünüyor.

Öte yandan, LVM bölümlerinin avantajları VM görüntüsünde çok önemli görünmemektedir, çünkü VM'yi çevrimdışı duruma getirmek ve bölümleri yeniden boyutlandırmak fiziksel sistem için olduğundan çok daha kolaydır.

"Değişir."

Kontrol ettiğiniz bir ortamdaysanız (vmware veya kvm veya her neyse) ve disk performansı QoS hakkında kendi kararlarınızı verebilirseniz, VM'leriniz içinde LVM kullanmamanızı tavsiye ederim. Hiper yönetici seviyesinde alamayacağın esnekliği almıyor.

Unutma, hipervizör zaten bu görevleri etkili bir şekilde yapıyor. Dosya sistemlerini keyfi bir şekilde yeniden boyutlandırmak istiyorsanız (iyi bir fikir), her dosya sistemi için ayrı bir sanal disk oluşturun.

Bu yolda giderken düşünebileceğiniz bir şey var. Sanal disklerinize bu şekilde bölümler koymanız bile gerekmez. Örneğin /home; için sanal bir disk oluşturabilirsiniz ; öyle /dev/vdcsenin vm içeride. Dosya sistemi oluştururken, sadece böyle bir şey yapmak mke2fs -j /dev/vdcyerine bölüm belirleme.

Bu iyi bir fikir, ancak ... çoğu araç (ve sizden sonra gelen diğer yöneticiler) her diskte bölümleri görmeyi bekler. Sadece diske tek bir bölüm koymanızı ve onunla yapılmasını öneririm. Yine de, dosya sistemini yeniden boyutlandırırken bir adım daha demek. Ve bölümlerinizi düzgün bir şekilde hizalamayı unutmayın - ilk bölümü 1 MB'de başlatmak iyi bir kuraldır.

Tüm söylenenler - Bunları hiper yönetici seviyesinde yapmak, muhtemelen bölümleri yeniden boyutlandırmak için VM'yi yeniden başlatmanız gerektiği anlamına gelir. LVM kullanmak, sanal bir disk ekleyebilmenizi sağlar (hypervisor / OS kombinasyonunuzun buna izin verdiğini varsayar) ve yeniden başlatmadan dosya sistemini genişletir. Bu kesinlikle bir artı.

Bu arada, bir bulut sağlayıcı kullanıyorsanız, daha ince olur.

Azure, GCP veya daha küçük oyuncuların hiçbiri hakkında fazla bir şey bilmiyorum, o yüzden orada yardım edemem.

AWS ile yukarıdaki tavsiyemi takip edebilirsin ve genelde iyi olacaksın. Anında (şimdi) EBS birimlerinin boyutunu (sanal diskler) artırabilir ve bölümleri vb. Yeniden boyutlandırabilirsiniz.

Ancak, genel durumda, her şeyi tek bir büyük EBS hacmine koymak ve LVM (veya sanırım, düz bölümler) kullanmak mantıklı olabilir. Amazon size her cilt için bir IOPS limiti verir. Varsayılan olarak, bu sınır birimin boyutuna göre ölçeklenir. örneğin, gp2birimler için GiB başına 3 IOPS elde edersiniz (en az 100 IOPS). Bkz https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html

Çoğu iş yükü için, mevcut ihtiyaca bağlı olarak mevcut tüm IOPS'larınızın herhangi bir dosya sisteminde kullanılabilir olmasını isteyeceksiniz. Bu yüzden, büyük bir EBS hacmi oluşturmak, tüm IOPS'lerinizi tek bir kovaya koymak ve bölümlemek / LVM yapmak mantıklı olacaktır.

Örnek:

Her biri 100 GB boyutunda olan bağımsız dosya sistemleri / takas alanları olan 3 disk. Her biri 300 IOPS alır. Performans her diskte 300 IOPS ile sınırlıdır.

1 disk, 300 GB boyutunda. Her biri 100 GB'lık diskteki LVM bölümleri. Disk 900 G / Ç alır. Herhangi bir bölüm 900 IOPS'un tümünü kullanabilir.

Mantıksal hacimleri anında oluşturmak, yeniden boyutlandırmak, silmek kolaydır.
"LVM'ye değil veya" sorusu her zaman aynı cevaba sahiptir, buna bağlıdır :)
Disk (ler), bölüm (ler) düzeyinde esnekliğe ihtiyaç duyduğunuzda mantıklıdır.
LVM tarafından sağlanan esnekliğe ihtiyaç duymuyorsanız ya da diğer LVM özelliklerinden yararlanmak istemiyorsanız, pek bir şey ifade etmez.

Aslında LV'leri kullanmayı seviyorum, çünkü virt-server'dan kolayca erişilemiyorlar. Böylece bu dosyalar kolayca tesadüfen imha edilemez / taşınamaz.

LV'lerin diğer önemli özellikleri:

• Anlık görüntüleri yapabilirsiniz
• LV ( iostat) 'ye dayalı disk IO’yu analiz edebilirsiniz.
• Yeniden boyutlandırmak kolay
• Anlık görüntüleri kullanarak, çalışan sistemlerin tutarlı bir klonunu oluşturabilirsiniz.

Karmaşıklığı azaltmak için LV olarak disk kullanıyorum (bölüm olarak değil). Buradaki dezavantaj, "disk" in son bölümünü kolayca kolayca yeniden boyutlandırabilmemdir - ancak standart VM disk düzenim bunu dikkate alır (bu nedenle son bölüm önemli uygulama verilerini içerir).

Esnekliğe ek olarak, LVM tabanlı VM görüntülerinin daha az ek yükü vardır, çünkü dosya sisteminden erişilmez. Öte yandan, bir dosyayla yaptığınız gibi, görüntüleri kolayca hareket ettirme araçlarını ortadan kaldırır. İmkansız değil, ama biraz daha karmaşık

Benim kendi tecrübem ....

Ext4 dosya sistemi için lvm2 ile mantıksal bir birim (lv) kullanmak istedim; bir disk olarak değil, fs için bölümlenmemiş bir ham disk olarak değil.

Bulduğum şey, VM'nin başlatılmasının başlangıç ​​aşamasında durdurulacağı; /etc/fstabgirişi yorumladıysam makine önyükleme yapardı. Yazının /etc/fstabyorumunu bırakmak, yaşamaktan mutlu olduğum bir çözüm değildi. Böylece, normal bir disk görüntüsü (hala mantıksal bir birim) fdiskoluşturdum, üzerinde dosya sistemini kullanarak bir bölümü bölümledim ve bunun üzerinde oluşturdum. Başka sorun yok.

İçimdeki ilgili bağlar /etc/fstabUUID kullanıyordu.

Dosya veya dosya sistemini kullanmayı düşündüm ama buna karşı karar verdim.

Benim durumumda Debian Jessie tabanlı bir sistem Devuan kullanıyorum

Aslında LVM'leri sadece hiper yönetici düzeyinde destek depolamak için kullanıyorum, görüntü dosyaları kuşlar için. Onları konuk düzeyinde de kullanmanızı tavsiye ederim. Farklı depolama kaynaklarının birleştirilmesinden faydalanamayacağınız ya da kullanılabilir toplam disk alanını arttırmayı daha kolay bulamayacağınız doğrudur (çünkü hipervizörün sunduklarını yeniden boyutlandırarak bunu kolayca elde edebilirsiniz), ancak bazen bir dosya sistemine çok fazla şey ayırırsınız . / Opt'dan 1 gig almak ve / var (örneğin) vermek için kolay bir yol isteyebilirsiniz. Sanal Makinenin içinde düzenli bölümler yapıyorsanız, yeniden boyutlandırma özelliğini bu kadar zorlaştırır.

Buradaki diğer iyi cevaplara ek olarak, LVM'yi bir VM içinde kullanmak için gerçekten iyi bir neden, LVM ile denemek ve pratik bir deneyim elde etmek için bir test ortamı istemenizdir.

Çeşitli NASIL ve öğreticilerden geçebilir, ortak (ve çok yaygın olmayan) LVM yönetimi görevlerini uygulayabilir, çeşitli başarısızlık senaryoları oluşturabilir ve bunlarla nasıl başa çıkacağınızı öğrenebilirsiniz.

yani kendi kendine öğretim yardımı olarak.

Düzenleme: Aşağıda artık doğru değil. LVM görüntüleri için LVM tarafından sağlanan ince provizyon kullanımı değeri muhtemelen durumsaldır;

Geliştirme VM'lerini bir dizüstü bilgisayarda mı kullanıyorsunuz? O zaman muhtemelen QCow2 ile daha iyisin.

Birden fazla diskte büyük miktarda depolama alanı kullanabilecek bir VM grubunu yönetmek? LVM muhtemelen bu depolamayı yönetmenin iyi bir yoludur.

bir nedeni değil lvm kullanmak değil overcommit depolama lvm kullanarak can olduğunu. 100 GB depolama alanına sahip bir 10 VM oluşturursanız, on VM'den 9'u yalnızca 20 GB dosya sistemlerini kullansa bile, 1000 GB gerçek diske ihtiyacınız vardır. Seyrek Disk görüntüleri veya qcow2 formatındaki görüntüler, yalnızca konuklar tarafından kullanılan depolama alanlarının kendilerine tahsis edilmesi gerektiği anlamına gelebilir.

Bunun gerçekten sizin için yararlı olup olmadığı, depolama alanından neye ihtiyacınız olduğuna bağlıdır.