Administrador de volumen lógico (Linux) - Logical Volume Manager (Linux)

Administrador de volumen lógico

Autor (es) original (es)	Heinz Mauelshagen
Lanzamiento estable	2.03.12  / 7 de mayo de 2021 ; Hace 2 meses ( 7 de mayo de 2021 )
Repositorio	sourceware .org / git /? p = lvm2 .git
Escrito en	C
Sistema operativo	Linux , Netbsd
Licencia	GPLv2
Sitio web	sourceware .org / lvm2 /

En Linux , Logical Volume Manager ( LVM ) es un marco de asignación de dispositivos que proporciona administración de volumen lógico para el kernel de Linux . La mayoría de las distribuciones de Linux modernas son compatibles con LVM hasta el punto de poder tener sus sistemas de archivos raíz en un volumen lógico .

Heinz Mauelshagen escribió el código LVM original en 1998, cuando trabajaba en Sistina Software , tomando sus pautas de diseño principales del administrador de volumen de HP-UX .

Usos

LVM se utiliza para los siguientes propósitos:

• Creación de volúmenes lógicos únicos de varios volúmenes físicos o discos duros completos (algo similar a RAID 0 , pero más similar a JBOD ), lo que permite el cambio de tamaño dinámico del volumen.
• Administrar grandes granjas de discos duros al permitir que los discos se agreguen y reemplacen sin tiempo de inactividad o interrupción del servicio, en combinación con el intercambio en caliente .
• En sistemas pequeños (como un escritorio), en lugar de tener que estimar en el momento de la instalación el tamaño que podría necesitar una partición, LVM permite cambiar el tamaño de los sistemas de archivos fácilmente según sea necesario.
• Realización de copias de seguridad consistentes tomando instantáneas de los volúmenes lógicos.
• Cifrar múltiples particiones físicas con una contraseña.

LVM se puede considerar como una fina capa de software sobre los discos duros y las particiones, lo que crea una abstracción de continuidad y facilidad de uso para administrar el reemplazo del disco duro, el reparticionamiento y la copia de seguridad.

Características

Varios elementos del LVM

Funcionalidad básica

• Los grupos de volumen (VG) se pueden cambiar de tamaño en línea absorbiendo nuevos volúmenes físicos (PV) o expulsando los existentes.
• Los volúmenes lógicos (LV) se pueden cambiar de tamaño en línea concatenando extensiones en ellos o truncando extensiones a partir de ellos.
• Los LV se pueden mover entre PV.
• Creación de instantáneas de solo lectura de volúmenes lógicos (LVM1), aprovechando una función de copia en escritura (CoW) o instantáneas de lectura / escritura (LVM2)
• Los VG se pueden dividir o fusionar in situ siempre que ningún LV abarque la división. Esto puede ser útil al migrar LV completos hacia o desde el almacenamiento fuera de línea.
• Los objetos LVM se pueden etiquetar por conveniencia administrativa.
• Los VG y LV pueden activarse a medida que los dispositivos subyacentes estén disponibles mediante el uso del lvmetaddemonio.

Funcionalidad avanzada

• Se pueden crear volúmenes híbridos utilizando el destino dm-cache , que permite que uno o más dispositivos de almacenamiento rápido, como SSD basados ​​en flash , actúen como caché para una o más unidades de disco duro más lentas .
• Los LV con aprovisionamiento fino se pueden asignar desde un grupo.
• En las versiones más recientes del mapeador de dispositivos , LVM está integrado con el resto del mapeador de dispositivos lo suficiente como para ignorar las rutas individuales que respaldan un dispositivo dm-multipath si devices/multipath_component_detection=1está configurado lvm.conf. Esto evita que LVM active volúmenes en una ruta individual en lugar de en el dispositivo de múltiples rutas.

REDADA

• Se pueden crear LV para incluir la funcionalidad RAID , incluidos RAID 1 , 5 y 6 .
• LV completos o sus partes se pueden dividir en múltiples PV, de manera similar a RAID 0 .
• Un dispositivo de back-end RAID 1 (un PV) se puede configurar como "escritura mayoritariamente", lo que evita las lecturas en dichos dispositivos a menos que sea necesario.
• La tasa de recuperación se puede limitar usando lvchange --raidmaxrecoveryratey lvchange --raidminrecoveryratepara mantener un rendimiento de E / S aceptable mientras se reconstruye un LV que incluye la funcionalidad RAID.

