Czy partycje LVM powinny być używane w obrazach maszyn wirtualnych?

Czy LVM powinien być używany do partycji podczas tworzenia obrazów VM (np. Obrazów KVM)? Wygląda na to, że dodaje złożoności, jeśli chcesz, powiedzmy, zamontować obraz qcow2 na hoście, jeśli obraz ma partycje LVM.

Z drugiej strony nie wydaje się, aby zalety partycji LVM były tak znaczące na obrazie maszyny wirtualnej, ponieważ znacznie łatwiej jest przenieść maszynę wirtualną w tryb offline i zmienić rozmiar partycji niż w przypadku systemu fizycznego.

"To zależy."

Jeśli pracujesz w środowisku, które kontrolujesz (vmware, kvm lub cokolwiek innego) i możesz podejmować własne decyzje dotyczące QoS wydajności dysku, odradzam używanie LVM wewnątrz maszyn wirtualnych. Nie zapewnia ci dużej elastyczności, której nie można uzyskać na poziomie hiperwizora.

Pamiętaj, że hiperwizor już skutecznie wykonuje te zadania. Jeśli chcesz dowolnie zmieniać rozmiar systemów plików (dobry pomysł), po prostu utwórz oddzielny dysk wirtualny dla każdego systemu plików.

Jedną rzecz, o której możesz pomyśleć idąc tą drogą. Nie musisz nawet umieszczać partycji na dyskach wirtualnych w ten sposób. Na przykład możesz utworzyć dysk wirtualny dla /home; jest /dev/vdcw twoim vm. Tworząc system plików, po prostu zrób coś takiego, mke2fs -j /dev/vdczamiast określać partycję.

To świetny pomysł, ale ... większość narzędzi (i inni administratorzy, którzy przyszli po ciebie) będą oczekiwać, że zobaczą partycje na każdym dysku. Polecam po prostu umieszczenie jednej partycji na dysku i gotowe. Jednak oznacza to jeszcze jeden krok podczas zmiany rozmiaru systemu plików. I nie zapomnij odpowiednio wyrównać partycji - dobrym pomysłem jest rozpoczęcie pierwszej partycji o wielkości 1 MB.

Wszystko, co powiedziane - Wykonanie tego wszystkiego na poziomie hiperwizora oznacza, że ​​prawdopodobnie musisz ponownie uruchomić maszynę wirtualną, aby zmienić rozmiar partycji. Użycie LVM umożliwiłoby dodanie dysku wirtualnego na gorąco (zakładając, że kombinacja hiperwizora / systemu operacyjnego na to pozwala) i rozwinięcie systemu plików bez ponownego uruchamiania. To zdecydowanie plus.

Tymczasem jeśli używasz dostawcy chmury, jest to bardziej subtelne.

Nie wiem dużo o platformie Azure, GCP ani żadnym z mniejszych graczy, więc nie mogę nic na to poradzić.

Dzięki AWS możesz postępować zgodnie z moimi wskazówkami powyżej i często nic ci nie będzie. Możesz (teraz) zwiększać rozmiar woluminów EBS (dysków wirtualnych) w locie, zmieniać rozmiar partycji itp.

Jednak w ogólnym przypadku sensowne może być umieszczenie wszystkiego na jednym dużym woluminie EBS i użycie LVM (lub, jak sądzę, zwykłych partycji). Amazon daje limit IOPS dla każdego woluminu. Domyślnie ten limit jest skalowany wraz z rozmiarem woluminu. np. w przypadku gp2woluminów dostajesz 3 IOPS na GiB (minimum 100 IOPS). Zobacz https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html

W przypadku większości obciążeń będziesz chciał, aby wszystkie dostępne IOPS były dostępne dla dowolnego systemu plików, w zależności od potrzeb w danym momencie. Dlatego sensowne jest utworzenie jednego dużego woluminu EBS, zebranie wszystkich IOPS w jednym segmencie i podzielenie go na partycje / LVM.

Przykład:

3 dyski z niezależnymi systemami plików / obszarami wymiany, każdy o wielkości 100 GB. Każdy dostaje 300 IOPS. Wydajność jest ograniczona do 300 IOPS na każdym dysku.

1 dysk o rozmiarze 300 GB. Partycje LVM na dysku o pojemności 100 GB każda. Dysk otrzymuje 900 IOPS. Każda z partycji może korzystać ze wszystkich 900 IOPS.

Woluminy logiczne można łatwiej tworzyć na bieżąco, zmieniać ich rozmiar i usuwać.
Pytanie „do LVM czy nie” zawsze ma tę samą odpowiedź, to zależy :)
Ma sens, jeśli potrzebujesz elastyczności na poziomie dysku (dysków), partycji.
Nie ma większego sensu, jeśli nie potrzebujesz elastyczności zapewnianej przez LVM lub nie chcesz korzystać z innych funkcji LVM

