2011-09-08 29 views
6

这个问题从我昨天从我的问题中学到的标题为using git to distribute nightly builds继续。使用bittorrent协议每晚分发和CI编译

在上述问题的答案中很明显,git不适合我的需要,并被鼓励使用BitTorrent重新检查。


短版

需要夜间分发构建每天早上人70+,想用混帐BitTorrent的进行负载平衡的转移。

龙版

NB。如果您已阅读我的previous question,则可以跳过以下段落。

每天早上我们需要将我们每晚的作品分发给70多人(艺术家,测试人员,程序员,制作人员等)的工作室。到目前为止,我们已经将构建版本复制到服务器,并编写了一个同步程序来获取它(使用下面的Robocopy);即使设置了镜像,传输速度也会慢得令人无法接受,因为在高峰时间同步需要长达一小时或更长时间(非高峰时间大约为15分钟),这指出硬件I/O瓶颈以及可能的网络带宽。

我知道什么到目前为止

我迄今发现:

  • 我发现有关BitTorrent protocol这是一个有趣的阅读维基百科的优秀条目(我先前只知道种子如何工作的基础知识)。在客户端 - 服务器握手之后发生的BITFIELD交换中也发现这个StackOverflow answer

  • 我还发现MonoTorrent C# LibraryGitHub Source),我可以用它来编写我们自己的跟踪器和客户端。我们不能使用现成的追踪器或客户端(例如uTorrent)。

问题

在我最初的设计,我有我们的编译系统创建的.torrent文件加入它来跟踪。我会超级种子洪流使用我们现有的构建镜像。

使用这种设计,我需要为每个新版本创建一个新的.torrent文件吗?换句话说,是否有可能创建一个“滚动”。torrent如果构建的内容只改变了20%,那么需要下载的所有内容到获取最新的

......其实。在写上面的问题,我认为我会需要创建新的文件然而我将能够下载到用户计算机上的相同位置和散列会自动确定什么,我已经有了。它是否正确?

响应于评论

  1. 对于完全新鲜同步整个构建(包括:游戏,源代码,本地化数据,和光盘图像为PS3和X360)〜37000页的文件和在未来只需 50GB以下。随着生产的继续,这将会增加。此同步需要29分钟才能完成,此时只有2个其他同步正在发生,如果您认为早上9点我们会有50多个人想要获得最新时间,那么这个同步会出现低峰。

  2. 我们已经调查了与IT部门的磁盘I/O和网络带宽;结论是网络存储正在饱和。我们也将统计数据记录到同步数据库,这些记录甚至显示少数用户正在获得不可接受的传输速率。

  3. 关于未使用过的,现成的客户,它具有像的uTorrent安装在考虑到其他项目可以容易地使用程序下载的用户机应用程序中的法律问题。我们也希望有一个自定义的工作流程来确定你想要获得哪个版本(例如,只有PS3或X360取决于你的桌面上有什么DEVKIT)并且有可用的新版本的通知等。使用MonoTorrent创建客户端不是部分我很关心。

+1

你分发的文件的大小是多少?你有没有试过一个很好的压缩?您也可以使用二进制比较工具对付以前的版本,该补丁对于几乎每个人都是足够的(其他人将下载完整的软件包)。 – Guillaume

+1

你确定改变协议/工具会解决问题吗?你有没有对你的网络上要发布的内容进行真实的数学分析,比如你的硬件,网络带宽等等。对于这个问题,你是否检查过文件系统系统缓存(cf:http://blogs.technet。 COM/b/askperf /存档/ 2007/05/08 /慢大文件拷贝issues.aspx)? –

+0

我真的不明白为什么你不能使用现成的客户端,你是否也在运行室内网页浏览器和文字处理器? – grapefrukt

回答

6

对于是否需要创建新的.torrent,问题的答案是:

但是,根据您的数据的布局一点,你可以做一些简单的半增量更新。

如果您发布的数据是个别文件的大量集合,每个构建的某些文件可能已更改,您可以简单地创建一个新的.torrent文件并让所有客户端将其下载到与旧文件相同的位置像你建议的那样)。客户端首先会检查磁盘上已存在的文件,更新已更改的文件并下载新文件。主要缺点是删除的文件实际上不会在客户端被删除。

如果你正在写反正你自己的客户端,在文件系统,不在的.torrent文件中删除的文件是一个相当简单的步骤,可以单独完成。

如果你发布的图像文件,自认为保持不变跨版本可能已移动了位,从而产生不同的片哈希这是行不通的。

我不一定会推荐使用超级种子。根据您使用的超级播种实施的严格程度,它实际上可能会损害传输速率。请记住超级播种的目的是尽量减少种子发送的字节数,而不是最大化传输速率。如果你所有的客户都表现得很好(比如先使用稀有),那么这件作品的发行也不应该成为问题。

另外,要创建一个洪流并对一个50Gb的洪流进行散列检查,会给驱动器带来很多负担,您可能需要对您使用的bittorrent实现进行基准测试,以确保其性能足够。在50 GiB时,不同实现之间的差异可能很大。

0

只是想把另一个选项加入组合中,你考虑过BITS吗?不是自己使用它,而是从阅读文档支持分布式peer caching model,这听起来像它会实现你想要的。

不足之处在于它是一种后台服务,所以它会放弃网络带宽以支持用户启动的活动 - 对用户来说很好,但如果您急需一台机器上的数据,可能不是您想要的。

不过,这是另一种选择。

+0

感谢您的建议。我们看了一下BITS(后台智能传输服务),并可能将其用作短期解决方案。 – Dennis

+1

BITS很适合作为后台下载程序**但是**根据文档:_“BITS 3.0:从Windows 7开始,不建议使用BITS 3.0对等缓存模型如果安装了BITS 4.0,则BITS 3.0对等缓存模型为更多信息,请参见Peer Caching。“_ –

+0

@Hightechrider:感谢有关BITS缓存模型的其他信息。 – Dennis

3

只想添加,请过目一些非BitTorrent的建议:

  • 如果每晚构建之间的变化并不显著,您可以使用rsync,以减少网络流量,并降低花时间复制构建。在以前的公司,我们使用rsync将版本提交给我们的发布者,因为我们发现我们的光盘映像没有改变很多构建。

  • 您是否考虑过简单地交错复制操作,以便客户不会减慢彼此的传输速度?当我们做里程碑分支时,我们一直在内部使用一个简单的Python脚本:脚本进入休眠状态,直到指定范围内的随机时间,唤醒,下载并检出所需的存储库并运行构建。用户在离开当天的工作时运行脚本,当他们返回时,他们有一切准备好的新副本。

2

您可以使用BitTorrent sync这是一种替代dropbox但在云中没有服务器的方式。它允许您同步任意数量的任意大小的文件夹和文件。与几个人,它使用Torrent协议相同的算法。您可以创建只读文件夹并与其他人共享密钥。此方法不需要为每个构建创建一个新的torrent文件。

+0

我刚才刚刚阅读过'\ .'上的同步以及在过去6个月中如何传输1PB的数据。但是,我并没有立即想到我可以用于这个目的。谢谢! – Dennis