This post covers the overview and concept of Availability Domain & Fault Domain in Oracle Cloud Infrastructure (OCI).
Note: OCI is part of IaaS Service model (other 2 Cloud Service models are SaaS & PaaS), where OCI is re-branding of Bare Metal Cloud Service (BMCS).
Another offering in IaaS from Oracle is OCI-Classic (or OCI-C) and to find the difference between two and when to use what, Check our previous post on OCI vs OCI-C here
Before we will deep-dive into Availability Domain (AD) & Fault Domain (FD), let understand the concept of Region in Oracle Cloud Infrastructure (OCI)
Region in Oracle Cloud Infrastructure(OCI)
OCI Servers & Data is hosted in a region where the region is a localized geographic area, as of August 2019, there are 11 regions for OCI i.e. London, Frankfurt, Ashburn, Phoenix, Toronto, Tokyo, Seoul, Mumbai, Zurich, Sao Paulo & Sydney.
- You can have OCI resources (Compute, Network, Storage) in multiple Regions
- When you create Tenancy (Account in Cloud) a Home Region is selected and later you can add more Regions
Note: For a full list of Oracle Cloud Regions including PaaS & IaaS check https://cloud.oracle.com/data-regions
Availability Domain (AD)
Availability Domain (AD) is one or more data centers located within a region. A region is composed of three availability domains. Services/Resources are either Region-Specific (like VCN) or Availability Domain Specific (like Compute)
Note: All the available domains in a region are connected to each other by a low latency, high bandwidth network, which makes it possible for you to provide high-availability connectivity to the Internet and customer premises, and to build replicated systems in multiple availability domains for both high-availability and disaster recovery wherein Regions are completely independent of other regions and can be separated by vast distances—across countries or even continents
Fault Domains in Oracle Cloud Infrastructure (OCI)
A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain contains three fault domains. Fault domains let you distribute your instances so that they are not on the same physical hardware within a single availability domain. A hardware failure or Compute hardware maintenance that affects one fault domain does not affect instances in other fault domains.
Use fault domains to:
- Protect against unexpected hardware failures
- Protect against planned outages due to Compute hardware maintenance
Note: Fault domains are available at no additional cost in all public region
For Best Practices See Fault Domains Best Practices for Your Compute Instance
Related/Further Readings
If you are just a beginner to Oracle cloud, then check our below posts to start your journey:
- 7 Days FREE Trial to Start Your Oracle Cloud Journey
- [Video]: Oracle Cloud Infrastructure (OCI) | Storage Object, Block | File Storage, Data Transfer Service
- [Video] Oracle Cloud Infrastructure (OCI) Compute CPU & Memory
- Amazon AWS or Oracle Cloud (Confused ?): Right Choice for DBA’s
- Role of Oracle Apps DBA in Cloud
Begin Your Cloud Journey
Begin your journey towards becoming an Oracle Cloud Expert and earn a lot more in 2024 by joining our FREE CLASS. You will also know more about the Roles and Responsibilities, Job opportunities for OCI Architects, Admins in the market, and what to study Including Hands-On labs you must perform to get the Higher Paying jobs.
Click on the below image to Register for Our FREE Class on MASTERING ORACLE CLOUD FOR DBAs, APPs DBAs, ARCHITECTS & SYS ADMINS
Erptree Oracle says
You’re so interesting and Fantastic; so nice to find someone with some original thoughts on this subject seriously. Many thanks for starting this up.
Rohit Pathak says
Thanks, Erptree for the feedback.
Regards,
Rohit
ASM says
Your company has decided to move a few applications to Oracle Cloud Infrastructure and you
have been asked to design it for Disaster Recovery (DR). One of the items of your design is to deploy
the DR at least 300 miles from the home site and minimize the network latency as much as possible.
Based on that, what will be the recommended deployment?
A. Deploy applications in different regions and have them connected using VCN Remote Peering
B. Deploy applications in two separated VCNs in different Availability Domains and use VCN Remote
Peering
C. Deploy applications in two separated VCNs in different regions and use VCN Local Peering
D. Deploy applications on the same region splitting workloads across Availability Domains.
Rohit Pathak says
Hi ASM,
Yes answer will be A, could you please let us know from where you get this question.
Regards,
Rohit
Subhajit Saha says
The network latency will be high if those are in different region.
D should be answer
ASN says
anyone who has the right answer
Confused between A & D
Wendell says
remote VCN peering. In this case, remote means that the VCNs reside in different regions. If the VCNs you want to connect are in the same region, see Local VCN Peering (Within Region).
So the correct is D
Sanjaykumar Ratanpara says
correct answer is A as remote VCN peering is for region to region connectivity
Saroj Mahanta says
Answer is D.
Reason :
A. Deploy applications in different regions and have them connected using VCN Remote Peering
Correct.
B. Deploy applications in two separated VCNs in different Availability Domains and use VCN Remote
Peering
Not Correct. If within ADs, then VCN Local Peering, NOT VCN Remote Peering.
C. Deploy applications in two separated VCNs in different regions and use VCN Local Peering
Not correct. If VCNs in different regions then we can use VCN Remote Peering
D. Deploy applications on the same region splitting workloads across Availability Domains.
Not Correct. this is done across FDs.