Grupa woluminów LVM współdzielona między hostem KVM / libvirt a gośćmi: czy to zły pomysł?

12

Właśnie zbudowałem nowy błyszczący host maszyny wirtualnej oparty na KVM / libvirt, zawierający 4 dyski twarde SATA II i działający CentOS 5.5 x86_64.

Zdecydowałem się utworzyć dyski maszyn wirtualnych jako woluminy logiczne w grupie woluminów LVM zarządzanej jako pula pamięci libvirt, zamiast zwykłej praktyki tworzenia dysków jako obrazów qcow.

Nie mogę zdecydować, czy powinienem utworzyć woluminy logiczne maszyny wirtualnej w grupie woluminów hosta maszyny wirtualnej, czy w dedykowanej grupie woluminów.

Którą metodę powinienem wybrać i dlaczego?

Metoda 1: Użyj grupy woluminów hosta VM

Realizacja:

  • mały RAID1 md0zawierający /bootsystem plików
  • duża RAID10 md1zajmująca pozostałą przestrzeń, która zawiera grupę woluminów LVM vghost. vghostzawiera główny system plików hosta VM i partycję wymiany
  • utwórz dyski maszyny wirtualnej jako woluminy logiczne vghostzgodnie z wymaganiami

Plusy:

  • jeśli w głównym systemie plików hosta VM zabraknie miejsca, mogę przydzielić więcej miejsca vghoststosunkowo łatwo
  • System jest już gotowy do pracy (ale nie jest niczym nowym, aby zacząć od nowa)

Cons:

Pomijając fakt, że ta metoda wydaje się działać, nie mogę pozbyć się wrażenia, że ​​jest to zły pomysł. Czuję to:

  • może to w jakiś sposób stanowić zagrożenie bezpieczeństwa
  • w pewnym momencie w przyszłości mogę znaleźć pewne ograniczenia związane z konfiguracją i żałuję, że nie korzystałem z dedykowanej grupy
  • system (CentOS, libvirt itp.) może nie być tak zaprojektowany, aby mógł być używany w ten sposób, i dlatego w pewnym momencie mogę przypadkowo uszkodzić / utracić pliki hosta VM i / lub system plików

Metoda 2: Użyj dedykowanej grupy woluminów

Realizacja:

  • tak samo md0i md1jak w sposobie 1, z wyjątkiem make md1prostu wystarczająco duży, aby zawierać dla hosta VM (np. 5 do 10 GB)
  • duża RAID10 md2zajmująca pozostałą przestrzeń. md2zawiera grupę woluminów LVM vgvms, których woluminy logiczne mają być używane wyłącznie przez maszyny wirtualne

Plusy:

  • Mogę majstrować vgvmsbez obawy o uszkodzenie systemu operacyjnego hosta
  • wydaje się to bardziej eleganckim i bezpiecznym rozwiązaniem

Cons:

  • jeśli w systemie plików hosta VM zabraknie miejsca, musiałbym przenieść części jego systemu plików (np. / usr lub / var) na vgvms, co nie wydaje się zbyt przyjemne.
  • Muszę ponownie zainstalować system operacyjny hosta (który, jak wspomniano wcześniej, nie mam nic przeciwko temu)

AKTUALIZACJA # 1:

Jednym z powodów, dla których martwię się brakiem miejsca na dysku hosta VM w Metodzie 2, jest to, że nie wiem, czy host VM jest wystarczająco silny, aby uruchomić wszystkie usługi na maszynach wirtualnych, tj. Być może będę musiał przeprowadzić migrację niektórych / wszystkich usług z maszyn wirtualnych do systemu operacyjnego hosta.

Specyfikacja sprzętu hosta VM:

  • Procesor Phenom II 955 X4 Black Edition (3,2 GHz, 4-rdzeniowy procesor)
  • 2x4 GB pamięci RAM Kingston PC3-10600 DDR3
  • Płyta główna Gigabyte GA-880GM-USB3
  • 4x dyski twarde WD Caviar RE3 500 GB SATA II (7200 obr./min)
  • Antec BP500U Basiq 500W zasilacz ATX
  • Obudowa CoolerMaster CM 690

AKTUALIZACJA # 2:

Jednym z powodów, dla których uważam, że system może nie być zaprojektowany do używania hosta VG jako puli pamięci libvirt w Metodzie 1, jest pewne zachowanie, które zauważyłem w virt-manager:

  • po dodaniu skarżył się, że nie może aktywować VG (oczywiście, ponieważ system operacyjny hosta już ją aktywował)
  • po usunięciu odmówił tego, ponieważ nie mógł dezaktywować VG (oczywiście, ponieważ system operacyjny hosta nadal używa root i swap LV)
