分布式文件系统选型和预研

Posted by arganzheng | September 24, 2015

背景

候选DFS

  1. MooseFS
  2. FastDFS
  3. TFS

Hi all,

背景

我们目前有接近3.5kw的文件数，总体容量是800GB的样子，平均文件大小是二三十KB的样子。主要是图片、HTML文件等小文件。走CDN之后，QPS大概是二三十的样子。目前我们的静态资源是部署在BPC的私有云平台NFS上。该平台主要是支持大文件，对单机文件数量有比较大的限制（单机100w，我们现在已经调高到了单机300w的样子），因此对机器数目的要求比较高（OP为我们投入了40台机器，目前的使用率已经到达86.5%），跟NFS的同学沟通是目前的机器数最多只能支撑到8kw，建议我们加机器或者定期归档老文件。 我们现在只保留了一个月的新闻，未来的业务规划可能会保留一年的新闻，另外，可能会有UGC方面的业务，对静态资源预计会有几倍的压力增长。所以我们希望能够找到一个分布式文件存储系统，具有足够的稳定性和扩展性，让业务不需要去担心文件存储问题，focus在业务上。

选型

  1. MooseFS
  2. 淘宝的TFS
  3. 百度基础架构部的BOS系统
  4. FastDFS

1、MooseFS

我们一开始就是使用MFS，后来迁移NFS，也搭建了MFS作为backup。

优点

  1. 节省机器：根据我们的使用情况，4台机器（1台master+3台chunckserver）就可以支撑5kw的数据。其中chunckserver可以混部。
  2. 迁移成本小：跟NFS一样，都是兼容POSIX接口，基本不需要改动。只需要数据迁移。
  3. 开源产品，可以根据需要修改。
  4. 我们有过搭建和运维经验。

缺点

  1. 社区版本master是单点，挂了需要手动恢复和切换。
  2. 系统能够容纳的文件数量屈居于master的内存，因为处于性能的考虑，master启动会将所有的metadata load到内存中，128G的内存只能支撑3亿左右的文件数。
  3. 社区不是很活跃，支持力度有限。

2、淘宝的TFS

优点

  1. 使用HA架构和平滑扩容
  2. 支持多种客户端
  3. 支持大小文件存储
  4. 淘宝的大数据、高并发考验

缺点

  1. 开源社区不够活跃，release的开源版本问题还是不少，基本上需要深度掌握，比如偶发core会很蛋疼。如果深度掌握，自己fix那么还好。
  2. 做的假设性条件太多，比较专用的存储场景（比例适合于存储图片等这些大小比较固定的场景），不然会造成空间的浪费，不适合用于通用性的存储。比如公有云，基本上就搞不定。
  3. 运维太复杂，整体体系比较复杂，如果是比较核心的服务，基本上需要投入一定的人力进行维护，因为配套的一些东西需要跟上。（这个问题其他的分布式文件系统也存在，除非不关注高可用和高可靠的问题）
  4. 对于海量数据场景（这里面的海量，是到了日增100TB级别或者以上，以及整体的存储到了数十PB的场景下），支持还不是很好。
  5. 整个系统的一些设计理念，有些历史包袱，开发维护成本也咧高。
  6. 另外了解到：淘宝的内部使用版本和开源版本其实是两套代码来的，很多bug在内部分支修复之后并没有同步到开源版本上。

3、百度基础架构部的BOS系统（Baidu Object Storage Service）

优点

这个跟淘宝的TFS基本是一样的。百度云盘和帖吧都是使用BOS，也是经历过大数据高并发的考验。 还有个好处就是有内部团队运维支持，不存在淘宝TFS开源版本和内部版本不一致的问题。

缺点

  1. 不兼容POSIX接口，迁移成本比较大
  2. 外部团队，虽然是同公司，沟通成本还是不少。

4、FastDFS

觉得BOS应该可以满足我们业务需求就没有继续调研其他的了。

