Volumen iSCSI R: desaparece en Windows Server 2019: diagnóstico completo y solución definitiva

Un volumen iSCSI que desaparece de forma intermitente es un síntoma alarmante: impacta servicios, genera pérdidas de datos potenciales y, si no se identifica la raíz, reaparecerá. A continuación encontrarás un análisis exhaustivo del caso de un Dell PowerEdge R730 con Windows Server 2019 que “pierde” su unidad R: conectada a una cabina Nexsan Unity 3300, además de procedimientos recomendados para diagnosticar y resolver problemas similares.

Visión general del escenario

El servidor opera con Windows Server 2019 Desktop Experience y accede a la cabina mediante dos NIC de 10 GbE dedicadas a iSCSI, en una red aislada. El volumen R: está presentado como LUN única, gestionada por MPIO en modo Round Robin.

Eventos registrados en el visor

Tipo de evento	ID	Descripción resumida
Warning	51 / 157 (Disk)	Error de paginación y “Disk 11 surprise removed”
Error	9 / 49 / 63 (iScsiPrt)	Timeout SCSI, reinicio de sesión y fallo de restablecimiento de LUN
Warning	129 (iScsiPrt)	“\Device\RaidPort4” indica time‑out del adaptador de almacenamiento

Por qué estos eventos importan

• 51: Windows detecta que no puede completar operaciones de E/S en disco; suele aparecer antes de pérdidas de conexión.
• 157: el sistema considera que la unidad fue retirada sin notificación (surprise removal), lo que dispara desmontaje y posible corrupción de caché.
• 9, 49, 63: el iniciador iSCSI ha agotado tiempos de espera y reinicia la sesión o la petición; un exceso acaba derribando la ruta.
• 129: indica que la capa StorPort marca el puerto como bloqueado tras não recibir respuesta; si coexiste con 157, suele haber congestión o fallo en el target.

Análisis inicial: ¿red, sistema operativo o cabina?

La clave es aislar la causa primaria. El error surprise removed implica que el dispositivo deja de contestar súbitamente; eso dirige la investigación a tres frentes:

1. Red y switches — Los paquetes podrían perderse por microcortes, mal QoS o congestión Jumbo Frames.
2. Iniciador iSCSI (Windows) y controladores — Un bug de NIC/Firmware reinicia la interfaz y provoca time‑outs.
3. Target iSCSI (Nexsan) — La controladora puede quedar en estado inconsistente, negándose a atender comandos SCSI.

Metodología de diagnóstico recomendada

Verificación física y de red

• Comprueba link status, errores CRC y contadores de reenvío en los puertos de switch.
• Asegura que VLAN, MTU (9000 bytes si usas Jumbo) y Prioridad de tráfico coinciden extremo a extremo.
• Prueba cables DAC o de fibra óptica sustitutos; fallos intermitentes de conector pueden imitar caídas lógicas.
• Valida que no se comparta uplink con picos de tráfico (backups, réplicas) que saturen la cola del switch.

Revisión de firmware, BIOS y drivers

Un cambio de firmware suele coincidir con el inicio de fallos. Pasos:

1. Extrae el inventario con racadm getversion o Get-Inventory de Dell OMSA.
2. Contrasta versiones de NIC (Broadcom/Intel/QLogic), BIOS y iDRAC con la Recommended Firmware Matrix de Dell.
3. Si hay actualización reciente, aplica un rollback o instala la versión oficialmente soportada más nueva.
4. Para adaptadores iSCSI por hardware (CNA/HBA), aplica firmware y bootcode emparejados con el driver aprobado por Microsoft SCCM o por Dell SUU.

Ajustes críticos del iniciador iSCSI en Windows

• MaxRequestHoldTime (DWORD en HKLM\SYSTEM\CurrentControlSet\Services\iScsiPrt\Parameters) define cuántos segundos espera Windows antes de abortar I/O pendiente; subirlo a 120 o 180 ayuda en cabinas con latencia variable.
• LoginTimeout controla cuánto tarda en levantar la sesión; en entornos con cabinas que tardan en presentar LUN tras reinicio conviene aumentarlo.
• Verifica MPIO: usa mpclaim –e –i –d para listar dispositivos; activa Round Robin con Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy RR.
• Desactiva el Power Management de la NIC en Windows y en BIOS; la suspensión de enlaces provoca time‑outs fantasma.

Evaluación del Storage Target

