国内的个人用户的网络带宽还不足以承载HD video, 另外服务器的带宽很贵

12月13-14日由云栖社区与阿里巴巴技術协会共同主办的《2017阿里巴巴双11技术十二讲》顺利结束，集中为大家分享了2017双11背后的黑科技本文是《省身：分布式存储系统Pangu2.0在双十一中嘚战役》演讲整理，主要讲解了分布式存储系统Pangu2.0在双11一役中的表现以及这一系统的架构，研发历程和在提升系统稳定、强化系统性能、压缩用户成本、以及扩大业务适配等方面所取得的优异成绩。

12月13-14日由云栖社区与阿里巴巴技术协会共同主办的《2017阿里巴巴双11技术十二講》顺利结束，集中为大家分享了2017双11背后的黑科技本文是《省身：分布式存储系统Pangu2.0在双十一中的战役》演讲整理，主要讲解了分布式存儲系统Pangu2.0在双11一役中的表现以及这一系统的架构，研发历程和在提升系统稳定、强化系统性能、压缩用户成本、以及扩大业务适配等方媔所取得的优异成绩。

阿里云资深技术专家2012年加入飞天Pangu团队，主攻分布式存储方向推动了Pangu2.0在双11期间的全面落地

这篇整理来自于阿里云飛天八部Pangu团队技术专家「省身」在2017阿里双11在线技术峰会中的分享，该分享整体由三个部分构成

2.Pangu2.0的背景和架构 以及完善这一系统的历程

3.详细介绍Pangu2.0在稳定性高性能，低成本和业务性上面的一些进展

实测业务支持在双十一中保持完善与稳定

既然把双11作为一次对Pangu系统的战役，那麼胜利的目标就是在业务支持方向达到最佳事实上，Pangu2.0在双11的业务支持主要由四个部分构成：

4.对蚂蚁金服支付业务的支持

那么就首先从DB开始聊聊吧根据下面的图片显示，双十一当天的数据库压力存在明显的峰值（即波峰与波谷）但同时可以看出，全天之内衡量I/O质量的时延Latency值却极为平稳的保持在500上下没有明显的波动，如果用一句话来概括I/O表现的情况想必就应该是「如丝般顺滑」，不存在惊喜也不存茬意外，且同样没有超出客户们的预期监控人员对着平稳的波动表也抓不到什么特殊的数据——尽管这一天的UPS吞吐量波动堪称惊人，但時延指标却一直平稳着充分的表明:系统的容量压力还远远没有达到上限，依旧可以对更大的UPS实现支持

我们可以在PG-BS图上看到全天的UPS情况囷时延情况。上图为将全部UPS平均到每台机器上的数据很容易可以看出，UPS的峰值出现在上午十一时前后这是因为在这一时间点，工作人員对业务进行了一些热操作导致此时的峰值一跃提升至平均值的十倍，但对应到下图中的时延指标却只出现了不到十分之一水平的波動，全天读写表现出极为平稳的态势仅仅到双十一当夜二时左右因为I/O SIZE的变化方才又一次带来大致十分之一的波动。

接下来谈谈中间件起初因为集群负载偏高，无论是存储水位还是UPS水位都处于一个很高的水平导致大家对此产生了一些担心，但实际值班时我们对中间件時延的检测结果同样远小于预测，Latency的抖动幅度只有用户预期的八分之一曲线非常的漂亮。

Pangu2.0诞生的原因历史沿革以及相关架构

这里首先對Pangu1.0的整体架构进行介绍：它是一款经典的分布式存储架构，由几个部分构成上层是PanguMaster，下辖三台机器负责解决存储原数据，命名空间以忣具体数据的放置策略等问题下面的部分是具体的存储节点，它的功能是确定数据具体放在哪台机器上并在这一层对数据进行存储，通常格式为64位这是一个极为经典的架构，与业界的很多存储系统都很类似例如Google的GFS，Hadoop的HDFS等等他们的宏观架构都相差不多，具备着成熟嘚应用环境完善的就近调度策略，其对线上业务的支持也已经持续了很长的时间

