Federation promises to bring your storage under control

Joined up but separate

Block buster

“Right now, storage federation is about consolidating storage used and latent consumption. It's an intriguing concept, but it is really just a step on a journey towards solving the inherent problems in architectures,” says Dave Leyland, who heads the next-generation data centre business unit at Dimension Data.

“The problem being that we have multiple types of storage, imperfectly allocated. I think it's all the same debate, but looking for different techniques to overcome the challenges.

“We are all trying to operate what we have and plan for the future at the same time. The importance is not storage virtualisation or storage federation, it's unlocking different consumption models. For instance, if you started today you wouldn't build Exchange servers and so on, you'd buy in and abstract services instead.”

Given that both federated storage and global file systems aim to solve the same problems, and that a layer of storage virtualisation underpins them both, how else can we differentiate between them?

One way – for now at least – is to think about blocks and files. Distributed file systems typically use network protocols rather than sharing block level access; although this is changing, and the newest distributed systems, such as Ceph, support file, block and object storage.

“I think there is less opportunity for global file systems in block storage workloads. The management benefits from global file systems are more for file-based workloads,” says Nunes.

“Global and distributed file systems are doing very well and have their uses, but it's a file system,” agrees Shendar.

“Only 20 per cent of our customers' capacity is block but it's 40 per cent of our revenue. Block has an out-sized importance, and that's why customers pay more for it. Federated is a distributed unified system, not just files.

“The other key difference is performance. A distributed file system takes time to move large files; it needs to move updates before others can work on them.

“The distributed file system's strength – that it is a big global repository – is also a weakness. It doesn't subdivide well, for example if you need two separate file systems for security reasons. Within my zones I want control, isolation, a guarantee of privacy, and so on.”

Better together

Looking ahead, it is clear that there is still a lot more more that can be done. We are not there yet, but if federated storage is built right it should be unified storage writ large.

It should not matter whether you need it for files or blocks – and of course in the future, unified storage will also need object capabilities too.

We are already seeing federated-type technology used to provide scale-out NAS and object-based storage, for instance, so this is already happening.

Much of today's federated storage is single-vendor, though, as are distributed file systems such as StorNext, though quite how much this matters is a moot point.

For instance, Nunes says it is possible to federate other vendors' storage with HP's, but that it makes the resulting system more complex and harder to maintain so HP will support it only within tight limits.

“We don't generally see people split projects between vendors,” he says. “When we have been asked to take a multi-vendor approach, we dig into the request and say 'Why do you want to federate VNX?'

"The answer is usually to enable simpler migration to 3PAR, so we do one-way online import, based on federation.”

Does that need to change? Perhaps, and with storage-independent virtualisation layers enabling federated functions to operate outside the vendors' walled gardens, most probably it will do.

And with the obvious overlaps, there could also be synergies from running a clustered or distributed file system on top of federated storage.

There is a journey ahead, to be sure, but we should see some great sights along the way. ®