按照 DotNetNuke 文档中的建议，从 UNC 共享运行 IIS Web 应用程序有什么不好？

Question

过去我被告知从 UNC 共享运行 Web 应用程序是不明智的。我记得的原因是安全、权利和授权问题以及性能。但是，在 DotNetNuke 文档中，它说：

DotNetNuke 最初支持的网络场配置涉及 两个或多个前端 Web 服务器（“web-heads”），其 IIS 网站根目录 目录映射到远程文件服务器上的公共 UNC 共享。 UNC 共享包含应用程序源代码以及任何 各个网站的静态内容。

不知何故，这对我来说听起来像是一个穷人的配置，我感觉就像打开了一个潜在的潘多拉盒子。遵循 DotNetNuke Corp 的建议是否明智？

Answer 1

使用 UNC 共享本质上没有任何问题。在之前的一家公司，我们运营着数十台 Web 服务器，它们都使用 UNC 共享（不在 DNN 上）。有超过 8 万付费订阅者，其中每天有数十万人使用该应用程序。效果非常好。

要解决 Mitchel 的观点：

1.) 仅当您将单点故障视为一个问题时，它才成为一个问题。各种 SAN/NAS 解决方案都提供大量冗余。

2.) 对于任何像样的 SAN 或 NAS，IO 都不会成为问题。我从来没有遇到过文件系统观察程序的问题。 DNN 不直接使用任何东西，万一内置 ASP.Net 观察器造成问题，我可能会禁用它们。

3.) 我不认为安全性比任何其他解决方案更重要。您必须确保控制对文件的访问并适当地设置权限。对于本地磁盘，您可以选择比网络上的权限更加开放，但您可能应该同样保护两者。有一个与使用 UNC 路径相关的额外配置步骤。与创建值得建立网络场的网站所需的数周甚至数月的努力相比，围绕配置安全性的额外工作将是微不足道的。

我完全同意米切尔关于为什么不使用文件同步的观点。

我知道有些人正在运行具有文件同步功能的 DNN 站点。我不知道有谁没有解决过文件同步引起的问题。就我个人而言，如果算上解决文件同步问题所花费的人力，我怀疑通过文件同步使站点运行良好比在 SAN 上使用 UNC 更便宜。

Answer 2

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

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

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

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