This article is more than 1 year old

Reg Vulture grills Xen hypervisor daddy on latest storage upstart

Coho Data techie gets technical on flash-disk rivals

Let's talk about VMAX, baby...

Now, regarding VMAX: That product is the storage equivalent of a Boeing 747.  There are few things that people have ever asked a monolithic storage system to do that can't be configured on the VMAX given enough patience and a sufficiently large professional services budget.

Getting into a race for feature parity with VMAX is a fool's errand; it is a mountain of work that ends up with you having a VMAX. Instead, our focus is on giving customers the specific core features that they want from sophisticated systems like VMAX without giving them Stockholm Syndrome along the way.

MicroArrays

El Reg: Coho seems to ignore mainstream suppliers scale-out storage offerings, such as EMC Isilon and NetApp's Clustered ONTAP. Why is its scale-out design and product better than those established suppliers?

AW: I'm surprised at this characterization. These are the two vendors that we most frequently run up against in the field.

The best answer to this question is probably for you to go do the same thing that I've done over the past few years, which is to talk to a whole lot of customers of both of those systems. My experience is that many of those customers are in varying stages of anger, frustration, and then eventually melancholy resignation.

Now it's easy for me to throw rocks as a relatively new vendor with a smaller install base, and less architectural burden to manage my way through.  However, these customers repeat the same points again and again: They are upset at the painful machinations of having to lease an entirely separate array in order to do a mandatory upgrade to cluster mode on a system that they bought new less than two years ago. In the other camp, they are sad at what appears to be the steady, calculated atrophying of a really interesting clustered storage architecture so that they can be drawn back to the more mainstay traditional storage offerings from the more central appendages of the same vendor. Putting technical issues aside, I've talked to a lot of customers who are quite unhappy with their experiences owning both of the above systems.

More technically: our scale-out design is better because we are actively innovating on it. It's better because the integration with SDN switching means that we can make the scale of the NFS controller, namespace, layout, and dynamic connection management all automated and dynamic. It's better because we are doing live analytics on storage workloads to specialize and respond to them on a workload-specific basis in production systems (this point is not nonsense, see the OSDI paper I mentioned above).

Our scale-out design is better because it is designed to be scale-out from the beginning, and because it's had the luxury of learning from the insights and errors of a lot of systems that have come before it.

El Reg: What is the practical maximum number of MicroArray nodes and how do they communicate to offer a consistent single pool of storage?

AW: Practical is the right qualifier here: We test to 20 nodes today. That's 40 x 10Gb ports serving what appears to be a single NFS target on a single IP address with 400Gb of aggregate physical connectivity into a single shared namespace. In the current packaging, that's about 25 TB of usable flash and 480 TB of usable disk.

As we cross 24 micro arrays, we will be using half of the ports on a redundant pair of active/active 48-port switches to expose storage connectivity. Beyond that point in scale, we expect to take on more work to our placement logic to embed more topology information, making the system more “rack-aware" with regard to placement, traffic management, and recovery in order to do things like managing east/west traffic across the SDN ToR (Top of Rack) switches.

We do component-wise test and system simulations to much larger scales than 20, and the system is designed for significantly larger deployments. The performance that we achieve off of the current offering is meeting enterprise customer needs at well under the scale that we are testing to.

We are working with several customers that will push us to significantly larger scale than this over the next year.The all-flash product that we will be releasing next will be accompanied by an independent all-disk capacity node that can be used to let larger customers scale the two aspects of their storage environment independently.

El Reg: For cloud service providers SolidFire has a scale-out all-flash array that scales to 100 nodes and has quality of service features. How does the MicroArray compare and contrast to that?

AW: Solidfire's offering is a great example of a newer-generation storage product, and one that was built from the ground up for scale out. I have an enormous amount of respect for what Dave Wright has done with that product, so don't expect a particularly adversarial response here:

Coho DataStream 1000

Coho DataStream 1000

Solidfire is iSCSI and we are NFS.  They are focused on allowing cloud service providers to resell a block-level abstraction (iSCSI LUNs) to their customers.  The focus on QoS is very important in that context, because it lets them set SLAs on clearly defined pieces of storage that are being leased on contract to customers.

We are providing a scalable network attached file system. Interestingly, a bunch of our customers have similarly turned out to be cloud hosting providers.  Here are the things that they seem to really like that are different:

  • Autotiering allows us to deliver better value, because we can put colder data on cheaper storage.
  • Heterogeneous clusters mean that they don't have to worry about being locked to a specific product generation.
  • Files means that they can use us for more than virtual machine image storage, and we will evolve to provide additional APIs for things such as S3 on top of the same platform.

In both cases, I suspect that customers like the ability to evolve their systems over time, and to take advantage of both continuously falling prices on flash and of the fact that ISPs/CSPs have highly volatile needs in terms of taking on new kit. I think that both SolidFire and us are focused on supporting that dynamic model of environmental evolution.

El Reg: VMware is leading the Virtual SAN charge with its Virtual SAN product and also its EVO: RAIL scheme for virtual SAN-using hyper-converged systems. Nutanix and Simplivity are the leading startups in the hyper-converged space and HP has lately joined in with its StoreVirtual appliance products. How do the MicroArray and Coho Data stack up against these suppliers and the whole server-side SAN idea?

Coho_Schematic

AW: Fully converged servers make sense when you are only deploying a small number of servers.  This is the market that, despite how they may portray themselves, the hyperconverged vendors sell into. It's a perfectly fine market, but it's not one that we are chasing.

As soon as you have scale beyond a very small number of physical servers, why would you commit to scaling compute, storage, and connectivity in equal proportion?  Applications don't consume resources like that.  Moreover, flash (unlike disk) is increasingly the most expensive component in a server, making it look a lot like CPUs were when we first did CPU virtualisation.

There are several other reasons to architect storage independently from compute in a data centre environment of even partial rack-scale. I think we will start to see more and more architectures that apply converged/hyperconverged ideas at that scale, as opposed to restricting themselves to myopically restricting themselves to a single server chassis as the domain of convergence.

There's a wordier version of this argument here.

El Reg: What channels does Coho use to get to market and in which geographies is its product available?

AW: Direct in North America and UK today and via strategic system integrator partner in Japan.  Broader global expansion [is coming] in 2015. ®

* Bootnote: What's in a name

Male breeding Coho Salmon

Male Coho salmon

Coho is named for the salmon that swim upstream to spawn in rivers flowing into the North Pacific Ocean. These rivers flow into the Pacific along the western coast of the USA down to Monterey Bay and so include the coast west of Silicon Valley. They are found in British Columbia, where the startup has a Vancouver base.

More about

TIP US OFF

Send us news


Other stories you might like