NVMe fent de RAM: la memòria per nivells funciona si en tens la meitat ociosa

A la crònica del darrer VMware Explore hi ha una frase que explica el moment millor que qualsevol gràfic: la DRAM costa avui sovint diverses vegades més que el servidor on va muntada. La resposta de VMware a això es diu memòria per nivells: si una part de la RAM fa hores que ningú no la toca, que baixi a un NVMe local i deixi lloc al que sí que es fa servir. És a producte, documentada, i dues sessions sobre el tema van omplir sales de 500 persones. El que menys s'ha citat de tot plegat és una recomanació que el mateix VMware va publicar al seu blog de Cloud Foundation el 6 d'agost: mantén la memòria activa per sota del 50 % de la física. Llegida a l'inrevés, aquesta recomanació és un diagnòstic.

Què fa exactament

La definició de Broadcom és d'una sola línia: «Memory Tiering et permet afegir capacitat de memòria a un host ESX fent servir dispositius NVMe instal·lats localment al host com a memòria per nivells». L'hipervisor vigila quines pàgines de memòria són fredes —ningú no les ha llegit ni escrit en una bona estona— i les baixa al NVMe. Quan algú les torna a demanar, pugen. Per a la màquina virtual tot això és invisible: continua veient els seus 64 GB.

La funció va sortir com a disponible amb VMware Cloud Foundation 9.0 i enguany, a la 9.1, VMware l'ha retocada perquè es porti millor amb bases de dades i li ha afegit taulers que ensenyen quanta activitat d'escalonament hi ha i eines de gestió. La documentació de vSphere 9.0 demana vCenter i ESX 9.0 o superior, i la funció ve desactivada de fàbrica. I hi ha full de ruta declarat: Dave Morera, arquitecte de màrqueting tècnic de VMware, ho va dir a Explore amb aquestes paraules: «tenim un full de ruta de dos a tres anys». El que hi ha posat en aquest full de ruta diu força sobre el que falta avui, i hi tornem més avall.

Escalonar no és tenir més memòria

Això és criteri nostre i convé dir-ho aviat, perquè el titular convida a entendre-ho malament. La memòria per nivells no crea memòria: canvia capacitat per latència. Un accés a DRAM i un accés a un NVMe no són a la mateixa escala; entre l'un i l'altre hi ha ordres de magnitud, i aquesta distància no l'arregla cap algorisme. El que fa l'algorisme és apostar que gairebé mai no pagaràs aquest peatge, perquè gairebé sempre el que demanes és a dalt.

L'aposta és raonable. A qualsevol clúster amb unes quantes desenes de màquines hi ha memòria que no fa res: entorns de preproducció encesos des del març, servidors d'aplicació dimensionats «per si de cas», la màquina d'un projecte que es va cancel·lar i ningú no va apagar. Aquesta memòria està assignada, ocupa lloc i no la toca ningú. És exactament el material que l'escalonament s'emporta al NVMe sense que es noti. Quan l'aposta es trenca és quan la màquina que es va quedar a baix era la que a les nou del matí es posa a treballar de cop.

El número que decideix és teu, no de VMware

En un article del 6 d'agost sobre reserves de memòria, VMware deixa anar la recomanació operativa més útil de tot el material que hem llegit sobre aquesta funció: mantenir la memòria activa per sota del 50 % de la memòria física total. És una bona pràctica publicada pel fabricant, i aquí ve la nostra lectura: aquesta frase descriu a quina mena de servidor li serveix això. Si la teva memòria activa és per sobre d'aquest llindar, l'escalonament no et salvarà; et traslladarà el problema a la latència.

El problema és que gairebé ningú no sap quina és la seva xifra. Quan entrem en una infraestructura aliena i preguntem quanta memòria està de debò en ús, la resposta habitual és la de la pestanya de resum, la memòria assignada, que mesura una altra cosa. Mesurar-ho no té misteri i no cal comprar res per fer-ho: s'agafa l'històric de memòria activa de diverses setmanes, inclosos els tancaments de mes, i es compara amb la física instal·lada. Aquest quocient decideix si aquesta funció és una bona compra o un pedaç car. El mateix defensàvem quan vam escriure sobre la pujada del preu de la RAM: abans de signar mòduls cal saber quanta de la que ja tens està treballant.

Els requisits són una llista de la compra

La documentació de Broadcom i la nota d'Explore deixen una llista de condicions que convé llegir seguida, perquè per separat cadascuna sembla menor:

• El NVMe ha de ser local. Literal: «els dispositius NVMe no poden ser sobre fabric ni Ethernet. Han d'estar instal·lats localment». Adéu a resoldre-ho des de la cabina que ja tens.
• I no val qualsevol NVMe. Broadcom demana l'especificació de memòria cau de vSAN, ús mixt, 3 DWPD. A Explore es va concretar encara més: mínim 100.000 escriptures per segon i 7.300 TB d'escriptures de per vida.
• Activar o desactivar exigeix el host en mode manteniment. És a dir: buidar el servidor i moure-ho tot. No és un interruptor que es prova un dimarts a la tarda.
• Es perden coses pel camí. Amb la memòria per nivells activada, la documentació diu que Quick Boot no està suportat en aquell host i que suspendre màquines a memòria tampoc; el hot-plug i el «preparar per retirar» queden fora per als discos NVMe que fan de nivell, no per a la resta. Suspendre a disc i els snapshots continuen funcionant. El servidor tampoc no pot portar Intel Optane ni memòria persistent NVDIMM-N.
• Hi ha sostre. Per defecte el sistema limita la capacitat escalonada a la mida de la DRAM, ràtio 1:1, amb un màxim de 4 TB per partició. La proporció per defecte i la que es recomana de partida és aquesta 1:1; VMware permet pujar-la fins a 1:4, i quan ho fa apunta a casos concrets com els escriptoris virtuals, no com a ajust general.

Posada en fila, la llista deixa de semblar una funció i comença a semblar un pressupost: unitats NVMe empresarials d'alta resistència a cada host, una finestra de manteniment per servidor i la subscripció al dia. Les exigències tenen la seva raó, perquè a aquell NVMe se li escriurà molt i molt sovint. Però és la part que no cap al titular. La resposta al fet que el ferro s'hagi encarit implica comprar més ferro, i d'un tipus que tampoc no s'ha lliurat de la pujada: les mateixes previsions de mercat que citàvem al nostre repàs al preu de la memòria donaven a la NAND un +70-75 % intertrimestral al segon trimestre del 2026, de la mateixa estirada de demanda que la DRAM.

El 25 % del qual no se sap gairebé res

La xifra que va donar VMware a Explore és que la memòria per nivells suporta avui al voltant del 75 % de les càrregues. S'agraeix que ho digui amb un número. El problema és que ningú no publica quin és el 25 % restant. L'única cosa d'aquest grup que té nom propi és al full de ruta: les monster VM —les màquines de fins a 960 vCPU i 16 TB de memòria repartides entre diversos servidors físics— estan previstes per a VCF 9.2, cap al maig del 2027.

I aquí convé que siguem precisos, encara que l'argument quedi menys rodó: una màquina de 16 TB repartida entre diversos servidors és un cas extrem, i l'ERP d'una pime o el motor d'informes que es dispara al tancament de mes gairebé segur que cauen dins del 75 % que ja està suportat. No insinuarem el contrari perquè la crítica soni millor. El que sí que sostenim, i és criteri nostre, és que un percentatge agregat no contesta l'única pregunta que t'importa: si la màquina concreta que t'està estrenyent la memòria és dins o fora d'aquest 75 %. Aquesta llista no està publicada, així que la resposta se n'obté provant en un host, no llegint una fitxa.

I no, la reserva no te'n treu

El reflex de qualsevol que porti anys a vSphere és: «va, doncs a la base de dades li poso una reserva completa i em quedo tranquil». No funciona així, i ho diu VMware al seu propi article del 6 d'agost: «no fixa la memòria a DRAM». Una reserva impedeix que el host reclami aquella memòria per swap, ballooning o compressió, però «aquelles pàgines reservades es poden continuar servint tant des de DRAM com des de NVMe». La distinció que fan servir és bona: el número de la reserva és una promesa al planificador; la memòria fixada és un contracte amb el maquinari. No són el mateix.

Treure de debò una màquina de l'escalonament es fa desactivant-lo per a ella, i això té un efecte que al mateix article s'explica amb un exemple: en desactivar-la i reservar-la sencera, la proporció de la resta del host es desplaça d'1:1 a 1:2. Traduït: la DRAM que has garantit a la màquina important l'has treta a les seves veïnes, que ara depenen el doble del NVMe. És una decisió perfectament legítima —hi ha càrregues que la mereixen—, però és un repartiment, no un regal. Qui pensi que pot blindar tres o quatre màquines crítiques i deixar la resta igual, es trobarà el cost al lloc on no el mirava.

Quan sí que surt a compte

Amb tot l'anterior sobre la taula, la funció continua resolent un problema real. Surt a compte, al nostre parer, quan es compleixen tres coses alhora: la teva memòria activa és clarament per sota de la meitat de la física; el clúster té moltes màquines mitjanes i tèbies, no dos monstres; i ja ets dins de VCF amb la versió que toca, de manera que el cost incremental és el dels discos i les finestres de manteniment, no el d'una plataforma nova. En aquest escenari, ficar NVMe a cada host és força més barat que ficar-hi DRAM, i encaixa amb el consell que donem des de fa mesos: estirar el ferro que ja tens abans que comprar en el pitjor moment del mercat.

