共计 3736 个字符，预计需要花费 10 分钟才能阅读完成。
前言
回顾上一篇《AI 场景的存储优化之路》中，咱们剖析了 AI 场景中分布式文件存储面临三大挑战：海量文件、小文件拜访性能、目录热点，其中对目录热点问题做了详细分析，并介绍了 YRCloudFile 在该问题上的计划实现。
而文中提到的元数据的动态子树、动静子树、目录 hash 三种分布模式，形象进去，大抵对应集中式、分布式、无元数据三种架构模型，这三种模型是业界通用的元数据管理形式，在特定业务场景中，各有千秋，集中式模型的问题在于单点故障、性能孤岛等；分布式模型的问题在于主从同步的性能开销，一致性问题等；无元数据模型的问题在于它通常应用用相似 DHT 计算形式代替查问，这毁坏了元数据中对于文件系统的树形拓扑构造，导致元数据性能不高。所以没有说哪一种计划能够在所有业务场景中，都能放弃最优的性能。在理论的产品设计中，根据产品定位，须要做肯定的取舍。
架构设计
无论是设计针对 AI 场景，还是针对通用场景的存储产品，对于一个企业级存储产品而言，数据可靠性、可用性以及性能是架构层面首先要思考的因素。
企业级存储产品，首先须要保证数据的可靠性，而后能力谈数据的高性能和高可用。因为对于绝大部分利用场景，存储的数据都必须是有状态的，所以不保证数据可靠性的存储，利用是无奈应用的。
数据的可靠性保障，从架构上首先要防止单点故障，单点故障可能会导致的数据不可复原，此外单点故障还会引入很多其它问题，如零碎可用性低、性能瓶颈等。对于曾经长久化的数据，也要避免静默数据损坏，存储层面的数据扫描以及驱动层的 520 扇区校验等机制也十分必要。因而很多分布式块或文件存储产品，都会在利用不感知的前提下，周期性地做数据查看，一方面能尽早发现并修复静默数据谬误和集群中正本间不统一的数据，另一方面也是集群衰弱状态监控的须要，通过数据查看，能够发现集群业务延时是否正当，集群是否异样导致 IO hang 等状况。从业务层面看，架构上对数据可靠性的设计也反映了对于一致性的要求，下层利用是冀望最终一致性还是强一致性，在多客户端并发拜访公共存储资源场景中，业务端观测到的数据一致性就变得更简单，这些考量最终会体现在存储的架构设计上。
数据的可用性保障，个别元数据用正本，数据存储用正本或纠删码（EC）来实现 HA，无论是元数据和存储服务、正本之间数据一致性策略、主从切换策略、集群视图推送策略，还是可降级维护性等，都是简单的技术环节。这些问题会因为集群规模变大而被进一步放大，任何一步处理不当，都有可能导致数据谬误，因而在设计上，所有场景的解决必须保障闭环，解决上也会更偏向于激进策略。
为了实现 数据读写的高性能，在软件层面，须要尽可能地进步并发度，尽量升高解决中的串行化比重。例如，因为控制流和数据流的拆散，客户端从元数据服务器获取控制权或资源后，将间接和存储集群进行 IO 交互，或是为保障操作的合法性以及数据的一致性，在集群复原时产生的 IO 交互，在交互过程中，不可避免会遇到须要串行化解决的中央，这种串行化占比越高，对分布式集群的性能影响越大。
实现思路
架构设计是产品性能的根本保障，代码实现决定产品性能的下限。YRCloudFile 在设计之初，剖析了泛滥计划，取各个架构的长处，在确保数据可靠性的前提下，通过一直迭代进步产品的可用性和性能。
分布式文件存储提供全局对立命名空间，对于客户而言，就是一个独立的挂载目录，空间和文件个数将不会受到限制。后端将不同存储介质资源池化成多个存储池，而存储资源能够依据空间须要，在虚拟存储池中进行弹性扩大扩容，元数据为了性能和空间须要进行横向扩大，做到扩容对利用通明。
零碎拓扑大抵如下：
晋升大文件 IO 的吞吐性能
在保障大文件 IO 的吞吐性能方面，要尽可能地缩短 IO 门路，缩小内存拷贝和上下文切换等操作，采纳常见的将控制流和数据流（即元数据和数据存储）拆散计划，客户端在取得文件拜访控制权后，间接对后端存储分片进行并发拜访。对文件属性的更新采纳的 lazy 模式，即在客户端调用 close 时更新 MDS 中的文件信息。这种形式可能缩小对 MDS 更新的频率，能够进步 IO 性能，但副作用是文件的元数据信息没有及时更新，IO 期间 stat 操作无奈获取最新的信息。能够在元数据服务中引入 ServerType + ServerNodeID + GloballyUniqueFileID 组成 sessionMap，来辨别该文件目前的状态，决定 stat 时，是否从后端存储获取最新信息并更新及返回，从而兼顾在更新文件时，对文件进行 stat 的多数申请。
晋升小文件 IO 拜访性能
小文件 IO 拜访性能方面，考验的是元数据的性能，一方面要反对海量文件，另一方面还要反对高效的元数据操作。咱们的集群整个命名空间目录树由元数据集群来保护，系统目录树架构：
基于该架构实现的元数据集群，如果基于本地文件系统做元数据服务，那么瓶颈就在于本地文件系统（如海量文件性能，单目录文件个数，单台服务器性能瓶颈等），基于 DB 治理裸盘元数据服务，能较好防止上述问题，但还是会存在上图中 MDS4 的单目录海量文件的增删改查的性能问题，解决方案就是子目录拆分，上面探讨下基于该计划的一致性访问控制。
多客户端的一致性拜访
作为一个分布式文件系统，多个客户端会并发拜访集群内的文件，因为客户端间各自独立，相互不感知，数据一致性就须要存储集群来保障，在元数据集群中，对被拜访的文件资源进行爱护，能保障利用在并发拜访时候，看到的数据是统一的。为保障业务数据实时长久化，保障集群呈现软硬件异样或整集群掉电重启后，业务数据的一致性，个别都是采纳分布式集群锁，例如 zookeeper 的程序长期节点、通过向某数据结构中插入 key 是否胜利作为并发访问控制的根据。
在上图的树形架构中，能够基于 MDS 实现文件、目录级别的锁，从而达到多客户端并发访问控制的目标。锁能够在 MDS 进行细粒度实现，尽管锁的细粒度化，必然会减少 MDS 服务器的压力，但因为 YRCloudFile 的 MDS 集群是多台服务器组成，还能够一直横向扩大，大量的 MDS 节点会摊派锁的压力，性能上是能够保障的。
保护语义的正确性和操作的幂等性
分布式系统中，在客户端申请的整个生命周期中，任何中央都有可能因为各类软硬件异样导致的申请重试，尤其在主从切换场景中，这时就须要保障语义的正确性和操作的幂等性。
因而，从客户端发动的某个申请，在其整个生命周期内都是能够被跟踪的，咱们用 GUID+ServerType + ServerNodeID + GloballyUniqueFileID 组成惟一的申请 ID，在任何一个阶段都须要缓存其执行后果，即便在各个阶段存在重试，也可实现操作的正确性和幂等性。
基于 AI 场景的针对性优化
当初非结构化数据迅速增长，分布式文件存储已成为对非结构化数据进行治理的一个广泛承受的解决方案，尤其 AI 场景中，以小文件读多写少为主，对小文件而言，多客户端并发拜访雷同文件资源的状况不多，局部场景中甚至可容忍大量数据的失落。因而，为了针对 AI 特定的读写场景，实现高性能，开启各类缓存就十分必要。
客户端的优化
开启客户端读写缓存，能够复用零碎 pagecache。增大客户端缓存生效工夫，升高 revalidate dentry 操作的频率。对于大块 IO 写申请，因为客户端内存资源无限，为防止缓存净化，能够将大块 IO 间接写入到后端存储节点的缓存中，将小块 IO 写入到客户端缓存中，后盾异步 flush dirty 数据到后端存储。
增大客户端缓存生效工夫，升高 revalidate dentry 操作的频度。文件的查找过程，就是从根目录逐级往下找，零碎 dentry 能减速这些操作，如果该文件门路缓存命中，那么就能疾速找到对应的 inode 信息，而后就能够间接去元数据集群去查找该文件了。
元数据性能优化
无论采纳什么模式的元数据管理形式，都须要从多维度思考计划的性能问题，在分布式系统中，单点硬件资源个别很难成为瓶颈，而真正成为瓶颈的还是某些特定 IO 流程，不可避免有串行化的中央，而这种串行化的比重越重，对分布式集群的性能的制约会更为严重，所以元数据的优化首先要缩小这种串行化的限度。
- 性能的 local 准则，在这棵树形架构中，即同级目录下的文件，元数据尽量散布在同一个节点中，这样能提供较好的本地化性能，而当该目录下有上亿的海量文件时，有须要将改目录拆分，把压力散布在多个元数据服务中。
- 提早化 ops 形式，即批量并发解决非相关性申请操作，可解决上图中 mds4 的性能瓶颈。
- 升高 mds 负载，用缓存取代磁盘拜访，缩小交互次数，防止上下文切换。所有和磁盘交互的中央，能异步尽量异步，如耗时的异步删除等。
后端存储优化
充分利用后端存储性能，如果后端存储够快，就用 direct 模式，如果不够快，就依赖 pagecache，如果是机械盘，就给他加缓存层等。
测试配置为：客户端为 E5-2603 v3 + 128G ddr4，存储集群为 2 正本，有 SSD 给 HDD 减速。
开启缓存前后性能比照图：
总结
本文次要剖析了从设计到实现中，保证系统一致性和高性能的须要关注的点，以及在 AI 场景下，通过客户端缓存进一步满足客户对高性能的需要，以及咱们的优化思路，也心愿借此文和更多技术专家交换如何对 AI 场景下的存储计划进行针对性的优化。
