精读笔记（RHCA 英文教材）· CL260 Chapter 8 Providing Object Storage Using a RADOS Gateway
大约 7 分钟
精读笔记（RHCA 英文教材）· CL260 Chapter 8 Providing Object Storage Using a RADOS Gateway
教材原文：RHCA 官方英文教材（PDF 第 281~312 页）（OCR 整书版已从本站移除，本页为章节精读） 关联知识：Ch9（REST API 访问 RGW）；对象存储三特性回顾见 Ch1；
00-RHCA教材精读-导航与学习法.md
Chapter Goal / Objectives（原文+译）
- GOAL: Provide object storage with a RADOS Gateway and configure multisite replication（用 RGW 提供对象存储并配置多站点复制）.
- OBJECTIVES: ① 部署 RGW 并验证客户端访问；② 配置多站点（multisite）对象存储部署。
- 结构：两个 Section + 各 Guided Exercise + 章末 Lab（
lab grade object-review）。
8.1 Deploying an Object Storage Gateway
对象存储 vs RADOS Gateway
- 对象存储把数据存成扁平的命名空间里的对象（object），用唯一 object ID/key 取回，没有目录层级、不可嵌套；对象=二进制数据流+系统/扩展元数据（key-value），可任意大。
- bucket（S3 叫法，Swift 叫 container）是扁平命名空间的分区；一个用户可访问多 bucket，各 bucket 权限独立。
- RGW（radosgw）：基于 librados 的 Web 服务 daemon，前端用 Beast HTTP 库，同时提供 Amazon S3 与 OpenStack Swift API（另有 Admin API）。客户端→REST→RGW→librados→集群。
- RGW 用户（radosgw-admin 建）不是 cephx 用户：它们由网关认证（也可接外部 LDAP），网关再用内部 cephx 凭据访问集群。
RGW 自动建的池（默认 zone 一组）
.rgw.root(记录) / .default.rgw.control / .default.rgw.meta(用户键与关键元数据) / .default.rgw.log(操作日志) / .default.rgw.buckets.index / .default.rgw.buckets.data / .default.rgw.buckets.non-ec(分段上传元数据)。生产建议手工按 zone 名前缀建池（如 .us-east-1.rgw.buckets.data）。
静态网站托管
- RGW 支持在 S3 bucket 上做静态网站托管（比开虚拟机划算，适合纯 HTML/CSS）。
- 限制：托管实例不能再同时提供 S3/Swift API；域名与公网 IP 都要和标准 API 网关实例分开不重叠。
部署与前端
- cephadm 把 RGW 部署为 daemon 集合；可用
ceph orchCLI 或服务规格文件（含 realm/zone/placement/count/端口）：
service_type: rgw
service_id: realm.zone # 服务名 = realm.zone
placement: { hosts: [serverd, servere], count_per_host: 2 } # 每台 2 实例
spec:
rgw_frontends: "beast ssl_port=443" # 前端协议/端口
# ssl_certificate / ssl_certificate_key 也可配ceph orch apply -i rgw_service.yaml
ceph orch ps --daemon-type rgw # 验证实例与端口
ceph config get client.rgw rgw_frontends # 查看前端：beast port=80+443s- 生产前端放 HAProxy + keepalived 负载均衡（至少两台分开部署保高可用）；RHCS5 与 OpenStack Barbican（密钥托管）集成是 technology preview，不支持生产。
- 课堂 GE：
rgw_service.yaml里让 serverd/servere 各起 2 个 RGW 实例、端口从 8080 起 → apply → 验证 →lab finish。
实验要点 · Guided Exercise（lab: object-gateway）
建 realm/zone（单站）→ 写 rgw 规格文件 → ceph orch apply -i 部署 → ceph orch ps --daemon-type rgw 看到 4 实例（serverd×2 + servere×2，8080/8081…）→ 用 radosgw-admin 建网关用户拿 access/secret key → curl/S3 客户端验证上传下载 → finish。
8.2 Configuring a Multisite Object Storage Deployment（多站点）
层级模型（realm → zonegroup → zone）
- zone：一组 RGW 实例 + 一个独立 Ceph 集群；zone 内数据一致。
- zonegroup：一个或多个 zone；zone 内数据复制到组内所有 zone；每组有一个 master zone，其余为 secondary。
- realm：全局对象/桶命名空间（多站点复制空间）；含一个 master zonegroup + 若干 secondary zonegroup；所有 RGW 从 realm 拉配置。
- 元数据（bucket 增删/版本开关/用户管理）必须发生在 master zone（master zonegroup 里）——在 secondary zone 也能做但不会被同步，会造成元数据碎片与配置不一致。
- 常用拓扑：单 zone / 多 zone（一 zonegroup 多 zone，各配独立集群，容灾） / 多 zonegroup（区域管理） / 多 region（一套硬件多命名空间）。最小多站点＝2 个集群各一 RGW，同一 realm、同一 master zonegroup，一个挂 master zone、一个挂 secondary zone。
- 同步：首次全量，之后增量；数据操作写进各 zone 的 data log 并通知对端；元数据操作由 master 更新 meta log 通知其它网关。
配置（master zone 侧）
# 1) 建 realm（并设为默认）
radosgw-admin realm create --default --rgw-realm=gold
# 2) 建 master zonegroup
radosgw-admin zonegroup create --rgw-zonegroup=us --master --default \
--endpoints=http://node01:80
# 3) 建 master zone（端点与 replication 系统用户钥匙）
radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-1 \
--master --default --endpoints=http://node01:80 \
--access-key=12345 --secret=67890
# 4) 建 system 用户（数据复制身份）
radosgw-admin user create --uid=sysadm --display-name="sysAdmin" \
--access-key=12345 --secret=67890 --system
# 5) 提交 period（realm 配置快照，跨集群同步的单元）
radosgw-admin period update --commit
# 6) 建 RGW 服务并指到该 zone
ceph orch apply rgw gold.us-east-1 --zone=us-east-1 --placement="1 node01"
# 7) 若需改 zone 名，更新配置库后重新 period update --commit配置（secondary zone 侧 / 故障提升）
radosgw-admin realm default --rgw-realm=cl260
radosgw-admin zonegroup default --rgw-zonegroup=classroom
# 建 secondary zone（endpoint 指向本集群）
radosgw-admin zone create --rgw-zonegroup=classroom --rgw-zone=us-east-2 --endpoints=http://serverf:80 ...
radosgw-admin period pull --url=http://serverc:80 --access-key=replication --secret-key=secret # 拉取 master 的 period
radosgw-admin period get-current # 确认 current_period 与 master 一致
# 部署 RGW 服务指向该 zone；之后
radosgw-admin sync status # 数据/元数据同步状态（master ↔ secondary）- master zone 挂了恢复前，可把 secondary zone 提升为 master：改 zone 与 zonegroup（
--master）→ period update --commit 通告全网。 - 系统用户（
radosgw-admin user create --system，如 admin.user/uid 与 replication 账号）用于跨集群复制；access/secret key 存在 zone 配置里供对端拉取。
实验要点 · Guided Exercise + Lab（lab: object-review）
GE：serverc 上建 realm cl260/zonegroup classroom/master zone → 建 --system 复制用户 → period update --commit → serverf（第二集群）建同名 realm/zonegroup/us-east-2 zone → radosgw-admin period pull 从 serverc 拉配置 → 两端部署 RGW → radosgw-admin sync status 验证；Lab：补建 admin.user（--system，access=admin/secret=secure）等系统用户并验证 bucket 跨 zone 出现 → lab grade object-review。
命令速查表（本章）
| 命令 | 作用 |
|---|---|
ceph orch apply -i rgw.yaml / ceph orch apply rgw REALM.ZONE --placement=… | 部署 RGW 服务 |
ceph orch ps --daemon-type rgw | 查看 RGW 实例与端口 |
ceph config get client.rgw rgw_frontends | 看前端（beast port=…） |
radosgw-admin user create --uid=U --display-name=N [--system] [--access-key=… --secret=…] | 建网关用户/系统用户 |
radosgw-admin realm create --default --rgw-realm=R | 建 realm |
radosgw-admin zonegroup create --rgw-zonegroup=ZG --master --default --endpoints=… | 建 master zonegroup |
radosgw-admin zone create --rgw-zonegroup=ZG --rgw-zone=Z --master --endpoints=… [--access-key … --secret …] | 建 zone（带复制钥匙） |
radosgw-admin period update --commit | 提交 realm 配置快照 |
radosgw-admin period pull --url=http://HOST:PORT --access-key=… --secret-key=… | 对端拉取 period |
radosgw-admin period get-current / sync status | 查配置版本/同步状态 |
词汇表（本章）
| 英文术语 | 中文 | 一句话速记 |
|---|---|---|
| object / object key | 对象/对象键 | 扁平命名空间里按唯一 ID 存取的数据单元 |
| bucket / container | 桶/容器 | S3/Swift 的分区概念，不可嵌套 |
| RGW / radosgw | 对象网关 | librados 之上的 S3/Swift REST 服务（Beast 前端） |
| Beast | HTTP 前端库 | radosgw 的 Web 服务器库 |
| realm | 领域 | 多站点全局命名空间（最高层级） |
| zonegroup | 区域组 | 组内 zone 互相同步；一个 master zonegroup |
| zone | 区域 | 一组 RGW+独立集群；组内一个 master zone |
| master zone | 主区域 | 元数据操作必须在此发生 |
| period | 配置期 | realm 配置快照，update--commit 后全网拉取 |
| system user | 系统用户 | 跨集群复制的身份（--system） |
| metadata / data log | 元数据/数据日志 | 同步靠 meta log（master）与 data log（各 zone） |
| static web hosting | 静态网站托管 | S3 bucket 直接托管静态网页（独立实例限制） |
| HAProxy / keepalived | 负载均衡/高可用 | RGW 前端双机 VIP+转发 |
自测
- 对象存储三特性（扁平命名空间、REST API、唯一 ID）？S3 bucket 与 Swift container 的关系？
- RGW 用户与 cephx 用户的认证层次差异（网关认证 → 内部 cephx）？
- RGW 默认会建哪些池（至少 6 个）？生产手动建池为什么建议 zone 名前缀？
- 静态托管实例与标准 API 实例要满足哪三个“分离”限制？
- 用服务规格文件在 serverd/servere 各起 2 个、端口 8080 起的 RGW，怎么写？如何验证？
- realm/zonegroup/zone 三级各是什么？“元数据必须在 master zone 做”为什么重要？
- 最小多站点部署需要什么拓扑（2 集群+2 RGW+1 realm+1 master zonegroup）？
- 写出 master 侧“建 realm→zonegroup→zone→system user→period commit”的命令链；secondary 侧如何拉取配置（period pull 参数）？
- period 的作用？改 zone/提升 secondary 为 master 后必须做什么（period update --commit）？
- sync 首次与后续如何工作（全量→增量，meta log/data log）？用什么命令查同步状态？