为什么嵌套的RAID级别1 + 5或1 + 6几乎闻所未闻？ 嵌套的RAID级别维基百科文章目前正在失踪他们的部分。 我不明白为什么它们不比RAID 1 + 0更常见，特别是与RAID 1 + 0三重镜像相比。
显然，随着驱动能力的增长速度超过其性能或可靠性，重build时间变得越来越成问题。 我被告知，RAID 1的重build速度更快，而RAID 1arrays中的RAID 1对可以避免这个问题，但是RAID 1或RAID 5arrays当然也是如此。 我至less希望他们是RAID 1 + 0的常见替代品。
对于1TB驱动器中的16个，这里是我计算采用备份的天真概率，即简单地假定驱动器是独立的，甚至是可能的：
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, ie milli.) 如果这是正确的，那么很明显，RAID 1 + 6比RAID 1 + 0更可靠，存储容量只有25％的降低。 与一般情况一样，理论上的写入吞吐量（不包括寻道时间）是存储容量/arrays大小×驱动器数量×arrays中最慢驱动器的写入吞吐量（具有冗余的RAID级别具有较高写入写入放大率不要填满条带，但这取决于块的大小），理论读取吞吐量是arrays中驱动器的读取吞吐量的总和（除了RAID 0，RAID 5和RAID 6仍然可以在理论上受限于最慢的，第二最慢的和第三最慢的驱动器读取吞吐量）。 也就是说，假设相同的驱动器，那将分别是8×，7×或6×最大写吞吐量和16×最大读吞吐量。
此外，考虑一个RAID 1三元组的RAID 0 四元组，即12个驱动器的RAID 1 + 0三重镜像，以及一个RAID 1六对的RAID 6六元组，即12个驱动器的RAID 1 + 6。 再次，这些是相同的1TB驱动器。 这两种布局具有相同的驱动器数量（12个），相同的存储容量（4TB），相同的冗余比例（2/3），相同的最大写入吞吐量（4×）以及相同的最大读取吞吐量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
是的，这可能看起来像是矫枉过正，但是在使用三重镜像来分割备份克隆的情况下，也可以使用RAID 1 + 6，只需通过冻结和删除RAID中除2之外的其中一个驱动器1对，在这样做的同时，降级的RAID 1 + 0arrays的可靠性仍然要好得多。 以下是我以这种方式降低了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倍。 尽pipe如此，如果一个驱动器在arrays处于降级状态时发生故障，那么RAID 1 + 6arrays将有50-50的机会停留在6X左右，或者进一步限制为5X，而RAID 1 + 0arrays会被限制为4×瓶颈。 写入吞吐量应该相当不受影响（如果备份的驱动器是最慢的驱动器，则吞吐量可能会增加）。
事实上，两者都可以被看作是“三重镜像”，因为降级的RAID 1 + 6arrays能够拆分额外的RAID 6四个驱动器组。 换句话说，这个12个驱动器的RAID 1 + 6布局可以分为3个降级（但function性）的RAID 6arrays！
那么大多数人是不是深入math呢？ 未来我们会看到更多的RAID 1 + 6吗？
一般来说，我认为RAID 1 + 0会比1 + 5或1 + 6更广泛使用，因为RAID 1 + 0 足够可靠，并且提供稍好的性能和更多的可用存储空间。
我认为大多数人将RAID 1 + 0组中的完全RAID 1对作为一个非常罕见的事件，这是值得打破备份的 – 而且可能不太热衷于获得低于50％的物理磁盘作为可用空间。
如果你需要比RAID 1 + 0更好的可靠性，那就去吧！ 但大多数人可能不需要这样做。
实际的答案在于硬件RAID控制器规格，平均磁盘大小，驱动器forms因素和服务器devise的交叉点。
大多数硬件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 0, 1, 5, 6, 10, 50, and 60
所以这些控制器只能将RAID 50和60作为嵌套级别。 LSI（ 戴尔PERC ）和惠普构成了大部分企业服务器存储适配器市场。 这是你在现场看不到像RAID 1 + 6或RAID 61这样的主要原因。
除此之外，超越RAID 10的嵌套RAID级别需要相对大量的磁盘。 鉴于目前可用的驱动器容量（带有3.5“近线SAS和SATA驱动器），加上许多服务器机箱都是围绕8 x 2.5”驱动器笼devise的，因此物理configurationRAID 1+ 6或RAID 61。
您可能会看到诸如RAID 1 + 6之类的领域将是大型机箱软件RAID解决scheme。 Linux MD RAID或ZFS绝对有能力。 但到那个时候，硬盘故障可以通过热备盘或冷备盘来缓解。 如果您避免使用有毒的RAID级别和硬件组合（例如RAID 5和6TB磁盘），则RAID可靠性目前并不是什么大问题。 另外，读写性能将被分层和caching层抽象出来。 平均存储工作量通常受益于其中一个。
所以最后，似乎没有必要/需求。
你的可靠性收益递减。 RAID 6不太可能在令人讨厌的SATA驱动器上以1：10 ^ 14的UBER速率复合故障。 在FC / SAS驱动器上，你的UBER在10 ^ 16中是1，你也可以获得更多的性能。
RAID组的可靠性不会保护您免受意外删除。 （所以你需要备份）
超过一定的RAID级别，磁盘上复合故障的可能性将低于支持基础设施的复合故障（电源，networking，空调泄漏等）
写处罚。 在RAID 61上的每个传入写入将触发12个IO操作（天真地完成）。 就“每TB”随机写入的IOP而言，RAID 6在“低层”场景中已经非常痛苦。 （在更高层次上，无论如何，你的失败率是100倍）
这不是“减less25％”，而是减less了25％。 你的16TB变成了6TB。 所以你得到37.5％的可用存储空间。 您需要每个容量3倍的磁盘，以及3倍的数据中心空间。 只需制作更小的RAID6套件，您可能会获得更高的可靠性。 我还没有完成数字处理，但是尝试 – 例如3×3 + 2套（15个驱动器，比RAID10更less的存储开销）的RAID6总和。 或者做3路的镜子。
话虽如此 – 比你想象的多站点灾难恢复更常见。 我运行复制存储arrays，将RAID5 / 6 / DP RAID组asynchronous或同步到DR站点。 （如果可以避免的话，不要同步 – 它看起来不错，实际上很糟糕）。
用我的NetApps，这是一个有一些镜像聚合的集群。 使用我的VMAX，我们使用了Symmetrix远程数据工具（SRDF）。 而我的3PARs做远程复制。
价格昂贵，但是提供了DR的“数据中心着火”级别。
关于三重镜像 – 我已经使用了它们，但不是直接的RAID韧性测量，而是作为备份策略的完整克隆。 同步第三个镜像，将其拆分，将其安装在单独的服务器上，然后使用完全不同的基础结构进行备份。 有时旋转第三个镜像作为恢复选项。
我试图做的一点是，作为存储pipe理员的直接经验 – 在一个大约40,000锭的地方（是的，我们每天要更换几十个驱动器） – 我们不得不去备份各种原因在过去的5年，但没有一个是RAID组的失败。 我们确实辩论相对优点和可接受的恢复时间，恢复点和停机窗口。 所有这一切的基础是额外的韧性成本。
我们arrays的所有媒体都会进行清理和故障预测，并积极地备用和testing驱动器。
即使有一个合适的RAID实施，成本效益也不存在。 在存储空间上花费的钱将更好地投入到更长的保留时间或更频繁的备份周期中。 或更快的通讯。 或者一般来说主轴速度更快，因为即使具有相同的弹性数值，更快地重build备件也可以提高复合失效概率。
所以我想我会提供你的问题的答案：
你不会经常看到RAID 1 + 6和1 + 5，因为成本效益根本不会叠加。 鉴于有限的资金，并且首先需要实施备份解决scheme，您所做的只是花钱来减less停机频率。 有更好的方式来花这笔钱。
现代和先进的系统不能实现这样的形状，因为它们过于复杂，完全不必要，并且与任何效率的外表相反。
正如其他人所指出的，原始空间与可用空间的比例基本上是3：1。 这基本上是三份（两份冗余）。 由于“raid6”的计算成本（如果镜像两次以上）以及由此导致的IOPS损失，这是非常低效的。 在devise和调整得非常好的ZFS中，相同的解决scheme（容量方面）将是创build一个3路镜像的条带。
举个例子，如果不是6路raid6 / raidz2形状的镜像（总共12个驱动器），效率会非常低（也不是ZFS有任何机制可以实现的），你可以使用4个3路镜像（也可以是12个驱动器）。 而不是1个驱动器的IOPS值，你将有4个驱动器值得的IOPS。 特别是与虚拟机，这是一个巨大的差异。 两个形状的总带宽在连续读取/写入中可能非常相似，但是三维镜像的条带肯定会随机读取/写入更具响应性。
总结一下：raid1 + 6通常是不切实际的，效率低下的，不出所料，没有任何关于存储的认真考虑会发展。
为了阐明IOPS的不一致性：使用raid6 / raidz2形状的镜像，每写入一次，所有12个驱动器必须作为一个。 整体形状没有能力将活动分成多个形状可独立执行的多个动作。 有了一条三面镜子，每一个写作可能只是四个镜子中的一个必须处理的东西，所以在看到进一步的动作之前，进入的另一个写入不需要等待整个总体形状来处理。
由于没有人直接说过：Raid6的写入性能并没有稍微差一些。 如果放在负载下是无法描述的。
顺序写入是可以的，只要caching，写入合并等都可以覆盖它，看起来没问题。 在高负荷下，事情看起来很糟糕，这是1 + 5/6设置几乎从不使用的主要原因。
问题在于写寻求放大与写吞吐量放大的行为非常不同。 当一次写入整个条带时（我们把这个形容词称为“全条带”），同时发生最小的写入寻道放大，相反，当在虚拟设备中寻道之后的整个写入适合于一个块。 在详细讨论之前，以表格formsexpression的关系要容易得多：
RAID | write throughput amplification factor | write seek amplification factor | full-stripe (eg) | 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 1是RAID 1组中的驱动器数量，n 5和n 6分别是RAID 5或RAID 6arrays中的组数。 例子与问题中的12驱动示例相关（相关的行是' *bolded* '）; RAID级别1 + 0,1 + 5,1 + 6的示例分别是4×3,6×2,6×2。
请注意，只有全带写入吞吐量放大因子与冗余的比例直接相关。 对于有平价的人来说，单块的情况更为复杂。 它们的出现是因为在写入奇偶块和新数据块之前，写单块需要读奇偶校验块或其他数据块中最容易的块。 （它们不是直接乘法的，因为引导读取必须乘以RAID 1的相应读取吞吐量/查找放大因子，两者都是1;见下文）。
不幸的是，select使这种额外写入吞吐量放大最小化的块大小具有实际上使写寻求放大最大化的副作用。 与寻道时间相比，对于写入时间可以忽略不计的微小写入，具有非常小的块大小（全带宽）的条带写入性能仅为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个吞吐量列要大，这个大块的写入时间比较长，但是足够小，这样大的写入就是全带宽的。 第二吞吐量列的大块大小更类似于跨区驱动器。 吞吐量的影响可以忽略不计。
具有不恰当的小块大小也增加了对读取的查找放大的效果，尽pipe不是那么多且仅在全条纹情况下。
RAID | read throughput amplification factor | read seek amplification factor | full-stripe | single-chunk | full-stripe (eg) | 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 (eg)| 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 6arrays。 注2：有一个偶然的机会，是否驱动器故障偏离了4个退化的RAID 1对之一或降低了2个正常对中的一个。
尽pipe如此，由于所需的读取在RAID 1对之间划分，RAID 6arrays的6个驱动器的读取性能会提高一倍，而微小的写入吞吐量应该提高25％（1.5 / 1.2）具有合适的应用程序，因此在高可用性应用程序中写入较大，或者比读写性能更关心读取性能，可能对RAID 1 + 6有利。 但是，这不是全部…
到目前为止，这仍然是理论上的（主要是组合 ），实际上复杂度将意味着RAID 1 + 6的实现可能存在缺失机会并且不能实现理论结果的缺陷。 RAID 6已经变得更加复杂了，嵌套在这上面增加了一点复杂性。
例如，6×2 RAID 1 + 6可以被抽象为具有3个独立的虚拟读取头，能够以4×吞吐量同时读取3个连续的大型读取，就像4×3 RAID 1 + 0一样。 简单地使用软件RAID将6个RAID 1对embeddedRAID 6arrays中可能不那么优雅; 实现可能是愚蠢的和颠簸（虽然我还没有testing过这个假设）。
复杂性也增加了实现和工具的开发成本。 即使可能有这样的嵌套应用程序可以受益，这些改进可能不值得开发成本。