Gruppo di volumi LVM condiviso tra host KVM / libvirt e ospiti: è una cattiva idea?


12

Ho appena creato un nuovo host di macchine virtuali basato su KVM / libvirt, contenente 4 dischi rigidi SATA II e con CentOS 5.5 x86_64.

Ho deciso di creare dischi di macchine virtuali come volumi logici in un gruppo di volumi LVM gestito come pool di archiviazione libvirt, invece della solita pratica di creare dischi come immagini qcow.

Ciò su cui non posso decidere è se devo creare i volumi logici della macchina virtuale nel gruppo di volumi dell'host di macchine virtuali o in un gruppo di volumi dedicato.

Quale metodo dovrei scegliere e perché?


Metodo 1: utilizzare il gruppo di volumi dell'host di macchine virtuali

Implementazione:

  • piccolo RAID1 md0contenente il /bootfilesystem
  • RAID10 di grandi dimensioni che md1occupa lo spazio rimanente, che contiene un gruppo di volumi LVM vghost. vghostcontiene il filesystem di root dell'host VM e la partizione di swap
  • creare dischi di macchine virtuali come volumi logici vghostcome richiesto

Professionisti:

  • se il filesystem di root dell'host VM esaurisce lo spazio, posso allocare più spazio vghostcon relativa facilità
  • Il sistema è già attivo e funzionante (ma non è un grosso problema ricominciare da capo)

Contro:

A parte il fatto che questo metodo sembra funzionare, non riesco a scuotere la sensazione che questa sia in qualche modo una cattiva idea. Sento che:

  • questo potrebbe in qualche modo essere un rischio per la sicurezza
  • ad un certo punto in futuro potrei trovare qualche limitazione con la configurazione e desiderare di usare un gruppo dedicato
  • il sistema (CentOS, libvirt, ecc.) potrebbe non essere progettato per essere utilizzato in questo modo, e quindi ad un certo punto potrei accidentalmente corrompere / perdere i file e / o il filesystem dell'host VM

Metodo 2: utilizzare un gruppo di volumi dedicato

Implementazione:

  • stesso md0e md1come nel Metodo 1, tranne md1che per essere abbastanza grande da contenere per l'host di macchine virtuali (es. da 5 a 10 GB)
  • RAID10 di grandi dimensioni che md2occupa lo spazio rimanente. md2contiene un gruppo di volumi LVM vgvms, i cui volumi logici devono essere utilizzati esclusivamente dalle macchine virtuali

Professionisti:

  • Posso armeggiare vgvmssenza paura di rompere il sistema operativo host
  • questa sembra una soluzione più elegante e sicura

Contro:

  • se il filesystem dell'host VM esaurisce lo spazio, dovrei spostare parti del suo filesystem (es. / usr o / var) vgvms, il che non sembra molto carino.
  • Devo reinstallare il sistema operativo host (che, come affermato in precedenza, non mi dispiace davvero farlo)

AGGIORNAMENTO N. 1:

Uno dei motivi per cui sono preoccupato di rimanere senza spazio su disco nell'host di macchine virtuali nel metodo 2 è perché non so se l'host di macchine virtuali è abbastanza potente da eseguire tutti i servizi nelle macchine virtuali, ad esempio. Potrei dover migrare alcuni / tutti i servizi dalle macchine virtuali al sistema operativo host.

Specifiche hardware dell'host di macchine virtuali:

  • Processore Phenom II 955 X4 Black Edition (3.2GHz, CPU a 4 core)
  • RAM DDR3 Kingston PC3-10600 da 2x4 GB
  • Scheda madre Gigabyte GA-880GM-USB3
  • 4x HDD SATA II da 500 GB WD Caviar RE3 (7200rpm)
  • Antec BP500U Basiq 500W ATX alimentatore
  • Custodia CoolerMaster CM 690

AGGIORNAMENTO # 2:

