Rook/Ceph 面试题

30 道题

分类: Kubernetes
子分类: csi
题目数: 30 道

已阅读 0 / 30 题

1 Rook/Ceph 的核心架构由哪些组件构成？

答案：

Rook/Ceph 架构分为 Rook 管理平面和 Ceph 存储平面。

Rook 管理平面：

Rook Operator：以 Deployment 部署，负责协调 Ceph 集群的部署和运维，监控 CRD 变更，自动执行集群调整操作
Rook Agent：每个节点上的 DaemonSet，通过 FlexDriver 或 CSI Driver 处理卷的挂载卸载
Rook Disco：发现节点上的块设备并自动识别可用的存储设备

Ceph 存储平面：

MON（Monitor）：维护集群映射图（Cluster Map），包括 OSD Map、PG Map、CRUSH Map。使用 Paxos 协议保证一致性，最小部署 3 节点
OSD（Object Storage Daemon）：实际存储数据，每个磁盘对应一个 OSD 进程。负责数据读写、复制、恢复和再平衡
MGR（Manager）：提供集群监控、仪表盘、REST API 和 prometheus 指标聚合
MDS（Metadata Server）：CephFS 的元数据服务，管理文件系统的目录和文件元数据
RGW（RADOS Gateway）：对象存储网关，提供 S3 和 Swift 兼容接口

组件	部署方式	职责
Rook Operator	Deployment	运维自动化
Ceph MON	DaemonSet / Deployment	集群一致性
Ceph OSD	DaemonSet（每磁盘）	数据存储
Ceph MGR	Deployment	监控和指标
Ceph MDS	Deployment	CephFS 元数据
Ceph RGW	Deployment	S3 对象存储

2 Ceph 的 CRUSH 算法的作用是什么？

答案：

CRUSH（Controlled Replication Under Scalable Hashing）是 Ceph 的核心算法，用于计算数据在 OSD 上的分布和定位。

核心功能：

数据分布：根据集群拓扑（Root → Row → Rack → Host → OSD）计算数据放置位置
数据定位：客户端直接计算数据存储位置，无需查询中心化元数据服务器
故障域控制：通过 CRUSH Map 定义故障域（磁盘、主机、机架、机房），确保副本分布在独立故障域

CRUSH Map 示例：

root default {
    id -1
    item rack-1 weight 12.0
    item rack-2 weight 12.0
}

rack-1 {
    id -2
    item host-1 weight 4.0
    item host-2 weight 4.0
    item host-3 weight 4.0
}

host-1 {
    id -3
    item osd.0 weight 1.0
    item osd.1 weight 1.0
}

CRUSH 算法优势：

去中心化：客户端可直接计算数据位置，不依赖查询服务器
最小数据迁移：集群扩容/缩容时，仅迁移必要数据（约 n/N 比例）
自定义故障域：灵活定义副本/纠删码的分布策略

3 Ceph 的数据读写流程是怎样的？

答案：

Ceph 采用客户端直接访问架构，数据路径去中心化。

写入流程（同步复制，3 副本）：

写入请求 → librados 计算 PG 和 OSD 集合
  → 客户端直接连接主 OSD
  → 主 OSD 并行写入从 OSD（副本复制）
  → 所有 OSD 返回确认 → 客户端收到写入成功

读取流程：

读取请求 → librados 计算 PG 位置
  → 客户端直接连接主 OSD 或从 OSD（balance_read 均衡）
  → OSD 返回数据 → 客户端直接使用

关键概念：

PG（Placement Group）：对象到 OSD 之间的中间逻辑层，一个 PG 包含多个对象
PG 分裂（Split）：PG 数不足时可动态分裂为更多 PG
EC（Erasure Coding）：替代副本模式，k+m 编码方式，空间效率更高

写延迟公式（同步复制）：

写入延迟 = 主 OSD 写入 + 从 OSD 复制确认
典型值（3副本，NVMe，10Gbps）：1-3ms

4 Rook 如何管理 Ceph OSD？

答案：

Rook 通过 CephCluster CRD 和 StorageClassDeviceSets 定义 OSD 的创建和管理策略。

OSD 部署模式：

1. 使用节点上的原始设备：

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  storage:
    useAllNodes: true
    useAllDevices: true
    # 排除特定设备
    deviceFilter: "^sd[b-z]"
    config:
      osdsPerDevice: "2"  # 每块盘 2 个 OSD 进程

2. StorageClassDeviceSets（推荐生产）：

spec:
  storage:
    storageClassDeviceSets:
    - name: ssd-set
      count: 3   # 3 个节点
      portable: false
      volumeClaimTemplates:
      - metadata:
          name: data
        spec:
          storageClassName: local-storage
          resources:
            requests:
              storage: 500Gi
      - metadata:
          name: metadata
        spec:
          storageClassName: local-storage
          resources:
            requests:
              storage: 10Gi
      placement:
        topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname

OSD 自动发现和管理：

# Rook 自动发现节点上的新设备
# 如果是 useAllDevices: true，自动创建 OSD
# 如果手动指定，需更新 CephCluster CRD

# 查看 OSD 状态
kubectl -n rook-ceph get pods -l app=rook-ceph-osd
ceph osd status
ceph osd tree

5 Ceph 如何处理数据不平衡和再平衡？

答案：

Ceph 通过 CRUSH 算法和自动再平衡机制处理集群数据分布不均。

再平衡触发条件：

新 OSD 加入集群
OSD 故障被移除
OSD 权重变更
PG 数量变更

再平衡过程：

