FYI Is PIAF Good for Big Deployments?

[frederic]

> how large of an environment is everyone deploying PIAF in? we have around 300 phones I host VoIP for small business and one of my servers has about 425 endpoints. > In a multi box solution / hot standby, to switch from A to B can be almost transparent. Absolutely. My main-office PIAF install is redundant. PIAF A:

• eth0 192.168.1.10
• eth1 192.168.1.11

PIAF B: [*]eth0 192.168.1.10 [*]eth1 192.168.1.12 [/list] PIAF A is the primary PBX. All telephony devices connect to .10. PIAF B is the backup PBX. Eth0 from PIAF A and PIAF B are mechanically interlocked by a homemade, IP controlled relay that ensures only one of the two servers can be connected to the switch at a time. This insures only one of the server’s 192.168.1.10 address will be present on the network. The other “floats.” Also, the backup doesn't have the asterisk service (and related) running. The backup PBX checks the primary to see if it’s online. If it is, it rsyncs primary-->backup via the .11 and .12 addresses only, then repeats the check again and rsync all day long. If the primary is borked, the secondary will flip the homemade, IP controlled relay to itself, load asterisk (and related), and in effect become the primary. When the former primary is repaired and reloaded, it will find out that its eth0 is “floating” and it will choose to become the backup, not load asterisk (and related) and perform the above backup PBX processes. Most of the SIP devices we have are stupid enough to fall for this just fine, unless they were on a call at the time of the failover. In that case they usually have to be rebooted. The exception is our cobbled push-to-talk flushmounted speakerphone outside the front door which has to be rebooted with every failover. It's also a PITA to do because an IDIOT drywalled over the access panel in the inside. Why? Because he’s an IDIOT. Did I mention he’s an IDIOT? I haven't tested the failover process since we eliminated the OBI's this past weekend, using the built-in google voice/motif instead. I see no reason why that wouldn't failover just fine. We went the mechanical interlock route because we used to have the servers swap IP addresses but that didn't fail correctly 100% of the time and I need my phones to ring no matter what. I immensely dislike homemade crud in a production environment but it's worked so well I should probably stop calling it "crud." Also, never having asterisk running on the backup server ensures it doesn't try to connect sip trunks, google voice, and other things it might reach out to via the .11 or .12 IP addresses. Asterisk (and related) is set in chkconfig to be off, and started by our little pile of scripts if that server is the primary. All telephony connections to .10 is by sip or iax. POTs lines go though a pair of grandstream 8-channel ATA's, all lines are wired to both units, configured identically, one powered on and one powered off. If one goes bad, the power switches are reversed and that's taken care of. I could make another IP-controlled relay to switch mains instead of ethernet but as time goes on more and more POTs are going away as we convert to SIP trunks so I haven't bothered. Power is the usual - dual power supplies, connected to different UPS which are on different breakers/feeds, connected to a main panel and a big generator just in case.

 

[frederic]

Sorry for the formatting. That looks truly awful.

 

[Michelle Dupuis]

I have to chime in on the High Availability 'missing' from PIAF. If you have a look at http://www.voip-info.org/wiki/view/Asterisk+High+Availability+Solutions web site, you'll see a number of HA options ranging from free to paid.

It's worth noting that Schmooze's commercial HA module is based on DRBD a FREE linux package (yet you get to pay for it). What's more, DRBD means a shared disk between peers - so corruption on one peer immediately causes corruption on the other. Ok for a 'hobbyist' system but not mission critical systems.

Have a look at the page above and you will see that there are real HA solutions. Our firm is the producer of the HAAst high availability for Asterisk product, and we have deployed on large scale PIAF systems in mission critical environments.

 

[smarks]

As far as I know you need to have a common IP and have to basically have the 2 servers right next to each other when using DRDB. I don't think you can do it over a WAN between datacenters (for example) unless they are right next to each other (low latency) connected with Gb ethernet or fiber. Even then you still need a common IP so you at least need a VLAN.

