Si necesitas que tu servidor o tu PC vaya rápido pero también almacenar montones de datos, la típica duda es clara: ¿me quedo con la velocidad del SSD o con los teras baratos de los discos mecánicos? En el ecosistema de Windows Server la respuesta es bastante más interesante, porque no tienes por qué elegir: puedes mezclar ambos mundos usando Storage Spaces y los niveles de almacenamiento (storage tiers).
Windows Server 2012 R2 introdujo una funcionalidad muy potente que ha ido evolucionando con las versiones posteriores, y que permite construir volúmenes híbridos donde las partes más calientes de los datos viven en SSD mientras que la masa de información se aparca en HDD tradicionales. Todo esto gestionado de forma automática por el sistema, sin que tengas que ir moviendo archivos a mano salvo que quieras afinar el comportamiento.
Qué son Storage Spaces y los niveles de almacenamiento (storage tiers)
Storage Spaces es la capa de almacenamiento definido por software de Windows Server. Permite agrupar discos físicos (SATA, SAS, NVMe, incluso algunos iSCSI o FC) en uno o varios grupos de almacenamiento (storage pools). Desde esos grupos se crean discos virtuales sobre los que el sistema ve volúmenes normales, pero en realidad estás trabajando sobre una capa de virtualización que te da resiliencia, flexibilidad y, en nuestro caso, tiering.
Los niveles de almacenamiento o storage tiers añaden inteligencia encima de esos pools. Un tier es básicamente un subconjunto de capacidad asociada a un tipo de medio: un tier rápido en SSD/NVMe y un tier de capacidad en HDD. El sistema analiza periódicamente qué bloques se usan más y los desplaza a la capa rápida, relegando al HDD lo poco accedido. Es similar a lo que hace un sistema híbrido automático, pero controlado desde el propio Windows Server y totalmente configurable.
La clave es que el tiering opera a nivel de bloque, no de archivo. Esto significa que no se limita a mover ficheros enteros entre SSD y HDD, sino que trabaja con fragmentos de datos. Un mismo archivo puede tener sus porciones más usadas residente en SSD y el resto durmiendo en HDD, lo que maximiza el aprovechamiento de cada giga de la parte rápida.
En la práctica, consigues lo mejor de los dos mundos: la experiencia de velocidad que asociamos a un SSD para la mayoría de accesos, con el coste por TB de un conjunto grande de discos mecánicos, sin necesidad de invertir en una cabina SAN de alta gama.
Tipos de discos, sectores físicos y lógicos: por qué importan en Storage Spaces
Antes de lanzarte a crear pools y discos virtuales conviene entender cómo trabajan los sectores de los discos. Durante años los HDD usaban sectores físicos y lógicos de 512 bytes, algo con lo que muchos sistemas operativos se diseñaron. Con el salto a capacidades de varios teras, los fabricantes pasaron a discos con sector físico de 4096 bytes.
Ahí entran en juego tres familias de discos muy habituales: los de sector 512 clásico, los 512e (512 emulado) y los 4Kn (4K nativo). En los 512e, el disco físicamente graba en bloques de 4 KB, pero la controladora admite peticiones de 512 bytes y se encarga de agruparlas. En los 4Kn, es el propio sistema operativo quien tiene que hablar en bloques de 4 KB, gestionando la compatibilidad hacia arriba con aplicaciones antiguas.
En escenarios de Storage Spaces y tiering esto es relevante porque el tamaño de sector lógico del pool debe ser coherente. Regla práctica: si todos los discos son 4K nativo, puedes crear el pool con sector lógico de 4096; si en la mezcla hay algún 512 o 512e, lo prudente es definir el pool con sector lógico de 512 bytes. Así evitas penalizaciones de rendimiento por desalineaciones y reescrituras internas constantes.
Windows Server ofrece GUI para manejar Storage Spaces, pero no todo se puede hacer desde el asistente. En particular, el tamaño de sector lógico del pool solo se puede definir mediante PowerShell, con cmdlets como New-StoragePool especificando -LogicalSectorSizeDefault. Quien quiera sacar el máximo rendimiento de sus tiers debería tomarse un rato para revisar este punto antes de clicar Siguiente como un poseso.
Crear un Storage Pool híbrido con SSD y HDD
El primer paso práctico es reunir los discos que formarán parte del Storage Pool. En laboratorios suele hacerse con máquinas virtuales (por ejemplo, dos discos virtuales que simulan SSD de 256 GB y dos HDD de 1 TB), pero la lógica es la misma en hardware real: discos SATA/SAS/NVMe conectados al servidor, inicializados y listos.
Desde el Administrador del Servidor, en la sección de Servicios de archivos y almacenamiento, accedes a Grupos de almacenamiento. Ahí verás el grupo primordial con los discos disponibles para agrupar. El asistente de “Nuevo grupo de almacenamiento” te permite asignar un nombre al pool, seleccionar los discos que lo integrarán y, básicamente, empaquetar toda la capacidad en un solo recurso lógico.
Una vez creado el pool, todos los discos aparecen como parte de ese conjunto, pero es posible que Windows no tenga claro qué medio es SSD y cuál es HDD. En entornos virtuales, de hecho, lo habitual es que salgan todos como “Unknown” o incluso todos como SSD. Para poder configurar correctamente los tiers hay que etiquetarlos.
PowerShell es la herramienta perfecta para corregir el tipo de medio. Con el cmdlet Set-PhysicalDisk -MediaType puedes marcar manualmente qué discos deben considerarse SSD y cuáles HDD, bien por nombre amigable (FriendlyName) o por UniqueId. Tras un refresco en el Administrador del Servidor, verás que el campo “Tipo de medio” por fin distingue entre ambos.
En despliegues más avanzados, conviene también deshabilitar la caché de escritura del pool si pretendes usar tiering a nivel de volumen y no quieres que haya otra capa de caché que interfiera. De nuevo, PowerShell te deja hacerlo con Set-StoragePool -WriteCacheSizeDefault 0, asegurando que el comportamiento del tiering será el esperado.
Discos virtuales con niveles de almacenamiento: simple, espejo y paridad
Con el pool listo, el siguiente paso es crear un disco virtual que aproveche los tiers. Desde el propio Administrador del Servidor puedes lanzar el asistente de “Nuevo disco virtual” sobre ese pool, asignar un nombre y, muy importante, activar la casilla de “Crear niveles de almacenamiento en este disco virtual”. Esa es la opción que habilita el carácter híbrido SSD+HDD.
El diseño (layout) del disco virtual determina la resiliencia. Tienes tres grandes opciones: Simple (similar a RAID 0, mayor rendimiento pero sin tolerancia a fallos), Mirror (espejo a dos o tres vías, equivalente a RAID 1/10) y Parity (paridad, parecido a RAID 5/6). Hay una limitación importante: si activas storage tiers en ese disco virtual, la opción de Parity desaparece, quedando solo Simple o Mirror.
Para laboratorios y pruebas rápidas, un diseño Simple combinado con tiers ya ofrece un buen vistazo al comportamiento del sistema. Pero en producción, lo normal es usar Mirror con al menos dos SSD y dos HDD, de forma que puedas perder una unidad de cada tipo sin quedarte sin datos. Eso sí, la capacidad útil será menor debido a la redundancia.
Otro detalle crítico es el aprovisionamiento. Los discos tiered deben crearse con aprovisionamiento fijo (Fixed); el thin provisioning no está soportado cuando hay niveles de almacenamiento activos. Esto tiene lógica: el mecanismo de mover bloques entre tiers necesita tener mapeadas de forma estable las direcciones lógicas y físicas, sin capas dinámicas por medio que cambien los tamaños sobre la marcha.
El asistente también te permite definir cuánto espacio tomar de cada tier. Por ejemplo, puedes crear un disco virtual de 100 GB compuesto por 10 GB de SSD y 90 GB de HDD. Internamente el sistema sabe que esos 10 GB son la parte rápida y concentrará ahí los bloques calientes, mientras que el HDD actúa como almacén masivo más barato. Nada te impide ampliar el tamaño de uno u otro tier más adelante, si el recuento de columnas y de discos lo permite.
Creación de volúmenes, sistemas de archivos y verificación de la configuración
Una vez creado el disco virtual, lo normal es continuar con el asistente para generar un volumen. Es conceptualmente lo mismo que particionar un disco físico: eliges qué porción de la capacidad usar (puede ser todo o una parte), seleccionas letra de unidad o punto de montaje y eliges el sistema de archivos, típicamente NTFS o ReFS según el escenario.
En entornos de virtualización y backup moderno, Microsoft recomienda ReFS, especialmente cuando combinas este tipo de volúmenes con tecnologías como Modern Backup Storage de System Center Data Protection Manager (DPM). ReFS está optimizado para clonación de bloques, detección y reparación acelerada de corrupción y manejo eficiente de archivos VHDX, lo que encaja muy bien con pools tiered y volúmenes grandes.
Volúmenes destinados a datos generales, ficheros compartidos o aplicaciones tradicionales pueden seguir usando NTFS sin problemas. Lo importante es ser coherente: si vas a usar DPM 2016 o superior con MBS, tu mejor apuesta es ofrecerle volúmenes ReFS sobre Storage Spaces, preferiblemente con un porcentaje de SSD como tier rápido.
Una vez montado el volumen, es buena idea revisar sus propiedades tanto en el Administrador del Servidor como en Administración de discos. Verás que el tamaño lógico anunciado coincide con el definido en el disco virtual, pero si miras el pool comprobarás que se ha consumido más capacidad bruta debido a la resiliencia (mirroring) y a las reservas internas necesarias para el tiering.
En escenarios de laboratorio también es interesante crear un segundo disco virtual sin tiers sobre el mismo pool, para ver claramente qué opciones desaparecen cuando activas los niveles de almacenamiento: Parity se vuelve disponible, el aprovisionamiento thin se habilita, etc. Esta comparación te ayuda a interiorizar las diferencias arquitectónicas entre volúmenes tiered y no tiered.
Cómo se mueven realmente los datos entre SSD y HDD
El funcionamiento interno del tiering en Storage Spaces se basa en análisis periódicos de acceso. El sistema monitoriza qué bloques se leen y escriben con más frecuencia y, en ciclos programados, reorganiza silenciosamente la distribución, subiendo los bloques calientes al tier SSD y bajando los fríos al HDD. Esto no es algo inmediato ni instantáneo al copiar un archivo grande, sino un proceso de optimización continuo.
Muchos administradores se sorprenden al probar con un archivo de gran tamaño y ver que el SSD no se llena al instante. Al escribir, primero entran en juego las cachés de los propios HDD (sus buffers internos) y, dependiendo de la configuración, también caches adicionales como Storage Bus Cache o mecanismos de journal. El nivel SSD no siempre actúa como una caché de escritura directa al estilo de un acelerador RAID.
Lo que sí debería ocurrir es que, tras cierto tiempo y análisis de uso, los bloques de ese archivo que se consulten con frecuencia migren al SSD. Si las pruebas de lectura muestran que el SSD apenas tiene actividad, hay que plantearse si el acceso es suficientemente repetitivo como para marcar esos bloques como calientes, o si la distribución de carga no está forzando el comportamiento que esperas.
En algunos casos también influye el tamaño relativo del tier SSD frente al HDD. Si el SSD representa un porcentaje irrisorio de la capacidad total, el algoritmo tendrá que priorizar muy agresivamente qué se considera caliente, y puede ser que tu prueba concreta no sea representativa. Un tamaño típico recomendado para escenarios de backup con DPM, por ejemplo, es destinar alrededor de un 4 % del total a SSD para metadatos y bloques críticos.
Además del tiering automático, Windows permite fijar manualmente archivos concretos en el SSD. Con PowerShell y comandos como los de File Storage Tiers puedes marcar un fichero ISO o una base de datos para que permanezcan anclados en la capa rápida; también puedes revertir esa decisión posteriormente con cmdlets complementarios, devolviendo el control al sistema.
Storage Spaces Direct (S2D) y almacenamiento definido por software en clúster
Cuando pasamos de un solo servidor a un clúster completo, entra en escena Storage Spaces Direct (S2D). Esta tecnología, presente en Windows Server Datacenter y en Azure Stack HCI, extiende la idea de Storage Spaces a un conjunto de nodos, creando un bus de almacenamiento de software que hace que todos los discos locales de todos los servidores parezcan un chasis compartido.
En S2D se combinan varias piezas clave: hardware validado (servidores x86 con discos NVMe, SSD y HDD), una red rápida RDMA (RoCE o iWARP a 10 GbE o más), el clúster de conmutación por error como base de alta disponibilidad y el propio software storage bus. Encima de todo ello se definen pools, discos virtuales, resiliencia (mirror, paridad) y, por supuesto, niveles de almacenamiento y caché.
El modelo hiperconvergente (HCI) es probablemente el más popular: las máquinas virtuales de Hyper-V y el almacenamiento S2D comparten los mismos nodos, simplificando la infraestructura y reduciendo costes frente a una SAN tradicional. También existe el modelo convergente, donde el clúster de almacenamiento es independiente y se expone al clúster de cómputo vía Scale-Out File Server y SMB3.
S2D automatiza gran parte del trabajo de reequilibrado y cacheo. Cuando añades nuevos discos o incluso nuevos nodos, el pool se redistribuye solo. Los medios más rápidos disponibles se usan como caché siempre activa, mejorando considerablemente el rendimiento de cargas de trabajo como máquinas virtuales o bases de datos SQL Server.
Aunque la teoría es muy atractiva, S2D exige una planificación cuidadosa: hardware del catálogo validado, red bien diseñada, comprensión de los modos de resiliencia (dos o tres vías de mirroring, paridad, erasure coding), y sobre todo una buena estrategia de monitorización y gestión diaria. Herramientas como el Administrador de clústeres, PowerShell y soluciones de terceros son fundamentales para no ir a ciegas.
Modern Backup Storage (MBS) en DPM y uso de volúmenes en capas
System Center Data Protection Manager (DPM) 2016 introdujo Modern Backup Storage (MBS) para reducir en torno a un 50 % el consumo de espacio, acelerar hasta tres veces las copias de seguridad en disco y gestionar mejor las cargas de trabajo. MBS se apoya fuertemente en ReFS, la clonación de bloques y, cómo no, en Storage Spaces.
La idea es sencilla: en lugar de usar dos volúmenes por origen de datos (uno inicial y otro para diferenciales), MBS consolida y aprovecha las capacidades avanzadas del sistema de archivos. Los volúmenes que DPM usa para su almacenamiento se formatean automáticamente en ReFS, siempre que hayan sido presentados sobre discos básicos (nada de discos dinámicos) y, preferiblemente, sobre Storage Spaces.
Con DPM 2019 y posteriores, se da un paso más al soportar volúmenes en capas como almacenamiento nativo. Esto significa que el propio volumen donde DPM guarda los backups puede estar respaldado por un tier SSD y otro HDD. El resultado práctico es una mejora adicional de entre un 50 y un 70 % en el tiempo de ejecución de ciertas copias de seguridad, al tener los metadatos y bloques críticos en la capa rápida.
La recomendación de Microsoft es reservar aproximadamente un 4 % de la capacidad total como SSD para este escenario, dejando que ReFS utilice esa porción como ubicación prioritaria para sus metadatos. Desde el punto de vista de DPM, no hace falta configuración adicional: solamente se ve un volumen ReFS y lo consume según lo previsto.
La configuración de MBS con almacenamiento en capas sigue un flujo bastante claro: preparar los discos físicos, crear el Storage Pool con sector lógico adecuado (normalmente 4K si todos los discos lo soportan), establecer correctamente los MediaType (SSD/HDD), desactivar la caché de escritura a nivel de pool, definir los tiers (uno de rendimiento, otro de capacidad) y crear un volumen ReFS combinando ambos niveles. Ese volumen se expone luego a DPM, que lo integra como almacenamiento de disco.
DPM ofrece cmdlets PowerShell para afinar aún más la gestión: Update-DPMDiskStorage para asignar nombres y etiquetar volúmenes según tipo de origen de datos, exclusión de volúmenes con Set-DPMGlobalProperty para evitar errores humanos al añadir almacenamiento, e incluso opciones de migración de datos entre volúmenes cuando renuevas cabinas o amplías capacidad.
Configuraciones soportadas, resiliencia y tamaño de columnas en Storage Spaces
Windows Storage Spaces admite distintas topologías de conexión y niveles de resiliencia. Puedes usar discos SAS, SATA, e incluso LUNs iSCSI o de canal de fibra en ciertos casos, aunque con limitaciones (por ejemplo, con iSCSI/FC solo se soportan discos virtuales simples en determinadas configuraciones).
En cuanto a resiliencia, tienes tres grandes modalidades: Simple (sin redundancia, máximo rendimiento y capacidad), Mirror (dos o tres copias de los datos, excelente rendimiento y buena tolerancia a fallos) y Parity (equilibrio entre capacidad y protección, con cierto coste en rendimiento de escritura). Cada una tiene un número mínimo de discos físicos requerido y particularidades sobre lo que se admite o no en SAN.
El concepto de tamaño de columna es otro factor importante a la hora de diseñar pools escalables. La columna define cómo se distribuyen los datos entre discos físicos y cuántas unidades se deben añadir de golpe cuando quieras ampliar un disco virtual. Un número de columnas más alto (hasta 8) suele dar mejor rendimiento, pero te fuerza a crecer en múltiplos de ese valor.
Por defecto, al crear discos virtuales o volúmenes, el sistema decide el número de columnas según los discos disponibles. Si quieres controlar este parámetro, puedes usar cmdlets como Set-ResiliencySetting para ajustar el número de columnas por defecto de Mirror o Parity dentro de un pool concreto, adaptándolo a tus necesidades de rendimiento y de crecimiento futuro.
A la hora de mezclar resiliencia con tiering, también hay matices. Por ejemplo, puedes crear un nivel SSD configurado en Mirror y un nivel HDD configurado en Parity, combinándolos en un único volumen tiered resiliente. Así, la parte crítica y más activa de los datos goza del mejor rendimiento y redundancia, mientras que la masa de información fría se beneficia de la eficiencia de la paridad.
Buenas prácticas, problemas habituales y trucos de laboratorio
En entornos de laboratorio es muy común “engañar” al sistema para probar configuraciones sin hardware SSD real. Virtualizadores como VMware Workstation o Hyper-V permiten crear discos virtuales que Windows ve como SAS genéricos, y con PowerShell puedes marcar algunos como SSD y otros como HDD. De este modo simulas un entorno híbrido sin tirar de cartera.
Un truco recurrente es usar scripts para reasignar el MediaType de discos concretos, como por ejemplo: listar los discos de un pool con Get-PhysicalDisk, localizar el FriendlyName o UniqueId de cada uno y aplicar Set-PhysicalDisk para etiquetar. Tras ello, el asistente de nuevo disco virtual ya te mostrará correctamente las opciones de almacenamiento por niveles.
En la parte menos amable, muchos administradores se topan con situaciones donde el tier SSD parece no hacer nada. Copias de archivos grandes que saturan el HDD, gráficas de rendimiento donde los SSD apenas registran actividad y, en general, una sensación de que el sistema ignora por completo la capa rápida. En estos casos conviene revisar varios puntos: tamaño del tier SSD, tipo de carga (accesos repetitivos o no), si hay cachés adicionales activas y si el ciclo de optimización del tiering ha tenido tiempo de actuar.
Otro foco de frustración suele ser Storage Bus Cache, una funcionalidad que puede mejorar dramáticamente el rendimiento de ciertos escenarios pero que a veces falla al habilitarse, mostrando errores de recursos insuficientes. En ocasiones el script que la activa intenta usar el máximo espacio posible y se topa con limitaciones por rondas de tamaño, similares a los errores que aparecen al seleccionar “Usar espacio máximo” al crear un disco virtual desde la GUI.
Si te encuentras con estos mensajes crípticos, una estrategia útil es reducir ligeramente el tamaño solicitado para los tiers (dejando unos cuantos gigas libres sin asignar) y recrear el disco virtual vía PowerShell especificando tamaños explícitos en lugar de dejar que el asistente calcule automáticamente. Esto evita los problemas de redondeo que dejan al sistema sin margen interno.
Por último, no olvides que puedes fijar archivos concretos en el tier SSD cuando lo necesites. Si tienes una ISO pesada, una base de datos o un conjunto de VHDX que quieres que vayan siempre a toda pastilla, los cmdlets de File Storage Tiering te dan ese control fino. Y si cambian tus prioridades, basta con deshacer ese pin para que el algoritmo automático vuelva a tomar las riendas.
Combinando bien Storage Spaces, niveles de almacenamiento, ReFS y herramientas como S2D y DPM, es posible construir soluciones de almacenamiento muy capaces sobre hardware estándar, mezclando SSD y HDD de forma inteligente para lograr servidores y clústeres que rinden como el rayo allí donde hace falta, mantienen enormes volúmenes de datos a bajo coste y, sobre todo, te dan la flexibilidad de ajustar la infraestructura a tus necesidades reales sin depender de cabinas propietarias ni presupuestos astronómicos.
from Actualidad Gadget https://ift.tt/FDLCgIA
via IFTTT
No hay comentarios:
Publicar un comentario