我们有一个ASP.NET文件传递应用程序（内部用户上传，外部用户下载），我想知道分发文件的最佳方法是什么，所以我们只通过存储应用程序就没有单点故障一台服务器上的文件。我们将应用程序的负载分布在多个前端Web服务器上，这意味着对于文件存储，我们不能简单地在Web服务器上本地存储文件。
我们当前的设置让我们指向主数据库/文件服务器上的共享。在一天中，我们将主服务器上共享的内容复制到故障转移。这个scneario确保我们有一台辅助机器上有相当新的数据，但是我们希望能够从主服务器故障转移到故障转移，然后再返回，而不会丢失前端应用程序中的数据或错误。现在，这是一个相当手动的过程。
可能的解决方案包括：
那么你通常如何解决这个问题？什么是最好的解决方案？
答案 0 :(得分：2)
考虑像AWS S3这样的云解决方案。它是您使用，可扩展和高可用性的代价。
答案 1 :(得分：1)
您需要一个带RAID的SAN。他们为正常运行时间构建这些机器。
这真的是一个IT问题......
答案 2 :(得分：1)
当有多种不同的应用程序类型通过中央数据库的介质共享信息时，将文件内容直接存储到数据库中通常是个好主意。但似乎您的系统设计中只有一种类型 - 一种Web应用程序。如果它只是需要访问文件的Web服务器，并且没有其他应用程序与数据库连接，那么文件系统而不是数据库中的存储通常仍然是更好的方法。当然，这实际上取决于系统的复杂要求。
如果您没有将DFS视为一种可行的方法，您可能需要考虑Failover clustering of your file server tier，您的文件存储在外部共享存储中（而不是昂贵的SAN，我认为这对您的案例来说太过分了。 DFS已经无法访问）连接在Active和Passive文件服务器之间。如果活动文件服务器关闭，则被动可以接管并继续读/写共享存储。对于此方案，Windows 2008群集磁盘驱动程序已针对Windows 2003进行了改进（根据文章），这表明需要支持SCSI-3（PR）命令的存储解决方案。
答案 3 :(得分：0)
我同意高可用性网站上的Omar Al Zabir：
执行：使用存储区域网络（SAN）
原因：性能，可扩展性， 可靠性和可扩展性。 SAN是 最终的存储解决方案。 SAN是 一个运行数百个磁盘的巨型盒子 在里面。它有很多磁盘 控制器，许多数据通道，很多 缓存记忆。你有终极的 RAID配置的灵活性， 在a中添加你喜欢的任意数量的磁盘 RAID，在多个RAID中共享磁盘 配置等。 SAN有 更快的磁盘控制器，更多并行 处理能力和更多磁盘缓存 内存比普通控制器那样 你把它放在服务器里面。所以，你明白了 使用时更好的磁盘吞吐量 SAN通过本地磁盘。你可以增加 并且即时减少音量 您的应用正在运行并使用 体积。 SAN可以自动镜像 磁盘和磁盘故障时，它 自动调出镜子 磁盘并重新配置RAID。
Full article在CodeProject。
因为我个人现在没有个人预算，所以我依靠您帖子中的选项1（ROBOCOPY）。但是我保存的文件并不是唯一的，如果它们因某种原因死亡，可以自动重新创建，因此在我的情况下绝对容错是必要的。
答案 4 :(得分：0)
我认为这取决于您将看到的下载量类型。我将文件存储在SQL Server 2005 Image列中并取得了巨大成功。我们没有看到对这些文件的大量需求，因此在我们的特定情况下，性能确实不是那么大的问题。
将文件存储在数据库中的一个好处是，它使灾难恢复变得轻而易举。管理文件权限也变得更加容易，因为我们可以在数据库上管理它。
Windows Server有一个我不推荐的文件复制服务。我们已经使用了一段时间，它引起了很多麻烦。
答案 5 :(得分：0)
DFS可能是最简单的设置解决方案，虽然根据网络的可靠性，这有时会变得不同步，这需要你打破链接，并重新同步，这是非常痛苦的。
鉴于上述情况，我倾向于使用SQL Server存储解决方案，因为这会降低系统的复杂性，而不是增加它。
进行一些测试，看看性能是否会成为问题。