可怕的阵列错乱

可怕的阵列错乱（Dreaded Array Confusion），即 DAC，是赋予一组 RAID 阵列故障类型的术语。这类故障实际上无法诊断，但它们有一个共同特征：在没有任何驱动器故障的情况下却发生了整个阵列的彻底失效，导致全部数据丢失。据推测，有三个关键原因造成了大多数 DAC：

软件或固件缺陷：虽然如今 RAID 行为中出现严重缺陷的情况很罕见，但它们始终是有可能发生的，尤其是在像奇偶校验 RAID 这样更复杂的阵列类型中，因为阵列上必须执行重建计算。RAID 软件或固件中的缺陷（取决于我们谈论的是软件 RAID 还是硬件 RAID）可能以多种方式表现出来，包括意外地销毁阵列。固件问题也可能出现在驱动器本身。

硬件故障：处理器、内存或控制器等硬件的故障可能对 RAID 阵列产生重大影响。尤其是内存错误，很容易导致整个阵列丢失。这被认为是 DAC 最不常见的原因。

驱动器松动（Drive Shake）：在这种情形下，单个驱动器松脱并与背板断开连接，随后又重新晃回原位，从而触发一次重新同步（resilvering）事件。如果这种情况在一次重新同步周期内发生在多个驱动器上，或者在重新同步期间遇到一次 URE，那么我们就会在奇偶校验阵列上看到整个阵列丢失，甚至有可能在完全没有发生任何硬件故障的情况下也是如此。

由于 DAC 的本质，也由于它并非 RAID 本身的问题，而是其支撑组件的问题，我们在试图识别或量化这种风险时处于非常困难的境地。没有人知道 DAC 发生的可能性有多大，虽然我们知道 DAC 对奇偶校验 RAID 系统构成更显著的威胁，但我们不知道这种威胁究竟大出多少。坊间证据表明，镜像 RAID 上的风险低到无法测量，而奇偶校验 RAID 上的风险在风险分析中可能会高出背景噪声。在这些故障模式中，软件缺陷和驱动器松动都对运行在奇偶校验 RAID 上的系统构成高得多的风险，因为 URE 风险只影响奇偶校验阵列，而且奇偶校验所必需的软件远比镜像所需的软件复杂得多。奇偶校验 RAID 本身就更脆弱，并且承载着更多类型的风险，使其在比镜像 RAID 更多的方面暴露于 DAC 之下。

由于 DAC 是多种可能性的集合，也由于它在发生之后实际上无法识别，因此几乎没有任何可行的手段来收集有关它的数据。自从 DAC 被识别为一种风险以来，许多人纷纷站出来，主要是在 Spiceworks 社区中，提供了关于 DAC 阵列故障的坊间目击描述。最终用户 IT 的特点是：统计数据——尤其是关于像 DAC 这样并不广为人知的模糊概念的统计数据——既没有被收集，也无法被收集。DAC 出现在世界各地的机房里：一位系统管理员回到办公室，发现一台服务器上的所有数据都没了，却没有任何硬件发生故障。数据已经丢失了。诊断很可能不会被运行，日志将不存在，而即便问题能够被识别出来，又该向谁报告呢？即便报告了，我们又如何量化它发生的频率，相对于它不发生的频率，或者它可能发生却没有被报告的频率呢？遗憾的是，我所知道的只是：在识别并在一定程度上公开了这种风险及其症状之后，突然有许多人站出来承认，他们自己也亲眼见过 DAC，却完全不知道发生了什么。

如果我那些坊间的研究能说明任何问题的话，那么看起来 DAC 实际上对奇偶校验阵列构成了相当可观的风险，故障存在于相当比例的阵列之中——但那次数据收集所覆盖的横截面，其准确性和规模都非常之小。然而，最初人们曾认为 DAC 如此罕见，以至于理论上你根本找不到任何曾经观察到它的人，但事实似乎并非如此。我已经知道许多经历过它的人。

由于这个行业的本质，我们被迫接受 DAC 作为一种潜在风险，在风险评估中将其列为一项未知的“次要”风险，并为之做好准备，但却无法据以进行计算。然而，知道它可能成为一种风险，并理解它为何会发生，对于评估风险和缓解风险而言都很重要。

[坊间证据表明，DAC 几乎总是仅出现在 SCSI 控制器上单奇偶校验 RAID 阵列的硬件 RAID 实现中。]