WEBVTT

00:00:00.000 --> 00:00:10.560
[MUSIC].

00:00:10.560 --> 00:00:11.895
>> Hi, my name is Amit Banerjee.

00:00:11.895 --> 00:00:14.520
I'm a Group Program Manager with
the SQL Server product group.

00:00:14.520 --> 00:00:17.970
I'm responsible for the
database engine for SQL Server.

00:00:17.970 --> 00:00:19.110
So in today's video,

00:00:19.110 --> 00:00:21.150
we're going to talk about
the SQL Server High

00:00:21.150 --> 00:00:23.250
Availability and Disaster
Recovery benefits

00:00:23.250 --> 00:00:26.055
that were introduced
in November 2019.

00:00:26.055 --> 00:00:29.910
So let's go figure out how we
actually deploy SQL Server

00:00:29.910 --> 00:00:31.830
today in the High Availability

00:00:31.830 --> 00:00:33.780
and Disaster Recovery configuration.

00:00:33.780 --> 00:00:37.555
So let's say you have a primary
instance of SQL Server.

00:00:37.555 --> 00:00:40.040
The primary instance now can have,

00:00:40.040 --> 00:00:41.900
depending on the feature
that you're using,

00:00:41.900 --> 00:00:45.080
whether it is availability
groups or log shipping,

00:00:45.080 --> 00:00:47.285
it can have multiple secondaries.

00:00:47.285 --> 00:00:50.375
If you have High
Availability solutions

00:00:50.375 --> 00:00:52.580
like Fail-over Cluster Instances,

00:00:52.580 --> 00:00:57.560
then those are HA only solutions
and you don't have a DR node,

00:00:57.560 --> 00:01:00.935
you have to use other
technologies to deploy DR.

00:01:00.935 --> 00:01:06.335
So if you had this with
SQL Server 2019 or below,

00:01:06.335 --> 00:01:07.790
and this was, let's say,

00:01:07.790 --> 00:01:10.220
another SQL Server 2019 and below,

00:01:10.220 --> 00:01:13.045
and the same thing over here.

00:01:13.045 --> 00:01:15.100
Prior to November first,

00:01:15.100 --> 00:01:17.660
if you had Software Assurance and

00:01:17.660 --> 00:01:20.030
your enterprise agreement gave

00:01:20.030 --> 00:01:22.205
you Software Assurance capabilities,

00:01:22.205 --> 00:01:25.739
you would be able to
license the primary,

00:01:25.739 --> 00:01:28.040
the first High Availability or

00:01:28.040 --> 00:01:30.755
DR replica would not
need to be licensed,

00:01:30.755 --> 00:01:36.070
and the next DR replica would
continue to be licensed.

00:01:36.070 --> 00:01:39.735
Starting with SQL Server 2019,

00:01:39.735 --> 00:01:43.270
and this applies to all older
versions of SQL Server as well,

00:01:43.270 --> 00:01:45.545
if you have the same architecture,

00:01:45.545 --> 00:01:47.930
if you have a primary now,

00:01:47.930 --> 00:01:49.550
I'm just going to draw this right

00:01:49.550 --> 00:01:52.580
aligned so that it's a
little easier to understand.

00:01:52.580 --> 00:01:54.530
You have multiple secondaries.

00:01:54.530 --> 00:01:56.240
Let's say this is used for

00:01:56.240 --> 00:01:59.015
High Availability and this
for Disaster Recovery,

00:01:59.015 --> 00:02:02.960
your primary will need to be
licensed under Software Assurance.

00:02:02.960 --> 00:02:05.825
Your first HA replica,

00:02:05.825 --> 00:02:08.540
which is synchronous
in nature and supports

00:02:08.540 --> 00:02:11.660
automatic fail-over does
not need to be licensed,

00:02:11.660 --> 00:02:15.575
and the Disaster Recovery replica also
does not need to be licensed.

00:02:15.575 --> 00:02:17.795
So let's figure out what
that actually means.

00:02:17.795 --> 00:02:26.720
So let's say this had 32
cores and you had 32 each,

00:02:26.720 --> 00:02:28.400
just to make it simpler.

00:02:28.400 --> 00:02:33.845
So prior to November 2019,

00:02:33.845 --> 00:02:36.860
you would have to
license for the primary,

00:02:36.860 --> 00:02:39.979
none for the first secondary,

00:02:39.979 --> 00:02:46.970
and another 32 cores
for the next secondary.

00:02:46.970 --> 00:02:50.490
Now, if you have a SQL Server or

00:02:50.490 --> 00:02:52.385
any SQL Server release as long as

00:02:52.385 --> 00:02:54.725
the cores are covered
by Software Assurance,

