我以前主要是出来讲OpenStack比较多，OpenStack这几年谈了很多以后，大家逐渐发现要做好OpenStack需要解决一些垂直领域的具体问题，比如存储，比方说平安介绍的要构建一个高可用的共享存储，刚才有一位同仁也提到类似的问题，这些在构建云环境中垂直领域的具体问题可能是现在更受关注的，所以我们现在做的一些事情就是围绕高可用高可扩展的存储这件事情展开的，我们采用的技术是分布式对象存储技术，今天又是运维大会，所以我分享的题目是分布式对象存储的运维。应主办方要求，全程无广告，最后有一个小的demo，也是以开源东西来做的，所以今天只谈技术。

【李明宇】：感谢力哥的邀请，非常荣幸来到咱们这个场地。我以前主要是出来讲OpenStack比较多，OpenStack这几年谈了很多以后，大家逐渐发现要做好OpenStack需要解决一些垂直领域的具体问题，比如存储，比方说平安介绍的要构建一个高可用的共享存储，刚才有一位同仁也提到类似的问题，这些在构建云环境中垂直领域的具体问题可能是现在更受关注的，所以我们现在做的一些事情就是围绕高可用高可扩展的存储这件事情展开的，我们采用的技术是分布式对象存储技术，今天又是运维大会，所以我分享的题目是分布式对象存储的运维。应主办方要求，全程无广告，最后有一个小的demo，也是以开源东西来做的，所以今天只谈技术。

分布式对象存储的运维，今天想从下面几个方向来做分享，首先是刚才提到的问题，就是前面演讲嘉宾也提到的我们要构建一个高可用的共享存储这个问题，其实对象存储给出了一个很好的答案；另外一方面是Swift开源分布式的对象存储系统，这里我有一个深刻体会，跟第一位演讲嘉宾说的东西比较类似，linux要成为一个可用的操作系统，除了内核，除了kernel，还有很多工作要做，我们公司做产品就是以Swift为核心，但是在Swift上还有很多事情要做，仅仅依靠开源的东西是不够的，所以这里说明一下，今天我在这里分享的技术都是围绕开源展开，是我们围绕对象存储做的工作中的非常小的一部分，其他的技术如果以后有机会的话，希望能跟大家继续交流。

【注：下面两页片子主要介绍对象存储出现和应用的必然性及技术优势，对此已经比较了解的读者可以直接跳过。】

首先说一下数据增长的刚需和对象存储技术，大家都知道现在处于大数据时代，到2020年全球数据量将增长到44ZB，这个量是非常大的，而其中90%以上是非结构化数据，而且还有一个特点是，海量小文件与大体积文件并存，我们以前讲的HDFS主要解决的是大体积文件的问题，对于这种海量小文件并没有给出很好的解决方案，同时有另外一些存储系统，比如TFS，是为海量小文件设计的，但是并不适用于大体积文件存储，现在在很多应用场合，很多公司、很多机构内部，海量小文件和大文件是共存的。

具体到一些行业，像GIS，有很多地理信息的应用领域，现在主要是由两大驱动力导致了数据的增长，应用驱动、有需求是一方面，另一方面是技术驱动，第一是遥感卫星越来越多，而且高分辨的遥感卫星越来越多了；第二是四旋翼无人机的普及，无人机航拍图像越来越多。还有金融领域，金融领域就我的体会，我说的不一定准确，我对金融是门外汉，在我们的工作中有一些金融的客户，我是从客户那总结的一些需求，金融领域里面，以往的数据存储主要以结构化数据和交易类数据为主，但是随着业务发生变化，除了一些互联网金融的业务以外，还有银行的一些生产业务，比较核心的生产业务，像办储蓄卡、借记卡，这对银行来说是非常重要的业务。但是随着现在远程开卡，办信用卡可以到你的家里，你的单位给你办，现在储蓄卡银行也有柜员机，这些业务产生大量图片、视频、声音还有签名图片的数据，这些导致了金融领域非结构化数据量快速增长。还有医疗领域，医疗影像、基因数据，这些都是非结构化数据。

还有还有一个重要方面是数据使用方式的变化，如果只是数据量增长这个事情，可能还比较好办，但是人们对数据的使用方式也在发生变化，首先是虚拟化、云化的发展，如果传统IT架构下要搞一个共享存储，用NAS，这个问题可能不大，但是现在的IT系统里，可能有很多的docker，有几百个几千个虚拟机，这些虚拟机和docker容器动态地创建和销毁，怎么样让它很好的挂载NAS里面的共享目录？不用的时候又要优雅的卸载卷、卸载共享目录？这是个问题。