添加 3 个新 OSD（集群从 10→13OSD）
  → CRUSH 重新计算 PG 到 OSD 的映射
  → 约 3/13 ≈ 23% 的 PG 需要迁移到新 OSD
  → OSD 之间并行迁移数据
  → 迁移完成后平衡状态恢复

手动平衡：

# 调整 OSD 权重（reweight）
ceph osd reweight-by-pg <osd-id> 1.0

# 查看 OSD 使用率
ceph osd df
# 推荐：最高使用率 - 最低使用率的差值 < 5%

平衡控制参数：

# rook-ceph-cluster.yaml
spec:
  cephConfig:
    global:
      osd_recovery_max_active: "5"         # 每 OSD 最大并发恢复 PG
      osd_max_backfills: "1"               # 每 OSD 最大并发 Backfill
      osd_recovery_op_priority: "3"        # 恢复操作优先级（2-10）
      osd_recovery_max_single_start: "1"   # 每 OSD 单次启动的最大恢复 PG

性能影响：

再平衡期间：
- 恢复正常 I/O 延迟增加 10-30%
- 网络带宽占用增加
- 建议在低峰期执行大规模扩容

6 Ceph 的 EC（Erasure Coding）与副本模式有什么差异？

答案：

EC（纠删码）和副本是 Ceph 两种数据冗余策略，EC 在空间效率上更优，但计算开销更大。

维度	副本（Replicated）	纠删码（Erasure Coding）
数据冗余	完整副本	k+m 编码块
空间效率	3 副本 = 300%	k=4,m=2 = 150%
写性能	高（直接写入）	中（编码计算）
读性能	高（直接读取）	中（需解码）
恢复开销	低（复制文件）	高（需重新计算）
适用场景	性能敏感	容量敏感

EC 配置示例：

apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: ec-pool
  namespace: rook-ceph
spec:
  replicated:
    size: 3  # 仍需 3 副本作为元数据池
apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: ec-data-pool
  namespace: rook-ceph
spec:
  erasureCoded:
    dataChunks: 4    # 数据块数
    codingChunks: 2  # 校验块数
    algorithm: "jerasure"  # 编码算法

EC 算法对比：

算法	特性	CPU 开销	适用场景
jerasure	通用，兼容性好	中	通用场景
shec	局部恢复优化	中	小规模数据
lrc	局部校验块，加速恢复	中	大集群

EC 池要求池包含至少 k+m 个故障域（OSD），否则无法创建 PG。

7 Ceph 的 RBD（RADOS Block Device）是如何工作的？

答案：

RBD 是 Ceph 的块存储接口，将 Ceph 集群的 RADOS 对象存储暴露为块设备。

RBD 架构：

客户端 → krbd（内核模块）或 librbd（用户态库）
  → librados → RADOS 集群 → OSD 存储

RBD 特性：

Thin Provisioning：按需分配实际存储空间
快照：支持读/写时复制快照（COW）
克隆：从快照创建写时复制克隆
在线扩容：块设备在线扩展
Striping：数据跨对象条带化，提升并行度

RBD StorageClass（Rook 管理）：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: rook-ceph-block
provisioner: rook-ceph.rbd.csi.ceph.com
parameters:
  clusterID: rook-ceph
  pool: replicapool
  imageFeatures: layering,fast-diff,object-map,deep-flatten,exclusive-lock
  csi.storage.k8s.io/fstype: ext4
  csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
  csi.storage.k8s.io/node-stage-secret-namespace: rook-ceph
reclaimPolicy: Delete
allowVolumeExpansion: true

RBD 性能调优：

# StorageClass 性能参数
parameters:
  # Object Size 影响吞吐
  objectSize: "4M"     # 4MB 对象大小（默认 4M，增加减少小文件压力）
  
  # Striping 提升并行度
  stripingUnit: "64K"   # 条带单元
  stripingCount: "16"   # 条带数 (= 1MB 每对象)

8 Ceph 的 CephFS 是如何实现文件存储的？

答案：

CephFS 是 Ceph 的 POSIX 兼容分布式文件系统，通过 MDS（Metadata Server）管理元数据。

CephFS 架构：

客户端 → ceph-fuse（用户态）或 kernel ceph.ko（内核态）
  → RADOS（数据流: 通过 OSD）
  → MDS（元数据流）

CephFS 关键特性：

POSIX 兼容：支持标准文件系统操作（open/read/write/stat）
动态子树分区：MDS 自动将元数据负载在多个 MDS 间分担
主动缓存：MDS 缓存元数据，提升目录操作性能
快照：目录级别快照

CephFS StorageClass：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: rook-cephfs
provisioner: rook-ceph.cephfs.csi.ceph.com
parameters:
  clusterID: rook-ceph
  fsName: myfs
  pool: myfs-data-0
  csi.storage.k8s.io/node-stage-secret-name: rook-csi-cephfs-node
  csi.storage.k8s.io/node-stage-secret-namespace: rook-ceph
reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
- noatime  # 减少元数据操作

MDS 高可用配置：

# CephFilesystem CRD
apiVersion: ceph.rook.io/v1
kind: CephFilesystem
metadata:
  name: myfs
  namespace: rook-ceph
spec:
  metadataPool:
    replicated:
      size: 3
  dataPools:
  - name: data-ssd
    replicated:
      size: 3
  metadataServer:
    activeCount: 2      # 活跃 MDS 数
    activeStandby: true # 是否有热备
    placement:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: role
              operator: In
              values:
              - mds-node

9 Ceph 的 RGW（RADOS Gateway）如何实现对象存储？

答案：

RGW 提供 S3 和 Swift 兼容的 RESTful API，将对象存储在 Ceph 集群中。