00:02:54.725 --> 00:02:59.690
what you really need to license
for post November first,

00:02:59.690 --> 00:03:01.880
2019 is the primary,

00:03:01.880 --> 00:03:05.305
and up to two secondaries,
it would be free.

00:03:05.305 --> 00:03:07.605
Now, what that actually means is,

00:03:07.605 --> 00:03:09.825
let's assume you have 32 cores,

00:03:09.825 --> 00:03:12.920
your licensing would look like this.

00:03:12.920 --> 00:03:16.370
Now, how do I actually set this up?

00:03:16.370 --> 00:03:20.615
The first prerequisite is, you need
to have Software Assurance.

00:03:20.615 --> 00:03:27.900
Second prerequisite, you can
license the cores on the primary.

00:03:27.900 --> 00:03:31.580
The number of cores on
the secondary has to

00:03:31.580 --> 00:03:38.430
be lesser than or equal to
the number of primary cores.

00:03:39.890 --> 00:03:44.405
For example, if you
had more than 32 here,

00:03:44.405 --> 00:03:46.115
then the benefit would not apply.

00:03:46.115 --> 00:03:49.520
So essentially, for each
core that you license

00:03:49.520 --> 00:03:56.330
for SQL Server posts November
and you have Software Assurance,

00:03:56.330 --> 00:04:00.485
you get one HA core,

00:04:00.485 --> 00:04:04.350
which is synchronous, one DR core.

00:04:04.350 --> 00:04:06.080
And, in addition to that,

00:04:06.080 --> 00:04:13.415
you also get another DR
core running on Azure VMs.

00:04:13.415 --> 00:04:15.110
So if you're running on

00:04:15.110 --> 00:04:16.865
an Azure Virtual Machine and you're

00:04:16.865 --> 00:04:19.160
using that as a
disaster recovery site,

00:04:19.160 --> 00:04:21.215
you also get that for free.

00:04:21.215 --> 00:04:23.570
So in this architecture,

00:04:23.570 --> 00:04:26.540
let's say prior to November,

00:04:26.540 --> 00:04:27.680
you added a secondary,

00:04:27.680 --> 00:04:30.460
but this was on an Azure VM.

00:04:30.460 --> 00:04:36.220
You would pay another 32 cores
provided this had 32 virtual cores.

00:04:36.220 --> 00:04:39.545
In this case, I add another secondary

00:04:39.545 --> 00:04:43.685
and I pay zero cores for this.

00:04:43.685 --> 00:04:46.385
So your architecture can

00:04:46.385 --> 00:04:49.670
actually leverage a better
High Availability and

00:04:49.670 --> 00:04:53.765
Disaster Recovery with a
lower cost of ownership

00:04:53.765 --> 00:04:55.730
with SQL Server benefits that were

00:04:55.730 --> 00:04:58.525
changed post November first.

00:04:58.525 --> 00:05:01.520
Now, what that entitles you to do is,

00:05:01.520 --> 00:05:05.995
you can actually take this to
any release of SQL Server, 2019,

00:05:05.995 --> 00:05:10.370
2017, 2016, and all the way

00:05:10.370 --> 00:05:12.980
to any release of SQL Server as

00:05:12.980 --> 00:05:16.145
long as those cores are
covered by Software Assurance.

00:05:16.145 --> 00:05:19.250
If you have a architecture which is,

00:05:19.250 --> 00:05:21.140
let's say, a physical machine.

00:05:21.140 --> 00:05:23.885
So if you're on
bare-metal, you get that.

00:05:23.885 --> 00:05:26.074
If you are on virtual machines,

00:05:26.074 --> 00:05:27.860
you also get this benefit.

00:05:27.860 --> 00:05:29.270
If you're in containers,

00:05:29.270 --> 00:05:30.770
you also get this benefit.

00:05:30.770 --> 00:05:35.360
So whether you're using SQL
Server on a physical data center,

00:05:35.360 --> 00:05:39.125
or you're using SQL Server
in virtual machines,

00:05:39.125 --> 00:05:42.200
or you're using Azure
as your DR Center

00:05:42.200 --> 00:05:46.745
and you are actually hosting
your primaries on-premises,

00:05:46.745 --> 00:05:49.010
you will have a DR benefit

00:05:49.010 --> 00:05:51.620
covering your SQL Server
replicas on Azure.

00:05:51.620 --> 00:05:53.510
In next few episodes,

00:05:53.510 --> 00:05:55.010
we will actually talk about what are

00:05:55.010 --> 00:05:56.960
the most optimal
architectures who leverage

00:05:56.960 --> 00:05:59.030
this benefit efficiently.
Thank you for joining.

00:05:59.030 --> 00:06:10.690
[MUSIC]

