自制文件系统 —— 05 总结:一切都为了狙击“文件”

694 阅读10分钟

[toc]

image.png

为什么会有这个系列?

自制文件系统系列的开端,主要是因为绝大部分人用到了文件这个概念,但是总是不以为然或者讳莫如深。其实关键还是对其原理缺乏了解。

总有朋友对 inode,文件的管理,权限等等有疑问,而这些只是最基础的概念。

自制文件系统的诞生理由就来源于此,目的是让大家认清楚,文件系统不过如此,朴实无华。

自制 FS 系列的特点

自制文件系统系列是一个完整的系列,从最开始教你看文件系统,介绍 FUSE 框架,最后做一个只读的文件系统,再做一个可写的分布式文件系统,是层层递进的。

03,04 篇介绍了原理并且附有完整的 Go 实现代码,可以让 0 基础的朋友,也能完整的制作出来,至于领悟多少,就看个人发挥了。

自制文件系统系列是典型的实战系列,着眼于动手,而不是纯粹的讲解。并且笔者也尽可能的把复杂的,非主干的知识剔除,目的是让你感受纯粹的文件系统,文件的概念。

我们学到了什么 ?

  1. 亲自参与了文件的组织管理,权限的配置,内容的处理,加密存储,解密读取;
  2. 亲自参与了数据的跨节点传输;
  3. 亲手捕捉了来自内核的 IO 请求;

分布式存储远不止如此!

你以为文件系统就这样了吗?不不不,还远远不够。

我们在 04 篇 里提到了分布式文件系统的架构,分为 Client,元数据中心,Server 这三大部分。

客户端

Client 一般会有哪些功能在里面?如下图:

image.png

哈希策略

客户端主要是承接用户请求,然后把请求分发到后端服务器,这里就涉及到怎么分发的策略了。

image.png

一般有 3 类分发策略:

  1. 轮询:请求依次分发,这样能保证每一个后段节点都能得到请求;
  2. 普通哈希:普通的哈希策略,这个考量一定的随机性,一般可以选定一个随机因子。比如时间戳,请求数等等;
  3. 一致性哈希:这个方式在扩缩容的场景有比较好的表现,能够保证在扩缩容的保证迁移量控制在一个常数级别;

轮询下发示意图:

轮转请求动画.gif

思考问题:哈希策略是为了后端节点的请求均衡,那如果由于各种原因已经导致了不均衡,怎么办?

这时候就要提到重要话题了:均衡迁移,一般也叫做 balance ,目的就是为了每个节点的数量平衡。

由于 balance 迁移一般会跟正常业务抢占 IO 资源,所以这里会涉及到 Qos 的策略,并且 balance 的触发时机和力度都是必须要考虑的。

哈希均衡是一个分布式系统里重要的模块功能,关系到怎么才能合理利用分布式机器节点。

副本策略

副本就是数据存储多个副本的意思,这样就避免单点问题,数据就算丢了一份,还有其他份,这样可以提高可靠性。

多副本说起来简单,但其实有很有讲究,其中最关键就是一致性的问题。

怎么能保证写下去的数据是一致的?这里就关乎策略了,都写成功了才算成功,还是写部分成功了就报告成功?

上面分别对应两大类策略:WARO(Write ALl Read One),Quroum。这两大策略被统一在 CAP 理论里面,你要可用性高,那么必然要容忍一段时间的不一致。要数据完全一致,同一个副本组那么可用性就会拉跨。

WRAO WARO写操作.gif

Quroum

quorum写机制.gif

现在讲了副本的策略,那么组成副本的形式又有哪几种呢?

这个其实可以按照粒度来区分,一般有几种形式组成副本:

  1. 文件级别
  2. 磁盘级别
  3. 主机级别

主机级别

  • 优点:这个简单了,把多台主机组成副本镜像,主机的数据完全一致,互成镜像;
  • 缺点:修复的粒度太大,扩容、缩容的粒度必须是副本数倍数的主机数,而且要是同构的机器,这个给资源准备提出了高要求;

image.png 磁盘级别

  • 优点:磁盘镜像(这个跟 raid 1 很像,区别在分布式上)实现比主机级别的复杂点,这个是把多个磁盘组成副本镜像组。这个扩容、缩容的粒度就可以做到磁盘级别;
  • 缺点:实现自然是比主机镜像要复杂,修复粒度还是较大,副本粒度还可以再做小一点;

image.png

文件级别

  • 优点:把多个文件组成副本镜像组,副本粒度更小,调度更灵活。并且可以实现全局打散,让一块磁盘和所有的主机产生副本关系。这样在修复盘的时候,效率最高;
  • 缺点:但同样的,粒度越小实现越复杂,元数据膨胀,越难管理;

纠删码策略

纠删码也是数据冗余的一种策略,和副本不同,纠删码能够做到更高的可靠性和更低的冗余度。什么意思?

image.png 举个例子:

  • 在 3 副本系统中,1 TiB 的用户数据,需要 3 TiB 的物理空间。只能容许一个副本节点损坏;
  • 在 6+3 的纠删码系统中,1T 的用户数据,只需要 1.5 TiB 的空间,能够容许 3 个节点损坏;

