Third time lucky? Plucky upstart Infinidat plonks down monolithic array

As a CTO, that isn't a very smart thing to say. It is downright irresponsible to call out storage controller functionality running on the server as not a good datacenter practice. You are after all doing nothing more than what DDN can deliver -- large capacity/high sequential B/W SANs.

> CTO Brian Carmody said: “Enterprises want packaged systems. SW-defined storage is like communism. It looks really good on paper but not so good in practise. There’s integration risk for customers. It’s the most un-cloud-like proposition you can make.”

Calling Nimble Nick and Noisy Nutanix to comment & more

This looks awfully similar to how Nimble does their data organization on disk (reads cached on DRAM/Flash and data is checksummed, coalesced before written to disk with parity using a log structured model).

The differences seem superficial ... non-deterministic drive selection. How do do they do garbage collection to avoid a whole bunch of junkie data from causing massive fragmentation issues?

How are they ensuring consistency on the front end? Is it using scale-out structure similar to Nutanix (3 nodes and up)? It would make sense to have the storage controllers share metadata using an efficient datastore like Redis or Cassandra with added Paxos functionality (Nutanix guys documented this in the Nutanix bible).

--

The way data is stored is unique. Incoming data is split into 64KB sections and the system is, below the protocol drivers, simply a collection of 3.125 billion of these sections. Concepts such as hosts and volumes don’t apply to the caches and disk drives. Each section is given a checksum and an activity vector (AV) score.

This AV score relates to the IO activity for a section and a heuristic map of inferred relationship to other sections, with the aim being to keep an application’s hot working set data in cache as its workload develops. The aim is to have all read requests be served from DRAM or NAND cache.

The system’s software groups 14 sections with similar AV values into a stripe, and two parity sections are computed to create a 16-way stripe for persistence to disk.

Next, 16 disk drives are chosen from the disk pool and the 16-way stripe is written. We’re told there is non-deterministic drive selection, log-structured writes and statistically uniform utilisation of drives.