Proxmox y almacenamiento iSCSI/NFS: ajuste de rendimiento, tiempos de espera y optimizaciones de montaje

Si las VMs en Proxmox responden con retraso o las operaciones de almacenamiento se bloquean aparentemente de forma aleatoria, ayuda un troubleshooting estructurado. Este documento práctico comienza con el mensaje central: Ajuste de rendimiento de iSCSI y NFS en Proxmox no es un único parámetro, sino la interacción afinada de ajustes en el host, la red y el target. Lea la cadena de comprobación, ejemplos de configuración concretos, procedimientos de prueba y una estrategia de reversión clara.

Resumen breve: características del protocolo y efectos operativos

iSCSI es almacenamiento a nivel de bloques: el host ve una LUN como un disco local. En el host actúan el Linux‑blocklayer, el I/O‑scheduler y Multipath (Device Mapper). NFS es un sistema de archivos distribuido sobre TCP (NFSv3/v4). Las imágenes de VM son archivos; en NFS la semántica del mount (p. ej. hard/soft, timeo, retrans) controla el comportamiento ante fallos de conexión. Ambos protocolos reaccionan de forma distinta ante pérdida de paquetes, problemas de MTU, hashing de switches o límites de hilos en el servidor.

Clasificación correcta de los grupos de síntomas

Antes de modificar, clasifique el problema. Grupos típicos:

• Límite de rendimiento: bajo throughput o pocas IOPS, pero sin errores.
• Timeouts y bloqueos: I/O colgado, tareas bloqueadas (en NFS frecuente con mounts de tipo hard).
• Errores/corrupción: I/O‑Errors, stale file handle, inconsistencias de datos.

La contramedida difiere: el aumento del rendimiento suele requerir cambios en colas/planificadores, los timeouts requieren ajuste de la lógica de reintentos y de las configuraciones de redundancia.

Cadena de comprobación: Host → Red → Target (procedimiento sistemático)

Los cambios en la cadena de almacenamiento deben ser siempre reversibles y efectuarse paso a paso. Ejecute la siguiente secuencia:

• Comprobaciones en el host: estadísticas de I/O, scheduler, procesos
• Comprobaciones de red: errores, MTU, retransmisiones, LACP
• Comprobaciones en el target: threading, queue‑depth, política de export/target

Host: comandos rápidos para diagnóstico básico

# Pakete für Diagnose
apt-get update && apt-get install -y sysstat multipath-tools open-iscsi fio blktrace

# Laufende Messwerte (lesen Sie r_await/w_await, avgqu-sz, %util)
iostat -xz 1 5

# Prozesse mit hoher IO‑Wait
pidstat -d 1 3

# Blockdevices und Schedulers
lsblk -o NAME,MAJ:MIN,ROTA,RO,SIZE,MODEL
cat /sys/block/sdX/queue/scheduler

Importante: r_await/w_await muestran latencias; avgqu‑sz la longitud de la cola. Valores elevados indican congestión o un manejo de cola insuficiente.

Red: comprobaciones end‑to‑end

# Link‑Fehler, Drops
ip -s link show dev eth1

# TCP Retransmits/Statistiken
ss -i dst 10.10.20.10:2049  # Beispiel NFS
ss -s

# MTU Test mit Ping (Jumbo)
ping -M do -s 8972 10.10.20.10

Verifique que los Jumbo Frames funcionen de forma coherente en todos los componentes. El hashing de LACP puede concentrar los flujos en un único enlace físico y anular así el beneficio de disponer de varios enlaces.

Ajustes específicos de Proxmox y definiciones de almacenamiento

Proxmox gestiona el storage en /etc/pve/storage.cfg (un archivo de configuración de cluster). Asegúrese de que las referencias a block‑devices consideren Multipath: apunte a /dev/mapper/mpath* en lugar de /dev/sdX para que la redundancia de caminos sea efectiva.

Ejemplo: storage.cfg para iSCSI con LVM

# Ausschnitt /etc/pve/storage.cfg
iscsi: iscsi-lun1
        portal 10.10.30.10:3260
        target iqn.example:lun1
        content images,rootdir

