¿LVM afecta el rendimiento?

Tengo que migrar algunos servidores a Linux, y un aspecto importante que necesito evaluar es que mi nuevo sistema host debe tener una capacidad de almacenamiento elástica. Naturalmente, haciendo una investigación básica, me encontré con LVM.

¿Hay alguna penalización de rendimiento por usar lvm? Si es así, ¿cómo puedo medirlo?

Lo que estoy considerando en este momento es tener Linux como sistema operativo host con LVM y cajas de Linux virtualizadas ejecutándose encima (¿debo agregar LVM también en el sistema operativo invitado?).

LVM está diseñado de una manera que evita que realmente se interponga en el camino. Desde el punto de vista del espacio de usuario, se ve como otra capa de "material virtual" en la parte superior del disco, y parece natural imaginar que toda la E / S ahora tiene que pasar por esto antes de llegar ao desde lo real hardware.

Pero no es así. El núcleo ya necesita tener un mapeo (o varias capas de mapeo en realidad) que conecta operaciones de alto nivel como "escribir esto en un archivo" a los controladores del dispositivo que a su vez se conectan a bloques reales en el disco.

Cuando LVM está en uso, esa búsqueda cambia, pero eso es todo. (Como tiene que suceder de todos modos, hacerlo un poco diferente es un éxito insignificante en el rendimiento). Cuando se trata de escribir realmente el archivo, los bits toman una ruta tan directa a los medios físicos como lo harían de otra manera.

Hay casos en los que LVM puede causar problemas de rendimiento. Desea asegurarse de que los bloques LVM estén alineados correctamente con el sistema subyacente, lo que debería suceder automáticamente con las distribuciones modernas. Y asegúrese de no estar usando núcleos viejos sujetos a errores como este . Ah, y el uso de instantáneas LVM degrada el rendimiento (y cada vez más con cada instantánea activa). Pero sobre todo, el impacto debería ser muy pequeño.

En cuanto al último: ¿cómo puedes probar? La herramienta de evaluación comparativa de disco estándar es bonnie ++ . Haga una partición con LVM, pruébela, elimínela y (en el mismo lugar, para mantener otros factores idénticos) cree un sistema de archivos simple y vuelva a comparar. Deben ser casi idénticos.

LVM, como todo lo demás, es una bendición mixta.

Con respecto al rendimiento, LVM lo obstaculizará un poco porque es otra capa de abstracción que debe resolverse antes de que los bits lleguen (o puedan leerse) al disco. En la mayoría de las situaciones, este éxito de rendimiento será prácticamente inconmensurable.

Las ventajas de LVM incluyen el hecho de que puede agregar más almacenamiento a los sistemas de archivos existentes sin tener que mover los datos. A la mayoría de la gente le gusta por esta ventaja.

Una desventaja del LVM utilizado de esta manera es que si su almacenamiento adicional abarca discos (es decir, involucra más de un disco), aumenta la probabilidad de que una falla de disco le cueste datos. Si su sistema de archivos abarca dos discos, y cualquiera de ellos falla, probablemente esté perdido. Para la mayoría de las personas, este es un riesgo aceptable debido a razones de espacio versus costo (es decir, si esto es realmente importante, habrá un presupuesto para hacerlo correctamente), y porque, como dicen, las copias de seguridad son buenas, ¿verdad?

Para mí, la única razón para no usar LVM es que la recuperación ante desastres no está (o al menos no estaba) bien definida. Un disco con volúmenes LVM que tenía un sistema operativo codificado no podía conectarse trivialmente a otra computadora y los datos se recuperaron de él; muchas de las instrucciones para recuperar volúmenes LVM parecían incluir pasos como retroceder en el tiempo y ejecutar vgcfgbackup, luego copiar el archivo / etc / lvmconf resultante en el sistema que aloja su volumen retenido . Esperemos que las cosas hayan cambiado en los tres o cuatro años desde la última vez que tuve que ver esto, pero personalmente nunca uso LVM por este motivo.

Eso dicho

En su caso, supongo que las máquinas virtuales serán relativamente pequeñas en comparación con el sistema host. Esto significa que para mí es más probable que desee expandir el almacenamiento en una máquina virtual más adelante; Esto se hace mejor agregando otro disco virtual a la VM y luego haciendo crecer los sistemas de archivos de VM afectados. No tiene la vulnerabilidad spanning-multiple-disks porque los discos virtuales probablemente estarán en el mismo dispositivo físico en el sistema host.

Si las máquinas virtuales van a tener alguna importancia para usted, estará RAID 'de alguna manera al sistema host, lo que reducirá la flexibilidad para aumentar el almacenamiento más adelante. Por lo tanto, la flexibilidad de LVM probablemente no será necesaria.

Por lo tanto, supongo que no usaría LVM en el sistema host, sino que instalaría máquinas virtuales para usar LVM.

