Designing the next generation of our storage systems

Back from SC09, and for a project Vipin asked me to work on quickly, I am cranking out our roadmaps in greater detail. One of the things I’ve been thinking of for a long time is, what comes after JackRabbit and DeltaV? In the case of JackRabbit, even when it is hobbled by a poorly performing IB network (we are still working on why this is the case), we appear to kick some serious tail in the high performance cluster storage space … our worst case result was 4x faster than a competitors best case on the same problem (info was presented at SC09 in a public talk by the user, so I think its ok to talk about, if not, let me know and I’ll elide this). Though we should have been much faster than that, we have caching on the client side and on the back end server side largely turned off for the cluster acceptance test to run.

This is siCluster. We did do some PR at SC09, but it looks they went into a black hole, so we will have to work on re-issuing this. Probably wait till after thanksgiving in the US. This said, I’ll give you the internal project name we are using for the next gen. It is called rho (ρ). This is a very different system than anything on the market, and very different than anything we have heard of. Where the JackRabbit has RAID supers and hums along at a nice (ridiculously fast) clip, rho has … well … warp engines. There’s more, and yes, it is very cool. In all aspects. It is a ways out, and we will offer a nice transition plan for customers with siClusters and existing JackRabbit and DeltaV systems.