加固存储阵列原理及参数，基于Bcache的超融合项目之灾难预案及破坏性实验处置方案

加固存储阵列原理及参数，基于Bcache的超融合项目之灾难预案及破坏性实验处置方案图4 机房现场观察到的盘位状态灯到机房观察服务器所有磁盘状态，如图4所示，1-7号盘位状态灯常亮，0盘位状态灯闪烁，图4照片所示为0盘位状态灯熄灭的瞬间。在iDRAC中，查询到相同序列号的磁盘，如图2所示。将其指示灯状态设置为“闪烁”，如图3所示。图2 在iDRAC中找到相同序列号的磁盘图3 将序列号相同的磁盘设置为”闪烁”

硬件损坏不在本方案讨论范围内，毕竟硬件有价。本方案主要考虑硬件损坏时，如何保证数据不丢失且服务不中断，并完成相应的实验记录处理过程。

首先盘位排序确认。盘位顺序决定了物理世界与数字逻辑世界的对应关系，远程监控得到的磁盘故障信息，最终要反应到具体的某块磁盘上，务必先建立好盘位与盘符的对应关系表。

以n1服务器/dev/sda盘为例，先取得该盘序列号（为保护客户隐私，该序列号打码处理）如图1所示：

图1 操作系统中查询/dev/sda序列号

在iDRAC中，查询到相同序列号的磁盘，如图2所示。将其指示灯状态设置为“闪烁”，如图3所示。

图2 在iDRAC中找到相同序列号的磁盘

图3 将序列号相同的磁盘设置为”闪烁”

到机房观察服务器所有磁盘状态，如图4所示，1-7号盘位状态灯常亮，0盘位状态灯闪烁，图4照片所示为0盘位状态灯熄灭的瞬间。

图4 机房现场观察到的盘位状态灯

重复以上操作，将所有逻辑盘符与物理盘位对应，得到表1。该表将作为日后故障处理、灾难响应的第一手资料。

表1 逻辑盘符与物理盘位对应关系表

在前面部署好的三节点集群中，已经运行了一套k8s，甲方需要在这个平台上进行性能验收工作，因此不宜再用来做破坏性实验，于是申请一台同配置的服务器搭建单机pve、单机ceph，副本数设为2，最小服务副本调整为1，8个osd分为2个故障域，以nvme ssd为逻辑分区依据，以host为type改写crush map，在破坏实验时，只对一块nvme ssd下个各osd进行破坏实验，数据无损，并在破坏后可以人工修复，即视为实验成功。

为了模拟真实生产环境，在pve下创建一台win10虚拟机，挂载2块rbd磁盘，在整个实验过程中，通过windows系统下两盘间无间断的文件复制模拟生产环境下的读写操作，此时展开破坏性实验。

图5 调整好故障域的crush map

第一大类：误操作导致的灾难。

一、分区破坏

1、 容量盘分区破坏

a) Osd.0对应的后端盘为/dev/sdg，以此为实验对象，在底层对其数据进行破坏，首先尝试格式化，操作失败，如图6所示。

图6，识别出有bcache文件系统，设备使用中，不允许格式化

b) 尝试对/dev/sdg盘重新分区，分区失败，如图7所示。

图7 识别出有bcache文件系统，设备使用中，不允许格式化

c) 通过dd命令破坏分区表所在扇区，再次分区，重分区成功并通过lsblk验证。如图8所示。

图8 重分区成功，并同步磁盘。

d) 为确保数据完全破坏，再次使用fio命令，加载libaio引擎，对/dev/sdg设备进行连续写操作，写入数据1TB。此时磁盘负荷已经达到100%，延迟已经非常高了，如图9所示。

图9 高负荷的破坏操作导致osd.0高延迟

以上操作过程中，运行在ceph上的windows持续不断地进行磁盘对拷操作，除fio运行时，对拷卡顿外，其余操作对虚拟机中的磁盘操作无任何影响。当所有破坏性操作完成后，ceph集群状态仍是clean active的，osd.0仍有bcache文件系统，设备处于使用中，不允许格式化，且数据在持续增加。直到人为停止osd.0后，问题才暴露出来，再次启动osd.0报错，如图10所示。

图10 osd.0 已无法启动

Osd.0停止后，集群开始数据再平衡，服务未中断，虚拟机中的数据未丢失。下面记录恢复过程。

先依次执行以下一串命令，将osd移出ceph。

ceph osd down 0 ceph osd out 0 systemctl stop ceph-osd@0 ceph osd crush remove osd.0 ceph auth del osd.0 ceph osd rm 0 umount /var/lib/ceph/osd/ceph-0

移除之后的osd tree如图11所示。

图11 移除后的osd tree

然后再执行如下一串命令，将新创建的osd上线，具体命令不再一一解释。

echo 1 > /sys/block/sdg/bcache/stop echo 1 > /sys/block/bcache7/bcache/stop dmsetup remove ceph--c5ca5db0--3225--484a--86b6--3bec1fdef615-osd--block--5965b4d5--491b--4df6--b8d5--745a7e8ef08a wipefs -a /dev/sdg echo 1 > /sys/fs/bcache/3962fef5-cd70-4314-bcdd-8a200e883aa1/unregister wipefs -a /dev/nvme1n1p3 make-bcache -C /dev/nvme1n1p3 -B /dev/sdg ceph-volume lvm prepare --bluestore --data /dev/bcache7 ceph-volume lvm activate 7 1fd0b7a1-7133-408b-9e30-199e4530a3db systemctl start ceph-osd@0