En general: si agrega una nueva capa de complejidad ("también conocido como más por hacer"), nada será más rápido. Nota: Solo agrega trabajo y no 'cambia' la forma en que se hace el trabajo.

¿Cómo puedes medir algo? Bueno, creas una partición con LVM y otra sin ella, luego usas un punto de referencia normal y simplemente lo ejecutas. Como la gente de

http://www.umiacs.umd.edu/~toaster/lvm-testing/

Como parece, solo impacta ligeramente a la velocidad. Eso parece sincronizarse con los hallazgos de otra persona que realizó un punto de referencia:

"ext4 es más rápido con LVM que sin él y otros puntos de referencia del sistema de archivos" Hilo de la lista de correo del kernel de Linux

Pero solo hágalo como referencia y vea si su hardware y el sistema operativo que desea usar se comportan de la misma manera y si puede ignorar el impacto (tal vez levemente) de una capa adicional de complejidad que le brinda almacenamiento elástico.

¿Debería agregar LVM al sistema operativo invitado? Eso depende de si necesita que el sistema operativo invitado también tenga almacenamiento elástico, ¿no es así? Sus necesidades dictan lo que tiene que implementar.

¿Debo agregar LVM en el sistema operativo invitado también?

No debería, ya que tener un sistema de archivos ext3 o ext 4 dentro del volumen lógico del host debería ser suficiente. No es necesario agregar otro grupo de volúmenes y volumen físico y volumen lógico dentro de eso.

No habría mucho éxito en el rendimiento solo de lvm, pero si estás dispuesto a tomarlo, usa zfs en su lugar. Obtiene administración de volumen y capacidad de recuperación y todo tipo de otras excelentes funciones.

Nadie menciona que lvm2 puede hacer que la velocidad de lectura y escritura se multiplique (similar a raid0). Yo personalmente uso 3 discos idénticos y sobre ellos lvm2 en modo despojado, las operaciones de lectura y escritura toman 1/3 del tiempo, eso es un gran impacto, el sistema de archivos es tres veces más rápido. Lo sé: cualquier disco falla y todos los datos en ellos no serán accesibles; pero eso no significa ninguna pérdida, ya que las copias de seguridad son IMPRESCINDIBLES, nada como Raid, LVM2, ZFS evitará tener copias de seguridad; así que nunca uso la duplicación, raid5 y demás, siempre uso stripping (para obtener el máximo rendimiento) y he sincronizado BackUPs. ZFS es ideal para la compresión sobre la marcha, y con copias de parámetros más grandes que uno es como duplicar, pero una cosa que ZFS tiene y que nadie más tiene es recuperar automáticamente la pudrición de bits sobre la marcha (bits que cambian espontáneamente mientras el disco está apagado),

Para reanudar: uso ZFS solo para mis copias de seguridad en discos externos, múltiples (dos o tres) ssd con lvm2 rayado para el sistema operativo (después de las actualizaciones rehago el clon del sistema operativo), tiendo a usar el sistema operativo inmutable; y utilizo múltiples (seis) discos spinnin con lvm2 despojado de datos, como máquinas virtuales, nuevamente después de cualquier cambio, rehago las copias de seguridad; así que después de que un disco falla, solo necesito reemplazarlo y restaurar la última copia de seguridad; Actualmente, tengo una velocidad de escritura cercana a 1.8GiB / s, por lo que restaurar una máquina virtual desde BackUP solo toma menos de 30 segundos (32GiB por disco de máquina virtual).

Entonces mi respuesta es: no use solo una cosa, sea inteligente y use lo mejor de cada parte, lvm2 stripped es más rápido que mdraid nivel 0, más cuando usa seis discos giratorios; una advertencia con ssd de stripping, dos y tres son buenos, cuatro ssd pueden degradar el rendimiento (mis pruebas dieron una velocidad de escritura más baja cuando usé cuatro ssd idénticos en modo stripped, sin importar si lvm, mdraid0, etc.), parece que SSD TRIM y tal La amplificación de escritura puede ser la causa principal de agregar más SSD al volumen eliminado, lo que reduce la velocidad de escritura.

Al advertir con ssd y cualquier raid0 (volúmenes despojados), alinee las cosas perfectamente, asigne tamaños de clúster en el sistema de archivos correctamente, tamaño de stip, etc. para que nadie cause degradación; como muestra: el sector del disco es 2048, por lo que 2K en cualquier lectura / escritura como mínimo, nunca use un sistema de archivos que use un clúster de 512 bytes, sobre eso, es mejor usar un tamaño de clúster de 2K o 4K; ahora imagine que usa 3xHDD, cada uno de los sectores de 2K, por lo que en cualquier clúster de sistema de archivos óptimo de lectura / escritura sería 3x2K = 6K, pero eso no es posible en muchos sistemas de archivos, luego piense qué pasaría si usara un tamaño de clúster de 64K, 64K / 6K = 32 / 3, que causa un desequilibrio, por lo que no es óptimo, etc. Haga cálculos matemáticos para obtener el tamaño óptimo del grupo.

