Storage Spaces con tiering: guía completa en Windows

Cuando empiezas a trastear con Storage Spaces y el famoso tiering en Windows, enseguida descubres dos cosas: que es potentísimo y que la interfaz gráfica se queda muy corta, sobre todo en Windows 10 y en escenarios un poco serios. La mayoría de las configuraciones interesantes pasan sí o sí por PowerShell y algo de planificación, tanto si hablamos de un homelab como de un servidor en producción.

Aunque a primera vista pueda parecer una tecnología reservada a grandes cabinas y entornos enterprise, lo cierto es que Storage Spaces con almacenamiento por niveles lleva presente desde Windows Server 2012 R2 y se puede aprovechar incluso en Windows 10, siempre que cumplas ciertos requisitos de hardware y te sientas cómodo con la línea de comandos. Vamos a ver en detalle cómo funciona, qué puedes hacer con él y qué trampas conviene evitar.

Qué es Storage Spaces con tiering y por qué merece la pena

En Windows Server 2012 R2 apareció una funcionalidad llamada Storage Tiers dentro de Storage Spaces. La idea es sencilla pero muy potente: combinar en un mismo pool discos SSD y discos mecánicos (HDD) y que el sistema coloque automáticamente los datos más activos en los SSD, manteniendo en los HDD todo lo que se accede con menos frecuencia.

En la práctica, esto convierte un conjunto de discos normales en una especie de unidad híbrida “a lo grande”: el sistema ve un único disco virtual, pero por debajo los bloques calientes viven en SSD y el resto se queda en discos más lentos y baratos. De este modo consigues rendimiento cercano al SSD con capacidad de HDD sin complicarte con soluciones externas de caché.

Un detalle importante es que el tiering en Storage Spaces funciona a nivel de bloque, no de archivo. El sistema analiza qué bloques se leen y escriben con más frecuencia y los reubica automáticamente. Todo esto se hace mediante tareas programadas que se habilitan después de crear el primer disco virtual con niveles.

En muchos entornos caseros o de laboratorio, antes de conocer esta característica la gente acababa montando dos grupos de almacenamiento separados: uno solo con SSD para cargas rápidas y otro con HDD para grandes volúmenes. Con los tiers puedes unificarlo en un único pool y simplificar bastante la gestión, manteniendo rendimiento y capacidad.

Requisitos básicos para usar Storage Spaces con niveles

Para poder crear un pool con tiering en condiciones necesitas cumplir varios requisitos de hardware y sistema operativo. No basta con tener un par de discos sueltos conectados al azar.

Lo mínimo imprescindible es disponer de al menos un SSD y un HDD en el sistema para que Windows pueda formar dos niveles distintos dentro del mismo grupo. En escenarios reales, y especialmente si quieres resiliencia tipo mirror, necesitarás más discos para que tenga sentido.

Desde el punto de vista de sistema, la capacidad de tiering está soportada en Windows Server 2012 R2 y versiones posteriores. En estos servidores, Server Manager incluye asistentes para crear pools y discos virtuales con almacenamiento por niveles guiado, aunque muchas opciones avanzadas siguen siendo más cómodas vía PowerShell.

En el caso de Windows 10, el soporte de Storage Spaces sigue estando, pero la interfaz gráfica del Panel de control no muestra ninguna opción para trabajar con tiers. Eso significa que toda la configuración de niveles se hace exclusivamente con cmdlets de PowerShell. Algunas guías y repositorios proporcionan scripts que automatizan la detección de discos, la creación del pool y del disco virtual con tiers, precisamente porque el GUI no ayuda nada en este escenario.

Cómo funciona la detección de discos y el tipo de medio

Uno de los puntos críticos para que el tiering funcione bien es que Windows identifique correctamente qué discos son SSD y cuáles son HDD. Esa información se guarda en la propiedad MediaType de cada disco físico, que debe estar ajustada a SSD o HDD según corresponda.

