New in clustering servers

[ichigo]

Hello

We have 10 units of
PowerEdge R220 rack server
Intel Xeon® processor E3-1200
4GB

and 10 unit of
PowerEdge R320 rack server
Intel® Xeon® processor E5-2400 (4 cores)
8GB

How will i cluster this in 200 seats and 40 seats

How many Dbase | Web | Asterisk?

[mflorell]

First, sell all of these Dell servers and buy SuperMicro servers

If that's not an option, then you will need to upgrade one of these Dell servers with an LSI Logic MegaRAID caching RAID Controller(PERC cards are NOT good enough!) and you will need to quadruple the RAM(or more). That server will then become your database server.

Then take two other servers and make them web servers.

Then ten of the other servers can become your dialers.

That will give you a good basic setup. If you record calls, you will want to get a high-capacity archive server as well.

There are many variables in a Vicidial setup, and since you haven't given us any details on what exactly you are planning to do with your Vicidial cluster, I can't really give you any more detailed advice.

[ichigo]

Thanks mflorell for your reply.

the 200 seats is inbound group and the 40 seats will be sales outbound group.

as of now upgrading the servers are not in the plan yet.

[williamconley]

The best method we've found is to install DB/Web/Dialer in your most powerful server (whatever that is). This is not related to hard drive space, but core count, CPU speed and Memory. Memory can be added later if you need it to pump up your system when you get time to do so.

Next up you'll need one or two Web servers (two is best for redundancy). These servers do not need to have any Vicidial processes/screens running on them. They are only for web. (We usually install everything and then just turn off the cron jobs ... so these servers can become dialers in a pinch!) Web servers can have tiny HDs. Seriously. We've got some with 20G.

Then you add all the rest of your servers as dialers. We also include web services in these servers to allow (once again) them to be used for web servers in a pinch and to allow access to recordings before they get pushed to the archive server. This way you can leave your recordings on the dialers longer if you choose to do so in addition to being able to use the dialers for web services if you need it. Dialers can have tiny HDs as well, but beware the recordings. If you put in 146G SAS or SSDs, then you can likely hold an entire day's worth of recordings if you want to ...

Any of the servers can be the Archive server if you add a huge HD. This server will be difficult to use for anything else unless you collect all your recordings onthe dialers during the day and push to the archive after shift. Most centers have a dedicated but 'underpowered' server for the archive server. It needs a big HD, but it does not need a lot of cores or fast cores or even a lot of memory.

Be careful with the archive server's HD. After recordings are pushed there, those are the only copies of the recordings. Having an external FTP service (off-site, another office for instance) to make a full copy of the archive server's HD is a great idea. You can use rsync or the "built in to Vicidial" ftp2 scripts for full automation.

You'll need to be very aware of your internal network and firewalls. Vicidial to carrier firewall especially. If your IT staff has experience with HIGH call volume networking it can still be a headache. But if they say that their "non-high-call-volume" experience will get them through, you should leave an extra week of "ramp up" time for the inevitable networking issues that Vicidial will throw at your systems. The Vicidial Group (and we at PoundTeam) are used to those perplexed phone calls where a call center reaches 150 agents and suddenly the "great planning" network falls apart. Avoid pfSense when using Vicidial (use it, but don't pass the Vicidial calls through it!). If possible, let the IPTables firewall already in Vicibox become a whitelist-based firewall and limit communications to the Carrier Only. Vicidial should share an internal IP/network with agents and the Cluster ... and each server should have its own public IP protected by the whitelist. Then you do not need a second firewall and there's one less link in the chain to fail. We published Dynamic Good Guys (Free on ViciWiki.com) a few years ago, which includes instructions for pure whitelist before installation. Continuing after the whitelist to install DGG is merely to give you a simple web-based interface to add whitelisted IPs and can also be used to allow the boss to hit the Real time screen from Starbucks (and external agents whose IPs change daily to get in without any fuss, while remaining secure!).

And don't let Matt get you down about Dell. We use nothing but Dell here, LOL. (We've only had three SuperMicro servers in 10 years ... all three have died and been scrapped!)

[ichigo]

Thanks Williamconley.

just upgrading the cores and memory will be fine?

William what if i will divide the 200 seats in 3 Dbase | 3 Web | 9 Dialers and 1 Archive Server while the cores and memory are not yet upgraded ?

[williamconley]

If you segregated the DB servers, you'd not be able to share data among the users on the other DBs. That would, however, offer better redundancy while completely failing at the concept of shared resources.

When you posted the server specs, you did so as if "Xeon" and a cpu model number has some meaning. Technically if I took the time to check the Ark, that could be true. But since you did not list the core count or CPU speed, I'm not really sure.

But what counts is the overall power of the server, from Front Side Bus to everything else. That being said, if you CAN get faster processors and more memory go right ahead. Just be careful that you don't pay more for CPUs than you would for all new servers (happens a lot). We've found that upgrading memory is often quite cost-effective, but upgrading CPUs is only effective if there's a Great Deal on the target CPUs that will increase speed by a good enough margin.

Also, if you have any dual cpu motherboards that presently have only one cpu in them, and you can double the core-count by buying a pair of CPUs, that's usually a good idea. As long as that pair of CPUs is fast enough to make a difference.

For the DB server, mostly. The dialers are really not cost-effective to upgrade after they're built (like I said, unless you get a really good deal on those upgrades ... which happens!).

Do you have enough bandwidth available for all this PBX traffic?

[mflorell]

A 200-seat Vicidial system cannot be run on a database server with only 8GB of RAM, it just won't run. 16GB would be a bare minimum, 32GB would be better, 64GB would be best.

The RAID card is very important for the database server in large vicidial clusters. Don't skimp on it. Get an LSI Logic MegaRAID caching RAID controller.

[williamconley]

A 200-seat Vicidial system cannot be run on a database server with only 8GB of RAM, it just won't run. 16GB would be a bare minimum, 32GB would be better, 64GB would be best.

The RAID card is very important for the database server in large vicidial clusters. Don't skimp on it. Get an LSI Logic MegaRAID caching RAID controller.

Concur. Luckily, memory is easy to add. But I don't think I've ever had a client with 200 agents who had less than 8G memory. But I've had some build from lower counts ... and started with 2G.

Although I have clients who "get away" with not using RAID at all until their first drive failure. 15k SAS drive with RAID 0 (ie No raid, single drive per array) have worked and continue to work for several clients. But they are regularly warned that RAID 10 will be in their future ... either WITH data and time lost or without, depending on whether they wait until the system crashes before they step up.

[ichigo]

thanks for the DGG.

William is it possible for now while i am waiting to upgrade the servers until maybe this march to divide the 200 in 3?

[williamconley]

absolutely. you'll get less capacity from each set, and you'll have issues with sharing the leads for outbound and the inbound calls of course. Assuming you have a method of spreading the agents/leads/calls among the clusters, you'll be ok.