Pregunta LVM peligros y advertencias


Recientemente comencé a usar LVM en algunos servidores para discos duros de más de 1 TB. Son útiles, ampliables y bastante fáciles de instalar. Sin embargo, no pude encontrar ningún dato sobre los peligros y las advertencias de LVM.

¿Cuáles son las desventajas de usar LVM?


177
2018-06-12 07:34


origen


Al leer las respuestas a esta pregunta, tenga en cuenta la fecha (año) en que se publicaron. Muchas cosas pasan en 3 años en esta industria. - MattBianco
He realizado algunas actualizaciones recientemente (abril de 2015) después de haber escaneado para ver si algo ha cambiado. El kernel 2.6 ahora está obsoleto, los SSD son más comunes, pero aparte de algunas pequeñas correcciones de LVM, no ha cambiado mucho. Escribí algunas cosas nuevas sobre el uso de instantáneas de VM / cloud server en lugar de instantáneas de LVM. El estado del almacenamiento en caché de escritura, el cambio de tamaño del sistema de archivos y las instantáneas de LVM no han cambiado mucho, por lo que puedo ver. - RichVel
con respecto al comentario "tenga en cuenta la fecha": es bastante cierto, pero también considere que muchas "empresas" siguen utilizando RHEL 5 y RHEL 6, las cuales son modernas o más antiguas que la fecha de la respuesta - JDS


Respuestas:


Resumen

Riesgos de usar LVM:

  • Vulnerable para escribir problemas de almacenamiento en caché con SSD o hipervisor VM
  • Más difícil de recuperar datos debido a las estructuras más complejas en el disco
  • Más difícil cambiar el tamaño de los sistemas de archivos correctamente
  • Las instantáneas son difíciles de usar, lentas y con errores
  • Requiere alguna habilidad para configurar correctamente dados estos problemas

Los primeros dos problemas de LVM se combinan: si el almacenamiento en caché de escritura no funciona correctamente y tiene una pérdida de energía (por ejemplo, la PSU o UPS falla), es posible que tenga que recuperarse de la copia de seguridad, lo que significa un tiempo de inactividad significativo. Una razón clave para usar LVM es un mayor tiempo de actividad (al agregar discos, cambiar el tamaño de los sistemas de archivos, etc.), pero es importante que la configuración de almacenamiento en caché de escritura sea correcta para evitar que LVM reduzca realmente el tiempo de actividad.

- Actualizado en septiembre de 2017: hizo que el material del núcleo antiguo fuera menos prominente

Mitigar los riesgos.

LVM todavía puede funcionar bien si:

  • Obtenga su configuración de almacenamiento en caché de escritura en el hipervisor, el kernel y los SSD
  • Evitar las instantáneas de LVM
  • Usa versiones recientes de LVM para redimensionar sistemas de archivos.
  • Tener buenas copias de seguridad

Detalles

He investigado esto bastante en el pasado después de haber experimentado alguna pérdida de datos asociada con LVM. Los principales riesgos y problemas de LVM que conozco son:

