负载平衡 ASP.NET 应用程序的最佳文件存储解决方案是什么？
我们有一个 ASP.NET 文件传输应用程序（内部用户上传，外部用户下载），我想知道分发文件的最佳方法是什么，这样我们就不会因为仅将应用程序的文件存储在一个应用程序上而出现单点故障服务器。 我们将应用程序的负载分布在多个前端 Web 服务器上，这意味着对于文件存储，我们不能简单地将文件存储在 Web 服务器本地。
我们当前的设置使我们指向主数据库/文件服务器上的共享。 一整天，我们都会将主服务器上的共享内容自动复制到故障转移服务器上。 此场景确保我们拥有一台具有相当最新数据的辅助计算机，但我们希望能够从主计算机故障转移到故障转移并再次返回，而不会在前端应用程序中丢失数据或出现错误。 现在这是一个相当手动的过程。
可能的解决方案包括：
- Robocopy。 很简单，但它不容易让您在没有多个作业始终运行（来回复制数据）的情况下进行故障转移和恢复
- 将文件存储在 SQL Server 2005 中的 BLOB 中。我认为这可能是一个性能问题，尤其是对于大文件。
- 使用 SQL Server 2008 中的 FILESTREAM 类型。 我们镜像我们的数据库，所以这看起来很有希望。 有人对此有经验吗？
- Microsoft 的分布式文件系统。 从我读到的内容来看，这似乎有点矫枉过正，因为我们只有 2 台服务器需要管理。
那么您通常如何解决这个问题以及最好的解决方案是什么？
We have an ASP.NET file delivery app (internal users upload, external users download) and I'm wondering what the best approach is for distributing files so we don't have a single point of failure by only storing the app's files on one server. We distribute the app's load across multiple front end web servers, meaning for file storage we can't simply store a file locally on the web server.
Our current setup has us pointing at a share on a primary database/file server. Throughout the day we robocopy the contents of the share on the primary server over to the failover. This scneario ensures we have a secondary machine with fairly current data on it but we want to get to the point where we can failover from the primary to the failover and back again without data loss or errors in the front end app. Right now it's a fairly manual process.
Possible solutions include:
- Robocopy. Simple, but it doesn't easily allow you to fail over and back again without multiple jobs running all the time (copying data back and forth)
- Store the file in a BLOB in SQL Server 2005. I think this could be a performance issue, especially with large files.
- Use the FILESTREAM type in SQL Server 2008. We mirror our database so this would seem to be promising. Anyone have any experience with this?
- Microsoft's Distributed File System. Seems like overkill from what I've read since we only have 2 servers to manage.
So how do you normally solve this problem and what is the best solution?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
DFS 可能是最容易设置的解决方案，尽管根据网络的可靠性，有时可能会变得不同步，这需要您断开链接并重新同步，说实话，这是相当痛苦的。
鉴于上述情况，我倾向于使用 SQL Server 存储解决方案，因为这会降低而不是增加系统的复杂性。
首先进行一些测试，看看性能是否会成为问题。
DFS is probably the easiest solution to setup, although depending on the reliability of your network this can become un-synchronized at times, which requires you to break the link, and re-sync, which is quite painful to be honest.
Given the above, I would be inclined to use a SQL Server storage solution, as this reduces the complexity of your system, rather then increases it.
Do some tests to see if performance will be an issue first.
考虑像 AWS S3 这样的云解决方案。 它按使用量付费，可扩展且具有高可用性。
Consider a cloud solution like AWS S3. It's pay for what you use, scalable and has high availability.
您需要一个带有 RAID 的 SAN。 他们制造这些机器是为了保证正常运行时间。
这确实是一个IT问题...
You need a SAN with RAID. They build these machines for uptime.
This is really an IT question...
当有多种不同的应用程序类型通过中央数据库共享信息时，将文件内容直接存储到数据库中通常是一个好主意。 但您的系统设计似乎只有一种类型 - Web 应用程序。 如果只是 Web 服务器需要访问文件，并且没有其他应用程序与数据库交互，那么通常来说，存储在文件系统而不是数据库中仍然是更好的方法。 当然，这实际上取决于您系统的复杂要求。
如果您不认为 DFS 是一种可行的方法，您可能希望考虑 文件服务器层的故障转移集群，您的文件存储在主动和被动之间连接的外部共享存储（不是昂贵的 SAN，我认为这对于您的情况来说有点过分，因为 DFS 已经超出了您的能力范围）文件服务器。 如果主动文件服务器出现故障，被动文件服务器可能会接管并继续读取/写入共享存储。 对于这种情况（根据文章），Windows 2008 群集磁盘驱动程序比 Windows 2003 进行了改进，这表明需要支持 SCSI-3 (PR) 命令的存储解决方案。
When there are a variety of different application types sharing information via the medium of a central database, storing file content directly into the database would generally be a good idea. But it seems you only have one type in your system design - a web application. If it is just the web servers that ever need to access the files, and no other application interfacing with the database, storage in the file system rather than the database is still a better approach in general. Of course it really depends on the intricate requirements of your system.
If you do not perceive DFS as a viable approach, you may wish to consider Failover clustering of your file server tier, whereby your files are stored in an external shared storage (not an expensive SAN, which I believe is overkill for your case since DFS is already out of your reach) connected between Active and Passive file servers. If the active file server goes down, the passive may take over and continue read/writes to the shared storage. Windows 2008 clustering disk driver has been improved over Windows 2003 for this scenario (as per article), which indicates the requirement of a storage solution supporting SCSI-3 (PR) commands.
我同意 Omar Al Zabir 在高可用性网站上：
完整文章位于 CodeProject。
因为我个人现在没有 SAN 的预算，所以我依赖您帖子中的选项 1 (ROBOCOPY)。 但我保存的文件不是唯一的，如果它们因某种原因死亡，可以自动重新创建，因此在我的情况下绝对的容错是必要的。
I agree with Omar Al Zabir on high availability web sites:
Full article is at CodeProject.
Because I don't personally have the budget for a SAN right now, I rely on option 1 (ROBOCOPY) from your post. But the files that I'm saving are not unique and can be recreated automatically if they die for some reason so absolute fault-tolerance is necessary in my case.
我想这取决于您将看到的下载量的类型。 我将文件存储在 SQL Server 2005 Image 列中并取得了巨大成功。 我们没有看到对这些文件的大量需求，因此在我们的特定情况下性能实际上并不是那么大的问题。
将文件存储在数据库中的好处之一是它使灾难恢复变得轻而易举。 管理文件权限也变得更加容易，因为我们可以在数据库上进行管理。
Windows Server 有一个我不推荐的文件复制服务。 我们已经使用它有一段时间了，它引起了很多头痛。
I suppose it depends on the type of download volume that you would be seeing. I am storing files in a SQL Server 2005 Image column with great success. We don't see heavy demand for these files, so performance is really not that big of an issue in our particular situation.
One of the benefits of storing the files in the database is that it makes disaster recovery a breeze. It also becomes much easier to manage file permissions as we can manage that on the database.
Windows Server has a File Replication Service that I would not recommend. We have used that for some time and it has caused alot of headaches.