Almacenamiento persistente en memoria (PMEM): qué es y cómo se usa

La memoria persistente o PMEM se ha convertido en uno de esos conceptos de los que todo el mundo habla cuando se trata de rendimiento extremo, bases de datos en memoria o virtualización avanzada. No es solo “otra clase de RAM” ni “otro tipo de disco”: es un nivel nuevo en la jerarquía de memoria y almacenamiento que mezcla lo mejor de ambos mundos.

Comprender qué es realmente la memoria persistente, cómo funciona y en qué se diferencia de la DRAM tradicional, de los SSD NVMe o del almacenamiento en la nube es clave para tomar decisiones técnicas con cabeza. En este artículo vamos a bajar a tierra el concepto, ver sus modos de uso (memoria, App Direct, vPMem, vPMemDisk…), cómo se integra en Windows, Linux, vSphere y entornos de contenedores, además de los casos de uso reales y sus limitaciones.

¿Qué es la memoria persistente (PMEM o PMem)?

La memoria persistente es un tipo de medio de almacenamiento no volátil que se presenta físicamente en forma de módulo DIMM, es decir, se coloca en las ranuras de memoria estándar del servidor junto con la DRAM. A diferencia de la RAM clásica, conserva su contenido incluso tras un apagado, reinicio, corte de luz o bloqueo del sistema.

Su comportamiento está a medio camino entre memoria y almacenamiento: es más lenta que la DRAM pura, pero muchísimo más rápida y con menor latencia que un SSD, incluso NVMe. Al estar instalada en el bus de memoria, los datos están mucho más cerca de la CPU que en cualquier unidad de almacenamiento tradicional, por lo que el acceso se mide en nanosegundos y no en microsegundos o milisegundos.

Los módulos de memoria persistente tienen capacidades muy superiores a las de la DRAM (128 GB, 256 GB, 512 GB por módulo son tamaños habituales), un coste por GB bastante menor que la RAM, aunque todavía por encima de los SSD NVMe. Por eso se usan como un nivel intermedio: ampliar memoria a lo bestia sin pagar lo que costaría todo en DRAM pura, y al mismo tiempo ganar velocidad frente al almacenamiento clásico.

Otro punto clave es la persistencia: los datos permanecen grabados incluso si el sistema se apaga de forma controlada o por un fallo eléctrico. Eso permite usar PMEM como almacenamiento extremadamente rápido para estructuras críticas (metadatos, tablas de asignación, bases de datos en memoria, logs de transacciones, etc.).

Conceptos básicos de PMEM y modos de acceso

La memoria persistente no se usa igual que la RAM normal. Dependiendo del sistema operativo y la plataforma, se puede exponer como almacenamiento en bloques, como memoria direccionable por bytes o como una mezcla de ambas. Aquí entran en juego varios conceptos fundamentales.

Métodos de acceso en Windows y Linux a PMEM suelen dividirse en dos grandes familias:

• Acceso en bloque (Block Access), donde la PMEM se comporta como un dispositivo de almacenamiento “clásico” que pasa por el sistema de archivos y la pila de almacenamiento.
• Acceso directo tipo DAX (Direct Access), donde se expone como memoria direccionable por bytes, evitando buena parte de la pila de almacenamiento y reduciendo aún más la latencia.

En el modo de acceso en bloque, la PMEM puede formatearse con sistemas de archivos como NTFS o ReFS en Windows, o EXT4/XFS en Linux, y se usa como si fuera un disco extremadamente rápido. Es el modo recomendado cuando se busca compatibilidad y sencillez, sobre todo en servicios que no están optimizados específicamente para memoria persistente.

En el modo DAX, la aplicación accede a los datos mapeando directamente la memoria persistente en su espacio de direcciones. El acceso es de tipo “memoria” y no de tipo “bloque”, con una latencia mínima. Eso sí, si no se programa y configura correctamente, se corre el riesgo de perder datos en caso de escritura incompleta, por lo que se recomienda combinar DAX con mecanismos como la Block Translation Table (BTT) o tablas de traslación de bloques.

