Many businesses are replacing their legacy infrastructures and application architectures with modern cloud computing and cloud native applications. This enables them to increase cost efficiency, improve operational efficiencies, meet customer demands at a faster pace and stay competitive. There are many areas of opportunity to modernize and drive productivity and better innovations towards better solutions for their customer.
Organizations are modernizing their legacy monolithic applications to a containerized, microservices based architecture that provides greater flexibility to scale and deploy rapidly. Kubernetes has become a de-facto standard providing a robust platform for managing containerized applications with many benefits such as portability, self-healing capabilities, and support for implementing DevOps, Cloud and DevSecOps practices. In addition, there is KubeVirt technology, that provides a unified development platform where developers can build, modify, and deploy applications residing in both application containers as well as virtual machines in a common, shared environment.
In a demonstration video that I published previously, I showed you the use of Red Hat’s Migration toolkit for Virtualization (MTV) to migrate VMs and the associated storage out of a VMware environment and run the VMs on an OpenShift Virtualization platform. I had demonstrated how ONTAP storage integrated using Astra Trident with the OpenShift Cluster providing persistent storage for the containerized applications, can also be used as the storage for the VMs running in the same clusters where OpenShift Virtualization is an add-on.
Storage vMotion is a routine task that a VMware administrator might perform moving virtual disks between storage locations for maintenance or reconfiguration of storage device without virtual machine downtime. Can a Kubernetes operator perform a similar move of virtual storage for the VMs on a Kubernetes based environment (KubeVirt)?
In this blog, I will use a Red Hat OpenShift cluster(4.13) where OpenShift Virtualization (based on KubeVirt) is an add-on. I will demonstrate that moving the volumes in ONTAP storage that provide persistent storage for the VMs (integrated using Astra Trident 24.02) does not cause any downtime for the VMs in OpenShift Virtualization. In a future blog, I will show the details of other volume operations that involve a change of storage class, and these operations will need a cutover window to bring the applications online with the new storage.
Here, I will demonstrate 3 scenarios:
- Moving the storage for a virtual disk provisioned for the VM during boot time.
- Moving the storage for a virtual disk while a write to the disk is ongoing.
- Moving the storage for a persistent hotplug virtual disk that is provisioned after the VM is booted.
Scenario 1: Moving the storage for a virtual disk provisioned for the VM during boot time
We start with the VM in the running state
In the OpenShift console for the cluster, you can navigate to the Persistent Volume Claims (PVC) under Storage menu, and you can see the PVC created for the disks of the VM.
You can also see the details of the Persistent volumes. (PV)
You can find the corresponding volume name in ONTAP by using the command shown below.
Using this internal name, you can see the volume from the ONTAP CLI and the aggregate where it is located.
Now perhaps, you may want to move the volume out of this aggregate because it is getting full. You can do so by using the command as follows:
After the volume move is completed, you can see that the VM is still in the running state.
Scenario 2: Moving the storage for a virtual disk while a write to the disk is ongoing
Before doing the volume move, let us look at the disks of the VM. I created this VM with an extra-disk and, when the VM started, I had created ext4 filesystem and mounted it on a local directory.
Here is the volume in ONTAP that serves as the backend storage for the extra-disk of the vm.
Let us start the volume move to another aggregate in the same vserver. You may want to do this may be to spread the load or may be to move the workload to an aggregate that has faster disks.
Here are the different phases of the volume move.
Before starting the volume move command, I started the following infinite loop that appends the current date into a file on the disk. (The volume backing this disk was moved). This loop continued to execute even after the volume move completed.
From the above, you can see that the client applications will continue to access the VM disks regardless of where the volume resides in the vserver.
Scenario 3: Moving the storage for a persistent hotplug virtual disk that is provisioned after the VM is booted
Here, I have added a hot plug disk to the VM.
And here is the volume name in ONTAP that provides the backing storage to this hotplug disk.
I performed a volume move as before moving the volume to a new destination aggregate. I also started a bash script with an infinite loop that appends the current date/time to a file. When the volume move was completed, the script continued to run, writing to the same file in the same volume but on a different aggregate. To the application, the volume move was transparent and does not cause any downtime.
Summary: In this blog, I have demonstrated, with the help of screen captures of the commands I executed to perform a volume move operation from the ONTAP CLI to show that it is a non-disruptive operation, and clients continue to access their data regardless of the location of the volume in the vserver.
Coming soon will be a blog where I will demonstrate the details of volume operations that involve a change of storage properties, that will need a cutover window.
