对于云服务来说，三分靠开发，七分靠运维。云存储究竟难在哪儿?为什么 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等等这些，简单思路就是把小文件拼成一个大文件。
#p#
你有足够强的运维么?
前面提到这些存储的局限性，其实更重要的问题是你怎么做好运维的工作，为什么要运维?一个软件就可以了吗?你的容量越大你需要解决的问题就很多。你的机器会挂，磁盘会满，网络满，内存不足。这个还跟你简单的应用层不一样，应用层的服务遇到问题很简单把机器下线，把IP从nginx去掉，反向代理不到这台机器来。如果应用层做大再买机器就可以了。数据库层面压力过大怎么办?分库、分表以及机器本身的提升。用更好的磁盘、CPU来提升单台数据的能力，这就是我们常规的应用层和数据库的伸缩办法。
但是在存储层就会面临运维压力会非常大，磁盘从你简单的几块到达几千块的时候，简单存1PB的数据，数据要存3份，3个PB，数据盘按填充率75%计算，就需要一千块4T磁盘。什么意思呢?考虑到磁盘寿命为3年多，那么平均每一天就有一块磁盘会坏掉，这是你面新的问题。机器会坏，磁盘会坏，同时又热点请求，磁盘满、网络满，磁盘过满内存不足。体系大到这个程度的时候，你还有大量的交换机，你还要考虑交换机坏死的情况，网络上面的故障也会出来。网线也会出事，可能会有坏掉，接口不好等等都会变成你的需求。机器多了还有一个额外的问题，如果出现安全更新，机器少的时候你可以手动来做。但是数量达到一百台的时候就做不了，你就需要安全更新的运维方案。
一个想法，类似于我们去买EMC存储一样，你给我一个简单的接口，卖给我一个盒子，然后你帮我把这些情况都解决好，不是说不可以，但是卖的很贵。但是有贵的道理，有些事情确实很难做，要不然所有东西有很高程度的冗余，你自己把细节测试的更全面，做的更好。
第二个来讲你还得防止系统过敏，这种事情不是一个罕见的现象了。之前amazon东部机房有大面积宕机，原因是什么呢?是一些小问题，小问题修复起来造成了更大的问题。拿人来比喻就是是过敏，可能是一个小问题，但是由于它的一些修复机制放大了这个问题，***导致整个网络堵死，又触发了很多磁盘备份的工作，导致压力过大，***整个机房的机器全部宕掉。
如果把所有的意外防范都做在程序里边，也会导致软件研发和周期非常长，架构复杂度也大规模增加了。
这些问题带来的是你在市面上根本找不到一个云存储软件是非常***的，能够大规模降低运维成本。同时你也很难找到足够多足够好的运维解决这个问题。
你需要更多基于云存储的服务
另外一个需求是基于存储的计算。比如说一个简单做图片的，图片有iPhone、安卓的，不同客户端都有不同的分辨率需求。为了节约流量，客户端希望下载一个小的图片而不去下载原图，iPhone和安卓要面临分辨率的问题，你的产品经理和设计师会突然说之前觉得300很合适。但是决定加一个边框，那么300的宽度就要变成298。你会发现你要把所有图片重新做一下缩放，这个工作压力非常大。所以你就希望有一些辅助的系统帮你做好这个事情，比如说你希望能有人能帮你搞定缩放、水印、原图保护。
类似的音视频领域有转码、切片、合成、快速预览的需求。有些客户还有自定义需求，比如美颜相机、人脸识别、数据统计。对于私有存储方案就很麻烦了，但是你用一个公有云就可以了。
单机房100PB的挑战
接下来讲讲云存储对我们来讲我们面临的挑战是什么?单机房100PB的挑战是我们现在需要考虑的事情。就是说我们稍微细算一下，100PB意味着什么?4000台存储计算的话，不考虑冗余的情况下每台承担25TB的容量。考虑3份冗余后它要承担大概75TB，4T乘12块盘是48T，是不够的。我们需要引入新的存储方式，减少冗余。
在200KB的文件平均大小情况下，原数据条目是五千亿条。怎么做好稳定的增删查改工作，是我们需要考虑的问题。
元数据库的压力不仅是维护的问题，更重要的是扛住100W每秒的请求频率，这是数据库怎么扛住的问题。
除了这些还有前面提到的，比如说机器、网络硬件、机房的出入口等等都会有问题，这些问题怎么解决才是我们考虑比较多的一个问题。
在单机房100PB的挑战里面，架构做的东西不太多。对于架构来讲，我们能做好的就是几件事情，***个每个组件都是高可用，可伸缩的。同时，我的组件能轻易的从10个伸缩到100个甚至到4k、5k都没有问题。在设计阶段高可用、可伸缩都要作为一个必选项来考虑。
第二个是保持每个远程调用都是可重入的，最简单的拿交易做例子，什么是不可重入?给账户添加一百块钱的API调用是不可以重入的，请求对方没有返回再发一次就不合适了，有可能你给用户一百块，也有可能给用户二百块。可重入的加钱API长什么样呢?如果账户版本是21的话，给它的账户添加一百块钱，并且把版本改为22，重新调一次的话要不然它成功，要不然它告诉我对方的版本不变。我根据版本是否变化去确认我们之前成功还是不成功，这是可重入的概念。
我们这边不涉及金钱的交易，所以很多时候会比这种简单一点。
第三点网络也是不可信的，传过来一个文件，这个文件是否正确，我们如何来保证呢?如果我们容忍错误文件的话，客户那边就会给我们大量的抱怨。而且由于我们有缓存存在，这个问题会一直错下去，直到缓存过期。所以对我们来讲所有网络传输都需要做校验，架构层面做到这几点，会保证你不会出一些低级的错误。
比较难的是规模扩大了之后怎么办?来自墨菲定律的诅咒：凡是可能发生的都会发生，所有你想得到的事情都会发生，只是发生在哪一天而已。
墨菲定律的诅咒***个是多磁盘故障，常规情况一般是一块磁盘坏了怎么修复。在量特别大的情况下你就面临一个问题，两块磁盘一起坏会发生什么事情?多块磁盘一起坏发生什么事情?如果其他机器属于维护的状态你又应该怎么做?
第二个是交换机故障，在常规的做设计的时候，一般不会去考虑这个问题。但是在做存储的时候，这就变成你必须考虑的问题，你要仔细的给你存储做一些分组。分组的目的是这台宕了，怎么做到客户完全无感知。不要把一份数据的所有备份都在同一个交换机下面，这是我们要确保的东西。
第三个是人为失误，运维的工作量大就会有一些人为失误。怎么确保即使操作失误有不会影响你的系统，这是我们更多要注意的一个方向。
我们能做到什么呢?多预案。针对你的每样事情你需要有一个预案，单磁盘坏了你怎么处理，多磁盘坏了怎么处理，交换机坏了整个流程怎么处理的?这些东西不要写进你的预案里面，在运维发生报警的时候，打开预案一步一步的往下操作。
第二个是多演习，让事故处理常态化，我们要有一个很大的测试集群，像我们前面提到的一些故障我们都会做一些定期或者不定期的演习。让大家能够了解这些东西会有哪些我们想到的事故。
第三个常规的数据处理一键化、自动化。更多的是我前面提到的防过敏，当有人在里面的时候，这种事故处理也许慢了一分两分钟。但是好处是通过人为介入到这里，整个事故不会扩大化，会让它停掉，避免大规模的出现错误。
总结一下，自建存储的缺点是运维成本高，便宜一点的运维人员一年也要15w左右，加上机器成本大概30w。如果你买100TB的云存储话，也就是15w左右，所以购买云服务更划算一些。
常规解决方案存在适用领域狭窄的问题，不够通用。也就是你今天的业务是图片，用mogilefs搞定了，之后想做视频，mogilefs就不行了，又得找新方案。
***推荐两本书，KK的《科技想要什么》，以及Eric Ries的 《THE LEAN STARTUP》。***本讲了很多趋势方面的东西，第二本讲了在创业过程中怎么快速试错，怎么快速让你的用户增长起来，在这方面的东西非常值得一看。
