I wanted to fully understand the Ratio(Session) load balancing method.
I came across this question in the forums, but the links are old and it doesn't provide a clear answer, I want to know what exactly is considered a session in the Ratio(session), it's mentioned for the Least sessions that it depends on a Persistence profile (least number of entries in the persistence table) to determine the sessions for each pool member, for example HTTP cookie determines the session in this case, is it the same case for Ratio(Session)?
What is meant by a session exactly in the Ratio(Session) and is there a real-world example for this case?
In this article, it's mentioning that Ratio(Session) is used for protocols that transmit multiple messages over the same connection, is this the same case for HTTP for example using Cookie persistence like Least Sessions? It's not very clear to me how the system will count sessions if it's not based on persistence like the Least Sessions.
When I applied this load balancing method to a pool with multiple members, I noticed the requests where going to one member only.
@ahmadmhd The way both of them read is that persistence entries would come into consideration for both. I wouldn't recommend any session load balancing because that adds unnecessary levels of troubleshooting. Instead you might consider configuring a low persistence timer and either ratio(node) or least connections(node) so that you take the entire IP into consideration rather than just the pool member. With the low persistence timeout this should allow for relatively even load balancing.
The Ratio (Session) load balancing method in an F5 LTM device refers to distributing the load based on the ratio of active sessions, where a session refers to a series of related message exchanges. The method works by associating a ratio value with each pool member, and the system then distributes user sessions based on those ratio values.
For example, if you have two servers, Server A with a ratio of 2 and Server B with a ratio of 1, for every three sessions, two will go to Server A, and one will go to Server B. Regarding the concept of a session in Ratio (Session), it is not necessarily tied to persistence like in Least Sessions. The term 'session' in this context generally refers to a series of related message exchanges that can occur over time, possibly over multiple TCP connections or IP datagrams. In other words, a session could be a single TCP connection or a series of requests and responses between a client and server within a certain time period.
When it comes to HTTP traffic, a session could indeed involve multiple messages over the same connection. A single HTTP session, for example, might consist of a client making multiple GET requests and receiving responses over the same TCP connection. As for why all requests were going to only one member when you applied this method, it could be due to a variety of reasons such as the configuration of ratio values, the nature of your traffic, or the health and availability of your pool members.
The Ratio (member) method can be used to load balance most connection types. When you configure the Ratio (member) load balancing method you should assign a ratio weight to each pool member that is proportional to the capacity of the server.
The ratio method is appropriate to use if same pool members are more powerful than others. In this example, the ratio is set as 3:2:1:1.
As a result, BIG-IP sends three times as many requests to server 1 and twice as many requests to server 2 (as compared with servers 3 & 4)
If one server that was much faster than the others. After receiving the available load balancing methods to choose Ratio method. Knowing it would allow BIG-IP to letter utilize his more efficient server.
As request are processed, all available members are given one client request.
Then three or greater, and so on until the member with the highest ratio has been given the number of requests equally its ratio. Then the whole process starts over again.
Remember that both ratio and Round robin are static load balancing methods. This means that if a server with a higher ratio is available, it will still receive more requests then the other servers even if its performance is shown then the others.
If you want to consider server performance, you should use one of the dynamic load balancing methods.
Least Connections :-
The least connections load balancing method uses the current connection to decide where to send the next client request. Assuming the current connection counts are listed.
The next connection will go to server1. now server1 & 2 have equal counts so BIG-IP will round robin between them.
Assuming connections count stay as shown, now server 1,2 &3 all have equal counts so BIG-IP will round robin between all three.
Least connections is appropriate for many cases but may be most relevant when the client connection length varies significantly and round robin could result in uneven loads.
F5 Design Engineer
Thanks everyone for the reponses
I do understand how the ratio should function generally, but the key point I still didn't fully grasp is the context of a session in the Ratio(Session) option,
As far as I know, TCP connections don't hold any session information, every connection is separate, for example HTTP works on TCP, it's a stateless protocol, so the session for the client is stored in a cookie header that is presented by the server and saved on the client, this way we understand how the load-balancer will understand what a session means (the cookie value presented in the persistence table is what determines which TCP connections belongs to which client session).
But the question in the Ratio(session) option what counts as a session for multiple TCP connections, in the docs it's mentioned that Ration(session) requires L7 profile, but how would the F5 know how to differentiate which TCP connection belongs to which session. unless it's in a persistence table or additional properties in that L7 profile, I don't see another way to differentiate between sessions.
For the Least Sessions it's clear on the docs that it depends on persistence table, but for Ratio(session) this is not mentioned.
I hope I made my self clear.