返回 登录
7

告别AWS:Dropbox自建软硬件系统,转移500PB数据

阅读5207

图片描述

Dropbox曾经是较早跻身独角兽俱乐部的AWS明星用户,而现在他们却跳下大船,走上了自建数据中心的道路。原因主要还是成本。Dropbox的工程副总裁Aditya Agarwal表示,云计算公司也是要赚钱的,规模大了以后自建还是可以节省大量资金。也难怪,Dropbox本身主营业务就是S3之上比较薄的一层,如果不自己搞,面对平台的竞争(Amazon、微软和Google都有类似的云盘服务),毫无优势啊。

据Wired网站的报道,Dropbox的整个迁移过程长达数年(文章里说的是2年半,但从Magic Pocket从2013年就开始开发,以及Hacker News评论里前员工指出的,肯定不止),已经在近期完成。其中主要工作包括:

  • 自行开发类似AWS S3的文件存储系统Magic Pocket,由James Cowling团队负责。原来的版本是2013年开始,用Go针对普通硬件编写的。然后在自己的数据中心进行测试,看是否能可靠支撑AWS中20%的数据180天,一旦发现bug,就重新计时。后来为了适应自建硬件,而且原系统内存占用较大,Jamie Turner又改用Rust重写了其中的两个大组件(OSD - Object Storage Device和volume manager)。这里更详细地讨论了改用Rust的原因:堆的尺寸,节省CPU时间等等,当然也有问题,Dropbox整体基础设施团队都在用Go,所以很多库都要再写,而Rust的许多特性还不足,编译时间也太慢。
  • 自行设计了名为Diskotech的机器,每台可以存储1PB数据,由曾在Twitter和Dell工作的Rami Aljamal团队负责。Diskotech每个机器18”×6”×42”(英寸),放在深度1.5倍的标准4U机柜里,硬盘是10T和14T的host-managed SMR。(参考HN上的讨论。)
  • 机房施工和安装,1天40~50个机架,每机架8台机器。
  • 数据迁移,每天4PB。峰值可以达到0.5TB/s。(参考这里。)

其他技术细节还包括:
- 使用了Reed-Solomon编码,但为降低重建成本而做了优化。类似于Local Reconstruction Codes。
- 网络IO方面,在mio之上自行开发了基于futures的框架(受Finagle启发)。所有I/O是异步的,但应用任务经常在线程池(尽可能控制得较小)里完成。

James Cowling在HN讨论里说明了整个项目的成效:

性能提升3~5倍。成本节省巨大,但具体不能透露。稳定性方面,S3和Magic Pocket都表现不错。总原始存储量是EB级别的。

Dropbox的官方博客说,“数据持续性达到99.9999999999%以上,可用性超过99.99%。”

Dropbox的5PB数量级很大了,但也只占AWS的百分之几;而且Dropbox很小心地一再强调,仍然与Amazon在合作,尤其是欧洲,因为用户增长很快,还将继续使用AWS。

这种告别云会成为一种趋势吗?我的判断是否定的,Dropbox的案例比较特殊(主要业务就是存储,竞争激烈,利润空间有限)。而且,能招到这一大规模项目所需的工程人员(很多来自Facebook、Google和Twitter等公司,已经有过大规模开发和运营的经验),绝非易事。

何况,之前虽然有Facebook和Twitter这样的成功案例,但也有前车之鉴:Zynga在轰轰烈烈自建云之后不久,公司业务萎缩,大量硬件成了负担……

评论