分布式存储_分布式存储系统 - CSDN
分布式存储 订阅
分布式存储是一种数据存储技术,通过网络使用企业中的每台机器上的磁盘空间,并将这些分散的存储资源构成一个虚拟的存储设备,数据分散的存储在企业的各个角落。 展开全文
分布式存储是一种数据存储技术,通过网络使用企业中的每台机器上的磁盘空间,并将这些分散的存储资源构成一个虚拟的存储设备,数据分散的存储在企业的各个角落。
信息
途    径
网络
外文名
Distributed storage
含    义
一种数据存储技术
中文名
分布式存储
分布式存储分布式存储系统
分布式存储系统,是将数据分散存储在多台独立的设备上。传统的网络存储系统采用集中的存储服务器存放所有数据,存储服务器成为系统性能的瓶颈,也是可靠性和安全性的焦点,不能满足大规模存储应用的需要。分布式网络存储系统采用可扩展的系统结构,利用多台存储服务器分担存储负荷,利用位置服务器定位存储信息,它不但提高了系统的可靠性、可用性和存取效率,还易于扩展。 [1] 
收起全文
精华内容
参与话题
  • 什么是分布式存储

    千次阅读 2018-09-30 11:14:02
    传统定义:分布式存储系统是大量 PC 服务器通过 Internet 互联,对外提供一个整体的服务。 分布式存储系统具有以下的几个特性: 可扩展 :分布式存储系统可以扩展到几百台甚至几千台这样的一个集群规模,系统的 ...

    传统定义:分布式存储系统是大量 PC 服务器通过 Internet 互联,对外提供一个整体的服务。

    分布式存储系统具有以下的几个特性:

    可扩展 :分布式存储系统可以扩展到几百台甚至几千台这样的一个集群规模,系统的 整体性能线性增长。

    低成本 :分布式存储系统的自动容错、自动负载均衡的特性,允许分布式存储系统可 以构建在低成本的服务器上。另外,线性的扩展能力也使得增加、减少服务器的成本低, 实现分布式存储系统的自动运维。

    高性能 :无论是针对单台服务器,还是针对整个分布式的存储集群,都要求分布式存 储系统具备高性能。

    易用 :分布式存储系统需要对外提供方便易用的接口,另外,也需要具备完善的监 控、运维工具,并且可以方便的与其他的系统进行集成。

     

    布式存储系统的挑战主要在于数据和状态信息的持久化,要求在自动迁移、自动容 错和并发读写的过程中,保证数据的一致性。

     

    容错:如何可以快速检测到服务器故障,并自动的将在故障服务器上的数据进行迁移

    负载均衡:新增的服务器如何在集群中保障负载均衡?数据迁移过程中如何保障不影 响现有的服务。

    事务与并发控制:如何实现分布式事务。

    易用性:如何设计对外接口,使得设计的系统易于使用。

     

     

    展开全文
  • 常见开源分布式存储系统

    万次阅读 2017-04-20 19:49:20
    系统整体对比 对比说明 /文件系统 TFS FastDFS MogileFS MooseFS GlusterFS Ceph 开发语言 C++ C Perl C C ...GPL

    系统整体对比

    对比说明

    /文件系统

    TFS

    FastDFS

    MogileFS

    MooseFS

    GlusterFS

    Ceph

    开发语言

    C++

    C

    Perl

    C

    C

    C++

    开源协议

    GPL V2

    GPL V3

    GPL

    GPL V3

    GPL V3

    LGPL

    数据存储方式

    文件/Trunk

    文件

    文件/

    对象/文件/块

    集群节点通信协议

    私有协议(TCP

    私有协议(TCP

    HTTP

    私有协议(TCP

    私有协议(TCP)/ RDAM(远程直接访问内存)

    私有协议(TCP

    专用元数据存储点

    占用NS

    占用DB

    占用MFS

    占用MDS

    在线扩容

    支持

    支持

    支持

    支持

    支持

    支持

    冗余备份

    支持

    支持

    -

    支持

    支持

    支持

    单点故障

    存在

    不存在

    存在

    存在

    不存在

    存在

    跨集群同步

    支持

    部分支持

    -

    -

    支持

    不适用

    易用性

    安装复杂,官方文档少

    安装简单,社区相对活跃

    -

    安装简单,官方文档多

    安装简单,官方文档专业化

    安装简单,官方文档专业化

    适用场景

    跨集群的小文件

    单集群的中小文件

    -

    单集群的大中文件

    跨集群云存储

    单集群的大中小文件

    开源协议说明

    GPL:不允许修改后和衍生的代码做为闭源的商业软件发布和销售,修改后该软件产品必须也采用GPL协议;

    GPLV2:修改文本的整体就必须按照GPL流通,不仅该修改文本的源码必须向社 会公开,而且对于这种修改文本的流通不准许附加修改者自己作出的限制;

    GPLV3:要求用户公布修改的源代码,还要求公布相关硬件;LGPL:更宽松的GPL

    TFS

    TFS(Taobao File System)是由淘宝开发的一个分布式文件系统,其内部经过特殊的优化处理,适用于海量的小文件存储,目前已经对外开源;

    TFS采用自有的文件系统格式存储,因此需要专用的API接口去访问,目前官方提供的客户端版本有:C++/JAVA/PHP


    § 特性

    1)在TFS文件系统中,NameServer负责管理文件元数据,通过HA机制实现主备热切换,由于所有元数据都是在内存中,其处理效率非常高效,系统架构也非常简单,管理也很方便;

    2)TFS的DataServer作为分部署数据存储节点,同时也具备负载均衡和冗余备份的功能,由于采用自有的文件系统,对小文件会采取合并策略,减少数据碎片,从而提升IO性能;

    3)TFS将元数据信息(BlockID、FileID)直接映射至文件名中,这一设计大大降低了存储元数据的内存空间;

    § 优点

    1)针对小文件量身定做,随机IO性能比较高;

    2)支持在线扩容机制,增强系统的可扩展性;

    3)实现了软RAID,增强系统的并发处理能力及数据容错恢复能力;

    4)支持主备热倒换,提升系统的可用性;

    5)支持主从集群部署,其中从集群主要提供读/备功能;

    § 缺点

    1)TFS只对小文件做优化,不适合大文件的存储;

    2)不支持POSIX通用接口访问,通用性较低;

    3)不支持自定义目录结构,及文件权限控制;

    4)通过API下载,存在单点的性能瓶颈;

    5)官方文档非常少,学习成本高;

    § 应用场景

    1)多集群部署的应用

    2)存储后基本不做改动

    3)海量小型文件

    根据目前官方提供的材料,对单个集群节点,存储节点在1000台以内可以良好工作,如存储节点扩大可能会出现NameServer的性能瓶颈,目前淘宝线上部署容量已达到1800TB规模(2009年数据)

    § 安装及使用

    ·   安装指导

    ·   TFS_配置使用

     

     源代码路径http://code.taobao.org/p/tfs/src/

     

     参考

     http://rdc.taobao.com/blog/cs/?p=128

     http://elf8848.iteye.com/blog/1724423

     http://baike.baidu.com/view/1030880.htm

     http://blog.yunnotes.net/index.php/install_document_for_tfs/

     

    FastDFS

    FastDFS是国人开发的一款分布式文件系统,目前社区比较活跃。如上图所示系统中存在三种节点:Client、Tracker、Storage,在底层存储上通过逻辑的分组概念,使得通过在同组内配置多个Storage,从而实现软RAID10,提升并发IO的性能、简单负载均衡及数据的冗余备份;同时通过线性的添加新的逻辑存储组,从容实现存储容量的线性扩容。

    文件下载上,除了支持通过API方式,目前还提供了apache和nginx的插件支持,同时也可以不使用对应的插件,直接以Web静态资源方式对外提供下载。

    目前FastDFS(V4.x)代码量大概6w多行,内部的网络模型使用比较成熟的libevent三方库,具备高并发的处理能力。

    §特性

    1)在上述介绍中Tracker服务器是整个系统的核心枢纽,其完成了访问调度(负载均衡),监控管理Storage服务器,由此可见Tracker的作用至关重要,也就增加了系统的单点故障,为此FastDFS支持多个备用的Tracker,虽然实际测试发现备用Tracker运行不是非常完美,但还是能保证系统可用。

    2)在文件同步上,只有同组的Storage才做同步,由文件所在的源Storage服务器push至其它Storage服务器,目前同步是采用Binlog方式实现,由于目前底层对同步后的文件不做正确性校验,因此这种同步方式仅适用单个集群点的局部内部网络,如果在公网上使用,肯定会出现损坏文件的情况,需要自行添加文件校验机制。

    3)支持主从文件,非常适合存在关联关系的图片,在存储方式上,FastDFS在主从文件ID上做取巧,完成了关联关系的存储。

    §优点

    1)系统无需支持POSIX(可移植操作系统),降低了系统的复杂度,处理效率更高

    2)支持在线扩容机制,增强系统的可扩展性

    3)实现了软RAID,增强系统的并发处理能力及数据容错恢复能力

    4)支持主从文件,支持自定义扩展名

    5)主备Tracker服务,增强系统的可用性

    §缺点

    1)不支持断点续传,对大文件将是噩梦(FastDFS不适合大文件存储)

    2)不支持POSIX通用接口访问,通用性较低

    3)对跨公网的文件同步,存在较大延迟,需要应用做相应的容错策略

    4)同步机制不支持文件正确性校验,降低了系统的可用性

    5)通过API下载,存在单点的性能瓶颈

    §应用场景

    1)单集群部署的应用

    2)存储后基本不做改动

    3)小中型文件根据

    目前官方提供的材料,现有的使用FastDFS系统存储容量已经达到900T,物理机器已经达到100台(50个组)


     安装指导_FastDFS

     

     源码路径:https://github.com/happyfish100/fastdfs

    §参考

     https://code.google.com/p/fastdfs/ 

     http://bbs.chinaunix.net/forum-240-1.html

     http://portal.ucweb.local/docz/spec/platform/datastore/fastdfs

     

    MooseFS

    MooseFS是一个高可用的故障容错分布式文件系统,它支持通过FUSE方式将文件挂载操作,同时其提供的web管理界面非常方便查看当前的文件存储状态。

    §特性

    1)从下图中我们可以看到MooseFS文件系统由四部分组成:Managing Server 、Data Server 、Metadata Backup Server 及Client

    2)其中所有的元数据都是由Managing Server管理,为了提高整个系统的可用性,MetadataBackup Server记录文件元数据操作日志,用于数据的及时恢复

    3)Data Server可以分布式部署,存储的数据是以块的方式分布至各存储节点的,因此提升了系统的整体性能,同时Data Server提供了冗余备份的能力,提升系统的可靠性

    4)Client通过FUSE方式挂载,提供了类似POSIX的访问方式,从而降低了Client端的开发难度,增强系统的通用性


    §元数据服务器(master):负责各个数据存储服务器的管理,文件读写调度,文件空间回收以及恢复

    §元数据日志服务器(metalogger):负责备份master服务器的变化日志文件,以便于在master server出问题的时候接替其进行工作

    §数据存储服务器(chunkserver):数据实际存储的地方,由多个物理服务器组成,负责连接管理服务器,听从管理服务器调度,提供存储空间,并为客户提供数据传输;多节点拷贝;在数据存储目录,看不见实际的数据


    §优点

    1)部署安装非常简单,管理方便

    2)支持在线扩容机制,增强系统的可扩展性

    3)实现了软RAID,增强系统的 并发处理能力及数据容错恢复能力

    4)数据恢复比较容易,增强系统的可用性5)有回收站功能,方便业务定制

    §缺点

    1)存在单点性能瓶颈及单点故障

    2)MFS Master节点很消耗内存

    3)对于小于64KB的文件,存储利用率较低

    §应用场景

    1)单集群部署的应用

    2)中、大型文件

    §参考

     http://portal.ucweb.local/docz/spec/platform/datastore/moosefsh 

     http://www.moosefs.org/ 

     http://sourceforge.net/projects/moosefs/?source=directory

     

    GlusterFS

    GlusterFS是Red Hat旗下的一款开源分布式文件系统,它具备高扩展、高可用及高性能等特性,由于其无元数据服务器的设计,使其真正实现了线性的扩展能力,使存储总容量可轻松达到PB级别,支持数千客户端并发访问;对跨集群,其强大的Geo-Replication可以实现集群间数据镜像,而且是支持链式复制,这非常适用于垮集群的应用场景

    §特性

    1)目前GlusterFS支持FUSE方式挂载,可以通过标准的NFS/SMB/CIFS协议像访问本体文件一样访问文件系统,同时其也支持HTTP/FTP/GlusterFS访问,同时最新版本支持接入Amazon的AWS系统

    2)GlusterFS系统通过基于SSH的命令行管理界面,可以远程添加、删除存储节点,也可以监控当前存储节点的使用状态

    3)GlusterFS支持集群节点中存储虚拟卷的扩容动态扩容;同时在分布式冗余模式下,具备自愈管理功能,在Geo冗余模式下,文件支持断点续传、异步传输及增量传送等特点

     

    §优点

    1)系统支持POSIX(可移植操作系统),支持FUSE挂载通过多种协议访问,通用性比较高

    2)支持在线扩容机制,增强系统的可扩展性

    3)实现了软RAID,增强系统的 并发处理能力及数据容错恢复能力

    4)强大的命令行管理,降低学习、部署成本

    5)支持整个集群镜像拷贝,方便根据业务压力,增加集群节点

    6)官方资料文档专业化,该文件系统由Red Hat企业级做维护,版本质量有保障

    §缺点

    1)通用性越强,其跨越的层次就越多,影响其IO处理效率

    2)频繁读写下,会产生垃圾文件,占用磁盘空间

    §应用场景

    1)多集群部署的应用

    2)中大型文件根据目前官方提供的材料,现有的使用GlusterFS系统存储容量可轻松达到PB

    §术语:

    brick:分配到卷上的文件系统块;

    client:挂载卷,并对外提供服务;

    server:实际文件存储的地方;

    subvolume:被转换过的文件系统块;

    volume:最终转换后的文件系统卷。

    §参考

      http://www.gluster.org/

      http://www.gluster.org/wp-content/uploads/2012/05/Gluster_File_System-3.3.0-Administration_Guide-en-US.pdf

      http://blog.csdn.net/liuben/article/details/6284551

     

    Ceph

    Ceph是一个可以按对象/块/文件方式存储的开源分布式文件系统,其设计之初,就将单点故障作为首先要解决的问题,因此该系统具备高可用性、高性能及可扩展等特点。该文件系统支持目前还处于试验阶段的高性能文件系统BTRFS(B-Tree文件系统),同时支持按OSD方式存储,因此其性能是很卓越的, 因为该系统处于试商用阶段,需谨慎引入到生产环境

    §特性

    1)Ceph底层存储是基于RADOS(可靠的、自动的分布式对象存储),它提供了LIBRADOS/RADOSGW/RBD/CEPHFS方式访问底层的存储系统,如下图所示

    2)通过FUSE,Ceph支持类似的POSIX访问方式;Ceph分布式系统中最关键的MDS节点是可以部署多台,无单点故障的问题,且处理性能大大提升

    3)Ceph通过使用CRUSH算法动态完成文件inode number到object number的转换,从而避免再存储文件metadata信息,增强系统的灵活性

    §优点

    1)支持对象存储(OSD)集群,通过CRUSH算法,完成文件动态定位, 处理效率更高

    2)支持通过FUSE方式挂载,降低客户端的开发成本,通用性高

    3)支持分布式的MDS/MON,无单点故障

    4)强大的容错处理和自愈能力5)支持在线扩容和冗余备份,增强系统的可靠性

    §缺点

    1)目前处于试验阶段,系统稳定性有待考究

    §应用场景

    1)全网分布式部署的应用

    2)对实时性、可靠性要求比较高官方宣传,存储容量可轻松达到PB级别

     

     源码路径:https://github.com/ceph/ceph

     

    §参考

      http://ceph.com/

     

    MogileFS

    §开发语言:perl

    §开源协议:GPL

    §依赖数据库

    §Trackers(控制中心):负责读写数据库,作为代理复制storage间同步的数据

    §Database:存储源数据(默认mysql

    §Storage:文件存储

    §除了API,可以通过与nginx集成,对外提供下载服务

     

     源码路径:https://github.com/mogilefs

     

    §参考

     https://code.google.com/p/mogilefs/wiki/Start?tm=6

     

     其它参考

     http://blog.csdn.net/qiangweiloveforever/ariticle/details/7566779

     http://weiruoyu.blog.51cto.com/951650/786607 

     http://m.blog.csdn.net/blog/junefsh/18079733

     

    展开全文
  • 各类分布式存储系统简介

    万次阅读 2017-10-23 15:49:51
    本地文件系统如ext3,reiserfs等(这里不讨论基于内存的文件系统),它们管理本地的磁盘存储资源、提供文件到存储位置的映射,并抽象出一套文件访问接口供用户使用。但随着互联网企业的高速发展,这些企业对数据存储...

    分布式文件系统原理

    本地文件系统如ext3,reiserfs等(这里不讨论基于内存的文件系统),它们管理本地的磁盘存储资源、提供文件到存储位置的映射,并抽象出一套文件访问接口供用户使用。但随着互联网企业的高速发展,这些企业对数据存储的要求越来越高,而且模式各异,如淘宝主站的大量商品图片,其特点是文件较小,但数量巨大;而类似于youtube,优酷这样的视频服务网站,其后台存储着大量的视频文件,尺寸大多在数十兆到数吉字节不等。这些应用场景都是传统文件系统不能解决的。分布式文件系统将数据存储在物理上分散的多个存储节点上,对这些节点的资源进行统一的管理与分配,并向用户提供文件系统访问接口,其主要解决了本地文件系统在文件大小、文件数量、打开文件数等的限制问题。


    分布式存储系统典型架构

    目前比较主流的一种分布式文件系统架构,如下图所示,通常包括主控服务器(或称元数据服务器、名字服务器等,通常会配置备用主控服务器以便在故障时接管服务,也可以两个都为主的模式),多个数据服务器(或称存储服务器,存储节点等),以及多个客户端,客户端可以是各种应用服务器,也可以是终端用户。

    分布式文件系统的数据存储解决方案,归根结底是将将大问题划分为小问题。大量的文件,均匀分布到多个数据服务器上后,每个数据服务器存储的文件数量就少了,另外通过使用大文件存储多个小文件的方式,总能把单个数据服务器上存储的文件数降到单机能解决的规模;对于很大的文件,将大文件划分成多个相对较小的片段,存储在多个数据服务器上(目前,很多本地文件系统对超大文件的支持已经不存在问题了,如ext3文件系统使用4k块时,文件最大能到4T,ext4则能支持更大的文件,只是受限于磁盘的存储空间)。

     

    理论上,分布式文件系统可以只有客户端和多个数据服务器组成,客户端根据文件名决定将文件存储到哪个数据服务器,但一旦有数据服务器失效时,问题就变得复杂,客户端并不知道数据服务器宕机的消息,仍然连接它进行数据存取,导致整个系统的可靠性极大的降低,而且完全有客户端决定数据分配时非常不灵活的,其不能根据文件特性制定不同的分布策略。

     

    于是,我们迫切的需要能知道各个数据服务器的服务状态,数据服务器的状态管理可分为分散式和集中式两种方式,前者是让多个数据服务器相互管理,如每个服务器向其他所有的服务器发送心跳信息,但这种方式开销较大,控制不好容易影响到正常的数据服务,而且工程实现较为复杂;后者是指通过一个独立的服务器(如上图中的主控服务器)来管理数据服务器,每个服务器向其汇报服务状态来达到集中管理的目的,这种方式简单易实现,目前很多分布式文件系统都采用这种方式如GFS、TFS(http://code.taobao.org/p/tfs/wiki/index/ )、MooseFS (http://www.moosefs.org/ )等。主控服务器在负载较大时会出现单点,较多的解决方案是配置备用服务器,以便在故障时接管服务,如果需要,主备之间需要进行数据的同步。


    问题及解决方法

    本文主要讨论基于上图架构的分布式文件系统的相关原理,工程实现时需要解决的问题和解决问题的基本方法,分布式文件系统涉及的主要问题及解决方法如下图所示。为方便描述以下主控服务器简称Master,数据服务器简称DS(DataServer)。

    主控服务器

    l 命名空间的维护

    Master负责维护整个文件系统的命名空间,并暴露给用户使用,命名空间的结构主要有典型目录树结构如MooseFS等,扁平化结构如淘宝TFS(目前已提供目录树结构支持),图结构(主要面向终端用户,方便用户根据文件关联性组织文件,只在论文中看到过)。

    为了维护名字空间,需要存储一些辅助的元数据如文件(块)到数据服务器的映射关系,文件之间的关系等,为了提升效率,很多文件系统采取将元数据全部内存化(元数据通常较小)的方式如GFS, TFS;有些系统借则助数据库来存储元数据如DBFS,还有些系统则采用本地文件来存储元数据如MooseFS。

     

    一种简单的实现目录树结构的方式是,在Master上存储与客户端完全一样的命名空间,对应的文件内容为该文件的元数据,并通过在Master上采用ReiserFS来进行小文件存储优化,对于大文件的存储(文件数量不会成为Master的瓶颈),这种方式简单易实现。曾经参与的DNFS系统的开发就是使用这种方式,DNFS主要用于存储视频文件,视频数量在百万级别,Master采用这种方式文件数量上不会成为瓶颈。

    l 数据服务器管理

    除了维护文件系统的命名空间,Master还需要集中管理数据DS, 可通过轮询DS或由DS报告心跳的方式实现。在接收到客户端写请求时,Master需要根据各个DS的负载等信息选择一组(根据系统配置的副本数)DS为其服务;当Master发现有DS宕机时,需要对一些副本数不足的文件(块)执行复制计划;当有新的DS加入集群或是某个DS上负载过高,Master也可根据需要执行一些副本迁移计划。

     

    如果Master的元数据存储是非持久化的,则在DS启动时还需要把自己的文件(块)信息汇报给Master。在分配DS时,基本的分配方法有随机选取,RR轮转、低负载优先等,还可以将服务器的部署作为参考(如HDFS分配的策略),也可以根据客户端的信息,将分配的DS按照与客户端的远近排序,使得客户端优先选取离自己近的DS进行数据存取.

    l 服务调度

    Master最终的目的还是要服务好客户端的请求,除了一些周期性线程任务外,Master需要服务来自客户端和DS的请求,通常的服务模型包括单线程、每请求一线程、线程池(通常配合任务队列)。单线程模型下,Master只能顺序的服务请求,该方式效率低,不能充分利用好系统资源;每请求一线程的方式虽能并发的处理请求,但由于系统资源的限制,导致创建线程数存在限制,从而限制同时服务的请求数量,另外,线程太多,线程间的调度效率也是个大问题;线程池的方式目前使用较多,通常由单独的线程接受请求,并将其加入到任务队列中,而线程池中的线程则从任务队列中不断的取出任务进行处理。

    l 主备(主)容灾

    Master在整个分布式文件系统中的作用非常重要,其维护文件(块)到DS的映射、管理所有的DS状态并在某些条件触发时执行负载均衡计划等。为了避免Master的单点问题,通常会为其配置备用服务器,以保证在主控服务器节点失效时接管其工作。通常的实现方式是通过HA、UCARP等软件为主备服务器提供一个虚拟IP提供服务,当备用服务器检测到主宕机时,会接管主的资源及服务。

     

    如果Master需要持久化一些数据,则需要将数据同步到备用Master,对于元数据内存化的情况,为了加速元数据的构建,有时也需将主上的操作同步到备Master。处理方式可分为同步和异步两种。同步方式将每次请求同步转发至备Master,这样理论上主备时刻保持一致的状态,但这种方式会增加客户端的响应延迟(在客户端对响应延迟要求不高时可使用这种方式),当备Master宕机时,可采取不做任何处理,等备Master起来后再同步数据,或是暂时停止写服务,管理员介入启动备Master再正常服务(需业务能容忍);异步方式则是先暂存客户端的请求信息(如追加至操作日志),后台线程重放日志到备Master,这种方式会使得主备的数据存在不一致的情况,具体策略需针对需求制定。


    数据服务器

    l 数据本地存储

    数据服务器负责文件数据在本地的持久化存储,最简单的方式是将客户每个文件数据分配到一个单独的DS上作为一个本地文件存储,但这种方式并不能很好的利用分布式文件系统的特性,很多文件系统使用固定大小的块来存储数据如GFS, TFS, HDFS,典型的块大小为64M。

     

    对于小文件的存储,可以将多个文件的数据存储在一个块中,并为块内的文件建立索引,这样可以极大的提高存储空间利用率。Facebook用于存储照片的HayStack系统的本地存储方式为,将多个图片对象存储在一个大文件中,并为每个文件的存储位置建立索引,其支持文件的创建和删除,不支持更新(通过删除和创建完成),新创建的图片追加到大文件的末尾并更新索引,文件删除时,简单的设置文件头的删除标记,系统在空闲时会对大文件进行compact把设置删除标记且超过一定时限的文件存储空间回收(延迟删除策略)。淘宝的TFS系统采用了类似的方式,对小文件的存储进行了优化,TFS使用扩展块的方式支持文件的更新。对小文件的存储也可直接借助一些开源的KV存储解决方案,如Tokyo Cabinet(HDB, FDB, BDB, TDB)、Redis等。

     

    对于大文件的存储,则可将文件存储到多个块上,多个块所在的DS可以并行服务,这种需求通常不需要对本地存储做太多优化。

    l 状态维护

    DS除了简单的存储数据外,还需要维护一些状态,首先它需要将自己的状态以心跳包的方式周期性的报告给Master,使得Master知道自己是否正常工作,通常心跳包中还会包含DS当前的负载状况(CPU、内存、磁盘IO、磁盘存储空间、网络IO等、进程资源,视具体需求而定),这些信息可以帮助Master更好的制定负载均衡策略。

     

    很多分布式文件系统如HDFS在外围提供一套监控系统,可以实时的获取DS或Master的负载状况,管理员可根据监控信息进行故障预防。

    l 副本管理

    为了保证数据的安全性,分布式文件系统中的文件会存储多个副本到DS上,写多个副本的方式,主要分为3种。最简单的方式是客户端分别向多个DS写同一份数据,如DNFS采用这种方式;第2种方式是客户端向主DS写数据,主DS向其他DS转发数据,如TFS采用这种方式;第三种方式采用流水复制的方式,client向某个DS写数据,该DS向副本链中下一个DS转发数据,依次类推,如HDFS、GFS采取这种方式。

     

    当有节点宕机或节点间负载极不均匀的情况下,Master会制定一些副本复制或迁移计划,而DS实际执行这些计划,将副本转发或迁移至其他的DS。DS也可提供管理工具,在需要的情况下由管理员手动的执行一些复制或迁移计划。

    l 服务模型

    参考主控服务器::服务模型一节


    客户端

    l 接口

    用户最终通过文件系统提供的接口来存取数据,linux环境下,最好莫过于能提供POSIX接口的支持,这样很多应用(各种语言皆可,最终都是系统调用)能不加修改的将本地文件存储替换为分布式文件存储。

     

    要想文件系统支持POSIX接口,一种方式时按照VFS接口规范实现文件系统,这种方式需要文件系统开发者对内核有一定的了解;另一种方式是借助FUSE(http://fuse.sourceforge.net)软件,在用户态实现文件系统并能支持POSIX接口,但是用该软件包开发的文件系统会有额外的用户态内核态的切换、数据拷贝过程,从而导致其效率不高。很多文件系统的开发借助了fuse,参考http://sourceforge.net/apps/mediawiki/fuse/index.php?title=FileSystems

     

    如果不能支持POSIX接口,则为了支持不同语言的开发者,需要提供多种语言的客户端支持,如常用的C/C++、java、php、python客户端。使用客户端的方式较难处理的一种情况时,当客户端升级时,使用客户端接口的应用要使用新的功能,也需要进行升级,当应用较多时,升级过程非常麻烦。目前一种趋势是提供Restful接口的支持,使用http协议的方式给应用(用户)访问文件资源,这样就避免功能升级带来的问题。

     

    另外,在客户端接口的支持上,也需根据系统需求权衡,比如write接口,在分布式实现上较麻烦,很难解决数据一致性的问题,应该考虑能否只支持create(update通过delete和create组合实现),或折中支持append,以降低系统的复杂性。

    l 缓存

    分布式文件系统的文件存取,要求客户端先连接Master获取一些用于文件访问的元信息,这一过程一方面加重了Master的负担,一方面增加了客户端的请求的响应延迟。为了加速该过程,同时减小Master的负担,可将元信息进行缓存,数据可根据业务特性缓存在本地内存或磁盘,也可缓存在远端的cache系统上如淘宝的TFS可利用tair作为缓存(减小Master负担、降低客户端资源占用)。

     

    维护缓存需考虑如何解决一致性问题及缓存替换算法,一致性的维护可由客户端也可由服务器完成,一种方式是客户端周期性的使cache失效或检查cache有效性(需业务上能容忍),或由服务器在元数据更新后通知客户端使cache失效(需维护客户端状态)。使用得较多的替换算法如LRU、随机替换等。

    l 其他

    客户端还可以根据需要支持一些扩展特性,如将数据进行加密保证数据的安全性、将数据进行压缩后存储降低存储空间使用,或是在接口中封装一些访问统计行为,以支持系统对应用的行为进行监控和统计。


    总结

    本文主要从典型分布式文件系统架构出发,讨论了分布式文件系统的基本原理,工程实现时需要解决的问题、以及解决问题的基本方法,真正在系统工程实现时,要考虑的问题会更多。如有问题,欢迎拍砖。


    HDFS 架构解析

    文以 Hadoop 提供的分布式文件系统(HDFS)为例来进一步展开解析分布式存储服务架构设计的要点。

    架构目标

    任何一种软件框架或服务都是为了解决特定问题而产生的。还记得我们在 《分布式存储 - 概述》一文中描述的几个关注方面么?分布式文件系统属于分布式存储中的一种面向文件的数据模型,它需要解决单机文件系统面临的容量扩展和容错问题。

    所以 HDFS 的架构设计目标就呼之欲出了:

    1. 面向超大文件或大量的文件数据集
    2. 自动检测局部的硬件错误并快速恢复

    基于此目标,考虑应用场景出于简化设计和实现的目的,HDFS 假设了一种 write-once-read-many 的文件访问模型。这种一次写入并被大量读出的模型在现实中确实适应很多业务场景,架构设计的此类假设是合理的。正因为此类假设的存在,也限定了它的应用场景。

    架构总揽

    下面是一张来自官方文档的架构图: 
    这里写图片描述

    从图中可见 HDFS 的架构包括三个部分,每个部分有各自清晰的职责划分。

    1. NameNode
    2. DataNode
    3. Client

    从图中可见,HDFS 采用的是中心总控式架构,NameNode 就是集群的中心节点。

    NameNode

    NameNode 的主要职责是管理整个文件系统的元信息(Metadata),元信息主要包括:

    • File system namesapce 
      HDFS 类似单机文件系统以目录树的形式组织文件,称为 file system namespace
    • Replication factor 
      文件副本数,针对每个文件设置
    • Mapping of blocks to DataNodes 
      文件块到数据节点的映射关系

    在上面架构图中,指向 NameNode 的 Metadata ops 主要就是针对文件的创建、删除、读取和设置文件的副本数等操作,所以所有的文件操作都绕不过 NameNode。除此之外 NameNode 还负责管理 DataNode,如新的 DataNode 加入集群,旧的 DataNode 退出集群,在 DataNode 之间负载均衡文件数据块的分布等等。更多关于 NameNode 的设计实现分析,后面会单独成文详解。

    DataNode

    DataNode 的职责如下:

    • 存储文件块(block)
    • 服务响应 Client 的文件读写请求
    • 执行文件块的创建、删除和复制

    从架构图上看到有个 Block ops 的操作箭头从 NameNode 指向 DataNode,会让人误以为 NameNode 会主动向 DataNode 发出指令调用。实际上 NameNode 从不调用 DataNode,仅仅是通过 DataNode 定期向 NameNode 发送心跳来携带回传的指令信息。

    架构图上专门标记了 Rack1 和 Rack2,表明了 HDFS 在考虑文件数据块的多副本分布时针对机架感知作了专门设计,细节我们这里先不展开,更多关于 DataNode 的设计实现分析,后面会单独成文详解。

    Client

    考虑到 HDFS 交互过程的复杂性,所以特地提供了针特定编程语言的 Client 以简化使用。Client 的职责如下:

    • 提供面向应用编程语言的一致 API,简化应用编程
    • 改善访问性能

    Client 之所以能够改善性能是因为针对读可以提供缓存(cache),针对写可以通过缓冲(buffer)批量方式,细节我们这里也先不展开,更多关于 Client 的设计实现分析,后面会单独成文详解。

    总结

    本来想在一篇文章里写完 HDFS 架构解析的,写着写着发现不太可能。作为分布式系统中最复杂的分布式存储类系统,每一个架构设计权衡的实现细节点,都值得好好推敲,一旦展开此文感觉就会长的没完没了,所以这里先总体过一下,针对每个部分的设计实现细节再以主题文章来详细解析。

    参考

    [1]Hadoop Documentation. HDFS Architecture
    [2]Robert Chansler, Hairong Kuang, Sanjay Radia, Konstantin Shvachko, and Suresh Srinivas. The Hadoop Distributed File System


    分布式存储系统sheepdog


    Sheepdog,是由NTT的3名日本研究员开发的开源项目,主要用来为虚拟机提供块设备。

    其架构如下:

     

     

     

    下面,我们将从架构、模块等几个方面来介绍下:

     

    一、架构图

    如上图:

    采用无中心节点的全对称架构,无单点故障,存储容量和性能可线性扩展;

    新增节点通过简单配置可自动加入(IP:PORT),数据自动实现负载均衡;

    节点故障时,数据可自动恢复;

    直接支持QEMU/KVM应用;

     

    二、模块

     

    如上图:

    由corosync,完成集群成员管理和消息传递;

    由Qemu作为Sheepdog的客户端,提供NBD/iSCSI协议支持;

    由gateway实现数据的DHT路由,由storage server数据数据本地存储;

     

    三、数据具体存储方式

     

    如上图:

    以VDI Object存储VM数据,向用户暴露的是一个块设备;

    包含4种数据对象:VDI、Data Object、属性对象和用于快照的VM实时状态数据对象;

    以4M的小文件方式实现OBS,但很容易基于此扩展,如使用使用库替代4M的小文件;

     

    四、集群管理

    1. 采用corosync,tot是em协议的一个开源实现。totem协议主要用来实现集群成员管理和可靠顺序传输。

    2. corosync通过提供一个CPG API来提供服务。

    首先,绑定一个fd到cpg_handle,并注册回调函数cpg_dispatch;

    然后将fd注册到epoll;

    corosync上消息会触发fd改变,通用epoll触发回调函数cpg_dispatch;

     

    这里主要有两个函数,cpg_deliver_fn和cpg_confchg_fn,分别对应sd_deliver和sd_confchg.

     其中,sd_deliver负责集群从corosync给本地发消息,主要是针对VDI进行操作;而sd_confchg主要是对node进行操作,用来监控集群成员变化。

     

    五、存储对象管理

    集群对象版本epoch;

    obj目录下,每个新的epoch要对应创建一个新的目录;

    可从epoch恢复数据;

     

    六、一致性模型

    通过epoll机制保证;

    通过数据操作实现强一致性(多副本的写同时成功时,才向client返回); 

     

    七、DHT路由

    代理路由方式;

    由ip:port生成节点编号,做一致性哈希;

     

    八、副本放置

    一致性哈希;

    虚拟节点;

     

    如需了解更详细信息,可参考其官网:http://www.osrg.net/sheepdog/



    文章转自:

    http://blog.csdn.net/it_yuan/article/details/8980849

    http://blog.csdn.net/kidd_3/article/details/8154964

    http://blog.csdn.net/mindfloating/article/details/47842495








    展开全文
  • 开源分布式存储系统的对比

    万次阅读 2019-12-23 17:56:24
    我们在选型开源分布式存储系统框架之前需要对不同的框架进行调研。 所有的开源存储系统介绍链接 存储系统对比 目前比较热门的分布式文件系统有如下几种: Ceph,GlusterFS,Sheepdog,Lustre,Swift,Cinder,TFS,HDFS...

    我们在选型开源分布式存储系统框架之前需要对不同的框架进行调研。

    所有的开源存储系统介绍链接

    存储系统对比

    目前比较热门的分布式文件系统有如下几种:

    Ceph,GlusterFS,Sheepdog,Lustre,Swift,Cinder,TFS,HDFS,MooseFS,FastDFS,MogileFS等

    开源协议说明
    GPL:不允许修改后和衍生的代码做为闭源的商业软件发布和销售,修改后该软件产品必须也采用GPL协议;
    GPL V2:修改文本的整体就必须按照GPL流通,不仅该修改文本的源码必须向社会公开,而且对于这种修改文本的流通不准许附加修改者自己作出的限制;
    GPL V3:要求用户公布修改的源代码,还要求公布相关硬件;
    LGPL:更宽松的GPL

    存储系统 Ceph GlusterFS Sheepdog Lustre Swift Cinder TFS HDFS MooseFS FastDFS MogileFS
    开发语言 C++ C C C Python Python C++ Java C C Perl
    开源协议 LGPL GPL V3 GPLv2 GPL Apache Apache GPL V2 Apache GPL V3 GPL V3 GPL
    数据存储方式 对象/文件/块 文件/块 对象 对象 文件 文件 文件/块 文件
    集群节点通信协议 私有协议(TCP) 私有协议(TCP)/ RDAM(远程直接访问内存) totem协议 私有协议(TCP)/ RDAM(远程直接访问内存) TCP 未知 TCP TCP TCP TCP HTTP
    专用元数据存储点 占用MDS 双MDS 未知 占用NS 占用MDS 占用MFS 占用DB
    在线扩容 支持 支持 支持 支持 支持 未知 支持 支持 支持 支持 支持
    冗余备份 支持 支持 支持 支持 未知 支持 支持 支持 支持 不支持
    单点故障 不存在 不存在 不存在 存在 不存在 未知 存在 存在 存在 不存在 存在
    跨集群同步 不支持 支持 未知 未知 未知 未知 支持 不支持 不支持 部分支持 不支持
    易用性 安装简单,官方文档专业化 安装简单,官方文档专业化 未知 复杂。而且Lustre严重依赖内核,需要重新编译内核 未知 目前来说框架不算成熟存在一些问题 安装复杂,官方文档少 安装简单,官方文档专业化 安装简单,官方文档多 安装简单,社区相对活跃 未知
    适用场景 单集群的大中小文件 跨集群云存储 弹性块存储虚拟机 大文件读写 openstack对象存储 openstack块存储 跨集群的小文件 Mapreduce使用的文件存储 单集群的大中文件 单集群的中小文件 未知
    FUSE挂载 支持 支持 支持 支持 支持 未知 未知 支持 支持 不支持 不支持
    访问接口 POSIX POSIX 未知 POSIX/MPI POSIX 未知 不支持POSIX 不支持POSIX POSIX 不支持POSIX 不支持POSIX

    选型时一定要考虑技术的热门程度,否则招不到人,找不到一起弄得同伴。

    我们的需求是支持NFS挂载的,就是可以当作本地文件系统一样的路径访问。

    满足这个需求的存储系统看看上表是否支持fuse挂载即可。

    在这里插入图片描述

    在这里插入图片描述

    在这里插入图片描述

    在这里插入图片描述

    在这里插入图片描述

    OpenStack Swift 和Ceph对比

    我们知道,在当前的开源对象存储项目中,OpenStack Swift 和Ceph无疑是佼佼者。OpenStack Swift通过大肆宣传,在市场上知名度很高。而Ceph是作为开源对象存储竞争产品出现的,以其丰富的功能和卓越的性能见长。两者都是开源的,但都有其短板。Ceph和Swift,哪种更好?在这个问题上大家争论不休,选择Swift还是Ceph这是一个问题!
      网友qfxhz:” Ceph虽然也有一些缺点问题,但是瑕不掩瑜,还是感觉Ceph更好一点, Ceph存储集成了对象存储和块存储,而Swift系统只能处理对象存储,不支持块存储和文件存储。“
      网友momo: “还是选择Swift吧。Ceph很重要的一个短板就是安全性。云计算节点上的RADOS客户端直接与RADOS服务器交互所使用的网络与Ceph用于未加密复制流量的网络相同。如果某个Ceph客户端节点被入侵,攻击者便能得到存储网络的所有流量。“
      网友yehuafeilang:“ceph毕竟不是一个专门的对象存储系统,其对象存储服务其实是在block服务上模拟出来的,所以和专门的对象存储swift比起来,在部署规模,使用成本上会有比较大的差距;但是,因为不是所有的云都需要大规模的对象存储,考虑到跨地域场景时,swift的部署也很复杂,所以在刚开始搭建openstack云服务时,或者是对象存储业务量不是很大时,为了节省系统搭建时间,使用ceph提供S3服务也是个不错的选择。“
      网友fatelyliang:存储不像服务器,它承载的内容是企业最重要的数据和信息,对他的可靠性、完整性、可用性、安全性、运行性能、与企业中的云计算平台关系、存储特征的可定义性等各部分的要求都应该是企业信息化基础架构中最重要的一个判断。存储设备的损坏、更换等都是对企业影响非常大的一个事情!除非系统可以轻易停机!因此,在目前的状态下,开源的存储我会更建议应用在开发测试环境、容灾环境等重要性级别相对稍低的地方,充分验证在以上几个判断依据的结论之后,结合企业的实际指标判断应该选取那一个!
      Ceph这样的系统一般不支持跨机房,跨地域的大规模部署。如果部署只在单一地域,没有计划扩展到多个地域时,Ceph会是很好的选择。但是,如果要考虑大规模部署的话,Swift可能更为适合。因为它的多地域能力会胜过 Ceph。从安全角度来看,Swift封闭的复制网络更为安全,但是,如果云基础架构本身已经很安全,存储安全性优先级便会降低,这时可能Ceph更适合。其实,在同一个云基础架构里同时拥有这两种选择也是可行的。比如说,可以使用Ceph作为本地高性能存储,而Swift则作为多地域Glance后台,但是,拥有这两种选择的解决方案花费必然更多,对于资金雄厚的企业来说为了避免长时间纠结,可以一试。 对于中小企业来讲还是得悉心衡量利弊以及自身的需求,做好整体把控为妙。关于Swift和Ceph二者的选择,更重要的是要从两者的架构角度分析各自的优缺点,并且需要结合自身的应用场景、技术实力、运营实力来进行评估,具体问题具体分析,不必纠结,正所谓寸有所长,尺有所短,选择最合适的才是最好的。

    Ceph用C++编写而Swift用Python编写,性能上应当是Ceph占优。但是与Ceph不同,Swift专注于对象存储,作为OpenStack组件之一经过大量生产实践的验证,与OpenStack结合很好,目前不少人使用Ceph为OpenStack提供块存储,但仍旧使用Swift提供对象存储。

    Ceph与HDFS对比

    Ceph对比HDFS优势在于易扩展,无单点。HDFS是专门为Hadoop这样的云计算而生,在离线批量处理大数据上有先天的优势,而Ceph是一个通用的实时存储系统。虽然Hadoop可以利用Ceph作为存储后端(根据Ceph官方的教程死活整合不了,自己写了个简洁的步骤: http://www.kai-zhang.com/cloud-computing/Running-Hadoop-on-CEPH/), 但执行计算任务上性能还是略逊于HDFS(时间上慢30%左右 Haceph: Scalable Meta- data Management for Hadoop using Ceph)。

    存储系统简介

    TFS

    TFS(Taobao File System)是由淘宝开发的一个分布式文件系统,其内部经过特殊的优化处理,适用于海量的小文件存储,目前已经对外开源;

    TFS采用自有的文件系统格式存储,因此需要专用的API接口去访问,目前官方提供的客户端版本有:C++/JAVA/PHP。

    特性

    1)在TFS文件系统中,NameServer负责管理文件元数据,通过HA机制实现主备热切换,由于所有元数据都是在内存中,其处理效率非常高效,系统架构也非常简单,管理也很方便;
    2)TFS的DataServer作为分部署数据存储节点,同时也具备负载均衡和冗余备份的功能,由于采用自有的文件系统,对小文件会采取合并策略,减少数据碎片,从而提升IO性能;
    3)TFS将元数据信息(BlockID、FileID)直接映射至文件名中,这一设计大大降低了存储元数据的内存空间;
    优点

    1)针对小文件量身定做,随机IO性能比较高;
    2)支持在线扩容机制,增强系统的可扩展性;
    3)实现了软RAID,增强系统的并发处理能力及数据容错恢复能力;
    4)支持主备热倒换,提升系统的可用性;
    5)支持主从集群部署,其中从集群主要提供读/备功能;
    缺点

    1)TFS只对小文件做优化,不适合大文件的存储;
    2)不支持POSIX通用接口访问,通用性较低;
    3)不支持自定义目录结构,及文件权限控制;
    4)通过API下载,存在单点的性能瓶颈;
    5)官方文档非常少,学习成本高;
    应用场景

    1)多集群部署的应用
    2)存储后基本不做改动
    3)海量小型文件
    根据目前官方提供的材料,对单个集群节点,存储节点在1000台以内可以良好工作,如存储节点扩大可能会出现NameServer的性能瓶颈,目前淘宝线上部署容量已达到1800TB规模(2009年数据)
    安装及使用

    安装指导

    TFS_配置使用

    源代码路径:http://code.taobao.org/p/tfs/src/

    参考
    http://rdc.taobao.com/blog/cs/?p=128

    http://elf8848.iteye.com/blog/1724423

    http://baike.baidu.com/view/1030880.htm

    http://blog.yunnotes.net/index.php/install_document_for_tfs/

    FastDFS

    FastDFS是国人开发的一款分布式文件系统,目前社区比较活跃。如上图所示系统中存在三种节点:Client、Tracker、Storage,在底层存储上通过逻辑的分组概念,使得通过在同组内配置多个Storage,从而实现软RAID10,提升并发IO的性能、简单负载均衡及数据的冗余备份;同时通过线性的添加新的逻辑存储组,从容实现存储容量的线性扩容。

    文件下载上,除了支持通过API方式,目前还提供了apache和nginx的插件支持,同时也可以不使用对应的插件,直接以Web静态资源方式对外提供下载。

    目前FastDFS(V4.x)代码量大概6w多行,内部的网络模型使用比较成熟的libevent三方库,具备高并发的处理能力。

    特性

    1)在上述介绍中Tracker服务器是整个系统的核心枢纽,其完成了访问调度(负载均衡),监控管理Storage服务器,由此可见Tracker的作用至关重要,也就增加了系统的单点故障,为此FastDFS支持多个备用的Tracker,虽然实际测试发现备用Tracker运行不是非常完美,但还是能保证系统可用。
    2)在文件同步上,只有同组的Storage才做同步,由文件所在的源Storage服务器push至其它Storage服务器,目前同步是采用Binlog方式实现,由于目前底层对同步后的文件不做正确性校验,因此这种同步方式仅适用单个集群点的局部内部网络,如果在公网上使用,肯定会出现损坏文件的情况,需要自行添加文件校验机制。
    3)支持主从文件,非常适合存在关联关系的图片,在存储方式上,FastDFS在主从文件ID上做取巧,完成了关联关系的存储。
    优点

    1)系统无需支持POSIX(可移植操作系统),降低了系统的复杂度,处理效率更高
    2)支持在线扩容机制,增强系统的可扩展性
    3)实现了软RAID,增强系统的并发处理能力及数据容错恢复能力
    4)支持主从文件,支持自定义扩展名
    5)主备Tracker服务,增强系统的可用性
    缺点

    1)不支持POSIX通用接口访问,通用性较低
    2)对跨公网的文件同步,存在较大延迟,需要应用做相应的容错策略
    3)同步机制不支持文件正确性校验,降低了系统的可用性
    4)通过API下载,存在单点的性能瓶颈

    应用场景

    1)单集群部署的应用
    2)存储后基本不做改动
    3)小中型文件根据
    目前官方提供的材料,现有的使用FastDFS系统存储容量已经达到900T,物理机器已经达到100台(50个组)

    安装指导_FastDFS

    源码路径:https://github.com/happyfish100/fastdfs

    参考

    https://code.google.com/p/fastdfs/

    http://bbs.chinaunix.net/forum-240-1.html

    http://portal.ucweb.local/docz/spec/platform/datastore/fastdfs

    MooseFS

    MooseFS是一个高可用的故障容错分布式文件系统,它支持通过FUSE方式将文件挂载操作,同时其提供的web管理界面非常方便查看当前的文件存储状态。

    特性

    1)从下图中我们可以看到MooseFS文件系统由四部分组成:Managing Server 、Data Server 、Metadata Backup Server 及Client
    2)其中所有的元数据都是由Managing Server管理,为了提高整个系统的可用性,Metadata Backup Server记录文件元数据操作日志,用于数据的及时恢复
    3)Data Server可以分布式部署,存储的数据是以块的方式分布至各存储节点的,因此提升了系统的整体性能,同时Data Server提供了冗余备份的能力,提升系统的可靠性
    4)Client通过FUSE方式挂载,提供了类似POSIX的访问方式,从而降低了Client端的开发难度,增强系统的通用性

    元数据服务器(master):负责各个数据存储服务器的管理,文件读写调度,文件空间回收以及恢复

    元数据日志服务器(metalogger):负责备份master服务器的变化日志文件,以便于在master server出问题的时候接替其进行工作

    数据存储服务器(chunkserver):数据实际存储的地方,由多个物理服务器组成,负责连接管理服务器,听从管理服务器调度,提供存储空间,并为客户提供数据传输;多节点拷贝;在数据存储目录,看不见实际的数据

    优点

    1)部署安装非常简单,管理方便
    2)支持在线扩容机制,增强系统的可扩展性
    3)实现了软RAID,增强系统的 并发处理能力及数据容错恢复能力
    4)数据恢复比较容易,增强系统的可用性5)有回收站功能,方便业务定制
    缺点

    1)存在单点性能瓶颈及单点故障
    2)MFS Master节点很消耗内存
    3)对于小于64KB的文件,存储利用率较低
    应用场景

    1)单集群部署的应用
    2)中、大型文件
    参考

    http://portal.ucweb.local/docz/spec/platform/datastore/moosefsh

    http://www.moosefs.org/

    http://sourceforge.net/projects/moosefs/?source=directory

    GlusterFS

    GlusterFS是Red Hat旗下的一款开源分布式文件系统,它具备高扩展、高可用及高性能等特性,由于其无元数据服务器的设计,使其真正实现了线性的扩展能力,使存储总容量可 轻松达到PB级别,支持数千客户端并发访问;对跨集群,其强大的Geo-Replication可以实现集群间数据镜像,而且是支持链式复制,这非常适用 于垮集群的应用场景

    特性

    1)目前GlusterFS支持FUSE方式挂载,可以通过标准的NFS/SMB/CIFS协议像访问本体文件一样访问文件系统,同时其也支持HTTP/FTP/GlusterFS访问,同时最新版本支持接入Amazon的AWS系统
    2)GlusterFS系统通过基于SSH的命令行管理界面,可以远程添加、删除存储节点,也可以监控当前存储节点的使用状态
    3)GlusterFS支持集群节点中存储虚拟卷的扩容动态扩容;同时在分布式冗余模式下,具备自愈管理功能,在Geo冗余模式下,文件支持断点续传、异步传输及增量传送等特点
    Yuyj GlusterFS.png

    优点

    1)系统支持POSIX(可移植操作系统),支持FUSE挂载通过多种协议访问,通用性比较高
    2)支持在线扩容机制,增强系统的可扩展性
    3)实现了软RAID,增强系统的 并发处理能力及数据容错恢复能力
    4)强大的命令行管理,降低学习、部署成本
    5)支持整个集群镜像拷贝,方便根据业务压力,增加集群节点
    6)官方资料文档专业化,该文件系统由Red Hat企业级做维护,版本质量有保障

    缺点

    1)通用性越强,其跨越的层次就越多,影响其IO处理效率
    2)频繁读写下,会产生垃圾文件,占用磁盘空间

    应用场景

    1)多集群部署的应用
    2)中大型文件根据目前官方提供的材料,现有的使用GlusterFS系统存储容量可轻松达到PB

    术语:

    brick:分配到卷上的文件系统块;
    client:挂载卷,并对外提供服务;
    server:实际文件存储的地方;
    subvolume:被转换过的文件系统块;
    volume:最终转换后的文件系统卷。

    参考

    http://www.gluster.org/

    http://www.gluster.org/wp-content/uploads/2012/05/Gluster_File_System-3.3.0-Administration_Guide-en-US.pdf

    http://blog.csdn.net/liuben/article/details/6284551

    Ceph

    Ceph是一个可以按对象/块/文件方式存储的开源分布式文件系统,其设计之初,就将单点故障作为首先要解决的问题,因此该系统具备高可用性、高性能及可 扩展等特点。该文件系统支持目前还处于试验阶段的高性能文件系统BTRFS(B-Tree文件系统),同时支持按OSD方式存储,因此其性能是很卓越的, 因为该系统处于试商用阶段,需谨慎引入到生产环境

    特性

    1)Ceph底层存储是基于RADOS(可靠的、自动的分布式对象存储),它提供了LIBRADOS/RADOSGW/RBD/CEPH FS方式访问底层的存储系统,如下图所示
    2)通过FUSE,Ceph支持类似的POSIX访问方式;Ceph分布式系统中最关键的MDS节点是可以部署多台,无单点故障的问题,且处理性能大大提升
    3)Ceph通过使用CRUSH算法动态完成文件inode number到object number的转换,从而避免再存储文件metadata信息,增强系统的灵活性

    优点

    1)支持对象存储(OSD)集群,通过CRUSH算法,完成文件动态定位, 处理效率更高
    2)支持通过FUSE方式挂载,降低客户端的开发成本,通用性高
    3)支持分布式的MDS/MON,无单点故障
    4)强大的容错处理和自愈能力5)支持在线扩容和冗余备份,增强系统的可靠性

    缺点

    1)目前处于试验阶段,系统稳定性有待考究

    应用场景

    1)全网分布式部署的应用
    2)对实时性、可靠性要求比较高官方宣传,存储容量可轻松达到PB级别

    源码路径:https://github.com/ceph/ceph

    参考
    http://ceph.com/

    MogileFS

    开发语言:perl

    开源协议:GPL

    依赖数据库

    Trackers(控制中心):负责读写数据库,作为代理复制storage间同步的数据

    Database:存储源数据(默认mysql)

    Storage:文件存储

    除了API,可以通过与nginx集成,对外提供下载服务

    源码路径:https://github.com/mogilefs

    参考

    https://code.google.com/p/mogilefs/wiki/Start?tm=6

    其它参考
    http://blog.csdn.net/qiangweiloveforever/ariticle/details/7566779

    http://weiruoyu.blog.51cto.com/951650/786607

    http://m.blog.csdn.net/blog/junefsh/18079733

    展开全文
  • (一)分布式存储综述

    万次阅读 2017-03-17 23:36:20
    这篇博客主要来总结一下分布式存储系统的历史,发展以及特性,从而对分布式存储系统有一个大概的了解,主要从一下几个部分来介绍分布式存储分布式存储概念 分布式文件系统的发展 分布式存储系统的分类 分布式存储...
  • 分布式存储与传统存储架构

    万次阅读 2019-04-10 20:34:58
    随着主机、磁盘、网络等技术的发展,对于承载大量数据存储的服务器来说,服务器内置存储空间,或者说内置磁盘往往不足以满足存储需要或者虽然能满足要求,但各个服务器之间独立,严重降低了磁盘的利用率。...
  • 很多人可能对分布式存储耳熟能详,但是,大多数人对其概念或者知识点却了解得都过于分散,看了很多却“只见树木,不见森林”,学了很多往往只能“知其然,却不能知其所以然”。因此,...
  • 分布式存储系统的分类

    千次阅读 2017-02-26 14:46:08
    分布式存储系统面临的需求比较复杂,大致可以分为三类: 非结构化数据:包括所有格式的办公文档、文本、图片、图像、音频、视频信息等。 结构化数据:一般会存储在关系型数据库中,可用二位关系的表结构来对数据进行...
  • https://blog.csdn.net/SmartShylyBoy/article/details/82424726 解析... https://blog.csdn.net/DonviYang/article/details/82990964初学大数据(主要介绍分布式存储) http://www.elecfans.com/consume/695431...
  • 在这个数据爆炸的时代,产生的数据量不断地在攀升,从Gb,Tb,Pb,Zb.挖掘其中数据的价值也是企业在不断地追求的终极目标。但是要想对海量的数据
  • 分布式存储系统(一) - 概念

    千次阅读 2018-10-21 18:08:37
    分布式存储系统是大量普通PC服务器通过Internet互联,对外作为一个整体提供存储服务。 最近在研读《大规模分布式存储系统》一书,顺便摘录整理,深入了解原理和架构,方便学习,欢迎交流。 一、概念 分布式存储...
  • 分布式的,用户客户端,接口服务,存储服务接口,本地磁盘。 上传接口 定位接口   之后就没有一一统计书中实现的接口了。 书中说还有视频,我还没有看。一本讲分布式对象存储系统的书,代码是用 GO 实现的,书...
  • 分布式存储 与分布式计算

    千次阅读 2016-10-20 15:26:31
    分布式存储 与分布式计算
  • 分布式存储与分布式计算

    千次阅读 多人点赞 2019-03-19 10:04:53
    3、黄金搭档:分布式存储+分布式计算 这篇文章聊一个话题:什么是分布式计算系统? (1)从一个新闻门户网站案例引入 现在很多同学经常会看到一些名词,比如分布式服务框架,分布式系统,分布式存储系统...
  • 数据库关系式存储和分布式存储区别:应用目标不同、 实现方式不同、各结点的地位不同。 (1) 应用目标不同。并行数据库系统的目标是充分发挥并行计算机的优势,利用系统中的各个处理机结点并行完成数据库任务...
  • 什么是分布式存储系统?

    千次阅读 2018-09-12 19:48:47
    分布式存储系统 定义 分布式存储系统是大量普通PC服务器通过Internet互联,对外作为一个整体提供存储服务 特性 可扩展 低成本 高性能 易用 挑战 分布式存储系统的挑战主要在于数据、状态信息的持久化,要求...
  • 先奉上干货 开源Github地址☟☟: https://github.com/xiaomi/pegasus 中文Wiki☟☟:  https://github.com/xiaomi/pegasus/wiki
  • 浅谈MongoDB数据库分布式存储管理

    千次阅读 2017-07-24 11:18:37
    分布式管理
  • 分布式 存储就是DAS ,就是服务器里面放着硬盘,多台服务器的话就是分布式存储,数据分散,不易于管理。 集中存储就是 NAS,SAN,将服务器和硬盘分开,数据都存放NAS设备中,NAS设备再级联磁盘阵列,然后多个服务器对...
  • 分布式存储原理

    千次阅读 2018-10-18 14:37:51
    分布式存储原理 1.当HDFS集群启动之时,DataNode会向NameNode发送信息,包括Block存储位置,DataNode地址。 2.Client向NameNode汇报当前上传文件的信息(Block数量、文件上传时间、文件权限、拥有着)。 2.1 Client将...
1 2 3 4 5 ... 20
收藏数 508,751
精华内容 203,500
关键字:

分布式存储