另外，随着“互联网+”的发展，有很多应用需要支持通过互联网随时随地的访问，比如说手机客户端，可能是在某些应用中是图片读取和上传图片和视频，是非常重的非结构化数据的访问来源。这些非结构化数据的读和写，它是要求随时随地访问的，对于这种场景，如果存储系统能做到广域网上的高可用访问就能减少了应用层的开发和运维负担。由此会带来的一些新的问题，以前我们通过应用服务器去上传和下载，比如说图片，我们可以做一些预处理，比如说判断是不是黄色图片，可以在里面打水印，万一出现信息泄露可以追溯等等。这些是用Web Server和Application Server做的，现在要直接访问存储，那我们把这东西做在哪？实际上现在对象存储系统里，比较先进的对象存储系统里就可以提供这样的功能，把一些数据类似于预处理或者相对比较轻的数据分析的工具，做到对象存储系统里面，这些都是数据访问方式、数据使用方式发生变化带来的需求。

还有一些以前说的冷数据，现在可能不是那么冷了，现在用户会想对大量的数据进行分析，进行挖掘，包括很久以前的历史数据，进行搜索，因此以前说的冷数据现在逐渐地可能没有那么冷了，也就是说存储系统要能做到很大，不断积累数据进来的同时还要保证对历史数据的高可用访问。

像这些都是数据使用方式的变化带来的对存储系统的新需求。

我们怎么解决这些问题？我们知道文件系统除了刚才讲的很难支持广域网上随时随地访问的问题以外，还有动态的虚机和docker，如果用传统文件系统，可能虚机销毁前需要把这些文件夹卸载，如果要访问要先挂载等等。即便纯粹说数量增长，一个目录或者一个Volume里面，如果文件数量达到千万级，可能就很困难了，如果要到亿级呢？大家千万别觉得千万文件数量是很大的数，实际上但很容易达到，你可以算算一秒钟只能爬一个文件的网络爬虫，一年下来是多少个文件；一个地产公司，某个区域有50个停车场，车辆进进处处都要拍照，还有视频监控，一年下来是多少图片和视频文件……所以我们现在就处在这样一个时代，大家稍不留神，文件数量很容易就突破了传统文件系统能够管理的区间了。那怎么办？答案是对象存储。

对象存储核心就是解决上述提到的问题，一个是访问模式的变化，一个是文件数量、数据量不断增长这两个问题。对象存储的概念在不同的上下文中有不同的含义，现在说得更多的是S3 like storage，有两个特点：

首先是抛弃了层层嵌套的文件夹，把对象放到buckets或containers里面，在Swift里面叫Container，AWS S3、阿里云OSS里面都叫Bucket。阿里云的OSS全程就是Object Storage Service。Buckets或Container相当于一个目录，但是不是嵌套结构，是扁平的结构，为什么要这么改，改完以后对应用来说，为什么失去了目录层级反而会带来好处，这个不解释了，今天是来探讨运维的问题，对象存储的基本问题我以前在各种文章和会议上也讨论得比较多了，大家如果有兴趣可以去找一下或者欢迎会后联系探讨。

另外一个特点是简洁和服务化的接口，数据写入、读取、更新、删除都是通过简洁的RESTful HTTP请求来实现的，这样便于安全地共享和远程访问。

这是我们讲的对象存储两大特点。传统文件系统除了文件的目录数搞起来比较累以外，接口也比较复杂，文件系统的这两个特性最初是在上世纪六七十年代根据当时的需求做出的设计，这么多年没怎么变，而上层的应用已经发生了翻天覆地的变化了，文件存储接口也是到改变的时候了，实际上改变的号角是从06年AWS推出S3的时候吹响的，现在已经走进企业级的IT系统里面了。

这样一个存储系统的特点第一是简洁，无论是数据组织形式还是数据访问接口都是很简洁，便于编程、开发应用，第二是容易扩展，因为简洁所以容易扩展，可以做到亿级文件存储，但其实文件存储到对象里面，就不叫文件了，就叫对象，简单就是这么理解。从根本上解决了传统文件系统在文件数量很多、存储规模较大时，性能衰减、可扩展性差、共享能力差的问题。

