Hello, Siberians. Welcome to Lesson 3.4. Off Monetary Off. Discuss stated Microsoft Azure architect design.
Here are the objectives that will be covering in this lesson.
We'll start out by covering as your sequel design decisions from the scalability perspective.
Then we'll move on to cover design decisions from an availability perspective
and finally will cover as just sequel design decisions. From a monitoring perspective, let's get right into this. Let's talk about scalability and some of the information that we need to know when designing for scalability off. I just said, Quote database.
The compute size can go up to 80 virtual calls, regardless off the deployment model that we have. So whether that single database, elastic pool or manage instance, we can go up to 80 vigil costs
that also the paint on the tear that we select our we've specified that
when it comes to the size of our database
for single database on elastic food database,
we can go off to four terabytes if we're deploying the general propose or business critical service tears. If we're deploying the iPods killed here, we can go up to 100 terabytes
when it comes to the managed incense. The maximum size of the database is eight terabyte, and that has to be the general propose serviced here for the business critical service. Day Off Manage instance, we can only go up to fourth of a bite
when it comes to design in five Gullibility and Hodja
What you're looking at on the screen at the different options of the different features that are available for just sequel that can help us without designed for business continuity and disaster recovery.
For example, let's start with automatic backup automatic backups I enabled by default as as just secrets and managed service. This is a neighborhood for house automatically taken on. It's not something that we can disable.
This protects against things like accidental corruption off delish in where we can do point in time, restore to our database states at the previous point.
Also, the back of that are taken are protected in that their start on job redundant stoppage, which means storage that is spread across different regions in Hajer,
the back off happen transparently in the background without impacting on performance. Fullback offs are taken every week.
Differential backups happens twice a day every 12 hours transaction log backups or call every 5 to 10 minutes.
Did the fault retention period for the back office is seven days, but we can extend this. We can configure the so for the general proposed on the business critical service here we can extend this often, detective five days retention period so that if there were to be an accidental corruption or delusion, we can restore back
provided we gets to eat within 35 days. Otherwise, stand that gets
We can use this backups to restore our database to a point in time in the past,
provided we do that within the retention period,
we can also use it to restore a deleted data base within the retention period if it databases accidentally deleted that fine.
However, we cannot use this to restore a data if the server is deleted.
If Ana Jossy core database, which is the administrative container for our databases and elastic pools, if that is deleted, we cannot use this automatic back off to restore that
when it comes to long term backup retention.
This is something that we can use as an extension of the automatic backups.
We have different complaints requirements to meet. We can extend our attention
So this backups are also gonna be start on your redundant storage off with access job redundant storage. We can enable long term retention for single database for elastic pooed it basis. It's not yet available for managed instances.
It can be used to restart if the survives deleted. So that's one of the good use cases of days. If if you, the latest of either accidentally are maliciously,
you can go to your long term backup retention because that copied off to another stoppage on, then you can restore your databases back from there.
That's also a feature of our Jessica called active replication,
because while backups of Great
they're great for disaster recovery, it doesn't help us with downtime during on plant or temporary plan failures. What do I mean by that? Let's say you wanted to do some application upgrades, and you need to be able to fail over. If there were to be
a confusion of their way to be an issue, something goes wrong.
That's where backups men will be great for that
where replication can be a useful technology forced to use. So what active your application does? Is it leverages, Theo always on technology of C course ever
on. It s in Conus Live replicates committed transaction on a primary database with the country database. So essentially, we have province a country database that stays in sync.
Andi, we can have up to 4 600 databases for each primary database.
And if I intervene in our primary database feels
or it's needs to be taken off line. We can initiate a fan over to any of us A country databases that we'll have applications, huh?
And we can promote them, actually to the primary.
So because the secondary databases RV edible,
they can also be used to offload read on Lee workload like reporting jobs. So when once you configure activity replication on your neighbor days, you can actually take advantage off your replicated databases to secondary at once on then run your reporting against them.
So active job application is not yet supported by managed incense.
And finally, when it comes to availability stark about something called auto failure of a group. Now what a fan of a group.
Think about it as an extension off activity of application right, so active your application helps us to replicate at databases. But the thing is, when it comes time to initiate the fail over, that still has to be done by house. We still needs to get involved. Now. We cannot make statute to some other process that we have,
but that do something that needs to come from us. What active fell over group does? Is it as an extension to that
on it? Also so transparent fail over off our database to the secondary database.
auto fan of a group is supported by managed instance. So that's great. We can use that in this scenario.
Let's talk about monitoring off. I just sequel when we talk about monitoring off azure in general, or any service in Azure where main liver for into three men. Things
we're talking about metrics. Now metrics are defined as numerical values that describes some aspect of a system at a particular point in time. What does that mean? What that means is information about the service that, um, eat it by the as your platform,
for example, wants the CPU utilization. What's the memory? Installation was the star digitalization
those sorts of information that a meted, sort of like from the eye, provides a level or from the azure platform in this case, those I referred to as metrics.
You describe the state of a system at a point in time
so we can go ahead and view this information about metrics off our logistical data bases in the metrics Explorer. This is not something that we need to enable. Once we deploy service, metrics are automatically a meted every one minute for most metrics by, in some cases can be every five minutes.
Then we have the activity locks and activity logs that provide insight into subscription level event. What does that mean? We're talking about administrative event or administrative oppressions. Would did this action. When did they do this action? What action did they do? Right?
Dosa dosa, administrative activities Also coming from the platform.
When it comes to activity logs, there's nothing that we need to do house. So it's automatically emitted by. There's your platform so we don't need to do anything. In this case, we can just exploit each using the activity logs Explorer.
Then they come to diagnostic logs.
Now diagnostic logs refer to events that are coming with dinner system or with dinner service.
So while metrics comment from within the platform itself, diagnostic clocks are coming from within the adjusted course Service itself. Another what, what exactly at the different operations that are going on within the service, And that's where we can get a lot of insight into our databases.
So when it comes to diagnostic locks,
it's something that's my neighbor by default. As I mentioned, it's something that we have to enable
but on we have to enable this in as your sequel are Jessica managed Instance.
Now when we go to enable this, we have the option to send this data tow three destinations
it a storage account event up on log analytic walk space on their different use cases for this different destinations. For example, if you're gonna be sending this information to adjust a bit accounts the menus case for this is archive in. You wants to take all these diagnostics information on, then archived them.
You could collect them. Just incident, taught Pattie information, or you could just start them
at a very low price.
When you enable diagnostic settings,
you can configure it retention period for this information in the eye. Just storage account.
It's a joint event. Hop
now the menus case for Joy Event hop is to integrate this information that's coming from within azure sequel service with custom monitoring solutions or ought pipelines. What that means that we can do near view Time analytics and insight
into our azure service on event ob
allows us to be able to do this.
Also, in this case, when we're nibble this option, we can configure the retention period
where where we can define our longer data is gonna be starting actually went up.
The corruption is log analytics workspace.
This option is mainly for the use case off getting intelligent monitoring or intelligent inside out off this information. So as your log analytics is and it's another service in Azure, where you have, like this Logan ITICs workspace where we can send this information into,
and then we can use something like to call the Cousteau query language
toe query, all the information that's inside this workspace, and then we can get insight
on dhe information. Useful information on trains out off this data that way, just passing into the workspace
we can either go down the path off, building out the queries and building out of a pot fire myself.
Oh, we can go down the path off as just equal analytics. Justin Quayle Analytics is unavailable Solution. A very made available solution in hasher that can layer on top off the Log Analytics workspace to extract insight about Ahjussi code
service from information that's in the log genetics workspace of I don't knows beauty In all these queries and reports on all these friends from scratch by ourselves, we could just leverage this solution.
There's a difference in this case because the retention period is not something that we coughing configure when we enable deception.
The retention period is based on what is configured for the walk space itself, which the default father Logan antics workspaces. That's one days, but something that can be extended to 7 30 days in Logan writings based on the option that's configured yet.
So why don't stop this recording this video for now, and I resent the next video with the other information about agile Seiko database design decisions.