cephaltermanager 只部署在一个实例 crash 所有主机部署一个 prometheus 只部署在一个 m

关系和流程

1. 上层组件与 librados 的关系
librados 是 Ceph 提供的核心库，它封装了与 RADOS 集群交互的所有功能。
上层组件（如 RGW、RBD、CephFS 等）通过调用 librados 提供的 API 来实现对 RADOS 集群的操作。
这些操作包括：
数据对象的创建、读取、更新和删除（CRUD）。
数据分布和副本管理。
故障检测和恢复。
2. librados 与 RADOS 的交互
RADOS 是 Ceph 的核心分布式存储系统，负责实际的数据存储和管理。
librados 作为 RADOS 的客户端库，提供了以下功能：
元数据获取：从 MON 节点获取集群的全局状态信息（Cluster Map），包括 OSD Map 和 CRUSH Map。
数据定位：根据 CRUSH 算法计算数据对象的目标 OSD。
数据操作：将数据写入或读取到目标 OSD。
3. RADOS 操作 OSD 的过程
当上层组件通过 librados 发起请求时，RADOS 会执行以下步骤来操作 OSD：




a) 获取 Cluster Map
RADOS 通过与 MON 节点通信，获取最新的 Cluster Map（包括 OSD Map 和 CRUSH Map）。
Cluster Map 包含了集群中所有 OSD 的状态信息以及数据分布策略。
b) 计算数据分布
RADOS 使用 CRUSH 算法，根据数据对象的名称（Object ID）和 Cluster Map 计算出目标 OSD 列表。
目标 OSD 列表通常包括主 OSD 和副本 OSD。
c) 与目标 OSD 通信
RADOS 将数据操作请求发送到目标 OSD。
主 OSD 负责协调数据的写入或读取，并确保副本 OSD 的一致性。
d) 执行数据操作
OSD 接收到请求后，执行具体的存储操作（如写入磁盘或从磁盘读取）。
如果是写操作，主 OSD 会将数据同步到副本 OSD，确保数据的高可用性。
4. 示例：RGW 如何通过 librados 操作 OSD
以 RADOS Gateway (RGW) 为例，说明其如何通过 librados 操作 OSD：




客户端发起请求：
用户通过 S3 或 Swift API 向 RGW 发起存储请求（如上传文件）。
RGW 调用 librgw：
RGW 将请求转换为对象存储操作，并通过 librgw 调用 librados。
librados 获取 Cluster Map：
librados 从 MON 节点获取最新的 Cluster Map。
librados 计算目标 OSD：
根据 CRUSH 算法，librados 计算出数据对象的目标 OSD 列表。
librados 操作 OSD：
librados 将数据写入请求发送到主 OSD。
主 OSD 协调数据写入，并同步到副本 OSD。
返回结果：
数据写入完成后，结果逐级返回给 RGW，最终返回给用户。
5. 总结：上层组件 → librados → RADOS → OSD
整个流程可以总结为以下步骤：




text
[上层组件] → [librados] → [RADOS] → [OSD]
上层组件：提供特定功能（如对象存储、块存储、文件系统）。
librados：作为 RADOS 的客户端库，负责与 RADOS 集群交互。
RADOS：负责数据分布、副本管理和故障恢复。
OSD：实际执行数据的存储和管理。




RADOS（Reliable Autonomic Distributed Object Store）： ◦ RADOS 是 Ceph 的核心分布式存储系统。 ◦ 它负责实际的数据存储、分布、复制和恢复。 ◦ RADOS 运行在 OSD 和 MON 节点上，直接管理物理存储设备。   •  librados： ◦ librados 是一个客户端库，用于与 RADOS 集群进行交互。 ◦ 它提供了 API 接口，供上层组件（如 RGW、RBD、CephFS 等）调用，以实现对 RADOS 集群的操作。

cephadm提供了一种基于容器化技术（如 Podman 或 Docker）的自动化方式来管理 Ceph 集群。

ceph orch 命令是由 Ceph 的核心组件（如 ceph-mgr 和 cephadm）支持的。

ceph orch 命令是 Orchestrator 的 CLI 接口，允许用户通过命令行与 Orchestrator 交互。

Ceph Orchestrator 是 Ceph 的一个管理框架，用于自动化部署、扩展和管理 Ceph 集群中的服务（如 MON、MGR、OSD、RGW 等）。

altermanager 只部署在一个实例

crash 所有主机部署一个

prometheus 只部署在一个

mgr Ceph Manager，负责集群状态监控、API 接口、性能统计等

mon Ceph Monitor，维护集群拓扑结构和一致性

node-exporter 节点级监控导出器，提供主机系统指标（CPU、内存、磁盘等）

cephadm 使用的特殊标签

1. mon 服务的行为变化 原因：Orchestrator 的默认扩展策略 • 在 Ceph 集群中，MON（Monitor）服务的数量通常由 Orchestrator 自动管理。 • 当您执行以下命令时： 
 ceph orch apply mon --unmanaged=true 
将 MON 服务设置为未托管模式。 此时，Orchestrator 不再自动管理 MON 的扩展、修复和配置一致性。 
默认情况下，Ceph 的 Orchestrator 可能会尝试将 MON 的数量扩展到最大值（如 5 个），以提高高可用性。输出分析 从输出中可以看到： text  mon    3/5  2m ago     1s    <unmanaged>  • 3/5：表示当前运行了 3 个 MON 实例，但 Orchestrator 的目标是扩展到 5 个。 
<unmanaged>：表示 MON 已进入未托管模式，后续需要手动管理。  