centos storage lvm software-raid kvm-virtualization mosno
źródło
Zadałem pytanie (nr 272324), gdzie twoje rozwiązanie nr 1 byłoby bardzo dobrą odpowiedzią! I właśnie tego szukałem w podobnej konfiguracji - i jak dotąd jestem z tego całkiem zadowolony. Mam jednak problem z tym, że diskIO w ramach Gościa jest znacznie wolniejsze niż w przypadku „montowania w pętli” tego samego LV na hoście.
stolsvik

Odpowiedzi:

3

Dobrze przemyślane pytanie!

Wybrałbym Metodę 2, ale to bardziej osobiste preferencje. Dla mnie Wady Metody 2 nie stanowią większego problemu. Nie widzę, aby system operacyjny hosta przerastał partycję 5-10 GB, chyba że zaczniesz instalować na nim dodatkowe rzeczy, których tak naprawdę nie powinieneś. Ze względu na prostotę i bezpieczeństwo, system operacyjny hosta powinien być naprawdę minimalną instalacją, nie uruchamiającą niczego poza absolutnym minimum niezbędnym do administrowania (np. Sshd).

Wady metody 1 nie są tak naprawdę problemem, IMO. Nie sądzę, aby istniało dodatkowe ryzyko bezpieczeństwa, ponieważ jeśli zrootowana maszyna wirtualna jest w stanie w jakiś sposób wyłamać się ze swojej partycji i zainfekować / uszkodzić inne partycje, posiadanie systemu operacyjnego hosta na oddzielnym VG może nie mieć znaczenia. Pozostałe dwa minusy nie są czymś, z czego mogę bezpośrednio porozmawiać, ale ja mam przeczucie, że CentOS, LVM i libvirt są elastyczne i wystarczająco solidne, aby się o nie martwić.

EDYCJA - Odpowiedź na aktualizację 1

W dzisiejszych czasach wydajność wirtualizacji jest bardzo niska, szczególnie przy użyciu procesorów z wbudowaną obsługą, więc nie sądzę, aby przeniesienie usługi z maszyny wirtualnej gościa do systemu operacyjnego hosta było kiedykolwiek warte zastosowania. Państwo może uzyskać zwiększenie prędkości 10% działa na „gołego metalu”, ale można stracić korzyści z posiadania małe, ciasne, bezpieczny system operacyjny hosta i potencjalnie wpłynąć na stabilność całego serwera. Nie warto, IMO.

W związku z tym nadal wolałbym Metodę 2.

Odpowiedź na aktualizację 2

Wydaje się, że szczególny sposób, w jaki libvirt zakłada przechowywanie, jest kolejnym punktem przemawiającym za Metodą 2. Moje zalecenie to: przejdź do Metody 2.

Steven Monday
źródło
dzięki. Do mojego pytania dodałem 2 aktualizacje, które dodatkowo wyjaśniają, dlaczego wymieniłem niektóre z wad, które skierowałeś. Czy aktualizacje w ogóle zmieniają twoją opinię?
mosno
@mosno: Zaktualizowałem moją odpowiedź w odpowiedzi na twoje aktualizacje.
Steven poniedziałek,
Dziękuję wszystkim za odpowiedzi, wszystkie były dla mnie pomocne i trudno było wybrać, czyją odpowiedź przyjąć. Wybieram Stevena, ponieważ uważam, że najlepiej jest odpowiedzieć na zadane pytanie. Dla przypomnienia, chociaż zgadzam się, że Metoda 2 jest prawdopodobnie lepsza, zdecydowałem się pozostać przy Metodzie 1, ponieważ działa i ze względu na ograniczenia czasowe.
mosno
1
Pozostaję też na razie w Metodzie 1, ponieważ uważam, że odkrywanie ograniczeń tej metody byłoby edukacyjne. Na przykład dowiedziałem się, że jeśli w systemie-gościu tworzysz LVM PG bezpośrednio na urządzeniu (np. Urządzenie / dev / vda zamiast partycji / dev / vda1), to pvscan systemu operacyjnego hosta wyświetla listę PV gościa (tj. użyj / dev / vda1, nie / dev / vda).
mosno
1

Tak długo, jak tylko jeden system próbuje użyć dowolnego LV w trybie odczytu / zapisu w dowolnym momencie, możliwe jest użycie tego samego VG dla hosta i gości. Jeśli wiele systemów spróbuje zapisać w tym samym LV, spowoduje to uszkodzenie systemu plików.