Mis mejores resultados son: Tamaño del clúster = tamaño de banda * número de disco en la banda; de esa manera, cada lectura / escritura es del tamaño exacto que hace que todos los discos funcionen, por lo que la mejora de la velocidad es realmente excelente. Un ejemplo de tamaño de clúster de 192K para 3 discos con un tamaño de banda de 64K; otro ejemplo de 192K de tamaño de clúster para 6 discos con 32K de tamaño de banda.

Y siempre recuerde probar un solo disco en bloque 4K, 8K, 16K, 32K, 64K; muchos discos ofrecen velocidades realmente malas con números más bajos como 4K, pero ofrecen un tiempo más de diez veces más rápido cuando están en 64K, 128K o más.

Sí, el uso de grandes tamaños de clúster puede hacer que se pierda espacio en el clúster de cada archivo (si usa millones de archivos de solo 1 byte cada uno), mejor use un sistema compacto / paquete sobre la marcha sobre el sistema de archivos, Como muestra, un disco de 4TiB con un tamaño de clúster de 4K solo puede tener menos de 4TiB / 4K = 1073741824 archivos de 1Byte cada uno, eso es solo 1GiB si todos los archivos tienen un tamaño de 1Byte (tamaño de clúster 4K), mayor relación de tamaño de clúster peor, pero si los archivos son enormes, como las máquinas virtuales (cerca de 32 GiB como muestra, o solo unos pocos megabytes), la pérdida está solo en el último clúster; archivos tan grandes, el tamaño de clúster grande es mucho mejor para el rendimiento, pero tenga cuidado con la forma en que lo usa la máquina virtual.

Nadie le dirá este secreto: dentro del invitado no use el tamaño de clúster 4K, use el mismo tamaño de clúster que el tamaño del clúster donde reside el disco virtual, o un múltiplo de él.

Sí, soy un maníaco de obtener la máxima velocidad dentro de los discos invitados, como dije con 6 discos giratorios que me acerco a 1.7GiB / s, la velocidad del bus SATA III es el cuello de botella, no los discos en sí mismos. Utilizo discos de gama alta (no baratos), 128MiB de caché con una velocidad de escritura de 283MiB / s cada uno.

Para usted y para todas las personas: es mucho mejor aprender cómo el tamaño del clúster, el tamaño de la banda y el tamaño del bloque deben estar relacionados antes de realizar cualquier prueba de velocidad, de lo contrario, probar LVM2 o cualquier otro RAID (también ZFS) puede dar conclusiones FALSAS.

Solo una muestra de esto: pruebo mis tiempos de arranque de Linux con 2x60MiB / s discos Sata de 2.5 pulgadas y 5400 rpm en una placa base de puertos Sata II, y luego pruebo con 2xSSD Sata III (pueden escribir más de 250MiB / s cada uno si están conectados a Sata III puertos), los tiempos de arranque solo toman dos segundos menos, solo dos segundos en un arranque de cinco minutos, ¿por qué? Debido a que la mayoría de los discos de tiempo de arranque no se están utilizando, está haciendo cosas en RAM y CPU, pero no en E / S.

Siempre pruebe lo que hará en el día real, no solo las velocidades brutas (en otras palabras, la velocidad máxima).

Es bueno saber que la velocidad máxima es poco representable, es posible que no esté utilizando los discos a la velocidad máxima el 100% del tiempo, el sistema operativo y las aplicaciones deben hacer cosas en RAM y CPU sin E / S, por lo que en ese momento la velocidad del disco no importa en absoluto.

Todas las personas dicen que SSD mejora mucho la velocidad de arranque de Windows, en mis pruebas que también es FALSO, solo pruebo 28 segundos en un tiempo de arranque de casi ocho minutos.

Entonces, si me gusta: copia de Linux a ram en el arranque, SSD no será mejor que discos duros giratorios, también probé el dispositivo USB 3.1 Gen2 (139MiB / s de lectura), el tiempo de arranque solo se ve afectado unos segundos en un arranque de cinco minutos, ¿por qué? fácil, la lectura se realiza al copiar a la memoria RAM, más allá de que el disco / ssd / usb-stick no se vuelva a usar en el resto del tornillo, los datos están en la memoria RAM, como una unidad de memoria RAM.

Ahora estoy vendiendo todos mis SSD que tengo, no mejoran la copia en RAM de Linux en el arranque, pero los comparan diciendo que son 5 veces más rápidos ... mira, benchmark da conclusiones FALSAS ... yest, prueba y prueba real día de trabajo.

Espero que esto pueda aclarar las cosas masculinas ... LVM con clúster y tamaños de banda incorrectos afectan mucho más que la capa superior de la capa superior.