Vulnerable al almacenamiento en caché de escritura en el disco duro debido a los hipervisores de máquinas virtuales, el almacenamiento en caché del disco o los núcleos de Linux antiguos, y hace que sea más difícil recuperar datos debido a estructuras más complejas en el disco; consulte a continuación para obtener detalles. He visto que las configuraciones completas de LVM en varios discos se corrompen sin posibilidad de recuperación, y el almacenamiento en caché de escritura en el disco duro de LVM plus es una combinación peligrosa.

  • Escribir caché y reordenar escritura por el disco duro Es importante para un buen rendimiento, pero puede fallar al vaciar bloques en el disco correctamente debido a los hipervisores de VM, el almacenamiento en caché de escritura del disco duro, los núcleos de Linux antiguos, etc.
    • Escribe barreras significa que el kernel garantiza que completará ciertas escrituras de disco antes de la escritura del disco de "barrera", para garantizar que los sistemas de archivos y RAID puedan recuperarse en caso de una pérdida repentina de energía o un fallo. Tales barreras pueden usar un Operación FUA (Force Unit Access) para escribir inmediatamente ciertos bloques en el disco, que es más eficiente que un vaciado completo de caché. Las barreras se pueden combinar con la eficiencia. etiquetado/nativo comando en cola (emitir múltiples solicitudes de E / S de disco a la vez) para permitir que el disco duro realice reordenes de escritura inteligente sin aumentar el riesgo de pérdida de datos.
  • Hipervisores VM puede tener problemas similares: ejecutar LVM en un huésped de Linux encima de un hipervisor VM, como VMware, Xen, KVM, Hyper-V o VirtualBox pueden crear problemas similaresa un kernel sin barreras de escritura, debido al almacenamiento en caché de escritura y al reordenamiento de escritura. Verifique cuidadosamente la documentación de su hipervisor para obtener una opción de "descarga al disco" o de caché de escritura directa (presente en KVM, VMware, Xen, VirtualBox y otros) - y prueba con tu configuración. Algunos hipervisores como VirtualBox tienen una configuración por defecto que ignora cualquier descarga de disco del invitado.
  • Los servidores empresariales con LVM siempre deben usar un controlador RAID con respaldo de batería y deshabilite el caché de escritura del disco duro (el controlador tiene caché de escritura respaldado por batería que es rápido y seguro) - vea este comentario por el autor de esta entrada de XFS FAQ. También puede ser seguro desactivar las barreras de escritura en el kernel, pero se recomienda la prueba.
  • Si no tiene un controlador RAID con respaldo de batería, deshabilitar el almacenamiento en caché de escritura del disco duro hará que las escrituras se ralenticen significativamente, pero hará que el LVM sea seguro. También deberías usar el equivalente de ext3. data=ordered opción (o data=journal para mayor seguridad), más barrier=1 para asegurar que el almacenamiento en caché del kernel no afecte la integridad. (O use ext4, que habilita barreras por defecto.) Esta es la opción más simple y proporciona una buena integridad de los datos al costo del rendimiento. (Linux cambió la opción predeterminada de ext3 a los mas peligrosos data=writeback hace un tiempo, así que no confíe en la configuración predeterminada para el servicio fijo.)
  • Para deshabilitar el almacenamiento en caché de disco duro: añadir hdparm -q -W0 /dev/sdX para todas las unidades en /etc/rc.local (para SATA) o use sdparm para SCSI / SAS. Sin embargo, de acuerdo con esta entrada en las Preguntas frecuentes de XFS (que es muy buena en este tema), una unidad SATA puede olvidar esta configuración después de una recuperación de error de la unidad, por lo que debe usar SCSI / SAS, o si debe usar SATA, coloque el comando hdparm en un trabajo cron corriendo cada minuto más o menos.
  • Para mantener el caché de escritura SSD / disco duro habilitado para un mejor rendimiento: esta es un área compleja - vea la sección a continuación.
  • Si estas usando Unidades de formato avanzado es decir, 4 KB de sectores físicos, consulte a continuación: desactivar el almacenamiento en caché de escritura puede tener otros problemas.
  • UPS es crítico tanto para la empresa como para SOHO, pero no lo suficiente como para hacer que el LVM sea seguro: cualquier cosa que cause una caída fuerte o una pérdida de energía (por ejemplo, falla de UPS, PSU o agotamiento de la batería de la computadora portátil) puede perder datos en cachés de disco duro.
  • Muy viejos núcleos de Linux (2.6.x de 2009): Hay soporte de barrera de escritura incompleta en versiones muy antiguas del kernel, 2.6.32 y anteriores (2.6.31 tiene algo de apoyo, mientras 2.6.33 obras para todos los tipos de dispositivos de destino) - RHEL 6 utiliza 2.6.32 Con muchos parches. Si estos viejos núcleos 2.6 no están parcheados para estos problemas, una gran cantidad de metadatos del FS (incluidos los diarios) podría perderse debido a una falla del disco duro que deja los datos en los buffers de escritura de los discos duros (por ejemplo, 32 MB por unidad para unidades SATA comunes). La pérdida de 32 MB de los metadatos y datos de diario más recientes del FS, que el núcleo cree que ya están en el disco, generalmente significa una gran cantidad de corrupción del FS y, por lo tanto, pérdida de datos.
  • Resumen: debe tener cuidado con el sistema de archivos, el RAID, el hipervisor de VM y la configuración del disco duro / SSD que se usa con LVM. Debe tener copias de seguridad muy buenas si está utilizando LVM, y asegúrese de realizar una copia de seguridad específica de los metadatos de LVM, la configuración de la partición física, el MBR y los sectores de arranque por volumen. También es aconsejable utilizar unidades de disco SCSI / SAS, ya que es menos probable que mientan acerca de cómo escriben el almacenamiento en caché: se requiere más cuidado para usar las unidades SATA.

