CEPH原理

前言

最近用上了ceph，虽然了解得不够深入但还是写下笔记。ceph是一个无主节点或者说所有节点都是主节点的分布式文件系统。它具有高性能、高可用性、高可扩展性、特性丰富等特点。

• 高性能
  a. 摒弃了传统的集中式存储元数据寻址的方案，采用CRUSH算法，数据分布均衡，并行度高。
  b.考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。
  c. 能够支持上千个存储节点的规模，支持TB到PB级的数据。
• 高可用性
  a. 副本数可以灵活控制。
  b. 支持故障域分隔，数据强一致性。
  c. 多种故障场景自动进行修复自愈。
  d. 没有单点故障，自动管理。
• 高可扩展性
  a. 去中心化。
  b. 扩展灵活。
  c. 随着节点增加而线性增长。
• 特性丰富
  a. 支持三种存储接口：块存储、文件存储、对象存储。
  b. 支持自定义接口，支持多种语言驱动。

存储分类

块存储

典型设备： 磁盘阵列，硬盘

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

优点：
通过Raid与LVM等手段，对数据提供了保护。
多块廉价的硬盘组合起来，提高容量。
多块磁盘组合出来的逻辑盘，提升读写效率。

缺点：
采用SAN架构组网时，光纤交换机，造价成本高。
主机之间无法共享数据。

文件存储

典型设备： FTP、NFS服务器
为了克服块存储文件无法共享的问题，所以有了文件存储。
在服务器上架设FTP与NFS服务，就是文件存储。

优点：
造价低，随便一台机器就可以了。
方便文件共享。

缺点：
读写速率低。
传输速率慢。

对象存储

典型设备： 内置大容量硬盘的分布式服务器(swift, s3)
多台服务器内置大容量硬盘，安装上对象存储管理软件，对外提供读写访问功能。

优点：
具备块存储的读写高速。
具备文件存储的共享等特性。

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对外提供的文件系统服务。

各状态

• Activating
• Peering已经完成，PG正在等待所有PG实例同步并固化Peering的结果(Info、Log等)
• Active
  活跃态。PG可以正常处理来自客户端的读写请求
• Backfilling
  正在后台填充态。 backfill是recovery的一种特殊场景，指peering完成后，如果基于当前权威日志无法对Up Set当中的某些PG实例实施增量同步(例如承载这些PG实例的OSD离线太久，或者是新的OSD加入集群导致的PG实例整体迁移) 则通过完全拷贝当前Primary所有对象的方式进行全量同步
• Backfill-toofull
  某个需要被Backfill的PG实例，其所在的OSD可用空间不足，Backfill流程当前被挂起
• Backfill-wait
  等待Backfill 资源预留
• Clean
  干净态。PG当前不存在待修复的对象， Acting Set和Up Set内容一致，并且大小等于存储池的副本数
• Creating
  PG正在被创建
• Deep
  PG正在或者即将进行对象一致性扫描清洗
• Degraded
  降级状态。Peering完成后，PG检测到任意一个PG实例存在不一致(需要被同步/修复)的对象，或者当前ActingSet 小于存储池副本数
• Down
  Peering过程中，PG检测到某个不能被跳过的Interval中(例如该Interval期间，PG完成了Peering，并且成功切换至Active状态，从而有可能正常处理了来自客户端的读写请求),当前剩余在线的OSD不足以完成数据修复
• Incomplete
  Peering过程中， 由于 a. 无非选出权威日志 b. 通过choose_acting选出的Acting Set后续不足以完成数据修复，导致Peering无非正常完成
  Inconsistent 不一致态。集群清理和深度清理后检测到PG中的对象在副本存在不一致，例如对象的文件大小不一致或Recovery结束后一个对象的副本丢失
• Peered
  Peering已经完成，但是PG当前ActingSet规模小于存储池规定的最小副本数(min_size)
• Peering
  正在同步态。PG正在执行同步处理
• Recovering
  正在恢复态。集群正在执行迁移或同步对象和他们的副本
• Recovering-wait
  等待Recovery资源预留
• Remapped
  重新映射态。PG活动集任何的一个改变，数据发生从老活动集到新活动集的迁移。在迁移期间还是用老的活动集中的主OSD处理客户端请求，一旦迁移完成新活动集中的主OSD开始处理
• Repair
  PG在执行Scrub过程中，如果发现存在不一致的对象，并且能够修复，则自动进行修复状态
• Scrubbing
  PG正在或者即将进行对象一致性扫描
• Unactive
  非活跃态。PG不能处理读写请求
• Unclean
  非干净态。PG不能从上一个失败中恢复
• Stale
  未刷新态。PG状态没有被任何OSD更新，这说明所有存储这个PG的OSD可能挂掉, 或者Mon没有检测到Primary统计信息(网络抖动)
• Undersized
  PG当前Acting Set小于存储池副本数

数据的存储

Ceph 存储集群从 Ceph 客户端接收数据——不管是来自 Ceph 块设备、 Ceph 对象存储、 Ceph 文件系统、还是基于 librados 的自定义实现——并存储为对象。每个对象是文件系统中的一个文件，它们存储在对象存储设备上。由 Ceph OSD 守护进程处理存储设备上的读/写操作。

