osd 故障测试 1. 创建的 volumes 是否可以导出数据 2. vm 进行数据写入时候, 是否会对 mon 节点保持长连接, 是否会对 ceph osd 节点保持长连接 3. 当 vm 进行数据写入时候, 断开一个 mon 节点, 是否会对数据写入造成影响 4. 当 vm 进行数据写入时候, 断开一个 osd 节点, 是否会对数据写入造成影响 5. 新增 osd 节点进行扩容 6. osd 灾难性破坏与恢复 7. 停电故障模拟

查询当前池

查询 volumes 池中的卷

导出卷

导出的卷只能够用于 ceph 导出, 而不可以令 linux 直接执行读写

<code>经测试, 当 vm 云盘后, 对应物理机即会产生一常连接到  mon 节点,  只有在 vm 产生数据写时候, 才会与 osd 节点产生对应的 tcp 连接</code>

<code>mon 节点的常连接并不会全部都集中到其中的一台 mon 节点中, 常连接会比较平均地分布到各个 mon 节点中</code>

参考生产环境上的 osd 连接

当前测试 compute 192.168.209.106 mon 192.168.48.144,

192.168.48.146, 192.168.48.148

mon 进程不会自动恢复,  需要手动对 mon 进行启动

重启启动了 mon 服务后, 恢复正常

在进行数据复制过程中,

把其中一台的 osd 进程全部 kill 掉

检查

ceph 集群, 发现发生故障

重新启动 osd, 发现有数据恢复现象

恢复后, 发现, 数据正常了

重启一下故障的 mon 服务

第二次测试

数据复制正常

对其中一台电脑中所有的 osd 执行 kill 操作

查询发现, osd 出现了故障, gp 也出现非正常现象

在数据复制完成后, 重启启动所有 osd

再次查询,  数据自动恢复中

再查询

最终, 恢复完成

当前集群磁盘状态 ( tt-ceph-048144 ~ tt-ceph-048149)

新加入节点, 执行下面操作

参考格式化脚本

参考创建 osd 脚本

参考磁盘挂载情况

参考 osd tree

3 初始化 osd

参考 初始化脚本

4 授权 osd

参考授权脚本

5. 修改 crush map

参考修改后的 osd tree

6. 启动 osd

在 osd 启动之后,  ceph 集群会自动执行数据迁移及数据平衡

再参考

再次参考

约莫几分钟后, 数据同步完成

参考之前容量

参考扩容后容量

参考新机器的磁盘容量

参考其他机器磁盘容量

目标, 破坏一个 osd 对应的所有数据, 尝试恢复集群完整性

当前的 osd 环境正常,

破坏 osd 操作

观察当前 osd 环境,  发现已经遭到破坏

恢复 osd 过程

初始化磁盘

初始化 osd

授权会在初始化时候自动完成 检查授权 key 是否正确

检查  osd 初始化后的 keyring

注意:   加入 key 不对, 则需要手动修改, 否则会遇到下面的报错

启动 osd

参考

ceph 集群监控

osd 启动后, 数据自动执行恢复

数据很快就恢复完成

在集群环境正常状态, 为两个节点作停电处理

停电时, 涉及 1 个 mon 节点,  11 个 osd 节点

参见停电后的集群状态

重新启动主机,  并重新启动 mon ,  osd 服务

再次参考 ceph 集群状态

故障自动修复, 数据复制没有被中断

参考停电期间的状态  (关闭 1 mon 节点,  16 osd 节点)

重新启动三个节点,  启动 mon,  osd 服务

参考集群状态

集群会被自动修复成功

在所有 ceph 节点关闭后,  重启启动主机, 分别启动 mon osd 服务后,  集群会自动恢复正常,  客户可继续访问,   读写云盘