Regiones, espacios de nombres y PmemDisk

Los módulos físicos de PMEM rara vez se gestionan uno a uno desde el sistema operativo. Normalmente se agrupan para aumentar rendimiento, capacidad o facilitar la administración, y ahí entran varios conceptos.

Una región de memoria persistente es un conjunto de uno o varios módulos agrupados, a menudo configurados en el BIOS o UEFI del servidor. Es frecuente que formen un conjunto intercalado (interleaved set), de forma que direcciones de memoria consecutivas se reparten entre varios módulos para aumentar el ancho de banda disponible.

En plataformas como Windows Server y Azure Local, sobre esas regiones se definen discos lógicos llamados PmemDisk. Un PmemDisk no es más que un intervalo contiguo de direcciones de memoria no volátil que se presenta al sistema como si fuera una unidad de disco o una LUN.

Cada módulo de memoria persistente contiene un área de almacenamiento de etiquetas (Label Storage Area, LSA) donde se guardan los metadatos de configuración (espacios de nombres, pertenencia a regiones, etc.). Herramientas como los cmdlets de PowerShell (Get-PmemDisk, Get-PmemPhysicalDevice, Get-PmemUnusedRegion, etc.) permiten ver qué módulos físicos participan en cada PmemDisk, revisar su estado y crear o eliminar discos lógicos de memoria persistente.

En entornos ESXi/vSphere, la idea es similar, pero la terminología cambia: se habla de espacios de nombres PMem que el hipervisor detecta y combina en volúmenes lógicos mediante tablas GPT. Estos volúmenes se montan como almacenes de datos PMem que luego se exponen a las máquinas virtuales como vPMem o vPMemDisk.

Tabla de traslación de bloques (BTT) y seguridad de datos

Un detalle delicado de la PMEM frente a un SSD es que los módulos de memoria persistente no incluyen de serie el mismo tipo de protección frente a “escrituras parciales” o torn writes que podemos encontrar en muchas unidades flash empresariales.

Si se produce un corte de energía o un cuelgue del sistema justo a mitad de una operación de escritura, es posible que parte de los datos nuevos se graben y parte de los antiguos se mantengan, dejando sectores en un estado inconsistente. Para reducir este riesgo se utiliza la Block Translation Table (BTT), una capa que ofrece semántica de actualización de sector atómica.

BTT actúa como un traductor entre direcciones lógicas y físicas y asegura que, para las aplicaciones, las escrituras parezcan de tipo “bloque tradicional”: o se completan completamente o no se ven. Activar BTT es muy recomendable tanto en el modo de acceso en bloque como en DAX, sobre todo porque incluso cuando los datos de la aplicación se acceden con semántica de memoria, los metadatos de los sistemas de archivos siguen usando un modelo de bloques.

En Windows, BTT es una propiedad del PmemDisk, por lo que debe habilitarse en el momento de su creación (por ejemplo, con New-VHD ... -AddressAbstractionType BTT) o bien convertir un disco ya existente a BTT con Convert-VHD. Tras la conversión, conviene regenerar el identificador de espacio de nombres con Set-VHD -ResetDiskIdentifier para evitar conflictos si coexisten ambos discos en la misma máquina virtual.

Hardware de memoria persistente: NVDIMM y Optane

La memoria persistente no es una única tecnología física, sino una familia de soluciones que se comportan de manera similar desde el punto de vista del sistema operativo. Entre las más conocidas encontramos:

• NVDIMM-N: módulos que combinan DRAM con NAND flash, respaldados por batería o supercondensadores. Al encender, el contenido se carga en DRAM; al apagar o perder la alimentación, se vuelca a flash.
• Intel Optane DC Persistent Memory (DCPMM): módulos basados en tecnología 3D XPoint, diseñados para aportar latencias cercanas a la memoria y una capacidad muy superior a la DRAM.

