Have you ever wondered how you transfer an application running on VMware vSphere over to a Kubernetes cluster,
especially if there's data touch, how do you actually do that?
And prevent as much downtime as you can?
My name is Michael Madsen,
I'm a Tech Marketing Engineer with Hewlett Packard Enterprise
and I'm going to show you today how you lift and transform applications
running on traditional infrastructure over to Kubernetes.
The end state we want to get to is running Maria DB.
We did with all the data from the source environment into a container running on Kubernetes.
The first step to do this is to set up an HPE Storage that is compatible with the HPE CSI driver for Kubernetes.
That will include HPE Alletra and Alletra 6000, 9000, Nimble Storage, and Primera.
Also, the first operation we want to do here, because there's data attached to this version machine that is backing the MariaDB database, right?
And that is running in some sort of VMFS data store and it is the content of that application that we're interested in moving over to
The new HPE storage array so the data basically sits in the volume on VMware and the first operation
here we're going to use the technology from VMware called VMware storage [INAUDIBLE]
and we're going to first create a vault data storage HPE store array and then we're going to transfer the content over to the array.
Once we have the content residing on the HPE storage array which have now been attached to the existing VM vSphere cluster
all the content in the volume is now present and still serving the old environment,
but once we have the content on the HPE storage array, we can create a couple of cool things on it.
So, we can create snapshots, I'm doing a little camera here,
and with those snapshots, we can then create zero-copy clones of that particular data.
And once we have installed the HPE CSE driver into the Kubernetes cluster,
there's a string of events that will take place, right?
So, the storage that may need to talk to the Kubernetes admin,
there is a volume that's been going through this transformation process.
We need to move the application over to the Kubernetes cluster
and the first step in this iteration is that the snapshots of the volume that we've taken on HPE storage array.
Those can be imported as clone as a persistent volume that can be served up to the CSI driver
and then later on being brought up with MARIADB database and this is usually done a couple of times to make sure
that you get the right data in the right mount path and stuff like that,
like very application specific things that matter a lot to the DBs because
they need the right file system in the right place and such,
so, they will probably perform this a couple of times and while we've been doing this,
there has been no disruption whatsoever
to the production application running in traditional infrastructure because the storage [INAUDIBLE] does not induce any downtime whatsoever.
It just might be latency spikes here and there.
But at the end of the day there won't be any downtime for the application so far and
creating snapshots and creating zero-copy clones on the HPE storage array
does not eat up any resources or disrupt any application workflow.
Depending if you migrated from a foreign old storage system,
you might actually even get better performance when you move your volume over to HPE storage.
And the next step, once you've completed this a couple of times, what you want,
what you want to do is, and when you have perfected everything,
you need to shut down the source VM and the legacy vSphere environments and this volume here is not the old volume
that we transfer, doesn't even exist in the traditional infrastructure anymore because it's all over here
and once you remove the VM and detach the vVault from your existing infrastructure, you have a volume that sits,
that is offline on HPE storage volume.
And at this point in time, you're now capable of issuing import volume by name,
into the CSI driver Kubernetes cluster where the CSI driver is running and then attach that
to reach the final state of the application.
And at this point you've shut down the application, you've done the import and you brought up the application.
We're talking minutes of downtime here and less than minutes, even.
So once the application is up and running, because you have tested this workflow
multiple times before you actually could perform the final cut over.
So, you obviously need to do a few DNS changes and such to make sure that
your application clients can talk to the database properly when it comes up in a new location.
But once you have the application transferred over to your HPE storage system,
you can reap all the benefits
of the HPE CSI driver in the deep integration with all the capabilities that are available
on the HPE Storage Platform.
And if you want to learn more about these very advanced use cases with the HPE storage and the HPE CSI driver,
please check out hpe.com/storage/containers. Talk to you soon.