Les dues xifres que més es repetiran a les presentacions són un 30 % menys de cicles de CPU i un 40 % menys de cost de propietat. Són afirmacions del fabricant, recollides a la crònica d'Explore, i no les hem mesurat nosaltres. Ni les donem per falses ni les repetim com si fossin nostres: si algú les vol fer servir per justificar una compra, que demani amb quina càrrega i contra quina línia base es van obtenir, perquè un percentatge de cost de propietat sense escenari de partida no significa res.

El que fem abans de tocar res

Quan arriba la conversa de «no tenim memòria», el primer que mirem és la diferència entre memòria assignada i memòria tocada, amb històric. Gairebé sempre apareix el mateix: màquines enceses que ningú no reclama, entorns que van sobreviure al seu projecte, dimensionaments que es van copiar d'una plantilla. Apagar i ajustar no dóna per a una presentació bonica, però és gratis i no afegeix una peça nova que pugui fallar. Només després té sentit parlar de ballooning, de deduplicació de pàgines —amb els seus inconvenients, que en té: costa CPU— o, ara, d'escalonar a NVMe.

I falta anomenar la palanca que més vegades hem vist moure la factura de debò, que és de llicències i no tècnica. Ja vam escriure que l'èxode massiu de VMware no ha passat i que bona part del mercat ha renegociat en comptes de marxar, i també que hi ha casos en què NO recomanem migrar a Proxmox. No som resellers de ningú: ni de VMware ni de Proxmox, i no venem llicències de cap dels dos. El que sí que diem, amb la mateixa tranquil·litat, és que si mires aquesta funció perquè el maquinari s'ha encarit, el calendari de les teves llicències mereix ser al mateix full de càlcul que els discos.

A everyWAN dissenyem i operem infraestructura virtualitzada a les dues plataformes des de fa anys, fem migracions de VMware a Proxmox quan el compte surt, i diem que no quan no surt. Si el que cal és algú que miri els teus números abans que signis res, això és consultoria i es cobra per hores, no per llicències.

Fonts (verificades el 2 de setembre de 2026): la crònica de VMware Explore, el full de ruta, la xifra del 75 % de càrregues suportades, la definició i el calendari de les monster VM (fins a 960 vCPU i 16 TB repartides entre diversos servidors físics, previstes per a VCF 9.2 cap al maig del 2027), els requisits del NVMe (100.000 escriptures per segon i 7.300 TB d'escriptures de per vida), les xifres de 30 % menys de cicles de CPU i 40 % menys de cost de propietat, la cita de Dave Morera i la dada de les sales de 500 persones provenen de The Register, 1 de setembre del 2026. La definició de la funció, la ràtio 1:1 per defecte amb màxim de 4 TB, el requisit de NVMe local («no poden ser sobre fabric ni Ethernet»), l'especificació de cau de vSAN amb 3 DWPD, el mode manteniment, la incompatibilitat amb Intel Optane i NVDIMM-N i les limitacions de Quick Boot, suspensió a memòria i hot-plug són a la documentació de Broadcom per a vSphere (pàgines de les versions 9.0 i 9.1). La recomanació de mantenir la memòria activa per sota del 50 % de la física —que no és a la documentació de producte sinó al blog corporatiu, i que allà apareix lligada a l'efecte de les reserves completes sobre el pressupost de DRAM—, la frase «no fixa la memòria a DRAM», la distinció entre promesa al planificador i contracte amb el maquinari i l'exemple del desplaçament d'1:1 a 1:2 són de l'article «Memory Tiering and VM Memory Reservation», 6 d'agost del 2026, del blog oficial de VMware Cloud Foundation. La disponibilitat inicial amb VCF 9.0 està anunciada al mateix blog. Criteri propi, no fet reportat: que escalonar canvia capacitat per latència i no crea memòria; la lectura del 50 % com a diagnòstic de quina mena de host aprofita la funció; que la llista de requisits funciona com a llista de la compra; que les màquines amb problema de memòria solen ser les grans, just les que són al full de ruta i no al producte d'avui; i l'ordre de palanques que apliquem (mesurar assignat davant de tocat, apagar i ajustar, i només després escalonar). La ràtio de fins a 1:4 i el seu encaix amb casos com els escriptoris virtuals provenen de l'anunci de disponibilitat de VCF 9.0 i de la crònica d'Explore, no de la pàgina de documentació citada. La xifra de la NAND (+70-75 % intertrimestral al segon trimestre del 2026) és una previsió de TrendForce ja recollida i verificada al nostre post sobre el preu de la memòria, que s'enllaça al cos. Les xifres de rendiment i cost de propietat són afirmacions del fabricant i no les hem verificades amb mesures pròpies.