Solucione de forma segura el problema de falta de espacio en el aprovisionamiento ligero LVM de SUSE Linux Enterprise.

¿Qué debes determinar antes de cambiar nada?

Primero, determine si el pool delgado ha agotado el espacio de datos , el espacio de metadatos o ambos. Esta distinción modifica el plan de recuperación. Un pool delgado contiene un volumen lógico de datos que almacena los bloques asignados y un volumen lógico de metadatos que realiza un seguimiento de dichas asignaciones. El tamaño virtual de los volúmenes lógicos delgados puede exceder la capacidad física del pool, lo cual es la finalidad del aprovisionamiento delgado, pero también la razón por la que se debe supervisar la sobreasignación.

La documentación de SUSE Linux Enterprise Server 15 SP7 confirma que los volúmenes delgados asignan espacio de un pool delgado bajo demanda y que el tamaño virtual combinado puede sobrepasar el almacenamiento físico disponible. La documentación de LVM thin-pool agrega una regla operativa importante: extender el pool antes de que Data%alcance Meta%el 100%. Consulte la Guía de administración de almacenamiento de SUSE Linux Enterprise Server 15 SP7 y el manual de aprovisionamiento delgado de LVM .

1. ¿Está lleno el espacio de datos o los metadatos?

Ejecute lvscon columnas explícitas en lugar de confiar en una comprobación genérica del espacio en disco. Un sistema de archivos aún puede informar de espacio virtual libre aunque el pool físico subyacente esté casi agotado.

lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent

Leyenda: El thin pool debe identificarse mediante sus valores Data% y Meta%; el espacio libre del sistema de archivos por sí solo no muestra el agotamiento físico del thin pool.

Si Data%el valor es igual o cercano a 100, el pool se ha quedado sin bloques para nuevas escrituras. La documentación oficial de LVM advierte que las escrituras pueden generar errores cuando el pool de datos está agotado, lo que a su vez puede dañar los sistemas de archivos. Si Meta%alcanza 100, la respuesta es más conservadora, ya que el agotamiento de los metadatos puede provocar inconsistencias tanto en los metadatos del pool delgado como en los sistemas de archivos.

2. ¿El grupo de volúmenes aún tiene extensiones físicas libres?

Este es el siguiente punto de decisión. Un pool delgado solo puede crecer si su grupo de volúmenes tiene extensiones libres, a menos que primero agregue más almacenamiento físico a ese grupo de volúmenes.

vgs -o vg_name,vg_size,vg_free
vgdisplay VG_NAME

Leyenda: Comprobar el espacio libre de VG permite diferenciar una extensión de pool delgada simple de un caso que requiere agregar almacenamiento primero.

Si el VG tiene suficiente espacio libre, normalmente puede extender el pool thin directamente. Si VFreees cero o demasiado pequeño, no siga intentándolo lvextend; decida si puede eliminar volúmenes thin o instantáneas innecesarias, recuperar bloques con descarte o agregar un nuevo volumen físico.

3. ¿Debería detener las aplicaciones antes de la recuperación?

Si el pool ya está al 100%, detenga o ponga en reposo las aplicaciones que realizan muchas operaciones de escritura antes de realizar cambios en el almacenamiento. Esto reduce la probabilidad de que las bases de datos, las máquinas virtuales, los contenedores u otros servicios sigan realizando escrituras mientras la capa de almacenamiento está fallando o en reparación.

systemctl stop YOUR_APPLICATION.service
systemctl status YOUR_APPLICATION.service

Leyenda: La suspensión de aplicaciones limita las escrituras adicionales mientras se recupera un pool delgado lleno o dañado.

No existe una lista universal de servicios que se deban detener. Utilice la arquitectura de su carga de trabajo y sus procedimientos de mantenimiento. Para bases de datos y máquinas virtuales, prefiera el método de apagado o suspensión que ofrece el producto en lugar de finalizar los procesos abruptamente.

4. Si Data% está lleno y el VG tiene espacio libre, ¿cómo se amplía el pool?

