Feeds

NetApp may serve app server flash cache

'Won't catch us with our Flash pants down' says NetApp

Next gen security for virtualised datacentres

Comment We've seen EMC and Dell looking to manage flash caches in application servers and contrasting this with NetApp's array controller Flash Cache strategy. Actually NetApp is involved with storage array management of flash caches in app servers - witness its Project Mercury presentation at the FAST '11 conference at San Jose in February.

A Reg commenter pointed this out, as did a NetApp person responding to the Dell server flash story, saying there's "no catching us with flash pants down".

The idea was to link a flash cache in the server to a shared, centrally-managed storage array so that virtual machines (VMs) and their storage could be moved between physical servers in a shared-pool datacentre without losing any I/O speed-up benefits from having a local flash cache.

NetApp Project Mercury schematic

NetApp Project Mercury code stack (NetApp)

NetApp devised its Mercury block-oriented, write-through flash cache as a KVM/QEMU block driver in a Linux guest VM. It provided an hg disk format and requests sent to the hg device were handed over to the SSD cache.

The cache was "warmed" (loaded) with a few days' activity and then NetApp engineers looked at the server I/O effects. There was a "nearly 40 per cent reduction in mean I/O service time" with a "near 50 per cent reduction of requests sent to [the] server." Almost all the reads were serviced from the Mercury cache.

Serial I/O showed a small improvement whereas random I/O had a substantial improvement.

Server flash cache or storage array flash?

These were measurements of server I/O with and without the Mercury cache. We don't know what the effects would be if the server with/without Mercury cache was compared to a cached server with/without a storage array with a Flash Cache in its controller and a storage array with/without SSDs as a drive tier.

It seems likely that a Mercury-cached server would have some read I/O improvement over a Flash Cached storage array controller but not that much, as we could assume the flash contents would be the same and the Mercury cache would be a few microseconds nearer the server DRAM in latency terms.

It would be a few more microseconds nearer the server's main memory than an SSD drive tier in a network-access storage array, assuming the data contents were the same again. Whether this latency improvement is significant or not intuition can't say; we need engineers and measurement to tell us that.

Judging by the existence of Dell, EMC, and NetApp work in this area, the indications are that it is significant.

Texas Memory Systems view

Jamon Bowen, Director of Sales Engineering at Texas Memory Systems, blogged on this topic, answering this question: "Doesn’t being on the PCIe bus increase performance by being as close to the CPU as possible?"

He wrote: "Yes, but nowhere near the degree it is promoted. Going through a HBA to FC-attached RamSan adds about 10µs of latency –that’s it. The reason that accessing SSDs through most SAN systems take 1-2 ms is because of the software stack in the SAN head – not because of the PCIe to FC conversion.

"For our customers the decision to go with a PCIe RamSan-70 for a FC/IB-attached RamSan-630 comes down to whether the architecture needs to share storage."

TMS is not working on a way to make its PCIe RamSan-70 card shareable: "If the architecture needs… shared storage, use our shared storage systems."

He is not saying server PCIe flash has no role in large scale server infrastructures needing co-ordination. This is how he sees that role:

In a shared storage model, a big core network is needed so each server can access the storage at a reasonable rate.  This is one of the main reasons a dedicated high performance Storage Area Network is used for the server to storage network.

However, after there are more than a few dozen servers, the network starts to become rather large.  Now imagine if you want to have tens of thousands of servers, the network becomes the dominant cost …  In these very large clusters the use of a network-attached shared storage model becomes impractical.

A new computing model developed for these environments – a shared nothing scale-out cluster.   The basic idea is that each computer processes a part of the data that is stored locally; many nodes do this in parallel, and then an aggregation step compiles the results. This way all of the heavy data to CPU movement takes place within a single server and only the results are compiled across the network.  This is the foundation of Hadoop as well as several data warehouse appliances.

In effect, rather than virtualized servers, a big network, and virtualized storage via a SAN or NAS array; the servers and storage are virtualized in a single step using hardware that has CPU resources and Direct-Attached Storage.

PCIe SSDs are important for this compute framework because reasonably priced servers are really quite powerful and can leverage quite a bit of storage performance. With the RamSan-70 each PCIe slot can provide 2 GB/s of throughput while fitting directly inside the server. This much local performance allows building high performance nodes for a scale-out shared-nothing cluster that balances the CPU and storage resources.

Otherwise, a large number of disks would be needed for each node or the nodes would have to scale to a lower CPU power than is readily available from mainstream servers. Both of these other options have negative power and space qualities that make them less desirable.

The rise of SSDs has provided a quantum leap in storage price-performance at a reasonable cost for capacity as new compute frameworks are moving into mainstream applications. 

A shared, centrally-managed storage array could conceivably pre-load the server PCIe caches in Bowen's shared-nothing, scale-out cluster model, but would then have no further role to play. We might think that TMS would see no role for shared storage in such clusters because it doesn't want to be beholden to suppliers of such systems for RamSan-70 sales.

It will be interesting see how HP, IBM and Oracle view the role of app server flash cache technology, and even more interesting to see server flash cache I/O behaviour with and without flash-cached and flash-tiered storage arrays. ®

The essential guide to IT transformation

More from The Register

next story
The Return of BSOD: Does ANYONE trust Microsoft patches?
Sysadmins, you're either fighting fires or seen as incompetents now
Microsoft: Azure isn't ready for biz-critical apps … yet
Microsoft will move its own IT to the cloud to avoid $200m server bill
Death by 1,000 cuts: Mainstream storage array suppliers are bleeding
Cloud, all-flash kit, object storage slicing away at titans of storage
US regulators OK sale of IBM's x86 server biz to Lenovo
Now all that remains is for gov't offices to ban the boxes
Oracle reveals 32-core, 10 BEEELLION-transistor SPARC M7
New chip scales to 1024 cores, 8192 threads 64 TB RAM, at speeds over 3.6GHz
VMware vaporises vCHS hybrid cloud service
AnD yEt mOre cRazy cAps to dEal wIth
prev story

Whitepapers

Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
7 Elements of Radically Simple OS Migration
Avoid the typical headaches of OS migration during your next project by learning about 7 elements of radically simple OS migration.
BYOD's dark side: Data protection
An endpoint data protection solution that adds value to the user and the organization so it can protect itself from data loss as well as leverage corporate data.
Consolidation: The Foundation for IT Business Transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?