专栏首页焱融科技如何实现支持百亿级文件的分布式文件存储
原创

如何实现支持百亿级文件的分布式文件存储

前言

文件系统是最常用的数据存储形式,所以,常用Linux操作系统的用户必然知道ext4、xfs等单机文件系统,用Windows操作系统的用户也都知道NTFS单机文件系统。各种业务场景下,不同的数据都存储于文件系统之上,大量业务逻辑就是基于文件系统而设计和开发的。提供最常用的存储访问方式,这是我们做文件系统的出发点之一。

另一方面,单机文件系统有其明显限制,主要是容量、文件数量限制,以及可靠、可用性限制。单机文件系统毕竟存储空间有限,且掉电或坏盘等故障会带来数据不可达或丢失。通过分布式文件系统解决这些问题,这是我们的出发点之二。

但做分布式文件系统会面临很多挑战,也会面临非常多的选择。

Google GFS论文面世之后,Hadoop HDFS随之诞生,HDFS的选择是处理大文件,面向MapReduce这种非在线数据分析业务,重吞吐而非延时,对HDFS内部存储的数据进行访问,需要借助其提供的专有命令行和SDK,意味着它并不是一个通用型的文件系统。它的主要架构是元数据服务(本文统一用MetaData Service的缩写MDS来指代元数据服务)和数据服务(本文统一用Data Storage Service的缩写DSS来指代数据服务),其中MDS是单点的,单点的MDS能做出一致的决策,为了保证MDS可靠性,一般会选择再做一个备份。HDFS的DSS则可以是很多个。因为文件大小和形式固定,元数据量不会太大,因而理论上单点MDS就可以支撑,不过单MDS仍限制了集群的规模。

HDFS之后,出现了一些其他的开源分布式文件系统,比如MooseFS。它也是类似的MDS+OSS架构,区别于HDFS的是,MooseFS没有对运行其上的业务做假设,它没有假设业务是大文件或海量小文件,也就是说,MooseFS的定位是像ext4、xfs、NTFS等单机文件系统一样的通用型文件存储。其实MooseFS底下用的就是单机文件系统,可以认为它只是将多台机器上的多个单机文件系统做了一个“逻辑上”的聚合,之所以这么说,是因为从数据角度,它主要是实现了一个多副本功能,而副本间的数据一致性并没有去严肃地保障。从元数据角度,MooseFS提供了一个本质上就是单机的MDS,但为了保证元数据的可靠性,MooseFS通过某些机制,接近实时地备份了元数据。

另外一个更为知名的开源分布式文件系统就是GlusterFS了,相比MooseFS等文件系统,GlusterFS的明显特点是它的“无元”架构,即它没有独立的MDS,GlusterFS使用一致性哈希算法去定位元数据和数据。我们在设计和开发自己的文件系统时,并没有选择这样的架构,因为它的缺点非常明显,例如元数据操作性能很差,而文件系统日常使用中,对元数据的操作占日常操作的比例比极高(50%以上);此外,这种“无元”的文件系统架构对故障的应对不够灵活,服务器进入集群或退出集群都会引起一致性哈希算法的重新计算,从而带来部分数据的迁移,进而影响业务IO。

近两年来,CephFS成为开源分布式文件系统的一颗璀璨新星。Ceph的RADOS对象存储层是一个理论完备且实现优秀的系统。CephFS基于RADOS,它的元数据和数据都是存储到Ceph RADOS之中。Ceph的哲学是首要确保数据稳定性而轻性能,但现实应用中性能往往也是强需求之一,某些场景甚至要求更看重性能。CephFS架构上利用了RADOS,它的MDS数据也存储到RADOS上,而不是存储到本地硬盘,理论和实现角度上看,这种做法可以复用RADOS,但也带来了较大的性能衰减。

CephFS MDS是支持Active-Active模式的,MDS不再是单点,多个MDS共同维护一个统一的命名空间。CephFS实现了它自己提出的动态子树划分算法,其目标是根据文件系统热点情况对MDS做动态的压力均衡。不过在大规模生产环境中,这个功能会带来运维的复杂度,因而实际被开启的不多。

人工智能、移动互联时代的一大数据特征,就是海量文件,为了做一个支持百亿级文件的分布式文件系统,我们该如何思考和设计呢?

方法论

在确定“方法论”之前,我们要先建立一些原则性认识。