Ignacio Vazquez-Abrams
źródło
z pewnością istnieje wyższy poziom złożoności, aby sobie z tym poradzić. To sprytne ... może zbyt sprytne.
The Unix Janitor
@ user37899: jest to zwykły sposób obsługi LVM
Javier
dzięki, ale rozumiem to; Nie planowałem tego zrobić.
mosno
kiedy wykonuję „lvscan” na systemie operacyjnym hosta, raportuje on LV gościa jako „AKTYWNY”. Host nie ma zamontowanego LV. Czy LV po prostu w stanie „AKTYWNYM” stanowi „tryb odczytu / zapisu”, czy masz na myśli jawne podłączenie do systemu plików hosta?
mosno
Mam na myśli jawne montowanie r / w.
Ignacio Vazquez-Abrams,
1

Możesz rzucić okiem na to, może majstrować i zobaczyć, jak ten projekt robi to, o czym mówisz.

ProxmoxVE jest hostem KVM bez systemu operacyjnego, który wykorzystuje perlową implementację libvirt zamiast cięższego odpowiednika RHEL. Implementuje oba scenariusze.

Dyski wirtualne są .raw i rzadkie, podobne do .qcow, ale szybsze.

Obsługiwane są również formaty obrazów dysku qcow i vmdk, ale myślę, że mogą występować ograniczenia LVM. Nie używam ich, więc nie mogę o tym wiele powiedzieć.

Magazyn LVM jest współdzielony między maszynami wirtualnymi w węźle i może być urządzeniami DRBD.

Jeśli chodzi o współdzielenie przestrzeni VG systemu operacyjnego, jedynym ograniczeniem, które należy wziąć pod uwagę, jest rozmiar migawki podczas tworzenia kopii zapasowych. Tutaj tę wartość można zmienić w pliku konfiguracyjnym, a czasami widzę na forach, gdzie ludzie musieli ją zmienić, ale wartości domyślne służyły mi już od kilku lat - nawet przy dużych wirtualnych dyskach.

Szczegóły przechowywania LVM PVE:

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

Tak wyglądają VG:

Znaleziono grupę woluminów „LDatastore1” przy użyciu typu metadanych lvm2

Znaleziono grupę woluminów „LDatastore0” przy użyciu typu metadanych lvm2

Znaleziono grupę woluminów „pve” przy użyciu metadanych typu lvm2

Oto moje LV:

AKTYWNE '/ dev / LDatastore1 / vm-9098-disk-1' [4.00 GB] dziedziczenie

AKTYWNE '/ dev / LDatastore1 / vm-7060-disk-1' [2.00 GB] dziedziczenie

AKTYWNE '/ dev / LDatastore1 / vm-5555-disk-1' [8.00 GB] dziedziczenie

AKTYWNE '/ dev / LDatastore0 / vm-4017-disk-1' [8.00 GB] dziedziczenie

AKTYWNE '/ dev / LDatastore0 / vm-4017-disk-2' [512.00 GB] dziedziczą

AKTYWNE '/ dev / LDatastore0 / vm-7057-disk-1' [32.00 GB] inherit

AKTYWNE '/ dev / LDatastore0 / vm-7055-disk-1' [32.00 GB] inherit

AKTYWNE '/ dev / LDatastore0 / vm-6030-disk-1' [80.01 GB] dziedziczenie

AKTYWNE '/ dev / pve / swap' [3.62 GB] dziedziczą

AKTYWNE '/ dev / pve / root' [7.25 GB] inherit

AKTYWNE '/ dev / pve / data' [14.80 GB] dziedziczą

Oto LVM na RAID10 wykonanym z 6 7200 obr./min. Dyskami SATA Barracuda SATA:

CPU BOGOMIPS: 53199.93

REGEX / SECOND: 824835

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

ZBUDOWANE CZYTANIA: 315,17 MB / s

ŚREDNI CZAS WYSZUKIWANIA: 7,18 ms

FSYNCS / SECOND: 2439.31

I to jest LVM na pojedynczym dysku SSD Intel X25-E SATA, takim samym VG, jak wspomniane wyżej / dev / pve / data, w którym żyją maszyny wirtualne:

CPU BOGOMIPS: 53203.97

REGEX / SECOND: 825323

ROZMIAR HD: 7,14 GB (/ dev / mapper / pve-root)

BUFOROWANE CZYTANIA: 198,52 MB / s

ŚREDNI CZAS WYSZUKIWANIA: 0,26 ms

FSYNCS / SECOND: 1867.56

NginUS
źródło