GFS分布式 文件系统

2024-04-09 06:44
文章标签 分布式 文件系统 gfs

本文主要是介绍GFS分布式 文件系统,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

一、GFS的概念

        文件存储分为nfs、lvm、raid

        对象存储分为GFS、CEPH、fastDFS(分布式文件存储)NAS OSS  S3  switch

OSS   属于阿里云  通过URL 链接        S3属于亚马逊通过URL链接

1.1 GFS简介

        开源的分布式文件系统,由存储服务器、客户端以及NFS/Samba存储网关组成,无原数据服务器

        具有扩展性和高性能,高可用性有(冗余、容灾),全局统一命名空间,弹性卷管理,基于标准协议,通过多和互联网的存储节点进行冗余,以确保数据的可用性和一致性

1.2 GFS的组成

① 存储服务器

② 客户端NFS/Samba存储网关 组成

③ 五元数据服务器:保存数据的地方

二、GFS特点

2.1扩展性和高可用性

        允许通过简单地增加存储节点的方式来提高存储容量和性能(磁盘、计算和I/O资源都可以独立增加)。改善了单点故障和性能瓶颈,真正实现了并行化数据访问GlusterFS采用弹性哈希算法在存储池中可以智能地定位任意数据分片(将数据分片存储在不同节点上),不需要查看索引或者向元数据服务器查询。

  GFS可以对文件进行自动复制,如镜像或多次复制,从而确保数据总是可以访问,甚至是在硬件故障的情况下也能正常访问当数据出现不一致时,自我修复功能能够把数据恢复到正确的状态,数据的修复是以增量的方式在后台执行,几乎不会产生性能负载。G可以支持所有的存储,因为它没有设计自己的私有数据文件格式,而是采用操作系统中主流标准的磁盘文件系统(如EXT3、XFS等)来存储文件,因此数据可以使用传统访问磁盘的方式被访问。

2.2 全局统一命名空间

        分布式存储中,将所有节点的命名空间整合为统一命名空间,将整个系统的所有节点的存储容量组成一个大的虛拟存储池,供前端主机访问这些节点完成数据读写操作。

2.3 弹性卷管理

        逻辑存储池可以在线进行增加和移除,不会导致业务中断。逻辑卷可以根据需求在线增长和缩减,并可以在多个节点中实现负载均衡。
        文件系统配置也可以实时在线进行更改并应用,从而可以适应工作负载条件变化或在线性能调优。

2.4 基于一个标准协议

        存储服务支持NFS、CIFS、HTTP、FTP、SMB 及Gluster原生协议,完全与POSIX标准(可移植操作系统接口)兼容。

        现有应用程序不需要做任何修改就可以对Gluster中的数据进行访问,也可以使用专用API进行访问。

三、GFS专业术语

        Brick(块存储服务器)实际存储用户数据的服务器
        Volume(逻辑卷)本地文件系统的"分区"
        FUSE用户空间的文件系统(类别EXT4),”这是一个伪文件系统“,用户端的交换模块
        VFS(虚拟端口)内核态的虚拟文件系统,用户是提交请求给VFS 然后VFS交给FUSH,再交给GFS客户端,最后由客户端交给远端的存储
        Glusterd(服务)是运行再存储节点的进程(客户端运行的是gluster client)GFS使用过程中整个GFS之间的交换由Gluster client 和glusterd完成。

        使用GFS会使用到以上的虚拟文件系统

四、GFS工作原理

GlusterFS 的工作流程:

(1)客户端或应用程序通过 GlusterFS 的挂载点访问数据。
(2)linux系统内核通过 VFS API 收到请求并处理。
(3)VFS 将数据交给 FUSE 内核文件系统,而 FUSE 文件系统则是将数据通过 /dev/fuse 设备文件递交给了 GlusterFS client 端。可以将 FUSE 文件系统理解为一个代理。
(4)GlusterFS client 收到数据后,根据配置文件的配置对数据进行处理。
(5)经过 GlusterFS client 处理后,通过网络将数据传递至远端的 GlusterFS Server,并且将数据写入到服务器存储设备上。

