This blogpost will give you a Portworx overview. Portworx is an enterprise storage platform focusing on containers and cloud-native. The company was founded in 2014 with its first deployment in 2017. Its market share has grown rapidly and in 2020 it was acquired by Pure Storage. The acquisition is good news for the Cloud-born storage provider, which aims to challenge the big storage players by offering a Cloud-first approach for storing Cloud workloads.
Storage as commodity
Why would I need a storage platform? Isn’t storage commodity, boring, expensive, and yesterday’s news? According to an IDC report, revenues of enterprise storage companies are relatively stable (apart from Dell EMC, which suffered quite a decline in revenue in early 2020 and is fluctuating ever since).
In a traditional brick-and-mortar, on-premises environment, storage probably is a commodity (and yes, expensive and boring, even though the large vendors probably disagree). In a Cloud environment, however – particularly when containers are concerned, storage becomes quite a different beast.
Incompatible with a split second container world
A storage system you use on-premises as a static file archive is simply incompatible with the split-second container world. For example, containers are created and deleted rapidly, within minutes of each other, workloads shift at a high pace, and storage needs to be flexible and scalable enough to follow. And, contrary to traditional storage, a Cloud based storage system needs to be application-aware instead of file-aware.
Always on and always there
Cloud storage is always on and always there, preferably at a fraction of the cost of the old bunch of drives in an expensive cabinet as it is billed based on usage. Theoretically, storage could be cheap or based on cheap parts: if a drive fails, just replace it and let the software deal with keeping everything in shape.
But then, Cloud is all about abstraction. You take away what isn’t needed. This is exactly how Portworx started out: by offering developers a way to access storage without wondering where the drive is exactly (even geographically), what brand it is or how many RPM it spins at. And giving ops access to lightning fast spin-up, deployment and deletion of application storage.
The Portworx platform
The Portworx Kubernetes storage platform is the main product of Portworx, the company. It consists of six different components: PX-Store, PX-Migrate, PX-Secure, PX-DR, PX-Backup and PX-Autopilot. The platform supports up to 1,000 nodes and 1 million volumes per cluster. The platform is based on various open source components built by Portworx.
The main component of the platform, PX-Store provides software-defined storage for containers. It works by abstracting any type of storage that is connected to Kubernetes worker nodes, regardless of size or brand, into a single, virtual pool. On each worker node in a Kubernetes cluster, Portworx is available as a DaemonSet. It manages the combined storage pool. When a worker node with storage is added to a Kubernetes cluster, the Portworx daemon is automatically installed and the storage is added to the pool. The architecture of PX-Store is described in great detail in a (Japanese) blog on the Purestorage site.
With PX-Migrate, it is possible to migrate complete workloads between clusters, either in a single datacenter or between clouds. It uses the open source component Stork (Storage Orchestration Runtime for Kubernetes), created by Portworx itself, to achieve this. Stork is an extension to Kubernetes that allows for tighter integration between clusters, pods and the storage they use. It allows for more control over how stateful applications (such as databases) are run on a Kubernetes cluster.
The security component of Portworx is called PX-Secure and is used for encrypting data living in a Kubernetes cluster. It integrates with directory services (such as AD and LDAP). It provides fine-grained Role Based Access Controls (RBAC) for Kubernetes, such as limiting operations that users within a specific namespace may perform by only allowing them read access. This extends the standard security feature set of Kubernetes quite a bit. The Portworx documentation provides examples on how to enable security (by means of a DaemonSet, through operators or at the namespaces level)
Disaster recovery is provided by the PX-DR component. It offers high availability in a single datacenter. You can also use it to achieve RPO near to zero between datacenters in the same metropolitan area. Examples on how to set this up (also for DR between different geographic regions) are provided on the Portworx documentation site.
Container backup and restore in the Portworx platform is offered by the PX-Backup component. It solves the puzzle of backing up an ever-changing, volatile container environment where containers might be short lived, and exist across machines. It offers backup of both stateless and stateful workloads and can backup to itself (via PX-Store) or integrates with other Cloud based block storage (S3 compatible) from Google, Amazon or Microsoft. By using Kubernetes namespaces, it is possible to backup containers connected to specific applications.
PX-Autopilot scales your cluster automatically. It is the capacity management component in the Portworx platform. It is an intelligent, rule based system which only scales when needed and does this in the background, for individual container volumes or even entire clusters, integrating with the storage solutions of large Cloud providers such as Google, Amazon and Microsoft.
Autopilot rules, Kubernetes CRD’s written in yaml, tell the platform under what conditions to resize the storage. It works by selecting a namespace and providing the conditions and actions, for example telling Portworx to resize a volume to a max of 100% of its original size when it is filled more than 50%.
The product features of the various components of the Portworx platform are described in detail on the feature overview page.
Portworx describes two different deployment architectures, converged and separated. In the first, a separated or disaggregated architecture, the storage is separated from the compute nodes. In the second, a converged architecture, everything is combined. You choose the architecture depending on your scalability needs. When workloads are relatively static, a converged cluster makes more sense. However, when workloads change rapidly and the underlying nodes need to scale rapidly, a separate cluster is the way to go.
Portworx needs a minimum of three nodes. Each node has the same requirements: 4 cores, 4Gb of available RAM, a minimum of 128Gb operational storage (unmounted, block). Other requirements are listed on the installation page.
A best practice installation consists of a control plane and worker nodes. In smaller clusters, the control plane and worker nodes run on the same machine. In larger clusters it is possible to run the control plane separately.
You control Portworx through an open sourced command line tool: pxctl. It is part of the OpenStorage SDK, an open source project maintained by Portworx that enables control and automation of cloud native storage volumes for Kubernetes, by means of API’s (available as gRPC, REST or CSI).
Portworx supports the following four license types:
|Portworx Developer||Embedded into px-developer, free license that supports select functionality.|
|Trial||Automatically installed with Portworx Enterprise , enables functionality for 30 days.|
|Portworx Enterprise VM||Enterprise license, suitable for Virtual Machine (VM) installs on-prem and in cloud|
|Portworx Enterprise Metal||Enterprise license, suitable for installs on any bare metal hardware|
The table below provides an overview of Portworx Enterprise pricing on AWS.
|Unit type||Cost/host/hour||Cost/host over a 365-day contract|
|Worker or Storage Bare Metal Nodes Per Hour||$1.11||$5,000.00|
|Worker or Storage Virtual Nodes Per Hour||$0.333||$1,500.00|
Also, download the informative 22-page guide ‘The Expert’s Guide to Running Containers in Production‘ and learn more about the best practices for:
- Addressing key challenges around persistence, availability, security, and more
- Managing stateful containers with the leading schedulers
- Building the ideal architecture for containerized apps
- Identifying ideal use cases for stateful containers