GlusterFS培训 中科院高能物理研究所计算中心 李海波 2015-8-17
提纲 GlusterFS系统概述 GlusterFS工作原理剖析 设计讨论 系统实战 Haibo Li/CC/IHEP 2018/11/15 - 2
(一)GlusterFS系统概述 Haibo Li/CC/IHEP 2018/11/15 - 3
GlusterFS是什么? GlusterFS is a unified, poly-protocol, scale-out filesystem serving many PBs of data. 用户空间设计,全局统一命名空间,堆栈式架构 scale-out在线扩展,数百节点,数PB数据 一切皆文件,block+object+file https://github.com/anoopcs9/glusterfs http://www.gluster.org/ Haibo Li/CC/IHEP 2018/11/15 - 4
GlusterFS起源 Gluster名字来源于GNU plus Cluster. 由Hitesh Chellani 和Anand Babu Periasamy于2006年创立 寻求高性能计算和可扩展存储解决方案。 300,000 + 下载:35,000/月,每年增长300%+ 1000 + 部署案例(45个国家) 2000 + 注册用户 http://yourstory.com/2011/09/yourstory-exclusive-california-based-indian-entrepreneurs-powering-petabytes-of-cloud-storage-the-gluster-story/ Haibo Li/CC/IHEP 2018/11/15 - 5
GlusterFS标签 Haibo Li/CC/IHEP 2018/11/15 - 6
GlusterFS特点 架构简单,使用方便 无元数据服务器,无单点故障 全用户空间设计,堆栈式扩展 高性能可扩展 支持多种访问协议,支持RDMA Haibo Li/CC/IHEP 2018/11/15 - 7
(二)GlusterFS工作原理剖析 Haibo Li/CC/IHEP 2018/11/15 - 8
GlusterFS架构设计目标 弹性 线性扩展 消除元数据服务器 简单 灵活适应增长/减少 增加,删除 卷和用户 无中断 多维度 聚合资源 性能 容量 聚合资源 消除元数据服务器 提升文件访问速度 简单 易管理 基于用户空间 Haibo Li/CC/IHEP 2018/11/15 - 9
GlusterFS架构特点 Haibo Li/CC/IHEP 2018/11/15 - 10
GlusterFS总体架构 Gluster主要由存储服务器(Brick Server)、客户端以及存储网关组成。Gluster架构中没有元数据节点,这是其最大的设计特点,对于提升整个系统的性能、可靠性和稳定性都有着决定性的意义。客户端可通过原生Gluster协议访问数据,对于不支持运行Gluster客户端(如Windows系统)的节点可采用NFS/CIFS标准协议通过存储网关访问存储系统。 存储服务器主要提供基本的数据存储功能,数据通过弹性哈希算法分布在不同的存储服务器上。存储服务器运行Gluster的后台服务进程,负责处理来自客户端的数据服务请求。数据以原始格式直接存储在服务器的本地文件系统上,如EXT3、EXT4、XFS、ZFS等,运行服务时指定数据存储路径。 在客户端方面,由于没有元数据服务器,客户端需要实现数据卷管理、I/O调度、文件定位、数据缓存等功能。客户端利用FUSE(File system in UserSpace)模块将Gluster挂载到本地文件系统之上,以POSIX兼容的方式来访问系统数据。Gluster客户端的负载相对传统分布式文件系统要高,包括CPU占用率和内存占用。 Gluster存储网关提供弹性卷管理和NFS/CIFS访问代理功能。卷管理器负责逻辑卷的创建、删除、容量扩展与缩减、容量平滑等功能,并负责向客户端提供逻辑卷信息及主动更新通知功能等。对于Windows客户端或没有安装Gluster的客户端,需要通过NFS/CIFS代理网关来访问,这时网关被配置成NFS或Samba服务器。 Haibo Li/CC/IHEP 2018/11/15 - 11
全局统一命名 通过分布式文件系统将物理分散的存储资源聚集成统一的虚拟存储池。 存储资源可按需进行弹性扩展,扩容或收缩 可通过单一挂载点进行数据共享。 Haibo Li/CC/IHEP 2018/11/15 - 12
无集中元数据服务器 采用弹性哈希算法在存储池中定位数据。 实现了真正的线性扩展。 数据恢复简单。 Haibo Li/CC/IHEP 2018/11/15 - 13
GlusterFS堆栈式软件架构 Haibo Li/CC/IHEP 2018/11/15 - 14
GlusterFS基本概念 Brick Translator Volume Node/Peer 文件系统挂载点 按层级提供功能 Volume 由brick通过translator组合而成 Node/Peer 运行gluster进程的服务器 Haibo Li/CC/IHEP 2018/11/15 - 15
Translator Haibo Li/CC/IHEP 2018/11/15 - 16
Translator GlusterFS提供的一种强大文件系统功能扩展机制,这一设计思想借鉴于GNU/Hurd微内核操作系统。 GlusterFS中所有的功能都通过Translator机制实现,运行时以动态库方式进行加载,服务端和客户端相互兼容。 (1) Cluster:存储集群分布,目前有AFR, DHT, Stripe三种方式 (2) Debug:跟踪GlusterFS内部函数和系统调用 (3) Encryption:简单的数据加密实现 (4) Features:访问控制、锁、Mac兼容、静默、配额、只读、回收站等 (5) Mgmt:弹性卷管理 (6) Mount:FUSE接口实现 (7) Nfs:内部NFS服务器 (8) Performance:io-cache, io-threads, quick-read, read-ahead, stat-prefetch, sysmlink-cache, write-behind等性能优化 (9) Protocol:服务器和客户端协议实现 (10)Storage:底层文件系统POSIX接口实现 Haibo Li/CC/IHEP 2018/11/15 - 17
Cluster Translator 分布式集群,文件通过HASH算法分散到集群节点上,每 个节点上的命名空间均不重叠,所有集群共同构成完整的 命名空间,访问时使用HASH算法进行查找定位。 复制集群,类似RAID1,所有节点命名空间均完全相同,每 一个节点都可以表示完整的命名空间,访问时可以选择任 意个节点。 条带集群,与RAID0相似,所有节点具有相同的命名空间, 但对象属性会有所不同,文件被分成数据块以Round Robin方式分布到所有节点上,访问时需要联动所有节点来获得完整的名字信息。 AFR相当于RAID1,同一文件在多个存储节点上保留多份,主要用于实现高可用性以及数据自动修复。AFR所有子卷上具有相同的名字空间,查找文件时从第一个节点开始,直到搜索成功或最后节点搜索完毕。读数据时,AFR会把所有请求调度到所有存储节点,进行负载均衡以提高系统性能。写数据时,首先需要在所有锁服务器上对文件加锁,默认第一个节点为锁服务器,可以指定多个。然后,AFR以日志事件方式对所有服务器进行写数据操作,成功后删除日志并解锁。AFR会自动检测并修复同一文件的数据不一致性,它使用更改日志来确定好的数据副本。自动修复在文件目录首次访问时触发,如果是目录将在所有子卷上复制正确数据,如果文件不存则创建,文件信息不匹配则修复,日志指示更新则进行更新。 DHT即上面所介绍的弹性哈希算法,它采用hash方式进行数据分布,名字空间分布在所有节点上。查找文件时,通过弹性哈希算法进行,不依赖名字空间。但遍历文件目录时,则实现较为复杂和低效,需要搜索所有的存储节点。单一文件只会调度到唯一的存储节点,一旦文件被定位后,读写模式相对简单。DHT不具备容错能力,需要借助AFR实现高可用性, 如图5所示应用案例。 Stripe相当于RAID0,即分片存储,文件被划分成固定长度的数据分片以Round-Robin轮转方式存储在所有存储节点。Stripe所有存储节点组成完整的名字空间,查找文件时需要询问所有节点,这点非常低效。读写数据时,Stripe涉及全部分片存储节点,操作可以在多个节点之间并发执行,性能非常高。Stripe通常与AFR组合使用,构成RAID10/RAID01,同时获得高性能和高可用性,当然存储利用率会低于50%。 Haibo Li/CC/IHEP 2018/11/15 - 18
GlusterFS系统组件 Glusterd Glusterfsd Glusterfs 弹性卷管理进程 运行在server上 GlusterFS brick进程 每个brick一个进程 由glusterd管理 Glusterfs NFS server进程 FUSE客户端进程 Haibo Li/CC/IHEP 2018/11/15 - 19
GlusterFS系统组件 mount.glusterfs gluster FUSE本地挂载工具 Gluster控制管理器 Haibo Li/CC/IHEP 2018/11/15 - 20
数据访问 Gluster本地客户端 NFS SMB/CIFS Filesystem in Userspace(FUSE) 内置的服务 需要Samba server Haibo Li/CC/IHEP 2018/11/15 - 21
弹性哈希算法 GlusterFS采用的是去中心化的存储方式,文件定位在客户端即可完成。 1. 所有的文件会被hash到一个32位的整数空间 2. 对于每个文件夹,存储节点上该文件夹的扩展属性里会标明该文件夹的hash range,落到该range的文件会存储到该节点上 3. 客户端在连接服务器端时,会要求获取某个文件夹在所有存储节点上的hash range 4. 访问文件时,客户端会计算该文件的hash值,然后访问对应的节点 5. 新增节点时,不改变已存在的文件夹的扩展属性,因此在已存在的文件夹下创建新文件时,该文件仍会放到老节点上 Haibo Li/CC/IHEP 2018/11/15 - 22
弹性hash算法流程 Haibo Li/CC/IHEP 2018/11/15 - 23
Gluster卷类型 基本卷 复合卷 哈希卷(Distributed Volume) 复制卷(Replicated Volume) 条带卷(Striped Volumes) 复合卷 哈希复制卷(Distributed Replicated Volume) 哈希条带卷(Distributed Striped Volume) 复制条带卷(Replicated Striped Volume) 哈希复制条带卷(Distributed Replicated Striped Volume) Haibo Li/CC/IHEP 2018/11/15 - 24
哈希卷 文件通过hash算法在所有brick上分布 文件级RAID 0,不具有容错能力 Haibo Li/CC/IHEP 2018/11/15 - 25
哈希卷工作原理 Haibo Li/CC/IHEP 2018/11/15 - 26
复制卷 文件同步复制到多个brick上 文件级RAID 1,具有容错能力 写性能下降,读性能提升 Haibo Li/CC/IHEP 2018/11/15 - 27
复制卷工作原理 Haibo Li/CC/IHEP 2018/11/15 - 28
条带卷 单个文件分布到多个brick上,支持超大文件 类似RAID 0,以Round-Robin方式 通常用于HPC中的超大文件高并发访问 Haibo Li/CC/IHEP 2018/11/15 - 29
复合卷:哈希+复制 哈希卷和复制卷的复合方式 同时具有哈希卷和复制卷的特点 Haibo Li/CC/IHEP 2018/11/15 - 30
复合卷:哈希+条带 哈希卷和条带卷的复合方式 同时具有哈希卷和条带卷的特点 Haibo Li/CC/IHEP 2018/11/15 - 31
复合卷:条带+复制 类似RAID 10 同时具有条带卷和复制卷的特点 Haibo Li/CC/IHEP 2018/11/15 - 32
复合卷:哈希+条带+复制 三种基本卷的复合卷 通常用于类Map Reduce应用 Haibo Li/CC/IHEP 2018/11/15 - 33
Distributed Hash Table (DHT) GlusterFS弹性扩展的基础 确定目标hash和brick之间的映射关系 Haibo Li/CC/IHEP 2018/11/15 - 34
添加节点 添加新节点,最小化数据重新分配 老数据分布模式不变,新数据分布到所有节点上 执行rebalance,数据重新分布 Haibo Li/CC/IHEP 2018/11/15 - 35
容量负载均衡 Hash范围均衡分布,节点一变动全局 目标:优化数据分布,最小化数据迁移 数据迁移自动化、智能化、并行化 Haibo Li/CC/IHEP 2018/11/15 - 36
文件更名 文件更名:FileA FileB 原先的hash映射关系失效,大文件难以实时迁移 采用文件符号链接,访问时解析重定向 Haibo Li/CC/IHEP 2018/11/15 - 37
脑裂 所谓脑裂,就是指两个或多个节点都“认为”自身是正常节点而互相“指责”对方,导致不能选取正确的节点进行接管或修复,导致脑裂状态。 Glusterfs的冗余镜像(AFR)提供了数据副本功能,能够在即使只有一个冗余节点的情况下仍能正常工作,不中断上层应用。当节点恢复后,能够将数据修复到一致状态,保证数据的安全。 两个副本均为WISE时发生脑裂。 解决方法:1、报错处理;2、Quorum方法(N=2?);3、仲裁机制 Haibo Li/CC/IHEP 2018/11/15 - 38
(三)设计讨论 Haibo Li/CC/IHEP 2018/11/15 - 39
无元数据服务器 vs 元数据服务器 优点 没有单点故障和性能瓶颈问题,可提高系统扩展性、性能、可靠性和稳定性。有利于解决海量小文件元数据难点问题。 缺点 数据一致问题更加复杂,文件目录遍历操作效率低下,缺乏全局监控管理功能。 导致客户端承担了更多的职能,比如文件定位、名字空间缓存、逻辑卷视图维护等等,这些都增加了客户端的负载,占用相当的CPU和内存。 Haibo Li/CC/IHEP 2018/11/15 - 40
用户空间 vs 内核空间 用户空间实现起来相对要简单许多,对开发者技能要求较低,运行相对安全。 用户空间效率低,数据需要多次与内核空间交换,另外GlusterFS借助FUSE来实现标准文件系统接口,性能上又有所损耗。 内核空间实现可以获得很高的数据吞吐量,缺点是实现和调试非常困难,程序出错经常会导致系统崩溃,安全性低。 纵向扩展上,内核空间要优于用户空间,GlusterFS有横向扩展能力来弥补。 Haibo Li/CC/IHEP 2018/11/15 - 41
堆栈式 vs 非堆栈式 GlusterFS堆栈式设计思想源自GNU/Hurd微内核操作系统,具有很强的系统扩展能力,系统设计实现复杂性降低很多,基本功能模块的堆栈式组合就可以实现强大的功能。 非堆栈式设计可看成类似Linux的单一内核设计,系统调用通过中断实现,非常高效。系统核心臃肿,实现和扩展复杂,出现问题调试困难。 Haibo Li/CC/IHEP 2018/11/15 - 42
原始存储格式 vs 私有存储格式 GlusterFS使用原始格式存储文件或数据分片,可以直接使用各种标准的工具进行访问,数据互操作性好,迁移和数据管理非常方便。 数据是以平凡的方式保存的,接触数据的人可以直接复制和查看,存在数据安全问题。 GlusterFS要实现自己的私有格式,在设计实现和数据管理上相对复杂一些,也会对性能产生一定影响。 Haibo Li/CC/IHEP 2018/11/15 - 43
大文件 vs 小文件 GlusterFS适合存储大文件,小文件性能较差,还存在很大优化空间。 弹性哈希算法和Stripe数据分布策略,移除了元数据依赖,优化了数据分布,提高数据访问并行性,能够大幅提高大文件存储性能。 对于小文件,无元数据服务设计解决了元数据的问题。但GlusterFS并没有在I/O方面作优化,在存储服务器底层文件系统上仍然是大量小文件,本地文件系统元数据访问是一个瓶颈,数据分布和并行性也无法充分发挥作用。 Haibo Li/CC/IHEP 2018/11/15 - 44
可用性 vs 存储利用率 可用性与存储利用率是一个矛盾体,可用性高存储利用率就低,反之亦然。 采用复制技术,存储利用率为1/复制数,镜像是50%,三路复制则只有33%。 RAID5的利用率是(n-1)/n,RAID6是(n-2)/n,而纠删码技术可以提供更高的存储利用率。 鱼和熊掌不可得兼,会对性能产生较大影响。 Haibo Li/CC/IHEP 2018/11/15 - 45
参考资源 http://www.gluster.org/community/documentation/index.php https://github.com/anoopcs9/glusterfs 刘爱贵的GlusterFS专栏:http://blog.csdn.net/liuaigui Haibo Li/CC/IHEP 2018/11/15 - 46