Ceph：关于 Ceph 存储架构理论方面的一些笔记整理(2)

已于 2025-01-28 08:51:09 修改
阅读量1k 收藏 3
点赞数 3
CC 4.0 BY-SA版权
分类专栏： 零基础入门Ceph 文章标签： ceph 架构 笔记
于 2023-05-12 09:20:02 首次发布
© 2018-2023 [email protected], All rights reserved. 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)
本文链接：https://blog.csdn.net/sanhewuyang/article/details/130635012

写在前面

  • 准备考试，整理ceph 相关笔记
  • 博文内容涉及，Ceph 架构/核心组件和对应的映射介绍
  • 理解不足小伙伴帮忙指正

对每个人而言，真正的职责只有一个：找到自我。然后在心中坚守其一生，全心全意，永不停息。所有其它的路都是不完整的，是人的逃避方式，是对大众理想的懦弱回归，是随波逐流，是对内心的恐惧 ——赫尔曼·黑塞《德米安》

Ceph 存储架构

Ceph 集群搭建使用标准硬件和存储设备的服务器,是一个高度可扩展的分布式存储系统, 采用模块化分布式架构。Ceph 主要通过 RADOS 核心组件来提供能力。以及与 RADOS 交互的多种访问方式构成

RADOS 是 Ceph 的底层对象存储服务，由 OSD 守护进程组成，而 Ceph 集群中的其他组件如 MON、MDS 和 RGW 等也都是守护进程，各自扮演着不同的角色和功能。OSD 进程是 Ceph 存储集群中的核心组件之一，负责将数据分散存储在多个节点和磁盘上，并提供高可用性、容错性和可靠性等特性。RADOS 是一种自我修复、自我管理的软件型对象存储

Ceph 中的核心组件并不一定是守护进程，RADOS 是核心组件，而不是守护进程本身。

RADOS(Reliable Autonomic Distributed Object Store) :可靠的自主分布式对象存储,RADOS 是一种 自我修复、自我管理 的软件型对象存储, Ceph 也同时支持块存储，和文件存储，这里实际上是在对象存储的基础上封装了一层，提供块存储和文件存储的能力。

Ceph 存储核心组件