lvmthin: local-lvm
        vgname pve
        thinpool data

Si el dispositivo iSCSI aparece primero como /dev/sdX, el LVM‑PV residirá en él y no se utilizará Multipath. Objetivo: que las LUN aparezcan como /dev/mapper/mpath*.

Multipath: Ejemplo de multipath.conf

# /etc/multipath.conf (vereinfachtes Beispiel)
defaults {
  user_friendly_names yes
  find_multipaths yes
}

blacklist {
  devnode "^sda$"
}

multipaths {
  multipath {
    wwid 3600a0980387example
    alias mpath-data
    path_selector "round-robin 0"
    path_grouping_policy multibus
    failback immediate
  }
}

Explicación: wwid identifica el dispositivo; path_selector controla la distribución de carga; find_multipaths facilita la detección. Compruebe multipath -ll tras realizar cambios.

Particularidades de NFS: opciones de montaje, nconnect, Timeouts

Los montajes NFS afectan en gran medida el comportamiento ante fallos. Opciones importantes:

• hard (predeterminado para almacenamiento crítico): bloquea las E/S hasta que se restaure; es más seguro, pero puede bloquear hilos.
• timeo (timeout en unidades de 0,1 s): controla cuándo comienzan los reintentos.
• retrans: número de reintentos antes de reportar error.
• nconnect: varias conexiones TCP por montaje para distribución de carga en paralelo (solo es compatible y tiene sentido a partir del cliente Linux y si el servidor dispone de hilos/CPU para atenderlas).

Ejemplo de montaje con nconnect

# /etc/fstab Beispiel
10.10.20.10:/export/pve /mnt/pve-nfs nfs4 _netdev,hard,timeo=600,retrans=2,noatime,nconnect=4 0 0

# Mount anwenden
mount /mnt/pve-nfs

Consejo: pruebe nconnect de forma gradual (1→2→4) y supervise la CPU del servidor/threading. Si el servidor NFS no puede atender eficazmente las conexiones adicionales, aumentará la latencia y pueden incrementarse las retransmisiones.

Afinación de iSCSI: Session‑Timeouts, replacement_timeout, Queue‑Depth

iSCSI dispone de numerosos parámetros. Áreas importantes son los session‑timeouts (cuánto tiempo espera un cliente para el rebind), las Queue‑Depths (cuántas E/S paralelas permite una ruta) y las estrategias de failover de Multipath.

# Beispiel: replacement_timeout anpassen
iscsiadm -m node -T iqn.example:lun1 -p 10.10.30.10 
  --op update -n node.session.timeo.replacement_timeout -v 120

# Login/Logout für Anwendung
iscsiadm -m node -T iqn.example:lun1 -p 10.10.30.10 --logout
iscsiadm -m node -T iqn.example:lun1 -p 10.10.30.10 --login

Explicación: un replacement_timeout demasiado pequeño puede provocar errores de E/S ante breves interrupciones de red; un valor demasiado alto dejará las tareas bloqueadas más tiempo. Compruebe los cambios con una caída de enlace controlada.

Parámetros del kernel y del sistema que suelen ayudar

Algunos problemas pueden mitigarse con sysctl/ajustes. Precaución: los cambios deben probarse y documentarse.

# Beispiel sysctl Tuning (Beispiele testen!)
net.core.netdev_max_backlog = 3000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
vm.swappiness = 10

# Anwenden
sysctl -p

Estos parámetros aumentan los buffers de red y reducen el swapping. Para clústeres de producción: aplicar solo con monitorización y un ciclo de pruebas.

Benchmarking: escenarios fio para mediciones objetivas

Antes y después de los cambios deben ejecutarse benchmarks reproducibles. Utilice fio para simular cargas de trabajo típicas de VM (p. ej. 4k Random Read/Write, mezclas, trabajos grandes y secuenciales).

# Beispiel fio Jobfile: 4k Random Read/Write für 60s
[global]
ioengine=libaio
direct=1
runtime=60
time_based
group_reporting

