共计 7552 个字符，预计需要花费 19 分钟才能阅读完成。
明天，高性能计算联合人工智能技术正在推动科研翻新。例如通过破解水稻基因明码推动作物育种从“试验选优”向“计算选优”倒退，在医药畛域疾速剖析分子与蛋白之间的相互作用，发现潜在的可能无效干涉疾病产生的药物分子。
之江实验室就是上述科研翻新的推动者，实验室由浙江省政府主导、浙江大学等院校反对、企业参加的事业单位性质的新型研发机构，为资料、基因、制药、地理、育种等迷信畛域的钻研提供新的办法、工具和伎俩。
因为算力资源的人造异构性，以及不同技术实现的计算能力往往出自不同的零碎架构或指令集，会导致软件不兼容性，从而进步了算力应用的门槛，也使得算力利用率难以无效进步。为解决这个问题，之江实验室将各种异构算力资源汇聚在一起，造成一个宏大的“算力池”。本文将分享之江实验室如何基于 JuiceFS 为超异构算力集群构建存储层的实际。
01- 之江实验室的输入反应堆
数字反应堆是之江实验室一个大型科研安装。整个科研安装由软硬件局部组成。在软件方面，负责研发之江瑶光智能操作系统。
该智能操作系统次要蕴含两个要害组成部分。首先，它提供了通用的计算平台解决方案，为下层应用层提供反对。通过这个平台，用户能够针对不同的应用领域，如计算资料、计算制药、计算地理等，进行开发和利用。
其次，咱们实现了一个异构资源聚合计划。在之江实验室，咱们领有多个异构集群，包含 CPU 集群、GPU 集群以及一些超算资源。这些不同类型的计算资源具备不同的应用形式。通过异构资源聚合计划，咱们将这些不同的计算资源对立聚合，实现对立的治理和应用。
整体架构如上，在之江实验室的计算与数据中心，咱们部署了多套异构集群，包含 H3C 的傲飞集群、之江的计算集群、国产的曙光集群等，以及边缘计算场景，这些都纳入了咱们的管控零碎中。通过集群设施插件的形式，咱们对这些不同的集群进行了对立形象，并实现了算力的聚合。在整个异构算力联邦的体系中，咱们将这些不同的算力集群都形象为 Kubernetes（k8s）集群进行治理。
下层下发的业务指令及不同类型的作业，通过元调度器来决定将这些作业发送到哪个集群。依据不同的调度策略，如计算优先级、能耗优先级和性能优先级，来确定计算作业的具体执行形式。目前，咱们已接入约 200P（PFLOPS, 1P 相当于每秒执行一千万亿次浮点运算）的 AI 算力和 7000 核的 HPC 算力。
算力侧对存储的需要
首先：存储层的形象和对立。因为在许多计算场景中，包含超算和 AI 训练，都应用 POSIX 接口。因而，咱们心愿在这一层面上对立应用 JuiceFS 的接口来提供服务。
第二个方面：存储计划的通用性。目前接入的算力集群是异构的，那么尽量须要思考计划在不同的异构集群中都能实用。
第三个方面：数据的编排条件。咱们的数据是有典型的冷热个性，在一个工作在计算过程中，它用到的数据是热数据，工作计算之后或者过了几天之后，这个数据就变成了冷数据，咱们对冷数据的读和操作是比拟少的。
第四个方面：存储性能的要求。数据读写性能要好。特地是热数据的读取性能。在算力集群中，计算资源十分贵重，如果因为数据读取慢导致 CPU，GPU 空转期待，是极大的节约。
存储计划选型
计划 1：袒露的对象存储（OSS）与 S3FS + NAS 相结合
这个计划存在一个较大的问题，即间接应用袒露的对象存储性能十分差。另外，袒露应用对象存储的 S3FS 挂载点常常会呈现莫名其妙的失落。一旦挂载点失落，容器将无法访问，如果要复原挂载点，必须对整个容器进行重启，这对用户业务造成了很大的烦扰。
因为开始时集群规模较小，而且这套计划部署简略，实验室一开始采纳了这种计划进行部署。但随着集群规模的逐步扩充，尤其是从去年开始建设的数字反应堆，从繁多集群到多集群的演进过程中，当节点数量从最后的 10 多台逐步扩大到 100 多个节点时，这个计划基本上曾经行不通了。
计划 2：Alluxio + Fluid + OSS
通过调研，咱们发现该计划的构造绝对简单，波及到许多组件的组成。之江实验室是一个超异构的多集群环境，因为 Alluxio 并不是一个强一致性的文件系统，它实际上只是一个缓存的粘合层。在这种多集群环境下，会面临元数据不统一的问题，而解决这个问题特地艰难。因为下层用户的业务产品十分繁多，咱们不能干预用户的应用形式。在这种状况下，如果不同集群之间的数据不统一，将会导致重大的问题。其次底层依然应用 OSS，当数据规模扩充到肯定水平时，因为 OSS 的元数据性能问题，当存储规模达到肯定级别后，元数据同步、新集群的缓存层初始化等操作也会遇到较大的性能瓶颈。
计划 3：JuiceFS（最终采纳）
JuiceFS 有十分具体的社区文档，能够间接上手应用，并且在咱们的搭建测试集群以及最终的上线部署中表现出色。另外，JuiceFS 反对 CSI 能够容器化部署，另外对国产硬件的适配性较好。因而咱们最终抉择将 JuiceFS 作为咱们算力侧的存储底座。
应用 JuiceFS 的劣势
首先，JuiceFS 提供了丰盛的元数据引擎抉择，比方 Redis 和 TiKV，使得 JuiceFS 具备较好的元数据性能。目前咱们实验室应用的是由三个节点搭建的 TiKV 作为元数据引擎。因为该配置是去年建设的，当初的性能曾经有些不够用，后续咱们将逐渐晋升性能。
最后咱们思考应用 Redis 作为元数据引擎，但起初发现如果应用 Redis，就无奈实现程度扩容。从而应用了 TiKV，则能够随着文件系统数量的增长逐渐扩大，这的确更好。
第二，在跨集群环境下，应用 JuiceFS 能够实现文件的原子性和一致性。在集群 A 中写入的文件在集群 B 中立刻可见。然而，如果应用 Alluxio，就无奈做到这一点。Alluxio 须要进行一些数据同步事件等操作能力实现，而这些事件实际上会带来肯定的开销。
第三，JuiceFS 具备缓存能力。客户端能够配置一个缓存目录，应用缓存后能够大大降低算力集群对底层存储的压力。
第四，JuiceFS 对于 POSIX 的兼容性十分好。咱们发现 Alluxio 的理论兼容性并不那么好，而且其客户端性能绝对较个别。Alluxio 可能更实用于不同异构数据源的对立接入层，用于读取数据较好。然而，如果须要频繁写入或批改数据，则可能应用起来并不现实。
第五 JuiceFS 的社区是常沉闷。
这个是咱们本人在实验室环境下测进去的，测试工具：FIO 16 线程、4M Block、1GB 数据 上图 NAS 的性能就没法看，因为过后测评的时候还在生产环境正在提供服务，过后有大略七十几个节点正在运行，带宽很小，根本就运行不了。
02- 存算拆散架构演进
初期，整个高性能计算的过程实际上是分为很多个环节，然而数据扩散在不同的存储系统中会带来应用效率和便利性上的挑战。为了简化数据的治理和流转，咱们应用了一个对立的存储底座作为存储基础设施。存储底座的外围能力包含高可靠性、低成本和高吞吐量，因而咱们抉择了对象存储作为存储底座。将数据存储到对象存储中能够轻松实现数据的冷热分层，从而节俭存储空间。
然而，间接让计算集群间接应用裸对象存储依然存在一些问题。首先是元数据性能差的问题，例如对同一目录下文件的列表操作，在文件数量较多的状况下，耗时会十分长。第二个问题是带宽耗费大，数据湖提供的是一般的 IP 网络，而不是 RDMA 高速网络，因而总带宽无限。
因而，在对象存储之外，咱们还建设了一个元数据集群，并应用了 TiKV 数据库。基于对象存储和 TiKV，咱们构建了 JuiceFS 分布式文件系统。算力集群通过在节点上装置 JuiceFS 客户端来读取文件系统的数据。这样，咱们能够克服对象存储的一些限度，进步元数据性能，并缩小带宽耗费。
为了实现高效的数据流转，咱们通过文件管理系统容许用户进行文件的上传和下载操作。文件管理系统底层采纳 JuiceFS S3 网关，将数据写入底层存储。
除了数据湖和元数据集群，咱们还建设了一个高速缓存集群，它严密部署在计算集群中，次要目标是为了实现最佳的 I/O 性能。这样解决了计算集群与对象存储数据湖底座之间高效数据流转的问题。用户并不需要关怀数据是存储在对象存储中还是在高速缓存集群中。
算力系统对数据流转进行管控。计算集群和高速缓存集群之间通过 200G 的 RDMA 高速网络连接。高速缓存集群上部署了 BeeGFS 高速并行文件系统，将该文件系统作为一个目录挂载到计算集群。这样，计算集群能够像应用本地目录一样应用该缓存零碎。
03- 存储能力产品化建设
在不同的业务场景中，对存储的需要和性能指标是不一样的。为了可能更高效地服务用户，咱们提出了打造存储能力产品化这样的想法，目前 JuieFS 被利用到了以下几类存储产品中。
通用文件存储
JuiceFS 会将其数据保留在一个特定的目录下，并依据用户所属的组织架构生成一个惟一的拜访门路。通过间接将该门路挂载到容器内，实现数据的隔离。用户能够通过页面端进行文件的上传和下载，也能够应用咱们提供的命令和工具对文件进行操作。
存储卷
在初始建设阶段，通用文件存储存在一个问题，容量的扩展性较差。底层的对象存储集群（oss）的容量无限，随着数据量的减少，用户无奈申请更多的存储空间。为解决这个问题，咱们引入了存储卷的概念。
存储卷能够类比为云盘，不同的存储卷相当于不同类型的云盘。对于不同的存储类型，咱们能够将它们包装成不同的存储卷，以满足用户在不同场景下的需要。
对于须要频繁地读写海量小文件的场景，它须要应用提早较低且吞吐量较高的存储产品。为满足这种需要，咱们将之前搭建的高速缓存集群转化为高速存储卷的性能，间接将其文件系统目录凋谢给用户应用。这样，用户能够间接应用高速存储，而无需通过 JuiceFS 来拜访，能够更间接地感触到高速存储的性能劣势。
而对于须要保留大数据但实际上不频繁读取的用户，能够联合 JuiceFS 和对象存储来创立规范存储卷。这样能够提供较大的存储容量和可承受的吞吐性能，同时绝对于高速存储卷，反对跨集群的网络互通能力。
此外，一些用户可能对性能有更高的要求，例如他们须要本地盘的产品，但同时也须要数据长久化的能力。在 Kubernetes 场景下，如果用户间接将数据写入本地盘，存在数据失落的危险，例如遇到意外重启或物理节点问题。在这种状况下，用户须要一种长久化的解决方案。咱们能够通过将用户在受影响节点的本地盘凋谢一部分存储空间作为本地存储卷，并在作业调度时依据用户指定的存储卷将任务调度到指定的节点上。
另外，不同存储产品在容量、吞吐量和跨集群互通能力方面存在差别。例如，高速存储能够在集群外部进行互通，但无奈跨集群；存储产品的容量和老本也各不相同。高速存储采纳全闪存的集群，建设老本较高，而对象存储的建设老本绝对较低，且具备较大的存储容量。因而，将不同的存储硬件（设施）能力包装成不同的存储产品来适配用户不同的业务场景。
数据编排
在应用 JuiceFS 时，咱们还实现了一个数据编排性能。管理员能够将罕用的数据集上传到文件系统某个目录，这个目录能够在下层形象成一个公开的数据集。不同用户在创立作业时都能够挂载这些数据集。普通用户也能够上传本人的公有数据集，并通过 JuiceFS 的预热性能对这些数据集进行预热。
咱们在算力集群外部建设了一个高速缓存集群。应用 warmup 指令，用户的数据集能够间接从两端预热到计算节点的高速缓存集群。这样，用户在进行大量模型训练时，能够间接与本人搭建的高性能集群交互，无需与近程 OSS 集群进行交互，从而取得更好的性能。
另外，这种设置能够升高对象存储底座的网络带宽压力。整个缓存的淘汰过程由 JuiceFS 客户端主动治理，因为能够对拜访目录进行下限容量的配置。对用户来说，这部分性能绝对通明且易于应用。
04-JuiceFS 应用过程当中也遇到了一些问题
文件读取性能
在咱们抉择应用 JuiceFS 之后，咱们在外部进行了一些文件读取性能的测试，并与算法团队单干进行了测试。过后，从测试后果看，JuiceFS 的读取性能总是比 NAS 慢得多。咱们开始查找起因为什么 JuiceFS 比 NAS 还要慢。
起初咱们发现，在应用 JuiceFS 和 TiKV 作为元数据的场景中，像列举目录这样的 API 操作实际上是随机的，它并不像 NAS 或其余文件系统那样保障统一的程序。在这种状况下，如果算法是基于随机抉择文件或者代码是固定的，那么可能会认为抉择的那些文件应该是固定的。
在解决海量小文件的场景中，元数据的开销是相当可观的。如果元数据没有被缓存到内存中，每次都须要从元数据引擎那里获取，与没有缓存相比这会带来较大的开销。因而，通过这个问题，咱们发现在特定的场景下须要对文件的索引目录进行编排。例如，某个算法可能须要解决数十万甚至数百万个文件，如果要确保算法训练的一致性，首先须要将这些文件作为索引文件，作为本人的一个索引目录树。每次进行算法训练时，间接读取索引文件，而不再调用 list dir 的操作，以确保这个文件夹下的文件目录树在算法训练中放弃一致性。
编著注：
造成读性能慢次要与用户的应用场景相干，评估后对“目录的随机读”这个性能未作调整，如果其余用户在这个问题上也有相似问题，欢送提出。
TiKV 无奈垃圾回收
在应用过程中，咱们遇到了 TiKV 无奈进行垃圾回收的问题。因为咱们只应用了这个文件系统，并且显示容量为 106T、1.4 亿个文件，而 TiKV 占用了 2.4T 的容量，这显然是不失常的。
依据官网文档的显示，例如 Redis，大概 1 亿个文件应该只占用大概 30GB 的容量。咱们进行了排查后发现可能是 TiKV 的元数据引擎没有进行垃圾回收。咱们还查看了报表，发现整个垃圾回收指标为空。可能的起因是咱们只部署了 TiKV，而没有部署 TiDB。然而，TiKV 的垃圾回收实际上须要依赖 TiDB，这是一个容易被忽视的问题点。
编著注：
JuiceFS 在 #3262 和 #3432 的 PR 中加上了 TiKV 的后盾 GC 工作，修复了这个问题。这些修复曾经在 v1.0.4 中合入。
JuiceFS client 内存占用较高
当咱们挂载 JuiceFS 客户端时，咱们将高速缓存集群设置为保留目录，并将其容量设置得绝对较高，实践下限为 50T。
在这种状况下，JuiceFS 客户端会定期扫描缓存目录，并建设内存索引，以便 JuiceFS 晓得哪些数据位于缓存目录中。因而，这会占用相当多的内存。如果目录十分宏大，咱们倡议用户敞开这个扫描性能。
在测试小文件随机 I/O 时，咱们感觉体现还能够，但在测试程序 I/O 时，呈现了一个较大的问题。例如，应用 dd 命令创立一个 500MB 的文件，后果发现对象存储生成了大量快照。能够看出，这里的存储和对对象存储的操作远远超过了创立一个 500MB 文件应有的操作。
在进一步排查时，咱们发现在启用 -o writeback_cache 参数后，程序写会变成随机写，从而升高整体的程序写性能。该参数只实用于十分高级的随机性场景。如果在不是这种场景下应用该参数，将导致重大的问题。这也是在应用 JuiceFS 时须要留神的一个点。
编著注：
这个问题次要是针对应用 NAS 做缓存的场景，曾经在 1.1beta 中优化，扫描时大幅缩小内存占用，并晋升速度。JuiceFS 在 #2692 中增加了--cache-scan-interval来自定义扫描时间，并且能够抉择只在启动时扫描一次或齐全敞开扫描，用户能够配置该选项。对于应用本地盘做缓存的用户则不须要调整。
05- 后续布局：更丰盛多样的存储产品
多层次
咱们将提供更多层次的软硬件产品，并将这些能力以不同的存储卷模式进行产品化，以适应用户在不同场景下的存储需要。
隔离性
- 目前存在数据安全危险，所有用户的数据都存储在同一个大型文件系统中并通过 hostpath 挂载在裸机。如某些用户领有节点登录权限，实际上能够拜访整个文件系统外部的数据。为了解决这个问题，咱们打算在后续采纳 CSI 模式联合门路定制来防止隔离性问题。
- 咱们还将上线配额治理性能。在用户应用存储产品时，须要有一种强制手段来限度用户能够应用的存储容量，并且可能精确查看用户理论应用了多少容量。间接应用 du 命令查看容量的过程开销很大，并且不太不便。配额治理性能将解决这个问题。
- 在计量计费场景下，咱们须要理解用户产生的流量和耗费的能量，并依据理论应用的容量进行计费。因而，良好的容量治理能力是必须的。
监控 & 运维
- 在应用 JuiceFS 时，咱们是间接在物理机上挂载，通过裸露一个监控端口，咱们的生产集群能够与这些端口进行通信，并建设了一套监控零碎，能够监控和收集所有的监控数据。
- 数据的容灾和迁徙能力目前还比拟欠缺。咱们遇到了一个典型场景，即现有集群的容量有余，须要上线新的集群。在新旧集群之间，如何解决数据迁徙以及不同数据的迁徙形式，如何在不影响生产用户的状况下尽量保障业务不中断，实现数据迁徙依然是一个较为艰难的问题。因而，咱们打算在后续寻找解决方案，以晋升这方面的能力
- 另外，咱们还在开发基于 JuiceFS 和 CSI 插件的通用能力，以实现在不同的存储客户端上动静挂载的能力。在生产环境中，用户对挂载参数的调整有肯定需要，因为不同的挂载参数适配不同的业务产品。然而，如果间接调整挂载参数，可能会导致整个物理节点的中断。因而，如果可能实现动静挂载的能力，用户只须要对业务进行适当的切换，而无需进行重启等操作。
对 JuiceFS 一些性能冀望：
- 卷治理能力 （配额、用户、权限）卷能力在之前曾经局部实现了配额的性能，但实际上咱们更须要的是基于用户和管理人员权限的治理能力。目前，JuiceFS 是挂载在一个大型文件系统上，如果为每个用户创立文件系统，将会带来很高的开销。 因而，咱们目前采纳的是基于一个大型文件系统，通过不同的目录来治理不同用户的权限配合，短少一个对立的、中心化的用户权限管理系统，依然须要依赖 Linux 的权限治理。然而，Linux 的权限治理是散布在不同节点上的，对用户权限的治理绝对较为艰难。我在思考是否能够依赖元数据，并将其作为一个中心化数据库的能力，实现用户和权限的治理。这样，卷的治理能力就能够更加产品化。
- 反对分布式缓存能力。它能够充沛利用计算机的物理资源和本地磁盘，通过集群内的计算节点和网络进行利用。目前咱们理解到，商业版有提供这个性能，但社区版也还没有。
- 挂载点热更新能力。在不同的场景下，用户须要不同的挂载参数，然而卸载和从新挂载的操作太重，会影响用户的业务。用户能够承受短暂的不可读取或者读取中断，然而不能重启业务容器或中断算法或策动程序。咱们正在外部调研和开发这个能力。
编著注：
目录配额需要在 1.1Beta 中曾经实现了，详情请大家关注下周的发版信息。分布式缓存和挂载点更新能力，目前商业版能够提供，这两个性能也在社区版的布局当中。
如有帮忙的话欢送关注咱们我的项目 Juicedata/JuiceFS 哟！(0ᴗ0✿)