Ceph集群的核心组件主要包括:

  1. MON (Monitor Daemon) : 集群监控, 守护进程,MON 负责监控 Ceph 集群的状态、配置和拓扑结构，并将这些信息保存在 Ceph Monitor 数据库(Store）中。Ceph 集群至少需要三个 MON 进程来保证高可用性。在集群中可以配置不同的选举方式。
  2. OSD (Object Storage Daemon): 对象存储设备,守护进程,存储数据并处理数据复制、恢复和重新平衡,
  3. MGR (Managers,ceph-mgr): 管理器(非必须),守护进程,通过基于浏览器的仪表板和 REST API，跟踪运行时指标并公开集群信息
  4. MDS (Metadata Servers): 元数据服务器,守护进程,存储供 CephFS 使用的元数据(而非对象存储或块存储)，让客户端能够高效执行 POSIX 命令。CephFS是基于 RADOS 实现的分布式文件系统，可提供与传统文件系统类似的功能。

部分组件以守护进程的方式运行，可以以副本形式扩展，以满足部署的存储集群的要求。

Ceph 监控器 MON

Ceph 监控器 (MON) 是维护集群映射主要副本的守护进程,是用于监控和管理集群状态、拓扑结构和配置信息的组件之一。MON 组件通常由多个进程组成，以提高可用性和容错性。

在这里插入图片描述

集群映射（Cluster Map）是指将 Ceph 集群中的各个组件（如 OSD、MON、MDS、RGW 等）映射到实际的网络地址和端口号的过程。Ceph 集群映射由五种不同的映射组成的集合，包括:OSD 映射集合/MON 映射集合/MDS 映射集合/RGW 映射集合/CRUSH 映射集合/

这五种映射集合共同构成了 Ceph 集群映射，用于实现各个组件之间的通信和协作，并支持数据的高可用性、可靠性和性能。

通过集群映射，客户端和其他组件可以找到并连接正确的 OSD、MON、MDS、RGW 进程，并使用 CRUSH 算法来计算数据位置和副本策略。

我理解，所谓集群映射，就是一个配置中心，用于维护映射K和具体配置。

Ceph 生产至少需要三台机器，根据官方的 Ceph 文档，建议在 Ceph 集群中至少使用三台机器以确保数据冗余和可用性。但是，可以使用少于三台机器运行 Ceph 集群，但不建议在生产环境中这样做。

在后端组件的基础上多了 CRUSH映射， Ceph 必须处理每个集群事件，更新合适的映射，并将更新后的映射复制到每个监控器守护进程，若要应用更新，MON 必须就集群状态 建立共识。

[ceph: root@clienta /]#  ceph health
HEALTH_OK
[ceph: root@clienta /]# ceph status
  cluster:
    id:     2ae6d05a-229a-11ec-925e-52540000fa0c
    health: HEALTH_OK

  services:
    mon: 4 daemons, quorum serverc.lab.example.com,clienta,serverd,servere (age 84m)
    mgr: clienta.nncugs(active, since 47h), standbys: servere.kjwyko, serverc.lab.example.com.aiqepd, serverd.klrkci
    osd: 9 osds: 9 up (since 47h), 9 in (since 3y)
    rgw: 2 daemons active (2 hosts, 1 zones)

  data:
    pools:   5 pools, 105 pgs
    objects: 221 objects, 4.9 KiB
    usage:   700 MiB used, 89 GiB / 90 GiB avail
    pgs:     105 active+clean

[ceph: root@clienta /]# ceph mon stat -f json-pretty

{
    "epoch": 4,
    "min_mon_release_name": "pacific",
    "num_mons": 4,
    "leader": "serverc.lab.example.com",
    "quorum": [
        {
            "rank": 0,
            "name": "serverc.lab.example.com"
        },
        {
            "rank": 1,
            "name": "clienta"
        },
        {
            "rank": 2,
            "name": "serverd"
        },
        {
            "rank": 3,
            "name": "servere"
        }
    ]
}
[ceph: root@clienta /]#

这要求配置的监控器中有多数可用且就映射更新达成共识，为 Ceph 集群配置奇数个监控器，以确保监控器能在就集群状态投票时建立仲裁，配置的监控器中必须有 超过半数正常发挥作用 ，Ceph 存储集群才能运行并可访问，这是保护集群数据的完整性所必需的。

在 Ceph 集群运行期间，MON 进程需要相互通信并就下列事项达成共识：

  • 集群状态：每个 MON 进程都要了解 Ceph 集群的当前状态，如 OSD 的在线状态、PG 的映射关系、数据副本的位置等等。
  • 健康状况：每个 MON 进程需要收集和汇总所有 OSD 和 PG 的健康报告，并根据报告指示的问题推断出整个集群的健康状况。
  • 拓扑结构：每个 MON 进程需要知道 Ceph 集群的拓扑结构，并为客户端请求和数据复制提供正确的路由和路径。
  • 配置信息：每个 MON 进程需要了解集群的配置信息，如 MON 和 OSD 的数量、PG 的数量和策略、CRUSH 映射规则等等。

因此，MON 必须就集群状态建立共识，才能保证整个 Ceph 集群的正确运行和数据的可靠存储。如果 MON 无法建立共识，那么可能会导致数据丢失、访问失败、性能下降等问题。

Ceph 对象存储设备 OSD

Ceph 对象存储设备 (OSD) 是 Ceph 存储集群的构建块，OSD 将存储设备(如硬盘或其他块设备)连接到 Ceph 存储集群。

一台存储服务器可以运行多个 OSD 守护进程，并为集群提供多个 OSD，Ceph 旧版本要求 OSD 存储设备具有底层文件系统，但 BlueStore 以原始模式使用本地存储设备，不在需要文件系统，这有助于提升性能

Ceph 客户端和 OSD 守护进程都使用 可扩展哈希下的受控复制 (CRUSH, Controlled Replication Under Scalable Hashing) 算法来高效地计算对象位置的信息，而不依赖中央服务器查找

在高层次上，CRUSH 算法通过使用分层树结构将数据对象映射到存储设备上。树是基于存储设备的物理拓扑结构构建的，树中的每个节点表示一组设备(放置组PG)。然后，算法使用确定性函数将每个数据对象映射到树中的叶节点，该叶节点对应于特定的存储设备。

在这里插入图片描述

CRUSH 算法的一个关键优点是它被设计为高度容错。由于算法是确定性的，即使某些设备失败，也可以重构数据对象到存储设备的映射。这使得即使在硬件故障的情况下，也可以保持数据可用性

[ceph: root@clienta /]# ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME         STATUS  REWEIGHT  PRI-AFF
-1         0.08817  root default
-3         0.02939      host serverc
 0    hdd  0.00980          osd.0         up   1.00000  1.00000
 1    hdd  0.00980          osd.1         up   1.00000  1.00000
 2    hdd  0.00980          osd.2         up   1.00000  1.00000
-5         0.02939      host serverd
 3    hdd  0.00980          osd.3         up   1.00000  1.00000
 5    hdd  0.00980          osd.5         up   1.00000  1.00000
 7    hdd  0.00980          osd.7         up   1.00000  1.00000
-7         0.02939      host servere
 4    hdd  0.00980          osd.4         up   1.00000  1.00000
 6    hdd  0.00980          osd.6         up   1.00000  1.00000
 8    hdd  0.00980          osd.8         up   1.00000  1.00000
[ceph: root@clienta /]#

CRUSH (keruasi) 将每个对象分配给单个哈希存储桶，称为放置组 (PG)，也就是上面我们讲的树的节点。

PG 是对象(应用层)和 OSD(物理层)之间的抽象层，CRUSH 使用伪随机放置算法在 PG 之间分布对象，并且使用规则来确定 PG 到 OSD 的映射。

[ceph: root@clienta /]# ceph pg dump
version 85450
stamp 2024-12-27T14:55:21.226718+0000
last_osdmap_epoch 0
last_pg_scan 0
PG_STAT  OBJECTS  MISSING_ON_PRIMARY  DEGRADED  MISPLACED  UNFOUND  BYTES  OMAP_BYTES*  OMAP_KEYS*  LOG   DISK_LOG  STATE         STATE_STAMP                      VERSION    REPORTED    UP       UP_PRIMARY  ACTING   ACTING_PRIMARY  LAST_SCRUB  SCRUB_STAMP                      LAST_DEEP_SCRUB  DEEP_SCRUB_STAMP                 SNAPTRIMQ_LEN
4.19           0                   0         0          0        0      0            0           0     0         0  active+clean  2024-12-26T16:35:23.813579+0000        0'0     208:170  [6,2,5]           6  [6,2,5]               6         0'0  2024-12-26T16:35:23.813517+0000              0'0  2024-12-25T15:21:40.146533+0000              0
2.1f           0                   0         0          0        0      0            0           0     0         0  active+clean  2024-12-26T22:04:14.186051+0000        0'0     208:174  [0,3,8]           0  [0,3,8]               0         0'0  2024-12-26T22:04:14.185926+0000              0'0  2024-12-25T15:21:10.365897+0000              0
3.1e           6                   0         0          0        0      0            0           0  8071      8071  active+clean  2024-12-26T21:42:52.796788+0000   208'8071   208:12273  [2,6,3]           2  [2,6,3]               2    208'5998  2024-12-26T21:42:52.796646+0000         197'2348  2024-12-25T15:21:15.187010+0000              0
4.18           0                   0         0          0        0      0            0           0     0         0  active+clean  2024-12-26T16:34:29.535090+0000        0'0     208:185  [3,2,6]           3  [3,2,6]               3         0'0  2024-12-26T16:34:29.535055+0000              0'0  2024-12-25T15:20:17.473197+0000              0
2.1e           0                   0         0          0        0      0            0           0     0         0  active+clean  2024-12-26T19:48:19.274977+0000        0'0     208:170  [2,6,5]           2  [2,6,5]               2         0'0  2024-12-26T19:48:19.274864+0000              0'0  2024-12-25T15:20:10.429178+0000              0
3.1f           6                   0         0          0        0    110            0           0  6737      6737  active+clean  2024-12-27T01:09:11.294472+0000   208'6737   208:10298  [0,3,4]           0  [0,3,4]               0    208'5353  2024-12-27T01:09:11.294413+0000         193'1964  2024-12-25T15:20:39.512382+0000              0
4.1b           0                   0         0          0        0      0            0           0     0         0  active+clean  2024-12-26T17:42:05.926100+0000        0'0     208:186  [3,2,8]           3  [3,2,8]               3         0'0  2024-12-26T17:42:05.926048+0000              0'0  2024-12-25T15:21:11.396736+0000              0
2.1d           0                   0         0          0        0      0            0           0     0         0  active+clean  2024-12-27T00:21:12.315462+0000        0'0     208:172  [6,7,0]           6  [6,7,0]               6         0'0  2024-12-27T00:21:12.315380+0000              0'0  2024-12-25T15:20:28.642644+0000              0
3.1c           7                   0         0          0        0    110            0           0  9706      9706  active+clean  2024-12-26T18:39:02.018596+0000   208'9906   208:14991  [5,1,6]           5  [5,1,6]               5    208'6898  2024-12-26T18:39:02.018551+0000         199'2905  2024-12-25T15:21:36.508246+0000              0
4.1a           0                   0         0          0        0      0            0           0     0         0  active+clean  2024-12-27T03:12:19.088918+0000        0'0     208:170  [3,0,4]           3  [3,0,4]               3         0'0  2024-12-27T03:12:19.088864+0000              0'0  2024-12-25T15:20:42.164822+0000              0
2.1c           0                   0         0          0        0      0            0           0     0         0  active+clean  2024-12-27T02:09:25.316389+0000        0'0     208:169  [8,7,1]           8  [8,7,1]               8         0'0  2024-12-27T02:09:25.316270+0000              0'0  2024-12-25T15:20:02.347202+0000              0
3.1d           6                   0         0          0        0    220            0           0  5411      5411  active+clean  2024-12-26T21:57:51.826969+0000   208'5411    208:8324  [8,3,1]           8  [8,3,1]               8    208'4038  2024-12-26T21:57:51.826919+0000         198'1595  2024-12-25T15:21:32.659303+0000              0
4.1d           0                   0         0          0        0      0            0           0     0         0  active+clean  2024-12-26T20:19:27.795615+0000        0'0     208:168  [4,7,1]           4  [4,7,1]               4         0'0  2024-12-26T20:19:27.795541+0000              0'0  2024-12-25T15:20:22.034633+0000              0
2.1b           0                   0         0          0        0      0            0           0     0         0  active+clean  2024-12-26T22:06:39.408345+0000        0'0     208:172  [6,7,2]           6  [6,7,2]               6         0'0  2024-12-26T22:06:39.408260+0000              0'0  2024-12-25T15:21:32.753330+0000              0
3.1a           6                   0         0          0        0    110            0           0  5110      5110  active+clean  2024-12-26T22:02:20.750169+0000   208'5110    208:7869  [4,1,7]           4  [4,1,7]               4    208'3806  2024-12-26T22:02:20.750090+0000         199'1458  2024-12-25T15:21:37.498993+0000              0
4.1c           0                   0         0          0        0      0            0           0     0         0  active+clean  2024-12-26T17:34:23.591368+0000        0'0     208:168  [4,1,3]           4  [4,1,3]               4         0'0  2024-12-26T17:34:23.591326+0000              0'0  2024-12-25T15:21:08.501325+0000              0
2.1a           0                   0         0          0        0      0            0           0     0         0  active+clean  2024-12-26T22:10:45.275675+0000        0'0     208:171  [5,8,2]           5  [5,8,2]               5         0'0  2024-12-26T22:10:45.275637+0000              0'0  2024-12-25T15:21:34.676865+0000              0
3.1b           3                   0         0          0        0    110            0           0  1918      1918  active+clean  2024-12-26T17:00:56.709449+0000   208'1918    208:3091  [4,7,1]           4  [4,7,1]               4    208'1290  2024-12-26T17:00:56.709402+0000          197'566  2024-12-25T15:21:23.993004+0000              0
4.1f           1                   0         0          0        0      0            0           0    11        11  active+clean  2024-12-27T07:45:48.199757+0000     208'11   208:97396  [6,5,1]           6  [6,5,1]               6      208'11  2024-12-26T20:54:36.980990+0000           208'11  2024-12-26T20:54:36.980990+0000              0
2.19           1                   0         0          0        0    358            0           0     2         2  active+clean  2024-12-26T23:20:32.788520+0000      197'2     208:182  [0,3,8]           0  [0,3,8]               0       197'2  2024-12-26T23:20:32.788480+0000            197'2  2024-12-25T15:21:12.134123+0000              0
3.18           5                   0         0          0        0    110            0           0  5122      5122  active+clean  2024-12-26T23:18:49.366183+0000   208'5122    208:7876  [2,6,7]           2  [2,6,7]               2    208'3918  2024-12-26T23:18:49.366082+0000         197'1508  2024-12-25T15:21:23.415590+0000              0
4.1e           0                   0         0          0        0      0            0           0     0         0  active+clean  2024-12-27T00:34:54.143838+0000        0'0     208:170  [0,7,6]           0  [0,7,6]               0         0'0  2024-12-27T00:34:54.143773+0000              0'0  2024-12-25T15:20:41.365635+0000              0
2.18           0                   0         0          0        0      0            0           0     0         0  active+clean  2024-12-26T19:39:31.410432+0000        0'0     208:169  [4,7,2]           4  [4,7,2]               4         0'0  2024-12-26T19:39:31.410365+0000              0'0  2024-12-25T15:21:16.541192+0000              0
3.19          11                   0         0          0        0    110            0           0  7167      7167  active+clean  2024-12-26T18:13:45.357053+0000  208'10067   208:15374  [1,5,6]           1  [1,5,6]               1    208'6960  2024-12-26T18:13:45.357016+0000         191'2943  2024-12-25T15:20:04.008711+0000              0
.....................................

5    0  0  0  0  0     0  0  0       0       0
4    8  0  0  0  0     0  0  0      82      82
3  209  0  0  0  0  3702  0  0  216809  216809
1    0  0  0  0  0     0  0  0       0       0
2    4  0  0  0  0  1323  0  0       8       8

sum  221  0  0  0  0  5025  0  0  216899  216899
OSD_STAT  USED     AVAIL    USED_RAW  TOTAL   HB_PEERS           PG_SUM  PRIMARY_PG_SUM
0          75 MiB  9.9 GiB    75 MiB  10 GiB  [1,2,3,4,5,6,7,8]      34              14
8          79 MiB  9.9 GiB    79 MiB  10 GiB  [0,1,2,3,4,5,6,7]      32              10
7          61 MiB  9.9 GiB    61 MiB  10 GiB  [0,1,2,3,4,5,6,8]      35               6
2          48 MiB  9.9 GiB    48 MiB  10 GiB  [0,1,3,4,5,6,7,8]      29               9
1          91 MiB  9.9 GiB    91 MiB  10 GiB  [0,2,3,4,5,6,7,8]      42              11
3          77 MiB  9.9 GiB    77 MiB  10 GiB  [0,1,2,4,5,6,7,8]      39              13
4          67 MiB  9.9 GiB    67 MiB  10 GiB  [0,1,2,3,5,6,7,8]      34              14
5          76 MiB  9.9 GiB    76 MiB  10 GiB  [0,1,2,3,4,6,7,8]      31              15
6          80 MiB  9.9 GiB    80 MiB  10 GiB  [0,1,2,3,4,5,7,8]      39              13
sum       653 MiB   89 GiB   653 MiB  90 GiB

* NOTE: Omap statistics are gathered during deep scrub and may be inaccurate soon afterwards depending on utilization. See http://docs.ceph.com/en/latest/dev/placement-group/#omap-statistics for further details.
dumped all
[ceph: root@clienta /]#

出现故障时，Ceph 将 PG 重新映射到不同的物理设备 (OSD) ，并同步其内容以匹配配置的数据保护规则，一个 OSD 是对象放置组的主要 OSD，Ceph 客户端在读取或写入数据时始终联系操作集合中的主要 OSD，其他 OSD 为次要 OSD，在确保集群故障时的数据弹性方面发挥重要作用

Primary OSD 的功能：

  • 服务所有 I/O 请求
  • 复制和保护数据
  • 检查数据的一致性
  • 重新平衡数据
  • 恢复数据

次要 OSD 的功能(备份)：

  • 行动始终受到 Primary OSD 的控制
  • 能够变为 Primary OSD

每个 OSD 具有自己的 OSD ⽇志。OSD 日志提供了对 OSD 实施写操作的性能。

来自 Ceph 客户端 的写操作本质上通常是随机的 I/O，由 OSD 守护进程顺序写入到日志中。当涉及的所有 OSD 日志记录了写请求后，Ceph 将每个写操作确认到客户端，OSD 然后将操作提交到其后备存储。

每隔几秒钟，OSD 会停止向日志写入新的请求，以将 OSD日志的内容应用到后备存储，然后，它会修剪日志中的已提交请求，回收日志存储设备上的空间

当 Ceph OSD 或其存储服务器出现故障时，Ceph 会在 OSD 重新启动后重演其日志，重演序列在最后一个已同步的操作后开始，因为 Ceph 已将同步的日志记录提交到 OSD 的存储，OSD日志使用OSD 节点上的原始卷，若有可能，应在单独的SSD等快速设备上配置日志存储

要查看 Ceph 集群的 OSD（Object Storage Daemon）服务信息，可以使用 Ceph 自带的命令行工具 ceph 命令。以下是一些常用的命令：

  • ceph osd tree：显示 OSD 树，即显示每个 OSD 的编号、主机名、状态、容量等信息，以及 CRUSH 算法对存储设备的映射关系。
[ceph: root@clienta /]# ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME         STATUS  REWEIGHT  PRI-AFF
-1         0.08817  root default
-3         0.02939      host serverc
 0    hdd  0.00980          osd.0         up   1.00000  1.00000
 1    hdd  0.00980          osd.1         up   1.00000  1.00000
 2    hdd  0.00980          osd.2         up   1.00000  1.00000
-5         0.02939      host serverd
 3    hdd  0.00980          osd.3         up   1.00000  1.00000
 5    hdd  0.00980          osd.5         up   1.00000  1.00000
 7    hdd  0.00980          osd.7         up   1.00000  1.00000
-7         0.02939      host servere
 4    hdd  0.00980          osd.4         up   1.00000  1.00000
 6    hdd  0.00980          osd.6         up   1.00000  1.00000
 8    hdd  0.00980          osd.8         up   1.00000  1.00000
[ceph: root@clienta /]#
  • ceph osd df：显示 OSD 的使用情况，包括总容量、已用空间、可用空间等信息。
[ceph: root@clienta /]# ceph osd df
ID  CLASS  WEIGHT   REWEIGHT  SIZE    RAW USE  DATA     OMAP     META     AVAIL    %USE  VAR   PGS  STATUS
 0    hdd  0.00980   1.00000  10 GiB   75 MiB  2.3 MiB      0 B   72 MiB  9.9 GiB  0.73  1.01   34      up
 1    hdd  0.00980   1.00000  10 GiB   91 MiB  2.4 MiB      0 B   88 MiB  9.9 GiB  0.89  1.22   42      up
 2    hdd  0.00980   1.00000  10 GiB   48 MiB  2.3 MiB      0 B   46 MiB  9.9 GiB  0.47  0.65   29      up
 3    hdd  0.00980   1.00000  10 GiB   76 MiB  2.4 MiB      0 B   74 MiB  9.9 GiB  0.75  1.03   39      up
 5    hdd  0.00980   1.00000  10 GiB   76 MiB  2.3 MiB      0 B   74 MiB  9.9 GiB  0.74  1.02   31      up
 7    hdd  0.00980   1.00000  10 GiB   77 MiB  2.3 MiB      0 B   74 MiB  9.9 GiB  0.75  1.03   35      up
 4    hdd  0.00980   1.00000  10 GiB   67 MiB  2.4 MiB      0 B   64 MiB  9.9 GiB  0.65  0.90   34      up
 6    hdd  0.00980   1.00000  10 GiB   80 MiB  2.3 MiB      0 B   77 MiB  9.9 GiB  0.78  1.07   39      up
 8    hdd  0.00980   1.00000  10 GiB   79 MiB  2.4 MiB      0 B   76 MiB  9.9 GiB  0.77  1.06   32      up
                       TOTAL  90 GiB  667 MiB   21 MiB  8.5 KiB  646 MiB   89 GiB  0.72
MIN/MAX VAR: 0.65/1.22  STDDEV: 0.11
[ceph: root@clienta /]#
  • ceph osd pool ls：列出所有的 OSD 数据存储池，包括数据存储池名称、ID 等信息。
[ceph: root@clienta /]# ceph osd pool ls
device_health_metrics
.rgw.root
default.rgw.log
default.rgw.control
default.rgw.meta
[ceph: root@clienta /]#
  • ceph osd pool stats：显示 OSD 数据存储池的使用情况，包括存储池大小、已用空间、剩余空间等。
[ceph: root@clienta /]# ceph osd pool stats
pool device_health_metrics id 1
  nothing is going on

pool .rgw.root id 2
  nothing is going on

pool default.rgw.log id 3
  nothing is going on

pool default.rgw.control id 4
  nothing is going on

pool default.rgw.meta id 5
  nothing is going on

[ceph: root@clienta /]#

  • ceph tell osd.* bench：对 OSD 进行性能测试，以便评估 OSD 的性能和稳定性。

  • ceph tell osd.* query：查询所有 OSD 进程的状态和性能数据，包括 IOPS、延迟等指标。

Ceph 管理器 MGR

Ceph 管理器 (MGR) 提供一系列集群统计数据，集群中不可用的管理器不会给 客户端 I/O操作带来负面影响。在这种情况下，尝试查询集群统计数据会失败，可以在不同的故障域中部署至少两个 Ceph 管理器提升可用性

管理器守护进程将集群中收集的所有数据的访问集中到一处，并通过 TCP 端⼝ 7000(默认)向存储管理员提供一个简单的 Web 仪表板。

在这里插入图片描述

它还可以将状态信息导出到外部 Zabbix 服务器，将性能信息导出到 Prometheus。Ceph 指标是一种基于 collectd 和 grafana 的监控解决方案，可补充默认的仪表板

在这里插入图片描述

查看 Ceph 集群的 MGR（Manager）服务信息，可以使用 Ceph 自带的命令行工具 ceph 命令。以下是一些常用的命令：

  • ceph mgr module ls：列出所有加载的 MGR 模块，包括模块名称、状态等信息。
  • ceph mgr module enable <module-name>：启用指定的 MGR 模块，以便进行管理和监控。
  • ceph mgr services：显示所有的 MGR 服务，包括进程 ID、名称、状态等信息。
[ceph: root@clienta /]# ceph mgr services
{
    "dashboard": "https://172.25.250.10:8443/",
    "prometheus": "http://172.25.250.10:9283/"
}
[ceph: root@clienta /]#
  • ceph daemon <mgr-id> perf dump：显示指定 MGR 进程的性能监控信息，包括 CPU 使用率、内存使用情况等。

元数据服务器 MDS

Ceph 元数据服务器(MDS)管理 Ceph 文件系统(CephFS)元数据。

它提供兼容 POSIX 的共享文件系统元数据管理，包括所有权、时间戳和模式。MDS 使用 RADOS 而非本地存储来存储其元数据，它无法访问文件内容

MDS 可让 CephFS 与 Ceph 对象存储交互，将索引节点映射到对象，并在树内映射 Ceph 存储数据的位置，访问 CephFS 文件系统的客户端首先向 MDS 发出请求，这会提供必要的信息以便从正确的 OSD 获取文件内容

Ceph 访问方式

Ceph 提供四种访问 Ceph 集群的方法：

  1. RGW(RADOS Gateway) :RADOS 网关,守护进程,RGW 是一个 REST 接口，使得客户端可以通过 HTTP 或 S3 协议来访问 Ceph 存储集群中的对象。RGW 可以将 Ceph 集群中的对象作为 Web 资源来公开，从而实现与 Amazon S3 兼容的对象存储服务。
  2. RBD（RADOS Block Device）：Ceph 块设备，将 Ceph 存储集群的对象存储能力暴露为块设备，支持虚拟机和容器等应用的块存储需求。
  3. Ceph 原生 API (librados)
  4. Ceph 文件系统（CephFS、libcephfs）

在这里插入图片描述

Ceph 块设备 RBD

RBD 全称为 RADOS Block Device，它将 Ceph 存储集群的对象存储能力暴露为块设备，支持虚拟机和容器等应用的块存储需求。RBD 的作用如下：

  • 块存储：RBD 提供了块存储服务，支持虚拟机和容器等应用使用块设备进行数据存储和访问。
  • 快照和克隆：RBD 支持块设备的快照和克隆功能，可以对块设备进行备份和恢复，以及基于现有块设备创建新的块设备。
  • 多租户支持：RBD 支持多租户功能，可以将一个 RBD 集群划分为多个租户，每个租户拥有自己的块设备空间和访问权限，可以避免资源的冲突和干扰。
  • 弹性伸缩：RBD 可以根据需求进行水平扩展和缩减，支持动态调整存储容量和性能，具有高度的弹性和灵活性。

要查看 Ceph 中 RBD 的服务信息，可以使用以下命令：

  • rbd ls：显示所有的 RBD 块设备，包括块设备名称、大小等信息。
  • rbd info <image>：显示指定 RBD 块设备的信息，包括块设备 ID、大小、快照数等信息。
  • rbd snap ls <image>：列出指定 RBD 块设备的所有快照，包括快照名称、创建时间等信息。
  • rbd du：显示 RBD 块设备的使用情况，包括总使用容量、总可用容量等信息。
  • rbd map <image>：将指定的 RBD 块设备映射为本地块设备，以便进行数据读写操作。

RBD 提供下列功能：

  1. Ceph 集群中虚拟磁盘的存储
  2. Linux 内核中的挂载支持
  3. QEMU、KVM 和 OpenStack Cinder 的启动支持

RADOS 网关 RGW

RADOS Gateway（ RGW） 提供了 S3 和 Swift 接口兼容的对象存储服务，可以将 Ceph 存储集群暴露为云存储服务。RADOS Gateway 的作用如下：

  • 对象存储：RADOS Gateway 提供了基于 S3 和 Swift 接口兼容的对象存储服务，支持大规模、高并发的数据访问和管理。用户可以使用标准的 S3 或 Swift 客户端库进行对象存储。
  • 数据访问控制：RADOS Gateway 支持多种认证和授权方式，可以对不同的用户或应用程序进行权限控制，保障数据的安全性和隐私性。
  • 数据可靠性：RADOS Gateway 使用 RADOS 集群作为底层存储设备，具有高可靠性和高可用性，可以保障数据的持久性和可靠性。
  • 多租户支持：RADOS Gateway 支持多租户功能，可以将一个 RGW 集群划分为多个租户，每个租户拥有自己的存储空间和访问权限，可以避免资源的冲突和干扰。
  • 弹性伸缩：RADOS Gateway 可以根据需求进行水平扩展和缩减，支持动态调整存储容量和性能，具有高度的弹性和灵活性。

要查看 Ceph 集群的 RGW（RADOS Gateway）服务信息，可以使用 Ceph 自带的命令行工具 radosgw-admin 命令。以下是一些常用的命令：

  • radosgw-admin user list：列出所有的 RGW 用户，包括用户 ID、显示名称等信息。
  • radosgw-admin bucket list：列出所有的 RGW 存储桶，包括存储桶名称、拥有者等信息。
  • radosgw-admin quota get --uid=<user-id>：显示指定用户的配额信息，包括存储空间配额、对象数配额等。
  • radosgw-admin policy list：列出所有的 RGW 策略，包括策略名称、权限等信息。
  • radosgw-admin usage show：显示集群的 RGW 使用情况，包括总请求数、总流量等信息。
  • radosgw-admin metadata list：列出集群中所有的 RGW 元数据，包括实体 ID、实体类型、元数据键值对等信息。
[ceph: root@clienta /]# radosgw-admin user list
[]
[ceph: root@clienta /]# radosgw-admin bucket list
[]
[ceph: root@clienta /]# radosgw-admin policy list
Command not found: policy list
[ceph: root@clienta /]# radosgw-admin usage show
{
    "entries": [],
    "summary": []
}
[ceph: root@clienta /]# radosgw-admin metadata list
[
    "bucket",
    "bucket.instance",
    "otp",
    "user"
]
[ceph: root@clienta /]#

Ceph 对象网关提供扩展支持，它不限制可部署的网关数量，而且支持标准的 HTTP 负载均衡器。它解决的这些案例包括：

  1. 镜像存储（例如，SmugMug 和 Tumblr）
  2. 备份服务
  3. 文件存储和共享（例如，Dropbox）

Ceph 文件系统 (CephFS)

Ceph 文件系统 (CephFS) 是一种并行文件系统，提供可扩展的、单层级结构共享磁盘，Ceph 元数据服务器 (MDS) 管理与 CephFS 中存储的文件关联的元数据 ，这包括文件的访问、更改和修改时间戳等信息

Ceph 原生API (librados)

librados 是原生C 库，允许应用直接使用RADOS 来访问 Ceph 集群中存储的对象，有可以用C++、Java、Python、Ruby、Erlang 和 PHP，编写软件以直接与 librados 配合使用可以提升性能，为了简化对 Ceph 存储的访问，也可以改为使用提供的更高级访问方式，如 RADOS 块设备、Ceph 对象网关 (RADOSGW) 和 CephFS

集群映射

Ceph 客户端和对象存储守护进程 OSD 需要确认集群拓扑。五个映射表示集群拓扑，统称为集群映射。

Ceph 监控器(Mon)守护进程维护集群映射的主副本。Ceph MON 集群在监控器守护进程出现故障时确保高可用性

监控器映射

包含集群 fsid、各个监控器的位置、名称、地址和端口，以及映射时间戳。

使用 ceph mon dump 来查看监控器映射。fsid 是一种自动生成的唯⼀标识符 (UUID)，用于标识 Ceph 集群

[ceph: root@serverc /]# ceph mon dump
epoch 5
fsid 4c759c0c-d869-11ed-bfcb-52540000fa0c
last_changed 2023-04-11T13:34:50.058049+0000
created 2023-04-11T13:03:51.482001+0000
min_mon_release 16 (pacific)
election_strategy: 1



0: [v2:172.25.250.12:3300/0,v1:172.25.250.12:6789/0] mon.serverc.lab.example.com
1: [v2:172.25.250.13:3300/0,v1:172.25.250.13:6789/0] mon.serverd
2: [v2:172.25.250.14:3300/0,v1:172.25.250.14:6789/0] mon.servere
dumped monmap epoch 5
[ceph: root@serverc /]#
  • epoch：监视器映射的时代编号。
  • fsid：Ceph集群的唯一标识符。
  • last_changed：修改监视器映射的时间。
  • created：创建监视器映射的时间。
  • min_mon_release：与监视器映射兼容的最小Ceph版本。
  • election_strategy：监视器用于选举领导者的策略。Ceph监视器的选举策略有两种：
    • classic：这是默认的选举策略，在此策略下，监视器具有相同的投票权，并根据周期性心跳和消息传递进行通信。如果监视器检测到其他监视器离线，则它们将在一段时间后进入新的领导者选举过程。
    • quorum：该策略要求至少三个监视器在线，并从中选择领导者，而不是所有在线监视器都拥有相同的投票权。采用此策略时，如果没有足够的监视器参与选举，则集群将无法正常工作或处于只读状态，直到更多的监视器加入并恢复其大多数选举能力。
  • 0、1、2：集群中每个监视器的排名和IP地址，以及它们的主机名。
  • dumped：表示已成功转储指定时代的监视器映射。
OSD 映射

包含集群 fsid、池列表、副本大小、放置组编号、OSD 及其状态的列表，以及映射时间戳。使用 ceph osd dump 查看 OSD 映射

[ceph: root@serverc /]# ceph osd dump
epoch 77
fsid 4c759c0c-d869-11ed-bfcb-52540000fa0c
created 2023-04-11T13:03:54.016381+0000
modified 2023-04-25T07:46:25.481881+0000
flags sortbitwise,recovery_deletes,purged_snapdirs,pglog_hardlimit
crush_version 24
full_ratio 0.95
backfillfull_ratio 0.9
nearfull_ratio 0.85
require_min_compat_client luminous
min_compat_client jewel
require_osd_release pacific
stretch_mode_enabled false
pool 1 'device_health_metrics' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 1 pgp_num 1 autoscale_mode on last_change 74 flags hashpspool stripe_width 0 pg_num_min 1 application mgr_devicehealth
max_osd 9
osd.0 up   in  weight 1 up_from 71 up_thru 0 down_at 70 last_clean_interval [50,65) [v2:172.25.250.12:6800/2046452011,v1:172.25.250.12:6801/2046452011] [v2:172.25.250.12:6802/2046452011,v1:172.25.250.12:6803/2046452011] exists,up 82c98821-3c02-468a-8e2f-7c5dfc2a0fbe
osd.1 up   in  weight 1 up_from 68 up_thru 23 down_at 67 last_clean_interval [50,65) [v2:172.25.250.12:6808/260025682,v1:172.25.250.12:6809/260025682] [v2:172.25.250.12:6810/260025682,v1:172.25.250.12:6811/260025682] exists,up 1ca3352b-4c2d-4a85-86cc-33d1715c1915
.......
blocklist 172.25.250.12:0/1295757381 expires 2023-04-26T07:42:28.540520+0000
blocklist 172.25.250.12:6825/3489966617 expires 2023-04-26T07:42:28.540520+0000
blocklist 172.25.250.12:6824/3489966617 expires 2023-04-26T07:42:28.540520+0000
  • epoch：OSD映射的时代编号。
  • fsid：Ceph集群的唯一标识符。
  • created：创建OSD映射的时间。
  • modified：修改OSD映射的时间。
  • flags：包含有关 OSD 映射状态的标志位，这些标志位都是用来控制 Ceph 集群中 OSD的行为和状态，以便最大程度地提高性能和可靠性。如 sortbitwise、recovery_deletes、purged_snapdirs 和 pglog_hardlimit 等。
    • sortbitwise：开启了每个对象单独排序，这可以优化存储分配和数据分布。
    • recovery_deletes：在恢复过程中删除陈旧的对象，以避免占用空间和影响性能。
    • purged_snapdirs：快照目录已从PG日志中删除，以节省空间并提高性能。
    • pglog_hardlimit：PG日志达到硬限制时强制转储日志，以保持一致性并避免性能问题。
  • crush_version：CRUSH映射版本号。
    • full_ratio：当 OSD 的使用量达到该值时，将触发警告（如果开启了警告）并阻止新数据写入 OSD。默认值为 0.95。
  • full_ratio、backfillfull_ratio 和 nearfull_ratio：用于控制OSD空间利用率的比率。
    • backfillfull_ratio：当 OSD 在后期重新填充时，其使用量达到该值时，将阻止进一步的后期重新填充操作。默认值为 0.9。
    • nearfull_ratio：当 OSD 的使用量达到该值时，将向 Ceph 发送慢操作警告。默认值为 0.85。
  • require_min_compat_client、min_compat_client 和 require_osd_release：最低客户端和OSD版本限制。
  • stretch_mode_enabled：是否启用了伸缩模式。该模式允许将数据复制到远程位置，以实现跨区域灾难恢复和数据备份。
  • pool：Ceph 存储池的相关信息，例如 size、min_size、pg_num、pgp_num 等等。
    • pool 1：这是存储池的编号，Ceph 存储集群中的每个存储池都有一个唯一的编号。
    • device_health_metrics：这是存储池的名称，通常用于描述存储池中存储的对象类型或数据用途。
    • replicated：这是存储池的副本模式，表示该存储池中的数据将被复制到多个 OSD 上以实现高可用性和冗余。
    • size 3 和 min_size 2：这些是存储池的副本大小设置。size 3 表示每个对象将被复制到 3 个不同的 OSD 上，而 min_size 2 表示在执行写入操作时至少要在 2 个 OSD 上成功复制数据才会视为写入成功。
    • crush_rule 0：这是使用的 CRUSH 规则的编号，CRUSH 是 Ceph 集群用于计算数据位置的分布式算法，该规则规定了如何将数据分散到存储设备上。
    • object_hash rjenkins：这是用于确定对象位置的哈希函数。在这种情况下，rjenkins 是一种快速哈希函数，能够快速生成对象位置。
    • pg_num 1 和 pgp_num 1：这些是该存储池中的 PG 数量和 PGP 数量。PG 是 Ceph 存储池中数据的基本组织单元，它们将对象分配到 OSD 上以实现负载均衡。
    • autoscale_mode on：这是存储池的自动扩展设置，表示在存储池满时是否自动扩展存储池大小。此处设置为“开启”。
    • last_change 74：这是最后修改存储池配置的时间戳，通常用于跟踪存储池配置更改历史记录。
    • flags hashpspool stripe_width 0 pg_num_min 1：这些是其他存储池标志，如使用哈希池（hashpspool）、条带宽度（stripe_width）和最小 PG 数量（pg_num_min）等。
    • application mgr_devicehealth：这是存储池的应用程序类型，表示该存储池用于存储设备健康度信息的管理数据。
  • max_osd：OSD的最大数量。
  • osd.X：每个OSD的详细信息，包括其状态、权重、IP地址、端口、在PG中的位置等等。
  • blocklist：列出被阻止或禁止使用的IP地址列表。
放置组 (PG) 映射

包含 PG 版本、全满比率、每个放置组的详细信息，例如 PG ID、就绪集合、操作集合、PG 状态、每个池的数据使用量统计、以及映射时间戳。使用ceph pg dump查看包含的 PG 映射统计数据

PG_STAT  OBJECTS  MISSING_ON_PRIMARY  DEGRADED  MISPLACED  UNFOUND  BYTES  OMAP_BYTES*  OMAP_KEYS*  LOG  DISK_LOG  STATE         STATE_STAMP                      VERSION  REPORTED  UP       UP_PRIMARY  ACTING   ACTING_PRIMARY  LAST_SCRUB  SCRUB_STAMP                      LAST_DEEP_SCRUB  DEEP_SCRUB_STAMP                 SNAPTRIMQ_LEN
4.19           0                   0         0          0        0      0            0           0    0         0  active+clean  2023-04-30T05:50:02.431578+0000      0'0    108:12  [7,2,5]           7  [7,2,5]               7         0'0  2023-04-30T05:50:01.330091+0000              0'0  2023-04-30T05:50:01.330091+0000              0
2.1f           0                   0         0          0        0      0            0           0    0         0  active+clean  2023-04-30T05:49:47.320452+0000      0'0    108:17  [0,3,8]           0  [0,3,8]               0         0'0  2023-04-30T05:49:46.202749+0000              0'0  2023-04-30T05:49:46.202749+0000              0
3.1e           0                   0         0          0        0      0            0           0    0         0  active+clean  2023-04-30T05:49:49.349973+0000      0'0    108:15  [2,6,3]           2  [2,6,3]               2         0'0  2023-04-30T05:49:48.270032+0000              0'0  2023-04-30T05:49:48.270032+0000              0
4.18           0                   0         0          0        0      0            0           0    0         0  active+clean  2023-04-30T05:50:02.449439+0000      0'0    108:12  [3,1,6]           3  [3,1,6]               3         0'0  2023-04-30T05:50:01.330091+0000              0'0  2023-04-30T05:50:01.330091+0000              0
  • PG_STAT: PG 的状态，表示 PG 在当前时间点内的活动情况和健康状况。 PG_STAT 数字由两部分组成，第一部分是十六进制的 OSD 编号，第二部分是十六进制的 epoch 号。
  • OBJECTS: PG 中对象数量。
  • MISSING_ON_PRIMARY: 在 primary OSD 上缺少的对象数量。
  • DEGRADED: 在副本 OSD 上损坏或不可用的对象数量。
  • MISPLACED: 在非预期 OSD 上的对象数量。
  • UNFOUND: 未找到的对象数量。
  • BYTES: PG 中对象的总字节数。
  • OMAP_BYTES: PG 中对象元数据的总字节数。
  • OMAP_KEYS: PG 中对象元数据键值对的总数。
  • LOG: 最近操作日志的序列号范围。
  • DISK_LOG: 存储在磁盘上的日志序列号范围。
  • STATE: PG 的状态，例如“active+clean”。
  • STATE_STAMP: PG 最后转换到当前状态的时间戳。
  • VERSION: PG 的版本。
  • REPORTED: 汇报 PG 状态的 OSD 的编号。
  • UP: 处于活动状态的 OSD 编号列表。
  • UP_PRIMARY: 作为主 OSD 进行同步的 OSD 编号。
  • ACTING: 负责读写请求的 OSD 编号列表。
  • ACTING_PRIMARY: 正在执行同步操作的 OSD 编号。
  • LAST_SCRUB: 上次 scrub 的时间戳和结果。
  • SCRUB_STAMP: 上次 scrub 的结束时间戳。
  • LAST_DEEP_SCRUB: 上次 deep scrub 的时间戳和结果。
  • SNAPTRIMQ_LEN: PgSnapTrimq 中等待处理的数量。
  • DEEP_SCRUB_STAMP: 上次 deep scrub 的结束时间戳。
CRUSH 映射

包含存储设备的列表、故障域层次结构(例如设备、主机、机架、行、机房)，以及存储数据时层次结构的规则，Crush Map 是 Ceph 存储集群的关键组件之一，用于定义数据如何分布到存储设备（如 OSD）上。 Crush Map 包含 bucket、设备和 ruleset 三个主要组件，结合使用可以定义数据的分布和副本策略。

若要查看CRUSH 映射，

  • 首先使用 ceph osd getcrushmap -o comp-filename，
  • 使用 crushtool -d comp-filename -o decomp-filename 解译该输出
  • 使用文本编辑器查看解译后的映射
[root@serverc ~]# cephadm shell
Inferring fsid 4c759c0c-d869-11ed-bfcb-52540000fa0c
Inferring config /var/lib/ceph/4c759c0c-d869-11ed-bfcb-52540000fa0c/mon.serverc.lab.example.com/config
Using recent ceph image registry.redhat.io/rhceph/rhceph-5-rhel8@sha256:6306de945a6c940439ab584aba9b622f2aa6222947d3d4cde75a4b82649a47ff
[ceph: root@serverc /]# ceph osd getcrushmap -o comp-filename
27
[ceph: root@serverc /]# crushtool -d comp-filename -o decomp-filename
[ceph: root@serverc /]# cat de
decomp-filename  dev/
[ceph: root@serverc /]# cat decomp-filename
# begin crush map
tunable choose_local_tries 0
tunable choose_local_fallback_tries 0
tunable choose_total_tries 50
tunable chooseleaf_descend_once 1
tunable chooseleaf_vary_r 1
tunable chooseleaf_stable 1
tunable straw_calc_version 1
tunable allowed_bucket_algs 54

# devices
device 0 osd.0 class hdd
device 1 osd.1 class hdd
device 2 osd.2 class hdd
device 3 osd.3 class hdd
device 4 osd.4 class hdd
device 5 osd.5 class hdd
device 6 osd.6 class hdd
device 7 osd.7 class hdd
device 8 osd.8 class hdd

# types
type 0 osd
type 1 host
type 2 chassis
type 3 rack
type 4 row
type 5 pdu
type 6 pod
type 7 room
type 8 datacenter
type 9 zone
type 10 region
type 11 root

# buckets
host serverc {
        id -3           # do not change unnecessarily
        id -4 class hdd         # do not change unnecessarily
        # weight 0.029
        alg straw2
        hash 0  # rjenkins1
        item osd.0 weight 0.010
        item osd.1 weight 0.010
        item osd.2 weight 0.010
}
host serverd {
        id -5           # do not change unnecessarily
        id -6 class hdd         # do not change unnecessarily
        # weight 0.029
        alg straw2
        hash 0  # rjenkins1
        item osd.3 weight 0.010
        item osd.4 weight 0.010
        item osd.5 weight 0.010
}
host servere {
        id -7           # do not change unnecessarily
        id -8 class hdd         # do not change unnecessarily
        # weight 0.029
        alg straw2
        hash 0  # rjenkins1
        item osd.6 weight 0.010
        item osd.7 weight 0.010
        item osd.8 weight 0.010
}
root default {
        id -1           # do not change unnecessarily
        id -2 class hdd         # do not change unnecessarily
        # weight 0.088
        alg straw2
        hash 0  # rjenkins1
        item serverc weight 0.029
        item serverd weight 0.029
        item servere weight 0.029
}

# rules
rule replicated_rule {
        id 0
        type replicated
        min_size 1
        max_size 10
        step take default
        step chooseleaf firstn 0 type host
        step emit
}

# end crush map
[ceph: root@serverc /]#
元数据服务器 (MDS) 映射

包含用于存储元数据的池、元数据服务器列表、元数据服务器状态和映射时间戳。查看包含 ceph fs dump 的 MDS映射

[ceph: root@serverc /]# ceph fs dump
e1
enable_multiple, ever_enabled_multiple: 1,1
compat: compat={},rocompat={},incompat={1=base v0.20,2=client writeable ranges,3=default file layouts on dirs,4=dir inode in separate object,5=mds uses versioned encoding,6=dirfrag is stored in omap,8=no anchor table,9=file layout v2,10=snaprealm v2}
legacy client fscid: -1

No filesystems configured
dumped fsmap epoch 1
[ceph: root@serverc /]#

运行 ceph fs dump 命令后的输出结果。以下是每个字段的含义：

  • e1: 当前文件系统的 epoch 号。
  • enable_multiple, ever_enabled_multiple: 1,1: 文件系统是否启用了多 MDS 支持并且曾经启用过。
  • compat: 文件系统支持的兼容性特性，包括三个字段（compat、rocompat 和 incompat），其中 compat 表示 CephFS 要求支持的最低版本，而 rocompat 和 incompat 分别表示与只读客户端和不兼容客户端相关的特性。
  • legacy client fscid: -1: 指定将 legacy 客户端分配给文件系统的 ID，但当前没有 legacy 客户端连接到该文件系统。
  • No filesystems configured: 表示当前没有配置任何文件系统。
  • dumped fsmap epoch 1: 表示已成功输出当前 Ceph 集群的文件系统映射。

博文部分内容参考

© 文中涉及参考链接内容版权归原作者所有，如有侵权请告知，这是一个开源项目，如果你认可它，不要吝啬星星哦 😃

https://docs.ceph.com/en/pacific/architecture/

https://github.com/ceph/ceph

https://docs.ceph.com

RHCA CL260 授课笔记

© 2018-至今 liruilonger@gmail.com, All rights reserved. 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)

