(upbeat music)
- Hi, and welcome to a brand new skilling video.
My name is Vybava Ramadoss
and I'm a Product Manager on Azure Storage for Kubernetes.
In previous videos, we've talked about best practices
on running stateful workloads with Kubernetes on Azure.
Today, we will deep dive into
how you can protect your production scale workloads
and recover from failures.
On the agenda for today,
we will cover different data protection considerations
and recovery scenarios as you think about
your different production workloads,
as well as do a backup and restore demo
for a stateful workload on Azure.
With that, let's get started.
Over the last few years, we are seeing
a significant increase in stateful production workloads
running with Kubernetes on Azure.
These workloads include databases,
for example, MongoDB or MySQL,
big data applications, like Cassandra,
machine learning applications,
like Apache Spark or Kubeflow,
as well as a plethora of other applications
like messaging apps, CICB systems or CMS.
These workloads leverage different types of storage,
including block, file, and object storage options,
which are exposed by a CSI Drivers that are deployed
and configured in our Kubernetes environments.
Now, as you run this workloads at production scale,
it is important for you to think
about data protection options and some key considerations.
These include ease of configuration,
simplicity of ongoing operations,
application awareness,
so you can restore an entire application,
as well as of course, cost effectiveness.
Let's look at these one by one.
With ease of configuration,
we have a number of built-in platform capabilities
like incremental snapshots
that will always ensure that you are able
to capture data with high fidelity.
When it comes to operational simplicity,
a number of enterprises use open source technologies
like Valero, which provide built-in automation,
not just for you to restore volumes,
but also cluster state.
Next up, ensuring that your entire application
is up on restore is critical.
We have a number of integrated partner solutions
that provide application awareness
with the right hooks in place
for you to control this at the resource, namespace,
or at the entire cluster level.
Last but not least,
ensuring that you can leverage the lowest cost options
on the platform is critical.
With Azure Blob Storage,
you can use lifecycle management to tier down data
to cooler storage for long-term retention.
In addition to these considerations,
you also need to look at different types
of failures and recoveries.
Let's look at the first scenario.
Here, you may have lost your volume data,
and this can be because of an accidental delete
or an incorrect update.
Say somebody dropped a table
and you want to be able to restore this back
to a previous good state.
And the second scenario that you have here,
your node becomes unavailable.
An example of this,
maybe during a node upgrade operation.
In this case, you want to be able
to enter not just your volumes are up,
but also your app data is recoverable
say to another nodepool.
In the last scenario,
the callout here is disaster recovery.
In this case, your entire cluster is down.
Say there's a regional outage.
Of course, that's super rare.
But in this case, what you want to do
is ensure that your volumes are up,
but also your cluster state is recoverable.
So your entire cluster is up in your target region.
Now let's take a look at some key storage capabilities
that enable and help bolster data protection.
First up it's snapshots.
For all of our different volume types,
we enable you to create fast, incremental snapshots
that allow you to capture changes at high fidelity
and restore volumes from these snapshots.
In addition to this, we also support
geo-replicated or globally redundant storage,
which provides a passive secondary
that allows you to then bring up volumes at fail-over.
This can be used, for example,
with our standard files of blobs.
On a similar line,
we have enabled cross-region replication
with Azure NetApp Files.
Which leverages NetApp's SnapMirror technology
to replicate to a passive secondary in a paired region.
You can sign up for this capability in preview
at the aka.ms link.
To further support cross-region data protection,
we are announcing the preview of cross-region copy
of snapshots for Azure Disks.
These snapshots will be incremental,
enabling fast and simple restore in your target region.
You can try out this functionality today in preview
by signing up at the aka.ms link.
Now, let's take a quick look at a demo
on how you can back up and restore your application
using Valero on Azure.
Here, you see a Kubernetes cluster
that's running in Azure on West US 2,
and this is running Kubernetes Version 1.21.
So in this environment, we have a stateful set
that's running with MySQL.
You can see the stateful set here.
See, this is MySQL stateful set.
And then this also leverages a PVC,
which is a managed disk PVC,
which is using ZRS as part of this configuration.
Now, what we have done is created a database
at a table as part of this server,
and we have populated some data on it.
So let's take a quick look via a pod.
that's a MySQL client.
So here you see I'm initializing a MySQL client,
and I'm running a select statement
saying select from ZRS test message.
Here, you see the result,
meaning that this is the data
that is populated in this table.
Now that we've seen this information,
what we're going to do is we're going to assume
that something really bad happened.
That someone dropped this table
or someone messed up the data.
And what we're going to do is we're going to take backups
so that in those scenarios,
we're able to restore to a previous good copy.
Now, let me go ahead and create a backup
of this table, using Valero.
And I'm going to do this by issuing Valero backup create.
I'm giving my backup a name,
which is backup V1,
and I'm pointing this at my default namespace.
Great.
Now Valero has submitted this backup successfully.
And what we're going to do is quickly look at the describe
to ensure that this was indeed done successfully.
So I'm going to issue the describe,
and here you see that this is completed.
So we know that the backup was done successfully.
Now, what we're going to do now is delete that stateful set
and those PVCs and see what happens on restore.
Let me go ahead and delete the stateful set.
I'm going to then go ahead and delete the PVC
that we just looked at as well.
So there you go.
And this PVC will now finally remove all of the remnants
of that stateful set that was running in the cluster.
What you will see next is that
when we issue the restore operations,
we now have to determine whether that stateful set and PVC
were able to come back into the environment successfully.
Now you see that the PVC is indeed deleted.
I'm going to go ahead and issue a Valero restore
from the snapshot that we created previously,
which is MySQL backup v1.
Now here, you see that this was completed successfully.
What we're going to do next,
do a watch on the pods to make sure
that they're all up and running
so we can validate that stateful set
indeed does come back.
Here you see that the pods in the stateful set
are starting to initialize.
And what this should really do
is not just bring up the two pods
that were part of the stateful set,
but also bring up the persistent volumes
that were mounted to this application.
Great.
There you see that the pods are running now.
And now what we can do next,
once we see that this is running is check out
if we got our PVC back.
So let's check that out.
Awesome.
Our PVC is back as well,
and it's bound to the application
as well as it is the same capacity that we expected
at the point when we took the backup.
What we're going to do is we're going to recreate
that client pod for MySQL
and issue the same select statement
to ensure that we're seeing the same data
that we had prior to when
this stateful application and PVC was dropped.
So let's go ahead and do that.
Here, you see I'm issuing a run command with that client
and issuing that same select statement,
which has a select start from ZRS test.
Woo hoo! There we see that the data is back
and that it was restored to a previous good state.
In addition to open-source options,
we have a number of integrated data protection solutions
from our partner ecosystem.
These solutions offer in-cluster, cross-cluster
as well as cross-region disaster recovery,
and also with application awareness.
These solutions protect different volume types
on the platform offering low RPO, low RTO solutions.
In addition, these are tightly integrated
with Azure Blob Storage to ensure
that you get long-term retention.
We work extremely closely with these partners
to ensure that you have a seamless end-to-end experience
leveraging these solutions on Azure.
(upbeat music continues)
Once again, thank you very much for joining us today.
We would love to hear your feedback on our surveys.
If you have any questions,
please do not hesitate to reach out
to us at askcontainerstorage@microsoft.com.
Have a great day.