教材原文：RHCA 官方英文教材（PDF 第 19~50 页，对应教材页码 1~32）（OCR 整书版已从本站移除，本页为章节精读） 关联知识：02-09-性能调优RH442（RHCA）同批存储课程；06-RedHat-RHCE-RHCA-目录梳理与课程地图；本系列配套 00-RHCA教材精读-导航与学习法.md
- GOAL: Describe Red Hat Ceph Storage architecture including data organization, distribution, and client access methods.（描述 RHCS 架构：数据组织、分布与客户端访问方式）
- OBJECTIVES: ① 描述云存储生态中的 persona（角色画像）及其在本课程的用例/任务；② 描述 Ceph 集群架构、引入 Object Storage Cluster（RADOS）、梳理数据访问方式；③ 描述并对比 Ceph 提供的管理接口（CLI 与 Dashboard）。
- 结构：两个知识 Section（Personas / Architecture，后者含 Management Interfaces）+ 两个 Guided Exercise（
intro-arch、intro-interface）。
Personas = user definitions representing user types; 红帽用 persona 把培训聚焦到“用户要做的任务/行为”，而不是堆功能特性。 一句话：先想清楚“谁在用、要干什么”，再学工具。
- 任务：安装/配置/维护 Ceph 集群；向基础设施架构师说明 Ceph 能力；告知用户数据呈现与访问方式（选型依据）；提供韧性/恢复（复制、备份、容灾）；通过 Infrastructure as Code 自动化与集成；为数据分析/海量挖掘提供访问。
- 画像可变：组织规模不同，一个岗位可能覆盖多个人设；本课程以 storage administrator 定义 Ceph 运维场景与用例。
- 比存储管理员经验浅，负责日常运维：主要用 Ceph Dashboard GUI 查看/响应集群告警与统计；执行 Dashboard 工作流化的例行管理（如更换故障存储盘）。
| 英文 | 中文 | 一句话职责 |
|---|
| Cloud operator | 云运维员 | 管理 OpenStack/OpenShift 等云资源，与存储管理员协作维护后端 Ceph |
| Automation engineer | 自动化工程师 | 为重复任务写 playbook（本课程所有界面操作理论上都可自动化） |
| Application developer (DevOps) | 应用开发 | 原始编码者/维护者，可用 Ceph 存储、配配额、加固应用存储 |
| Service administrator | 服务管理员 | 管理“端用户服务”（区别于 OS 服务），类似产品经理角色 |
| Deployment engineer (DevOps) | 部署工程师 | 大环境里专门负责应用部署的调优与实施 |
| Application architect | 应用架构师 | 把 Ceph 基础设施布局与资源可用性/扩展/延迟关联起来 |
| Infrastructure architect | 基础设施架构师 | 精通集群架构布局（容量/延迟/资源位置），可能是云厂商/方案顾问 |
| Data center operator | 数据中心运维 | 底层数据供给；存储管理员通过工单与其协作 |
| Responsibility | Persona |
|---|
| Designs distributed cloud deployment capacities and configurations | Infrastructure architect |
| Manages end-user services | Service administrator |
| Configures cloud services at the infrastructure level | Cloud operator |
| Installs, configures, and maintains Ceph storage clusters | Storage administrator |
| Designs cloud applications based on modern cloud protocols/configurations | Application architect |
| Implements solutions as effortless application deployment and scaling | Automation engineer |
| Manages cluster operations by using the Ceph Dashboard GUI | Storage operator |
- RADOS（Reliable Autonomic Distributed Object Store）＝ 存储后端核心：纯软件、自愈（self-healing）、自管理（self-managing）的对象存储；集群规模可扩展到上千客户端、EB 级数据。
- 访问层（Various access methods to interact with RADOS）：
librados 原生对象 API、librbd（块设备）、librgw（对象网关 S3/Swift）、libcephfs（分布式文件系统）——所有访问最终都落到 RADOS 对象。 - 架构原则：把“计算”尽可能贴近数据（compute near the physical data）；客户端与 OSD 都自己计算对象位置，不依赖中央查表。
| 守护进程 | 全称 | 职责 |
|---|
| MON | Monitor | 维护 cluster map（5 张 map 集合）供各守护进程协调；投票达成共识（quorum），需过半数在线，生产配奇数台 |
| OSD | Object Storage Device | 存数据 + 负责复制（replication）、恢复（recovery）、再平衡（rebalancing）；RHCS 5 默认 BlueStore 后端（裸盘 raw 模式、高性能） |
| MGR | Manager | 采集运行时指标，经浏览器 Dashboard 与 REST API 暴露；至少 2 个且分属不同故障域（MGR 挂了不影响 I/O，只影响查询统计） |
| MDS | Metadata Server | 只服务 CephFS 元数据（属主/时间戳/mode），让客户端能高效执行 POSIX 命令；对象/块存储不需要 MDS |
- CRUSH（Controlled Replication Under Scalable Hashing）：伪随机放置算法；把每个对象分配到唯一一个 PG（Placement Group，哈希桶）；PG 是“对象(应用层) ↔ OSD(物理层)”之间的抽象层。
- CRUSH rules 决定 PG → OSD 的映射（placement strategy）；每条 rule 指明在 CRUSH 拓扑里按哪个**故障域（failure domain）**挑选副本/纠删码分片。
- 客户端定位对象三步：
- 从 MON 拿最新 cluster map（含 pool 数字 ID 等）；
PG ID = hash(object_name) % pg_num（模该池 PG 数），再拼上 pool 数字 ID；- 用 CRUSH 把 PG 映射到 OSD Acting Set；其中处于 up 的组成 Up Set，Up Set 第一个 OSD 是 Primary。
- Primary OSD：承接该 PG 全部读写的入口；负责复制保护数据、数据一致性检查、再平衡、恢复。Secondary OSD：永远受 primary 控制，可晋升为 primary。
- 故障/扩容时：OSD 增删 → PG 自动在可用 OSD 间再平衡并同步到符合数据保护规则的状态。
- ⚠️ Warning：跑 OSD 的主机不要用内核态客户端挂载 RBD/CephFS（可能因内存死锁或阻塞 I/O 悬挂在过期会话上导致无响应）。
- Pool = Ceph 集群的逻辑分区/命名标签，用一组 PG 把对象分组存储。
- 每个 pool 可调属性：不可变 ID、Name、PG 数、CRUSH rule、保护类型（replicated 副本 vs erasure coding 纠删码）、保护参数、若干 flag。
- 副本池：整对象多份拷贝，按业务容忍度配置“可同时坏几台 OSD 不丢数据”（由 size/min_size 等控制）；纠删码池：对象切成 k+m 分片（典型 4+2，可容忍任意 2 块丢失），省空间但 CPU/IO 开销更高。
- 数据条带化（striping）：Ceph 客户端可把数据条带化到多设备，突破单盘吞吐瓶颈。
| 访问 | 库/入口 | 说明与用例 |
|---|
| 原生对象 | librados（C/C++/Python） | 池操作、快照、读写对象/字节区间、append/truncate、XATTR、键值对、复合操作、双 ack 语义 |
| 块设备 RBD | librbd（KVM/QEMU），可经 iSCSI gateway 暴露给 Samba 等 | object map 特性在 librbd 客户端内存里记录“对象是否存在”，加速 resize/export/copy/flatten/delete/read，避免无效查询 OSD |
| 对象网关 | librgw（RADOS Gateway） | 兼容 Amazon S3 与 OpenStack Swift API；改 endpoint 即可迁移存量应用；典型场景：图片存储、备份服务、网盘式文件存储共享 |
| 文件 CephFS | libcephfs + MDS | 并行文件系统、单一层级共享盘；RHCS 5 生产级支持含快照 |
目标：登录管理节点并查询/浏览集群服务。流程与命令：
# 1) 登录管理节点并进入 cephadm 容器 shell
ssh admin@clienta; sudo -i
cephadm shell -- ceph orch ls # 查看运行中的“服务”(service)：alertmanager/crash/osd/prometheus/rgw...
cephadm shell # 进入容器化 shell
ceph orch ps # 查看所有“守护进程”(daemon) 状态（HOST/STATUS/PORTS/VERSION…）
# 2) ceph status：集群总体状态
ceph status
# mon:4 daemons, quorum ... · mgr:1 active+3 standby · osd:9 up/in · rgw:2 active
# 5 pools,105 pgs · 105 active+clean
# 3) 分层查看集群组件
ceph mon dump # MON map：fsid、epoch、election_strategy、每个 MON 的 v2:3300/v1:6789 地址
ceph mgr stat # JSON：available、active_name、num_standby
ceph osd pool ls # 列出池（device_health_metrics…）
ceph pg stat # PG 状态统计：105 pgs active+clean
ceph osd status # 每个 OSD 的 ID/HOST/STATE/USED/AVAIL/读写指标
lab finish intro-arch # workstation 上收尾
考点提示：ceph orch ls＝服务编排列表（偏“要跑几个服务、放哪”）；ceph orch ps＝实际守护进程列表（偏“每个 daemon 跑在哪台、什么状态”）。
- cephadm 取代 ceph-ansible：RHCS 5 引入 cephadm 统一管理集群全生命周期（部署/管理/监控）。cephadm 是 MGR 里的一个模块；5.x 全部容器化部署，宿主机只需
cephadm 包与容器运行时，其余全靠镜像。 - Bootstrap（引导）：
cephadm bootstrap 在单个节点拉起最小集群＝1 MON + 1 MGR（+必要依赖）；之后用 orchestrator 加主机/守护进程/存储。前置条件：先到 registry.redhat.io 注册并取得账号密码（https://access.redhat.com/RegistryAuthentication）。 - Orchestrator（编排器）：统一“声明式”地加主机/加守护进程/扩缩集群；CLI 入口
ceph orch（Dashboard 也可）；内部接口 mgr/orchestrator，cephadm 与 rook 都是它的后端实现（mgr/cephadm、mgr/rook）。 - 两类交互界面：bootstrap 后默认同时提供
- Ceph CLI（含容器化
cephadm shell：只有 bootstrap 节点能访问 /etc/ceph 的 admin keyring，故只建议在 bootstrap 节点运行）； - Dashboard GUI：
https://serverc:8443（课堂账号 admin/redhat，自签证书需信任）；默认 SSL/TLS 加密全部 HTTP 连接。
- Dashboard 典型功能速记：
- 管理：浏览 CRUSH map、启停/编辑 manager modules、增删管理 OSD、管理 iSCSI、管理 pools；
- 监控：集群健康、主机与服务、日志、告警、容量。
- 主界面三大块：Status / Capacity / Performance；Inventory（物理盘与主机）、CRUSH map 查看器、Pools 页面。
- 健康状态三档：
HEALTH_OK / HEALTH_WARN / HEALTH_ERR。
lab start intro-interface → Firefox 打开 https://serverc.lab.example.com:8443 → admin/redhat 登录；- 依次浏览 Dashboard 主屏（Status: HEALTH_OK、Hosts、Monitors quorum 0..3、Managers 1 active+3 standby、Pools、PGs 105 active+clean、Object Gateways、Metadata Servers、iSCSI Gateways）；
- Inventory → Hosts → 查看每台主机物理盘（类型 HDD、容量、可用）；
- Cluster → CRUSH map 查看器（default root → host → osd.N 层级）；
- Cluster → Pools（池列表、应用类型、保护、PG 状态）；
lab finish intro-interface。
| 命令 | 作用 |
|---|
cephadm shell | 进容器化 Ceph shell（含全部 ceph 命令；仅 bootstrap/管理节点推荐） |
cephadm shell -- ceph orch ls | 查看集群编排的服务（service 维度） |
ceph orch ps | 查看各守护进程（daemon 维度：host/status/端口/镜像） |
ceph status / ceph -s | 集群总览：mon 法定人数、mgr、osd up/in、池/PG、健康 |
ceph mon dump | MON map（epoch/fsid/各 MON v1/v2 地址） |
ceph mgr stat | MGR 状态 JSON（active_name / num_standby / available） |
ceph osd pool ls | 列出存储池 |
ceph pg stat | PG 状态汇总（如 105 active+clean） |
ceph osd status | 各 OSD ID/HOST/STATE/容量与读写指标 |
lab start/grade/finish <exercise> | 课堂实验：开始/评分/收尾 |
| 英文术语 | 中文 | 一句话速记 |
|---|
| RADOS | 可靠自治分布式对象存储 | Ceph 自愈自管理的软件对象存储后端 |
| MON / Monitor | 监视器 | 维护 cluster map、投票成 quorum（过半存活） |
| cluster map | 集群地图 | 5 张 map：mon/osd/pg/mds/crush；客户端据此自算对象位置 |
| OSD | 对象存储设备 | 每个 OSD 绑一块盘，管复制/恢复/再平衡（BlueStore） |
| MGR / Manager | 管理器 | 汇总运行时指标 → Dashboard/REST API；建议 2 个分故障域 |
| MDS | 元数据服务器 | 只服务 CephFS 元数据（POSIX 语义） |
| BlueStore | 蓝店后端 | RHCS 5 OSD 默认存储后端（裸盘高性能） |
| PG / Placement Group | 放置组 | 对象→PG（哈希桶）→OSD 的中间抽象层 |
| CRUSH | 可控复制伪随机哈希算法 | 免中央查表，客户端/OSD 自算 PG→OSD 映射 |
| CRUSH rule | 放置规则 | 决定副本/纠删分片按哪个故障域挑选 OSD |
| Acting Set / Up Set | 生效组/在线组 | PG 映射到的 OSD 集合；Up Set 首台＝Primary |
| pool | 池 | 对象逻辑分区（名字标签），含 PG 数/rule/保护类型等属性 |
| replicated / erasure coding | 副本/纠删码 | 整对象多拷贝 vs k+m 分片（省空间费 CPU） |
| data striping | 数据条带化 | 跨多设备分摊 I/O 提吞吐 |
| RBD / librbd | RADOS 块设备 | 供 KVM/QEMU 的块访问，可经 iSCSI gateway 共享 |
| CephFS / libcephfs | Ceph 文件系统 | 并行 POSIX 文件系统（需 MDS） |
| RADOS Gateway | 对象网关 | S3/Swift 兼容 API（librgw） |
| object map | 对象映射表 | librbd 客户端内存表，加速对不存在对象的判断 |
| persona | 用户角色画像 | 用“人设+任务”组织课程内容 |
| cephadm | Ceph 管理员工具 | 容器化全生命周期管理，取代 ceph-ansible |
| orchestrator | 编排器 | 统一加主机/daemon/服务（mgr/cephadm、mgr/rook） |
| bootstrap node | 引导节点 | cephadm bootstrap 拉起的首个节点（MON+MGR 最小集群） |
| Dashboard | 图形管理界面 | :8443 HTTPS，默认 admin；Status/Capacity/Performance 三大屏 |
- 说出 Ceph 四种守护进程及各自职责；为什么生产 MON 建议奇数台、MGR 建议 ≥2 台？
- 客户端读一个对象，如何不查中央表就知道该找哪个 OSD？（cluster map → hash(object)%pg_num → CRUSH → Up Set 首台 Primary）
- Primary OSD 与 Secondary OSD 的分工；OSD 增减后 PG 会发生什么？
- 副本池与纠删码池的取舍（空间 vs CPU/IO）；给出 4+2 的含义。
- Storage Administrator 与 Storage Operator 的画像差异（用哪种界面/做什么层级的事）。
- cephadm 相比 ceph-ansible 解决了什么？bootstrap 会得到什么最小集群？为什么要 registry.redhat.io 凭据？
ceph orch ls 与 ceph orch ps 分别回答什么问题？- Dashboard 三档健康状态是哪三个？进入课堂 Dashboard 的 URL 与默认账号？
- CephFS、RBD、RGW、librados 分别解决哪类访问？（file/block/object/native）
- 为什么 OSD 主机不能内核态挂载 RBD/CephFS？
