Amazon EC2 to Host the Web/Database?

[bmorrison]

Assuming that I have bare metal running asterisk in some colocation someplace, would it be a bad idea to attempt to host vicidial's web and db on EC2?

If you've tried it, how did it work for you?

Thanks!

[williamconley]

vicidial does not work on virtual anything. often one can get a "demo" or "test" version running, but to date noone has managed to get a "production" box to work in a virtual environment with any load worthy of note.

vicidial uses hi-res timing and will misfire miserably with any load if that is not available.

vicidial's WEB requires vicidial scripts, which require hi-res timing.

[bmorrison]

Too bad. I thought I could get away with running mysql remotely.

Thanks for the reply!

[williamconley]

mysql in a sql cluster is viable. because the mysql merely requires extremely high availability. but mysql in a "cloud" may respond slowly. the mysql server in vicidial does not require vicidial scripts. just fast response time.

and "remotely" is another timing issue. there are hundreds of sql calls for every activity in vicidial. it has better odds of success than running the WEB in the cloud, but it needs to be a Powerful MySQL instance, not "slow" or "scaled down for sharing" in any way.

[roundqube]

I separated our my environment like this and it's functioning:

Host Machine running:
Asterisk
Vicidial agi-bin scripts for those pesky local agi scripts
VMWare Server 2.0.2

Guest Machine running:
Apache
Vicidial
MySQL

I edited the extensions.conf file on my host machine to send into different contexts based on which guest needed access to the dialer. And on host I have several /etc/astguiclient_xx-xx01.conf files where xx-xx01 is any call center I wanted to create (fl-pg01, fl-oi01 etc..). I have 3 guest VM's running vicidial on my host machine where all of them have apache/vicidial/mysql contained in the VM and all using Asterisk on the host machine since I have my USB voicetime device connected to the host.

Working very well for us with no timing issues. If anyone is interested in discussing what we've done in detail, feel free to contact me (naushad.kasu@gmail.com).

[williamconley]

um ... how many agents on each instance? (how many instances? ... for a total of ...?)

and how powerful is the host machine?

the reason i ask is that so far everyone who has done this has had "a couple" agents on two or three VM boxes perhaps totaling 7 or 8 agents on a server with 8 cores OR a single VM box with under 10 agents (one guy at 15) ... which means that a server that should be able to handle 50 agent is handling 10 or less. not entirely practical.

however, if you're working on it, that's one more shot at "getting there". the question is: how close to useful is your present setup? (ie: the questions above ... if you have 5 agents on each of 3 VM guests on a Core2Quad ... I AM impressed ... but do you? )

[roundqube]

How many agents on each instance?
Instance1: 8 , Instance2: 5, Insance3: 7. Instance1 is doing adaptive_avg while the others are doing 2:1 ratio. We had 2 more instances (fl-ej01 and fl-tc01) but they have stopped dialing because they just wanted to "test" out our platform.

The nice thing is that I wrote a perl script that copies my template VM and so if anyone wants to test our our vicidial platform, I have their call center up in about 8 minutes (all automated setup given some variables like call center code, number of phones, server IP etc..)

Machine Specs:
Dual Xeon 3.4 w/ 6G RAM -- each VM instance is only running MySQL, Web + Vicidial so we give each instance 256M of RAM.

[williamconley]

! oh! so you're using a "real" asterisk to run a single dialer with all the agents web on the virtual machines. silly question: what stops the agents/managers from dialing the wrong conference number? (ie: manager wants to listen to one of his agents but dials a conference number for another instance by accident ... or on purpose if they love playing, which they do)

