ceph一些细节处理

/etc/ceph下的文件

复制代码

root@node3:~# ls /etc/ceph/
ceph.client.qemu.keyring  ceph.conf  rbdmap
root@node3:~# cat /etc/ceph/rbdmap
# RbdDevice             Parameters
#poolname/imagename     id=client,keyring=/etc/ceph/ceph.client.keyring
root@node3:~# cat /etc/ceph/ceph.conf 
# minimal ceph.conf for 30fb8914-d898-11f0-acd2-6d7eef4c5920
[global]
        fsid = 30fb8914-d898-11f0-acd2-6d7eef4c5920
        mon_host = [v2:192.168.244.128:3300/0,v1:192.168.244.128:6789/0] [v2:192.168.244.129:3300/0,v1:192.168.244.129:6789/0]
root@node3:~# cat /etc/ceph/ceph.client.qemu.keyring 
[client.qemu]
        key = AQClpz5pcwI1HhAA6hAliqtxgB05DPN1DQVppA==

上面是一些配置文件，分别是密钥环，集群配置文件

您提供的这几个文件是 Ceph 客户端（在本例中是 node3）用于连接和操作 Ceph 集群的核心配置文件和密钥文件。它们共同构成了客户端访问 RBD 块存储环境的基础。

下面我来详细解释每个文件的作用和重要性：

📂 核心文件作用解析1. ceph.conf (集群配置和连接信息)

bash 复制代码

# cat /etc/ceph/ceph.conf
[global]
        fsid = 30fb8914-d898-11f0-acd2-6d7eef4c5920
        mon_host = [v2:192.168.244.128:3300/0,v1:192.168.244.128:6789/0] [v2:192.168.244.129:3300/0,v1:192.168.244.129:6789/0]

作用： 这是 Ceph 客户端的主要配置文件，类似于网络上的"地址簿"。它告诉客户端如何找到集群的入口点。
关键内容：
fsid：集群的唯一标识符（文件系统 ID）。
mon_host：最重要。列出了集群中所有 Monitor (MON) 节点的 IP 地址和端口。客户端连接 Ceph 集群时，会首先尝试连接列表中的任一 Monitor，以获取集群的完整地图（CRUSH Map）和最新状态。
总结： 连接集群的路径和身份证明。

###2. ceph.client.qemu.keyring (用户身份密钥)

bash 复制代码

# cat /etc/ceph/ceph.client.qemu.keyring
[client.qemu]
        key = AQClpz5pcwI1HhAA6hAliqtxgB05DPN1DQVppA==

作用： 这是客户端使用 client.qemu 这个身份连接集群的密钥环文件 (Keyring File)。
关键内容：
[client.qemu]：指定了用户 ID。
key：用于身份验证 (Auth) 的 Base64 编码的密钥。
重要性： 在 Ceph 中，每个操作都需要授权。当您运行 rbd map ... --id qemu 时，客户端会读取这个文件，使用里面的密钥向 Monitor 证明"我就是 client.qemu，请验证我的权限"。这个文件是您实现最小权限原则的关键凭证。

rbdmap (系统启动时自动映射配置)

bash 复制代码

# cat /etc/ceph/rbdmap
# RbdDevice             Parameters
#poolname/imagename     id=client,keyring=/etc/ceph/ceph.client.keyring

作用： rbdmap 是一个特殊的配置文件，供系统服务（通常是 /etc/init.d/rbdmap 或 Systemd 服务）在主机启动时 自动读取，并执行 rbd map 操作。
工作方式： 该文件中的每一行都定义了一个要在启动时映射的 RBD 镜像及其参数（如用户 ID、密钥路径、文件系统类型等）。
您文件中的状态： 您的文件目前处于注释状态 （以 # 开头），这意味着它没有配置任何自动映射的镜像。
示例 (如果启用)： 如果您想在启动时自动映射 rbdpool/myimage，并使用 client.qemu 用户，您会添加一行类似这样的配置：

rbdpool/myimage id=qemu,keyring=/etc/ceph/ceph.client.qemu.keyring

##📝 总结它们的关系这三个文件是 Ceph 客户端工作的必要条件：

ceph.conf 提供了去哪里的信息。
ceph.client.qemu.keyring 提供了你是谁的证明。
rbdmap 提供了启动时要做什么的指令。

rbd showmapped的细节

1. `rbd showmapped` 的作用是什么？`rbd showmapped` 是一个客户端本地的工具命令，它的作用是显示当前这台客户端主机上所有已经成功映射的 RBD 镜像信息。

