Scenario - Storage Classes and Storage Profiles

In this scerario, we will be creating and configuring both Storage Classes, as well as OpenShift specific Storage Profiles.

Creating our project

For this lab, we will be using a new project. In the terminal window execute the following command to create a new project.

oc new-project vmtest

Reminder: Accessing the Openshift Console

You can connect to the terminal in the windows to the right.

The {openshift_cluster_console_url}[OpenShift Web Console^] tab will open in a new browser. window.

The username is {openshift_cluster_admin_username} and the password is {openshift_cluster_admin_password}

Storage Classes and Storage Profiles in Openshift

Storage Classes are a Kubernetes concept that allows an administrator to describe classes of storage they offer. Storage Classes are unopinionated about what the class represents, but it may include things such as: quality-of-service levels, backup policies, or snapshot policies.

Portworx storage classes offer a number of configuration parameters that can be used to configure the amount of replicas, or encryption-at-rest configurations.

Storage Classes are not specific to Openshift or Virtualization, but we still need a storage class to provision virtual machine disks.

Task 1: View existing storage classes

Portworx deploys serveral pre-configured storage classes when the storage cluster was created. These storage classes offer a veriety of configuration options. To view the current storage classes run:

oc get sc

Portworx offers Kubernetes in-tree and CSI provisioners. Storage Classes that contain the -csi- string.

Let’s look at the configuration of an example storage class:

oc get sc px-csi-db -o yaml

We can see in the terminal output a list of parameters. This isn’t exactly what we want for our new virtual machines, so let’s create a new storage class.

Task 2: Create a new storage class for VMs

Run the following command to create a new yaml file for the block-based StorageClass configuration:

cat << EOF |oc apply -f -
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: px-csi-vm-example
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
parameters:
  repl: "3"
  sharedv4: "true"
  sharedv4_svc_type: "ClusterIP"
  sharedv4_mount_options: vers=3.0,nolock
provisioner: pxd.portworx.com
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
EOF

PVCs provisioned using the above StorageClass will have a replication factor of 3, which means there will be three replicas of the PVC spread across the OpenShift worker nodes.

We have also set some configuration options on how RWX volumes should work. We specified the service type to ClusterIP which uses a cluster IP as the endpoint of NFS, and set some mount options.

We also specified that the volumeBindingMode should be WaitForFirstConsumer to allow Portworx to intelligently place the volume.

See the Portworx Documentation for further details.

Also note that the provisioner is set to pxd.portworx.com. This means that our storage class will be using CSI rather than the in-tree provisioner.

With our StorageClass created, we can now create move on to Storage Profiles.

Task 3: Configure the Storage Profile

Storage Profiles provide recommended storage settings based on an associate storage class. Storage profiles are automatically created in Openshift when a new storage class is created.

Portworx sets desired parameters when using the CSI provider, including the prefered access mode.

We can see the current configuration of our new storage profile by running:

oc get storageprofile px-csi-vm-example -o yaml

We can see under the .status node a list of access modes. The first access mode: RWX in filesystem mode will be prefered.

For further details on storage clusters, see the Openshift documentation.

We can now create virtual machines using our new storage profile!