Detailed Failover information

[NathanB]

Hi.

I was hoping to find some more detailed information or a guide on the Failover feature of the Vodia Hosted PBX. I have read the information from https://doc.vodia.com/docs/failover but it doesn't quite clear up everything for me

If nothing else exists the questions i have are:

(Currently running v66 of Vodia Hosted PBX on Debian 64bit)

1. At what point in setting up the second PBX do I enable Failover? Once Vodia is installed and the license key is entered do i then go to the failover config, or is there other "system level" config that also needs to be set first?

2. In the Failover config page (reg_failover.htm) -  does this need to be configured on both servers, or just the secondary?

3. Path to store the fail over information - Where does the command line option "--serverdir <dir>" come into effect, do I need to append this to "pbxctrl" when the service starts each time, or does it get called from a different executable and once it is set then that's it? Does this also only get set on the secondary server, or both? - I'm guessing this also means that a file share has to remain available externally to both PBX's?

4. "The license must list all IP addresses that will be used by the primary and the secondary server" - How do i set this? on the Vodia Portal I can change the IP address, but I want to add one. Can i do multiple values with a delimiter?

Thanks in advance,

Nathan

[Vodia PBX]

The secondary PBX is almost just a clone of the primary PBX, with two exceptions. There is a file pbxctrl-failover.xml which by default is in the working directory of the PBX, but which can be also in another directory. This directory can be set with the option --serverdir <dir>. The other exception is the startup file (in Linux /etc/init.d/pbx) which may include that --serverdir option. That file must not be replicated from the primary to the secondary server, either by making it an exception for the sync process or by putting it into the directory for the --serverdir. 

1. The easiest is to enable failover is to modify the /etc/init.d/pbx on the secondary server and set the --serverdir option. Then start the secondary and set the failover options. Then restart the secondary. Then it is a good time to start synchronizing the file system. Once you have a pbxctrl-failover.xml file you can as well just edit and copy it for another server the saves you the start and restart. 

2. Only on the secondary. You will not see the information on the primary.

3. Yes add it to the startup command on the secondary server and make sure that this is not being replicated.

4. Just set both IP addresses in the IP address field separated by a space character. 

[NathanB]

Hi, Thank you for the response.

A couple more questions..

1. You say above "making it an exception for the sync process" - How do I go about that? Is Vodia syncing the working directory between the two servers, or is this something we need to implement separately?

2. What about the scenario of failing back from the secondary to the primary server when the primary comes back on line - Does Vodia handle this automatically?

Thanks

 

 

 

[Vodia PBX]

1. Vodia does not take care about synchronizing the working directory. But that can be easily done with rsync or a cloud-based file system. The pbxctrl-failover.xml is the one file that makes the difference between primary and secondary. 

2. The automatic failover takes care about failing from primary to secondary. It I actually important that the primary does not automatically come up again and start messing with the file system, which would create a mess with the files. Going back to the primary is a manual process.

You have to keep in mind that the failover is for the case that the virtualization layer cannot handle failover within the data center. This is typically geographical failover when the whole datacenter goes offline, which should be a very rare event (hurricanes, power grid issues over a longer time and so on). The failover when the hardware goes down is much easier done with virtualization within the data center. Most data centers offer that service as part of their offering, practically invisible, even for what they call bare bone which is essentially dedicated virtualized resources.