今天要介绍的开源对象存储系统是OpenStack Swift，我去年前年也经常讲OpenStack，我从2012年开始搞OpenStack，在四年多，将近五年的时间里，非常深刻体会到了OpenStack社区，整个云的生态，特别是开源云的生态在国内的巨大变化。2012年以前国内搞OpenStack的非常少，那是我在科学院做研究，要追求前沿，后来我逐渐发现技术要落地，要产业化，还是需要聚焦，我就找一个点来做一些事情，最后我选择了以OpenStack Swift开源对象存储为核心做一些工作，因为我看到了很多用户在存储共享和高可用性上遇到了问题，我希望提供一些解决的技术和方案，所以今天介绍的是OpenStack Swift。

Swift是OpenStack六个核心服务之一，Swift是有业界成功的百PB级集群的，Rackspace两三年前就已经做了百PB级的Swift集群，现在业内做到这个规模有实际案例的还是很少的。另外是全分布式架构，没有集中管理节点，没有任何一个组件提供集中管理功能，从理论上，全分布式能达到最高的可用性和可靠性，在分布式系统理论里面。另外支持跨机房、跨地域多活，这个对前面举的金融领域的例子就非常重要，我们现在有金融客户生产环境双活存储的案例，刚才平安科技的嘉宾也介绍了平安有多个数据中心，像去哪网的嘉宾也提到了多个数据中心，那怎么存储呢？一个数据中心完全不可用了，断电断网，应用还是可以正常地往存储系统里写数据、从里面读数据，这是我们Swift的跨地域多活的特点。跨地域多活实现了，Swift可以实现在全国范围内，比如北京、上海、深圳都有Swift节点的一个大存储集群，甚至是在全球范围内，这个目前已经有人做到了，比如说AT&T，AT&T就使用了Swift来构建跨全球多个数据中心的对象存储系统。另外还天然支持多租户，支持租户之间的隔离，一个租户里有多个用户，统一租户的多个用户之间的存储空间是共享的，但是两个租户间是隔离的，不会出现数据泄露。另外还支持Hadoop，跟OpenStack无缝集成，我们可以把OpenStack的镜像、快照、硬盘的备份、数据库备份、系统备份和应用备份，这些备份数据都放Swift里面，Swift又可以跨数据中心跨地域，这就可以很好地支撑OpenStack云环境的灾备和双活。

这是一个Swift部署的例子，这个部署的规模比较小，再大规模的案例从投影上可能就看不太清楚了。这是十二个结点，跨两个数据中心，这是同城双活，两个数据中心在Swift里面是两个Region，跨数据中心一开始是用的VPN，后来换成了波分，这个效率还是比较高的。可以看到Swift主要有这样一些服务，首先中间的是account服务，就是用来做多租户管理的，另外container服务就相当于阿里云或AWS的bucket，object服务就是执行对象存储、读写的。上面还有缓存服务，不是缓存对象数据，而是用来缓存用户认证的一些信息。还有Proxy服务，是API服务，或者叫接入服务，用户访问请求，经过负载均衡分发到每一个Proxy服务，然后Proxy服务找到具体我是要访问哪个container、account还是object服务。值得一提的是，Proxy服务可以部署在任何一个节点上，通过任何一个节点上的Proxy服务，都可以访问到整个集群里所有的数据，前提是你有权限，在有权限基础上，在任何一个节点上，你运行了Proxy服务，用户请求进来就可以访问到整个集群所有数据，这是我们讲的全分布式、无中心特点的一个体现。

刚才提到了这个中间，两个Region，两个数据中心互联，一开始是通过VPN，速率比较低，测的双活没有问题，后来上了效果更高的波分。我们还测过两地相差四百公里的，双活也是没有问题的，但是具体怎么做优化，后面会提。

前面是对对象存储和swift的简介，下面进入跟运维相关的内容，刚才讲了swift做跨地域部署，我们需要注意什么东西？首先这张图是一个简单的示意图，我们可以看到里面的数据存了三副本，比如说data1，在这个主中心或者说这个在深圳，这个上海，在深圳的数据中心里存了三个副本，还有data2，两个副本存在深圳，一个副本存在上海，data3也是两个存在深圳，一个存在上海，我们能够划不同的资源池，让有的数据只存在一个中心，有的跨中心存，你可以选择三副本、四副本方式还是纠删码方式存。