En Windows Server 2016 y 2019, Azure Local y otras plataformas, el soporte para estos módulos varía según la versión, pero la idea general es la misma: se pueden usar como memoria persistente pura (App Direct) o como memoria “extendida” (modo memoria).

Optane DC PMem permite tres grandes modos de funcionamiento, que suelen configurarse en la BIOS del servidor:

• Modo Memoria (Memory Mode): la PMEM actúa como memoria principal de gran capacidad, mientras que la DRAM se usa como caché rápida para los datos más calientes. En este modo la memoria se comporta como volátil; si se corta la alimentación, se pierden los datos.
• Modo App Direct (o Directo de la aplicación): la PMEM se expone como memoria persistente no volátil, accesible por el sistema operativo como regiones de almacenamiento o memoria direccionable por bytes. Es el modo interesante para bases de datos en memoria, almacenamiento ultrarrápido y cargas de trabajo sensibles a la persistencia.
• Modo Mixto: una parte del módulo se reserva para Memory Mode y otra para App Direct, permitiendo equilibrar capacidad de memoria volátil ampliada y almacenamiento persistente.

Conviene no confundir el “modo Memoria” con DAX. El modo Memoria trata la PMEM como RAM más lenta y pierde persistencia, mientras que DAX es un modo de acceso a volúmenes persistentes que sí conservan los datos entre reinicios.

PMEM en entornos de virtualización (vSphere y ESXi)

En vSphere, la memoria persistente está soportada desde la versión 6.7 y posteriores. En estos entornos, los módulos PMEM del host se presentan como un almacén de datos local de alta velocidad que las máquinas virtuales pueden consumir de dos formas.

vPMem (memoria persistente virtual) expone la PMEM al sistema operativo invitado como un NVDIMM virtual. Desde el punto de vista de la VM, parece que el host tiene módulos NVDIMM físicos, lo que permite al sistema operativo invitado y a las aplicaciones acceder a la memoria persistente en modo direccionable por bytes.

vPMemDisk (disco de memoria persistente virtual) funciona de otra manera: la memoria persistente se presenta como un disco SCSI virtual cuyo contenido vive físicamente en el almacén de datos PMem del host. Para sistemas operativos antiguos o aplicaciones que solo entienden discos, esta opción es muy útil.

La reserva de PMEM para una máquina virtual se realiza en el momento en que se crea su disco vPMem o se añade el dispositivo vNVDIMM, y permanece reservada para esa VM tanto si está encendida como si está apagada, hasta que se elimina o se migra. En clústeres, la suma de PMEM consumida por todas las VMs no puede superar la cantidad total disponible en el conjunto de hosts.

Respecto a la alta disponibilidad y la migración, hay varios matices: una VM con vPMem solo puede migrarse a un host que disponga también de PMEM disponible, mientras que una VM con vPMemDisk puede moverse a un host sin PMEM si se replica o mueve el disco a otro tipo de almacenamiento mediante Storage vMotion.

Un punto importante es que PMEM es almacenamiento local al host, y las soluciones de backup o replicación que asumen un almacenamiento tradicional pueden no funcionar directamente. Además, en escenarios de fallo severo del host se puede perder el contenido si no se ha diseñado una estrategia de protección adecuada.

PMEM en Windows Server, Azure Local y Storage Spaces Direct

Windows Server 2019 y Azure Local integran la memoria persistente con Storage Spaces Direct (S2D), que es la tecnología SDS (almacenamiento definido por software) básica en estos entornos. Aquí la PMEM puede jugar el papel de nivel de caché ultrarrápido para el resto de unidades.

Storage Spaces Direct entiende cuatro tipos principales de unidades: PMem, NVMe, SSD y HDD. En función de la combinación, el sistema configura de manera automática qué tipo de disco se usará como caché y cuál como capacidad, siguiendo una jerarquía: PMem > NVMe > SSD > HDD.

Algunas combinaciones típicas son:

• PMem + NVMe + HDD: PMem como caché superior, NVMe y HDD como capacidad.
• NVMe + SSD: NVMe como caché de solo escritura para SSD.
• SSD + HDD: SSD como caché de lectura y escritura para HDD.

Cuando la caché se sitúa por encima de unidades flash (NVMe sobre SSD, por ejemplo), se configura en modo solo escritura. Las lecturas se sirven directamente desde las unidades de capacidad porque su latencia ya es muy baja, y así la caché se puede dedicar a consolidar escrituras y reducir el desgaste.

Cuando la caché está por encima de HDD, actúa en modo lectura y escritura: almacena lecturas frecuentes para evitar accesos aleatorios al disco mecánico y absorbe ráfagas de escritura, reordenando las operaciones para que lleguen a los discos en patrones lo más secuenciales posible.

En escenarios con NVMe, SSD y HDD mezclados, las NVMe suelen servir como caché tanto para SSD (solo escritura) como para HDD (lectura y escritura). El sistema enlaza dinámicamente unidades de caché con unidades de capacidad a razón de 1:N, y reequilibra la asignación cuando se añaden o retiran discos.

Si fallan unidades de caché PMem o NVMe, los datos que todavía no han sido descargados a las unidades de capacidad se pierden solo en ese servidor, pero las copias redundantes en otros nodos del clúster (por ejemplo, en una configuración con reflejo triple) permiten a Storage Spaces Direct reconstruir la información automáticamente.

Memoria persistente en Linux (ejemplo: Red Hat Enterprise Linux)

En entornos Linux empresariales como RHEL, la PMEM suele presentarse como dispositivos /dev/pmemX o como dispositivos NVDIMM gestionados a través de herramientas del kernel (por ejemplo, ndctl).

Red Hat y otras distribuciones permiten utilizar NVDIMM como:

• Almacenamiento de bloques tradicional, formateado con EXT4, XFS, etc.
• Memoria direccionable por bytes en modo DAX, montando sistemas de archivos con soporte directo sobre dispositivos pmem.
• Dispositivo raíz de sistema, instalando el propio sistema operativo sobre un NVDIMM para reducir drásticamente los tiempos de arranque.

Al igual que en Windows, se habla de memoria de clase de almacenamiento (SCM) para referirse a esta categoría de dispositivos que combinan almacenamiento y memoria. Los casos de uso más habituales son bases de datos extremadamente exigentes, cachés de alto rendimiento, colas de mensajería y sistemas que necesitan minimizar el tiempo de recuperación tras un reinicio.

PMEM frente a DRAM, SSD, HDD y NVMe

Para entender bien el valor de PMEM merece la pena compararla con las tecnologías que ya usamos a diario.

DRAM es la memoria más rápida de uso general en un servidor, pero también la más cara por gigabyte y completamente volátil. Su tamaño típico por DIMM (16, 32, 64, 128 o 256 GB) se dispara en precio según aumenta la capacidad, lo que limita cuánto se puede instalar antes de que el coste sea prohibitivo.

Los SSD y NVMe ofrecen persistencia y un rendimiento muy superior al de los HDD, pero siguen siendo dispositivos de almacenamiento “alejados” de la CPU: están conectados por SATA, SAS o PCIe, no en el bus de memoria. Sus tiempos de acceso, aunque buenos, no llegan a los de PMEM, que se acerca más al comportamiento de la RAM.

Los HDD siguen ganando por coste por TB y capacidad bruta, pero su latencia y su rendimiento aleatorio están a años luz de la DRAM y la PMEM. Por eso, en arquitecturas modernas, se reservan para capas frías de datos y se colocan por debajo de capas flash y/o PMEM.

PMEM se sitúa entre DRAM y NVMe: algo más lento que la memoria pura, pero con tamaños por módulo mucho mayores, precio por GB más ajustado y la ventaja de conservar datos. Frente a SSD y NVMe, ofrece latencias más bajas y la posibilidad de acceder por bytes, haciéndola ideal para cargas de trabajo en memoria, pero a un coste superior.

