云存储： 三分开发，七分运维

1. 云存储：三分开发，七
分运维
李道兵 <lidaobing@gmail.com>
七⽜牛云存储
2014-11 北京

2. 七⽜牛为什么要做云存储？
• 客户是谁？
• 有存储需求的⼈人（典型情况: 图⽚片，⾳音频，视频应
⽤用，⽇日志存储和分析）
• 价值如何体现？
• 他们⾃自⼰己搞定这个事情的成本是多少？
• 前景如何？
• 世界上的新增数据以每年66%的速度增⻓长，。。。

3. 我们为什么需要⼀一个公
有云？
• 我把数据放在磁盘⾥里，磁盘做RAID5 是不是就可以
了？
• 单点故障，如果机器损坏或者需要停机，这些数据
就下线了
• IOPS和吞吐量都很有限
• 容量有限，放满了这个⽅方案就不合适了
• 听说 glusterfs 不错，是否可以解决这个问题

4. glusterfs 的问题
• 优点
• POSIX兼容，很多程序不⽤用修改就可以直接⽤用
• ⽆无中⼼心的架构，机器数量不受限制
• 缺点
• ⽆无中⼼心的架构天⽣生的两个缺点: a. 扩容时rehash导致⼤大量数据迁移 b. 对称
盘的形式导致修复速度太慢
• 数据链路过⻓长，所以⼩小⽂文件性能超差
• 实现的API过多，导致实现复杂度很⾼高
• 适⽤用领域: ⼩小规模集群，容量可预估，没有⼩小⽂文件，程序很难改造成⽤用 API 来
访问存储

5. mogilefs 的问题
• 优点
• 有中⼼心，扩容和修复更⽅方便
• 缺点
• 有中⼼心的缺点:
• 总条⺫⽬目数受中⼼心限制
• 读写速度受中⼼心限制
• ⼤大⽂文件上传不⽅方便
• 适⽤用领域
• 中⼩小型⺴⽹网站，⽂文件数量不超过⼏几千万，1PB左右的规模，访问频率不超过⼏几千
QPS，不⽤用考虑⼤大⽂文件上传的问题。

6. Hadoop 的问题
• 优点
• 超强的伸缩性，1000台规模⽆无压⼒力，5000台阿⾥里也有⼀一些实践
• 缺点
• Hadoop 是按照离线数据分析服务来设计的
• 可⽤用性低: Java语⾔言本⾝身的问题，Hadoop 数据平衡时数据访问超
时
• ⼩小⽂文件⽀支持不好，hadoop 的数据块太⼤大
• 适⽤用领域:
• 离线数据分析：各类⽇日志分析，数据报表类的业务

7. 混搭模型
• HBase
• Hadoop+HBase/MySQL
• RawDisk+MySQL
• …
• 简单来说，做⼀一个⽀支持 1PB 的云存储已经不是什么
难事了，剩下的⼤大问题只有⼀一个: 运维

8. 你有⾜足够强的运维么？
• 为什么需要运维
• 机器坏，磁盘坏
• 磁盘满，⺴⽹网络满，磁盘过载，内存不⾜足
• ⺴⽹网络不稳，交换机死机，。。。
• 安全更新
• 为什么哪些软件不把这些全部做到业务逻辑⾥里边去
• 有些很难做（⽐比如⺴⽹网络，交换机，磁盘满，安全更新)
• 防⽌止系统过敏（⽐比如上次亚⻢马逊机房事故就是⼀一次过敏）
• 研发和稳定期很⻓长
• 不想⼤大幅度增加架构的复杂度

9. 你需要更多基于云存储
的服务
• 图⽚片：缩放，⽔水印，原图保护
• ⾳音视频：转码，切⽚片，合成，快速预览
• 你的⾃自定义需求: 美颜相机，⼈人脸识别，数据统计
• ⽽而这些需求在跟私有云整合时开发⼯工作量很⼤大，⽽而对
于很多云存储这些功能都是现成的

10. 七⽜牛为什么要做云存储？
• 客户+价值+前景 // 公司的⽴立⾝身之本
• 有技术⻔门槛 // 不会变成红海
• 很酷 // ⼤大家干得很开⼼心
• 创业加速器 // 看到⼀一堆新公司在⾃自⼰己的平台成⻓长起
来很开⼼心

11. 单机房100PB的挑战
• 4000台存储机，不考虑冗余每台要承担 25TB 的容
量
• 200KB的⽂文件平均⼤大⼩小情况下，如何去⽀支持 5000亿
条元数据
• 元数据集群如何去⽀支持1Mqps 的请求频率
• 除了这些还有...

12. 单机房100PB的挑战
• 架构也许不是那么难
• 保持每个组件都是⾼高可⽤用，可伸缩的
• 保持每个远程调⽤用都是可重⼊入的
• ⺴⽹网络传输需要校验
• 。。。
• 难得是规模⼤大了之后的⼀一个问题
• 墨菲定律：凡是可能发⽣生的，就⼀一定会发⽣生

13. 单机房100PB的挑战
• 墨菲定律的诅咒
• 多磁盘故障
• 交换机故障
• ⼈人为失误

14. 单机房100PB的挑战
• 我们能做什么？
• 多预案，并且喜欢处理流程
• 多演习，让事故处理常态化
• 常规事故处理⼀一键化，⾃自动化

15. Summary
• ⾃自建云存储的缺点
• 运维成本⾼高，相⽐比购买云服务，并不划算
• 常规解决⽅方案存在适⽤用领域狭窄的问题，不够通⽤用
• 七⽜牛云存储的优点
• 运维外包，成本更低，安全性可⽤用性更好
• 更多的扩展功能

16. Thanks for your
attention