Grupo de volúmenes LVM compartido entre el host KVM / libvirt y los invitados: ¿es una mala idea?

12

Acabo de construir un nuevo y brillante host de máquina virtual basado en KVM / libvirt, que contiene 4 discos duros SATA II y ejecuta CentOS 5.5 x86_64.

Decidí crear discos de máquinas virtuales como volúmenes lógicos en un grupo de volúmenes LVM administrado como un grupo de almacenamiento de libvirt, en lugar de la práctica habitual de crear los discos como imágenes qcow.

Lo que no puedo decidir es si debo crear los volúmenes lógicos de la máquina virtual en el grupo de volúmenes del host VM o en un grupo de volúmenes dedicado.

¿Qué método debo elegir y por qué?

Método 1: use el grupo de volúmenes del host VM

Implementación:

  • RAID1 pequeño que md0contiene el /bootsistema de archivos
  • RAID10 grande que md1ocupa el espacio restante, que contiene un grupo de volúmenes LVM vghost. vghostcontiene el sistema de archivos raíz del host VM y la partición de intercambio
  • crear discos de máquinas virtuales como volúmenes lógicos vghostsegún sea necesario

Pros:

  • si el sistema de archivos raíz del host VM se queda sin espacio, puedo asignar más espacio vghostcon relativa facilidad
  • El sistema ya está en funcionamiento (pero no es gran cosa volver a empezar)

Contras:

A pesar del hecho de que este método parece funcionar, no puedo dejar de sentir que de alguna manera es una mala idea. Siento que:

  • esto de alguna manera puede ser un riesgo de seguridad
  • en algún momento en el futuro puedo encontrar alguna limitación con la configuración, y desearía usar un grupo dedicado
  • Es posible que el sistema (CentOS, libvirt, etc.) en realidad no esté diseñado para usarse de esta manera y, por lo tanto, en algún momento podría dañar / perder accidentalmente los archivos y / o el sistema de archivos del host VM

Método 2: use un grupo de volúmenes dedicado

Implementación:

  • igual md0y md1como en el Método 1, excepto hacer md1lo suficientemente grande como para contener el host VM (por ejemplo, 5 a 10 GB)
  • RAID10 grande que ocupa md2el espacio restante. md2contiene un grupo de volúmenes LVM vgvms, cuyos volúmenes lógicos deben ser utilizados exclusivamente por máquinas virtuales

Pros:

  • Puedo jugar vgvmssin temor a romper el sistema operativo host
  • esto parece una solución más elegante y segura

Contras:

  • si el sistema de archivos del host VM se queda sin espacio, tendría que mover partes de su sistema de archivos (por ejemplo, / usr o / var) vgvms, lo que no parece muy agradable.
  • Tengo que reinstalar el sistema operativo host (que, como se dijo anteriormente, realmente no me importa hacerlo)

ACTUALIZACIÓN # 1:

Una razón por la que me preocupa quedarme sin espacio en el disco del host VM en el Método 2 es porque no sé si el host VM es lo suficientemente potente como para ejecutar todos los servicios en máquinas virtuales, es decir. Es posible que tenga que migrar algunos / todos los servicios de máquinas virtuales al sistema operativo host.

Especificación de hardware del host VM:

  • Procesador Phenom II 955 X4 Black Edition (3.2GHz, CPU de 4 núcleos)
  • 2x4GB Kingston PC3-10600 DDR3 RAM
  • Placa base Gigabyte GA-880GM-USB3
  • 4 discos duros WD Caviar RE3 500GB SATA II (7200 rpm)
  • Fuente de alimentación Antec BP500U Basiq 500W ATX
  • Estuche CoolerMaster CM 690

ACTUALIZACIÓN # 2:

Una razón por la que siento que el sistema puede no estar diseñado para usar el host VG como un grupo de almacenamiento de libvirt en el Método 1 es un comportamiento que noté en virt-manager:

  • al agregarlo, se quejó de que no podía activar el VG (obviamente, porque el sistema operativo host ya lo ha activado)
  • al eliminarlo, se negó a hacerlo porque no podía desactivar el VG (obviamente, porque el sistema operativo host todavía está usando los LV de raíz e intercambio)
