Many times, during discussion about various OpenSIPS based solutions, I noticed that people make a confusion when comes to the meaning of “load balancing”. Whenever they talk about distributing SIP traffic between multiple destinations, the term of “load balancing” is abused in a very very generic way. Such a mis-usage of terms leads to mis-understandings when comes to describing (or drafting the requirements) of a SIP system.
In my opinion, the generic term should be “traffic distribution”, while “load balancing” is a sub-category, where the distribution is driven by some “load” factors.
Now, let’s take an exercise and see how many types/flavors of “traffic distribution”, depending on what actually controls the distribution logic. And from this perspective there are two main areas :
- load balancing, where the distribution is controlled by hard, strict numbers giving information on the load of the destination servers
- probabilistic distribution, where you do a kind of random dispatching of the call to the destination servers, without any idea of what is actually happening on those servers in terms of load.
Or shortly, distribution with or without real-time load information. What the load means, where it is calculated (on the balancer or on the destinations)….these are different topics 🙂 .
Load driven balancing
Or “load balancing” – this means the balancer has information about the actual load of each destination, so the balancer will pick the less loaded destination for sending new calls. This will guarantee a precise even balancing of the call among all destinations.
The load may have different meaning – can be the number of ongoing calls, can be the processing effort (in terms of resources) or any other kind of quantifiable data. Also, it is not important which party is computing the load information – the balancer, the destinations or a third party.
Now, let’s see what OpenSIPS has to offer in this area:
- Load Balancer module, call driven – here the load factor is the number of ongoing calls on each destination. The module computes this load by itself (based on the dialog module); of course, there is a limitation here, as the Load Balancer modules “sees”, when comes to load, only the calls it routes. Here is an tutorial on how to use this module for complex balancing scenarios.
- Load Balancer module, load driven – this is very similar to the above, except that the module get load information back from the destinations, so it can dynamically adjust its load limits based on the information received on the destination servers (like the server is getting also calls from other sources, or there are other applications consuming CPU/memory on the destination server). For more, see a previous post of how to FreeSWITCH driven balancing with OpenSIPS
- Dispatcher module – under certain configuration, the dispatcher module can be load driven; similar to the above, the module can receive realtime feedback on the load of the destination, so it can adjust its dispatching algorithms to achieve an call distribution as even as possible. This was covered in the second part of the post mentioned above
Probabilistic driven balancing
In this scenario the balancer has no information about the load of the destination, so the best it can do is to distribute the call using the random-based logic. Here, the balancer is not aware of how many distributed calls were actually established or how long they last.
Because of this zero-visibility over the load on the destinations, a probabilistic call distribution give no guarantee for its results – you may end up with a totally un-balanced system, with overloaded servers or idle servers.
So, what can OpenSIPS do in this area:
- Dispatcher module – natively, this module is design for probabilist/random call dispatching. It may use different algorithms for randomly picking up the destination, like by computing hashes over different parts of the messages. Better take a look in the module documentation for all the available algorithms. It worth mentioning that the module allow you to define weights for each destinations, to you can split the incoming traffic in an un-even way on purpose.
- Dynamic Routing module – this module is mainly intended for prefix-based matching and routing. Still the module operates with concepts like lists of gateways (or carriers) when comes to where to send the calls matching a certain prefix. How the traffic (matching a prefix) is distributed over that list of gateways ? Well, the modules allows you to do weights-based distribution over the list, so a probabilistic distribution. You just have to define weights for the gateway and to instruct the module to perform weight-based balancing – see the “W” flag for do_routing() function or the 0x1 flag in the carrier definition .
Hopefully this article will help you in the future to select the proper call distribution method – with or without load. While the load-based distribution is very accurate, it also consumes more resources on the balancer side. The probabilistic distribution is much simpler and faster, but there is no guarantee for a fair distribution.