最终基本确定选型BOS系统。已经跟BOS团队的同学沟通了几天，在等待BOS团队的最终回复。根据BOS开发的大概评估：10台左右的机器可以支撑3到4亿的文件存储，这个相对于NFS来说还是比较给力的。

实施

为了屏蔽文件系统的差异，引入一个中间层——FileServer，提供文件的操作服务，主要是文件上传和下载。还有图片处理，如：裁剪，压缩，格式转换，打水印等。

优点

  • 切换底层分布式文件系统对业务透明
  • 图片功能单独作为一个服务，可以方便的线性扩展和负载均衡

缺点

  • 封装成本
  • 如果做成RPC，会多一层复杂性和调用开销

说明

BOS没有目录的概念。但是使用特殊的文件名可以模拟文件夹，访问的时候需要使用绝对路径。出于下面两个目的，还是考虑引入目录的概念：

  1. 现在的文件存储结构就是目录形式，对外的URL也是有目录的概念。
  2. 平坦结构的URL，即${bucket}.${domain}/${fileName}，需要在fileName中携带统计信息以便统计，比如语言，类别，那么对fileName也有要求，而BOS的文件夹其实就是对fileName有特别的要求，只是要求使用’/’而已。其实想想也是不错的。需要注意的是这样子其实文件名是全路径名称的，即/{dir}/…/{fileName}

注意事项

  1. 有很多第三方库还是采用老的文件系统方式读写文件（比如velocity读取模板文件），像这些依赖文件就不能放到BOS系统，只能存放在本地文件中。
  2. 另外，BOS系统的写入文件本质上就是上传文件，数据必须先存在，所以需要先写入文件在本地，再上传文件内容，最后再删除本地临时文件。会麻烦一些，而且性能也会差一些。不过迁移过程有个好处就是相当于业务双写。。方便切换。。

迁移步骤和相应估点

  1. 申请新机器，搭建BOS集群。 – 依赖于外部；估计3d左右
  2. 修改所有的文件读写操作地方，将写入NFS改成写入NFS，上传BOS，删除NFS（后面稳定之后清除，一开始双写）。这里建议封装一个统一的接口层，屏蔽底层的文件系统差异。 – 7d
    1. 封装: 2d
    2. 修改: 5d
  3. 迁移NFS的文件到BOS中，保持文件存储目录结构与NFS一致。– 迁移程序2d，数据迁移完成时间待定（估计一到两周）
  4. 修改nginx: 放在BOS上的文件指向BOS，NFS作为backup；其他的直接root。 – 1d
  5. 观察一段时间，稳定之后就可以不双写了，可以删除NFS，只保留少量不适合放在BOS的文件（比如模板文件，pac文件等）。这里可以考虑直接使用原生的文件系统，然后用NFS挂载。– 1d

大概需要11个人日开发的样子。预计一个多月可以完成整体切换。

架构图如下所示：

现有的静态资源情况：

  • activity: 主要存放运营活动H5页面
  • CN_ips: 就一个spdy.txt文件，不知道干什么用的
  • t7pac: T7 pac文件
  • t5pac: T5 pac文件
  • timgpac: Timg pac文件
  • templates: 新闻模板
  • uploadTemp: 里面有很多jpg文件，不知道干什么的
  • cliponyu: cliponyu静态资源，很多图片
  • guanxing: 观星静态资源目录
  • mbrowser-beback: 貌似是一个H5页面
  • mbrowser-image: 浏览器图片目录
  • mbrowser-news: 浏览器新闻目录
  • mbrowser-video: 视频静态资源
  • mbrowser-life: 本地生活
  • temp: 零时目录，但是里面存放官网和渠道包。。
  • download: 下载目录
  • ecommerce: 电商的静态资源
  • eshop: 电商临时目录
  • face: DuStyle的静态资源
  • launcher: Launcher的静态资源
  • tongji.html: 统计html页面
  • web_resources: JS/CSS等静态文件

YOU MIGHT ALSO LIKE

CATALOG