Memoria persistente (NVDIMM, PMEM): guía completa y casos de uso

Inicio » Hardware » Memoria persistente (NVDIMM, PMEM): guía completa y casos de uso

La memoria persistente (NVDIMM, PMEM) se ha colado en todos los roadmaps de servidores modernos porque ocupa un hueco muy jugoso entre la DRAM y el almacenamiento clásico. Combina la baja latencia de la RAM con la capacidad de retener los datos cuando se apaga la máquina, lo que la convierte en una pieza clave para bases de datos, virtualización, sistemas hiperconvergentes y aplicaciones extremadamente sensibles al tiempo de caída.

Este tipo de módulos especiales se montan en ranuras DIMM estándar, pueden funcionar como memoria, como almacenamiento ultrarrápido o como un híbrido de ambos, y aparecen bajo mil nombres: PMem, NVM, DCPMM, SCM, vPMem, vPMemDisk, etc. A lo largo de este artículo vamos a ordenar todas esas siglas, ver qué aporta realmente la memoria persistente, cómo se usa en Windows, Linux, SQL Server y vSphere, y qué debes tener en cuenta para configurarla sin perder datos ni rendimiento.

¿Qué es exactamente la memoria persistente (PMEM, NVDIMM)?

La memoria persistente es un medio no volátil que se presenta en formato DIMM estándar y se instala en el bus de memoria del servidor, junto a la DRAM convencional. A diferencia de la RAM, su contenido no se pierde cuando se apaga o se cuelga el sistema: los datos permanecen en el módulo incluso ante cortes de corriente inesperados o apagados controlados.

En cuanto a rendimiento y coste, PMem se sitúa en un punto intermedio: es más lenta que la DRAM, pero muchísimo más rápida que SSD y NVMe, con latencias en el rango de nanosegundos y un ancho de banda muy superior al de un bus de almacenamiento tradicional. A cambio, ofrece capacidades muy superiores a la RAM y un precio por GB más bajo que la DRAM, aunque todavía por encima de las unidades NVMe.

Este equilibrio entre velocidad, capacidad y persistencia hace que muchas plataformas la etiqueten como “memoria de clase de almacenamiento” (Storage Class Memory, SCM). En la práctica, puedes usarla como caché de altísimo rendimiento, como un pool de memoria “ampliado” más barato que la DRAM, o bien como un nivel de almacenamiento ultrarrápido sobre el que poner bases de datos, ficheros calientes o estructuras en memoria que no quieres reconstruir cada vez que arrancas.

Detrás del término genérico PMem hay varias tecnologías. Dos de las más conocidas son los módulos NVDIMM-N, que combinan DRAM con NAND y una pequeña batería para volcado de datos, y la memoria persistente Intel Optane DC Persistent Memory (DCPMM), que ofrece capacidades de 128, 256 o 512 GB por módulo y puede trabajar en diferentes modos lógicos expuestos al sistema operativo.

Conceptos fundamentales: modos de acceso, regiones y PmemDisk

Para sacarle todo el partido a la memoria persistente es clave entender cómo se presenta y cómo se accede a ella desde el sistema operativo. Aquí entran en juego conceptos como los modos de acceso (bloques vs DAX), las regiones intercaladas y los discos lógicos de PMem (PmemDisk o equivalentes).

Métodos de acceso: bloque tradicional frente a DAX

En Windows y Linux se puede acceder a PMem de dos formas principales: como dispositivo de bloques “clásico” (similar a un disco) o a través de acceso directo a la memoria (DAX, Direct Access), donde las aplicaciones mapean el espacio persistente como si fuera memoria direccionable por bytes.

• Acceso por bloques: la memoria persistente se expone como si fuera una unidad de disco. Los datos pasan por el sistema de archivos y la pila de almacenamiento, lo que facilita la compatibilidad con aplicaciones y herramientas existentes. En Windows puede usarse con NTFS o ReFS; en Linux, con XFS o ext4. Este modo es recomendable para la mayoría de escenarios porque conserva las semánticas de E/S por bloques, snapshots, utilidades de backup, etc.
• Acceso directo (DAX): permite que el sistema operativo y las aplicaciones accedan al espacio de PMem como memoria direccionable por bytes, sin usar la caché de página tradicional. Se elimina gran parte de la sobrecarga de la pila de E/S, consiguiendo la menor latencia posible. En Windows solo es compatible con NTFS en volúmenes marcados como DAX, y en Linux se usa con espacios de nombres fsdax. La contrapartida es que, si se usa mal, es fácil exponerse a escrituras incompletas y corrupción de datos, por lo que conviene combinarlo con mecanismos de protección como la Block Translation Table (BTT) cuando se requiere atomicidad por sectores.

