我们正在设置一个包含两台服务器的 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 上；然后这个 VM 会将 SMB 共享暴露给我们的 Web 服务器。
另一方面，共享内容方法的一个好处是我们只需要将代码部署到一个地方，并且内容的多个副本之间永远不会出现暂时的不一致。
此主题非常有趣，尽管其中一些人的工作规模要大得多。
到目前为止，我只是在讨论内容，但我们还需要考虑配置。我不知道我们是否可以只对 applicationHost.config 和其他文件使用 DFS 复制，或者最好使用共享配置使用 UNC 共享上的配置功能。
你怎么认为？
答案1
您的担心是有道理的，到最后您要么必须评估每项奖励及其固有的风险。
共享内容很棒；但正如您所指出的，您需要依赖远程主机，而集群存储技术既不便宜也不简单。这种设置有其适用之处，考虑到您当前的解决方案，我认为您不需要 99.999% 的正常运行时间解决方案。
您是否考虑过扩展您的脚本以在从 Web1 > Web2 同步内容时禁用负载平衡节点（在防火墙处）？
然而，共享配置非常棒，如果您的 UNC 共享不可用，则使用本地缓存副本，这是确保 Web 应用程序具有正确配置的好方法。
我的 2c
答案2
SAN 上的共享磁盘是最佳解决方案 - 但只比骑着扫帚飞行稍微现实一点。一些供应商（如 Melio）提供它 - 但有一些很大的缺点（昂贵，需要 SAN，如果在 VMware 上，则无法使用共享控制器进行快照）
答案3
一段时间以来，我们一直在使用 UNC 共享来为集群 (NLB) Webhead 提供服务，最近我们又迁移到了 64 位操作系统 Win 2008R2，两者的区别非常大，我们不再担心耗尽 SMB 连接。虽然有限制，但限制很高。我刚刚将 DFS 与另一台文件服务器混合使用，但目前还不能确定其可靠性。
答案4
在共享磁盘文件系统上使用 iSCSI...UNC 共享太慢