Expansion from test box to cluster

[leseul]

Hi All,

We've been trialing Vicidial for 3 Months now and are very happy with the results. We're now looking to expand from our single box 20 agent setup to a cluster replacing our current system and covering roughly 50 agents (with a view to expand again later on down the line).

Basically I want to check that I have the right idea/plan before going ahead (and of course get any tips fro the pro's)

I have 5 boxes => 1 Current Vici Setup, 2 from the outgoing system and 2 blanks

I'm going to move in 2 stages to ensure continuity in case of mistake from me or any unforseen failure.
Pre-cluster: Backup current Vici setup and Database to a NAS, check backup on blank box to ensure it's viable
Step 1: Using Vicibox ISO install asterisk on the two blank boxes to be used as diallers, re-provision existing polycom phones to point at thier assigned server and change usage of the current vicidial box to DB, Web, Storage.
I should then have a working system with the fastest box running the DB, Web and Storage with 2 smaller boxes handling the telephony. The old system is still available as backup in case of emergency.
Step 2: Install Vicibox onto two remaining boxes to be used as Web and Storage, leaving the fastest box as DB only, Point agent terminals at the new webserver.
This should leave me with a load balanced Vicidial setup that is expandable by adding extra asterisk boxes.

Have I missed anything obvious or am I going about it completely wrong?

Has anyone else expanded from a single to multi-server setup that can offer any advice, pitfalls to avoid or tips to help speed things up?

Can I apply the steps in williamconley's Cluster Manual to this or will there be additional steps required due to the fact it's expansion rather than a fresh install?

[williamconley]

1) Sounds like a valid plan.

2) If you use Vicibox 3+ you will not need to cluster if you answer the setup questions correctly (ie: Kumba's cluster install manual instead of the old poundteam manual cluster manual).

3) BUT you will need to time sync the servers (using ntp.conf to sync them, NOT issue a command at the command line to "set" them to the same time. Syncing and setting are completely different monkeys).

4) You may wish to consider running web/dialer on all the servers so you can determine the best load balance on your own (this can also allow for more redundancy, in case a server dies). In the end you could have 4 dialers, 4 web, and 1 archive that's inside one of the web/dialers. Then experiment with your load (move agents to different web servers and dialers and observe your load until you learn ... with a system this large, however, your load with 50 agents should be easily managed).

[leseul]

Thanks Will,

2) If you use Vicibox 3+ you will not need to cluster if you answer the setup questions correctly (ie: Kumba's cluster install manual instead of the old poundteam manual cluster manual).

Okay, so set up 5 fresh boxes from ISO as per Kumba's Cluster Manual, then apply the relevant parts of the earlier backup to the relevant server?

3) BUT you will need to time sync the servers (using ntp.conf to sync them, NOT issue a command at the command line to "set" them to the same time. Syncing and setting are completely different monkeys).

Should I have them all ntp to the DB box like the terminals, or 'daisy chain' db => dialler1 => dialler2 and so on, or all from pool?

4) You may wish to consider running web/dialer on all the servers so you can determine the best load balance on your own

Like this: Server 1 [DB] => Servers 2-4 [Web & Dial] => Server 5 [Web, Dial & Archive]?

I like that idea much better than my original plan after the "redundancy" magic word... It seems working in this industry has turned me into a true pessimist

[williamconley]

apply the relevant parts of the earlier backup to the relevant server?

Couldn't even begin to render an opinion on that until you clarify what is being restored ... but advice: get it working FIRST. validate your install and your cluster. Back up everything. then play with any "restore" ideas that pop into your brain.

The identity of the NTP server is not an issue except: it must ALWAYS be available to ALL servers. ESPECIALLY at boot (ie: if you are going to reboot the servers, be sure ntp is up again before rebooting the rest or reboot it last after you've rebooted the others).

Server 1 [DB & Web & Dial] => Servers 2-4 [Web & Dial] => Server 5 [Web, Dial & Archive]

but that's an option some don't agree with. until you are extremely familiar with your system and/or have lots of redundancy ... that has been known to be handy (even if for testing purpose, a place to see what happens if the database server is Local ... removing one fail point from a troubleshooting run). Remember that you do not have to USE web & dial on the DB server, but having it available can save your tush in a crunch. When you are pushing the limits of your DB server, turn off those functions (um ... and start looking for a beefier DB!)

[leseul]

Thanks for all your help so far, it would seem that you're something of a legend on these forums!

I'm limited by the hardware as we're using PRI with Sangoma A102's. Until I have enough cards to go round I'll have to leave the database on its own.

Also, What it the process for 'switching off' the dialler portion of the DB server? I can't seem to find this anywhere...

[williamconley]

? when you install, you answer "Y" or "N" and it will or won't activate the dialer portion (or whichever portion was being asked about) of the server being installed. But it isn't necessary to switch off anything. Just don't use those functions and they won't waste enough processor time to notice, really.

However, if you MUST play, LOL, you can modify the server under Admin->Servers to NOT be an active dialer, and then modify the OS to not run Asterisk (and not run Apache as well, but then you lose the ability to administer directly on the database server which can be handy for large list uploads and such).