Dell PowerStore File Capabilities for NFS Kubernetes Persistent Volumes

Our customers have a wide variety of traditional and modern workloads. Each of these workloads connects to the underlying infrastructure using various networking protocols. PowerStore’s single architecture for block, file, and vVols uses the latest technologies to achieve these disparate objectives without sacrificing the cost-effective nature of midrange storage. PowerStore provides the ultimate workload flexibility and enables IT to simplify and consolidate infrastructure.

Dell PowerStore offers a native file solution that is designed for the modern data center. The file system architecture is highly scalable, efficient, performance-focused, and flexible. PowerStore also includes a rich supporting feature set, enabling the ability to support a wide array of use cases such as departmental shares or home directories. These file capabilities are integrated, so no extra hardware, software, or licenses are required. File management, monitoring, and provisioning capabilities are handled through the simple and intuitive HTML5-based PowerStore Manager. In this blog post, I’ll be focusing on the NFS part of PowerStore CSI driver and its unique capabilities for modern cloud native applications

Kubernetes allows us to provision our PersistentVolumes dynamically using PersistentVolumeClaims. Pods treat these claims as volumes. The access mode of the PVC determines how many nodes can establish a connection to it.
A PersistentVolume can be mounted on a host in any way supported by the storage provider. Dell PowerStore CSI Driver supports the three access modes listed below and has different capabilities and each PV’s access modes are set to the specific modes supported by that particular volume. For example, NFS can support multiple read/write clients, but a specific NFS PV might be exported on the server as read-only. Each PV gets its own set of access modes describing that specific PV’s capabilities.

The access modes are:
– ReadWriteOnce — the volume can be mounted as read-write by a single pod
– ReadOnlyMany — the volume can be mounted read-only by many pods
– ReadWriteMany — the volume can be mounted as read-write by many pods

The standard access mode for PVCs within Kubernetes is ReadWriteOnce, which specifies a 1:1 mapping between a volume and its consuming application. This access mode is suitable for most cloud-native workflows such as databases and message buses. ReadWriteMany permits multiple applications to safely access the same volume, enabling different types of workloads to run in Kubernetes.

There are many use-cases for ReadWriteMany volumes. Some applications can benefit from horizontal scaling. For example, a web-service where static content on a backend volume is merged with dynamically generated content at run-time. Scaling such a service by adding extra pods might be highly desirable, and of course with Deployments in Kubernetes, scaling is very easy. ReadWriteMany volumes can be also used to add HA to some types of application.

Another common use-case for RWX volumes is to enable so-called ‘legacy workloads’. These are applications, or groups of applications, which have been written with access to a shared filesystem in mind.

In order to support these constantly changing storage requirements we need to provide a highly scalable, efficient, performant, and flexible storage solution.

From a performance point of view, traditionally, NFS is slower than SAN-based persistent volumes, with PowerStore, this is not the case anymore.

PowerStore features a 64-bit file system architecture that is designed to be highly scalable, efficient, performant, and flexible. PowerStore also includes a rich supporting file feature set to ensure that the data is secure, protected, and can be easily monitored.

PowerStore file systems are also tuned and optimized for high performance. In addition, platform components such as Non-Volatile Memory Express (NVMe) drives and dual-socket CPUs enable the system to maintain low response times while servicing large workloads.

The maturity and robustness of the PowerStore file system combined with these supporting features enables it to be used in many file-level storage use cases.

Network File Share or NFS is Block storage provided across a network. with the help of our CSI driver, customers can mount the same storage resources across multiple Kubernetes pods. It is an excellent choice for storing and sharing information across various systems. It generally helps in situations where you want to have multiple instances of your application to serve in an HA mode, or multiple instances of your application that need read and write access simultaneously which is becoming a popular requirement for AI/ML workloads these days. Shared file systems in Kubernetes are great for data hungry stateful applications like analytics, machine learning or dev workloads like compile and test.

In this post, we are going to set up a NFS dynamic persistent volume with a ReadWriteMany access using Dell PowerStore CSI driver for NFS and deploy of a K8s application that can leverage this file capabilities

• Mount: enable the container to access an external storage
  
• Persistent: this external storage is still accessible after container shutdown
  
• Dynamic: the external storage’s creation and life cycle are not managed by the user
  
• NFS: The external storage will be exposed via the Network File System protocol
  
• ReadWriteMany: Multiple containers can simultaneously access the storage in write mode
  

Detailed information on how to install the PowerStore CSI driver can be found here

To leverage the Powerstore file capabilities with Kubernentes, we need to create a NAS server first, we navigate to the NAS Servers page in PowerStore manager and click on the create button, here we specify the NAS server details such as name and network settings, then we select the file protocols we want to enable and continue with the wizard.

In order to start creating NFS volumes using the CSI driver, all we need to do is to create a new storage class for file, the provisioer needs to be set to our powerstore csi driver, under the fstype we specify NFS and then specify the powerstore array id and the nas -server we just created

At this stage, we are ready to deploy the application. We are going to deploy a 3-pod frontend app which will be connected to a single persistent volume, in addition we have a service to load balance the traffic between all the pods, the application requires simultaneous read write access to the persistent from all pods, this unique capability is available for powerstore NFS CSI volumes.

Once we run the kubectl command to create the application, we can see that a 50GB volume has been created.

By clicking on its details, we can see that the access mode is set to RWX and the storage class is set to powerstore-nfs.

By navigating to Powerstore manager, we can see that the size has been updated as well, if we go to the file systems tab, we can see our file system which has been created by the CSI driver and represents the RWX K8s persistent volume, under the NFS exports tab we can see that that CSI driver automatically added read & write permission to all the worker nodes as each application pod is running on a different node, while all pods need read & write access at the same time.

Every time I refresh the application web page, the visit count number written to the persistent volume increases and is pulled from a different pod, this clearly illustrates the need of cloud native application these days for readwritemany volume capabilities.

Now let’s say that we are expecting an increase in the number of visits to the site, and we need to scale up the number of pods, with K8s and the Powerstore CSI driver, it’s as simple as a click of a button, or a single kubectl command, depends on what type of person you are. If we go back to our website, we can see that we are being redirected to the new pods that were added to the deployment as well as the existing pods, both connected to the same readwritemany persistent volume.

Now, let’s say that our persistent volume is running out of space and we need to increase its size without impacting the web app itself.

Again, all we have to do is to go to the persistent volume claim object and edit its size, let’s say we want to double the size from 50GB to 100GB, then we just click save and the change is reflected in K8s and well as the share itself on Powerstore with zero impact on the app.

A guest post by Tomer Eitan