Unifica rendimiento y capacidad: aprende a combinar discos duros de gran tamaño con una caché SSD “invisible” en Windows Server para eliminar traslados manuales de proyectos y acelerar tu servidor de archivos on‑prem.

Por qué una caché SSD cambia las reglas del juego

Cuando el volumen “Producción” en SSD y el volumen “Archivo” en HDD se llenan, la rotación manual de carpetas se convierte en un cuello de botella. Una capa de caché o tiering transparente:

• Ubica los bloques “calientes” en SSD y deja los fríos en HDD.
• Mantiene un único punto de montaje NTFS para usuarios y aplicaciones.
• Reduce el tamaño total de SSD necesario a un 5 – 10 % del dataset.
• Aprovecha discos duros de bajo coste para capacidad masiva.

Opciones disponibles en Windows Server

Storage Bus Cache (SBC) con Storage Spaces

SBC es la funcionalidad nativa de Windows Server 2019/2022 Datacenter que implementa tiering por bloques:

• Requisitos de hardware: el HBA debe presentar todos los discos en modo JBOD; no se admite RAID por hardware.
• Políticas automáticas: Windows mide lecturas/escrituras recientes y promueve esos bloques a SSD (escrituras en write‑back; lecturas en read cache).
• Protección de datos: la resiliencia se define en Storage Spaces (mirror, parity o mirror‑accelerated parity).
• Métricas y ajuste: PowerShell Get‑SBCPerformance y Set‑SBCSize.

Tiering de terceros sobre RAID por hardware

Si el servidor debe conservar controladoras RAID tradicionales, soluciones como StarWind Virtual SAN, DataCore SANsymphony o NetApp Flash Pool se colocan como una capa virtual entre Windows y las LUN RAID, realizando caché o tiering sin exigir JBOD. Su valor añadido suele incluir deduplicación en línea, compresión y QoS.

Mantener dos volúmenes separados

La vía más simple es ampliar ambos arrays y seguir migrando proyectos manualmente o con scripts basados en antigüedad (file aging). Minimiza cambios, pero no elimina la administración manual ni evita que el volumen rápido se llene.

Migrar a un sistema de archivos alternativo (Linux/BSD)

ZFS (L2ARC/ZIL) o bcache en Linux ofrecen una arquitectura de caché muy refinada, pero exigen adoptar un SO y herramientas distintos, lo que puede ser inviable en empresas ligadas a Active Directory, DFS Namespaces o software que dependa de NTFS.

Comparativa rápida de soluciones

Opción	¿Cumple el objetivo?	Requisitos / limitaciones	Ventajas destacadas	Desventajas / riesgos
Storage Bus Cache + Storage Spaces	✔	Discos JBOD; Windows Server 2019/2022 Datacenter	Automatización total; caché al 5‑10 %	Hay que abandonar RAID HW; resiliencia vía software
Ampliar dos volúmenes RAID	❍ (parcial)	Ninguno (mantiene RAID HW)	Simplicidad; inversión conocida	Traslados manuales continúan
Tiering de terceros	✔	Licencia; soporte del fabricante	Funciones avanzadas: QoS, dedupe, compresión	Coste y complejidad mayores; dependencia externa
ZFS / bcache / dm‑cache	✔	Migrar a Linux/BSD	Tiering maduro y flexible	Cambio de plataforma y soporte

Guía paso a paso: implementar Storage Bus Cache

Preparativos de hardware

1. Instale una controladora HBA en modo passthrough y conecte SSD y HDD individuales.
2. Asegure la presencia de una UPS que permita un apagado limpio; en write‑back la caché retiene datos en RAM y SSD.
3. Actualice firmware y drivers recomendados por el catálogo de Windows Server Hardware Compatibility.

Creación del Storage Pool

New-StoragePool -FriendlyName “PoolPrincipal” `
               -StorageSubsystemFriendlyName “Windows Storage*” `
               -PhysicalDisks (Get-PhysicalDisk) `
               -ResiliencySettingNameDefault Mirror

El pool puede utilizar discos heterogéneos; los SSD se etiquetarán como Cache y los HDD como Capacity.

Dimensionar y habilitar la caché

# Ejemplo: reservar 512 GB para lecturas y 256 GB para escrituras
Enable-StorageBusCache -Size 768GB `
                       -WriteCacheSize 256GB `
                       -Policy WriteBack

Empiece con el 5 % del tamaño total del volumen “lento” y ajuste tras una semana de telemetría.

Crear el volumen virtual

New-Volume -StoragePoolFriendlyName “PoolPrincipal” `
           -FriendlyName “Datos” `
           -FileSystem NTFS `
           -ResiliencySettingName Parity `
           -PhysicalDiskRedundancy 2 `
           -Size 20TB

Con mirror‑accelerated parity los metadatos y bloques calientes se duplican, mientras que la mayor parte de los datos usan paridad para maximizar capacidad.

Monitorear y ajustar

• Get‑SBCPerformance muestra lecturas/escrituras atendidas por SSD.
• Si la tasa de cache‑hit baja del 70 %, incremente la caché un 2 % por iteración.
• Integre alertas en SCOM o Grafana mediante Get‑StoragePool y Get‑Volume.

Buenas prácticas de operación

Deduplicación y compresión

La función “Data Deduplication” reduce hasta un 50 % los conjuntos de CAD, ISO o imágenes RAW. No se recomienda en volúmenes con archivos de bases de datos activos.

Clasificación y retención

Configurar File Server Resource Manager (FSRM) para etiquetar carpetas inactivas y moverlas a un LUN de archivo o a la nube (Azure File Sync, Amazon FSx). Esto disminuye la presión sobre la caché.

Backups coherentes

Las copias de seguridad basadas en VSS siguen funcionando porque el volumen es NTFS. No obstante, use la opción “backup‑optimized” de Storage Spaces para evitar fracturas de paridad durante un chkdsk.

Costos y retorno de inversión

En escenarios reales con 50 TB de datos y un patrón 80/20 (workingset caluroso), una caché SSD de 4–5 TB puede recortar tiempos de compilación o render un 60 %, permitiendo posponer la compra de cabinas All‑Flash que duplicarían el presupuesto.

Preguntas frecuentes

¿Qué ocurre si falla un SSD de la caché?

SBC replica la caché entre al menos dos discos. Si uno cae, el sistema lo evacúa y continúa operando. Es esencial que el pool tenga PhysicalDiskRedundancy = 2.
¿Puedo convertir un array RAID 5 existente a JBOD sin pérdida de datos?

No. El proceso implica borrar la tabla RAID y exponer discos individuales; debe migrar/copiar datos a almacenamiento temporal.
¿Se puede usar ReFS en lugar de NTFS?

Sí, pero hoy ReFS carece de compresión y cotas de FSRM. Para servidores de archivos con controles de cuota es mejor seguir en NTFS.

Conclusión

La combinación de HDD económicos y una caché SSD gestionada por Storage Bus Cache le permite ofrecer prestaciones cercanas a un All‑Flash con una fracción del coste, eliminando además la tediosa tarea de mover proyectos entre volúmenes. Si el modelo de soporte y la política de riesgos permiten abandonar el RAID por hardware, SBC es la estrategia nativa más limpia y sostenible. De lo contrario, considere una plataforma de tiering de terceros o automatice su flujo de archivado.