Mantener el caché de escritura habilitado para el rendimiento (y hacer frente a las unidades mentirosas)

Una opción más compleja pero eficaz es mantener el caché de escritura en el disco duro / SSD y confiar en las barreras de escritura del kernel que funcionan con LVM en el kernel 2.6.33+ (revise dos veces buscando mensajes de "barrera" en los registros).

También debe asegurarse de que la configuración RAID, la configuración del hipervisor VM y el sistema de archivos usa barreras de escritura (es decir, requiere que la unidad vacíe las escrituras pendientes antes y después de los metadatos / escrituras de diario clave). XFS usa barreras por defecto, pero ext3 no, entonces con ext3 debes usar barrier=1 en las opciones de montaje, y todavía utilizar data=ordered o data=journal como anteriormente.

  • Desafortunadamente, algunos discos duros y SSDs mentir sobre si realmente han vaciado su caché en el disco (especialmente en unidades antiguas, pero que incluyen algunas unidades SATA y algunos SSDs empresariales) - más detalles aquí. Hay un gran resumen de un desarrollador de XFS.
  • Hay una herramienta de prueba simple para unidades de mentira (Perl script), o ver este fondo con otra herramienta pruebas de reordenamiento de escritura como resultado del caché de la unidad. Esta respuesta cubrió pruebas similares de las unidades SATA que descubrieron un problema de barrera de escritura en el software RAID: estas pruebas en realidad ejercen toda la pila de almacenamiento.
  • Unidades SATA más recientes que soportan Cola de comandos nativos (NCQ) puede ser menos probabilidades de mentir - o tal vez tienen un buen rendimiento sin almacenamiento en caché de escritura debido a NCQ, y muy pocas unidades no pueden deshabilitar el almacenamiento en caché de escritura.
  • Las unidades SCSI / SAS generalmente están bien, ya que no necesitan almacenamiento en caché de escritura para funcionar bien (a través de SCSI). Tagged Command Queueing, similar al NCQ de SATA).
  • Si sus unidades de disco duro o SSD mienten acerca de vaciar su caché en disco, realmente no puede confiar en las barreras de escritura y debe deshabilitar el almacenamiento en caché de escritura. Este es un problema para todos los sistemas de archivos, bases de datos, administradores de volúmenes y software RAID, no solo LVM.

SSDs son problemáticos porque el uso de la caché de escritura es crítico para la vida útil de la SSD. Es mejor usar un SSD que tenga un supercapacitador (para habilitar el vaciado de la memoria caché en caso de fallo de alimentación y, por lo tanto, permitir que la memoria caché sea de escritura y no de escritura).

Formato avanzado configuración de la unidad: escritura de caché, alineación, RAID, GPT

  • Con más nuevo Unidades de formato avanzado que utilizan 4 sectores físicos KiB, puede ser importante mantener el almacenamiento en caché de escritura de la unidad habilitado, ya que la mayoría de dichas unidades emulan actualmente sectores lógicos de 512 bytes ("512 emulación"), y algunos incluso afirman tener sectores físicos de 512 bytes mientras usan 4 KiB.
  • La desactivación de la memoria caché de escritura de una unidad de Formato avanzado puede causar un impacto muy grande en el rendimiento si la aplicación / el kernel está realizando escrituras de 512 bytes, ya que dichas unidades dependen de la memoria caché para acumular 8 escrituras de 512 bytes antes de realizar una sola revisión física de 4 KiB escribir. Se recomienda realizar pruebas para confirmar cualquier impacto si deshabilita el caché.
  • Alineando los LV en un límite de 4 KiB es importante para el rendimiento, pero debería ocurrir automáticamente siempre que las particiones subyacentes para los PV estén alineadas, ya que las LVM Physical Extents (PE) son 4 MiB de forma predeterminada. RAID debe ser considerado aquí - esto Página de configuración de LVM y software RAID sugiere poner el superbloque RAID al final del volumen y (si es necesario) usar una opción en pvcreate para alinear los PVs. Este hilo de lista de correo electrónico LVM señala el trabajo realizado en los núcleos durante 2011 y el problema de las escrituras de bloque parcial cuando se mezclan discos con 512 bytes y 4 sectores KiB en un solo LV.
  • Particionamiento GPT con Formato Avanzado necesita atención, especialmente para los discos de arranque + raíz, para garantizar que la primera partición LVM (PV) comience en un límite de 4 KiB.

