Advice or Support needed to build 600 to 1000 seats

[naresh6119]

• 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

[williamconley]

Consultation Pricing I'd recommend at least a one hour consultation to get a list of concerns and options.

Hourly Support Or dive straight in (with at least one hour) to investigate your existing system and see what may be done to increase capacity.

[naresh6119]

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.

[williamconley]

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.

Vicidial servers generate thousands of transactions per second. Vicidial scripts deal with nanosecond timing to accomplish their tasks. Each independent server uses the database for all decisionmaking and coordination with other servers.

MySQL replication and clustering requires Time to transmit data between servers. Real time. Not nanoseconds, but seconds. Thus any failover would always create (at the very least) a hiccup in decisionmaking. Incorrect decisions can be quite disruptive: Multiple clients in one agent session, for instance, create a scenario where two clients are talking to one agent at the same time (and not coincidentally, those clients can hear each other). This is a tiny example of one of the thousands of decisions made every second by a Vicidial server while making those decisions based on response from the database server.

Not to say it would be impossible to create a true failover scenario, but the coding and testing time required will likely be $10k to $50k. Most call centers are not interested enough to pursue this to that level. It's customary presently to make the DB server as bulletproof as possible instead and create a script to switch to the secondary server when needed (which will incur a 5-10 minute downtime period).

We do have alternatives which allow for an unlimited seat system in production presently. But those are pre-release and not (yet) available outside our systems while we test them thoroughly. We hope for release next year.