为什么几乎没有听说过嵌套RAID级别1 + 5或1 + 6？该嵌套的RAID级别维基百科的文章，目前缺少的部分。我不明白为什么它们不比RAID 1 + 0更常见，特别是与RAID 1 + 0三重镜像相比。

显然，随着驱动器容量的增长快于其性能或可靠性，重建时间变得越来越成问题。有人告诉我RAID 1的重建速度更快，而RAID 1对的RAID 0阵列可以避免此问题，但是RAID 5对或RAID 1对的RAID 5或6阵列肯定可以避免此问题。我至少希望它们是RAID 1 + 0的常见替代方案。

对于16个1TB的驱动器，以下是我求助于备份的天真的概率的计算，即，在简化的假设下，这些驱动器是独立的，并且具有均匀的概率：

RAID | storage | cumulative probabilities of resorting to backup /m
 1+0 |     8TB | 0, 67, 200, 385, 590, 776, 910, 980, 1000, 1000, 1000
 1+5 |     7TB | 0,  0,   0,  15,  77, 217, 441, 702,  910, 1000, 1000
 1+6 |     6TB | 0,  0,   0,   0,   0,   7,  49, 179,  441,  776, 1000
(m = 0.001, i.e. milli.)

如果这是正确的，那么很明显，RAID 1 + 6比RAID 1 + 0更加可靠，而存储容量却减少了25％。通常，理论写吞吐量（不计算寻道时间）是存储容量/阵列大小×驱动器数量×阵列中最慢的驱动器的写吞吐量（具有冗余功能的RAID级别对写操作具有更高的写放大率，即：不要填充条带，但这取决于块的大小），理论上的读取吞吐量是阵列中驱动器的读取吞吐量的总和（除了RAID 0，RAID 5和RAID 6在理论上仍受以下因素限制）分别是最慢，第二慢和第三慢的驱动器读取吞吐量）。也就是说，假设驱动器相同，则分别为8x，7x，

此外，考虑RAID 1三元组的RAID 0 四元组，即12个驱动器的RAID 1 + 0三元组镜像，以及RAID 1对的RAID 6四元组，即12个驱动器的RAID 1 + 6。同样，这些是相同的1TB驱动器。两种布局具有相同数量的驱动器（12），相同数量的存储容量（4TB），相同比例的冗余（2/3），相同的最大写入吞吐量（4x）和相同的最大读取吞吐量（ 12倍）。这是我的计算结果（到目前为止）：

RAID      | cumulative probabilities of resorting to backup /m
1+0 (4×3) | 0, 0, 18,  ?,   ?,   ?,   ?,   ?, 1000
1+6 (6×2) | 0, 0,  0,  0,   0,  22, 152, 515, 1000

是的，这看起来有些过分，但是在使用三重镜像拆分一个克隆进行备份的情况下，只需冻结并删除除2个RAID以外的每个驱动器中的1个，就可以使用RAID 1 + 6。 1对，并且这样做时，降级时的可靠性仍要比降级的RAID 1 + 0阵列好得多。这是我对以这种方式降级4的12个驱动器的计算：

RAID      | cumulative probabilities of resorting to backup /m
1+0 (4×3) | (0, 0, 0, 0), 0, 143, 429, 771, 1000
1+6 (6×2) | (0, 0, 0, 0), 0,   0,  71, 414, 1000

但是，在这段时间内，对于RAID 1 + 6，读吞吐量可能会下降到6倍，而RAID 1 + 0只能降低到8倍。但是，如果在阵列处于降级状态时驱动器发生故障，则RAID 1 + 6阵列将有50–50的机会保持在大约6倍或进一步限制为5倍，而RAID 1 + 0阵列会被限制为4倍瓶颈。写入吞吐量应该几乎不受影响（如果用于备份的驱动器是速度最快的极限驱动器，则吞吐量甚至可能会增加）。

实际上，这两者都可以看作是“三重镜像”，因为降级的RAID 1 + 6阵列能够拆分额外的RAID 6组（4个驱动器）。换句话说，这种12驱动器RAID 1 + 6布局可以分为3个降级（但功能正常）的RAID 6阵列！

难道仅仅是大多数人没有详细研究数学吗？将来我们会看到更多的RAID 1 + 6吗？

一般来说，我会说RAID 1 + 0的使用比1 + 5或1 + 6的使用更为广泛，因为RAID 1 + 0 足够可靠，并且可以提供更好的性能和更多可用的存储。

