精华内容
参与话题
问答
  • 分布式存储系统

    千次阅读 2017-05-23 15:36:13
    (一)分布式存储系统应该具备的能力; (二)阿里云分布式存储系统盘古的介绍; (三)分布式系统技术展望。 分布式存储系统应该具备的能力 大数据同生活息息相关,大量数据的出现对分布式存储提出了更高的...

    本次分享内容主要包括三部分:

    (一)分布式存储系统应该具备的能力;

    (二)阿里云分布式存储系统盘古的介绍;

    (三)分布式系统技术展望。

    分布式存储系统应该具备的能力

    大数据同生活息息相关,大量数据的出现对分布式存储提出了更高的需求,具体表现为以下方面:

    (1) 高可靠,这是存储系统需要满足的最关键需求,既要保证数据在读写过程中不能发生错误,同时还要保证数据进入到系统后硬件失效不会导致数据丢失。随着集群规模的增大,遇到硬件错误概率会随之变高,存储系统需要有能力保证在任何对数据做转换的时候有无缝的数据检查机制保证数据不会出错,在硬件失效后可以及时补充数据防止硬件损坏引起的数据丢失。

    (2) 高可用,存储系统必须具备连续提供对外服务的能力。在系统运行过程中,软件升级、软件缺陷、供电和网络系统维护、硬件失效都有可能中断系统服务。为了实现高可用,软件方面,系统模块之间需要做到低耦合,模块内部做成高可用,保证在某个集成或者某一个模块的一批进程出现异常时系统其他组件仍然可用;硬件方面,可以根据硬件的拓扑结构来分布数据,防止某个硬件故障导致任何数据不可用,例如采用数据跨机架、跨数据中心分布等策略。

    (3) 高性能,存储系统软件的实现需要释放硬件技术进步带来的性能提升。现在高速存储设备再不断降低延迟增加吞吐,如果还使用传统的TCP网络和内核的CPU调度,将不能充分发挥硬件的性能。例如现在NVMe SSD设备的写入延时小于10微秒,RDMA网络小数据包传输延时小于5微秒,如果采用传统的多线程编程技术和传统的TCP网络模型会导致软件时间消耗是硬件消耗的几倍甚至几十倍,完全体现不出硬件发展带来的技术红利。

    (4) 低成本,随着云计算的蓬勃发展,数据爆炸式增长,粗放的堆设备的发展方式最终会让公司失去竞争力。存储系统在保证高可靠、高可用、高性能的前提下如何做到更低的成本会从根本上提高产品的竞争力。在存储行业一般采用的通用方法是数据编解码、分级存储等技术。

    (5) 好用,存储系统面临的用户多种多样,如何能服务好这些用户是系统能否广为使用的前提。在存储系统接口上需要多种多样,传统用户使用最多的是块设备和文件系统,同时互联网新应用需要的是对象存储、分布式表格存储等形式,如何在一套系统中提供这样丰富的接口,既对存储架构的灵活性有比价高的要求,同时还需要有很好的抽象能力。

    阿里云分布式存储系统介绍

    1. 系统架构

    盘古存储系统在阿里云内部支持ECS、MaxCompute、OSS、OTS、SLS等几乎所有的阿里云存储产品,对这些产品提供一致、可靠、高性能分布式文件接口和块设备接口,对上层屏蔽硬件错误和存储位置。

    系统层次上遵循Meta和Data分离的原则,架构类似HDFS系统的NameNode和DataNode分离,同时利用数据读写和Meta节点低耦合、Meta节点高可用和Meta节点水平扩展等技术方案来规避Meta的单点问题。在盘古系统中NameNode对应盘古的Master节点,DataNode对应盘古的ChunkServer节点。针对块设备,盘古在文件系统上增加block层来将块设备的随机读写映射到顺序读写的文件上,保证块设备数据的强一致。在上述两层之外,增加系统管控层次,可以让存储系统同其他例如流计算、NoSQL、MapReduce等系统协调一致共享硬件资源,在系统运维方面可以从各个节点获取监控、Trace、日志信息,给出运维建议和硬件故障自动处理。

    050044dc75ed23156ecae0f37715c460943bdc2b

    系统模块划分和部署图

    Master节点相当于系统的大脑,主要完成数据分布、恢复、垃圾回收功能。可以在数据写入时根据数据节点的情况动态分配数据位置,防止局部热点。在部分节点失效情况下,合理控制数据恢复过程,既保证数据可靠,同时让性能损失最小,例如在某个交换机出现故障后,为了让数据恢复尽量快,可以先在部分交换机下允许数据有多个副本,这样可以加速数据恢复,在交换机故障恢复后选择多个副本在同以交换机下的数据进行回收,尽量降低单交换机失效引起的集群性能波动。

    ChunkServer节点需要做到可以适应不同的硬件类型,以各种硬件最友好的I/O方式操作硬件,释放硬件极限性能,同时对外暴露统一的接口。实现的主要难度是在最小资源消耗的情况下,如何让软件消耗在整个I/O路径上的消耗最小。在数据恢复和重新分布功能中,ChunkServer也是流量控制和优先级控制的重要环节,涉及到多点流量控制,防止系统由于数据恢复过多占用整体或者局部网络流量导致系统性能下降。

    2. 数据复制

    在分布式存储系统中,即利用了网络设备的网卡、交换机,同时也利用了单机的磁盘、CPU、内存、主板等硬件设备,每种设备都有其特有的失效模型。那HDD磁盘举例,其失效模型包括磁盘直接损坏导致数据丢失、IO下发之后永不返回、数据静默错误,进入只读状态等多种错误类型,不同错误都需要有针对性的处理,底线应该保证数据不会丢失。在万台的集群(一个独立存储系统称为一个集群,数据中心和集群间的关系为多对多,假设机器为20盘位)中,如果按照磁盘年损坏率为5%计算,平均到每天要损坏3块硬盘。

    为保证数据可靠性,数据采用多拷贝的方式来防止硬件损坏导致数据丢失,Meta和Data同样需要高可靠,但是使用的方法不同。为保证Meta可靠,Master多个进程分成一组,使用Raft协议对数据状态进行复制。协议保证所有的Meta修改日志同步给大多数成员且落盘成功后才会返回用户成功,同时针对每条日志计算CRC,防止数据出错。数据采用多副本和Erasure Coding两种方式实现,为了降低成本,存储的拷贝数越少越好,但为了增加数据可靠性,存储的拷贝越多越好,所以为了协调两者关系,需要系统可以即时发现硬件错误并快速对数据进行恢复。

    在盘古系统中,对于硬件错误会分成不同级别进行处理,例如磁盘错误作为第一优先级处理,因为这样的错误会导致数据永久丢失,不管在网络、磁盘、CPU的调度上都会为这样的硬件失效留有配额,做到单盘数据丢失在分钟量级就可以恢复。

    3. 数据容灾

    数据容灾主要解决某个数据中心的网络和电力故障导致的系统可用性问题,跨数据中心和跨地域容灾可以突破单数据中心可用性限制,将系统可用性提高到和数据可靠性相同的水平。

    在容灾水平上,一地多中心和异地多中心区别比较大,主要局限在延时和网络带宽两个方面。在同地域100千米范围内,多个数据中心间的延时增加小于1毫秒,带宽可以做到接近于数据中心内部网络的水平,在系统设计时主要考虑在数据分布上,在流量控制和延时上的限制不突出。但是跨地域的容灾将延时增大到几十毫秒,带宽则下降至少一个数量级。为了缓解这样的问题,需要做到数据可以异步进行同步,数据可以按照重要程度来区别对待。异步复制需要保证系统Meta的一致性,需要在每时每刻保证充分利用了跨地域的网络带宽,地域内部多副本防止数据恢复占用跨地域带宽。数据重要程度则反映到对数据分布特性的指定,目前盘古系统可以设置每个文件的分布特性,改变分布特性后可以动态对数据分布做出调整。

    4. 低成本

    降低成本从不同维度可以找到不同的解决方案,将方案集成到存储系统就可以达到极致的成本降低。从软硬件方面考虑,软件编码可以有效降低存储空间,同时硬件高集成度也可以降低存储成本。从系统内部单机到整个集群,单机降低资源消耗和整个集群共享资源都可以降低对硬件的要求。从系统间考虑,能将多个系统混合部署到相同机器上分时或者同时隔离使用硬件资源也可以做到成本降低,同时有助于降低网络带宽要求。

    盘古系统支持Erasure Coding编码,可以在降低数据可靠性的前提下,将数据存储成本降低一半以上,同时利用集成度非常高的存储机型,降低对网络、内存、CPU等的均摊成功,这是一个软硬件同时进行优化达到极大降低成本的事例。为了在降低成本不降低性能的目的,在单机的硬件上盘古采用SSD介质Cache的技术手段,在享受HDD低成本的同时还可以体验到接近于SSD的高性能,同时在整个盘古系统范围内,可以设置文件的多个拷贝分别放在不同的介质上,在多个副本间做不同的介质分布,在系统级别将介质混合使用的方案发挥到极致。在和其他系统共享使用硬件的方案上,盘古提供本地磁盘接口,当用户程序需要使用本地盘存储数据的时候,直接向盘古申请一块块设备,按照自己的要求格式化成需要的各种文件系统,所有数据流均经过盘古做统一的I/O调度。这种方案不但没有造成由于共享硬件带来的管理复杂性和硬件效率降低,还给用提供了兼容所有现在本地磁盘操作所有数据操作接口。有了这基础,盘古系统和其他计算类系统可以有效共享网络、磁盘、内存、CPU资源,达到硬件使用效率的增加。

    5. 高性能

    为了实现高性能,系统在各个模块应该尽量降低软件实现对时间和资源的消耗,常用的技术手段有:使用Cache;降低多线程访问防止锁冲突带来的时间消耗和上下文切换;在数据处理过程中国利用内存零拷贝的处理方式降低时间消耗;并发使用多组硬件;硬件处理同软件处理在时间上并行处理;数据处理流水线化增大吞吐;借助新硬件技术对某个数据阶段进行加速。

    上述技术虽然不能完全应用的所有模块,但是针对不同模块的特点选择尽量多得手段组合可以将性能优化的极致。例如盘古的Master节点使用了所有文件Meta池化缓存在内存中的Cache方式,细粒度目录锁,处理流水线,操作日志合并落盘,软件处理和落盘并行处理等技术,单组盘古Master的读写混合OPS可以达到10万/秒。盘古在块存储数据通路上采用全链路无锁,全程无内存拷贝,磁盘操作和数据验证并行处理,操作Session使用线程级别Cache等技术,可以充分发挥NVMe SSD和双25Gb网络的极限性能,延时小于30微妙,数据流量将网络带宽用满的效果。

    6. 规模和隔离

    规模增大有利于平滑各种由于瞬时并发带来的系统波动,同时规模增大会带来单集群多租户的场景顺势产生,多个租户隔离和优先级控制可以防止高优先级用户收到其他用的影响。

    在MaxCompute系统需要调度的作业规模比较大,单个计算任务使用的数据量可以达到PB级别,任务众多,每天处理的作业量在百万级别,在每天凌晨开始到早上结束的这段时间内部系统均处于众多用户并行使用的阶段,白天更多的资源会闲下来给开发调试软件版本和模型训练使用。

    针对这样的计算规模,盘古系统可以提供单集群1万台的存储系统,整个MaxCompute系统会在不同集群间调度计算资源,导致链接单个盘古集群的客户端数量远远大于一个集群的国模。在盘古系统中为了应对规模个盘古Master带来的管理压力,将目录树进行静态划分,用多组Master来提供更大的处理能力,同时在各个处理阶段采用优先级队列的方式来做到多用户的隔离个优先级目的。在MaxCompute使用情况下,盘古单集群使用3组Master来对外服务,每个Master可以并行处理70万客户端的并发访问,每个任务需要在请求中提供用户信息,Master通过用户信息和用户访问的请求数在多个用户间做公平性调度。当相同优先级的多个用户的请求同时到达Master且超过处理能力时,发送请求最多的任务的请求会优先被丢弃,这样可以保证整个集群中小任务可以尽快执行完成释放出资源,大任务有效利用Master处理能力尽快完成处理的目的。在数据路径上使用相同的处理方法,做到不同用户的I/O做到优先级控制和相同优先级内部的公平。

    ec429a2e77a46f44064c8ad34415e0647e3a90c5 

    多队列调度

    d83738c91487d757901a3829a61a03f8908f98f0 

    相同优先级调度

    针对MaxCompute这种大规模数据处理任务的计算特点,大部分中间数据只在计算过程中用,计算完毕后就会被删除,例如MapReduce过程中产生Shuffle数据,盘古为这类数据的操作提供了特殊处理,这类文件的创建、打开、读写、关闭、重命名等操作不经过Master节点,只会存储于单台机器跨网络读取,删除操作跟随任务的生命周期由Master节点负责。这种类型文件的增加有效的解决了Master节点在大规模计算过程中OPS能力不足的问题,增大了系统规模。

     

    分布式存储系统技术展望

    随着更多传统业务由于成本和新应用场景要求会搬迁到云计算平台上来,对系统的接口兼容、性能和可用性会提出更高的要求,同时大客户和众多用户上云会进一步对系统的规模提出要求。所以从不同方面可以总结出分布式系统的发展路线:

    接口方面:

    1. ISCSI的系统接口可能企业存储上云的主要接口,这个方式可以有效兼容当前所有传统存储系统的接口形态,同时对于后端定制性更强,有利于快速变化的云计算技术的迭代更新。HDFS由于有Hadoop计算生态非常广泛的用户基础,会作为一个重要的分布式存储接口形式来顺利将生态用户迁移上公有云计算平台。

    2. 互联网新业务要求存储系统在提供块和文件接口的同时,也需要提供对象存储、NoSQL等存储形态,同时在这样的形态之上需要存储系统集成图片处理、视频处理、特征提取等更多的计算服务,一站满足很多用户公共的处理要求,这样不但可以让存储和计算结合来降低成本,同时也将稍微偏底层的公共技术作为用户建立新系统的基础。

    3. 存储系统对于规模的适应性可以拓展更多企业客户,并且将会成为这部分企业使用公有云的必经阶段。只有让用户在自己的企业内部熟悉了存储系统的功能,同时了解到企业内部很难在资源弹性、容灾级别上和公有云媲美后,将最终切换到公有云上。

    稳定性方面:

    1. 跨数据中心和跨地域的容灾将是存储系统的标准配置,同时对于容灾进行动态调整和灵活的定价策略将吸引更多的用户。

    2. 容器技术和只能交换网络需要进一步和存储系统进行结合,在数据安全和隔离性方面给存储系统带来巨大变化。目前基于进程内部的队列和优先级控制始终处于被动状态,不能在源头上就达到数据流量和优先级的控制,增加了系统的消耗。

    性能方面:

    1. 存储节点的数据处理将使用专用硬件设备接管来实现数据处理加速,并将数据处理和存储数据的过程合并。存储节点将集成更多的硬件,例如FPGA、RDMA网卡、GPU,这些硬件为特定的数据处理带来加速效果,同时降低功耗,例如利用FPGA对数据进行加密和解密,校验数据的Checksum等。

    2. 操作系统内核将不会再参与数据的I/O处理。由于内核进程调度、内存管理和文件系统等增加的软件消耗阻止了新存储硬件性能的发挥,所以这些软件层次将直接被跳过或者放到用户态进行重新实现,而内核只会参与存储节点的管理工作等对时效性要求不强的功能。

    原文地址:http://click.aliyun.com/m/21629/  



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

    万次阅读 多人点赞 2018-04-20 16:32:49
    我们在选型开源分布式存储系统框架之前需要对不同的框架进行调研。 所有的开源存储系统介绍链接 存储系统对比 目前比较热门的分布式文件系统有如下几种: 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

    展开全文
  • 如何架构与设计大规模分布式存储系统满足海量数据的存储需求?如何保证海量数据的一致性?如何保证海量数据的高可靠性?如何保证数据高安全性?如何保证分布式存储系统的高扩展性?如何保证分布式存储系统的负载均衡...
  • 分布式存储系统:大量普通PC服务器通过Internet互联,对外作为一个整体提供存储服务。 特点:可扩展, 低成本,高性能,易用 可扩展: 分布式存储系统扩展几百台甚至几千台的集群规模,而且随着集群规模的增长,...

    1. 概念

    分布式存储系统:大量普通PC服务器通过Internet互联,对外作为一个整体提供存储服务。

    特点:可扩展, 低成本,高性能,易用

    • 可扩展: 分布式存储系统扩展几百台甚至几千台的集群规模,而且随着集群规模的增长,性能程线性增长。
    • 低成本:分布式存储系统的自动容错、自动负载均衡机制可使其构建在普通PC机之上。 线性扩展使得增加减少机器方便,实现自动运维。
    • 高性能:单点还是整个集群,都要求分布式存储系统具备高性能。
    • 易用:分布式存储系统需要能够提供易用的对外接口,另外也要求具备完善的监控、运维工具,并能够方便地与其他系统集成。

    分布式存储系统的挑战主要在于数据、状态信息的持久化,要求在自动迁移、自动容错、并发读写的过程中保证数据的一致性。所涉及的技术来自两个领域: 分布式系统,以及数据库

    2. 分类

    分布式存储面临数据需求分为:

    • 非结构化数据: 文本,图片,音频。。。
    • 结构化数据: 关系型数据库
    • 半结构化数据:HTML文档

    分布式文件系统分为四类:

    1. 分布式文件系统, 2. 分布式键值(key- value)系统 , 3. 分布式表格系统 和 4. 分布式数据库


    end 2019.11.7

    展开全文
  • 为您提供Alluxio分布式存储系统下载,Alluxio(以前称为Tachyon)是一个虚拟的分布式存储系统。它弥合了计算框架和存储系统之间的鸿沟,使计算应用程序可以通过公共接口连接到众多存储系统。Alluxio项目源自加州大学...
  • 文件分布式存储系统

    2014-12-12 20:02:59
    文件分布式存储系统
  • 为您提供curve分布式存储系统下载,curve是网易开源的高性能、高可用、高可靠分布式存储系统,具有非常良好的扩展性。基于该存储底座可以打造适用于不同应用场景的存储系统,如块存储、对象存储、云原生数据库等。...
  • 为您提供curve分布式存储系统下载,curve是网易开源的高性能、高可用、高可靠分布式存储系统,具有非常良好的扩展性。基于该存储底座可以打造适用于不同应用场景的存储系统,如块存储、对象存储、云原生数据库等。...
  • 为您提供curve分布式存储系统下载,curve是网易开源的高性能、高可用、高可靠分布式存储系统,具有非常良好的扩展性。基于该存储底座可以打造适用于不同应用场景的存储系统,如块存储、对象存储、云原生数据库等。...
  • 大规模分布式存储系统 pdf
  • 分布式存储系统概述

    2019-02-13 21:24:29
    分布式存储系统定义:由大量普通PC服务器通过Internet互联,对外作为一个整体提供服务,具有可扩展,低成本,高性能,易用的特点。 数据分类 非结构化数据:如办公文档,图片,视频等 结构化数据:一般存储在关系...

    分布式存储系统定义:由大量普通PC服务器通过Internet互联,对外作为一个整体提供服务,具有可扩展,低成本,高性能,易用的特点。

    数据分类

    非结构化数据:如办公文档,图片,视频等

    结构化数据:一般存储在关系型数据库中,可以用二维关系表结构来表示

    半结构化数据:一般是自描述的,如html文档

    分布式存储系统分类

    分布式文件系统:存储Blob数据(二进制大对象,如非结构化数据),定长块,大文件,内部按照数据块来组织数据,每个数据块的大小相同,每个数据块包含多个Blob对象或数据块,一个大文件也可以拆分为多个数据块。分布式文件系统将这些数据块分散到存储集群,处理数据复制,一致性,负载均衡,容错等分布式系统难题。

    分布式键值系统:用于存储关系简单的半结构化数据,只提供基于主键的CRUD功能。

    分布式表格系统:用于存储关系较为复杂的半结构化数据,支持基于主键的CRUD功能以及范围查找功能。

    分布式数据库:用于存储结构化数据。

    展开全文
  • 什么是分布式存储系统

    千次阅读 2018-09-09 10:03:22
    分布式存储系统 定义 分布式存储系统是大量普通PC服务器通过Internet互联,对外作为一个整体提供存储服务 特性 可扩展 低成本 高性能 易用 挑战 分布式存储系统的挑战主要在于数据、状态信息的持久化,要求...
  • ZStack Ceph 企业版分布式存储系统软件安装手册 ZStack Ceph 企业版分布式存储系统软件安装手册
  • 海量分布式存储系统Doris

    千次阅读 2020-10-11 22:09:26
    Doris是一个海量分布式KV存储系统,其设计目标是支持中等规模高可用、可伸缩的KV存储集群。跟主流的NoSQL系统HBase相比,其具有...分布式存储系统的高可用架构 在系统架构层面,保证高可用的主要手段是冗余:服务器热备
  • 分布式存储系统 Ceph

    2018-05-23 16:35:30
    分布式存储系统 Ceph你了解Ceph吗?Ceph是一种分布式存储系统,它可以将多台服务器组成一个超大集群,把这些机器中的磁盘资源整合到一块儿,形成一个大的资源池(PB级别),然后按需分配给应用使用。那么你知道Ceph...
  • 整个大数据处理的体系,按我的理解可以分为两个部分,一个是分布式存储系统、另一个是分布式计算框架。分布式存储系统主流是HadoopDFS,其他还有Ceph和Swift。分布式计算框架主流是MapReduce,Storm和Spark。 首先...
  • 分布式存储系统 知识体系
  • 面向海量业务文件的分布式存储系统,段锐,,本文描述了一种面向顺序产生、顺序处理的海量业务文件的分布式存储系统(SSDS)。SSDS系统不仅能够满足传统海量文件的存储,而且针�
  • RDMA分布式存储系统

    千次阅读 2019-03-13 15:18:30
    文献:基于RDMA的分布式存储系统研究综述 作者:陈游旻 RDMA是远程直接内存访问,是为了解决网络传输中服务器端数据处理的延迟而产生的。在对方主机cpu不参与的情况下远程读写异地内存,无内核干预和内存拷贝发生...
  • 文章目录一、为什么要用Ceph二、Ceph架构介绍三、Ceph核心概念RADOSLibradosCrushPoolPGObject四、Ceph核心组件OSDMonitorMDSMgrRGWAdmin五、Ceph三...Ceph是当前非常流行的开源分布式存储系统,具有高扩展性、高性能、
  • 《大规模分布式存储系统:原理解析与架构实战》是分布式系统领域的经典著作,由阿里巴巴高级技术专家“阿里日照”(OceanBase核心开发人员)撰写,阳振坤、章文嵩、杨卫华、汪源、余锋(褚霸)、赖春波等来自阿里、...
  • 《大规模分布式存储系统:原理解析与架构实战》是分布式系统领域的经典著作,由阿里巴巴高级技术专家“阿里日照”(OceanBase核心开发人员)撰写,阳振坤、章文嵩、杨卫华、汪源、余锋(褚霸)、赖春波等来自阿里、...
  • 分布式存储系统(一) - 概念

    千次阅读 2018-10-21 18:08:05
    分布式存储系统是大量普通PC服务器通过Internet互联,对外作为一个整体提供存储服务。 最近在研读《大规模分布式存储系统》一书,顺便摘录整理,深入了解原理和架构,方便学习,欢迎交流。 一、概念 分布式存储...
  • 文章目录开篇:分布式系统关注的点一、基本概念1.异常2.“超时”(1)分布式存储的三态:成功、失败、超时(未知状态)3....大规模分布式存储系统的一个核心问题是:自动容错,因为服务器节点是不可靠的...
  • 分布式存储系统基本概念

    千次阅读 2015-11-13 11:33:53
    参考《大规模分布式存储系统》杨传辉  一.数据分类 非结构化数据:办公文档、文本。图片、视音频等 结构化数据:可以设计成二维关系表来存储,数据属性基本固定,数据的模式(字段、数据间关系--个表之间的关系)要...
  • 大规模分布式存储系统架构概述 概念 大规模分布式存储系统的定义:“分布式存储系统是大量普通PC服务器通过Internet互联,对外作为一个整体提供存储服务”。 分布式存储系统具有如下几个特性: ????可扩展。...

空空如也

1 2 3 4 5 ... 20
收藏数 34,876
精华内容 13,950
关键字:

分布式存储系统