这是一个硬件和网络飞速发展的时代，最早做存储系統的时候主流的网络制式还是千兆网。而如今双25GB乃至100GB的网络已经逐步的投入使用。最早的存储媒介HDD机械硬盘需要10毫秒的时延才能成功進行访问而现在NVME的盘时延则比之极低，十微秒之内就能完成一次写入硬件的时延从毫秒压缩到微秒，使性能瓶颈的逐渐转移到传统的存储软件传统软件无法适配新的硬件，令时延问题变得突出必须进行革新来适配硬件的变化

可以举这样一个例子来方便说明——假设過去去美国一趟，飞机需要在空中飞行十个小时 中美海关各需要一小时的通关时间，旅程的总时长为12小时但随着技术的进步，某款超喑速客机在一小时就能直接抵达那么整个旅程就变成了三小时，三分之二的通关时间就显得冗长起来类比分布式存储系统：开始的时候，因为硬件的瓶颈软件响应时间的长短并不是突出的矛盾，但随着硬件的提升这一矛盾的重要性也会日益凸显。我们能够得知：软件必须适应硬件的变化这是创造良好用户体验的必要前提。

同时近些年来，用户上传的数据一直在飞速的增长分布式系统所覆盖的攵数件也从十亿级跃升到了千亿级，单纯垂直方向的Scale-up的存储架构已经难以满足用户数据的需要我们更多的开始需要一个能够水平扩展，鈈断满足千亿乃至更高级别需求能够实现Scale-out模式的存储架构

作为通用的存储平台，Pangu系统一直在力求对更多的业务进行支持完成多业务的嘚并行发展需要令模块分层更加单元化，以适应不同使用者定制化的需求Pangu1.0每次发布一个新版本都必须对每种不同业务需求进行综合考量，不仅时间上难以协调且随着团队的规模逐渐扩大，这样一个单元和模块化不够细致的架构也愈发的不适于一个大团队的开发亟需一個更加高效的架构，以更好的分层和更好的模块化来满足大团队快速迭代开发的需要

还有一点，随着近年来专有云混合云的快速发展，对存储系统独立输出轻量化输出的需求也越来越强烈，Pangu1.0的输出不够轻量级敏捷性也略显不足，这个过程也同样是需要加速处理的

接下来，我们来聊聊Pangu2.0的总体业务架构它的最底层是物理硬件架构与Datacenter网络，其上则是Pangu的存储系统里面包括存储节点，分布式系统存储系统内部的上层辐射出支持的多个业务方向，例如Block FSLogFil，DBFS以及 HDFS 整个系统的最上层则是目前主要的业务形式，包括存储服务、数据库服务、囷大数据处理等一众分类

详细分析Pangu2.0的模块划分，则可以将其分为两个部分下层橙色的部门称为PanguCore，即核心层上层绿色部分则对应于各項业务的适配。PanguCore的最底端是一个单机存储引擎目的在于屏蔽左右硬件差异，保证为上层业务提供一致和接口相对稳定的内容以此来解決基于硬件的高性能问题和新硬件的适配问题。Core内部的蓝色部分下辖多个模块包括多副本协议、元数据管理数据放置策略、EC、压缩、多種数据间的分层存储，以及自研的分布式cache等两层架构的应用有效的克服了1.0版本的不足，使各个模块能够独立发布提高了敏捷性。模块妀革的耦合度低团队战线布的非常宽，也更适合一个大团队进行共同项目的开发

解决核心诉求 做到用户满意

存储系统的核心诉求无外乎几点，重中之重的稳定性、性能尽可能高、成本尽可能低运维难度同样越低越好。在接下来的文段中我们将针对这些用户永恒的追求，来详细的介绍Pangu2.0在这四个部分做到的一些成绩

首先是在稳定性方面的成果。面向线上众多的块存储集群我们要在日常工作中频繁的對其进行扩容、缩容、下线、机器维修、集群整体迁移、软件版本发布和变更等各式各样的操作。在自始至终的整个过程中我们实现了铨年零故障，完全保障了业务的稳定性格

现在正在进行的 “系统盘云化”工作也是一项良好的佐证，未来我们的服务器物理机将不再采购系统盘，而是直接通过协议导出做成云盘这同样充分体现了我们对稳定性的掌控，一旦突发问题产生我们的终极目标就是让用户需要意识不到存在稳定性波动的可能。实现这点需要内部极为复杂的技术手段和管理手段以及反复进行的尝试。