Más difícil de recuperar datos debido a las estructuras más complejas en el disco:

  • Cualquier recuperación de datos de LVM requerida después de un fuerte golpe o pérdida de energía (debido al almacenamiento en caché de escritura incorrecto) es un proceso manual en el mejor de los casos, porque aparentemente no hay herramientas adecuadas. LVM es bueno para respaldar sus metadatos en /etc/lvm, que puede ayudar a restaurar la estructura básica de LV, VG y PV, pero no ayudará con la pérdida de metadatos del sistema de archivos.
  • Por lo tanto, es probable que se requiera una restauración completa desde la copia de seguridad. Esto implica mucho más tiempo de inactividad que un fsck basado en diario rápido cuando no se utiliza LVM, y se perderán los datos escritos desde la última copia de seguridad.
  • TestDisk, ext3grep, ext3undel y otras herramientas  pueden recuperar particiones y archivos de discos que no son LVM, pero no admiten directamente la recuperación de datos de LVM. TestDisk puede descubrir que una partición física perdida contiene un PV de LVM, pero ninguna de estas herramientas entiende los volúmenes lógicos de LVM. Tallado de archivos herramientas tales como PhotoRec y muchos otros funcionarían al pasar por alto el sistema de archivos para volver a ensamblar los archivos de bloques de datos, pero este es un enfoque de último nivel y bajo nivel para datos valiosos, y funciona menos bien con archivos fragmentados.
  • La recuperación manual de LVM es posible en algunos casos, pero es compleja y requiere mucho tiempo; consulte este ejemplo y esta, estay esta para saber cómo recuperarse.

Más difícil cambiar el tamaño de los sistemas de archivos correctamente - el fácil cambio de tamaño del sistema de archivos a menudo se otorga como un beneficio de LVM, pero necesita ejecutar media docena de comandos de shell para cambiar el tamaño de un FS basado en LVM. pero nunca me arriesgaría a este último sin las copias de seguridad actualizadas y el uso de comandos previamente probados en un servidor equivalente (por ejemplo, clon de recuperación de desastres del servidor de producción).

  • Actualizar: Versiones más recientes de lvextend apoyen el -r (--resizefs) opción: si está disponible, es una forma más segura y rápida de cambiar el tamaño del LV y del sistema de archivos, especialmente si está reduciendo el FS, y puede omitir esta sección.
  • La mayoría de las guías para cambiar el tamaño de los FS basados ​​en LVM no tienen en cuenta el hecho de que el FS debe ser algo más pequeño que el tamaño del LV: explicación detallada aquí. Al reducir un sistema de archivos, deberá especificar el nuevo tamaño de la herramienta de cambio de tamaño de FS, por ejemplo. resize2fs para ext3, y para lvextend o lvreduce. Sin gran cuidado, los tamaños pueden ser ligeramente diferentes debido a la diferencia entre 1 GB (10 ^ 9) y 1 Gibraltar (2 ^ 30), o la forma en que las diferentes herramientas redondean los tamaños hacia arriba o hacia abajo.
  • Si no hace los cálculos exactamente correctos (o usa algunos pasos adicionales más allá de los más obvios), puede terminar con un FS que sea demasiado grande para el LV. Todo parecerá estar bien durante meses o años, hasta que llene completamente el FS, momento en el que obtendrá una grave corrupción, y, a menos que sea consciente de este problema, es difícil averiguar por qué, ya que para entonces también tendrá errores de disco reales. Eso nubla la situación. (Es posible que este problema solo afecte a la reducción del tamaño de los sistemas de archivos; sin embargo, está claro que cambiar el tamaño de los sistemas de archivos en cualquier dirección aumenta el riesgo de pérdida de datos, posiblemente debido a un error del usuario).
  • Parece que el tamaño del LV debe ser más grande que el tamaño del servicio fijo por 2 veces el tamaño de la extensión física (PE) del LVM, pero consulte el enlace anterior para obtener detalles, ya que la fuente de esto no es autoritaria. A menudo, permitir 8 MiB es suficiente, pero puede ser mejor permitir más, por ejemplo. 100 MiB o 1 GiB, solo para estar seguros. Para verificar el tamaño de PE y su volumen lógico + tamaños de FS, usando 4 KiB = 4096 bloques de bytes:

    Muestra el tamaño de PE en KiB:
    vgdisplay --units k myVGname | grep "PE Size"

    Tamaño de todos los LVs:
    lvs --units 4096b

    Tamaño de (ext3) FS, asume 4 KiB FS tamaño de bloque:
    tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

  • Por el contrario, una configuración no LVM hace que redimensionar el FS sea muy confiable y fácil de ejecutar Gparted y redimensione los FS requeridos, entonces hará todo por usted. En los servidores, puede utilizar parted de la cáscara.

    • A menudo es mejor usar el Gparted Live CD o Magia Parted, ya que tienen un Gparted & kernel reciente ya menudo más libre de errores que la versión de la distribución: una vez perdí todo un FS debido a que Gparted de la distribución no actualiza las particiones correctamente en el kernel en ejecución. Si usa Gparted de la distro, asegúrese de reiniciar justo después de cambiar las particiones para que la vista del kernel sea correcta.

