了解分布式存储UCloud云计算的设计和优化

随着信息化水平的不断提高，全球数据也在不断扩展. 面对当前的PB级海量数据存储需求，传统存储系统在容量和性能扩展方面存在瓶颈. 云存储以其强大的可扩展性，高性价比和良好的容错性而被业界广泛认可. 由于其前瞻性，许多公司已将其作为云计算的第一步. 分布式文件系统和分布式块存储作为云存储中的一项重要技术，已成为云存储发展的重要基石.

对于大多数专注于云计算本身的IT技术人员而言，他们不一定具有分布式文件系统和分布式块存储的深入知识. 为此，在加拿大大学校园下午茶武汉站，我们邀请了与分布式文件系统，分布式块存储和云存储相关的技术专家来讨论分布式存储.

分布式文件系统产品架构分析——UCloud邓进

分布式存储产品是各种产品业务中必不可少的基础架构. 了解存储产品的设计思想和使用场景可以使用户更好地基于存储产品构建自己的业务逻辑. UCloud文件存储研发工程师邓进，着重介绍了UCloud分布式文件系统UFS的设计概念和开发实践，分享了如何解决存储产品业务多元化的需求，如何解决上一代产品遇到的局限性以及如何避免这些困难，例如类似开源产品的瓶颈.

邓进认为，分布式文件系统是传统文件系统的扩展. 用户可以通过分布式技术和公共云来获得传统文件系统中不可用的存储容量. 规模效应: 1）横向扩展: 容量和性能线性/近线性改进； 2）容错: 屏蔽硬件故障以提高数据可靠性和系统可用性； 3）较低的TCO和即付即用: 这是云计算产品的独特功能，可以为应用程序层的用户提供较低的TCO.

UFS（UCloud文件系统）是UCloud开发的高度可用/可靠的文件存储服务，专为公共云服务而设计. 在设计之初，研发团队主要使用开源软件GlusterFS在公共云环境中快速执行产品原型验证，但在运行过程中发现GlusterFS在多租户公共云中存在更多的痛点和困难. 环境，例如规模扩展性能存在瓶颈（较大的对等开销），节点数有限；无法执行多集群管理和灰度管理；索引操作可能会导致较高的IO，从而影响数据操作性能，小文件访问和大目录操作性能非常差等. 基于这些问题，UCloud最终决定改进自主开发产品的设计.

根据开源解决方案操作的难点，UCloud首先将索引和数据分开，而自定义索引结构和语义有助于后续非NFS协议的扩展；然后独立设计的存储服务支持集管理，灰度和其他策略；此外，旨在支持数百万个大型目录和TB +文件大小并支持QoS，以隔离多租户场景中的用户访问；最后云计算分布式文件系统，通过数据加密和切片策略来确保数据安全. 下图显示了UFS 1.0的方案体系结构.

通常，一个成熟的体系结构需要经历发现问题的过程->转换实践->发现新问题的过程->改造和升级. 通过这种持续的迭代升级，最终它会稳定下来，UFS架构也是如此. 在运行过程中，UCloud存储研发团队发现UFS 1.0解决方案仍然存在一些局限性. 例如，存储模型更适合于小型分片场景，并且不够通用. 固定的基础存储分片会导致一定数量的空间浪费；存储层支持的文件大小较小；因此，该团队基于UFS 1.0进行了新一轮的架构升级.

新架构优化了存储层并使用了仅附加模型. 如下图所示，Stream代表文件流，可以附加在文件尾. 范围是流中的数据片段，片段大小不是固定的，每个范围以文件的形式落入地面. 在数据层中，streamsvr负责维护流和扩展区的索引/路由信息，extentsvr维护扩展区中块的索引信息，为直接连接的客户端提供读写请求.

插入式引擎设计可以减少写入故障，并充分利用内存缓冲区来减少读取故障. 此外，为了解决底层存储引擎的随机写入不友好的问题，系统使用FileLayer设计来缓存热点数据并减轻存储压力.

分布式存储中的数据分发算法——Aosi Data李明宇

数据分发算法是分布式存储的核心技术之一，不仅要考虑数据分发的均匀性和寻址效率，还要考虑在扩展和减少容量时要考虑的数据迁移成本，并要考虑到副本的一致性和可用性. Aosi Data的创始人兼首席技术官李明宇现场分析了几种典型的数据分发算法的优缺点，并分享了在具体实现中遇到的一些问题.