En entornos donde se mezclan metadatos por bloques y acceso DAX (por ejemplo, aplicaciones con ficheros mapeados en memoria sobre un volumen DAX), conviene tener activada BTT o modos de espacio de nombres que aseguren semánticas de sector atómico, ya que los metadatos del sistema de archivos siguen operando a nivel de bloques aunque las lecturas/escrituras de la aplicación se hagan en modo byte-addressable.

Regiones e intercalado de módulos

Una región de memoria persistente es un conjunto continuo de direcciones que se crea a partir de uno o varios módulos físicos (NVDIMM o DCPMM). Lo habitual en servidores modernos es configurar regiones intercaladas (interleaved sets) en el BIOS o firmware de la placa, haciendo que varios módulos aparezcan como un único espacio de direcciones lógico para incrementar el ancho de banda disponible.

En un conjunto intercalado de dos o cuatro vías, las direcciones virtuales consecutivas se reparten entre varios DIMM, de forma similar a un RAID de memoria: mientras un núcleo accede a una dirección que reside en un módulo, otro puede acceder en paralelo a otra dirección alojada en un segundo módulo. Esto reduce la latencia efectiva y mejora significativamente el rendimiento en lectura y escritura secuencial o aleatoria.

Herramientas de administración como PowerShell en Windows permiten inspeccionar estas configuraciones. Por ejemplo, comandos como Get-PmemDisk y Get-PmemPhysicalDevice muestran qué disco lógico de PMem usa qué dispositivos físicos (identificados por DeviceId), el estado de salud, la ubicación física (CPU1_DIMM_C1, CPU1_DIMM_F1, etc.) y las capacidades de memoria persistente y volátil de cada módulo. También es útil recurrir a utilidades de diagnóstico como usar RAMMap en Windows para análisis avanzados.

PmemDisk y discos lógicos SCM en Windows

Cuando se quiere usar PMem como almacenamiento en Windows Server (ya sea en máquinas físicas, Azure Local o entornos con Hyper-V) se define al menos un PmemDisk: un disco duro virtual especial (VHD con extensión .vhdpmem) que representa un rango contiguo de memoria no volátil.

Estos PmemDisk se manejan como si fueran LUN o particiones: se pueden crear varios para particionar la capacidad total, se inicializan, se les crea una partición y se formatean con NTFS o ReFS, pudiendo marcar el volumen con la opción DAX cuando se desea acceso directo. Cada módulo físico de PMem contiene un área de almacenamiento de etiquetas (Label Storage Area, LSA) donde se guardan los metadatos de configuración de estos espacios de nombres y discos lógicos.

La creación de PmemDisk con BTT habilitada se hace, por ejemplo, con el cmdlet New-VHD especificando -AddressAbstractionType BTT. También es posible convertir un VHD sin BTT a otro con BTT usando Convert-VHD y regenerar su identificador de espacio de nombres con Set-VHD -ResetDiskIdentifier para evitar conflictos si ambos se conectan a la misma VM.

Block Translation Table (BTT) y escrituras atómicas

Los módulos de memoria persistente, a diferencia de muchos SSD, no protegen de forma nativa contra escrituras parciales si hay un corte de luz o una caída del sistema en mitad de una operación. Esto puede dejar sectores en un estado intermedio, mezclando datos viejos con nuevos.

La Block Translation Table (BTT) es una capa de abstracción que proporciona semántica de actualización atómica por sector sobre dispositivos de PMem. Básicamente actúa como una traducción de direcciones que garantiza que los sectores se escriben de forma similar a un dispositivo de bloques clásico, reduciendo el riesgo de corrupción en fallos inesperados.

En modo de acceso por bloques es muy recomendable activar BTT porque toda la lógica de las aplicaciones y del sistema de archivos presupone esa atomicidad de escritura a nivel de sector. En volúmenes DAX, aunque los datos de la aplicación se escriban mediante mapeo de memoria, los metadatos del sistema de archivos siguen utilizando operaciones por bloques, por lo que BTT continúa siendo útil para evitar daños silenciosos en estructuras internas.

Memoria persistente en Windows Server, Azure Local e Hyper-V

En Windows Server 2019 y Azure Local, la memoria persistente puede utilizarse tanto como caché de alto rendimiento como unidad de capacidad. En escenarios de Espacios de almacenamiento directo, lo habitual es que PMem se use de forma automática como capa de caché para acelerar los datos calientes, dejando los SSD o NVMe como capa de capacidad más amplia.

Debido a la estructura de costes de PMem, su mayor valor se suele obtener cuando se reserva una fracción relativamente pequeña para datos muy sensibles a la latencia, como estructuras internas de asignación de memoria o metadatos críticos. El resto del almacenamiento menos exigente sigue residiendo en SSD/NVMe.

