像Yahoo、Facebook这样的企业都需要存储数亿级的用户图片，他们都在为实现这个目标而努力，Yahoo将非结构数据的MObStor对象存储系统转移到了Ceph上，并且正在部署***的基于Ceph的系统—云对象存储，Yahoo在数百个PB级规模上操作，显然已经是业内老大。
任何超级巨头们都不会等待IT产业技术的自我更新，来满足自己应用的需求，但是当一个可替代的开源项目成长足够成熟，巨头们通常会从自己的软件到其他栈上做跨越式部署。从雅虎的门户网站上我们可以清晰的看到，Yahoo的重心从自己研发的对象存储转移到了即将成为exascale级别的系统，这个系统基于开源项目Ceph，一种Swiss army knife的存储。
这样的跨越并不常见，因为这些超级公司更倾向去超越技术规模的限制，不论是他们自己的技术还是开源项目，当然通常是开源项目。但这种情况确实存在。比如说这周早些时候谈到的平台，媒体巨头Netflix，它一直使用Cassandra NoSQL 数据库的一个自定义版本来作为控制流媒体服务和用户交互的后端，去年秋天，它将端口从DataStax转移到Cassandra的商业级别的 variant上。而Yahoo正在进行一次更大的跨越，他们将自己研发的用于非结构数据的MObStor对象存储系统转移到了Ceph上，Yahoo的架构副总监说，他们这次的变化是经过慎重考虑的。
所有的信息技术都从cat图片开始
雅虎是对象存储领域规模上的创新者，就如同Facebook和他的Haystack系统，Amazon和他的S3系统，Mosso Cloud Files系统曾经是Rackspace Hosting的Swift对象存储的基础，而现在已成为OpenStack云控制器的一部分。Yahoo和Facebook都要存储数亿级别的用户图片，处理PB级别的容量，这就迫使他们开发自己的系统，实现更高效的图片存储功能，亚马逊和Rackspace假设，创建云应用的用户同样希望将丰富的媒体嵌入到图片上，所以他们想将对象存储变成他们公有云的一部分。
上面提到的所有对象存储系统，Haystack、 MObStor、 S3、Cloud Files/Swift， 他们被开发都是因为文件系统中常规存储阵列都存在非常大系统开销，这是因为用来跟踪对象的元数据存在于集群中。对象存储刚好忽略了文件系统，并将所有数据放在同一个bucket里，然后使用一个key，比如文件名或web的地址，在集群中找到该数据。这样可以使元数据的开销更小，因为没有文件系统与之抗衡。
十几年前，早期的雅虎图片服务器是由一个特殊的存储系统来处理非结构数据，其之后是一个由Yahoo开发，被称为MObStor的系统，它是一个用起来更加复杂、更具有普遍性的对象存储系统，Yahoo于2009年的夏天***公开提及MObStor。2005年，雅虎的图片分享网站Flickr急需一种类似于对象存储的技术，然而当时MObStor被雅虎应用程序用来储存JavaScript和HTML代码以及富媒体，在2010年夏天，雅虎的工程师更新了MObStor，这在当时非常先进，这也是在六个月内系统的处理能力增长了4X(倍)的一个因素。当Yahoo揭露MObSto的时候，它仍在运作，而且运行在专用系统Direct Object Repository Architecture (DORA)上，DORA是针对MObStor的一个新后端，被称作是一个集群对象存储系统，它在很多方面与Ceph非常相似。MObStor是DORA 后端系统的接口，Yahoo的程序员写这个系统是因为他们需要存储非结构性内容，比如照片、视频和其他类似的数据。DORA是运行在普通硬件和存储应用上的，雅虎当时还不太明确这些意味着什么，但是DORA后端特点允许Yahoo在更廉价的系统上做对象存储，这也就说明了一切。
我们将在数百个PB级规模上操作，我不知道其他Ceph社区是否还会这样做。如果我们不是***的，那么我们就会成为***的产品用户，而且我们很可能会去寻找适合我们规模的版本。你只需要看雅虎这个规模的数据，不用看传统的那些。
经过一些改进，McMillen说贯穿Yahoo所有的服务和中心数据，如果将对象、块和文件存储叠加在一起，这将是一个exabyte级别的存储。在发布过的一篇微博中说到，Yahoo从MObStor迁移到Ceph上是因为Flickr上的照片分享服务，公司说那有250亿个对象，将近500PB的照片、视频、邮件和博客帖子。这些都是为用户存储的，并且存储量仍以每年百分之20-25速度增长。
根据McMillen所述，MObStor具有“完整特性”，它广泛部署于雅虎。那么如果MObStor真的被广泛应用和被看好，为什么Yahoo却热衷于一个新的技术了?不管怎样这些都涉及到了钱。
首先，MObStor是一个闭源项目，这意味着雅虎不得不独立完成创建、扩展和所有支撑工具。与之对应的是Yahoo所创的Hadoop数据分析平台，这是一个开源项目，在这个平台有一群资深的工程师，他们在不断改进平台上的所有的layer，这体现出了社区的价值。
"我想说，转向Ceph的最主要是因为我们仅仅想降低存储费用"，McMillen解释,"我们的存储已经增长了许多，我们在尽可能得缩减成本，尽可能得拥有更多的选择，而不是坚守着一个系统，一种技术或一种硬件架构。
原始的MObStor对象存储是运行在存储阵列上，存储阵列上有动态保护RAID数据，保证了文件安全。随着DORA的使用，雅虎增加了选项，用来复制存储集群中阵列之间的数据。RAID和复制带来了一个很大的开销，而 McMillen却不愿意透漏出任何有关MObStor与Ceph在这个方面对比的详细信息。但他却说过，对传统对象存储系统的检查发现，这个开销对三路复制来说为200%，伴随着纠删码技术运用到Ceph及其他的对象存储，能将开销降低到40-60%，这些能在雅虎安装调试Ceph中看到，McMillen说最接近的40%的开销在纠删码保护校验来确定数据的原始性。这个意味着雅虎在Ceph上存储容量的开销是用传统对象存储的一半，而且还是三副本。
MObStor/DORA不支持纠删码，雅虎不得不将这个移植到该系统上，这可意味着大量的开发和测试的工作量的产生。另一方面Ceph是一个 exascale级部署设计，它有纠删码技术以确保数据的内建。(有了纠删码，少量无结构数据碎片和分散存储，或者如果一部分丢失，纠删码算法可以重建丢失数据)
#p#
云对象存储
雅虎正在部署***的基于Ceph的系统，它被称为云对象存储，从去年秋天开始，它已经被雅虎stack的Flickr部门试验。Flickr在管理上有“多PB级别”的Ceph容量，在本年度雅虎计划增加10个基数来达到“轻量过百PB级别”，据McMillen所说，当推出基于Ceph的云对象存储，将其隶属于Flickr、雅虎邮箱、Tumblr(轻量博客)。(McMillen说Flickr会有更多的存储量，其中的一分部还会在MObstor中保留一段时间)
雅虎也曾经关注过swift和Gluster文件系统，还有那些为寻找新的对象存储系统的特有选择，最终他们将注意力放在了Ceph上。首先，McMillen说Ceph有吸引力的地方是将支持对象和块存储两者于一身，如果Ceph社区永远如此高效处理问题，在未来某一天(很有希望)Ceph同样支持文件系统存储。
“并不是所有雅虎的存储都适合对象存储，但是很多却适合”，McMillen说到，“我们正在使用块存储，但是他们却没有对象存储走的远。我们非常喜欢Ceph，除了它因纠删码而产生的低成本和它是一个开源项目，在开发者的社区发展非常迅速外，还因为它是一个同时具有块存储和对象存储能力的单一存储系统。所以代替块、对象分开的存储系统，我们可以灵活掌握一种技术栈而获得两种使用方法。而且如果Ceph有一个稳定的文件系统，我们今天绝对会使用它。”
Ceph社区(后台是Red Hat，其已经在一年前以175 百万获得Ceph管理Inktank)仍在专注它 。
McMillen说，当Ceph可以从单个集群扩展到exabyte级存储系统，雅虎将Ceph应用于pod架构，这会比一个单一集群具有更好的性能预测性和错误隔离性，效果如下：
在雅虎云对象存储上，每一个节点(被称作一个对象存储设备)，有60TB的存储，这都是基于X86的服务器。雅虎已经尝试过每个节点配置12-72个设备，对于COS服务，Yahoo没有透露其硬件配置。每个集群有54个这样的节点，总容量可达3.2 pb。为了向外扩展这些服务，雅虎复制pods并使用哈希算法来打破利用纠删码横跨pods和节点的无结构数据。
依赖这些应用，雅虎正在使用常规的硬件驱动和磁盘，他们使用的是shingled magnetic recording (SMR)技术，在容量和花费上都不同;SSDs也被部署到了COS服务来提供更高的I/O率。
雅虎正在Ceph的variant上使用8/3纠删码，这说明8份中的3份共享对象的服务或者驱动可以失败却仍然可以访问的到。这是常规级别的纠删码在Ceph上应用的。但是雅虎已经计划了一个针对Ceph的11/3纠删码variant，这意味着11个中的3个驱动或者服务可以失败，更重要的是这个可以减少40%的读写延迟。(根据McMillen的说法，雅虎计划把这项改进回馈给Ceph社区，通过这个方法，它能让自己参与到“Hummer” 代码稀释中)公司已经做出了一系列调整来使Ceph表现出更好的性能，如下图：
#p#
加入了纠删码的更改，雅虎已经想出一个共享bucket索引的方法，那就是一个索引保持跟踪对象存储到一个bucket(这是针对对象存储容量单位的亚马逊术语)正常Ceph是在一个单一的服务器节点上实现bucket索引，但是雅虎的工程师为了高可用性和性能方面的改进，已经解决了如何切分和跨节点传播。当有磁盘或服务器失效，数据恢复完成，雅虎想出一个在恢复数据时将延迟的速率限制到60%的方法。
与此同时，雅虎自支持Ceph的实现，但是McMillen说公司与RehHat关系非常好，而且也不反对使用RedHat做一些技术支持。但是雅虎正处于一个大量消耗的时期，而这与超大规模Ceph有关，也许自支持是他们现在唯一的选择。
“我们将在数百个PB级规模上操作，我不知道其他Ceph社区是否还会这样做”，McMillen说。“如果我们不是***的，那么我们就会成为***的产品用户，而且我们很可能会去寻找适合我们规模的版本。你只需要看雅虎这个规模的数据，不用看传统级别。我们正致力于解决所有这些问题，我相信社区会从中受益。