[randrw]
bs=4k
rw=randrw
rwmixread=70
numjobs=8
iodepth=64
filename=/dev/mapper/mpath-data

# Ausführen
fio job.fio

Interprete p50/p99 Latenzen. Enfoque en los valores p99‑Werten (latencias de cola), no solo en los promedios.

Störungssimulation: kontrolliert Ausfälle provozieren

Un corte de enlace planificado o un reinicio del target muestran el comportamiento real. Ejemplo: desactivar brevemente un puerto de switch de almacenamiento mientras fio está en ejecución y observar.

# Auf dem Host: Port kurz abschalten (nur in Testumgebung)
ip link set dev eth2 down
sleep 5
ip link set dev eth2 up

# Beobachten
dmesg -T | tail -n 50
multipath -ll
journalctl -u multipathd --since "5 minutes ago"

Observe si Multipath reactiva rutas o si el I/O falla de forma persistente. Anote los intervalos de tiempo para failover y recuperación.

Monitoring und Alerts: Was Sie unbedingt im Blick haben sollten

Para el funcionamiento operativo, las siguientes métricas son esenciales:

• Latencias a nivel de bloque (r_await/w_await), longitud de la cola (avgqu‑sz)
• IOPS y throughput
• Retransmisiones de red, errores de enlace
• Estado de Multipath (dead/alive paths)
• Hilos del servidor NFS y carga

Implemente métricas en Prometheus/Grafana o en su monitoring‑stack. Las alertas deberían reaccionar ante la latencia p99, la tasa de retransmisiones y la pérdida de rutas, no solo ante el ancho de banda.

Sicherheit und Konsistenz: kurze Hinweise

Para iSCSI utilice CHAP (Challenge‑Handshake Authentication Protocol) para la autenticación. Para NFS considere Kerberos (sec=krb5) para datos sensibles. Tenga en cuenta: los mecanismos de autenticación pueden añadir latencia adicional y deben ser considerados en las pruebas.

Typische Stolperfallen und wie Sie sie vermeiden

• Referencia a /dev/sdX en lugar de /dev/mapper/mpath*: conduce a pérdida de redundancia de rutas.
• nconnect sin capacidad en el servidor: más conexiones TCP aumentan la carga de CPU en el servidor.
• Montajes soft en discos VM: provocan abortos de I/O y problemas de datos.
• Jumbo Frames solo configurados parcialmente: fragmentación, errores y retransmisiones incrementadas.
• Cambios en el scheduler sin análisis: pueden empeorar las latencias p99.

Konkrete Checkliste vor Änderungen