Uno dei motivi per cui ritengo che il sistema potrebbe non essere progettato per utilizzare l'host VG come pool di archiviazione libvirt nel Metodo 1 è un comportamento che ho notato in virt-manager:

  • dopo l'aggiunta, si è lamentato di non poter attivare il VG (ovviamente, poiché il sistema operativo host lo ha già attivato)
  • al momento della rimozione, ha rifiutato di farlo perché non è stato possibile disattivare il VG (ovviamente, poiché il sistema operativo host sta ancora utilizzando i LV root e swap)

Ho fatto una domanda (# 272324) in cui la soluzione numero 1 sarebbe stata un'ottima risposta! E questo è esattamente quello che sono andato in una configurazione simile - e finora sono abbastanza soddisfatto. Tuttavia ho un problema in cui diskIO all'interno del Guest è molto più lento di se "monta in loop" lo stesso LV nell'Host.
stolsvik,

Risposte:


3

Domanda ben ponderata!

Andrei con il metodo 2, ma è più una preferenza personale. Per me, i contro del metodo 2 non rappresentano un grosso problema. Non vedo il sistema operativo host superare la sua partizione da 5-10 GB, a meno che non inizi a installare roba extra su di esso, cosa che non dovresti davvero. Per motivi di semplicità e sicurezza, il sistema operativo host dovrebbe essere in realtà un'installazione minimale, senza eseguire nulla tranne il minimo indispensabile per l'amministrazione (ad esempio sshd).

I contro del metodo 1 non sono nemmeno un problema, IMO. Non penso che ci sarebbe un ulteriore rischio per la sicurezza, dal momento che se una VM con root è in qualche modo in grado di uscire dalla sua partizione e infettare / danneggiare altre partizioni, avere il sistema operativo host su un VG separato potrebbe non fare alcuna differenza. Gli altri due contro non sono qualcosa con cui posso parlare per esperienza diretta, ma il mio istinto dice che CentOS, LVM e libvirt sono abbastanza flessibili e robusti da non preoccuparsene.

EDIT - Risposta all'aggiornamento 1

Al giorno d'oggi, il successo delle prestazioni della virtualizzazione è molto basso, in particolare utilizzando processori con supporto integrato, quindi non credo che valga la pena spostare un servizio da una VM guest al sistema operativo host. Si potrebbe ottenere un aumento di velocità del 10% eseguendo sul "bare metal", ma si perderebbe i vantaggi di avere un piccolo, stretto, sistema operativo host sicuro, e potenzialmente un impatto sulla stabilità dell'intera server. Non ne vale la pena, IMO.

Alla luce di ciò, preferirei ancora il Metodo 2.

Risposta all'aggiornamento 2

Sembra che il modo particolare in cui libvirt presuppone che sia disposta la memoria sia un altro punto a favore del Metodo 2. La mia raccomandazione è: andare con il Metodo 2.


Grazie. Ho aggiunto 2 aggiornamenti alla mia domanda, il che spiega ulteriormente perché ho elencato alcuni dei contro che hai affrontato. Gli aggiornamenti cambiano la tua opinione?
mosno,

@mosno: aggiornata la mia risposta in risposta ai tuoi aggiornamenti.
Steven lunedì

Grazie a tutti per le vostre risposte, tutti mi sono stati utili ed è stato difficile scegliere la risposta da accettare. Sto scegliendo Steven perché ritengo che faccia il possibile per rispondere alla domanda posta. Per la cronaca, mentre concordo sul fatto che il Metodo 2 sia probabilmente migliore, ho scelto di rimanere con il Metodo 1 perché funziona e per motivi di tempo.
mosno,

1
Inoltre, rimarrò con il Metodo 1 per ora perché penso che sarebbe istruttivo esplorare i limiti di questo metodo. Ad esempio, ho imparato che se in un SO guest si crea un PG LVM direttamente sul dispositivo (es. Device / dev / vda invece di partizione / dev / vda1), allora il pvscan del sistema operativo host elenca il PV del guest (es. usa / dev / vda1, non / dev / vda).
mosno,

1

Finché un solo sistema tenta di utilizzare qualsiasi dato LV in modalità lettura / scrittura in qualsiasi momento, è possibile utilizzare lo stesso VG per host e guest. Se più sistemi tentano di scrivere sullo stesso LV, si verificherà la corruzione del filesystem.


c'è sicuramente un maggiore livello di complessità per gestirlo. È intelligente ... forse troppo intelligente.
Unix Janitor,

@ user37899: questo è il solito modo di gestire LVM
Javier l'

grazie, ma lo capisco; Non avevo intenzione di farlo.
mosno,

quando eseguo un "lvscan" sul sistema operativo host, segnala LV dell'ospite come "ATTIVO". L'host non ha LV montato. Il LV semplicemente nello stato "ATTIVO" costituisce una "modalità di lettura / scrittura" o intendi un montaggio esplicito sul filesystem dell'host?
mosno,

Intendo una montatura esplicita a sinistra.
Ignacio Vazquez-Abrams,

1

Potresti dare un'occhiata a questo, forse armeggiare e vedere come questo progetto fa quello di cui stai parlando.

ProxmoxVE è un host KVM bare metal che utilizza un'implementazione perl di libvirt anziché la controparte più pesante di RHEL. Implementa entrambi gli scenari.

I dischi virtuali sono .raw e sparsi, simili a .qcow ma più veloci.

Sono supportati anche i formati di immagine del disco qcow e vmdk, ma penso che potrebbero esserci delle limitazioni LVM. Non li uso quindi non posso dire molto al riguardo.

L'archiviazione LVM è condivisa tra VM sul nodo e può essere un dispositivo DRBD.

Per quanto riguarda la condivisione dello spazio VG del sistema operativo, l'unica limitazione da considerare è la dimensione dell'istantanea durante i backup. Qui questo valore può essere modificato in un file di configurazione, e vedo a volte nei forum in cui le persone hanno dovuto cambiarlo, ma i valori predefiniti mi sono serviti bene per un paio d'anni, anche con enormi dischi virtuali.

Dettagli di archiviazione LVM di PVE:

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

Ecco come sono strutturati i VG:

Trovato il gruppo di volumi "LDatastore1" utilizzando metadati di tipo lvm2

Trovato il gruppo di volumi "LDatastore0" utilizzando metadati di tipo lvm2

Trovato gruppo di volumi "pve" utilizzando metadati di tipo lvm2

Questi sono i miei LV:

ACTIVE '/ dev / LDatastore1 / vm-9098-disk-1' [4.00 GB] eredita

ACTIVE '/ dev / LDatastore1 / vm-7060-disk-1' [2,00 GB] eredita

ACTIVE '/ dev / LDatastore1 / vm-5555-disk-1' [8,00 GB] eredita

ACTIVE '/ dev / LDatastore0 / vm-4017-disk-1' [8,00 GB] eredita

ACTIVE '/ dev / LDatastore0 / vm-4017-disk-2' [512,00 GB] eredita

ACTIVE '/ dev / LDatastore0 / vm-7057-disk-1' [32,00 GB] eredita

ACTIVE '/ dev / LDatastore0 / vm-7055-disk-1' [32,00 GB] eredita

ACTIVE '/ dev / LDatastore0 / vm-6030-disk-1' [80,01 GB] eredita

ACTIVE "/ dev / pve / swap" [3,62 GB] eredita

ATTIVO '/ dev / pve / root' [7.25 GB] eredita

ATTIVO '/ dev / pve / data' [14.80 GB] ereditato

Questo è LVM su RAID10 composto da 6 unità SATA Seagate Barracuda da 7200 rpm:

BOGOMIPS CPU: 53199.93

REGICE / SECONDO: 824835

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

LETTURE BUFFERATE: 315,17 MB / sec

TEMPO DI RICERCA MEDIA: 7.18 ms

FSYNCS / SECONDO: 2439.31

E questo è LVM su un singolo SSD Intel X25-E SATA, stesso VG del suddetto / dev / pve / data in cui vivono le VM:

BOGOMIPS CPU: 53203.97

REGICE / SECONDO: 825323

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

LETTURE BUFFERATE: 198,52 MB / sec

TEMPO DI RICERCA MEDIA: 0,26 ms

FSYNCS / SECONDO: 1867.56

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.