Ideal redundancy configuration for 3 physical servers running IIS and SQL Server

Question

I'm looking to set up as redundant an architecture as possible to serve a data-centric web application with only 3 servers (only 5U of rack space). Between these two setups, which would be most ideal, and what kinds of pros and cons for each would I be looking at?

Option 1:

• 2 web servers + 1 database server. The web servers would be moderately powerful and be served traffic by a load balancer while the database server would be a significantly beefy machine with as much on-board redundancy as possible (power supplies, hot-swap HDDs, etc.)

Option 2:

• 3 identical servers, each running IIS and SQL Server. They would each be more powerful than option 1's web servers, each with RAID 5/10 setups, tons of RAM, 8-16 cores, etc. I'm not sure if they'd have things like hot-swappable drives or power supplies, though.

I like the simplicity of option 1 but don't like how the database sever is a big failure point. Option 2 seems to address the database issue, however I'm sure there'll be some caveats with having the database both mirrored across 3 instances and running along side IIS.

Any thoughts? Thanks in advance.

Answer 1

If high availability (HA) is your goal then you really should have a separate site for disaster recovery. What happens if you lose power to your rack? Your app goes offline. Database mirroring is a good, cheap solution for this for the database server. You could also consider double-take replication or even a replicated SAN (more expensive) so that you can replicate the web server too.

For local HA you could set up a load balanced web server on machines A and B. Then set up a SQL Server failover cluster on machines B and C with B being a passive node and C the active node. This means that machines A and B will service web requests and will pass on these requests to the database server on machine C. If machine C dies, the database will failover to machine B giving you redundancy but with a possible hit on performance. If machine A dies, then machine B will take over. If machine B dies, then Machine A will service web requests and machine C will service database requests as usual. You could have two machines go down (as long as they're both not the web server) and your application will still run but with a major performance hit.

I like phoebus's suggestion of utilising VMs for this, however you really need to test performance with the VMs as it can be a limiting factor. I would not cluster VMs though, I'd rather rely on Vmotion to failover. For performance I would also only have 1 VM per host - there's no benefit in creating more than 1 VM per host IMO. Be aware of limitations of VMs though - reduced RAM and CPU. You also need someone fairly experienced to configure it fully optimally. I have found for instance that performance can go up in some cases by reducing the number of vCPUs a VM has to 1.

Much testing and benchmarking should be done to find the best solution, however my gut feel is to use load balanced web servers and SQL Server clustering. Make sure that your disk arrays can be configured as shared disks.