纠删码的优势够大,对吧?特别是在这个数据为王的时代。公有云厂商如果用更低的价格存储了更多的数据,那就有极大的竞争力。

俗话说的好,天下没有免费的早餐。纠删码也是如此,虽然有更高的可靠性,还有更低的冗余度。但是却带来更复杂的管理,还有更多的计算能力要求。

划重点:校验块是要用算法计算出来的,吃 CPU ,所以纠删码的节点,CPU 不能太差。因为写的时候要计算,修复读的时候要计算。

修复策略

修复策略,这个跟冗余策略是关联的。

  • 副本镜像策略的话,修复就是数据拷贝成镜像即可,把数据源拷贝到目的文件;
  • 纠删码的修复就是通过算法计算出缺失的数据块,然后写到目的地(这里是要吃计算能力的);

元数据中心

元数据中心一般有哪些功能?

image.png

顾名思义,就是元数据集中放置的地方,一般会放置一些用户的元数据,当然还有集群本身的元数据。这是一个非常重要的角色,但是由于过于重要,所以问题也常常会出现在这里,比如性能瓶颈,单点故障,那遇到这种情况,你会怎么做呢?

怎么解决单点故障

划重点:以前说过的,使用冗余的节点是解决单点故障的唯一途径。 多节点随之而来的是一致性,所以一般用 Paxos,raft 或者其他一致性算法来管理管理多节点,形成一个对外有机的整体。

怎么解决性能问题

性能这个就尴尬了,除非是支持线性扩容,否则这元数据中心必定是有性能极限的。所以一般通过固化集群规模,搭建多个集群来解决。

更极端一点

是的,还有更极端的方式:取消元数据中心,设计一个无元数据的集群。

有项目实践的例子吗?

有,比如 Glusterfs ,就是一个典型的实现,最大的特点就是无元数据中心。

服务注册发现

一般元数据中心还可以加上一个服务注册发现的功能,这样就能在集群组件扩容,缩容的时候从容面对。

集群拓扑管理

集群拓扑的管理是元数据中心必须承担的责任。比如副本镜像的绑定关系,纠删码的绑定关系,存储节点的状态维护等等。

举个例子,A,B,C 这三台主机组成一个主机镜像。

192.168.56.1
192.168.56.2
192.168.56.3

这样写数据的时候如果选到了这组主机镜像,那么就只需要把请求发往这三台主机。

服务端

Server 一般有哪些功能?

image.png 存储服务端最核心的就是存储用户数据,管理磁盘空间,这是最核心的需求。

在这个模块什么是最重要的考虑?

稳定和安全。怎么把数据快速的存入,安全的持久化,快速的读出 是这个模块最核心的诉求。

存储引擎

所谓存储引擎就是最底层存储数据的模块,比如和文件,或者块设备打交道的模块。目的是掏空硬盘硬件的性能,跑出最高 iops,最高吞吐,最低时延 是这里的毕生追求。

这里的主角是 IO ,引擎模块就是要极限的压榨出 IO 的极限性能。

举个例子?

有,很多,比如 rocksdb 其实就可以作为一个很好的存储引擎模块,这个是一个 kv 存储引擎库,以前常用于 mongodb 的底层。当然了,现在 mongodb 已经改用 WiredTiger 这个存储引擎。

空间回收策略

业务上增、删、改是常有的事。数据新增了要扩容,删除了自然要回收,这样才能达到重复利用空间的目的。怎么回收?很简单的,就是把删除的空间腾出来即可。如下,Compact 就是一个非常简单的方式。

image.png

磁盘坏盘策略

磁盘坏盘是经常的,所以换盘的流程是 必须要设计的。这个是做到服务端(当然要客户端配合)。这个原则是什么呢?当然是数据安全。只有确认数据能够修复回来,那么就可以安全换盘。

这里只提到了一些最关键的模块,其实还有很多模块没提到,比如缓存策略,Qos 模块,任务调度策略等等。

对哪些人适用?

  1. 做存储的,对象存储,块存储,文件存储等从业人员;
  2. Linux 后端开发人员;
  3. 大学生,正在理解“文件”的概念;
  4. Go 开发人员,对存储感兴趣的开发人员;

总结

  1. 自制文件系统系列通过介绍文件系统,框架原理介绍,动手实践形成一个完整的系列文章,让人从 0 开始感受了一个文件系统的诞生;
  2. 文件系统内部也是分布式的,客户端和核心功能是协议解析,请求均衡转发,冗余策略(副本策略、纠删码策略),修复策略,等等。服务端的核心模块是存储引擎(单机存储),磁盘管理;
  3. 希望能让大家理解到一个观点:“文件”就是这样朴实无华。

后记

文件系统远不止如此,但是后续的功能就不在这个模块讲了,这个系列就只狙击“文件”的概念。自制系列完结撒花,后续更新其他系列文章。坚持思考,就会很酷。

原创不易,更多干货,关注奇伢云存储