Regions and ADs

OCI has been built using the concept of regions. A region is simply a physical location in the world where OCI hosts data centers. In a nutshell, a region is a localized geographic area. Within a region, OCI hosts one or more physical data centers and calls this an Availability Domain (AD).

In this section, we will look at the main concepts of OCI in more detail, such as regions, ADs, and fault domains. Additionally, we will learn how to subscribe to other regions.

A lot of OCI services are regional; for example, Virtual Cloud Networks (VCNs). If you create a VCN, it will span across the AD. Other services are AD-specific, such as compute resources. You can create a compute instance that has access to a specific AD. Additionally, there is a very strong interconnectivity between the ADs within a region and across regions. Within an AD, interconnected traffic is encrypted as well.

As of August 2020, there are 26 regions and 6 interconnected Azure regions that are live. The following map shows the different regions that are currently live across the globe:

Figure 1.1 – OCI regions

Oracle's strategy is to add new regions around the world in order to give customers local access to its cloud resources. To speed up the process and still provide high availability, OCI has launched one AD region that has three fault domains inside the physical AD. We will discuss fault domains in more detail later in this chapter.

OCI regions are dispersed via vast distances across countries and even continents. When a customer deploys their application, they typically put that application in the region where it is most heavily used. However, there are multiple reasons why someone might choose to put their applications in different regions, such as the following:

• A natural calamity could affect a whole country or continent.
• Data jurisdiction drives data locality requirements.

The following table identifies a region, its identifiers, location, region key, realm key, and the number of ADs within it:

Important note

The data in the table is accurate as of August 2020. However, it may not remain accurate as Oracle is rapidly adding new regions and interconnected Azure regions. You can refer to Oracle's public documentation to find the latest information on the available regions at https://docs.cloud.oracle.com/en-us/iaas/Content/General/Concepts/regions.htm?.

Managing regions from the OCI console

You can subscribe to any of the commercially available regions from the OCI console. However, doing so requires administrative privileges.

During the sign-up process, OCI will create a tenancy and assign a region to you. This is called the home region. You cannot change this home region later. However, you can subscribe to other available regions. By doing so, OCI will replicate your identity resources to the new region.

To view the subscribed regions, follow these steps:

1. Log in to the OCI console.
2. Open the Regions menu.
3. View the subscribed region(s). Please note that all the region names that appear in the Regions menu are the regions that you are subscribed to already.

To subscribe to other regions, perform these steps:

1. Log in to the OCI console.
2. Open the Regions menu, and then click on Manage Regions, as highlighted in the following screenshot:
   

   Figure 1.2 – The list of subscribed regions

3. Check which region you want to subscribe to, and then click on Subscribe, as shown in the following screenshot:

Figure 1.3 – The Infrastructure Regions subscription page

So, you can see how simple it is to subscribe to regions where you want to consume cloud resources.

Logical view of Oracle Cloud Infrastructure components

OCI regions are part of a realm. A realm is a logical collection of regions. Realms do not share any data. While regions within a realm can share data via replication, regions in separate realms are completely isolated from each other.

Tenancies

OCI users live in a tenancy, which is a logical grouping for a business customer that contains users, groups, and compartments. A tenancy is based in a home region but can be subscribed to other regions. When a tenancy is subscribed to another region, tenancy data created in the home region is automatically replicated to the subscribed region. Replication of this data is required to call services in that region. Identity data can only be modified in the tenant's home region.

Bootstrapping

A tenancy is created when the accounts service receives a request to create an account entitlement. The account service coordinates with the Identity and Access Management (IAM) service to generate several resources, such as the tenancy (root compartment), a default access policy, a user account, and an administrators group to which the user is added.

When the user account is created, a one-time password (OTP) is generated. With this password, the user can sign in to the web console and upload the public part of the key pair they generated. Once this is done, the user can start making signed calls to the OCI APIs using command-line interface (CLI) tools.

Compartments

Compartments are the logical containers of resources. Compartments typically have a policy attached to them to control access to the resources inside. Compartments can be nested as well. They can span regions, which makes it possible to add, for example, compute instances from different regions to the same compartment and have them guarded by the same policy.

Oracle Cloud Identifiers (OCIDs)

Resources in OCI are identified by unique Oracle Cloud Identifiers (OCIDs). An OCID consists of different parts separated by dots:

ocid1.<resource type>.<realm>.[region][.future use].<unique ID>

Let's take a look at the various parts that make up the OCID:

• ocid1: This indicates the version of the OCID.
• resource type: This is the type of resource. For example, a resource can be an instance, a volume, a VCN, a tenancy, a user, or a group.
• realm: This indicates which realm the resource is in. For example, all production regions use oc1.
• region: This indicates where this resource is located.
• future use: This is reserved for future use; therefore, you are likely to see a blank space here.
• unique ID: This section is the unique portion of the ID. You might notice a different format depending on the type of resource or service.

Here are a couple of examples:

ocid1.tenancy.oc1..aaaaaaaaba3pv6wkcr4jqae5f44n2b2m2yt2j6rx32uzr4h25vqstifsfdsq
ocid1.instance.oc1.phx.abuw4ljrlsfiqw6vzzxb43vyypt4pkodawglp3wqxjqofakrwvou52gb6s5a

OCI's regions are physically divided into ADs, which are named by numbering them (for example, phx-ad-1, phx-ad-2, and phx-ad-3). It is a human tendency to pick the first AD from a given list when it comes to creating a compute instance in an AD. In order to stop you from doing this, OCI gives each tenancy a random set of logical ADs. This is called AD obfuscation. Logical AD names look like SQPR:PHX-AD-1, and physical AD names look like phx-ad-1.

AD, which is nothing but physical data centers, are far away enough that they are completely independent, from a failure perspective, but are close enough to have very low-latency connectivity. Customers get to choose what AD they create resources in, such as compute instances, databases, and more. This selection, however, is randomly mapped to a physical AD to prevent the uneven usage of ADs. In the following screenshot, you can see a logical view of the mapping of ADs in a region and how that maps to a fault domain inside it:

Figure 1.4 – An OCI AD

Inside an AD, OCI runs a highly scalable and high-performance network, which is not oversubscribed. Due to this design of non-oversubscription, there is no noisy neighbor problem. In terms of scalability, this AD can scale up to approximately 1 million ports. Additionally, because of the no noisy neighbors and non-oversubscription network, this AD has predictable low latency and high-speed interconnectivity between hosts that don't traverse more than two hops. In the following logical diagram, you can see a mapping of how the physical network infrastructure connects to the regions:

Figure 1.5 – The layout of OCI's physical infrastructure

OCI's first four regions (Phoenix, Ashburn, London, and Frankfurt) consist of three ADs. Each AD is in a physically separate data center.

In these initial regions, Oracle built many foundational services that were specifically tied to a single AD. This is so that there would be no dependencies outside of a single AD. A compute service is the most prominent example of this.

After the first four regions, Oracle shifted their strategy. The majority of customer workloads do not take advantage of ADs for high availability, and, instead, they rely on high availability within an AD and use multiple regions to support disaster recovery. Therefore, OCI adapted to this by launching a larger number of single-AD regions.