嘉宾：王鹏飞，焱融云 CTO
引言：
近年来，容器技术和云原生应用越来越多地占据企业级市场，有状态容器业务也开始得到广泛使用，包括结构化数据库、非结构化数据库、数据分析、内容管理、CI/CD、海量数据共享等业务场景需要对容器的数据进行持久化，容器持久化存储成为企业 IT 系统的刚需。近日，CNCF 发布了最新版本的 Cloud Native Landscape，焱融云 YRCloudFile 被列入云原生全景图谱，位于云原生存储象限中，这是国内首个被收录的容器持久化存储产品。InfoQ 记者专访到了焱融云 CTO 王鹏飞，揭秘这家成立3年多的创业公司是如何凭借技术实力在竞争激烈的分布式存储市场取得一席之地的。
正文：
“经历了华为、中兴事件后，更加深了我们对自研的重视”
互联网的规模越来越大，并发请求也越来越高，传统的集中式存储并不能很好地满足各种场景的需求，于是分布式储存系统得以广泛应用。王鹏飞提到，“2011年我在IBM工作的时候就开始接触到分布式存储，一直到现在，其实我经历了分布式存储整个蓬勃发展的过程”。随着互联网经济的迅速发展，带动各行各业的应用呈爆发式增长，对存储的需求也越来越高，场景划分越来越细。这是焱融云创立的一个出发点，就是要做一款好的分布式存储。
据王鹏飞介绍，目前市场上做分布式存储的公司主要集中在大厂，比如浪潮、NetApp、华为等。其他一些相对而言较小的公司，主要利用 GlusterFS、CephFS 甚至 Lustre 等一些开源的分布式文件系统。焱融云从2017年开始推出基于高性能分布式文件的容器存储。YRCloudFile 的定位是统一管理所有服务器磁盘并提供统一命名空间的文件系统，采用分布式架构，单集群最多可以支撑上万个 client 同时访问。YRCloudFile 可以帮助企业达到对数据的自主可控，其统一命名空间的特点在于，用户无需感知下层存储的物理结构以及部署架构;对上层应用而言，它是一个统一的海量文件系统存储空间。
YRCloudFile 是国内首家进入CNCF Landscape Cloud-Native Storage 的容器存储产品，无论在接口适配、生态合作，还是容器存储特殊场景的支持上，焱融云在国内都处于领先地位。在性能上，YRCloudFile 在最新发布的 IO500 存储系统性能测试榜单中，也进入了全球 Storage Vendor的前十。无论对大文件顺序读写，还是对小文件的操作性能上，YRCloudFile 都通过 IO500 的测试得到了验证。
谈及如何在大厂夹击、竞争激烈的存储市场保持竞争优势，王鹏飞提到了三点：
首先是自研。经历过中兴、华为等事件后，科技公司对自研的感受变得更加深刻，只有自己的，才是长久的。焱融云的存储团队有丰富的存储系统开发、维护等经验，核心团队成员在金山云、百度等做过多年的存储开发，可以说在人员配置上，焱融云具备了自研的底气。
其次是性能。YRCloudFile 存储层软件对 IO 路径进行了 优化，可以充分发挥出底层硬件的特性，配合整个系统的缓存技术，提供更高的性能。同时针对新的网络、硬盘技术，比如 RDMA、NVMe 都进行了完美的适配。王鹏飞提到，“前段时间与 Mellanox 以及 E8Storage 分别发布了联合测试报告，同等硬件条件下，性能比某大厂同类产品要高出50%”。
还有一点是对容器场景的支持。YRCloudFile 可以适配 Kubernetes 的各种版本，无论创建方式是动态创建还是静态创建，都可与容器平台紧密结合。
容器持久化存储逐现峥嵘
近几年容器的热度持续上升。在2018年11月，OpenStack Summit 更名为 Open Infrastructure Summit，对此官方给出的解释是拥抱开源、拥抱K8S、拥抱容器化。这也从另一个角度证明，容器化已经成为 IaaS 平台的事实标准。
从2018年Gartner技术趋势图中也可以发现，专门针对容器应用场景的持久化存储 Container-Native Storage 正处于明显上升趋势，其特点是：首先它专门为支持容器而设计;其次它能够满足容器应用的扩展以及性能需求;第三它与容器管理系统 整合;最后它支持大量系统的并行访问。
2018年Gartner技术趋势图
伴随着 K8S 和容器化的发展，越来越多的用户有了灵活的业务选择能力。与此同时，对于业务数据的困扰也随之而生。存储在容器内部的任何数据，在容器被销毁以后，这些数据将自动消失，例如网站页面、配置文件、数据库和大数据应用等。因此，在企业真正运行环境中，如何实现容器持久化存储一直是业界的热点问题。
容器持久化存储面临的挑战
从Kubernetes官方社区支持的存储列表中可以看到，目前容器持久化存储分为两类，一种是块存储，例如 Ceph、OpenEBS 等;另一种是文件类存储，如 GlusterFS、CephFS 等。当然还有很多传统的存储设备等。但绝大部分的存储是早在容器普及之前就已经出现了，换句话说，大部分存储不是为容器持久化而设计和开发的。
目前容器持久化存储主要面临的挑战有四点：
缺乏存储软件和工具
担心数据丢失
现有存储扩展性差
传统 SAN/NAS 阵列灵活性和容器场景针对性差
具体来看，如果是块存储类型，如CephRBD，首先会面临一个多挂载的问题，使其无法提供ReadWriteMany(RWX)这一非常重要的访问方式，这对一些应用的部署方式会产生影响;其次，在 Kubernetes 工作节点(Worker Node)发生故障，需要对有状态 Pod 进行跨节点迁移时，Kubernetes 需要对块设备进行 umount/deattach/reattach /remount 操作，这是一个耗时并且易错的过程，这就阻碍了容器的快速恢复。以上两点是 CephRBD 这种块存储用作容器存储时面临的问题。而对于文件类存储，如GlusterFS，在大量的小文件以及目录层次复杂时将面临着较大的性能压力。
容器持久化存储是 YRCloudFile 的“杀手锏”
容器平台天生适合无状态应用，如Web前端、Nginx 代理等，这1是从2017年 Kubernetes 蓬勃发展以来，用户利用容器平台的典型场景。但随着平台的成熟、使用的深入，越来越多的用户期望将其他的应用迁移到容器平台内，如典型的数据库、数据共享等。
这就面临一个难题，如何为这类有状态的应用提供存储?很明显本地存储是不合适的，因为随着容器的迁移，这些数据将无法做到应用的跟随，客户需要一个能够适配容器场景的存储。王鹏飞提到，“我们在面对一些客户时，他们当前往往考虑的是如何把应用放到容器上去，而对于底层存储的选择只限于能够工作即可。但很快他们就会发现，只满足于能够工作是远远不够的，一个好的存储非常重要”。
YRCloudFile 架构设计
YRCloudFile 是一款有元数据服务的分布式文件存储产品，支持元数据服务和数据服务的线性水平扩展。元数据服务节点数可以支持多达256个，数据服务节点可以支持多达1024个，客户端节点可以支持上万个。能够支持海量文件存储，文件数据可以支持千亿级别，容量可扩展到EB级别。支持RDMA协议，能够提供亚毫秒级别的延迟。支持文件切片和数据冗余，能够提供良好的带宽。支持冷热数据分层，在保证高性能的同时，能够节约成本。支持容器存储，能够完美兼容CSI/FlexVolume接口。YRCloudFile 对接容器编排平台如下图所示。
YRCloudFile 对接容器编排平台
YRCloudFile 的容器化支持
可以说，YRCloudFile 对容器具有天然的支持优势。主要体现4在访问模式上，YRCloudFile 支持三种访问模式：RWO、ROX、RWX，满足各种应用对存储的使用要求，并且针对不同的访问方式做了 优化。
YRCloudFile 是最早支持CSI容器存储接口的存储产品之一，而 CSI 是整个容器生态的标准存储接口，可以平滑支持 Kubernetes V1.13及以后的版本。针对CSI接口出现故障，比如存储链路中断、网络故障等时，YRCloudFile 创造性地开发了对故障的动态感知功能，即当CSI状态出现问题时，K8S 会标记该Node，从而避免 Master 节点把新建有状态 Pod 分发到该 CSI 故障 Node，而不影响整个集群效率。
双活数据中心，是YRCloudFile容器存储的又一亮点，该功能使得跨数据中心部署业务的复杂度大大降低，其容器存储双活如下图所示。
容器存储双活部署设计
其设计思路是：管理员在YRCloudFile上创建一个跨数据中心的存储池pool1，当依赖持久化数据的业务需要跨数据中心部署，且希望获得双活特性时，可以将PV通过storageclass配置在pool1中。这样，写入该PV的数据会同时分布到两个数据中心，任何一个数据中心发生火灾或电力中断等灾难故障时，pool1在另一个数据中心的数据副本都可以继续提供读写服务。同时，借助YRCloudFile支持有状态容器快速恢复和迁移的特性，可以帮助管理员快速地将故障数据中心上运行的业务迁移至安全的数据中心。
客户除了需要依赖双活容器存储池进行跨数据中心部署的应用，也有只需要部署在某一数据中心内的应用，这种应用只要把数据存放在应用所在的数据中心即。这时，管理员可以在同一个YRCloudFile集群的统一命名空间内，创建另外一个新的存储池pool2，pool2的数据副本策略设置为同一个数据中心。管理员通过YRCloudFile提供的另一个storageclass，即可将PV创建在pool2。这样，有状态应用容器所生成的数据副本，就都管理在pool2内，数据的读和写都发生在本数据中心了。YRCloudFile 的双活容器存储、本地优先读、双活存储池加本地存储池统一管理的功能，大大增强了 IT架构的灵活性。
除了以上之外，YRCloudFile 还做了很多其他的工作。首先，把K8S的存储(PV/PVC/Pod)呈现在了YRCloudFile管理界面，提供可视化功能，用户可以在管理界面清楚了解Pod、PV 使用量、PVC 关联关系。并且能通过名称、大小、Label 等对 PV/PVC/Pod 进行搜索和筛选，方便用户管理。
其次，可针对实际应用中大量PV场景下，提供PV Hot Spot 功能，对热点PV进行跟踪和定位，保障系统的稳定运行。 并且能针对每一个 PV 设置性能告警功能，对重点需要监控的PV，设置PV性能告警阈值，实现细粒度的管理和监控。
第三，YRCloudFile 还提供了QoS功能。用户可以通过参数设置限制 PV 的 IOPS 及 BandWidth;从而达到有效利用存储资源的效果，保障关键应用的性能。
YRCloudFile 的QoS功能示意
第四，YRCloudFile 还提供 PV Insight 功能，以图形化的方式，从三个维度(数据层次、文件大小、数据温度)帮助用户对业务进行分析和调整。
第五，YRCloudFile 提供了 PV Resize 功能，当企业需要调整 PV 配置额外存储但又无法忍受服务中断时间时，通过 PV Resize 功能，不需要将应用程序或服务脱机，只需一个简单的操作，即可以调整PV的大小。
最后，YRCloudFile 还提供自定义的Prometheus exporter，向 Prometheus server 提供集群监控数据，并且提供基于 Grafana 的集群监控 Web 展现模板。用户可以统一观察到所有集群的状态，从而提高运维的效率。
YRCloudFile的其他创新优势
YRCloudFIle 的高性能
CephFS 是构建在 RADOS 基础上的，而Ceph的OSD性能损耗比较大，越是性能好的硬件，体现出来的性能损耗则越大。同时 CephFS 的多 MDS 架构实现非常复杂，尤其是当文件数量大了之后，其体现出来的性能跟理论值差距非常大。NAS的性能主要受限于NAS网关的数量和NFS协议，通常情况下，NAS网关只有2～4个，因此带宽受到很大限制，同时NFS的协议消耗也比较大。
根据大量的实践和测试，最终 YRCloudFIle 采用轻量级的数据模型和动态子树的多MDS方案，与Ceph不同的是，YRCloudFIle不会在内存中维护 B+ tree，而是将其持久化到磁盘中，结果就是相对简洁稳定。即使在百亿级的文件数量场景，性能衰减也很小。同时 YRCloudFile 采用专有客户端进行数据访问，避免了 NFS 协议的消耗，性能有保障。
YRCloudFIle 有效应对海量小文件场景
随着移动终端使用频繁，文件碎片化越来越严重，以前一些传统的存储并不能很好地支撑小文件的场景。比如一个传统存储，在运行大文件读写的时候性能非常好，但随着场景的复杂化，导致各种各样应用都需要把数据放到存储里，从而产生了大量的小文件，不管是查询还是访问，性能降低得很明显。这是传统存储技术面临的问题，即如何存储小文件。以GlusterFS举例，在典型的用户场景，即存储的都是大文件(例如日志)时，工作良好;但是当容器内需要产生海量小文件时，性能上就无法满足需求了。
YRCloudFile可以同时支持海量小文件存储和大文件存储，这在业界还是比较少见的。其具体实现思路是：
首先，基于元数据服务可以随时扩展的特性。由于元数据信息存在磁盘里面，所以可以通过元数据集群规模的扩大来支撑海量小文件，比如现在有几千万个小文件，2个元数据节点就够了;如果有几亿个元数据，可以将元数据扩展成4个甚至更多。
其次，通过动态算法实现负载均衡。YRCloudFile 会根据整个集群元数据的分布的情况，包括流量信息等，通过把这些信息分散在不同的元数据节点里，使得一个目录里即使有非常海量的小文件也不会影响访问效率，这样相当于消除了某一个元数据节点的热点问题，实现负载均衡，充分利用底层多个元数据节点的服务能力。
第三点就是使用自定义协议。为了充分利用 YRCloudFile 本身提供的一些性能，焱融云开发了客户端，通过自己开发的协议，提高通信效率，也提高了对小文件读写的性能。
加入CNCF云原生全景图谱后，YRCloudFile 的未来?
YRCloudFile 在近期发布的几个版本中，逐渐丰富了对容器的整合能力;并推出了支持数据的冷热分层的智能分层功能，在提供同样性能的基础上为用户节省更多的成本;同时也支持了Harbor HA，从生态的角度让拼图更加完整。
对于YRCloudFile 的未来规划，王鹏飞提到两点：首先，焱融云会保持高性能的分布式文件系统以及容器存储的方向，无论是对新技术的支持，还是本身软件的优化，会一直持续进步。
再者，焱融云会全面拥抱Cloud Native这个大家庭，包括自身产品的容器化方案的能力，到与 Harbor、Etcd以及Promethues 等软件的整合，将专注于容器存储本身，加强与容器平台的厂商合作。 (关贺宇)
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