Alta disponibilidad

El LVM también funciona en un clúster de almacenamiento compartido en el que los discos que contienen los PV se comparten entre varias computadoras host, pero pueden requerir un demonio adicional para mediar el acceso a los metadatos a través de una forma de bloqueo.

CLVM

Se utiliza un administrador de bloqueo distribuido para gestionar accesos de metadatos LVM simultáneos. Siempre que un nodo de clúster necesite modificar los metadatos de LVM, debe obtener el permiso de su local clvmd, que está en contacto constante con otros clvmddemonios en el clúster y puede comunicar el deseo de obtener un bloqueo en un conjunto particular de objetos.

HA-LVM

El conocimiento del clúster se deja a la aplicación que proporciona la función de alta disponibilidad. Por parte de LVM, HA-LVM puede usar CLVM como mecanismo de bloqueo, o puede continuar usando el bloqueo de archivos predeterminado y reducir las "colisiones" restringiendo el acceso solo a aquellos objetos LVM que tienen las etiquetas apropiadas. Dado que esta solución más simple evita la contención en lugar de mitigarla, no se permiten accesos concurrentes, por lo que HA-LVM se considera útil solo en configuraciones activo-pasivo.

lvmlockd

A partir de 2017, un componente LVM estable que está diseñado para reemplazar clvmdal hacer que el bloqueo de objetos LVM sea transparente para el resto de LVM, sin depender de un administrador de bloqueo distribuido. Tuvo un desarrollo masivo durante 2016.

Los mecanismos descritos anteriormente solo resuelven los problemas con el acceso de LVM al almacenamiento. El sistema de archivos seleccionado para estar en la parte superior de dichos LV debe admitir la agrupación en clústeres por sí mismo (como GFS2 o VxFS ) o solo debe ser montado por un solo nodo de clúster en cualquier momento (como en una configuración activa-pasiva).

Política de asignación de grupos de volumen

Los LVM VG deben contener una política de asignación predeterminada para los nuevos volúmenes creados a partir de ellos. Esto se puede cambiar más tarde para cada LV usando el lvconvert -Acomando, o en el mismo VG a través de vgchange --alloc. Para minimizar la fragmentación, LVM intentará la política más estricta (contigua) primero y luego avanzará hacia la política más liberal definida para el objeto LVM hasta que la asignación finalmente tenga éxito.

En las configuraciones RAID, casi todas las políticas se aplican a cada tramo de forma aislada. Por ejemplo, incluso si un LV tiene una política de adherencia , expandir el sistema de archivos no dará como resultado que LVM use un PV si ya lo usa una de las otras ramas en la configuración de RAID. Los LV con funcionalidad RAID colocarán cada tramo en diferentes PV, lo que hará que los otros PV no estén disponibles para ningún otro tramo determinado. Si esta fuera la única opción disponible, la expansión del LV fallaría. En este sentido, la lógica detrás de la adherencia solo se aplicará a la expansión de cada una de las ramas individuales de la matriz.

Las políticas de asignación disponibles son:

• Contiguo : obliga a todos los LE en un LV dado a ser adyacentes y ordenados. Esto elimina la fragmentación pero reduce gravemente la capacidad de expansión del VI.
• Cling : obliga a que los nuevos LE se asignen solo a los PV ya utilizados por un LV. Esto puede ayudar a mitigar la fragmentación, así como a reducir la vulnerabilidad de LV particulares en caso de que un dispositivo falle, al reducir la probabilidad de que otros LV también tengan extensiones en ese PV.
• Normal : implica una selección casi indiscriminada de PE, pero intentará evitar que los tramos paralelos (como los de una configuración RAID) compartan un dispositivo físico.
• En cualquier lugar : no impone restricciones de ningún tipo. Es muy arriesgado en una configuración RAID, ya que ignora los requisitos de aislamiento, lo que socava la mayoría de los beneficios de RAID. Para volúmenes lineales, puede resultar en una mayor fragmentación.