En entornos reales pasa muchas veces que algunos discos mecánicos aparecen como MediaType: Unknown o Unspecified. Cuando eso ocurre, el asistente gráfico para discos virtuales no permite habilitar la opción de crear almacenamientos por niveles; la casilla aparece deshabilitada y el sistema avisa de que no se cumplen los requisitos para tiering.

La solución, por suerte, es directa: hay que usar PowerShell para forzar el tipo de medio de esos discos con valor desconocido y etiquetarlos como HDD. Normalmente se filtran los discos pertenecientes al pool que figuran como Unspecified y se les aplica el cambio en bloque mediante una condición WHERE (o su abreviatura ? en PowerShell) para no tocar lo que ya está bien.

Hasta que no hayas corregido esos tipos de medio y actualizado la información del pool, no podrás activar el checkbox de creación de discos con Storage Tiers en el asistente de Server Manager ni tampoco generar tiers coherentes desde scripts automatizados.

Creación de un pool y discos virtuales con la interfaz de Windows Server

En Windows Server 2012 R2 y superiores, el flujo básico para montar un entorno de Storage Spaces con tiering vía interfaz gráfica se puede resumir en una serie de pasos bastante claros, aunque haya detalles avanzados que conviene ajustar a mano.

Primero, desde el Server Manager o Windows Admin Center, se conectan todos los discos que vayas a usar: al menos un SSD y un HDD. En un ejemplo típico de laboratorio puedes encontrar configuraciones con 4 SSD y 9 discos de 1 TB, con algunos de ellos reservados como hot spares. Todos los dispositivos aparecen en el llamado pool Primordial, que es básicamente el conjunto de discos disponibles aún sin asignar a ningún grupo concreto.

Desde ese pool Primordial se lanza el asistente para crear un nuevo Storage Pool, al que se le da un nombre y se seleccionan los discos que formarán parte de él. En ese paso también se pueden marcar ciertos discos como repuestos en caliente, lo que permite que entren en juego automáticamente si otro disco del pool falla.

Tras confirmar la selección, el asistente crea el pool y lo deja listo para empezar a definir discos virtuales por encima. Es crucial, antes de seguir, comprobar en la interfaz o via PowerShell que los SSD figuran como SSD y los HDD como HDD, y que no queda ningún disco con tipo Unknown, porque eso bloqueará la creación de tiers.

Una vez solucionado el tema de los tipos de medios y tras un refresco del Server Manager para que recoja los últimos cambios, ya se puede lanzar el asistente de creación de un nuevo disco virtual sobre ese pool, esta vez marcando la casilla que activa la creación de almacenamiento por niveles SSD/HDD.

Ajuste de columnas, resiliencia y aprovisionamiento

Antes o durante la creación del disco virtual conviene revisar algunos parámetros de diseño del pool y del propio disco virtual, especialmente el número de columnas y la configuración de resiliencia, porque afectan directamente al rendimiento y a la capacidad útil.

Por defecto, los pools de Storage Spaces suelen usar una selección automática del número de columnas, que determina cómo se distribuyen los datos a través de los discos físicos. En un ejemplo práctico, si vas a usar un layout en espejo (mirror) con 4 SSD, puede interesarte fijar manualmente 2 columnas para ese tipo de resiliencia; si creases un volumen simple con los 4 SSD, podrías preferir 4 columnas para repartir mejor la carga.

Este ajuste no se puede cambiar fácilmente después de crear el disco virtual, así que suele ser buena idea modificar las propiedades de resiliencia y columnas del pool mediante PowerShell antes de seguir con el asistente gráfico. De este modo te aseguras de que el layout resultante se adapta a tu escenario, en lugar de depender de una configuración automática genérica.

En el asistente de creación del disco virtual, al habilitar los tiers se te pedirá seleccionar el tipo de layout: simple, mirror o parity. Para cargas habituales de datos con tolerancia a fallos, lo más común en ejemplos de laboratorio y muchas instalaciones es el mirror, a menudo en two-way mirror, que duplica los datos en dos conjuntos de discos.

