vicidial.org

Posted: **Tue May 01, 2018 4:40 pm**

would this suffice for a vicibox8 DB for 150 agents ? inbound & outbound dialing 80 agents @ 4:1 ratio, inbound only for 70 of the agents, recording all calls, AC-CID both campaigns, roughly 10 IVRS, DNC list of roughly 700000 numbers, and a separate FTP box for recordings.

any input or criticism is greatly appreciated!

Product model: R410
Processors: ( + 2 ) Intel Xeon E5506 Quad Core 2.13GHz
Memory: (+ 8 ) 4GB DDR3 10600R Total-32GB
Hard Drives: ( + 4 ) Samsung 860 EVO 250GB 2.5 Inch SATA III Internal SSD
Hard Drive Trays: ( + 4 ) 3.5" R410 R-Series Trays
Storage Controller: H700 512MB BBWC w/Battery
RAID Level: 10
Ethernet: Dual Port Embedded Broadcom NetXtreme II 5716 Gigabit Ethernet
Video: Embedded Matrox G200
Optical Drive: DVD-ROM
Remote Access: iDRAC6 Express
Power Supply: 2 x Dell 480W Power Supplies

Posted: **Tue May 01, 2018 6:40 pm**

1) You left off the word "Dell" ... are you ashamed of it? lol ( 8-)

)
2) I edited your (+

to (+ 8 ) so everyone could read it. You should probably have used 8X instead of + 8, seems a little weird but you got your point across.
3) 2.1Ghz is a tad slow. Otherwise it looks good.
4) Samsung 860 EVO 250GB -> SSD is cool, but be sure these can sustain throughput at rated capacity as well as (for instance) a 15K 6G/sec SAS drive. The fake reviews for this model are proliferous and almost all identical (so they are paid advertisement white papers, rather than reviews) and none of them can speak to long-life or Vicidial's level of torture. I did note in several of them that they mentioned improving the endurance of the 850 EVO, which leads me to believe the 850 EVO had endurance issues that needed to be fixed. The question is whether they "improved" the endurance enough.

We like 15K SAS drives, but we don't have any problem with SSDs ... just be very sure of your drive warranty and keep them handy in case the drives die fast.

Otherwise it looks good. To me, that is. 8-)

Posted: **Thu May 03, 2018 11:22 am**

Get a nvme drive if you can, https://www.amazon.co.uk/Samsung-MZ-V6E ... s=nvme+pro, these are fast. The bottleneck wouldn't be the ssd for sure.

Don't use a storage controller with ssd. You direct sas/sata. Use software raid.
Spend the money on a UPS instead of the raid controller.

Posted: **Thu May 03, 2018 12:53 pm**

vkad wrote:Use software raid.

Never use software raid in a Vicidial Database Server.

Posted: **Thu May 03, 2018 1:40 pm**

The ONLY RAID card that we recommend for large database servers is a MegaRAID card. It is designed for fast seek and high numbers of reads/writes, and we have installed hundreds of them over the years. They are extremely reliable and are built for the kind of data activity that a high-volume VICIdial database server requires.

Posted: **Fri May 04, 2018 11:53 am**

williamconley wrote:
vkad wrote:Use software raid.

Never use software raid in a Vicidial Database Server.

Particular reason why?

the hardware raid will only become a bottleneck

Posted: **Fri May 04, 2018 12:07 pm**

You have a firm misunderstanding of how RAID works. Common for those who have never NEEDED RAID with fast throughput, just as a glorified backup system. Thus you likely overlook the various RAID levels which offer different value for the buck.

The Vicidial Group recommends ONLY RAID 10, which provides redundant redundancy and better throughput than no RAID at all (ie: faster than no RAID). RAID5 is "technically" slower than No RAID, but the difference is minor and offset by the reliability of the system which can continue at full speed even if a drive dies (also true of RAID10). That assumes, of course, a decent RAID controller. The Vicidial Group is quite vocal about which controller they recommend. No reason to go anywhere else unless inventing wheels is your goal.