一切顺利的话，新的osd.0就running起来了。如图12所示。

图12 重新上线的osd.0

重新上线的osd.0重新挂载在了主机名下，如图13所示。由于我们要在单机下实现故障域划分，还要调整一下crush map。

图13 分配在主机名下的osd.0

调整好的crush map如图14所示。此时osd.0的使用率很低。

图14 调整好的crush map

重新归档crush map，集群状态恢复正常，如图15所示。

图15 集群状态恢复正常

经过一段时间的数据再平衡，新osd.0上线，osd.0使用率达到平均水平，数据重建完毕。如图16所示。

图16 数据重建完毕

2、 缓存盘分区破坏

本项目中，一个缓存盘为4个后端盘提供缓存，可以预见，缓存盘的破坏最大影响范围是4个osd，这也是搭建破坏实验平台时，逻辑上划分2个故障域的原因，破坏过程与容量盘类似，格式化、重分区都无法人为破坏，还是用dd命令破坏分区表所在扇区，再用fio命令加载libaio驱动，对缓存盘持续写入以达到破坏数据结构的效果。如果只破坏分区表扇区可能影响4个osd；而持续写入的数据量，决定了受影响的osd个数，本次破坏预计写入100G的数据，理论上，受影响的就只有2个osd。本次破坏准备双管齐下，确保缓存盘的故障有效。首先记录一下，本次破坏的缓存盘为 /dev/ nvme1n1，它是4个后端盘的缓存，缓存盘、后端盘、osd对应关系如表2所示。根据表2，可以判断出图16的故障域划分有误，如果在这样的故障域下做缓存破坏实验，将导致所有数据丢失，先要按表2的对应关系，调整osd故障域，调整后如图17所示。

表2 缓存盘、后端盘、osd

图17调整好故障域的osd

图18 破坏后的分区

正常“误”操作分区，无法移除旧的分区信息，分区1也提示设备忙无法更新，旧的分区表将一直工作直到下次重启。重启前，再通过fio写入100G数据，此时集群状态出现警告，如图19所示。

图19 Osd.0报警

这次，我们通过重启服务器看看一缓存盘破坏带来的问题。重启后系统报警，4个osd掉线，如图20所示。此时实验用的windows虚拟机可以正常开机，正常读写，本实验验证了crush map配置是正确的。

图20 缓存盘破坏后系统显示4个osd掉线。

下面记录恢复过程。

ceph osd out osd.0 ceph osd stop osd.0 ceph osd rm osd.0 ceph osd crush rm osd.0 ceph auth del osd.0 echo 1 > /sys/block/sde/bcache/stop wipefs -a /dev/sde

以上命令调整参数后执行4遍，对应4个Osd，最后再：

wipefs -a /dev/nvme1n1

为/dev/nvme1n1分区，后面的命令不再一一解释。

parted -s /dev/nvme1n1 mklabel gpt parted /dev/nvme1n1 mkpart primary 0% 25% parted /dev/nvme1n1 mkpart primary 25% 50% parted /dev/nvme1n1 mkpart primary 50% 75% parted /dev/nvme1n1 mkpart primary 75% 100% make-bcache -C /dev/nvme1n1p1 -B /dev/sde make-bcache -C /dev/nvme1n1p2 -B /dev/sdf make-bcache -C /dev/nvme1n1p3 -B /dev/sdg make-bcache -C /dev/nvme1n1p4 -B /dev/sdh echo /dev/sdb > /sys/fs/bcache/register vgremove ceph-af16c73e-8c3d-4ab4-934d-f91d0ac6dd24 ceph osd crush move osd.0 host=n4-2 ceph osd crush reweight osd.0 1.74660

重新恢复上线的4个osd，使用率均为0，如图21所示。ceph会自动backfill新加入的4个osd，如图22所示。

图21 恢复好的4个osd

大约20分钟后，8个osd已经平衡好，如图22所示。集群状态恢复正常，如图23所示。期间用做实验的windows虚拟机正常开机，正常读写，缓存盘破坏恢复成功。

图22 重填好的osd

图23 重回正常状态的集群

本项实验小结：不论是容量盘还是缓存盘的分区破坏，此类误操作引起的故障比较隐蔽，破坏后的osd仍能正常读写，这可能与ceph直接以数据块的形式操作祼设备的原理有关，但这样的机制有隐患，在osd服务或机器重启时，分区信息的损坏导致osd无法上线，会引发数据再平衡，虽无数据丢失的风险，如果此时数据量比较高，有服务中断风险。

文档太长，坚持到这儿的看官都不容易，给你们点赞！拆分一下哈，下一篇预告：

讲 容量盘与缓存盘的热插拔实验、强行断电实验、误重启实验，以及一些可预期的事件，比如扩容、计划停电、硬件损坏等处置预案。