核心作用：状态查询该命令查询的不是 Ceph 集群的状态，而是本地内核中 RBD 模块的状态。

输出项	含义	存储位置
`id`	映射到内核的设备 ID（从 0 开始）。	本地内核内存
`pool`	镜像所在的存储池名称。	本地内核内存
`name`	镜像的名称。	本地内核内存
`device`	在操作系统中显示的块设备路径（如 `/dev/rbd0`）。	本地 `/dev/` 目录

总结： rbd showmapped 相当于一个"本地设备管理器"命令，用于确认您是否可以访问和使用 RBD 镜像，以及它在您的操作系统中对应的设备路径是什么。

2. 一个客户端映射的关系，集群中的其他服务器看得到吗？简短的回答是：不能，至少不能通过简单的、直接的方式看到。

RBD 的映射关系是本地化 的，但 Ceph 集群知道哪个镜像正在被哪个客户端使用。

客户端映射的本地性* 本地：当您运行 `rbd map` 时，您只是在本地客户端的内核中加载了一个 RBD 驱动实例，并创建了一个设备文件（如 `/dev/rbd0`）。

不可见： 其他服务器（包括 Ceph Monitor、OSDs 或其他客户端）不会在它们的 /dev/ 目录下看到 /dev/rbd0，也不能运行 rbd showmapped 来查看您的映射。

集群知道"谁在使用" (RBD 独占锁)虽然映射关系不可见，但 Ceph 集群为了防止数据损坏（即防止两个客户端同时读写同一个 RBD 镜像），会维护一个独占锁 (Exclusive Lock) 机制。

锁机制： 当客户端成功映射一个启用了独占锁功能的 RBD 镜像时，客户端会向 Ceph 集群（通过 Monitors 或 MGRs）发送一个请求，并在该镜像的元数据上设置一个独占锁。
集群知道： 集群 Monitor 或 Manager（MGR）知道：
哪个镜像 (myimage) 被锁定。
哪个客户端 (client.qemu@host-id) 持有这个锁。

如何查询镜像的使用情况？您可以通过 `rbd status` 命令来查询一个镜像当前是否被锁定，以及哪个客户端持有该锁。

命令示例：

bash 复制代码

rbd status rbdpool/myimage

作用： 这个命令会向 Ceph MGR/Monitor 查询该镜像的元数据锁信息。
输出内容： 如果镜像被映射，输出将显示持有锁的客户端 ID 和客户端的唯一 ID（例如客户端的 IP 地址或主机名）。

总结：

rbd showmapped 只看本地。
其他服务器看不到 您的 /dev/rbd0。
但 Ceph 集群（Monitors/MGRs）可以通过独占锁元数据 来跟踪哪个客户端正在使用哪个 RBD 镜像，以确保数据一致性和完整性。

客户端什么时候需要指定id

这是一个非常好的问题，它准确地指出了 Ceph 管理命令 （ceph -s）和 本地设备状态查询命令 （rbd showmapped）在设计和权限要求上的根本区别。

🔬 核心区别：集群操作 vs. 本地查询根本原因在于：`ceph -s` 访问的是整个集群的全局状态，需要权限；而 `rbd showmapped` 访问的是客户端机器的本地内核信息，不需要权限。

1. 运行 `ceph -s` 需要指定 ID 的原因 (集群操作)* 命令目的： `ceph -s` (Status) 命令的作用是向 Ceph Monitor (MON) 或 Manager (MGR) 查询整个集群的健康状态、I/O 统计、OSD 状态、存储池使用率等全局管理信息。

权限要求： 访问这些全局信息属于管理操作 。为了安全，Ceph 要求所有访问集群的请求都必须经过 身份验证（Authentication） 和 授权（Authorization）。
您必须提供一个用户 ID（例如 admin 或具有相应权限的 client.ID）及其密钥，才能证明您有权查看集群状态。
默认行为： 如果您不指定 --id，ceph 命令行工具会尝试使用默认的管理员身份（通常是 client.admin），如果该密钥环不在默认路径或权限不足，命令就会失败。

2. 运行 `rbd showmapped` 不需要指定 ID 的原因 (本地查询)* 命令目的： `rbd showmapped` 命令的作用是查询当前客户端机器内核中 RBD 模块的状态。它查看的是：哪些 RBD 镜像当前已在本地被映射为 `/dev/rbdX` 块设备？