Un punto clave que no se puede pasar por alto es que, cuando utilizas almacenamiento por niveles, el aprovisionamiento del disco virtual debe ser fijo. No es posible usar thin provisioning con tiers en este contexto. El asistente obliga a seleccionar aprovisionamiento fijo, reservando desde el principio el espacio en el pool de acuerdo con el tamaño y la resiliencia definidos.

Dimensiones de los tiers, espacio utilizable y tareas de optimización

Durante el proceso de creación del disco virtual con niveles, Windows muestra los tamaños máximos que puedes asignar al tier SSD y al tier HDD. Ambos se combinan para formar un único disco virtual, como si fuera una sola unidad vista por el sistema operativo.

En muchos ejemplos se suele optar por asignar el máximo posible en ambas capas: todo el espacio SSD disponible y todo el HDD que se pueda usar respetando las restricciones del layout y del número de columnas. El resultado es que el tamaño final del disco virtual puede ser bastante inferior a la suma bruta de capacidades del pool, especialmente con mirror, porque en realidad se están duplicando datos entre columnas.

Es habitual ver casos con 9 TB de capacidad en discos físicos terminando en unos 3,6 TB de volumen utilizable, precisamente porque el espacio de SSD es menor y porque la configuración en espejo consume aproximadamente el doble de espacio lógico respecto al tamaño final, dejando además discos sobrantes en el pool para otros usos.

Tras terminar el asistente y crear también el volumen y el sistema de archivos sobre el disco virtual (usando todo el espacio disponible del disco virtual, requisito cuando hay tiers), el almacenamiento queda listo para guardar datos. A partir de ahí entran en juego las tareas programadas de Storage Tiers, que se activan automáticamente tras crear el primer volumen con niveles y se encargan de mover los bloques calientes al SSD en base a patrones de acceso.

Si en algún momento quieres forzar este reequilibrio de datos, es posible lanzar manualmente las tareas correspondientes o utilizar herramientas como defrag con opciones específicas sobre el disco virtual tiered, de forma que Windows reorganice los bloques y aproveche mejor la capa rápida.

Creación y automatización con PowerShell en Windows 10 y Server

En Windows 10, y también en algunos escenarios avanzados de servidor, la forma más flexible y directa de trabajar con Storage Spaces y niveles es apoyarse en PowerShell y los cmdlets de almacenamiento. De hecho, en Windows 10 la interfaz gráfica de Storage Spaces ni siquiera muestra nada relativo a tiering, así que no hay otra opción si quieres esta funcionalidad.

Algunos administradores han publicado scripts que detectan automáticamente todos los discos “en bruto” del sistema, crean un pool, corrigen el tipo de medio de los HDD que aparezcan mal etiquetados, generan los tiers SSD/HDD y finalmente definen un disco virtual que agrega todo el espacio a una sola unidad lógica.

Estos scripts suelen asumir configuraciones mínimas como disponer de al menos 1 SSD y 1 HDD para un volumen simple con caché, o escenarios más robustos, por ejemplo 2 SSD y 2 HDD para un tiered mirror, o 1 SSD y 2 HDD para un almacenamiento simple con striping que sume la capacidad de los HDD, acompañados de un nivel rápido para caché de lectura y escritura.

En muchos casos se incluye lógica para permitir dimensionar de forma manual el tamaño del caché SSD y del propio disco virtual, porque el autosizing no siempre funciona bien o no se adapta a lo que necesitas. De esta manera puedes decidir cuántos gigas de SSD quieres dedicar a acelerar tu Storage Space, en función del tipo de cargas que esperas.

También es habitual que estos scripts creen una única gran unidad lógica con todo el espacio disponible del pool, asignándole una letra de unidad y una etiqueta personalizadas, configurables mediante variables al inicio del archivo de script para que sea fácil adaptarlo a cada entorno.

Escenarios de ejemplo: rendimiento, caché y pools híbridos

