It was one of the big surprises of the recent KubeCON show in Amsterdam – dedicated to all things Kubernetes – when customers that asked about NetBackup’s container backup capabilities were told they should deploy Veritas’s InfoScale software-defined storage for Kubernetes instead.
Directly competing with Pure Storage’s Portworx, InfoScale offers block storage for applications that run in containers.
InfoScale makes the point that it is closer than Portworx to the Linux kernel that runs Kubernetes clusters and is aimed at input/output (I/O)-hungry applications, and reads and writes at the minimum possible latency.
“Infoscale has all the functionality you want in a SAN solution,” said Petter Sveum, chief architect for infoScale at Veritas.
“That includes writes to mirrors on several nodes for redundancy, synchronised locally or replicated to another datacentre,” he said. “And we use an erasure coding algorithm with a load-balancing mechanism so you can continue to access your data when you’ve lost a disk, a node or a cluster of nodes.”
At root, a Kubernetes cluster runs short-lived containerised applications, where – as originally conceived, at least – their data disappears when runtime is done. That principle is well-suited to web applications that exist for as long as needed according to user demand.
On the other hand, containers are not well-suited to traditional datacentre applications that backup data from every session and must recover and restart operations when the need arises.
However, enterprises increasingly want to run legacy applications in containers, which is often less expensive than using virtual machines.
“Our first customers for InfoScale are banks and telcos that want to migrate applications and databases of several TB from VMware or OpenStack to Kubernetes,” said Sveum. “With block storage that integrates with Kubernetes via a CSI driver you can eliminate the constraint of having to use object storage. All the storage array makers offer a CSI driver, but ours has the merit of being compatible with all disk arrays. It’s universal.”
InfoScale can provide a pool of SAN storage made from arrays from different makers, as well as work cloud/container-native, and not just via CSI.
“Our additional advantage – and this is why enterprises often come to us – is that migration is easy via NetBackup, which can save and restore from deduplicated snapshots,” said Sveum. “That means you can get on with restoring applications without stopping those that are running. And it can be done quickly and save on network bandwidth.”
Sveum pointed out that NetBackup and InfoScale are independent. The former can backup storage systems for Kubernetes while the other can be backed up by any software.
For now: 16 nodes maximum
InfoScale comes with an admin console that allows division of global capacity into volumes – or persistent storage classes in Kubernetes-speak – that can have differing characteristics, such as writes to mirrors, deduplication, sharing or not between several pods and by quality of service.
So, if an application is deployed via container with a config file that assigns access to persistent storage, InfoScale applies all the necessary rules without the user knowing.
The console can integrate with OpenShift’s Kubernetes for Red Hat. Veritas points out that InfoScale is also useable with any other Kubernetes that the admin wants from the command line and future versions will integrate with other consoles.
Red Hat also makes persistent storage for Kubernetes in the form of Ceph, but with differences, said Sveum.
“Ceph isn’t as fast as InfoScale,” he said. “That’s in part because its storage nodes work via a network protocol, whereas InfoScale presents storage as if it was integrated with the server. Also, Ceph is primarily an object storage system with gateways that access data in block or file mode.”
InfoScale offers performance, but perhaps less elasticity. For now, InfoScale can’t manage more than 16 nodes of storage, which contrasts with hundreds in Ceph.
“It’s a limitation that we’re working on,” said Sveum. “We will soon offer the possibility of InfoScale clustered clusters. But for now, the limitation is not too annoying in the sense that you only usually have the need for lots of I/O for one application and not for several of them that need to talk to each other. It’s enough, therefore, to provide a different InforScale storage cluster for each application that needs speed.”
