Ideal DB Server setup

[bastece]

Hi all,

I am looking to install a v11 cluster to initially support ~150 agents, with the intention to increase it to 500+ all potentially dialing on predictive from the same campaign (hence the need of a single system).

My intention is to spec the DB servers the best way possible to support the 500+ agents, so as the system grows I don't have to be doing any migration or anything, just keep adding telephony and web servers.

This is what I was thinking on doing:
2 x 2.8GHz 8-Core 4309Y Xeon Silver
128gb of DDR4 RAM
2x 1TB NVME SSDs on a software raid
2x 480gb SATA SSDs on MegaRAID card (RAID1)
Use the SATA SSDs to install the OS and the NVME RAID to store the database.

The above would be x2, to host the reporting database.

My main questions are:

1.- Has anyone done this setup before? Any advise would be greatly appreciated.
2.- Has anyone gotten to the 600-700 agents mark doing predictive?
3.- Has anyone hit a point where a DB server like this starts being the bottleneck and creates the need to split the system into 2?
4.- Does anyone recommend using AMD CPUs? As they can be found with higher Core Count and Clock Speeds for less money.

P.S.: I have plenty of experience setting up clusters, I am just curious on what new hardware has done to VD's capacity.

[mflorell]

The number of concurrent logged-in agents is just one metric in sizing a system. What dial-ratio are you looking at for these agents? How many maximum SIP trunk lines? Will you be handling any inbound calls? Will you be recording all phone calls? Will you be using any of the API functions? etc...

Yes, we have set up very large clusters with up to 600 agents, but there are several rules you need to follow depending on the details of how you want to operate to get to high density on a single cluster.

[williamconley]

on a software raid

This makes me nervous.

My experience with software raid is that it slows things down and can't be ported to new hardware easily.

That being said: I've never tried software raid with a Server on NVMe

[carpenox]

I would definitely suggest breaking it down to 2 clusters, at that size, you will more than likely have bottleneck issues at the DB level

[bastece]

Thank you all for your responses.

Here are my assumptions:
- What we are predicting for this is potentially dialing in a 6:1, so I am assuming 3000-4000 concurrent calls on the outbound side.
- AMD detection on
- Recording on (potentially with a delayed start)
- Inbounds just callbacks (roughly 5% of the outbound traffic, I'd say)
- The only API usage will be to add leads to the system.

This might seem a little crazy, I am just trying to figure out what type of DB server you'd guys use to build the largest cluster you can possibly build.

[mflorell]

I would suggest using the fastest NVMe drives you can get, and use them for BOTH on separate sets of drives for the MySQL data directory and the OS/apps. We have seen issues on very large clusters with the OS/apps drives falling behind in certain circumstances.

[bastece]

Got you, that makes a lot of sense.

Should I still do software raid1 or 10 on both NVMes sets?
As far as the CPU, do you think that will suffice?

I really really appreciate your help, by the way.

[okli]

Take a look at Intel Optane P58xx series, they are simply the fastest NVMEs available with amazingly high IOps and DWPD compared to any other NVME. although Intel have abandoned Optane project, they are still available.
Put them in softraid1, used for database files only and have a couple of spares just in case. No need for raid10 for these.

As for CPU, I would go with Xeon Gold and more cores, like 2 x 16 or AMD with more cores again.

At dial level 6, AMD on and full recording, in my opinion you should either split this in 2 clusters, or seek Vicidial group to do the entire set up, tuning and support once in production.

Just imagine 600 agents sitting unproductive, while you are figuring out why the heck agents get kicked out randomly, or get several calls at once etc. hard amd lengthy to troubleshoot issues. Are you willing to take the risk?