精华内容
下载资源
问答
  • 搭建ISCSI存储系统

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

    一、 NAS和SAN服务器的概述
    1、 NAS网络存储
    NAS(Network Attached Storage),NAS服务器是连接在网络上,具备资料存储功能的服务器,一种专用数据存储服务器。网络附属存储基于标准网络协议(Tcp/IP)实现数据传输,为网络中的Windows / Linux / Mac OS 等各种不同操作系统的计算机提供文件共享和数据备份。部分NAS系统还可以支持FTP, HTTP, SQL SQLSERVER等等功能,比如说现在NAS品牌 群晖!

    国内: 群晖Synology, 希捷, 西部数码, 威联通
    国际: Netapp, OUO, Dell, EMC

    专业开源NAS系统: freeNAS, nas4free, OpenMediaValut, [H群晖]
    美国八大金刚: Cisco, IBM, Google, 高通, Intel, Apple, 甲骨文, Microsoft

    去IOE计划: IBM[小型机],Oracle[DB],EMC[存储]

    NAS优点:1. I/O消耗由前端服务器转移到后端存储设备上
    2. 扩展方便
    NAS缺点:1. 以前网络会成为瓶颈, 但是现在使用10G光纤卡,就可以解决这个问题。

    NAS常见的技术:NFS和CIFS
    NAS采用了NFS技术实现类Unix系统之前存储共享。使用CIFS实现Windows与类Unix系统之前数据共享。samba 服务器就是使用CIFS计术。
    NAS就是一台服务器,把空间共享出来,如下图:
    在这里插入图片描述

    2、 SAN存储
    存储区域网络(Storage Area Network and SAN Protocols,简写SAN,即存储区域网络,是一种高速网络,提供在计算机与存储系统之间的数据传输。存储设备是指一台或多台用以存储计算机数据的磁盘设备,通常指磁盘阵列。

    SAN存储,采用网状通道(Fibre Channel ,简称FC)技术,通过FC交换机连接存储阵列和服务器主机,建立专用于数据存储的区域网络。
    SAN由于其基础是一个专用网络,因此扩展性很强,不管是在一个SAN系统中增加一定的存储空间还是增加几台使用存储空间的服务器都非常方便。

    SAN的存储类型:
    IPSAN: 不同的网络上, 使用TCP/IP协议的iscsi协议封装构件的存储区域网络
    FSCAN: 利用光纤线, 通过高速FC交换机构件的存储区域网络,。(scsi协议)

    NAS与SAN的区别在两方面:
    第一,从网络架构来说,本质区别在于:
    NAS,直接使用TCP/IP传输数据。SAN使用SCSI或iSCSI协议传输数据。
    第二,从文件读写实现方法上来说,本质区别在于:
    NAS采用了NFS和 CIFS技术实现文件共享。说明NAS是基于操作系统的“文件级”读写操作。
    SAN中计算机和存储间的接口是底层的块协议,它按照协议头的“块地址+偏移地址”来定位。共享的存储和前端的操作系统类型没有关系,任何服务器操作系统,都可以正常识别。如下图:
    在这里插入图片描述
    在这里插入图片描述

    SAN存储架构图:
    在这里插入图片描述
    配置成功后: 存储设备被前端server直接识别为块设备,即硬盘。

    IP SAN 拓扑图:
    在这里插入图片描述

    二、 实战1:配置IP SAN服务器
    1、 环境准备
    IP-SAN的运行模式:C/S模式,工作端口3260
    在这里插入图片描述

    在xuegod120中添加一块硬盘,用来作为存储共享盘给xuegod130使用
    在这里插入图片描述

    2、 配置xuegod120为IP SAN存储服务器
    1)安装target
    [root@xuegod120 ~]# yum -y install targetcli
    进入交互配置
    [root@xuegod120 ~]# targetcli
    在这里插入图片描述

    2)使用help查看帮助文件
    /> help
    在这里插入图片描述

    3)使用/dev/sdb创建块存储对象sun1,sun1是自定义名称
    /> cd /backstores/block
    /backstores/block> create sun1 /dev/sdb
    Created block storage object sun1 using /dev/sdb.

    4)创建ISCSI Target,注意:target命名在同一子网内确保是唯一的。命名格式为:iqn.yyyy-mm.<主机名反写>:自定义名称(自定义名称不能有下划线)
    /backstores/block> cd /iscsi
    /iscsi> create iqn.2019-07.cn.xuegod.server
    Created target iqn.2019-07.cn.xuegod.server.
    Created TPG 1.
    Global pref auto_add_default_portal=true
    Created default portal listening on all IPs (0.0.0.0), port 3260.

    5)为InitiatorNmae创建一个名字为:iqn.2019-07.cn.xuegod:xuegod120的ACL访问控制列表。
    也就是客户端名字在为iqn.2019-07.cn.xuegod:xuegod120才可以连接target存储
    /iscsi> cd /iscsi/iqn.2019-07.cn.xuegod.server/tpg1/acls
    /iscsi/iqn.20…ver/tpg1/acls> create iqn.2019-07.cn.xuegod:xuegod120
    Created Node ACL for iqn.2019-07.cn.xuegod:xuegod120

    6)指定块存储对象/backstores/block/sun1为target的逻辑单元号LUN0
    /iscsi/iqn.20…ver/tpg1/acls> cd /
    /> cd /iscsi/iqn.2019-07.cn.xuegod.server/tpg1/luns
    /iscsi/iqn.20…ver/tpg1/luns> create /backstores/block/sun1
    Created LUN 0.
    Created LUN 0->0 mapping in node ACL iqn.2019-07.cn.xuegod:xuegod120

    扩展:
    LUN概述:LUN的全称是Logical Unit Number,也就是逻辑单元号,是SCSI中的概念。块存储对象只要一加入target存储系统,就分有一个代号,后期在区别块设备的时候,只要说target 中LUN几号就可以了。 块存储对象被指定了一个LUN后,成为了一个“逻辑”磁盘,供存储客户端使用。

    7)指定新的监听地址和端口号
    先删除原来的默认监听端口0.0.0.0
    /iscsi/iqn.20…ver/tpg1/luns> cd …/portals/
    /iscsi/iqn.20…/tpg1/portals> delete 0.0.0.0 3260
    Deleted network portal 0.0.0.0:3260
    /iscsi/iqn.20…/tpg1/portals> create 192.168.0.120 3260
    Using default IP port 3260
    Created network portal 192.168.0.120:3260.
    /iscsi/iqn.20…/tpg1/portals> ls
    o- portals … [Portals: 1]
    o- 192.168.0.120:3260 … [OK] #创建OK
    /iscsi/iqn.20…/tpg1/portals>

    8)配置验证用户名和密码
    /> cd iscsi/iqn.2019-07.cn.xuegod.server/tpg1/acls/iqn.2019-07.cn.xuegod:xuegod120/
    /iscsi/iqn.20…god:xuegod120> set auth userid=admin
    Parameter userid is now ‘admin’.
    /iscsi/iqn.20…god:xuegod120> set auth password=123456
    Parameter password is now ‘123456’.
    /iscsi/iqn.20…god:xuegod120>

    9)退出,保存
    /iscsi/iqn.20…god:xuegod120> cd /
    /> saveconfig
    Configuration saved to /etc/target/saveconfig.json
    /> exit
    Global pref auto_save_on_exit=true
    Last 10 configs saved in /etc/target/backup/.
    Configuration saved to /etc/target/saveconfig.json

    10)启动target服务
    [root@xuegod120 ~]# systemctl start target
    [root@xuegod120 ~]# systemctl enable target
    [root@xuegod120 ~]# netstat -antup | grep 3260
    tcp 0 0 192.168.0.120:3260 0.0.0.0:* LISTEN -

    三、 实战2:IP SAN服务器日常操作
    1、 配置xuegod130客户端
    1) 安装iscsi
    [root@xuegod130 ~]# yum -y install iscsi-initiator-utils

    2) 配置ISCSI Initiator名称
    [root@xuegod130 ~]# vim /etc/iscsi/initiatorname.iscsi
    InitiatorName=iqn.2019-07.cn.xuegod:xuegod120 #=后面的名称必须和存储服务器配置相同

    3) 添加验证用户名和密码
    [root@xuegod130 ~]# vim /etc/iscsi/iscsid.conf
    改:57 #node.session.auth.authmethod = CHAP
    为:57 node.session.auth.authmethod = CHAP #删除前面的#号,取消注释
    改:
    61 #node.session.auth.username = username
    62 #node.session.auth.password = password
    为:
    61 node.session.auth.username = admin
    62 node.session.auth.password = 123456

    4) 重启iscsid服务
    [root@xuegod130 ~]# systemctl restart iscsid

    5) 发现设备
    [root@xuegod130 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.0.120
    192.168.0.120:3260,1 iqn.2019-07.cn.xuegod.server

    6) 登录到iscsi设备
    [root@xuegod130 ~]# iscsiadm -m node –login
    在这里插入图片描述

    7) 查看磁盘信息
    在这里插入图片描述

    target存储服务器信息在客户端存储的位置
    在这里插入图片描述

    8) 格式化识别的硬盘/dev/sdb
    这里如果再存储服务器上已经格式化,就不需要再次格式化
    在这里插入图片描述

    9) 挂载磁盘
    [root@xuegod130 ~]# mount /dev/sdb /opt
    在这里插入图片描述

    10) 写入数据测试
    [root@xuegod130 ~]# cd /opt/
    [root@xuegod130 opt]# echo aabbcc > a.txt
    [root@xuegod130 opt]# cat a.txt
    aabbcc

    2、 配置另外一台客户端连接target
    IP地址:192.168.0.140 主机:xuegod140 作用:iscsi客户单
    1) 安装iscsi
    [root@xuegod140 ~]# yum -y install iscsi-initiator-utils

    2) 配置连接存储服务器的名称和认证用户密码
    因为配置一样,这里不再详细写,直接将xuegod130的配置文件传递到xuegod140中使用
    [root@xuegod130 opt]# scp /etc/iscsi/initiatorname.iscsi 192.168.0.140:/etc/iscsi
    [root@xuegod130 opt]# scp /etc/iscsi/iscsid.conf 192.168.0.140:/etc/iscsi/
    在这里插入图片描述

    3) 重启iscsid服务
    [root@xuegod140 ~]# systemctl restart iscsi
    [root@xuegod140 ~]# systemctl restart iscsid

    4) 发现设备
    [root@xuegod140 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.0.120
    192.168.0.120:3260,1 iqn.2019-07.cn.xuegod.server

    5) 登录设备
    [root@xuegod140 ~]# iscsiadm -m node -l

    6) 查看硬盘
    在这里插入图片描述

    7) 挂载硬盘
    这里不用再次格式化,因为在xuegod130上已经格式化过,直接挂载即可
    [root@xuegod140 ~]# mount /dev/sdb /opt
    在这里插入图片描述

    8) 写入数据测试
    在这里插入图片描述
    可以看到xuegod130上写入的数据,在xuegod140上可以显示

    重新写入数据
    [root@xuegod140 opt]# touch b.txt
    [root@xuegod140 opt]# ll
    total 4
    -rw-r–r-- 1 root root 7 Jul 20 09:31 a.txt
    -rw-r–r-- 1 root root 0 Jul 20 09:39 b.txt

    9) 到xuegod130上查看
    在这里插入图片描述
    发现数据没有同步

    原因:因为我们使用的XFS 文件系统,XFS文件系统不支持多个客户端同时使用。 后期使用时,可以把sdb在xuegod64上识别出来后,挂载到/opt目录下,然后在xuegod64安装一个nfs服务器,把/opt目录共享给xuegod62使用,这样就可以保障数据同步了。

    临时解决方法:将挂载的盘卸载,然后再次挂载即可识别
    在这里插入图片描述

    展开全文
  • 常见结构化存储系统架构

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

    什么是结构化存储系统

    结构化数据一般指存储在数据库中,具有一定逻辑结构和物理结构的数据,最为常见的是存储在关系数据库中的数据;非结构化数据:一般指结构化数据以外的数据,这些数据不存储在数据库中,而是以各种类型的文本形式存放,其中Web上的一些数据(内嵌于HTML或XML标记中)又具有一定的逻辑结构和物理结构,被称为半结构数据。

    目前比较成熟的结构化存储系统有Cassandra、Bigtable、Hadoopdb、Megastore、Dynamo等。

    • 几个较成熟的结构化存储系统

    1. Cassandra

    Cassandra是一个分布式的存储系统,可用来管理分布在大量廉价服务器上的巨量结构化数据,并同时提供没有单点故障的高可用服务。Cassandra的设计目的是运行在由几百个节点(可能分布在多个不同的数据中心)组成的基础设施(infrastructure)上。当节点达到这个规模时,大大小小的组件出现故障就可能经常发生了。Cassandra在管理持久状态时面临这些故障,这种情况也驱动软件系统的可靠性(reliability)与可伸缩性(scalability)会依赖于Cassandra的服务。虽然大部分情况,Cassandra看上去像一个数据库系统, 也与数据库系统共享大量的设计与实现手段,但是Cassandra并不支持完整的关系数据模型;相反,它提供了一个简单数据模型的客户端,支持对数据布局与数据格式的动态控制。设计Cassandra的初衷是,可以运行在廉价硬件上,并能在不牺牲读效率的情况下实现高的写吞吐量。

    Cassandra系统架构:

    一个需要在生产环境运转的存储系统的架构是很复杂的。除了真实的数据持久化组件外,这个系统还需要包含以下特性;可伸缩性与强大负载均衡解决方案、会员与故障检测、故障恢复、副本同步、超负荷处理、状态转移、并发与任务调度、请求编组、请求路由、系统监控与报警以及配置管理。详细描述这里的每一个解决方案超出了本论文的范围,我们将集中介绍Cassandra使用的核心的分布式系统技术:分区、复制、会员、故障处理以及伸缩性。处理读写请求需要所有这些模块的协同处理。通常,一个键的请求可能被路由到Cassandra集群的任何一个节点去处理。这个节点会确定这个特定的键的副本。对于写操作来讲,系统会将请求路由到副本上,并且等待仲裁数量的副本以确认写操作完成。对于读操作来讲,基于客户端要求的一致性保证,系统要么将请求路由到最近的副本,要么将请求路由到所有的副本并等待达到仲裁数量的响应。

    2Bigtable

       Bigtable是一个分布式的结构化数据存储系统,它被设计用来处理海量数据:通常是分布在数千台普通服务器上的PB级的数据。Google 的很多项目使用Bigtable存储数据,包括Web索引、Google Earth、Google Finance。这些应用对Bigtable提出的要求差异非常大,无论是在数据量上(从URL到网页到卫星图像)还是在响应速度上(从后端的批量处理到实时数据服务)。尽管应用需求差异很大,但是,针对Google的这些产品,Bigtable还是成功的提供了一个灵活的、高性能的解决方案。

    Bigtable数据模型:

     

    3Hadoopdb

    耶鲁大学的Hadoopdb研究项目挺有意思。这是个并行DBMS(PostgreSQL) 技术和MapReduce的结合的产物。MapReduce是Google提出的一个编程模型,用于进行大规模的数据处理。

    Hadoopdb系统架构图:

    上图中的 SMS 是 "SQL to MapReduce to SQL" 的缩写。这是 HadoopDB 的一个设计难点。经过了两层转换,对于 SQL 执行的效率多少会是个问题。

    4Megastore

    Megastore是谷歌一个内部的存储系统,它的底层数据存储依赖Bigtable,也就是基于NoSql实现的,但是和传统的NoSql不同的是,它实现了类似RDBMS的数据模型(便捷性),同时提供数据的强一致性解决方案(同一个datacenter,基于MVCC的事务实现),并且将数据进行细颗粒度的分区(这里的分区是指在同一个datacenter,所有datacenter都有相同的分区数据),然后将数据更新在机房间进行同步复制(这个保证所有datacenter中的数据一致)。

    Megastore数据组织:

    5Dynamo

    Dynamo是面向Amazon自有的电子商务应用的,使用广域分布的大规模集群提供高可靠的对象存储服务,主要存储1M左右甚至更小的内容,如购物车、推荐列表等。由于Dynamo的应用场合,设计上有这么一些“独特”的要求:

    高可靠性与高伸缩性。

    始终可写,写优先于读。

    一致性与写入速度的折衷,不要求同步写入所有副本。

    对称、无中心的构架,支持异构节点。

    Amazon平台的架构图:

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

    万次阅读 2017-10-23 15:31:26
    本地文件系统如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








    展开全文
  • Ceph分布式存储系统

    千次阅读 2016-09-12 01:38:07
    Ceph是根据加州大学Santa Cruz分校的Sage Weil的博士论文所设计开发的新一代自由软件分布式文件系统,其设计目标是良好的可扩展性(PB级别以上)、高性能及高可靠性。Ceph其命名和UCSC(Ceph 的诞生地)的吉祥物有关,...

    Ceph是根据加州大学Santa Cruz分校的Sage Weil的博士论文所设计开发的新一代自由软件分布式文件系统,其设计目标是良好的可扩展性(PB级别以上)、高性能及高可靠性。Ceph其命名和UCSC(Ceph 的诞生地)的吉祥物有关,这个吉祥物是“Sammy”,一个香蕉色的蛞蝓,就是头足类中无壳的软体动物。这些有多触角的头足类动物,是对一个分布式文件系统高度并行的形象比喻。
    其设计遵循了三个原则:数据与元数据的分离,动态的分布式的元数据管理,可靠统一的分布式对象存储机制。本文将从Ceph的架构出发,综合性的介绍Ceph分布式文件系统特点及其实现方式。
    一、Ceph基本架构
    Ceph是一个高可用、易于管理、开源的分布式存储系统,可以在一套系统中同时提供对象存储、块存储以及文件存储服务。其主要由Ceph存储系统的核心RADOS以及块存取接口、对象存取接口和文件系统接口组成,如图所示
    这里写图片描述

    Ceph的底层是RADOS,它的意思是“A reliable,autonomous, distributed object storage”。 RADOS作为Ceph分布式文件系统的一个子项目,是为了满足Ceph的需求而设计的,但是,其也可以单独作为一种分布式数据存储系统,给其他的有类似需求的分布式文件系统提供数据存储服务。Ceph文件系统, Ceph对象存储和Ceph块设备从RADOS的存储集群中读去和写入数据。
    Ceph作为一个分布式存储系统,其对外提供的接口,决定了其通用性以及扩展性。如上图架构图中所示的那样,Ceph对外提供了丰富多样的服务接口,包括多种编程语言接口LIBRADOS(备注,上图来自Ceph中文社区,社区人员在翻译的过程中将字母L遗失掉了)、对象存储接口(RADOSGW)、块存储接口(RBD)以及文件系统接口(Ceph FS)。其中LIBRADOS编程接口是其他各种客户端接口的基础,其他接口都是基于LIBRADOS来进行扩展实现的。

    1.1. RADOS
    Ceph中RADOS(Reliable Autonomic Distributed Object Store)存储集群是所有其他客户端接口使用和部署的基础。RADOS由两个组件组成:
    OSD: Object StorageDevice,提供存储资源。
    Monitor:维护整个Ceph集群的全局状态。
    这里写图片描述

    典型的RADOS部署架构由少量的Monitor监控器以及大量的OSD存储设备组成,它能够在动态变化的基于异质结构的存储设备集群之上提供一种稳定的、可扩展的、高性能的单一逻辑对象存储接口。
    RADOS系统的架构如图所示:
    这里写图片描述

    我们看到,RADOS不是某种组件,而是由OSD(Object Storage Device)集群和Monitor集群组成。通常,一个RADOS系统中,OSD集群是由大量的智能化的OSD节点组成;Monitor集群是由少量的Monitor节点组成。OSD集群负责存储所有对象的数据。Monitors集群负责管理Ceph集群中所有成员、关系、属性以及数据分发等信息。

    1.2. Ceph客户端接口(Clients)
    我们将Ceph架构中除了底层基础RADOS之上的LIBRADOS、RADOSGW、RBD以及Ceph FS统一称为Ceph客户端接口。而LIBRADOS又是Ceph其它如RADOSGW、RBD以及Ceph FS的基础。简而言之就是RADOSGW、RBD以及Ceph FS根据LIBRADOS提供的多编程语言接口开发。所以他们之间是一个阶梯级的关系。
    1.2.1. RADOSGW
    RADOSGW(RADOS Gmeway),又叫Ceph对象存储网关,是一个底层基于librados向客户端提供RESTful接口的对象存储接口。目前Ceph支持两种API接口:
    (1) S3.compatible:S3兼容的接口,提供与Amazon S3大部分RESTfuI API接口兼容的API接口。
    (2) Swift.compatible:提供与OpenStack Swift大部分接口兼容的API接口。Ceph的对象存储使用网关守护进程(radosgw), radosgw结构图如图所示:
    这里写图片描述

    在实际的Ceph集群中,radosgw是一个监听RESTfulAPI访问的后台进程,s3 API和Swift APl使用同一个命名空间,即共享同一个命名空间;所以,你可以用其中一个接口写入数据而又用另外一个接口读出数据。
    1.2.2. RBD
    一个数据块是一个字节序列(例如,一个512字节的数据块)。基于数据块存储接口最常见的介质,如硬盘,光盘,软盘,甚至是传统的9磁道的磁带的方式来存储数据。块设备接口的普及使得虚拟块设备成为构建像Ceph海量数据存储系统理想选择。
    在一个Ceph的集群中, Ceph的块设备支持自动精简配置,调整大小和存储数据。Ceph的块设备可以充分利用 RADOS功能,实现如快照,复制和数据一致性。Ceph的RADOS块设备(即RBD)通过RADOS协议与内核模块或librbd的库进行交互。。RBD的结构如图所示:
    这里写图片描述

    在Ceph中,如果客户端要想使用存储集群服务提供的块存储,必须要先安装相应的Linux内核模块Kernel Module,或者使用librbd编程接口。
    1.2.3. Ceph FS
    Ceph文件系统(CEPH FS)是一个POSIX兼容的文件系统,使用Ceph的存储集群来存储其数据。Ceph的文件系统使用相同的Ceph的存储集群系统比如Ceph的块设备,Ceph的S3和SwiftAPI对象存储,或本机绑定(librados)。CEPH FS的结构图如下所示:
    这里写图片描述

    CEPH FS是一个符合POSIX标准的文件系统接口,同时支持用户空间文件系统FUSE。在CEPH FS中,与对象存储接口与块存储接口最大的不同就是在集群中增加了文件系统元数据服务节点MDS(Ceph Metadata Server)。MDS也支持多台机器分布式的部署,以实现系统的高可用性。文件系统客户端需要安装对应的Linux内核模块Ceph FS KernelObject或者Ceph FS FUSE组件。

    二、Ceph数据存储
    2.1. 数据存储过程
    Ceph存储集群从客户端接收文件,每个文件都会被客户端切分成一个或多个对象,然后将这些对象进行分组,再根据一定的策略存储到集群的OSD节点中,其存储过程如图所示:
    这里写图片描述

    图中,对象的分发需要经过两个阶段的计算,才能得到存储该对象的OSD,然后将对象存储到OSD中对应的位置。
    (1) 对象到PG的映射。PG(PlaccmentGroup)是对象的逻辑集合。PG是系统向OSD节点分发数据的基本单位,相同PG里的对象将被分发到相同的OSD节点中(一个主OSD节点多个备份OSD节点)。对象的PG是由对象ID号通过Hash算法,结合其他一些修正参数得到的。
    (2) PG到相应的OSD的映射,RADOS系统利用相应的哈希算法根据系统当前的状态以及PG的ID号,将各个PG分发到OSD集群中。OSD集群是根据物理节点的容错区域(比如机架、机房等)来进行划分的。
    Ceph中的OSD节点将所有的对象存储在一个没有分层和目录的统一的命名空问中。每个对象都包含一个ID号、若干二进制数据以及相应的元数据。
    ID号在整个存储集群中是唯一的;元数据标识了所存储数据的属性。一个对象在OSD节点中的存储方式大致如图所示。
    这里写图片描述

    而对存储数据的语义解释完全交给相应的客户端来完成,比如,Ceph FS客户端将文件元数据(比如所有者、创建日期、修改日期等)作为对象属性存储在Ceph中。
    2.2. CRUSH算法
    Ceph作为一个高可用、高性能的对象存储系统,其数据读取及写入方式是保证其高可用性及高性能的重要手段。对于已知的数据对象,Ccph通过使用CRUSH(ControlledReplication Under Scalable Hashing)算法计算出其在Ceph集群中的位置,然后直接与对应的OSD设备进行交互,进行数据读取或者写入。
    例如其写入数据的其主要过程如图所示。
    这里写图片描述

    首先,客户端获取Ceph存储系统的状态信息Cluster Map,然后根据状态信息以及将要写入的Pool的CRUSH相关信息,获取到数据将要写入的OSD,最后
    OSD将数据写入到其中相应的存储位置。其中相关概念的解释如下:
    (1) 集群地图(Cluster Map):Ceph依赖于客户端以及OSD进程中保存有整个集群相关的拓扑信息,来实现集群的管理和数据的读写。整个集群相关的拓扑信息就称之为“Cluster Map”。Cluster Map主要保存Monitor集群、OSD集群、MDS集群等相关的拓扑结构信息以及状态信息。
    (2) 存储池(P001):是对Ceph集群进行的逻辑划分,主要设置其中存储对象的权限、备份数目、PG数以及CRUSH规则等属性。
    在传统的存储系统中,要查找数据通常是依赖于查找系统的的文件索引表找到对应的数据在磁盘中的位置。而在Ceph对象存储系统中,客户端与OSD节点都使用CRUSH算法来高效的计算所存储数据的相关信息。相对于传统的方式,CRUSH提供了一种更好的数据管理机制,它能够将数据管理的大部分工作都分配给客户端和OSD节点,这样为集群的扩大和存储容量的动态扩展带来了很大的方便。CRUSH是一种伪随机数据分布算法,它能够在具有层级结构的存储集群中有效的分发对象副本。
    CRUSH算法是根据集群中存储设备的权重来进行数据分发的,数据在各个OSD设备上近似均匀概率分布。CRUSH中,数据在存储设备上的分布是根据一个层次化的集群地图(Cluster Map)来决定的。集群地图是由可用的存储资源以及由这些存储资源构建的集群的逻辑单元组成。比如一个Ceph存储集群的集群地图的结构可能是一排排大型的机柜,每个机柜中包含多个机架,每个机架中放置着存储设备。数据分发策略是依照数据的存放规则(placement rules)进行定义的,存放规则是指数据在备份以及存放时应该遵循的相关约定,比如约定一个对象的三个副本应该存放在三个不同的物理机架上。
    给定一个值为x的整数,CRUSH将根据相应的策略进行哈希计算输出一个
    有序的包含n个存储目标的序列:
    CRUSH(x)=(osd1,osd2,osd3osdn)
    CRUSH利用健壮的哈希函数,其得到的结果依赖于集群地图Cluster Map、存放规贝则(placementmles)和输入x。并且CRUSH是一个伪随机算法,两个相似的输入得到的结果是没有明显的相关性的。这样就能确保Ceph中数据分布是随机均匀的。
    2.3. 数据一致性
    Ceph中,为了保持数据的一致性,在PG内部通常会进行对象的净化过程(scrubobjects)。数据净化通常每天进行一次(通常在数据I/O量不大,进行系统维护时进行)。OSD设备还能够通过进行数据对象bit-for-bit的对比进行深度的数据净化,用以找到普通数据净化中不易察觉的问题(比如磁盘扇区损坏等)。通过数据维护和净化,为数据的一致性提供了保障。

    三、扩展性和高可用性
    在传统的分布式系统中,客户端通常与一个中央节点进行交互,这样通常存在着单点故障问题,而且不利于系统的扩展。Ceph中客户端是直接与OSD节点进行交互,而不需要通过中心节点。对同一个对象,Ceph通常会在不同的OSD节点上创建多个备份,这样就保证了数据可靠性和高可用性。Ceph对元数据服务器也采用高可用的集群管理,这样也提高了系统元数据的的高可用性。Ceph的良好的高可用性和扩展性是系统设计的核心,这其中用到了很多精巧的设计和算法,下面就对实现Ceph的一些关键的实现技术进行介绍。
    3.1. 高可用性的Monitor集群
    在Ceph的客户端读或者写数据之前,他们必须先通过Ceph Monitor来获取最新的Cluster Map的副本。如果只有一个Monitor节点,Ceph存储集群也可以正常工作,但是这样会有单点的风险(如果这一台Monitor节点宕机了,整个Ceph
    集群就无法正常工作)。Ceph中支持多台Monitor节点组成高可用的集群来提高整个Ceph系统的高可用性。Ceph中通过Paxos算法来保持Monitor集群中各个节点的状态一致性。
    3.2. 高可用性的MDS集群
    在通过Ceph FS接口使用Ceph集群时,Ceph集群中需要部署MDS(Metadata Server)进程,通常也是使用集群的方式进行部署。MDS集群的主要作用是将所有的文件系统元数据(目录、文件拥有者、访问权限等)存放在高可用的内存中。这样,客户端简单的文件操作(ls,cd等)将由MDS集群快速的响应,而不用消耗OSD设备的I/O,实现了元数据与数据的分离。为Ceph FS文件系统接口将能提供了性能上的保证。
    Ccph FS旨在提供POSIX兼容的文件系统接口,依赖于MDS中运行的ceph-mds进程,该进程不仅能够作为一个单一的进程运行,还可以分布式的运行在多个服务器上,实现了高可用性和扩展性。
    (1) 高可用性:通常在Ceph集群中有多个ceph-mds进程在运行。当一个Ceph-mds出现运行故障时,备用的其他的ceph-mds能够立刻接替失效的ceph-mds的工作。这个过程主要依赖于Ceph中的日志机制并且通过高可用的Monitor进程来完成相关的恢复工作。
    (2) 扩展性:Ceph集群中可以分布式的部署多个ceph-mds进程实例,他们共同完成Ceph文件系统相关的工作,并且能够动态的实现负载均衡。
    3.3. 超大规模智能守护(OSD)
    在许多传统的集群架构中,往往设立一个中心节点来掌控整个集群的全部元数据信息,这样不仅会因为单点问题对系统的高可用性造成影响,而且中心节点的性能也会成为系统横向扩展的瓶颈。在Ceph就没有这样的瓶颈,在Ceph中,每个Ceph的客户端和OSD节点都保存有整个系统相关的拓扑信息。这样,客户端就能直接和存储数据的OSD节点进行交互,OSD节点相互之间也能直接进行交互。Ceph中去中心节点的架构能够带来以下一些好处:
    (1) OSD节点能直接为客户端提供服务:我们知道,任何网络设备都有一个并发连接的上限。中心节点结构的分布式集群中,中心节点往往是整个系统性能的瓶颈。Ceph中客户端能与存放数据的OSD节点直接通信,而不用经过任何的中心节点,这样整个系统不仅没有单点问题,而且性能就得到了很大的提升。
    (2) OSD节点参与系统的维护:通常一个OSD节点加入到Ceph存储集群中,要向集群中的Monitor节点汇报自己的状态。如果OSD节点宕机,则需要系统能自动检测出来。这通常是由Monitor节点周期性的对各个OSD节点中的相关服务进行检测来实现。如果Monitor节点检测的周期间隔太短会影响系统的性能;而如果检测周期间隔太长,则会使整个系统有较长的时间处于不一致的状态。Ceph中允许OSD节点对相邻的OSD节点的状态进行检测,如果相邻的节点有状态变化,OSD节点则会主动向整个集群进行汇报,同时集群中相关的Cluster Map得到更新。这样大大减轻了Monitor节点的压力。系统的扩展性和高可用性得到很大的提升。
    (3) OSD节点定期的数据清洁:数据清洁是指,一个OSD节点中存储的对象与另外一个存储该对象副本的OSD节点之间进行对象的元数据对比,依此来找出文件系统相关的错误。Ceph中OSD节点能够自动的进行数据清洁(通常是一天一次)。除了普通的数据清洁,Ceph中OSD节点还可以通过对相同对象不同副本中的数据进行按位(bit-for-bit)的深度数据清洁(通常一周一次)。这种数据清洁机制对系统的数据一致性有很大的帮助。
    (4) 数据智能备份:和Ceph客户端一样,Ceph OSD节点也使用CRUSH算法。但是和客户端使用CRUSH算法来查找数据不同,Ceph OSD节点使用该算法来计算对象的备份副本应该被存储在哪个位置。数据智能备份的大致流程如图所示:
    这里写图片描述

    3.4. 智能负载均衡
    当在Ceph集群中增加或减少OSD设备时,集群会执行负载再均衡的过程(rebalancing)。首先,集群地图(Cluster Map)会得到更新,PG ID以及OSD集群相关的信息都会得到更新。如下图,简单展示了增加OSD存储设备时数据再均衡的大致过程。其中,一些PG从其原来所处的OSD存储设备迁移到了新的OSD存储设备。在数据再均衡过程中,CRUSH保持稳定,有许多的PG还是依然保留其原有的配置。并且由于进行了数据的迁出,原有OSD设备中的剩余容量也会相应的有所增加。整个数据再均衡过程也是利用的CRUSH算法,数据依然是均衡的分布在新的OSD集群中。
    这里写图片描述

    四、小结
    在本文中,我们介绍了Ceph分布式文件系统的基本架构、工作机制及原理。并且从架构和原理的基础上论述了其优良的特性。综合看来,Ceph分布式文件系统有如下的特点:
    (1) Ceph的核心RADOS通常是由少量的负责集群管理的Monitor进程和大量的负责数据存储的OSD进程构成,采用无中心节点的分布式架构,对数据进行分块多份存储。具有良好的扩展性和高可用性。
    (1) Ceph分布式文件系统提供了多种客户端,包括对象存储接口、块存储接口以及文件系统接口,具有广泛的适用性,并且客户端与存储数据的OSD设备直接进行数据交互,大大提高了数据的存取性能。
    (2) Ceph作为分布式文件系统,其能够在维护 POSIX 兼容性的同时加入了复制和容错功能。从2010 年 3 月底,以及可以在Linux 内核(从2.6.34版开始)中找到 Ceph 的身影,作为Linux的文件系统备选之一,Ceph.ko已经集成入Linux内核之中。虽然目前Ceph 可能还不适用于生产环境,但它对测试目的还是非常有用的。Ceph 不仅仅是一个文件系统,还是一个有企业级功能的对象存储生态环境。现在,Ceph已经被集成在主线 Linux 内核中,但只是被标识为实验性的。在这种状态下的文件系统对测试是有用的,但是对生产环境没有做好准备。但是考虑到Ceph 加入到 Linux 内核的行列,不久的将来,它应该就能用于解决海量存储的需要了。

    原文
    http://www.linuxidc.com/Linux/2016-04/130026.htm

    在 CentOS 7.1 上安装分布式存储系统 Ceph http://www.linuxidc.com/Linux/2015-08/120990.htm
    Ceph环境配置文档 PDF http://www.linuxidc.com/Linux/2013-05/85212.htm
    CentOS 6.3上部署Ceph http://www.linuxidc.com/Linux/2013-05/85213.htm
    Ceph的安装过程 http://www.linuxidc.com/Linux/2013-05/85210.htm
    HOWTO Install Ceph On FC12, FC上安装Ceph分布式文件系统 http://www.linuxidc.com/Linux/2013-05/85209.htm
    Ceph 文件系统安装 http://www.linuxidc.com/Linux/2013-05/85208.htm
    CentOS 6.2 64位上安装Ceph 0.47.2 http://www.linuxidc.com/Linux/2013-05/85206.htm
    Ubuntu 12.04 Ceph分布式文件系统 http://www.linuxidc.com/Linux/2013-04/82588.htm
    Fedora 14上安装 Ceph 0.24 http://www.linuxidc.com/Linux/2011-01/31580.htm
    Ceph 的详细介绍:请点这里
    Ceph 的下载地址:请点这里
    本文永久更新链接地址:http://www.linuxidc.com/Linux/2016-04/130026.htm

    展开全文
  • kubernetes存储系统介绍kubernetes存储系统介绍 前言 无状态服务 普通有状态服务 有状态集群服务 K8S存储系统 普通Volume persistent volume 动态存储供应dynamic provisioning References前言 在K8S运行的服务,从...
  • 第四章 存储系统

    千次阅读 2020-05-31 21:11:50
    文章目录存储器概述存储器分类按存取方式按存储介质按功能和存取速度按信息保存的时间存储器系统的层次结构主存的主要技术指标容量存取速度...主存的基本结构和工作过程存储系统的层次结构半导体存储器静态MOS存储器...
  • 主存储器与存储系统

    千次阅读 2008-04-12 21:21:00
    主存储器与存储系统1、存储系统的组成1.1、存储器的分类按存储器在计算机系统中的作用分类:高速缓冲存储器:高速缓冲存储器(Cache)位于主存和CPU之间,用于存放正在执行的程序段和数据,以便CPU能高速地使用它们...
  • 存储系统性能 - 带宽计算

    千次阅读 2013-08-14 23:40:15
    存储系统的最大吞吐量(IOPS)是多少? 某存储系统的最大带宽(MB/s)是多少? IOPS和带宽的计算与I/O大小、随机/顺序、读写比率、应用程序的线程模型、对响应时间的要求等诸多因素相关,这些因素的组合称之为...
  • TFS与其他分布式存储系统的对比分析 ...其他分布式存储系统,这里主要的是最近我通过读论文以及网络上的技术文档和分享所了解到的一些大公司所采用的存储系统,其中包括Google的GFS,BigTable(BT),Amaz
  • 存储系统中热备盘的作用

    千次阅读 2014-01-13 16:27:17
    为保证存储系统的可靠性,建议在创建RAID组后创建热备盘。但目前存储系统的热备盘为全局热备盘,不能为某个特定的RAID组指定热备盘。 在配置热备盘时,需要遵循以下配置原则: 不能使用保险箱硬盘作为热备盘。 ...
  • 高速数据采集存储系统分类

    千次阅读 2017-09-28 10:54:34
    随着计算机技术发展,计算机总线速率、处理能力与存储技术得到了快速发展。就存储技术而言相比于五年前,现在不论是传输速率,存储速度与存储容量均有了不同数量级的变化。如现在的PCIe Express总线可以实现3GB/s ...
  • HDFS分布式文件存储系统

    千次阅读 2017-09-02 15:57:21
    Namenode 是一个中心服务器,单一节点(简化系统的设计和实现),负责管理文件系统的名字空间(namespace)以及客户端对文件的访问。 文件操作,NameNode 负责文件元数据的操作,DataNode负责处理文件内容的读写请求...
  • 笔者最近在学习,了解当前流行的若干分布式存储系统。为什么这么做呢?因为笔者比较了解HDFS,但是对其它同等类型的存储系统知道的不多,想借此学习比较一番,希望能够做到触类旁通吧。本文可能不会阐述的很具体,...
  • 操作系统储存管理功能

    千次阅读 2019-05-12 11:32:59
    一般而言,低地址空间,从0x00000000~ 0x7FFFFFFF使用户空间,高地址空间被分配给系统。 虚拟内存范围 功能 0x00000000 ~ 0x0000FFFF 这段内存为空指针区,不可以同时访问 0x00010000 ~...
  • 本文按照自己的理解从硬件磁盘到文件系统的逐层网上的思路开展,从操作系统的角度详解Linux文件系统层次、文件系统分类、文件系统存储结构、不同存储介质的区别(RAM、ROM、Flash)、存储节点inode。
  • 在大规模存储系统或云存储系统中,高可用、高扩展性的元数据存储问题一直是一个关键点。
  • 计算机系统结构 存储体系

    千次阅读 2016-05-06 00:02:18
    (2)命中率 H 和不命中率 F命中率是CPU在访问存储系统时,在存储器M中找到所需信息的概率。 不命中率=1-命中率。 (3)平均访存时间 T二、“Cache-主存”和“主存-辅存”层次2.1 Cache-主存2.2 主存-辅存2.3 比
  • 有时候初创企业需要快速搭建一个文件存储平台,满足企业内项目的图片、视频、文本等文件的存储;...为了解决这些问题,我们设计了自己的存储系统WFS。 最基本的分布式文件存储系统需要满足以下几个原则:
  • 目前主流的文件系统包括windows下的NTFS文件系统、Linux下的EXT系列文件系统(管理规则已升级到EXT4)、XFS文件系统和Btrfs文件系统。由于本专题的知识体系全部基于Linux操作系统,所以我们不会对NTFS文件系统做过多...
  • http://blog.csdn.net/enweitech/article/details/51445087 2016年05月18日 16:33:31 24238人阅读 评论(2) 收藏 举报 分类:操作系统(51) 块存储和文件存储是我们比较熟悉的两种主流的存储类型,而对象存储...
  • ARM体系架构中的存储系统

    千次阅读 2016-06-20 17:44:56
    在计算机系统当中,数据的存储是以字节为单位的,每个地址单元当中都可以存放一个字节的数据,每个字节为8bit。在C语言中编译器为char型的数据分配了一个字节的存储空间,为long型的数据分配了4个字节的存储空间,为...
  • 分布式存储系统是将数据存放在多个服务器上,同时按照一定规则做备份,冗余出2-3套副本,以保障有服务器出故障时,整个系统不受影响,依旧可用。 当一部分服务器节点出故障无法访问的时候,存储在故障服务器上的副本...
  • 计算机组成原理:储存系统和结构

    万次阅读 2019-06-19 22:27:37
    储存系统的组成: 1.按作用分类 1>高速缓冲存储器:位于主存和CPU之间,用来存放正在执行的程序段和数据,以便CPU能高速的访问它们。其速度可以和CPU速度相匹配。 2>主存储器:存放计算机运行期间所需要...
  • Bitcask存储系统架构设计思想

    千次阅读 2017-09-02 16:13:40
    Bitcask存储系统架构设计思想 Bitcask模型是一种日志型键值模型。所谓日志型,是它不直接支持随机写入,而是像日志一样支持追加操作。Bitcask模型将随机写入转化为顺序写入。有两个好处: 提高随机写入的吞吐...
  • 在J2ME中使用记录存储系统(RMS)存储信息 更多文章请访问:http://blog.csdn.net/mailbomb 在MIDP中,没有文件的概念,所以永久存储一般只能依靠记录存储系统实现,关于记录存储系统的简介,可以参看教程: ...
  • 存储系统的类型及特点

    千次阅读 2020-05-30 19:43:39
    DAS:开放系统的直连式存储(Direct-Attached Storage,简称DAS)已经有近四十年的使用历史,随着用户数据的不断增长,尤其是数百GB以上时,其在备份、恢复、扩展、灾备等方面的问题变得日益困扰系统管理员。...
  • 视频监控/存储系统设计要点

    千次阅读 2014-10-21 17:07:11
    视频监控系统组成; 存储的设计宗旨; 存储的发展过程; 存储设计特点; 存储视频格式; 关于拉模式和推模式; 存储模式; 分配存储资源; 录像检索; 录像查询方式; 容灾和异常处理; 旧系统升级; 其它及注意事项...
  • iSCSI存储系统知识详解

    千次阅读 2014-06-13 14:20:55
    SCSI 即 小型计算机系统接口 。... 简写:SCSI),一种用于计算机和智能设备之间(硬盘、软驱、光驱、打印机、扫描仪等)系统级接口的独立处理器标准。 SCSI是一种智能的通用接口标准。它是各种计算机与外部
  • 前面已经给大家讲了《从0到1搭建大数据平台之数据采集系统》、《从0到1搭建大数据平台之调度系统》,今天给大家讲一下大数据平台计算存储系统。大数据计算平台目前主要都是围绕着hadoop生态...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 792,180
精华内容 316,872
关键字:

储存系统一般指