Note:
- This tutorial requires access to Oracle Cloud. To sign up for a free account, see Get started with Oracle Cloud Infrastructure Free Tier.
- It uses example values for Oracle Cloud Infrastructure credentials, tenancy, and compartments. When completing your lab, substitute these values with ones specific to your cloud environment.
Monitor OCI Load Balancer backend operations for DevOps
Introduction
In this tutorial you will explore editing a backend’s weight, drain state, offline state, and backup state to see the resulting behavior. These are all useful features that can make your application deployment, maintenance, and recovery simple and seamless.
Objective
Monitor the OCI Load Balancer backend weight, drain state, offline state, backup state and understand how it affects traffic.
Prerequisites
- Access to an Oracle Cloud Account. If you do not have an Oracle Cloud Account, you can use a Always Free Tier account.
- Create and configure a Virtual Cloud Network.
- Create a Load Balancer with multiple backends.
Task 1: Monitor OCI Load Balancer default behavior
This example utilizes a weighted round robin distribution policy, with all weights being equal.
-
We are using the OCI Load Balancer setup as shown in the following screenshot:
-
Prediction: All servers are healthy, so this is expected to cycle through all the backends sequentially.
-
The following images show the actual behavior:
The behavior is as expected with the Load Balancer cycling through all backends sequentially.
Task 2: Monitor the OCI Load Balancer backend weight
A backend’s weight determines what proportion of incoming traffic it will receive, with a higher weight indicating a larger proportion. For example, a backend weighted “3” receives three times the number of new connections compared to a backend weighted “1”.
-
We are using the OCI Load Balancer setup as shown in the following screenshot:
To achieve this:
- Navigate to the backend.
- Select the checkbox next to it and click Edit Weight. Specify the weight.
-
Prediction: The higher the weight the larger the proportion of traffic sent to the backend. If the weight for one backend is 2x that of the other backends, it should receive twice as much traffic. If 10x, ten times as much traffic, and so on.
-
Actual behavior: Here is a table displaying how many times the three backends are hit when modifying backend 2’s weight.
Backend 2 Weight # Backend 1 # Backend 2 # Backend 3 1 4 4 4 2 3 6 3 3 3 7 2 4 2 8 2 5 1 9 2
The weights work as expected.
Task 3: Explore the OCI Load Balancer backend drain state
Setting a server’s drain state to true means the Load Balancer will stop forwarding new TCP connections and new non-sticky HTTP requests to the backend server. This allows you to seamlessly take the server out of rotation and is useful for maintenance purposes.
-
We are using the OCI Load Balancer setup as shown in the following screenshot:
To achieve this:
- Navigate to the backend.
- Select the checkbox next to it and click Edit Drain State. You should see the drain status for the backend go to “Drained”.
-
Prediction: Backend 3 should not receive any new requests, so requests should now round robin between Backend 1 and Backend 2.
-
Actual Behavior: As expected, Backend 3 has been drained of all connections and does not receive any new TCP or non-sticky HTTP requests. Consequentially, the Load Balancer bounces back and forth between Backend 1 and Backend 2.
Note: Drained backends do not receive any new TCP or non-sticky requests. Even so, the Load Balancing service considers a server marked “drain” available for existing persisted sessions. This means existing persisted sessions will still hit the drained backend, but new requests not part of an existing persisted session will not.
Task 4: Explore the OCI Load Balancer backend offline state
A backend’s offline status determines if any ingress traffic is forwarded to it, sticky or not. For example, when set to “True”, the Load Balancer forwards no ingress traffic to the backend.
-
We are using the OCI Load Balancer setup as shown in the following screenshot:
To achieve this:
-
Navigate to the backend.
-
Select the checkbox next to it and click Edit Offline State. You should see offline status turn “True”.
-
-
Prediction: Backend 2 is completely offline, so we should bounce back and forth between Backend 1 and Backend 2.
-
Actual Behavior: After marking Backend 2 as offline, requests bounce between Backend 1 and Backend 3.
Task 5: Explore the OCI Load Balancer backup state
Backup state allows you to define backend servers for disaster recovery scenarios. If a server’s backup status is set to “True”, the Load Balancer forwards ingress traffic to it only when all other backend servers not marked as backup are offline.
Note: Backend servers marked as backup are not compatible with Load Balancers using the IP Hash policy.
-
We are using the OCI Load Balancer setup as shown in the following screenshot:
To achieve this:
- Navigate to the backend.
- Select the check box next to it and click Edit Backup State. You should see backup status turn “True”.
-
Prediction - Initially, with all health checks passing, the Load Balancer should round robin between Backend 2 and Backend 3. Backend 1 should only start receiving requests when both Backend 2 and Backend 3 are unhealthy.
-
Actual Behavior: With all three health checks passing:
The Load Balancer bounces back and forth between Backend 2 and Backend 3. However, once we take the two servers offline:
The Load Balancer begins to serve only Backend 1.
Related Links
Acknowledgements
- Author - Cody Brinkman (Cloud Architect)
More Learning Resources
Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.
For product documentation, visit Oracle Help Center.
Monitor OCI Load Balancer backend operations for DevOps
F75028-01
January 2023
Copyright © 2023, Oracle and/or its affiliates.