centos storage lvm software-raid kvm-virtualization mosno
fuente
¡Hice una pregunta (# 272324) donde su solución # 1 habría sido una muy buena respuesta! Y esto es exactamente lo que busqué en una configuración similar, y hasta ahora estoy bastante feliz con eso. Sin embargo, tengo un problema en el que diskIO dentro del Guest es mucho más lento que si se "monta en bucle" el mismo LV en el Host.
stolsvik

Respuestas:

3

¡Pregunta bien pensada!

Yo iría con el Método 2, pero eso es más una preferencia personal. Para mí, los inconvenientes del Método 2 no son un gran problema. No veo que el sistema operativo host supere su partición de 5-10 GB, a menos que comience a instalar cosas adicionales en él, lo que realmente no debería. En aras de la simplicidad y la seguridad, el sistema operativo host realmente debería ser una instalación mínima, sin ejecutar nada excepto el mínimo necesario para la administración (por ejemplo, sshd).

Las desventajas del Método 1 tampoco son realmente un problema, OMI. No creo que haya ningún riesgo de seguridad adicional, ya que si una máquina virtual rooteada es capaz de salir de su partición e infectar / dañar otras particiones, tener el sistema operativo host en un VG separado podría no hacer ninguna diferencia. Los otros dos Contras no son algo con lo que pueda hablar por experiencia directa, pero creo que CentOS, LVM y libvirt son lo suficientemente flexibles y robustos como para no preocuparse por ellos.

EDITAR - Respuesta a la actualización 1

En estos días, el impacto en el rendimiento de la virtualización es muy bajo, especialmente usando procesadores con soporte incorporado, por lo que no creo que valga la pena hacer un servicio desde una VM invitada al sistema operativo host. Es posible que obtenga un aumento de velocidad del 10% si se ejecuta en el "metal desnudo", pero perdería los beneficios de tener un sistema operativo host pequeño, apretado y seguro, y podría afectar la estabilidad de todo el servidor. No vale la pena, en mi opinión.

A la luz de esto, aún favorecería el Método 2.

Respuesta a la actualización 2

Parece que la forma particular en que libvirt supone que se almacena el almacenamiento es otro punto a favor del Método 2. Mi recomendación es: vaya con el Método 2.

Steven Monday
fuente
Gracias. He agregado 2 actualizaciones a mi pregunta, que explican por qué he enumerado algunos de los inconvenientes que ha abordado. ¿Las actualizaciones cambian tu opinión?
mosno
@mosno: Actualicé mi respuesta en respuesta a tus actualizaciones.
Steven lunes
Gracias a todos por sus respuestas, todos me han sido útiles y fue difícil elegir qué respuesta aceptar. Elijo a Steven porque siento que hace el mejor esfuerzo para abordar la pregunta que se hace. Para el registro, si bien estoy de acuerdo con que el Método 2 es probablemente mejor, decidí quedarme con el Método 1 porque funciona y por limitaciones de tiempo.
mosno
1
Además, me quedo con el Método 1 por ahora porque creo que sería educativo explorar las limitaciones de este método. Por ejemplo, aprendí que si en un SO invitado crea un LVM PG directamente en el dispositivo (por ejemplo, dispositivo / dev / vda en lugar de partición / dev / vda1), entonces el pvscan del SO host enumera el PV del invitado (es decir. use / dev / vda1, no / dev / vda).
mosno
1

Mientras solo un sistema intente usar cualquier LV dado en modo lectura / escritura en cualquier momento, es factible usar el mismo VG para el anfitrión y los invitados. Si varios sistemas intentan escribir en el mismo LV, se producirá la corrupción del sistema de archivos.

Ignacio Vazquez-Abrams
fuente
Ciertamente hay un mayor nivel de complejidad para gestionar esto. Es inteligente ... tal vez demasiado inteligente.
El conserje de Unix
@ user37899: esta es la forma habitual de manejar LVM
Javier
gracias, pero entiendo eso; No estaba planeando hacer eso.
mosno
cuando hago un "lvscan" en el sistema operativo host, informa que el LV del invitado es "ACTIVO". El host no tiene el LV montado. ¿El LV simplemente estando en estado "ACTIVO" constituye un "modo de lectura / escritura", o quiere decir un montaje explícito en el sistema de archivos del host?
mosno
Me refiero a un montaje explícito de r / w.
Ignacio Vazquez-Abrams
1

Es posible que desee echar un vistazo a esto, tal vez jugar y ver cómo este proyecto hace lo que está hablando.

ProxmoxVE es un host KVM de metal desnudo que utiliza una implementación perl de libvirt en lugar de la contraparte más pesada de RHEL. Implementa ambos escenarios.

Los discos virtuales son .raw y dispersos, similares a .qcow pero más rápidos.

Los formatos de imagen de disco qcow y vmdk también son compatibles, pero creo que pueden existir limitaciones de LVM. No los uso, así que no puedo decir mucho al respecto.

El almacenamiento LVM se comparte entre las máquinas virtuales en el nodo y puede ser dispositivos DRBD.

En cuanto a compartir el espacio VG del sistema operativo, la única limitación que debe preocuparse es el tamaño de la instantánea durante las copias de seguridad. Aquí este valor se puede cambiar en un archivo de configuración, y a veces veo en los foros donde la gente ha tenido que cambiarlo, pero los valores predeterminados me han servido bien durante un par de años, incluso con enormes discos virtuales.

Detalles de almacenamiento LVM de PVE:

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

Así es como se presentan los VG:

Se encontró el grupo de volúmenes "LDatastore1" utilizando metadatos tipo lvm2

Se encontró el grupo de volúmenes "LDatastore0" utilizando metadatos tipo lvm2

Grupo de volúmenes encontrado "pve" utilizando metadatos tipo lvm2

Estos son mis LV:

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

ACTIVE '/ dev / LDatastore1 / vm-7060-disk-1' [2.00 GB] hereda

ACTIVE '/ dev / LDatastore1 / vm-5555-disk-1' [8.00 GB] hereda

ACTIVE '/ dev / LDatastore0 / vm-4017-disk-1' [8.00 GB] hereda

ACTIVE '/ dev / LDatastore0 / vm-4017-disk-2' [512.00 GB] hereda

ACTIVE '/ dev / LDatastore0 / vm-7057-disk-1' [32.00 GB] hereda

ACTIVE '/ dev / LDatastore0 / vm-7055-disk-1' [32.00 GB] hereda

ACTIVE '/ dev / LDatastore0 / vm-6030-disk-1' [80.01 GB] hereda

ACTIVE '/ dev / pve / swap' [3.62 GB] hereda

ACTIVE '/ dev / pve / root' [7.25 GB] heredar

ACTIVE '/ dev / pve / data' [14.80 GB] hereda

Este es LVM en RAID10 hecho de 6 unidades SATA Seagate Barracuda de 7200 rpm:

CPU BOGOMIPS: 53199.93

REGEX / SEGUNDO: 824835

TAMAÑO DE HD: 19.69 GB (/ dev / mapper / LDatastore0-testlv)

LECTURAS BUFFERED: 315.17 MB / seg

TIEMPO DE BÚSQUEDA MEDIA: 7.18 ms

FSYNCS / SEGUNDO: 2439.31

Y este es LVM en un único SSD Intel X25-E SATA, el mismo VG que el mencionado / dev / pve / data donde viven las máquinas virtuales:

CPU BOGOMIPS: 53203.97

REGEX / SEGUNDO: 825323

TAMAÑO DE HD: 7.14 GB (/ dev / mapper / pve-root)

LECTURAS BUFFERED: 198.52 MB / seg

TIEMPO DE BÚSQUEDA MEDIA: 0.26 ms

FSYNCS / SEGUNDO: 1867.56

NginUS
fuente