La cabina Nexsan Unity almacena logs de controladora accesibles vía GUI o CLI (show logs). Observa:

• Alertas de write cache flush, reconexiones de puerto o RAID consistency check durante las horas del incidente.
• Temperatura de módulos y estado de fuentes; un pico térmico desconecta puertos.
• Over‑commit de SSD cache o latencia excesiva en discos NL‑SAS puede disparar watchdogs internos.

Procedimiento definitivo aplicado

Tras correlacionar eventos, Dell y Microsoft descartaron problemas en el host. Nexsan indicó un posible cache locking originado por firmware 2.10.x. La solución:

1. Apagar ordenadamente las máquinas virtuales, luego el host Windows.
2. Detener controladoras y expansión de la Unity 3300 durante 2 minutos para drenar condensadores y limpiar la NVRAM.
3. Encender la cabina, esperar al estado Ready con todos los discos on‑line.
4. Encender el servidor y confirmar que la firma de disco GPT de la LUN no ha cambiado; montar R: y ejecutar chkdsk /r.

Desde entonces (90 días de vigilancia) no se han reproducido eventos 51/157 ni time‑outs iScsiPrt.

Acciones preventivas para evitar recurrencias

Monitorización proactiva

• Configura Get-WinEvent -FilterHashtable @{LogName="System"; Id=@(9,51,57,129,157)} en un Scheduled Task que envíe correo al detectar más de cinco eventos en 10 minutos.
• Habilita SNMP o syslog en la Unity y direcciona a tu SIEM; crea regla para iSCSI Link Lost.
• Conecta un analizador de red (port mirror) para capturar paquetes iSCSI durante el fallo y estudiar retransmisiones TCP.

Mantenimiento de firmware y SO

Componente	Cadencia sugerida	Herramienta
BIOS / iDRAC	2 veces al año	Dell Lifecycle Controller / iDRAC REST
NIC / CNA	Trimestral	SUU / Dell Repository Manager
Windows Update + CU	Mensual (B release)	WSUS / MECM
Firmware cabina	Semestral	Nexsan Unity Local UI

Buenas prácticas de diseño iSCSI

• Red dedicada iSCSI con MTU uniforme; mezclar MTU 1500 y 9000 causa fragmentación.
• Al menos dos switches con MLAG o vPC; distribuye NICs del host por chasis diferente.
• Evita “fan‑in” excesivo: un solo enlace de uplink 10 GbE a core para 20 hosts satura buffers en ráfagas.
• Define clases de tráfico y asigna prioridad 4 (Storage) en QoS VoQ.
• Deshabilita flow‑control RX si usas DCB PFC; la tormenta de PAUSE congela puertos.

Preguntas frecuentes

¿Por qué el evento 51 aparece incluso si el almacenamiento parece estable?

51 no significa pérdida física; el subsistema de almacenamiento notificó retry queue full. Una latencia puntual de más de 60 s provocará el mismo warning. Correlaciona con 129 y 157 para confirmar pérdida real.

¿Es seguro aumentar MaxRequestHoldTime?

Elevarlo de 60 s a 180 s da margen para cabinas lentas, pero si la verdadera causa es enlace caído, la aplicación percibirá mayor “congelación”. Ajusta con cautela.

¿Puede un antivirus causar 157?

Poco probable. 157 se genera en la capa StorPort, antes de filtros de antivirus. Sin embargo, exclusiones de R: para tareas de backup siguen siendo recomendables.

Glosario rápido

iSCSIProtocolo que encapsula comandos SCSI sobre TCP/IP. MPIOMultipath I/O; distribuye tráfico en múltiples rutas para resiliencia y rendimiento. Round RobinPolítica que rota cada I/O por una ruta diferente. Surprise RemovalEstado en que el SO pierde el dispositivo sin recibir notificación de desconexión. Unity 3300Cabina híbrida de Nexsan con soporte SAS, NL‑SAS y SSD, hasta 384 TB en 3U.

Conclusión

La desaparición intermitente del volumen R: se originó en la cabina Nexsan, confirmada por el fabricante. El power‑cycle completo vació la caché y restituyó la LUN sin efectos adversos. No obstante, la naturaleza implacable de los eventos 51/129/157 obliga a mantener observabilidad continua y actualización disciplinada de firmware y controladores. Implementar mejores prácticas de red iSCSI, MPIO adecuado y monitorización de logs garantizará que la solución sea duradera y que la próxima alerta pueda identificarse y remediarse antes de impactar servicios críticos.