我们正在改变我们的SAAS应用程序（IIS + MSSQL）的主机，并有机会重新devise基础架构。 要么坚持我们所拥有的（运行良好），要么使用vSphere虚拟化。
当前：
2个Web /数据库服务器每个都安装了IIS / MSSQL。 Windowsnetworking负载平衡使用虚拟IP地址和MSSQL镜像来为两个节点之间的stream量分配数据库自动故障转移。
1x MSSQL见证服务器 （小型VM）
如果一台服务器出现故障，NLB会将stream量重新路由到另一个节点，MSSQL将自动进行故障转移。 NLBredirect时，可能会有40秒的停机时间。
可能：
2x vSphere主机
1个CentOS Linux SAN （挂载为NFS共享）
对于数据库和networking来说，担心是不够的。 目前，Web / DB服务器充分利用节点，如果出现故障，只需要共享一个节点。 如果SAN失败怎么办？ 被告知，虚拟机HDD将驻留在主机上，SAN充当冗余存储。 我认为这个解决scheme使用VMware高可用性 – 数据库的数据丢失是不可接受的。 而是应该有两个数据库虚拟机与MSSQL镜像设置，但运行在不同的主机节点？
编辑：虚拟化的优点是能够克隆机器，轻松移动到新的硬件，能够分离出DB / Web服务器。 对此有何评论？
任何帮助将不胜感激！
使用vSphere，SAN成为（理论上的，因为好的SAN具有内置冗余）单点故障; 但是如果您希望能够在主机之间移动虚拟机，则需要将虚拟机磁盘放在那里（主机上的本地存储无法完成此操作）。
另外，您当前的解决scheme可以保护您免受服务器内部的问题：如果其中一个服务器的操作系统受到损坏，另一个服务器将保持在线状态; 如果您的唯一的数据库虚拟机出现了问题，那么您就会失去它。
我build议使用这两种解决scheme：用两台主机构build虚拟化环境，然后在其中放置冗余虚拟机，以便能够在操作系统/应用程序级别处理故障。 但是，如果您的硬件资源有限，无法处理，那就坚持使用当前的解决scheme。
数据库的数据丢失是不可接受的
好，。 你需要3个使用MIRRORING的数据库服务器，第三个作为Witness。 另外，如果出现问题，可以将日志文件发送到外部第三个系统。
因为有可能sql服务器在失败时会破坏数据库。 这会导致不良的数据。
您需要接近实时的备份或基本上数据库的副本永久更新。