其一是不会有one size fits all,我们不可能兼顾所有,必须有侧重点,有侧重就会有舍弃。“取舍”,相信是大多分布式开发者的心得。比如分布式系统,我们不可能突破CAP理论限制。面对各种各样的业务需求,如果我们只满足CP,有的业务对A有强需求怎么办?如果我们只满足AP,那相信我们强调数据一致性的存储工程师就不愿意动手,因为我们深知数据稳定是要坚守的底线。因此我们会细化,会支持针对业务的CA可以进行一定程度上的配置。

其二是要围绕“主线”去做设计,否则上层的实现会积重难返。我们的核心主线之一就是支持百亿千亿级别文件海量文件。从这个主线出发,我们会去针对性地思考关键问题,去做要点设计。我们都知道,核心设计决定未来。前面讨论到的MooseFS和GlusterFS等,为我们众多分布式系统研发者提供了学习案例,在它们基础上实现不了百亿级文件,因为已经积重难返。

下面从这两个原则出发,来讨论一下我们设计自己的分布式文件系统时考虑的要点。

要点设计

要支持百亿级文件,从前面“方法论”提出的大思路出发,我们认为要实现的关键点有以下几点。

采用中心元数据服务器(即MDS)

这几乎是必然选择,只有使用了MDS,CAP中的A才更为可控,系统的整体架构也更加清晰,故障处理更加自如,数据放置策略、故障恢复策略也将更加方便和可控,因为这些行为都在MDS控制之下。

我们使用多MDS共同组成一个统一的命名空间,为了支持百亿级,对目录树必须做切分。围绕“切分”思路,我们可以做多种切分策略,不同策略有不同的效果。如何做策略就是工程实践问题了,从项目管控以及工程实现的复杂度角度考虑,我们目前实现的策略是按目录哈希切分策略,这已经能满足大多数场景的需求。在未来,我们会再实现其他策略。

MDS的另一设计要点是,是否使用本地硬盘。产生这点考虑,是借鉴到了CephFS的经验,CephFS复用RADOS,有好处也有坏处,坏处是性能受到较大影响,好处是工程实践角度更为清晰。我们认为,对元数据的操作要更重视性能,因此我们坚定地选择了MDS直接对接本地硬盘。

选择MDS使用本地硬盘后,下一个要考虑的要点是,是否直接使用本地MDS节点的文件系统,如ext4或xfs。使用本地文件系统,开发和实现会更加高效,,目前我们的选择是直接使用MDS的本地文件系统,将来,为了进一步提升MDS的操作性能,我们会直接操作裸盘的KV系统。

数据存储(即DSS)要点

DSS主要思路是bypass文件系统,跟MDS bypass文件系统类似,这里有两个阶段的考量,第一阶段利用本地文件系统,能快速实现功能。第二阶段是bypass文件系统,DSS直接操作裸盘,即做出一个独立的单机存储引擎,我们的主要考虑点是单机文件系统不利于海量小文件的存储和管理;其次,单机裸盘存储引擎,有助于我们追求更极致的性能,裸盘引擎更利于将来我们对NVMe等新型硬件和SPDK等新型技术栈做深入整合。目前,我们已经推出了基于裸盘的DSS存储引擎。

集群管理要点

分布式集群中,如何对节点是否离线、是否加入等关键事件进行判定,也是要考虑的核心问题之一。我们将这些任务交给集群管理节点,或称为monitor来处理。如何实现monitor集群,不需要多多考虑,基本上是实现一个paxos集群,近几年来用raft是一个“流行”趋势。

副本机制和CAP开关

副本机制是分布式系统实现数据可靠性的关键思路,它带来的CA问题将是面对不同业务时需要考虑的均衡点。如“方法论”所述,我们将CA的权衡做成选项,在不同应用场景中可以有不同的侧重。在这个简单思路之上,魔鬼就在复杂的细节里,难点主要在工程实践之中,充足的测试是验证这一机制的方法。

“瑞士军刀”式功能开关

要实现百亿级分布式文件存储,以上讨论了我们的出发点和“方法论”的关键要点。基于这些点做出来的系统是“骨架”完整的。

但仍如“方法论”所说,没有one size fits all的系统,我们接触的客户需求都是各种各样的,不会一个系统能满足所有业务场景和需求。因而我们的思路是在上面的核心之上,去做丰富的功能,并将主要功能做成开关式控制,某些甚至支持运行时调整。

下面讨论一些主要的功能

分池存储

