引言

当服务器多时，为了管理方便和提升效率，就会用到自动化管理工具（如Ansible）来自动部署和批量分发文件。

场景描述：目前有50+台服务器，已部署Ansible用于自动化部署和批量分发文件。批量分发文件时，一般把文件传到 Ansible 所在的服务器并通过 copy或者synchronize 模块传输，文件小于100M时，分发正常。当传输大文件时（100M+），受单节点及其带宽的影响，整个分发过程变得非常缓慢，甚至出现Ansible卡死。

使用 Ansible 来分发小文件速度很快，但对于大文件，文件分发就是一个很大的问题。在使用单一分布点和固定出口带宽的情况下，经常存在带宽拥堵、耗费时间长的问题。

对于大文件分发，首先想到的是 BitTorrent ，利用 P2P 协议实现快速分发，节省带宽，提高效率。

P2P软件介绍

为了解决上面的问题，这里我们使用 Murder 。

Murder 是 Twitter 的开源项目，很适合大文件分发。（该项目还能用，但官方已经不再继续维护）

项目介绍中有这么一段话：

根据 Murder 开发者的博客，可以知道这个项目的来龙去脉：

Twitter 在早期便依赖 Capistrano 来进行应用程序的部署，每当有新版本需要发布时，Capistrano 会根据预设好的各种设置和流程到 Twitter 所有的服务器上进行更新的操作。
在过去服务器还不多的情況下一切都很美好，但随着 Twitter 服务器数量的增长，到了几百台服务器时，事情已经不再像过去一样美好，甚至到后来拥有数千台服务器时，更新的操作会耗费 40 分钟。
Twitter 针对这个问题，认为问题的关键在于：使用集中式的系统，也就是所有的服务器要轮流排队到同一台版本控制系统上进行代码更新。

Twitter 最初的想法是将版本控制系统也做出分散式的架构，服务器的代码更新就可以分散到不同的机器来压缩部署时间，但事实上版本控制系统即使分散在多台服务器上，这些服务器要更新文件也同样需要时间。
因此 Twitter 发现或许需要一个完全去中心化、最好是像 BitTorrent 这样的，利用 P2P 的特点让所有的节点都可以协助进行程序代码的更新。

从结果来看，在采用了 BitTorrent 的方式来更新代码，部署的时间从 40 分钟大幅减少到只要 12 秒！实在是非常惊人的改善，数千台服务器的代码更新居然只要短短 12 秒就能完成。

集中式架构和Murder架构对比：

部署Murder

Murder 组件介绍

Murder 是基于 BitTornado 来实现的。有以下几个主要组件：

• torrent tracker ：tracker 使用  运行，tracker 实际上是运行中一台服务器上的单个服务，其他任何成员都要依赖它。Murder为了保持简单，并没有实现tracker-less distribution（DHT）功能。tracker 实际上是个迷你的 httpd 服务，存放着BitTorrent客户端需要更新状态的路径。
• seeder ：sender 是存放要分发到其他主机的文件的服务器。这些文件存放在 seeder 的一个目录中，Murder 会将这个目录打包成 tgz 格式并创建一个  文件（非常小的文件，包含有关这个tgz文件的基本hash信息）。这个  文件让各个 peer 节点知道他们下载的是什么文件。同时，tracker 会保持跟踪有哪些  文件正在被分发。一旦 Murder 开始传输文件，seeder 服务器将是各个 peer 节点获取种子的地方。
• peers ：peer 是成百上千需要接收文件的服务器，并且它们之间可以相互传输文件（下载、上传）。一旦一个peer节点下载完整个 tgz 文件，还将继续 seeding 一段时间，防止蜜罐效应。

准备工作

在 tracker 服务器下载并安装 Murder，写成脚本运行：

配置好 ansible 服务，连通各个 peer 节点。

通过 ansible 将tracker服务器下的  分发到各个 peer 节点的家目录下，并解压安装 Murder ：

各个节点ip和环境说明：

• tracker : 192.168.1.100
• seeder : 192.168.1.100
• peers : 192.168.1.101-111
• 服务器都在同一个机房
• 都是 CentOS 6.5 系统

启动 tracker 服务

在 Tracker 服务器，启动 tracker 服务：

检查端口：

实时查看日志输出：

配置防火墙（如果防火墙是关闭的，则不用此操作）：

 实际上是调用  这个文件。  有很多参数，如果需要添加参数，可以修改 。

几个重要参数：

• port ：tracker 监听的端口，默认 8998
• dfile ：存储近期下载信息的文件
• logfile ：tracker 日志文件，默认是标准输出

在 seeder 服务器上准备要分发的文件并创建种子

这里将 seeder 和 tracker 服务 放在同一台服务器。

准备分发文件，并放在  目录下。

生成种子文件的脚本：

分发种子文件给所有的peer节点

利用 ansible 分发seeder服务器上的种子文件给所有的 peer 节点

启动 seeder 服务

启动 seeder 服务的脚本：

要确保 seeder 服务在启动状态，否则 peer 节点下载时连接不到。

在各个peer节点执行下载任务

编写下载脚本  ：

利用ansible远程操控，在每个peer节点都执行下载脚本。使用ansible的 script 模块，在本地写一个脚本，然后在远程服务器执行：

下载速度分析

Murder 默认是服务器都存于一个数据中心的彼此相互信任的内 ，并且每台服务器都是关闭防火墙的。

Murder 封装的是 BitTornado，在  代码中默认是启动一个 范围的随机端口，每个 peer 在下载的同时向其他 peer 提供下载服务也是通过这个随机端口。

对于端口的配置，把防火墙关了当然好，当然为了安全，还是开放端口更好。然而开放这个大的端口范围，肯定是不行的，这里选择开放  500个端口，只允许内 IP访问。

在各个 peer 节点中配置：

并且在  中修改代码的端口范围：

这一步最好在把Murder代码分发到各个peer节点前做，如果已经做了，只能重新分发覆盖了。

分发测试的机器有11台，都是内 IP，千兆路由器，但防火墙开启，测试文件有 560 M 大小。

第一次分发：没有配好防火墙，用时 5m 分发完成。
第二次分发：配好了防火墙，用时 2m30s 分发完成。
第三次分发：不用Murder，用 ansible 直接分发，用时 36s 分发完成。

这里测试的服务器还是太少，服务器越多时，P2P方式分发文件速度越快。服务器不超过50+时，还是用 ansible 直接分发更快。

文件都下载完后，关闭 seeder 服务器进程

kill 掉 seeder 的进程PID，避免它一直做种子和提升安全性。