1.外来一个请求,例:用户端申请创建一个文件,客户端或应用程序通过GFS的挂载点访问数据
2.linux系统内容通过VFSAPI收到请求并处理
3.VFS将数据递交给FUSE内核文件系统,fuse文件系统则是将数据通过/dev/fuse设备文件递交给了GlusterFS client端
4.GlusterFS client端收到数据后,会根据配置文件的配置对数据进行处理
5.再通过网络,将数据发送给远端的ClusterFS server,并将数据写入到服务器储存设备上
6.server再将数据转交给VFS伪文件系统,再由VFS进行转存处理,最后交给EXT3

五、GFS卷的类型 (七个卷)

5.1 分布式卷(Distribute volume)

        文件通过HASH算法分布到所有Brick Server上,这种卷是GlusterFS的默认卷;以文件为单位根据HASH算法散列到不同的Brick,其实只是扩大了磁盘空间,如果有一块磁盘损坏,数据也将丢失,属于文件级的RAID0,不具有容错能力。
        在该模式下,并没有对文件进行分块处理,文件直接存储在某个Server节点上。
由于直接使用本地文件系统进行文件存储,所以存取效率并没有提高,反而会因为网络通信的原因而有所降低。


分布式卷具有如下特点:

        1.文件分布在不同的服务器,不具备冗余性。
        2.更容易和廉价地扩展卷的大小。
        3.单点故障会造成数据丢失。
        4.依赖底层的数据保护。


6.2 条带卷(Stripe volume)

        类似RAID0,文件被分成数据块并以轮询的方式分布到多个Brick Server上,文件存储以数据块为单位,支持大文件存储,文件越大,读取效率越高,但是不具备冗余性。

条带卷特点:

        数据被分割成更小块分布到块服务器群中的不同条带区。
        分布减少了负载且更小的文件加速了存取的速度。
        没有数据冗余。


6.3 复制卷(Replica volume)

        将文件同步到多个Brick上,使其具备多个文件副本,属于文件级RAID 1,具有容错能力。因为数据分散在多个Brick中,所以读性能得到很大提升,但写性能下降。
        复制卷具备冗余性,即使一个节点损坏,也不影响数据的正常使用。但因为要保存副本,所以磁盘利用率较低。

复制卷特点:
        1.卷中所有的服务器均保存一个完整的副本。
        2.卷的副本数量可由客户创建的时候决定,但复制数必须等于卷中Brick所包含的存储服务器数。
        3.至少由两个块服务器或更多服务器。
        4.具备冗余性。

6.4 分布式条带卷(Distribute Stripe volume)

        BrickServer数量是条带数(数据块分布的Brick数量)的倍数,兼具分布式卷和条带卷的特点。
主要用于大文件访问处理,创建一个分布式条带卷最少需要4台服务器。
创建一个名为dis-stripe的分布式条带卷,配置分布式的条带卷时,卷中Brick所包含的存储服务器数必须是条带数的倍数(>=2倍)。Brick的数量是4 (Server1:/dir1、Server2:/dir2、Server3:/dir3和Server4:/dir4),条带数为2(stripe 2)
        创建卷时,存储服务器的数量如果等于条带或复制数,那么创建的是条带卷或者复制卷:如果存储服务器的数量是条带或复制数的2倍甚至更多,那么将创建的是分布式条带卷或分布式复制卷。

6.5 分布式复制卷(Distribute Replica volume)

        Brick Server数量是镜像数(数据副本数量)的倍数,兼具分布式卷和复制卷的特点。主要用于需要冗余的情况下。
        创建一个名为dis-rep的分布式复制卷,配置分布式的复制卷时,卷中Brick所包含的存储服务器数必须是复制数的倍数(>=2倍)。Brick的数量是4 (Server1:/dir1、Server2:/dir2、Server3:/dir3 和Server4:/dir4),复制数为2(replica 2)

6.6 条带复制卷(Stripe Replca volume)

        类似RAID10,同时具有条带卷和复制卷的特点。

6.7 分布式条带复制卷(Distribute Stripe Replicavolume)

三种基本卷的复合卷,通常用于类Map Reduce应用。

六、GFS部署

这篇关于GFS分布式 文件系统的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/887443