伸缩性和高可用性

Ceph 客户端和 OSD 守护进程都用 CRUSH 算法来计算对象的位置信息，而不是依赖于一个中心化的查询表。与以往方法相比， CRUSH 的数据管理机制更好，它很干脆地把工作分配给集群内的所有客户端和 OSD 来处理，因此具有极大的伸缩性。 CRUSH 用智能数据复制确保弹性，更能适应超大规模存储。

集群运行图
Ceph 依赖于 Ceph 客户端和 OSD ，因为它们知道集群的拓扑，这个拓扑由 5 张图共同描述，统称为“集群运行图”：

• Montior Map
  包含集群的 fsid 、位置、名字、地址和端口，也包括当前版本、创建时间、最近修改时间。要查看监视器图，用 ceph mon dump 命令。
• OSD Map
  包含集群 fsid 、创建时间、最近修改时间、存储池列表、副本数量、归置组数量、 OSD 列表及其状态（如 up 、 in ）。要查看OSD运行图，用 ceph osd dump 命令。
• PG Map
  包含归置组版本、其时间戳、最新的 OSD 运行图版本、占满率、以及各归置组详情，像归置组 ID 、 up set 、 acting set 、 PG 状态（如 active+clean ），和各存储池的数据使用情况统计。
• CRUSH Map
  包含存储设备列表、故障域树状结构（如设备、主机、机架、行、房间、等等）、和存储数据时如何利用此树状结构的规则。要查看 CRUSH 规则，执行 ceph osd getcrushmap -o {filename} 命令；然后用 crushtool -d {comp-crushmap-filename} -o {decomp-crushmap-filename} 反编译；然后就可以用 cat 或编辑器查看了。
• MDS Map
  包含当前 MDS 图的版本、创建时间、最近修改时间，还包含了存储元数据的存储池、元数据服务器列表、还有哪些元数据服务器是 up 且 in 的。要查看 MDS 图，执行 ceph mds dump 。

各运行图维护着各自运营状态的变更， Ceph 监视器维护着一份集群运行图的主拷贝，包括集群成员、状态、变更、以及 Ceph 存储集群的整体健康状况。

高可用监视器

Ceph 客户端读或写数据前必须先连接到某个 Ceph 监视器、获得最新的集群运行图副本。一个 Ceph 存储集群只需要单个监视器就能运行，但它就成了单一故障点（即如果此监视器宕机， Ceph 客户端就不能读写数据了）。

集群用多个监视器实现高可用性时，多个监视器用 Paxos 算法对主集群运行图达成一致，这里的一致要求大多数监视器都在运行且够成法定人数（如 1 个、 3 之 2 在运行、 5 之 3 、 6 之 4 等等）。

高可用性认证

为识别用户并防止中间人攻击， Ceph 用 cephx 认证系统来认证用户和守护进程。
Cephx 用共享密钥来认证，即客户端和监视器集群各自都有客户端密钥的副本。这样的认证协议使参与双方不用展现密钥就能相互认证，就是说集群确信用户拥有密钥、而且用户相信集群有密钥的副本。

• 设置用户
  
  client.admin 用户从命令行调用 ceph auth get-or-create-key 来生成一个用户及其密钥， Ceph 的认证子系统生成了用户名和密钥、副本存到监视器然后把此用户的密钥回传给 client.admin 用户，也就是说客户端和监视器共享着相同的密钥。

• 联动Monitor认证
  
  客户端得把用户名传给监视器，然后监视器生成一个会话密钥、并且用此用户的密钥加密它，然后把加密的凭证回传给客户端，客户端用共享密钥解密载荷就可获取会话密钥。会话密钥在当前会话中标识了此用户，客户端再用此会话密钥签署过的用户名请求一个凭证，监视器生成一个凭证、用用户的密钥加密它，然后回传给客户端，客户端解密此凭证，然后用它签署连接集群内 OSD 和元数据服务器的请求。

• 通讯
  
  cephx 协议认证客户端机器和 Ceph 服务器间正在进行的通讯，二者间认证完成后的每条消息都用凭证签署过，监视器、 OSD 、元数据服务器都可用此共享的密钥来校验这些消息。

复制

OSD 用 CRUSH 算法，但用于计算副本存到哪里（也用于重均衡）。一个典型的写情形是，一客户端用 CRUSH 算法算出对象应存到哪里，并把对象映射到存储池和归置组，然后查找 CRUSH 图来确定此归置组的主 OSD 。

客户端把对象写入目标归置组的主 OSD ，然后这个主 OSD 再用它的 CRUSH 图副本找出用于放对象副本的第二、第三个 OSD ，并把数据复制到适当的归置组所对应的第二、第三 OSD （要多少副本就有多少 OSD ），最终，确认数据成功存储后反馈给客户端。

PG 映射到 OSD

每个存储池都有很多归置组， CRUSH 动态的把它们映射到 OSD 。 Ceph 客户端要存对象时， CRUSH 将把各对象映射到某个归置组。