权限要求： 这是一个纯粹的本地查询操作。它不涉及网络通信、不访问 Ceph 集群的 Monitor 或 OSDs，也不需要任何集群授权。它仅仅是读取操作系统内核中的设备信息。
内核操作： 映射（rbd map）一旦成功，该状态就驻留在内核内存中。任何本地用户（包括普通用户）都有权限读取内核导出的设备列表信息。
总结： rbd showmapped 类似于运行 lsblk 或 df -h，它只关心本地设备，与 Ceph 集群的权限管理无关。

##💡 验证与总结

命令	访问对象	是否需要 Ceph 权限	实际作用
`ceph -s`	Ceph 集群 Monitor/Manager	是 (需要 ID/Key)	查看集群全局健康和状态
`rbd map`	Ceph Monitor (获取映射许可)	是 (需要 ID/Key)	向集群注册映射并创建本地设备
`rbd showmapped`	客户端本地内核	否	查看本地已映射的设备列表
`rbd unmap`	Ceph Monitor (释放映射许可)	是 (需要 ID/Key)	向集群注销映射并移除本地设备

关键点： rbd map 和 rbd unmap 命令确实需要 ID 和密钥，因为它们涉及与 Ceph 集群的交互和对镜像元数据的操作。但 rbd showmapped 仅仅是查看 rbd map 成功后的本地结果，所以是完全本地化的，不需要身份验证。

Primary OSD 的写入逻辑

是等待所有的副本osd都返回成功，还是达到副本数就行

答：您提出的问题是关于 Ceph 数据持久性 和 写操作仲裁 机制的核心，这是 Ceph 强一致性模型的基础。

答案：Primary OSD 等待的是 "仲裁集合" 的确认Primary OSD 等待的不是一个固定的数值，而是当前活跃的、被认为是 PG 仲裁集合（Quorum Set）的所有副本 OSD 的确认。

1. 正常工作状态 (Health State)在集群健康、没有 OSD 失败的理想状态下：

条件： 当前活跃副本数 N' 等于存储池配置的副本数 N（即 N' = N）。
写入确认： Primary OSD 必须等待所有 N 个副本 OSD 都返回写入成功的确认（ACK）。
目的： 确保数据在集群中以预期的持久性（N 份）存储，从而保证数据强持久化。

2. 降级工作状态 (Degraded State)当集群中出现 OSD 故障或 OSD 暂时离线时，Primary OSD 必须遵循 `osd_min_size` 规则：

