2.4.2 盘古
1.盘古架构
如前所述，盘古是阿里云大底座飞天（Apsara）的核心组件之一，它本质上是一个分布式文件系统。秉承“云”的设计思想，盘古将并不高可靠的PC服务器中的磁盘连接成一个整体，向外提供安全、稳定、易用的文件存储能力。如果将盘古的架构抽象到极致，我们会看到一个经典的分布式文件系统设计，如图2-49所示。
图2-49 盘古的极简架构
从图2-49可以看出，盘古架构类似于GFS（Google文件系统），盘古系统是基于GFS原理实现的，大家所熟知的HDFS（Hadoop文件系统）也是基于GFS实现的。当然，盘古的功能和复杂性远不是上面这个极简的架构图所能描述的。限于篇幅，这里只是简单介绍盘古架构组成及原理。盘古整个架构大致分为以下几个部分：
● 存放元数据（Metadata）的管控层，我们称其为PanguMaster。
● 存放数据（Data）的服务层，我们称其为ChunkServer。而ChunkServer又可以被进一步划分为：
- 对底层硬件进行适配和抽象的存储适配层。
- 负责数据存放和管理，提供高性能I/O的存储引擎层。
- 向上层云产品提供API、实现存储协议的服务接入层。
（1）PanguMaster
为了满足高可用和一致性，图2-49中的PanguMaster需要被扩展成图2-50所示的样子——一个使用RAFT协议的三副本集群，图中PM表示一个PanguMaster节点。
在这样的架构中，一个PanguMaster集群至少由3个PanguMaster（以下简称PM）节点组成，数据在3个PM中同步，平时由一个PM对外提供服务。这个提供服务的PM被称为Primary节点，此时其他的PM被称为Secondary节点。这样一个三节点的集群可在最多1（（3-1）/2=1）个PM发生故障时依旧保证服务可用。
图2-50 盘古的扩展架构
为了提高服务速度，PM的数据都被存储在内存中。为了回收磁盘空间和加速节点重启速度，PM会周期性地将内存中的状态写到磁盘上，称为checkpoint（cpt）文件。同时，每次对元数据的修改都会被记录到oplog（Operation Log）中。用户的写操作，只有当Primary节点和至少一个Secondary节点的oplog落盘成功以后才能得到返回。为了保证该落盘操作不成为PM的性能瓶颈，盘古会要求PM本地有极低延迟的磁盘作为存储设备，如NVMe SSD。
以上所说的数据，指的都是用户数据的元数据。在一个文件系统中，元数据的核心作用是描述数据的物理位置，即数据寻址。而在分布式文件系统中，一个文件通常是被分成多片存放在不同节点上的，盘古这个分布式文件系统也不例外。在图2-50所示的架构中，一次数据的读取过程大致如下：
①客户端通过“pangu：//{盘古集群地址}/{对象路径}”向PM发起读取一个对象的请求，在客户端的上层应用系统里，这个对象可能是一个文件或一个目录。PM在本地记录中找到该对象的元数据，并返回给客户端。
②客户端根据所获取的元数据信息，与各ChunkServer（以下简称CS）进行点对点通信，申请该CS上的数据分片（Chunk），CS则向客户端返回该数据分片的数据流。
③客户端在本地根据元数据中数据分片的组合信息，将数据分片拼接成完整的数据并返回给自己的上层应用，完成一次读取。
一个写操作在CS上的行为会与读操作有些区别，但在数据寻址上两者没有本质的不同。从上面内容可以看到，从一个客户端请求的对象到CS上的数据分片，中间需要经过两个寻址过程：
①PM根据客户端请求中提供的对象路径，定位该对象存储于PM本地的元数据。这是请求对象→元数据的寻址。
②根据元数据中记录的该对象的所有数据分片信息，定位需要访问的CS。这是元数据→物理位置的寻址。
PM使用了图2-51所示的这样的目录树来组织文件。从根目录“/”开始，图中每一个节点都是一个文件，内容是客户端读取的对象的元数据。该元数据中除了有节点自身的信息，还有其所含的子目录或子文件（统称“子entry”，如果有的话）统计信息。这些子entry都经过了哈希（Hash）处理，这让客户端通过“pangu：//{盘古集群地址}/a/d”访问文件d时，可以快速定位到d节点。这便完成了请求对象→元数据的寻址。
图2-51 盘古文件系统目录树
一个节点文件中包含了其数据分片的信息，每个数据分片的信息中都带有它所在的CS和该CS上的副本所在的磁盘信息。数据分片通过全局唯一的chunkID进行标识，客户端使用这个chunkID向CS索要数据。于是，这便完成了元数据→物理位置的寻址。
（2）ChunkServer
①ChunkServer诉求
如上所述，PanguMaster是用来保存元数据的模块，而ChunkServer是用来保存数据的模块。众所周知，商用服务器环境是不可靠的，一般来说，硬盘年化故障率为1%～5%，服务器年化故障率为2%～4%。一个典型的数据中心在运行中会遇到各种问题，如硬件故障、软件Bug、网络抖动乃至人为错误等，这些都是数据中心日常的一部分。分布式存储系统的本质就是利用副本冗余实现容错，在非可靠环境中实现可靠的存储。然而，保证数据的安全和可靠只是用户对一个分布式存储系统最基本的要求。此外，对系统还有如下要求：
● 系统的可用性，即任何时候都可以正常读/写数据。
● 性能，其中包括访问延迟、吞吐量和IOPS。
● 横向扩展能力。
● 易用性和通用性，这对于阿里云所有存储产品的共同底座盘古来说尤其重要。
● 尽量低的单位容量成本。
为满足这些要求，ChunkServer在软件架构层面增加了服务接入层、存储引擎层和存储适配层。鉴于整个架构的复杂性，此处只简单介绍ChunkServer的副本复制原理，其是提高数据可靠性的关键。
②副本复制
对数据可靠性而言，写操作是关键，像盘古这类分布式文件系统都是通过增加副本数量来对抗硬件介质的损坏的，副本越多，数据可靠性就越高，但副本数量的增加也意味着写操作性能的下降。根据CAP理论，3个副本可以同时兼顾数据可用性和可靠性，所以盘古系统默认也采用三副本方案，即一个数据分片会被复制成3个副本，存放于3个CS上，并且PM会确保使用的是3个不同机架上的CS。CS通过副本复制（Replication）模块向其他CS上进行副本复制，每个数据分片的每次写都会进行副本复制。一般来说，有两种情况需要进行副本复制。
● 客户端使用了Y型写方案（如图2-52所示），即客户端先写3个副本所在CS中的一个CS，然后由这个CS对剩下的两个CS进行副本复制。
图2-52 Y型写方案
● 环境中出现了损坏的副本。PM发现有副本损坏时，会生成一个副本复制任务下发到其他有该数据分片副本的CS上发起副本复制。复制的目标CS包含在副本任务描述中，由PM根据副本的分布策略指定。副本存放策略需要应对的是机架级别的机房故障，图2-53描述的就是在最坏情况下副本的复制过程，其中3种形状分别代表一个数据分片的3个副本。
图2-53 坏副本复制过程
2.盘古扩展
盘古对上层存储产品提供了丰富的接口和SDK，并持续地丰富自身功能以满足这些产品的需求。比如块存储服务（Block Device Service）、快照服务（Snapshot Service）、NAS（Network Attached Storage）等都是利用盘古的扩展性开发的服务。对于这些存储产品，感兴趣的读者可以访问阿里云官网进行更多的了解。