SIP Load balancer on Cloud
Some thoughts about using Load Balancer when placing your SIP services on public cloud like AWS
Following up on the post about placing SIP services on public cloud like AWS, I am going to talk briefly about using load balancer. We will use OpenSIPS as an example again.
Advantages of using Load Balancer are quite obvious, but nevertheless, lets remember them:
- Balancing of the load - obviously. You do not need to worry that some of the services might be overloaded while others are idling
- Detecting failed gateway. It is common feature of most load balancers regardless of service type they balance (HTTP/HTTPS, other TCP, etc) to be able to constantly monitor their destination routes and proactively take them out or routing, put it back, and alert administrator
- Easier maintenance. Operators can do updates on their backend systems by taking nodes out of routing one by one (rolling update) without interrupting services for the users
- Security. Smaller attack surface - less machines exposed to the internet.
I cannot think about obvious disadvantages at the moment, except that of course any new new unit adds a bit more complexity in the system and requires some more knowledge and attendance.
For those interested in practical setup, here is a link to our documentation page which explains how to set up OpenSIPS as a Load Balancer with relevant routing script fragments explained.
OpenSIPS and similar Load balancer implementations make use of separate routing database. This allows to create a setup with one more significant feature - avoiding single point of failure. in such setup there are more than one loadbalancer instances (say, two) and each of them has a copy or routing database. both databases should be setup in a replication environment, however, with caution. Routing tables can be replicated, so that both balancers access same routing data, however, other tables, like dialog storage, can be kept separate for each balancer. This allows each one of the balancers fail, and the remaining one (ones) will have their copy of routing tables active at all times.
The only disadvantage of dual-load balancer setup is the management of hot swap. There are several ways how to solve this, but not all are ideal:
- DNS failover. It is reliable method, however very slow, since DNS propagation can take hours if not days;
- DNS Service records. Somehow difficult since not all devices support it;
- Solutions which create a virtual address shared between several hosts. Might not be possible to set up in all cases;
- Requiring clients to use two hosts at all times - most reliable method which usually fails only because users do not implement it.
To sum up, SIP load balancers are easy to set up, and provide a range of advantages for a SIP service of any size.