RGW 架构：

S3/Swift 客户端 → HTTP → RGW（Civetweb/Beast）
  → librados → OSD 存储

RGW 数据组织：

每个对象的存储结构：
  - 对象数据: RADOS OMAP + data
  - 元数据: bucket index + user info
  - 多部分上传: 拆分为多个段

RGW 多站点（Multi-Site）：

# Rook RGW 配置
apiVersion: ceph.rook.io/v1
kind: CephObjectStore
metadata:
  name: my-store
  namespace: rook-ceph
spec:
  metadataPool:
    replicated:
      size: 3
  dataPool:
    erasureCoded:
      dataChunks: 4
      codingChunks: 2
  preservePoolsOnDelete: true
  gateway:
    type: s3
    port: 80
    instances: 3  # 多实例负载均衡
    placement:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: role
              operator: In
              values:
              - rgw-node

S3 Bucket 访问：

# 创建 ObjectBucketClaim
apiVersion: objectbucket.io/v1alpha1
kind: ObjectBucketClaim
metadata:
  name: my-bucket
spec:
  storageClassName: rook-ceph-bucket
  generateBucketName: my-bucket
  additionalConfig:
    maxObjects: "100000"
    maxSize: "10G"

性能优化：

使用 Beast 前端（替代 Civetweb，更高并发）
配置 Bucket Index Sharding 加速大规模 bucket 操作
启用压缩（zlib/lz4/snappy/zstd）

10 Rook 如何处理 Ceph 节点的故障恢复？

答案：

Rook Operator 自动监控 Ceph 组件状态，在节点故障时执行自动恢复。

MON 故障恢复：

MON pod 故障 → Rook Operator 检测到 MON 不可用
  → 在可用节点重新创建 MON
  → 新 MON 从其他 MON 同步数据库
  → 集群 MON 数恢复为奇数（3/5）

OSD 故障恢复：

磁盘故障 → 对应 OSD 标记为 down 和 out
  → CRUSH Map 更新，故障 OSD 退出 PG 映射
  → Ceph 自动在其他 OSD 上恢复 PG 副本
  → 更换磁盘后，Rook 自动发现并创建新 OSD

替换故障磁盘：

# 1. 标记故障 OSD
kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph osd out <osd-id>

# 2. 删除故障 OSD 的 Deployment
kubectl -n rook-ceph delete deployment rook-ceph-osd-<osd-id>

# 3. 清理故障 OSD 数据
kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph osd purge <osd-id> --yes-i-really-mean-it

# 4. 更换磁盘后自动发现

# 5. Rook 自动创建新 OSD

节点完全故障：

节点宕机 → Rook 检测到节点 NotReady
  → 如果 MON 在该节点 → 重新调度到健康节点
  → OSD 进程停止 → Ceph 数据面自动恢复
  → 如果超过故障时间（默认 10 分钟）→ 触发 rebalance

11 Rook 如何配置和管理 Ceph 的存储池（Pool）？

答案：

Rook 通过 CephBlockPool CRD 定义和管理存储池。

Pool 配置：

apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: replicapool
  namespace: rook-ceph
spec:
  failureDomain: host        # 故障域: osd/host/rack
  replicated:
    size: 3                  # 副本数
    requireSafeReplicaSize: true  # 需要安全副本数
  parameters:
    compression_mode: "aggressive"  # 压缩: none/aggressive/passive/force
    compression_algorithm: "lz4"    # 压缩算法: lz4/snappy/zstd/zlib
    compression_required_ratio: ".875"
  mirroring:
    enabled: true
    mode: "pool"   # 池级别镜像
  quotas:
    maxBytes: 10T  # 最大容量配额
    maxObjects: 1000000
  statusCheck:
    mirror:
      disabled: false

Pool 类型选择：

Pool 类型	CRUSH 规则	适用场景
副本池	replicated_rule	通用块存储、RBD
纠删码池	ec_rule	对象存储、冷数据
分层池	通过 Cache Tier	热/冷数据自动分层

PG 数量计算：

PG_Count = (OSD_Count × Target_PG_per_OSD) / Replica_Size
示例：50 OSD × 100 PG/OSD / 3 副本 ≈ 1667 PG

经验公式：
  < 5 OSD: 128 PG
  5-10 OSD: 512 PG
  10-50 OSD: 1024 PG
  > 50 OSD: 2048 PG 或公式计算

12 Rook 的监控和仪表盘功能如何配置？

答案：

Rook/Ceph 通过 MGR 模块和 Prometheus 集成提供全面的监控能力。

启用 Ceph Dashboard：

# CephCluster CRD 启用 Dashboard
spec:
  dashboard:
    enabled: true
    ssl: true
    port: 8443

访问 Dashboard：

# 暴露 Service
kubectl -n rook-ceph get service rook-ceph-mgr-dashboard
# 或端口转发
kubectl -n rook-ceph port-forward service/rook-ceph-mgr-dashboard 8443:8443

# 获取登录密码
kubectl -n rook-ceph get secret rook-ceph-dashboard-password \
  -o jsonpath="{['data']['password']}" | base64 --decode && echo

Prometheus 集成：

# 启用 MGR Prometheus 模块
spec:
  monitoring:
    enabled: true
    rulesNamespace: rook-ceph
# 自动创建 ServiceMonitor
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: rook-ceph-mgr
  namespace: rook-ceph
spec:
  selector:
    matchLabels:
      app: rook-ceph-mgr
  endpoints:
  - port: http-metrics
    path: "/metrics"

关键监控指标（Rook 层面）：

