vicidial.org

As mentioned in another thread someone asked me to set up a vicidial system for 200 seats or maybe 300 (in the case of 300 I would split into two systems - but first I plan with 200 seats). I never planed such a big system, maximum was 60 seats until now. The system will start with a big inbound campaign with 200 seats for 2-3 weeks. After that there will be inbound and outbound, ratio maximum 3 and recording 50% of the calls I think.
My plan:
2 webservers with SATA Raid 1, 1 Quad-Core CPU, 2 GB memory
4 or 5 Asterisk servers (40 or 50 seats per server), Sata harddisk, 2 GB memory
1 Mysql server, one 4-core CPU (maybe 6-core??), 4 GB memory (or 6 GB??), Raid 10 with 4 SAS drives
Storage for recordings is on a separate file-server.
Cause I read about bad Dell servers here and cause I have some HP servers in production without problems I would prefer HP servers.
So my questions: AMD or Intel for database server (the war begins - I like AMD but Intel seems to have more performance)? Does a six-core cpu speed mysql up compared to a 4-core cpu? I had a look to HP ProLiant DL160 G6: Xeon quad-core, 6 GB, P410 raid controller and 4x 144 GB SAS hard drives in raid-10.
The AMD or Intel question again for the two web-servers. I think quad-core is enough here. Are 2 GB memory enough? Cause every agent uses the same application I think there isn't much to keep in memory. Anyone tried XCache? I read it's a bit faster than eAccelerator (http://itst.net/wp-content/uploads/2006/10/PHP%20Bytecode%20Cacher%20Review.html)
At last the Asterisk-servers. I read about people with 70 or more agents on one server. Other people have a rule about maximum 25 agents on one server. I will set up a 512 MB memory-drive for the recordings so there shouldn't be a bottleneck. The question is: Can a dual-core cpu with 2 GB memory handle 40 agents and some recordings? Or do I need a quad-core with 4 GB memory for this? I saw Pentium 4 computers with 2 GB memory and 25 agents on it - web and database on a separate server.

I like Debian based systems. So database and webservers will get 64 bit Debian (any cons??). Asterisk will be 32 bit cause it doesn't benefit from 64 bit I think.

Network plan: Two gigabit core switches connected to each other. The second one is the backup switch. Servers are connected to both switches (2 nics in every server). Agent switches (fast ethernet) are connected to both core switches (one backup link - STP)

Would be fine to hear some opinions.


Regards,
Gunnar

You can easily handle 300 agents on a single system.

Get a better DB server, dual quad-core Intel CPUs with 16GB RAM should be enough.

We use only Intel CPUs

HP is much better than Dell

you should have at least 4GB RAM for each dialer server, and more if you will be doing 50 agents and full recording.

Thanks for your answer. I told my boss to order a "HP DL160 G6 2x X5550 12 GB" with 4 SAS drives for database server. You think this server can handle up to 300 agents? Would be great.
My opinion was to have two separate vicidial systems. So if one system fails the other system isn't affected. While having 300 agents on a single system with a single database server the single point of failure is the database (I think I don't have to tell you this . When it goes down 300 agents have to wait. How do you secure the database server in such big environments? Replication to a slave database server?

daily backup of the database and making sure it is repaired and optimized everytime?

I dont really have much issue on the database server as I only use 1 but when worst comes to worst I have a backup that I can revert too.

Or you can also use replication servers then just hot swap it. or just repair and optimize the database if it crashed

I would recommend going for at least 16GB of RAM, it's really not much more than 12GB.

As for redundancy, yes we have several clients that we set up master/slave MySQL repoication for. In the even of a master failure you can switch to the slave in a matter of minutes.

In our experience, a properly sized database server is very reliable, running for months at a time on the same mysql instance. It is usually not the single point of failure unless it is being abused or it is undersized.