我们目前有一个实时服务器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共享上的配置一起使用.
你怎么看？
解决方法
共享内容很棒;但正如您所指出的那样,您对远程主机具有依赖性,并且群集存储技术并不便宜或简单.这种类型的设置有它的位置,根据您当前的解决方案,我假设您不是在寻找99.999％的正常运行时间解决方案.
您是否考虑过扩展脚本以在从Web1同步内容时禁用负载平衡节点(在防火墙处)> WEB2？
虽然共享配置很棒,但如果您的UNC共享不可用,则使用本地缓存副本,这是确保Web应用程序具有正确配置的好方法.
我的2c