一个较大规模的分布式集群中,往往会引入不同类型的存储设备。另一方面,用户的多种业务中,往往有关键业务和非关键业务之分。这两个角度,不管从哪个角度来考虑,我们都发现,有将物理资源分池管理的必要性。因此我们实现了对物理资源分池管理的功能,也可称之为分组、分zone,叫法无所谓,其核心要义是提供物理资源划分的能力。

我们实现了这个机制,目前基于这个机制,我们实现了故障域划分的效果,将资源分配到不同池,实现物理上的故障域划分,减小故障时的影响。

分层存储

有不少业务会存储大量冷数据,对冷数据,往往追求存储成本的节约。如果用户提供了SSD和HDD,并计划将海量的HDD空间用作冷存储,用少量的SSD空间用作热存储。我们可以将HDD空间分成一个池,将SSD空间分成一个池,逻辑上将SSD池架设到HDD池之上,实现一个分层存储的功能,将SSD池的冷数据转移到HDD池中去。

数据压缩

这个功能需求往往伴随分层存储存在,针对冷数据存储,用户业务往往会再使用我们的数据压缩功能先做数据压缩。

后记

本文“囫囵吞枣”般介绍了我们是如何去思考和设计百亿级分布式文件系统的。当前网络资源丰富,开源发达,通过借鉴其他系统的经验,再加上以前的积累,我们对做一个百亿级分布式文件系统形成了自己的理解。简单来说做百亿级分布式文件系统,首先是一个思路问题,其次是也很有挑战的工程实践。本文主要简单地讨论了整体“思路问题”部分,以后有机会我们再一起来讨论小模块的设计细节和实现问题。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • NVMe over TCP高性能文件存储,让未来照进现实

    在说NVMe之前,我们觉得有必要先聊一聊NVM(Non-Volatile Memory),即非易失性内存。从名字上看就知道,NVM是一种类内存式(访问及寻址方式...

    焱融科技
  • 你不知道的SSD那些事

    从2005年三星作为第一个进入SSD市场的巨头,到现在短短15年,SSD已经成为非常普遍的存储介质了,相对于机械硬盘HDD,SSD在IOPS上提升了数百倍,带宽...

    焱融科技
  • 什么是ReadWriteMany?

    在Kubenetes体系内,针对每一个持久化存储卷,都有三种访问方式: ReadWriteOnce(RWO), ReadOnlyMany(ROX), ReadW...

    焱融科技
  • Linux sysfs文件系统实现之顺聊Linux文件系统实现

    最近三天写了一个jefffs文件系统,是高仿sysfs文件系统实现的,所以想分享一下sysfs文件系统的实现过程,顺道分享一下我对文件系统的一点理解,...

    jeff xie
  • IBM:区块链让我们重新思考企业,生态和经济

    几个世纪以来,全球贸易一直是人类历史上财富创造的主要渠道,市场摩擦则是财富创造的主要障碍。近年来,商业领域已经克服了很多阻碍发展的障碍。现在出现了很多种信任机...

    点滴科技资讯
  • Windows系统性能分析

    性能调优是系统管理的重要部分,而最常使用的工具就是Windows自带的Performance Monitor了,特别是从windows 2008开始,Perfo...

    张善友
  • 统一业务流程管理平台解决方案

    近几年来,随着中国社会经济的快速发展,经济活动表现出强劲的增长趋势。然而在中国经济发展的过程中,我国的政府和企业都面临着,提高各职能部门的办公效率,并逐步实现职...

    程序源代码
  • 19.16 不发邮件的问题处理

    不发邮件的问题处理 因为虚拟机,可能存在一些bug,第一次配置的时候,经常会出现zabbix发现问题,做了邮件告警,但是邮箱却没有收到邮件的问题; 重新恢复快照...

    运维小白
  • 通过深度学习实现安全帽佩戴的检测

    前一段时间做企业的智能安全项目,我们在面对一些问题时,大胆采用深度学习的方法,解决传统算法和统计学算法不好实现的问题,今天就和大家分享一下,如何解决通过视频监控...

    用户1332428
  • 快点进来get“推荐系统常用的推荐算法”

    ? 一、推荐系统概述和常用评价指标 1.1 推荐系统的特点 在知乎搜了一下推荐系统,果真结果比较少,显得小众一些,然后大家对推荐系统普遍的观点是: (1)重...

    小莹莹

扫码关注云+社区

领取腾讯云代金券