一致性哈希算法可以定位数据，因为它不需要查表或通信过程，计算复杂度不会随数据量的增加而变化，并且效率高，一致性好，添加/减少时数据迁移少节点等. 功能受到开发人员的喜爱. 但是，在实际应用中，该算法由于自身的局限性而遇到了很多挑战. 例如，在“存储区块链”场景中，几乎不可能获得全局视图，甚至暂时还不稳定. 企业级IT场景接下来，存在可靠存储多个副本的问题，并且数据迁移的成本巨大.

所谓的存储区块链可以理解为分布式存储（p2p storage）+区块链，它鼓励每个人通过令牌激励来贡献存储资源并参与全球分布式存储系统的构建. 由于需要鼓励大量用户自发参与，因此涉及数亿甚至数十亿个节点的寻址和路由. 目前，该行业的主要解决方案包括Chord和Kademlia. 但是，Chord算法效率较低，并且会导致更高的延迟. 您可以使用Finger表记录当前节点和下一个节点的位置，还可以记录当前节点2 ^ i + 1的位置，这降低了计算复杂性并最终减少了延迟.

在企业IT场景中，数据分发算法包括Dynamo，Ceph的CRUSH，Gluster的Elastic Hashing和Swift的Ring. 这些算法具有相似的特征. 首先，它们基于/从一致性哈希中借用，并且在增加/减少节点时数据迁移量很小. 其次，介绍数据中心物理拓扑的建模（集群图）. 数据/ EC片段的多个副本分布在故障域/可用性区域中. 此外，这些算法还可以划分节点的权重，数据分布和容量/性能匹配，并有助于扩展.

通常，这两种类型的解决方案都基于一致的哈希算法，仅由于不同的需求，存在不同的改进方向. 企业级更加关注副本故障域的分布；对于P2P存储，它更加注意确保在节点随时退出并随时加入的有效时间内可以对数据进行寻址.

云硬盘架构升级和性能提升——UCloud艺恒

作为云计算的基本存储产品，云硬盘为云服务器提供了高可用性，高可靠性和持久性的块级随机存储. 云盘性能和数据可靠性特别重要. 根据过去的操作经验，UCloud在过去一年中重新设计了云磁盘的基础架构，以提高普通云磁盘的性能并支持NVME高性能存储. UCloud块存储研发工程师Ye Heng重点介绍了UCloud云存储的体系结构升级和性能改进实践.

通过对当前阶段的问题和需求的分析，UCloud存储研发团队首先理清了架构升级的目标: 1）解决无法充分利用硬件功能的原始软件架构的局限性； 2）支持SSD云盘并提供QoS保证，充分发挥后端NVME物理磁盘的IOPS和带宽性能，单个云盘IOPS可以达到2.4W； 3）支持更大容量的32T甚至更大的云盘； 4）充分减少IO流量的热点问题； 5）支持同时创建数千个云盘，支持同时挂载数千个云盘； 6）支持将旧架构云盘迁移到新架构，并支持将普通云盘迁移到SSD云盘.

根据上述目标，UCloud为IO路径优化，元数据分片，线程模型设计，防超载策略和迁移定制了五个主要的转换方向.

IO路径优化: 在旧体系结构中，整个IO路径具有三个主要层: 第一层托管客户端，第二层代理端，第三层存储Chunk层. 为了减少延迟，优化的解决方案拆分了代理的功能，并将路由获取交给客户端，IO读写客户端可以直接访问存储块层. 整个IO路径成为第2层. 对于读取IO，网络请求可以直接到达后端存储节点，平均延迟可以减少0.2-1ms.

元数据分片: 在旧架构中，UCloud支持1G的分片大小. 但是，在特殊情况下（例如，业务IO热点限制在较小范围内），1G碎片将使普通SATA磁盘的性能非常差. 在新架构中，UCloud减少了元数据碎片以支持1M数据碎片. 并采用一套统一的规则来计算路由，以节省IO路径消耗，并确保1M片段下元数据的分发和安装不受阻碍.

