我们正在建立一个带有两台服务器的 IIS7 网络场。每个服务器应该有自己的本地内容副本，还是应该直接从 UNC 共享中提取内容？每种方法的优缺点是什么？
我们目前有一个实时服务器 WEB1，内容本地存储在单独的分区上。作业定期将 WEB1 同步到备用服务器 WEB2，对内容使用 robocopy，对配置使用 msdeploy。如果 WEB1 出现故障，Nagios 会通知我们，我们手动运行脚本将 IP 地址移动到 WEB2 的网络接口。两台服务器实际上都是在不同的 VMWare ESX 4 主机上运行的虚拟机。服务器已加入域。
我们在 WEB1 上有大约 50-60 个实时站点 - 主要是 ASP.NET，还有一些只是静态 HTML。大多数是低流量的“微型网站”。少数流量适中，但没有一个流量很大。
我们想改变这一点，以便 WEB1 和 WEB2 都在积极地提供内容。这主要是为了可靠性 - 如果 WEB1 出现故障，我们不希望手动干预以故障转移。分散负载也很好，但是现在负载还不够高，我们需要这个。
我们计划配置我们的防火墙以平衡两台服务器之间的流量。它将检测服务器何时关闭并将所有流量发送到剩余的活动服务器。我们现在计划使用粘性会话......最终我们可能会转向 SQL Server 会话状态和无状态负载平衡。
但是我们需要一种让服务器共享内容的方法。我们最初计划将所有内容移至 UNC 共享。我们的存储提供商说他们可以为我们设置一个高度可用的 SMB 共享。因此，如果我们走 UNC 路线，存储不应该是单点故障。但我们想知道这种方法的缺点：
我们需要更改每个站点和虚拟目录的物理路径。还有一些项目在其 web.config 文件中有绝对路径——我们也必须更新它们。
我们需要为 Web 服务器创建一个域用户以访问共享，并授予该用户适当的权限。我还没有对此进行研究 - 我不确定是否需要将应用程序池标识更改为此用户，或者是否有另一种方法告诉 IIS 在连接到共享时使用此帐户。
如果出现 Active Directory 问题，站点将无法再访问其内容。
一般来说，它看起来要复杂得多，有更多可能会损坏的活动部件。我们的存储提供商会在他们的冗余 SAN 上为我们创建一个卷。如果我理解正确，这个 SAN 卷将安装在运行在其冗余 VMWare 环境中的虚拟机上；然后，此 VM 会将 SMB 共享公开给我们的 Web 服务器。
另一方面，共享内容方法的一个好处是我们只需将代码部署到一个地方，并且内容的多个副本之间永远不会出现暂时的不一致。
这个线程非常有趣，尽管其中一些人的工作规模要大得多。
到目前为止，我一直在讨论内容，但我们还需要考虑配置。我不知道我们是否可以只对 applicationHost.config 和其他文件使用 DFS 复制，或者最好将共享配置功能与 UNC 共享上的配置一起使用。
你怎么看？
您的担忧是有道理的，最终您将不得不评估每个奖励及其继承风险。
共享内容很棒；但是正如您指出的那样，您依赖于远程主机，并且集群存储技术并不便宜或简单。这种类型的设置有它的位置，鉴于您当前的解决方案，我假设您不是在寻找 99.999% 正常运行时间的解决方案。
在从 Web1 > Web2 同步内容时，您是否考虑过扩展脚本以禁用负载平衡节点（在防火墙处）？
Shared Config 很棒，如果您的 UNC 共享不可用，它会使用本地缓存副本，并且是确保 Web 应用程序具有正确配置的好方法。
我的2c
SAN 上的共享磁盘是最好的解决方案——但它只比在扫帚上飞行更现实一点。像 Melio 这样的一些供应商提供它 - 但有一些很大的缺点（昂贵，需要 SAN，如果在 VMware 上失去使用共享控制器进行快照的能力）
一段时间以来，我们一直在使用 UNC 共享服务集群 (NLB) 网络头，最近迁移到 64 位操作系统 Win 2008R2，差异巨大，不再担心耗尽 SMB 连接。有限制，但它们很高。我刚刚将 DFS 添加到另一个文件服务器中，但我还不能谈论可靠性。
在共享磁盘文件系统上使用 iSCSI... UNC 共享太慢