vicidial.org

• Current Scenario
We are using Goautodial Cluster setup is 1x DB & Web Server and 2x Dialers.
Database Hardware - 16 core servers with 32G ram,
Telephony 16 core servers with 32G ram and
Web 8 core servers with 16G ram
• Server info
Goautodial 3.3
from Goautodial iso
Asterisk Version: 1.8.23.0
Version: 2.9rc1
DB Schema Version:1379
We install Goautodial on centos 5.9 64bits, we are using the same setup for 150~200 users, we observed the DB load gets increased and go beyond 200% once the user reach to near 200
• Requirement
We are looking support for VICIDIAL or Goautodial setup for 600~1000 users and need the following details.
• Number of hardwares and its specifications required for DB, WEB and Dialer
• Clustering of DB servers (Master/Slave or Active-Active)
• Need to know more on timelines and commercials
• Prefer timing - IST

Hello,
I suggest to use Vicibox instead GoAutoDial because it has the last version from ViciDial Group.
For support I recommend you the vicidial group, www.viciDial.com or our services ITContinental.com

Goautodial is Vicidial under the hood. Adding new servers is easier with Vicibox as it handles the interconnects automagically. Upgrading is also easier in a Vicibox installed system. However, upgrading is possible with Goautodial ... it just wipes out the customized goauto pages and leaves you with vanilla Vicidial (which is a good thing, IMHO). Mixing old Goauto and new Vicibox servers is not a problem.

If you intend to build a Single System with over 150 seat capacity, you likely should engage a consultant. Over 500? You're IQ is in question if you don't engage a consultant.

600 to 1000 seats, however, is a bit vague. I have systems with 600 seats on a single server. Because it's rare to have more than 20 agents actually logged in at the same time, much less actually dialing outbound.

So for capacity it's important to know the total MAXIMUM of simultaneous logged in agents, outbound autodialed calls, inbound calls in queue and anything else that would be using load "right now" (AMD? g729? Survey?)

If you want to do this without a consultant, your best bet is to always have at least one (possibly two) servers of each role (Dialer or Web) ready for expansion. One "powered up and ready" and one "still in the box". Do not combine roles on servers. One server is DB. One server is Reports (replicated DB), and several servers each for Web and Dialer. You can certainly install Web and Dialer on all servers, just don't use both on the same server except in unusual situations. One role per server gives you the best bang for your buck on each server.

DB server should be RAID10 with fast drives and a solid RAID card (The Vicidial Group strongly recommends LSI MegaRAID). This also applies to the replication server so it can keep up with the DB server. Plus lots of memory and cores as DB servers love those.

Be very sure the interconnects on the servers are gigabit switches and there's nothing complex in the local network routing (don't bounce through several switches/routers between the servers).

Have a Vicidial Professional familiar with your system so that when you exceed capacity they can tell you which barrier you have hit by looking at the system they already have access to (as opposed to beginning the search or allowing access while you are experiencing a "bad day", that's just poor planning).

Current architecture

We have WEB+DB+Telephony servers supported upto 200 users without any issue with Goautodial 3.3

New requirement

We would like to have Active-Active (Both DB servers will be in active mode so that one fails, there shouldn’t be any impact on production)

or Active-passive (if active failed, passive server should become active automatically) Data base architecture with Multiple WEB and Telephony servers to support upto 700 users

Need to know : Kindly let us know the good time (IST) to discuss our requirement in details with you.

naresh6119 wrote:We would like to have Active-Active (Both DB servers will be in active mode so that one fails, there shouldn’t be any impact on production)

Mysql clustering is a thing. Vicidial, however, is too fast to support it and as such has NO code to link to more than one node on a cluster. making the concept moot. Note that Vicidial mysql links depend on hi-res perl timing. MySQL deals in nanoseconds. MySQL replication and clustering deals in seconds for data transfer. Accessing a DB on more than one node fails miserably. This has been tested thoroughly.

naresh6119 wrote:or Active-passive (if active failed, passive server should become active automatically) Data base architecture with Multiple WEB and Telephony servers to support upto 700 users

Automation does not yet exist. Vicidial code does not allow for failover. Not that it couldn't be written, just that it has not yet been written.

At present the best practice consensus is for multiple power supplies on multiple UPSs with RAID10. Six or more HDs for the RAID10 is often useful. Basically, make the DB server bulletproof if possible.

Options:
* Scripting to "force failover" on all servers, reboot to cleanly start all process with new DB associated. Takes 5-10 minutes (depending mostly on the time of reboot)
* Same, except without the reboot. Force restart of all processes. More coding and testing time to identify and restart all processes. Would likely allow less than one minute switchover.
* Fully involved: Add code to all processes to allow failover without restart. Switchover at death of primary DB. Will need to discuss "switch back" after rebuilding/certifying primary server. NOTE: NO method will allow "hiccup free" transition, as there will always be at least a few pieces of data lost in the death. So some queries will fail, and that will result in poor decisions on the part of the requesting process OR any later processes which require the missing data.

This goes from a few (3-5?) hours to ... many, many hours. Without funding to check all the necessary links, I'd guess roughly 15 hours total.

Our website and contact information is in my signature.

Thanks william,
we will get back to with proper decision

Naresh we are based in india and running vicidial with 1500 seats on single cluster with HA (1+1, N+1 & N+N) Replication of DB, Storage Regular backup. There is no human intervention for any failure or backup.

We have created entire ecosystem automatically which will work based on alerts in case of failure. We can share our experience with you so that it can help full to you.

Kindly pm me for more details.