[MUSIC]
>> Hi, my name is Amit Banerjee.
I'm a Group Program Manager with the SQL Server product group.
In today's episode, we're going to
talk about how to actually leverage the
SQL Server Disaster Recovery and
high availability benefits that are
introduced in the previous episode and use
that to develop a optimal architecture
for setting up HADR for your SQL Server instances.
So what we talked about in the past was you
get a high availability replica,
you get a DR replica,
and you get a DR replica in Azure if you have Software Assurance.
So these changes apply to
every SQL Server release as
long as those cores are covered by Software Assurance.
As long as those cores are covered,
if your primary has 10 cores,
you get 10 cores worth of HA in another node,
you get 10 cores worth of DR in another node and you get
10 cores worth of DR in a SQL Server VM running on Azure.
So let's talk about a few common scenarios that we have.
So the first is a primary,
and if you have a secondary architecture over here,
you will essentially set up this with,
let's say, an Always On availability group.
The secondary, if you're in the same data center,
one of them would be high availability replica.
This is typically going to be a sync replica.
If this is a DR replica,
this will be an A sync replica.
Let's say for simplicity sake,
you have 64 cores on the physical machine,
you have another 64 cores on another secondary,
and you have another 64 cores on the other secondary as well.
All of them are the same. So this
makes the calculations a lot easier.
So for this type of architecture,
now you would need to license for 64 quarters of the
primary zero for your secondary,
which is the HA, and zero for the secondary which is the DR.
So the next question is, when their second reason they're passive,
what operations are allowed?
So the first is you can actually perform
backups on the secondary replicas.
You can perform any maintenance operations like your check DBs.
You can do consistency checks on them.
The third one is you can actually
run monitoring applications against these instances.
These monitoring applications can connect and get resources from
the secondary replicas or can
check if the SQL Server instance is online.
So monitoring application connections are allowed.
The fourth one is actually DR tests.
This is quite common in enterprises where you actually need
to switch from primary to secondary and perform a DR drill.
For a period of time,
you can actually bring
your secondary online and do
any DR test that you need to do to validate
that if there is a event where
you need to invoke DR or you need to practice your HA drill,
you could actually do that.
Secondary environments can be
actually brought online without incurring additional costs.
What is actually not allowed is any reads
from any production application
or writes from any production application.
This is absolutely not allowed.
So if you have any reads
or writes happening in these two replicas,
these would need to be licensed.
Now let's look at a more complex setup where you have
a data center here and you have another data center here.
Let's call this Data center One and Data center two.
In this scenario, if you have two replicas,
let's say this is the primary, this is the secondary.
You have another secondary here and another secondary.
So essentially this is a very common setup where you actually
replicate the environment in
both data centers so that if one data center does go down,
another data center can take over.
So let's say each of those has
64 cores and you're running SQL server instances on them.
Now if you have Software Assurance and you're
covering the primary replica with Software Assurance cores,
and the number of cores you would need to
license is 64 for the primary.
Let's say this is the HA replica and this is sync in nature,
you would need to license it with no cores because you get
the benefit for the DR instance.
Again, this is the first DR. You'd not need to license it.
For the second DR in the second data center,
you would need to license it because this is
a DR which is not residing in Azure.
In future episodes, we'll talk about how
this architecture can also be simplified and
a lower cost of ownership can be achieved with a similar setup.
Now other scenarios which include things like log shipping.
So if you have any environment that are using
log shipping or if you're just using a combination of,
let's say, SQL Server Failover Cluster
instances and let's say a log ship environment.
These benefits also apply there.
So irrespective of how you actually deploy
this particular architecture in any shape or form,
whether you're using log shipping,
whether you're using a Failover Cluster instances
or you're using availability groups,
these benefits do apply.
So stay tuned for more episodes in
the future where we talk about scenarios with
Azure VM and we talk about other scenarios
where the architecture completely
resides in Azure. Thanks for joining.
[MUSIC]