3

We're changing hosts for our SAAS app (IIS+MSSQL) and have an opportunity to redesign the infrastructure. Either stick with what we have (which works well) or virtualise with vSphere.

Current:

2x Web/DB Servers Each have IIS/MSSQL installed. Windows Network Load Balancing to distribute traffic between the 2 nodes with a virtual IP address & MSSQL Mirroring with automatic failover for the DB.

1x MSSQL Witness Server (small VM)

If one server fails, NLB reroutes traffic to the other node and MSSQL automatically fails over. There's maybe 40 seconds downtime while NLB redirects.

Possible:

2x vSphere Hosts

  • Firewall VM – 1 vCPU, 512MB RAM, 20GB HDD
  • Web Server VM – 1 vCPU, 2GB RAM, 50GB HDD
  • DB Server VM – 2 vCPU, 4GB RAM, 100GB HDD

1x CentOS Linux SAN (mounted as NFS shares)

Concerns are not enough resources for the DB & web. Currently the Web/DB server makes full use of the node and only has to share a node if one fails. What if the SAN fails? Was advised that the VMs HDD would reside on the Hosts themselves with the SAN acting as a redundant store. I presume this solution uses VMware High Availability - data loss for the DB is unacceptable. Should instead there be 2x DB VM machines with MSSQL mirroring set up but running on different host nodes?

EDIT: Pros of virtualisation are the ability to clone machines, easily move to new hardware, able to separate out DB/Web servers. Any comments on this?

Any help would be GREATLY appreciated!

Marcus
  • 400
  • 2
  • 5
  • 16

2 Answers2

3

With vSphere, the SAN becomes a (theoretical, because good SANs have built-in redundancy) single point of failure; but you need to place VM disks there if you want to be able to move the VMs between hosts (there is no way this can be done with local storage on the hosts).

Also, your current solution protects you from problems inside the servers: should f.e. the O.S. of one of them become damaged, the other server would remain online; if instead your only DB VM had a problem, you'd just lose it.

I would suggest using both solutions: build a virtualization environment with the two hosts, and then place redundant virtual machines inside them in order to be able to handle faults at the OS/application level. But if your hardware resources are limited and can't handle that, then just stick with the current solution.

Massimo
  • 70,200
  • 57
  • 200
  • 323
  • In practice what do people do? Is it better to separate out the web/db servers rather than have them on one machine? I think so but budget constraints mean this is only possible if we virtualise. – Marcus Feb 14 '12 at 14:40
  • Yes, it's better. But if you can only have two servers and you want redundancy, having a single DB server and a single web server will give you none, while having two DB/web servers will survive a single server failure. – Massimo Feb 14 '12 at 15:58
1

data loss for the DB is unacceptable

Ok,. you need 3 database servers using MIRRORING and the third as Witness. Alternatively logfile shipping to an external third system in case of problems.

Because it is possible the sql server corrupts the database when failing. Which results in bad data.

You need either near real time backups or basically a copy of the database permanently updated.

TomTom
  • 51,649
  • 7
  • 54
  • 136
  • Thanks TomTom. So in this case, virtualisation is no benefit? I know there is VMware Fault Tolerance? – Marcus Feb 14 '12 at 18:30
  • Which helps you how much if a faul in the database server kills the database? it helps, but to be sure you need to be able to deal with a driver error on the raid controller corrupting the drive (been there, seen that - with a HP EVA taking down a financial database). Mirroring is more expensive but gives you another copy of the database. – TomTom Feb 14 '12 at 19:05
  • Sounds like the solution we have now then is ideal. Would be better if we had redundant hardware load balancers but for cost reasons this isn't possible. Also better if we had a central store (perhaps using DFS) for storing the web files - right now we rely on a robocopy script to keep the 2nd server up to date. – Marcus Feb 14 '12 at 19:23
  • No. Replication is async and slow. mirroring can make sure both servers are in sync ALL The time - or a failover happens. Mirroring is a tricky solution and requires application elvel adjustments, mirroring is transparent, with 2012 includign failover. 3 machines for a third witness to automatically fail over. – TomTom Feb 14 '12 at 19:40
  • Sorry maybe I was unclear. We already use mirroring (with a 3rd witness server) in synchronous mode with automatic failover. – Marcus Feb 14 '12 at 19:42
  • Ah, perfect - that is IMHO the berest solution. 2 db copies is rully separated. Clustering only is worse - cheaper obviously (no second storage space) ;) but then sometimes the prie is secondary. Good setup. – TomTom Feb 14 '12 at 20:02