Un escenario típico documentado con Storage Spaces y tiering parte de dos HDD de 2 TB y un SSD de unos 200 GB. A partir de estos tres discos se puede crear un disco virtual que ofrece, hacia el sistema, una unidad de datos de unos 3,6 TB (un volumen simple o striped) que aprovecha ambos HDD para la capacidad, mientras el SSD actúa como tier rápido con unos 200 GB de caché de lectura y escritura.

En pruebas reales, todo el conjunto de discos se conecta habitualmente a interfaces SATA de 3 Gb/s, lo cual limita algo la velocidad máxima teórica, pero el uso del SSD como nivel caliente sigue marcando una diferencia notable en latencias y IOPS respecto a un conjunto de discos puramente mecánicos sin caché.

Es importante entender que el panel clásico de Storage Spaces en Windows no muestra ni permite manipular los tiers: solo ves el pool, el disco virtual y el volumen, sin detalle de en qué capa está cada cosa. Para ver o cambiar configuración de niveles necesitas sí o sí PowerShell o herramientas de administración más avanzadas.

Otro detalle curioso es cómo se comporta la resiliencia de tipo mirror con tiers: cuando eliges mirror en un entorno con SSD y HDD, Windows intenta aplicar la lógica de espejo a ambos niveles, de manera que para lograr un mirror completo que duplique tanto el tier SSD como el HDD, necesitarás al menos cuatro discos (dos SSD y dos HDD) para tener redundancia efectiva en ambas capas.

También hay que tener en cuenta que ciertas optimizaciones internas, como el write-back cache, no se aplican con la misma intensidad a todos los patrones de IO. Por ejemplo, en algunos casos se documenta que la caché de escritura no se usa para flujos secuenciales superiores a 256 KB, que van prácticamente directos a disco para evitar sobrecargar el SSD con escritura sostenida que no aporta beneficio real.

Uso de Storage Spaces con tiering en entornos virtualizados

En varios debates sobre homelabs y pequeños entornos de producción aparece una duda recurrente: cómo se comporta Storage Spaces con tiering cuando se usa como almacenamiento subyacente para máquinas virtuales, especialmente si hablamos de servidores Hyper-V o clusters gestionados por vCenter.

La clave es entender que, de cara al hipervisor, toda la complejidad de la capa de almacenamiento es transparente. El servidor de virtualización ve simplemente un datastore o un volumen de cierto tamaño, sin importar si por debajo hay RAID tradicional, tiering, cabinas externas, NAS, SAN o lo que sea. Lo único que le interesa es el espacio disponible y, en la práctica, el rendimiento resultante.

Por tanto, si montas un servidor con, por ejemplo, un pool de 1 NVMe de 1 TB y 16 TB en discos SATA, configurado como disco virtual con Storage Spaces y niveles, y sobre ese disco creas un datastore donde guardas VHD o VHDX de tus máquinas, el hypervisor solo ve un almacenamiento de X TB. El tiering se aplica en la capa inferior, gestionado por Windows, sin que ni Hyper-V, ni vCenter ni el propio sistema operativo invitado tengan que saber nada.

Algunos administradores preguntan concretamente si, al repartir el espacio en varios VHD de tamaño intermedio (por ejemplo, tres discos virtuales de 3 TB presentados a una VM de ficheros), Storage Spaces seguirá aprovechando el tiering. La respuesta es que sí: el sistema sigue moviendo bloques calientes a SSD, independientemente de cuántos VHD haya definidos por encima, porque trabaja al nivel de bloques físicos dentro del disco virtual base.

Lo que sí debes plantearte es el rol que va a tener ese servidor con Storage Spaces: si será un simple datastore para el hypervisor o un servidor de ficheros directo. Mezclar ambos usos en una misma instancia no suele ser una buena idea por cuestiones de rendimiento, gestión y backup. Además, algunas soluciones como Veeam B&R pueden condicionar cómo montas la arquitectura de almacenamiento para mantener copias de seguridad consistentes.

