Tips for large deployment

[alphard]

Hi, I'm looking to deploy FusionPBX in a large organization and would like some tips to get good stability with it. Here's some info I'm looking for:

- When should I expect thing to break during an update?
- What's everyone way of backing/restoring things up? (filesystem snapshots? vm snapshots? some other way?)
- Any outstanding settings etc I need to do for performance?
- When are FBX version considered EOL and should be upgraded?

Thanks

 

[ad5ou]

Some tips depend on your definition of “large deployment”

You should expect things to break (or change behavior) with any update.
A test system comes in handy to check for any gotchas before deploying to production.

Everyone has their own methods for backups. Usually a combination of backup scripts and snapshots. I have multiple servers in a cluster for redundancy, run a nightly backup of Fusionpbx database and files, copy backups to other site, take full snapshots at least monthly but usually weekly, and finally restore nightly backups to a ‘server of last resort’ in case everything else breaks.

The default setup is tuned to work fairly well. THe list of possible performance tweaks are long and many are dependent on the size of system to determine if it is worth doing.

The PBX version is in a strange state. The last “stable release” is already considered EOL The developers recommend using the Master branch at this time. A new stable release is on the horizon but no schedule has been announced. Many of us update after the monthly “continuing education”

if your deployment is large enough to justify the minimum $1200 commitment (1 year at $100/month) you and your users will be best served by signing up for the Green level Fusionpbx.com membership to gain access to recorded training videos, additional documentation, and monthly update videos to understand changes in code etc.

 

[John]

Some tips depend on your definition of “large deployment”

You should expect things to break (or change behavior) with any update.
A test system comes in handy to check for any gotchas before deploying to production.

Everyone has their own methods for backups. Usually a combination of backup scripts and snapshots. I have multiple servers in a cluster for redundancy, run a nightly backup of Fusionpbx database and files, copy backups to other site, take full snapshots at least monthly but usually weekly, and finally restore nightly backups to a ‘server of last resort’ in case everything else breaks.

The default setup is tuned to work fairly well. THe list of possible performance tweaks are long and many are dependent on the size of system to determine if it is worth doing.

The PBX version is in a strange state. The last “stable release” is already considered EOL The developers recommend using the Master branch at this time. A new stable release is on the horizon but no schedule has been announced. Many of us update after the monthly “continuing education”

if your deployment is large enough to justify the minimum $1200 commitment (1 year at $100/month) you and your users will be best served by signing up for the Green level Fusionpbx.com membership to gain access to recorded training videos, additional documentation, and monthly update videos to understand changes in code etc.

As a member, I cannot also justify $1,200/year, but since he is not sharing any information about the updates publicly and there is not a human readable changelog for none members, not paying that $1,200/year means that next time you update your Fusion you can end up with a non-working system. So we have to endure this until there is a better alternative. Funny thing is, you normally pay for support in open source projects. We are paying for change-log, and we are paying to report bugs and see the bugs. Continuing Education is just a fancy name for changelog.

From another perspective, this is an open source project, and we can fork it. However, so far there has not been a powerful community wanting to do that reliably, and the contributors are few. Everything is on one guy's shoulder. Even a powerful community could help him eliminate development cost. Why should he spend his family's time, endanger his health (which he did) and his family money for others' benefit?

In contrast, I wonder if he really wants a powerful community? A project that does not have a public bug list, no public bug reporting, and does not have a public changelog, cannot complain about a weak community. It seems this is what he hopes for.

It is really a dilemma and does not have a definite answer.