面向云数据库，超低延迟文件系统PolarFS诞生了

原标题：面向云数据库，超低延迟文件系统PolarFS诞生了阿里妹导读：随着国内首款Cloud Native自研数据库POLARDB精彩亮相ICDE 2018的同时，作为其核心支撑和使能平台的PolarFS文件系统的相关论文"PolarFS: An Ultra-low Latency and Failure Resilient Distributed File System for Shared Storage Cloud Database"也被数据库顶级会议VLDB 2018录用，VLDB 2018将于8月份在巴西里约召开。本文着重介绍PolarFS的系统设计与实现。背景如同Oracle存在与之匹配的OCFS2，POLARDB作为存储与计算分离结构的一款数据库，PolarFS承担着发挥POLARDB特性至关重要的角色。PolarFS是一款具有超低延迟和高可用能力的分布式文件系统，其采用了轻量的用户空间网络和I／O栈构建，而弃用了对应的内核栈，目的是充分发挥RDMA和NVMe SSD等新兴硬件的潜力，极大地降低分布式非易失数据访问的端到端延迟。目前，PolarFS的3副本跨节点写入的访问总延迟已经非常接近单机本地PCIe SSD的延迟水平，成功地使得POLARDB在分布式多副本架构下仍然能够发挥出极致的性能。设计初衷针对数据库设计分布式文件系统会带来以下几点好处：此外，云数据库服务也会因此带来额外的收益：系统结构系统组件PolarFS系统内部主要分为两层管理：PolarFS的系统结构如图所示：在进一步介绍各部分之前，我们先来了解下PolarFS存储资源的组织方法：PolarFS的存储资源管理单元分为3层：Volume、Chunk、Block。★VolumeVolume是为每个数据库提供的独立逻辑存储空间，其上建立了具体文件系统供此数据库使用，其大小为10GB至100TB，可充分适用于典型云数据库实例的容量要求。在Volume上存放了具体文件系统实例的元数据。文件系统元数据包括inode、directory entry和空闲资源块等对象。由于POLARDB采用的是共享文件存储架构，我们在文件层面实现了文件系统元数据一致性，在每个文件系统中除DB建立的数据文件之外，我们还有用于元数据更新的Journal文件和一个Paxos文件。我们将文件系统元数据的更新首先记录在Journal文件中，并基于Paxos文件以disk paxos算法实现多个实例对Journal文件的互斥写访问。★Chunk每个Volume内部被划分为多个Chunk，Chunk是数据分布的最小粒度，每个Chunk只存放于存储节点的单个NVMe SSD盘上，其目的是利于数据高可靠和高可用的管理。典型的Chunk大小为10GB，这远大于其他类似的系统，例如GFS的64MB。这样做的优势是能够有效地减少Volume的第一级映射元数据量的大小（例如，100TB的Volume只包含10K个映射项）。一方面，全局元数据的存放和管理会更容易；另一方面，这使得元数据可以方便地缓存在内存中，从而有效避免关键I/O路径上的额外元数据访问开销。但这样做的潜在问题是，当上层数据库应用出现区域级热点访问时，Chunk内热点无法进一步打散，但是由于我们的每个存储节点提供的Chunk数量往往远大于节点数量（节点:Chunk在1:1000量级），PolarFS可支持Chunk的在线迁移，并且服务于大量数据库实例，因此可以将不同实例的热点以及同一实例跨Chunk的热点分布到不同节点以获得整体的负载均衡。★Block在ChunkServer内，Chunk会被进一步划分为多个Block，其典型大小为64KB。Blocks动态映射到Chunk 中来实现按需分配。Chunk至Block的映射信息由ChunkServer自行管理和保存，除数据Block之外，每个Chunk还包含一些额外Block用来实现Write Ahead Log。我们也将本地映射元数据全部缓存在ChunkServer的内存中，使得用户数据的I／O访问能够全速推进。下面我们详细介绍PolarFS的各个系统组件。★libpfslibpfs是一个轻量级的用户空间库，PolarFS采用了编译到数据库的形态，替换标准的文件系统接口，这使得全部的I／O路径都在用户空间中，数据处理在用户空间完成，尽可能减少数据的拷贝。这样做的目的是避免传统文件系统从内核空间至用户空间的消息传递开销，尤其数据拷贝的开销。这对于低延迟硬件的性能发挥尤为重要。其提供了类Posix的文件系统接口（见下表），因而付出很小的修改代价即可完成数据库的用户空间化。★PolarSwitchPolarSwitch是部署在计算节点的Daemon，它负责I/O请求映射到具体的后端节点。数据库通过libpfs将I/O请求发送给PolarSwitch，每个请求包含了数据库实例所在的Volume ID、起始偏移和长度。PolarSwitch将其划分为对应的一到多个Chunk，并将请求发往Chunk所属的ChunkServer完成访问。★ChunkServerChunkServer部署在后端存储节点上。一个存储节点可以有多个ChunkServer。每个ChunkServer绑定到一个CPU核，并管理一个独立的NVMe SSD盘，因此ChunkServer之间没有资源争抢。ChunkServer负责Chunk内的资源映射和读写。每个Chunk都包括一个WAL，对Chunk的修改会先进Log再修改，保证数据的原子性和持久性。ChunkServer使用了3DXPoint SSD和普通NVMe SSD混合型WAL buffer，Log会优先存放到更快的3DXPoint SSD中。ChunkServer会复制写请求到对应的Chunk副本（其他ChunkServer）上，我们通过自己定义的Parallel Raft一致性协议来保证Chunk副本之间在各类故障状况下数据正确同步和保障已Commit数据不丢失。★PolarCtrlPolarCtrl是PolarFS集群的控制核心。其主要职责包括：PolarCtrl使用了一个关系数据库云服务用于管理上述metadata。中心统控，局部自治的分布式管理分布式系统的设计有两种范式：中心化和去中心化。中心化的系统包括GFS和HDFS，其包含单中心点，负责维护元数据和集群成员管理。这样的系统实现相对简单，但从可用性和扩展性的角度而言，单中心可能会成为全系统的瓶颈。去中心化的系统如Dynamo完全相反，节点间是对等关系，元数据被切分并冗余放置在所有的节点上。去中心化的系统被认为更可靠，但设计和实现会更复杂。PolarFS在这两种设计方式上做了一定权衡，采用了中心统控，局部自治的方式：PolarCtrl是一个中心化的master，其负责管理任务，如资源管理和处理控制平面的请求如创建Volume。ChunkServer负责Chunk内部映射的管理，以及Chunk间的数据复制。当ChunkServer彼此交互时，通过ParallelRaft一致性协议来处理故障并自动发起Leader选举，这个过程无需PolarCtrl参与。PolarCtrl服务由于不直接处理高并发的I／O流，其状态更新频率相对较低，因而可采用典型的多节点