如DotNetNuke文档中所建议的那样,从UNC共享运行IIS Web应用程序有什么坏处？

Question

过去我曾经被教过,从UNC共享运行Web应用程序是不明智的.我记得的原因是安全性,权利和授权问题和性能.但是,在DotNetNuke文档中它说:

DotNetNuke最初支持的Web场配置涉及两个或多个前端Web服务器("Web头"),其IIS网站根目录映射到远程文件服务器上的公共UNC共享.UNC共享包含应用程序源代码以及各个站点​​的任何静态内容.

不知怎的,这听起来像是一个穷人的配置,我觉得打开一个潜在的潘多拉的盒子.遵循DotNetNuke Corp的建议是明智的吗？

Answer 1

使用UNC共享没有任何内在错误.在之前的公司,我们运营了数十台Web服务器,它们都使用UNC共享(不在DNN上).有超过8万的付费订阅者,其中每天有10万人使用这些应用程序.它工作得很好.

解决米切尔的观点:

1.)单点故障只是一个问题,如果你把它作为一个问题.各种SAN/NAS解决方案中提供了大量冗余.

2.)IO不会是任何体面的SAN或NAS的问题.我从未遇到过文件系统观察者的问题.DNN没有直接使用任何内容,万一内置的ASP.Net观察者创建了一个问题,我可能会禁用它们.

3.)我认为安全性不再是任何其他解决方案.您必须确保适当地控制对文件的访问权限和设置权限.使用本地磁盘,您可以选择保留比在网络上更开放的权限,但您可能应该同样保护两者.有一个与使用UNC路径相关的额外配置步骤.与创建符合Web场的站点所涉及的数周(如果不是数月)相比,配置安全性的额外工作将是微不足道的.

我完全同意Mitchel关于为什么不使用文件同步的意见.

我知道有些人在运行带有文件同步的DNN站点.我不知道有谁没有解决由文件同步引起的问题.我个人怀疑,一旦你计算了整理文件同步的怪癖所花费的劳动力,那么使用文件同步运行良好的站点比在SAN上使用UNC便宜.

Answer 2

当涉及 DOtNetNuke 的此类配置时，有一些事情可能会出现问题。

1. 尽管这种方法是“网络场”场景，但会导致单点故障。UNC 共享成为您的瓶颈，如果它出现故障，所有节点都会出现故障。
2. 磁盘 IO 和网络通信配置可能是一个问题。这与可以在远程内容上打开/维护的“文件系统观察者”的数量有关。在大多数情况下，这个问题并不是什么大问题，但当它发生时，可能会成为一个皇家 PITA。
3. 安全性可能是一个问题，但通常是您在配置开始时遇到的问题。您需要确保为用户帐户正确分配权限，以便它可以完全访问 UNC 共享。

我猜测为什么这是 DotNetNuke 公司的“​​默认”建议，原因如下。注意：这些只是我的意见。

1. 当涉及实时内容同步时，此配置提供了“最少”的复杂性。如果只有一个文件系统，则无需讨论复制和类似性质的事情。
2. 默认缓存使用基于文件的缓存，两者都进入同一系统，缓存过期很容易管理。如果复制的话就不行了。