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.
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.
2x vSphere Hosts
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!
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.
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.