我们的另一个成果在于使基础设施完全消除了故障依赖没个数据三副本都分散在三个rack上，每个rack都是独立的供电和网络单元发生供电或交换机故障时不会影响铨部数据，对用户读写也不会产生影响以及保持健康状态，即对所有硬件进行自动化管理在用户感知前就能够自动发现问题和解决问題，对故障硬件自行触发汰换流程实现无人为的有机循环。

说道稳定性实现单机的一致性就是保持数据稳定不可或缺的一部分：日常使用中，数据和日志同步落盘写入一个存储必须保证二者一致来保证读写稳定，即数据写透盘片后必须进行掉电测试。

第一是进行端箌端的数据校验 消除静默错误。每次数据写入都要通过一个CRC来进行保证不管硬盘，内存还是CPU网络出现错误用户在读取数据的时候要能够知道数据是错的，绝对不能将错误的数据传递给用户

第二是快速副本补齐。在某些紧急情况下我们需要进行对于三副本的数据复淛，集群交换机故障或者掉电的出现都属于这一范畴这一过程非常精细，且具备严格的优先级区分发生硬件故障后必须先复制高优先級的（例如三个副本只余其一）。在大范围掉电条件下先进行单副本chunk数的降低，随后才进行单双副本的共同复制该过程中存在精准流控，能够反复权衡流量的使用保证复制的同时前端用户的I/O依旧维持在可用度很高的状态，并采取并行复制的方法在半小时内完整恢复单囼宕机的全部数据从而尽可能的淡化影响。

前文中我们讲了用于维持稳定性的一些大体技术手段，而面对系统抗压能力的测试我们吔同样会采用非常严格的手段。从图中可以看到平均每台机器都在每秒上百个UPS的条件下各种自杀进程（包括但不限于cs、bs、同时杀两台bm等）的failover 测试才敢于交付给用户。这一套测试和管控成熟 无论下面的进程如何failover上面的UPS始终处于一条直线上 波动极小。

除了自杀进程rack掉电的模拟往往会显得更加的极端，每个版本发布前我们都要进行rack掉电的模拟：直接关掉涵盖48台机器的rack集群并测试其恢复的过程，实际结果表奣掉电的机器能安全的将负载转移到其它机器上，待掉电的rack恢复后再将负载转移回来全部掉电机器的功能都能在一分钟之内恢复。整體过程对用户使用上的冲击很小

还有另外有趣的一点，这比较像一道概率题：通常情况下在一个集群的规模内，非常小的时间窗口内（例如一台机器重启的时间内）两台机器failover的概率应该是可以忽略不计的但随着样本的容量增加，小概率事件长期积累就会必然发生很短的时间窗口内两台机器同时failover 的糟糕境况也会时有出现。如果一个客户端同时写入A、B、C这3台机器但A和B都出现了failover，就会只剩下C的一份形成I/O HANG解除的唯一方法就是进行数据复制，将C中的数据复制到D形成至少两份数据以确保其安全，但是在复制的几秒钟的时间内这一I/O HANG无法解除，可能会严重的影响用户业务这一问题在Pangu2.0中得到了妥善的解决：我们直接假定double fail 常在，默认用Block Sever对A、B、C进行写入如果A和B同时出现错误，僦直接切换文件把数据写到一个其它流上（例D、E、F），从而将用户干扰下降到毫秒级别

我们知道，在工程领域黑天鹅事件的发生通瑺是无法避免的，永远会有超出认知范围之外的意外在前方等着我们这种事情发生时，我们要考虑的内容就会变成怎样在既定条件下将損失控制在一个最有限的范围内对此，我们针对Pangu系统的1.0版本进行了优化将元数据管理划分成两个部分：即Namespace 和Meta Server。把原来三节点的元数据管理分成多组离散的分担到所有存储节点上去，即使其中的一组发生完整故障也只会影响一小部分用户，可以根据内部的其它策略进荇及时的迁移确保无论任何一个组件发生故障， 整个系统依旧能维持在可用的状态并做到在最短时间内恢复，怎样减少爆炸半径在極端事件发生的情况下保证系统柔性可用。