Extienda el pool delgado en sí, no el LV delgado virtual, porque el problema es la falta de capacidad física del pool. Por ejemplo:

lvextend -L +20G VG_NAME/THIN_POOL
lvs -o lv_name,vg_name,lv_size,data_percent,metadata_percent VG_NAME/THIN_POOL

Leyenda: Ampliar el pool delgado aumenta la capacidad física; el porcentaje de datos resultante debería disminuir una vez que el nuevo espacio esté disponible.

El manual de lvextend documenta la extensión directa del thin pool y la --poolmetadatasizeopción independiente para metadatos. Elija un incremento basado en la tasa de crecimiento real y la capacidad de almacenamiento que puede reservar. Un ejemplo fijo como este +20Gno constituye una recomendación de dimensionamiento para todos los sistemas.

5. ¿Qué ocurre si el grupo de volúmenes no tiene espacio libre?

Agregue almacenamiento solo después de confirmar que el dispositivo de bloques de destino no está en uso y no contiene datos que necesite. Al crear un volumen físico LVM, se escriben los metadatos de LVM en el dispositivo seleccionado, por lo que un error en el nombre del dispositivo puede tener consecuencias desastrosas.

lsblk
blkid

pvcreate /dev/NEW_DEVICE
vgextend VG_NAME /dev/NEW_DEVICE
vgs -o vg_name,vg_size,vg_free

Leyenda: Cuando el VG está lleno, se puede agregar primero nuevo almacenamiento físico, después de que el administrador verifique que el dispositivo no utilizado sea el correcto.

La documentación de SUSE indica que los grupos de volúmenes se pueden expandir agregando particiones o discos completos. Revise la topología de almacenamiento antes de realizar esta operación en sistemas multipath, SAN, RAID, cifrados, en clúster o basados ​​en la nube, ya que la capa de dispositivo correcta podría no ser el disco sin formato que se muestra en un ejemplo sencillo.

6. ¿Qué pasaría si Meta% alcanzara el 100%?

Trate el agotamiento de metadatos como un caso de reparación sin conexión en lugar de simplemente agregar capacidad de datos. El manual de LVM thin-pool indica explícitamente que el agotamiento de metadatos puede causar inconsistencias en los metadatos y sistemas de archivos del thin-pool. Su secuencia de recuperación documentada consiste en desactivar el pool, repararlo lvconvert --repair, extender los metadatos y luego verificar el sistema de archivos.

Después de detener las aplicaciones, desmonte los sistemas de archivos o desactive de otro modo los volúmenes lógicos ligeros (LV) utilizando el grupo. A continuación, siga un procedimiento de mantenimiento controlado similar al siguiente:

lvchange -an VG_NAME/THIN_LV
lvconvert --repair VG_NAME/THIN_POOL
lvextend --poolmetadatasize +1G VG_NAME/THIN_POOL

Leyenda: Una condición de metadatos llenos requiere una reparación del pool delgado sin conexión y espacio adicional para metadatos, no solo más extensiones de datos.

La +1Gfigura es solo un ejemplo. El tamaño de los metadatos depende del tamaño del grupo de almacenamiento, el tamaño del fragmento, el uso de instantáneas y el comportamiento de asignación. Después de la reparación, revise los registros del sistema y utilice el procedimiento de verificación o reparación compatible con el sistema de archivos si se produjeron errores de E/S. No ejecute una herramienta de reparación de sistemas de archivos sin revisarla previamente en un sistema de archivos montado.

¿Eliminar archivos libera inmediatamente un pool delgado?

No siempre. Eliminar un archivo libera espacio en el sistema de archivos, pero el pool delgado solo recupera fragmentos físicos cuando la información de descarte llega al pool. La documentación de LVM indica que fstrimpuede recuperar dichos bloques, mientras que las instantáneas pueden seguir haciendo referencia a ellos e impedir que se liberen. Si el pool está configurado para ignorar los descartes, trim no recuperará los bloques.

Cuando el sistema de archivos y la carga de trabajo lo permitan, compruebe el comportamiento de descarte y realice el recorte solo después de que el grupo sea lo suficientemente estable como para funcionar:

