Before you begin:
- Sign up for an IBM Cloud Pay-As-You-Go account. With an IBM Cloud Pay-As-You-Go account you can access the IBM Cloud Platform-as-a-Service and Infrastructure-as-a-Service portfolio.
- Learn about IBM Cloud Kubernetes Service or Red Hat OpenShift on IBM Cloud and the service benefits.
Step 1: Plan the setup of your IBM Cloud cluster
Portworx is a highly available software-defined storage solution that you can use to manage persistent storage for your containerized databases or other stateful apps in your IBM Cloud Kubernetes Service or Red Hat OpenShift on IBM Cloud cluster across multiple zones. To make sure that your cluster is set up with the compute resources that are required for Portworx, review the FAQs in this step.
What worker node flavor is the right one for Portworx? The worker node flavor that you need depends on the infrastructure provider that you use. If you have a classic cluster, IBM Cloud Kubernetes Service and Red Hat OpenShift on IBM Cloud provide classic bare metal worker node flavors that are optimized for software-defined storage (SDS) usage. These flavors also come with one or more raw, unformatted, and unmounted local disks that you can use for your Portworx storage layer. In classic clusters, Portworx offers the best performance when you use SDS Ubuntu 18 worker node machines that come with 10 Gbps network speed. For an overview of available SDS flavors, see the IBM Cloud Kubernetes Service or Red Hat OpenShift on IBM Cloud documentation.
In VPC clusters, make sure to select a virtual server flavor that meets the minimum hardware requirements for Portworx. The flavor that you choose must have a network speed of 10 Gpbs or more for optimal performance. No VPC flavors include raw and unformatted block storage devices. To successfully install and run Portworx, you must manually attach block storage devices to each of your worker nodes first.
What if I want to run Portworx in a classic cluster on non-SDS worker nodes?
You can install Portworx on non-SDS worker node flavors, but you might not get the performance benefits that your app requires. Non-SDS worker nodes can be virtual or bare metal. If you want to use virtual machines, use a worker node flavor of
b3c.16x64 or better. Virtual machines with a flavor of
u3c.2x4 do not provide the required resources for Portworx to work properly. Bare metal machines come with sufficient compute resources and network speed for Portworx. For more information about the compute resources that are required by Portworx, see the minimum requirements.
To add non-SDS worker nodes to the Portworx storage layer, each worker node must have at least one tertiary raw, unformatted, and unmounted disk that is attached to the worker node. You can manually add these tertiary disks or use the IBM Cloud Block Attacher plug-in to automatically add the disks to your non-SDS worker nodes. For more information, see the IBM Cloud Kubernetes Service documentation.
How can I make sure that my data is stored highly available? You need at least 3 worker nodes in your Portworx cluster so that Portworx can replicate your data across nodes. By replicating your data across worker nodes, Portworx can ensure that your stateful app can be rescheduled to a different worker node in case of a failure without losing data. For even higher availability, use a multizone cluster and replicate your volumes on SDS worker nodes across 3 zones.
Step 2: Create an IBM Cloud Kubernetes Service or Red Hat OpenShift on IBM Cloud cluster
To install Portworx, you must have an IBM Cloud Kubernetes Service or Red Hat OpenShift on IBM Cloud cluster.
- Plan the network setup for your Kubernetes or OpenShift cluster.
- Decide if you want to create a multizone Kubernetes or OpenShift cluster for high availability. If you do, you must enable VLAN spanning or Virtual Routing and Forwarding (VRF) for your IBM Cloud account.
- Choose the worker node flavor for your Kubernetes or OpenShift cluster that you want to use. Make sure to review Step 1 to find frequently asked questions for the type of worker node that best meets the Portworx minimum requirements.
- Make sure that your IBM Cloud account is set up with the right permissions to create a cluster.
- Create a Kubernetes or OpenShift cluster.
- If you created a classic cluster with non-SDS worker nodes or a VPC cluster, add raw, unformatted, and unmounted block storage to your worker nodes. For more information, see the Creating raw, unformatted, and unmounted block storage for VPC and non-SDS classic worker nodes section of the IBM documentation. The block storage devices are attached to your worker node and can be included in the Portworx storage layer. If you used SDS worker nodes, you do not need to attach raw block storage devices to your worker nodes.
Step 3: Set up a key-value store for the Portworx metadata
Every Portworx cluster must be connected to a key-value store to store Portworx metadata. The Portworx key-value store serves as the single source of truth for your Portworx storage layer. If the key-value store is not available, then you cannot work with your Portworx cluster to access or store your data. Existing data is not changed or removed when the Portworx database is unavailable.
In order for your Portworx cluster to be highly available, you must ensure that the Portworx key-value store is set up to be highly available. By using an instance of Databases for etcd, you can set up a highly available key-value store for your Portworx cluster. Each service instance contains three etcd data members that are added to a cluster. The etcd data members are spread across zones in an IBM Cloud location and data is replicated across all etcd data members.
Alternatively, if you want to get up and running quickly, and don’t need your key-value store to be highly available, you can select an internal KVBD from the
Portworx metadata key-value store option on the deployment page. If you choose to install Portworx with the internal KVDB, then you can skip the steps that ask for the endpoints and the secret.
Step 4: Set up volume encryption with IBM Key Protect
By default, data that you store on a Portworx volume is not encrypted at rest or during transit. To protect your data from being accessed by unauthorized users, you can choose to protect your volumes with IBM Key Protect. IBM Key Protect helps you to provision encrypted keys that are secured by FIPS 140-2 Level 2 certified cloud-based hardware security modules (HSMs).
Review the following information in the IBM Cloud Kubernetes Service documentation:
- IBM Key Protect volume encryption flow
- IBM Key Protect volume decryption flow
- Setting up IBM Key Protect encryption for your volumes
Step 5: Install Portworx in your cluster
Provision a Portworx service instance from the IBM Cloud catalog. After you create the service instance, the latest version of is installed on your cluster by using Helm. The installation includes a Portworx license. Make sure to review the costs for the license in the IBM Cloud catalog.
Before you begin:
- Make sure that you set up your Portworx database to store your Portworx cluster metadata (Step 3).
- Decide if you want to enable Portworx volume encryption (Step 4).
- If you use classic non-SDS or VPC worker nodes, add raw, unformatted, and unmounted block storage to your worker nodes.
Step 6: Add Portworx storage to your apps
Now that your Portworx cluster is all set, you can start creating Portworx volumes by using Kubernetes dynamic provisioning. The Portworx installation already set up a few default storage classes in your cluster that you can see by running the
kubectl get storageclasses | grep portworx command. You can also create your own storage class to define settings, such as:
- Encryption for a volume
- IO priority of the disk where you want to store the data
- Number of data copies that you want to store across worker nodes
- Sharing of volumes across pods
For more information about how to create your own storage class and add Portworx storage to your app, see the IBM Cloud Kubernetes Service or Red Hat OpenShift on IBM Cloud documentation. For an overview of supported configurations in a PVC, see Dynamic Provisioning of PVCs.
Now that you set up Portworx on your IBM Cloud Kubernetes Service cluster, you can explore the following features:
- Use existing Portworx volumes: If you have an existing Portworx volume that you created manually or that was not automatically deleted when you deleted the PVC, you can statically provision the corresponding PV and PVC and use this volume with your app. For more information, see Using pre-provisioned volumes.
- Running stateful sets on Portworx: If you have a stateful app that you want to deploy as a stateful set into your cluster, you can set up your stateful set to use storage from your Portworx cluster. For more information, see Stateful applications.
- Running your pods hyperconverged: You can configure your Portworx cluster to schedule pods on the same worker node where the pod’s volume resides. This setup is also referred to as hyperconverged and can improve the data storage performance. For more information, see Run hyperconverged.
- Creating snapshots of your Portworx volumes: You can save the current state of a volume and its data by creating a Portworx snapshot. Snapshots can be stored on your local Portworx cluster or in the Cloud. For more information, see Create snapshots.