There has been a disruptive paradigm shift in data storage called Persistent Memory (PMEM) that resides between DRAM and disk storage in the data storage hierarchy. The technology enables byte addressable updates and does not lose data if power is lost. Instead of having nonvolatile storage at the bottom with the largest capacity but the slowest performance, nonvolatile storage is now very close to DRAM in terms of performance.

PMEM is a byte-addressable form of computer memory that has the following characteristics:

- DRAM-like latency and bandwidth
- Regular load/store CPU instructions
- Paged/mapped by operating system just like DRAM
- Data is persistent across re-boots

PMEM falls between the two ends of the spectrum, DRAM and Flash Storage. DRAM is expensive and volatile and Flash is cheaper, slower and persistent

VMware is working with a broad ecosystem including hardware vendors, OEMS and ISVs to develop and support PMEM. vSphere has been enabled to manage and expose the persistent memory feature to VMs. There are different ways in which one can leverage the PMEM feature in a virtualized environment and below are some of the use cases that elaborate them. These use cases are currently in the tech-preview mode:

• Faster storage for existing workloads
• Turbocharged performance for any application
• Reduced development time and costs with the PMEM Emulator

• Bring your legacy application on PMEM backed storage 
• Consolidate ‘PMEM’ aware application and ‘legacy’ applications on single infrastructure

vSphere can also slice a piece of the local persistent memory in a server and present it to a VM as a virtual NVDIMM. This is a new type of virtual device that exposes a byte addressable persistent memory to the VM. Virtual NVDIMM is compatible with latest Guest Operating Systems which support persistent memory such as Windows 2016, RedHat Enterprise Linux 7.4, etc. But, applications need not change and can still use legacy (block based) file interfaces like read, write, mmap.

• Unmodified applications get super-fast file access
• Applications that are modified to take advantage of PMEM get direct and uninterrupted access to hardware (SNIA Programming Model for reference)
• Applications storing all its Persistent state in PMEM can instantly restart after re-boot

Given that Persistent Memory hardware is not readily available and could be initially expensive for some of the ISVs, there is an option to experience the behavior of Persistent Memory using PMEM Emulator. The emulator uses a chunk of volatile memory and makes it behave like Persistent Memory. Following are the key value propositions of PMEM emulator:

• Works with existing servers, there is no need to wait for actual hardware availability to develop your application.
• Reduces the cost of development as you can provide development environment to R&D at a fraction of the cost
• Reduces overall development life-cycle with with agile creation and tear-down of development environment and recreating it, and no need to wait on the stabilization of hardware.
• Available for your development environment only, not a supported feature to run your production workloads.

To illustrate the benefits of byte-addressable persistent memory, we took a popular open source application Redis and modified it to take full advantage of persistent memory. Redis is an open source, in-memory key-value store that is often used as a database, cache or message broker. Clients can establish a network connection to a Redis server and send requests of the form “set foo bar” (i.e., set the value of the key foo to be the string bar). Companies such as Twitter, GitHub, Pinterest, Sanpshot have or do use Redis as part of their infrastructure.

Redis, by default, only commits key-value transactions to memory. Persistence across reboot (e.g., due to power loss) is provided by periodically writing transaction logs to storage. By default, transaction log is written to storage every second. Therefore, Redis can lose a second’s worth of transactions in the default configuration.

Initially, we experimented by storing Redis transaction logs in persistent memory. That provided noticeable but marginal (around 12%) improvement in performance. Then, we decided to modify Redis to take full advantage of byte-addressable persistent memory by placing the entire key-value database in persistent memory. We call the modified version PMem-aware Redis. We added very low-overhead journaling to make Redis transactions on persistent memory crash consistent. With these changes, we got around 45% improvement in transaction throughput. In addition, PMem-aware Redis can recover from crash almost instantaneously because the database is already in persistent memory and need to be read from disk. For comparison, unmodified Redis using NVMe SSD can take minutes to recover after crash, even for modest (around 1 GB) database sizes. Finally, since persistent memory is local to a host, we experimented with replicating Redis transactions to a standby host. Even with replication, PMem-aware Redis performed around 28% better than unmodified Redis using a fast and host-local NVMe SSD without any replication.

For more information, please fill the short form. We will get back to you on reviewing this form. This page will be updated in the near future with more details, so please bookmark it!!!