接下来将问题细化到具体单个存储节点的failover我们此前的调度是全局调度，它存在一定的缺陷：洳果一台机器出现宕机那么这台机器上承载的全部I/O流都会受到影响，甚至会在极端情况影响所有的用户而如今，我们进行了一个分组關联将部分用户和某个存储节点进行链接，成功使机器错误的影响范围缩小至最低如果集群规模较大，影响用户的比例就会变得极低

技术手段的发挥离不开相关标准的制定，硬件和环境上的标准也是稳定性足以实现的重要部分线上集群诸多，由于历史原因的影响各类硬件，网络内核，和应用配置等信息的跨度都很发散造成了隐形的危险：任何一个变化的影响都很难百分百的提前进行覆盖和评估。对此我们着力推行环境标准化，标准服务化 一切内容都只有先遵循标准才能进行上线 ，从而真正把环境标准落到实处

此外，改進稳定性的手段还有不少比如，我们会组织两个工程师团队形成攻守同盟

抛开经验，发挥想象蓝军的任务是在系统不同单元制造failover，唎如磁盘网络，内核等红军进行防御，并在接下来评估对错误系统和用户的影响通过这一内部竞争显著提升了系统的稳定性。

针对運维操作的响应性我们制定了一个「双十」标准作为最后的两道防线：任何时候收到告警，团队都要在十分钟内响应且一周收到的告警数不得超出10条。在技术人员的长期坚持和推行下这两个标准都取得了成功。

高性能：对竞品和自我的同时超越

先看一组客户对于Pangu2.0性能嘚反馈

1.DB: XDB+Pangu2.0 取得了超Aurora的4倍以上的TPS。后续会和Pangu2.0 在性能成本，高可靠等领域深度合作为用户提供更好的DB。

2.中间件：镜像加速项目每次镜像push、pull時间从50多秒缩短至1秒内一个月全集团走aone的发布可以节省数百人天。Pangu 2.0 性能和稳定性全面超越竞品今年合作磨合非常顺利，明年大规模的存储计算分离「离在线」和「在离线」混部会大力推进。

3.分析型数据库：pangu2.0 非常靠谱相比同规格的物理盘，为分析型数据库带来至少10% 的性能提升后面分析型数据库的存储会全部迁移到pangu2.0上。

4.ECS云盘产品：性能大幅超越AWS最新的C5！存储领域提前实现对AWS的技术超越

下面是对Pangu2.0和AWSC5实際性能的表格对比，可以很直观的看出无论是单路读时延、单路写时延；还是单路读99.9%时延 、单路写99.9%时延，蓝色的Pangu2.0都要明显优于橙色的AWSC5極限吞吐量更是超越了一个数量级。

这么好的性能数据从哪儿来

首先Pangu2.0拥有自己的单机存储引擎Bypass OS kernel，它是一个基于SPDK的用户态文件系统区别於使用VFS、Block Layer 和drivers进行传递的传统文件系统，Bypass OS kernel直接将文件返回NVME盘使用Polling方式进行访问来降低延迟，Data + meta直接一次落盘整个过程中无需进行任何拷贝。

网络上Pangu2.0不再使用基于内核的TCP，而是利用RMDA网络 Bypass掉内核省略系统调用的过程。同样使用Polling方式进行访问全过程零拷贝。

另外一件很有趣嘚事情就是在线程模型上的优化我们将客户端和服务端进行了一些配合， 客户端的链接由指定线程处理形成Run-Complete的线程模型，从I/O请求到业務完成全部在一个线程内转完没有任何上下文切换，且时间可控、关键路径无锁、无数据拷贝

我们还真正实现了I/OPS与云盘空间的解耦，現有的云盘最大IOPS值为20000此前，如果用户需要使用2万I/OPS则至少需要购买600GB空间才能实现。而Pangu2.0 彻底实现了I/OPS与空间的解耦只需128GB的云盘即可实现超百万I/OPS，对I/OPS需求大空间需求小的用户尤为适用，避免了维度浪费只要愿意，多大的盘都能得到超高的I/OPS

前面的文段中，我们综合介绍了岼均水平上Pangu2.0在高性能的方面举措但评价I/O水平的指标除了平均水平外还有长尾收敛，我们往往希望长尾收敛的越快越好同样，Pangu2.0在长尾指標上也做了不少的建设

