OCI DNS Geolocation Traffic Steering and Object Storage

Hi! In this blog entry, we will talk about an interesting use case: how to use OCI’s DNS Traffic Steering service, with a Geolocation policy, to direct clients to the closest Object Storage public pucket.

Prerequisites

To be able to configure this in OCI we need the following:
- Certificates for a DNS domain you own because we will use an OCI Load Balancer to redirect the traffic. We will need a public SSL certificate, the certificate chain (up to the root) and the private key.
- A DNS domain (or subdomain) managed by OCI’s Public DNS service to be able to use Traffic Steering Management policies
Note: For details on DNS Traffic Management, please check our documentation.

The use case

Let’s say you have static content in an OCI Public Bucket and your users need to access it from all over the world. Users closer to the OCI Region that holds the bucket will have a better experience compared to users that are across the globe. To help users who are far from the bucket you could:
a) Use a Content Delivery Network – this is a textbook CDN use case: static content, single Origin, need for global coverage.
b) Replicate the bucket’s content into multiple OCI regions. Use DNS Traffic Steering with a geolocation policy to redirect the users to the closest OCI Region.
Let’s do a demo on the b) option above.

Demo

For the demo, I will create the following setup:
- 1 public Object Storage Bucket in OCI Frankfurt
- 1 public Object Storage Bucket in OCI Chicago
- Bucket replication from OCI Frankfurt to OCI Chicago
- 1 VCN with 1 Public subnet and 1 Public Load balancer in OCI Frankfurt
- 1 VCN with 1 Public subnet and 1 Public Load balancer in OCI Chicago
- A Geolocation Traffic Steering policy with the following setup:
        o Users from Europe will be directed to the Frankfurt Load Balancer;
        o Users from North America will be directed to the Chicago Load Balancer;
        o Users from outside those regions will be randomly distributed.
Let’s look at the diagram and discuss flows:

In the diagram above, we have one user in Europe and one in North America. They both want to access the same file – OCI.png – which is hosted in OCI Object Storage, in both regions. The user-facing FQDN is storage.oci-lab.cloud.  As the users put https://storage.oci-lab.cloud/OCI.png in their web browsers, the following will happen, based on the 1-6 steps in the diagram:
1. The host will want to do DNS resolution for storage.oci-lab.cloud. While we know that the request will go to the Local DNS server which will do a recursive lookup, I’ve simplified this step to show that, in the end, the OCI DNS servers will answer to that request.
2. Considering that a Geolocation Traffic Management Steering Policy is in place, each user will get the “A” record corresponding to the closest OCI Region Load Balancer.
3. The users will now do the https://storage.oci-lab.cloud/OCI.png request to the OCI Load Balancer.
4. The Load Balancer will have a redirect rule that will tell the user that the content moved to the corresponding public bucket in Object Storage.
5. The user will now request the same content from the public bucket. For example, the North America user will request the content to https://objectstorage.us-chicago-1.oraclecloud.com/bucket_path/OCI.png .
6. The Public Bucket will serve the traffic.
Let’s set this all up.

A. Object Storage Public Buckets deployment

The design works with as many buckets as you like, for example, you can do one for each continent. What is important is that all buckets should have the same content. If you plan to do this with only two buckets then we can use a cool feature called “bucket replication”. That means that we put the content into one bucket and then OCI will replicate/copy that content to the other bucket. I will use the Frankfurt bucket as “primary” and the Chicago one as a replica.

1. Go to the OCI Console menu, in Frankfurt, and choose Object Storage. Create a new bucket. Give it a name and leave everything else on default.

2. In the OCI Console, switch the other region (in my case-Chicago). Create a bucket there too.

3. Go back to the initial region – Frankfurt. Click on the bucket created in step 1. In the Resources menu, click Replication Policy and click Create. Select the destination bucket you created in step 2.

4. In the Bucket Details menu, click Edit Visibility. Make this bucket public.

5. Next, under Resources, click Objects and Upload a file. I will upload a picture called OCI.png.

6. After you upload it, click the 3 dots at the end of the row and take the object URL. We will need that later in the setup.

The URL for this file is https://objectstorage.eu-frankfurt-1.oraclecloud.com/n/ociateam/b/Frankfurt-Bucket/o/OCI.png.

7. Now switch regions again, to the other region. Click the bucket there. You should already have the file there, copied by the replication policy. Take a note of the URL. Mine is:

https://objectstorage.us-chicago-1.oraclecloud.com/n/ociateam/b/Chicago-Bucket/o/OCI.png

8. In the second region, edit the bucket’s visibility and make it public too.

Now that we are done with the Object Storage part, we can move to VCNs and Load Balancers.

B. VCNs and Load Balancers deployment.