1. Capture la línea base: iostat, ss, multipath, dmesg.
2. Haga copia de seguridad de los archivos de configuración: /etc/fstab, /etc/multipath.conf, /etc/iscsi/*, /etc/pve/storage.cfg.
3. Pruebe los cambios en un host; realice una simulación de fallo.
4. Documente los cambios; tenga por escrito los pasos de rollback.
5. Tras el despliegue, valide con fio y con la carga de producción.

Fazit und Handlungsleitfaden

La optimización de rendimiento Proxmox iSCSI NFS significa considerar host, red y target como una unidad. Comience con mediciones, implemente de forma gradual cambios de bajo riesgo (nconnect, noatime, correcciones de Multipath), realice pruebas de fallo controladas y documente los procedimientos de reversión. Concéntrese en las latencias de cola (p99) y no solo en los valores medios: esto es decisivo en entornos productivos para los tiempos de respuesta y la experiencia del usuario.

Modo de trabajo: medir → ajustar → probar → desplegar. Y: realice cambios en entornos productivos solo con una estrategia de reversión probada. De este modo los tiempos de espera serán previsibles y el rendimiento del almacenamiento estable.

Proxmox iSCSI NFS Performance Tuning: Architektur‑ und Betriebsrisiken

Además de parámetros como nconnect o replacement_timeout, existen riesgos arquitectónicos que a menudo se pasan por alto en optimizaciones de rendimiento. Estos afectan a ciclos de backup/snapshot, Thin Provisioning, caches y el tipo de emulación de disco de la VM. Para responsables y operadores es importante entender cómo interactúan estas capas, de modo que los cambios no aporten rendimiento a corto plazo y a la larga conduzcan a inestabilidad o pérdida de datos.

Snapshots, Backups y tormenta de I/O

Los snapshots (LVM‑thin, ZFS, Array‑Snapshots) pueden causar picos elevados de escritura al consolidar o crear. En particular, el software empresarial con muchas escrituras pequeñas presenta entonces fuertes latencias p99. Planifique ventanas de backup separadas de las horas pico, limite los jobs de snapshot que se ejecuten en paralelo y supervise la ocupación del Thin‑Pool.

# Thinpool‑Nutzung prüfen (Hosts)
lvs -o+seg_monitor,metadata_percent,data_percent --units m

Fragmentación del Thin‑Pool y metadatos

Una región de metadatos del Thin‑Pool llena o fragmentada provoca una degradación abrupta del rendimiento. Los umbrales de alerta para metadata_percent deben incorporarse a su monitorización (p. ej. Prometheus); las reducciones automáticas son arriesgadas — mantenga capacidad PV libre y planes de RESTauración detallados.

Modos de caché, seguridad de datos y rendimiento

Proxmox/QEMU ofrece opciones de caché (none, writeback, writethrough). „writeback“ suele ofrecer las mejores latencias, pero aumenta el riesgo ante un corte de alimentación si los backends de almacenamiento no disponen de un caché de escritura persistente (Battery‑Backed Unit/BBU o NVRAM). „cache=none“ evita los efectos de caché del host y suele ser más estable con iSCSI/Multi‑Path.

# VM‑Konfiguration prüfen
cat /etc/pve/qemu-server/101.conf | grep -E 'scsi|cache'
# Beispiel: scsi0: local-lvm:vm-101-disk-0,size=32G
# cache: writeback

Tipo de controlador y comportamiento de multipath

Virtio‑SCSI suele ofrecer mejor soporte de funcionalidades para Multipath que virtio‑blk. Si sus LUNs son accesibles vía Multipath, pruebe migración y failover con Virtio‑SCSI; de lo contrario corre el riesgo de que cambios de ruta bloqueen el I/O dentro de la VM.

Deduplicación, compresión y alineación

La deduplicación o compresión a nivel de array puede degradar el throughput para cargas secuenciales y aumentar las latencias de cola (tail). PRESTe atención al alineamiento de LUN y a si debe habilitarse TRIM/DISCARD; los DISCARDs no planificados pueden fragmentar los Thinpools.

Operación, despliegue y gestión de compatibilidades

Realice actualizaciones de kernel, multipath y cliente iSCSI en un grupo canario. Documente una estrategia clara de retroceso, p. ej.:

• Rollback del archivo de configuración desde /etc/pve y /etc/multipath.conf
• Logout de un target iSCSI para comprobación:

iscsiadm -m node -T iqn.example:lun1 -p 10.10.30.10 --logout

Lista de verificación operativa práctica

• Monitorización: latencia p99, metadata_percent, estado de rutas Multipath, retransmisiones NFS.
• Prueba: simular consolidación de snapshots y jobs de backup bajo carga.
• Despliegue: cambios en modo canario, retroceso documentado y ventanas de mantenimiento.
• Gobernanza: coordinación con los responsables de aplicaciones (software empresarial individual) — los perfiles de I/O varían.

Tenga en cuenta estos aspectos de arquitectura desde temprano: evitan que las ganancias rápidas logradas por optimizaciones deriven más adelante en incidencias operativas críticas y picos de latencia impredecibles. Un proceso coordinado de pruebas y releases suele ser más eficaz que el ajuste aislado de parámetros.

Para este tema también son importantes los tiempos de espera de almacenamiento de Proxmox y las opciones de montaje NFS en Proxmox. El artículo contextualiza estos aspectos de forma comprensible y muestra en qué hay que fijarse en la operación diaria.