Infrastructure advice - appliaction and network servers

Question

I'd like to ask for server infrastructure advice. We'll be upgrading our network infrastructure (built on MS ecosystem) and so far we have two servers (not counting ISA server): one machine serves application services like Exchange, IIS, SQL, etc., the other machine serves network services (domain controller, network services like DNS, DHCP, cert, it's also a file server. Both servers are on local subnet 192.168.x.x.

Application server was partly accessible from the outside through server publishing rules via ISA server for specific services (e.g., Exchange server). This setup is for small to middle size organization, so performance isn't an issue.

Now we'll be upgrading old hardware and it might be good to review our current server infrastructure. What we need is:

• domain controller
• network services (DNS, DHCP, ...)
• Exchange server
• SQL server
• IIS
• TFS
• file server
• update services
• certification authority
• something more, but mostly insignificant -

Would you recommend to keep current two-server infrastructure (one machine for application server on local network with some published services) and one machine as DC, network & files server, or everything in one server (but Exchange and DC on one machine isn't good so far I know), or something entirely different, or to keep application server in DMZ, etc. Btw, do you see any problem with having DC and file server in one machine?

Added after comments and Nextraztus's and Golmaal's answers:

Regarding virtualization, I'm definitely for Hyper-V - I'm fully MS person, I'm developing for Windows since WfW 3.1 and last decade I work with ASP.NET and Windows kernel IFS (yes, two quite but nice different worlds, C# and pure C).

Our standard setup is RAID 10 for system and critical data, RAID 5 for 'normal' data.

I'm almost afraid to admit that aloud, but I have some personal issues with virtualization - and I would appreciate if you can help me overcome this :) I use it day and night for the development, especially kernel developmnet with checkced builds of Windows, I use it with our work on Azure (we use nearly all services that Azure offers, VMs, Web Sites, Web Roles, caches and many more), but here in house, I "feel" that I'd still like to have real physical servers.

So far I understand, virtualization gives me more freedom, since I can have nearly as much servers as I want and can separate concerns as a need arises, I can back up entire images.

Without virtualization, I can specify that system runs on SSD, these data run on RAID 10, these data on RAID 5 (and if I need, I can add specifically new disks to thes data volume), etc. I know it becomes a different question, and it really seems you're all right, but what's real benefit of have everything virtualized, besides much lower costs?

EDIT 2:

I can understand that DC should be kept alone (but it's ok with network services, especially DNS and DHCP) - but why it seems better to expose almost each server role to separate server? Exchange to one server, SQL Server to another server, TFS to another server - the only reason I can think of is load balancing, but if it's not an issue ... ? On the contrary, I can see that e.g. TFS can benefit from running on the machine with SQL Server, IIS and Exchange.

Answer 1

As @Sarge mentioned in his comment, virtualization is a good route to go for your use case. Please note that these are all mostly opinion and really high-level look at it.

Pick a virutalization platform.

There are many to choose from these days, I'd personally recommend one of the following:

• Microsoft's HyperV
• VMWare

There are major pro's and con's to each, mostly price and license terms. You will want to work with your vendors to make sure you don't get oversold or undersold (and fail the specter of an audit).

Decide how redundant you want to be

Again, several ways you can go with this, the most obvious choice is just get two beefy servers and cluster them with whatever virtualization platform you decide on. This can obviously become very expensive very quickly.

Another option would be to just put everything on a SAN that is backed up properly -- one failure scenario is the case that you lose your server that does the actual virtualization, but since everything is nicely containerized into virtual machines, you can get back up and running as soon as the new iron arrives.

The other mode of failure is of course the SAN dying. Do good backups and this isn't a problem. Obviously, you have lots of options here as well

Get appropriate training

Virutalization is a whole-new-bag-o-worms and requires a careful hand sometimes. However, it is really nice when you need to test something out and don't want to risk breaking your existing infrastructure. Whatever technology you pick, go get some professional development on how to administer it.

Deploy

There are a lot of tools for converting physical servers to virtual machines. Since most of your services are clustered onto a single server, you're not going to see much benefit out of the gate, unless you can spend a weekend setting everything up and moving things over.

Improve

Once everything is back up to where you were, you can now have some fun. In your new environment it will be much trickier to break things. Go forth and prosper knowing you can setup and tear down new machines and new ideas at the click of a few buttons.

Architecture

I am not a Windows specialist, but I've always been told that having anything running on a DC besides just directory services is bad juju. I've also heard you almost always want two DCs to split up the roles (RID, PDC, and IM) as well as the obvious redundancy if something happens to one of the DCs.

Obviously, licensing is an issue for these kinds of things. But in reality, if you keep an eye on load and stay on top of your duties, a small environment probably isn't going to be a big deal to double-duty the servers. Also, servers these days, STUPID powerful for reasonable prices.

Gotchas

Virtualization shares resources. This is obvious but needs to be mentioned. RAM, HardDrive, and everything else needs to be kept on the forefront of your mind if you go this route. Do not undersize your hardware since everything will be sharing now. If something goes crazy and eats up all the space on your storage, your other machines will now suffer if you don't keep an eye on it.

As for your DMZ question - if you decide to virtualize AND you decide to publically expose anything, you should make sure to put those machines on a different virtual network so they stay properly segmented.

Hope some of these thoughts help.

Answer 2

In a small/medium setup where clustering/HA are not a prime concern (esp due to complexities and costs involved in multiple licenses, need for higher/enterprise versions etc.), virtualization may not appear attractive option; that said, it all depends on the number of users and how critical the operations are. Since you have mentioned that "This setup is for small to middle size organization, so performance isn't an issue", I take some freedom to make an assumption that that clustering/HA etc. are not required. In the end it all depends on acceptable downtime.

I would go with two physical servers running four VM (each Windows Server 2008 license can run on either one physical server or two virtual servers):

Server 1:
   VM1:
      PDC
      Network Services
      File Server (Use DFS replication)
   VM2:
      SQL Server

Server 2:
   VM3:
      Secondary Domain Controller (global catalog; backup dhcp etc)
      File Server (Use DFS replication)
   VM4:
      Exchange

You can have other services running on either VM1 or VM3. Liquidate ISA and go for a third physical server (low-end); install pfSense on it and make it your full-fledged TMG/UMG with firewall, anti-virus, caching, VPN etc. Go for mail relay / backup services provided by cos like dnsexit.com; it can be least expensive way of achieving Exchange failover (depends on expectations).

This way you will have a domain with failover for some of the most critical services. For example, if your PDC is unavailable for some reasons, your VM3 will take over and your clients can still access files and use Internet and mails.

With proper backup strategy, you may be able to minimize the downtime to acceptable limits for other services such as SQL Server, Exchange, etc. Use of RAID 10, SSD, etc. can give you configuration freedom and can improve reliability without adding considerable costs or complexities.

I hope it helps.

EDIT:

I am not much into Exchange but it is one server which you will want to keep in DMZ and thus it might make sense to keep it in its own VM. Same goes for IIS - in same VM as Exchange. I can see that you are totally into MS ecosystem and Azure. Is there any particular reason for having in-house Exchange rather than hosted?

DFS - It works and works well. In my view, it is poor admin's HA solution for file server. If you don't have to do offline files, you should give DFS a try.

TFS can go with VM2. I haven't used it but I understand that it is a resource hungry application. If you go with hosted Exchange, use VM4 for TFS.

Running Exchange, SQL Server and TFS on same physical machine / same VM is okay if you ask me. But when you run them on different VMs, it does not have any disadvantages compared to running them on single physical/virtual machine. For me, the biggest advantage is flexibility and some peace of mind. For example, if your SQL Server admin messes up something badly and you have to rebuild that machine, the rest of your services will still work uninterrupted while you restore the SQL Server VM from backup or from scratch.