精华内容
下载资源
问答
  • 开源分布式存储系统的对比

    万次阅读 多人点赞 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

    存储系统CephGlusterFSSheepdogLustreSwiftCinderTFSHDFSMooseFSFastDFSMogileFS
    开发语言C++CCCPythonPythonC++JavaCCPerl
    开源协议LGPLGPL V3GPLv2GPLApacheApacheGPL V2ApacheGPL V3GPL V3GPL
    数据存储方式对象/文件/块文件/块对象对象文件文件文件/块文件
    集群节点通信协议私有协议(TCP)私有协议(TCP)/ RDAM(远程直接访问内存)totem协议私有协议(TCP)/ RDAM(远程直接访问内存)TCP未知TCPTCPTCPTCPHTTP
    专用元数据存储点占用MDS双MDS未知占用NS占用MDS占用MFS占用DB
    在线扩容支持支持支持支持支持未知支持支持支持支持支持
    冗余备份支持支持支持支持未知支持支持支持支持不支持
    单点故障不存在不存在不存在存在不存在未知存在存在存在不存在存在
    跨集群同步不支持支持未知未知未知未知支持不支持不支持部分支持不支持
    易用性安装简单,官方文档专业化安装简单,官方文档专业化未知复杂。而且Lustre严重依赖内核,需要重新编译内核未知目前来说框架不算成熟存在一些问题安装复杂,官方文档少安装简单,官方文档专业化安装简单,官方文档多安装简单,社区相对活跃未知
    适用场景单集群的大中小文件跨集群云存储弹性块存储虚拟机大文件读写openstack对象存储openstack块存储跨集群的小文件Mapreduce使用的文件存储单集群的大中文件单集群的中小文件未知
    FUSE挂载支持支持支持支持支持未知未知支持支持不支持不支持
    访问接口POSIXPOSIX未知POSIX/MPIPOSIX未知不支持POSIX不支持POSIXPOSIX不支持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

    展开全文
  • 存储系统3.1 概述3.1.1 分类1) 根据作用(层次分类)2) 根据材料分类3) 材料不同特性不同存储方式信息的可保存性3.1.2 性能指标1) 存储容量2) 单位成本存储速度(存储时间Ta/存储周期Tm/主存带宽Bm)3) 存储时间Ta4) ...

    https://gitee.com/fakerlove/computer-organization

    文章目录

    3. 存储系统

    3.1 概述

    img img

    3.1.1 分类

    1) 根据作用(层次分类)

    高速缓冲存储器(cache)主存储器(主存,内存)辅助存储器(辅存,外存)

    img

    2) 根据材料分类

    • 磁表面存储器 :磁盘磁带
    • 磁芯存储器 :DRAM
    • 半导体存储器 :ROM,RAM
    • 光存储器 :光存储器

    3) 材料不同特性不同

    存储方式

    1.磁盘(直接存取) 磁带(顺序存取)
    2.DRAM
    3.ROM,RAM(随机存取)
    4.光存储器

    信息的可保存性

    断电后是否容易消失:容易失去RAM
    读出时是否破坏信息:破坏性读出DRAM

    随机存取存储器(random access memory,RAM)又称作“随机存储器”,是与CPU直接交换数据的内部存储器,也叫主存(内存)。它可以随时读写,而且速度很快,通常作为操作系统或其他正在运行中的程序的临时数据存储媒介。

    比如高速缓存 SRAM,主存 DRAM

    注意点,随机存储和随机存取存储器(RAM)是不一样的。ROM也支持随机存取,但不是随机存取存储器

    3.1.2 性能指标

    img

    1) 存储容量

    存储容量 = 存储单位的数量 × 字长

    比如:1M × 8位(bit)
    个人理解: 存储容量 = 地址总线数 × 数据总线数

    2) 单位成本

    单位成本 = 总成本 / 总容量

    存储速度(存储时间Ta/存储周期Tm/主存带宽Bm)

    img

    3) 存储时间Ta

    存储时间:完成一次操作的时间

    比如完成的一次读出 或 写入

    4) 存储周期Tm

    存储周期 = 存储时间 + 恢复时间

    理解:两次操作中之间的最小时间间隔

    5) 主存带宽Bm

    主存带宽,又名存储数率
    表示每秒从主存进出信息的最大数量

    最大通路数,就像烤冷面一样,是由好多条好多条构成的一板

    3.1.3 层次结构

    分为两层 cache-主存一层 ,主存-辅存一层
    img

    img

    3.2 半导体存储器

    3.2.1 存储芯片的基本结构

    img

    1) 容量计算

    img

    2^10 = 1k
    2 ^ 14 = 1k × 2^4 =16K

    2) 选择控制

    img

    3) 选片 #CS #CE

    单信号控制读写 #WE(低电平写,高电平读)双信号控制读写 #OE(允许读) #WE(允许写)

    4) 引脚数目

    数据线

    地址线 根据题目—如果是总线复用技术,行地址和列地址会分别发送,地址线会减半 DRAM采用地址复用技术,而SRAM 不能采用

    片选线 1–根据题目要求来,地址复用,片选线为2,无特殊说明为1

    读写控制线2------可以是1,根据题目要求

    例题

    例如 容量为 1024 *8 位,按字节寻址,所需要引脚数目

    地址线 按字节寻址,2^10=1024 ,需要10根地址线

    数据线 按字节编址,所以需要 8位,

    片选线1

    读写控制2

    10+8+1+2=21

    例如 容量为 1024 *8 位DRAM ,按字节寻址,采用地址复用技术,所需要引脚数目

    地址线 按字节寻址,2^10=1024 ,需要10根地址线,采用地址复用技术。地址线为5

    数据线 按字节编址,所以需要8位,

    片选线***2***

    读写控制2

    5+8+2+2=17

    3.2.2 RAM的分类

    1) SRAM,DRAM的工作原理

    img

    DRAM 刷新

    • 集中刷新
    • 分散刷新:没有死区
    • 异步刷新

    DRAM刷新单位为行

    用途

    • DRAM为主存
    • SRAM为高速缓存

    2) 简单模型改进行列地址

    img

    在这里插入图片描述

    3) DRAM的刷新

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Q2tBAn39-1609146196784)(https://gitee.com/fakerlove/picture/raw/master/20200311094423792.png)]

    4) RAM的读写周期

    3.2.3 存储系统ROM

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZjbRBJOh-1609146196785)(picture/20200318085909769.png)]

    3.3 存储器与CPU协同工作

    3.3.1 存储器的简单模型

    存储器简单模型:
    img

    实际中MAR,MDR是在CPU里,理论上是在主存里
    img

    存储器地址连线 (A地址线,D数据线)

    在这里插入图片描述

    1) 字扩展

    线选法

    在这里插入图片描述

    译码片选法⭐️⭐️

    首先得了解电路

    在这里插入图片描述

    • 与非门

    与非门真值表

    ABY
    001
    011
    101
    110

    逻辑表达式:*Y=(A·B)’=(A’)+(B’)*

    • 与门

      输入A输入B输出Y
      000
      010
      100
      111

    • 或门

      输入A输入B输出F
      000
      011
      101
      111

    • 或非门

      输入A输入B输出Y
      001
      010
      100
      110

    • 异或门

      AB输出Y
      000
      011
      101
      110

    首先得看懂电路,带圆圈的都是 取反,

    题目要求的低电平–就是输出为0,合理选择 电路

    2) 位扩展

    在这里插入图片描述

    3) 字位扩展

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EQr9qBoW-1609146196795)(picture/2020031810280724.png)]

    3.4 如何提高访问/存储的速度

    3.4.1 存储周期

    img

    提高速度的办法引入: 双口RAM和多模块存储器

    双端口 物理上的并行
    多模块 时间上的并行

    3.4.2 双端口RAM

    双端口会给两个CPU都有个"忙"的标记,防止出现同时写入之类的情况
    img

    3.4.3 多模块存储器

    单体多字存储器 (略) 和 多体并行存储器
    在这里插入图片描述[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-L70Dugoj-1609146196798)(picture/20200323102232737.png)]

    低位多体交叉存储器的性能分析

    img

    3.5 高速缓冲存储器Cache

    在这里插入图片描述
    cache出现的原因: 避免速度差造成的拥堵

    时间局部性:未来要用到的信息可能是我现在正在用的信息
    空间局部性:未来要用的信息,从存储角度说,可能在我正在用的信息的附近

    所以我把正在使用的信息,和附近的信息都放入cache
    单位:块
    img

    3.5.1 Cache 工作原理

    CPU在Cache中找到有用的数据被称为命中
    Cache高速缓存 : 存放的是cpu经常调用的主存中的内容的副本
    问题1: 主存中的块放到Cache中哪个位置 – 地址映射
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    3.5.2 Cache与内存的地址映射

    主存字块标记: 记录一些和替换算法相关的

    1) 全相联映射 - 空位随意放

    需要知道: 主存的块号(主存的哪一块) , 和该块中的具体地址
    img
    在这里插入图片描述

    2) 直接映射 - 一对一映射

    主存一一对应放入Cache,当主存超过Cache容量时候,取余 放到余数的位置
    img

    img

    3) 组相联映射

    在这里插入图片描述
    在这里插入图片描述

    3.5.3 Cache性能分析

    img

    例题1: 同时访问Cache和主存

    img

    例题2: 先访问Cache再访问主存

    img

    例题3:

    在这里插入图片描述

    3.5.4 Cache 替换算法

    当Cache装满后,CPU又经常调用主存中一个数据,这个数据没有在Cache里备份,那么这个数据 什么时候 会替换Cache中的内容

    除了直接映射(一对一映射):他会把对应位置的数据直接踢走
    剩下两种 全相联映射 和 组相联 就需要替换算法
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KRZU8xTI-1609146196815)(picture/20200420142521963.png)]
    随机算法RAND
    先入先出算法FIFO - First Input First Output
    近期最少使用算法(LRU) - Least Recently Used
    最不经常使用算法(LFU) - Least Frequently Used

    全相联情况下置换例题

    在这里插入图片描述

    组相联映射下多种置换算法的比较

    FIFO陷入先出算法LRU替换算法

    Cache 总结

    当命中的时候 CPU直接从Cache里面取数据
    当没有命中的时候 CPU从内存里去,并且内存会更新Cache里面的内容 (添加/置换) 以提高命中率
    在这里插入图片描述

    3.5.5 Cache 写策略

    CPU对Cache内容修改后,Cache如何与主存保持一致

    1) 写回法:-命中

    增加脏位: 看看是把Cache修改后的内容写回内存还是直接覆盖掉
    在这里插入图片描述

    2) 全写法write-through - 命中

    利用缓冲buffer 实现 Cache的内容一改变,主存的内容就改变
    在这里插入图片描述

    3) 写分配法 - 未命中

    CPU想修改Cache中的某一数据,但是这个数据恰恰在Cache中没存,所以从主存赶紧调入到Cache里,再修改这个数据
    在这里插入图片描述

    4) 非写分配法 - 未命中

    CPU要修改的数据,Cache中没有,CPU就知己在主存内修改

    在这里插入图片描述

    5) 总结

    在这里插入图片描述

    Cache 总容量=行数(块大小+标记位)

    Cache标记位=Tag(必有)+有效位(必有)+替换算法位(根据题目要求)+脏位(根据题目要求)

    Tag=题目算出来的

    • 全相连=主存地址位数-块内地址位数
    • 组相连=主存地址位数-行数-块内地址位数
    • 组相连=主存地址位数-组数-块内地址位数

    有效位=1

    替换算法位—组相连,2路组相连(LRU替换算法)–需要1 位,4路组相连(LRU替换算法)–2 位

    脏位–只有写回法才需要,一般不加。直接题目说明需要写回,才加

    6) 多级Cache

    在这里插入图片描述

    3.6 虚拟存储器 - 提高存储系统的容量

    重点:地址转化
    虚拟存储器的访问过程
    在这里插入图片描述

    3.6.1 页式虚拟存储器

    相关知识点: 操作系统 页式存储
    在这里插入图片描述

    3.6.2 段式存储

    段的长度是不固定的,和分组还不一样
    在这里插入图片描述

    3.6.3 快表TBL

    在这里插入图片描述

    3.6.4 页式虚拟存储例题

    页框号 : 实页号
    在这里插入图片描述

    常用的虚拟存储器寻址系统由______两级存储器组成。 A.Cache—辅存 B.主存—辅存 C.主存—Cache

    主存——辅存
    内存在计算机中的作用很大,电脑中所有运行的程序都需要经过内存来执行,如果执行的程序很大或很多,就会导致内存消耗殆尽。为了解决这个问题,Windows中运用了虚拟内存技术,即拿出一部分硬盘空间来充当内存使用,当内存占用完时,电脑就会自动调用硬盘来充当内存,以缓解内存的紧张。

    展开全文
  • 大规模分布式存储系统

    千次下载 热门讨论 2015-08-31 10:22:04
    理论方面,不仅讲解了大规模分布式存储系统的核心技术和基本原理,而且对谷歌、亚马逊、微软和阿里巴巴等国际型大互联网公司的大规模分布式存储系统进行了分析;实战方面,首先通过对阿里巴巴的分布式数据库Ocean...
  • Android存储系统及存储的挂载 Android是基于Linux内核开发的,所以它的文件系统也是跟Linux文件系统类似。 首先我们来看Android存储的分类。 内部存储和外部存储、内置SD卡和外置SD卡 一般的Android手机都有2个存储...

    Android存储系统及存储的挂载


    Android是基于Linux内核开发的,所以它的文件系统也是跟Linux文件系统类似。

    首先我们来看Android存储的分类。

    内部存储和外部存储、内置SD卡和外置SD卡

    一般的Android手机都有2个存储卡,一个内置到手机里的,不可更换,叫做内置存储卡;另外一个可以通过扩展卡槽添加一个SD卡,叫做外置SD卡。内置存储卡和外置SD卡,它们是从物理上来进行区分的,一个内置到设备,另一个是添加的扩展卡。

    对于Android系统来说,存储只分为内部存储和外部存储两类。内部存储是在应用的安装目录下(data目录),外部存储(通常是sdcard目录)在应用的安装目录外,它们是以目录为基准划分的。我们不要和内置存储卡和外置SD卡的概念混淆了,一个是逻辑上的划分,另一个是物理上的划分。

    存储所需要的权限

    我们在进行App开发时,通常需要对App的存储权限做一些处理:

    • 内部存储不需要App单独申请权限。
    • 外部存储需要App申请外部存储的读写权限,并且使用时,首先要判断外部存储是否已经挂载(因为外部存储并不总是可用)。
    • 读权限:android.permission.READ_EXTERNAL_STORAGE
    • 读写权限:android.permission.WRITE_EXTERNAL_STORAGE

    我们已经了解了存储分为内部存储和外部存储,接下来我们来分析外部存储是如何被挂载到系统的。

    外部存储的挂载

    sdcard是我们常说的sd卡根目录,我们以它为例,来分析外部存储是如何挂载到系统的。

    路径的链接关系

    我们来看sdcard的路径链接关系:

    /sdcard -> /storage/self/primary
    /mnt/sdcard -> /storage/self/primary
    
    /storage/self/primary -> /mnt/user/0/primary
    /mnt/runtime/default/self/primary -> /mnt/user/0/primary
    
    /mnt/user/0/primary -> /storage/emulated/0
    
    说明:
    • sdcard是一个软链接,它的真实地址是/storage/self/primary。
    • /storage/self/primary和/mnt/runtime/default/self/primary也是软链接,它们的实际地址是/mnt/user/0/primary。
    • /mnt/user/0/primary也是软链接,它的实际地址是/storage/emulated/0。
    • 最终是链接到/storage/emulated/0目录。

    动态存储权限授权的实现

    Android6.0 引入了一个新的应用权限模型,该模型将标记为危险的权限从安装时权限模型移动到运行时权限模型。新模型包含了READ/WRITE_EXTERNAL_STORAGE这两个存储权限,因此Android系统需要在不杀死或者重启运行中的应用的前提下,需要动态对存储访问进行授权。

    动态对存储访问授权,是通过维护所有挂载的存储设备的三个不同视图来实现的:

    /mnt/runtime/default:对所有的应用、root命名空间可见,而无需任何权限.
    /mnt/runtime/read:对有READ_EXTERNAL_STORAGE权限的应用可见。
    /mnt/runtime/write:对有WRITE_EXTERNAL_STORAGE权限的应用可见。

    出现这三个不同权限目录的原因是控制不同权限app访问。然后利用挂载命名空间实现了挂载点的隔离,在不同挂载命名空间的进程,看到的目录层次不同。每个app都根据自己的授权,选择了不同权限的runtime目录进行访问,而不同用户访问的目录也根据当前用户的id区分开了。

    具体的实现是:zygote fork进程时,我们为每个运行中的应用创建一个mount命名空间,并且bind mount合适的初始视图。当被授予运行时权限时,vold(vold是Andorid系统的设备管理器,Android系统通过vold层完成磁盘的热插拔功能)在运行中的应用的名命名空间上,通过bind mount来更新视图。注意,如果权限被撤销,将意味着该应用被kill。系统使用setns()函数来实现上述特性,这要求Linux3.8,不过Linux3.4加上补丁上也可以支持该功能。

    /mnt/runtime/default的挂载

    /mnt/runtime/default在开机执行init.rc时,挂载到storage下:

        # Mount default storage into root namespace
        mount none /mnt/runtime/default /storage bind rec
    

    并且在执行init.rc脚本时进行了软链接:

        # Symlink to keep legacy apps working in multi-user world
        symlink /storage/self/primary /sdcard
        symlink /storage/self/primary /mnt/sdcard
        symlink /mnt/user/0/primary /mnt/runtime/default/self/primary
    

    软链接&硬链接

    上文中,我们知道Android文件系统用到了很多软链接,那么什么是软链接呢?链接又分为几种类型呢?

    * 软链接

    软链接又叫符号链接,这个文件包含了另一个文件的路径名。可以是任意文件或目录,可以链接不同文件系统的文件,类似于windows中的快捷方式。链接文件甚至可以链接不存在的文件。

    * 硬链接

    硬链接相当于一个灾备份,数据存放在两处,与复制不同的是两处之间存在同步机制,一处数据的改变会实时同步到另一处,另外一处数据如果被删除了,不会影响到另一处的数据.

    硬链接,以文件副本的形式存在,但不占用实际空间。硬链接文件有两个限制:不允许给目录创建硬链接;只有在同一文件系统中的文件之间才能创建链接。

    权限控制与文件系统


    Android 8.0以上开始支持SDcardFS文件系统,它是由三星wrapfs改写而成。

    fuse文件系统(Filesystem in Userspace)

    早期的版本android系统使用的是fuse文件系统,用于控制不同APP对文件访问的权限。

    Android将手机内置SD卡与userdata分区合并成为一个分区。userdata分区使用ext4文件系统存储数据,访问userdata分区是直接操作ext4文件系统,而访问内置SD卡,则是先访问fuse文件系统,然后再访问ext4文件系统。

    fuse文件系统的基本方法是,创建fuse设备,并将fuse设备挂载到与内置SD卡目录关联的目录。那么,对内置SD卡的访问变成了先访问fuse文件系统,再访问ext4文件系统。fuse的内核部分创建了多个队列,其中包含一个pending队列和一个processing队列。每当有调用者对内置SD卡的系统调用时,fuse把文件访问路径转换为对ext4文件系统的操作路径,设置对应的操作码,并放入一个请求中。fuse在用户态有3个监控线程,循环地读取fuse设备。对fuse设备的读取操作在内核部分转换从pending队列读取请求,如果队列中没有请求,则对应的线程进入睡眠状态。监控线程读取到pending队列中的请求后,把请求转换为对ext4文件系统的系统调用操作。系统调用执行完成后,监控线程把执行结果写入到fuse设备,对fuse设备的写操作在内核部分转换为把结果放入processing队列。processing队列依次取出结果,返回给调用者。

    fuse需要进行多次的用户态与内核态交互,这样就会造成切换开销。

    SDcardFS文件系统

    sdcardfs的作用与fuse相同,也是用于控制文件访问的权限。sdcardfs的工作方式是把内置SD卡目录挂载到用于权限控制目录。对内置SD卡的系统调用,先经过sdcardfs,然后把访问路径改为ext4文件系统的真正路径,再到达ext4文件系统。ext4执行完以后,把结果返回给sdcardfs,再返回给调用者。

    sdcardfs的优势:
    1. 对同一个文件访问,fuse需要经过6次用户态与内核态的切换,但是sdcardfs只需要经过2次切换。
    2. fuse在内核中有多个队列,队列中元素的出列要等带前面的元素先出列,因此单次文件访问,fuse比sdcardfs需要更多的时间。当需要进行大量的文件访问时,累积产生时间差异是可以明显感觉出来的。
    3. SDcard由于减少了用户态与内核态的切换,其理论性能会十分接近真实系统系统。
    展开全文
  • 分布式存储系统

    千次阅读 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/  



    展开全文
  • 盘点分布式文件存储系统

    千次阅读 2021-02-08 22:14:23
    在项目的数据存储中,结构化数据通常采用关系型数据库,非结构化数据(文件)的存储就有很多种方式,服务器本地存储、Nas挂载、ftp等等,今天就来盘点一下,分布式文件存储系统
  • 存储系统和结构

    万次阅读 2018-06-10 22:35:59
    很久没有在CSDN上面发文章了,最近...将两个或来两个以上速度、容量和价格各不相同的存储器用硬件、软件或硬件软件结合的方式连接起来形成存储系统。这个系统对应用程序员是透明,即从应用程序员角度来看,它是一...
  • 存储系统设计(logisim)

    千次阅读 多人点赞 2020-05-15 18:01:42
    ** 存储系统设计(logisim) ** 汉字字库存储芯片扩展实验 MIPS寄存器文件设计 MIPS RAM设计 直接相联cache设计
  • 海量分布式存储系统Doris

    千次阅读 2020-10-11 22:09:26
    Doris是一个海量分布式KV存储系统,其设计目标是支持中等规模高可用、可伸缩的KV存储集群。跟主流的NoSQL系统HBase相比,其具有相似的性能和线性伸缩能力,并具有更好的可用性及更友好的图形用户管理界面。对于一个...
  • EMC存储系统模拟器

    千次阅读 2015-02-02 16:28:52
    EMC存储系统模拟器
  • 第四章 存储系统

    千次阅读 2020-05-31 21:11:50
    文章目录存储器概述存储器分类按存取方式按存储介质按功能和存取速度按信息保存的时间存储器系统的层次结构主存的主要技术指标容量存取速度...主存的基本结构和工作过程存储系统的层次结构半导体存储器静态MOS存储器...
  • 一、图数据模型 ...(2)图数据存储系统 存储图顶点和边,提供顶点和边的查询。 二、Neo4j (1)概念 Native graph database:采用自定义的结构在本地硬盘存储图,而不是存在数据库关系型表中。 开源Java实
  • 分段式虚拟存储系统分段式虚拟存储系统把作业的所有分段的副本都存放在辅助存储器中,当作业被调度投入运行时,首先把当前需要的一段或几段装入主存,在执行过程中访问到不在主存的段时再把它们装入。因此,在段表中...
  • 常见结构化存储系统架构

    千次阅读 2019-03-01 22:39:24
    什么是结构化存储系统 结构化数据一般指存储在数据库中,具有一定逻辑结构和物理结构的数据,最为常见的是存储在关系数据库中的数据;非结构化数据:一般指结构化数据以外的数据,这些数据不存储在数据库中,而是以...
  • MongoDB的分布式文件存储系统

    千次阅读 2017-03-06 15:17:58
    对于MongoDB的存储基本单元BSON文档对象,字段值可以是二进制类型,基于此特点,我们可以直接在MongoDB中存储文件,但是有一个限制,由于...小文件存储系统与GridFS文件存储我们先看下MongoDB存储小文件系统的例子
  • 前面已经给大家讲了《从0到1搭建大数据平台之数据采集系统》、《从0到1搭建大数据平台之调度系统》,今天给大家讲一下大数据平台计算存储系统。大数据计算平台目前主要都是围绕着hadoop生态...
  • 存储系统设计实验(logisim)计算机组成实验

    万次阅读 多人点赞 2020-05-14 15:52:31
    理解存储系统进行位扩展、字扩展的基本原理,能利用相关原理解决实验中汉字字库的存储扩展问题,并能够使用正确的字库数据填充。 我们可以做出下图: 第2关:MIPS寄存器文件设计 了解 MIPS 寄存器文件基本概念,...
  • 如何设计存储海量数据的存储系统

    千次阅读 2018-03-02 21:10:16
    基于Hadoop的海量数据存储系统设计paperuri:(514aa584f4ded0754e78326c77a15543) Hadoop基于HDFS、MapReduce、HBase
  • Ceph分布式存储系统介绍

    万次阅读 2015-11-28 09:48:18
    1. Ceph存储系统概述 Ceph 独一无二地用统一的系统提供了对象、块、和文件存储功能,它可靠性高、管理简便、并且是自由软件。 Ceph 的强大足以改变贵公司的 IT 基础架构、和管理海量数据。 Ceph 可提供极大的伸缩...
  • 传统存储系统发展史调研

    千次阅读 2015-10-20 14:15:05
    *原创文章,转载请注明: 转载...每一个技术的进步势必伴随着市场需求的不断扩张,这里存储系统的技术演进和IT系统的需求息息相关,既有对于存储设备硬件本身的改善和演进,同样也有上层针对存储设备组织构建的存储系统
  • 整个大数据处理的体系,按我的理解可以分为两个部分,一个是分布式存储系统、另一个是分布式计算框架。分布式存储系统主流是HadoopDFS,其他还有Ceph和Swift。分布式计算框架主流是MapReduce,Storm和Spark。 首先...
  • 什么是分布式存储系统

    千次阅读 2018-09-09 10:03:22
    分布式存储系统 定义 分布式存储系统是大量普通PC服务器通过Internet互联,对外作为一个整体提供存储服务 特性 可扩展 低成本 高性能 易用 挑战 分布式存储系统的挑战主要在于数据、状态信息的持久化,要求...
  • kubernetes存储系统介绍kubernetes存储系统介绍 前言 无状态服务 普通有状态服务 有状态集群服务 K8S存储系统 普通Volume persistent volume 动态存储供应dynamic provisioning References前言 在K8S运行的服务,从...
  • 笔者最近在学习,了解当前流行的若干分布式存储系统。为什么这么做呢?因为笔者比较了解HDFS,但是对其它同等类型的存储系统知道的不多,想借此学习比较一番,希望能够做到触类旁通吧。本文可能不会阐述的很具体,...
  • 搭建ISCSI存储系统

    千次阅读 2019-07-21 11:00:10
    一、 NAS和SAN服务器的概述 ...网络附属存储基于标准网络协议(Tcp/IP)实现数据传输,为网络中的Windows / Linux / Mac OS 等各种不同操作系统的计算机提供文件共享和数据备份。部分NAS系统还可以支持FTP, HT...
  • 日志存储系统常用技术方案介绍

    千次阅读 2019-01-08 04:24:29
    日志存储系统常用技术方案有两种:一是log4j/logback+mongodb的方式,一种是基于ELK的日志存储系统。  日志一般存储在数据库和文件系统中。日志数据要和生产正式库分开存储,否则会影响正式库的运行,带来隐患。...
  • 分布式存储系统 之 数据备份

    千次阅读 2015-12-02 10:57:06
    为了保证分布式存储系统的高可靠和高可用,数据在系统中一般存储多个副本。当某个存储节点出故障时,系统能够自动将服务切换到其他的副本,从而实现自动容错。
  • 一张图介绍计算机存储系统

    千次阅读 2014-09-22 16:50:33
    计算机中的存储尤为重要,需要好好理解,下边一张图介绍下计算机的存储系统: 未完待续。。。
  • 分布式存储系统(一) - 概念

    千次阅读 2018-10-21 18:08:05
    分布式存储系统是大量普通PC服务器通过Internet互联,对外作为一个整体提供存储服务。 最近在研读《大规模分布式存储系统》一书,顺便摘录整理,深入了解原理和架构,方便学习,欢迎交流。 一、概念 分布式存储...
  • 华中科技大学计算机组成存储系统设计(HUST)

    千次阅读 多人点赞 2020-06-19 23:06:59
    存储系统设计(HUST) (仅有1,2,3,5关图片及资源) 文件提取链接提取码:6f2h (失效的话评论区踢我一下) 1.汉字字库存储芯片扩展实验 2.MIPS寄存器文件设计 3.MIPS RAM设计 5.直接相联cache设计 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,820,919
精华内容 1,128,367
关键字:

存储系统