我认为大多数人会认为RAI​​D 1 + 0组中的完整RAID 1对失败是非常罕见的事件，值得为之进行备份-而且可能不太热衷于获得低于其物理磁盘50％的数据磁盘作为可用空间。

如果您需要比RAID 1 + 0更好的可靠性，那就去吧！..但大多数人可能不需要。

实际答案在于硬件RAID控制器规格，平均磁盘大小，驱动器外形尺寸和服务器设计的交集。

大多数硬件RAID控制器受其支持的RAID级别的限制。以下是HP ProLiant Smart Array控制器的RAID选项：

[raid=0|1|1adm|1+0|1+0adm|5|50|6|60]

注意：“ adm”只是三重镜像

LSI RAID控制器支持： 0, 1, 5, 6, 10, 50, and 60

因此，这些控制器只能将RAID 50和60作为嵌套级别。LSI（néeDell PERC）和HP构成了大多数企业服务器存储适配器市场。这是您在现场看不到RAID 1 + 6或RAID 61之类的主要原因。

除此之外，超出RAID 10的嵌套RAID级别需要相对大量的磁盘。鉴于当今可用的驱动器容量不断增加（带有3.5英寸近线SAS和SATA驱动器），以及许多服务器机箱围绕8 x 2.5英寸驱动器仓设计的事实，物理配置RAID 1+的机会不多。 6，或RAID 61。

您可能会看到类似RAID 1 + 6的区域是大型机箱软件RAID解决方案。Linux MD RAID或ZFS绝对有能力。但是到那时，可以通过热备用或冷备用磁盘来减轻驱动器故障。现在，如果您避免使用有害的RAID级别和硬件组合（例如RAID 5和6TB磁盘），RAID可靠性就不再是问题。另外，将通过分层和缓存层来抽象读写性能。平均存储工作负载通常会受益于其中之一。

因此，最后似乎似乎没有需求/需求。

• 您的可靠性回报递减。即使在Uber速率为10 ^ 14的讨厌的SATA驱动器上，RAID 6也不大可能导致故障。在FC / SAS驱动器上，您的UBER为10 ^ 16中的1，而且您可以获得更高的性能。

• RAID组的可靠性不能保护您避免意外删除。（因此您仍然需要备份）

• 除了某些级别的RAID，您在磁盘上发生复合故障的几率比支持基础架构（电源，网络，空调泄漏等）的复合故障的几率低。

• 写罚款。RAID 61上的每个传入写操作都会触发12个IO操作（天真完成）。在“低层”方案中，就每TB随机写入的IOP而言，RAID 6已经很痛苦。（在更高级别中，您的故障率反而会好100倍）

• 不是“减少25％”，而是进一步减少25％。您的16TB已变成6TB。这样您将获得37.5％的可用存储空间。每个容量需要3倍的磁盘，以及3倍的数据中心空间。只需制作更小的RAID6集，您可能会获得更高的可靠性。我还没有进行数字运算，但是请尝试-例如3x 3 + 2集（15个驱动器，比RAID10少的存储开销）中的RAID 6总数。或改为使用三向镜。

话虽如此-对于多站点灾难恢复，它比您想象的要普遍得多。我运行复制的存储阵列，在其中将RAID5 / 6 / DP RAID组异步或同步到DR站点。（如果可以避免，则不要进行同步-看起来不错，实际上太可怕了）。

对于我的NetApps，这是一个带有一些镜像聚合的都市集群。使用我的VMAXes，我们有了Symmetrix远程数据设施（SRDF）。我的3PAR执行远程复制。

它很昂贵，但是提供了“数据中心着火”级别的灾难恢复。

关于三重镜像-我已经使用了它们，但不是将其用作直接RAID弹性措施，而是将其作为完整克隆作为备份策略的一部分。同步第三个镜像，将其拆分，将其安装在单独的服务器上，然后使用完全不同的基础结构备份该镜像。有时旋转第三个镜像作为恢复选项。

我要说明的要点是，以我作为存储管理员的直接经验-在大约40,000个主轴中（是的，我们每天要更换数十个驱动器）-我们不得不为各种存储进行备份原因是最近5年，但没有一个是RAID组故障。我们确实在争论相对优缺点以及可接受的恢复时间，恢复点和中断时间窗口。而所有这些的基础始终是额外弹性的成本。

