Hi, I am Denise Ochoa. My current role is a Technical Solutions Engineer
on the Technical Marketing Engineering team for HPE Storage. I am currently located
in Fort Collins, Colorado. In this demo, I would like to demonstrate the entire
lifecycle of a containerized application and its storage needs.
We will see the entire lifecycle using the containerized NoSQL Database Cassandra.
Today, we have distributed systems orchestrated by kubernetes.
Kubernetes is the de facto orchestration software behind
containerized applications. Containers are packaged solutions which only contain
what is needed for an application to run, and are referred to as lightweight.
As a result, containers can achieve higher performance
than virtual machines. Since containers are lightweight, creating and spinning
new containers is fast and agile. If a new service or more distribution
of a workload is needed, new containers can be created quickly to meet the dynamic need.
By design, a container is stateless, which means that when the container
is removed, the data associated with that specific container disappears as well.
This creates a challenge in that critical information or data
will no longer be available to use.
Many applications are stateful, these applications need a container
that includes persistent storage that can respond to application requirements.
What we have with distributed systems is de-coupled compute and what we need
is de-coupled storage, where it is easy to access and provision persistent
storage as well as maintaining security and reliability. Here, in this demo,
we are using the HPE Data Fabric for our stateful applications that need
persistent storage.
The Data Fabric Container Storage interface, or CSI Driver, enables
the HPE Ezmeral Data Fabric to create a plugin for adding or removing volumes
of storage across different container orchestration systems. For instance,
in this demo, we are using the HPE Container Platform environment.
Once the CSI Driver is installed, kubernetes can dynamically provision
volumes for the stateful application to use without the need of a storage administrator.
Volumes for applications can be created, cloned or expanded
for the application needs. A snapshot of a volume can also be created and restored
to use with another instance of an application. Volumes can also be deleted
or archived. All these actions are initiated and controlled
on the kubernetes side of the house. So let's begin our demo. We are assuming we have
installed the CSI Driver and created the necessary resources to allow
kubernetes access to provision volumes on the Data Fabric. A demo is linked below
if the steps are needed. This is the Ezmeral Data Fabric Manage Control System.
A storage administrator can create volumes on the GUI or command line,
but, as we will see with the Data Fabric CSI Driver,
the kubernetes side of the house will be able to dynamically provision volumes
for stateful application storage needs. We begin by showing the namespace
we are using. Again, we have already added the necessary resources
in the demo namespace. We switch our context to demo and we are ready to see
the data lifecycle for a container application. We will be using
the NoSQL Database Cassandra for this demo. Now, let's create a volume. We must create
a persistent volume claim which is dedicated storage carved out for the container
from the storage we made available using the storage class.
A persistent volume claim has to be bound to its persistent volume from its storage class.
When it's bound, it means the volume is available to use.
We use the command kubectl describe to get more information on the persistent
volume claim created. Please, note the volume path. We can go
to the Data Fabric Manage Control System and see the same name path
for the dynamically provisioned volume.
Next, let's deploy Cassandra and attach the persistent volume claim to our Cassandra deployment.
In order to be able to access our Cassandra deployment, we need to create
a service which is a load balancer and expose a port for our outside Cassandra
client to hit. We expose port 30042.
We have a Cassandra stateful set to a replication factor of one
for demo purposes only. Here, we reference our created persistent volume claim
for the application to use.
We check to see if our Cassandra application is up and running and now
we will see if we are able to reach it at port 30042 using our Cassandra client.
Utilizing CQLSH on our Cassandra client, we can communicate remotely
with our containerized Cassandra application using the port we exposed.
We create a test keyspace and table and add users, their names and email addresses
for demo purposes only. CQH is used for crafting curries
and in a standard environment, Cassandra might be paired up with a messaging broker
like Kafka. Let's say we want to analyze the data our first instance of Cassandra has.
We can do so by cloning the volume our marked production data has
and attach it to another instance of Cassandra. First we will create
a persistent volume claim that will clone the mock production persistent volume claim
called dynamic provisioning Cassandra PVC. We now have two bound
persistent volume claims that are original and cloned. We are ready to create a new
Cassandra deployment and attach the cloned persistent volume claim.
Since it's a new instance, we will use a different node port to reach this Cassandra instance.
The cloned persistent volume claim is reference for the Cassandra deployment to use.
We check to see if the pods and services are up and running and it is now time
to check if our cloned instance has the same data as our marked
production instance. We log into the cloned Cassandra instance using
the new node port number and check to see if the data is available. We can check back
onto our original Cassandra instance and see our data matches.
We can use kubectl describe to see the volume path name of our cloned volume
on the kubernetes side of the house, as well as from the Manage Control System.
In the scenario first instance of Cassandra needs more storage,
we can expand the volume on the fly. We can see the original capacity.
To expand the volume, we just add the capacity desired to the existing
persistent volume claim and the CSI Driver will expand the volume.
We can see here our volume has been expanded. When the need to run analysis on a database
multiple times from a specific state is necessary, this can be managed
by creating a snapshot and restoring it. First, a snapshot secret will be created,
then a snapshot class.
We are now ready to create a volume snapshot. We will reference the original
persistent volume claim we created to take the snapshot of.
Here, we can further describe the snapshot created.
Since we have a snapshot of our database at a specific point in time,
we can add data to our database and use our snapshot to restore a Cassandra
instance back to the original data we had.
It's time to restore the snapshot to a new volume and attach it to a new
Cassandra deployment. Since this is the third instance of Cassandra, a new
service port will be used. We can see the volume path using kubectl describe
as well as on the Manage Control System. We can also see the snapshot
created of the original volume. Now, we connect to our restored
Cassandra instance and see if our data is back to the state to where the snapshot
was taken. We can compare the two instances, we can see
that the snapshot worked and that we have a Cassandra instance in a desired state.
We can also delete all the volumes created for our Cassandra deployments
all through the kubernetes side of the house. First, we delete the deployment,
then we delete the persistent volume claim. We do so for all three Cassandra instances
and, as seen on the Manage Control System, the volumes are now deleted.
Persistent storage that is flexible to accommodate the entire lifecycle
of stateful applications is critical for easy App modernization.
The HPE Ezmeral Data Fabric brings a distributed file system that works
within a container-based environment, ideal for stateful applications lifecycle.
This concludes our demo. Thank you.