ceph 硬件相关问题

选择 ceph 硬件时的常见错误

    1、设备利旧，重新利用功能不足的旧硬件以与 Ceph 一起使用
    2、在同一个池中使用不同的硬件
    3、使用 1Gbps 网络而不是 10Gbps 或更高
    4、未将 cluster_network 与 Public_network 独立出来
    5、使用 RAID 代替 JBOD
    6、根据价格选择驱动器，而不考虑性能或吞吐量
    7、当用例需要 SSD 日志时，在 OSD 数据驱动器上记录日志
    8、磁盘控制器的吞吐量特性不足
    9、若是不打算绑定cpu的情况下，未关闭numa非统一内存架构，bios的电池未更换为全新的

ceph 存储网络设计

# 网络类型
    Public_network： 公共网络处理 clinet 流量以及与 Ceph mon 的通信
    Cluster_network：Ceph OSD 心跳、复制、回填和恢复流量

# 网络带宽（抛弃1G，选择10G 或者更大带宽）
    在 1 GB  以太网网络中复制 1 TB 数据需要 3  小时，3 TB 需要 9 小时
    在 10 GB 以太网网络中复制 1 TB 数据需要 20 分钟，3 TB 需要 1 小时

ceph osd 一致的硬件要求

# 创建 pool 并定义 crush 层次结构，使得池中的 osd 硬件相同
    disk 控制器相同。
    osd  容量相同。
    osd  转速相同。
    osd  读写|IOPS的性能相同。
    osd  的日志配置相同。

ceph 服务相关问题

ceph 开放的服务端口

    mon node：6789，9100
    osd node：6800-7300，9100
    mds node：6800，9100
    rgw node：80，8080，7480，443，9100
    mgr node：6800-7300，8080，2003，9090，9100，9283

配置存储策略的大致步骤

# 1、确定pool的性能场景
    IO密集型，吞吐率优化型，容量型

# 2、定义crush 规则集

# 3、计算pg 数量

# 4、创建pool

ceph osd 主辅辨识

若是一个pg 被包含在 [77,88,99] 这三个osd中，那么第一个osd.77便是主osd，当osd.77故障时，osd.88 便会成为主osd

ceph 原理相关知识

ceph replication 写操作 原理

当clinet 将对象写入主 OSD 时，主 OSD 将对象写入辅助 OSD。当主 OSD 收到来自辅助 OSD 的应答并且主 OSD 本身完成其写操作时，它会确认对 clinet 的成功写操作.

ceph rebalancing 和 recovery

当集群中有osd的加入或退出时，会触发crush的重新计算与再平衡

ceph data integrity 数据完整性（scrub，deep-scrub，repair）

# Scrubbing：（scrub 默认周期是每天，deep-scrub 默认周期是7天，单位都是秒）
    Ceph OSD 守护程序可以擦除放置组中的对象 
    Ceph OSD 守护程序可以将一个放置组中的对象元数据与其在其他 OSD 上存储的放置组中的副本进行比较。 擦除通常执行每天捕获错误或存储错误。
    Ceph OSD Daemons 还通过比较对象位中的数据来执行更深层次的擦除。
    通常每周执行的深度擦除会发现驱动器上的错误扇区在光擦洗中不明显。

# CRC 检查：
    Ceph 可以通过对写操作执行循环冗余校验 (CRC) 来确保数据完整性; 然后将 CRC 值存储在块数据库中。 
    在读操作上， Ceph 可以从块数据库中检索 CRC 值，并将其与所检索数据的生成 CRC 进行比较，以确保即时数据完整性。

ceph client 的强制独占锁

# 介绍：强制独占锁是一项功能，如果存在多个挂载，则将 RBD 锁定到单个客户端
# 默认情况下不启用强制排他锁。您必须--image-feature在创建图像时使用参数显式启用它
# 数字13是1、4和8的总和，其中1启用分层支持，4启用独占锁定支持，8启用对象映射支持。下面创建了一个RBD 映像，启用分层、独占锁和对象映射。
# 强制独占锁也是 的先决条件object map。如果不启用独占锁定支持，则无法启用对象映射支持
[root@mon ~]# rbd create --size 102400 mypool/myimage --image-feature 13

ceph clinet 的对象映射

# 介绍：默认情况下不启用对象映射，需要显示启用，如上面的强制独占锁一样

ceph clinet 的数据条带化

好好研究该文章：https://www.ibm.com/docs/en/storage-ceph/5?topic=components-ceph-client-data-striping

ceph pg 各个状态介绍

（1）creating：    # 创建pool时，自动创建pg，此时会出现该状态；
（2）active：      # pg活跃态，表示pg可以接受读写业务，当pg状态不是active时，集群将业务异常，会导致上层业务大面积瘫痪；
（3）clean：       # pg处于健康态，三个副本的数据是一致的；
（4）recovering：  # pg增量恢复，根据日志条目，复原数据；
（5）backfilling： # pg全量恢复，根据全量扫描对象，比较差异，还原差异数据；
（6）recovery-wait / backfill-wait：   # pg需要增量/全量恢复，当前等待状态，由于每个OSD并发恢复pg个数的限制(默认值为1)；
（7）recovery-toofull / backfill-toofull：# OSD出现容量使用超过门限值95%，无法数据迁移；
（8）scrubbing：   # 扫描pg副本的元数据，副本之间进行比较，保证元数据一致，默认开启，一般一周扫描一次；
（9）deep+scrubbing：  # 扫描pg副本的元数据与数据，副本之间进行对比，保证元数据和数据一致，默认关闭，由于扫描数据相当耗时，影响业务；
（10）inconsistent：   # 扫描数据之后出现数据不一致，默认没有开启自动修复；
（11）repair：     # 数据不一致时，修复数据的状态，默认关闭，需要手动出发修复，修复的原理：将正常的OSD的数据推送给异常的OSD。
（12）peering：    # 协商副本之间数据一致性；
（13）degraded：   # 降级态，peering完成后，检查到PG有对象需要修复；
（14）remapped：   # upset 不等于 actset;
（15）undersized： # actset 小于副本数(size);
（16）activating： # peering完成之后，同步固化peering的结果(info、log)；
（17）peered：     # peering已经完成，当出现actset < min_size；
（18）down：       # peering过程中检查到，当前在线的osd无法完成数据修复；
（19）imcomplete： # peering过程中，无法选取权威日志。 
（20）stale：      # 未刷新态，mon将osd标记为down，可能由于网络原因，osd没有感知mon把自己标记为down，osd主动上报pg的列表还包含自己，被mon发现，将被标记为stale；
（21）snaptrim：   # 删除快照后的快照回收；
（22）snaptrim-wait：# 由于每个osd并发的限制，已经有pg在做删除快照，那么其他的pg必须等待；
（23）snap-error： # 删除快照时，遇到异常情况， 如果出现snap-error，问题很严重，意味着丢失数据了；

参考文章

https://cloud.tencent.com/developer/article/1977487