我们的阵列可以对所有介质进行擦洗和故障预测，并积极地备份和测试驱动器。

即使有合适的RAID实施，成本效益也就不存在了。花在存储空间上的钱最好用于更长的保留期或更频繁的备份周期。或更快速的通讯。或通常只是更快的主轴，因为即使弹性系数相同，更快地重建备件也会提高复合故障的可能性。

因此，我想为您提供以下问题的答案：

您不会经常看到RAID 1 + 6和1 + 5，因为成本优势并没有累积。给定有限的资金，并且首先需要实现备份解决方案，那么您要做的就是花钱减少停机的频率。有更好的方法来花费这笔钱。

现代和先进的系统不能实现那样的形状，因为它们过于复杂，完全不必要，并且与效率的任何表现都背道而驰。

正如其他人指出的那样，原始空间与可用空间之比基本上为3：1。这实际上是三个副本（两个冗余副本）。由于“ raid6”的计算成本（如果镜像，则为两倍），以及由此导致的IOPS损失，这是非常低效的。在经过精心设计和调整的ZFS中，等效的解决方案在容量方面将创建一个三路反射镜条。

例如，您将拥有4个3向镜像（也就是12个），而不是效率非常低的6向raid6 / raidz2形状的镜像（总共12个驱动器）（同样不是ZFS有任何实现的机制）。驱动器）。而不是1个驱动器的IOPS，而是4个驱动器的IOPS。尤其是对于虚拟机，这是巨大的差异。两种形状的总带宽在顺序读取/写入中可能非常相似，但三向反射镜的条带肯定会在随机读取/写入时响应更快。

综上所述：raid1 + 6通常是不切实际，效率低下的，不足为奇的是，任何认真对待存储的人都不会考虑开发。

要阐明IOPS差异：对于raid6 / raidz2形状的镜像，每次写入时，所有12个驱动器必须充当一个。整体形状无法将活动拆分为多个形状可以独立执行的多个动作。使用三路镜像条带，每个写入可能只是四个镜像中的一个必须处理的内容，因此传入的另一个写入不必等待整个杂波形状处理之后再查看其他操作。 。

既然没有人足够直接地说：Raid6的写入性能并不差一点。如果承受重负荷，这将是无法描述的可怕。

顺序写入是可以的，只要可以进行缓存，写入合并等将其掩盖，就可以了。在高负载下，情况看起来很糟，这是几乎从未使用1 + 5/6设置的主要原因。

寻求时间

问题在于，写寻道放大的行为与写吞吐量的放大非常不同。当一次写入整个条带时，发生具有奇偶校验的最小写入吞吐量放大（我们称此形容词为“全条带”），而相反，当虚拟设备中遵循寻道的整个写入都适合时，则发生最小写入寻道放大。一个大块。在详细介绍之前，这些关系以表格形式更容易传达：

RAID | write throughput amplification factor | write seek amplification factor
     | full-stripe (e.g.) | single-chunk     | full-stripe  | single-chunk
   0 | 1           ;  1   | 1           ;  1 | n       ; 12 | 1           ;  1
   1 | n           ; 12   | n           ; 12 | n       ; 12 | n           ; 12
   5 | n/(n - 1)   ; ~1.1 | min [3, n]  ;  3 | n       ; 12 | min [3, n]  ;  3
   6 | n/(n - 2)   ;  1.2 | min [5, n]  ;  5 | n       ; 12 | min [5, n]  ;  5
*1+0 | n₁          ;  3   | n₁          ;  3 | n       ; 12 | n₁          ;  3*
 1+5 | n/(n₅ - 1)  ;  2.4 | expr₁       ;  5 | n       ; 12 | expr₁       ;  5
*1+6 | n/(n₆ - 2)  ;  3   | expr₂       ;  8 | n       ; 12 | expr₂       ;  8*
expr₁ = 2n₁ + min [1, n₅ - 2]
expr₂ = 3n₁ + min [2, n₆ - 3]

其中n是驱动器总数，n₁是RAID 1组中的驱动器数，n₅和n₆分别是RAID 5或RAID 6阵列中的组数。示例与问题中的12驱动器示例相关（相关行为' *bolded*'）；RAID级别1 + 0、1 + 5、1 + 6的示例分别为4×3、6×2、6×2。