Ceph分布式存储架构
Besokuse__End的博客
03-31 318
Ceph分布式存储架构搭建 分布式的原理： 分布式文件系统( Distributed File System)是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。简单来说，就是把一些分散的(分布在局域网内各个计算机上)共享文件夹，集合到一个文件夹内(虚拟共享文件夹)。对于用户来说，要访问这些共享文件夹时，只要打开这个虚拟共享文件夹，就可以看到所有链接到虚拟共享文件夹内的共享文件夹，用户感觉不到这些共享文件是分散于各个计算机上的。分布式文件系统的好处是集中访问、简化操作、数
Ceph实战（一）-分布式存储介绍与原理架构概述
2401_84046645的博客
04-23 921
至此，文章终于到了尾声。技术能力：先写岗位所需能力，再写加分能力，不要写无关能力；项目经历：只写明星项目，描述遵循 STAR 法则；简历印象：简历遵循三大原则：清晰，简短，必要，要有的放矢，不要海投；以及最后为大家准备的福利时间：简历模板+Java面试题+热门技术系列教程视频《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！要海投；以及最后为大家准备的福利时间：简历模板+Java面试题+热门技术系列教程视频。
Ceph分布式存储系统架构研究综述
朱小厮的博客
07-01 482
点击上方“朱小厮的博客”，选择“设为星标”后台回复"书"，获取后台回复“k8s”，可领取k8s资料Ceph项目是加州大学圣克鲁兹分校的 Weil于2006年开发的。当时他发...
Ceph存储集群手动部署指南
最新发布
gitblog_01106的博客
06-02 421
Ceph存储集群手动部署指南 概述 Ceph是一个开源的分布式存储系统，提供高性能、高可靠性和高扩展性的存储服务。本文将详细介绍如何手动部署一个基础的Ceph存储集群，包括监控器(Monitor)、对象存储设备(OSD)以及可选的管理器(Manager)等核心组件。 集群架构规划 一个基本的Ceph集群需要至少包含以下组件： 1个或多个Monitor节点（推荐3个以实现高可用） 多个OSD节点（...
ceph笔记
热爱我的热爱
07-11 265
1 Ceph基础介绍 Ceph是一个可靠地、自动重均衡、自动恢复的分布式存储系统，根据场景划分可以将Ceph分为三大块，分别是对象存储、块设备存储和文件系统服务。 在虚拟化领域里，比较常用到的是Ceph的块设备存储。 比如在OpenStack项目里，Ceph的块设备存储可以对接OpenStack的cinder后端存储、Glance的镜像存储和虚拟机的数据存储，比较直观的是Ceph集群可以提...
架构设计：系统存储（30）——分布式文件系统Ceph（RADOS结构）
JAVA入门中
04-29 9156
从本篇文章开始介绍一款现在非常火的分布式文件系统Ceph，包括这款文件系统的安装、基本使用场景、常用管理命令和重要工作原理。特别是讨论了PaxOS算法的基本理后，就更容易理解Ceph分布式文件系统中各种角色的工作原理。
Ceph学习笔记.pdf
12-16
通过阅读这份《Ceph学习笔记》，读者可以获得关于Ceph存储系统的基本理解和配置实践，特别是CRUSH算法、crush_class功能的使用和操作系统的兼容性等重要知识点。这对于希望深入理解Ceph或者从事Ceph相关工作的技术...
ceph 学习笔记
NLP家的码奴小荷的博客
01-27 3714
ceph 入门知识梳理
2024年网络安全最新Ceph工作原理详解_ceph作用(1)
2401_84264244的博客
05-03 726
这次映射的目的是，将用户要操作的file，映射为RADOS能够处理的object。其映射十分简单，本质上就是按照object的最大size对file进行切分。这种切分的好处有2点。一是让大小不限的file变成最大size一致、可以被RADOS高效管理的object；二是让对单一file实施的串行处理变为多个object实施并行化处理每一个切分后产生的object将获得唯一的oid，即object id。其产生方式也是线性映射，图中ino是待操作file的元数据，可以简单理解为该file的唯一id。
ceph学习笔记
hezhonglei的专栏
01-18 337
点击打开链接
【7】Ceph分布式存储架构搭建.docx
07-26
Ceph是一个开源的分布式文件系统。因为它还支持块存储、对象存储，所以很自然的被用做云计算框架openstack或cloudstack整个存储后端。当然也可以单独作为存储，例如部署一套集群作为对象存储、SAN存储、NAS存储等。 本文档主要讲述ceph集群的搭建和挂载方法等信息，仅供参考
ceph优秀博文
weixin_33862993的博客
12-02 95
ceph官方博文： http://ceph.com/community/blog/ rgw根据rgw用户来分pool存放数据 http://cephnotes.ksperis.com/blog/2014/11/28/placement-pools-on-rados-gw 源码相关 http://my.oschina.net/u/2271251/blog?disp=2&amp;p=1&am...
ceph 笔记整理
Man_In_The_Night的博客
12-31 622
ceph 查看、修改 crushmap 直接通过 ceph 命令 1、创建对应的root ceph osd crush add-bucket ssd root ceph osd crush add-bucket sas root 2、创建对应的host ceph osd crush add-bucket node-4-sata host ceph osd crush add-bucket node-5-sata host ceph osd crush add-bucket node-4-ssd host c
Ceph分布式存储笔记
追求幸福，探索未知的博客
04-10 1340
Ceph 分布式存储系统 块存储 文件存储 对象存储
Ceph学习笔记之一初识ceph
weixin_33834628的博客
07-19 308
一、Ceph概述 1、Ceph简介 Ceph是可靠的、可扩展的、统一的、分布式存储系统。Ceph可以同时提供对象存储RADOSGW（Reliable Autonomic Distributed Object Strorage Gateway）、块存储RBD（Rados Block Device）、文件系统存储CephFS（Ceph FileSystem) 3种功能...
【Ceph学习笔记】简介、集群部署与集群扩容
DeusExMachina_V的博客
07-11 667
简介、集群部署与集群扩容，常见命令与错误
Redhat Ceph存储之“深入理解Ceph架构”
架构师技术联盟
09-06 1217
本文由Ceph中国社区穆艳学翻译、耿航校稿，英文原文出处: Red_Hat_Ceph_Storage-2-Architecture_Guide (扫文尾二维码读原文)目录...
企业ceph分布式存储架构
花老头
10-28 431
概述 ceph是可靠的、可扩展的、统一的、开源分布式的存储系统。 ceph官方文档 http://docs.ceph.org.cn/ 　　ceph中文开源社区 http://ceph.org.cn/ ceph优点 统一存储 高扩展性 可靠性强 高性能 ceph应用场景 ceph可以提供对象存储、块设备存储和文件系统服务，其对象存储可以对接网盘应用业务等；其块设备存储可以对接，当前主流的laas云...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

山河已无恙

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值