1
00:00:07,655 --> 00:00:17,960
You may be familiar with a traditional Windows Server failover cluster.
It looks something like this with two or more nodes connected to shared storage.

5
00:00:17,960 --> 00:00:36,180
Now that shared storage can represent a single point of failure.
It's also not widely available in the cloud. And if you want to deploy your clusters where cluster nodes reside in different data centers or different cloud availability zones, it's not possible to use shared storage.

10
00:00:36,180 --> 00:00:43,325
So if your shared storage fails, all the nodes in your cluster fail.
So again, it's a single point of failure as well.

13
00:00:43,325 --> 00:01:03,615
So what SIOS does is we have a product called DataKeeper, and DataKeeper enables what we like to call SANless clustering.
Now, SANless clustering is exactly the same as your traditional Windows Server failover cluster, but instead of using shared
storage, we allow you to leverage locally attached storage.

19
00:01:03,615 --> 00:01:19,105
Again, this can be any storage device on on a virtual machine, a cloud instance, a physical server.
It's just a local block device attached, formatted NTFS. You give it a drive letter, and the Datakeeper will do two things.

24
00:01:19,105 --> 00:01:49,795
One, it will do block level volume replication of that storage between the cluster nodes, either synchronously for nodes in the same data center or same region in the cloud, or if you want to replicate
longer distances for disaster recovery, it also supports asynchronous replication.
So pictured here is a simple two node cluster. As you might expect, if there's a failure on the primary node, failure clustering will detect that failure, initiate a recovery on a secondary node.

34
00:01:49,795 --> 00:02:06,885
Now as part of that recovery, the mirror direction reverses.
So now all the writes are occurring locally on node two and are automatically replicated back to node one without going into the, DataKeeper software.
That all just happens automatically.

39
00:02:06,885 --> 00:02:27,665
This is a a typical two node cluster, but we also support multiple targets.
So shown here would be two nodes locally, maybe doing synchronous replication for high availability so that there's a failure, local, it'll recover locally.
But then also continue to replicate out to a third node for disaster recovery.

47
00:02:27,665 --> 00:02:52,520
Should you have the failure of an entire data center or an entire cloud region, you can have another copy of your data, available in the disaster recovery site.
And that node can either be part of the cluster to facilitate the automated recovery or it can simply be a data copy only.
And so that recovery on the DR node would be more of a manual process.

54
00:02:52,520 --> 00:03:15,725
And in the cloud, it would look something like this.
And it's really the same, regardless of what cloud you're you're deploying in.
You typically have something called availability zones.
So you're gonna wanna put your cluster nodes in different availability zones, and that gives you, typically four nines of availability in terms of the SLA that the cloud provider will offer.

62
00:03:15,725 --> 00:03:35,275
But once you do that, it's configured exactly the same as your traditional, on premise cluster, except, again, you're leveraging the replication to replicate the data between the availability zones so that there's a failure on the primary server.
The secondary server will come online automatically.

69
00:03:35,275 --> 00:03:54,995
We also support what we call hybrid storage multi site clusters.
So in this configuration, you might have a traditional shared storage cluster in your primary data center, and we allow you to take that existing cluster and replicate it off-site to a third
node for disaster recovery.

74
00:03:54,995 --> 00:04:23,830
That could be your own disaster recovery site or it could be a cloud instance in the hybrid cloud model.
So again, if you have the local failure, you'll still have local failover.
DataKeeper will take care of the disk locking locally while continuing to replicate the data out to the DR site for disaster recovery so that if you have failure of your entire data center,
you can recover automatically or very quickly in your DR site.

82
00:04:23,830 --> 00:04:44,165
So let me jump over to a quick demo, show you how this is put together.
You might be familiar with failover cluster manager as shown here.
And you can see I have a two node cluster preconfigured with, SQL one and SQL two as my cluster nodes.
And I don't have any roles defined yet.

88
00:04:44,165 --> 00:05:12,970
So what I want to do is, the first thing we need to do after we create the basic cluster like you see here, we have the DataKeeper interface.
And this is just a local MMC snap in that runs on any either the cluster nodes or on your local workstation.
Once you connect to the two servers in question SQL one and SQL two, the server overview report will give you a picture of what storage is available on these two servers.

96
00:05:12,970 --> 00:05:33,360
So these are, each server has an F drive, a 10 GB F drive and a 100 GB G drive.
Now the only requirement for replication is if you want to replicate the F drive, from SQL one to SQL two,
Each node needs to have an F drive, and it needs to be, the same size.

101
00:05:33,360 --> 00:05:57,325
So the the real requirement is the target needs to be at least as big as the source.
So you can see here we can replicate the F drive, 10 GB.
We can also replicate the G drive, which is a 100 GB.
So to create what we call a job, it's a simple three step wizard.
You give the job a name. We'll call this F drive. Optional description.

108
00:05:57,325 --> 00:06:11,645
And so step one, you choose the source, SQL1. Choose the volume, F.
You can specify the network you want to use for replication. In our case, we only have a single network, so we will use that network.

113
00:06:11,645 --> 00:06:35,075
Choose the target SQL two, F drive, same network. All that looks fine. And then, finally, you have your options.
So these servers are in the same region, or same data center. I would choose synchronous.
If, again, if I want to replicate greater distance, I would choose asynchronous.
With asynchronous, you might also want to enable compression.

121
00:06:35,075 --> 00:06:54,760
There's nine levels of compression. And, you also have the option to set a bandwidth throttle or maximum bandwidth.
But for local targets and replication across availability zones in the same region of a cloud, synchronous is the way to go.
And so we'll click done.

127
00:06:54,760 --> 00:07:17,980
Now that will initiate the replication and in a moment we'll also get a pop up that asks us if we want to register this in the cluster.
We'll say yes. Go ahead and put that in the cluster and we're going to jump back now to failover cluster manager and we look in storage in available storage, now we see this DataKeeper volume F.

135
00:07:17,980 --> 00:08:03,000
At this point, failover clustering treats that like it's a regular, shared storage device.
So, it'll support any cluster workload from SQL Server to file servers to ERS, ASCS, or whatever it might be.
Future demo, I'll show you how to cluster SQL Server. But let's say I had a just to give you, indication of how it works, I'm going to create just an empty role.
It doesn't have any resources in it. And if I go to add storage to this role, you'll see that it recognizes the DataKeeper volume as an available storage type.
Click okay.

150
00:08:03,000 --> 00:08:25,820
And now I have, this DataKeeper volume F. It's currently online on SQL one.
So anything I write on the F drive is being replicated from SQL one to SQL two.
And if I want to move this to SQL two, I could do that through failover cluster manager.

156
00:08:25,820 --> 00:08:49,685
And things will start moving over, to SQL2. So the F drive you see now is online on SQL2.
And in a moment my job will refresh to show me that SQL two is now the source.
So now we see the source serverSQL two. The target is SQL one. So that all happened automatically.
I didn't have to come out here to DataKeeper to make that happen.

163
00:08:49,685 --> 00:09:09,805
If I want to move it back again, I would simply move it back. Same thing would happen with unexpected failure.
So if the active node had a failure, failover clustering would detect that and would initiate recovery.
And DataKeeper just obeys with whatever,the failover clustering is telling it to do.

169
00:09:09,805 --> 00:09:13,145
So we came back online on SQL one and DataKeeper will refresh.
And we'll see now that the F drive is, once again, the source on SQL one and the target on SQL two.