Si trabajas con Windows Server y necesitas estirar al máximo tu almacenamiento, seguro que has oído hablar de Storage Spaces, Storage Spaces Direct y del famoso tiering. Son términos que suenan mucho a “buzzword” de marketing, pero detrás hay una tecnología muy potente que, bien configurada, te puede ahorrar una buena pasta en cabinas SAN y darte una flexibilidad brutal.
En las siguientes líneas vamos a ver qué es exactamente Storage Spaces con tiering, cómo encaja en Storage Spaces Direct (S2D), qué piezas intervienen, cómo se amplía un espacio en capas ya creado y qué necesitas tener en cuenta para montar un clúster hiperconvergente de verdad, tanto en laboratorio como en producción. Lo haremos con un tono cercano, pero sin escatimar en detalles técnicos, para que puedas aplicar todo esto en tu entorno sin ir a ciegas.
Qué es Storage Spaces y qué pinta tiene el tiering
En el ecosistema de Windows Server, Storage Spaces es la capa de almacenamiento definido por software que permite agrupar discos físicos (SATA, SAS, SSD, NVMe…) en un “pool” o grupo de almacenamiento, sobre el que luego se crean discos virtuales (virtual disks) con distintos niveles de resiliencia (simple, mirror, parity).
El concepto de tiering o niveles de almacenamiento entra en juego cuando combinamos discos de distinto rendimiento dentro de ese pool: por ejemplo, SSD o NVMe para el nivel rápido y HDD tradicionales para el nivel de capacidad. Storage Spaces es capaz de mover de forma automática los datos “calientes” (muy accedidos) al tier rápido y dejar los datos “fríos” en el tier más lento y barato.
En un escenario típico, tendrías un tier de rendimiento basado en SSD/NVMe y un tier de capacidad en HDD. Windows gestiona internamente la colocación de bloques y su migración entre tiers, de forma similar a lo que hacen soluciones de cabinas SAN comerciales, pero usando servidores estándar x86 con discos locales.
Este mismo enfoque de niveles se ve también en otros fabricantes y nubes públicas, donde se ofrecen clases de almacenamiento con diferentes costes y tiempos de acceso, y se automatiza la transición según el patrón de uso. El objetivo en todos los casos es el mismo: tener todo disponible sin tener que pagar el precio del almacenamiento más caro para todos los datos.
Storage Spaces Direct (S2D): la base de la hiperconvergencia en Windows
Storage Spaces Direct, o S2D para los amigos, es la evolución de Storage Spaces tradicional que apareció inicialmente en Windows Server 2012 R2. Con S2D, Microsoft lleva al extremo el concepto de almacenamiento definido por software: en lugar de depender de una cabina SAN externa, los propios servidores del clúster aportan sus discos locales, que se agregan en un solo pool distribuido.
Esta tecnología forma parte del núcleo de Azure Stack HCI y de las ediciones Datacenter de Windows Server (2016, 2019, 2022 y posteriores, incluyendo la Azure Edition). No hay que instalar componentes raros: viene integrada en el sistema operativo, y se habilita sobre la base del clúster de conmutación por error de toda la vida.
Con S2D puedes construir dos grandes modelos de despliegue: el escenario hiperconvergente clásico, en el que los mismos nodos proporcionan cómputo (máquinas virtuales Hyper-V) y almacenamiento, y el escenario convergente o desagregado, con un clúster dedicado únicamente al almacenamiento y otro al cómputo que accede vía SOFS (Scale-Out File Server).
En entornos productivos, Microsoft recomienda usar hardware validado para S2D o plataformas Azure Stack HCI, con al menos tres nodos si quieres poder perder uno sin interrupción del servicio, y discos adecuados (SAS, SSD, NVMe…) en cada servidor. Para laboratorio puedes apañarte con menos, incluso con SATA y configuraciones más “creativas”, pero eso ya es otra película y no está soportado en producción.
Componentes clave de Storage Spaces Direct y del tiering
Para entender cómo se conjugan Storage Spaces, S2D y el tiering, conviene repasar las piezas técnicas que hay por debajo de la interfaz gráfica o de los asistentes.
En primer lugar, necesitamos hardware compatible y suficiente cantidad de discos: servidores x86 certificados, cada uno con varias unidades locales que pueden mezclar NVMe, SSD y HDD. Esta mezcla es lo que nos permite crear distintos tiers dentro del mismo pool, por ejemplo, un tier rápido todo-flash y un tier de capacidad con discos mecánicos.
La red es otro pilar fundamental, porque el bus de almacenamiento definido por software (Software Storage Bus) hace que todos los nodos del clúster vean los discos locales de todos los demás como si estuvieran en un chasis común. Para que esto vaya fino, es muy recomendable usar redes rápidas con RDMA (RoCE o iWARP) sobre 10 GbE o superior, especialmente en clústeres de producción con muchas IOPS.
Encima de ese bus, se construye un único Storage Pool que agrupa toda la capacidad disponible. Desde ese pool se crean los discos virtuales o Storage Spaces, en los que se configura el tipo de resiliencia (simple, mirror, parity) y la política de tiering, indicando qué parte se apoya en SSD/NVMe y qué parte en HDD.
Sobre esos discos virtuales, lo normal es usar ReFS (Resilient File System) como sistema de archivos recomendado, sobre todo para cargas de trabajo de virtualización con Hyper-V o almacenamiento de VHDX. ReFS ofrece autointegridad, detección y reparación acelerada de corrupción, y optimizaciones para clonado rápido de bloques, muy útiles en escenarios de muchas máquinas virtuales.
Modelos de implementación: hiperconvergente y convergente
Dentro de la familia S2D, el modelo más popular hoy en día es el despliegue hiperconvergente (HCI). En este enfoque, los mismos servidores del clúster alojan las máquinas virtuales Hyper-V y al mismo tiempo aportan su almacenamiento al pool S2D. Es una configuración muy atractiva para muchas empresas porque reduce complejidad y costes al no necesitar una cabina SAN separada.
La otra opción es el enfoque convergente o desagregado. Aquí se separan los roles: un clúster se dedica exclusivamente al almacenamiento S2D y expone volúmenes a través de un Scale-Out File Server (SOFS) usando SMB3, mientras que otro clúster independiente se encarga del cómputo y consume ese almacenamiento remoto.
En ambos modelos, el tiering sigue jugando el mismo papel: colocar de manera inteligente los datos activos en los medios de mayor rendimiento y mover al nivel económico aquello que no se accede frecuentemente. Esta filosofía también la vemos reflejada en servicios de nube como Amazon S3 Intelligent-Tiering, donde los objetos accedidos con frecuencia permanecen en una clase “Standard” y los que apenas se usan pasan a clases de acceso infrecuente o archivo para reducir el coste.
Un beneficio claro del enfoque convergente es que puedes escalar cómputo y almacenamiento de forma independiente, añadiendo nodos de S2D si necesitas más capacidad o ancho de banda de almacenamiento, o nodos de Hyper-V si te faltan recursos de CPU y RAM, sin tener que crecer todo a la vez.
En cualquier caso, tanto en modelo hiperconvergente como convergente, el clúster de conmutación por error de Windows Server es la base que aporta alta disponibilidad y gestión coordinada de recursos, roles de clúster, volúmenes compartidos y migraciones en vivo de máquinas virtuales.
Cómo configurar un clúster S2D con Storage Spaces y tiering
Montar un clúster con Storage Spaces Direct y activar el tiering puede parecer un lío al principio, pero el flujo general de trabajo sigue una serie de pasos bastante lógicos que conviene tener claros antes de empezar.
Lo primero es preparar los nodos con Windows Server Datacenter (en la versión soportada que vayas a usar), instalando Hyper-V si vas a alojar máquinas virtuales, y añadiendo la característica de clúster de conmutación por error. El clúster se crea siguiendo el asistente estándar de Failover Cluster Manager, validando hardware, redes y discos.
Una vez formado el clúster, verificas en Administrador de discos que cada nodo ve sus discos de datos como unidades independientes (idealmente JBOD o RAID-0 uno a uno para que S2D tenga visibilidad directa). Los discos que se van a dedicar al pool no deben tener volúmenes ni particiones creadas; simplemente quedan “en bruto” disponibles para que S2D los gestione.
A nivel de red, se configura al menos una red para tráfico de cliente y otra para el tráfico interno de clúster (latidos, replicación de datos, etc.). En entornos productivos suele haber más redes segmentadas para distintos tipos de tráfico, pero en laboratorio normalmente se simplifica mucho.
Con el clúster operativo y los discos listos, llega el momento de habilitar Storage Spaces Direct mediante PowerShell. Desde una consola con privilegios de administrador puedes lanzar un comando como:
Enable-ClusterS2D -PoolFriendlyName S2D Inicia la habilitación automatizada del pool de almacenamiento
Este cmdlet analiza los discos elegibles, crea el Storage Pool y configura la infraestructura de S2D. En laboratorios con discos que no cumplen todos los requisitos (por ejemplo, SATA en lugar de SSD certificados) se puede usar el parámetro -SkipEligibilityChecks para saltarse algunas comprobaciones, aunque esto, insistimos, no es algo soportado en producción.
Creación del pool, discos virtuales y volumen con ReFS
Después de habilitar S2D, si vuelves al Failover Cluster Manager y te vas a Almacenamiento > Pools, verás un nuevo pool que agrupa los discos de datos de todos los nodos. Ese es el corazón de tu almacenamiento definido por software.
El siguiente paso es crear un disco virtual (virtual disk) dentro del pool. Desde las acciones del pool eliges “Nuevo Disco Virtual” y sigues el asistente indicando el nombre y si quieres aprovechar tiering entre distintos tipos de disco. Si tu pool mezcla SSD y HDD, ahí es donde puedes marcar la casilla para habilitar el tiering de datos.
El asistente también te preguntará por la resiliencia que tendrá el disco virtual. Para entornos serios lo habitual es usar mirror (equivalente a RAID-1) o mirror de tres vías, que permite la caída simultánea de dos discos. Parity (similar a RAID-5) es una opción válida para ciertos escenarios de archivo, pero tiene más penalización de escritura.
Una vez escogido el tipo de resiliencia y definido el tamaño del disco virtual, el asistente puede encadenar la creación del volumen directamente encima. Es muy práctico dejar marcada esa opción para que, nada más crear el disco virtual, se formatee con el sistema de archivos adecuado, normalmente ReFS si piensas alojar máquinas virtuales, o NTFS si tienes otras necesidades específicas.
Durante este proceso también decides si asignas una letra de unidad o dejas el volumen sin letra. En entornos de clúster con volúmenes compartidos para Hyper-V es muy común no usar letras y trabajar con rutas en C:\ClusterStorage\, de forma que todos los nodos vean el mismo volumen como recurso compartido.
Conversion a volumen compartido de clúster (CSV) y uso con Hyper-V
Una vez creado el volumen sobre tu disco virtual, queda un paso esencial para sacarle partido en el clúster: convertirlo en Cluster Shared Volume (CSV). Desde el Failover Cluster Manager, en la sección de discos disponibles, seleccionas el volumen y eliges la opción “Añadir a Volumen de Clúster Compartido”.
Al hacerlo, el clúster monta el volumen bajo la ruta C:\ClusterStorage\VolumeX en todos los nodos, permitiendo que cualquiera de ellos acceda de forma simultánea al almacenamiento. Es justo esto lo que hace posible la migración en vivo de máquinas virtuales sin cortes, ya que el disco de la VM permanece disponible para todos los hosts a la vez.
Si abres el explorador de archivos en cada nodo, verás que aparece la carpeta ClusterStorage en la raíz de C:, con el volumen compartido dentro. Es ahí donde se suelen crear las carpetas para las máquinas virtuales (VHDX, configuración, checkpoints) y, por ejemplo, folders con ISOs que quieras utilizar desde cualquier nodo.
Desde el Administrador de Hyper-V puedes crear una nueva máquina virtual alojando sus archivos directamente en el CSV. Después, esa VM se puede añadir como recurso de clúster y moverse entre nodos utilizando Live Migration, comprobando que sigue funcionando mientras cambia de host físico.
Un detalle práctico en algunos laboratorios con “nested virtualization” es que para que una máquina virtual dentro de otra VM tenga acceso de red, hay que activar el MAC Address Spoofing. Es un clásico olvido que obliga a apagar nodos y ajustar la configuración, así que conviene tenerlo presente para no perder tiempo.
Caso concreto: ampliar un Storage Space con tiering en un servidor
Además de montar clústeres, hay un escenario muy habitual: tienes un espacio de almacenamiento en un servidor independiente con tiering configurado y necesitas ampliarlo porque la capacidad actual se ha quedado corta. Windows Server permite hacerlo de forma bastante directa utilizando PowerShell y algunos pasos bien definidos.
Imagina un espacio en capas de unos 12 TB ya creado, con tier SSD y HDD. El proceso general para ampliarlo sería el siguiente: primero añades discos físicos nuevos al conjunto de almacenamiento (por ejemplo, más HDD para el tier de capacidad) y te aseguras de que el sistema los ve correctamente.
Después, desde PowerShell, ejecutas un Get-PhysicalDisk | FL * para listar todos los discos y localizar el uniqueId del nuevo disco que acabas de incorporar. Ese identificador será el que uses para ajustar el tipo de medio, algo fundamental si el disco no es detectado automáticamente como HDD o SSD.
Con el uniqueId en la mano, lanzas un comando del estilo Set-PhysicalDisk -UniqueId <ID> -MediaType HDD para actualizar el tipo de medio del nuevo disco. Tras esto, conviene refrescar el Administrador del servidor o la consola de administración de almacenamiento para verificar que el disco aparece con el tipo correcto.
Una vez ajustado el tipo, ya puedes redimensionar el tier correspondiente usando el cmdlet Resize-StorageTier. Por ejemplo, algo como Resize-StorageTier -FriendlyName Vdisk01_Microsoft_HDD_Template -Size 16.1TB permitiría ampliar el tamaño asignado al tier de HDD dentro de ese disco virtual en capas.
El último paso es ir a Administración de discos y extender el volumen que se apoya en ese disco virtual, de forma que el sistema operativo aproveche la nueva capacidad disponible. A partir de ese momento, tendrás más espacio útil manteniendo el comportamiento de tiering entre SSD y HDD sin tener que recrear el Storage Space desde cero.
Consideraciones sobre columnas, número de discos y diseño del tier
Una duda frecuente cuando se trabaja con Storage Spaces en configuraciones algo más avanzadas es cómo se relacionan las columnas con el número de discos físicos necesarios, sobre todo cuando se quieren usar SSD como tier de rendimiento junto a HDD en un chasis con muchos discos.
Las columnas determinan cómo se distribuyen los datos en paralelo entre los discos físicos, algo que influencia tanto el rendimiento como la tolerancia a fallos y el número mínimo de unidades necesarias. Si defines, por ejemplo, un Storage Space con tres columnas, eso implica que los datos se “stripean” sobre tres discos por cada copia de datos (según el tipo de resiliencia).
Cuando introduces un tier SSD por encima de un conjunto de HDD, la lógica es similar: si el diseño del disco virtual usa tres columnas, lo habitual es que necesites que el tier de SSD también disponga de suficientes unidades para mantener esa estructura. Trabajar con un único SSD como tier suele ser una mala idea, porque elimina paralelismo, complica la resiliencia y se convierte en punto único de fallo.
Aunque en laboratorio se pueden hacer concesiones (pocos discos, mezclas extrañas, etc.), en entornos reales conviene respetar las recomendaciones de Microsoft respecto a número mínimo de discos por tipo de medio, número de columnas adecuado al tamaño del pool y niveles de resiliencia, de modo que el tiering pueda funcionar de forma equilibrada.
El diseño correcto del tier influye directamente en el rendimiento percibido por las aplicaciones, la eficiencia del uso de SSD (para que no se convierta en un cuello de botella) y la capacidad efectiva que obtendrás tras aplicar mirror o parity. Un mal dimensionamiento puede dar lugar a sorpresas desagradables cuando quieras crecer o cuando falle un disco.
Paralelismos con el tiering en la nube y gestión del ciclo de vida
Más allá de Windows Server, merece la pena mirar cómo otros proveedores abordan el tiering, porque los principios son los mismos y ayuda a entender la filosofía general. Un ejemplo claro es Amazon S3 Intelligent-Tiering combinado con S3 Glacier, donde el sistema clasifica automáticamente los objetos según su patrón de acceso.
En un caso real de uso, una plataforma de streaming europea migró más de 3 PB de contenido audiovisual a Amazon S3 usando dispositivos Snowball, y hoy mantiene todo su archivo en línea gracias a Intelligent-Tiering. El contenido con mucha demanda se queda en el tier de acceso frecuente, mientras que las series y películas menos vistas pasan a niveles de acceso poco frecuente o de archivo, manteniendo el coste total bajo control.
De forma similar, en entornos on-premise con soluciones como ONTAP, se pueden definir políticas de ciclo de vida para mover datos entre distintas clases de almacenamiento, comenzando en una clase estándar y, tras X días de inactividad, pasando a clases más baratas. Además, algunos sistemas permiten hasta crear espejos en otros almacenes de objetos y alternar cuál es el destino principal o el espejo.
El mensaje de fondo es que el tiering ya no es solo una característica de hardware local, sino una estrategia global de gestión de datos, tanto en la nube como en el CPD. Storage Spaces con tiering en Windows encaja perfectamente en esta filosofía, permitiendo que, sin salir del ecosistema Microsoft, puedas jugar con diferentes niveles de rendimiento y coste.
En todos estos contextos, lo que realmente ahorras es tiempo de gestión y quebraderos de cabeza; no tienes que estar constantemente pensando qué borrar, qué método de copia usar o qué mover manualmente, porque el sistema aprende del patrón de acceso y recoloca los datos donde toque para optimizar gasto y rendimiento.
Si juntamos todo lo que hemos visto, se aprecia que Storage Spaces con tiering y Storage Spaces Direct forman un bloque muy potente para construir infraestructuras modernas, tanto on-premise como en escenarios híbridos. Partiendo de servidores estándar, puedes obtener un comportamiento muy similar al de cabinas SAN avanzadas, con alta disponibilidad, gran rendimiento, escalabilidad horizontal y automatización en la gestión de datos calientes y fríos. Planificando bien el hardware, las redes y el diseño de pools y tiers, se convierte en una pieza clave para clústeres Hyper-V, file servers escalares o incluso despliegues HCI integrados con la nube, sin tener que depender de soluciones propietarias mucho más caras.