# Ceph 集群健康
ceph_health_status    # 0=HEALTH_OK, 1=HEALTH_WARN, 2=HEALTH_ERR

# OSD 状态
ceph_osd_in           # 在线 OSD 数
ceph_osd_up           # 正常运行 OSD 数
ceph_osd_down         # 宕机 OSD 数

# 存储容量
ceph_cluster_total_used_bytes  
ceph_cluster_total_bytes
ceph_cluster_total_used_raw_bytes

# PG 状态
ceph_pg_active        # 活跃 PG 数
ceph_pg_degraded      # 降级 PG 数
ceph_pg_stuck_unclean # 卡住 PG 数

PrometheusRule 示例：

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: ceph-alerts
  namespace: monitoring
spec:
  groups:
  - name: ceph
    rules:
    - alert: CephClusterHealthError
      expr: ceph_health_status == 2
      for: 5m
      annotations:
        summary: "Ceph 集群健康状态错误"
    - alert: CephOSDDown
      expr: ceph_osd_down > 0
      for: 5m
      annotations:
        summary: "XQOPEN $value XQCLOSE 个 OSD 宕机"
    - alert: CephPGStuckInactive
      expr: ceph_pg_stuck_inactive > 0
      for: 5m
      annotations:
        summary: "XQOPEN $value XQCLOSE 个 PG 卡住"

13 Ceph 如何处理存储容量不足的问题？

答案：

Ceph 通过全满（Full）比率和水位线机制控制存储容量。

容量水位线：

正常区域:     0% →           85% →    95% →     100%
Full Ratio:                  85%（默认：停止写入）
Near Full:        75%（告警阈值）
Backfillful:                       95%（停止数据再平衡）

配置容量告警：

# 查看当前使用率
ceph osd df
ceph df

# 设置 Full Ratio
ceph osd set-full-ratio 0.90   # 将 Full 阈值从 85% 提升到 90%

# 设置 Near Full Ratio
ceph osd set-nearfull-ratio 0.80

容量不足处理策略：

扩容：增加新 OSD 或增大现有 OSD 权重
平衡：调整 CRUSH 权重使分布更均匀
清理：删除无用快照和数据
归档：将冷数据迁移到 EC 池

Rook 层面的容量管理：

# CephCluster CRD 配置
spec:
  storage:
    storageClassDeviceSets:
    - count: 6  # 扩容时增加 count
    ...
# StorageClass OverProvisioning 限制
parameters:
  csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner

14 Rook 如何处理 Ceph 集群的升级？

答案：

Rook Operator 内置自动化升级流程，支持 Ceph 版本和 Rook 版本的升级。

Rook 版本升级：

# 1. 更新 Rook Operator 的镜像版本
kubectl -n rook-ceph set image deployment/rook-ceph-operator \
  rook-ceph-operator=rook/ceph:v1.14.0

# 2. 启用自动升级
kubectl -n rook-ceph edit configmap rook-ceph-operator-config
# operator:
#   ROOK_CURRENT_NAMESPACE_ONLY: "false"
#   ROOK_LOG_LEVEL: "INFO"
#   ROOK_UNREACHABLE_NODE_TOLERATION_SECONDS: "5"

# 3. 触发 Ceph 守护进程更新
kubectl -n rook-ceph patch CephCluster rook-ceph --type merge \
  -p '{"spec": {"cephVersion": {"image": "quay.io/ceph/ceph:v18.2.0"}}}'

自动升级顺序：

1. MON（逐个升级，保持仲裁）
2. MGR（滚动升级）
3. OSD（逐节点，先标记 out → drain → 升级 → 标记 in）
4. MDS（Standby 切换）
5. RGW（滚动升级）

升级策略：

# 升级时暂停指定守护进程
spec:
  skipUpgradeChecks: false
  continueUpgradeAfterChecksEvenIfNotHealthy: false
  # 允许同时最大不可用 OSD 数
  disruptionManagement:
    managePodBudgets: true
    osdMaintenanceTimeout: 30
    pgHealthCheckTimeout: 5

升级验证：

# 检查版本
kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph version

# 检查集群健康
kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph status

# 查看升级进度
kubectl -n rook-ceph logs deployment/rook-ceph-operator -f | grep "upgrade"

15 Ceph 如何实现数据压缩？

答案：

Ceph 支持 Pool 级别的数据压缩，在 OSD 写入数据时触发压缩处理。

压缩配置：

apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: compressed-pool
spec:
  replicated:
    size: 3
  parameters:
    compression_mode: "aggressive"    # 压缩模式
    compression_algorithm: "zstd"     # 压缩算法
    compression_required_ratio: ".7"  # 压缩比例阈值

压缩模式：

模式	行为
none	不压缩
passive	仅当写请求的 hint 提示压缩时
aggressive	始终尝试压缩
force	强制压缩（即使压缩比未达标）

压缩算法对比：

算法	压缩比	速度（MB/s）	CPU 占用
lz4	2:1	1500	低
snappy	2.2:1	1200	低
zlib	3:1	300	高
zstd	3.5:1	800	中

压缩效率监控：

# 查看池压缩情况
ceph osd pool stats <pool-name> | grep compress

# 查看 OSD 压缩统计
ceph osd perf
ceph tell osd.* perf dump | grep compress

16 Rook 如何配置 Ceph 的网络和加密？

答案：

Rook 支持 Ceph 的公共网络和集群网络分离、以及传输加密配置。

双网络配置：