RAID1 (aka: mirror) is pretty much identical to no RAID for speed, since everything just happens on both drives simultaneously (and at the same speed). But in all cases the RAID controller itself (if it's decent, not just some "built-in to the mbd" RAID) has buffering that is often unavailable in a simple drive controller or HD, which tends to improve throughput just by being "RAID".

Software RAID, on the other hand, is not RAID at all, it's just a software-based instant backup system that takes away from system resources and (by design) slows the system. Marvelous if you're running a generic DB or website and see no need to spend $$ on a RAID controller or SAS drives.

But if you're running a single-server Vicidial system with web/DB/PBX and you push it near its limit, the first limit you'll hit is that software RAID. Switching to hardware RAID will require a reinstall, which most people don't appreciate once they get their server up to full speed.

Seriously: your first "problem" moment will, by definition, be your busiest day on record ... not the moment to have to figure out why your Dialer is suddenly unreliable in ways nobody can explain. And since there are no rules for what unstable overloaded software RAID will break ... it'll be a very bad day with lots of head-scratching and hand-wringing until you finally bite the bullet and pay a Vicidial Professional to look into it. If you're lucky you'll mention your software RAID before spending too much money and they'll do a "hard-stop" and tell you to lose the software raid.

If you're not lucky (or go to the wrong Pro ...), you won't mention this, they won't ask, and you'll end up adding extra servers until JUST the DB resides on the original server. But that'll overload early even with just the DB and then someone may focus on that RAID (which is common for "just DB" servers in Vicidial: good Vici pros will always discuss RAID10 and lots of memory for that DB server along with 1G local network access to all the other servers).

Been there. Done that. Cleaned up several of those messes. Not goin' back for the T-Shirt. 8-)

PS: also don't do vicidial "virtual".

Posted: **Tue May 08, 2018 2:28 pm**

Why are you not using the newer generation of CPUs. That CPU is like 9 years old now and probably the RAM is more expensive than the dual cpu.

Go for at least Haswell series of server, a single cpu would be sufficient for 150 agents with load close to 2.00 to 2.50 at all times..Look at E5-1650v3. You would need a slaveDB though after a month.

Posted: **Tue May 08, 2018 3:58 pm**

frequency wrote:Why are you not using the newer generation of CPUs. That CPU is like 9 years old now and probably the RAM is more expensive than the dual cpu.

Go for at least Haswell series of server, a single cpu would be sufficient for 150 agents with load close to 2.00 to 2.50 at all times..Look at E5-1650v3. You would need a slaveDB though after a month.

CPU age is not relevant. Speed, cache and core count is relevant.

Front Side Bus speed is also relevant, just like RAID sustainable speed is relevant. But only when pushing limits on heavy usage systems. Otherwise, the ROI is usually much better on older systems that are now very inexpensive.

Brand name is also not relevant (for CPUs at least).

Posted: **Tue May 08, 2018 9:31 pm**

williamconley wrote:
frequency wrote:Why are you not using the newer generation of CPUs. That CPU is like 9 years old now and probably the RAM is more expensive than the dual cpu.

Go for at least Haswell series of server, a single cpu would be sufficient for 150 agents with load close to 2.00 to 2.50 at all times..Look at E5-1650v3. You would need a slaveDB though after a month.

CPU age is not relevant. Speed, cache and core count is relevant.

Front Side Bus speed is also relevant, just like RAID sustainable speed is relevant. But only when pushing limits on heavy usage systems. Otherwise, the ROI is usually much better on older systems that are now very inexpensive.

Brand name is also not relevant (for CPUs at least).

ROI is definitely better on older systems but until those aged systems fail. At least, i am not gonna load up 150 agents on such a machine. Speed and cache are totally relevant but i highly doubt the speed of those 8 cores that were offered back then are equal to the speeds today's quad systems are offering.

Posted: **Tue May 08, 2018 9:39 pm**

frequency wrote:ROI is definitely better on older systems but until those aged systems fail. At least, i am not gonna load up 150 agents on such a machine. Speed and cache are totally relevant but i highly doubt the speed of those 8 cores that were offered back then are equal to the speeds today's quad systems are offering.

8 cores @ 2.6Ghz vs 4 cores @ 3.2 ... I'll go with 8 for most situations.

Posted: **Wed Jul 04, 2018 1:34 pm**

williamconley wrote:You have a firm misunderstanding of how RAID works. Common for those who have never NEEDED RAID with fast throughput, just as a glorified backup system. Thus you likely overlook the various RAID levels which offer different value for the buck.

------------------------------------------------
V:
No I I understand how raid works. You misunderstand why people and data centers don't use Raid the Dinosaur anymore. RAID was OKish when we had slow drives and relatively slow SSDs.

NVME raid 1 (in zfs) butchers any raid cards out there in performance and durability. The purpose of a raid was never to be used as a backup system, "glorified" or not. The purpose of RAID cards doesn't exist anymore and won't in the future. The future is about levels of parity that are beyond RAID because it sounds like that the only thing you have ever known is RAID and all of its levels (which it doesn't have many of and aren't very glorious anyways). I stopped working with RAID because there are better solutions available.
BTW, we use 2 x replicated across two sites Ceph cluster storage for general storage and backups which is very "GLORIFIED" or maybe we should have used RAID cards.
-----------------------------------
Software RAID, on the other hand, is not RAID at all, it's just a software-based instant backup system that takes away from system resources and (by design) slows the system. Marvelous if you're running a generic DB or website and see no need to spend $$ on a RAID controller or SAS drives.
-----------------------------------
V:
I don't think you understand the difference between a backup and a software raid. The purpose of a software raid is not backup...
-----------------------------------
But if you're running a single-server Vicidial system with web/DB/PBX and you push it near its limit, the first limit you'll hit is that software RAID. Switching to hardware RAID will require a reinstall, which most people don't appreciate once they get their server up to full speed.
---------------------------------------------------------------------------------
V:
We run nvme ssds and yet to hit the problem you are talking about. The shit has hit the fan many times but it has never been because of the drives.

---------------------------------------------------------------------------------

Seriously: your first "problem" moment will, by definition, be your busiest day on record ... not the moment to have to figure out why your Dialer is suddenly unreliable in ways nobody can explain. And since there are no rules for what unstable overloaded software RAID will break ... it'll be a very bad day with lots of head-scratching and hand-wringing until you finally bite the bullet and pay a Vicidial Professional to look into it. If you're lucky you'll mention your software RAID before spending too much money and they'll do a "hard-stop" and tell you to lose the software raid.

If you're not lucky (or go to the wrong Pro ...), you won't mention this, they won't ask, and you'll end up adding extra servers until JUST the DB resides on the original server. But that'll overload early even with just the DB and then someone may focus on that RAID (which is common for "just DB" servers in Vicidial: good Vici pros will always discuss RAID10 and lots of memory for that DB server along with 1G local network access to all the other servers).

---------------------------------------------------------------------------------------------------------
V:
I mean if you even have to mention that 1G is good practice on a local level, I wonder if you are still stuck in the early 2000s. 1G has been a standard across pretty much everywhere for nearly a decade now. I didn't know that anybody could even buy anything lower than 1G.
---------------------------------------------------------------------------------------------------------

Been there. Done that. Cleaned up several of those messes. Not goin' back for the T-Shirt.
---------------------------------------------------------------------------------------------------------
I can see why you need to clear up a lot of those messes. You just need to enter the realm of Modern Computing

Look at Matt, he is doing it. With Asterisk 13, WebRTC, Letsencrypt -- he is building futureproof software. Or he could have been like you and just stuck with Asterisk 11 or older (why fix it if it ain't broke) and no webrtc (why add extra load on the server or even give an awesome extra feature when you can do SIP softphones). I bet you are going to oppose OPUS and any new development.
---------------------------------------------------------------------------------------------------------
PS: also don't do vicidial "virtual".

---------------------------------------------------------------------------------------------------------
This is one point I would agree with as I have tested it and we start to have issues going beyond 15-20 agents per dialler. But if you only have 10 agents then go for it by all means. Make sure you have atleast 2.5GHZ cores and atleast 8 of them. Don't do more than 10 lines per agent.
Also keep 2gb ram per agent.
KVM is less efficient, but we have seen amazing results with LXD containers, but wonder if vicidial community will support that in the near future as they are very anti-virtualisation.
---------------------------------------------------------------------------------------------------------

vicidial.org

DB specs for 150 agents

DB specs for 150 agents

Re: DB specs for 150 agents

Re: DB specs for 150 agents

Re: DB specs for 150 agents

Re: DB specs for 150 agents

Re: DB specs for 150 agents

Re: DB specs for 150 agents

Re: DB specs for 150 agents

Re: DB specs for 150 agents

Re: DB specs for 150 agents

Re: DB specs for 150 agents

Re: DB specs for 150 agents