注意，只有全条写吞吐量放大系数直接与冗余比例有关。对于具有平价的人，单块情况更为复杂。之所以会出现这种情况，是因为写入单个块需要先读取奇偶校验块或其他数据块中最简单的一个，然后再将奇偶校验块和新数据块一起写入。（它们不是直接相乘的，因为对于RAID 1，必须将诱导的读取乘以各自的读取吞吐量/寻求放大系数，两者均为1；请参见下文。）

不幸的是，选择最小化此额外写吞吐量放大的块大小会产生实际最大化的副作用。写寻道放大。对于写时间与查找时间相比可忽略的微小写操作，具有很小块大小（要全条带化）的条带化写入性能仅为1倍，就像镜像一样，因为它要求所有驱动器都寻求每次写入的数据块与动员所有这些驱动器获得的吞吐量无关紧要。它已将写入时间与寻道时间的比率除以阵列中驱动器的数量，但是对于微小的写入来说，这已经可以忽略不计了。使用如此小的块大小以至于即使是很小的写入也可以完全剥离是没有意义的。对于足以感觉到寻找效果的写入，最好将它们放在单个块中。

RAID | large contiguous write throughput    | concurrent tiny writes throughput
     | full-stripe    | single-chunk        | full-stripe | single-chunk
   0 | n×       ; 12× | n×          ; 12×   | 1×     ; 1× | n×          ; 12×
   1 | 1×       ;  1× | 1×          ;  1×   | 1×     ; 1× | 1×          ;  1×
   5 | (n - 1)× ; 11× | max[n/3, 1]×;  4×   | 1×     ; 1× | max[n/3, 1]×;  4×
   6 | (n - 2)× ; 10× | max[n/5, 1]×;  2.4× | 1×     ; 1× | max[n/5, 1]×;  2.4×
*1+0 | n₀×      ;  4× | n₀×         ;  4×   | 1×     ; 1× | n₀×         ;  4×  *
 1+5 | (n₅ - 1)×;  5× | expr₃×      ;  2.4× | 1×     ; 1× | expr₃×      ;  2.4×
*1+6 | (n₆ - 2)×;  4× | expr₄×      ;  1.5× | 1×     ; 1× | expr₄×      ;  1.5×*
expr₃ = n/(2n₁ + min [1, n₅ - 2]) = max [n/(2n₁ + 1), n/(2n₁ + n₅ - 2)]
expr₄ = n/(3n₁ + min [2, n₆ - 3]) = max [n/(3n₁ + 2), n/(3n₁ + n₆ - 3)]

注意：如果给定的明智的块大小大于查找时间很长的写入，但是足够小以至于大写入是全条带的，则可以忽略中间2个吞吐量列。第二个吞吐量列的较大块大小更类似于跨接驱动器。“微小的”写入是吞吐量影响可忽略不计的地方。

具有不合适的小块大小还会增加读取的寻道放大效果，尽管不会那么大，并且仅在全条带情况下有效。

RAID | read throughput amplification factor | read seek amplification factor
     | full-stripe      | single-chunk      | full-stripe (e.g.) | single-chunk
   0 | 1                | 1                 | n      to n;    12 | 1
   1 | 1                | 1                 | 1      to n;  1–12 | 1
   5 | 1                | 1                 | n - 1  to n; 11–12 | 1
   6 | 1                | 1                 | n - 2  to n; 10–12 | 1
*1+0 | 1                | 1                 | n₀     to n;  4–12 | 1           *
 1+5 | 1                | 1                 | n₅ - 1 to n;  5–12 | 1
*1+6 | 1                | 1                 | n₆ - 2 to n;  4–12 | 1           *

注意：“ to n”是因为当仅同时发生一次读取时，理论上可以调动所有驱动器以寻找合适的位置并集中读取数据以实现最大的连续读取吞吐量。

RAID | large contiguous read throughput | concurrent tiny reads throughput
     | full-stripe (e.g.)| single-chunk | full-stripe         | single-chunk
   0 | n×          ; 12× | n×     ; 12× | 1×          ;  1×   | n×     ; 12×
   1 | n×          ; 12× | n×     ; 12× | n×          ; 12×   | n×     ; 12×
   5 | n×          ; 12× | n×     ; 12× | n/(n - 1)×  ; ~1.1× | n×     ; 12×
   6 | n×          ; 12× | n×     ; 12× | n/(n - 2)×  ;  1.2× | n×     ; 12×