Las instantáneas son difíciles de usar, lentas y con errores- Si la instantánea se queda sin espacio asignado previamente, es cayó automáticamente. Cada instantánea de un LV dado es un delta contra ese LV (no contra las instantáneas anteriores) que puede requerir mucho espacio cuando se toman instantáneas de sistemas de archivos con una actividad de escritura significativa. Es seguro crear un LV de instantáneas del mismo tamaño que el LV original, ya que la instantánea nunca se quedará sin espacio libre.

Las instantáneas también pueden ser muy lentas (es decir, de 3 a 6 veces más lentas que sin LVM para estas pruebas de MySQL) - ver Esta respuesta cubre varios problemas de instantáneas.. La lentitud es en parte porque Las instantáneas requieren muchas escrituras síncronas.

Las instantáneas tienen algunos errores importantes, por ejemplo, en algunos casos pueden hacer que el arranque sea muy lento, o hacer que el arranque falle completamente (debido a que el núcleo puede agotarse  esperando el FS raíz cuando se trata de una instantánea de LVM [corregido en Debian initramfs-tools actualización, Mar 2015]).

  • Una métrica es que hay muchos errores de Debian. a juego "instantánea lvm 2015", algunos de ellos bastante graves, sin embargo, muchos errores de condición de carrera de instantáneas aparentemente sido arreglado. LVM sin instantáneas en general parece bastante bien depurado, tal vez porque las instantáneas no se usan tanto como las funciones principales.

Alternativas de instantáneas - Sistemas de archivos e hipervisores VM.

Instantáneas de VM / nube:

  • Si está utilizando un hipervisor VM o un proveedor de nube IaaS, sus instantáneas (por ejemplo, las instantáneas EBS de VMware, VirtualBox o Amazon EC2) a menudo son una alternativa mucho mejor que las instantáneas LVM. Puede tomar una instantánea con fines de copia de seguridad (pero considere congelar el FS antes de hacerlo).

Instantáneas del sistema de archivos:

  • las instantáneas a nivel de sistema de archivos con ZFS o btrfs son fáciles de usar y, en general, mejores que LVM, y aunque ninguno de los dos sistemas de archivos es muy maduro en Linux, podrían ser una mejor opción para las personas que realmente necesitan instantáneas sin pasar por la ruta de VM / cloud:

Instantáneas para copias de seguridad en línea y fsck

Las instantáneas se pueden utilizar para proporcionar una coherencia fuente para copias de seguridad, siempre y cuando tenga cuidado con el espacio asignado (lo ideal es que la instantánea sea del mismo tamaño que la copia de seguridad del LV). La excelente rsnapshot (desde la versión 1.3.1) incluso administra la creación / eliminación de instantáneas de LVM por usted, vea esto HOWTO en rsnapshot usando LVM. Sin embargo, tenga en cuenta los problemas generales con las instantáneas y que una instantánea no debe considerarse una copia de seguridad en sí misma.

También puede usar instantáneas de LVM para hacer un fsck en línea: instantánea del LV y fsck de la instantánea, mientras usa el FS principal no instantáneo - descrito aquí - Sin embargo, es no del todo sencillo así que es mejor usar e2croncheck como descrito por Ted Ts'o, mantenedor de ext3.

