3.PG (Placement Group)----顾名思义,PG的用途是对object的存储进行组织和位置映射。一个PG负责若干个object(可以为数前个甚至更多),但一个object只能被映射到一个PG中,即,PG和object之间是一对多映射关系。同时,一个PG会被映射到n个OSD上,而每个OSD上都会承载大量的PG,即,PG和OSD之间是多对多映射关系。如果用于生产环境,OSD至少为3.一个OSD上的PG则可达到数百个。事实上,PG数量的设置牵扯到数据分布的均衡性问题。
4.OSD ----即object storage device 需要说明的是OSD的数量事实上也关系到系统的数据分布均衡性,因此数量不能太少。
5.Failure domain ----这个概念在论文中并没有进行定义,此处不过多解释
基于上述定义,Ceph中的寻址至少要经历下面三次映射✌️
1️⃣ File->object 这次映射的目的是,将用户要操作的file,映射为RADOS能够处理的object。其映射十分简单,本质上就是按照object的最大size对file进行切分。这种切分的好处有2点。一是让大小不限的file变成最大size一致、可以被RADOS高效管理的object;二是让对单一file实施的串行处理变为多个object实施并行化处理
每一个切分后产生的object将获得唯一的oid,即object id。其产生方式也是线性映射,图中ino是待操作file的元数据,可以简单理解为该file的唯一id。ono则是由该file切分产生的某个object的序号。而oid就是将这个序号简单连缀在该file id之后得到的。
举例而言,如果一个id为filename的file被切分成了三个object,则其object序号依次为0、1和2,而最终得到oid就依次为filename0、filename1和filename2. 这里隐含的问题是,ino的唯一性必须得到保障,否则后续无法正常进行
2️⃣ Object->PG映射 在file映射为一个或多个object之后,就需要将每个object独立地映射到一个PG中去
计算公式如下
hash(oid) & mask -> pgid
- 1
由此可见,其计算由两步组成。首先是使用Ceph系统指定的静态哈希函数计算oid的哈希值,将oid映射成一个近似均衡分布的伪随机值。然后,将这个随机值和mask按位相与,得到最终的PG序号(pgid)。根据RADOS的设计,给定PG的总数为m(m应该是为2的整数),则mask的值为-1。因此,哈希值计算和操作结果事实上是从所有m个PG中近似均匀的随机选择一个。基于这个机制,当有大量的object和大量PG时,RADOS能够保证object和PG之间的近似均匀映射。又因为object是由file切分而来,大部分object的soze相同,因而这一映射最终保证了,各个PG中存储的object的总数据量近似均匀
只有当object和PG的数量较多时,这种伪随机关系的近似均匀性才能成立,Ceph的数据存储均匀性才有保证。为保证大量成立,以方便,object的最大size应该被合理配置,以使得同样数量的file能够被切分更多的object;另一方面,Ceph推荐PG总数应该为OSD总数的数百倍,以保证有足够数量的PG可供映射。
3️⃣PG->OSD映射 第三次映射就是作为object的逻辑组织单元的PG映射到数据的实际存储单元OSD,RADOS采用一个名为CRUSH的算法,将pgid带入其中,然后得到一共n个OSD。这n个OSD即共同负责存储和维护一个PG中所有的object。前面已经描述,n的数值可以根据实际应用中对于可靠性的需求而配置,生产环境通常为3.具体到每个OSD。则由其上的OSD daemon负责执行映射到本地的object在本地文件系统中的存储、访问、元数据维护等操作
和object->PG映射中采用的哈希算法不同,这个CCRUSH
算法的结果不是绝对不变的,而是受到其他因素的影响。其影响因素主要有二点:
一是当前系统状态,也就是上文逻辑结构中曾经提及的cluster map。当系统中的OSD状态、数量发生变化时,cluster map可能发生变化,而这种变化会影响到PG与OSD之间的映射
二是存储策略配置。这里的策略主要与安全相关,利用策略配置,系统管理员可以指定承载同一个PG的3个OSD分别位于数据中心的不同服务器乃至机架上,从而进一步改善存储的可靠性。
因此,只有在系统状态cluster map和存储策略都不发生变化的时候,PG和OSD之间的映射关系才是稳定不变的。在实际使用中,策略已经配置通常不会改变。而系统状态的改变或者是由于设备损坏,或者是因为存储集群规模扩大。好在Ceph本身提供了对这种变化的自动化支持。因而,即便PG与OSD之间的映射关系发生了变化,也并不会对应用造成困扰。事实上,Ceph正是需要有目的的利用这种动态映射关系。正是利用了CRUSH的动态特性,Ceph可以将一个PG根据需要动态迁移到不同的OSD组合上,从而自动化地实现高可靠性、数据分布性等。
至此为止,Ceph通过三次映射,完成了从file到object、PG和OSD整个映射过程。通过整个过程可以看到没有任何的全局性查表操作需求。至于唯一的全局性数据结构cluster map的维护和操作都是轻量级的,不会对系统的可扩展性、性能等因素造成不良的影响
一个可能出现困惑的问题:为什么需要同时设计出第二次和第三次映射?难道不重复吗
如果没有PG这一层映射,通过算法将object直接映射到一组OSD上。如果这种算法是某种固定映射的哈希算法,则意味着一个object将被固定在一组OSD上,当其中一个或多个OSD损坏时,object无法被自动迁移至其他OSD上(因为映射函数不允许),当系统为了扩容新增了OSD时,object也无法被re-balance到新的OSD上(同样因为函数不允许)这些限制都违背了Ceph系统的高可靠性、高自动化的设计初衷
例如,在Ceph的现有机制中,一个OSD平时需要和与其共同承载一个PG的其他OSD交换信息,以确定各自是否工作正常,是否需要进行维护操作。由于一个OSD上约承载数百个PG,每个PG内通常有3个OSD,因此,一个OSD大约需要进行数百至数千次OSD信息交换
然后,如果没有PG的存在,则一个OSD需要和与其共同承载同一个object的其他OSD交换信息。由于每个OSD上承载的object很可能高达数百万个,因此同样长度的一段时间内,一个OSD大约需要进行的OSD间信息交换将暴涨至数百万乃至数千万次。而这种状态维护成本显然过高
总结:引入PG的好处有两种,一方面实现了object和OSD之间的动态映射,从而为Ceph的可靠性、自动化性等特征的实现留下了空间;另一方面也有效简化了数据的存储组织,大大降低了系统的维护管理开销。
1.4 Ceph集群
前面说过,monitor共同负责整个Ceph集群中所有OSD状态的发现与记录,并且共同形成cluster map的master版本,然后扩散至全体OSD以及client。OSD使用cluster map进行数据的维护,而client 使用cluster map进行数据的寻址。
在集群中,各个monitor的功能总体上是一样的,其相互间的关系可以简单理解为主从备份关系。monitor并不主动轮询各个OSD的当前状态。正相反,OSD需要向monitor上报信息状态。常见的上报情况有两种:一是新的OSD被加入集群,二是某个OSD发现自身或者其他OSD发生异常。在收到这些上报信息,monitor将更新cluster map的信息并加以扩散。
Cluster map包含如下内容 命令:ceph -s
(1) Eposh 即版本号。Cluster map的epoch是一个单调递增序列。Epoch越大,则cluster map版本越新。因此,持有不同版本cluster map的OSD或client可以简单的通过比较epoch决定应该遵从谁手中的版本。而monitor手中必定有epoch最大、版本最新的cluster map。当任意两方在通信时发现彼此epoch值不同时,将默认先将cluster map同步至高版本一方的状态。在进行后续状态
(2) health 集群内部健康状态,显示这台服务器在集群内部的状态
(3) monmap 各个OSD的网络地址
(4) osdmap 各个OSD的状态。OSD状态分为两个维度:up或者down (表示OSD是否正常工作),in或者out (表示OSD是否在至少一个PG中)。因此,对于任意一个OSD,共有四种可能的状态
状态 | 说明 |
---|---|
Up且in | 说明该OSD正常运行,且已经承载至少一个PG的数据。这是一个OSD的标准工作状态; |
Up且out | 明该OSD正常运行,但并未承载任何PG,其中也没有数据。一个新的OSD刚刚被加入Ceph集群后,便会处于这一状态。而一个出现故障的OSD被修复后,重新加入Ceph集群时,也是处于这一状态; |
Down且yin | 说明该OSD发生异常,但仍然承载着至少一个PG,其中仍然存储着数据。这种状态下的OSD刚刚被发现存在异常,可能仍能恢复正常,也可能会彻底无法工作 |
Down且out | 说明该OSD已经彻底发生故障,且已经不再承载任何PG |
(5) pgmap 集群中pg、pools、磁盘大小等信息
1.5 Ceph特点
介绍了这么多ceph的信息,我们这里做一个总结
- 高性能 a.摒弃了传统的集中式存储元数据寻址的方案,采用CHUSH算法,数据分布均衡,并行度高。 b.考虑了容灾域的隔离,能够实现各类的副本放置规则,例如跨机房、机架感知等。 c.能够支持上千个存储节点的规模,支持TB到PB的数据
- 高可用性 a.副本数可以灵活控制。 b.支持故障域分隔,数据强一致性。 c.多种故障场景自动进行修复自愈。 d.没有单点故障,自动管理。
- 高可扩展性 a.去中心化。 b.扩展灵活 c.随着节点增加而线性增长
- 特性丰富 a.支持三种存储接口:块存储、文件存储、对象存储 b.支持自定义接口,支持多种语言驱动
1.6 Ceph架构
Ceph支持三种接口
- Object:有原生的API,并且也兼容Swift和S3的api
- Block:支持精简配置、快照和克隆
- File:Posix接口、支持快照
1.7 Ceph核心组件及概念
组件 | 概念 |
---|---|
Monitor | 一个Ceph集群需要多个Monitor组成的小集群,它们通过Paxos同步数据,用来保存OSD的元数据 |
OSD | OSD负责相应客户端请求返回具体数据的进程,一个Ceph集群一般都有很多个OSD |
MSD | msd全称Cepg Metadata Service,是CephFs服务依赖的元数据服务 |
Object | Ceph最底层的存储单位是Object对象,每个Object包含元数据和原始数据 |
PG | PG全称Placement Groups,是一个逻辑的概念,一个PG包含多个OSD。引入PG这一层其实是为了更好的分配数据和定位数据 |
RADOS | 是Ceph集群的精华,为用户实现数据分配,Failover等集群操作 |
Libradio | Libradio是Rados提供库,因为RADOS是协议很难直接访问,因此上层的RBD、RGW和CephFs都是通过librados访问的目前提供PHP、Ruby、Java、Python等支持 |
CRUSH | CRUSH是Ceph使用的数据分布算法,类似一致性哈希,让数据分配到预期的地方。 |
RBD | RBD全称RADOS block device,是Ceph对外提供的块设备服务 |
RGW | RGW全称RADOS gateway,是Ceph对外提供的对象存储服务,接口与S3和Swift兼容 |
CephFs | CephFs全称Ceph File System,是Ceph对外提供的文件系统服务 |
Pool | pool 是Ceph存储时的逻辑分区,它起到namespace的作用 |
二、三种存储类型
2.1 块存储 rbd
典型设备:磁盘阵列,硬盘 主要是将裸磁盘空间映射给主机使用的
优点
- 通过Raid与LVM等手段,对数据提供了保护
- 多块廉价的硬盘组合起来,提高容量
- 多块磁盘组合出来的逻辑盘,提高读写效率
缺点
- 采用SAN架构组网时,光纤交换机,造价成本高
- 主机之间无法共享数据
使用场景
- docker容器、虚拟机磁盘存储分配
- 日志存储
- 文件存储
- 等等…
2.2 文件存储 fs
典型设备:FTP、NFS服务器 为了克服块存储文件无法共享的问题,所以有了文件存储。在服务器上架设FTP与NFS服务,就是文件存储
优点
- 造价低,随便一台机器就可以了
- 方便文件共享
缺点
- 读写速度低
- 传输速度慢
使用场景
- 日志存储
- 有目录结构的文件存储
2.3 对象存储 rgw
典型设备:内置大容量硬盘的分布式服务器(swift、s3) 多台服务器内置大容量硬盘,安装上对象存储管理软件,对外提供读写访问功能。
优点
- 具备块存储的读写高速
- 具备文件存储的共享等特性
使用场景 (适合更新变动比较少的数据)
- 图片存储
- 视频存储
3.1 正常io流程图
1.client创建cluster handler 2.client读取配置文件 3.client连接上monitor,获取集群map信息 4.client读写io根据crshmap算法请求对应的主osd数据节点 5.主osd数据节点同时写入另外两个副本节点数据 6.等待主节点以及两个副本节点写完数据状态 7.主节点及副本节点写入状态都成功后,返回给client,io写入完成。
3.2 新主io流程图
如果有新加入的OSD1取代了原有的OSD4成为Primary OSD,由于OSD1上未创建PG,不存在数据,那么PG上的IO无法进行,如何工作呢?
流程:
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变成副本
3.3 Ceph IO算法流程
在1.3Ceph存储过程 (Ceph IO算法流程)
中我们已经详细介绍了,这里只是简单过一下
1.File用户需要读写的文件。 File->映射成Object
- a.ino(File的元数据,File的唯一ID)
- b.ono (File切分产生的某个Object的序号,默认以4M切分一个块大小
- c.oid (object id:ino+one)
2.Object是RADOS需要的对象。Ceph指定一个静态的hash函数计算oid的值,将oid映射成一个近似均匀分布的伪随机值,然后和mask按位相与,得到pgid。 Object->映射PG
- a.bash (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)
3.4 Ceph RBD IO 流程 & Ceph RBD IO框架图
流程 1.客户端创建一个pool,需要为这个pool指定pg的数量 2.创建pool/image rdb设备进行挂载 3.用户写入的数据进行切块,每个块的大小默认为4M,并且每个块都有一个名字,名字就是object+序号 4.将每个object通过pg进行副本位置的分配 5.pg根据cursh算法会寻找3个osd,把这个object分别保存在这三个osd上 6.osd上实际是把底层disk进行了格式化操作,一般部署工具会将它格式化为xfs文件系统 7.object的存储就变成了存储一个文rbd0.object1.file
客户端写数据OSD过程
1.采用的是librados的形式,使用librbd创建一个块设备,向这个块设备中写入数据 2.在客户端本地通过调用librados接口,然后经过pool、rdb、pg进行层层映射,在PG这一层,可以知道数据保存在哪3个OSD上,这3个OSD分为主从的关系 3.客户端primay OSD简历SOCKET通信,将要写入的数据传给primary OSD,由primary OSD再讲数据发送给其他replica OSD数据节点
3.5 Ceph Pool和PG分布情况
说明:
- pool是ceph存储数据时的逻辑分区,它起到namespace的作用
- 每个pool包含一定数量(可配置)的PG
- PG里的对象被映射到不同的Object上
- pool是分布到整个集群的
- pool可以做故障隔离域,根据不同的用户场景不一进行隔离
Ceph数据扩容PG分布
- 现状3个OSD,4个PG
- 扩容到4个OSD,4个PG
现状:
扩容后:
每个OSD上分布很多PG,并且每个PG会自动散落在不同的OSD上。如果扩容那么相应的PG会进行迁移到新的OSD上,保证PG数量的均衡。
3.6 Ceph 心跳机制
1.心跳介绍 心跳是用于节点间检测对方是否故障的,以便及时发现故障节点进入相应的故障处理流程。
问题
- 故障时间和心跳报文带来的负载之间做权衡
- 心跳频率太高则过多的心跳会影响系统性能。
- 心跳频率过低则会延长发现故障点的时间,从而影响系统的可用性。
故障检测策略优点
- 及时:节点发生异常如宕机或网络中断时,集群可以在可接受的时间范围内感知
- 适当的压力:包括对节点的压力,和对网络的压力
- 容忍网络抖动:网络偶尔延迟
- 扩散机制:节点存活状态改变导致的元信息变化需要通过某种机制扩散到整个集群。
2.心跳检测
点会监听public、cluster、front和back四个端口
一、网安学习成长路线图
网安所有方向的技术点做的整理,形成各个领域的知识点汇总,它的用处就在于,你可以按照上面的知识点去找对应的学习资源,保证自己学得较为全面。
二、网安视频合集
观看零基础学习视频,看视频学习是最快捷也是最有效果的方式,跟着视频中老师的思路,从基础到深入,还是很容易入门的。
三、精品网安学习书籍
当我学到一定基础,有自己的理解能力的时候,会去阅读一些前辈整理的书籍或者手写的笔记资料,这些笔记详细记载了他们对一些技术点的理解,这些理解是比较独到,可以学到不一样的思路。
四、网络安全源码合集+工具包
光学理论是没用的,要学会跟着一起敲,要动手实操,才能将自己的所学运用到实际当中去,这时候可以搞点实战案例来学习。
五、网络安全面试题
最后就是大家最关心的网络安全面试题板块
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!