>> There are new Software Assurance core benefits
that are going to make running
SQL Server on an Azure Virtual Machine
even cheaper than it was before.
Learn more in this episode of Data Exposed.
[MUSIC]
>> Hi. I'm Anna Hoffman.
Welcome to this episode of Data Exposed.
Today I'm joined by Amit,
a Group Program Manager on the Azure Data team.
Amit, why don't you tell us a little bit about what you do.
>> Thanks, Anna. Great to be here.
I'm part of the Azure Data Engineering team.
I'm responsible for the SQL Server database engine
running outside of Azure and in Azure Virtual Machines.
>> Awesome. Today, I'm excited because we're going to be talking
about Software Assurance and
how that relates to SQL Server and Azure VM,
and how three can be a part of this.
I don't really know a lot about any of these things,
so I'm excited to learning more.
Why don't you go ahead and tell us about
Software Assurance and some of these benefits
that are available to our SQL customers.
>> Absolutely, Anna. I'm going to switch over to
a slide that I prepared for this video.
We actually have a benefit called Azure Hybrid Benefit that
SQL Server customers with Software Assurance or
subscription licenses are able to leverage on Azure.
One of the most recent things that we
announced was the core multiplier benefit,
where in this example,
if you have one core of SQL Server Enterprise license,
you can actually use it for one core
on a SQL Server Enterprise Virtual Machine,
or you can actually use it for four cores
of Standard Edition in a VM.
What that means is if you have
six SQL Server Enterprise core licenses,
you can actually stand up
a SQL Server Virtual Machine with six cores,
or you could stand up
four different SQL Server Standard Virtual Machines
with four cores each.
That makes it a multiplication effect.
In this example you see
six translates to six cores of Enterprise Edition,
and six cores translates to 24 cores of Standard Edition.
Once we look at this benefit,
you would understand that customers that have
their Enterprise and Standard
licenses covered with Software Assurance,
they can fungibly use
both these licenses being their Standard and Enterprise VMs.
In addition to that, we announced the Benefit last year in
November where Software Assurance customers and
subscription license customers could get
one free replica for
high availability and disaster recovery, which already existed.
In addition to that, we started
providing an additional three core for
disaster recovery and additional three core for
disaster recovery if that VM was residing on Azure.
In both cases there's DR VM,
so we need to have asynchronous replication.
We redefined the rules for passive replica as well.
On passive replicas, you're not able to
run operations like consistency checks,
log backups, full backups,
monitor the VMs for health,
for resource usage, and at the same time,
run DR drills without incurring any additional license costs.
It simplified how passive replicas and how they work.
Let's see how this actually stitches together before and after
November 1st in the most common configuration
that we see on Azure Virtual Machines.
In this setup, what you see is we have
two availability group replicas
in East US and two others in West US.
The first one is the primary,
the second one in server 2
is actually the high availability replica,
which is a sync secondary,
and the remaining two are asynchronous secondary.
What you see on your screen over here is
essentially before November 1st,
2019, you would have to pay for six of
the cores on the third and the fourth server.
But post-November 1st, you only have to pay for one of them.
The first replica is the HA replica.
The second one is the async DR. replica.
Any additional replica, you actually need to pay for it.
Let's extend that and see what
happens when you actually use that for Reads.
For Reads, because it's not passive,
you'd have to end up licensing that.
But now, if you have a fourth replica,
which is a DR-only replica and is passive
and is asynchronous in nature,
then you can actually not
pay for the licenses for the fourth replica.
The passive replica could use any feature.
I'm showing this example with availability groups.
You could actually use log shipping,
you could use on basic availability groups in Standard Edition,
which limits you to two replicas,
or you could use backup restore,
or even database mirroring for setting
up the high availability sync secondary.
This mirroring, as you see,
is a deprecated feature.
We don't recommend using it,
but we understand that you might
have older releases of SQL Server,
so we extended that benefit to be featured in our sync.
Let's see some other common configurations that customers use.
This one is another common one across regions,
we see customers actually using distributed availability groups,
which essentially allows you to create a forwarder in
between your primary and your remaining secondary replicas.
Why is that helpful? It actually helps reduce
the network bandwidth requirements
between the primary and the other replicas.
In this case, you see server 3 acting as the forwarder.
In this case, the forwarder
always needs to be licensed because it's not passive.
However, after November 1st,
server 4 need not be licensed.
That's another way you can actually save on costs
in another type of configuration.
This is very common for
customers that did not have availability groups,
especially before SQL Server 2012.
Failover clustering was very common for setting up
high availability solutions with shared storage.
You've seen customers that are moving into
Azure asking for support for failover cluster instances.
Recently, we added SQL Server failover cluster instance support
on Azure Virtual Machines using Azure shared disk,
so now, you have the ability to actually
deploy a failover cluster solution with SQL Server
running in an Azure Virtual Machine using
the same practices and
the same patterns that you're used to on-premises.
This makes your lift and shift a lot easier,
but at the same time, from
a licensing perspective, nothing changes.
It's important to point out, in this case,
in VM 2 and VM 3,
they were never really running a SQL Server replica,
they were just waiting for a failover to happen,
which is why there's no change between
before and after when we announced this operation's benefits.
The same thing applies if you have an additional instance.
This architecture, node 2 that you see here on the screen,
is actually running a second SQL Server failover cluster instance,
which means now you have
two different failover cluster instances
active on two different virtual machines.
In that case, every time you have
an active SQL Server instance running on the machine,
which is serving production applications,
you need to license them.
That's why the licensing increases from 6-12,
six for each VM and there's no change.
These are the different common things that we find customers
are very excited about when they're leveraging
SQL Server in a virtual machine on Azure.
We hope that you are able to leverage these benefits.
Please go over to
aka.ms/azuresqlvm to know more details about
what features we offer.
We hope to see you in our next episode.
>> Thanks, Amit. I just have a few questions as we round this out.
One, looking over all of this,
it's very interesting to see the different options that are
available and also, the three cores that are not new,
but I'm guessing probably a lot of people
didn't know about these things that came in November 2019.
Which one do you think would be the best or which one do
you see most customers moving towards and taking advantage of?
Is it customers moving
their enterprise cores to getting
more cores in standard and virtual machine?
Or is it some of these high availability architectures,
or maybe a combination of both?
>> We definitely see a combination of both,
but the most common one that we see
customers leverage is this architecture right here.
You would want to have a high availability replica in one of
the regions and have an equal balance setup in another region,
just to ensure that you have the right capacity to failover or
even switch them on for DR drills and DR purposes.
This is what we see as the most common configuration.
In certain configurations, customers
just get rid of server 4 because they're running in Azure,
and it's very easy to set up a replica if
they want to set up one from scratch.
If I had to talk about what's
the most common one we see customers ask us about,
this is the most common one.
>> Awesome, cool. This is one where you can
save six cores where previously you couldn't.
Thanks so much, Amit, for being on the show.
We are going to do a few more SQL Server
and Azure Virtual Machine,
you want to give us a sneak peek of what's next?
>> Sure. In this one we talked about what
three cores and benefit Software Assurance customers have.
What I would like to do in one of
the future episodes is even talk about
what virtual machine benefits
are offered to any SQL Server customer and Azure.
I'm pretty excited about that video as well.
>> Awesome. I'm looking forward to it as well,
and I think our viewers will too.
If you like this video,
please like our videos,
subscribe to our channel,
and we hope to see you next time on Data Exposed.
[MUSIC]