SLES Thin Pool sin espacio: Extienda LVM de forma segura y restaure las escrituras.

Cuando un volumen con aprovisionamiento ligero de SUSE Linux Enterprise Server informa que no hay espacio disponible en el dispositivo, verifique primero el área de datos del grupo de volúmenes ligeros. Si el área de datos está llena y el grupo de volúmenes tiene extensiones libres, extienda el Data%grupo de volúmenes ligeros con el área de metadatos, no solo con el tamaño virtual de su volumen lógico ligero. Un área de metadatos completamente llena es diferente: puede requerir una reparación sin conexión antes de que se reanuden las escrituras normales.Meta%lvextend

El procedimiento que se describe a continuación utiliza comandos LVM2 documentados para Linux y el modelo de almacenamiento descrito en la Guía de administración de almacenamiento de SUSE Linux Enterprise Server 15 SP7 . La disponibilidad de los comandos y la configuración del servicio pueden variar en otro Service Pack de SLES o en una instalación en clúster. Realice una copia de seguridad coherente con la aplicación y restrinja las escrituras intensivas antes de modificar el almacenamiento de producción.

1. Compruebe si el espacio de datos o los metadatos están agotados.

Ejecute lo siguiente en el host propietario del grupo thin activo, reemplazando vgdatacon el nombre de su grupo de volúmenes:

sudo lvs -a -o lv_name,lv_size,segtype,data_percent,metadata_percent,pool_lv vgdata

Busque la fila con thin-pool. SegTypemide Data%los bloques de datos asignados; Meta%mide los metadatos de asignación del pool. Estos son límites de capacidad separados. Si Data%está cerca de 100 pero Meta%está cómodamente por debajo, las extensiones de datos adicionales son la solución más directa. Si Meta%está en 100, utilice las precauciones de recuperación en la sección 4.

Por ejemplo , supongamos vgdata/pool0que el pool tiene 100 GiB con un uso de datos del 98,12 % y un uso de metadatos del 40,26 %. El pool corre un riesgo inmediato, incluso si df -hinforma de espacio suficiente dentro de un volumen delgado montado. El tamaño virtual de un volumen delgado puede exceder la capacidad física que respalda el pool, como explica la documentación de Expert Partitioner de SUSE .

Inspeccione también los errores recientes:

sudo journalctl -k --since "-30 min" | grep -Ei 'thin|no space|I/O error'

No interprete un resultado vacío de grep como prueba de que no se produjeron errores de escritura. Revise también los registros de la aplicación, especialmente si una base de datos o una máquina virtual estaba escribiendo cuando el grupo de memoria se llenó.

2. Confirme que el grupo de volúmenes tiene extensiones físicas libres.

Antes de cambiar el tamaño de la piscina, averigüe si el grupo de volumen puede financiar la ampliación:

sudo vgs -o vg_name,vg_size,vg_free vgdata

En el ejemplo hipotético, el grupo de volúmenes de 200 GiB tiene 40 GiB libres. Por lo tanto, una extensión de 20 GiB es factible en principio, sujeta a las restricciones de asignación y al espacio disponible para el crecimiento de los metadatos. Es mejor reservar algo de espacio del grupo de volúmenes en lugar de asignar todas las extensiones libres al pool.

Si VG_FREEes cero, lvextendno se puede inventar capacidad física. Añada un volumen físico correctamente identificado y preparado al grupo de volúmenes (VG), amplíe el almacenamiento subyacente y su volumen físico LVM según corresponda, o recupere bloques antes de volver a intentarlo. SUSE documenta cómo añadir volúmenes físicos al redimensionar un grupo de volúmenes . Nunca ejecute esta operación pvcreateen un disco no verificado: puede destruir los metadatos de almacenamiento existentes.

3. Ampliar la piscina delgada en lugar del volumen delgado

Cuando Data%el factor limitante no se agota, y hay suficientes extensiones de VG libres, se amplía el propio pool:

sudo lvextend -L +20G vgdata/pool0

La +20Gsintaxis añade 20 GiB al tamaño actual del pool; no establece el tamaño final en 20 GiB. En este ejemplo, el pool de respaldo aumenta de 100 GiB a 120 GiB. Con los datos asignados sin cambios, 98,12 GiB en uso representarían aproximadamente el 81,8 % del pool ampliado. El porcentaje real puede variar si continúan las escrituras durante la operación.

No sustituya . Ampliar el espacio delvextend -L +20G vgdata/thin1 direcciones virtuales de un volumen delgado no necesariamente añade capacidad de datos físicos a su grupo. Dado que este comando expande el grupo de respaldo en lugar del dispositivo de bloques virtuales del sistema de archivos, normalmente no se requiere redimensionar el sistema de archivos para esta operación específica. El manual de aprovisionamiento delgado de LVM documenta el mecanismo de extensión del grupo delgado y sus limitaciones.

