How to Scale Asterisk Over Multiple Servers

Scaling your Asterisk PBX can be complicated. It’s hard to get more than one Asterisk server acting as a single PBX. A call comes in, and you want it to go where it’s supposed to go. But it takes a ridiculous amount of effort to get your installation to do what you want.

Take a look at the typical setup, where you have two Asterisk servers, with a trunk between them:

  • Getting your Call Detail Records (CDRs) requires that you aggregate records across each server, and is only going to work nicely if the servers are time synchronized.
  • Directing calls from one box to the other requires meticulously-managed dialplan configuration, or the call won’t reach the other side.
  • Coordinating configuration changes has to happen every time a change is made. If you add an extension on one server, that change has to be updated on the other server as well, or calls to your extension from the outside world will fail. Did you add a queue? Is there a way to get there from here?
  • Resources belong to one server or another. When you have a conference, it will have to reside on one server or the other. Maybe you can create it on both and bridge the two, but then how do you coordinate administrator tasks?

As an example of the resource problem, Agent queues don’t scale. How do you scale your agent queue beyond the capacity of a single Asterisk server? If you try to get everybody into the same queue, you introduce performance down. If you split the queue and have separate queues on each server, you now have a sequence issue. Here’s an example:

  • Agent 1 is on Asterisk server A
  • Agent 2 is on Asterisk server B
  • Agent 1 has been waiting longer than Agent 2
  • A call comes in to the customer service queue, which both agents are logged in to.
  • If the call comes in on Asterisk server B, Agent 2 will get the call even though Agent 1 has been waiting longer.

What’s worse, what happens if too many calls come in on one box or the other? Some callers get good quality calls, others don’t?

Indosoft Q-Suite has been managing multiple Asterisk servers for years. Multiple telephony servers were introduced with Q-Suite version 3.7. In the years since, integration has only gotten better.

Using the Q-Suite to coordinate multiple Asterisk servers, you in fact are able to treat your entire collection of Asterisk servers as a single PBX. It doesn’t matter where your agents, your trunks, your queues, dial plans or IVR’s are located. As long as it’s on a server managed by the same Q-Suite installation, it’ll be available.

Whether you’re doing outbound predictive dialling, inbound skills based routing, or building an IVR using the associated HAASIPP application, you can have a single trunk that’s distributes calls to one or more of your Asterisk servers. Or you could have a trunk per server. Or any combination in between. This allows you to do load-balancing on the basis of incoming calls, or if your trunks have capacity, then you can do load-balancing on a trunk basis.

Several schemes to manage agents and users on multiple Asterisk servers involve grouping agents together or extensions together in a way that’s simple to code into the dial plan. Without Q-Suite, for instance, you might put extensions 400 to 499 on one server, and 500 to 599 on a different server. You then hardcode that logic on all the boxes. That does make moving individual agents or extensions around a problem. The Q-Suite, using the administrator screens, makes it easy. Just make your changes, click “Go Live”, and make any changes needed to the phone configuration. Using phone provisioning, it may not even be necessary to change the configuration manually on the device at all

The advantage of the Indosoft method is that adding a server or removing a server is quick and easy.  Moving a server, we just need to make sure that any extensions that belong to that server are moved to a new server in the interface if you want to keep using them. Adding a server, you just make a couple of changes to the screen, then reassign any extensions that you want to move. And thanks to load-balancing etc., it’s possible for this new box be doing useful work without assigning any agents to all.