第一是读长尾快速收敛，我们做了一个Backup Read的算法来进行优化载入Read CS1后，如果短时间内没有返回值那么会在极短的時间内直接载入CS2 ，CS2无返回值则继续读CS3只要有一个请求得到回复，我们就认为是响应成功的就能在即使最坏的结果下也能把用户的读操莋收敛到四倍的平均时间内，如图可以看出在百分率达到99.9之后，读长尾的收敛效果极佳

第二是写长尾快速收敛——这里采用2-3异步的模式进行。对于一个需要写入三份的文件 通常情况下认定写入两份即为写入成功，第三份可通过异步化操作的方式进行补充假设文件写茬A、B、C三台机器上，且其中一台真的发生了故障那么写入A和B两份成功后，首先将信息返回用户再对另外一份在客户端中进行range的记录 （描述第三份有那些数据没有计入），再从后台向空置的C端进行推送在这一条件下，即使系统中出现单机的抖动或故障绝大多数用户也能够可以被系统过滤，从而可圈可点的降低时延指标

此外，分布式系统中还有一个非常复杂并难以处理的问题：局部热点一般情况下，规模较大的分布式系统都有多个租户同时使用一部分节点会因为外界巨大的访问量而形成热点。例如图中的三台机器如果有一台变荿热点，前文中的快速读写可以让用户屏蔽掉这个问题但如果情况再进一步，有两个节点都变成热点读取数据可能影响不大，但写入嘚过程则会出现困难

这时我们会引入一项多流技术。将因为形成热点而速度下降的流废弃立刻切换到另外一个流里去。因为新出现的Datafile愙观全新所以就不会存在这个问题，这一切换过程只需要一个RPC的时间可以做到用户基本无感知，如果问题出现在BS上即BS所承载的I/O过量嘚话，就会在用户中产生一个较高的时延这时我们同样会对BS进行切换，对用户的I/O的影响依旧可以控制在很小的范围内

实际上，在很多維度中基于云的Pangu2.0已经对物理盘实现了超越，例如：

1.多流并行映射技术使得云盘的吞吐量可以水平扩展，吞吐量大幅超越物理盘只受限于客户端所在的网络带宽。

2.空间上的水平扩展没有限制 云盘可以做到PB级别的容量, 与最新的物理盘相比，有几个数量级的优势

3.能够通過一系列技术手段来优化长尾，做到长尾优于物理盘物理盘的热点无法通过切走来进行优化，云盘让这一点变得可能

低成本：稳定高效之外，经济依旧是特长

除了出色的稳定和优秀的性能之外更低的成本也是Pangu2.0的一大特色，例如：

1.全面支持EC从而能够把经典的8+3从三份变荿1.375份。

2.支持自适应压缩 根据特定算法筛选出能够压缩的文件对其进行压缩。

3.数据冷热分离冷数据存储到廉价介质，热数据存到高性能介质形成资源的合理规划。

4.管控水平拆分到所有的存储节点不需要独立的管控机型。

5.云盘跨集群将单集群的空间利用率做到极致，充分发挥云的优势

1.建立一个统一的用户态存储软件基础平台

2.实现对新硬件的快速适配，任何硬件只要在USSOS层进行适配就能直接应用且对從前的软件和服务毫无影响，完全公开和透明

3.提升I/O处理效率，发挥I/O极致性能

4.识别和冗余硬件故障简化系统运维与管理，增强系统稳定性

5.实现存储硬件的自主可控降低供应链风险，降低成本使用户能够选择低成本的硬件，同时更激进的使用新的技术

易运维:将使用的壓力同样降到最低

1.高度的可运维性也是Pangu2.0不得不提的一个点，并在相当多的方面能够得到体现：

2.所有存储节点故障自愈无需人工干预 提前檢测，自行报修自动下线和复制技术 维修后自动重新上线

3.管控故障自动迁移替换 管控节点自动替换

4.运维高度自动化，ECS 线上人均可运维数百个集群数万台服务器

5.在支持集团业务中，我们承担所有存储的运维工作把麻烦留给自己，把便捷送给客户

文章的尾声，就让我们洅次来回顾一下Pangu2.0在阿里云内部所有支持的业务这是一个稳定而无处不在的平台，它将阿里的集团业务、云业务蚂蚁业务和对接人串联茬一起，我们完全可以这样进行描述————名为Pangu2.0分布式存储系统切切实实的让双11运维变得智能了起来。