Tech

Multiple Instances on a Single Server

Published on:

October 12, 2018

The method detailed in the post explains how to efficiently run multiple PBX instances on a single server with multiple CPU cores. By following the steps described, businesses can significantly reduce hosting costs while maintaining excellent server performance. The approach involves installing the first PBX instance, copying necessary files for additional instances, assigning separate IP addresses, and setting up startup scripts for each instance's control. The post also discusses fine-tuning for optimal performance and mentions alternative approaches such as containerization and virtualization in similar setups.

Most servers today have multiple CPU cores. In many cases, it makes sense to run multiple instances on that server to reduce costs; it also makes sense to run multiple instances if the customization requires separate instances must be run. This way you can have several hundred, maybe even a thousand domains on a single server, with excellent server performance, all at typical hosting costs (down to less than a dollar per domain and month). This blog entry explains how to do this on a CentOS installation.

1. Installing the First Instance

Installing the first instance is just like installing any other PBX instance. In anticipation of the other instances, you might want to use the working directory /usr/local/pbx-1, so the other instances have similar path names, or include the IP address you will use later on in the path name, making it easier to discern which one is which. It is also okay to name the first directory /usr/local/pbx if you have already done so. 

2. Adding Directories

Once the first PBX is installed, it’s easiest to copy just the PBX executable and the .dat file into the directory of the other instances; this means those those instances will start off with whatever software version you are running. Later, if you decide to perform a software upgrade, you can upgrade each instance independently. If you are using a backup cloud service, you might also want to add those directories for backup, so you still have the data in the case of a fatal crash.

3. Separate IP addresses

On the operating system level you should have one public IPv4 address, whatever it is, per PBX instance on your server; unfortunately IPv6 has not made it into the mainstream yet, which would make this a lot easier. 

It is possible to have multiple PBXs running on the same IP address and just run the different instances on different, non-standard ports; this will have several drawbacks, however: First of all, telling your users they have to log in on a non-standard port is somewhat unusual; second, using a standard port makes it easy to obtain SSL certificates through challenges on port 80. The biggest problem will be to get those IP addresses assigned from your hosting company. This is something you need to figure out yourself - it’s different from installation to installation.

Once the PBX is running, you need to bind all ports to the assigned IP address. The easiest way to do this is to set up the first PBX instance with the right IP address bindings: you will need to do this for the HTTP, HTTPS, SIP, SIPS, and TFTP ports. For example, if your server has the address 1.2.3.4, you would use 1.2.3.4:80 for the HTTP port (IMHO there is no need to have the TFTP port open if you're running this as a hosted PBX service). You also need to set the address for the "Bind to specific IP address (IPv4)" setting in the RTP settings (reg_rtpsettings.htm). Having an overlapping port range isn’t a problem, as the PBX will automatically pick a random port anyway. If you want to be super-sure, however, that this isn’t a problem, you can assign separate RTP port ranges for each instance.

Copy the pbx.xml file to the other directories and edit it with a standard text editor and replace the IP addresses of the first instance with the IP address for the other instances. When you start those instances up they will bind to the right address right away. 

4. Separate startup scripts

Having separate startup scripts gives you the advantage of easily controlling each of the instances. You can use the following script for each instance, just edit the INSTANCE variable in the script:

#!/bin/bash
#
# pbx      This takes care of starting and stopping the Vodia PBX.
#
# chkconfig: - 20 80|
# description: Vodia PBX PBX \
# Vodia PBX is a software-based private branch exchange (PBX) for \
# devices that support the SIP protocol. It provides telephony \
# services as well as associated services like provisioning devices \
# for telephony.
### BEGIN INIT INFO
# Provides: pbx
# Required-Start: $network $local_fs $remote_fs
# Required-Stop: $network $local_fs $remote_fs
# Should-Start: $syslog $named ntpdate
# Should-Stop: $syslog $named
# Short-Description: start and stop the Vodia PBX
# Description: Vodia PBX is a software-based private branch exchange
#              (PBX) for devices that support the SIP protocol. It
#              provides telephony services as well as associated
#              services like provisioning devices for telephony.
### END INIT INFO
# Source function library.
. /etc/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
INSTANCE=1
PBX_DIR=/usr/local/pbx-$INSTANCE
PROG=$PBX_DIR/pbxctrl
PIDFILE=/var/run/pbx-$INSTANCE
LOCKFILE=/var/lock/subsys/pbxctrl-$INSTANCE
OPTIONS="--respawn --dir $PBX_DIR --pidfile $PIDFILE"
start() {
       [ "$EUID" != "0" ] && exit 4
       [ "$NETWORKING" = "no" ] && exit 1
       [ -x $PROG ] || exit 5
}
stop() {
       [ "$EUID" != "0" ] && exit 4
       PID=$(cat $PIDFILE)
       echo -n $"Shutting down $PROG: "
       /bin/kill -- -$(ps -o pgid= $PID | grep -o [0-9]*)
       RETVAL=$?
       echo
       [ $RETVAL -eq 0 ] && rm -f $LOCKFILE
       return $RETVAL
}

# See how we were called.
case "$1" in
 start)
       start
       ;;
 stop)
       stop
       ;;
 status)
       status $PROG
       ;;
 restart|force-reload)
       stop
       start
       ;;
 try-restart|condrestart)
       if status $PROG > /dev/null; then
           stop
           start
       fi
       ;;
 reload)
       exit 3
       ;;
 *)
       echo $"Usage: $0 {start|stop|status|restart|try-restart|force-reload}
       exit 2
