ceph_ceph 多副本 - CSDN
ceph 订阅
Ceph是第一人称游戏《孤岛危机》系列中一个技术先进的神秘外星物种,该绰号是“Cephalopod(头足类动物)”的简称,因为它们非常类似于地球海洋上的章鱼或乌贼,而人类对这个物种给出的正式名称是“卡律布狄斯(Charybdis)”。它们对人类怀有敌意,对他们发动一场灭绝人类的战争。 [1]  它们是外来殖民者,来自于Messier 33三角座星系α象限中一颗被视为“Ceph Homeworld”的行星,距地球约300万光年。大约6500万年前到达地球,在游戏事件发生之前,它们最近的活动发生在大约200万年前,集体进入了休眠状态。直到它们在灵山岛上被完全唤醒。 [1] 展开全文
Ceph是第一人称游戏《孤岛危机》系列中一个技术先进的神秘外星物种,该绰号是“Cephalopod(头足类动物)”的简称,因为它们非常类似于地球海洋上的章鱼或乌贼,而人类对这个物种给出的正式名称是“卡律布狄斯(Charybdis)”。它们对人类怀有敌意,对他们发动一场灭绝人类的战争。 [1]  它们是外来殖民者,来自于Messier 33三角座星系α象限中一颗被视为“Ceph Homeworld”的行星,距地球约300万光年。大约6500万年前到达地球,在游戏事件发生之前,它们最近的活动发生在大约200万年前,集体进入了休眠状态。直到它们在灵山岛上被完全唤醒。 [1]
信息
中文名
Ceph
其它名称
Charybdis
登场作品
孤岛危机
定    义
外星生物
Ceph孤岛危机1
而后因为地壳运动导致其深埋在地下,无法觉醒。在《孤岛危机》历史中,Ceph与人类的接触可能最早是在1908年,当年通古斯大爆炸后,哈格瑞夫(二代中的罐装人)、卡尔·罗许(三代中的Ceph首脑代理)和沃尔特·古德(二代古德博士的爷爷)秘密组织了一支探险队前往调查大爆炸的遗址,虽然具体过程不明,但结果最后只剩下上述三人生还。后来到了2020年的8月,因为陨石的缘故,深埋在灵山岛下的Ceph机械开始活动,同时朝鲜和美国开始纷纷向岛上派遣部队,随后因为朝鲜人民军的庆将军执意启动Ceph飞船,结果导致灵山岛的Ceph全部苏醒,并在顷刻间几乎将整个岛屿全部冰封,随后美 孤岛危机1 Ceph部队(5张) 国和朝鲜的军队被迫联合抗敌,但在Ceph的优势火力下节节败退,美国军队只好出动宪法号航母上全部的VTOL来撤离部队。随后,美军战斗机向灵山岛发射了一颗核弹,企图用核弹来歼灭整座岛上的Ceph,但因为Ceph拥有可以吸收外来能量并转化为自己能源的恐怖技术,核弹反而使Ceph机械部队更加强大,之后Ceph机械部队攻上了宪法号,在诺曼(一代男主)的反击下,消灭了Ceph Hunter 机甲和Ceph母舰,随后撤离航母,再次飞向灵山岛(救普费)。
收起全文
  • Ceph是一个可靠的、数据自动重均衡、自动恢复的SDS(软件定义存储)分布式存储系统,功能主要有三大块:块存储、对象存储、文件系统。 Ceph不但是提供了统一存储,并且同时还充分利用了客户端的计算能力,在...
  • Ceph基础篇

    2019-07-18 10:59:31
    本课程主要讲解了以下几个方面:首先讲解了 Ceph 存储和组件的介绍,让大家了解到有哪些功能以及使用的一些地方。随后讲解了 使用 ceph-deploy 怎么去部署一个多节点的Ceph 集群架构,最后又详细的介绍了Ceph的块...
  • 介绍分布式ceph自动化集群部署,以及企业生产环境中osd数据恢复案例,同时讲解了ceph自带的dashabord健康页面。
  • 1. Ceph架构简介及使用场景介绍1.1 Ceph简介Ceph是一个统一的分布式存储系统,设计初衷是提供较好的性能、可靠性和可扩展性。Ceph项目最早起源于Sage就读...
        

    1. Ceph架构简介及使用场景介绍


    1.1 Ceph简介


    Ceph是一个统一的分布式存储系统,设计初衷是提供较好的性能、可靠性和可扩展性。


    Ceph项目最早起源于Sage就读博士期间的工作(最早的成果于2004年发表),并随后贡献给开源社区。在经过了数年的发展之后,目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。


    1.2 Ceph特点


    • 高性能
      a. 摒弃了传统的集中式存储元数据寻址的方案,采用CRUSH算法,数据分布均衡,并行度高。
      b.考虑了容灾域的隔离,能够实现各类负载的副本放置规则,例如跨机房、机架感知等。
      c. 能够支持上千个存储节点的规模,支持TB到PB级的数据。


    • 高可用性
      a. 副本数可以灵活控制。
      b. 支持故障域分隔,数据强一致性。
      c. 多种故障场景自动进行修复自愈。
      d. 没有单点故障,自动管理。


    • 高可扩展性
      a. 去中心化。
      b. 扩展灵活。
      c. 随着节点增加而线性增长。


    • 特性丰富
      a. 支持三种存储接口:块存储、文件存储、对象存储。
      b. 支持自定义接口,支持多种语言驱动。


    1.3 Ceph架构


    支持三种接口:


    • Object:有原生的API,而且也兼容Swift和S3的API。

    • Block:支持精简配置、快照、克隆。

    • File:Posix接口,支持快照。


      640?wx_fmt=png

      rados


    1.4 Ceph核心组件及概念介绍


    • Monitor
      一个Ceph集群需要多个Monitor组成的小集群,它们通过Paxos同步数据,用来保存OSD的元数据。


    • OSD
      OSD全称Object Storage Device,也就是负责响应客户端请求返回具体数据的进程。一个Ceph集群一般都有很多个OSD。


    • MDS
      MDS全称Ceph Metadata Server,是CephFS服务依赖的元数据服务。


    • Object
      Ceph最底层的存储单元是Object对象,每个Object包含元数据和原始数据。


    • PG
      PG全称Placement Grouops,是一个逻辑的概念,一个PG包含多个OSD。引入PG这一层其实是为了更好的分配数据和定位数据。


    • RADOS
      RADOS全称Reliable Autonomic Distributed Object Store,是Ceph集群的精华,用户实现数据分配、Failover等集群操作。


    • Libradio
      Librados是Rados提供库,因为RADOS是协议很难直接访问,因此上层的RBD、RGW和CephFS都是通过librados访问的,目前提供PHP、Ruby、Java、Python、C和C++支持。


    • CRUSH
      CRUSH是Ceph使用的数据分布算法,类似一致性哈希,让数据分配到预期的地方。


    • RBD
      RBD全称RADOS block device,是Ceph对外提供的块设备服务。


    • RGW
      RGW全称RADOS gateway,是Ceph对外提供的对象存储服务,接口与S3和Swift兼容。


    • CephFS
      CephFS全称Ceph File System,是Ceph对外提供的文件系统服务。


    1.5 三种存储类型-块存储

    640?wx_fmt=png

    rbd


    典型设备: 磁盘阵列,硬盘


    主要是将裸磁盘空间映射给主机使用的。


    优点


    • 通过Raid与LVM等手段,对数据提供了保护。

    • 多块廉价的硬盘组合起来,提高容量。

    • 多块磁盘组合出来的逻辑盘,提升读写效率。


    缺点


    • 采用SAN架构组网时,光纤交换机,造价成本高。

    • 主机之间无法共享数据。


    使用场景


    • docker容器、虚拟机磁盘存储分配。

    • 日志存储。

    • 文件存储。


    1.6 三种存储类型-文件存储


    640?wx_fmt=png

    fs


    典型设备: FTP、NFS服务器


    为了克服块存储文件无法共享的问题,所以有了文件存储。


    在服务器上架设FTP与NFS服务,就是文件存储。


    优点


    • 造价低,随便一台机器就可以了。

    • 方便文件共享。


    缺点


    • 读写速率低。

    • 传输速率慢。


    使用场景


    • 日志存储。

    • 有目录结构的文件存储。


    1.7 三种存储类型-对象存储


    640?wx_fmt=png

    rgw


    典型设备: 内置大容量硬盘的分布式服务器(swift, s3)


    多台服务器内置大容量硬盘,安装上对象存储管理软件,对外提供读写访问功能。


    优点


    • 具备块存储的读写高速。

    • 具备文件存储的共享等特性。


    使用场景: (适合更新变动较少的数据)


    • 图片存储。

    • 视频存储。


    2. Ceph IO流程及数据分布


    640?wx_fmt=png

    rados_io_1


    2.1 正常IO流程图


    640?wx_fmt=png

    ceph_io_2


    步骤


    1. client 创建cluster handler。

    2. client 读取配置文件。

    3. client 连接上monitor,获取集群map信息。

    4. client 读写io 根据crshmap 算法请求对应的主osd数据节点。

    5. 主osd数据节点同时写入另外两个副本节点数据。

    6. 等待主节点以及另外两个副本节点写完数据状态。

    7. 主节点及副本节点写入状态都成功后,返回给client,io写入完成。


    2.2 新主IO流程图


    说明


    如果新加入的OSD1取代了原有的 OSD4成为 Primary OSD, 由于 OSD1 上未创建 PG , 不存在数据,那么 PG 上的 I/O 无法进行,怎样工作的呢?


    640?wx_fmt=png

    ceph_io_3


    步骤


    1. client连接monitor获取集群map信息。

    2. 同时新主osd1由于没有pg数据会主动上报monitor告知让osd2临时接替为主。

    3. 临时主osd2会把数据全量同步给新主osd1。

    4. client IO读写直接连接临时主osd2进行读写。

    5. osd2收到读写io,同时写入另外两副本节点。

    6. 等待osd2以及另外两副本写入成功。

    7. osd2三份数据都写入成功返回给client, 此时client io读写完毕。

    8. 如果osd1数据同步完毕,临时主osd2会交出主角色。

    9. osd1成为主节点,osd2变成副本。


    2.3 Ceph IO算法流程

    640?wx_fmt=png

    ceph_io_4


    1. File用户需要读写的文件。File->Object映射:


    a. ino (File的元数据,File的唯一id)。
    b. ono(File切分产生的某个object的序号,默认以4M切分一个块大小)。
    c. oid(object id: ino + ono)。


    2. Object是RADOS需要的对象。Ceph指定一个静态hash函数计算oid的值,将oid映射成一个近似均匀分布的伪随机值,然后和mask按位相与,得到pgid。Object->PG映射:


    a. hash(oid) & mask-> pgid 。
    b. mask = PG总数m(m为2的整数幂)-1 。


    3. PG(Placement Group),用途是对object的存储进行组织和位置映射, (类似于redis cluster里面的slot的概念) 一个PG里面会有很多object。采用CRUSH算法,将pgid代入其中,然后得到一组OSD。PG->OSD映射:


    a. CRUSH(pgid)->(osd1,osd2,osd3) 。


    2.4 Ceph IO伪代码流程


    locator = object_name
    obj_hash =  hash(locator)
    pg = obj_hash % num_pg
    osds_for_pg = crush(pg)    # returns a list of osdsprimary = osds_for_pg[0]
    replicas = osds_for_pg[1:]


    2.5 Ceph RBD IO流程


    640?wx_fmt=png

    ceph_rbd_io


    步骤


    1. 客户端创建一个pool,需要为这个pool指定pg的数量。


    2. 创建pool/image rbd设备进行挂载。


    3. 用户写入的数据进行切块,每个块的大小默认为4M,并且每个块都有一个名字,名字就是object+序号。


    4. 将每个object通过pg进行副本位置的分配。


    5. pg根据cursh算法会寻找3个osd,把这个object分别保存在这三个osd上。


    6. osd上实际是把底层的disk进行了格式化操作,一般部署工具会将它格式化为xfs文件系统。


    7. object的存储就变成了存储一个文rbd0.object1.file。


    2.6 Ceph RBD IO框架图


    640?wx_fmt=png

    ceph_rbd_io1


    客户端写数据osd过程


    1. 采用的是librbd的形式,使用librbd创建一个块设备,向这个块设备中写入数据。


    2. 在客户端本地同过调用librados接口,然后经过pool,rbd,object、pg进行层层映射,在PG这一层中,可以知道数据保存在哪3个OSD上,这3个OSD分为主从的关系。


    3. 客户端与primay OSD建立SOCKET 通信,将要写入的数据传给primary OSD,由primary OSD再将数据发送给其他replica OSD数据节点。


    2.7 Ceph Pool和PG分布情况


    640?wx_fmt=png

    ceph_pool_pg


    说明


    • pool是ceph存储数据时的逻辑分区,它起到namespace的作用。

    • 每个pool包含一定数量(可配置)的PG。

    • PG里的对象被映射到不同的Object上。

    • pool是分布到整个集群的。

    • pool可以做故障隔离域,根据不同的用户场景不一进行隔离。


    2.8 Ceph 数据扩容PG分布


    场景数据迁移流程


    • 现状3个OSD, 4个PG

    • 扩容到4个OSD, 4个PG


    现状


    640?wx_fmt=png

    ceph_recory_1


    扩容后


    640?wx_fmt=png

    ceph_io_recry2


    说明


    每个OSD上分布很多PG, 并且每个PG会自动散落在不同的OSD上。如果扩容那么相应的PG会进行迁移到新的OSD上,保证PG数量的均衡。


    3. Ceph心跳机制


    3.1 心跳介绍


    心跳是用于节点间检测对方是否故障的,以便及时发现故障节点进入相应的故障处理流程。


    问题


    • 故障检测时间和心跳报文带来的负载之间做权衡。

    • 心跳频率太高则过多的心跳报文会影响系统性能。

    • 心跳频率过低则会延长发现故障节点的时间,从而影响系统的可用性。


    故障检测策略应该能够做到


    • 及时:节点发生异常如宕机或网络中断时,集群可以在可接受的时间范围内感知。

    • 适当的压力:包括对节点的压力,和对网络的压力。

    • 容忍网络抖动:网络偶尔延迟。

    • 扩散机制:节点存活状态改变导致的元信息变化需要通过某种机制扩散到整个集群。


    3.2 Ceph 心跳检测


    640?wx_fmt=png

    ceph_heartbeat_1


    OSD节点会监听public、cluster、front和back四个端口


    • public端口:监听来自Monitor和Client的连接。

    • cluster端口:监听来自OSD Peer的连接。

    • front端口:供客户端连接集群使用的网卡, 这里临时给集群内部之间进行心跳。

    • back端口:供客集群内部使用的网卡。集群内部之间进行心跳。

    • hbclient:发送ping心跳的messenger。


    3.3 Ceph OSD之间相互心跳检测


    640?wx_fmt=png

    ceph_heartbeat_osd


    步骤


    • 同一个PG内OSD互相心跳,他们互相发送PING/PONG信息。

    • 每隔6s检测一次(实际会在这个基础上加一个随机时间来避免峰值)。

    • 20s没有检测到心跳回复,加入failure队列。


    3.4 Ceph OSD与Mon心跳检测


    640?wx_fmt=png

    ceph_heartbeat_mon


    OSD报告给Monitor:


    • OSD有事件发生时(比如故障、PG变更)。

    • 自身启动5秒内。

    • OSD周期性的上报给Monito

      • OSD检查failure_queue中的伙伴OSD失败信息。

      • 向Monitor发送失效报告,并将失败信息加入failure_pending队列,然后将其从failure_queue移除。

      • 收到来自failure_queue或者failure_pending中的OSD的心跳时,将其从两个队列中移除,并告知Monitor取消之前的失效报告。

      • 当发生与Monitor网络重连时,会将failure_pending中的错误报告加回到failure_queue中,并再次发送给Monitor。

    • Monitor统计下线OSD

      • Monitor收集来自OSD的伙伴失效报告。

      • 当错误报告指向的OSD失效超过一定阈值,且有足够多的OSD报告其失效时,将该OSD下线。


    3.5 Ceph心跳检测总结


    Ceph通过伙伴OSD汇报失效节点和Monitor统计来自OSD的心跳两种方式判定OSD节点失效。


    • 及时:伙伴OSD可以在秒级发现节点失效并汇报Monitor,并在几分钟内由Monitor将失效OSD下线。


    • 适当的压力:由于有伙伴OSD汇报机制,Monitor与OSD之间的心跳统计更像是一种保险措施,因此OSD向Monitor发送心跳的间隔可以长达600秒,Monitor的检测阈值也可以长达900秒。Ceph实际上是将故障检测过程中中心节点的压力分散到所有的OSD上,以此提高中心节点Monitor的可靠性,进而提高整个集群的可扩展性。


    • 容忍网络抖动:Monitor收到OSD对其伙伴OSD的汇报后,并没有马上将目标OSD下线,而是周期性的等待几个条件:

      • 目标OSD的失效时间大于通过固定量osd_heartbeat_grace和历史网络条件动态确定的阈值。

      • 来自不同主机的汇报达到mon_osd_min_down_reporters。

      • 满足前两个条件前失效汇报没有被源OSD取消。


    • 扩散:作为中心节点的Monitor并没有在更新OSDMap后尝试广播通知所有的OSD和Client,而是惰性的等待OSD和Client来获取。以此来减少Monitor压力并简化交互逻辑。


    4. Ceph通信框架


    4.1 Ceph通信框架种类介绍


    网络通信框架三种不同的实现方式:


    • Simple线程模式
      特点:每一个网络链接,都会创建两个线程,一个用于接收,一个用于发送。
      缺点:大量的链接会产生大量的线程,会消耗CPU资源,影响性能。

    • Async事件的I/O多路复用模式
      特点:这种是目前网络通信中广泛采用的方式。k版默认已经使用Asnyc了。

    • XIO方式使用了开源的网络通信库accelio来实现
      特点:这种方式需要依赖第三方的库accelio稳定性,目前处于试验阶段。


    4.2 Ceph通信框架设计模式


    设计模式(Subscribe/Publish):


    订阅发布模式又名观察者模式,它意图是“定义对象间的一种一对多的依赖关系,
    当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新”。


    4.3 Ceph通信框架流程图


    640?wx_fmt=png

    ceph_message


    步骤


    • Accepter监听peer的请求, 调用 SimpleMessenger::add_accept_pipe() 创建新的 Pipe 到 SimpleMessenger::pipes 来处理该请求。


    • Pipe用于消息的读取和发送。该类主要有两个组件,Pipe::Reader,Pipe::Writer用来处理消息读取和发送。


    • Messenger作为消息的发布者, 各个 Dispatcher 子类作为消息的订阅者, Messenger 收到消息之后,  通过 Pipe 读取消息,然后转给 Dispatcher 处理。


    • Dispatcher是订阅者的基类,具体的订阅后端继承该类,初始化的时候通过 Messenger::add_dispatcher_tail/head 注册到 Messenger::dispatchers. 收到消息后,通知该类处理。


    • DispatchQueue该类用来缓存收到的消息, 然后唤醒 DispatchQueue::dispatch_thread 线程找到后端的 Dispatch 处理消息。


    640?wx_fmt=png

    ceph_message_2


    4.4 Ceph通信框架类图


    640?wx_fmt=png

    ceph_message_3


    4.5 Ceph通信数据格式


    通信协议格式需要双方约定数据格式。


    消息的内容主要分为三部分:


    • header              //消息头,类型消息的信封

    • user data          //需要发送的实际数据

      • payload     //操作保存元数据

      • middle      //预留字段

      • data          //读写数据

    • footer             //消息的结束标记

    class Message : public RefCountedObject {
    protected:
      ceph_msg_header  header;      // 消息头
      ceph_msg_footer  footer;      // 消息尾
      bufferlist       payload;  // "front" unaligned blob
      bufferlist       middle;   // "middle" unaligned blob
      bufferlist       data;     // data payload (page-alignment will be preserved where possible)

      /* recv_stamp is set when the Messenger starts reading the
       * Message off the wire */

      utime_t recv_stamp;       //开始接收数据的时间戳
      /* dispatch_stamp is set when the Messenger starts calling dispatch() on
       * its endpoints */

      utime_t dispatch_stamp;   //dispatch 的时间戳
      /* throttle_stamp is the point at which we got throttle */
      utime_t throttle_stamp;   //获取throttle 的slot的时间戳
      /* time at which message was fully read */
      utime_t recv_complete_stamp;  //接收完成的时间戳

      ConnectionRef connection;     //网络连接

      uint32_t magic = 0;           //消息的魔术字

      bi::list_member_hook<> dispatch_q;    //boost::intrusive 成员字段
    };

    struct ceph_msg_header {
        __le64 seq;       // 当前session内 消息的唯一 序号
        __le64 tid;       // 消息的全局唯一的 id
        __le16 type;      // 消息类型
        __le16 priority;  // 优先级
        __le16 version;   // 版本号

        __le32 front_len; // payload 的长度
        __le32 middle_len;// middle 的长度
        __le32 data_len;  // data 的 长度
        __le16 data_off;  // 对象的数据偏移量


        struct ceph_entity_name src; //消息源

        /* oldest code we think can decode this.  unknown if zero. */
        __le16 compat_version;
        __le16 reserved;
        __le32 crc;       /* header crc32c */
    } __attribute__ ((packed));

    struct ceph_msg_footer {
        __le32 front_crc, middle_crc, data_crc; //crc校验码
        __le64  sig; //消息的64位signature
        __u8 flags; //结束标志
    } __attribute__ ((packed));


    5. Ceph CRUSH算法


    5.1 数据分布算法挑战


    • 数据分布和负载均衡:
      a. 数据分布均衡,使数据能均匀的分布到各个节点上。
      b. 负载均衡,使数据访问读写操作的负载在各个节点和磁盘的负载均衡。


    • 灵活应对集群伸缩
      a. 系统可以方便的增加或者删除节点设备,并且对节点失效进行处理。
      b. 增加或者删除节点设备后,能自动实现数据的均衡,并且尽可能少的迁移数据。


    • 支持大规模集群
      a. 要求数据分布算法维护的元数据相对较小,并且计算量不能太大。随着集群规模的增 加,数据分布算法开销相对比较小。


    5.2 Ceph CRUSH算法说明


    • CRUSH算法的全称为:Controlled Scalable Decentralized Placement of Replicated Data,可控的、可扩展的、分布式的副本数据放置算法。


    • pg到OSD的映射的过程算法叫做CRUSH 算法。(一个Object需要保存三个副本,也就是需要保存在三个osd上)。


    • CRUSH算法是一个伪随机的过程,他可以从所有的OSD中,随机性选择一个OSD集合,但是同一个PG每次随机选择的结果是不变的,也就是映射的OSD集合是固定的。


    5.3 Ceph CRUSH算法原理


    CRUSH算法因子:


    • 层次化的Cluster Map
      反映了存储系统层级的物理拓扑结构。定义了OSD集群具有层级关系的 静态拓扑结构。OSD层级使得 CRUSH算法在选择OSD时实现了机架感知能力,也就是通过规则定义, 使得副本可以分布在不同的机 架、不同的机房中、提供数据的安全性 。


    • Placement Rules
      决定了一个PG的对象副本如何选择的规则,通过这些可以自己设定规则,用户可以自定义设置副本在集群中的分布。


    5.3.1 层级化的Cluster Map


    640?wx_fmt=png

    ceph_crush


    CRUSH Map是一个树形结构,OSDMap更多记录的是OSDMap的属性(epoch/fsid/pool信息以及osd的ip等等)。


    叶子节点是device(也就是osd),其他的节点称为bucket节点,这些bucket都是虚构的节点,可以根据物理结构进行抽象,当然树形结构只有一个最终的根节点称之为root节点,中间虚拟的bucket节点可以是数据中心抽象、机房抽象、机架抽象、主机抽象等。


    5.3.2 数据分布策略Placement Rules


    数据分布策略Placement Rules主要有特点


    a. 从CRUSH Map中的哪个节点开始查找
    b. 使用那个节点作为故障隔离域
    c. 定位副本的搜索模式(广度优先 or 深度优先)

    rule replicated_ruleset  #规则集的命名,创建pool时可以指定rule集
    {
        ruleset 0                #rules集的编号,顺序编即可   
        type replicated          #定义pool类型为replicated(还有erasure模式)   
        min_size 1                #pool中最小指定的副本数量不能小1
        max_size 10               #pool中最大指定的副本数量不能大于10       
        step take default         #查找bucket入口点,一般是root类型的bucket    
        step chooseleaf  firstn  0  type  host #选择一个host,并递归选择叶子节点osd     
        step emit        #结束
    }


    5.3.3 Bucket随机算法类型

    640?wx_fmt=png

    ceph_bucket


    • 一般的buckets:适合所有子节点权重相同,而且很少添加删除item。


    • list buckets:适用于集群扩展类型。增加item,产生最优的数据移动,查找item,时间复杂度O(n)。


    • tree buckets:查找负责度是O (log n), 添加删除叶子节点时,其他节点node_id不变。


    • straw buckets:允许所有项通过类似抽签的方式来与其他项公平“竞争”。定位副本时,bucket中的每一项都对应一个随机长度的straw,且拥有最长长度的straw会获得胜利(被选中),添加或者重新计算,子树之间的数据移动提供最优的解决方案。


    5.4 CRUSH算法案例


    说明


    集群中有部分sas和ssd磁盘,现在有个业务线性能及可用性优先级高于其他业务线,能否让这个高优业务线的数据都存放在ssd磁盘上。


    普通用户


    640?wx_fmt=png

    ceph_sas.png


    高优用户


    640?wx_fmt=png

    ssd


    配置规则


    640?wx_fmt=png

    ceph_crush1


    6. 定制化Ceph RBD QOS


    6.1 QOS介绍


    QoS (Quality of Service,服务质量)起源于网络技术,它用来解决网络延迟和阻塞等问题,能够为指定的网络通信提供更好的服务能力。


    问题


    我们总的Ceph集群的iIO能力是有限的,比如带宽,IOPS。如何避免用户争取资源,如果保证集群所有用户资源的高可用性,以及如何保证高优用户资源的可用性。所以我们需要把有限的IO能力合理分配。


    6.2 Ceph IO操作类型


    • ClientOp:来自客户端的读写I/O请求。


    • SubOp:osd之间的I/O请求。主要包括由客户端I/O产生的副本间数据读写请求,以及由数据同步、数据扫描、负载均衡等引起的I/O请求。


    • SnapTrim:快照数据删除。从客户端发送快照删除命令后,删除相关元数据便直接返回,之后由后台线程删除真实的快照数据。通过控制snaptrim的速率间接控制删除速率。


    • Scrub:用于发现对象的静默数据错误,扫描元数据的Scrub和对象整体扫描的deep Scrub。


    • Recovery:数据恢复和迁移。集群扩/缩容、osd失效/从新加入等过程。


    6.3 Ceph 官方QOS原理


    640?wx_fmt=png

    ceph_mclok_qos


    mClock是一种基于时间标签的I/O调度算法,最先被Vmware提出来的用于集中式管理的存储系统。(目前官方QOS模块属于半成品)。


    基本思想:


    • reservation 预留,表示客户端获得的最低I/O资源。

    • weight 权重,表示客户端所占共享I/O资源的比重。

    • limit 上限,表示客户端可获得的最高I/O资源。


    6.4 定制化QOS原理


    6.4.1 令牌桶算法介绍


    640?wx_fmt=png

    ceph_token_qos


    基于令牌桶算法(TokenBucket)实现了一套简单有效的qos功能,满足了云平台用户的核心需求。


    基本思想


    • 按特定的速率向令牌桶投放令牌。


    • 根据预设的匹配规则先对报文进行分类,不符合匹配规则的报文不需要经过令牌桶的处理,直接发送。


    • 符合匹配规则的报文,则需要令牌桶进行处理。当桶中有足够的令牌则报文可以被继续发送下去,同时令牌桶中的令牌量按报文的长度做相应的减少。


    • 当令牌桶中的令牌不足时,报文将不能被发送,只有等到桶中生成了新的令牌,报文才可以发送。这就可以限制报文的流量只能是小于等于令牌生成的速度,达到限制流量的目的。


    6.4.2 RBD令牌桶算法流程


    640?wx_fmt=png

    ceph_token1


    步骤


    • 用户发起请求异步IO到达Image中。

    • 请求到达ImageRequestWQ队列中。

    • 在ImageRequestWQ出队列的时候加入令牌桶算法TokenBucket。

    • 通过令牌桶算法进行限速,然后发送给ImageRequest进行处理。


    6.4.3 RBD令牌桶算法框架图


    现有框架图:


    640?wx_fmt=png

    ceph_qos2


    令牌图算法框架图:


    640?wx_fmt=png

    ceph_qos_token2


    作者:李航,多年的底层开发经验,在高性能nginx开发和分布式缓存redis cluster有着丰富的经验,目前从事Ceph工作两年左右。先后在58同城、汽车之家、优酷土豆集团工作。 目前供职于滴滴基础平台运维部 负责分布式Ceph集群开发及运维等工作。个人主要关注的技术领域:高性能Nginx开发、分布式缓存、分布式存储。


    出处:https://www.jianshu.com/p/cc3ece850433


    版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢。


    640?wx_fmt=png

    架构文摘

    ID:ArchDigest

    互联网应用架构丨架构技术丨大型网站丨大数据丨机器学习

    640?wx_fmt=jpeg

    更多精彩文章,请点击下方:阅读原文

    展开全文
  • 介绍分布式ceph自动化集群部署,以及企业生产环境中osd数据恢复案例,同时讲解了ceph自带的dashabord健康页面。
  • Ceph

    2020-03-13 11:24:52
    Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。其命名和UCSC(Ceph 的诞生地)的吉祥物有关,这个吉祥物是 "Sammy",一个香蕉色的蛞蝓,就是头足类中无壳的软体动物。这些有多触角的头足...

    Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。其命名和UCSC(Ceph 的诞生地)的吉祥物有关,这个吉祥物是 "Sammy",一个香蕉色的蛞蝓,就是头足类中无壳的软体动物。这些有多触角的头足类动物,是对一个分布式文件系统高度并行的形象比喻。

    Ceph 生态系统架构可以划分为四部分:

    1. Clients:客户端(数据用户)

    2. cmds:Metadata server cluster,元数据服务器(缓存和同步分布式元数据)

    3. cosd:Object storage cluster,对象存储集群(将数据和元数据作为对象存储,执行其他关键职能)

    4. cmon:Cluster monitors,集群监视器(执行监视功能)

    作为分布式文件系统,其能够在维护 POSIX 兼容性的同时加入了复制和容错功能。从 2010 年 3 月底,可以在Linux 内核(从2.6.34版开始)中找到 Ceph 的身影,作为Linux的文件系统备选之一,Ceph.ko已经集成入Linux内核之中。虽然目前Ceph 可能还不适用于生产环境,但它对测试目的还是非常有用的。

    Ceph 不仅仅是一个文件系统,还是一个有企业级功能的对象存储生态环境。

    现在,Ceph已经被集成在主线 Linux 内核中,但只是被标识为实验性的。在这种状态下的文件系统对测试是有用的,但是对生产环境没有做好准备。但是考虑到Ceph 加入到 Linux 内核的行列,不久的将来,它应该就能用于解决海量存储的需要了。

    一些开源的云计算项目已经开始支持Ceph,事实上Ceph是目前OpenStack生态系统中呼声最高的开源存储解决方案。这些项目都支持通过libvirt调用Ceph作为块设备进行读写访问。

    展开全文
  • 第五篇: Ceph集群运维

    2019-08-05 22:32:07
    本部分介绍了 Ceph 集群的常用操作,包括进程的起停、集群的监控、用户管理、MDS/MON/OSD 的增加和删除、存储池(pool)的操作、修改集群的配置,以及 Crushmap 的管理、修改 Monitor 的 IP 等操作。 1 MDS增删 1.1 ...

    常用操作

    本部分介绍了 Ceph 集群的常用操作,包括进程的起停、集群的监控、用户管理、MDS/MON/OSD 的增加和删除、存储池(pool)的操作、修改集群的配置,以及 Crushmap 的管理、修改 Monitor 的 IP 等操作。

    1 MDS增删

    1.1 新增元数据服务器(metadata server)

    1. 创建一个存储mds的数据节点:/var/lib/ceph/mds/ceph-{$id},id表示元数据服务器的名称,可根据需求自行定义。

      例如:

      sudo mkdir /var/lib/ceph/mds/ceph-`hostname`
      sudo chown ceph:ceph -R /var/lib/ceph/mds/ceph-`hostname`
      
    2. 修改ceph.conf,增加MDS

      [mds.{$id}]
      host = {hostname}
      

      例如:

      [mds.ceph-1]
      host = ceph-1
      
    3. 如果使用了CephX验证,则创建验证密钥;否则调过此步骤

      sudo ceph auth get-or-create mds.{$id} mon 'profile mds' mgr 'profile mds' mds 'allow *' osd 'allow *' > /var/lib/ceph/mds/ceph-{$id}/keyring
      
    4. 启动mds服务

      sudo cp /usr/lib/systemd/system/ceph-mds@.service /usr/lib/systemd/system/ceph-mds@`hostname`.service 
      sudo systemctl start ceph-mds@`hostname`
      sudo systemctl enable ceph-mds@`hostname`
      
    5. 查看mds服务的状态

      ceph mds stat
      
      cephfs-1/1/1 up  {0=ceph-1=up:active}, 2 up:standby
      

    1.2 删除元数据服务器(metadata server)

    注意:在删除元数据服务器之前一定要确保有剩余的备选元数据服务器为ceph客户端提供服务。如果没有的话,那么需要先新增一个元数据服务器(安照上述方法),然后再进行删除。已确保cephfs服务能够正常被使用

    如果有备用的元数据服务器,则可以执行下述的删除操作:

    1. 停止元数据服务

      ceph mds fail <mds name>
      

      例如:

      ceph mds fail ceph-1
      
    2. 删除元数据服务的目录

      sudo rm -rf /var/lib/ceph/mds/ceph-{$id}
      

      例如:

      sudo rm -rf /var/lib/ceph/mds/ceph-ceph-1
      

    2 OSD增删

    2.1 新增osd(不增加新机器)

    2.1.1 创建osd进程相关的disk

    使用fdisk工具格式化磁盘,生成osd进程的磁盘以及journal磁盘

    sudo umount /disk3  #先将挂载在/dev/sde上的disk3 umount掉
    sudo fdisk /dev/sde
    
    WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
    Welcome to fdisk (util-linux 2.23.2).
    
    Changes will remain in memory only, until you decide to write them.
    Be careful before using the write command.
    
    
    Command (m for help): p(显示该磁盘的分区情况)
    Command (m for help): d(删除该磁盘的所有分区)
    Command (m for help): g(将磁盘的文件格式变成gpt)
    Command (m for help): n(创建新分区,创建两个,一个为journal(10G),一个为data)
    Command (m for help): w(保存退出)
    

    2.1.2 创建osd(step by step)

    2.1 添加一个新osd,id可以省略,ceph会自动使用最小可用整数,第一个osd从0开始
    ceph osd create {id}

    ceph osd create
    3
    

    2.2 初始化osd目录

    创建osd.3目录,目录名格式{cluster-name}-{id}
    mkdir /var/lib/ceph/osd/{cluster-name}-{id}

    sudo mkdir /var/lib/ceph/osd/ceph-3
    

    2.3 挂载osd.0的数据盘/dev/sde2

    sudo mkfs.xfs /dev/sdb2
    sudo mount /dev/sdc2 /var/lib/ceph/osd/ceph-3
    

    2.4 初始化osd数据目录

    
    sudo ceph-osd -i 3 --mkfs --mkkey
    --mkkey要求osd数据目录为空
    

    这会创建osd.0的keyring /var/lib/ceph/osd/ceph-0/keyring

    初始化后,默认使用普通文件/var/lib/ceph/osd/ceph-3/journal作为osd.3的journal分区,普通文件作为journal分区性能不高,若只是测试环境,可以跳过更改journal分区这一步骤

    2.5 创建journal

    生成journal分区,一般选ssd盘作为journal分区,这里使用ssd的/dev/sde1分区作为journal

    使用fdisk工分出磁盘/dev/sde1,

    sudo mkfs.xfs /dev/sde1
    sudo rm -f /var/lib/ceph/osd/ceph-3/journal 
    查看分区对应的partuuid, 找出/dev/sdb1对应的partuuid
    
    sudo blkid
    sudo ln -s /dev/disk/by-partuuid/b3897364-8807-48eb-9905-e2c8400d0cd4 /var/lib/ceph/osd/ceph-3/journal
    
    sudo chown ceph:ceph -R /var/lib/ceph/osd/ceph-3
    sudo chown ceph:ceph /var/lib/ceph/osd/ceph-3/journal
    sudo ceph-osd --mkjournal -i 3
    sudo chown ceph:ceph /var/lib/ceph/osd/ceph-3/journal
    

    2.6 注册osd.{id},id为osd编号,默认从0开始
    sudo ceph auth add osd.{id} osd ‘allow *’ mon ‘allow profile osd’ -i /var/lib/ceph/osd/ceph-{id}/keyring

    sudo ceph auth add osd.3 osd 'allow *' mon 'allow profile osd' -i /var/lib/ceph/osd/ceph-3/keyring
    

    2.7 加入crush map
    ceph osd crush add-bucket {hostname} host

    sudo ceph osd crush add-bucket `hostname` host
    

    2.8 然后把osd节点移动到默认的root default下面

    sudo ceph osd crush move `hostname` root=default
    

    2.9 添加osd.3到CRUSH map中的m1节点下面,加入后,osd.3就能够接收数据
    ceph osd crush add osd.{id} 0.4 root=sata rack=sata-rack01 host=sata-node5

    sudo ceph osd crush add osd.3 1.7 root=default host=`hostname`
    

    0.4为此osd在CRUSH map中的权重值,它表示数据落在此osd上的比重,是一个相对值,一般按照1T磁盘比重值为1来计算,这里的osd数据盘1.7,所以值为1.7

    此时osd.0状态是downinin表示此osd位于CRUSH map,已经准备好接受数据,down表示osd进程运行异常,因为我们还没有启动osd.0进程

    2.10 启动ceph-osd进程

    需要向systemctl传递osd的id以启动指定的osd进程,如下,我们准备启动osd.3进程
    systemctl start ceph-osd@{id} id表示osd编号,从数字0开始

    sudo cp /usr/lib/systemd/system/ceph-osd@.service /usr/lib/systemd/system/ceph-osd@3.service
    sudo systemctl start ceph-osd@3
    sudo systemctl enable ceph-osd@3
    

    上面就是添加osd.3的步骤,可以查看集群状态 ceph -s。

    2.2 新增osd(增加新机器)

    2.2.1 配置环境

    2.1 修改yum源

    这里将yum源修改成aliyun的源,指令如下:

    curl http://mirrors.aliyun.com/repo/Centos-7.repo >/etc/yum.repos.d/CentOS-Base.repo
    curl http://mirrors.aliyun.com/repo/epel-7.repo >/etc/yum.repos.d/epel.repo 
    sed -i '/aliyuncs/d' /etc/yum.repos.d/CentOS-Base.repo
    sed -i '/aliyuncs/d' /etc/yum.repos.d/epel.repo
    

    2.2 添加ceph源

    sudo vim /etc/yum.repos.d/ceph.repo
    
    [ceph]
    name=ceph
    baseurl=http://mirrors.aliyun.com/ceph/rpm-luminous/el7/x86_64/
    gpgcheck=0
    [ceph-noarch]
    name=cephnoarch
    baseurl=http://mirrors.aliyun.com/ceph/rpm-luminous/el7/noarch/
    gpgcheck=0
    [ceph-source]
    name=ceph-source
    baseurl=http://mirrors.aliyun.com/ceph/rpm-luminous/el7/SRPMS/
    gpgcheck=0
    

    2.3 安装软件

    sudo yum install ceph ntp ntpdate ntp-doc openssh-server
    

    验证ceph是否正确安装

    ceph -v
    ceph version 12.2.10 (177915764b752804194937482a39e95e0ca3de94) luminous (stable)
    

    2.4 关闭防火墙

    sudo sed -i 's/SELINUX=.*/SELINUX=disabled/' /etc/selinux/config
    sudo setenforce 0
    sudo systemctl stop firewalld 
    sudo systemctl disable firewalld
    

    2.2.2 新建osd(同步骤2.1)

    2.3 删除osd

    要想缩减集群尺寸或替换硬件,可在运行时删除 OSD 。在 Ceph 里,一个 OSD 通常是一台主机上的一个 ceph-osd 守护进程、它运行在一个硬盘之上。如果一台主机上有多个数据盘,你得逐个删除其对应 ceph-osd 。通常,操作前应该检查集群容量,看是否快达到上限了,确保删除 OSD 后不会使集群达到 near full 比率。

    警告: 删除 OSD 时不要让集群达到 full ratio 值,删除 OSD 可能导致集群达到或超过 full ratio值。

    1、停止需要剔除的 OSD 进程,让其他的 OSD 知道这个 OSD 不提供服务了。停止 OSD 后,状态变为 down

    ssh {osd-host}
    sudo stop ceph-osd id={osd-num}
    

    2、将 OSD 标记为 out 状态,这个一步是告诉 mon,这个 OSD 已经不能服务了,需要在其他的 OSD 上进行数据的均衡和恢复了。

    sudo ceph osd out {osd-num}
    

    执行完这一步后,会触发数据的恢复过程。此时应该等待数据恢复结束,集群恢复到 HEALTH_OK 状态,再进行下一步操作。

    3、删除 CRUSH Map 中的对应 OSD 条目,它就不再接收数据了。你也可以反编译 CRUSH Map、删除 device 列表条目、删除对应的 host 桶条目或删除 host 桶(如果它在 CRUSH Map 里,而且你想删除主机),重编译 CRUSH Map 并应用它。

    sudo ceph osd crush remove osd.{osd-num}
    

    该步骤会触发数据的重新分布。等待数据重新分布结束,整个集群会恢复到 HEALTH_OK 状态。

    4、删除 OSD 认证密钥:

    ceph auth del osd.{osd-num}
    

    5、删除 OSD 。
    ceph osd rm {osd-num}

    ceph osd rm 1
    

    6、卸载 OSD 的挂载点。

    sudo umount /var/lib/ceph/osd/$cluster-{osd-num}
    

    7、登录到保存 ceph.conf 主拷贝的主机。

    ssh {admin-host}
    cd /etc/ceph
    vim ceph.conf
    

    8、从 ceph.conf 配置文件里删除对应条目。

    [osd.1]
    host = {hostname}
    

    9、从保存 ceph.conf 主拷贝的主机,把更新过的 ceph.conf 拷贝到集群其他主机的 /etc/ceph 目录下。

    如果在 ceph.conf 中没有定义各 OSD 入口,就不必执行第 7 ~ 9 步。

    所有的osd节点下线删除之后:
    ceph osd crush remove {hostname} 将主机条目从crush map中删除
    ceph -s 等待集群变为active+clean状态

    3 MON增删

    3.1 增加MON节点

    在ceph.conf文件中增加mon节点信息

    mon initial members = hostname1,hostname2,new_mon_hostname
    mon host = IP1,IP2,new_mon_ip
    

    创建mon进程

    host_name=`hostname`
    sudo ceph mon getmap -o /tmp/monmap
    sudo rm -rf /var/lib/ceph/mon/ceph-$host_name
    sudo ceph-mon -i $host_name --mkfs --monmap /tmp/monmap
    sudo chown -R ceph:ceph /var/lib/ceph/mon/ceph-$host_name/
    

    启动mon进程

    sudo cp /usr/lib/systemd/system/ceph-mon@.service /usr/lib/systemd/system/ceph-mon@$host_name.service
    sudo systemctl start ceph-mon@$host_name
    sudo systemctl enable ceph-mon@$host_name
    

    4 客户端挂载

    4.1 kernel client挂载

    • 挂载之前需要下载安装ceph-common
    sudo yum install ceph-common
    
    • 挂载命令如下:
    mount -t ceph <monitor1-host-name>:6789,<monitor2-host-name>:6789,<monitor3-host-name>:6789:/ <mount-point>
    

    Example:

    sudo mkdir -p /gruntdata/lipeibao_ceph
    sudo mount -t ceph 11.188.199.210:6789:/ /mnt/mycephfs
    

    4.2 ceph-fuse挂载

    • 挂载之前需要下载安装ceph-common,ceph-fuse
    sudo yum install ceph-common ceph-fuse
    
    • 将monitor上的ceph配置文件拷贝到该客户端

    Example:

    sudo vim /etc/ceph/ceph.conf
    [global]
    fsid = $genuuid
    mon initial members = hostname1
    mon host = IP1,IP2,IP3
    rbd default features = 1
    auth_cluster_required = none
    auth_service_required = none
    auth_client_required = none
    public network = 11.165.0.0/16
    cluster network = 11.165.0.0/16
    osd journal size = 1024
    osd pool default size = 2 
    osd pool default min size = 1
    osd pool default pg num = 1000 
    osd pool default pgp num = 1000
    osd crush chooseleaf type = 1
    mon_max_pg_per_osd = 200
    
    [mon]
    mon allow pool delete = true
    
    [mds.hostname1]
    host = hostname1
    
    • 在管理机或者monitor机器上创建客户端用户及权限、密钥

      ceph auth get-or-create client.<client-name/id> mon 'allow r' mds 'allow r, allow rw path=<directory>' osd 'allow rw pool=<pool>' -o <file_name>
      
      1. client.<client-name/id>:用于指定客户端的名称或者id
      2. mon ‘allow r’: 指定客户端访问mon的权限,只读
      3. mds ‘allow r, allow rw path=’: 指定客户端访问mds的权限,只读,并指定读写的路径
      4. osd ‘allow rw pool=’: 指定客户端访问osdd权限,读写,并指定读写的pool
      5. <file_name>: 客户端的配置信息存放文件

      Example:

      $ ceph auth get-or-create client.1 mon 'allow r' mds 'allow r, allow rw path=/' osd 'allow rw pool=data' -o ceph.client.1.keyring
      [client.1]
      	key = AQACNoZXhrzqIRAABPKHTach4x03JeNadeQ9Uw==
      

    5 客户端剔除

    登录主mds服务器, 查看所有连接的客户端信息:

    sudo ceph daemon mds.`hostname` session ls 
    

    找到需要剔除的客户端id,然后执行下述命令:

    sudo ceph tell mds.`hostname` client evict id=客户端id
    

    这是客户端地址会存在blcaklist中,如果要重新挂载,需要将其从blacklist中删除:

    sudo ceph osd blcaklist ls
    

    删除对应的address

    sudo ceph osd blacklist rm address
    

    6 ceph集群参数调整

    6.1 pool 参数的查看

    1. 查看指定pool的相关参数
    ceph osd pool get {pool_name} pg_num 
    
    1. 设置指定pool的相关参
      set 操作需要慎重,否则会影响集群的服务
    ceph osd pool set {pool_name} pg_num 1024
    

    7 osd集群数据balance处理

    7.1 balancer 插件

    ceph集群在使用过程中,经常会遇到osd存储分布不均衡的情况,如下图是我们线上ceph集群的osd分布情况:
    可参考:https://docs.ceph.com/docs/mimic/mgr/balancer/
    具体操作如下:
    checklist:
    ** 1. all buckets should use straw2:**

    ceph osd getcrushmap -o crush.map; crushtool -d crush.map | grep straw; rm -f crush.map
    253
    tunable straw_calc_version 1
      alg straw2
      alg straw2
      alg straw2
      alg straw2
      alg straw2
      alg straw2
      alg straw2
      alg straw2
      alg straw2
      alg straw2
      alg straw2
      alg straw2
      alg straw2
      alg straw2
      alg straw2
      alg straw2
      alg straw2
    

    如果存在非straw2,update

    ceph osd crush set-all-straw-buckets-to-straw2
    

    2. minimum client version is jewel or higher:

    ceph osd dump|grep require_min_compat_client;
      require_min_compat_client jewel
    

    Ceph distribution balancer:
    Activate balancing:

    ceph mgr module ls
    ceph mgr module enable balancer
    ceph balancer on
    ceph balancer mode crush-compat
    ceph config-key set "mgr/balancer/max_misplaced": "0.01"
    

    Show configuration and state:

    ceph config-key dump
    ceph balancer status
    
    展开全文
  • CEPH简介

    2019-09-30 15:02:10
    无论您是要向Cloud Platform提供Ceph对象存储和/或Ceph块设备服务,部署Ceph文件系统还是将Ceph用于其他目的,所有Ceph Storage Cluster部署都首先要设置每个Ceph节点,您的网络和Ceph。存储集群。一个Ceph存储群集...

    CEPH简介

    无论您是要向Cloud Platform提供Ceph对象存储/ Ceph块设备服务,部署Ceph文件系统还是将Ceph用于其他目的,所有 Ceph Storage Cluster部署都首先要设置每个 Ceph节点,您的网络和Ceph。存储集群。一个Ceph存储群集至少需要一个Ceph监视器,Ceph管理器和Ceph OSD(对象存储守护程序)。运行Ceph文件系统客户端时,也需要Ceph Metadata Server

     

    • 监视器Ceph Monitorceph-mon)维护集群状态的映射,包括监视器映射,管理器映射,OSD映射和CRUSH映射。这些映射是Ceph守护程序相互协调所需的关键群集状态。监视器还负责管理守护程序和客户端之间的身份验证。通常至少需要三个监视器才能实现冗余和高可用性。
    • 管理器Ceph Manager守护进程(ceph-mgr)负责跟踪运行时指标和Ceph集群的当前状态,包括存储利用率,当前性能指标和系统负载。Ceph Manager守护进程还托管基于python的模块,以管理和公开Ceph集群信息,包括基于WebCeph仪表板 REST API。高可用性通常至少需要两个管理器。
    • Ceph OSDCeph OSD(对象存储守护程序, ceph-osd)存储数据,处理数据复制,恢复,重新平衡,并通过检查其他Ceph OSD守护程序的心跳来向Ceph监视器和管理器提供一些监视信息。通常至少需要3Ceph OSD才能实现冗余和高可用性。
    • MDSCeph元数据服务器MDSceph-mds)代表Ceph文件系统存储元数据(即Ceph块设备和Ceph对象存储不使用MDS)。Ceph的元数据服务器允许POSIX文件系统的用户来执行基本的命令(如 lsfind没有放置在一个Ceph存储集群的巨大负担,等等)。

    Ceph将数据作为对象存储在逻辑存储池中。使用 CRUSH算法,Ceph计算哪个放置组应包含该对象,并进一步计算哪个Ceph OSD守护程序应存储该放置组。CRUSH算法使Ceph存储集群能够动态扩展,重新平衡和恢复。

    硬件建议

    Ceph被设计为在商品硬件上运行,这使得在经济上构建和维护PB级数据集群成为可能。在规划群集硬件时,您需要权衡许多注意事项,包括故障域和潜在的性能问题。硬件规划应包括在许多主机之间分发Ceph守护进程和其他使用Ceph的进程。通常,我们建议在为该类型的守护程序配置的主机上运行特定类型的Ceph守护程序。我们建议将其他主机用于利用您的数据集群的进程(例如,OpenStackCloudStack等)。

    小费

     

    也可以查看Ceph博客

    CPU 

    Ceph元数据服务器动态地重新分配其负载,这会占用大量CPU。因此,您的元数据服务器应具有强大的处理能力(例如,四核或更好的CPU)。Ceph OSD运行RADOS服务,使用CRUSH计算数据放置,复制数据并维护自己的集群图副本。因此,OSD应具有合理数量的处理能力(例如,双核处理器)。监控器仅维护集群映射的主副本,因此它们不占用大量CPU。您还必须考虑主机除Ceph守护程序外是否还将运行CPU密集型进程。例如,如果您的主机将运行计算VM(例如,OpenStack Nova),则需要确保这些其他进程为Ceph守护程序留有足够的处理能力。我们建议在单独的主机上运行其他占用大量CPU的进程。

    RAM 

    通常,内存越多越好。

    监视器和管理器(CEPH-MONCEPH-MGR

    监视程序和管理程序守护程序的内存使用量通常随群集的大小而扩展。对于小型群集,通常1-2 GB就足够了。对于大型群集,您应该提供更多(5-10 GB)。您可能还需要考虑调整设置,例如mon_osd_cache_size rocksdb_cache_size

    元数据服务器(CEPH-MDS

    元数据守护程序的内存利用率取决于其缓存配置为消耗多少内存。对于大多数系统,我们建议最小为1 GB。请参阅 mds_cache_memory

    OSDCEPH-OSD

    默认情况下,使用BlueStore后端的OSD需要3-5 GBRAM。您可以osd_memory_target在使用BlueStore时通过配置选项来调整OSD占用的内存量。使用旧版FileStore后端时,操作系统页面缓存用于缓存数据,因此通常不需要进行调整,并且OSD内存消耗通常与系统中每个守护程序的PG数量有关。

    数据存储

    仔细计划数据存储配置。在计划数据存储时,需要考虑大量的成本和性能折衷。同时执行OS操作,以及从多个守护程序同时请求对单个驱动器的读写操作,可能会大大降低性能。

    重要

     

    由于Ceph必须先将所有数据写入日志,然后才能发送ACK(至少对于XFS),因此平衡日志和OSD性能非常重要!

    硬盘驱动器

    OSD应该具有足够的硬盘驱动器空间来存储对象数据。我们建议最小硬盘驱动器大小为1 TB。考虑更大磁盘的每GB成本优势。我们建议将硬盘驱动器的价格除以千兆字节的数量,以得出每千兆字节的成本,因为更大的驱动器可能会对每千兆字节的成本产生重大影响。例如,一个定价为75.00美元的1 TB硬盘的成本为每GB 0.07美元(即75美元/ 1024 = 0.0732)。相比之下,定价为150.00美元的3 TB硬盘的成本为每GB 0.05美元(即150美元/ 3072 = 0.0488)。在前面的示例中,使用1 TB磁盘通常会使每GB的成本增加40%,从而使群集的成本效率大大降低。而且,存储驱动器容量越大,每个Ceph OSD守护程序所需的内存更多,尤其是在重新平衡,回填和恢复期间。一般的经验法则是1TB的存储空间需要约1GBRAM

    小费

     

    在单个磁盘上运行多个OSD(与分区无关) 不是一个好主意。

    小费

     

    运行OSD和监视器或对单个磁盘,无论元数据服务器的分区,是不是一个好主意,无论是。

    存储驱动器受到查找时间,访问时间,读写时间以及总吞吐量的限制。这些物理限制会影响整个系统的性能,尤其是在恢复过程中。我们建议为操作系统和软件使用专用的驱动器,并为主机上运行的每个Ceph OSD守护程序使用一个驱动器。大多数“ OSD问题是由于在同一驱动器上运行操作系统,多个OSD/或多个日志而引起的。由于对小型群集上的性能问题进行故障排除的成本可能超出了额外磁盘驱动器的成本,因此您可以避免对OSD存储驱动器施加过多负担的诱惑,从而加快群集设计计划。

    您可以在每个硬盘驱动器上运行多个Ceph OSD守护程序,但这可能会导致资源争用并降低整体吞吐量。您可以将日志和对象数据存储在同一驱动器上,但这可能会增加将写和ACK日志记录到客户端所需的时间。Ceph必须先写入日志,然后才能确认写入。

    Ceph最佳实践规定您应在单独的驱动器上运行操作系统,OSD数据和OSD日志。

    固态硬盘

    一种提高性能的机会是使用固态驱动器(SSD)来减少随机访问时间和读取延迟,同时加快吞吐量。与硬盘驱动器相比,SSD的每千兆字节价格通常高出10倍以上,但是SSD的访问时间通常比硬盘驱动器快至少100倍。

    SSD没有可移动的机械部件,因此它们不一定受到与硬盘驱动器相同类型的限制。SSD确实有很大的局限性。在评估SSD时,重要的是要考虑顺序读取和写入的性能。当存储多个OSD的多个日志时,具有400MB / s顺序写入吞吐量的SSD可能比具有120MB / s顺序写入吞吐量的SSD更好。

    重要

     

    我们建议探索使用SSD来提高性能。但是,在对SSD进行大量投资之前,我们强烈建议您既检查SSD的性能指标,又在测试配置中测试SSD以评估性能。

    由于SSD没有移动的机械零件,因此在不占用大量存储空间(例如日志)的Ceph区域中使用它们是有意义的。相对便宜的SSD可能会吸引您的经济感觉。谨慎使用。选择用于CephSSD时,可接受的IOPS不够。对于期刊和SSD,有一些重要的性能注意事项:

    • 写密集型语义:日志记录涉及写密集型语义,因此在写数据时,应确保选择部署的SSD的性能等于或优于硬盘驱动器。廉价的SSD可能会增加写入延迟,即使它们加快了访问时间,因为有时高性能硬盘的写入速度可能比市场上某些更经济的SSD快或快!
    • 顺序写入:在SSD上存储多个日志时,还必须考虑SSD的顺序写入限制,因为它们可能正在处理同时写入多个OSD日志的请求。
    • 分区对齐: SSD性能的一个常见问题是人们喜欢对驱动器进行分区,这是最佳做法,但是他们通常忽略了与SSD进行正确的分区对齐,这可能导致SSD传输数据的速度变慢得多。确保SSD分区正确对齐。

    尽管SSD禁止对象存储成本,但OSD可能会通过将OSD的日志存储在SSD上以及将OSD的对象数据存储在单独的硬盘驱动器上而获得显着的性能提升。所述配置设置默认为。您可以将此路径安装到SSDSSD分区,以便它不仅仅是与对象数据在同一磁盘上的文件。osd journal/var/lib/ceph/osd/$cluster-$id/journal

    Ceph加速CephFS文件系统性能的一种方法是将CephFS元数据的存储与CephFS文件内容的存储区分开。Ceph metadataCephFS元数据提供了一个默认池。您将不必为CephFS元数据创建池,但可以为CephFS元数据池创建仅指向主机的SSD存储介质的CRUSH映射层次结构。有关详细信息,请参见将 池映射到不同类型的OSD

    控制器

    磁盘控制器对写入吞吐量也有重大影响。仔细考虑您选择的磁盘控制器,以确保它们不会造成性能瓶颈。

    小费

     

    Ceph的博客往往是对头孢性能问题的信息的极好来源。有关更多详细信息,请参见Ceph写吞吐量1Ceph写吞吐量2

    其他注意事项

    您可以在每个主机上运行多个OSD,但应确保OSD硬盘的总吞吐量之和不超过满足客户端读取或写入数据所需的网络带宽。您还应该考虑群集在每个主机上存储的全部数据的百分比。如果特定主机上的百分比很大且主机发生故障,则可能导致诸如超过的问题,这会导致Ceph停止操作,这是一种安全预防措施,可防止数据丢失。full ratio

    当每个主机运行多个OSD时,还需要确保内核是最新的。请参阅操作系统建议,以获取注释,glibc syncfs(2)确保每个主机运行多个OSD时硬件能够按预期运行。

    网络

    我们建议每个主机至少有两个1Gbps网络接口控制器(NIC)。由于大多数商用硬盘驱动器的吞吐量约为100MB /秒,因此您的NIC应该能够处理主机上OSD磁盘的流量。我们建议至少使用两个NIC来说明一个公共(前端)网络和一个群集(后端)网络。群集网络(最好不连接到Internet)可以处理数据复制的额外负载,并有助于阻止拒绝服务攻击,从而阻止群集实现active + cleanOSD在整个群集中复制数据时,放置组的状态。考虑从机架中的10Gbps网络开始。跨1Gbps网络复制1TB数据需要3个小时,而3TB(典型的驱动器配置)则需要9个小时。相反,对于10Gbps网络,复制时间分别为20分钟和1小时。在PB级群集中,OSD磁盘故障应该是一种期望,而不是例外。系统管理员将欣赏PGdegraded状态恢复到正常 状态的过程。active + clean在考虑价格/性能折衷的情况下尽可能快地进行陈述。此外,某些部署工具(例如DellCrowbar)可部署五个不同的网络,但使用VLAN使硬件和网络布线更易于管理。使用802.1q协议的VLAN需要具有VLAN功能的NIC和交换机。增加的硬件支出可能会因网络设置和维护的运营成本节省而被抵销。当使用VLAN处理群集和计算堆栈(例如OpenStackCloudStack等)之间的VM通信时,还值得考虑使用10G以太网。每个网络的架顶式路由器还需要能够与吞吐量甚至更高(例如40Gbps100Gbps)的主干路由器通信。

    您的服务器硬件应具有基板管理控制器(BMC)。管理和部署工具也可能会广泛使用BMC,因此请考虑带外网络进行管理的成本/收益之间的权衡。系统管理程序SSH访问,VM映像上传,OS映像安装,管理套接字等可能会对网络造成很大的负担。运行三个网络似乎有些过头,但是每个流量路径都代表一个潜在的容量,吞吐量和/或性能瓶颈,您在部署大规模数据集群之前应仔细考虑。

    失败域

    故障域是阻止访问一个或多个OSD的任何故障。那可能是主机上停止的守护程序。硬盘故障,操作系统崩溃,网卡故障,电源故障,网络中断,电源中断等。在计划硬件需求时,您必须权衡诱惑以降低成本,方法是将过多的职责分配到过少的故障域中,以及增加隔离每个潜在故障域的成本。

    最低硬件建议

    Ceph可以在廉价的商品硬件上运行。小型生产集群和开发集群可以使用适度的硬件成功运行。

    处理

    标准

    最低推荐

    ceph-osd

    处理器

    • 1个64位AMD-64
    • 1个32位ARM双核或更高

    内存

    每个守护程序1TB的存储空间约为1GB

    卷存储

    每个守护程序1个存储驱动器

    日志

    每个守护程序1个SSD分区(可选)

    网络

    2个1GB以太网NIC

    ceph-mon

    处理器

    • 1个64位AMD-64
    • 1个32位ARM双核或更高

    内存

    每个守护程序1 GB

    磁盘空间

    每个守护程序10 GB

    网络

    2个1GB以太网NIC

    ceph-mds

    处理器

    • 1个64位AMD-64四核
    • 1个32位ARM四核

    内存

    每个守护程序至少1 GB

    磁盘空间

    每个守护程序1 MB

    网络

    2个1GB以太网NIC

    小费

     

    如果使用单个磁盘运行OSD,请为卷存储创建一个分区,该分区与包含OS的分区分开。通常,我们建议为操作系统和卷存储使用单独的磁盘。

    生产集群的例子

    用于PB级数据存储的生产集群也可以使用商用硬件,但应具有更多的内存,处理能力和数据存储以应对繁重的流量负载。

    戴尔示例

    最近(2012年)的Ceph集群项目正在为Ceph OSD使用两个相当健壮的硬件配置,为显示器使用一个较轻的配置。

    组态

    标准

    最低推荐

    戴尔PE R510

    处理器

    2个64位四核Xeon CPU

    内存

    16 GB

    卷存储

    8个2TB驱动器。1个操作系统,7个存储

    客户网络

    2个1GB以太网NIC

    OSD网络

    2个1GB以太网NIC

    MGMT。网络

    2个1GB以太网NIC

    戴尔PE R515

    处理器

    1个六核Opteron CPU

    内存

    16 GB

    卷存储

    12个3TB驱动器。存储

    操作系统存储

    1个500GB驱动器。操作系统。

    客户网络

    2个1GB以太网NIC

    OSD网络

    2个1GB以太网NIC

    MGMT。网络

    2个1GB以太网NIC

    OS建议

    头孢依赖

    通常,我们建议在较新版本的Linux上部署Ceph。我们还建议在具有长期支持的版本上进行部署。

    LINUX内核

    • Ceph内核客户端

    如果您使用内核客户端映射RBD块设备或挂载CephFS,则一般建议是使用http://kernel.org或您的Linux发行版在任何客户端上提供的稳定长期维护内核系列。主机。

    对于RBD,如果您选择跟踪长期内核,我们目前建议使用基于4.x长期维护内核系列:

      • 4.19.z
      • 4.14.z

    对于CephFS,请参阅CephFS最佳做法以获取内核版本指导。

    较旧的内核客户端版本可能不支持您的CRUSH可调参数配置文件或Ceph群集的其他较新功能,因此需要在禁用这些功能的情况下配置存储群集。

    平台

    下图显示了Ceph的要求如何映射到各种Linux平台上。一般而言,除了内核和系统初始化程序包(即sysvinitupstartsystemd)以外,对特定发行版的依赖性很小。

    鹦鹉螺(14.2.Z

    发行

    发布

    代码名称

    核心

    笔记

    测试

    CentOS的

    7

    N / A

    Linux的3.10.0

    3

    B,我,C

    Debian的

    8

    杰西

    Linux的3.16.0

    一二

    B,我

    Debian的

    9

    伸展

    Linux的4.9

    一二

    B,我

    RHEL

    7

    迈波

    Linux的3.10.0

     

    B,我

    Ubuntu的

    14.04

    可信赖的塔尔

    Linux的3.13.0

     

    B,我,C

    Ubuntu的

    16.04

    Xenial Xerus

    Linux的4.4.0

    3

    B,我,C

    Ubuntu的

    18.04

    仿生海狸

    Linux的4.15

    3

    B,我,C

    openSUSE的

    15.1

    飞跃

    Linux的4.12

       

    openSUSE的

     

    滚草

    Linux的5.1.7

       

    发光的(12.2.Z

    发行

    发布

    代码名称

    核心

    笔记

    测试

    CentOS的

    7

    N / A

    Linux的3.10.0

    3

    B,我,C

    Debian的

    8

    杰西

    Linux的3.16.0

    一二

    B,我

    Debian的

    9

    伸展

    Linux的4.9

    一二

    B,我

    Fedora的

    22

    N / A

    Linux的3.14.0

     

    B,我

    RHEL

    7

    迈波

    Linux的3.10.0

     

    B,我

    Ubuntu的

    14.04

    可信赖的塔尔

    Linux的3.13.0

     

    B,我,C

    Ubuntu的

    16.04

    Xenial Xerus

    Linux的4.4.0

    3

    B,我,C

    注释

    • 1:默认内核具有较旧的版本btrfs,我们不建议将其用于ceph-osd存储节点。我们建议使用XFS。
    • 2:默认内核具有旧的Ceph客户端,我们不建议将其用于内核客户端(内核RBD或Ceph文件系统)。升级到推荐的内核。
    • 3:btrfs 使用文件系统时,默认内核通常会在质量检查中失败。我们不建议将其btrfs用于备份Ceph OSD。

    测试

    • B:我们为此平台构建发行包。对于其中一些平台,我们还可能会不断构建所有ceph分支并进行基本的单元测试。
    • I:我们对该平台上的发行版进行基本的安装和功能测试。
    • C:我们在该平台上连续运行一个综合的功能,回归和压力测试套件。这包括开发分支,预发布和发布的代码。

    参与CEPH社区!

    Ceph社区,这是令人兴奋的时刻!参与其中!

    渠道

    描述

    联络资料

    博客

    定期检查Ceph 博客,以跟踪Ceph的进度和重要的公告。

    http://ceph.com/community/blog/

    Ceph星球

    查看Planet Ceph上的博客聚合,以获取社区中有趣的故事,信息和经验。

    https://ceph.com/category/planet/

    维基

    查看Ceph Wiki,可获取更多与社区和开发相关的主题。您可以在此处找到有关蓝图,聚会,Ceph开发者峰会等的信息。

    http://wiki.ceph.com/

    IRC

    当您深入研究Ceph时,您可能会对Ceph开发团队有疑问或反馈。Ceph开发人员通常可以在#ceph IRC频道上使用,特别是在美国太平洋标准时区的白天。虽然#ceph是集群运营商和用户一个很好的起点,也有 #ceph-devel#ceph-dashboard 专用的头孢开发。

    • 域:

    irc.oftc.net

    • 渠道:

    #ceph #ceph-devel #ceph-dashboard

    用户清单

    通过订阅电子邮件列表ceph-users @ ceph来询问和回答与用户有关的问题 com。您可以随时取消订阅,退出电子邮件列表。只需一封简单的电子邮件!如果您想查看档案,请转到Gmane

    开发清单

    通过订阅电子邮件列表ceph -devel @ vger与开发人员保持联系 内核org。您可以随时取消订阅,退出电子邮件列表。只需一封简单的电子邮件!如果您想查看档案,请转到Gmane

    提交清单

    订阅ceph-commit @ ceph com通过电子邮件获取提交通知。您可以随时取消订阅,退出电子邮件列表。只需一封简单的电子邮件!

    质量检查清单

    对于质量保证(QA),相关活动订阅此列表。您可以随时取消订阅,退出电子邮件列表。只需一封简单的电子邮件!

    社区清单

    对于与Ceph用户委员会和其他社区主题有关的所有讨论。您可以随时取消订阅,退出电子邮件列表。只需一封简单的电子邮件!

    错误追踪

    您可以通过记录和跟踪错误以及使用Bug Tracker提供功能请求来帮助保持Ceph产品的价值。

    http://tracker.ceph.com/projects/ceph

    源代码

    如果您想参与开发,错误修复,或者只想要Ceph的最新代码,可以在http://github.com获得。有关 github进行克隆的详细信息,请参见Ceph源代码

     

     

     

    展开全文
  • 1. Ceph架构简介及使用场景介绍 1.1 Ceph简介 Ceph是一个统一的分布式存储系统,设计初衷是提供较好的性能、可靠性和可扩展性。 Ceph项目最早起源于Sage就读博士期间的工作(最早的成果于2004年发表),并...

    1. Ceph架构简介及使用场景介绍

     

    1.1 Ceph简介

     

    Ceph是一个统一的分布式存储系统,设计初衷是提供较好的性能、可靠性和可扩展性。

     

    Ceph项目最早起源于Sage就读博士期间的工作(最早的成果于2004年发表),并随后贡献给开源社区。在经过了数年的发展之后,目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。

     

    1.2 Ceph特点

     

    • 高性能
      a. 摒弃了传统的集中式存储元数据寻址的方案,采用CRUSH算法,数据分布均衡,并行度高。
      b.考虑了容灾域的隔离,能够实现各类负载的副本放置规则,例如跨机房、机架感知等。
      c. 能够支持上千个存储节点的规模,支持TB到PB级的数据。

     

    • 高可用性
      a. 副本数可以灵活控制。
      b. 支持故障域分隔,数据强一致性。
      c. 多种故障场景自动进行修复自愈。
      d. 没有单点故障,自动管理。

     

    • 高可扩展性
      a. 去中心化。
      b. 扩展灵活。
      c. 随着节点增加而线性增长。

     

    • 特性丰富
      a. 支持三种存储接口:块存储、文件存储、对象存储。
      b. 支持自定义接口,支持多种语言驱动。

     

    1.3 Ceph架构

     

    支持三种接口:

     

    • Object:有原生的API,而且也兼容Swift和S3的API。

    • Block:支持精简配置、快照、克隆。

    • File:Posix接口,支持快照。

       

      640?wx_fmt=png

      rados

     

    1.4 Ceph核心组件及概念介绍

     

    • Monitor
      一个Ceph集群需要多个Monitor组成的小集群,它们通过Paxos同步数据,用来保存OSD的元数据。

     

    • OSD
      OSD全称Object Storage Device,也就是负责响应客户端请求返回具体数据的进程。一个Ceph集群一般都有很多个OSD。

     

    • MDS
      MDS全称Ceph Metadata Server,是CephFS服务依赖的元数据服务。

     

    • Object
      Ceph最底层的存储单元是Object对象,每个Object包含元数据和原始数据。

     

    • PG
      PG全称Placement Grouops,是一个逻辑的概念,一个PG包含多个OSD。引入PG这一层其实是为了更好的分配数据和定位数据。

     

    • RADOS
      RADOS全称Reliable Autonomic Distributed Object Store,是Ceph集群的精华,用户实现数据分配、Failover等集群操作。

     

    • Libradio
      Librados是Rados提供库,因为RADOS是协议很难直接访问,因此上层的RBD、RGW和CephFS都是通过librados访问的,目前提供PHP、Ruby、Java、Python、C和C++支持。

     

    • CRUSH
      CRUSH是Ceph使用的数据分布算法,类似一致性哈希,让数据分配到预期的地方。

     

    • RBD
      RBD全称RADOS block device,是Ceph对外提供的块设备服务。

     

    • RGW
      RGW全称RADOS gateway,是Ceph对外提供的对象存储服务,接口与S3和Swift兼容。

     

    • CephFS
      CephFS全称Ceph File System,是Ceph对外提供的文件系统服务。

     

    1.5 三种存储类型-块存储

    640?wx_fmt=png

    rbd

     

    典型设备: 磁盘阵列,硬盘

     

    主要是将裸磁盘空间映射给主机使用的。

     

    优点:

     

    • 通过Raid与LVM等手段,对数据提供了保护。

    • 多块廉价的硬盘组合起来,提高容量。

    • 多块磁盘组合出来的逻辑盘,提升读写效率。

     

    缺点:

     

    • 采用SAN架构组网时,光纤交换机,造价成本高。

    • 主机之间无法共享数据。

     

    使用场景:

     

    • docker容器、虚拟机磁盘存储分配。

    • 日志存储。

    • 文件存储。

     

    1.6 三种存储类型-文件存储

     

    640?wx_fmt=png

    fs

     

    典型设备: FTP、NFS服务器

     

    为了克服块存储文件无法共享的问题,所以有了文件存储。

     

    在服务器上架设FTP与NFS服务,就是文件存储。

     

    优点:

     

    • 造价低,随便一台机器就可以了。

    • 方便文件共享。

     

    缺点:

     

    • 读写速率低。

    • 传输速率慢。

     

    使用场景:

     

    • 日志存储。

    • 有目录结构的文件存储。

     

    1.7 三种存储类型-对象存储

     

    640?wx_fmt=png

    rgw

     

    典型设备: 内置大容量硬盘的分布式服务器(swift, s3)

     

    多台服务器内置大容量硬盘,安装上对象存储管理软件,对外提供读写访问功能。

     

    优点:

     

    • 具备块存储的读写高速。

    • 具备文件存储的共享等特性。

     

    使用场景: (适合更新变动较少的数据)

     

    • 图片存储。

    • 视频存储。

     

    2. Ceph IO流程及数据分布

     

    640?wx_fmt=png

    rados_io_1

     

    2.1 正常IO流程图

     

    640?wx_fmt=png

    ceph_io_2

     

    步骤:

     

    1. client 创建cluster handler。

    2. client 读取配置文件。

    3. client 连接上monitor,获取集群map信息。

    4. client 读写io 根据crshmap 算法请求对应的主osd数据节点。

    5. 主osd数据节点同时写入另外两个副本节点数据。

    6. 等待主节点以及另外两个副本节点写完数据状态。

    7. 主节点及副本节点写入状态都成功后,返回给client,io写入完成。

     

    2.2 新主IO流程图

     

    说明:

     

    如果新加入的OSD1取代了原有的 OSD4成为 Primary OSD, 由于 OSD1 上未创建 PG , 不存在数据,那么 PG 上的 I/O 无法进行,怎样工作的呢?

     

    640?wx_fmt=png

    ceph_io_3

     

    步骤:

     

    1. client连接monitor获取集群map信息。

    2. 同时新主osd1由于没有pg数据会主动上报monitor告知让osd2临时接替为主。

    3. 临时主osd2会把数据全量同步给新主osd1。

    4. client IO读写直接连接临时主osd2进行读写。

    5. osd2收到读写io,同时写入另外两副本节点。

    6. 等待osd2以及另外两副本写入成功。

    7. osd2三份数据都写入成功返回给client, 此时client io读写完毕。

    8. 如果osd1数据同步完毕,临时主osd2会交出主角色。

    9. osd1成为主节点,osd2变成副本。

     

    2.3 Ceph IO算法流程

    640?wx_fmt=png

    ceph_io_4

     

    1. File用户需要读写的文件。File->Object映射:

     

    a. ino (File的元数据,File的唯一id)。
    b. ono(File切分产生的某个object的序号,默认以4M切分一个块大小)。
    c. oid(object id: ino + ono)。

     

    2. Object是RADOS需要的对象。Ceph指定一个静态hash函数计算oid的值,将oid映射成一个近似均匀分布的伪随机值,然后和mask按位相与,得到pgid。Object->PG映射:

     

    a. hash(oid) & mask-> pgid 。
    b. mask = PG总数m(m为2的整数幂)-1 。

     

    3. PG(Placement Group),用途是对object的存储进行组织和位置映射, (类似于redis cluster里面的slot的概念) 一个PG里面会有很多object。采用CRUSH算法,将pgid代入其中,然后得到一组OSD。PG->OSD映射:

     

    a. CRUSH(pgid)->(osd1,osd2,osd3) 。

     

    2.4 Ceph IO伪代码流程

     

    locator = object_name
    obj_hash =  hash(locator)
    pg = obj_hash % num_pg
    osds_for_pg = crush(pg)    # returns a list of osdsprimary = osds_for_pg[0]
    replicas = osds_for_pg[1:]
    

     

    2.5 Ceph RBD IO流程

     

    640?wx_fmt=png

    ceph_rbd_io

     

    步骤:

     

    1. 客户端创建一个pool,需要为这个pool指定pg的数量。

     

    2. 创建pool/image rbd设备进行挂载。

     

    3. 用户写入的数据进行切块,每个块的大小默认为4M,并且每个块都有一个名字,名字就是object+序号。

     

    4. 将每个object通过pg进行副本位置的分配。

     

    5. pg根据cursh算法会寻找3个osd,把这个object分别保存在这三个osd上。

     

    6. osd上实际是把底层的disk进行了格式化操作,一般部署工具会将它格式化为xfs文件系统。

     

    7. object的存储就变成了存储一个文rbd0.object1.file。

     

    2.6 Ceph RBD IO框架图

     

    640?wx_fmt=png

    ceph_rbd_io1

     

    客户端写数据osd过程:

     

    1. 采用的是librbd的形式,使用librbd创建一个块设备,向这个块设备中写入数据。

     

    2. 在客户端本地同过调用librados接口,然后经过pool,rbd,object、pg进行层层映射,在PG这一层中,可以知道数据保存在哪3个OSD上,这3个OSD分为主从的关系。

     

    3. 客户端与primay OSD建立SOCKET 通信,将要写入的数据传给primary OSD,由primary OSD再将数据发送给其他replica OSD数据节点。

     

    2.7 Ceph Pool和PG分布情况

     

    640?wx_fmt=png

    ceph_pool_pg

     

    说明:

     

    • pool是ceph存储数据时的逻辑分区,它起到namespace的作用。

    • 每个pool包含一定数量(可配置)的PG。

    • PG里的对象被映射到不同的Object上。

    • pool是分布到整个集群的。

    • pool可以做故障隔离域,根据不同的用户场景不一进行隔离。

     

    2.8 Ceph 数据扩容PG分布

     

    场景数据迁移流程:

     

    • 现状3个OSD, 4个PG

    • 扩容到4个OSD, 4个PG

     

    现状:

     

    640?wx_fmt=png

    ceph_recory_1

     

    扩容后:

     

    640?wx_fmt=png

    ceph_io_recry2

     

    说明

     

    每个OSD上分布很多PG, 并且每个PG会自动散落在不同的OSD上。如果扩容那么相应的PG会进行迁移到新的OSD上,保证PG数量的均衡。

     

    3. Ceph心跳机制

     

    3.1 心跳介绍

     

    心跳是用于节点间检测对方是否故障的,以便及时发现故障节点进入相应的故障处理流程。

     

    问题:

     

    • 故障检测时间和心跳报文带来的负载之间做权衡。

    • 心跳频率太高则过多的心跳报文会影响系统性能。

    • 心跳频率过低则会延长发现故障节点的时间,从而影响系统的可用性。

     

    故障检测策略应该能够做到:

     

    • 及时:节点发生异常如宕机或网络中断时,集群可以在可接受的时间范围内感知。

    • 适当的压力:包括对节点的压力,和对网络的压力。

    • 容忍网络抖动:网络偶尔延迟。

    • 扩散机制:节点存活状态改变导致的元信息变化需要通过某种机制扩散到整个集群。

     

    3.2 Ceph 心跳检测

     

    640?wx_fmt=png

    ceph_heartbeat_1

     

    OSD节点会监听public、cluster、front和back四个端口

     

    • public端口:监听来自Monitor和Client的连接。

    • cluster端口:监听来自OSD Peer的连接。

    • front端口:供客户端连接集群使用的网卡, 这里临时给集群内部之间进行心跳。

    • back端口:供客集群内部使用的网卡。集群内部之间进行心跳。

    • hbclient:发送ping心跳的messenger。

     

    3.3 Ceph OSD之间相互心跳检测

     

    640?wx_fmt=png

    ceph_heartbeat_osd

     

    步骤:

     

    • 同一个PG内OSD互相心跳,他们互相发送PING/PONG信息。

    • 每隔6s检测一次(实际会在这个基础上加一个随机时间来避免峰值)。

    • 20s没有检测到心跳回复,加入failure队列。

     

    3.4 Ceph OSD与Mon心跳检测

     

    640?wx_fmt=png

    ceph_heartbeat_mon

     

    OSD报告给Monitor:

     

    • OSD有事件发生时(比如故障、PG变更)。

    • 自身启动5秒内。

    • OSD周期性的上报给Monito

      • OSD检查failure_queue中的伙伴OSD失败信息。

      • 向Monitor发送失效报告,并将失败信息加入failure_pending队列,然后将其从failure_queue移除。

      • 收到来自failure_queue或者failure_pending中的OSD的心跳时,将其从两个队列中移除,并告知Monitor取消之前的失效报告。

      • 当发生与Monitor网络重连时,会将failure_pending中的错误报告加回到failure_queue中,并再次发送给Monitor。

    • Monitor统计下线OSD

      • Monitor收集来自OSD的伙伴失效报告。

      • 当错误报告指向的OSD失效超过一定阈值,且有足够多的OSD报告其失效时,将该OSD下线。

     

    3.5 Ceph心跳检测总结

     

    Ceph通过伙伴OSD汇报失效节点和Monitor统计来自OSD的心跳两种方式判定OSD节点失效。

     

    • 及时:伙伴OSD可以在秒级发现节点失效并汇报Monitor,并在几分钟内由Monitor将失效OSD下线。

     

    • 适当的压力:由于有伙伴OSD汇报机制,Monitor与OSD之间的心跳统计更像是一种保险措施,因此OSD向Monitor发送心跳的间隔可以长达600秒,Monitor的检测阈值也可以长达900秒。Ceph实际上是将故障检测过程中中心节点的压力分散到所有的OSD上,以此提高中心节点Monitor的可靠性,进而提高整个集群的可扩展性。

     

    • 容忍网络抖动:Monitor收到OSD对其伙伴OSD的汇报后,并没有马上将目标OSD下线,而是周期性的等待几个条件:

      • 目标OSD的失效时间大于通过固定量osd_heartbeat_grace和历史网络条件动态确定的阈值。

      • 来自不同主机的汇报达到mon_osd_min_down_reporters。

      • 满足前两个条件前失效汇报没有被源OSD取消。

     

     

    • 扩散:作为中心节点的Monitor并没有在更新OSDMap后尝试广播通知所有的OSD和Client,而是惰性的等待OSD和Client来获取。以此来减少Monitor压力并简化交互逻辑。

     

    4. Ceph通信框架

     

    4.1 Ceph通信框架种类介绍

     

    网络通信框架三种不同的实现方式:

     

    • Simple线程模式
      特点:每一个网络链接,都会创建两个线程,一个用于接收,一个用于发送。
      缺点:大量的链接会产生大量的线程,会消耗CPU资源,影响性能。

    • Async事件的I/O多路复用模式
      特点:这种是目前网络通信中广泛采用的方式。k版默认已经使用Asnyc了。

    • XIO方式使用了开源的网络通信库accelio来实现
      特点:这种方式需要依赖第三方的库accelio稳定性,目前处于试验阶段。

     

    4.2 Ceph通信框架设计模式

     

    设计模式(Subscribe/Publish):

     

    订阅发布模式又名观察者模式,它意图是“定义对象间的一种一对多的依赖关系,
    当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新”。

     

    4.3 Ceph通信框架流程图

     

    640?wx_fmt=png

    ceph_message

     

    步骤:

     

    • Accepter监听peer的请求, 调用 SimpleMessenger::add_accept_pipe() 创建新的 Pipe 到 SimpleMessenger::pipes 来处理该请求。

     

    • Pipe用于消息的读取和发送。该类主要有两个组件,Pipe::Reader,Pipe::Writer用来处理消息读取和发送。

     

    • Messenger作为消息的发布者, 各个 Dispatcher 子类作为消息的订阅者, Messenger 收到消息之后,  通过 Pipe 读取消息,然后转给 Dispatcher 处理。

     

    • Dispatcher是订阅者的基类,具体的订阅后端继承该类,初始化的时候通过 Messenger::add_dispatcher_tail/head 注册到 Messenger::dispatchers. 收到消息后,通知该类处理。

     

    • DispatchQueue该类用来缓存收到的消息, 然后唤醒 DispatchQueue::dispatch_thread 线程找到后端的 Dispatch 处理消息。

     

    640?wx_fmt=png

    ceph_message_2

     

    4.4 Ceph通信框架类图

     

    640?wx_fmt=png

    ceph_message_3

     

    4.5 Ceph通信数据格式

     

    通信协议格式需要双方约定数据格式。

     

    消息的内容主要分为三部分:

     

    • header              //消息头,类型消息的信封

    • user data          //需要发送的实际数据

      • payload     //操作保存元数据

      • middle      //预留字段

      • data          //读写数据

    • footer             //消息的结束标记

     

     

    class Message : public RefCountedObject {
    protected:
      ceph_msg_header  header;      // 消息头
      ceph_msg_footer  footer;      // 消息尾
      bufferlist       payload;  // "front" unaligned blob
      bufferlist       middle;   // "middle" unaligned blob
      bufferlist       data;     // data payload (page-alignment will be preserved where possible)
    
      /* recv_stamp is set when the Messenger starts reading the
       * Message off the wire */
      utime_t recv_stamp;       //开始接收数据的时间戳
      /* dispatch_stamp is set when the Messenger starts calling dispatch() on
       * its endpoints */
      utime_t dispatch_stamp;   //dispatch 的时间戳
      /* throttle_stamp is the point at which we got throttle */
      utime_t throttle_stamp;   //获取throttle 的slot的时间戳
      /* time at which message was fully read */
      utime_t recv_complete_stamp;  //接收完成的时间戳
    
      ConnectionRef connection;     //网络连接
    
      uint32_t magic = 0;           //消息的魔术字
    
      bi::list_member_hook<> dispatch_q;    //boost::intrusive 成员字段
    };
    
    struct ceph_msg_header {
        __le64 seq;       // 当前session内 消息的唯一 序号
        __le64 tid;       // 消息的全局唯一的 id
        __le16 type;      // 消息类型
        __le16 priority;  // 优先级
        __le16 version;   // 版本号
    
        __le32 front_len; // payload 的长度
        __le32 middle_len;// middle 的长度
        __le32 data_len;  // data 的 长度
        __le16 data_off;  // 对象的数据偏移量
    
    
        struct ceph_entity_name src; //消息源
    
        /* oldest code we think can decode this.  unknown if zero. */
        __le16 compat_version;
        __le16 reserved;
        __le32 crc;       /* header crc32c */
    } __attribute__ ((packed));
    
    struct ceph_msg_footer {
        __le32 front_crc, middle_crc, data_crc; //crc校验码
        __le64  sig; //消息的64位signature
        __u8 flags; //结束标志
    } __attribute__ ((packed));
    

     

    5. Ceph CRUSH算法

     

    5.1 数据分布算法挑战

     

    • 数据分布和负载均衡:
      a. 数据分布均衡,使数据能均匀的分布到各个节点上。
      b. 负载均衡,使数据访问读写操作的负载在各个节点和磁盘的负载均衡。

     

    • 灵活应对集群伸缩
      a. 系统可以方便的增加或者删除节点设备,并且对节点失效进行处理。
      b. 增加或者删除节点设备后,能自动实现数据的均衡,并且尽可能少的迁移数据。

     

    • 支持大规模集群
      a. 要求数据分布算法维护的元数据相对较小,并且计算量不能太大。随着集群规模的增 加,数据分布算法开销相对比较小。

     

    5.2 Ceph CRUSH算法说明

     

    • CRUSH算法的全称为:Controlled Scalable Decentralized Placement of Replicated Data,可控的、可扩展的、分布式的副本数据放置算法。

     

    • pg到OSD的映射的过程算法叫做CRUSH 算法。(一个Object需要保存三个副本,也就是需要保存在三个osd上)。

     

    • CRUSH算法是一个伪随机的过程,他可以从所有的OSD中,随机性选择一个OSD集合,但是同一个PG每次随机选择的结果是不变的,也就是映射的OSD集合是固定的。

     

    5.3 Ceph CRUSH算法原理

     

    CRUSH算法因子:

     

    • 层次化的Cluster Map
      反映了存储系统层级的物理拓扑结构。定义了OSD集群具有层级关系的 静态拓扑结构。OSD层级使得 CRUSH算法在选择OSD时实现了机架感知能力,也就是通过规则定义, 使得副本可以分布在不同的机 架、不同的机房中、提供数据的安全性 。

     

    • Placement Rules
      决定了一个PG的对象副本如何选择的规则,通过这些可以自己设定规则,用户可以自定义设置副本在集群中的分布。

     

    5.3.1 层级化的Cluster Map

     

    640?wx_fmt=png

    ceph_crush

     

    CRUSH Map是一个树形结构,OSDMap更多记录的是OSDMap的属性(epoch/fsid/pool信息以及osd的ip等等)。

     

    叶子节点是device(也就是osd),其他的节点称为bucket节点,这些bucket都是虚构的节点,可以根据物理结构进行抽象,当然树形结构只有一个最终的根节点称之为root节点,中间虚拟的bucket节点可以是数据中心抽象、机房抽象、机架抽象、主机抽象等。

     

    5.3.2 数据分布策略Placement Rules

     

    数据分布策略Placement Rules主要有特点:

     

    a. 从CRUSH Map中的哪个节点开始查找
    b. 使用那个节点作为故障隔离域
    c. 定位副本的搜索模式(广度优先 or 深度优先)

     

    rule replicated_ruleset  #规则集的命名,创建pool时可以指定rule集
    {
        ruleset 0                #rules集的编号,顺序编即可   
        type replicated          #定义pool类型为replicated(还有erasure模式)   
        min_size 1                #pool中最小指定的副本数量不能小1
        max_size 10               #pool中最大指定的副本数量不能大于10       
        step take default         #查找bucket入口点,一般是root类型的bucket    
        step chooseleaf  firstn  0  type  host #选择一个host,并递归选择叶子节点osd     
        step emit        #结束
    }
    

     

    5.3.3 Bucket随机算法类型

    640?wx_fmt=png

    ceph_bucket

     

    • 一般的buckets:适合所有子节点权重相同,而且很少添加删除item。

     

    • list buckets:适用于集群扩展类型。增加item,产生最优的数据移动,查找item,时间复杂度O(n)。

     

    • tree buckets:查找负责度是O (log n), 添加删除叶子节点时,其他节点node_id不变。

     

    • straw buckets:允许所有项通过类似抽签的方式来与其他项公平“竞争”。定位副本时,bucket中的每一项都对应一个随机长度的straw,且拥有最长长度的straw会获得胜利(被选中),添加或者重新计算,子树之间的数据移动提供最优的解决方案。

     

    5.4 CRUSH算法案例

     

    说明:

     

    集群中有部分sas和ssd磁盘,现在有个业务线性能及可用性优先级高于其他业务线,能否让这个高优业务线的数据都存放在ssd磁盘上。

     

    普通用户:

     

    640?wx_fmt=png

    ceph_sas.png

     

    高优用户:

     

    640?wx_fmt=png

    ssd

     

    配置规则:

     

    640?wx_fmt=png

    ceph_crush1

     

    6. 定制化Ceph RBD QOS

     

    6.1 QOS介绍

     

    QoS (Quality of Service,服务质量)起源于网络技术,它用来解决网络延迟和阻塞等问题,能够为指定的网络通信提供更好的服务能力。

     

    问题:

     

    我们总的Ceph集群的iIO能力是有限的,比如带宽,IOPS。如何避免用户争取资源,如果保证集群所有用户资源的高可用性,以及如何保证高优用户资源的可用性。所以我们需要把有限的IO能力合理分配。

     

    6.2 Ceph IO操作类型

     

    • ClientOp:来自客户端的读写I/O请求。

     

    • SubOp:osd之间的I/O请求。主要包括由客户端I/O产生的副本间数据读写请求,以及由数据同步、数据扫描、负载均衡等引起的I/O请求。

     

    • SnapTrim:快照数据删除。从客户端发送快照删除命令后,删除相关元数据便直接返回,之后由后台线程删除真实的快照数据。通过控制snaptrim的速率间接控制删除速率。

     

    • Scrub:用于发现对象的静默数据错误,扫描元数据的Scrub和对象整体扫描的deep Scrub。

     

    • Recovery:数据恢复和迁移。集群扩/缩容、osd失效/从新加入等过程。

     

    6.3 Ceph 官方QOS原理

     

    640?wx_fmt=png

    ceph_mclok_qos

     

    mClock是一种基于时间标签的I/O调度算法,最先被Vmware提出来的用于集中式管理的存储系统。(目前官方QOS模块属于半成品)。

     

    基本思想:

     

    • reservation 预留,表示客户端获得的最低I/O资源。

    • weight 权重,表示客户端所占共享I/O资源的比重。

    • limit 上限,表示客户端可获得的最高I/O资源。

     

    6.4 定制化QOS原理

     

    6.4.1 令牌桶算法介绍

     

    640?wx_fmt=png

    ceph_token_qos

     

    基于令牌桶算法(TokenBucket)实现了一套简单有效的qos功能,满足了云平台用户的核心需求。

     

    基本思想:

     

    • 按特定的速率向令牌桶投放令牌。

     

    • 根据预设的匹配规则先对报文进行分类,不符合匹配规则的报文不需要经过令牌桶的处理,直接发送。

     

    • 符合匹配规则的报文,则需要令牌桶进行处理。当桶中有足够的令牌则报文可以被继续发送下去,同时令牌桶中的令牌量按报文的长度做相应的减少。

     

    • 当令牌桶中的令牌不足时,报文将不能被发送,只有等到桶中生成了新的令牌,报文才可以发送。这就可以限制报文的流量只能是小于等于令牌生成的速度,达到限制流量的目的。

     

    6.4.2 RBD令牌桶算法流程

     

    640?wx_fmt=png

    ceph_token1

     

    步骤:

     

    • 用户发起请求异步IO到达Image中。

    • 请求到达ImageRequestWQ队列中。

    • 在ImageRequestWQ出队列的时候加入令牌桶算法TokenBucket。

    • 通过令牌桶算法进行限速,然后发送给ImageRequest进行处理。

     

    6.4.3 RBD令牌桶算法框架图

     

    现有框架图:

     

    640?wx_fmt=png

    ceph_qos2

     

    令牌图算法框架图:

     

    640?wx_fmt=png

    ceph_qos_token2

     

    作者:李航,多年的底层开发经验,在高性能nginx开发和分布式缓存redis cluster有着丰富的经验,目前从事Ceph工作两年左右。先后在58同城、汽车之家、优酷土豆集团工作。 目前供职于滴滴基础平台运维部 负责分布式Ceph集群开发及运维等工作。个人主要关注的技术领域:高性能Nginx开发、分布式缓存、分布式存储。

     

     

    出处:https://www.jianshu.com/p/cc3ece850433

     

     

    版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢。

     

    640?wx_fmt=png

    展开全文
  • 点击上方“民工哥技术之路”选择“星标”每天10点为你分享不一样的干货读者福利!多达 2048G 各种资源免费赠送作者:李航原文:https://www.jianshu....
  • 开源社区的明星项目—Ceph谈 前言 启迪云作为一家知名私有云提供商,面向客户提供一套完整的私有云解决方案。存储作为私有云的重中之重,因此启迪云后端也支持多种存储,包括开源社区的明星项目—Ceph。 启迪云与...
  • 一、 ceph概述 随着OpenStack日渐成为开源云计算的标准软件栈,Ceph也已经成为OpenStack的首选后端存储。Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。 ceph官方文档 ...
  • 环境 主机名 IP ... Ceph1 192.168.48.132 Centos7 Ceph2 192.168.48.133 Centos7 ...
  • ceph 快照:可用做备份 一、ceph概述 1.1 什么是分布式文件系统 • &amp;nbsp;分布式文件系统(Distributed File System)是指文 件系统管理的物理存储资源不一定直接连接在本地节 点上,而是通过计算机网络与...
  • ceph-deploy配置ceph分布式集群 graph LR ceph-deploy-->ceph-node1 ceph-deploy-->ceph-node2 ceph-deploy-->ceph-node3 说明 ceph-depoly install使用说明: 不通过–release指定版本的话, 会默认安装...
  • ceph监控仪表盘

    2018-06-18 02:35:19
    使用开源管理控制台监控Ceph Ceph存储管理员通常通过Ceph接口提供的CLI命令执行大部分的集群监控工作。Ceph还为管理API提供了丰富的接口,可以使用这些接口方便的监控整个Ceph集群。有一些开源项目,它们利用Ceph的...
  • 手动安装ceph和使用

    2018-05-19 18:34:28
    我们已经对ceph有了一个大概的了解,现在就进行手动的安装ceph集群。 在我们安装集群之前,首先应该对自己的服务器环境以及集群节点作用做一个规划。 架构设计 Ceph 分布式存储集群有三大组件组成,分为:Ceph ...
  • 资源名称:Ceph分布式存储学习指南内容简介:卡伦·辛格所著的《Ceph分布式存储学习指南》是一本关于Ceph开发与集成的综合实践指南。书中详细讲解如何部署和设置Ceph集群,深入探索各种组件以及为什么需要它们,既...
  • 不管你是想为云平台提供Ceph 对象存储和/或 Ceph 块设备,还是想部署一个 Ceph 文件系统或者把 Ceph 作为他用,所有 Ceph 存储集群的部署都始于部署一个个 Ceph 节点、网络和 Ceph 存储集群。 Ceph 存储集群至少需要...
  • Ceph是呼声很高的开源分布式的SDS产品存储系统。同时提供对象存储、块存储和文件系统存储三种功能,满足不同应用需求。Ceph使用C++语言开发,遵循LGPL协议开源。Sage Weil(Ceph论文发表者)于2011年创立了以Inktank...
1 2 3 4 5 ... 20
收藏数 19,902
精华内容 7,960
关键字:

ceph