Naprawdę lubię używać LV, ponieważ nie są one łatwo dostępne z serwera virt. Tak więc tych plików nie można łatwo zniszczyć / przenieść przypadkowo.

Inne ważne cechy LV:

• Możesz robić migawki
• Możesz analizować IO dysku w oparciu o LV ( iostat)
• Łatwy do zmiany rozmiaru
• Za pomocą migawek można utworzyć spójny klon działających systemów

Aby zmniejszyć złożoność, używam LV jako dysku (nie jako partycji). Wadą jest to, że mogę łatwo zmienić rozmiar ostatniej partycji „dysku” - ale mój standardowy układ dysku VM bierze to pod uwagę (więc ostatnia partycja zawiera ważne dane aplikacji).

Oprócz elastyczności obrazy maszyn wirtualnych opartych na LVM mają potencjalnie mniejszy narzut, ponieważ nie są one dostępne za pośrednictwem systemu plików. Z drugiej strony zabiera środki do łatwego przenoszenia obrazów, tak jak w przypadku pliku. Nie niemożliwe, ale nieco bardziej skomplikowane

Moje własne doświadczenie ....

Chciałem użyć woluminu logicznego (lv) z lvm2 dla systemu plików ext4; nie jako dysk, a raczej po prostu jako niepodzielony na partycje dysk surowy dla fs.

Odkryłem, że uruchomienie VM zostanie zatrzymane na początkowym etapie; gdybym skomentował /etc/fstabwpis, maszyna uruchomiłaby się. Pozostawienie /etc/fstabkomentarza do wpisu nie było rozwiązaniem, z którym cieszyłem się, że mogę z tym żyć. Tak więc utworzyłem normalny obraz dysku (wciąż wolumin logiczny), podzieliłem go na partycje przy użyciu fdiski utworzyłem na nim system plików. Żadnych dalszych problemów.

Odpowiednie wierzchowce w moim /etc/fstabkorzystały z UUID.

Myślałem o użyciu pliku lub systemu plików, ale zdecydowałem się tego nie robić.

W moim przypadku korzystam z systemu Devuan opartego na Debian Jessie

Właściwie używam LVM tylko do przechowywania kopii zapasowej na poziomie hiperwizora, pliki obrazów są dla ptaków. Poleciłbym również ich użycie na poziomie gościa. To prawda, że ​​nie skorzystasz z puli różnych źródeł pamięci ani nie zwiększysz całkowitego dostępnego miejsca na dysku (ponieważ możesz to zrobić równie łatwo, zmieniając rozmiar prezentacji hiperwizora), ale czasami przydzielasz zbyt wiele do jednego systemu plików . Może ci się spodobać prosty sposób, aby wziąć 1 koncert z / opt i przekazać go do / var (na przykład). Jeśli wykonujesz regularne partycje w samej maszynie wirtualnej, to znacznie utrudnia zmianę rozmiaru.

Oprócz innych dobrych odpowiedzi tutaj, jedynym naprawdę dobrym powodem do korzystania z LVM w maszynie wirtualnej jest to, że chcesz przetestować środowisko testowe i uzyskać praktyczne doświadczenia z LVM.

Możesz przeglądać różne HOWTO i samouczki, ćwiczyć wspólne (i nie tak powszechne) taksówki administracyjne LVM, konfigurować różne scenariusze awarii i nauczyć się, jak sobie z nimi radzić.

tj. jako pomoc samokształcenia.

Edycja: Poniższe nie jest już prawdą. Wartość zastosowania cienkiego udostępniania udostępnianego przez LVM dla obrazów dysków VM jest prawdopodobnie sytuacyjna;

Czy używasz programistycznych maszyn wirtualnych na laptopie? wtedy prawdopodobnie lepiej Ci z QCow2.

Zarządzasz farmą maszyn wirtualnych, która może wykorzystywać ogromne ilości pamięci na wielu dyskach? LVM jest prawdopodobnie dobrym sposobem zarządzania tym magazynem.

Jednym z powodów, dla których nie należy używać lvm, jest to, że nie można przeciążać pamięci za pomocą lvm. Jeśli utworzysz 10 maszyn wirtualnych ze 100 GB pamięci, potrzebujesz 1000 GB rzeczywistego dysku, nawet jeśli 9 na dziesięć maszyn wirtualnych będzie kiedykolwiek wykorzystywać tylko 20 GB swoich systemów plików. Obrazy rzadkich dysków lub obrazy w formacie qcow2 mogą oznaczać, że tylko pamięć faktycznie używana przez gości musi zostać im przydzielona.

To, czy jest to naprawdę przydatne, zależy od tego, czego potrzebujesz z pamięci.