F5 – Redis Load Balancing Settings

This blog post will discuss some crucial configurations for integrating an F5 load balancer with a Redis setup using Sentinel for high availability. Redis Sentinel manages a master-slave configuration, and the F5 load balancer needs to recognize the current master node. We will focus on two key settings:

1. Configuring Monitor settings to detect the Redis Master.
2. Ensuring that all sessions to a failed node are terminated as soon as possible.

Monitor Settings:
The first crucial configuration is within the Monitor settings of your F5 load balancer. This is where you instruct the load balancer on determining which Redis node is currently acting as the master. This is done using send and receive strings.

Below is an example configuration:

CLI:

monitor redis-is-master-custom {
   defaults from tcp
   interval 2
   timeout 5
   recv "role:master"
   send "info\r\nquit\r\n"

GUI:

Explanation:

1. Monitor Name: redis-is-master
   • This is the custom name given to the health monitor.
2. Defaults from tcp:
   • This line indicates that the health monitor inherits default settings from a pre-defined TCP monitor. TCP monitors generally check the availability of a server by establishing a TCP connection.
3. Interval 2:
   • This sets the frequency at which the health monitor checks the status of the Redis server. In this case, it checks every 2 seconds.
4. Timeout 5:
   • This specifies the duration the monitor waits for a response from the Redis server before considering it unresponsive. Here, the timeout is set to 5 seconds. If the Redis server does not respond within this time frame, it is marked as down or unhealthy.
5. Recv “role:master”:
   • This line defines the expected response for the server to be considered healthy. The monitor expects to receive a response that includes the text role:master. This specific text indicates that the Redis server is currently operating as a master node.
6. Send “info\r\nquit\r\n”:
   • This line specifies the command that the monitor sends to the Redis server. The info command requests detailed information about the server, and \r\n is a carriage return and line feed, signalling the end of a line. The quit command then closes the connection. The monitor uses the response to this command to determine if the Redis server is the master node, based on the ‘recv’ condition.

In summary, this F5 health monitor is a specialized TCP monitor tailored for a Redis deployment. It continuously checks (every 2 seconds) to ensure that a given Redis server is functioning as a master node. It does this by sending a specific command to the Redis server and expecting a particular response. If the Redis server does not respond as expected within 5 seconds, or if the response does not indicate that it is a master node, the monitor will mark it as down or unhealthy. This is crucial for high-availability environments, ensuring that traffic is only directed to the Redis master node.

Handling Failover:
Once the F5 load balancer is configured to detect the master node, the next step is to ensure that existing connections are handled properly during a failover. By default, connections might not be dropped even when there’s a failover, which could lead to issues. A setting under the pool settings controls this behavior.

By default, this mode is set to “none” However, in a high-availability environment, especially when using Redis, it’s advisable to change this setting to “reject” under “Action on Service Down.”

See the configuration below:

Explanation:
By setting the mode to “reject,” the F5 load balancer will immediately terminate both the client and server-side connections in the event of a node failure. This ensures that in the case of a failover, your applications will not experience issues due to lingering connections to the failed node.

Conclusion:
Configuring the F5 load balancer properly is vital when integrating it with a Redis setup using Sentinel for high availability. By setting up the monitor settings to detect the master node and ensuring that connections are terminated promptly during failovers, you can achieve a robust and highly responsive environment.