12月13-14日，由云栖社区与阿里巴巴技术协会共同主办的《2017阿里巴巴双11技术十二讲》顺利结束，集中为大家分享了2017双11背后的黑科技。本文是《省身：分布式存储系统Pangu2.0在双十一中的战役》演讲整理，主要讲解了分布式存储系统Pangu2.0在双11一役中的表现，以及这一系统的架构，研发历程，和在提升系统稳定、强化系统性能、压缩用户成本、以及扩大业务适配等方面所取得的优异成绩。
分享嘉宾：省身
阿里云资深技术专家，2012年加入飞天Pangu团队，主攻分布式存储方向，推动了Pangu2.0在双11期间的全面落地
这篇整理来自于阿里云飞天八部Pangu团队技术专家「省身」在2017阿里双11在线技术峰会中的分享，该分享整体由三个部分构成
1.Pangu2.0在双十一当天的表现
2.Pangu2.0的背景和架构 以及完善这一系统的历程
3.详细介绍Pangu2.0在稳定性，高性能，低成本和业务性上面的一些进展
实测业务支持，在双十一中保持完善与稳定
既然把双11作为一次对Pangu系统的战役，那么胜利的目标就是在业务支持方向达到最佳，事实上，Pangu2.0在双11的业务支持主要由四个部分构成：
1.集团DB
2.中间件
3.列式数据库Histore
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等等。他们的宏观架构都相差不多，具备着成熟的应用环境，完善的就近调度策略，其对线上业务的支持也已经持续了很长的时间。
推出Pangu2.0的原因
这是一个硬件和网络飞速发展的时代，最早做存储系统的时候，主流的网络制式还是千兆网。而如今，双25GB乃至100GB的网络已经逐步的投入使用。最早的存储媒介HDD机械硬盘需要10毫秒的时延才能成功进行访问，而现在NVME的盘时延则比之极低，十微秒之内就能完成一次写入，硬件的时延从毫秒压缩到微秒，使性能瓶颈的逐渐转移到传统的存储软件，传统软件无法适配新的硬件，令时延问题变得突出，必须进行革新来适配硬件的变化
可以举这样一个例子来方便说明——假设过去去美国一趟，飞机需要在空中飞行十个小时 ，中美海关各需要一小时的通关时间，旅程的总时长为12小时。但随着技术的进步，某款超音速客机在一小时就能直接抵达，那么整个旅程就变成了三小时，三分之二的通关时间就显得冗长起来。类比分布式存储系统：开始的时候，因为硬件的瓶颈，软件响应时间的长短并不是突出的矛盾，但随着硬件的提升，这一矛盾的重要性也会日益凸显。我们能够得知：软件必须适应硬件的变化，这是创造良好用户体验的必要前提。
同时，近些年来，用户上传的数据一直在飞速的增长，分布式系统所覆盖的文数件也从十亿级跃升到了千亿级，单纯垂直方向的Scale-up的存储架构已经难以满足用户数据的需要，我们更多的开始需要一个能够水平扩展，不断满足千亿乃至更高级别需求，能够实现Scale-out模式的存储架构
作为通用的存储平台，Pangu系统一直在力求对更多的业务进行支持。完成多业务的的并行发展需要令模块分层更加单元化，以适应不同使用者定制化的需求。Pangu1.0每次发布一个新版本都必须对每种不同业务需求进行综合考量，不仅时间上难以协调，且随着团队的规模逐渐扩大，这样一个单元和模块化不够细致的架构也愈发的不适于一个大团队的开发。亟需一个更加高效的架构，以更好的分层和更好的模块化来满足大团队快速迭代开发的需要。
还有一点，随着近年来专有云，混合云的快速发展，对存储系统独立输出，轻量化输出的需求也越来越强烈，Pangu1.0的输出不够轻量级，敏捷性也略显不足，这个过程也同样是需要加速处理的。
Pangu2.0的总体业务架构
接下来，我们来聊聊Pangu2.0的总体业务架构。它的最底层是物理硬件架构与Datacenter网络，其上则是Pangu的存储系统，里面包括存储节点，分布式系统，存储系统内部的上层辐射出支持的多个业务方向，例如Block FS，LogFil，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.云盘跨集群，将单集群的空间利用率做到极致，充分发挥云的优势。
Pangu2.0的软硬件一体化工作也一直在同步进行，我们与AIS合作，共同研发了USSOS – User Space Storage Operating System，并实现了很多之前所期待的目标：
1.建立一个统一的用户态存储软件基础平台
2.实现对新硬件的快速适配，任何硬件只要在USSOS层进行适配就能直接应用，且对从前的软件和服务毫无影响，完全公开和透明。
3.提升I/O处理效率，发挥I/O极致性能
4.识别和冗余硬件故障，简化系统运维与管理，增强系统稳定性
5.实现存储硬件的自主可控，降低供应链风险，降低成本，使用户能够选择低成本的硬件，同时更激进的使用新的技术。
易运维:将使用的压力同样降到最低
1.高度的可运维性也是Pangu2.0不得不提的一个点，并在相当多的方面能够得到体现：
2.所有存储节点故障自愈，无需人工干预 提前检测，自行报修，自动下线和复制技术 维修后自动重新上线
3.管控故障自动迁移替换 管控节点自动替换
4.运维高度自动化，ECS 线上人均可运维数百个集群，数万台服务器
5.在支持集团业务中，我们承担所有存储的运维工作，把麻烦留给自己，把便捷送给客户。
文章的尾声，就让我们再次来回顾一下Pangu2.0在阿里云内部所有支持的业务，这是一个稳定而无处不在的平台，它将阿里的集团业务、云业务，蚂蚁业务和对接人串联在一起，我们完全可以这样进行描述————名为Pangu2.0分布式存储系统，切切实实的让双11运维变得智能了起来。