*1+0 | n×          ; 12× | n×     ; 12× | n₁×         ;  3×   | n×     ; 12×*
 1+5 | n×          ; 12× | n×     ; 12× | n/(n₅ - 1)× ;  2.4× | n×     ; 12×
*1+6 | n×          ; 12× | n×     ; 12× | n/(n₆ - 2)× ;  3×   | n×     ; 12×*

注意：同样，给定合理的块大小，可以忽略中间2个吞吐量列。第三吞吐量列再次与冗余比例紧密相连。

但是，足够大的块大小意味着微小的读取永远不会完整。因此，鉴于有效的实现方式和适当的块大小，读取性能应与不降级的相同驱动器数量成比例。

因此，实际上，“放大因子”比问题中的公式要复杂得多，在该公式中，只考虑了全带宽吞吐量的放大。特别是，对于并发写的6×2 RAID 1 + 6的写性能要小到足以被查找绑定，将比4×3 RAID 1 + 0的写性能差。而且对于全部都是寻觅的微小写入，性能绝对只能达到4×3 RAID 1 + 0的三分之二（即完美的实现）。

解决了这个问题后，12驱动器的比较没有直接的胜利者：

                                  | 4×3 RAID 1+0 | 6×2 RAID 1+6
   number of identical 1TB drives | 12           | 12
                 storage capacity | 4TB          | 4TB
            redundancy proportion | 2/3          | 2/3
large contiguous write throughput | 4×           | 4×
 large contiguous read throughput | 12×          | 12×
concurrent tiny writes throughput |*4×           | 1.5×
 concurrent tiny reads throughput | 12×          | 12×
safe number of random drive loses | 2            |*5
    12 - 1 large write throughput | 4×           | 4×
     12 - 1 large read throughput | 8×           |*11×
    12 - 1 tiny writes throughput |*4×           | ~1.42×
     12 - 1 tiny reads throughput | 8×           |*~9.33×
  can split-off a copy for backup | yes[1]       | yes[1]
                  2-site failover | yes          | yes
    2-copy large write throughput | 4×           | 4×
     2-copy large read throughput |*8×           | 6×
    2-copy tiny writes throughput |*4×           | ~1.28×
     2-copy tiny reads throughput |*8×           | 6×
   2-copy safe random drive loses | 1            |*2
2-copy - 1 large write throughput | 4×           | 4×
 2-copy - 1 large read throughput | 4×           |*5× or 6×[2]
2-copy - 1 tiny writes throughput |*4×           | ~1.46× or 1.2×[2]
 2-copy - 1 tiny reads throughput | 4×           |*3.6x or 6×[2]
can be divided into 3 full copies | yes          | yes
                  3-site failover | yes          | yes
    1-copy large write throughput | 4×           | 4×
     1-copy large read throughput | 4×           | 4×
    1-copy tiny writes throughput |*4×           | ~0.85×
     1-copy tiny reads throughput |*4×           | 2×
   1-copy safe random drive loses | 0            | 0
                       complexity |*simple       | more complex

注1：存储数据的完整副本分别是RAID 0四倍或4/6降级RAID 6阵列。注意2：驱动器故障使4个降级的RAID 1对之一脱机还是使2个正常的RAID对之一脱机，甚至有机会。

但是，它将具有6个驱动器的RAID 6阵列的读取性能提高一倍，并且由于将所需的读取划分为RAID 1对，因此微小的写入吞吐量应提高25％（1.5 / 1.2），而RAID 6显然可以具有合适的应用程序，因此在具有更大写入量或比写入性能更关注读取性能的高可用性应用程序中，毕竟RAID 1 + 6 还是一个利基市场。但这还不是全部...

复杂

到目前为止，这仍然只是理论上的（主要是组合），实际上，复杂性将意味着RAID 1 + 6的实现可能会缺少机会，而无法达到理论结果。RAID 6已经更加复杂，而嵌套又增加了一点复杂性。

例如，立即将6×2 RAID 1 + 6抽象为具有3个独立的虚拟读取头，能够以4x吞吐量同时读取3个连续的大型读取，就像4×3 RAID 1 + 0一样，并不是立即显而易见的。使用软件RAID将6个RAID 1对简单地嵌套在RAID 6阵列中可能并不那么好。实施可能是愚蠢而混乱的（尽管我还没有检验这个假设）。

复杂性还带来了实现和工具开发成本的增加。即使有些应用程序可以从这种嵌套中受益，但这些改进可能不值得开发成本。