昨天，我们托管数据库和 IIS 的服务器发生了突袭故障。
我们正在尝试确定 IIS 和 MSSQL 托管环境方面的最佳前进方式。
我们希望 IIS 端和 SQL 端具有冗余。
对于我们的某些应用程序，我们使用 pfSense 来平衡两个 Web 服务器的负载（粘性会话效果不佳，因此我们在数据库中进入了会话状态）。这两个 Web 服务器访问运行 SQL Express 的单个 MSSQL 实例（免费，我们的数据库非常小，最大为 1GB）。
我对我们的 IIS 负载平衡相当有信心，因为当我们运行补丁时，它“就能正常工作”，我实际上不需要做太多事情。
然而，我们的 SQL Server 基础设施让我担心。
构建容错 SQL 堆栈的最佳方法是什么？
编辑：现在我想起来，集群不一定能解决我们的问题。我们的 RAID5 中有两个驱动器发生故障。一个完全故障，另一个尚未损坏，但标记为有坏扇区故障。我们有一个数据库位于坏集群中，我们必须从备份中恢复。集群要么会损坏，要么会将坏数据放在整个集群中。啊！
答案1
虽然这不是问题的重点，但我确实想指出，在数据库中使用会话状态会导致性能下降。有一些棘手问题（有一些解决方法）已知该会话存储模型会发生这种情况。值得花时间让粘性会话正常工作，以便您可以使用 InProc 存储 - 即使这意味着 Web 前端的负载有些不对称。
我原本打算深入研究合并复制、分区、对等事务复制以及使用 SQL Server 进行扩展/FT/HA 的其他技术，但这些技术似乎对您的环境来说有些过度了 - 而且需要非 Express SQL Server。使用 MS Cluster Services 的 SQL Server 故障转移群集虽然功能有限，但是为了容错而设计的。但是，通常的单站点配置依赖于共享存储，这对您没有任何帮助。
我建议你使用 SAN（甚至是 NAS，取决于你的负载和预算）和 RAID 10（或 6，如果你买不起）以及热备件、频繁备份，并且最好使用可以主动扫描完整性问题的设备，而不是一堆便宜的磁盘，从而专注于更高质量的存储。（尽管你可能会做得更糟开放文件管理器在合适的硬件上。
如果你的服务器硬盘仅限于 RAID 5（无共享存储），请查看“多站点”故障转移群集使用复制，尽管您可能会发现实施的价格（SQL Server Enterprise Edition 是最低要求）非常高。