00:00
Hey, everyone, My name is Andy, you know, and I'm a field solution architect with pure storage. Everybody, I'm Antony Santino, principal field solution architect, Your at your storage. And today we're here to talk to you about Microsoft sequel server and flash array snapshots and how these snapshots can help make your life easier.
00:23
So what we have over here is the sequel server with the data volume, right and a lot of us are used to our volumes being physical allocations of our storage but inside flash rates a little bit different. Our volumes are defined within a little corner of the flat during which we call metadata, and all the volume really consists of is a collection of pointers to the underlying data that exists on the flash rate in a compressed
00:49
and de duplicated fashion all across the entire array. So it's important to understand that these volumes are just logical constructs because they are logical constructs. It allows us to manipulate them in a nearly instantaneous fashion. In particular, we can take snapshots without impacting the servers in
01:11
question, and these snapshots are not actually copying the data. We are just making a copy of the pointers to the same exact data on the on the flash array itself. So we're able to again do this nearly instantaneously. Because of that, it allows us to do some really cool things.
01:32
Anthony, do you want to talk about some of those? Sure thing, Andy. Let's talk about what we can use snapshots for in sequel server scenarios. And so what we can do with the snapshot as we can clone that to a volume. And the data that's inside of that snapshot at the point in time of the snapshot is now going to be available to me to do some things with.
01:49
Let's talk about some of those use cases. A primary use case for a D. B. A is recovery, whether it be for a whole database or even a subset of the database inside of particular platform. So I can take this data that's inside the clone, and I can either revert the entire database back to a point in time, or I can call following that database again to give me that
02:08
access to the data, maybe attach it as a new name and get a subset of that data out to recover it back to the original system before the point of the failure. Andy, have you ever drop the table or run a delete statement without a where clause Guilty as charged. Absolutely. We've all done it. So let's talk about some other scenarios. So sometimes DVDs were moving lots of data
02:29
around our data centre to service things like Dev, Test Workloads and conventionally would do that with things like back up and restore. And so, with clones, what I can do is I can make additional clones of my snapshot to get access to that data across multiple systems. So now the data that's in those volumes inside of that snapshot can be replicated across multiple instance of secret service so that
02:50
multiple developers can get unique copies of that data that would conventionally take up tonnes of space inside of a data centre. If I had to do that with backward restore, if I'm using clones and snapshots to do this, Andy, is that going to take up additional space inside of our flash array? No, because it's actually just more sets of pointers that go back to the original sets of data now on the other hand.
03:10
Of course, my original volume is still going to be doing workload and writing new data, but we're just going to be writing new data blocks down elsewhere on the array. But the snapshot itself remains intact, lockdown and immutable. So we've been looking at snapshots within a singular A rate. Let's look at some really powerful capabilities of taking snapshots and sending them to other
03:29
parts of our data centre or to the cloud. So that snapshot there I could have another flash array inside of my data centre, right or even in another data centre, and I can take that snapshot and replicate it to that array, right? So this snapshot is now available to me, whether it's in the same data centre or between data centres.
03:47
And I can clone that and present that data to a host that's available on that flash array, which means I can now move that work between data centres for recovery reasons, or get it off of that primary flash array for performance reasons to have that data available here. Additionally, another thing I can do with snapshots is send them to the cloud. We have two scenarios that we can cover here
04:08
the first one to cloud object stores so I can send data into S three or azure blob as snapshots. Or I can provision what's called a cloud block store, which is our purity operating environment flash rate in the cloud. And that gives me the ability to replicate those snapshots into the cloud, whether it be the object or to CBS. And in the case of CBS,
04:29
I can take that snapshot and present that to a virtual machine inside of Azure and get access to that data for either deaf tests. Purpose is to get that out of my primary data centre or for hybrid disaster recovery scenarios. That's really, really awesome. So, Anthony, do we have any parting thoughts that we want to leave with our audience members today?
04:49
Sure, when I talk to customers about snapshots and Flash array running Sequel server. What I really encourage folks to do is to think about if you're ever moving data between sequel servers in your environment by back restore or moving rows of GTL, you can stop doing that. You can push that complexity into your storage platform and minimise the time it takes to perform these kind of operations,
05:10
the snapshots nearly instantaneous, and the replication between these devices is also data reduced. So you're literally moving less data in your environment. Thank you all for watching.