Casos de uso de memoria persistente

Las aplicaciones que más partido sacan de PMEM son las que combinan necesidad de velocidad y de durabilidad de datos, o las que necesitan enormes cantidades de memoria sin que el coste se dispare.

Algunos ejemplos habituales de uso son:

• Bases de datos en memoria como SAP HANA, Oracle In-Memory, REDIS o MSSQL con optimización para PMEM.
• Cargas de trabajo de big data (Hadoop, Spark, análisis masivo) donde interesa tener conjuntos de datos enormes listos en memoria al arrancar.
• Plataformas de virtualización que quieren reducir la latencia de almacenamiento para ciertas VMs críticas.
• Aprendizaje automático e IA, donde el acceso ultrarrápido a conjuntos de entrenamiento puede disminuir considerablemente los tiempos de entrenamiento.
• Secuenciación genómica y análisis científico, donde se manejan datasets grandes y muy sensibles al tiempo de procesamiento.
• Procesamiento de datos IoT en tiempo real, para reaccionar rápidamente ante eventos masivos generados por sensores.
• Edición y renderizado de vídeo profesional, al acelerar acceso a ficheros grandes y proyectos complejos.
• Juegos y motores gráficos en entornos de servidor o cloud gaming, para minimizar tiempos de carga de niveles y activos.

A nivel de infraestructura, también se utiliza como capa caché persistente por encima de NVMe/SSD/HDD en sistemas como Storage Spaces Direct, asegurando que los datos recientemente escritos o leídos estén tan cerca de la CPU como sea posible sin renunciar a la tolerancia a fallos.

Almacenamiento persistente en aplicaciones y contenedores

Cuando hablamos de almacenamiento persistente en el mundo de las aplicaciones web y los contenedores, el foco no está solo en la PMEM, sino en cualquier mecanismo que garantice que los datos sobreviven a reinicios, despliegues y actualizaciones.

En aplicaciones monolíticas clásicas, el servidor y el almacenamiento suelen ir “de la mano”, así que acceder a un disco local o a una SAN es relativamente sencillo. Pero cuando pasamos a arquitecturas distribuidas o microservicios en múltiples regiones, la cosa se complica: el sistema de almacenamiento debe estar disponible globalmente, mantener la consistencia y soportar fallos parciales.

Con la llegada de los contenedores (Docker, Kubernetes, etc.), el problema se agudiza. Los contenedores son, por naturaleza, efímeros y sin estado. Si se destruye un contenedor, se va con él todo lo que estuviera solo en su sistema de archivos interno.

Por eso se usan volúmenes y volúmenes persistentes. Un volumen estándar en Docker puede sobrevivir al reinicio de un contenedor, pero si se elimina el contenedor y se borra el volumen asociado, los datos se pierden. En cambio, los volúmenes persistentes (o montajes de tipo bind) se ubican fuera del sistema de archivos del contenedor, en el host o en un backend de almacenamiento remoto, y persisten incluso si la aplicación se recrea.

Plataformas como Kubernetes introducen el concepto de PersistentVolume (PV) y PersistentVolumeClaim (PVC) para abstraer el almacenamiento físico (puede ser HDD, SSD, NAS, SAN, NFS, soluciones cloud o incluso PMEM en el host) y permitir que las aplicaciones pidan “x gigas de almacenamiento persistente” sin saber qué hay por debajo.

Proveedores como Kinsta o similares utilizan volúmenes persistentes de Kubernetes

para que las aplicaciones alojadas conserven sus datos de forma fiable. Desde el punto de vista del desarrollador, se define el tamaño y el tipo de volumen, y la plataforma se encarga de mapearlo al almacenamiento físico correcto.

En este contexto, la PMEM podría actuar como un backend ultrarrápido para volúmenes persistentes específicos (por ejemplo, para bases de datos intensivas en I/O), mientras que el resto de los datos se alojan en SSD o HDD, logrando un equilibrio entre prestaciones y coste.

