Storage Spaces con almacenamiento por niveles (Storage Tiers) se ha convertido en una de las herramientas más potentes de Windows Server para exprimir el rendimiento de los SSD sin renunciar a la gran capacidad y al bajo coste de los HDD tradicionales. Si combinas bien ambas tecnologías y configuras correctamente los grupos de almacenamiento, los discos virtuales y las capas, puedes conseguir un sistema que vuele para las cargas críticas y siga siendo asequible para el resto de datos.
En las siguientes líneas te explicamos qué son Storage Spaces, cómo funciona el almacenamiento en capas, qué requisitos debes cumplir y cómo montar todo el entorno tanto en servidor independiente como en escenarios con Storage Spaces Direct.
Qué es Storage Spaces y cómo encaja el almacenamiento por niveles
Storage Spaces es la capa de almacenamiento definido por software de Windows Server que permite agrupar varios discos físicos en uno o varios pools de almacenamiento (grupos de almacenamiento) desde los que se crean discos virtuales con diferentes niveles de resiliencia y aprovisionamiento. Sobre estos discos virtuales se crean posteriormente volúmenes NTFS o ReFS como si fueran discos “de toda la vida”.
Pero, ¿qué es un grupo de almacenamiento? No es más que un contenedor lógico de discos físicos donde Windows deja de ver los discos por separado para tratarlos como un único conjunto. Desde ese pool podrás añadir más discos en el futuro, ampliar capacidad y delegar la administración con bastante flexibilidad. Algo muy útil en entornos con crecimiento continuo.
Desde cada pool puedes crear uno o varios discos virtuales (espacios de almacenamiento). Una vez creado el disco virtual, el siguiente paso es definir uno o varios volúmenes formateados, donde eliges tamaño, letra de unidad o carpeta de montaje, sistema de archivos (NTFS o ReFS), tamaño de unidad de asignación y una etiqueta descriptiva. A nivel de administración diaria, trabajarás con estos volúmenes igual que con cualquier otra unidad de Windows.
El almacenamiento por niveles (Storage Tiers) entra en juego cuando en el mismo pool se combinan SSD y HDD. Windows analiza qué bloques de datos son accedidos con mayor frecuencia y los sitúa en la capa rápida (SSD), mientras que los bloques fríos o poco utilizados se reubican en la capa de capacidad (HDD). Todo este movimiento es automático y transparente para las aplicaciones.
El resultado es que consigues la velocidad de los SSD para los datos calientes y la capacidad barata de los HDD para datos menos críticos. Y sin tener que partir a mano qué va en cada disco. Para un administrador de sistemas es una manera muy eficiente de equilibrar presupuesto, IOPS y capacidad sin complicaciones excesivas.
Requisitos previos y consideraciones de hardware
Antes de lanzarte a crear pools y discos virtuales, hay una serie de requisitos de hardware que Windows Server impone para que Storage Spaces y Storage Tiers funcionen correctamente. Especialmente en servidores físicos.
En cuanto a tipos de bus de disco, Storage Spaces soporta SAS (Serial Attached SCSI), SATA, iSCSI y Fibre Channel. También puedes usar unidades USB, aunque en un servidor es una práctica poco recomendable por rendimiento y fiabilidad. Si vas a montar Storage Spaces sobre LUNs de iSCSI o FC, los discos virtuales han de ser no resilientes (diseño Simple) para que la capa de RAID no se solape con la del propio cabinado.
Los discos físicos deben tener al menos 4 GB de tamaño. Es fundamental que lleguen limpios: sin particiones, sin volúmenes y sin formatos previos. Lo ideal es que todos los discos que participen en un pool sean homogéneos en capacidad y tipo de medio. Sobre todo cuando vayas a aplicar resiliencia por Mirror o Parity.
Respecto a los HBA (Host Bus Adapter), Microsoft recomienda usar adaptadores “simples”, sin funcionalidades RAID activas. Si tu HBA soporta RAID, debe poder configurarse en modo no RAID, deshabilitando completamente cualquier caché o agrupación a nivel de controlador. Storage Spaces necesita ver cada disco como un dispositivo independiente, sin que el HBA abstraiga nada ni proporcione servicios tipo JBOD cerrados que oculten la visibilidad de las ranuras.
En escenarios con cabinas JBOD externas, es muy recomendable que estén certificadas para Storage Spaces y aparezcan listadas en el Windows Server Catalog. Para verificar que la cabina expone correctamente el número de chasis y la ranura de cada disco (EnclosureNumber y SlotNumber), puedes usar un cmdlet de PowerShell filtrando por bus SAS y revisando que esos campos tengan valores válidos.
Tipos de resiliencia: Simple, Mirror y Parity
Cuando creas un disco virtual, una de las decisiones clave es el tipo de resiliencia, ya que condiciona tanto el rendimiento como la tolerancia a fallos y el consumo de capacidad útil.
Diseño Simple
Distribuye los datos en stripes sobre todos los discos físicos participantes, maximizando rendimiento y capacidad efectiva, pero sin ningún tipo de protección. Basta con que un disco falle para que el conjunto quede irrecuperable. Es adecuado para datos temporales, test, laboratorios o información que se pueda regenerar fácilmente a bajo coste.
El diseño Mirror (reflejo)
Almacena dos o tres copias de los datos en discos físicos distintos, incrementando muchísimo la fiabilidad a costa de sacrificar capacidad. Al igual que en un RAID 1/10, cada escritura se duplica (o triplica) y, además, los datos se reparten entre varias unidades, lo que mejora el rendimiento y reduce la latencia en comparación con la paridad. En Windows se utiliza además un mecanismo de DRT (Dirty Region Tracking) para mantener la coherencia entre copias tras reinicios bruscos o caídas inesperadas.
Diseño Parity (similar a un RAID 5/6)
Combina datos e información de paridad repartida por todos los discos. Ofrece un mejor aprovechamiento de capacidad que Mirror, con protección ante fallo de disco, pero a cambio de más latencia, sobre todo en escrituras aleatorias. Funciona muy bien para datos con acceso secuencial, como repositorios de backup, archivos de archivo (archiving), registros históricos o datos fríos.
Para usar Parity con protección frente al fallo de un disco, necesitas al menos 3 discos físicos. Conviene evitarlo para cargas con escrituras aleatorias intensivas (bases de datos OLTP, VM con mucho churn), donde Mirror suele ofrecer una experiencia mucho más fluida.
Creación de grupos de almacenamiento paso a paso
El primer paso operativo para trabajar con Storage Spaces es agrupar los discos físicos disponibles en uno o varios grupos de almacenamiento. Ya sea desde el Administrador del servidor o bien mediante PowerShell.
En la consola del Administrador del servidor, accede a “Servicios de archivos y almacenamiento” y, dentro de “Volúmenes”, entra en “Grupos de almacenamiento”. De forma predeterminada, los discos libres aparecerán en un pool llamado “grupo primordial”. Si no lo ves, normalmente significa que el almacenamiento no cumple los requisitos de Espacios de almacenamiento o que los discos no están en estado apto para agruparse.
Desde la sección de “GRUPOS DE ALMACENAMIENTO”, despliega el menú de “TAREAS” y lanza el asistente de “Nuevo grupo de almacenamiento”. Ahí podrás asignar un nombre amigable al pool, una descripción y seleccionar el subsistema de almacenamiento correspondiente.
En la página de selección de discos físicos, marca los discos que vayan a formar parte del pool. Si quieres, establece algunos como repuestos activos (Hot Spare) cambiando el tipo de asignación. Estos discos quedarán en reserva y se usarán automáticamente para reconstrucciones en caso de fallo de una unidad activa.
Tras confirmar las selecciones y crear el pool, verás el nuevo grupo de almacenamiento listado en la consola, listo para que crees sobre él los discos virtuales que necesites. Toda esta operación se puede replicar por PowerShell con cmdlets como Get-StoragePool, Get-PhysicalDisk -CanPool $true y New-StoragePool, especificando bien el nombre del subsistema y el listado de discos a incluir.
Creación de discos virtuales y activación de Storage Tiers
Una vez tienes el pool listo, el siguiente paso es crear uno o varios discos virtuales desde ese grupo, definiendo diseño de resiliencia, aprovisionamiento y, si procede, habilitando almacenamiento por niveles.
En la sección de “DISCOS VIRTUALES” del Administrador del servidor, selecciona el pool correspondiente y elige “Nuevo disco virtual” desde “TAREAS”. El asistente te pedirá que nombres el disco virtual, selecciones el diseño de almacenamiento (Simple, Mirror o Parity) y, si hay discos de distintos tipos de medio, podrás marcar la opción de “Crear capas de almacenamiento en este disco virtual” para activar Storage Tiers.
Cuando activas Storage Tiers, hay algunas limitaciones importantes. Solo puedes usar diseños Simple o Mirror (Paridad no está disponible con capas) y el tipo de aprovisionamiento debe ser Fixed (fijo). No se permite Thin para discos por niveles. Esto es clave si estás planificando un diseño con paridad. Tendrás que usar un disco virtual separado sin capas o un pool distinto.
En entornos de laboratorio o virtualizados, puedes incluso “engañar” al sistema creando varios discos virtuales SAS en un hipervisor como VMware Workstation y luego marcando manualmente qué discos son SSD y cuáles HDD mediante PowerShell con Set-PhysicalDisk -MediaType. De este modo Windows detectará correctamente las dos clases de medio y permitirá definir las capas.
Durante el asistente, podrás elegir el tamaño a asignar en cada capa. Es decir, cuánto espacio de SSD se reservará para la capa rápida y cuánta capacidad de HDD se dedicará a la capa masiva. Esta proporción es clave: un tier SSD demasiado pequeño puede saturarse rápido y perder parte del beneficio en cargas muy activas.
Aprovisionamiento fino vs fijo y tamaño de los discos virtuales
La creación de un disco virtual también implica elegir el tipo de aprovisionamiento y el tamaño lógico que verá el sistema operativo. Decisiones que afectan a la gestión de capacidad.
- Con aprovisionamiento fino (Thin). El espacio se asigna dinámicamente a medida que se escriben datos reales. Esto permite sobreaprovisionar, creando discos virtuales más grandes que la capacidad física disponible a corto plazo. El riesgo es evidente: si no monitorizas bien el uso del pool, puedes quedarte sin espacio físico y poner en peligro la integridad de los datos.
- Con aprovisionamiento fijo (Fixed). Toda la capacidad declarada para el disco virtual se reserva inmediatamente en el pool. No puedes sobreasignar, pero ganas en previsibilidad y rendimiento estable, ya que no hay sobrecarga asociada a extensiones de espacio en caliente. En el caso de discos con Storage Tiers, el aprovisionamiento debe ser fijo obligatoriamente.
En el asistente podrás indicar un tamaño concreto (en MB, GB o TB) o, en el caso de diseños fijos, usar la capacidad máxima disponible del pool.
Todo este proceso se puede automatizar con PowerShell usando New-VirtualDisk, donde defines el nombre amigable, el diseño de resiliencia (ResiliencySettingName), el número de copias de datos, el tamaño, el tipo de aprovisionamiento y, si es necesario, parámetros avanzados como columnas o intercalado para tunear el rendimiento según la carga de trabajo.
Creación de volúmenes, formato y administración básica
Con el disco virtual creado y en línea, el último paso del flujo clásico consiste en crear un volumen, asignarle letra de unidad o carpeta de montaje y formatearlo con el sistema de archivos adecuado.
Desde el Administrador del servidor puedes lanzar el asistente de “Nuevo volumen” haciendo clic derecho en el disco virtual. Primero eliges el servidor y el disco, luego defines el tamaño del volumen y decides si quieres asignar una letra de unidad o montar en una carpeta vacía de otro volumen. Finalmente, seleccionas entre NTFS o ReFS como sistema de archivos.
En ese mismo paso puedes elegir el tamaño de unidad de asignación (lo habitual es dejarlo en predeterminado salvo requisitos concretos) y establecer una etiqueta descriptiva. Si el servidor tiene rol de desduplicación instalado, también podrás elegir si quieres activarla o no en ese volumen. Algo interesante para repositorios de backup o librerías de VHD.
Al finalizar el asistente, el volumen aparecerá en la sección de volúmenes del Administrador del servidor y también en el Explorador de archivos listo para usarse. Si prefieres hacer todo esto con un único comando, puedes encadenar cmdlets como Get-VirtualDisk | Get-Disk | Initialize-Disk | New-Partition | Format-Volume, lo que resulta muy cómodo para scripts de despliegue masivo.
Extender un disco virtual existente también es posible desde la consola (opción “Extender disco virtual”) o por PowerShell, y después tendrás que ampliar el volumen correspondiente desde el Administrador de discos clásico o con Resize-Partition. Esta operación es especialmente útil cuando has añadido discos nuevos al pool y quieres que una carga específica crezca sin interrupciones y sin pérdida de datos.
Storage Spaces Direct y el papel de las capas en clúster
Cuando das el salto a Storage Spaces Direct (S2D), todo lo anterior se traslada a un entorno de clúster donde varios servidores aportan sus discos locales a un pool distribuido con alta disponibilidad. Aquí las capacidades de rendimiento y capacidad por niveles cobran aún más relevancia. Especialmente en diseños hiperconvergentes con Hyper-V.
El despliegue de S2D comienza con la instalación de Windows Server Datacenter en cada nodo, configuración de red con NICs 10 GbE (o superiores) y, preferiblemente, RDMA (iWARP o RoCE) para latencias mínimas entre nodos. Necesitarás además unir los servidores a dominio, instalar roles como Failover Clustering, Hyper-V, File Server y los módulos RSAT necesarios para administrar todo remotamente.
Antes de habilitar S2D hay que limpiar por completo las unidades de cada host (sin particiones ni datos previos) y ejecutar una validación de clúster con Test-Cluster incluyendo específicamente las pruebas de “Storage Spaces Direct”. Después, crear el clúster y su testigo.
El cmdlet clave es Enable-ClusterStorageSpacesDirect, que pone el sistema en modo S2D, crea automáticamente un gran pool compartido, configura la caché (por ejemplo usando SSD como write-back para HDD más lentos) y genera dos niveles predeterminados: un tier de “Rendimiento” y otro de “Capacidad”. Ambos listos para que crees volúmenes por niveles.
A partir de ahí, el cmdlet New-Volume simplifica el proceso porque en un solo paso crea el disco virtual, lo particiona, lo formatea y lo agrega a CSV (Cluster Shared Volumes). Puedes especificar en el propio comando qué resiliencia usar, qué tamaño de cada tier deseas y cuántas copias de datos quieres, adaptando el diseño al tipo de carga (Hyper-V, SQL Server, archivos de usuario, etc.).
Clases de datos, niveles y dónde usar cada uno
Más allá de la pura tecnología, para sacar todo el partido a Storage Tiers es esencial clasificar correctamente tus datos. Al final, el almacenamiento por niveles no es otra cosa que decidir qué datos merecen el SSD y cuáles pueden vivir en HDD baratos, cinta o incluso nube fría.
Una clasificación típica distingue entre:
- Datos de misión crítica (bases de datos de negocio, sistemas de facturación, VMs clave).
- Datos calientes (muy activos pero no vitales).
- Datos templados (acceso ocasional).
- Datos fríos (logs históricos, backups antiguos, archivos de archivo).
Cada categoría encaja naturalmente en un nivel de almacenamiento distinto, tanto dentro de Storage Spaces como fuera de él.
En la práctica, los datos calientes y críticos se benefician de estar en el tier SSD dentro del pool, con resiliencia Mirror y latencia mínima. Los datos templados pueden residir en discos híbridos o en la parte HDD de un pool con tiering, mientras que los fríos pueden migrarse a storage nearline, cintas o servicios de almacenamiento en la nube con costes muy bajos por GB.
Las arquitecturas de almacenamiento por niveles suelen hablar de niveles 0, 1, 2 y 3:
- Tier 0: SSD ultrarrápido.
- Tier 1: SSD de alto rendimiento más convencional.
- Tier 2: almacenamiento híbrido o HDD rápidos.
- Tier 3: dispositivos nearline masivos de bajo coste.
En entornos híbridos, muchos diseños añaden además un “Cloud Tier” específico para almacenamiento en la nube.
Dentro de Windows, Storage Spaces y Storage Spaces Direct permiten jugar con esta lógica de niveles a nivel local, mientras que soluciones de backup o de gestión de datos externas pueden extender la idea hacia la nube o hacia sistemas de archivo profundo. La clave es mantener siempre alineados valor del dato, frecuencia de acceso y coste.
Almacenamiento por niveles vs caché: dos piezas que se complementan
Un punto que suele generar confusión es la diferencia entre almacenamiento por niveles y caché. Aunque ambos usan medios rápidos para acelerar el acceso, funcionan de formas bastante distintas y tienen objetivos complementarios.
La caché copia datos calientes a un medio de muy alta velocidad (DRAM, SSD, NVRAM) situado entre la aplicación y el almacenamiento principal. Los datos originales siguen viviendo en el nivel lento y la caché guarda copias temporales que pueden desecharse cuando se consideran “viejas” o cuando hace falta espacio para nuevos bloques.
El almacenamiento por niveles (tiered storage) mueve físicamente los datos entre niveles: cuando un bloque se detecta como caliente, se traslada al tier rápido y desaparece del medio lento; cuando se enfría, se acaba reubicando en el nivel de capacidad. No hay duplicación permanente, sino reubicación según políticas y patrones de acceso.
En Storage Spaces Direct, por ejemplo, la caché CSV en memoria y la propia caché de S2D pueden combinarse con tiers SSD/HDD para conseguir un esquema mixto muy potente: la caché absorbe picos de I/O a muy baja latencia, mientras que el tiering optimiza dónde residen de forma persistente los datos a medida que su patrón de acceso cambia.
Entender bien esta diferencia te ayudará a decidir cuándo te conviene invertir en más RAM, memoria persistente (PMEM) o en mejores SSD de caché, y cuándo es mejor ampliar el tier rápido del pool para alojar más datos activos sin penalizar el presupuesto.
Combinando Storage Spaces, Storage Spaces Direct, cachés bien dimensionadas y un diseño inteligente de almacenamiento por niveles, se puede construir una plataforma de almacenamiento en Windows Server que entregue altísimo rendimiento donde hace falta, gran capacidad para el archivo masivo y una administración razonablemente sencilla, siempre que se respeten los requisitos de hardware, se sigan las mejores prácticas y se apoye todo en una monitorización y automatización cuidadosas.