spec:
  network:
    # 公共网络（客户端访问）
    publicNetwork: "10.0.0.0/24"
    # 集群网络（OSD 复制）
    clusterNetwork: "10.1.0.0/24"
    # 加密
    enableMessagingV2: true
    connections:
      encryption: true        # 启用传输加密
      compression: true       # 启用传输压缩
      requireEncryption: true  # 要求所有连接必须加密

加密配置详解：

# 启用 Ceph 的 TCP Pre-shared Key (PSK) 加密
network:
  enableMessagingV2: true
  connections:
    encryption: true
    # 密钥由 Rook 自动管理
    # 生成密钥证书:
    # ceph config set mgr mgr/certificate <cert>
    # ceph config set mgr mgr/certificate_key <key>

TLS 证书配置：

# 自定义证书
spec:
  security:
    keyManagementService:
      tokenSecretName: vault-token
  tls:
    certSecretName: rook-ceph-cert

网络性能优化：

spec:
  network:
    # OSD 配置
    osd:
      publicAddress: "10.0.0.1/24"
      clusterAddress: "10.1.0.1/24"
    # 启用 DPDK
    dpdk:
      enabled: true
      lcores: "4-7"
      memory: "1024"

17 Rook 如何处理 CephFS 的配额管理？

答案：

Rook 通过 CephFS 的目录配额（Quota）功能限制文件和存储使用。

CephFS 配额配置：

# 通过 Ceph 工具设置目录配额
kubectl -n rook-ceph exec deploy/rook-ceph-tools -- \
  ceph fs set cephfs max_file_size 1099511627776  # 1TB

# 设置目录级别配额
setfattr -n ceph.quota.max_bytes -v 10737418240 /mnt/cephfs/user-a
setfattr -n ceph.quota.max_files -v 100000 /mnt/cephfs/user-a

# 查看配额
getfattr -n ceph.quota.max_bytes /mnt/cephfs/user-a

PVC 级别的配额：

# 通过 StorageClass 的 mountOptions
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: rook-cephfs-quota
provisioner: rook-ceph.cephfs.csi.ceph.com
parameters:
  clusterID: rook-ceph
  fsName: myfs
  pool: myfs-data-0
  csi.storage.k8s.io/provisioner-secret-name: rook-csi-cephfs-provisioner
  csi.storage.k8s.io/provisioner-secret-namespace: rook-ceph
mountOptions:
- "noatime"
- "context=system_u:object_r:container_file_t:s0"

配额监控：

# 查看文件系统使用
ceph fs status
ceph fs ls
ceph daemon mds.<id> perf dump | grep quota

18 Ceph 的 Scrubbing 机制是什么？

答案：

Scrubbing 是 Ceph OSD 的后台一致性检查机制，分为 Light Scrubbing 和 Deep Scrubbing。

Scrubbing 类型：

类型	检查内容	频率	性能影响
Light Scrubbing	对象大小和基本属性	默认每天一次	低（< 5%）
Deep Scrubbing	逐位数据校验 + CRC	默认每周一次	中（10-20%）

配置 Scrubbing：

# rook-ceph-cluster.yaml 中 Ceph 配置
spec:
  cephConfig:
    global:
      osd_scrub_auto_repair: "false"   # 自动修复
      osd_scrub_begin_hour: "22"       # 开始时间（22点）
      osd_scrub_end_hour: "6"          # 结束时间（6点）
      osd_max_scrubs: "1"              # 每 OSD 同时 scrubbing 数
      osd_scrub_min_interval: "86400"  # 最小间隔（秒）
      osd_scrub_max_interval: "259200" # 最大间隔（秒）
      osd_deep_scrub_interval: "604800" # 深度检查间隔（秒）

Scrubbing 状态查看：

# 查看所有 PG 的 Scrubbing 状态
ceph pg dump | grep scrubbing
ceph pg scrub <pgid>  # 手动触发

# 查看 OSD Scrubbing 状态
ceph osd status
ceph daemon osd.<id> scrub status

Scrubbing 问题处理：

# PG Scrub 卡住
ceph pg deep-scrub <pgid>  # 重新触发深度检查

# 取消 Scrubbing
ceph osd unset noscrub
ceph osd unset nodeep-scrub

19 Rook 如何处理 Ceph 集群的网络分区？

答案：

Rook 和 Ceph 对网络分区有专门的容错机制，涉及 MON 仲裁、OSD 心跳和 PG 恢复。

MON 网络分区：

3 MON 集群，MON-3 被网络隔离
  → MON-1 和 MON-2 维持仲裁（2/3 > 50%）
  → MON-3 无法参与 Paxos 选举
  → 集群正常运行，但不能容忍再一个 MON 故障
  → MON-3 恢复后自动同步数据并重新加入仲裁

OSD 网络分区：

网络分区隔离部分 OSD
  → OSD 之间心跳中断（每 6 秒）
  → 无法到达的 OSD 标记为 down
  → PG 所影响的副本标记为 degraded
  → 自动开始在可用 OSD 上恢复 PG
  → 分区恢复后，原 OSD 作为新 OSD 重新加入

Ceph 网络相关配置：

spec:
  cephConfig:
    global:
      mon_lease: "5"               # MON 租约时间
      mon_lease_renew_interval_factor: "3"
      mon_accept_timeout: "10"
      paxos_service_trim_min: "250"
      paxos_service_trim_max: "500"
      mon_election_timeout: "1"    # 选举超时
      mon_clock_drift_allowed: ".05"
      mon_clock_drift_warn_backoff: "30"

20 Ceph 如何处理大文件（分片和条带化）？

答案：

Ceph 通过条带化（Striping）机制将大文件分割为多个对象分布在多个 OSD 上。

