1
Consulta básica sobre LVM

Open 1 Respuestas 1 Views
Estoy haciendo las primeras pruebas con LVM y tengo una duda que, creo, requiere más de la experiencia que del conocimiento teórico.

Aclaración: todo está es en un ambiente virtualizado (sobre Linux), así que existe mucha facilidad para "crear" varios discos de distintos tamaños. Los filesystems son xfs.

Necesito armar dos filesystems con distintas características: uno con un tamaño determinado que probablemente no crezca más que eso y, por otro lado, un filesystem con datafiles de una base de datos y que irá creciendo sostenidamente con el tiempo.

Como no quiero crear discos innecesariamente grandes ahora, pensé armar un LVM que me vaya permitiendo agregar nuevos discos a medida que los necesite.

La pregunta es ¿qué conviene más: crear dos VG con un LV cada uno o crear un sólo VG que tenga dos LV?

Intuitivamente iría por la opción 1 (2 VG) para separar las cosas y tratándose de dos LV supongo que no habrá mucha diferencia hacerlo de una forma u otra... pero en general (pensando en varios VGs/LVs): ¿que es lo que se recomienda? ¿tener varios VG o tener la menor cantidad posibles de VG? ¿O es lo mismo?
Aclaración final: la pregunta va más por el lado de la administración... o de performance "significativo"  (no tanto si es por mejorar 37 milisegundos en una operación de diez segundos) :)

Desde ya, muchas gracias

1 Respuesta

2

Más allá de la diferencia 'organizativa', es más o menos lo mismo, sobretodo si no vas a estar haciendo otras cosas a nivel LVM como clustering y eso. Usá lo que te convenga más.

Una aclaración: tomo por "agregar nuevos discos a medida que los necesite" como literal, ir agregando discos bajo LVM y extendiendo VG/LV acorde y no thin provisioning. No uses thin provisioning en nada que tenga mucho I/O (como ser, una base de datos)

respondido por godlike (8,230 puntos) Oct 24
1Comentarios
comentado por HacheEle (920 puntos) Oct 25
Gracias por la respuesta.
Efectivamente, lo decía en sentido literal y no me refería a thin provisioning (aunque tambíen es muy buen dato).
...