Welcome to this demonstration of the HPE CSI driver beta for Red Hat OpenShift.
This demo uses OpenShift 4.1 where CSI is currently in Technology Preview.
The HPE CSI Driver is a multi-platform and multi-vendor driver
where interested party may develop a container storage provider.
A CSP as we call it.
The CSP a much simpler control plane shim
that abstracts away all the intricacies of Kubernetes
and all the backend storage data management.
Such as discovering LUNs and formatting filesystems which can be a quite daunting
task for a developer.
In this demo we're going to deploy the driver to utilize two different HPE Nimble Storage arrays, one all-flash and one hybrid-flash.
We'll then deploy a WordPress app server and a MariaDB database using persistent volumes
dynamically provisioned by the CSI driver through an OpenShift StorageClass API object.
Another capability OpenShift also have available
as a feature-gate in Technology Preview is the direct use of block devices.
This opens for applications that crave raw block access and suffers from the double buffering overhead
that filesystems provide. So, let's dive.
The HPE CSI Driver for Kubernetes is available on GitHub.
All the instructions are currently available on how to deploy it on Kubernetes,
but it also applies to Red Hat OpenShift just as much.
I'm going to spare you all a lot of the details here but I'm going all the steps needed to deploy the driver.
First of all we need two secrets that point to the two arrays that we have in our environment
we're going deploy to. So I'm going to login to the UI here and create those two secrets.
I'm going to copy & paste those in here and we can see that we have a hybrid-flash system here
named as src-array869.
We also have a few other parameters here as the username and password for that particular array
and also where the container storage provider is listening.
That is basically a service on the cluster. We haven't deployed that yet, but we get to that point.
So, we also need another for
the all-flash system. Copy & paste that in here.
As you can see, points to a completely backend. These two arrays are in two
discrete groups they're not connected
in a HPE Nimble Storage array group. They're both independent.
Alright, we can see we have our secrets here. Perfect!
Now I need to login from the CLI because we need to copy & paste
a few YAML declarations to get the CSP installed
and then get all the necessary sidecars
needed to be able to provision storage and manage attachment and detachment and such.
Let's copy & paste the CSP first.
The CSP has a Service and Deployment.
And then we have the stack of CSI sidecars.
And also our node driver and controller.
We're just going wait for those to come up here. We can see a bunch of services coming up here.
So, looking at my nodes in the OpenShift cluster here. I have three workers.
And we also a CRD that gives us more information about the workers themselves.
We utilize the CRD to be able to abstract information about node.
Such as IQNs and what networks it's connected to.
If that would be a Fibre Channel host
you would be able to see the World Wide Port Names (WWPNS) and so forth.
So, and back in the OpenShift UI here we're going to declare Storage Classes.
The provisioner we have installed doesn't list the CSI provisioner
so we need to create YAML manually
and I'm just going to copy & paste those in here in the edit YAML box.
Here we can see all the different details, first of all we want a default StorageClass, we call that "hue-standard".
It's going to point to the hybrid-flash system
and we also reference the namespace where we deployed the secret, everything is deployed in kube-system.
You can only manipulate these resources if you're an admin on the system.
You can also specify what type of filesystem you want here, we fall back to XFS but we also support ext4, btrfs
and ext3 as well.
Then we have a bunch of container storage provider specific
parameters specific to the HPE Nimble Storage CSP.
We're going talk a little bit about storage parameters and StorageClass parameters
a little bit later. Let's just create this StorageClass and this is our default one.
Then we're creating another one, edit YAML, as you can see we're going to call it "hpe-database".
As I mentioned we're deploying a MariaDB database, so this StorageClass
will then be put on the all-flash system and it has a bunch of different parameters also
backend specific that allows to tweak and tune that specific volume when it gets created.
Let's create that one.
We can see we have two Storage Classes here. Out on the GitHub
page here you can see
and observe some examples on how to use the driver.
There's the USING.md file that will
go through some very basic examples on how to get the secret in place
creating storage classes a lot of simple examples.
What we're going to show here is the StorageClass parameters.
What we've done here is basically divided the section, the common, cloning, provisioning parameters
and also the import parameters.
Let's get back to OpenShift and deploy our workload.
I'm just going to logout from the OpenShift UI
and login with my user.
This is a restricted account. Only authenticated to the
cluster and I will be able to create persistent volume claims
against the storage classes I created.
The first volume I'm going to create is a generic volume for the WordPress instance. I'm going to use the UI
elements to create that particular volume. I give it a name
and I give it a size.
We're now able to see the volume is created and bound.
There we go! On the other volume I'm actually going to edit the YAML box and show you
a few other capabilities, we want to be able to tweak
the actual volume we create for the MariaDB database.
I'm going to give it a custom description.
I want to give it more snapshots and snapshot retentions so I changed the Protection Template.
I'm also very particular about who the filesystem owner is going to be as the container startup as I want to run it with a particular UID.
I'm also going to boost the IOPS, the default on the StorageClass is 20000 but I want to give this volume 50000 IOPS.
Then we give it a size and then we'll be to create this volume.
We also need to call the particular StorageClass name that we want this
persistent volume claim to create a volume against.
We call the "hpe-database" that is the StorageClass name for the database specific StorageClass.
Bound!
I'm now going to login the CLI as my user to just deploy my
database instance and wordpress instance.
These are not any rocket scientist type deployments, they use the stock Bitnami images.
You can login to the database here for instance and just check inside the
container inside the pod, that we have a multipath device mapped to
whatever host this application is running on. Check the requested size, 4GB.
It's been mounted on slash bitname and that's where the
MariaDB image from Bitname actually stores its data.
Same thing with WordPress, you just do a "df" and you'll see a multipath device of 20GB
also mounted on slash bitnami.
I have a route setup for application.
I'm just going to refresh this and this is essentially what you land on when you deploy this image for the first.
I'm logging in username "user" and password "bitnami".
Then, I'll just create some content. "This is awesome!" I'll then upload an image.
Most prettiest storage array in the industry.
This is the stuff!
Now we have a post in our WordPress instance with an asset.
Just to prove that is an actual persistent
application I'm going to delete MariaDB pod.
Refresh the site and you can see that you have a
database outage and shortly thereafter it's up and running again.
You'll be able to refresh the web page and you should get your content back.
Back to the UI here I'm just going to show another
capability that we also have enabled and that is
the capability of creating raw block volumes. You just change the volumeMode to Block.
The default volumeMode is always set to filesystem but you don't really use that because the normal
mode of operation. You set the volumeMode to Block.
Create the persistent volume claim. Bound instantly, a tiny volume, no formatting involved.
Then I'm going to create a very simple Pod which I just constructed here, it's utility called "ioping".
Ioping checks for storage connectivity, either in a filesystem or a block device.
I'm going to run the ioping command against the block device.
What is different here is that you have the volumeDevices stanza in the specification that
points to a device path where you want it mounted
but then in the volume section it's exactly the same where you point to a claim name of a certain name.
We're going wait the app to come up, there we go!
Now you can see that we're actually
access a block device of 32GB that we created and that just works!
Back to the CSI driver Github page.
This is just a beta, we are currently
working diligently in a generally availability state.
The version we'll ship will also include all the latest capabilities in the
CSI specification, that will include snapshots that you can create from volume snapshot classes
and you'll also be able to specify in your
persistent volume claim which data source you want to create the persistent volume claim from.
That could be from an existing persistent volume claim that you already created
or could be a volume snapshot that you have taken at any point in time.
We'll also be able to demonstrate the capability of doing online resize of any of the supported filesystems.
And bring a lot of more, new cool features and capabilities that we become available through the CSI initiative.
Until then, take care, that's all for now! Bye!