I presume you have different conference numbers for each instance to avoid a conflict (two vici's trying to pull the same conference would be awkward).

you do seem to have the most useful sounding solution so far (even though you haven't hit 50% usage of the machine, it's intriguing )

[roundqube]

What my script does is keep a tally of who has what conferences assigned in /etc/asterisk/vConferences.conf file. For example, when my script runs the first time we tell it that the call center needs 10 agents.... so I overestimate by double and allocate 20 rooms. So...

Instance1: 20 agent capacity - vici conf rooms 8600051 - 8600070.
Instance2: 15 agent capacity - vici conf rooms 8600071 - 8600085.
etc..

So let's say Instance3 is being created and it needs 15 agents, then I append their call center to the next line in the script:
fl-xx01: 8600086 - 8600100

Next time my script runs, it checks the last used conference and keeps adding and dynamically creates those conference in the table for the call center I'm creating at the time.

[williamconley]

you'll need (for security reasons) to find a way to modify the conference context to stop managers / agents from listening in on rooms they do not own (for instance the room with 8600071 has a manager who "accidentally" dial 8600051 and listens to a conversation or two for a while). this has been a problem for multi-tenant installs for those who have tried them. not usually on day one with "newbies", but eventually in almost all cases.

i'll be interested to see if you find a resolution for that

then, of course, whether you can get your box OVER 25 agents (since an 8 core xeon should be able to handle 50 agents in a non virtual environment, that's only 50% capacity ...)

and even better would be the ability to cluster ... that would be a neat trick

[roundqube]

We do not use softphones, we use Polycom's just in our office. We tie these into Vicidial so all the agents can continue using the regular Polycoms we have all over the place.

In each of the sub-call center's dial plan, I have it set so when they dial 08600051 for example, this entry is only in the fl-xx01 call center dialplan and thus will get forwarded to their respective dialer. If a manager in fl-xx01 tries to dial say, 08600099 (not in their list of conferences), the dial will not get anywhere.

[williamconley]

Excellent. Sounds like you might have a decent solution for a "group server" for mini-offices ... if you can get at least 50% capacity out of the box (OR: if you can get it to use a NON-local Dialer, as in not the asterisk on the same VMWare server but on an external box ... either one of those would really make it a useful solution).

Have you exceeded 25 agents on the box yet? (at the same time, of course! and spread out between the different VM guests)

[roundqube]

We have it using a non-local Asterisk dialer as well. We have another server with just VMWare Server 2.0.2 on it running 2 more VM's and MySQL/Apache/Viciial contained in each one. They are using the original Asterisk dialer (on server 1) for its dialing.

I have been having issues getting Asterisk to work properly on the new server (server 2) so for now they are dialing through the original server 1.

So our setup is like:

Server1: Asterisk / Vicidial (no cron jobs) / VMWare Server 2.0.2 + 3 VM's of CentOS running Apache/MySQL/Vicidial (w/ cron jobs)

Server2: VMWare Server 2.0.2 on CentOS 5.5 64-bit w/ 2 VM's of CentOS running Apache/MySQL/Vicidial (w/ cron jobs). This server hosts the 2 VM's that currently dial through Server1 because as I mentioned earlier, I'm having issues with Asterisk on Server2.

[williamconley]

Cool: Now for the $10 question, though: How many agents and/or simultaneous calls have you "cruised" at for more than an hour MAX on that 8 processor (xeon) system?

[roundqube]

Cool: Now for the $10 question, though: How many agents and/or simultaneous calls have you "cruised" at for more than an hour MAX on that 8 processor (xeon) system?

It's not 8 process Xeon. It's dual processor dual core 3.4 (4 hyper threaded). Currently... w/ 15 agents online:

dlr*CLI> core show channels
.... <snip>
70 active channels
37 active calls

[williamconley]

Dual Xeon 3.4 w

My bad, i assumed dual was for two physical processors, most people build the "kick @ss" system on eight core total (two xeon with 4 each).

So you have 15 agents on a Two processor 3.4Ghz system ... split between how many VMs?

If that's ONE VM with 15 agents ... it's in the area of the 50% utilization mark of the overall system if all services are actually ON this box

but if that system has three VMware instances with three clients and each has 5 agents running ... that's actually worthy of note

[roundqube]

8 agents on one VM and 7 on the other. During noon time when the 3rd call center is calling (they stop at 5pm EST), then we have about 20 agents total. 8 on instance1, 7 on instance2 and roughly 5 on instance3.

[williamconley]

Excellent. 8+7+5 = 20 AGENTS

Now ... how many calls total? (cuz if they're all inbound this doesn't count )

[roundqube]

Right now the server is hitting about 40 calls, we have answering machine detection on as well.

We are only doing outbound programs at the moment with vicidial. Our inbound is running off proprietary platform designed by us (still using Asterisk as backend).

[williamconley]

ok: 20 agents, 40 calls, outbound only, split between 3 VM boxes with vici/apache/mysql and using a NONVM asterisk vici/dialer on the same hardware?

that's very close to being useful. seriously. Can you see where the "top end" is?

[cristian]

The network latency is far too high over the internets. This is a killer as vici uses mysql to control its processes.