关于ceph osd auth keyring

概述

关于osd auth 认证

误删osd auth认证

如果在删除osd时，id指定错误，错误执行了ceph auth del osd.x，此时osd工作目录还在，osd重启会因为认证无法启动。只要重新添加该osd auth认证即可

ceph auth add osd.{osd-num} osd 'allow *' \
	mon 'allow profile osd' \
	mgr 'allow profile osd' \
	-i /var/lib/ceph/osd/ceph-{osd-num}/keyring

上述原理和命令对于各位运维来说应该非常熟悉，不算新鲜命令，不做展开。

关于osd重建的一些构想

上述命令从另一个角度，也可以理解为，为拥有完成结构的osd，添加auth认证，从而可以加入集群。
在ceph运维中最常见的一种场景：换盘重建
假设一个大规模集群，出现硬盘损坏，以往的方案：

• 删除原有osd（down，out，del osd.id,auth 认证，crush结构，lvm，pv，vg等）
• 物理更换硬盘
• 用新硬盘进行prepare和activate等等

此步骤没有任何问题，确实可以完成硬盘重建。但对集群来说，pg状态经历了至少3次变化

• osd out时，由于reweight的变化，osd会进行计算迁移
• osd remove时，由于tree中weight变化，pg会计算迁移
• 新osd进入时，pg会向新osd进行backfill（即使新osd.id与原先osd相同，上面的pg分布也会发生变化）

也就是说完全删除osd，再重新create的方法，会引起额外的pg迁移和恢复时间，且在集群规模很大，pg很多时，很多pg要重新参与计算分布

能否有一种方式优化呢？

显然可以，只要不进行out和删除osd的操作，保持osd tree结构没有发生过变化，就可以优化这个过程。
将旧盘拔下后，直接插上新盘。以一个init.conf（结构和ceph.conf类似，cluster为空或者补齐0）正常zap、prepare

ceph-volume lvm zap ......
ceph-volume lvm prepare --cluster init .......

挂载临时temp，

然后将旧的osd的几个配置文件恢复，分别是：

• whoami（osd编号，手写就行）
• keyring（auth认证，ceph auth get-or-create osd.${ID}获取，将集群中的auth认证写到文件，与上述误删过程恰好相反）
• fsid（实际是osd的uuid，从旧的硬盘中获取，或者ceph osd dump获取）
• ceph_fsid(集群的cluster_id从别的osd或者ceph.conf或者ceph-conf --lookup fsid获取）

恢复完成后，umount掉temp临时目录
进行activate激活即可，新硬盘会直接承担旧硬盘的osdid，并承担原有工作。