lvs -o lv_name,discards VG_NAME/THIN_POOL
fstrim -v /mount/point

Eliminar instantáneas antiguas también puede liberar espacio de almacenamiento cuando dichas instantáneas son las únicas referencias restantes a los bloques. Verifique los requisitos de copia de seguridad y retención antes de eliminar instantáneas.

7. ¿Cómo se puede evitar que esto vuelva a suceder?

Habilite y verifique la monitorización del thin-pool de LVM y configure la autoextensión con suficiente capacidad libre en el VG. LVM ascendente utiliza dmeventd, normalmente a través del lvm2-monitorservicio, para reaccionar cuando el uso de datos o metadatos supera el umbral configurado.

systemctl status lvm2-monitor.service
lvs -o+seg_monitor VG_NAME/THIN_POOL
lvchange --monitor y VG_NAME/THIN_POOL

lvmconfig --type full activation/thin_pool_autoextend_threshold
lvmconfig --type full activation/thin_pool_autoextend_percent

Leyenda: La extensión automática depende de la monitorización activa, un umbral adecuado y la disponibilidad de extensiones libres en el grupo de volúmenes.

El manual de LVM indica que un umbral de 100 desactiva la extensión automática y que el umbral mínimo válido es 50. Un umbral más bajo le da a LVM más tiempo para reaccionar ante grupos con tasas de escritura muy rápidas. El porcentaje de extensión determina cuánto crece el grupo cuando se activa la política.

Una configuración representativa /etc/lvm/lvm.confpodría ser:

activation {
    thin_pool_autoextend_threshold = 70
    thin_pool_autoextend_percent = 20
}

Estos valores son ejemplos, no valores predeterminados universales. Ajuste el margen de seguridad según la tasa de ráfaga de escritura, el intervalo de monitorización, el tiempo de entrega del almacenamiento y el espacio libre disponible en el VG. La extensión automática no será útil si el VG ya está lleno.

8. ¿Cómo sabes que la recuperación realmente funcionó?

Verifique más de una señal. El pool debe tener capacidad disponible, el VG debe tener suficiente espacio libre para el crecimiento previsto, las aplicaciones deben poder escribir con normalidad y los registros no deben mostrar errores continuos de E/S o metadatos del thin pool.

lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent
vgs -o vg_name,vg_size,vg_free
journalctl -u lvm2-monitor.service --since "30 minutes ago"

Leyenda: La recuperación se confirma cuando la utilización del pool tiene margen, el VG conserva espacio libre utilizable y el sistema de monitorización no informa de errores de E/S continuos.

Reinicie las aplicaciones gradualmente y observe el tamaño reducido del grupo de recursos mientras se recupera la carga de trabajo real. Si Data%el aumento es inusualmente rápido, ampliar el grupo podría haber solucionado la interrupción inmediata sin resolver el problema de planificación de capacidad.

¿Cuándo deberías detenerte y utilizar una ruta de recuperación diferente?

¿Qué debes evitar?

• No asuma que df -hesto demuestra que una piscina delgada tiene almacenamiento físico gratuito.
• No inicialice un nuevo dispositivo pvcreatehasta que haya comprobado que no se ha utilizado.
• No considere el agotamiento de metadatos como un problema idéntico al agotamiento de datos ordinarios.
• No confíe en la extensión automática sin reservar extensiones libres en el VG.
• No ejecute comandos de reparación del sistema de archivos en sistemas de archivos montados a menos que el proveedor del sistema de archivos admita explícitamente esa operación.
• No desactive la monitorización simplemente para suprimir las advertencias; la advertencia suele ser la última oportunidad para ampliar el grupo de memoria antes de que fallen las escrituras.

Referencias oficiales y primarias

• Guía de administración de almacenamiento de SUSE Linux Enterprise Server 15 SP7
• Documentación de SUSE SLES 15 SP7 Expert Partitioner
• Manual de aprovisionamiento ligero de LVM
• Manual de LVM lvextend