By Simon Stevens, PowerFlex Engineering Technologist, EMEA. March 2023.
Regular readers will be aware of some of my previous blogs, where I have discussed the various plugins that are available for PowerFlex – you can find a couple of them here: https://powerflex.me/2021/08/24/managing-powerflex-using-vsphere-vcenter/ and here: https://powerflex.me/2021/09/30/plentiful-powerflex-plug-ins/ for example. Feedback from our customers play strongly into the decisions that are taken when our IaC (Infrastructure-as-Code) Team are planning for the next steps that we make with our Dell supported plugins across the entire Dell storage portfolio. Whether it is providing new plugins that give customers an easier way of integrating their Dell products with 3rd party applications or frameworks, or adding new capabilities into existing plugins, our developers are always busy. So now is a good time to summarise what is happening in the world of PowerFlex plugins.
It is always pleasing to start off such a roundup by revealing the introduction of new integrations that make it easier for developers to use PowerFlex within their estates. On March 8th 2023, Dell released Terraform Providers for both PowerFlex and PowerStore to our catalogues, adding to the providers that already existed for OME and PowerMax. The full list of Dell Terraform Providers can be found here in the Hashicorp Terraform Registry:
Focusing in on the PowerFlex specific provider, this allows Terraform customers to automate and orchestrate the provisioning of Dell PowerFlex systems. Terraform enables DevOps personnel to build, configure and modify infrastructure configuration using human-readable configuration files that are written in Hashicorp Configuration Language (HCL) securely and efficiently.
The PowerFlex provider allows DevOps teams to easily automate key PowerFlex components – SDC, Storage Pool, Volume, SDS and Snapshots – as resources, as well as providing data resources for those components as well as Snapshot Policies. Armed with capabilities enabled by the provider, it now makes it very easy for any DevOps team to automate most of the common storage operations – that is to say, operations that need to manipulate storage volumes, snapshots, snapshot policies and storage pools.
Version 1.0.0 of the Dell PowerFlex Provider supports Dell PowerFlex 3.6.x and Terraform 1.3.2 and 1.2.9. It is compatible with ubuntu 22.04 as well as supported versions of RHEL 8.x and RHEL 7.x. The Provider can be downloaded from the following GitHub repo: https://github.com/dell/terraform-provider-powerflex .
Moving onto our Ansible Modules – version 1.5 of the Dell Ansible Modules for PowerFlex were recently released. Having added support for PowerFlex 4.0 into version 1.4, the “big ticket” item that has been added into version 1.5 is the addition of the “replication_consistency_group” module. This new module allows PowerFlex Replication Consistency Groups – RCGs – to be managed via Ansible. Using RCGs makes it easier for storage admins to manipulate multiple snapshot operations at the same time by grouping those snapshots into RCGs. The operations now supported by the RCG module are shown in the table below:
Dell Ansible Modules for PowerFlex v1.5 has been tested to work with Ansible 2.12, 2.13 and 2.14 and is compatible with PowerFlex versions 3.5.x, 3.6.x and 4.0. The Modules and documentation are available on: https://github.com/dell/ansible-powerflex . Don’t forget that you will also need to install the PowerFlex Python SDK before you can use the Ansible Modules – full details on downloading and installing this can be found here: https://github.com/dell/python-powerflex .
Finally, we move on to the ever changing world of Kubernetes, where yet again, our IaC Team have again been busy of late, adding functionality into our Dell Container Storage Modules (CSM), whilst also ensuring that our base CSI drivers keep up with the constant cadence of k8s release cycles. Several key improvements were added into both the latest release of the CSI driver, version 2.5.0, and the functionality offered by the CSMs keep increasing.
The features added into version 2.5.0 of the Dell PowerFlex CSI driver are as follows:
- Read Only Block support
- Added support for setting QoS limits by CSI-PowerFlex driver
- Added support for standardizing helm installation for CSI-PowerFlex driver
- Automated SDC deployment on RHEL 7.9 and 8.x
- SLES 15 SP4 support added
- OCP 4.11 support added
- k8s 1.25 support added
- Added support for PowerFlex storage system v4.0
The addition of support for SLES15 SP4 and OCP 4.11 are both welcome and timely, as is adding support for PowerFlex 4.0. The automated SDC deployment for RHEL 7.9 and 8.x make it easier for k8s admins to ensure that when a k8s cluster is scaled out and new worker nodes are deployed, that they have the SDC installed in them by default (this was already happening for RHCOS worker nodes).
The other newly added feature that caught my eye with version 2.5.0 of the CSI driver was QoS support. This has been implemented with the introduction of two new Storage Class parameters – ‘bandwidthLimitInKbps’ and ‘iopsLimit’.
While PowerFlex never suffers from performance hotspots, due its distributed mesh-mirror architecture that ensures optimal performance at all times, that does not always help if human errors can still occur. Many of us will relate to tales heard from colleagues that tell of the carnage that ensues after development teams have ‘accidentally’ created too many test instances on shared infrastructure platforms. With the addition of QoS support, developers can now create multiple storage classes and allocate bandwidth and IOPS limits for each class. The result is that it is now easy to create separate storage classes for Production and non-Prod storage volumes.
As an example – in a PowerFlex system that only has a single Storage Pool (which is the case for many customers), the Devops team could create two storage classes – one for PROD and another for non-PROD workloads. If either the IOPS or Bandwidth Limit parameters are to “0”, then this means that each parameter is set to “unlimited”, which is likely to be preferable for Production workloads. Any volumes provisioned using such a storage class will not have any QoS limits in place on them. See below for an example Storage Class – ‘prod-powerflex-qos-class
’ – where the QoS limits have been removed:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: prod-powerflex-qos-class
annotations:
storageclass.kubernetes.io/is-default-class: "false"
provisioner: csi-vxflexos.dellemc.com
reclaimPolicy: Delete
allowVolumeExpansion: true
parameters:
storagepool: "SP01" # Use Your Storage Pool here
systemID: "7d0a06c0592ad60f" # Use Your System ID here
bandwidthLimitInKbps: "0"
iopsLimit: "0"
csi.storage.k8s.io/fstype: ext4
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
- key: csi-vxflexos.dellemc.com/0e7a082862fedf0f # Use Your System ID here
values:
- csi-vxflexos.dellemc.com
However, by creating a second storage class – here called ‘test-powerflex-qos-class
’ – with IOPS and/or bandwidth limits in place, we can implement QoS limits on any volumes provisioned from this class. The example below shows a class where we have implemented a bandwidth limit of 1 MB/s and a 15 IOPS limit:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: test-powerflex-qos-class
annotations:
storageclass.kubernetes.io/is-default-class: "false"
provisioner: csi-vxflexos.dellemc.com
reclaimPolicy: Delete
allowVolumeExpansion: true
parameters:
storagepool: "SP01" # Use Your Storage Pool here
systemID: "7d0a06c0592ad60f" # Use Your System ID here
bandwidthLimitInKbps: "1024000"
iopsLimit: "15"
csi.storage.k8s.io/fstype: ext4
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
- key: csi-vxflexos.dellemc.com/0e7a082862fedf0f # Use Your System ID here
values:
- csi-vxflexos.dellemc.com
One thing to point out here – in the CSM 1.5 documentation for this feature, it incorrectly states that the parameter to limit the bandwidth is “bandwidthLimitsinKbps”, when in fact it should be “bandwidthLimitInKbps”, as shown in the above examples. This documentation typo should be fixed when CSM version 1.6 rolls out soon.
Onto the Dell Container Storage Modules themselves and recent additions of note here. These are currently at version 1.5.1, with version 1.6 soon to arrive. At present, the following CSMs are supported with PowerFlex:
An up-to-date list of the supported modules for all Dell Storage Platforms (not just PowerFlex) can be found here: https://dell.github.io/csm-docs/docs/ . One module that has slipped quietly under the radar is the “Application Mobility” module. This was introduced in CSM 1.4.0 and is still in “Tech Preview” mode, but it certainly should be of interest to k8s admins. In short, the Application Mobility module provides Kubernetes administrators with a way to clone their stateful application workloads and application data between k8s clusters. These clusters can either be on-prem or in the cloud. Use of this module allows stateful applications to be backed up, restored and cloned, which should make it much simpler to move applications for many reasons, such as cloud repatriation or application migration use cases.
As I mentioned, this is still in Tech Preview as of CSM 1.5.1, but this can be used today by PowerFlex customers. We already have many customers that use PowerFlex to provide the infrastructure across multiple k8s clusters that cover the entire development lifecycle, so these customers are already busy testing out th module today in their non-Production environments. My colleague and VP of Dell ISG Evangelists, Itzik Reich, published an excellent blog recently that discusses the Application Mobility module in more detail, you can find his blog here – https://volumes.blog/2023/01/09/dell-container-storage-modules-csm-1-5-application-mobility-is-here/ .
This brings this roundup to an end. I hope that this blog has helped with your understanding of the latest PowerFlex plugins and modules. It is always worth keeping tabs on the Dell Technologies GitHub site https://github.com/dell which contains the code repositories for products that span the entire Dell portfolio.