La consola de administración y PowerShell proporcionan cmdlets específicos para gestionar PMem: Get-PmemDisk, Get-PmemPhysicalDevice, Get-PmemUnusedRegion, New-PmemDisk, Remove-PmemDisk o Initialize-PmemPhysicalDevice, entre otros. Estos comandos permiten listar los discos lógicos de PMem, ver qué dispositivos físicos los forman, crear nuevos discos intercalando regiones sin usar y limpiar áreas de etiquetas si es necesario.

Si se produce un fallo en un módulo de memoria persistente, normalmente será necesario sustituir el DIMM defectuoso y volver a aprovisionar los discos lógicos de PMem a partir de las regiones disponibles. Durante el troubleshooting avanzado se puede recurrir a Remove-PmemDisk para borrar discos lógicos (con pérdida de datos) o a Initialize-PmemPhysicalDevice para reinicializar las áreas de metadatos dañadas. Además, es recomendable usar utilidades de diagnóstico como memtest64 en Windows para comprobar la integridad del DIMM.

PMem como almacenamiento para Hyper-V y máquinas virtuales

En entornos con Hyper-V sobre Windows Server 2019, la memoria persistente se puede exponer a máquinas virtuales de dos formas principales: como discos virtuales basados en PMem (VHD con extensión .vhdpmem) o como controladoras PMem específicas para que la VM vea un NVDIMM virtual.

El flujo típico de configuración incluye habilitar PMem en el BIOS del servidor (por ejemplo, en un Dell PowerEdge R740xd), instalar Windows Server 2019, habilitar Hyper-V y comprobar que el hipervisor detecta dispositivos SCM tanto en el Administrador de dispositivos como mediante PowerShell. A partir de ahí se crean los discos de memoria persistente con Get-PmemUnusedRegion | New-PmemDisk, se inicializan, se crean volúmenes y se formatean con DAX (-IsDAX $True) cuando se quiere aprovechar el acceso directo.

Posteriormente se añade una controladora PMem a la VM y se crea un archivo .vhdpmem con New-VHD -Fixed (no es compatible con VHD dinámicos) que se adjunta a esa controladora con add-VMHardDiskDrive -ControllerType PMEM. Dentro de la VM, el sistema operativo detecta el nuevo disco de PMem, se inicializa y formatea, pudiendo marcarse también como volumen DAX para usos como SQL Server en NVDIMM.

Hay algunas limitaciones importantes en memoria de clase de almacenamiento para VM en ciertos escenarios: no se permiten migraciones en caliente de VM (live migration) usando PMem como almacenamiento directo, no se soporta el redimensionamiento de disco en tiempo de ejecución, se deshabilitan aprovisionamiento delgado e instantáneas para esos discos PMem y gran parte de la automatización se implementa vía PowerShell en lugar de asistentes gráficos completos.

PMem en vSphere: vPMem y vPMemDisk

VMware vSphere soporta memoria persistente a partir de la versión 6.7, permitiendo que las máquinas virtuales se beneficien de PMem tanto en hosts independientes como en clusters. Aunque PMem no forma parte del stack de vSAN de forma directa, las VMs desplegadas sobre clusters con vSAN pueden seguir usando dispositivos vPMem y vPMemDisk exposiciones locales de App Direct.

En ESXi, la memoria persistente aparece como un datastore local de PMem. La capacidad total de PMem del cluster se puede tratar como un único recurso lógico a ojos del administrador, sin necesidad de gestionar manualmente cada datastore host por host. VMware vCenter y DRS se encargan de automatizar la colocación inicial de los discos y reservas de PMem según la política de almacenamiento seleccionada.

Las máquinas virtuales pueden consumir PMem de dos formas, lo que resulta especialmente útil para sistemas operativos invitados modernos y también para legacy:

• Memoria persistente virtual (vPMem): el host presenta un NVDIMM virtual al sistema operativo invitado mediante un dispositivo vNVDIMM. El invitado ve PMem como memoria direccionable por bytes y puede montar sistemas de archivos DAX o utilizar APIs específicas para sacar partido a la persistencia en el bus de memoria.
• Disco de memoria persistente virtual (vPMemDisk): la VM ve un dispositivo SCSI virtual clásico, pero el fichero VMDK que lo respalda reside físicamente en el datastore de PMem. Esto permite que sistemas operativos invitados que no soportan NVDIMM aprovechen la latencia y ancho de banda de PMem como si fuera un disco ultrarrápido.

Cuando creas una VM con vPMem, se reserva su capacidad de memoria persistente desde el primer arranque y esa reserva se mantiene tanto si la VM está encendida como si está apagada, hasta que se elimina o se migra. El control de admisión de vSphere HA tiene en cuenta este consumo de PMem en el cluster, lo que obliga a que la suma de reservas nunca supere la capacidad total disponible.

