Hello, my name is Denney Liptak and I'm a Solutions Engineer with HPE Storage.
You're perhaps familiar with discreet, no SQL, database deployments running on local storage.
This traditional installation method has been well optimized for production environments
but it can be less flexible for workloads that need to scale or for DevOps environments
that benefit from rapid setup and tear down.
Containers are great for this but they historically lend themselves to more transient workloads.
This is where the HPE CSI driver for Kubernetes plays an integral role by providing persistent storage
to containers and exposing valuable features from our primary storage arrays.
I'd like to demonstrate how containers with persistent storage
can provide an alternative infrastructure for deploying and using no SQL workloads
that is both rapid and resilient.
We will use several components, some of which you may already have in your environment.
First, we need a Kubernetes cluster. In this case a cluster managed and deployed with Rancher
Next, our database will be provided by MongoDB who integrates with Kubernetes via a custom Kubernetes operator
and database lifecycle being managed by the MongoDB Operations Manager.
Finally, we need persistent storage
and that will be provided by the HPE CSI driver for Kubernetes.
Let's proceed with the demonstration, highlighting these components
and taking a closer look at an example use case.
We will begin in the Rancher UI.
the HPE CSI driver for Kubernetes can be deployed from the Apps and Marketplace.
Once the chart is deployed, you can then create a secret referencing your array and then
one or more storage classes that will be used by your workloads.
I've already deployed the MongoDB operations manager and Kubernetes operator which will be using shortly for the demo.
I will deploy a MongoDB replica set and populate with some data.
Well then snapshot the whole replica set
and clone it to a new resource that could be then used for test or dev purposes.
Let's get started.
On the left is our replica set specification. It's got three members each with a 60-gigabyte volume.
Let's [exec] in and make sure we've got some data there.
All right, that looks good.
Let's then create our volume group.
And then the next step is to list the persistent volume claims that are used by this resource
so, we can see that it provisioned three volumes.
Let's now annotate these volumes with the name of our volume group.
So, here's the first, second and third.
With the PVCs annotated, we can verify that they indeed show up in our volume group.
We see them showing up in the specification here. So that's good.
We will now take a … we will issue a snapshot for the volume group.
We look at the specification for that, simply give it a name,
some class names certainly, and then the name of your volume group that you'd like to snapshot.
So, with a single command we can snapshot all volumes in the volume group at once
and it's quick.
We can now issue another command filtering just on the name of our snapshot group
and we see the volume names, the volume snapshot names, right here.
So that this name is going to be important in the next step.
Now to prepare for our next replica set, we need to create new persistent volume claims
but we're going to use the snapshot volumes as the source.
So, in the specification on the left here, we have the snapshot volume names
as the data source and then we're giving very specific name here for our new persistent volume claims.
So, this actually is quite important. It's deterministic.
So, the name, this RS clone here is going to be the name of our replica set that we create.
When the name matches like this, the operator will not provision a new persistent volume claim.
It'll see that there's one already there and mount that, instead of creating a new one.
So, we will provision our new persistent volume claims based on the snapshot.
And this is a pretty quick operation, too.
If we move over to the rancher UI, it's already refreshed,
we've got our original PVCs and then our three clones.
We're now ready to create our new replica set.
So, here's a specification for that and you'll notice that it is exactly the same as the parent.
The only difference is the name here. So, I flip back and forth between these two.
See? It is exactly the same.
So, let's kick off our new replica set. That'll take a couple minutes to deploy.
After it's deployed, there are some reconfiguration steps that need to be done
in the MongoDB operations Manager.
Those are detailed in the technical white paper.
Let's speed through the reconfiguration step in MongoDB Operations Manager.
The first step is to shut down all nodes in the replica set, wait for that to complete and then we will power on
the first node and ask it to perform a force reconfigure.
We now wait for the first node in the replica set, node zero, to reach a point where it's waiting
for the other nodes to come back on to complete the reconfiguration
and it looks like we're there.
Wait for all necessary members to be up for the replica set reconfig.
So, we will come back in, and set the other two nodes to start up.
This takes a few minutes to stabilize but not too long.
It needs to cycle through this a couple of times.
When it's complete, this bar goes away and you'll get a green status here.
Changes have been successfully deployed so, we've got green status.
If we come in here and we take a look, we see no zeros are primary and we got two secondaries up
and that completes the reconfiguration process.
With the reconfiguration complete, let's verify that we've got a clone of our parent
and that we can use them independently.
The top console will be the parent replica set and the bottom is the clone that we just finished reconfiguring.
Let's verify in the parent that we still have the data present
and that we have the same in our clone.
But now let's add some new data.
So, you can see, we can modify and edit our clone without affecting the parent.
This concludes our demo. Thank you.
And with that I'd like to leave you with a few helpful links for exploring further.
See the description below for my technical white paper
detailing this environment and other examples.
Also, the HPE Storage Container Orchestrator documentation website where,
in addition to documentation,
you'll find examples and more videos detailing configurations and features
provided by the HPE CSI driver for Kubernetes.
Finally check out the active GitHub repos for the MongoDB Operator
and corresponding Operations Manager.
Thank you.