条带化原理：

文件 10GB → 分片为 4MB 对象 → 每个对象存储在独立的 OSD
读取时并行从多个 OSD 获取对象 → 合并为完整文件

RBD 条带化配置：

# StorageClass 条带参数
parameters:
  # 默认条带化（全局）
  objectSize: "4M"
  # 自定义条带（每个对象级别）
  # stripingUnit: "64K"    # 条带单元大小
  # stripingCount: "16"    # 每个对象的条带数

条带化模式：

模式	说明	适用场景
默认	对象级别条带，1 对象 = 4MB	通用
用户自定义	更细粒度条带（64K × 16）	高并发大文件
文件级条带	CephFS 自动条带化	大文件存储

大文件性能优化：

spec:
  cephConfig:
    client:
      rbd_cache: "true"
      rbd_cache_size: "134217728"         # 128MB
      rbd_cache_max_dirty: "50331648"     # 48MB
      rbd_cache_target_dirty: "33554432"  # 32MB
      rbd_cache_max_dirty_age: "1"
      rbd_cache_writethrough_until_flush: "true"

21 Rook 如何配置 Ceph 的 RBD Mirroring？

答案：

RBD Mirroring 提供跨集群的块设备级异步复制，实现灾备。

启用 RBD Mirroring：

apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: mirrored-pool
spec:
  replicated:
    size: 3
  mirroring:
    enabled: true
    mode: "image"     # pool（池级别）或 image（镜像级别）
    peers:
      secretNames:
      - "rbd-mirror-peer"  # 对端集群的密钥

配置灾备对等集群：

# 主要集群
apiVersion: ceph.rook.io/v1
kind: CephRBDMirror
metadata:
  name: rbd-mirror
  namespace: rook-ceph
spec:
  count: 1
  placement:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: role
            operator: In
            values:
            - rbd-mirror
# 灾备集群同样部署 RBD Mirror

镜像同步模式：

模式	RPO	描述
pool	数秒	池内所有镜像自动同步
image	用户控制	手动为特定镜像启用

监控同步状态：

# 查看 RBD Mirror 状态
kubectl -n rook-ceph exec deploy/rook-ceph-tools -- \
  rbd mirror pool status replicapool

# 查看特定镜像
kubectl -n rook-ceph exec deploy/rook-ceph-tools -- \
  rbd mirror image status replicapool/<image-name>

22 Ceph 如何处理 OSD 的性能故障（慢 OSD）？

答案：

Ceph 内置慢 OSD 检测机制，自动识别和隔离性能异常的 OSD。

慢 OSD 检测标准：

# Ceph 配置
spec:
  cephConfig:
    osd:
      osd_op_complaint_time: "30"         # 操作超时告警（秒）
      osd_op_history_size: "20"           # 历史操作记录
      osd_op_history_duration: "600"      # 历史记录时长
      osd_max_completed_hist: "100"
      osd_client_message_size_cap: "524288000"
      osd_pg_log_dups_ratio: ".3"

检测慢 OSD：

# 查看 OSD 操作延迟
ceph osd perf | sort -k 3 -n  # 按延迟排序

# 查看慢请求
ceph daemon osd.<id> dump_historic_ops | jq '.ops[] | select(.duration > 10)'

# 查看 OSD 级别操作分布
ceph daemon osd.<id> perf dump | grep op_latency

慢 OSD 常见原因及处理：

原因	表现	处理措施
磁盘故障	大量 I/O 错误	停止 OSD，更换磁盘
网络问题	延迟波动	检查网卡/交换机
磁盘满	写入延迟增加	清理数据或扩容
硬件争用	CPU/内存不足	资源隔离

自动隔离慢 OSD：

spec:
  cephConfig:
    osd:
      osd_op_complaint_time: "30"
      mon_osd_down_out_interval: "600"       # 自动标记 out 的间隔
      mon_osd_down_out_subtree_limit: "host" # 故障域限制

23 Rook 如何处理 Ceph 的 BlueStore 配置优化？

答案：

BlueStore 是 Ceph 的默认 OSD 存储引擎，相比 FileStore 有显著的性能优势。

BlueStore 架构：

graph TD
    A["Block Device<br/>WAL + DB + Data"] --> B["RocksDB<br/>元数据键值存储"]
    B --> C["BlueFS<br/>轻量文件系统"]

BlueStore 关键配置：

spec:
  # 每个 OSD 的存储配置
  storage:
    storageClassDeviceSets:
    - name: ssd-set
      count: 3
      volumeClaimTemplates:
      - metadata:
          name: data
        spec:
          resources:
            requests:
              storage: 500Gi
          storageClassName: local-storage
      - metadata:
          name: wal          # WAL + DB 使用 SSD
        spec:
          resources:
            requests:
              storage: 10Gi
          storageClassName: local-ssd  # 单独 SSD 存储类

BlueStore vs FileStore 对比：

维度	BlueStore	FileStore
写入路径	直接写块设备	写 XFS 文件系统
双写开销	无	有（Journal + 文件）
RocksDB	原生集成	无
校验和	内置（CRC32C/XXHASH）	无
压缩	原生支持	不支持
性能	高（2-3x FileStore）	一般

BlueStore Cache 配置：

spec:
  cephConfig:
    osd:
      bluestore_cache_size: "1073741824"        # 1GB
      bluestore_cache_size_hdd: "1073741824"
      bluestore_cache_size_ssd: "3221225472"    # 3GB
      bluestore_max_blob_size: "524288"          # 512KB
      bluestore_min_alloc_size: "4096"           # 4KB
      bluestore_throttle_bytes: "67108864"       # 64MB
      bluestore_fsck_quick_fix: "true"           # 快速修复