2. crash 服务的行为变化 原因：Crash 服务的特性 
Crash 服务是 Ceph 的崩溃报告模块，负责收集和上报节点的崩溃信息。 
它的特点是每个节点上都会运行一个实例，因此其数量与集群中的节点数直接相关。
当您执行以下命令时：ceph orch apply crash --unmanaged=true
将 Crash 服务设置为未托管模式,但由于 Crash 服务的数量是由节点数决定的，而不是由 Orchestrator 动态扩展的，因此即使取消托管模式，其数量仍然保持不变。
输出分析 从输出中可以看到： text  crash                                       3/3 2m ago     1s   <unmanaged>  • 3/3：表示当前运行了 3 个 Crash 实例，并且没有扩展计划。 • <unmanaged>：表示 Crash 已进入未托管模式，后续需要手动管理。    3. 为什么行为不同？ 两者的差异主要源于它们的设计目的和管理策略： a) MON 服务 • 设计目的：MON 是 Ceph 集群的核心组件，负责维护集群的元数据和状态信息。 • 管理策略：Orchestrator 默认会尝试扩展 MON 的数量，以提高高可用性和容错能力。 • 取消托管后的行为：即使进入未托管模式，Orchestrator 可能仍会保留扩展目标（如 5 个 MON），但不会自动完成扩展。  b) Crash 服务 • 设计目的：Crash 服务用于收集节点的崩溃信息，每个节点上运行一个实例即可满足需求。 • 管理策略：Crash 服务的数量与节点数绑定，Orchestrator 不会动态扩展其数量。 • 取消托管后的行为：由于 Crash 服务的数量不受 Orchestrator 动态控制，取消托管模式后其数量保持不变。

临时更改，重启失效

：ceph tell mon.ceph1.laogao.cloud config set mon_allow_pool_delete false


ceph tell mon.ceph1.laogao.cloud config get mon_allow_pool_delete
{
    "mon_allow_pool_delete": "false"
}


：ceph config get mon.ceph1.laogao.cloud mon_allow_pool_delete
false


：ceph orch daemon restart mon.ceph1.laogao.cloud
Scheduled to restart mon.ceph1.laogao.cloud on host 'ceph1.laogao.cloud'




ceph tell mon.ceph1.laogao.cloud config get mon_allow_pool_delete
{
    "mon_allow_pool_delete": "false"
}


重启后看到就没有保留

当你使用 ceph tell 修改配置时，该修改仅作用于当前运行的守护进程实例，并未更新到 Ceph 的全局配置数据库中。全局数据库由montior管理

使用 ceph config set 修改的配置会写入全局配置数据库，并同步到所有相关守护进程。

Daemon 是集群实际运行的服务进程，例如montior，OSD，mgr 每个守护进程从全局配置数据库

集群mon有问题时可以用ceph daemon 更改

要用cephadm shell 这样用不连mon的模式进入,使用ceph daemon

部署

cat >> /etc/hosts << EOF
###### ceph ######
192.168.108.10 client.laogao.cloud client
192.168.108.11 ceph1.laogao.cloud ceph1
192.168.108.12 ceph2.laogao.cloud ceph2
192.168.108.13 ceph3.laogao.cloud ceph3
192.168.108.14 ceph4.laogao.cloud ceph4
192.168.108.15 ceph5.laogao.cloud ceph5
192.168.108.16 ceph6.laogao.cloud ceph6
EOF


sed -ri 's/^SELINUX=.*/SELINUX=disabled/g'
/etc/selinux/config
#关闭selinux
systemctl disable firewalld --now
#关闭防火墙
cat << 'EOF' > /etc/yum.repos.d/ceph.repo
[Ceph]
name=Ceph
baseurl=https://mirrors.aliyun.com/centos-vault/8-stream/storage/x86_64/cephpacific
enabled=1
gpgcheck=0
EOF
#配置yum仓库
dnf install -y bash-completion vim lrzsz unzip rsync sshpass
tar
#安装基础软件包
dnf install -y chrony
systemctl enbale chronyd --now 
#配置时间同步
dnf install -y cephadm
#安装cephadm
#ceph组件是容器化环境。需要下载cephadm来部署和管理容器化的ceph核心组件
rpm -q podman
podman-4.9.4-0.1.module_el8+971+3d3df00d.x86_64
#安装cephadm会自动安装官方推荐的容器引擎podman
podman pull quay.io/ceph/ceph:v16
podman pull quay.io/ceph/ceph-grafana:8.3.5
podman pull quay.io/prometheus/node-exporter:v1.3.1
podman pull quay.io/prometheus/alertmanager:v0.23.0
podman pull quay.io/prometheus/prometheus:v2.33.4
#使用podman从ceph官方仓库拉取核心组件镜像，包含了运行所需的组件和依赖
cephadm bootstrap --mon-ip 192.168.108.11 --allow-fqdn-hostname -
-initial-dashboard-user admin --initial-dashboard-password laogao@123 --dashboard-password-noupdate
#初始化集群
dnf install -y ceph-common