序幕：

我是一个代码猴子，越来越多地为我的小公司承担系统管理员的职责。我的代码就是我们的产品，而且我们越来越多地提供与 SaaS 相同的应用程序。

大约 18 个月前，我将我们的服务器从一家以优质托管为中心的供应商转移到了 IV 级数据中心的准系统机架推进器。（字面意思是在街对面。）这个人自己做的事情更多——比如网络、存储和监控。

作为重大举措的一部分，为了取代我们从托管公司租用的直连存储，我构建了一个基于 SuperMicro 机箱、3ware RAID 卡、Ubuntu 10.04、两打 SATA 磁盘、DRBD 和 . 三篇博文详细记录了这一切：构建和测试新的 9TB SATA RAID10 NFSv4 NAS：第一部分、第二部分和第三部分。

我们还设置了一个 Cacit 监控系统。最近，我们添加了越来越多的数据点，例如 SMART 值。

我不能这样做这一切，而不真棒 挤入 在 ServerFault。这是一次有趣且有教育意义的经历。我的老板很高兴（我们节省了大量的美元），我们的客户很高兴（存储成本下降），我很高兴（有趣，有趣，有趣）。

直到昨天。

中断和恢复：

午饭后一段时间，我们开始从我们的应用程序（一个按需流媒体 CMS）收到性能缓慢的报告。大约在同一时间，我们的 Cacti 监控系统发送了大量电子邮件。一个更有说服力的警报是 iostat await 的图表。

性能变得如此下降以至于 Pingdom 开始发送“服务器关闭”通知。整体负载适中，没有流量高峰。

在登录应用服务器、NAS 的 NFS 客户端后，我确认几乎所有东西都在经历高度间歇性和超长的 IO 等待时间。一旦我跳到主要 NAS 节点本身，在尝试导航问题阵列的文件系统时，同样的延迟很明显。

是时候进行故障转移了，一切顺利。在 20 分钟内，一切都被确认备份并完美运行。

验尸：

在任何和所有系统故障后，我都会进行事后分析以确定故障原因。我做的第一件事是 ssh 回到盒子里并开始查看日志。它完全离线。是时候去数据中心旅行了。硬件复位，备份并运行。

在/var/syslog我发现这个可怕的条目：

Nov …