Along with the kind assistance provided by some customers of [url=/support-and-professional-services]FreePBX Professional Support[/url] (in the form of time donated for a feature they needed for their business), the boys over at Schmoozecom (disclaimer: including yours truly) have once again surpassed all expectations. As of FreePBX 2.8, (currently in beta – more on that later) the Backup module includes built in support for High Availability clustering!
The following is an interview I had with Me (aka myself), elaborating on the new features:
[b]I: So, what is this new HA (High Availability) feature, and why are we so excited with it?[/b]
[b]Me:[/b] To ensure that their critical infrastructure maintains a high level of reliability, many business seek out HA solutions of one type of another. To that end, we have introduced an automated capability for a designated server (herein: backup server) to periodically backup a production server (herein: primary server) and to restore said backup on the backup server. This ensures that the backup server always has a fresh copy of the primary server’s settings, and is ready to take over should the primary server fail.
[b]I: Billions of bilious blistering barnacles – that’s not true HA! True HA means the backups in real time and instant hand off between the two servers?![/b]
[b]Me:[/b] Actually, according to ( wait for it – you’ll never guess!) Wikipedia, HA is [i]“is a system design … to ensures a certain degree of operational continuity…“.[/i] While there may be some benefit to having both the backups and hand-offs in real-time, such solutions can to be overly complex and way above the requirements of many organizations. Additionally, such solution tend to require a unique and complex setup with additional components not usually installed on FreePBX based distributions. Being OS agnostic, FreePBX is best not left to deal with the configuration and maintenance of such solutions. Instead, FreePBX takes a simplistic approach, removing much obscurity and confusion from the picture. Keep in mind, however, that FreePBX’s HA implementation can be used as part of a greater HA solution, perhaps including real-time fail-over support.
[b]I: So, how does FreePBX backup a server?[/b]
[b]Me:[/b] The backup server can perform backups at any requested interval – ranging from every minute (not recommended for most scenarios) to multiple times per hour/day/week/month, etc. It then restores the backup to itself, wiping away any previous configurations, and replacing them with the latest setting from the production server.
Optionally, the backup server can be configured NOT to restore the setting locally, and act as a storage area for backing up MANY primary servers. In this configuration, the backup server keeps copies of backups handy, ready to be restored locally in the event of a failure to any of the primary servers. Please note that in this scenario, the backup server will continue to function as a backup server, even in the capacity of a surrogate to the failed production server.
[b]I: How does production move to the backup server?[/b]
[b]Me:[/b] As mentioned previously, on its own – it doesn’t. The sysadmin is required to manually change the ip address of the server so that all peers can find it. This also allows the sysadmin more control of the switching over process, more notification to error’s and an incentive to ensure that the primary server doesn’t fail in the first place!
Additionally, there are services that can do the fail over automatically, but those are beyond the scope of this discussion. Apparently, these can be enabled in certain routers as well.
[b]I: Great! This is the perfect way to backup my CDR’s![/b]
[b]Me:[/b] Actually, if you require real-time backups of cdr’s, your probably better off with a master-slave setup for your database (for the cdrs that is).
[b]I: After a backup is restored, what happens to my trunks – will they automatically try to register to my provider and ‘steal’ the incoming calls from the primary server?[/b]
[b]Me:[/b] No. FreePBX requires that you click the orange bar at the top of the screen for any changed settings to go in to affect. This can be done manually or, if you’re using other elements as part of you HA solution, programmaticly by calling [code]/var/lib/asterisk/bin/module_admin reload[/code]. If you have traditional PSTN trunks (not VoIP), additional measures will have to be taken to connect those lines to your PBX and assure they are up and running.
[b]I: Bougainvillea! How do I backup the backup server?![/b]
[b]Me:[/b] Exposed now in the GUI are many different options that can be run after a backup is complete. For example, copy the backup to an ftp server, ssh the backup to another host, or even have it emailed to you.
[b]I: Doesn’t the ability to pull a backup off a primary server pose a security risk?[/b]
[b]Me:[/b] We have gone to great lengths to ensure that your phone system remains safe and secure throughout this process. The backups are all executed over ssh and encrypted with the public key.
[b]I: Public keys rock! (Uh, What are public keys?)[/b]
[b]Me:[/b] Public/private keys are a method to encrypt data sent over insecure connections – easily considered one of the securest method in the world. See here for more info.
[b]I: Right, I knew that! But just to make sure, can you ‘remind’ me how to set up ssh keys?[/b]
[b]Me:[/b] That’s probably something better left for the wiki/forums, but here is a very, very, very quick primer (designed for Cent OS systems, assuming asterisk is running as Linux user asterisk):
sudo -u asterisk ssh-keygen
Then copy the public key to the primary server:
[code]sudo -u asterisk ssh-copy-id -i /var/lib/asterisk/.ssh/id_rsa.pub root@
Your output should look something like this:
[root@localhost /]# sudo -u asterisk ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/var/lib/asterisk/.ssh/id_rsa):
Created directory ‘/var/lib/asterisk/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /var/lib/asterisk/.ssh/id_rsa.
Your public key has been saved in /var/lib/asterisk/.ssh/id_rsa.pub.
The key fingerprint is:
[root@localhost /]# sudo -u asterisk ssh-copy-id -i /var/lib/asterisk/.ssh/id_rsa.pub firstname.lastname@example.org
The authenticity of host ‘myserver.example.com (188.8.131.52)’ can’t be established.
RSA key fingerprint is 8e:ae:6a:49:bb:1b:1b:91:3f:02:4f:65:ab:e7:5e:6b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘myserver.example.com,184.108.40.206’ (RSA) to the list of known hosts.
Now try logging into the machine, with “ssh ‘email@example.com'”, and check in:
to make sure we haven’t added extra keys that you weren’t expecting.
[b]I: Duh! Now, what do I need to do in the backup module?[/b]
[b]Me:[/b] Under Remote Backup Options, put in the hostname or IP address of the primary server, the user name (probably root), and the private ssh key (if you followed the steps above, that should be: [code]/var/lib/asterisk/.ssh/id_rsa[/code]). To restore the backup immediately, check “Restore to this server”.
[b]I: Great, I’m all set. One last thing – why don’t I see these options in my backup module?[/b]
[b]Me:[/b] These options were included starting with FreePBX 2.8, currently in beta. Feel free to start beta testing 2.8! Have a look [url=/news/2010-05-24/freepbx-2-8-beta2]here[/url] for more info.
[b]I: Thank you so much for sharing your thoughts with me. Is there anything else you would like to add?[/b]
[b]Me:[/b] Yes. As of [url=/news/2010-05-09/preview-the-all-new-directory]last week[/url] there were some issues threatening the continuity of Custom Contexts as of FreePBX 2.8. Congratulation and a tip of the hat to all those that step up to [url=/bounties/custom-context]contribute and help resolve[/url] the issue!