If we were hired to do this install for a client who "left it up to us" (which is a major percentage of our installs), we would load all servers using the 64-bit Vicibox 5.0.3 iso image like this:
1) DB / Web / Dialer (ie: all possible roles for the first server). Certify it with all required operations (validate autodial and inbound and anything else you feel the need to test to be sure this server is fully functional). Note that this should be the most powerful server in the cluster with the most cores and the most memory and the FAST hard drives (SSD or SAS 15K rpm ... 6G/Sec, that sort of thing). Possibly with RAID 10 if you have it for the DB and OS. Servers should have two network cards, one public ip and one private ip, and the public IP should be whitelist limited so no one can access without an authorized IP address. Configure NTP to use only US Government ntp tier 1 or 2 servers for date/time sync. And verify that ntpq -p shows "synced" to multiple servers several times throughout the day (stable ntp is necessary to verify). If there is a problem, use "yast" to configure ntp until it works properly (or learn ntp ...).
2) Add a 1T (or larger) generic SATA cheap drive (or two in a mirror) to the above server to allow it lots of storage NOT on the OS/DB drive, mounted in /home which is the archive folder. Then add the Archive role to this server and test that role. To test, you will make a client recording and verify that it gets moved to the new drive and is still available via Web in its new location (NOT on the OS/DB drive and no longer in its original recording location, preferably on the external IP if that will be where recordings will normally be accessed).
3) Now that the entire system is built ... it needs only some disposable/replaceable servers (clone up!). Add all three servers (one at a time) as Dialer/Web. Configure them with standard Vicibox installer to join the cluster. Also be sure to NTP them to iburst (immediate ntp sync) to the DB server. They do not need to ntp anywhere else, they should merely trust the DB server's time because it is important their time matches the DB server (even if the DB is wrong, they should all agree with the DB!).
4) Upon completion, you have a four server cluster capable of 25 agents per dialer. In theory you should avoid registering phones to the DB server and only use it for DB/Web, but you can use "htop" to show your average server load and experiment with how many agents on which server give you the lowest load while keeping sound quality and server operations stable.
Do have a look at load balancing for both web and dialer functions. Web server load balancing is handled in many ways by different software packages (do you just send every agent logging in to the next server? or do you check load average and send them to the lowest load? or perhaps check the number of agents on each and try to balance that way?). Same with Agent Phone Registrations, except there is already a function in Vicidial for this if you have MultiLine phones and use Phone Aliases (it's in the manual! LOL).
Remember that the bulk of your load is in three main areas: 1) Dialer functions 2) DB functions and 3) Web functions. When you only have one dialer, the dialer functions are biggest. But when you have multiple, the DB functions will eventually be largest. And web functions vary with usage but with larger systems will eventually require a dedicated server. Installing all roles on all servers, however, allows you the opportunity to "Balance" in any way you see fit. We've noted VERY minimal savings by not having those functions installed and idling. Necessary by the time you get to Eight servers, but not so much at Four.
I will note, however, that your scenario WOULD be better served by Eight servers:
1 - DB
2 - Web (50 agents each)
4 - Dialer (25 agents each)
1 - Archive (no agents, just archival functions)
But: as you only have Four servers at your disposal, you'll need to make the most of the resources at hand and "blend" services to suit your needs on a daily basis. Keep an eye on your load averages and listen for call quality complaints and watch for irregular behavior during heavy load. And learn to run your system the way YOU need to. No one will know these servers better than you in 30 days.
Happy Hunting.
PS: For those who think installing dialer functions on the DB server is a waste, consider this: In the middle of a workday you need to test a call to see if the problem is A or B or to see if you can accomplish something in test scenario. Trying to troubleshoot this with 5 calls per second shooting off and all the other debug/console messages flying by can be painfully slow. But ... the DB server is also part of the cluster. Even if left out of "regular dialing", it can still have a campaign with a single agent joined into an existing campaign to take individual calls. With a small trunk limit, it's dialing can be very limited. Troubleshooting can take very little CPU and yet yield great rewards without taking all the agents off any of the other dialers or impeding progress in any way. Excellent for real world testing on the cluster with much less headache and almost no noticeable CPU usage if done correctly.