Containers began life as a lightweight, supremely portable way of running applications. So lightweight, in fact, that even the storage they required lived and died along with the container.

But that didn’t cut it for enterprise applications built to handle the most mission-critical and sensitive transactions out there today.

So now, container storage needs to be persistent but it also needs to sacrifice none of the portability that containers were originally designed for. It should be built from the ground up as storage for Kubernetes – to run in Kubernetes, in fact – be cloud native and capable of carrying application storage profiles to wherever it runs, on site or in the cloud.

That is according to Robin Systems, which showcased its Robin.io during the recent virtual edition of the IT Press Tour, and whose product is aimed at enterprise database, big data and search/indexing, with financial services and telco/5G companies particularly in mind.

Stateful applications need a cloud-native storage stack,” said Robin founder and CEO Partha Seetala, who acknowledged that Robin is in a market that has “15-ish” container storage providers vying for market share.

According to Seetala, persistent storage for Kubernetes should provide data availability across any pod, server, location (cloud, on-site) etc with failover between them, should provide predictable application performance, advanced storage features such as snapshots, clones, backup and disaster recovery and be manageable by non-storage expert staff.

That’s what Robin.io aims to provide.

The so-called Robin CNS (Cloud Native Storage) works with any supplier’s Kubernetes deployment and provides storage volumes (via Kubernetes Persistent Volume Claims – PVCs) to any application that needs stateful/persistent storage.

It claims customer deployments as large as 6PB – at Palo Alto Networks in a big data implementation, for example.

On install, Robin CNS deploys an operator that discovers and pools storage media, whether on local disk or cloud.

A key attribute aimed for by Robin is that the storage is application-aware, which means storage performance profiles are at the centre of the way the product provisions physical capacity, and therefore also how it rebalances and fails over during performance peaks and production events that affect storage.

So, for example, storage can be provisioned according to application performance requirements, with live rebalancing taking place that takes into account the need to avoid I/O issues such as hotspots and noisy neighbours, but also to distribute storage between racks, sites, cloud zones, and so on.

All of this is carried out by defining storage volume profiles with storage capacity that can be grown and shrunk on the fly.

Robin auto-discovers all it needs to know about the (local and cloud) storage it can access and creates a Robin storage class which comprises the varying types of storage available and groups them under different Persistent Volumes (PVs).

These can then exposed to applications using the CSI (Container Storage Interface). Persistent Volume Claims (PVCs) associated with applications and their needs are matched to PVs.

Key to defining an application’s storage requirements is its profile in the Kubernetes Helm chart, which is a YAML file that summarises the resources required to run the application and specifies its PVCs in terms of storage class and PVs.

That’s the heart of what goes on in Robin. Higher up the stack, there are advanced storage features, such as snapshots and backup. The company is considering a standalone backup product, but currently it is only available with the full storage product.

“Backup is tightly integrated with storage in Robin,” said Seetala. “But we are looking at it over the next few quarters.”

As well as the full enterprise version of Robin, there is a fully-featured Express product that is totally free but limited to five nodes or 10TB.

source