Cambios de comportamiento del tiering en Windows Server 2019 y uso de ReFS

A partir de Windows Server 2019, el mecanismo de tiering sufre cambios importantes que conviene tener presentes si vienes de 2012 R2 o 2016. Uno de los puntos más llamativos es que la lógica de escalado de datos entre niveles se invierte en cierta medida: las escrituras iniciales tienden a aterrizar primero en el nivel frío (HDD) y se promueven al nivel caliente (SSD) posteriormente según los patrones de acceso.

Este matiz puede suponer un cambio drástico en los IOPS percibidos tras una actualización de sistema operativo, sobre todo en cargas muy centradas en escritura inicial intensa. Usuarios que migran su Storage Spaces con tiering a 2019 han notado diferencias notables en la sensación de rendimiento precisamente por este nuevo comportamiento.

Otro aspecto crítico es que, en estas versiones más nuevas, el soporte de tiering ya no está disponible para volúmenes NTFS. Si quieres seguir usando almacenamiento por niveles en Windows Server 2019, tienes que utilizar el sistema de archivos ReFS. Esto obliga a repensar el diseño de muchos entornos que durante años habían usado NTFS sin problemas.

El problema es doble: por un lado, no existe una ruta directa de migración in-place de NTFS a ReFS, así que cualquier transición implica crear nuevos volúmenes en ReFS y mover datos, con el consiguiente riesgo y ventana de mantenimiento. Por otro, ReFS ha tenido históricamente ciertos problemas y limitaciones en determinadas versiones, lo cual hace que algunos administradores se lo piensen dos veces antes de lanzarse.

En general, si estás planificando una renovación o migración a Windows Server 2019 y quieres seguir exprimiendo Storage Spaces con niveles, es muy recomendable valorar desde ya la creación de nuevos volúmenes en ReFS, asumir que habrá trabajo de copia de datos y probar bien el comportamiento del sistema de archivos y del tiering en tu propia carga antes de ponerlo en producción.

Buenas prácticas, riesgos y límites de la tecnología

Por muy flexible que sea Storage Spaces, conviene recordar que sigue siendo una tecnología compleja y con ciertas aristas. Un error en un comando de PowerShell lanzado con privilegios elevados puede acabar borrando pools, discos virtuales o volúmenes completos, así que hay que ir con pies de plomo y copias de seguridad verificadas.

Es vital tener claro el inventario de discos físicos, sus capacidades y su rol (SSD frente a HDD, hot spares, etc.) antes de ejecutar scripts que “descubren todos los discos en bruto y los añaden a un pool”. Esta automatización está muy bien en un entorno controlado, pero puede ser peligrosa en servidores con discos que contienen datos de otras funciones.

Del mismo modo, cuando se decide jugar con almacenamiento por niveles para uso doméstico o de laboratorio, hay que asumir que estás utilizando características avanzadas de nivel empresarial fuera de los caminos más documentados y soportados, sobre todo si hablamos de Windows 10 y combinaciones poco usuales. Esto no significa que no funcione, sino que puede haber comportamientos no del todo pulidos o cambios inesperados entre versiones.

Otro punto recurrente es que, aunque la idea de combinar SSD y HDD en un único Storage Space es muy atractiva, no siempre es la solución ideal para todas las cargas. Hay casos en los que un RAID de SSD dedicados para bases de datos críticas, junto a un pool de HDD simple para archivos fríos, resulta más sencillo de gestionar y diagnosticar que un único volumen con tiering complejo.

Storage Spaces con tiering es una pieza muy potente del ecosistema de almacenamiento de Windows que, bien diseñada y entendida, permite montar cabinas híbridas muy capaces con hardware relativamente económico, tanto en entornos de laboratorio como en despliegues más serios. La clave está en dominar PowerShell, respetar las limitaciones de cada versión de Windows y elegir bien cuándo usar esta tecnología y cuándo optar por algo más simple.