把对象映射到归置组在 OSD 和客户端间创建了一个间接层。由于 Ceph 集群必须能增大或缩小、并动态地重均衡。如果让客户端“知道”哪个 OSD 有哪个对象，就会导致客户端和 OSD 紧耦合；相反， CRUSH 算法把对象映射到归置组、然后再把各归置组映射到一或多个 OSD ，这一间接层可以让 Ceph 在 OSD 守护进程和底层设备上线时动态地重均衡。下列图表描述了 CRUSH 如何将对象映射到归置组、再把归置组映射到 OSD 。

有了集群运行图副本和 CRUSH 算法，客户端就能精确地计算出到哪个 OSD 读、写某特定对象。

互联和子集

OSD 守护进程相互检查心跳并回馈给监视器；它们的另一行为叫“互联（ peering ）”，这是一种把一归置组内所有对象（及其元数据）所在的 OSD 带到一致状态的过程。

Ceph 存储集群被设计为至少存储两份对象数据（即 size = 2 ），这是保证数据安全的最小要求。为保证高可用性， Ceph 存储集群应该保存两份以上的对象副本（如 size = 3 且 min size = 2 ），这样才能在degraded 状态继续运行，同时维持数据安全。

回想前面智能程序支撑超大规模中的图表，我们没明确地提 OSD 守护进程的名字（如 osd.0 、 osd.1 等等），而是称之为主、次、以此类推。按惯例，主 OSD 是 acting set 中的第一个 OSD ，而且它负责协调以它为主 OSD 的各归置组 的互联，也只有它会接受客户端到某归置组内对象的写入请求。

当一系列 OSD 负责一归置组时，这一系列的 OSD 就成为一个 acting set 。一个 acting set 对应当前负责此归置组的一组 OSD ，或者说截止到某个版本为止负责某个特定归置组的那些 OSD。

OSD 守护进程作为 acting set 的一部分，不一定总在 up 状态。当一 OSD 在 acting set 中是 up 状态时，它就是 up set 的一部分。 up set 是个重要特征，因为某 OSD 失败时 Ceph 会把 PG 映射到其他 OSD 。

重均衡

向 Ceph 存储集群新增一 OSD 守护进程时，集群运行图就要用新增的 OSD 更新。重新计算 PG ID ，这个动作会更改集群运行图，因此也改变了对象位置，因为计算时的输入条件变了。下面的图描述了重均衡过程（此图很粗略，因为在大型集群里变动幅度小的多），是其中的一些而不是所有 PG 都从已有 OSD （ OSD 1 和 2 ）迁移到新 OSD （ OSD 3 ）。即使在重均衡中， CRUSH 都是稳定的，很多归置组仍维持最初的配置，且各 OSD 都腾出了些空间，所以重均衡完成后新 OSD 上不会出现负载突增。

存储过程

1. File 箭头 ⇢ Object映射

File按照Object size（一般4M）切分成Object。
每个对象都会有一个唯一的OID，由ino与ono组成，ino即是文件的File ID，用于在全局唯一标示每一个文件，而ono则是分片的编号。

3. Object ⇢ PG映射

hash(oid) & mask ⇢ pgid

首先计算oid的哈希值并与PG的数量取模，得到pgid。因此，哈希值计算和按位与操作的整体结果事实上是从所有m个PG中近似均匀地随机选择一个。基于这一机制，当有大量object和大量PG时，RADOS能够保证object和PG之间的近似均匀映射。又因为object是由file切分而来，大部分object的size相同，因而，这一映射最终保证了，各个PG中存储的object的总数据量近似均匀。

4. PG ⇢ OSD映射

根据设置的副本数量进行复制，然后将pgid带入crush算法，存储到不同的OSD节点上（其实是把PG中的所有对象存储到节点上），第一个osd节点即为主节点，其余均为从节点。

PG-id = hash(pool-id). hash(objet-id) % PG-number

OSD-ids = CURSH(PG-id, cluster-map, cursh-rules)。

crush算法

CRUSH
CRUSH算法通过每个设备的权重来计算数据对象的分布。对象分布是由cluster map和data distribution policy决定的。cluster map描述了可用存储资源和层级结构(比如有多少个机架，每个机架上有多少个服务器，每个服务器上有多少个磁盘)。data distribution policy由placement rules组成。rule决定了每个数据对象有多少个副本，这些副本存储的限制条件(比如3个副本放在不同的机架中)。

CRUSH算出x到一组OSD集合(OSD是对象存储设备)：

(osd0, osd1, osd2 … osdn) = CRUSH(x)

OSD MAP
OSD MAP包含当前所有pool的状态和OSD的状态。OSDMap管理当前ceph中所有的OSD，OSDMap规定了crush算法的一个范围，在这个范围中选择OSD结合。OSDMap其实就是一个树形的结构，叶子节点是device（也就是osd），其他的节点称为bucket节点，这些bucket都是虚构的节点，可以根据物理结构进行抽象，当然树形结构只有一个最终的根节点称之为root节点，中间虚拟的bucket节点可以是数据中心抽象、机房抽象、机架抽象、主机抽象等如下图。

看到crush算法给我的感觉这不是和动态路由ospf一样么，每个节点保存一份map，通过算法计算出来路径。