Implementación

Ejemplo básico de un cabezal LVM

Funcionamiento interno de la versión 1 de LVM. En este diagrama, PE significa Extensión física.

Normalmente, el primer megabyte de cada volumen físico contiene una estructura codificada principalmente en ASCII denominada "encabezado LVM" o "encabezado LVM". Originalmente, el cabezal LVM solía estar escrito en el primer y último megabyte de cada PV para redundancia (en caso de una falla parcial del hardware); sin embargo, esto se cambió más tarde a solo el primer megabyte. El encabezado de cada PV es una copia completa del diseño del grupo de volumen completo, incluidos los UUID de todos los demás PV y LV, y el mapa de asignación de PE a LE . Esto simplifica la recuperación de datos si se pierde un PV.

En la serie 2.6 del kernel de Linux, el LVM se implementa en términos del mapeador de dispositivos , un esquema simple a nivel de bloque para crear dispositivos de bloques virtuales y mapear su contenido en otros dispositivos de bloque. Esto minimiza la cantidad de código del kernel relativamente difícil de depurar que se necesita para implementar LVM. También permite que sus servicios de redirección de E / S se compartan con otros administradores de volumen (como EVMS ). Cualquier código específico de LVM se envía a sus herramientas de espacio de usuario, que simplemente manipulan estas asignaciones y reconstruyen su estado a partir de los metadatos del disco en cada invocación.

Para poner un grupo de volumen en línea, la herramienta "vgchange":

1. Busca PV en todos los dispositivos de bloque disponibles.
2. Analiza el encabezado de metadatos en cada PV encontrado.
3. Calcula los diseños de todos los grupos de volúmenes visibles.
4. Recorre cada volumen lógico en el grupo de volúmenes para ponerlo en línea y:
   1. Comprueba si el volumen lógico que se pondrá en línea tiene todos sus PV visibles.
   2. Crea una nueva asignación de dispositivo vacía.
   3. Lo asigna (con el objetivo "lineal") a las áreas de datos de los PV a los que pertenece el volumen lógico.

Para mover un volumen lógico en línea entre PV en el mismo grupo de volúmenes, use la herramienta "pvmove":

1. Crea una nueva asignación de dispositivo vacía para el destino.
2. Aplica el objetivo "espejo" a los mapas original y de destino. El kernel iniciará el espejo en modo "degradado" y comenzará a copiar datos del original al destino para sincronizarlo.
3. Reemplaza la asignación original con el destino cuando el espejo se sincroniza y luego destruye el original.

Estas operaciones del mapeador de dispositivos se realizan de forma transparente, sin que las aplicaciones o los sistemas de archivos se den cuenta de que su almacenamiento subyacente se está moviendo.

Advertencias

• Hasta el kernel de Linux 2.6.31, las barreras de escritura no eran compatibles (totalmente compatible en 2.6.33). Esto significa que la garantía contra la corrupción del sistema de archivos que ofrecen los sistemas de archivos registrados como ext3 y XFS fue negada en algunas circunstancias.
• A partir de 2015, no existe ningún programa de desfragmentación en línea o fuera de línea para LVM. Esto se ve mitigado de alguna manera por la fragmentación que solo ocurre si se expande un volumen y aplicando las políticas de asignación mencionadas anteriormente. Sin embargo, todavía se produce fragmentación y, si se va a reducir, las extensiones no contiguas deben identificarse y reorganizarse manualmente mediante el pvmovecomando.
• En la mayoría de las configuraciones de LVM, solo se guarda una copia del cabezal LVM en cada PV, lo que puede hacer que los volúmenes sean más susceptibles a sectores de disco fallidos. Este comportamiento se puede anular mediante vgconvert --pvmetadatacopies. Si el LVM no puede leer un encabezado adecuado usando la primera copia, verificará el final del volumen en busca de un encabezado de respaldo. La mayoría de las distribuciones de Linux mantienen una copia de seguridad en ejecución /etc/lvm/backup, lo que permite la reescritura manual de un cabezal LVM dañado mediante el vgcfgrestorecomando.

Ver también

Referencias

Otras lecturas