As far as large deployments and PiAF vs Fpbx distro. There is almost no difference where it counts. They both use Asterisk and Asterisk is what does everything. All the other stuff is largely exactly the same as well. The differences are in configurations and little bits and pieces. That all adds up of course but if you know what you are doing and how it all works then it's all pretty much the same.

There are some annoying things with Fpbx distro like how they preload all the commercial modules. Also they have it setup in such a way that they are making a lot of assumptions how you should be using it. That is annoying for people like me who have a certain way we want to do things and don't want software trying to dictate any of that. Oh and their upgrade process is insane. You can't just go from Vx.1 to Vx.9. You have to incrementally upgrade to Vx.2 then to Vx.3 etc. It's insane. Easier to just do it manually on a vanilla install. yum update + amportal a ma upgradeall. Done.

Personally I install everything from scratch. To me it's all the same. Just Centos + Asterisk + fpbx. Doesn't matter what distro or vanilla from scratch. Even their schmooze OS or whatever they call it now is just CentOS.

Fpbx is just a config file generator. That is almost all it does. You can disable the web server and Asterisk will continue running happily along until you need to make additions/changes. MySQL will continue running and CDR reports will still be logging. At least it used to be that way. Haven't tried lately.

 

[dicko]

One very flexible but robust solution is a three node proxmox 4.0 cluster with the disks of the Asterii machines with write-back caching on a glusterfs based NDB , the advantages are that it's easy to deploy (just three times the recipe I've seen from Ward), a little rtfm to set up the cluster, glusterfs and its' replication ability, and the HA bit for the machines.

Build as many machines as you want , 10g of diskspace each should be good, the machines are cloneable and snapshot able, automatic backups on and off site, and perhaps the biggest saving is commercial licenses, like for example Digium's g729 they will stay with the running machine no matter what node it is hosted on, as most such things are keyed to the MAC address. So build any number of "templates" to suit, maybe a PIAF or two, a FBX or so, throw in a Kamailio or FreeSwitch, add a monitoring server, whatever.

The choice of three nodes will be apparent to whoever has suffered a "split-brain" DRBD or such , one node can be tiny (but 64bit) , just set it up for it's quorum vote for the ProxMox service. Glusterfs would be running as master/master and offers geo-replication for extra safety.

 

[dbdataplus]

I like this thread. I have seen the incredible UP sides and the incredible DOWN sides of "free software" and it makes me long for a world in-between. PIAF is, even with it's problems, pretty close to that world in-between. The problem I've found with "free software" is that without a clear cut commercial goal, the software development can get entangled with big egos between the developers and an idea of the "right" way to use the software that is truly at odds with what the user actually needs. Worse, the forums are often haunted by self-proclaimed "protectors" of the program ... who seem to see it as their job to attack people who have the temerity to suggest that the code may be flawed and things just degenerate from there. PIAF has been great. My limited attempt at dealing with Schmooze was not - for all the reasons covered.

My PIAF Mentor runs some very large installations as Hyper-V systems in some breathtakingly large commercial enterprises and I'd bet on PIAF before a half dozen commercial products from the big names. But that's key - if I were doing anything remotely approaching large scale I'd use Hyper-V rather than native.

 

[Michelle Dupuis]

As an Asterisk related software vendor I can tell you that PIAF is becoming popular in mid-size installations (and we've even seen a couple of large PIAF installations now too). I don't think the reason is functionality / capability, 'hobby' vs 'pro', free vs paid, etc; remember these are configuration generators and add-ons. The core is still Asterisk. I think it has to do with the people behind the products.

On of our customers moved all of their US distribution centers to PIAF (from a competing Asterisk distro) because they felt the incumbent vendor was misleading them about free vs commercial modules, add-on compatibility, need for certain licenses, etc. They lost all confidence in their old vendor and picked PIAF because of transparency and honesty. They had no problem with closed source or commercial products, but they also felt they were being manipulated into increasing product module fees and service fees (without reason / corresponding value).

We're happy to work with all vendors/distros/flavors of Asterisk; however we officially started supporting our High Availability software with PIAF this year based on customer demand. From what we've seen and heard PIAF is starting to stand out from the crowd!