Portworx is a software defined persistent storage solution designed and purpose built for applications deployed as containers, via container orchestrators such as Kubernetes, Marathon, Nomad, and Swarm. It is a clustered block storage solution and provides a Cloud-Native layer from which containerized stateful applications programmatically consume block, file and object storage services directly through the scheduler. Portworx volumes are always hyper-converged. That is, they are exposed on the same host where the application container executes.

Portworx technology:

  • Is delivered as a container and gets installed on your servers that run stateful applications. Portworx volumes are available on the same host where an application container consumes the volume.
  • Provides virtual, container-granular data volumes to applications running in containers.
  • Is scheduler aware - provides data persistence and HA across multiple nodes, cloud instances, regions, data centers or even clouds.
  • Is application aware - applications like Cassandra are deployed as a set of containers, and Portworx is aware of the entire stack. Data placement and management is done at an application POD level.
  • Is designed for enterprise production deployments, with features like BYOK inline encryption, snapshot-and-backup to S3 and support for stateful Blue-Green deployments.
  • Manages physical storage that is directly attached to servers, from cloud volumes, or provided by hardware arrays. It monitors the health of the drives and manages the RAID groups directly, repairing failures when needed.
  • Provides programmatic control on your storage resources - volumes and other stateful services can be created and consumed directly via the scheduler and orchestration software tool chain.
  • Is radically simple - Portworx is deployed just like any other container - and managed by your scheduler of choice.

Cloud Native Storage

Here is a short video that shows how Portworx provides an entire platform of storage services for managing stateful containerized applications in any Cloud or On-Prem data center

How it Works

Unlike traditional storage which is designed to provide storage to a host machine or operating system via protocols like iSCSI, NBD or NFS, Portworx directly provides block, file and object storage to your applications on the same server where the application is running. Portworx itself is deployed as a container and runs on every host in your cluster. Application containers consume Portworx volumes directly through the Container Orchestrator. The following are supported:

Read more about how Portworx provides storage volumes to your application containers here.

Minimum Requirements

  • Linux kernel 3.10 or greater
  • Docker 1.13.1 or greater
  • Configure Docker to use shared mounts. The shared mounts configuration is required, as PX-Developer exports mount points.
    • Run sudo mount –make-shared / in your SSH window
    • If you are using systemd, remove the MountFlags=slave line in your docker.service file.
  • Minimum resources dedicated to Portworx per server:
    • 4 CPU cores
    • 4 GB RAM
  • Additional resources recommended per server:
    • 128 GB Storage
    • 10 GB Ethernet NIC
  • Maximum nodes per cluster:
    • Unlimited for the Enterprise Edition
    • 3 for the Developer Edition
  • Open network ports:
    • Ensure ports 9001-9016 are open between all nodes that will run Portworx.
  • All nodes running PX container must be synchronized in time and recommend setting up NTP to keep the time synchronized between all the nodes
  • Before going production, ensure a 3-node clustered etcd is deployed that PX can use for configuration storage. Follow the instructions here to deploy a clustered etcd

Portworx can run with heterogenously configured servers, including servers with different cpu/memory configurations. Portworx can also run with servers that have different local storage profiles (number and size of disks/SSD/NVMe, etc.) There is a definite benefit (but not an absolute requirement) for servers to have local storage to contribute, since providing local storage enables high-performance features such as scheduler hyper-convergance. Nodes that do not contribute local storage can still fully participate in a Portworx cluster. However data access for any jobs scheduled on a “storage-less” or “head-only” node will be via implicit network access.

From an operational standpoint, Portworx recommends installing on all nodes within a cluster. Having Portworx installed on all nodes eliminates the overhead of configuring scheduler “constraints” that would then be needed to prohibit a job from running on a node where Portworx is not installed.

This ansible playbook can be used to deploy a 3-node etcd cluster

Install

PX runs completely in a container. It can be installed to run directly via OCI runC or deployed and managed via your container orchestrator. Follow the instructions for either method below.

Pre-install Check

Run the pre-install check on each node to be added to Portworx cluster to ensure that the node is ready for deploying PX successfully and join a PX cluster. Follow this link to run the pre-install check script.

Install with RunC

You can run Portworx directly via OCI runC. This will run Portworx as a standalone OCI container without any reliance on the Docker daemon. In this method, PX is managed by systemd. Install with RunC

Install with a Container Orchestrator

You can also deploy Portworx via your container orchestrator. Chose the appropriate installation instructions for your scheduler.

Join us on Slack!

Slack

Contact us to share feedback, work with us, and to request features.