Panasas on server flash cache: 'What problem are you solving?'
We don't need the speed, we don't heed the feed
ISC12 Storage array feeding of server flash caches is not needed for high-performance computing because network latency is negligible - according to parallel storage biz Panasas.
Geoffrey Noer, Panasas's senior product marketing director, tells the Reg:
"We are not under pressure from our customers to deliver more performance. In principle we could extend PanFS to include cache in servers but what problem are you solving? We don't see the problem. For all general purposes the latency of the network is invisible. We haven't seen a need for customers to use flash because the file system is so fast."
In enterprise storage the idea that applications can be speeded up by getting rid of storage network latency is gaining ground. EMC is leading the mainstream storage array suppliers' charge in this area with its VFCache, the placement of a PCIe flash card into servers and software enabling it to cache data from an EMC storage array and give applications virtually instantaneous access to it.
This follows on from pioneering work by start-ups like Fusion-io, whose ioDrive PCIe flash card products are being used by Facebook and others to give array I/O-bound application software a swift boot up the rump. You would think that what works with enterprise IT would work in the HPC world as well, where application execution speed is important and hundreds of compute nodes access tens of petabytes of data.
Panasas builds ActiveStor 11 and 12 storage systems using its PanFS parallel file system to deliver up to 1,600MB/sec write IOPS per storage shelf and 1,500 read IOPS to HPC compute nodes. Its systems scale up both capacity and I/O performance to 150GB/sec of bandwidth yet use bulk 3TB SATA disk drives, far from the fastest horse around the storage block.
Noer doesn't discount the idea of server cache feeding in future though.
"Exascale is down the road," he says, meaning that what uses petaflops and petabytes of storage today will be using exaflops and exabytes in a few years' time.
This growth in storage needs by HPC customers can't be ameliorated by using deduplication and compression, both common tactics used by all-flash array startups like Solidfire. Noer adds:
"In HPC, deduplication and compression are negative performance factors. HPC workloads are not generally compressible."
Noer said that Panasas sees its customers' HPC workloads as different from the random I/O-intensive enterprise workloads which benefit from flash data access acceleration in servers.
IBM's HPC architect, Crispin Keable, says GPFS – IBM's General Parallel File System – already supports storage tiering and he thinks his customers would see appreciable application acceleration from having flash-enhanced servers. He can foresee benefits that could be gleaned from having GPFS look after that server cache, and mentioned the idea of GPFS using flash itself to store file metadata and so spend less time looking up files and more time reading and writing data for clients. Panasas founder Garth Gibson is of a similar mind.
There may well be workload differences between Panasas and IBM HPC customers behind the two contrasting viewpoints. With Panasas emphasising its commercial credentials as an HPC supplier more strongly and with Exascale "down the road", it will be interesting to see how things develop. ®
HPC has always been thus. I/O isn't random access to lots of little bits of data, it is massive broadside access to very very large lumps of ordered data. Latency of access is swamped by the transmission time. Optimising for access is simply missing Amdhal's Law. Most caching strategies don't apply. Data is very often only read once. Optimising data layout, order, prefetch, matching bandwidths, this is where you win.
Same for deduplication. Science data is inherently not internally correlated. Except for the case where finding hidden correlations is the entire point of the computation in the first place. Enterprise level dedupe doesn't get any traction at all, just slows things down and costs money.
Just the nature of the game.
Enterprise IT needs are just different from HPC
Hi! Some good comments here. The bottom line is that the requirements for Enterprise IT and HPC are normally very different from each other. So considering an Enterprise IT-focused flash-based storage system with features like compression and de-duplication, it’s pretty unlikely that such a product would be equally applicable to HPC storage. Flash is simply too costly for it to be used for the predominantly large file throughput requirements in HPC where storage is usually measured in a combination of GB/s and $/TB. However, there is a very interesting role to be played for flash memory in accelerating small file IOP-focused workloads in HPC. The same goes for speeding file system metadata performance which is useful for both large file throughput and small file IOP HPC workloads.
Re: Two points of view
An obvious fix for the performance increase/cache coherency issue is to increase the number of director blades for performance, but give them a dedicated 10GE or IB back-channel link to improve cache operations.
Load-balancing likely involves getting into the switch and controlling the load routing round-robin, if that is an option.
Of course, Panasas topology needs to support these types of approaches.