>> You may be familiar with failover clusters for SQL Server,
but how does that change in Azure virtual machines?
Learn more in this episode of Data Exposed.
[MUSIC].
>> Hi, I'm Anna Hoffman and welcome to
this episode of Data Exposed MVP edition.
Today I'm joined by Javier Villegas MVP working on Azure Data.
Javier, thanks so much for joining us today.
Can you get us started by telling
us a little bit about what you do?
>> Sure Anna. Hello everybody.
Well, basically I am from Buenos Aires, Argentina.
I am data platform MVP and I work at
Mediterranean Shipping Company as
an IT director in the DBA and BI services.
I'm also a Microsoft Certified Trainer and I am
member of the Azure Data Tech community board of advisors.
>> Awesome. Well, it's great to have you on the show.
I think you have the right expertise
for what we're going to be talking about today,
which is SQL Server failover clusters in Azure.
Now, before we get really into the Azure part,
I'd love to understand from you,
what is a failover cluster?
>> Okay. Sure. Yeah,
a failover cluster is basically a group of computers,
of servers that you can put all
together to achieve high availability,
for certain obligations or resources.
In this case, what we're going to be focusing on is on
failover cluster using shared storage and we're going
to discuss specifically SQL severed scenarios.
Basically, you can have two or more machines in
your cluster sharing group of disk.
This could be one disk or multiple disk.
The beauty of this is that you have
one active node being the owner of all the resources.
Again, in this case, SQL Server.
If something happened to that computer, to that server,
let's say that it crash or you have a hardware issue,
or you need to patch or something,
you can easily move all the resources to
the other nodes and the ones that were
the passive nodes of the cluster becomes the new active node.
You can do that in a matter of seconds.
Also it's important to notice that you always have
the same SQL server name and IP address.
That means that you don't have to do
any changes on your connection string.
That's a matter which is the node that is serving SQL server,
in this case, you don't have to worry about the application.
Let's say that you need to have multiple instances of SQL Server.
You can add more node to the cluster and have some
of this nodes serving on a specific SQL Server instance.
You can move each of the instances to
any of the nodes in a matter of seconds,
always having the same SQL server name and IP address.
This is extremely important and the shared storage fit over
clusters are available in Windows since Windows NT 4.
It's a technique that is well-proven.
In my case, I've been using it probably since then.
>> Awesome. Cool. It sounds like a very useful technology.
I actually think for some of our Azure SQL pass services,
this is what we're doing under the hood actually.
But if I wanted to do this in an Azure virtual machine,
can I build a shared storage failover cluster using an Azure VM?
>> Yes. Absolutely. Before I go into that,
let me also tell you that you can combine
a failover cluster instance with
an availability group with
other cluster nodes in a different data center,
in a different locations.
With that, you can not also achieved high availability,
you can also have disaster recovery.
This is why it's important to
know and have it in your environment.
You have the whole solution,
high availability and disaster recovery
using failover cluster instances,
using shared storage, combine it with our liability group.
Here I have some screenshots on how you see the nodes, the disc,
and the resources in the Window cluster,
from the failover cluster manager point of view.
You can see all the nodes that you have in your cluster.
You can have also the share cluster name and IP and you can
also see all the shared disk that are attached to the cluster.
Going back to the question,
if we can have these in Azure,
the answer is yes.
Since last year, we have the possibility you've seen
premium or ultra disk to have
the possibility of having the share storage cluster.
That means that when you create the disk within the Azure portal,
you have a new property,
which is called max shares, meaning,
how many virtual machines can
own that disk or can share that disk.
It's as simple as running this common from the Cloud Shell.
You're going to create, in this case,
a disk which is named,
mySharedDisk2 with certain size.
In this case I specify that I'm using premium sku.
The important thing is the max share.
With that, you have your disk ready to
multiple nodes and have the shared storage failover cluster.
>> Why is the max shares?
Why is that important?
>> This is important because basically,
if you don't do this,
when you create the disk in Azure,
it's going to be only owned by
one built on machine at the same time.
With this much share option,
which is the new part,
you can have the disk map to multiple virtual machines.
Of course you need the failover cluster manager to govern,
which is the active nodes and which one
has access to the disk at any particular moment.
But the good is that you can have it already connected to
the disc and depending on which is the active node,
each machine will see all the disks.
That is why this max-shares option is important.
You can set it up to 2,5,10,
whatever depending on how many nodes
you need in your failover cluster.
It's also important to consider that when you
install SQL Server on a failover cluster,
we have to go to a different setup process.
It's not the one that we know,
which is the first option.
New SQL Server installation is actually
new failover cluster installation and you have to
start installation on the active node.
When they say, active node is
the one owning the disk at that particular moment,
the disk and all the cluster resources.
With that, you have to do,
let's say, a SQL Server setup following the installation guide.
There's going to be some differences between
a regular standalone SQL installation and
a failover cluster and then when you are
done with your active node,
you have to jump to the passive node that again,
you're can have more than one.
In that case, you have to go to the option.
I've known to the SQL Server failover cluster.
>> Awesome. Thanks. It seems like this is pretty straightforward,
very similar to what you would do for
SQL server but now in an Azure virtual machine.
One question I have Javier,
can you show us how you would actually go about
creating this shared disk in something like the Azure portal?
>> Yes, absolutely. Let me go to my Azure portal.
Here I am logged in in my subscription.
I have started the Cloud Shell,
and here I have my prompt.
When I go here,
I just have the command that we create the share this with
one terabyte in East US
with standard SSD and with max-share option.
When I submit the command,
it just create that this is going to take
few seconds to have it complete.
But now I will close this.
I will refresh my portal and we will
see in a few seconds the shared disk.
Here, mySharedDisk1.
When I go to the disk properties within the portal,
this is like any other regular disk that we
have for any virtual machines.
But here we have the option that the same max-shares2.
This way when we have multiple virtual machines,
in this case two,
we can attach this specific disk to multiple ones.
This way we can create multiple disk using the same syntax.
We can also combine different skills.
If you only want to use premium disk
or ultra disk or a combination of then,
you can do it this way.
If you have four disks,
you can do it this way.
It's extremely simple.
>> Awesome. Cool. This has been a really useful session.
I've learned a lot.
One question I had,
which is maybe you can help me out with,
earlier you talked about creating
this failover cluster instance and
then adding an availability group.
Is that something you see customers or
people you work with wanting to do in Azure as well?
Is this the way you would get
started in doing that or do you have any tips?
>> Well, in my particular experience,
I do this combination all the time.
In order to have high availability
within the same Azure ration but you have the availability set,
you have the different songs, etc.
But if you want to cover
the pruning where one of your PM, for example, crash,
you have the other and for that,
I have failover cluster,
with two nodes in my case.
When we want to have, for example,
BAM on a different data center,
on a different region,
in my case we are using West Europe and North Europe,
we have an availability group
and a standalone instance
actually running on the North Europe data-center.
During an asynchronous availability group synchronization,
that makes a lot of sense.
Eventually if something happened to the whole region,
you can do the AC failover
from one region to the other with absolutely no product.
With all this solution,
you archive this high availability
and disaster recovery with many nines.
>> This has been awesome and I really appreciate
us learning about not just the HA side,
but also the DR sides and how crucial setting up the shares is
and also how it makes it easier once you set up
the max-shares during deployments.
Thanks so much having us. This has been really useful.
I've learned a lot. I'm sure our viewers have learned a lot.
For our viewers, if you like this video,
go ahead and give it a like,
subscribe to our channel,
leave us a comment and let us know what your doing
for HADR in Azure VMs.
We hope to see you next time on Data Exposed.
[MUSIC].