Welcome to this screencast, where we will talk about Synchronizing
Volume Snapshots For Distributed Workloads Using The HPE CSI Driver For Kubernetes.
My name is Michael Mattsson. I am a Tech Marketing Engineer
with Hewlett Packard Enterprise. Before we start, I just want to set
the context of it. I have a Kubernetes cluster with a WordPress application installed.
This WordPress application consists of one application server and
a distributed database. I also have the HPE CSI Driver for Kubernetes installed,
along with the necessary controllers to perform snapshotting.
To be able to synchronize snapshots of distributed workloads, the user needs
a logical construct to be able to group different volumes together and
access those interfaces within Kubernetes itself. So in this example, I have the HPE CSI
Driver for Kubernetes installed. We can see here that we have a set
of different API objects that we make available to the cluster administrator
and the user.
First, the cluster administrator needs to create something called
a volume group class. The volume group class uses a HPE Storage backend that has been
configured on the cluster. Users will create something called Volume Groups.
Volume groups are names-based. And, once the volume group has been created,
a VolumeGroupContent API object is created and the external volume group
gets created.
Initially, the external volume group is empty and the user will simply
add members to the external volume group by annotating existing persistent volume claims.
Volume group class parameters are unique per backend. So if you say,
for example, that Nimble has one set of parameters and Primera and 3PAR
on https://scod.hpedev.io. You will also find information on how to use
these constructs under the Using section. But I am just going to show you here
under Container Storage Providers, you will find Nimble Storage and you scroll down
to VolumeGroupClass parameters.
Say, for example, you want to add array-based snapshot and replication
to your volume group class. That is being done through this interface.
And that's where you will reference the Nimble Storage-specific parameters
that either have been pre-defined or defined by a storage administrator
to allow replication to a downstream Nimble array or to HPE Cloud Volumes.
Switching to my terminal, I am going to create an initial VolumeGroupClass.
The VolumeGroupClass refers to a secret that refers to a HPE storage backend
that's already been provided by the cluster administrator.
We are going to create that.
Once the volume group class has been created, a user will then be able
to create a volume group. And the volume group will simply refer to the volume group
class name that we just created.
We are going to kubectl that.
The volume group provisioner will actually create an object
on the HPE Nimble Storage array. That is something called a volume collection.
So let's log into the web UI and see what we can find.
Under Data Protection, we will now see that we have an empty volume group
created on the system. Back in my terminal, I will enumerate
the PVCs that are available in my namespace. We can see here that we have a number
of different PVCs. I want to be able to snapshot together the 2 MariaDB
database volumes and also my NFS volume that serves the application server.
Adding PVCs to our volume group is done by simply using the kubectl annotate command
and giving it the custom annotation csi.hpe.com/volume/group=
and the volume group that you just created.
Inspecting the volume group, you can now see that we have persistent volume
claim names enumerated on the volume group. Switching back to the array UI,
we will now see that we have three volumes in the volume group.
In the next steps, I will show you how to create snapshot on this volume collection.
Before we start creating snapshots, I just want to go over
the API object model for snapshot group classes and snapshot groups.
Again, imagine we have the HPE CSI Driver for Kubernetes installed and these are
the different objects that will become available to the Cluster Administrator
and the end user. The SnapshotGroupClass, the SnapshotGroup and
the SnapshotGroupContent. The SnapshotGroupClass is very similar
to the VolumeGroupClass. Give it a name and your reference a HPE storage backend
that already exists on a cluster. And again, the snapshot group class
parameters are unique per backend. More responsibility is put on the user
at this stage. To be able to create a snapshot group, the user needs
to specify the volume group as source, and he also needs to understand
what snapshot group classes are available on the cluster and also volume snapshot classes.
Volume snapshot classes are created with the CSI Snapshot Controller
and how to create volume snapshot classes is out of scope
for this tutorial, and more information can be found on Scod on how to create
volume snapshot classes and how to perform regular volume snapshots.
Once a snapshot group is created, the snapshot group snapshotter will simply
create an object called SnapshotGroupContent that will then reference
external group snapshots that we created on our volume collection.
In this case, we are using Nimble. We will also see in the demonstration later
that we will be using standard Kubernetes volume snapshots for this operation.
Back in my terminal, I will create a snapshot group class. A snapshot
group class simply references a secret that has already been defined
on the cluster.
I am going to kubectl that. At this stage, users can then create something called
a snapshot group by referencing a volume group as source and also point out what
SnapshotGroupClassName they want to use and also which VolumeSnapshotClassName
they want to create the Kubernetes snapshots from. I am going
to create a snapshot group. And by enumerating the volume snapshots we will now
be able to see that each of the volumes, or the persistent volume claims on the cluster,
each have a snapshot on their own. Switching back
to the HPE Nimble Storage Web UI, we can see that we already have
a snapshot collection created.
As users create more snapshots from Kubernetes, we will be able to immediately
see those snapshot collections on the volume collection
in the HPE Nimble Storage UI.
In other storage infrastructure frameworks, volume groups are usually referenced
as Consistency Groups. That means that the volumes within that group
have referential integrity. In highly-distributed applications
in a micro service architecture, it is crucial to keep data in sync.
This was a very simple example with only three volumes, but say if you have
a larger application with multiple services across multiple hosts,
data might eventually skew, if you have many volumes that you create snapshot in a sequence.
When you create a snapshot group, that is not the case as all the volumes
are snapshotted at the exact same point in time
on the backend storage system.
We have already demonstrated in a previous screencast on how to use
snapshots clones and perform restores of those snapshots. So please
look for a screencast named Using Snapshots And Clones With HPE CSI Driver For Kubernetes.
If you like to know more, visit HPE.COM/Storage/Containers.
Until next time, take care.