Hello there, I am Sriram Natarajan and I am part of the Oracle Bare Metal Cloud Services product management team.

 

Today, I am excited to share more information about the Oracle Bare Metal Cloud Load Balancing Service (currently in Preview) and how this service helps achieve common business objectives such as higher availability, minimal downtime, and disaster recovery.

 

On the Bare Metal Cloud platform, we offer three separate data centers (what we call availability domains), connected via a high-speed, low-latency network, within a geographical region. You can use our API/Console to create a virtual cloud network (VCN) that spans these three availability domains to run applications across these availability domains.

 

Now, as you transition from development to production, you need an entry-point to transparently manage and distribute Internet traffic to these application clusters (web-tier and application-tier). The Bare Metal Cloud Load Balancing Service offers such an entry-point!

 

Here is a quick rundown of the Load Balancing Service:

  • A regional service to distribute traffic to your compute instances either within the same availability domain or across multiple availability domains
  • Handle modern protocols such as HTTP/2, and WebSockets in additional to traditional protocols such as HTTP and TCP.
  • Continuously monitor your application health via application specific health-check policy.
  • Use any DNS vendor to easily attach a DNS name or vanity URL domain name to the load balancer provided public IP address.

 

Let us say you wish to deploy a mission critical application such as Oracle EBS within our Phoenix geographical region. Here is one way to go about achieving this objective:

  • To start with, you can easily create a cloud network connecting all the three availability domains within the Phoenix region and run EBS web, application, and database-tier across all these three availability domains.
  • Then, you can use our load balancing service to create a redundant load balancer, across two availability domains, within your cloud network.
  • The load balancing service ensures that your load balancer continues to be available, even during an extreme event such as availability domain outage, and continues to distribute Internet traffic to your applications across other availability domains.

 

Here is a topology to help you visualize the above architecture:

 

 

LB Diagram.PNG

 

In this topology, you will:

  • Create a cloud network connecting multiple availability domains, and a subnet that is specific to an availability domain
  • Create multiple compute instances within a subnet to host your web, application or database tier.
  • Create a load balancer resource across two subnets (say load-balancer subnets) from different availability domains. Here, the load balancing service is responsible for ensuring that the load balancer is available across these two subnets. Because this load balancer is Internet-facing, you should have different security policies on who should administer this subnet and how should traffic flow to the load balancer subnets.
  • Run your application and database tiers in different subnets (say application subnets) that do not have direct access to the Internet.
  • Create security list rules so that traffic can flow between load balancer subnets and application subnets.

 

Using a topology such as this allows you to meet your security objectives without having a single point of failure.

 

To wrap this up, here are some key benefits you get with our Bare Metal Cloud Load Balancing Service:

  • Increase application availability by distributing Internet traffic to applications either within the same availability domain or across all the availability domains within a region.
  • Secure application deployment by handling SSL traffic either at the load-balancer tier or across every tier.
  • Reduce latency by enabling users to connect to the load-balancer via modern HTTP/2 protocol.
    • When your users use modern web browsers to connect via HTTP/2 enabled load balancer, then they will see faster load times because HTTP/2 protocol supports header compression and connection multiplexing to avoid the costly connection overhead.
    • Your web/application tiers can work as-is because Load Balancer will continue to communicate to these applications via standard HTTP.
  • Deploy modern cloud-native applications behind the load balancer as the load balancer supports load balancing WebSocket-based applications.

 

Lastly, as with other services on our platform, the load balancing service allows you to manage load balancers via APIs/Console, and setup access management policies restricting who has access to use or manage these load balancers.

 

I am super excited to have you try out our load balancing service and to hear your feedback. Please write to us to participate in our preview and to share your use cases.

 

Sriram Natarajan

Principal Product Manager

Oracle Bare Metal Cloud Team