分布式文件系统典型异常场景剖析及模拟（二）

上一条博文中分析了一些分布式文件系统典型的异常场景，之前详细讲述了2种场景，第一个是注入文件错误场景，第二个是磁盘部分块写入失败场景。

强制卸载文件系统之前，可以正常写入成功：

强制卸载PS A上的/mnt/sdc，此时在该磁盘上运行的ps进程也被杀掉，但是由于zone中有其他可用的ps，因此写入发现写入失败会重试其他ps，最终结果还是会写入成功，如下图所示：

 

最终结果：写入失败会自动重试其他ps，最终结果还是会写入成功，不影响上层的业务。同时要注意如果整个zone的ps都坏掉了（不管是下线或者磁盘故障或者是文件系统故障等），那写入操作就无法保证成功了。

场景四：磁盘整块故障。

如果说之前的操作都还比较温柔的话，那么后面这两个场景绝对是所有项目都不愿意遇到的异常场景。但是由于线上某些机器比较陈旧，这种磁盘故障的几率也不是没有。如果一块盘故障了，是否还能正常的提供服务呢，如果部署得当的话，分布式文件系统是可以正常提供服务的。因此就需要验证该场景。

异常测试的重要原则是一个是尽量模拟或构造真实情况可能发生的故障，另一个就是优先测软件可以处理的场景，如果某些场景虽然可能会存在，但是已经超出软件层面的范畴，也建议不需要测试。可以参考下最近比较火的光纤被挖导致某宝停服的事件。

磁盘整块故障原因很多，但结果都类似，即无法提供存储服务，这次测试中就采用一种比较暴力的方式，即拔出整块磁盘来模拟故障。这种方式相对来说模拟成本较小，需要联系机房人员操作一下就可以了。逻辑图跟上面的场景差不多，需要注意的是拔盘以后重新插入，逻辑盘符可能会变掉，并且需要手工挂载到原来的路径才可以使用，因此拔盘之前的disk与挂载点的对应关系需要记录下来。

例如需要记录disk name为/dev/disk/by-id/ata-ST3500630NS_5QG0FEST 对应的挂载点是 /mnt/sdb。

而不是记录disk name 为/dev/sdb 对应的挂载点是/mnt/sdb。因为/dev/sdb拔盘再插入后很可能变成了/dev/sdj或者其他的逻辑盘符。

 

场景五：整机掉电重启。

整机掉电的场景有两种：

如果可用zone里有多个服务器，其中一个服务器掉电或重启了，预期不应该影响这个zone中其他服务器的可用性。

如果可用zone中只有一个服务器，掉电或重启了，当时业务中断，但预期是重启以后可以自动恢复服务。

本次是针对第一个场景的测试。

逻辑示意图如下：

整机掉电重启前：

 

整机掉电重启后：

 

经验证，可以提供服务。

总结：

一、  针对分布式的系统，测试故障的侧重点在于模拟单个故障点后检查分布式文件系统是否还能够正常的运转，或者至少能够正确的应对这些异常。

二、  模拟故障点应该尽量贴近真实场景的故障来模拟。

三、  部署架构以及预期结果一定要想清楚，不同的部署架构，同样的故障点，也许结果就不一样。避免测试后得到的一些结果无法用来评估系统OK。

相关阅读：分布式文件系统典型异常场景剖析及模拟（一）

本文来自网易实践者社区，经作者崔晓晴授权发布。