盘古分布式存储系统的稳定性实践
内容介绍：
一、飞天盘古的整体介绍
二、飞天盘古的稳定性实践
三、总结
本次分享的主题是盘古分布式存储系统的稳定性实践，由阿里云智能集团资深技术专家董元元分享。
今天分享的是分布式存储系统盘古的稳定性实践。整个分享内容分为三个部分：首先是对盘古系统的整体概述；接着是深入探讨盘古的稳定性实践；最后是总结环节。而今天的核心内容将聚焦于稳定性实践，具体涵盖数据的高可靠性、系统的高可用性，以及安全高效的生产运维这三个关键方面。
一、飞天盘古的整体介绍
盘古是阿里云针对云计算全栈自主研发的分布式存储系统，它基于通用服务器构建，规模庞大。然而，盘古并非阿里云直接面向市场的存储产品，而是作为飞天云操作系统的核心组件，扮演着阿里云统一数据存储底座的角色，为外部提供服务。具体而言，阿里云的各类存储产品，如块存储、对象存储、文件存储、表格存储，以及面向专有云的CDS产品，均是基于盘古构建的。
这些基于盘古的存储产品，支撑起了阿里巴巴几乎所有的数据存储业务，包括阿里巴巴集团的电商核心交易系统、阿里云的计算内大数据产品，以及数据库产品等。如此众多的业务依赖于盘古，这就要求盘古必须满足各业务共性的需求，这些需求可以总结为以下五个方面：
首先是稳定性，即存储数据必须做到高可靠性，确保数据不丢失、不出错。同时，服务也需要具备高可用性，系统服务不能中断，能够持续在线并支持多重容灾。
其次是规模性，盘古能够灵活支持从小到大的不同规模部署，最少支持4台服务器即可部署一个盘古集群，最大则可支持单集群数万台服务器，以满足不同业务对规模的需求。
第三是普适性，盘古能够支持多种业务场景，包括DM业务和高存储业务，同时也能够支持多种硬件介质，如闪存、非易失性存储和磁盘介质。此外，它还支持多种硬件平台，如UX86平台、ARM平台等。
第四是性能，盘古通过软硬件协同设计以及大规模应用RDMA技术，实现了用户网络VUM级的低延迟。例如，基于盘古的ESD云盘，可以单盘提供高达100万的IOPS，延迟控制在100余秒以内。
最后是存储能力，盘古为OS盘和VS的每个租户提供了100G的存储能力，为后台存储提供了坚实的基础。在安全性方面，盘古还支持数据默认加密功能。
二、飞天盘古的稳定性实践
稳定性虽非新话题，却是众多业务系统需面对却非轻易能解决的共性问题。其之所以成为挑战，在于它是一个宽泛且抽象的目标，涵盖系统架构设计、开发、测试、线上运维等多个环节。任何一环的疏漏都可能引发稳定性风险。对于存储系统而言，稳定性尤为关键，主要体现在以下三个方面：
首先是数据高可靠性，即确保数据既不丢失也不出错，这是存储系统的基石。然而，在实际操作中，这一诉求往往难以实现。
其次，系统高可用性是另一大挑战。由于盘古运行所依赖的软硬件环境复杂多变，故障频发，数据丢失的风险始终存在。因此，我们不仅要确保数据服务的高可用性，还要保障服务在故障发生时能够持续运行，并在约定的时间内完成响应。
最后，安全生产运维也是不可忽视的一环。盘古部署规模大，支持的业务种类繁多，访问模式各异，这无疑增加了安全生产运维的难度。
在数据高可靠性方面，我们主要关注数据不丢和数据不错两个方面。数据丢失的问题主要源于硬件故障和数据未持久化。硬件故障，如服务器和磁盘的持续故障，若超出系统容忍范围，将导致数据丢失。此外，若数据未写入盘片即发生集群断电，也存在数据丢失的风险。在软件设计层面，若数据未持久化即返回用户成功，同样会导致数据丢失。
为了保障数据不丢，盘古采用多副本，如三副本策略，确保数据强一致写入盘片后才返回用户成功。多个副本分布在不同的故障域，故障发生后能自动进行数据复制和恢复。同时，我们还实现了坏盘自动检测和ICD盘寿命性检测，以便在磁盘故障或寿命到期时主动替换，避免数据丢失风险。
故障后的数据恢复依赖于数据复制能力，该能力决定了系统对节点或磁盘故障的容忍程度。为了降低成本，业务可能采用大容量磁盘、高密机型以及第一种比例93码的编码方案，这都对数据复制提出了更高要求。例如，大容量机型故障后复制时间较长，若此期间更多节点出现故障，则数据丢失风险增加。
因此，盘古对数据复制进行了大量优化。一方面，我们实现了数据复制任务在全局集群范围内的并发调度和执行，提高数据复制吞吐能力，加快数据恢复速度。另一方面，我们基于优先级和节点负载进行动态任务调度，确保高优先级的数据能够更快恢复。
第三个优化策略是能够基于前台流量进行动态的流量调度。在集群节点数固定的情况下，其总吞吐能力相对恒定。因此，在业务流量低谷时段，我们可以提高数据复制的吞吐能力，以加速数据恢复；而在业务负载高峰时段，则降低数据复制的带宽，将更多吞吐能力分配给前端用户，从而减少对前端用户的干扰。通过这种流量削峰填谷的方式，我们实现了低干扰、高效率的数据复制，提升了节点故障后的数据恢复能力。
关于如何保证数据不出错，其风险来源与数据丢失有所不同。在硬件层面，可能存在磁盘故障、网络传输错误以及CPU的生态cropping导致的数据错误。在软件层面，则可能涉及软件缺陷、内存错误、指针异常等问题。
保证数据不出错的常规方案是基于CRC的数据校验。在业务写入数据时，同时生成数据的CRC校验码。在写入路径上，会对数据和CRC进行校验，一旦发现数据和CRC不匹配，即报错返回。这种方式可以确保在数据写入过程中，如果因软件错误、内存故障或网络传输中的比特反转导致数据出错，能够通过CRC校验识别出错误数据，从而避免错误数据的写入。
在数据读取过程中，也采用类似的校验机制。在返回用户数据之前，会对数据和CRC进行校验，以避免返回错误数据。同时，盘古后台也会定期对数据和CRC进行校验，以发现存储在磁盘上的数据错误。
然而，即便有了CRC校验，也不能完全保证数据的正确性。因为在实际应用中，还存在一些特定场景可能导致数据错误。例子如下。
一个因CPU标准问题导致的数据错误，简称SDC，是由于硬件故障使得CPU产生了错误数据，但CPU自身并未检测到此错误。这种异常通常源于HDC，其成因颇为复杂。简而言之，它可能是在制造过程中未被检测出的随机缺陷，或在使用过程中因温度、电压、频率等因素引发的电路边缘性故障。其实实际上，多家大厂如Google、Facebook以及阿里云已经发现并分析了CPU的SDC问题。阿里云采取了一系列措施，对存在CPU、SDC问题的服务器进行拦截，避免其上线。然而，这种方法并不能完全避免系统运行过程中CPU、SDC问题的出现，它仍可能导致数据错误。因此，系统软件层面的防护仍然必不可少。
CPU的SDC可能导致数据在计算过程中出错，如纠删码的编码、解码、数据加密、压缩等环节，甚至可能导致数据的元数据发生错误。而且，CPU 、SDC导致的数据错误和元数据错误是无法通过3C校验发现的
以世界阿里算码为例进行说明。纠删码的编码过程是对数据进行切片，然后计算出校验块，并对切片后的数据与原始数据使用CRC进行校验。这种方式可以确保在编码过程中输入数据的正确性。但它无法保证在CPU的SDC发生时，计算过程不受影响，从而可能产生错误的校验块。由于这些校验块在生成时并未使用CRC进行预先校验，因此无法识别出其中的错误，进而引发数据错误。
针对这类问题，盘古采用的方案是数据副本间的交叉校验。从算法层面来看，这相当于对数据先进行编码，再解码，然后用解码后的数据与原始数据进行对比，以确保计算过程的正确性。但这种方式会增加较大的计算开销。为此，盘古还进行了一系列计算优化，以及数据加密压缩和类似的数据交叉校验方法，以避免CPU SDC引入的数据错误。
然而，CPU的SDC还可能引发数据的元数据错误。为了解决这个问题，盘古为所有数据块设计了一个实际化的数据块结构，其中包含了自包含的元数据。这些自包含的元数据也使用CRC进行校验。在自包含的元数据中，还会与系统中的元数据进行交叉对比，以确保数据块元数据的正确性。
通过这一系列措施，盘古在保障数据正确性方面积累了丰富的经验。在所有涉及数据正确性的IO路径上，我们不仅采用了完备的基于实验室的端到端数据校验，还设置了多级的交叉校验方式，如数据副本间的交叉校验、数据与元数据的一致性交叉校验等机制。
接下来是保障系统高可用方面的实践经验。在大规模部署的环境下，盘古运行的软硬件环境中的小概率故障已成为常态。
这是系统极简的模块图，图中的每个模块以及连接模块之间的网络都存在潜在的故障风险，这些故障都可能影响服务的可用性。例如，硬盘有4%的年化故障率，机器有2%的日宕机概率，网络则可能出现中断、丢包、重传以及网络分区等问题。原数据服务和业务进程同样会受到机器宕机、硬盘故障以及网络故障的影响，进而威胁到服务的可用性。此外，机房还可能遭遇断网、断电、升温等突发事件，导致AZ级别的故障。在这种背景下，盘古不仅要确保服务不中断，还要在约定的时间内完成响应。
我们将从数据节点和硬盘故障、原数据节点故障以及AZ级故障三个方面来介绍盘古采用的高可用实现方案。
首先，数据节点和硬盘的异常种类繁多，对业务可用性的影响显著，可能导致业务请求超时或延迟大幅增加。例如，数据节点或硬盘可能因故障而无法响应请求，导致业务请求超时；或者集群中部分节点和硬盘性能明显落后于其他节点和硬盘，导致业务请求响应缓慢，造成请求堆积；系统中存在的热点也可能导致业务请求响应时间变长。
针对这些问题，盘古的解决方案是对节点和硬盘进行实时异常检测。一旦判定访问的数据节点或硬盘出现异常，便将其加入黑名单。在读写IO路径上，采用主动规避机制来避开这些异常的节点和硬盘，从而确保延迟和响应的稳定性。当然，系统检测异常的时间决定了在遇到顺序阶段和排除异常后，对业务延迟影响的时间。盘古通过实时的IO统计信息结合硬件异常事件等，可以在1秒钟之内检测到异常。这样，在数据节点或硬盘出现异常后，对业务的影响时间可以控制在一秒钟以内。而且，在检测到数据节点和硬盘故障后，盘古还采用了一系列主动异常规避机制，如备份读、写亦不写、缺串和重试等，可以将这段时间内对业务的影响控制在毫秒级。
其次，原数据服务也会受到服务器和网络故障的影响。在分布式系统中，这些原数据故障对系统可用性的影响往往更大。因此，盘古也采取了一系列措施来降低原数据服务对系统可用性的影响。盘古构建了分布式元数据管理系统，在整个集群中采用多种元数据来管理。这样，在单组元数据出现故障后，可以降低故障的影响范围。
再者，每组原数据服务都是高可用的，能够容忍一定数量的节点故障。在组件故障后，能够快速进行组织切换，保证系统的高可用性。此外，在数据路径上，盘古还能主动判定原数据服务的健康状态。即使高可用服务出现异常，也可以在数据路径上主动对其进行降级处理，确保读写打开的文件读写流程不会中断。
还有一种影响服务可用性的场景是业务进程故障。由于节点或硬盘故障可能导致业务进程崩溃。针对这种场景，盘古提供了原数据和数据的分析机制，支持业务进程进行更快的HA切换。基于盘古的分析机制，业务进程的HA切换可以在1秒钟以内完成。这意味着业务进程在故障后，可以在1秒钟内切换到备用服务，极大地提升了业务系统的可用性。
最后，机房可能出现的断网、断电、升温等故障也是不容忽视的。这类问题已经多次发生。这就要求业务具备多AZ的容灾能力。为了满足业务的这一需求，盘古支持同城多AZ部署，主要采用3AZ方案，同时也支持2AZ或更多AZ的部署。以3AZ部署为例，盘古的数据和原数据在3AZ内均匀分布，并同步写入。在任何一个AZ出现故障后，系统能在一分钟内检测到故障，并采用2AZ方案来降级服务。在采用2AZ降级服务后，数据在两个AZ中仍有足够的冗余，不会存在数据丢失的风险。此外，在故障的AZ恢复后，数据也能自动恢复到3AZ的分布状态。
基于盘古提供的数据持久化能力以及同城多AZ容灾能力，业务可以更容易地实现业务侧的多AZ容灾。例如，对象存储、块存储以及表格存储等都基于盘古实现了多AZ容灾。阿里云曾多次遭遇机房级故障。在这种情况下，单AZ部署的业务出现了服务中断，并面临了较大的数据风险。但多AZ部署的业务都能够快速地进行自动降级和恢复服务，且没有数据损失。
以上是在系统架构和设计的层面，盘古在保障数据不丢不错、系统高可用方面的实践经验分享。
接下来，我将介绍盘古在安全生产方面的实践经验。在全面、大规模部署复杂运行环境及业务场景时，我们依然会面临多种风险。例如，线上配置错误可能导致系统处于风险状态，若未能及时发现，将引发更大隐患。此外，软件中的低概率Bug、硬件在特定模式下的访问失效、资源配置不足以及业务高峰期的稳定性风险等问题，都可能导致系统出错，正如那句老话所说：“凡是可能出错的事情，那必定会出错。”这些在盘古的大规模应用过程中，都得到了多次验证。
第一个经验是故障演练。故障演练旨在两个方面进行提升：一是检验系统能力，即在极小概率的大规模故障发生时，系统的行为是否符合预期，告警是否及时准确，以及故障应急处理的预案和工具是否完备；二是锻炼故障处理机制，即在大规模故障处理过程中，不同角色人员的配合是否高效，应急决策是否合理，以及整个应急处理的操作是否熟练且合理。
故障演练的场景可以分为三类：第一类是What-if演练，即模拟各代组件发生大规模异常时的影响，并评估这些影响是否符合预期，以及是否存在改进空间；第二类是数据正确性及恢复能力演练，即模拟系统注入导致数据丢失、错误或不一致的故障，检验系统是否具备数据不丢、不错的能力，或在故障超出系统容忍范围后，是否有足够的工具恢复数据；第三类是对机房进行断电、断网等AZ级故障演练，以检验盘古是否具备AZ级容灾能力。
在故障演练的形式上，我们主要采用红蓝双方突袭演练的方式。红方负责注入故障，并观察和记录系统行为及故障处理过程的合理性；蓝方则在收到故障报警后，紧急启动故障处理流程，以快速恢复服务。演练结束后，红蓝双方会共同对系统行为及故障处理过程进行时间线分析和复盘，以找出不足并提出改进措施。对于已多次演练且较为成熟的场景，我们会将其加入自动演练平台，实现常态化演练。
通过这些故障演练，我们不断推动系统优化，完善故障处理机制和预案，并锻炼应急处理能力，以确保在真正发生重大故障时，能够尽量降低影响时间，缩短恢复时间。
第二个经验是实施自动化的发布编排，并严格执行发布的灰度策略。发布是线上生产稳定性风险的重要来源之一。为了降低发布风险，我们构建了自动化的发布系统，并严格执行灰度发布策略。发布过程被分为多个批次，从低影响区域到高影响区域，从少量集群到大量集群逐步推进。同时，发布过程也在多个核心区域进行错开，以避免对业务造成同时的多个影响。
在发布过程中，系统会自动进行巡检，一旦发现异常就会暂停发布。对于高风险问题，系统会自动进行回滚。对于已发布的问题及高风险问题，系统会进行标记并阻塞后续发布，直到问题解决。根据最近几个月的统计数据，盘古在全网、全业务的每月发布次数超过了2500次。通过这种高频发布及自动化能力，我们能够快速上线功能并解决线上风险问题，且对业务完全无影响。
保障安全生产的第三个经验是进行集群健康度检查和自动化治理。这是盘古应对系统运行潜在风险的重要机制。集群健康度检查类似于人的体检，通过高频检查能够确保系统处于健康运行状态。集群健康度检查的指标包括系统参数、硬件故障、软件配置一致性、系统运行状态等。通过集群架构检查，我们可以统一线上风险的管理和治理，规范线上运行环境。
对于检查中发现的问题，我们会开出工单并跟进修复。对于常见问题，我们会实现自动化修复过程，以降低运维负担。目前，在整个系统中累积的系统监控项有八千多项，提炼出的自动化巡检指标有一千多项。根据最近几个月的统计数据，每天能够发现并自动化修复两千多项线上问题。通过这种方式，极大地增强了系统在线上运行的稳定性。
三、总结
最后，提出两个观点。首先，稳定性是一项系统工程。盘古通过面向容错的系统设计以及多重的事务处理机制，确保数据的完整性和准确性，即保证数据不丢、不错。此外，盘古还具备多重故障恢复优化技术和分布式元数据容灾能力，这些措施共同保障了系统的高可用性。更为先进的是，盘古能够在服务不中断的同时，有效屏蔽异常对系统性能的影响。为了保障现场的安全生产，盘古还采用了故障演练、自动化发布、自动化的健康检查以及高效的运维手段等多种措施。
其次，稳定性不是一蹴而就的，它需要持续不断的迭代演进。作为阿里云的统一数据存储底座，盘古已经经历了阿里集团和阿里云等核心产品十年以上大规模的线上锤炼。
