Poor Mans HA

[bcmike]

HI,

I have a couple of Fusion PBX machines that were dev that became production (Yes I know bad mike, but that's how it went). When these boxes were set up they weren't set up with replication in mind but now that real users occupy them I want to be able to fail over to a different DC with the dual reg feature on the phones. To do this of course I need a replica in the remote DC. These machines are VM's so I just copied a snapshot to the remote DC. However I don't really feel comfortable enough with postgres replication to retrofit an existing install so I thought I'd just do it the poor mans way and dump the database, move the dump file to the remote location and restore it nightly. Not a true real time cluster but if the crap hits the fan day old CDRs and voicemail will be the least of my worries

Simple right? Except that the remote DC uses a different local subnet and everything lives behind NAT, so if I restore the SIP profiles to the remote site none of them will work.

So I'm thinking restore the database minus the v_sip_profile_settings table . Also after the restore I'm assuming I need to flush the cache and reload, can this be done from the command line via script?

Any suggestions or validation would be most appreciated.

 

[DigitalDaz]

I would seriously just change out the remote DC to one that doesn't have NAT

 

[Adrian Fretwell]

I agree with @DigitalDaz about the NAT in the DC. I always insist on a raw internet connection in the DC so I know nothing has been manipulated by their routers.

To go back to your question, I think I would just restore the backup and then run some SQL to alter the SIP profile settings. Here is an example script to change ext-sip-ip in the external profile:

#!/bin/sh

#settings
export PGPASSWORD="xxxxxxxxxxxxxxxxxxxxxxxx"
db_host=127.0.0.1
db_port=5432

#update external ext-sip-ip
psql --host=127.0.0.1 --username=fusionpbx -c "update v_sip_profile_settings as a \
         set sip_profile_setting_value = '185.xxx.xxx.42' from v_sip_profiles as b \
         where sip_profile_name = 'external' and a.sip_profile_uuid = b.sip_profile_uuid and sip_profile_setting_name = 'ext-sip-ip';"

After the restore you may need to run one of more of these commands:

fs_cli -x "fsctl reloadxml"
fs_cli -x "fsctl reloadacl"
fs_cli -x "reload mod_voicemail"
fs_cli -x "reload mod_conference"
fs_cli -x "reload mod_sofia"

You can just re-read a sofia profile which will not cause calls to drop
fs_cli -x "sofia profile internal rescan"
fs_cli -x "sofia profile external rescan"

 

[bcmike]

Thanks for the information!! That's what I need.

Regarding NAT, In a lot of respects I agree and I've traditionally given my machines a public Ip to cut out an extra single point of failure, however after years of fending off attacks I thought I'd try and get behind a firewall. The firewall is a pfsense CARP setup running on two pieces of pretty good hardware. I've got my NAT kinks worked out, but yes I do worry about things like the size of the states table as I scale. I'm starting to think a SIP proxy might be a better solution in this role but as with all things baby steps.

I'm wondering in a traditional replication setup across DC's at the very least the public Ip's must be different , how is this overcome? I must be missing something obvious.

FYI I'll also be sharing my Cisco SPA dual reg template mods in the Cisco section soon if anyone needs them.