我们正在build立一个有两台服务器的IIS7 Web场。 每个服务器应该有自己的本地副本的内容，还是应该直接从UNC共享内容中提取内容？ 每种方法的优缺点是什么？
我们目前有一个实时服务器WEB1，内容存储在一个单独的分区上。 作业定期将WEB1同步到备用服务器WEB2，使用robocopy作为内容，使用msdeploy作为configuration。 如果WEB1出现故障，Nagios会通知我们，我们手动运行脚本将IP地址移到WEB2的networking接口。 这两台服务器实际上都是在单独的VMWare ESX 4主机上运行的虚拟机。 服务器是域join的。
我们在WEB1上有大约50-60个活动站点 – 主要是ASP.NET，有一些只是静态的HTML。 大部分是低stream量的“微型网站”。 less数人拥有中等stream量，但没有一个是大规模的。
我们想改变这个，所以WEB1和WEB2都在积极地提供内容。 这主要是为了可靠性 – 如果WEB1发生故障，我们不希望手动干预来解决问题。 传播负载也很好，但现在负载不够高，我们需要这个。
我们计划configuration我们的防火墙来平衡两台服务器之间的stream量。 它将检测服务器何时closures，并将所有stream量发送到剩余的活动服务器。 我们现在计划使用粘性会话…最终我们可能会转移到SQL Server会话状态和无状态负载平衡。
但是我们需要一种服务器共享内容的方式。 我们原本计划将所有内容转移到UNC份额。 我们的存储提供商说，他们可以为我们build立一个高度可用的SMB分享。 所以，如果我们去UNC路线，存储不应该是一个单一的失败点。 但是我们想知道这种方法的缺点：
我们需要更改每个站点和虚拟目录的物理path。 还有一些在web.config文件中有绝对path的项目 – 我们也必须更新它们。
我们需要为Web服务器创build一个域用户来访问共享，并为该用户授予适当的权限。 我还没有看过这个 – 我不确定应用程序池标识是否需要更改为此用户，或者如果有另一种方式告诉IIS连接到共享时使用此帐户。
如果存在活动目录问题，站点将不能再访问他们的内容。
总的来说，似乎更复杂一些，更多的运动部件可能会被打破。 我们的存储提供商将为我们在冗余SAN上创build一个卷。 如果我理解正确，这个SAN卷将挂载在运行在冗余VMWare环境中的VM上; 这个虚拟机然后将SMB分享给我们的networking服务器。
另一方面，共享内容方法的好处是我们只需要将代码部署到一个地方，并且内容的多个副本之间永远不会有暂时的不一致。
这个主题非常有趣，尽pipe其中一些人的工作规模更大。
到目前为止，我刚刚讨论过内容，但是我们也需要考虑configuration。 我不知道我们是否可以将DFS复制用于applicationHost.config和其他文件，或者最好是将共享configurationfunction与UNC共享上的configuration一起使用。
你怎么看？
您的担心是有效的，在一天结束的时候，您将不得不评估每个奖励与其inheritance风险。
共享内容很棒; 但正如您所指出的那样，您对远程主机有依赖性，而集群存储技术并不便宜或不简单。 这种types的设置有其自己的位置，并给出你现在的解决scheme，我假设你不是在寻找一个99.999％的正常运行时间的解决scheme。
您是否想过在Web1> Web2中同步内容的时候扩展脚本以禁用负载平衡节点（在防火墙上）？
共享configuration是伟大的，并使用本地caching副本，如果您的UNC共享不可用，并且是确保Web应用程序具有正确configuration的好方法。
我的2c的
SAN上的共享磁盘是最好的解决scheme，但只比使用扫帚飞行更现实一点点。 一些像Melio这样的供应商提供了它 – 但是有一些很大的缺点（昂贵，需要一个SAN，如果在VMware上失去了使用共享控制器的能力）
一段时间以来，我们一直在使用UNC共享服务集群（NLB）网站头，最近迁移到64位OS Win 2008R2，差别是巨大的，没有更多的担心用尽SMB连接。 有限制，但他们很高。 我刚刚添加了DFS到另一个文件服务器的混合，但我不能说可靠性呢。
在共享磁盘文件系统上使用iSCSI … UNC共享速度太慢