Debieras "congelar" el sistema de archivos temporalmente mientras se toma la instantánea, algunos sistemas de archivos como ext3 y XFS haz esto automáticamente cuando LVM crea la instantánea.

Conclusiones

A pesar de todo esto, sigo utilizando LVM en algunos sistemas, pero para una configuración de escritorio prefiero particiones en bruto. El principal beneficio que puedo ver de LVM es la flexibilidad de mover y cambiar el tamaño de los FS Cuando debe tener un alto tiempo de actividad en un servidor - Si no lo necesita, gparted es más fácil y tiene menos riesgo de pérdida de datos.

LVM requiere mucho cuidado en la configuración del almacenamiento en caché de escritura debido a los hipervisores de VM, el almacenamiento en caché del disco duro / escritura de SSD, etc., pero lo mismo se aplica al uso de Linux como un servidor de base de datos. La falta de apoyo de la mayoría de las herramientas (gparted incluyendo los cálculos de tamaño crítico, y testdisk etc) hace que sea más difícil de usar de lo que debería ser.

Si usa LVM, tenga mucho cuidado con las instantáneas: use VM / cloud snapshots si es posible, o investigue ZFS / btrfs para evitar LVM por completo. Es posible que ZFS o btrs estén lo suficientemente maduros en comparación con LVM con instantáneas.

En pocas palabras: si no conoce los problemas mencionados anteriormente y cómo abordarlos, es mejor no utilizar LVM.


238
2018-06-12 08:19



El cambio de tamaño en línea con xfs funciona perfectamente, ni siquiera tiene que especificar el tamaño. Crecerá hasta el tamaño del LV. Lea más en xfs_grow (5). OTOH pulsé +1 para el resumen sobre barreras de escritura. - cstamas
¡TIPO! ¿¡Donde has estado toda mi vida!? - songei2f
@TREE: la idea con un controlador RAID respaldado por batería es que su caché sea persistente a través de fallas de energía y generalmente se puede confiar en que funcione como se documenta, mientras que algunos cachés en el disco duro mienten acerca de si realmente han escrito un bloque en el disco, y Por supuesto, estos cachés no son persistentes. Si deja el caché en el disco duro habilitado, es vulnerable a una falla repentina de alimentación (por ejemplo, falla de la PSU o UPS), que está protegido por la batería de respaldo del controlador RAID. - RichVel
Una de las mejores respuestas que he visto, cualquier tema. Solo el cambio que haría, mueva el resumen al TOP de la pregunta para aquellos con trastorno por déficit de atención o no mucho tiempo. :-) - Prof. Falken
Al ver todos los comentarios y la última actualización de la respuesta hace un año, me preguntaba si la respuesta podría actualizarse para reflejar cualquier cambio nuevo en la confiabilidad, el rendimiento y la facilidad de uso. - Luis Alvarado


Yo [+1] ese post, y al menos para mí creo que la mayoría de los problemas existen. Los vi mientras ejecutaban unos pocos 100 servidores y unos pocos 100 TB de datos. Para mí, el LVM2 en Linux se siente como una "idea inteligente" que alguien tenía. Como algunos de estos, a veces resultan ser "no inteligentes". Es decir. no tener estados del kernel y del espacio de usuario (lvmtab) estrictamente separados podría haberse sentido realmente inteligente de eliminarlos, ya que puede haber problemas de corrupción (si no entiende el código correctamente)

Bueno, solo que esta separación estaba allí. por una razón - las diferencias se muestran con el manejo de la pérdida de PV, y la reactivación en línea de un VG con PV faltantes para ponerlas en juego nuevamente El manejo del estado no es lo suficientemente bueno. Y ni siquiera me haga hablar sobre la detección de pérdida de quórum (jaja) o el manejo del estado (si quito un disco, no se marcará como no disponible. Ni siquiera tener la maldita columna de estado)

Re: estabilidad pvmove... por que es

pérdida de datos pvmove

Un artículo tan alto en mi blog, ¿hmm? Ahora mismo miro un disco donde los datos de phyiscal lvm todavía están colgados en el estado desde mediados de pvmove. Creo que ha habido algunos memleaks, y la idea general de que es bueno copiar alrededor de datos de bloques en vivo desde el espacio de usuario es simplemente triste. Buena cita de la lista de lvm "parece que vgreduce --missing no maneja pvmove" De hecho, significa que si un disco se separa durante pvmove, entonces la herramienta de administración lvm cambia de lvm a vi. Ah, y también ha habido un error por el cual pvmove continúa después de un error de lectura / escritura de bloque y, de hecho, ya no escribe datos en el dispositivo de destino. WTF?

