Si treballes amb Windows Server i necessites estirar al màxim el teu emmagatzematge, segur que has sentit a parlar de Storage Spaces, Storage Spaces Direct i del famós tiering. Són termes que sonen molt a “buzzword” de màrqueting, però darrere hi ha una tecnologia molt potent que, ben configurada, et pot estalviar una bona pasta a les cabines SAN i donar-te una flexibilitat brutal.
En les següents línies veurem què és exactament Storage Spaces amb tiering, com encaixa a Storage Spaces Direct (S2D), quines peces intervenen, com s'amplia un espai en capes ja creat i què necessites tenir en compte per muntar un clúster hiperconvergent de veritat, tant al laboratori com a producció. Ho farem amb un to proper, però sense escatimar en detalls tècnics, perquè puguis aplicar tot això al teu entorn sense anar a cegues.
Què és Storage Spaces i quina pinta té el tiering
A l'ecosistema de Windows Server, Storage Spaces és la capa demmagatzematge definit per programari que permet agrupar discos físics (SATA, SAS, SSD, NVMe…) en un “pool” o grup d'emmagatzematge, sobre el qual després es creen discos virtuals (virtual disks) amb diferents nivells de resiliència (simple, mirror, parity).
El concepte de tiering o nivells d'emmagatzematge entra en joc quan combinem discos de diferent rendiment dins aquest pool: per exemple, SSD o NVMe per al nivell ràpid i HDD tradicionals per al nivell de capacitat. Storage Spaces és capaç de moure de forma automàtica les dades “calentes” (molt accedides) al tier ràpid i deixar les dades “fredes” al tier més lent i barat.
En un escenari típic, tindries un tier de rendiment basat en SSD/NVMe i un tier de capacitat en HDD. Windows gestiona internament la col·locació de blocs i la seva migració entre tiers, de manera similar al que fan solucions de cabines SAN comercials, però usant servidors estàndard x86 amb discos locals.
Aquest mateix enfocament de nivells també es veu en altres fabricants i núvols públics, on s'ofereixen classes demmagatzematge amb diferents costos i temps daccés, i automatitza la transició segons el patró d'ús. L'objectiu en tots els casos és el mateix: tenir-ho tot disponible sense haver de pagar el preu de l'emmagatzematge més car per a totes les dades.
Storage Spaces Direct (S2D): la base de la hiperconvergència a Windows
Storage Spaces Direct, o S2D per als amics, és levolució de Storage Spaces tradicional que va aparèixer inicialment al Windows Server 2012 R2. Amb S2D, Microsoft porta a l'extrem el concepte d'emmagatzematge definit per programari: en lloc de dependre d'una cabina SAN externa, els mateixos servidors del clúster aporten els seus discos locals, que s'agreguen en un sol pool distribuït.
Aquesta tecnologia forma part del nucli de Azure Stack HCI i de les edicions Datacenter de Windows Server (2016, 2019, 2022 i posteriors, incloent l'Azure Edition). No cal instal·lar components rars: ve integrada al sistema operatiu, i s'habilita sobre la base del clúster de commutació per error de tota la vida.
Amb S2D pots construir dos grans models de desplegament: l'escenari hiperconvergent clàssic, en què els mateixos nodes proporcionen còmput (màquines virtuals Hyper-V) i emmagatzematge, i l'escenari convergent o desagregat, amb un clúster dedicat únicament a l'emmagatzematge i un altre al còmput que accedeix via SOFS (Scale-Out File Server).
En entorns productius, Microsoft recomana utilitzar maquinari validat per a S2D o plataformes Azure Stack HCI, amb almenys tres nodes si vols poder perdre'n un sense interrupció del servei, i discos adequats (SAS, SSD, NVMe…) a cada servidor. Per a laboratori pots arreglar-te amb menys, fins i tot amb SATA i configuracions més “creatives”, però això ja és una altra pel·lícula i no està suportat en producció.
Components clau de Storage Spaces Direct i del tiering
Per entendre com es conjuguen Storage Spaces, S2D i el tiering, convé repassar les peces tècniques que hi ha per sota de la interfície gràfica o dels assistents.
En primer lloc, necessitem maquinari compatible i suficient quantitat de discos: servidors x86 certificats, cadascun amb diverses unitats locals que poden barrejar NVMe, SSD i HDD. Aquesta barreja és el que ens permet crear diferents tiers dins del mateix pool, per exemple, un tier ràpid tot-flash i un tier de capacitat amb discos mecànics.
La xarxa és un altre pilar fonamental, perquè el bus d'emmagatzematge definit per programari (Software Storage Bus) fa que tots els nodes del clúster vegin els discos locals de tots els altres com si estiguessin en un xassís comú. Perquè això vagi fi, és molt recomanable fer servir xarxes ràpides amb RDMA (RoCE o iWARP) sobre 10 GbE o superior, especialment en clústers de producció amb moltes IOPS.
A sobre d'aquest bus, es construeix un únic Storage Pool que agrupa tota la capacitat disponible. Des d'aquest pool es creen els discos virtuals o Storage Spaces, on es configura el tipus de resiliència (simple, mirror, parity) i la política de tiering, indicant quina part es recolza en SSD/NVMe i quina part en HDD.
Sobre aquests discos virtuals, el més normal és fer servir ReFS (Resilient File System) com a sistema de fitxers recomanat, sobretot per a càrregues de treball de virtualització amb Hyper-V o emmagatzematge de VHDX. ReFS ofereix autointegritat, detecció i reparació accelerada de corrupció, i optimitzacions per a clonat ràpid de blocs, molt útils a escenaris de moltes màquines virtuals.
Models d'implementació: hiperconvergent i convergent
Dins de la família S2D, el model més popular avui dia és el desplegament hiperconvergent (HCI). En aquest enfocament, els mateixos servidors del clúster allotgen les màquines virtuals Hyper-V i alhora aporten el seu emmagatzematge al pool S2D. És una configuració molt atractiva per a moltes empreses perquè redueix complexitat i costos en no necessitar una cabina SAN separada.
L'altra opció és l'enfocament convergent o desagregat. Aquí se separen els rols: un clúster es dedica exclusivament a l'emmagatzematge S2D i exposa volums a través d'un Scale-Out File Server (SOFS) usant SMB3, mentre que un altre clúster independent s'encarrega del còmput i consumeix aquest emmagatzematge remot.
En tots dos models, el tiering segueix jugant el mateix paper: col·locar de manera intel·ligent les dades actives als mitjans de major rendiment i moure al nivell econòmic allò que no s'accedeix freqüentment. Aquesta filosofia també la veiem reflectida en serveis de núvol com Amazon S3 Intelligent-Tiering, on els objectes accedits sovint romanen en una classe “Standard” i els que amb prou feines es fan servir passen a classes d'accés infreqüent o arxiu per reduir el cost.
Un benefici clar de lenfocament convergent és que pots escalar còmput i emmagatzematge de forma independent, afegint nodes de S2D si necessites més capacitat o ample de banda demmagatzematge, o nodes de Hyper-V si et falten recursos de CPU i RAM, sense haver de créixer tot alhora.
En qualsevol cas, tant en model hiperconvergent com convergent, el clúster de commutació per error de Windows Server és la base que aporta alta disponibilitat i gestió coordinada de recursos, rols de clúster, volums compartits i migracions en viu de màquines virtuals.
Com configurar un clúster S2D amb Storage Spaces i tiering
Muntar un clúster amb Storage Spaces Direct i activar el tiering pot semblar un embolic al principi, però el flux general de treball segueix una sèrie de passos força lògics que convé tenir clars abans de començar.
El primer és preparar els nodes amb Windows Server Datacenter (en la versió suportada que utilitzaràs), instal·lant Hyper-V si allotjaràs màquines virtuals, i afegint la característica de clúster de commutació per error. El clúster es crea seguint l'assistent estàndard de Failover Cluster Manager, validant maquinari, xarxes i discos.
Un cop format el clúster, verifiques a Administrador de discs que cada node veu els seus discs de dades com a unitats independents (idealment JBOD o RAID-0 un a un perquè S2D tingui visibilitat directa). Els discos que es dedicaran al pool no han de tenir volums ni particions creades; simplement queden “en brut” disponibles perquè S2D els gestioni.
A nivell de xarxa, es configura almenys una xarxa per a trànsit de client i una altra per al trànsit intern de clúster (batecs, replicació de dades, etc.). En entorns productius hi sol haver més xarxes segmentades per a diferents tipus de trànsit, però al laboratori normalment se simplifica molt.
Amb el clúster operatiu i els discos llestos, arriba el moment de habilitar Storage Spaces Direct mitjançant PowerShell. Des d'una consola amb privilegis d'administrador podeu llançar una ordre com:
Enable-ClusterS2D -PoolFriendlyName S2D Inicieu l'habilitació automatitzada del pool d'emmagatzematge
Aquest cmdlet analitza els discos elegibles, crea el Storage Pool i configura la infraestructura de S2D. A laboratoris amb discos que no compleixen tots els requisits (per exemple, SATA en lloc de SSD certificats) es pot fer servir el paràmetre -SkipEligibilityChecks per saltar-se algunes comprovacions, encara que això, insistim, no és suportat en producció.
Creació del pool, discos virtuals i volum amb ReFS
Després d'habilitar S2D, si tornes al Failover Cluster Manager i te'n vas a Emmagatzematge > Pools, veureu un nou pool que agrupa els discs de dades de tots els nodes. Aquest és el cor del vostre emmagatzematge definit per programari.
El següent pas és crear un disc virtual (virtual disk) dins del pool. Des de les accions del pool tries “Nuevo Disco Virtual” i segueixes l'assistent indicant el nom i si vols aprofitar tiering entre diferents tipus de disc. Si el teu pool barreja SSD i HDD, és on pots marcar la casella per habilitar el tiering de dades.
L'assistent també et preguntarà per la resiliència que tindrà el disc virtual. Per a entorns seriosos el més habitual és fer servir mirror (equivalent a RAID-1) o mirror de tres vies, que permet la caiguda simultània de dos discos. Parity (similar a RAID-5) és una opció vàlida per a certs escenaris de fitxer, però té més penalització d'escriptura.
Un cop triat el tipus de resiliència i definida la mida del disc virtual, l'assistent pot encadenar la creació del volum directament a sobre. És molt pràctic deixar marcada aquesta opció perquè, només crear el disc virtual, es formategi amb el sistema de fitxers adequat, normalment ReFS si penses allotjar màquines virtuals, o NTFS si tens altres necessitats específiques.
Durant aquest procés també decideixes si assignes una lletra d'unitat o deixes el volum sense lletra. En entorns de clúster amb volums compartits per a Hyper-V és molt comú no fer servir lletres i treballar amb rutes a C:\ClusterStorage\, de manera que tots els nodes vegin el mateix volum com a recurs compartit.
Conversió a volum compartit de clúster (CSV) i ús amb Hyper-V
Un cop creat el volum sobre el teu disc virtual, queda un pas essencial per treure'n partit al clúster: convertir-lo en Cluster Shared Volume (CSV). Des del Failover Cluster Manager, a la secció de discos disponibles, seleccioneu el volum i escolliu l'opció “Afegir a Volum de Clúster Compartit”.
En fer-ho, el clúster munta el volum sota la ruta C:\ClusterStorage\VolumeX a tots els nodes, permetent que qualsevol d'ells accedeixi de manera simultània a l'emmagatzematge. És just això el que fa possible la migració en viu de màquines virtuals sense talls, ja que el disc de la VM roman disponible per a tots els hosts alhora.
Si obriu el navegador de fitxers a cada node, veureu que apareix la carpeta ClusterStorage a l'arrel de C:, amb el volum compartit dins. És aquí on se solen crear les carpetes per a les màquines virtuals (VHDX, configuració, checkpoints) i, per exemple, folders amb ISOs que vulguis utilitzar des de qualsevol node.
Des de l'Administrador de Hyper-V podeu crear una nova màquina virtual allotjant els seus arxius directament al CSV. Després, aquesta VM es pot afegir com a recurs de clúster i moure's entre nodes utilitzant Live Migration, comprovant que segueix funcionant mentre canvia de host físic.
Un detall pràctic en alguns laboratoris amb “nested virtualization” és que perquè una màquina virtual dins d'una altra VM tingui accés de xarxa, cal activar el MAC Address Spoofing. És un clàssic oblit que obliga a apagar nodes i ajustar la configuració, així que convé tenir-ho present per no perdre temps.
Cas concret: ampliar un Storage Space amb tiering a un servidor
A més de muntar clústers, hi ha un escenari molt habitual: tens un espai d'emmagatzematge en un servidor independent amb tiering configurat i necessites ampliar-lo perquè la capacitat actual s'ha quedat curta. Windows Server permet fer-ho de forma força directa utilitzant PowerShell i alguns passos ben definits.
Imagina un espai en capes d'uns 12 TB ja creat, amb tier SSD i HDD. El procés general per ampliar-lo seria el següent: primer afegeixes nous discos físics al conjunt d'emmagatzematge (per exemple, més HDD per al tier de capacitat) i t'assegures que el sistema els veu correctament.
Després, des de PowerShell, executes un Get-PhysicalDisk | FL * per llistar tots els discos i localitzar l'uniqueId del nou disc que acabes d'incorporar. Aquest identificador serà el que facis servir per ajustar el tipus de mitjà, cosa fonamental si el disc no és detectat automàticament com HDD o SSD.
Amb l'uniqueId a la mà, llances una ordre de l'estil Set-PhysicalDisk -UniqueId <ID> -MediaType HDD per actualitzar el tipus de mitjà del nou disc. Després d'això, cal refrescar l'Administrador del servidor o la consola d'administració d'emmagatzematge per verificar que el disc apareix amb el tipus correcte.
Un cop ajustat el tipus, ja pots redimensionar el tier corresponent usant el cmdlet Resize-StorageTier. Per exemple, alguna cosa com Resize-StorageTier -FriendlyName Vdisk01_Microsoft_HDD_Template -Size 16.1TB permetria ampliar la mida assignada al tier de HDD dins aquest disc virtual en capes.
El darrer pas és anar a Administració de discos i estendre el volum que es recolza en aquest disc virtual, de manera que el sistema operatiu aprofiti la nova capacitat disponible. A partir d'aquell moment tindràs més espai útil mantenint el comportament de tiering entre SSD i HDD sense haver de recrear el Storage Space des de zero.
Consideracions sobre columnes, nombre de discos i disseny del tier
Un dubte freqüent quan es treballa amb Storage Spaces en configuracions una mica més avançades és com es relacionen les columnes amb el nombre de discos físics necessaris, sobretot quan es volen utilitzar SSD com a tier de rendiment al costat d'HDD en un xassís amb molts discos.
Les columnes determinen com es distribueixen les dades en paral·lel entre els discos físics, cosa que influencia tant el rendiment com la tolerància a fallades i el nombre mínim d'unitats necessàries. Si defineixes, per exemple, un Storage Space amb tres columnes, això implica que les dades es “stripegen” sobre tres discos per cada còpia de dades (segons el tipus de resiliència).
Quan introdueixes un tier SSD per sobre d'un conjunt d'HDD, la lògica és similar: si el disseny del disc virtual fa servir tres columnes, el més habitual és que necessitis que el tier de SSD també disposi de suficients unitats per mantenir aquesta estructura. Treballar amb un únic SSD com a tier sol ser una mala idea, perquè elimina paral·lelisme, complica la resiliència i es converteix en punt únic de fallada.
Encara que al laboratori es poden fer concessions (pocs discos, barreges estranyes, etc.), en entorns reals convé respectar les recomanacions de Microsoft respecte a nombre mínim de discos per tipus de mitjà, nombre de columnes adequat a la mida del pool i nivells de resiliència, de manera que el tiering pugui funcionar de manera equilibrada.
El disseny correcte del tier influeix directament en el rendiment percebut per les aplicacions, l'eficiència de l'ús de SSD (perquè no es converteixi en un coll d'ampolla) i la capacitat efectiva que obtindràs després d'aplicar mirror o parity. Un mal dimensionament pot donar lloc a sorpreses desagradables quan vulguis créixer o quan falli un disc.
Paral·lelismes amb el tiering al núvol i gestió del cicle de vida
Més enllà de Windows Server, val la pena mirar com altres proveïdors aborden el tiering, perquè els principis són els mateixos i ajuda a entendre la filosofia general. Un exemple clar és Amazon S3 Intelligent-Tiering combinat amb S3 Glacier, on el sistema classifica automàticament els objectes segons el patró d'accés.
En un cas real d'ús, una plataforma de streaming europea va migrar més de 3 PB de contingut audiovisual a Amazon S3 usant dispositius Snowball, i avui manté tot el seu fitxer en línia gràcies a Intelligent-Tiering. El contingut amb molta demanda es queda al tier d'accés freqüent, mentre que les sèries i les pel·lícules menys vistes passen a nivells d'accés poc freqüent o d'arxiu, mantenint el cost total sota control.
De manera similar, en entorns on-premise amb solucions com ONTAP, es poden definir polítiques de cicle de vida per moure dades entre diferents tipus d'emmagatzematge, començant en una classe estàndard i, després de X dies d'inactivitat, passant a classes més barates. A més, alguns sistemes permeten fins i tot crear miralls en altres magatzems d'objectes i alternar quina és la destinació principal o el mirall.
El missatge de fons és que el tiering ja no és només una característica de maquinari local, sinó una estratègia global de gestió de dades, tant al núvol com al CPD. Storage Spaces amb tiering a Windows encaixa perfectament en aquesta filosofia, permetent que, sense sortir de l'ecosistema Microsoft, puguis jugar amb diferents nivells de rendiment i cost.
En tots aquests contextos, el que realment estalvies és temps de gestió i maldecaps; no has d'estar constantment pensant què esborrar, quin mètode de còpia utilitzar o què moure manualment, perquè el sistema aprèn del patró d'accés i recol·loca les dades on toqui per optimitzar despesa i rendiment.
Si ajuntem tot el que hem vist, s'aprecia que Storage Spaces amb tiering i Storage Spaces Direct formen un bloc molt potent per construir infraestructures modernes, tant on-premise com en escenaris híbrids. Partint de servidors estàndard, pots obtenir un comportament molt semblant al de cabines SAN avançades, amb alta disponibilitat, gran rendiment, escalabilitat horitzontal i automatització en la gestió de dades calentes i fredes. Planificant bé el maquinari, les xarxes i el disseny de pools i tiers, es converteix en una peça clau per a clústers Hyper-V, file servers escalars o fins i tot desplegaments HCI integrats amb el núvol, sense haver de dependre de solucions propietàries molt més cares.
