Introduction

Load Balancer

I think it goes without saying that load balancer's are pretty straight forward.  Load balancer's are used where:

1. Redundancy is important

2. Increased Scalability 

3. Reduced Downtime

4. Increased Performance

5. Efficiently Manages Failures

Here is a link that shows how to configure an Load Balancer in OCI.

First, I will be constructing two load balancers that will front end two compute nodes; where we will host a simple home page for vk.ociateam.com.  Each load balancer will reside in two different regions; Toronto and Sydney.  

The Architecture in each region:

Of course in a production environment I highly recommend that you at least terminate SSL at the Load Balancer.  Check out these great post that explains how to turn on SSL for load balancing and automatic certificate renewal.

Traffic Steering Policy

Now that my load balancers and compute instances are setup, I will create a new traffic steering policy.  A common use case for traffic steering policies is the fail-over scenario.  You can also read about it here.

I will setup the same fail-over scenario.  In my case I will use the load balancer in Toronto to handle all requests.  If there is any issues with the Toronto load balancer or issues with Instance1 and Instance2, the request will fail-over to Sydney.

Here is my setup:

Here you can see that my answer pool is the load balancers IP address in Toronto which has the highest priority.

The fail-over will not work unless you have the health check also configured:

DNS Zone Management

During the Traffic Steering policy screens above, I added the sub-domain 'vk' as depicted below. You can also leave this blank and attach it after you have created the steering policy. 

If you are using OCI DNS for your domain, when the Traffic Steering policy gets created or when you attache a domain, a DNS 'A' record is created for your domain under the covers.  If your DNS is hosted elsewhere you must ensure that a record is created to direct users to your site location.

Within the DNS Zone Management screens , if there had been an DNS entry for vk.ociateam.com then you would have seen a similar record below:

Notice the ‘….occluded by Steering Policy’.  Basically this means that the steering policy will supersede and apply the policy to the request. 

I can now test my domain vk.ociateam.com.  To simulate the fail-over, I will shutdown the two compute nodes in Toronto.  Now I get redirected to the Sydney load balancer:

Web Application Firewall

Now that I have fail-over to my web site configured, I want to setup a Web Application Firewall (WAF) to block unwanted requests.

Here is a post that describes some of the protection mechanisms you can apply to protect your site.

For my use case I will:

1. Log each request to get a sense of what traffic my site is receiving and

2. I will block certain IPs from accessing my web site.  

To set this up, I need to modify how vk.ociateam.com gets accessed.  Now the WAF will be the entry point for vk.ociateam.com; currently that domain is attached to my Traffic Steering Policy.

The first step is to dissociate my domain with the traffic steering policy and assign a new subdomain.  I currently have:

I need to remove vk.ociateam.com from my policy and create a new one.  Let’s call it vkorigin.ociateam.com; here the name doesn’t really matter and it does not have to be in the same DNS domain.  It is just a pointer to another DNS record that will be used in my WAF origin configuration.

Now we will configure the WAF for vk.ociateam.com with an origin of vkorigin.ociateam.com.

Once the WAF policy is created you will see a message that will ask you to add the WAF endpoint to your DNS configuration.

This is the final step.  Now all traffic to vk.ociateam.com will be directed to the WAF endpoint!

Now lets add some Access Rules.  I added two rules:

1) Block a specific IP address

2) Allow and Log all traffic

 

 

 

The order of the Access Rules is important.  The more stringent rule should be first.

 

Now when I try and access my web site from a blocked IP:

 

 

Securing the network

One last thing and very important; you will need to secure your network so that no request can bypass the WAF.  Here are some steps you will need to take:

1) Your compute nodes should be on a private subnet; Oracle recommends that you create a Bastion host in a public subnet so you can access your compute nodes. 

2) The security list for the compute nodes should have an specific Ingres rule to allow traffic only from the load balancers IP.

3) To secure your WAF, you must configure your servers to accept traffic from the WAF servers. Configure your origin's ingress rules to only accept connections from the following CIDR ranges.

Thats it! Good luck!

P.S. The title of my blog post was inspired by the 'Great Highway'.