对于云服务来说，三分靠开发，七分靠运维。云存储究竟难在哪儿?为什
么 HDFS，glusterfs,mogilefs 不能作为云存储的基础设施?本文基于对
七牛云存储首席架构师李道兵带来的《三分开发，七分运维》的精彩分享
的整理，希望大家能从中寻得答案。
我们为什么需要一个公有云?
作为一个创业或者开公司也好，最基础 的要解决几个问题。第一个问题
你的客户是谁，简单的说客户就是有存储需求的人。什么人有存储需求呢?
像一些应用就有很多的图片存储需求，比如说需要把拍的 照片发到网上，
存储需求就很强，有很多做音频、视频的，比如说美拍，它就面临一个很
大的问题，用户的视频要放在哪里?
另外一个很大的需求就是说日志存储，一个网站每天产生很多的日志，
也有很大的价值。但是把它存哪里是一个大问题。
日志和富媒体都还面临着另外一个问题，我需要有很强的运维功底，不
够强的话，维护起来成本比较高。特别是对创业团队来讲，组建一个优秀
的运维团队是一个非常昂贵的事情。
别人去解决这个问题的时候，他们的成本究竟是多少呢?比如说存储图
片，在我们学PHP的时候，就有一些超级简单的解决方案，比如直接上传
到服务器的磁盘里边。
这种情况你的文件会放在磁盘里面，在使用RAID5或者RAID10的情况
下，可以保证在单个磁盘坏了的时候整个数据不丢，是不是这样就可以了
呢?至少还有如下几个问题，第一个问题是宕机，特别是主板损坏或者内存
损坏的情况，在机器修好之前这部分数据就不可访问了，互联网企业宕机
造成的损失越来越大，用这种方案带来的第一个问题是单点故障怎么解决?
这是个很难接受的后果。
第二个问题是IOPS和吞吐量都很有限。IOPS的限制在你的磁盘。一般
存图片和音视频不会使用SSD，如果做RAID5的话你能拿到 200~300的
IOPS，RAID10能达到600左右，但如果你有大量的小图片(比如缩略
图)，这点 IOPS 就无法支撑你的业务了。另外一点是吞吐量，如果整个网
站越做越大的时候，一些音视频的下载很可能把你的机器压跨，特别是在
只配备了千兆网卡的情况下。万兆网卡能好一些，但是对应的成本很高。
最大的问题是容量有限，市面上能买的是4T盘，12块盘加起来是48T，你
做一个 RAID10后是24T。你的存储存满了之后，单机存储方案就有问题
了。存储满了这个方案就完全走不通了。所以说这种方案只适合一些实验
性质的，自己玩一玩的东西还是很适合，如果你去创业，开一个新公司，
真正做一个服务的话，从最开头你就要考虑这个东西存哪里合适，要怎么
存。
glusterfs的问题
回到几年前的话，那时候有一个很漂亮的方案的glusterfs，做的比较
早，大概 2006年就应用的比较多了。他有很多很炫的东西，像可以当一个
普通磁盘来挂载，你可以在上面创建目录，也可以使用任何其他 POSIX
API，所以你以前针对本地文件的所有程序不用做任何修改就可以放到上面
去。第二个来讲无中心的架构，机器数量不受限制。但是实际用下来缺点
也很明显。
第一个问题是无中心的架构有两个缺点是致命的，是所有无中心架构都
无法逃避的缺点，一上来你不会上一个很大的集群，会先上3台或者6台测
试一下，当你的容量不够的时候，就会想到扩容到12台，基于客户端Hash
就会出现问题，之前一三五七放第1组，二四六八放第2组，现在变成一五
放第1组，二六放第2组。剩下的三七要放到第3组，四八要放到第4组。你
有一半的数据需要迁移，这个时候你整个系统就处于不可用的状态。你知
道搬数据特别是通过网络搬数据是一件超级痛苦的事情，大家有空可以算
一下，简简单单搬一个4T的盘透过千兆网搬的话是4万秒，差不多是一天，
这样才是一块盘。如果通过网络搬一台机器12块盘的话，几天就过去了。
这种架构导致你的整个系统是一个固定容量好说，如果你的系统容量不固
定，在你扩容的时候会超级痛苦。
第二个问题这种客户端架构会导致两三台机器结构完全对称，从一个方
面来说比较好维护，我这个数据的这一份知道在哪里，另外也知道在哪
里。但是有一个问题，你第一块磁盘坏了，你修复要多久?在对称盘的情况
下，第一块磁盘修复了，我把这块卸下来，安装一模一样好盘到当前位
置，拷贝出来数据。一块4T要拷16小时，而且你还要考虑到在拷贝的过程
中不要跟你的业务抢带宽。在16个小时之内，你的第二块盘不能坏，有没
有可能运气超级不好的时候，第一块坏了的话，没有修复完成的时候，第
二块又坏掉了，这对你来讲是灾难性的事件。
第二个是它自身的设计有些问题，数据链路非常长，所以小文件性能是
超级差的。比如说几十K级别的文件，在互联网应用里面，特别是针对图片
的一些应用的话，几十K是超级常用的东西。客户上传一些原始图或者缩略
图等等，这些小文件的性能超级差。
第三个是要实现兼容，大概是40多个API，简单的云存储只需实现三到
四个API就可以了。40多个API导致它的整个架构非常复杂。
所以说对于我来讲glusterfs只能适用于一些特殊领域，小规模、容量可
预估的，同时你的程序很难改造到基于云存储的API来实现，比如买的是第
三方提供的程序，这种情况下你用这个是最好的选择。
mogilefs 的问题
互联网企业的话，mogilefs用的比较多，中小网站存一些图片等等的用
得非常广。优点是有中心、扩容和修复更方便。缺点是总条目数受中心限
制，还有就是大文件上传不方便。因为它的中心实际是一个数据库，所以
他的能力就受这个数据库的能力限制。比如说mogilefs几千万条问题不
大，再往上的数量级呢?几亿、十亿，甚至更多的话就有点扛不住了。中国
网民是4亿人，如果每个人都来使用你的应用的话，一百亿的文件是一个可
以很快达到的高度。在这个领域来说，整个数据库会出现问题，会扛不
住。
所以说mogilefs适用于文件数量不太多，几千万水平，总容量PB往下的
规模。访问频率在数据库能扛住，同时不用考虑太多大文件的问题。
Hadoop 的问题
当然说到存储不得不提Hadoop的问题，他的优点是超强的伸缩性，不
用任何改动就可以上到1000台规模，阿里在5000台做过一些实验。只不过
他们现在迁移到自己的系统，这个就慢慢地放弃掉了。
Hadoop拿来存文件有些什么问题呢?本身设计的目标不是做文件存储
的。它是按照离线数据分析业务来设计的，可用性就低了。你在上面不停
地取文件，大概有很小的一个概率，大概千分之一到千分之五的情况下是
取不到的。对离线分析业务来讲不是什么问题，取不到等三四秒重新做一
遍就可以了。但是对在线应用来讲的话，图刷不出来了，是一个红叉，或
者说音视频播放不了，这都是很大的问题。
大概是两个方面造成的，一个是Java语言本身的问题，另一个是
hadoop数据在平衡时数据访问会超时。
第二个是小文件支持不好，Hadoop的块大小是64MB，你在上面直接存
几十K的文件，那么它的NameNode内存会被用满，可能你用十台的话，
就已经到极限了。
混搭模型
就是说你做存储的话，很多小的公司自己做存储是基于这些。还有一些
其他的，比如说Hbase、Hadoop+HBase等等这些，简单思路就是把小文
件拼成一个大文件。
