A2Billing – MySQL Master / Slave and Asterisk load balancing – Part 2

In part 1 of this post we went through the configuration of MySQL replication plus configuring 3 A2Billing/Asterisk servers to use a common MySQL database.

Now for some simple load balancing.

Load balancing round robin DNS

If you are just making outbound calls then the simplest way to load balance is to use round robin DNS. Here you would create a DNS name for the A2Billing/Asterisk servers and assign multiple IP addresses to it. I would also suggest creating individual entries for the servers also.

So, for the example in part 1 of the guide, I might create

  • red1.sysadminman.net = 1.1.1.1
  • red2.sysadminman.net = 2.2.2.2
  • red3.sysadminman.net = 3.3.3.3
  • red.sysadminman.net = 1.1.1.1   2.2.2.2   3.3.3.3

By default (although I would test this is what your DNS provider does) when someone queries red.sysadminman.net they will get all three entries back, but with the primary address being rotated each time a query is made.

Using DNS in this was has some limitations that you should be aware of –

  • DNS changes can take a while to propagate. You should look at having a low TTL. This could be an issue should one of the servers fail.
  • If a server becomes unavailable the client may not automatically re-resolve the updated DNS entry

Manual load balancing

Using the DNS settings above it would be possible to point clients manually to either red1.sysadminman.net, red2.sysadminman.net or red3.sysadminman.net. You could then assign an equal number of clients to each server. This is probably more applicable if you are providing SIP trunks to customers, or you have geographically located servers.

Inbound calls might not work to registered SIP clients

One thing to be aware of is that if a SIP client registers to one of the Asterisk/A2Billing servers above then Inbound DDI calls, that were being sent to the registered phone, would only work if they were forwarded to the specific Asterisk/A2Billing server that the customers SIP client was registered with. If the call went from the DDI provider to wrong Asterisk server then the inbound call would fail (assuming the ultimate destination of the call was the registered IP device)

Better load balancing plus fixing inbound calls to registered SIP clients

If you need to have inbound calling working to SIP clients, or if you want better load balancing between the Asterisk servers, you will probably need to implement something like OpenSIPS. OpenSIPS can act as a central registration server, and also use the same A2Billing MySQL database to get a list a authorized SIP accounts. A2Billing would then use this to locate where the customers SIP handset was.

Another benefit of OpenSIPS is that you can very quickly remove one of the A2Billing/Asterisk servers from the cluster, allowing calls to be routed via the remaining servers.

Don’t forget if you are going to implement OpenSIPS then it makes configuration more complicated, plus you are introducing another single point of failure that you would need to provide some redundancy for.