曾经有一个用户就跟我们讨论了他们的需求，在华南有一个主数据中心，那个用的是运营商的机房，在海外有一些办事处，也搞了服务器，但是办事处的机房条件差一些，可能在那找个房间一对付接了互联网就算完事了。这种情况下海外那边只存一个副本，因为容量也比较小，存一个副本过去有利于提高海外办事处的访问速度，但是海外那个机房不太可靠，所以要以国内的数据中心为主中心。

这里就涉及到两个东西，一个是写亲和（Affinity）读亲和特性，第二个是存储策略的配置。写亲和就是优先把数据写到某一个region，某一个数据中心，异步复制到另一个region，读亲和就是优先从某一个region读取数据，这里的优先region通常是本地region，所以亲和性能够提升数据读写的性能。但是有一种情况，比如前面说的这种海外和国内都有数据中心的情况，但是两个数据中心地位是不对等的，国内的比较稳定可靠，我们希望数据总是先写到国内的数据中心，然后同步到国外去，保证写入的数据都能可靠存储，还可能有一些数据我们希望只保存到国内的数据中心，不同步到海外节点。这就涉及到第二个方面，存储策略，我们可以对不同的数据配置不同的存储策略，策略可以按照地域来分，也可以按照介质来分，比如固态盘的存储池和机械盘的存储池分为两个存储策略。

前面谈的是跨地域部署和存储策略的划分，下面我们来讨论一下日志分析问题。我们做对象存储要回答不同于传统存储的问题，对象存储里要考虑什么问题？每秒钟多少次访问请求，这些访问请求是谁发过来的？这些请求的完成需要消耗多少时间，请求上传下载需要多少数据？跨地域多副本数据是否完成同步？等等，这些是我们今天要回答的问题，传统存储里面没有，这些问题通过什么来回答？通过日志分析就可以回答很大一部分。

我们看一下swift的日志，默认会写成这个德性，没法搞，因为它把刚才提到的那些服务的都写在一个文件里面了，还有后台的数据检查和数据复制的日志，都写在这里面，中间还有一些其他的服务，如keepalived，这没法搞，所以要做swift日志分析，首先第一步就是做日志拆分。然后对日志做结构化，最后再想把你想要的东西搜出来。

日志拆分，除了把四个主要存储以外，还有后台的检查、复制等等，全部都拆开，不用怕多，全写到一起反而是不太好弄的事情。

拆出来以后，这是一条访问日志，只是举一个例子，做结构化，这个访问日志可以看到：这些请求从哪里来的？谁访问我们的存储？有两个IP；另外我们要统计写、读、删等等这样的次数，我们可以看到这里有请求方法，如果是PUT就是写入；这些可以分析出对一个对象的请求还是对容器的请求，这是租户ID，这是buckets，整个是对象名称；还有响应码，我们看到是201，201是创建成功，根据这个响应码可以做一些错误的分析和处理，比如你看到40几的错误，你想读的文件对象，根本就不在里面，可以根据它做错误处理；还有接收的数据量和发出的数据量，可以看到一次上传操作，写入到集群数据量的多少……还有其他的东西，根据这些就可以得出很多我们想要的东西。

做完结构化以后存到一个后端，这个后端要结构数据化存储、支持搜索，就可以了。接下来就是构造搜索条件，其实就是根据你想要回答的这些问题，来构造你的搜索条件。每个用户看中需要去分析、需要去监控的运维指标不一样，搜索条件也不尽相同。

这是swift对访问日志分析怎么做。还有后台数据检查和复制进程日志，我跨地域做三副本，要同步过去一个，现在人家要问，我这个数据有没有同步过去？

有时候用户会问你，我写完了之后，数据什么时候同步过去？你要给他看他的数据有没有同步过去的话，你就通过分析后台数据的检查与复制进程日志。可以看到这一段，已经100%完成了partitions的复制，总共花了多长时间，做了多少次成功操作，一个partition最多花了多少时间，最少的花了多少时间，可以在这个时间以前写的数据，全部都已经同步完成了。所以为什么要把这些后台的日志都拆开，否则混在一起没法搞，这样就很清晰的往上追溯，这个时间点往前写的日志都同步了。