esac

4. Failover

Failover works exactly like a single instance failover: because some files are stored outside of the directory (to differentiate between the primary and secondary), you need to make sure those files are also named after the instance name. 

5. Fine-tuning

Once the PBXs are running, it makes sense to set the processor affinity so the operating system doesn’t start shuffling processes around once you get load on the system.

Outgoing TCP connection, from the HTTP client or when sending emails, will still be done from the standard IP address of the system. This usually isn’t a problem, except when customers get confused when they receive traffic from a different IP address than they expected. If this is a problem, it might be necessary to reserve the standard IP address for this purpose and to refrain from running a PBX instance on it.

6. Further Thinking

For other operating systems, this will be similar. We have seen multiple instances working also in Windows, though the setup there requires a proper setup with the service manager.

There are alternatives to this. The first is to leverage the container service (Docker) to let it handle the instances; this further increases the separation of the systems. When using Docker, you need to pay attention to the performance of the networking subsystem, as Docker mostly addresses systems with only a few ports requiring exposure in the container; if you expose thousands of RTP ports, this will be a different setup, and it might make sense to expose the full port range of a system IP. This will be similar to the setup with different directories.

The other alternative is of course the virtualization of the server. This is mainstream in the hosting industry, but it is important to pay attention to the CPU resource allocation so the PBX gets the CPU when there is work to do, especially on the RTP side. Sharing the RAM can also have a negative effect on performance, which must be kept in mind. 

As always, at Vodia we are happy to help you with your installation and make sure your operations are smooth. Questions, reach out to us, sales@vodia.com

Latest Articles

View All

Webinar | Real-Time Media Streaming in Vodia PBX: AI, Call Transcription, and Security in V69.5.6

Join Vodia Networks on April 8 for a live, in-depth webinar on how real-time media streaming is powering the future of voice communication. Discover how Vodia PBX version 69.5.6 enables seamless AI integration, live call transcription using the Whisper API, and secure voice data handling. Hosted by Sales Engineer Eric Altman and VoIP Engineer Hamlet Collado, this session will walk you through real-world use cases, including OpenAI and Google Speech-to-Text integrations, MS Teams support, and new security features. You’ll also get a first look at Vodia’s AI roadmap and have the opportunity to ask your questions during a live Q&A.

March 28, 2025

The Vodia PBX On-Premise Whisper AI Deployment​

Whisper, OpenAI’s Automatic Speech Recognition system, delivers multilingual, noise-tolerant, and technical-language-ready transcription through a streamlined encoder-decoder architecture. With Vodia PBX’s integration, organizations can choose between using OpenAI’s service or hosting Whisper AI locally for complete data sovereignty and control. This on-premise option ensures that sensitive call data stays within your infrastructure while still benefiting from powerful transcription capabilities. To explore deployment options, see our Whisper AI on-premise setup documentation, review a self-hosted integration example, or follow our cloud-based call transcription guide.

March 27, 2025

Vodia at Enterprise Connect 2025: Embracing AI and Advancing Communications

Vodia Sales Engineer Eric Altman attended Enterprise Connect 2025 on March 18 and 19, where he connected with partners and gained insight into the future of enterprise communications. AI was the clear focus of the event, with discussions centered on agentic systems, chatbots, and generative technologies. “It was certainly the main element in the atmosphere,” Eric noted. He also shared his excitement about Vodia PBX version 69.5.6, which includes real-time AI integration with OpenAI and call transcription using the Whisper API. The event confirmed that AI is rapidly becoming a core component of modern communication platforms—and Vodia is well-positioned to lead the way.

March 26, 2025