我们目前有一个实时服务器WEB1,内容存储在一个单独的分区上.作业定期将WEB1同步到备用服务器WEB2,使用robocopy进行内容,使用msdeploy进行配置.如果WEB1发生故障,Nagios会通知我们,我们手动运行脚本将IP地址移动到WEB2的网络接口.两台服务器实际上都是在不同的VMWare ESX 4主机上运行的VM.服务器是域加入的.

我们在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服务器.

另一方面,共享内容方法的好处是我们只需要将代码部署到一个地方,并且内容的多个副本之间永远不会存在暂时的不一致.

This thread非常有趣,尽管其中一些人的工作规模要大得多.

我到目前为止一直在讨论内容,但我们还需要考虑配置.我不知道我们是否可以将dFS复制用于applicationHost.config和其他文件,或者最好将shared configuration功能与UNC共享上的配置一起使用.

你怎么看？