Como PMem es un recurso local a cada host, la migración se maneja de forma distinta: una VM con vPMem sólo se puede mover a otro host que disponga de recursos de PMem suficientes; si solo utiliza vPMemDisk, la VM puede migrarse a un host sin PMem siempre que el disco se mueva mediante Storage vMotion a otro datastore que lo soporte.

Existen también varias consideraciones de seguridad y gestión: el software de sistema no siempre puede seguir los cambios en dispositivos PMem en modo byte-addressable, por lo que algunas soluciones de copia de seguridad o replicación no funcionan todavía con volúmenes DAX puros. Además, errores catastróficos de host pueden implicar pérdida de datos y necesidad de reformatear el datastore de PMem, especialmente cuando se usa en modos de escritura diferida o configuraciones no inmediatas.

Uso de PMem en Linux y SQL Server sobre memoria persistente

En el ecosistema Linux, la gestión de NVDIMM y PMem se realiza fundamentalmente con la utilidad ndctl, que permite crear regiones, espacios de nombres y dispositivos de bloque sobre módulos de memoria no volátil. Para instalar y configurar NVDIMM como almacenamiento se siguen unos pasos bastante claros.

El punto de partida es crear un espacio de nombres sobre la región PMem disponible. El modo fsdax es el más interesante cuando se quiere montar un sistema de archivos con soporte DAX sobre el dispositivo, porque permite que las aplicaciones usen mapeos de memoria directa sin pasar por la caché de página. Un ejemplo típico sería:

Una vez creado el espacio de nombres, se formatea el dispositivo resultante (por ejemplo, /dev/pmem0) con XFS o ext4 y se monta con las opciones adecuadas: mount -o dax,noatime /dev/pmem0 /mnt/dax, adoptando tamaños de bloque y parámetros de alineación que permitan aprovechar bloques de 2 MB y eviten que el kernel regrese silenciosamente a páginas de 4 KB en los mapeos de memoria.

Es recomendable que los ficheros que vayan a usarse con mmap sobre PMem tengan tamaños múltiplos de 2 MB, que no se desactiven las Transparent Huge Pages (THP) y que se validen los perfiles de rendimiento según la carga de trabajo, ya que una alineación incorrecta puede anular parte de las ventajas de la memoria persistente.

SQL Server 2019 en Linux sobre PMem

SQL Server 2019 (y versiones posteriores) en Linux incorpora varias optimizaciones para aprovechar memoria persistente. Permite colocar los archivos de datos de usuario (.mdf, .ndf) y la base de datos tempdb en un dispositivo PMem configurado en modo fsdax, mientras recomienda mantener los archivos de log (.ldf) en almacenamiento con garantías atómicas de sector (por ejemplo, SSD NVMe de alta gama o PMem configurado en modo sector/BTT).

Para crear un espacio de nombres en modo sector (pensado para logs con requerimientos estrictos de atomicidad FUA) se usa un comando similar, cambiando el modo a sector. La documentación de SQL Server enfatiza la necesidad de comparar el rendimiento real del log sobre PMem en modo sector frente a las mejores unidades NVMe disponibles para decidir cuál es la mejor opción en cada escenario.

Otro aspecto clave es la interacción con FUA (Forced Unit Access) en el subsistema de E/S de Linux. Algunas distribuciones y kernels (por ejemplo, SLES 12 SP5, RHEL 8.0, Ubuntu 18.04 con kernels XFS ≥ 4.18 y ext4 ≥ 5.6) ofrecen soporte completo de FUA, lo que permite a SQL Server lograr E/S duraderas sin depender excesivamente de vaciados forzados (flush) costosos; conviene revisar las novedades del kernel Linux para entender compatibilidades y mejoras.

En estos entornos se recomiendan configuraciones específicas: habilitar la marca de seguimiento 3979, ajustar los parámetros control.writethrough y control.alternatewritethrough mediante mssql-conf, y garantizar que el almacenamiento subyacente y la distribución de Linux realmente soportan FUA. Para otras combinaciones menos modernas, la guía oficial sugiere usar la marca 3982 y activar ambos modos de writethrough para minimizar riesgos de pérdida de datos.

En despliegues de SQL Server en contenedores sobre Kubernetes se aplican las mismas reglas de FUA: el almacén persistente debe usar XFS o ext4 con soporte FUA, el nodo de trabajo ha de ejecutar una distribución con esa funcionalidad y el almacenamiento debe montarse como volumen persistente real, no sobre overlayfs. Solo así se pueden aplicar las optimizaciones de E/S de alto rendimiento apoyadas en FUA sin comprometer la durabilidad de las transacciones.