Re: instantáneas El CoW se realiza de forma insegura, al actualizar los datos NUEVOS en el área de instantáneas lv y luego fusionarlos de nuevo una vez que elimine el snap. Esto significa que tiene fuertes picos de IO durante la fusión final de los nuevos datos con el LV original y, lo que es más importante, también tiene un riesgo mucho mayor de corrupción de datos, ya que no se romperá la instantánea una vez que llegue al Muro, pero el original.

La ventaja está en el rendimiento, hacer 1 escritura en lugar de 3. Elegir el algoritmo rápido pero no seguro es algo que obviamente se espera de personas como VMware y MS, en "Unix" Prefiero que las cosas se "hagan bien". No he visto muchos problemas de rendimiento siempre que tenga la tienda de respaldo de instantáneas en una diferente unidad de disco que los datos primarios (y copia de seguridad a otro, por supuesto)

Re: Barreras No estoy seguro de si uno puede culpar a LVM. Era un problema de devmapper, que yo sepa. Pero puede haber algo de culpa por no preocuparse realmente por este problema, desde al menos el kernel 2.6 hasta el 2.6.33 AFAIK Xen es el único hipervisor que usa O_DIRECT para las máquinas virtuales, el problema solía ser cuando se usaba "loop" porque el kernel aún se almacenaría en caché al usarlo. Al menos, Virtualbox tiene alguna configuración para deshabilitar cosas como esta y Qemu / KVM generalmente parece permitir el almacenamiento en caché. Todos los FUSE FS también tienen problemas allí (no O_DIRECT)

Re: Tamaños Creo que LVM hace "redondeo" del tamaño mostrado. O utiliza GiB. De todos modos, necesita usar el tamaño VG Pe y multiplicarlo por el número LE del LV. Eso debería dar el tamaño de red correcto, y ese problema siempre es un problema de uso. Se agrava por los sistemas de archivos que no notan algo así durante fsck / mount (hola, ext3) o no tienen un "fsck -n" en línea que funcione (hola, ext3)

Por supuesto, es evidente que no puede encontrar buenas fuentes para dicha información. "¿cuántos LE para el VRA?" "¿Cuál es el offset de phyiscal para PVRA, VGDA, ... etc"

Comparado con el original, LVM2 es el principal ejemplo de "Los que no entienden UNIX están condenados a reinventarlo, mal".

Actualización unos meses más tarde: he estado llegando al escenario de "instantánea completa" para una prueba por ahora. Si se llenan, la instantánea se bloquea, no el LV original. Me equivoqué allí cuando publiqué esto por primera vez. Recogí información incorrecta de algún documento, o tal vez la entendí. En mis configuraciones siempre había sido muy paranoico al no dejar que se llenaran, por lo que nunca terminé corregido. También es posible ampliar / reducir las instantáneas, lo cual es un placer.

Lo que aún no he podido resolver es cómo identificar la edad de una instantánea. En cuanto a su rendimiento, hay una nota en la página del proyecto fedora "thinp" que dice que la técnica de instantáneas se está revisando para que no se vuelvan más lentas con cada instantánea. No sé cómo lo están implementando.


15
2017-12-11 14:03



Buenos puntos, particularmente en la pérdida de datos pvmove (no me di cuenta de que esto podría fallar en poca memoria) y el diseño de instantáneas. Sobre las barreras de escritura / almacenamiento en caché: estaba confundiendo LVM y el mapeador de dispositivos del kernel desde el punto de vista del usuario, trabajan juntos para entregar lo que proporciona LVM. Upvoted. También me gustó la publicación de tu blog sobre la pérdida de datos pvmove: deranfangvomende.wordpress.com/2009/12/28/… - RichVel
En las instantáneas: son notoriamente lentas en LVM, así que claramente no fue una buena decisión de diseño apostar por el rendimiento sobre la confiabilidad. Por "golpear la pared", ¿quiso decir que la instantánea se está llenando, y puede realmente causar la corrupción de los datos originales de LV? El LVM HOWTO dice que la instantánea se descarta en este caso: tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html - RichVel
"La CoW se realiza de forma insegura, al actualizar los datos NUEVOS en el área de instantáneas lv y luego fusionarlos de nuevo una vez que elimines la instantánea". Esto es simplemente falso. Cuando se escriben nuevos datos en el dispositivo original, antiguo La versión está escrita en el área de instantáneas COW. Nunca se fusionan datos (excepto si lo desea). Ver kernel.org/doc/Documentation/device-mapper/snapshot.txt Para todos los detalles técnicos sangrientos. - Damien Tournoud
Hola Damien, la próxima vez, simplemente sigue leyendo hasta el punto en el que corregí mi publicación. - Florian Heigl