Cuando no se puede ampliar la piscina inmediatamente

Si ya se han eliminado archivos de un sistema de archivos ligero y la pila completa admite el descarte, considere recuperar los bloques descartados:

sudo fstrim -v /srv/data

Utilice el punto de montaje real de un volumen delgado, no el dispositivo del pool delgado. Un recorte exitoso puede reducir Data%, pero eliminar archivos por sí solo generalmente no devuelve bloques al pool. Las instantáneas delgadas pueden conservar bloques compartidos, y un pool configurado para ignorar descartes no se beneficiará. No considere el recorte como un sustituto de emergencia confiable para la capacidad física, especialmente si las escrituras han comenzado a fallar. Elimine instantáneas antiguas solo después de verificar su propiedad, dependencias y requisitos de retención; la eliminación de instantáneas es irreversible.

4. Tratar un área de metadatos completa como una condición de recuperación.

Si Meta%se alcanza el 100%, detenga las escrituras de la aplicación y planifique una interrupción controlada. LVM advierte que el agotamiento de los metadatos puede provocar inconsistencias en los metadatos y sistemas de archivos del pool de memoria. Simplemente aumentar el tamaño del pool, reintentar las escrituras o forzar la activación no resuelve este riesgo.

La secuencia de recuperación documentada consiste en desactivar el grupo afectado sin conexión, reparar sus metadatos reducidos mediante lvconvert --repair VG/ThinPool, aumentar la capacidad de los metadatos mediante lvextend --poolmetadatasizey, a continuación, comprobar cada sistema de archivos afectado con la herramienta sin conexión adecuada. Por ejemplo, un grupo cuyos metadatos LV sean inferiores a 2 GiB podría requerir un destino revisado como:

sudo lvextend --poolmetadatasize 2G vgdata/pool0

Este no es un comando para ejecutar a ciegas en un pool activo y dañado. Su tamaño es un ejemplo, no un requisito universal. Confirme primero el tamaño actual de los metadatos, las extensiones disponibles, la desactivación correcta, los medios de recuperación y las copias de seguridad. lvconvert --repairDebe planificarse con tiempo de inactividad y experiencia en recuperación; el manual de LVM indica que puede fallar y los datos aún pueden ser irrecuperables. Conserve el LV de metadatos antiguo hasta que se hayan verificado el pool y los sistemas de archivos. Una copia de seguridad de la configuración de LVM desde vgcfgbackupno realiza copias de seguridad de los metadatos del thin-pool. Para datos críticos para el negocio, contacte con el soporte de SUSE o su equipo de recuperación de almacenamiento antes de intentar la reparación.

5. Habilite la extensión automática y luego verifique las escrituras.

Una vez que el sistema esté estable, configure una política de crecimiento proactivo en la activationsección de /etc/lvm/lvm.conf. Este ejemplo comienza la extensión con un uso del 70 % y solicita un crecimiento del 20 %; ajuste estos valores para la tasa de escritura y la capacidad disponible del VG:

activation {
    thin_pool_autoextend_threshold = 70
    thin_pool_autoextend_percent = 20
}

Asegúrese de que la configuración se aplique al ámbito de configuración correcto y de que se supervise el grupo:

sudo lvchange --monitor y vgdata/pool0

El crecimiento automático del thin-pool depende de la monitorización de eventos de LVM ( dmeventd) y de extensiones libres suficientes. Compruebe el servicio de monitorización que proporciona su instalación de SLES (por ejemplo, systemctl status lvm2-monitordónde se encuentra esa unidad) y revise sus registros. Un umbral no garantiza la protección si las escrituras superan la extensión o si el VG ya está lleno. Consulte la guía de extensión automática y las opciones de monitorización de lvchange del manual de LVM .

Verifica que la solución haya funcionado.

Lee tanto la utilización del pool como la capacidad restante del VG:

sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vgdata/pool0
sudo vgs -o vg_name,vg_free vgdata

Data%El espacio debería haber disminuido tras la expansión del grupo de datos, Meta%debe permanecer por debajo del límite de agotamiento y el grupo debe estar activo sin nuevos errores de E/S. Compruebe el estado del sistema de archivos y los registros de la aplicación, y luego realice una pequeña prueba de lectura y escritura adecuada para la aplicación antes de liberar las cargas de trabajo suspendidas. Si los errores persisten después de que haya espacio disponible, mantenga la carga de trabajo afectada fuera de línea hasta que se haya evaluado la integridad de su sistema de archivos y de la aplicación; una mayor capacidad no puede revertir las escrituras que ya han fallado o se han perdido.