24 Rook 如何管理 Ceph 的密钥（Keyring）？

答案：

Rook 自动管理 Ceph 的认证密钥（Keyring），存储在 Kubernetes Secret 中。

密钥类型：

组件	密钥用途	Secret 名称
Admin	集群管理	rook-ceph-admin-keyring
MON	MON 间通信	rook-ceph-mon-keyring
OSD	OSD 认证	rook-ceph-osd-keyring
MGR	MGR 客户端认证	rook-ceph-mgr-keyring
MDS	MDS 客户端认证	rook-ceph-mds-keyring
RGW	RGW 客户端认证	rook-ceph-rgw-keyring
Client	CSI 挂载认证	rook-csi-rbd-node / rook-csi-cephfs-node

查看密钥：

kubectl -n rook-ceph get secrets | grep keyring

# 获取 Admin 密钥
kubectl -n rook-ceph get secret rook-ceph-admin-keyring \
  -o jsonpath='{.data.keyring}' | base64 -d

CSI 凭据自动管理：

Rook 自动创建 CSI 所需的 Secret
CSI Provisioner 使用管理员凭据创建/删除卷
CSI Node 使用客户端凭据执行挂载操作
凭据轮换通过 ceph auth 命令更新

25 Rook 如何处理节点磁盘的替换？

答案：

Rook 提供完整的磁盘替换流程，从检测故障到新 OSD 自动创建。

磁盘替换流程：

# 1. 确认故障磁盘对应的 OSD
ceph osd tree
ceph osd df | grep <osd-id>

# 2. 标记 OSD 为 out（停止数据迁移）
ceph osd out <osd-id>

# 3. 等待 PG 迁移完成
ceph pg stat
# active+clean 表示完成

# 4. 停止 OSD 进程
kubectl -n rook-ceph delete deployment rook-ceph-osd-<id>

# 5. 从 CRUSH Map 移除（purge 方式）
ceph osd purge <osd-id> --yes-i-really-mean-it

# 6. 物理更换磁盘

# 7. Rook 自动发现并创建新 OSD
kubectl -n rook-ceph logs deployment/rook-ceph-osd-<new-id>

Rook 自动发现新磁盘：

# CephCluster 配置
spec:
  storage:
    useAllNodes: true
    useAllDevices: true
    # 自动发现周期（秒）
    deviceDiscovery:
      refreshInterval: 300

使用 PVC 替换：

# 如果使用 StorageClassDeviceSets
# 只需删除对应的 PVC，Rook 会自动重新创建
kubectl -n rook-ceph delete pvc <osd-pvc-name>
# Rook 自动创建新的 PVC 和 OSD

26 Ceph 的 Cache Tiering 分层存储如何工作？

答案：

Ceph 通过 Cache Tiering 在 SSD 和 HDD 之间自动管理数据分层。

Cache Tier 架构：

热数据层（SSD） → Cold 数据降级 → 冷数据层（HDD）

配置 Cache Tier：

# 1. 创建热层池（SSD）
ceph osd pool create hot-tier 128 128
ceph osd tier add replicapool hot-tier

# 2. 设置缓存模式
ceph osd tier cache-mode hot-tier writeback

# 3. 设置缓存参数
ceph osd tier set-overlay replicapool hot-tier
ceph osd pool set hot-tier hit_set_type bloom
ceph osd pool set hot-tier hit_set_count 4
ceph osd pool set hot-tier hit_set_period 3600      # 1小时
ceph osd pool set hot-tier target_max_bytes 107374182400  # 100GB
ceph osd pool set hot-tier target_max_objects 100000
ceph osd pool set hot-tier cache_target_dirty_ratio 0.4
ceph osd pool set hot-tier cache_target_full_ratio 0.8

Cache Tier 模式：

模式	写行为	读行为
writeback	写热层，异步推冷层	优先读热层
readforward	写热层，同步写冷层	读冷层
readonly	不写热层	只读热层

提示：Ceph Luminous 版本后 Cache Tiering 被视为遗留功能，推荐使用多副本池 + EC 池组合方案。

27 Rook 如何处理 CephFS 的 Subvolume 组？

答案：

CephFS Subvolume 组提供文件系统的逻辑分组，用于多租户隔离和配额管理。

创建 Subvolume 组：

# 通过 Ceph 工具
kubectl -n rook-ceph exec deploy/rook-ceph-tools -- \
  ceph fs subvolumegroup create myfs group1 \
  --pool_layout myfs-data-0 \
  --uid 1000 \
  --gid 1000 \
  --mode 755

CephFS Subvolume 操作：

# 在 Subvolume 组中创建 Subvolume
ceph fs subvolume create myfs subvol1 group1 \
  --size 10737418240  # 10GB 配额

# 查看 Subvolume 信息
ceph fs subvolume info myfs subvol1 group1

# 列出所有 Subvolume
ceph fs subvolume ls myfs group1

# 授权客户端访问
ceph fs authorize myfs client.client1 /group1/subvol1 rw

Subvolume 的 Kubernetes 集成：

# Rook CSI 动态创建 Subvolume
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: cephfs-subvol
provisioner: rook-ceph.cephfs.csi.ceph.com
parameters:
  clusterID: rook-ceph
  fsName: myfs
  pool: myfs-data-0
  csi.storage.k8s.io/provisioner-secret-name: rook-csi-cephfs-provisioner
  # subvolumeGroup 参数自动创建 Subvolume
  subvolumeGroup: group1

