Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am designing a computer network for a public high school and came up with the following division of responsibilities between the servers:

In the LAN:

  • Active Directory Domain Controller. The DC will serve approx. 130 devices in the LAN. DNS, DHCP and RADIUS run here.

  • File server. User profiles, data shares, mail.

  • Application server. SQL server and several other programs, such as IP camera recorder, building access control, lunch ordering system, etc.

In the DMZ:

  • Internet gateway. Provides access to the Internet. Runs Exchange, IIS and a web-caching proxy.

  • Web server. Debian GNU/Linux hosting several websites and webmail.

This is five servers. Although I can acquire the necessary hardware, it seems like a lot. And for some reason, I do not like having servers virtualized.

If I use this design, I would like to take advantage of it and run another AD DC on the file server, just in case something goes wrong with the first server. But user profiles are stored on the file server, so if the file server goes down, everything goes down.

So maybe I could move the data onto a disk array attached to both the AD DC and the file server. Both of them would serve as a DC and file server. I could even run secondary DNS, backup DHCP and backup RADIUS on the second server thus making all services redundant for a little more configuration.

Half of the computers in the LAN could have the first server configured as the primary DC/DHCP/DNS, the other half could use the other server as the primary to balance loads.

SQL server is absolutely critical on the Application server. I could run a backup SQL server on the first DC. The other apps on the application server are not as critical.

Two machines are in the DMZ. Unfortunately we need IIS server in the DMZ. Otherwise a single GNU/Linux server would do. (I would use postfix instead of Exchange Server.)

I do not have much experience with the design of computer networks (except for very small networks or separate servers) and would like to know whether or not is my design reasonable and whether there are any inherent flaws.

If there is a good book on the subject, please let me know.

share|improve this question
If you're not willing to consider virtualization, you are already way behind the curve. Virtualized servers is now the default for the vast majority of orgs, and for good reason. There is no good reason you shouldn't be virtualizing every single one of there systems. Doing so will vastly increase your flexibility, reliability, and ease of management. – EEAA May 4 '14 at 21:06
I'm with @EEAA on this. Given the maturity of virtualization platforms you're screwing yourself with backups, change management, disaster recovery, system management, everything. – Scott Pack May 4 '14 at 21:15
By not virtualizing, you're doing a disservice. Hyper-V Server is free and provides live migration, storage migration, and guest replicas without and shared storage. Introduce a shared SAS DAS and you have HA in a box. – MDMarra May 4 '14 at 22:34
up vote 7 down vote accepted

You want high availability - the ability for everything to keep running smoothly when something fails. Virtualization is a key part of offering that. I would not even think of doing this without virtual machines.

A very simple setup would be two physical servers with lots of RAM, running VMware ESXI or HyperV in a cluster, and some shared storage (an iSCSI SAN, for example). I'm a big fan of HyperV, especially if you get special educational pricing on Windows Server Datacenter. Spec the systems so everything COULD run on one server, though perhaps not as quickly as you'd like it to under normal circumstances. Primarily this means having enough RAM to run everything. If you do this, under normal circumstances the load will be balanced across the two servers, but if a physical host fails, everything keeps running and nobody is screaming at you while you fix it.

Virtualizing means you aren't limited by the number of physical servers you have (though you are limited by their memory and CPU power). This means you can do things like run two domain controllers, with DHCP either setup as a failover cluster role or split DHCP ranges. You may also be able to use the new Server 2012 features to run a continuously available file server. Same things goes for redundant SQL servers. In both cases, you tell the virtualization platform to keep those virtual machine pairs on separate physical servers, so even if a physical server dies nobody notices.

You NEED to have two domain controllers. Anything less is asking for trouble down the road. Active directory ties into everything, and if it goes down, a LOT of things break. More importantly, recovering active directory is a lot easier if there is still a working domain controller on the network.

Your idea to run your fileserver as a second domain controller isn't too terrible. But running SQL on a domain controller isn't a good idea. Separate servers for separate tasks makes things less likely to break, gives you more control over down time (I need to update SQL I have to take active directory offline for awhile...), and makes restoring backups much, much simpler.

The DMZ can be handled by VLANs on the same servers, or could be a separate physical box, depending on exactly what you need.

The best aspect of virtualization, besides saving you a ton of money buying expensive servers that sit idle all day, is that it decouples the operating system from the hardware. Want to upgrade the hardware to the latest and greatest model - no problem, no need to reinstall windows, just install the hypervisor and migrate the virtual machine over. In many cases, this can be done without even turning the virtual machine off, 0 downtime. The OS doesn't know its on new hardware, doesn't need drivers reinstalled, it just works.

Working for a school you're probably eligible for awesome discounts from Microsoft, so I'd recommend picking up a good book on Hyper-V. For picking hardware - work with a vendor. Dell or HP or whoever will be more than happy to show you a setup of servers and storage that they've already tested to work well together.

share|improve this answer
thank you very much for your answer, it is greatly appreciated. I will seriously consider implementing HyperV. – David May 6 '14 at 15:56
One more question. From your experience, what is the least amount of RAM necessary to run the setup I am talking about smoothly? I am not asking for exact numbers, just a general rule of thumb. – David May 7 '14 at 17:25
@david that depends a lot on how much memory is needed for sql server to run smoothly and your other applications. I would plan on 1-2gb each minimum for AD servers, 8gb min for sql. Those are absolute minimums. Buy as much as you can possibly afford, and if possible larger sticks so you leave some slots free for future upgrades. My hyperv servers have 96gb RAM each, and I plan to upgrade that soon. The more ram you give each vm the more caching it can do so the better it runs. Database servers especially benefit from as much ram as you can afford to give them. – Grant May 7 '14 at 17:41

The avoidance of virtual servers certainly restricts your choice. You should reconsider this if possible.

There is no good way to run multiple DHCP on a segment. It makes more sense to run this as a cluster resource to ensure high-availability. The second DC is essential to allow things like maintenance to happen during normal hours. You don't indicate the reason for RADIUS, so I'll assume VPN. This should also be redundant to allow faults and maintenance.

SQL Server also needs a highly available cluster to provide assured service.

The IIS in the DMZ is curious. If you intend to keep a *nux web server there, use reverse proxy to keep the IIS role inside the firewall. That way you can also keep the Exchange role on the internal servers.

It is more important to consider the workload of each role than the specific role.

You also need to consider how you want to allow for backups across this many machines.

Look at using a cluster as a NAS front-ending onto a fault-tolerant SAN node - iSCSI attached to lower costs. You also need redundant switches.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.