相关文章

Python FastAPI+Celery+RabbitMQ实现分布式图片水印处理系统

《PythonFastAPI+Celery+RabbitMQ实现分布式图片水印处理系统》这篇文章主要为大家详细介绍了PythonFastAPI如何结合Celery以及RabbitMQ实现简单的分布式... 实现思路FastAPI 服务器Celery 任务队列RabbitMQ 作为消息代理定时任务处理完整

redis+lua实现分布式限流的示例

《redis+lua实现分布式限流的示例》本文主要介绍了redis+lua实现分布式限流的示例,可以实现复杂的限流逻辑,如滑动窗口限流,并且避免了多步操作导致的并发问题,具有一定的参考价值,感兴趣的可... 目录为什么使用Redis+Lua实现分布式限流使用ZSET也可以实现限流,为什么选择lua的方式实现

Linux中的缓冲区和文件系统详解

《Linux中的缓冲区和文件系统详解》:本文主要介绍Linux中的缓冲区和文件系统方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、FILE结构1、fd2、缓冲区二、文件系统1、固态硬盘2、逻辑地址LBA(一)数据块 Data blocks(二)inode表

Seata之分布式事务问题及解决方案

《Seata之分布式事务问题及解决方案》:本文主要介绍Seata之分布式事务问题及解决方案,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录Seata–分布式事务解决方案简介同类产品对比环境搭建1.微服务2.SQL3.seata-server4.微服务配置事务模式1

java如何分布式锁实现和选型

《java如何分布式锁实现和选型》文章介绍了分布式锁的重要性以及在分布式系统中常见的问题和需求,它详细阐述了如何使用分布式锁来确保数据的一致性和系统的高可用性,文章还提供了基于数据库、Redis和Zo... 目录引言:分布式锁的重要性与分布式系统中的常见问题和需求分布式锁的重要性分布式系统中常见的问题和需求

Golang使用minio替代文件系统的实战教程

《Golang使用minio替代文件系统的实战教程》本文讨论项目开发中直接文件系统的限制或不足,接着介绍Minio对象存储的优势,同时给出Golang的实际示例代码,包括初始化客户端、读取minio对... 目录文件系统 vs Minio文件系统不足:对象存储:miniogolang连接Minio配置Min

Golang使用etcd构建分布式锁的示例分享

《Golang使用etcd构建分布式锁的示例分享》在本教程中,我们将学习如何使用Go和etcd构建分布式锁系统,分布式锁系统对于管理对分布式系统中共享资源的并发访问至关重要,它有助于维护一致性,防止竞... 目录引言环境准备新建Go项目实现加锁和解锁功能测试分布式锁重构实现失败重试总结引言我们将使用Go作

Redis分布式锁使用及说明

《Redis分布式锁使用及说明》本文总结了Redis和Zookeeper在高可用性和高一致性场景下的应用,并详细介绍了Redis的分布式锁实现方式,包括使用Lua脚本和续期机制,最后,提到了RedLo... 目录Redis分布式锁加锁方式怎么会解错锁?举个小案例吧解锁方式续期总结Redis分布式锁如果追求

集中式版本控制与分布式版本控制——Git 学习笔记01

什么是版本控制 如果你用 Microsoft Word 写过东西,那你八成会有这样的经历: 想删除一段文字,又怕将来这段文字有用,怎么办呢?有一个办法,先把当前文件“另存为”一个文件,然后继续改,改到某个程度,再“另存为”一个文件。就这样改着、存着……最后你的 Word 文档变成了这样: 过了几天,你想找回被删除的文字,但是已经记不清保存在哪个文件了,只能挨个去找。真麻烦,眼睛都花了。看

开源分布式数据库中间件

转自:https://www.csdn.net/article/2015-07-16/2825228 MyCat:开源分布式数据库中间件 为什么需要MyCat? 虽然云计算时代,传统数据库存在着先天性的弊端,但是NoSQL数据库又无法将其替代。如果传统数据易于扩展,可切分,就可以避免单机(单库)的性能缺陷。 MyCat的目标就是:低成本地将现有的单机数据库和应用平滑迁移到“云”端