500 seats Inbound-50 seats OB

General and Support topics relating to ViciDialNow and GoAutoDial ISO installers

Moderators: enjay, williamconley, Op3r, Staydog, gardo, mflorell, MJCoate, mcargile, Kumba, s0lid

500 seats Inbound-50 seats OB

Postby wonderwall » Sat Aug 15, 2015 3:06 pm

Dear All,

we are planning to purchase a server which can server upto 500 IB and 50 OB simultaneously. following are the configuration which we are thinking. let me know if you think that this hardware will be enough.
PowerEdge R730xd

2xIntel® Xeon® E5-2698 v3 2.3GHz,40M Cache,9.60GT/s QPI,Turbo,HT,16C/32T (135W) Max Mem 2133MHz
12x32GB RDIMM, 2133MT/s, Dual Rank, x4 Data Width
RAID 10
PERC H730P RAID Controller, 2GB NV Cache
600GB 15K RPM SAS 6Gbps 2.5in Hot-plug Hard Drive
Intel Ethernet X540 DP 10GBASE-T Server Adapter

thanks in advance.
installation of Goautodial 3.0 from Yum on CentOS release 5.10.1 (Final)
Installation method.
go autodial wiki 64 bit

Quad Processor 10 Core Westmere EX 4850 - 2.00GHz - 4 x 24MB cache
512 GB DDR3 Registered 1066
4TB x3 SATA III in RAID 5
wonderwall
 
Posts: 27
Joined: Sun Feb 09, 2014 2:54 pm

Re: 500 seats Inbound-50 seats OB

Postby williamconley » Sat Aug 15, 2015 3:41 pm

IMHO: You're trying to use Microsoft values in the Linux world.

Vicidial runs very well in a distributed environment. If you spend $10k on a single-server solution you'll get about half the capacity of spending that same amount on a multi-server solution. And you won't have redundancy (except in the power supply on that single server).

Also: Vicidial is published by The Vicidial Group. They approve Vicibox.com's installation .iso, not the GoAutoDial installation .iso. If you ever have an Enterprise Problem (likely with 550 agents), you'll be presented with a challenge at getting a wide array of support specialists ... and you may not get any help at all from The Vicidial Group if they perceive the problem to be related to GoAutoDial (which they expressly do not support).

Of course *we* support any version of any open source software. But that doesn't give you "lots of options" (Don't get me wrong: I like it when *we* are one of the limited available options for someone with a serious problem that must be solved Right Freakin' Now, but I digress ...).

On the other hand: Were you to invest in a heavy-duty DB server (8-24 cores) and two generic web servers (4 cores generally does it) for redundancy, and as many Dialers (4-8 cores, as your price-breaks seem best to you) as necessary to "hold the load" as you build ...

You'll end up with redundancy in Dialers, redundancy in web servers, and (if done properly) a near-bullet-proof DB server. You can also go so far as to replicate the DB server onto an Archive server that can double as an emergency-backup DB server, if you feel the need. And the assignment of roles will be managed by the installation CD! :)

The DB server does not need lots of HD space. It only has the DB on it. It needs fast, reliable (preferably RAID10!!) HDs. SAS 15k or SSD whenever possible. SATA is fine for medium-level services. It should also be configured for Vicidial heavy-use in the my.cnf file (there are threads about this).

The Web servers need very little HD space. They can survive nicely with a simple mirror. And they'll need apache configured for "lots of processes" (check the threads for heavily-used web servers!).

The Dialers are essentially disposable. They hammer HDs (and those will die, just be ready for it). You can Mirror them or RAID5 them or better yet RAID10 them, but be carefull not to blow a bunch of money on each one, just have lots of them. If one dies, spin up a new one and rebuild the dead one at your leisure.

The Archive server is where all the data will be stored. Multiple Terabyte HDs, in a mirror or better to avoid having to rebuild it if you like. Or just rsync copy it (or both, for ultimate security). If the Archive server will also be the slave DB for running reports that would save some cash. But try to avoid putting the Archive/Emergency server's OS on the same drive as the Archived Data. This way a failure will be segregated between the DB and Audio/Report data sets.

All that being said: It is entirely possible that your above specs will work for what you want. But if it does not, you'll need to "Cluster" in more servers at some point. Goautodial does not support clustering, so you'll need to cluster manually. There is a free manual published by ... PoundTeam ... available for multi-server Vicidial, but I much prefer the Vicibox installation method. And if you take into consideration that *I* wrote that manual, you'll get my meaning. :) Seriously, Vicibox. 8-)
Vicidial Installation and Repair, plus Hosting and Colocation
Newest Product: Vicidial Agent Only Beep - Beta
http://www.PoundTeam.com # 352-269-0000 # +44(203) 769-2294
williamconley
 
Posts: 20258
Joined: Wed Oct 31, 2007 4:17 pm
Location: Davenport, FL (By Disney!)

Re: 500 seats Inbound-50 seats OB

Postby wonderwall » Sat Aug 29, 2015 4:44 am

thanks willaim, After your reply we have hold that thought of using a giant server.
installation of Goautodial 3.0 from Yum on CentOS release 5.10.1 (Final)
Installation method.
go autodial wiki 64 bit

Quad Processor 10 Core Westmere EX 4850 - 2.00GHz - 4 x 24MB cache
512 GB DDR3 Registered 1066
4TB x3 SATA III in RAID 5
wonderwall
 
Posts: 27
Joined: Sun Feb 09, 2014 2:54 pm


Return to ViciDialNow - GoAutoDial

Who is online

Users browsing this forum: No registered users and 44 guests