状态	副本数 (N')	Primary OSD 写入行为	写入确认条件
可写入 (Degraded)	N' \ge osd_min_size	允许写入	Primary OSD 必须等待所有 N' 个活跃 OSD 的 ACK。
不可写入 (Stale/Stopped)	N' < osd_min_size	拒绝写入	Primary OSD 停止新的写入，直到有足够的副本恢复，满足 N' \ge osd_min_size。

关键总结：

Primary OSD 遵守的原则是：

最小安全数： 写入之前，必须确保当前活跃副本数 N' 满足最小安全阈值 (osd_min_size)。
全部仲裁： 写入时，必须等待所有当前活跃的副本 OSD（即 Acting Set 中的 N' 个 OSD）都返回确认，才能向客户端确认写入成功。

注意： "达到副本数就行" 这个说法不够准确。因为如果集群处于降级状态 (N' < N)，Primary OSD 只需要达到 N' 个副本的确认。但是，如果集群是健康的 (N' = N)，则需要达到 N 个副本的确认。核心在于它总是等待所有当前被信任的（在仲裁集合中的）副本 OSD。

写入osd过程中出问题

您提出了一个关于 Ceph **高可用性（High Availability, HA）和故障转移（Failover）**的核心问题。在集群处于健康状态 (Health OK) 时，如果在写入过程中 Primary OSD 或 Replica OSD 突然发生故障，Ceph 会立即启动一系列自动恢复策略，确保数据写入最终成功并保证一致性。

策略：Primary OSD 写入过程中的故障处理我们分两种情况来讨论：

1. Primary OSD 在写入过程中故障Primary OSD 负责协调写入操作。如果它在向副本发送数据之后、向客户端确认之前突然崩溃或离线，会发生以下关键步骤：

步骤	动作	目的
1. 故障发现	Monitor (MON) 和其他 OSDs 会通过心跳机制迅速发现 Primary OSD 丢失。	启动故障处理。
2. 选举新 Primary	MONs 会检查该 PG (Placement Group) 的 Acting Set （活跃集合）中剩余的 OSDs，并从其中最靠前、数据最新的 OSD 中选举一个新的 Primary OSD。	确保 PG 服务可以继续。
3. 状态回退与恢复 (Recovery)	新的 Primary OSD 会与剩余的副本 OSDs 核对事务日志或对象版本。	保证数据一致性。
4. 客户端重试	原先向旧 Primary OSD 写入的客户端连接会断开。客户端会自动重试，并将写入请求发送给新选举出来的 Primary OSD。	完成未成功的写入。
结果：	整个写入操作会重新开始，并在新的 Primary OSD 及其副本上完成。客户端只会感知到写入延迟，但最终会收到成功确认。	确保数据不会丢失，保持强一致性。

2. Replica OSD 在写入过程中故障如果 Primary OSD 成功向 Replica OSD 发送了数据，但 Replica OSD 在写入磁盘之前或返回 ACK 之前崩溃：

步骤	动作	目的
1. Primary OSD 发现	Primary OSD 发现一个副本 OSD 失去连接，或者长时间未收到它的 ACK。	启动降级处理。
2. 检查最小副本数	Primary OSD 检查剩余的活跃副本数是否仍 \ge osd_min_size（通常为 2）。	确保满足写入的最低安全要求。
3. 提交写入	如果满足 `osd_min_size` 要求，Primary OSD 会忽略该故障的副本，并等待剩余所有活跃副本的 ACK。在收到所有这些 ACK 后，Primary OSD 向客户端确认写入成功。	优先保证写入的可用性。
4. PG 状态降级	该 PG 的状态会从 `active+clean` 变为 `active+degraded`。	标记该 PG 处于副本不足状态。
5. 自动修复 (Healing)	Ceph Monitor 发现 PG 处于 `degraded` 状态后，会从 CRUSH Map 中找到一个新的 OSD 来替换故障 OSD 的位置（称为 Acting Set 变更）。Primary OSD 会立即启动后台恢复进程，将完整的数据同步到这个新的 OSD 上，直到 PG 状态回到 `active+clean`。	修复故障，恢复到预期的持久性级别。

总结：Ceph 的核心保证无论是 Primary 故障还是 Replica 故障，Ceph 的策略目标都是一致的：

强一致性： 只要写入操作最终返回成功，就保证数据不会丢失，且所有后续读取请求都会看到最新数据。
可用性 (Availability)： 在不超过 osd_min_size 限制的情况下，集群会牺牲短期的副本数量，优先完成客户端的写入请求。
自愈能力 (Self-Healing)： 故障发生后，Ceph 会自动（且通常是异步地在后台）将丢失的副本修复到新的 OSD 上，无需人工干预。

把一个节点加入集群加不加 _admin的label对集群的性能有影响吗

将一个节点加入 Ceph 集群时，是否为其添加 _admin 标签（label），对集群的性能 （即 I/O 吞吐量、延迟、数据存储和恢复速度）本身没有直接影响。

_admin 标签的作用是管理和运维层面的，与数据路径和存储能力无关。

标签的作用解析

1. `_admin` 标签的作用* 目的：这是一个约定俗成的标签，用于标记集群中的一个或多个节点，作为执行 Ceph 管理命令（如 `ceph osd down`、`ceph osd create`、`ceph mon add` 等）的操作控制台。

功能：
它通常与 Ansible/Cephadm 等部署工具配合使用，用于识别"管理主机"。
它也常用于配置 Ceph Dashboard，以识别哪些主机可以托管管理界面。
对性能的影响： 无直接影响。 标签只是元数据。

2. 节点在集群中的角色与性能节点的性能取决于它在集群中承担的实际角色，以及这些角色是否消耗大量的 CPU、内存和 I/O 资源。

节点角色	对集群性能的潜在影响	是否应该设置 `_admin` 标签
OSD 节点 (数据存储)	直接影响性能。负责数据的存储、复制和恢复。高负载会影响 I/O 性能。	不建议。 OSD 节点应专注于数据工作，管理操作应在专门的管理节点进行。
Monitor (MON)	影响元数据性能。负责维护集群地图和仲裁。高负载会增加客户端连接和元数据查询的延迟。	通常不设置。 MON 应专注于仲裁和集群状态。
Manager (MGR)	影响管理性能。负责收集统计信息、运行模块（如 Dashboard、Prometheus）。	可以设置。 MGR 通常是执行管理命令的理想位置，但应避免在 MGR 节点上运行过多的其他服务。
客户端/网关	无影响。客户端（如 RGW, RBD 客户端）消耗的是其自身的 I/O 和 CPU 资源。	可以设置。如果该节点用于执行 `ceph` 命令，可以方便管理。

总结如果您在一个专门的管理节点上添加 `_admin` 标签，并且仅在这个节点上执行管理任务，那么：

好处： 您将隔离了管理操作的负载，避免了在 OSD 节点或 MON 节点上运行资源密集型命令，从而间接保护了集群的 I/O 性能。
影响： _admin 标签本身不会影响性能，是角色的分离影响了性能。

最终建议：

如果该节点是您用来执行管理命令的专用主机，那么加上 _admin 标签是推荐的，它有助于清晰地界定节点的用途，方便自动化工具管理。但请记住，性能影响来自于您在节点上运行的实际服务（OSD, MON, MGR），而不是标签。

快照可以嵌套吗

weight和reweight

您提出的 osd tree 中 WEIGHT 和 REWEIGHT 的区别，是理解 Ceph CRUSH 算法 、数据分布 和集群管理之间关系的关键。

这两个值虽然都影响数据分布，但它们的作用机制、修改权限和影响范围是完全不同的。

⚖️ `WEIGHT` vs `REWEIGHT` 区别解析

特性	WEIGHT (权重)	REWEIGHT (重新加权)
定义	物理容量权重。代表 OSD 的实际或潜在存储容量。	运行时分配调整系数。代表 Ceph 在 PG 分布时，对该 OSD 分配 PG 的意愿。
计算/来源	由 CRUSH 算法基于 OSD 的实际容量或管理员设置的容量值自动计算得出。	由管理员手动设置，用于临时或精细地调整 PG 分布。
作用范围	全局影响。影响 CRUSH 算法在整个拓扑结构中如何选择 OSD 来存储 PG。它控制了 PG 的初始分布。	局部影响。仅影响 OSD 在 Acting Set 中被选为 Primary OSD 的概率，以及 PG 在 OSD 之间的最终平衡。
数值变化	变化基于 OSD 的实际容量变化（例如增加磁盘空间）。	可以在 0.0 到 1.0 之间手动调整。通常用于平衡 I/O 或进行运维操作。
命令	通过 `ceph osd crush reweight <osd.id> <weight>` 进行修改。	通过 `ceph osd reweight <osd.id> <reweight>` 进行修改。
主要用途	容量分配。确保存储池的数据量与 OSD 的物理容量成比例。	I/O 或负载平衡。在不改变 CRUSH Map 的前提下，手动将 PG 负载从一个繁忙的 OSD 转移到另一个 OSD。

详细解释和使用场景

1. WEIGHT (CRUSH 权重)`WEIGHT` 是 CRUSH Map 的一个属性，用于指导 Ceph 的数据放置。

如何计算： 默认情况下，WEIGHT 通常是基于 OSD 提供的存储容量计算得出。例如，一个 2TB 的 OSD 可能有一个 2.0 的权重，而一个 1TB 的 OSD 可能是 1.0。
数据放置的影响： CRUSH 算法会倾向于将更多的 PG 分配给权重更高的 OSD，以确保数据的物理分布与容量相匹配。
何时修改： 当您永久性地改变了 OSD 的存储容量时（例如更换更大的磁盘），需要更新 CRUSH 权重。

2. REWEIGHT (运行时分配加权)`REWEIGHT` 是一个独立于 CRUSH 的运行时参数，它位于 OSD Map 中。它的主要目的是精细调整。

数值范围： REWEIGHT 的有效值是 0.0 到 1.0：
1.0 (默认): OSD 正常参与 PG 分布。
0.0: OSD 不再分配新的 PG，并且当前已有的 PG 正在被迁移走。用于安全下线 OSD。
0.xx (例如 0.5): Primary OSD 被选为主要副本的概率降低，从而减少其 I/O 负载。
主要用途：

负载平衡： 如果发现某个 OSD 的 I/O 负载（不是容量占用）特别高，可以略微降低其 REWEIGHT 值（例如 0.9），Ceph 会将一部分 PG 迁移到其他 OSD，或降低它被选为 Primary 的概率。
安全下线： 在替换 OSD 之前，将其 REWEIGHT 设为 0.0，安全地清空其上的所有数据。

总结：比喻理解您可以用交通系统来理解这两个值：

WEIGHT (容量权重): 就像公路的设计容量 。容量大的路段（高 WEIGHT）将被分配更多的车辆（PG），这是长期的、由物理条件决定的。
REWEIGHT (运行时加权): 就像交通信号灯的配时 。如果某条路段（OSD）突然发生拥堵（I/O 负载高），交警可以手动调整红绿灯配时（降低 REWEIGHT），减少流向该路段的车辆，从而缓解拥堵。这是一个临时的、用于负载优化的措施。

在绝大多数情况下，您应该只在容量发生变化 时调整 WEIGHT，并在进行负载平衡 或安全下线 时调整 REWEIGHT。

reweight真的可以影响被选为 Primary OSD 的概率，pri aff这个参数是干什么的

您对 REWEIGHT 作用的理解是完全正确的，并且您引入的 pri_affinity（Primary Affinity）参数进一步深入了 Ceph 控制 PG 主副本选举的机制。

这两个参数都用于精细调整 OSD 承担 Primary 角色的概率和意愿，但它们的工作方式和应用场景有所不同。

1. `REWEIGHT` 如何影响 Primary OSD 选举概率是的，`REWEIGHT` 确实可以影响一个 OSD 被选为 Primary OSD 的概率，尽管它是一个间接影响。

机制解析1. CRUSH 的角色： CRUSH 算法负责决定一个 PG (Placement Group) 的 Acting Set （活跃副本集合，例如 OSD 1, OSD 2, OSD 3）。CRUSH 算法本身只依赖于 `WEIGHT`。

Primary 的决定： 在这个 Acting Set 中，通常第一个 OSD（在本例中是 OSD 1）会被指定为 Primary OSD。
REWEIGHT 的干预： 当您降低 OSD 1 的 REWEIGHT 值（例如从 1.0 降到 0.5）时，Ceph 会启动一个 PG 迁移过程。

目标是平衡 OSD 之间的 PG 负载。
为了实现这个平衡，Ceph 会将 OSD 1 上的一部分 PG 迁移到其他 OSD 上。
在迁移过程中，PG 的 Acting Set 可能会重新计算，导致 OSD 1 不再是 Acting Set 中的第一个 OSD，从而不再是 Primary OSD。

结果： 最终，拥有较低 REWEIGHT 的 OSD 会承担更少的 PG，从而承担更少的 Primary 角色。

结论： REWEIGHT 通过影响 OSD 拥有的 PG 数量 （即 PG 的物理分布）来间接影响其被选为 Primary OSD 的概率。这是用于 全局 I/O 负载平衡 的主要工具。

2. `pri_affinity` (Primary Affinity) 是什么？`pri_affinity` 参数是 Ceph 提供的一个更直接、更细粒度的机制，用于控制 OSD 被选为 Primary OSD 的意愿或倾向性。

A. 定义和数值* 定义： `pri_affinity` 是 OSD 的一个属性，用于设置 OSD 成为 Primary OSD 的相对权重。

数值范围： 0.0 到 1.0。
1.0 (默认): OSD 正常参与 Primary 选举。
0.0: 绝对阻止 OSD 被选为任何 PG 的 Primary OSD。它只能作为副本 OSD。
0.xx (例如 0.5): 降低 OSD 被选为 Primary OSD 的概率。

B. 机制和用途与 `REWEIGHT` 相比，`pri_affinity` 的优势在于它不会触发数据迁移。

不迁移数据： 改变 pri_affinity 不会改变 PG 的物理位置（即 PG 仍在原来的 OSD 上）。它只会影响 PG 的 "Primary Election" 过程。
用途： 如果一个 OSD 磁盘容量充足，并且是某个 PG 的 Acting Set 成员，但是它的硬件（例如 CPU、网络接口）相对较慢，或者您希望将该节点的负载限制在只读或备份任务上，您可以降低它的 pri_affinity。
如何工作： 当 MONs 决定一个 PG 的 Primary 时，它会将 Acting Set 中的 OSDs 的 pri_affinity 值作为因素考虑进去，倾向于选择那些 pri_affinity 值高的 OSD 作为 Primary。

C. 设置命令您可以使用以下命令设置 OSD 的 `pri_affinity`：

bash 复制代码

# 语法：ceph osd primary-affinity <osd.id> <value>
ceph osd primary-affinity osd.5 0.5   # 降低 osd.5 成为 Primary 的倾向性
ceph osd primary-affinity osd.5 1.0   # 恢复 osd.5 成为 Primary 的倾向性

总结：何时使用哪个参数？

参数	影响 PG 的物理分布?	主要目标	推荐使用场景
`REWEIGHT`	是（会触发数据迁移）	容量和 I/O 负载的全局平衡	OSD 容量或负载差异大时，需进行大规模迁移来平衡。
`pri_affinity`	否（只影响 Primary 选举）	控制 I/O 角色（Primary = 写入/复制）	OSD 硬件较弱，不适合承担大量写入负载，但仍希望它能作为数据副本存在时。

简单来说：如果您想移动数据，使用 REWEIGHT。如果您只想调整 Primary 角色的分配 ，而不移动数据，使用 pri_affinity。

ceph一些细节处理

/etc/ceph下的文件

rbd showmapped的细节

1. rbd showmapped 的作用是什么？rbd showmapped 是一个客户端本地 的工具命令，它的作用是显示当前这台客户端主机上所有已经成功映射的 RBD 镜像信息。

核心作用：状态查询该命令查询的不是 Ceph 集群的状态，而是本地内核中 RBD 模块的状态。

2. 一个客户端映射的关系，集群中的其他服务器看得到吗？简短的回答是：不能，至少不能通过简单的、直接的方式看到。

客户端映射的本地性* 本地： 当您运行 rbd map 时，您只是在本地客户端的内核中加载了一个 RBD 驱动实例，并创建了一个设备文件（如 /dev/rbd0）。

集群知道"谁在使用" (RBD 独占锁)虽然映射关系不可见，但 Ceph 集群为了防止数据损坏 （即防止两个客户端同时读写同一个 RBD 镜像），会维护一个 独占锁 (Exclusive Lock) 机制。

如何查询镜像的使用情况？您可以通过 rbd status 命令来查询一个镜像当前是否被锁定，以及哪个客户端持有该锁。

客户端什么时候需要指定id

🔬 核心区别：集群操作 vs. 本地查询根本原因在于：ceph -s 访问的是整个集群的全局状态，需要权限；而 rbd showmapped 访问的是客户端机器的本地内核信息，不需要权限。

1. 运行 ceph -s 需要指定 ID 的原因 (集群操作)* 命令目的： ceph -s (Status) 命令的作用是向 Ceph Monitor (MON) 或 Manager (MGR) 查询整个集群的健康状态、I/O 统计、OSD 状态、存储池使用率 等全局管理信息。

2. 运行 rbd showmapped 不需要指定 ID 的原因 (本地查询)* 命令目的： rbd showmapped 命令的作用是查询当前客户端机器内核 中 RBD 模块 的状态。它查看的是：哪些 RBD 镜像当前已在本地被映射为 /dev/rbdX 块设备？

Primary OSD 的写入逻辑

1. 正常工作状态 (Health State)在集群健康、没有 OSD 失败的理想状态下：

2. 降级工作状态 (Degraded State)当集群中出现 OSD 故障或 OSD 暂时离线时，Primary OSD 必须遵循 osd_min_size 规则：

写入osd过程中出问题

策略：Primary OSD 写入过程中的故障处理我们分两种情况来讨论：

1. Primary OSD 在写入过程中故障Primary OSD 负责协调写入操作。如果它在向副本发送数据之后、向客户端确认之前突然崩溃或离线，会发生以下关键步骤：

2. Replica OSD 在写入过程中故障如果 Primary OSD 成功向 Replica OSD 发送了数据，但 Replica OSD 在写入磁盘之前或返回 ACK 之前崩溃：

总结：Ceph 的核心保证无论是 Primary 故障还是 Replica 故障，Ceph 的策略目标都是一致的：

把一个节点加入集群加不加 _admin的label对集群的性能有影响吗

标签的作用解析

1. _admin 标签的作用* 目的： 这是一个约定俗成的标签 ，用于标记集群中的一个或多个节点，作为执行 Ceph 管理命令 （如 ceph osd down、ceph osd create、ceph mon add 等）的操作控制台。

2. 节点在集群中的角色与性能节点的性能取决于它在集群中承担的实际角色，以及这些角色是否消耗大量的 CPU、内存和 I/O 资源。

总结如果您在一个专门的 管理节点上添加 _admin 标签，并且仅在这个节点上执行管理任务，那么：

快照可以嵌套吗

weight和reweight

⚖️ WEIGHT vs REWEIGHT 区别解析

详细解释和使用场景

1. WEIGHT (CRUSH 权重)WEIGHT 是 CRUSH Map 的一个属性，用于指导 Ceph 的数据放置。

2. REWEIGHT (运行时分配加权)REWEIGHT 是一个独立于 CRUSH 的运行时参数，它位于 OSD Map 中。它的主要目的是精细调整。

总结：比喻理解您可以用交通系统来理解这两个值：

reweight真的可以影响被选为 Primary OSD 的概率，pri aff这个参数是干什么的

1. REWEIGHT 如何影响 Primary OSD 选举概率是的，REWEIGHT 确实可以影响一个 OSD 被选为 Primary OSD 的概率，尽管它是一个间接影响。

机制解析1. CRUSH 的角色： CRUSH 算法 负责决定一个 PG (Placement Group) 的 Acting Set （活跃副本集合，例如 OSD 1, OSD 2, OSD 3）。CRUSH 算法本身只依赖于 WEIGHT。

2. pri_affinity (Primary Affinity) 是什么？pri_affinity 参数是 Ceph 提供的一个更直接 、更细粒度 的机制，用于控制 OSD 被选为 Primary OSD 的意愿 或倾向性。

A. 定义和数值* 定义： pri_affinity 是 OSD 的一个属性，用于设置 OSD 成为 Primary OSD 的相对权重。

B. 机制和用途与 REWEIGHT 相比，pri_affinity 的优势在于它不会触发数据迁移。

C. 设置命令您可以使用以下命令设置 OSD 的 pri_affinity：

总结：何时使用哪个参数？

1. `rbd showmapped` 的作用是什么？`rbd showmapped` 是一个客户端本地的工具命令，它的作用是显示当前这台客户端主机上所有已经成功映射的 RBD 镜像信息。

客户端映射的本地性* 本地：当您运行 `rbd map` 时，您只是在本地客户端的内核中加载了一个 RBD 驱动实例，并创建了一个设备文件（如 `/dev/rbd0`）。

集群知道"谁在使用" (RBD 独占锁)虽然映射关系不可见，但 Ceph 集群为了防止数据损坏（即防止两个客户端同时读写同一个 RBD 镜像），会维护一个独占锁 (Exclusive Lock) 机制。

如何查询镜像的使用情况？您可以通过 `rbd status` 命令来查询一个镜像当前是否被锁定，以及哪个客户端持有该锁。

🔬 核心区别：集群操作 vs. 本地查询根本原因在于：`ceph -s` 访问的是整个集群的全局状态，需要权限；而 `rbd showmapped` 访问的是客户端机器的本地内核信息，不需要权限。

1. 运行 `ceph -s` 需要指定 ID 的原因 (集群操作)* 命令目的： `ceph -s` (Status) 命令的作用是向 Ceph Monitor (MON) 或 Manager (MGR) 查询整个集群的健康状态、I/O 统计、OSD 状态、存储池使用率等全局管理信息。

2. 运行 `rbd showmapped` 不需要指定 ID 的原因 (本地查询)* 命令目的： `rbd showmapped` 命令的作用是查询当前客户端机器内核中 RBD 模块的状态。它查看的是：哪些 RBD 镜像当前已在本地被映射为 `/dev/rbdX` 块设备？

2. 降级工作状态 (Degraded State)当集群中出现 OSD 故障或 OSD 暂时离线时，Primary OSD 必须遵循 `osd_min_size` 规则：

1. `_admin` 标签的作用* 目的：这是一个约定俗成的标签，用于标记集群中的一个或多个节点，作为执行 Ceph 管理命令（如 `ceph osd down`、`ceph osd create`、`ceph mon add` 等）的操作控制台。

总结如果您在一个专门的管理节点上添加 `_admin` 标签，并且仅在这个节点上执行管理任务，那么：

⚖️ `WEIGHT` vs `REWEIGHT` 区别解析

1. WEIGHT (CRUSH 权重)`WEIGHT` 是 CRUSH Map 的一个属性，用于指导 Ceph 的数据放置。

2. REWEIGHT (运行时分配加权)`REWEIGHT` 是一个独立于 CRUSH 的运行时参数，它位于 OSD Map 中。它的主要目的是精细调整。

1. `REWEIGHT` 如何影响 Primary OSD 选举概率是的，`REWEIGHT` 确实可以影响一个 OSD 被选为 Primary OSD 的概率，尽管它是一个间接影响。

机制解析1. CRUSH 的角色： CRUSH 算法负责决定一个 PG (Placement Group) 的 Acting Set （活跃副本集合，例如 OSD 1, OSD 2, OSD 3）。CRUSH 算法本身只依赖于 `WEIGHT`。

2. `pri_affinity` (Primary Affinity) 是什么？`pri_affinity` 参数是 Ceph 提供的一个更直接、更细粒度的机制，用于控制 OSD 被选为 Primary OSD 的意愿或倾向性。

A. 定义和数值* 定义： `pri_affinity` 是 OSD 的一个属性，用于设置 OSD 成为 Primary OSD 的相对权重。

B. 机制和用途与 `REWEIGHT` 相比，`pri_affinity` 的优势在于它不会触发数据迁移。

C. 设置命令您可以使用以下命令设置 OSD 的 `pri_affinity`：