有时，事件和设备会串通起来，给您和您的团队带来问题。然而，有时，缺乏理解或远见可能会适得其反。不幸的是，这是一个关于我们未能发现所有可能出错的事情的故事。

那是 2006 年，我们刚开始试水为公司试点一种新的服务器架构。我们刚刚收到了我们的第一个完全配置的惠普刀片式服务器机箱（对于那些熟悉此类设备的人来说，这是一个 P 类机箱，带有八个双核刀片服务器）、一个新的 EMC 存储区域网络 (SAN) 和三个 VMware ESX 许可证。我们刚刚完成将相当一部分开发网络转换为使用物理到虚拟 (P2V) 迁移的 VMware 环境，并且一切进展顺利。事实上，公司里的很多人不太明白我们对系统所做的改进，但他们确实注意到了从单处理器奔腾 4 级服务器（带有 IDE 磁盘）到双核 Opteron（存储由光纤通道 SAN 的速度支持）的性能提升。总而言之，一切进展顺利，我们迄今收到的反馈推动了从老化的物理架构到速度更快的虚拟机架构的快速转变。

在我们深入了解这个故事之前，一些背景信息稍后会变得非常重要。正如我所说，我们收到了八个双核刀片服务器，但当时只有三个被预留用于 VMware 主机。其余的计划成为强大的物理机器——Oracle 服务器等。所有这些新刀片服务器的配置都相同：它们每个都配备了 16GB 内存、两个双核 Opteron 处理器、两个 300GB 磁盘和连接到闪亮的新 EMC SAN 的光纤通道卡。关于 SAN，由于我们是将这个 SAN 专门用于刀片服务器，因此决定不增加划区 SAN 交换机的复杂性。（划区 SAN 交换机意味着它被设置为仅允许某些主机访问某些磁盘。）最后一个小细节与 kickstart 有关。

Kyle 和我都写过一些关于 kickstart 和自动化安装的文章，所以现在您可能已经意识到我们是这方面的爱好者。然而，那是 2006 年，我们两人都刚开始接触这项技术。我们从之前的 IT 管理部门继承了一个半设置的 kickstart 服务器，并且随着我们对这项技术以及我们希望它做什么越来越了解，我们慢慢地对其进行调整。

[Kyle：是的，kickstart 环境在技术上是可行的，但它要求您物理地走到每台机器前，放入 Red Hat 安装 CD，从 CD 启动，然后手动键入 kickstart 文件的完整 HTTP 路径。我喜欢无需离开办公桌就能启动机器的想法，因此环境很快就改为 PXE 启动以及许多其他改进。这很方便，因为这些刀片服务器没有 CD-ROM 驱动器。]

回到故事...我们已经将相当一部分开发和公司基础设施转移到了 VMware 环境，但我们仍然需要高性能物理机器。我们收到了对一台新的 Oracle 数据库机器的需求，并且由于它们是当时公司中最强大的设备，并且连接到存储区域网络，我们选择将其中一个新刀片服务器作为 Oracle 服务器。

据我不太完美的记忆回忆，当我在做其他事情时——可能是浏览 Slashdot 网站或填写一些愚蠢的管理文书工作——Kyle 启动了将要成为新 Oracle 机器的远程管理，并开始了 kickstart 过程。我不记得了，这对于故事来说并不重要，因为大约在 Kyle 启动新 Oracle 刀片服务器 20 分钟后，我们的黑莓手机都开始不停地发出哔哔声。

[Kyle：那些在那个时期与我们一起工作（或生活）的人可能会说，“你们的黑莓手机难道不是总是不停地发出哔哔声吗？” 是的，这是真的，但这次不同：一是我们醒着，二是我们实际上在办公室。]

当我们开始收到来自开发环境中大多数机器的“主机宕机”警报时，我们都看着我们的黑莓手机。大约在那个时候，也从其他隔间里传来了嘟囔声：“网络坏了吗？嘿，我哪里也去不了。” 当 Kyle 和我开始深入调查这个问题时，我开始感到胃里一阵阵下沉。

果然，当我们开始查看时，我们意识到几乎所有东西都宕机了。Kyle 启动了 VMware 控制台并尝试重启几台虚拟机，但他的努力在重启时遇到了来自控制台的“文件未找到”错误。文件未找到？那种下沉的感觉加速变成了自由落体。我开始和 Kyle 一起查看，并意识到所有 LUN（虚拟机所在的磁盘）都完全停止对任何 VM 主机可用。

[Kyle：那种下沉的感觉很难形容。当时我对 SAN 还比较陌生，并且刚刚意识到它本身就是一个多么广泛的主题。在深入层面进行 SAN 故障排除并不是我觉得很快就能准备好的事情，但看起来除非我们能找出一些东西，否则我们将会有大量服务器永远消失。]

我立即打电话给 VMware，而 Kyle 继续进行故障排除。在电话上几分钟后，问题变得明显了。包含虚拟机的 LUN 的分区表已被擦除。我们很幸运能够重新创建它们，并且在快速重启每台 VM 主机后，我们恢复了正常运行，尽管我们对这个问题非常担心和困惑。

[Kyle：所以这就是为什么那种下沉的感觉如此熟悉。这和我第一次用错误的 dd 命令意外地核弹了我自己电脑上的分区表时的感觉是一样的。]

然而，当这个问题第二次出现时，我们的担忧和焦虑变成了近乎恐慌，情况也类似。物理机器 kickstart 最终核弹了承载虚拟机文件的 SAN LUN 上的分区表。我们再次致电 VMware，经过一些日志挖掘，他们确定这不是他们软件中的错误，而是我们这边的某些东西正在擦除分区表。

Kyle 和我开始拼凑事件链，并意识到每次发生这种情况之前，都会先启动刀片服务器的 kickstart。这促使我们查看我们正在使用的实际 kickstart 控制文件，结果发现其中有一行导致了整个问题。指令 clearpart --all --initlabel 将擦除连接到特定主机的所有磁盘上的分区表，这对于有本地磁盘的服务器来说是有意义的，但这些刀片服务器连接到 SAN，并且 SAN 没有进行任何划区来防止这种情况。事实证明，系统完全按照其设置的方式运行。如果我们已将 LUN 放置在区域中，或者如果我们事先审核了 kickstart 控制文件并考虑过它，那么问题也不会发生。

[Kyle：谁会想到 kickstart 会成为另一个像 dd 这样的 UNIX 类精灵命令，它们完全按照你说的做。我们不仅将 LUN 放置在区域中，而且我们还确保 clearpart 指令非常具体，仅清除我们想要的磁盘——对我们来说幸运的是，这些 HP RAID 控制器显示为 /dev/cciss/ 设备，因此很容易编写限制。]

那天我们学到了几件事。首先是正确划区 SAN 的重要性。我们所依据的假设——这些盒子都希望访问 SAN，因此区域是不必要的——是完全错误的。其次，是审核和理解其他系统管理员之前所做的工作以及理解该工作将如何影响我们正在实施的新事物的重要性。不用说，从那以后，我们的 SAN 始终被正确划区。