28 Rook 如何配置 Ceph 的多站点 RGW？

答案：

多站点 RGW 实现跨地域的对象存储同步和灾备。

主集群配置：

apiVersion: ceph.rook.io/v1
kind: CephObjectRealm
metadata:
  name: primary-realm
  namespace: rook-ceph
apiVersion: ceph.rook.io/v1
kind: CephObjectZoneGroup
metadata:
  name: primary-zonegroup
  namespace: rook-ceph
spec:
  realm: primary-realm
  master: true
apiVersion: ceph.rook.io/v1
kind: CephObjectZone
metadata:
  name: primary-zone
  namespace: rook-ceph
spec:
  zoneGroup: primary-zonegroup
  master: true
apiVersion: ceph.rook.io/v1
kind: CephObjectStore
metadata:
  name: primary-store
  namespace: rook-ceph
spec:
  zone:
    name: primary-zone
  gateway:
    port: 80
    instances: 3

灾备集群配置：

# 灾备集群创建 Realm 和 Zone
# 注意：Rook 多站点配置需要手动导出导入 Realm 密钥
# 同步策略
apiVersion: ceph.rook.io/v1
kind: CephObjectStore
metadata:
  name: secondary-store
  namespace: rook-ceph
spec:
  zone:
    name: secondary-zone
    endpoint: "http://primary-rgw.example.com"
  gateway:
    port: 80
    instances: 2

**同步模式：|

模式	方向	延迟
双向	两个 Zone 互相同步	秒级
单向	主→备	秒级
按 Bucket	只同步指定 Bucket	用户控制

29 Rook/Ceph 在生产环境部署的最佳实践是什么？

答案：

Rook/Ceph 生产部署需要从硬件选择、网络配置、容量规划和运维管理多维度设计。

硬件规划：

节点：最少 3 个存储节点，推荐 5 个
CPU：每 OSD 至少 1 核心（推荐 2 核）
内存：每 OSD 至少 4GB，MON 4GB，MGR 2GB
磁盘：
- 数据盘：HDD（SATA/SAS）或 SSD/NVMe
- WAL+DB 盘：NVMe/SSD（每 1TB HDD 建议 4-64GB DB 空间）
- 系统盘：独立 SSD，不参与 Ceph 存储

网络配置：

管理网络：1Gbps（MON/MGR 管理）
集群网络（推荐）：10Gbps+（OSD 复制）
公共网络：10Gbps+（客户端访问）

Ceph 配置建议：

spec:
  cephConfig:
    global:
      osd_pool_default_size: "3"
      osd_pool_default_min_size: "2"
      osd_pool_default_pg_num: "128"
      osd_pool_default_pgp_num: "128"
      mon_max_pg_per_osd: "300"       # 每 OSD 最大 PG
      mon_pg_warn_max_per_osd: "300"
    osd:
      osd_recovery_max_active: "5"
      osd_max_backfills: "2"
      osd_recovery_op_priority: "3"
      osd_scrub_auto_repair: "false"
      bluestore_cache_size: "1073741824"

运维 Checklist：

配置 Prometheus 告警（OSDDown、PGDegraded、ClusterError）
设置 MON 时间同步（NTP/Chrony），时钟偏移 < 0.05s
内核参数优化（net.core.rmem_max / wmem_max, vm.swappiness=10）
定期执行 Scrubbing（建议业务低峰期）
监控 OSD 磁盘健康（SMART 检测）
配置 RBD Mirroring 或 Backup 用于灾备

容量规划公式：

有效容量 = (总原始容量 × 冗余系数) × 超分比例
  副本模式（3 副本）：有效 = 原始 × 0.33 × 1.5（超分）
  EC 模式（4+2）：有效 = 原始 × 0.67 × 1.2（超分）

30 Rook/Ceph 故障排查的常用方法和工具有哪些？

答案：

Rook/Ceph 的故障排查需要同时掌握 Rook 和 Ceph 两个层面的诊断工具。

Rook 层面排查：

# 查看所有 Rook 资源状态
kubectl -n rook-ceph get pods -o wide
kubectl -n rook-ceph logs deployment/rook-ceph-operator -f

# 检查 CRD 状态
kubectl -n rook-ceph get CephCluster -o yaml
kubectl -n rook-ceph describe CephBlockPool

# Rook 工具 Pod
kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph status

Ceph 层面排查：

# 集群健康
ceph status
ceph health detail  # 详细健康信息

# OSD 状态
ceph osd status
ceph osd tree
ceph osd df

# PG 状态
ceph pg stat
ceph pg dump | grep -E "stale|down|degraded|incomplete"
ceph pg dump_stuck stale
ceph pg dump_stuck inactive
ceph pg dump_stuck unclean

# 监控状态
ceph mon stat
ceph mon map

# 集群日志（最后 100 行）
ceph log last 100

常见问题及解决：

问题	诊断命令	解决方案
HEALTH_ERR	`ceph health detail`	查看具体错误信息
PG 卡住 inactive	`ceph pg dump_stuck inactive`	标记对应 OSD 并恢复
OSD 无法启动	`ceph-osd -i <id> --debug-osd 20`	检查日志 /var/log/ceph
MON 无法仲裁	`ceph mon stat`	检查 MON 可达性和时间同步
磁盘空间满	`ceph df`	删除快照、扩容
客户端连接慢	`ceph osd perf`	检查慢 OSD

# 集群恢复模式（修复 PG 问题）
ceph osd set norebalance  # 停止再平衡
ceph osd set noscrub      # 停止 Scrubbing
# 修复后取消
ceph osd unset noscrub
ceph osd unset norebalance