Is storage sexy yet? A Portworx overview
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. 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 , 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.
Abstraction
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: , , , , and . The platform supports up to 1,000 nodes and 1 million volumes per cluster. The platform is based on built by Portworx.
Portworx Kubernetes storage platform overviewPX-Store
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 .
PX-Store architecturePX-Migrate
With PX-Migrate, it is possible to migrate complete workloads between clusters, either in a single datacenter or between clouds. It uses the (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.
PX-Secure
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 . The Portworx documentation provides (by means of a DaemonSet, through operators or at the namespaces level)
PX-DR
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 .
PX-Backup
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-Backup dashboard (Lighthouse)PX-Autopilot
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.
PX-Autopilot architectureAutopilot 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%.
Product features
The product features of the various components of the Portworx platform are described in detail on the .
Deployment architectures
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.
a disaggregated cluster
a converged storage clusterPortworx 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 .
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 , 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).
License types
Portworx supports the following :
| License type | Description |
| 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 |
Pricing
The table below provides an overview of .
| 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 ‘‘ 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
The post appeared first on .