Tipos y arquitecturas de almacenamiento persistente

Más allá del hardware concreto, el almacenamiento persistente puede organizarse en distintas arquitecturas, cada una adecuada para determinados patrones de uso.

Arquitectura de objetos almacena los datos como objetos con metadatos y un identificador, en lugar de bloques o archivos. Es ideal para datos no estructurados (imágenes, vídeos, documentos) y se usa masivamente en nubes públicas (S3, Azure Blob Storage, etc.). Aquí la clave es la escalabilidad y la durabilidad, más que la latencia ultrabaja.

Arquitectura de bloques presenta el almacenamiento como bloques direccionables de tamaño fijo. Es el modelo clásico de discos y LUNs y el preferido cuando hablamos de HPC, bases de datos, edición de vídeo profesional o juegos porque ofrece baja latencia, alto rendimiento y operaciones paralelas de E/S bien controladas.

Arquitectura de archivos se basa en sistemas de ficheros compartidos o locales (EXT4, NTFS, NFS, SMB, etc.). Es cómoda para aplicaciones que necesitan manipular archivos con rutas, permisos y jerarquías, como CMS web, plataformas de colaboración, sistemas de contenido multimedia, etc.

La PMEM encaja sobre todo en los modelos de bloques y memoria por bytes, pero puede integrarse debajo de un sistema de archivos o incluso como backend ultrarrápido de soluciones de objetos, actuando como caché de metadatos o de datos calientes.

Ventajas y limitaciones de la memoria persistente

Las principales ventajas de la PMEM que suelen citarse en entornos empresariales son:

• Rendimiento muy superior al del almacenamiento tradicional, especialmente en lecturas/escrituras aleatorias pequeñas.
• Latencia reducida, al estar en el bus de memoria y poder acceder por bytes.
• No volatilidad: los datos persisten ante apagados, fallos o reinicios (en modos persistentes).
• Mayor escalabilidad de memoria a un coste por GB más bajo que la DRAM.
• Mejor TCO para escenarios donde ampliar DRAM sería prohibitivo pero un SSD NVMe no ofrece la latencia deseada.
• Opciones avanzadas de seguridad al poder cifrar los datos en módulos y ofrecer más protección a la memoria “en caliente”.

Aun así, tiene también sus inconvenientes y retos:

• Coste superior a SSD y NVMe, por lo que no tiene sentido sustituir todo el almacenamiento por PMEM.
• Compatibilidad limitada con cierto hardware, sistemas operativos o hipervisores, sobre todo en entornos antiguos.
• Capacidades y oferta de producto más reducidas, especialmente tras la discontinuación de líneas como Intel Optane.
• Complejidad de adopción: para sacarle todo el partido hace falta adaptar aplicaciones, ajustar sistemas de archivos y tener clara la estrategia de persistencia.

La realidad es que la memoria persistente tiene más sentido utilizada de forma estratégica: como caché ultrarrápida, como nivel de capacidad intermedio entre DRAM y NVMe, o como soporte específico para bases de datos y cargas de trabajo en memoria donde la velocidad y la persistencia compensan el coste.

Aunque productos icónicos como Intel Optane se hayan retirado, las necesidades que atacaba la PMEM siguen ahí: más memoria, más rápida, más barata que la DRAM y con persistencia. Es de esperar que nuevas generaciones de memoria de clase de almacenamiento, tecnologías de estratificación de memoria o soluciones híbridas sigan explorando este espacio entre la RAM clásica y el almacenamiento masivo.

El almacenamiento persistente en memoria (PMEM) y el concepto más amplio de persistencia de datos se han consolidado como piezas clave del puzzle moderno de la infraestructura: permiten construir sistemas más rápidos, escalables y resilientes, siempre que se entiendan bien sus modos, limitaciones y casos de uso adecuados, y se combinen con HDD, SSD, NVMe y almacenamiento distribuido de forma equilibrada.