Red Hat OpenShift 4.10 was released last month. this new 4.10 release, available now, is based on Kubernetes 1.23 with the CRI-O 1.23 runtime. OpenShift 4.10 has several exciting new enhancements […]
Red Hat OpenShift 4.10 was released last month. this new 4.10 release, available now, is based on Kubernetes 1.23 with the CRI-O 1.23 runtime. OpenShift 4.10 has several exciting new enhancements and features for both developers and administrators. In this I’ll be focusing on the VMware Cloud native storage driver integration with OpenShift and Dell PowerStore vVols.
PowerStore is designed with deep integration with VMware vSphere including VAAI and VASA support, event notifications, snapshot management, storage containers for VMware vSphere Virtual Volumes (vVols), and virtual machine discovery and monitoring in PowerStore Manager. These integrations make PowerStore an ideal platform for EKS Anywhere and containerized applications and services.
One of the features that was added in vSphere 7.0 is the ability to provision Virtual Volumes (vVols) to back Kubernetes Persistent Volumes (PVs) via the vSphere Cloud Native Storage (CSI) driver. OpenShift 4.10 allows us to integrate with the vSphere Cloud Native Storage for virtual OpenShift cluster and create persistent volumes which are backed by PowerStore vVols.
To start creating persistent volumes on vVols datastores, we need to create an SPBM policy and attach it to our vVol datastore,
PowerStore vVols leverage Storage Policy Based Management (SPBM) to ensure VMs have the appropriate storage capabilities through their entire life cycle. VM storage policies can be optionally created after the storage provider is registered. These policies are used to determine the desired storage capabilities when a VM is being provisioned.
Next, we need to create a storage policy, we can do it by navigating to the storage classes page in Openshift UI.
We give it a name and set the provisioner to VMware CSI driver and the storage policy name to the SPBM policy we created in vSphere, this means that each PVC from this storage class will be created as a virtual volume on Powerstore using the VMware CNS driver.
At this stage, we are ready to provision a stateful applications, all we need to do is set the point the storage class of the application to our newly created storage class
One of the main advantages of running OpenShift on top of vSphere is the insight we receive via CNS. Rather than having to keep switching between array views and datastore content views, we can view all the information relevant to Persistent Volumes consuming vSphere storage in one place. Using vVols for PVs has no difference. Here is the Container Volumes view, showing our PVs in the vSphere UI:
We can see the PV name, we see it is on the powerStore-vvol Datastore which is compliant with the storage policy. We can also see the health status and the capacity.
By navigating to PowerStore manager, and clicking on the vvol, we can see the newly created vvols which are VMware FCDs
FCD are just virtual disks, but in the API they are 1st class objects–they can be created and exist independently of a VM. Which makes sense for something a container. FCDs can be created, snapshotted, resized, etc just like a virtual disk but without a VM to own it, this is exactly what Kubenrers persistent volume claim is.
The type of vVol provisioned depends on the type of data that is being stored:
• Config: Stores standard VM configuration data such as .vmx files, logs, and NVRAM
• Data vvols: Stores data such as VMDKs, snapshots, full clones, and fast clones
• Swap: Stores a copy of the VM memory pages when the VM is powered on. Swap vVols are automatically created and deleted when VMs are powered on and off.
In addition, we can see storage performance metrics showing the total IOPS, bandwidth, latency and IO size each Kubernetes persistent volumes which is basically a PowerStore virtual volume.
Dell Powerstore vVols integration is a key component of this solution, as it offers full flexibility, and granularity that may be required by your containerized application. You can define multiple VM storage profiles which can be assigned to a different storage classes within OpenShift or any other Kubernetes distribution to really fit your needs.
A guest post by Tomer Eitan