Portworx to add application profiles to persistent container storage
Container persistent storage specialist Portworx plans to add application-specific profiles to its software.
Portworx is a software-defined product that provides persistent storage capacity for applications that use Kubernetes container orchestration.
CTO Gou Rao could not be exact about timescales but said customers could expect application profiles to be built into Portworx starting in about nine months. “In providing automated storage for Kubernetes implementations we’ve learned a lot about the application layer,” he said.
“So, for example, with ElasticSearch the question arises how do you shard the database, how do you best provision storage for that application?”
Rao also mentioned Kafka and Postgres as other applications for which profiles would be built into Portworx, which works from within the Kubernetes cluster, running in worker nodes, to provide persistent storage to containerised applications.
Rao makes very clear the distinction between storage built in this way and the use of external – SAN and NAS – shared storage.
“People need Portworx when they deploy applications to Kubernetes because an application is not just one machine that can use storage from one machine, but is made of many components on many systems. So, the storage needs to have knowledge of that.”
Rao provides the example of taking snapshots of a Cassandra database that could be distributed across many Kubernetes nodes. To be able to track the many components and their states the storage needs to be integrated with the Kubernetes control plane, he said.
Rao is keen to spell out why he thinks traditional external storage isn’t up to the job with containerised applications.
“You can run into a variety of problems with SAN and NAS. For example, with failover you can get something that can’t run on a node because of a shortage of resources, so the data becomes unavailable and you get the ‘stuck volume’ problem, which is probably the number one issue with storage on Kubernetes.”
So, the solution, said Rao, is storage that runs alongside Kubernetes and shares its application-defined control plane, which traditional storage cannot.
When Persistent Volume Claims meet Portworx, PVs are created by agents that help build capacity from storage comprised of hardware drives, cloud capacity or virtual drives such as VMware VMDKs and made available.
Portworx volumes are replicated within the cluster synchronously and asynchronously between clusters for DR, as well as passively replicating to an external object store for backup.
Features in Portworx include PX-Backup which allows users to see and manage their backups.
There is also Autopilot, which is a rules-based engine that can manage capacity and performance. It can, for example, expand capacity or tier data between media if certain thresholds are exceeded. An example would be, “If a PVC exceeds X% usage, expand storage capacity by X%.”
Portworx’s approach to persistent container storage sits alongside the likes of StorageOS and Rook in that it runs in a containerised fashion in Kubernetes and builds the storage control plane into it.
It is also possible to use mainstream hardware or software-defined storage products to expose capacity from them as a PV. That is done using the Container Storage Interface (CSI), which numerous storage suppliers – more than 60 at the time of writing – have written APIs for Kubernetes.