另外在分布式存储里面还有一些监控项，盘的利用率、IO、网络带宽消耗、CPU消耗等等。对于swift还要回答这些问题：在一个存储池内部，数据分布是否均匀？还有swift要根据时间去判断副本是旧的副本还是新的副本，需不需要新的副本去覆盖旧的副本？所以时间同步是一个需要关注的点。swift这里面还有一个ring一致性的事情，ring是swift特有的配置文件，要在各个节点上保持一致，保持同一份。其实在我们的互联网的系统里面，很多地方都需要做这样的工作，配置文件保持一致，所以其实并不是什么特别特殊的事情。但是你怎么样去确认各个节点上的ring都一致了？不一致的时候需要做出一些处理，这个ring的一致性检查，很重要。另外就是一些监控指标要分存储池，不能一套系统一个指标下去，你要分不同的指标，三副本的池，两副本的池，有的池还会重叠，这些怎么搞，swift提供了一个工具，我在这个地方给大家演示一下。

如果大家用swift，有一个swift-recon，这可以获得很多swift的指标，回车以后有个提示信息，中间就会有replieation完成得怎么样，磁盘的使用情况，可以根据存储池来做区分，通常我们讲的存储池在swift叫做policy。所以简单来看一下，这里只有三块盘，三块盘的平均利用率是1%，现在已经到了1.5%，还有更有意思的是，这些盘里利用率最低的是多少，利用率最高的是多少，这就涉及到存储分布尽可能的均匀，所以swift就可以回答这样的问题。还有上面，这些地方是给出了各个盘具体存了多少数据的量，在这个地方，这里实际是一个表，如果你有一百块盘，有二十块盘运维比较低，只有10%，剩下的80个盘都正常，就可以看到10%后面写了一个20%，一个长条，然后是30%，然后80%，后面一个长条，可以很直观的看到磁盘使用分布的情况。但是这也有一个小问题，swift在划分存储策略和存储池的时候，一块盘可以属于不同的池，所以有时候它看到的数据分布不均匀了，不一定真的就数据分布不均匀。还有一些情况，可能是人为想要数据分布不均匀一些，假如说服务器磁盘用了三年以后或者五年以后，即便没有坏，我们可能都要做一些准备工作，在我们公司通常会这么做，随着时间推移把旧的盘存储权重逐渐降低，让上面存的数据逐渐变少，这也是我们经常用的手段和技巧，这时候也会显示不均匀，所以swift-recon这东西只是作为开源比较简单的运维工具，你可以去用一下，但是要真正生产中用swift的话，还是要开发一些专门的运维工具。

再看刚才我们刚才讲的ring一致性的事情，加上--md5，它说每个节点都是相同的，这只有一个节点，假如你现在是20或者200节点，你就可以看到这个，如果有一个ring不一致，就会提示你说有一个节点的ring而跟别的节点不一样，这是我们讲的所有的recon。除了这些之外，还有比如，通过日志去看后台复制进程怎么样，比较复杂，可以用swift-recon带-R参数，可以把检查的结果告诉你，看这个结果显示我们演示环境这里的失败率就是0，最近一次复制是11秒之前，这些都是我们可以用recon做的事情，比直接去抠日志轻松一些，但是得不到历史状态。要想知道当前的即时状态的话是非常快的。swift-recon能做的事情不少，但是对于实际使用的系统进行监控和运维来说还是比较有限的，毕竟只是一个你敲一次给你一个结果的命令行。对于一开始集群的调试，用recon还是挺灵活的。

实际使用swift还是要开发运维工具来做更多运维的事情，这是我们自己在用的工具，因为我们对外提供的产品自己也在用，公司的好多文件就放在自己的对象存储系统里，所以我们还是比较有信心的。

【肖力】：感谢李明宇的精彩分享，由于时间有限，只能提一个问题。

【提问】：刚才看到你的PPT是说对象存储可以支持让OpenStack实现双活，这个双活是什么样的尝试？怎么实现的？

【李明宇】：首先要说明一下，这是支持OpenStack双活，但是支持业务的双活在OpenStack双活的基础上还是有很多其他工作要做的。这个今天只是提了一句，但是在今年年中OpenStack China Days，我们跟华为曾经有一个合作的分享，那上面就具体说了怎么用它来实现双活和灾备。

【肖力】：这个问题可以通过微信交流，李明宇干货非常多，下次再请你过来分享。咱们这个场就结束了，谢谢大家。

【李明宇】：谢谢主持人，也谢谢大家！希望以后有机会跟大家进行更深入的讨论。