目前我们正在使用阿斯佩拉。我们拥有的许可证仅涵盖每个连接 10 兆比特的吞吐量。我们正在考虑从 Aspera 迁移，因为他们的许可成本太高，无法让我们达到 100 兆比特。我一直在寻找，但真的找不到任何替代方案。现在我们每天传输大约 500GB 的数据。我更喜欢 FOSS 阵营的产品，但我并不反对购买基于 Windows 的产品。
为您提供一些有关我们的硬件配置的背景信息。
(2) BL495c 刀片服务器 - 2x 6 核 Opterons，128GB RAM，存储全部在 HP MSA2300 FC 阵列上，总共约 10TB 数据。一切都在 Hyper-V Server 2008r2 上运行。
因此，考虑到所有这些，真正的问题是：
您使用什么软件/方法为客户提供高速文件上传/下载服务？
编辑：我主要与生活在 Windows 世界中的非技术终端用户打交道。因此，我希望使用基于浏览器且具有相当简单的用户前端的东西。后端可以尽可能地技术化。我认为我唯一真正的要求是大约 100 兆位文件传输的性能能力、用户配额以及可能的连接限制。
答案1
您是否考虑过其他商业加速文件传输解决方案？
看看 FileCatalyst www.filecatalyst.com，它将以更实惠的价格为您提供相同的速度优势。
您还可以从商业角度看待 Signiant。
在开源方面也有一些选择。UDT、Tsunami、GridFTP 都是可行的选择。另请查看通用FTP也是。我认为这些解决方案的问题在于，你面对的是非技术最终用户。也许通过编写一些脚本并在后台运行其中一个产品，你就可以创建一个可行的解决方案。
在我的博客上，我对所有开源文件传输产品进行了比较，并试图确定哪一个产品在某些情况下效果最好（例如：高带宽、高延迟场景等）
以下是博客文章的链接：http://www.filecatalyst.com/open-source-fast-file-transfers
约翰
笔记：该用户是 FileCatalyst 的员工。
答案2
我们使用 SFTP/SCP 或 rsync-over-SSH，但这取决于客户端是否具有相关的客户端/服务器软件。
它以我们链接允许的最快速度运行，使用 rsync 中断的传输可以重新启动，并且一切都可以很好地编写脚本（假设您了解 bash/等效脚本和相关工具），因此可以完全自动化。除非您本地有 100Mbit 管道，否则您需要在某处租用服务器来托管文件，而不是将它们直接从您传输到客户端，但除非您需要重要的 SLA（当然，如果信息敏感，请记住使用加密文件系统和其他此类预防措施），否则这并不昂贵。
不过，这有点像 DIY 解决方案。如果您正在寻找一种能够以更友好的界面呈现给客户的东西（例如类似于 Dropbox 的东西），那么您需要在问题中添加一些关于您正在寻找什么类型的详细信息，以便获得相关的答案。请记住，我们大多数人不会使用 Aspera，因此不会熟悉它，即使那些使用它的人也不会知道您认为哪些功能特别有用（哪些功能与您无关），如果您不列出它们的话。
编辑：
此工具最近在 HN 上（这里)，如果您确实有一个大外发连接，这似乎值得您研究一下。显然，您必须考虑安全方面的问题，例如通过某种方式将您的客户彼此分开（因为它似乎旨在同步不同位置之间的个人文件，而不是与客户共享）。警告：我还没有亲自尝试过。
答案3
如果您的数据集接近 PB 大小，并且您的管道很宽但 RTT 较高，则可以使用 HPC 中的某些东西：GridFTP - 并行 TCP 流，可以分布在多个服务器上。对于您的应用程序来说可能有点过头了，但它不会比 GridFTP 更快。根据您的安全策略，它可能需要完整的 X509 PKI。
答案4
就像约翰提到的，filecatalyst 是一个选项。如果我错了，请纠正我，但从我的阅读来看，我认为 filecatalyst 缺乏对带宽消耗的控制。它将消耗所有可用带宽。但是，file catalyst 提供了将其安排在“非高峰期”的能力，作为带宽管理的替代方案。
其他解决方案是开源 UDT 或 Tsunami，filecatalyst 就是基于其构建的。
马丁