深入浅出分布式存储的设计与优化之道
随着信息化程度的不断提高，全球数据日益膨胀。面对当前PB级的海量数据存储需求，传统的存储系统在容量和性能的扩展上存在瓶颈。云存储以其扩展性强、性价比高、容错性好等优势得到了业界的广泛认同。由于其前瞻性，众多企业都将其作为进军云计算的第一步。分布式文件系统和分布式块存储作为云存储中重要的技术，成为奠定云存储发展的重要基石。
对于大多数专注于云计算本身的IT技术人员来说，对分布式文件系统和分布式块存储未必有深入的了解。为此，UCan下午茶-武汉站，我们邀请了分布式文件系统、分布式块存储以及云存储相关的技术专家，一起聊聊分布式存储的那些事儿。
分布式文件系统产品架构解析--UCloud 邓瑾
分布式存储产品在各类产品业务中是必不可少的基础设施，了解存储产品的设计思路及使用场景，可以让用户更好地基于存储产品构建自己的业务逻辑。来自UCloud 文件存储研发工程师邓瑾，围绕UCloud分布式文件系统UFS的设计理念和开发实践，分享了如何解决业务多样性对存储产品的要求、如何解决前一代产品中遇到的局限性以及如何避免同类的开源产品的瓶颈等难题。
邓瑾认为，分布式文件系统是传统文件系统的延伸，用户可以通过分布式技术手段和公有云规模效应，获取传统文件系统所没有的存储能力：1）scale out: 容量和性能的线性/近线性提升；2）fault tolerant: 屏蔽硬件故障，提升数据可靠性与系统可用性；3）lower TCO & pay-as-you-go: 这是云计算产品所独有的特性，它能够给应用层的用户提供一些比较低的TCO。
UFS（UCloud File System）是UCloud完全自主研发、面向公有云业务设计的高可用/高可靠文件存储服务。设计之初，研发团队主要是利用开源软件GlusterFS快速在公有云环境中进行产品原型验证，但在运营过程中发现，GlusterFS在多租户的公有云环境中有较多的痛点和难点，如规模拓展性具有瓶颈(peering开销大)，节点数量受限；无法进行多集群的管理与灰度管理；索引操作容易引起高IO从而影响数据操作性能，小文件访问和大目录操作性能极差等等，基于这些问题，UCloud最终决定进行自研产品的设计改进。
根据开源方案运营的痛点，UCloud首先将索引和数据分离，自定义的索引结构和语义，便于后续拓展非 NFS 协议；然后独立设计的存储服务，支持 set 管理、灰度等策略；此外，设计支持百万级大目录和TB+文件大小并支持QoS，对多租户场景下的用户访问进行隔离；最后，通过数据加密与切片策略，保证数据的安全性。下图为UFS 1.0 的方案架构。
通常，一个成熟的架构需要经历发现问题->改造实践->发现新问题->再改造升级的过程，通过这种不断的迭代升级，最后趋于稳定，UFS架构亦如是。在运营过程中，UCloud存储研发团队发现UFS 1.0方案仍然一些局限性，如存储模型比较适合小分片场景，不够通用；固定的底层存储分片造成了一定的空间浪费；存储层支持的文件尺度较小；对随机写的支持不够等等。因此，团队在UFS 1.0的基础上进行了新一轮架构升级。
新架构对存储层做了优化，采用了append-only 模型，如下图，Stream代表一个文件流，可在尾部追加；Extent是stream中的数据分片，分片大小不固定，每个extent 以文件的形式落地。在数据层，由streamsvr负责维护stream和extent的索引/路由信息，extentsvr维护extent内的block索引信息，提供直连客户端的读写请求。
插件式的引擎设计，可以降低写入毛刺，并充分利用内存buffer降低读毛刺。此外，为了解决底层存储引擎随机写不友好的问题，系统采用了FileLayer设计，对热点数据进行缓存，降低存储压力。
分布式存储中的数据分布算法--奥思数据 李明宇
数据分布算法是分布式存储的核心技术之一，不仅仅要考虑到数据分布的均匀性、寻址的效率，还要考虑扩充和减少容量时数据迁移的开销，兼顾副本的一致性和可用性。奥思数据创始人兼CTO 李明宇现场分析了几种典型的数据分布算法的优缺点，并分享了具体实现中会遇到的一些问题。
一致性哈希算法因其不需要查表或通信过程即可定位数据，计算复杂度不随数据量增长而改变，且效率高、均匀性好、增加/减少节点时数据迁移量小等特性受到开发者喜爱。但具体到实际应用中，这种算法也因其自身局限性遇到了诸多挑战，如在"存储区块链"场景下，几乎不可能获取全局视图，甚至没有一刻是稳定的；企业级IT场景下，存在多副本可靠存储问题，数据迁移开销巨大。
所谓存储区块链，可以理解为分布式存储（p2p存储） + 区块链，它通过token激励，鼓励大家贡献存储资源，参与构建一个全世界范围的分布式存储系统。因为需要激励大量用户自发参与，因此会涉及上亿甚至几十亿节点的寻址和路由问题，目前业界主要的解决方案主要有Chord、Kademlia等。不过，Chord算法效率较低，会产生较高延迟，可以采用Finger table，除了记录当前节点以及下一节点位置，同时还记录当前节点2^i+1的位置，降低计算复杂度，最终降低延迟。
企业级IT场景下，数据分布算法包括Dynamo、Ceph的CRUSH、Gluster的Elastic Hashing以及Swift的Ring等。这些算法都有相似的特点，首先它们都是基于/借鉴一致性哈希，增加/减少节点时数据迁移量小。其次，引入对数据中心物理拓扑的建模（Cluster Map），数据多副本 / EC分片跨故障域 / 可用区分布。另外，这些算法还可以对节点划分权重，数据分布和容量/性能匹配，辅助扩容。
总体来说，这两类方案均是基于一致性哈希算法实现，只是因为需求不同，才有了不同的改进方向。企业级更注重副本故障域的分布；而对于P2P存储，则更注重在节点随时退出随时加入的情况下，保证数据能够在有效时间内寻址。
云硬盘架构升级和性能提升--UCloud 叶恒
云硬盘作为云计算的基础存储产品，为云服务器提供了高可用、高可靠、持久化的数据块级随机存储。云盘的性能和数据可靠性尤为重要，UCloud根据过去运营经验，在过去一年里重新设计了云盘的底层架构，提升了普通云盘的性能，并支持了NVME高性能存储。UCloud块存储研发工程师叶恒，着重讲解了UCloud云硬盘的架构升级和性能提升实践。
通过对现阶段问题和需求的分析，UCloud存储研发团队首先整理了架构升级的目标：1）解决原有软件架构不能充分发挥硬件能力的局限；2）支持SSD云盘，提供QoS保证，充分发挥后端NVME物理盘的IOPS和带宽性能，单个云盘IOPS可达2.4W；3）支持更大容量云盘，32T甚至更大；4）充分降低IO流量的热点问题；5）支持并发创建几千块云盘，支持并发挂载几千块云盘；6）支持老架构云盘在线向新架构迁移，支持普通云盘在线迁移至SSD云盘。
根据上述目标，UCloud定制了IO路径优化、元数据分片、线程模型设计、防过载策略、在线迁移五大改造方向。
IO路径优化： 老架构中，整个IO路径有三大层，第一层宿主Client侧，第二层Proxy侧，第三层存储Chunk层。为了降低延时，优化后的方案将 Proxy 的功能拆分，将路由获取交给了Client，IO读写Client可直接访问存储Chunk层。整个IO路径就变成了2层，对于读 IO 而言，一次网络请求可直达后端存储节点，其时延平均可降低 0.2-1ms。
元数据分片： 老架构中，UCloud 支持的分片大小是 1G。但在特殊场景下（如业务 IO 热点局限在较小范围内），1G 分片会使普通 SATA 磁盘的性能非常差。新架构中，UCloud 将元数据分片调小，支持 1M 大小的数据分片。并采用以一套统一规则计算获取路由的方案，节省IO路径消耗，保证1M分片下，元数据的分配和挂载畅通无阻。
线程模型设计： 传统架构采用单线程传输，单个线程写 IOPS 达 6W，读 IOPS 达 8W，难以支持后端 NVME 硬盘几十万的 IOPS 以及 1-2GB 的带宽。为了利用 NVME 磁盘的性能，UCloud采用了多线程传输模型，并通过IO路径、路由获取等软件细节的优化，减少CPU消耗。
防过载策略： 多线程并行工作压测时，UCloud模拟了热点集中在某个线程上的场景，发现该线程CPU基本处于99%-100%满载状态，而其它线程则处于空闲状态。为了解决这个问题，存储团队采用定期上报线程CPU以及磁盘负载状态的方式，当满足某线程持续繁忙而有线程持续空闲时，选取部分磁盘分片的IO切换至空闲线程，来规避部分线程过载。
在线迁移： 老架构普通云盘性能较差，部分普通云盘用户业务发展较快，希望从普通云盘迁移至SSD云盘，满足更高的业务发展需要。面对用户诉求，UCloud采用从系统外围支持在线迁移的方式，快速达到在线迁移的目的。
据了解，SSD云盘相比普通云盘，IOPS提升了13倍，稳定性提升了3倍，平均时延降低了10倍。新架构推出后，已服务了现网用户的3400多个云盘实例，总存储容量达800TB，集群每秒IOPS均值31万。
基于CephFS的改进及优化--深信服科技 卢波
据IDC的调查报告显示，企业中80%的数据都是非结构化数据，这些数据每年都按指数增长60%。分布式文件存储以其灵活扩展、快速部署等特点越来越受到政府、教育、医疗等行业用户的青睐。随着OpenStack技术的发展，Ceph成为了分布式存储的明星，来自深信服科技的存储研发专家卢波结合深信服研发的分布式存储系统EDS，分享了深信服针对Ceph的文件存储所做的一些改进及优化，以及未来的一些思考。
Ceph 是一个分层的架构，底层是基于 CRush（哈希）的分布式对象存储-Rados，上层提供对象存储（RadosGW）、块存储（RDB）和文件系统（CephFS）三种访问方式。其中，CephFS 始于 Sage Weil 的博士论文研究，目标是实现分布式的元数据管理以支持 EB 级别数据规模。下图为CephFS的整体结构。
ceph-mds: 缓存文件系统元数据，并将元数据持久化到rados中，自身运行在rados之上，本身并不存储数据。
open： 客户端从MDS获取文件元数据
write： 客户端直接通过rados进行数据写入操作
所有数据的操作时均通过客户端直接访问raods，多客户端的数据访问操作时依靠OSD来控制，元数据和数据可以在不同的存储池中。可以看到，CephFS是一个分布式系统，需要跨网络访问，因此在实际使用中，其IO路径较长，导致延时较高，性能受限。为了解决此问题，深信服科技基于此架构进行了系列改进。
全局缓存： 缓存是整系统全局共享的，即只要缓存在任意一个节点上的文件分条数据，其它任意节点再次收到该数据的访问请求后都可以从一级缓存中命中该数据。通过全局缓存，实现数据合并，利用K-V存储的高吞吐，从而大大提高系统整体性能。
FusionStorage： FusionStorage块存储根据业务不同的IO大小，智能地对不同大小的IO采取不同的处理方式。对于小块IO，FusionStorage块存储采用多副本的方式写入分布式EC Cache中，并在Cache中做条带聚合；而对于大块IO，则绕过分布式EC Cache，直接提交EC写入后端硬盘。由于大块IO直接下盘，系统可以释放原来大块IO占用的宝贵的Cache资源，缓存更多的随机小块I/O，间接的提高了随机小块I/O的Cache命中率，提升系统随机小IO的性能。而HDD在写入大块顺序IO时，写性能差距相比SSD并没有那么明显，加上多块HDD并发处理，在大块顺序IO的场景下系统也能获得很好的写入带宽，兼顾了系统的整体性能。
由于篇幅有限，本文仅整理了现场演讲部分精彩内容，感兴趣的读者可以点击链接下载讲师演讲PPT了解更多技术详情。
下载地址（提交表单后可下载）：PPT下载地址
