DDN's cache wolves come howling out of the creek

WolfCreek, Data Direct Network’s burst buffer caching system, has arrived in the shape of the IME14K product – apparently ready to leap burning buildings, solve climate change, and make a $5m HPC cluster perform like a $100m one.

The idea here is that high-performance computing (HPC) is dealing with ever-bigger data sets, and the parallel file system repositories used can’t keep up with the compute clusters and their multiplying and hungry cores.

To get out of the IO-wait trap, solid state storage is needed plus software to put right parallel file system features that don’t suit HPC compute IO demands. Step forward DDN’s WolfCreek technology.

The Infinite Memory Engine (IME14K) has a client driver, a solid state cache, and an out-of-band and open API. It's "14K" suffix doesn't mean it's necessarily tied to DDN's SFA14K arrays.

"An IME14K creates a DDN pre-configured appliance leveraging the DDN 14K hardware and the IME software," said DDN chief marketing officer Molly Rector. "As IME pushes data from its solid state cache and into the parallel file system storage, that file system can be provided by DDN or an alternative provider."

DDN said the IME is, in principle, compute-, storage- and vendor-agnostic.

The background here is this:

"The DDN 14K platform is the name of the DDN custom-designed hardware (previously known as WolfCreek) upon which DDN is building several different appliances."

"For example, embedding the SFA operating system to create high-performance block storage which is the SFA14K, embedding IME software and loading with just SSD to make the IME14K appliance, or loading SFA operating systems and Lustre to make a Lustre appliance."

The IME14K burst buffer sits between a parallel file system (PFS) store and a compute cluster, providing read and write IO acceleration. It’s scalable to multiple TBs in size and protects its data with hash-based erasure coding.

The system buffers incoming writes and manages them, aligning fragmented data to striped writes, to accelerate PFS writes, and, DDN said, eliminates POSIX file locking penalties, with instant open/close.

DDN suggests that a compute cluster can get 25GB/sec bandwidth from a PFS storage system. With the IME14K interposed between the compute resource and the PFS that jumps to 50GB/sec ... yes, GB/sec not MB/sec. It claims the compute cluster could be operating at 6,250 IOPS without the IME and 12.5 million IOPS with the all-flash NVMe IME, a 2,000X acceleration.

If your HPC-style compute clusters are IO-bound then such claims need looking at.

The IME14K engine features:

• 4U dual controller enclosure with 14-core, dual socket, Haswell Xeon CPUs
• 48 x NVMe PCIE gen 3 4-lane 800GB or 1.6TB SSDs with performance increasing as the SSD number increases
• 2546GB DRAM per controller

"[The] IME14K can connect to a cluster via EDR (100Gbit/s) or FDR (56Gbit/s) Infiniband today," said Rector. "It will support 40 and 100GbitE in Q1 as well as Omni-Path as soon as Omni-Path begins shipping." Ditto for connection to back end parallel file system stores.

The out-of-band API is used to integrate with job schedulers and manage data flushing to the PFS and also pre-stage the IME cache for new jobs so that first reads are from the IME cache instead of the backing disk store if possible.

Where HPC-style jobs have spiking IO loads which causes PFS delays, the IME can soak them up without the users have to upgrade their PFS store to handle such peak loads.

The IME14K is designed to deliver up to 50GB/s of throughput. Additional appliances can be clustered up to well over 1TB/s throughput or to increase the capacity of the NVMe cache.

"Limited availability shipments begin in December as the NVMe devices become available. Full availability in Q1 2016," said Rector. "We are not quoting pricing at this time." ®