We need to deploy one VCN in each region. The VCN layout and assigned CIDRs are not important, we only need a public subnet to host the Load Balancer. As this is intended as a demo, we will use the VCN Creation Wizard to quickly deploy a VCN and all needed OCI Gateways.

1. In the OCI Console, go to the primary region - Frankfurt. Under the burger menu, select Networking and then Virtual Cloud Networks. Click Start VCN Wizard.

As we don’t need any VPNs, use the first type. In the menu that opens, simply give it a name (I will call it FRA-VCN) and leave everything else as it is. Press Next and then Create.

After it gets deployed, we need to make some quick modifications to the public subnet. Enter the VCN Details page and click the public subnet.

Inside the public subnet, click on the route table.

Inside the route table, add a route for Object Storage via the Service Gateway.

In the end, the route table must have 2 routes: default to the Internet Gateway and Object Storage to the Service Gateway.

Next, go back to the public subnet details page and click the attached security list.

Add an ingress rule that allows HTTPS (TCP 443) from the Internet.

And we are done with the VCN in Frankfurt.

2. Repeat the whole procedure above and deploy a VCN in Chicago. Do not forget to modify the route table and the security list of the public subnet. You can use the same CIDR for the Chicago VCN.

3. Now that each region has a VCN, we will deploy a Public Load Balancer in each region. Let’s start with the main region, Frankfurt. Go to Networking -> Load Balancers and Create a new LB.

Give it a name, and make sure it’s Public. For the demo, the allocated bandwidth is not important.

Under “networking” make sure you select the VCN created earlier and the public subnet. Press Next.

In the next menu, do not add any backends and make the health check TCP 443. Press Next.

Note: If you have certificates that can act as “client” certificates you can switch the health check to HTTP and enable SSL via the toggle in that page.
 
In the next menu, create an HTTPS Listener. Make sure you add the certificate, the CA bundle and the private key. The certificate MUST allow the hostname which you will use in the DNS zone.

Press Next, enable logging and press Create.

Inside the Load Balancer page, we need to add backends. The backends will be the actual IPs of the Object Storage Service. To get those we need to do a nslookup on the FQDN.

In the Load Balancer details page, click on Backend Sets and click on the Backend set that was created.

In the new menu, add the three IPs as backends.

After you add them, make sure the Load Balancer turns to status “OK” before moving on.

Next, in the Load Balancer details page, go to “Rule Sets” and create a redirect rule. The rule will be customized according to the Object storage URL.

The last thing is to edit the Load Balancer Listener to add the Rule Set we created.

4. Repeat the same procedure and deploy a Public Load Balancer in the second region – Chicago. Make sure you use the correct backends for OCI Object Storage in Chicago and the correct redirect rule, based on the Chicago URL.

URL: https://objectstorage.us-chicago-1.oraclecloud.com/n/ociateam/b/Chicago-Bucket/o/OCI.png
Items in the redirect rule:
Host: objectstorage.us-chicago-1.oraclecloud.com
Path: /n/ociateam/b/Chicago-Bucket/o/{path}

Before moving to the next chapter, let’s note down the public IPs assigned to the Load Balancers. As they are randomly allocated by OCI, yours will be different.

- Frankfurt LB - 138.2.175.80
- Chicago LB - 207.211.184.13

C. DNS Steering policy

The last step in the setup is to create the Geolocation DNS Steering Policy. Go to Networking -> DNS management -> Traffic management steering policies (in any of the regions) and create a new one.

In the menu that opens, we need to fill in the details. First, select the policy type (Geolocation) and give it a name.

Next, configure the two pools, one will point to the Frankfurt LB and the other to the Chicago LB, with “A” records.

Next, configure the steering rules: Europe will go to Frankfurt, North America will go to Chicago.

Last, select no health check and attach the policy to a domain you have running in the OCI Cloud. As stated in the beginning, I will use storage.oci-lab.cloud.

Press Create policy and we are done.

Note: Typical DNS steering policies use the Health Check service to decide which pool a client will be directed to. However, for this particular use case, health checks will not work because the Load Balancer will return a 302 HTTP answer instead of the expected 200. Even so, the Object Storage service is highly redundant across Availability Domains so the chances for a full regional outage are extremely low.

Testing

To test the setup I will request  https://storage.oci-lab.cloud/OCI.png from a test computer in Europe and from one in US. Let’s see the results.

        Europe:

        US:

And we’re done, the policy is working as expected.

One last thing

You may not like, or your application may not like that the answer to the request is an HTTP Redirect to the oraclecloud.com domain. If you want to hide that you need to use a tool that can rewrite the HTTP header, like an F5 Load Balancer instead of the OCI Load Balancer. For a complete, step-by-step guide on how to implement that check out my blog.