线程模型设计: 传统体系结构采用单线程传输，单个线程写入IOPS最高为6W，读取IOPS最高为8W. 很难支持数十万次IOPS和1-2GB带宽的后端NVME硬盘驱动器. 为了充分利用NVME磁盘的性能，UCloud使用了多线程传输模型，并优化了IO路径和路由获取等软件细节，以减少CPU消耗.

防超载策略: 在多线程并行工作压力测试期间，UCloud模拟了热点集中在某个线程上的场景，发现线程CPU基本上是99％-100％满载，而其他线程是闲. 为了解决此问题，存储团队采用了定期报告线程CPU和磁盘负载状态的方法. 当某个线程处于繁忙状态并且一个线程连续处于空闲状态时，会选择某些磁盘碎片的IO切换到空闲线程，以避免某些线程过载.

迁移: 在旧架构中，普通云磁盘的性能很差，并且某些普通云磁盘用户得到了快速发展. 他们希望从普通云磁盘迁移到SSD云磁盘，以满足更高的业务开发需求. 面对用户需求，UCloud采用支持从系统进行迁移的方法，以快速实现迁移的目的.

据了解，与普通云盘相比，SSD云盘的IOPS改善了13倍，稳定性提高了3倍，平均延迟提高了10倍. 新架构启动后，它已为现有网络用户的3400多个云磁盘实例提供服务，总存储容量为800TB，平均群集IOPS为每秒310,000.

基于CephFS的改进和优化-神康科技路波

根据IDC的，企业中80％的数据是非结构化数据，并且这些数据每年呈指数增长60％. 由于分布式文件存储的灵活扩展和快速部署，在政府，教育和医疗保健等行业的用户中越来越受欢迎. 随着OpenStack技术的发展，Ceph已成为分布式存储的明星. 来自深圳康维思技术的存储研发专家陆波，与深圳康维思开发的分布式存储系统EDS结合，分享了神甫对Ceph文件存储的一些改进和优化. ，以及一些未来的想法.

Ceph是一个分层的体系结构. 底层基于CRush（哈希）分布式对象存储Rados. 上层提供了三种访问方法: 对象存储（RadosGW），块存储（RDB）和文件系统（CephFS）. . 其中，CephFS从Sage Weil的博士论文研究开始，目标是实现分布式元数据管理以支持EB级数据规模. 下图显示了CephFS的总体结构.

ceph-mds: 缓存文件系统元数据并将元数据持久保存到rados中. 它可以在rados上运行，并且不存储数据.

打开: 客户端从MDS获取文件元数据

write: 客户端直接通过rados写入数据

所有数据操作均可通过raod通过客户端直接访问. 多客户端数据访问操作由OSD控制. 元数据和数据可以位于不同的存储池中. 可以看出，CephFS是一个分布式系统，需要通过网络进行访问，因此在实际使用中，其IO路径更长，导致更高的延迟和性能受限. 为了解决这个问题，Sangfor Technology在此架构的基础上进行了一系列改进.

全局高速缓存: 整个系统在全局范围内共享高速缓存，也就是说，只要高速缓存任何节点上的文件高速缓存数据，任何其他节点在收到对高速缓存的访问请求后都可以从主高速缓存中命中数据. 再次数据. 通过全局缓存云计算分布式文件系统，可以实现数据合并，并利用K-V存储的高吞吐量，从而大大提高了系统的整体性能.

FusionStorage: FusionStorage块存储根据服务的IO大小不同，智能地对不同大小的IO采用不同的处理方法. 对于小型块IO，将FusionStorage块存储以多个副本写入分布式EC Cache，并在Cache中执行条带聚合；对于大块IO，将绕过分布式EC缓存，直接将EC写入提交到硬盘. 由于大块IO直接从磁盘移出，系统可以释放原始大块IO占用的宝贵Cache资源，缓存更多随机小块I / O，间接提高随机小块I / O Cache的命中率，并改善系统随机小IO性能. 但是，在写入大块顺序IO时，与SSD相比，写入性能差距不是那么明显. 考虑到系统的整体性能，通过并行处理多个HDD，在大块顺序IO的情况下，系统还可以获得良好的写入带宽.

由于篇幅所限，本文仅总结了现场演讲的一些精彩内容. 有兴趣的读者可以单击链接下载讲师演讲PPT，以获取更多技术细节.

下载地址（提交表格后可下载）: PPT下载地址

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-170498-1.html