si planea usar instantáneas para copias de seguridad, prepárese para un mayor impacto de rendimiento cuando la instantánea esté presente. Lee mas aquí. de lo contrario todo está bien. He estado usando lvm en producción durante un par de años en docenas de servidores, aunque mi principal razón para usarlo es la instantánea atómica, no la capacidad de expandir volúmenes fácilmente.

Por cierto, si va a utilizar una unidad de 1TB, recuerde la alineación de la partición: esta unidad probablemente tiene sectores físicos de 4kB.


12
2018-06-12 09:44



+1 para advertencia de rendimiento para instantáneas abiertas. - Prof. Falken
Mi experiencia es que las unidades de 1TB generalmente usan sectores de 512 bytes, pero la mayoría de las unidades de 2TB usan 4Kb. - Dan Pritts
@DanPritts no tiene nada de malo suponer que el tamaño del sector es de 4kB o incluso de 128kB, en caso de que haya una redada intermedia. Pierdes tan poco, tal vez 128kB y puedes ganar mucho. también cuando se crea una imagen desde el disco antiguo a uno nuevo. - pQd
Hay un pequeño daño al hacer que el tamaño del bloque del sistema de archivos sea "demasiado grande"; Cada archivo está contenido en no menos de un solo bloque. Si tienes muchos archivos pequeños y bloques de 128KB, se sumarán. Sin embargo, estoy de acuerdo en que 4K es bastante razonable, y si mueve un sistema de archivos a un nuevo hardware, eventualmente terminará con 4k sectores. - Dan Pritts
(no me deja editar mi comentario anterior) ... Una pérdida de espacio puede no importar, pero terminará incrementando el tiempo promedio de búsqueda en discos giratorios. Posiblemente se convierta en amplificación de escritura (rellenando el sector con nulos) en los SSD. - Dan Pritts


Adán,

Otra ventaja: puede agregar un nuevo volumen físico (PV), mover todos los datos a ese PV y luego eliminar el PV anterior sin interrupciones en el servicio. He usado esa capacidad al menos cuatro veces en los últimos cinco años.

Una desventaja que no vi claramente señalada todavía: hay una curva de aprendizaje algo pronunciada para LVM2. Principalmente en la abstracción que crea entre sus archivos y los medios subyacentes. Si trabaja con unas pocas personas que comparten tareas en un conjunto de servidores, es posible que la complejidad adicional resulte abrumadora para todo su equipo. Los equipos más grandes dedicados al trabajo de TI generalmente no tendrán tal problema.

Por ejemplo, lo usamos ampliamente aquí en mi trabajo y nos hemos tomado el tiempo de enseñarle a todo el equipo los conceptos básicos, el lenguaje y lo esencial sobre la recuperación de sistemas que no arrancan correctamente.

Una advertencia específicamente para señalar: si arranca desde un volumen lógico LVM2, dificultó las operaciones de recuperación cuando el servidor se bloquea. Knoppix y sus amigos no siempre tienen las cosas correctas para eso. Entonces, decidimos que nuestro directorio / boot estaría en su propia partición y siempre sería pequeño y nativo.

En general, soy un fan de LVM2.


5
2018-06-22 21:03



acuerdo /boot separado siempre es una buena idea - Hubert Kario
GRUB2 no admite el arranque desde un volumen lógico LVM (ver wiki.archlinux.org/index.php/GRUB2#LVM) pero GRUB1 no lo hace. Siempre usaría un arranque / LVM separado solo para asegurar que sea fácil de recuperar. La mayoría de los discos de rescate en estos días son compatibles con LVM, algunos requieren un manual vgchange -aypara encontrar los volúmenes LVM. - RichVel
en pvmove: vea el punto acerca de pvmove la pérdida de datos hecha en la respuesta de Florian Heigl. - RichVel