00:00Welcome to this lesson on OCI architecture.
00:07In this lesson, we will cover the core constructs of OCI's physical architecture, starting with regions.
00:15Region is a localized geographic area comprising of one or more availability domains.
00:21Availability domains are one or more fault-tolerant data centers located within a region but connected to each other by a low-latency, high-bandwidth network.
00:35Fault domains is a grouping of hardware and infrastructure within an availability domain to provide anti-affinity.
00:42So, think about these as logical data centers.
00:47We looked at it in the previous lesson.
00:49Today, OCI has a massive geographic footprint around the world with multiple regions across the world and we also have a multi-cloud partnership with Microsoft Azure and we have a differentiated hybrid cloud offering called Dedicated Region Cloud at Customer.
01:09But before we dive into the physical architecture, let us look at how do you choose a region.
01:14First thing is, choosing a region, you choose a region closest to your users for lowest latency and highest performance.
01:22So, that's a key criteria.
01:24The second key criteria is data residency and compliance requirements.
01:28Many countries have strict data residency requirements and you have to comply to them and so you choose a region based on these compliance requirements.
01:37The third key criteria is service availability.
01:40New cloud services are made available based on regional demand, at times, regulatory compliance reasons and resource availability and several other factors.
01:50Keep these three criteria in mind when choosing a region.
01:55So, let's look at each of these in a little bit more detail.
01:59Availability domain.
02:00Availability domains are isolated from each other, fault tolerant and very unlikely to fail simultaneously.
02:07Because availability domains do not share physical infrastructure such as power or cooling or the internal network, a failure that impacts one availability domain is unlikely to impact the availability of others.
02:23So, as you can see in this graphic here, a particular region has three availability domains.
02:28One availability domain has some kind of an outage is not available, but the other two availability domains are still up and running.
02:35We talked about fault domains a little bit earlier.
02:40What are fault domains?
02:41Think about each availability domain has three fault domains.
02:44So, think about fault domains as logical data centers within availability domains.
02:49So, as you can see in the picture here, we have three availability domains and each of them has three fault domains.
02:56So, the idea is you put the resources in different fault domains and they don't share single point of hardware failure like physical servers, physical rack, top of rack switches, or power distribution units.
03:09You can get high availability by leveraging fault domains.
03:14We also leverage fault domains for our own services.
03:17So, in any region, resources in at most one fault domain are being actively changed at any point in time.
03:24This means that availability problems caused by change procedures are isolated at the fault domain level.
03:32And moreover, you can control the placement of your compute or database instances to fault domain at instance launch time.
03:39So, you can specify which fault domain you want to use.
03:43So, what is the general guidance?
03:44The general guidance is we have these constructs like fault domains and availability domains to help you avoid single points of failure.
03:54We do that on our own.
03:56So, we make sure that the servers, the top of rack switch, all are redundant.
04:01So, you don't have hardware failures or we try to minimize those hardware failures as much as possible.
04:06You need to do the same when you are designing your own architecture.
04:11So, let's look at an example.
04:12You have a region, you have an availability domain and as we said, 1AD has three fault domains.
04:18So, you see those fault domains here.
04:20So, first thing you do is when you create an application, you create this software-defined virtual network.
04:25And then let's say it's a very simple application.
04:28You have an application tier, you have a database tier.
04:31So, first thing you could do is you could run multiple copies of your application.
04:36So, you have an application tier which is replicated across fault domains and then you have a database which is also replicated across fault domains.
04:46Why do you do that?
04:47Well, it gives you that extra layer of redundancy.
04:50So, something happens to a fault domain, your application is still up and running.
04:54Now, to take it to the next step, you could replicate the same design in another availability domain.
05:01So, you could have two copies of your application running and you can have two copies of your database running.
05:07Now, one thing which will come up is how do you make sure your data is synchronized between these copies.
05:12And so, you could use various technologies like Oracle Data Guard to make sure that your primary and standby the data is kept in sync here.
05:22And so, you can design your application, your architectures like these to avoid single points of failure.
05:30Even for regions where we have a single availability domain, you could still leverage fault domain construct to achieve high availability and avoid single points of failure.
05:41Let's summarize what we learned in this lesson.
05:45So, we looked at region.
05:46Region comprises of availability domains.
05:49Availability domains comprise of fault domains.
05:51So, let's look at the inside-out view.
05:54So, first let's start with fault domain.
05:56Fault domain provide protection against failure within an availability domain.
06:00Availability domain themselves provide protection from entire availability domain failures, particularly in a multi-AD region.
06:08And then, you have this concept of region pair where in every country we operate or most of the countries we operate, we have at least two data centers.
06:17So, you could use the second data center for disaster recovery or backup.
06:21It also helps you to comply with data residency and compliance requirements.
06:27And then, not only this, we also have SLAs on availability, management, and performance.
06:32To recap, we looked at the physical architecture of OCI with regions which are geolocations.
06:40We looked at availability domains.
06:42And then, every availability domain has three fault domains.
06:44So, use these architectural constructs to design your applications which are highly available and avoid single points of failure.
06:53Thanks for watching.
Comments