multi location call center hardware specs

[cyrenity]

Hi all,

we are considering deploying vicidial for inbound only purposes on 3 different locations(300 seats total) with a central database server on following hardware:

Hardware: dell power edge r710 servers (Quad core intel xeon)
2 x media gateways (for pri to sip)
2 x sip proxies (call routing based on cli - caller geographic location)
3 x Asterisk servers (8G RAM)
2 x Web servers (8G RAM)
2 x Database servers (12G RAM)
2 x FTP servers (4G RAM)

we are considering deploying mysql-cluster on above two db servers with 2 cluster management consoles running on file server as they don't take much resources. all server will be hosted on our main data center and agents will login from different geographic locations (call centers), bandwidth is not an issue for us.

i am wondering if db hardware specs is sufficient to handle a huge call load(ALL on SIP) and 300 agents.

ps. all asterisk server are equipped with sangoma voice transcoding cards and plan is to use g729 for agents on all remote locations

Best Regards,
-m

[mflorell]

The DB servers should be Master/slave, not cluster, since MyISAM does not support cluster and you will have problems using another storage engine. Also, the DB should be at least a dual-quad-core machine.

I would also recommend at least one more Asterisk server if you plan on ever going over 1:1 line to agent ratio.

How many lines are you going to have going into this setup?

[cyrenity]

The DB servers should be Master/slave, not cluster, since MyISAM does not support cluster and you will have problems using another storage engine. Also, the DB should be at least a dual-quad-core machine.

I would also recommend at least one more Asterisk server if you plan on ever going over 1:1 line to agent ratio.

How many lines are you going to have going into this setup?

DB servers are all quad core (Xeon 3.0GHz) with 12G of ram and enough storage.

It's an inbound only campaign and we are going to terminate around 12 E1 (360 Lines). and based on our customer base we are expecting all 360 lines will be choked during working hours.

reason i am interested in mysql cluster because this way we can easily share db load(selects, inserts) between two mysqld nodes instead of putting all load on a single master server in master/slave mode.

also there will be almost zero down time if in case any db node goes down

[mflorell]

MySQL cluster will not work with ViciDial. You can use Master/slave with failover for redundancy, that does work as a solution.

You need Dual quad-core CPUs on your DB server, that means two not one CPU chips.

We have set up several system like this so I know what I am talking about.

[cyrenity]

I understand what you are talking about and i am sure i can't beat your experience, i am just curious about mysql cluster case studies on mysql website, mysql-cluster website primarily talks about telecom/voip and industries with large number of writes (100's to 1000's /per second).

i think migrating from MyISAM to ndb storage engine is not a big deal in favor of true redundancy and HA. master/slave replication setups fails to provide HA and Failover facilities unlike mysql cluster.

on the other hand mysql cluster scales very well and doesn't want you to commission a single high-end machine instead you can split resources across multiple servers and can keep scaling the cluster as database load increases.

Please let me know if i am going in the wrong direction

[mflorell]

If you would want to change to INNODB-style storage engines(which the cluster engine is based on) you would need to write a queueing engine to proxy all database queries through to ensure order integrity(which innoDB engines do not do and MyISAM does do). This is a major hurdle to the move and not one that anyone we have ever talked to wants to tackle.

The problem is that under load, innodb will just deadlock random queries and in essence tell the application to go away, and not queue the query like MyISAM does. So you would have to replicate what MyISAM does and hold the query and keep retrying it until the database allows the query to go through.

This is because unlike 99% of applications out there(including most VOIP/carrier applications), ViciDial is a real-time application and Innodb is not designed for this type of application. ViciDial needs the order that queries are sent to the database in to be preserved and executed in order which MyISAM is great for.

Also, Master/slave is capable of true redundancy. Using heartbeat software you can guarantee non-loss failover to the slave server and we have a couple of clients that have achieved this with their ViciDial cluster DB server.