NetApp 技术报告存储子系统故障恢复能力指南.docx

1、NetAppGofurther,faster技术报告存储子系统故障恢复能力指南NetApp公司MohammadJawwadMemon2013年7月|TR-3437摘要本文档提供了与NetApp存储子系统中数据可用性和故障恢复能力相关的技术建议和最佳实践。在规划和构建可满足客户需求和期望的NetApp存储环境时，了解本文档中所涉及的主题十分重要。目录1简介41.1 数据可用性41.2 范围42可靠性42.1 衡量可靠性52.2 系统可靠性62.3 可靠性最佳实践63错误和故障63.1 单点故障.732S区苍力W74更正操作和预防性功能74.1 RAID重建84.2 RAID快速恢复84.3 维护

2、中，84.4 失写保护94.5 后台介质扫描94.6 RAID奇偶校验擦除95其他注意事项95.1 磁盘架级别故障恢复能力95.2 RAID组105.3 RAID选项105.4 备件策略115.5 混合配置125.6 MYAUTOSUPPORT系统风险126数据可用性层136.1 笫1层：任务关犍型136.2 笫2层业务关键型146.3 第3层：存储库156.4 第4层归档156.5 第5层多用途16表格目录表1）确定建议的备件数11表2）任务关键型数据可用性的建议和最佳实践。13表3）业务关键型数据可用性的建议和最佳实践。14表4）存储库数据可用性的建议和最佳实践。15表5）归档数据可用性的

3、建议和最佳实践。15表6）多用途数据可用性的建议和最佳实践。16插图目录图1）MTBF公式。5图2）根据MTBF计算驱动器故障率。5图3）根据MTBF和驱动器数量，运行寿命内预期的故障次数。51简介本文档的前身在探讨存储故障恢复能力时，将重点放在主要功能和选项上，借助这些功能和选项，您可以在一组预定义的数据可用性层范围内配置存储系统，以实现最高的存储故障恢复能力。本文档是在此基础上编写的,根据给定存储配置的目的和要求，不一定总是可以甚至需要配置系统以实现最高的故障恢复能力。而且，不一定所有存储配置的最终目标都是确保存储故障恢复能力，也有可能是确保数据可用性C如果系统发生的故障影响到整个系统的性

4、能，以致于即使系统在技术上仍然响应前台I/O,但依赖存储系统的应用程序却停止运行，则该系统故障恢复能力如何？由于诸如上述描述的情形，仅仅强调故障恢复能力是不够的。在探讨故障恢复能力时，必须考虑数据可用性及其对整个系统的影响C1.1 数据可用性NetApp存储系统的一个核心测评指标是数据可用性。在本文档中，将基于以下三个因素评估数据可用性： 性能：从数据可用性的角度，性能可分为两个主要方面。第一个方面是，客户有具体的性能要求，客户需要满足这些性能要求，才能满足需要随时访问存储系统数据的应用程序的需求。从这个角度来看，数据可用性中断意味着，存储系统仍然可以响应前台I/O,但已无法满足依赖该系统的应

5、用程序正常运行必须达到的要求第二个方面是，如果系统性能受到影响，以致于停止响应前台I/O,则表示出现数据可用性中断的情况， 故障恢复能力：从数据可用性角度而言，故障恢复能力是指系统在遇到一个或多个故障时以降级状态继续响应前台I/O的能力。系统承受故障的能力取决于多个选项和功能；本文档将通篇讨论这些选项和功能C 可恢复性：可恢复性用于定义系统从故障中自动恢复以及在存储系统中执行恢复操作期间继续响应前台I/O的能力。数据可用性的三个层面又进一步受到以下三个因素的影响： 存储子系统：存储子系统层提供与存储系统内部相关的所有硬件组件及软件功能。从物理角度而言，这一层主要可视为从HBA向下贯穿到所连接的

6、存储阵列；也可视为与DataONTAP中的存储和RAID软件层相关：简言之.系统支持控制器从内部与所连接的存储阵列进行通信的能力。 系统：系统层可为存储系统提供抵御故障的能力。这一层主要侧重于控制器级别的故障，这一级别的故障会影响系统继续进行外部通信的能力。这一层适用于单控制器和高可用性（HA）对配置以及用于进行外部控制器通信的组件（如网络接口）。 站点：站点层可为处于同一位置的一组存储系统提供抵御故障的能力。这一层主要侧重于与分布式存储系统架构相关的功能，这一架构可以抵御整个存储系统的故障，此类故障可能与站点级别意外事件（如自然灾害或恐怖活动）相关C为了进一步量化最佳实践和建议，必须将此信息

7、应用于一组定义的数据可用性层。该步骤是必需的，因为例如无法在不在某种程度上影响的性能的情况下实现最高的故障恢复能力和可恢复性，根据每个数据可用性层的要求，上述三个因素之间的平衡会发生更改，这会在定义的数据可用性层之间产生不同的最佳实践和建议。本文档第6节“数据可用性层”将介绍数据可用性层及对各层的建议。1.2 范围本文档主要介绍了数据可用性的存储子系统层，同时考虑到第1.1节“数据可用性”中所述的三个因素（性能、故障恢复能力和可恢复性）。2可靠性目前业内公开的最常用的可靠性衡量指标是平均无故障时间（MTBF）。问题在于，MTBF可靠性衡量指标不如平均退货率（ARR）或平均故障率（AFR）准确，

8、这两个指标均由各公司进行跟踪，但在大多数情况下不会公开。NetApp确实跟踪重要存储组件的ARR和AFRo虽然ARR和AFR优于MTBF,但是也不是完美的。如果使用统计学来计算可靠性衡量指标，则只有在应用于大量设备时，计算才有意义。2.1 衡量可靠性目前，通常硬件组件有三个可靠性衡量指标。分别为平均无故障时间、平均退货率和平均故障率。下文详细介绍了这些衡量指标，此处概要说明了本节要点： 企业驱动器的预期运行寿命为五年“NetApp强烈建议替换运行寿命超过五年的驱动器，这也与所提供的驱动器五年保修一致。 配置中的驱动器越多,在驱动器服务寿命内发生驱动器故障的可能性就越大。 MTBF是准确性最低的

9、可靠性衡量指标。 AFR是最佳的可靠性衡量指标，但需要花费时间来建立准确的数据集C本节主要侧重介绍驱动器，但相同的方法和信息同样适用于存储子系统中存在的其他设备等。平均无故障时间MTBF是准确性最低的可靠性衡量指标。人们通常会将MTBF误解为硬件设备的使用寿命。由于硬件厂家无法在发布之前合理地测试设备的整个预期寿命，因此他们会测试许多设备，以尝试得到设备预期寿命内的故障率。最常用的公式如下：测试时长*测试的驱动器效/测试失败的驱动器数=MTBF图1）MTBF公式。存储子系统设备最常引用的MTBF值是针对驱动器而言的。SSD.SATA、SAS和FC驱动器具有不同的MTBF值，如下所示： SSD（

10、SLC）驱动器为200万小时 SAS和FC驱动器为160万小时 SATA驱动器为120万小时驱动器保修五年（43,800小时），远远低于160万甚至120万小时。再次重申,MTBF也不是驱动器使用寿命的衡量指标，而是驱动器使用寿命内的错误率。如果单纯基于MTBF进行数学计算，则对于SATA驱动器（120万小时MTBF）,每年大约应有0.73%的已部署驱动器出现故障，对于FC和SAS驱动器（160万小时MTBF）,每年大约应有0.55%的已部署驱动器出现故障，对于SSD驱动器（200万小时MTBF）,每年大约应有0.44%的已部署驱动器出现故障。SATA1,200,0小时MTBF/每年8,760

11、小时=136.9863年1个故障/136.9863年=0.00730*10O=每年0.73%的故障率FC和SAS1.6,000小时MTBF/每年8.760小时=182.6484年1个故障/182.6484年=0.00547*100=每年0.55%的故障率SSD2,0.0小时MTBF/每年8,760小时=228,3105年1个故障/228.3105年=0.00438*100=每年0.44%的故障率图2）根据MTBF计算驱动器故障率。为了进一步应用此计算方法，让我们考虑以下两个配置示例： 30个预期使用寿命为5年的SAS驱动器 300个预期使用寿命为5年的SAS驱动器 3,000个预期使用寿命为5

12、年的SAS驱动器现在，可以应用数学计算来确定这些配置的运行寿命内预期会发生多少次故障：30个SAS驱动器*0.55%=0.165个故障/年*5年=5年内0.825个故障300个SAS驱动器*0.55%=1.65个故障/年*5年=5年内8.25个故障3000个SAS驱动器*0.55%=16.5个故障/年*5年=5年内82.5个故障图3）根据MTBF和驱动器数JT运牙钿脚脚糊滕就磁.从以上的内容可概括出一点，即，所拥有的驱动器越多，使用期间其中一个驱动器出现故障的可能性就越大，根据目前适用于企业驱动器的五年保修（三年标准保修加两年延保），我们大可以表述为，驱动器的预期可靠寿命为五年，五年之后，驱动

13、器处于使用状态的时间越长，其出现故障的可能性会显著增加。平均退货率设备的ARR是一种优于MTBF的可靠性衡量指标，因为它基于服务中和使用设备的系统中设备的实际退货率：遗憾的是，这仍然不是最佳的可靠性衡量指标，因为该指标不能区分因与故障无关的原因而退货的设备，与故障无关的退货示例包括因误报（作为预防措施）或由于发货错误而退货的驱动器：虽然ARR不是确定可靠性的最佳方法，但是对于要跟踪该指标以了解运营效率、可用性或其他与业务相关的原因是否存在问题的公司，该方法非常有用，平均故障率这是最为准确的设备可靠性衡量指标，因为该衡量指标基于已退货并经过验证确有故障的设备C遗憾的是，由于AFR是基于一段时间的

14、平均值，因此建立AFR需要时间，也正因如此，AFR会随着时间的推移而更加准确。设备出现故障的原因可能有多种，其中一些原因将在本文档后面的部分中进行介绍C本文档的目的不是解决NetApp所售出的各种设备的ARR或AFR问题（因为这不是公开信息），而是说明NetApp客户可公开获得或可能获得的衡量指标并介绍具体示例。2.2 系统可靠性许多人会问，对于控制器或存储架来说，MTBF是什么。没有为大量设备发布MTBF有多种原因： MTBF计算取决于单个设备或集成设备组的使用。控制器和存储架包含多个可选组件（扩展卡、磁盘架模块等等）和本身是更小设备的集合的组件。因此，在整个系统所涉及的组件方面，这些配置非

15、常多变。 MTBF值需要考虑所有使用中的组件，但是对于控制器和存储架，并非所有的组件都十分重要。例如，如果存储架上的LED出现故障，存储架会继续发挥访问驱动器的主要作用。 如第2.1节“衡量可靠性”所述，MTBF是准确度最低的可靠性衡量指标.添加其他设备会进一步降低已提取的计算和结果的准确性。更重要的是，公司会跟踪ARR和AFR,这就不再需要了解MTBFo在存储架、磁盘架模块和驱动器中，一般将驱动器视为存储子系统中可靠性最低的组件。但这并不意味着存储架和磁盘架模块比驱动器更加可靠，这背后的逻辑如下所示： 存储架中存在的驱动器比其他设备多。例如，一个DS4243具有2到4个PSUx2个I0M3磁

16、盘架模块1个架机箱和24个驱动器 驱动器与龚他组件包含相同数量的电子元件，而且其复杂性相同，此外还都包含移动部件（但SSD除外）。出于这一考虑，在介绍存储子系统可靠性时，通常主要围绕驱动器C2.3 可靠性最佳实践在试图最大程度地提高存储子系统组件的可靠性时，需要遵循下面的一些重要最佳实践： 快速移除出现故障的硬件组件，这样故障才不会传播到系统中正常运行的组件。 替换或停用已超过保修期的硬件组件。 处理硬件组件以防止物理损坏和静电放电（ESD）损坏时，采用安全的方式. 了解故障是技术所不可避免的.确保重要组件的备件随时可用。这意味着要遵循热备件和冷备件的最佳实践，并了解所在站点的部件周转情况。

17、使用冷备件时仍需要热备件。硬件组件在磁盘架上的时间越长，其遭受物理损坏或者彻底无法工作的可能性就越大。安装在存储系统（热备件）中并且正在运行的驱动器所处的状态具有高可靠性，因为该驱动器可随时接替其他驱动器的工作。3错误和故障本节详细介绍了有关存储子系统中可能发生的一些主要错误和故障的其他详细信息。其中未涵盖对于可能发生的故障的所有可能的错误信息，而是重点介绍放在影响系统故障恢复能力操作（如RAID重建）的各种情况。还介绍了单点故障（SPOF）,因为这会影响系统故障恢复能力。NetApp强烈建议尽快将发生故障的组件从活动系统中移除，以便降低该故障传播到系统中正常运行的组件的风缸3.1 单点故障一

18、些潜在的SPOF已通过本机系统配置加以消除。例如，每个NetApp存储架使用多个单磁盘架模块、供电设备和驱动器*根据选定的系统配置，可能存在其他SPOF:控制器：NetAPP支持单控制器配置，其中控制器本身就是一个SPOFo如果使用包含两个控制器的HA对存储配置，则不会再将该控制器作为SPOFo1 主机总线适配器（HBA）:这包括板载端口和独立的HBA,也称为端口组。端口组是指任意一组互连端口。例如，板载端口A和B可能与端口C和D使用不同的ASIC,但是它们都依赖于系统主板才能运行。一个四端口HBA通常也具有两个ASIC,但HBA本身是SPOFo因此，NetApp通常建议将您的存储环路（FC-

19、AL）和堆栈（SAS）连接到多个端口组。例如，可以是两个HBA,或者板载端口与一个或多个HBA的组合。NetApp始终建议至少在ASIC之间分担连接.电缆：用于连接存储系统的电缆有多种类型。有些电缆对物理损坏的故障恢复能力比其他电缆强，例如与以太网电缆相比，光缆更容易发生物理损坏。为避免您的存储配置中电缆成为SPOF1NetApp建议（目前许多情况下也要求）采用多路径高可用性（MPHA）布线“MPHA为连接到系统的所有存储架提供了辅助路径连接.架机箱：虽然整个架机箱故障非常少见，但也可能出现。实践中用于防止这种情况的方法是，确保单个磁盘架上任意RAID组中的驱动器不超过两个（具体体现是RAID

20、DPe）o这种方法不是磁盘架故障恢复能力解决方案C丢失磁盘架后（无镜像）导致的系统降级会使系统继续运行的能力下降，为防止出现磁盘架故障.建议使用本地SyncMirror或其横像方法使数据在故障情形下快速可用.镜像解决方案还可解决多种故障情形。请注意，DataONTAP8.1集群模式系统当前不支持SyncMirrortl32驱动器与驱动器相关的错误和故障非常复杂。因此，在所发生故障的类型及其解决方法方面存在许多误解C在某些情况下，人们可能会认为NetApp存储系统使驱动器大量失败的原因不一定是什么严重问题*例如，检测到单个块错误后，NetApp会使驱动器失败，这可能看似极端。术语块错误在这里具

21、有一般含义。实际上，驱动器返回的错误代码与驱动器操作失败相关，该错误可能表明存在严重问题，根据从驱动器返回的错误的重要性，可能表明驱动器上的其他块也可能受到影响。在这种情况下，使驱动器失败并将其从活动文件系统中移除更加安全，这样数据才不会进一步受到影响。以下五种情况通常都会导致系统使驱动器失败并启动更正操作： 驱动器自身返回致命错误。 DataONTAP的存储层报告驱动器无法访问。 驱动器向DataONTAP返回建议，建议应使驱动器失败。 DataONTAP的存储和RAID层建议，基于驱动器超过的各个错误阚值，应使驱动器失败。 失写保护（LWP）o4更正操作和预防性功能遇到问题时，DataON

22、TAP会检查当前RAID状态和错误情况。这样可能会导致执行以下三种操作之一： 启动RAID重建。 启动RAID快速恢复（还可能会使用维护中心）。 忽略错误。下文将详细介绍RAID重建和RAID快速恢复。只有已处于降级状态的RAID组才可能忽略错误。这是因为DataONTAP已了解到目前存在问题，并可能正在解决降级状态“对于通常通过预防性操作（如RAID擦除）检测到的与驱动器故障无关的错误，可能会导致执行以下操作之一： 将可疑数据块重新写入新块（数据块修复）。 为块重新写入奇偶校验数据（奇偶校验修复）。了解DataONTAP执行数据块修复和奇偶校验修复对于本文档来说就已足够，因为这些操作并不特定

23、于驱动器故障，而是文件系统中各个数据库块的问题C重点是DataONTAP会执行多个步骤以确保数据完整性，并且这些步骤不一定会导致驱动器失败。4.1 RAID重建驱动器失败并启动RAID重建后，多种因素确定了重建流程所需的时间，以及因此将如何影响系统的性能。在降级模式下运行时影响系统性能的一些因素包括： 系统工作负载性能特征（随机/顺序和读/写混合） 当前CPU和I/O带宽利用率 RAID组大小 使用中的存储架和磁盘架模块技术 驱动器类型（SSD、SATA、FC或SAS） RAID选项设置 驱动器路径分配 驱动器在各个堆栈/环路上的分布 单驱动器和双驱动器故障和重建由于这些因素，很难准确地预测对

24、存储系统的影响，驱动器发生故障后，通常定向到驱动器的所有I/O都会重定向到备用驱动器C重建流量会影响已降级RAID组中的所有驱动器，因为会在RAID组中的所有数据驱动器上发生读取。包含已降级RAID组和备用驱动器的堆栈/环路上需要额外带宽。前台I/O在当前系统利用率和RAID选项设置的范围内时，RAID重建I/O将完成。这将在本文档第5.2节“RAID选项”中进行深入介绍。单驱动器重建在RAID-DPRAID组中进行单驱动器重建，会导致数据与所有单奇偶校验驱动器RAID组的重建方式相似（不需要双奇偶校验信息）。重建涉及从RAID组中所有剩余驱动器和奇偶校给驱动器中进行读取（除非要重建的是奇偶校

25、验驱动器）。单个重建可以有效地将堆栈/环路上的I/O增加一倍，因为对于定向到RAID组的每个前台I/O,需要为故障驱动器按需进行重建，该流量是对与奇偶校验计算相关的重建流量的补充，并写入备用驱动器，双驱动器重建在RAID-DP组中进行双驱动器重建，会导致数据同时通过单奇偶校验数据和双奇偶校验数据进行重建。这种类型的重建涉及从RAID组中所有剩余数据驱动器（除单奇偶校验和双奇偶校验驱动器之外）中进行读取，在这种情况下，前台I/O的堆栈带宽要求将是原来的三倍CDataONTAP具有足够的智能水平，无需要求多次读取即可同时执行奇偶校验和双奇偶校验数据重建计算；一次读取操作足以进行两种计算。双重建可以

26、有效地将堆栈/环路上的I/O增加为原来的三倍，因为对于定向到RAID组的每个前台I/O,需要为这两个故障驱动器按需进行重建，该流量是对与奇偶校验计算相关的重建流量的补充，并写入备用驱动器C4.2 RAID快速恢复RAID快速恢复类似于RAID重建，但无需通过奇偶校验重建数据，因为驱动器仍可访问。驱动器上的一些块可能需要通过奇偶校验数据进行重建，但会在块级别将大部分驱动器复制到备用驱动器,由于这是块级复制，因此无论驱动器的使用率如何（或者为空），所有的块都会进行复制，由于故障驱动器和备用驱动器之间会产生读取和写入流量，因此RAID快速恢复确实会增加堆栈/环路上的I/O。但是，对RAID组中剩余驱

27、动器的影响远远小于重建，因为故障驱动器上的所有或大多数数据都不需要进行奇偶校验计算。RAID快速恢复完成的时间也短于完整RAID重建的时间。4.3 维护中心维护中心在系统上启用后，将与RAID快速恢复结合使用，以便在将故障驱动器返回NetApp之前评估其情况。驱动器进入维护中心后，将启动RAID快速恢复，使RAID组中的驱动器失败。然后通过运行驱动器诊断，由DataONTAP对故障驱动器进行评估。如果该驱动器被视为正常，则将其返回系统备用池。如果该驱动器不正常，则其仍处于故障状态并需要将其替换。维护中心要求系统上至少有两个热备件可用，并且必须启用RAID快速恢复侨黑签徵弹濯容盘4瓣觥翳撞吃In

28、ikSParesUnt设置为最小值2.4.4 失写保护失写保护是DataONTAP的一项功能，在每次WAFL读取时可用。根据块校验和信息（WAFL上下文）以及RAID奇偶校验数据来检查数据。如果检测到问题，可能会有两种结果： 使包含相应数据的驱动器失败。 将包含相应数据的聚合标记为不一致。如果将聚合标记为不一致，则需要使用WAFLiron才能将该聚合返回一致状态。如果驱动器故障，将与系统中所有故障驱动器一样采取相同的更正操作。失写保护极少会查找问题。其主要目的是检测通常可能出现哪些极为复杂的问题或边缘问题，并确定为保护数据完整性而应采取的最佳措施。4.5 后台介质扫描后台介质扫描是一种在所有R

29、AID组驱动器上持续运行的驱动器诊断功能。这种类型的擦除（介质擦除）用于检测介质错误。其目的不是为了从文件系统的角度确保数据块的完整性，而是为了确保驱动器上的块可供访问。后台介质扫描对系统性能的影响平均小于4%.这主要是因为实际扫描由驱动器内部执行，而无需系统中的CPU或I/O带宽。4.6 RAID奇偶校验擦除RAID奇偶校验擦除用于检查空闲数据的完整性。对于活动频繁的数据集，由于数据经常被读取，RAID奇偶校验擦除的优势有限，因此DataONTAP会通过其他方式保证数据完整性“最常见的空闲数据是归档数据。在用于这类数据时，RAID奇偶校验擦除的效果最佳。这个过程会遍历空闲数据并触发对该数据的

30、读取操作C触发读取操作的结果是，对数据进行奇偶校验检查，确定其是否正确，如果发现某个块不正确，会将其标记为错误，并通过奇偶校验重新创建数据，然后将这些数据写入新块.RAID擦除对前台I/O的影响最小，并且数据表明，这种影响平均小于10%对于大型归档数据集，NetApp建议增加RAID奇偶校验擦除的频率和/或时长。默认情况下，RAID奇偶校验擦除会启用，并且运行一次擦除的时间为360分钟（6小时）。默认情况下，性能影响设置为“低”会导致该过程中仅使用空闲的系统资源。5其他注意事项除了特定故障恢复功能和更正操作之外，配置存储系统时还需要了解其他重要注意事项，本节重点介绍了特定的配置因素，例如RAI

31、D组大小、RAID选项和混合配置的最佳实践。5.1 磁盘架级别故障恢复能力过去，许多管理员采用的磁盘架级别故障恢复方法是确保任意RAID组中位于单个机架上的驱动器不超过两个，其中的逻辑是，使用RAID-DP时，如果磁盘架发生故障，则系统上的任何一个RAID组都不会超过双重降级。这并不是切实可行的磁盘架级别故障恢复方法。请考虑下列情形： 您正在使用DS14（14个驱动器）查看由于磁盘架故障而导致降级的七个RAID组。如果磁盘架发生故障，则DS4243或DS2246将留下12个降级的RAID组。 默认情况下，DataONTAP一次仅在两个RAID组中执行RAID重建。等待正在重建的RAID组都完成

32、重建时，该操作将留下5个（DS14）或10个（DS4243/DS2246）数据丢失风险较高的RAID降级组。 大量的重建流量，再加上如此多的RAID组处于严重降级状态，这会从实质上导致系统响应前台I/O的能力下降。NetApp的磁盘架级别故障恢复功能称为SyncMirror11SyncMirror可保护NetApp存储配置不受磁盘架级别故障事件的影响，虽然该故障不常见，但还是存在的。SyncMirror不仅能提供磁盘架级别故障恢复能力，还可以将受驱动器制约的配置中的读取性能提高达80%n请注意，DataONTAP8.1集群模式系统当前不支持SyncMirror05.2 RAID组RAID组配置

33、可以显著影响存储系统的故障恢复能力。由于RAID-DP可提供最佳的故障恢复功能，并可为驱动器启用无中断的后台固件更新，NetApp强烈建议将RAID-DP用于所有存储配置“本节讨论的最佳实践和重点均假定使用的是RAID-DPo人们倾向于始终在聚合中创建最大的RAID组，因为这样能够最大限度地减少奇偶校验负担并提高性能，但是会导致以下问题： 故障域范围更广：RAID组中的驱动器越多，在存储系统的运行生命周期内就越可能会有一个或多个驱动器发生故障。在尝试了解单个RAID组内遇到多个驱动器故障（MDF）的风险时，驱动器可靠性是其中的一个主要因素。从根本上来说，任何计算都是一种猜想，因为无法保证驱动器

34、会在相同的时间、相同的RAID组内发生故障，或完全发生故障（在五年的保修期内）。 驱动器重建时间更长：RAID组中的数据驱动器越多，在奇偶校验中用于重建数据的计算开销就越大。每个数据驱动器都是一个需要在奇偶校验计算中考虑的数据点：数据点越多，奇偶校验计算就越庞大，从而导致重建时间增加。在大小为12到20的RAID组中，数据表明重建时间只会增加6%oSATA与FC/SAS许多人认为SATA驱动器（MTBF120万小时）的可靠性不及FC和SAS驱动器（MTBF160万小时）。NetApp的AFR和ARR数据表明，企业SATA驱动器在实际部署方面的可靠性与FC和SAS驱动器不相上下，这引出了一个问题

35、哪为什么SATARAID组的大小上限会小于SSD.FC或SAS?”尽管可靠性可能类似，但是容量和速度的差异不容忽视。较之于FC/SAS驱动器，SATA驱动器容量大、速度慢，这意味着其重建时间会明显长于FC/SAS驱动器。在DataONTAP8.0.1中，SATARAID组大小上限已从16增加到20。此更改是在分析现场数据后根据NetApp跟踪的SATA可靠性数据（以及其他因素）决定的C但RAID组大于20（21到28）时会出现转折点，可能会有多个驱动器同时发生故障的风险，这将可能造成永久重建驱动器的情况,驱动器的重建时间一旦过长，就会在完成当前重建活动之前显著增加遇到其他驱动器故障的几率，继

36、而出现永久重建驱动器的情况。这种风险通常只存在于大型（大于1TB）的SATA驱动器中。由于投放市场的SATA驱动器越来越大（3TB.4TB及更大），因此目前这种风险的几率也就更大。固态驱动器鉴于SSD容量小的特点和显著优越的驱动器级别性能.基于SSD的大型RAID组的使用风险也会降低。数据显示，系统在负载的情况下，100GBSSD的RAID重建时间不会超过20分钟。鉴于如此快速的重建时间，即使是面对最大上限为28的RAID组（假设为RAID-DP）,我们也有理由相信系统具有足够的故障恢复能力;5.3 RAID选项在数据可用性范围内，了解如何调整存储设备以确保满足数据可用性要求非常重要。例如，在

37、归档存储配置中.最好对系统进行调整，从而使重建I/O能够与前台I/O进行强有力的竞争；而在Exchange配置中，则可能有必要确保前台I/O比重建I/O更有效地争夺系统资源。RAID选项是主要的用户可配置方法，可告知DataONTAP前台I/O和更正I/O（RAID重建I/O和RAID快速恢复I/O）应该如何争夺系统资源。raid.reconstruct.perfimpact选项可以设置为三个值：低、中或高默认情况下设置为中。更改此选项会导致以下行为：一 低：允许更正I/O与前台I/O在控制器高峰性能期间争夺0%的系统资源。这有效保障了前台I/O在完全有能力时使用100%的系统资源。更正I/O

38、将仅使用空闲的系统资源。 低：允许更正I/O与前台I/O在控制器高峰性能期间争夺40%的系统资源。这有效保障了前台I/O可以在不受更正I/O影响的情况下使用60%的系统资源， 低：允许更正I/O与前台I/O在控制器高峰性能期间争夺90%的系统资源。这有效保障了前台I/O可以在不受更正I/O影响的情况下使用10%的系统资源。对于更正I/O,“系统资源”指的是以下几项: CPU I/O带宽 驱动器利用率更正I/O可以使用的空闲CPU和I/O带宽的数量不受限制.因此，0%意味着系统在负载的情况下仅能分配后台进程。这也意味着该选项对空闲系统的影响微乎其微，因为没有与之竞争的前台I/O.所列出的百分比不

39、会保证更正I/O使用这么多资源，更确切地说，也不会保证前台I/O和更正I/O将争夺这些百分比内的系统资源。设置为高并不意味着会对前台I/O产生90%的影响，因为前台I/O和更正I/O仍在该百分比内进行。此外，更正操作与前台I/O可能会竞争高达这些百分比的系统资源，但这不代表更正操作需要该百分比的系统资源C5.4 备件策略备件建议因配置和具体情形不同而异。过去，NetApp的备件建议纯粹是基于连接到系统的驱动器数。这当然是一个重要因素，但并不是唯一的考量因素，NetApp存储系统部署在非常广泛的配置中。这就要求规定多种方法来确定存储配置中备有适当数量的备件。根据存储配置的要求，您可选择将备件策略

40、调整为以下几项： 最少备件：如果配置中的驱动器容量利用率是关心的主要问题，可能希望只使用最少的备件。采用该选项，您将经受得住最基本的故障。如果发生了多个故障，可能有必要进行手动干预，以确保持续的数据完整性。 均衡备件：该配置方法是介于最少备件与最多备件之间的中间地带。这样可确保不会遇到最糟的情况，所提供的备件足以应对大多数故障情形。 最多备件：该选项可确保备有的备件足以应对系统一次需要占用的最多备件的故障情形。使用最多”一词并不表示备件数超过建议的这一数量时系统就有可能无法运行。只要您认为合适，在不超出磁盘轴数限制的情况下，随时都能添加更多热备件。选择其中任何一种方法都是符合系统要求的最佳实践

41、尽管对数据完整性极其敏感的客户可能有理由采用最多备件方法，但绝大多数存储架构师都可能选择均衡备件”方法。鉴于入门级平台使用的驱动器数非常少，“最少备件”方法对这些配置较为合理。对于RAID-DP配置，请参见表1中的建议备件数。表1）确定建议的备件数。建议的备件数最少均衡最大每个控制器两个每个控制器四个每个控制器六个特殊注意事项入门级平台对于仅使用内部驱动器的入门级平台，使用的热备件数可减少到最少一个。RAID组对于仅包含一个RAID组的系统，备有的热备件没有必要超过两个。维护中心维护中心要求系统中至少存在两个备件。48小时以上的提前期位于远程的系统更有可能发生多个故障而且在手动干预之前完成重

42、建。对于这些系统，建议的备件数应该加倍。超过1,200个驱动器对于使用超过1200个驱动器的系统，应在以上三种方法中建议数量的基础上，额外增加两个热备件。不足300个驱动器对于使用不足300个驱动器的系统，可将“均衡备件”和“最多备件”方法中建议的备件数减去二。关于热备件的附加说明： 备件建议针对系统中安装的每个驱动器类型“有关详细信息，请参见第5.4节“混合配置二 容量较大的驱动器可用作容量较小的驱动器的备件（当作小容量驱动器使用）。 速率较慢的驱动器代替速率较快的同类驱动器将影响RAID组和聚合性能。例如,如果使用转速为IOkrPm的SAS驱动器（DS2246）代替转速为15krpm的SA

43、S驱动器（DS4243）,这样得到的配置并非最佳。 尽管FC和SAS驱动器从性能角度来看处于同等水平，但是所在存储架的故障恢复功能却有很大差别。默认情况下，DataONTAP可将FC和SAS驱动器互换使用。要避免这种情况的发生，可将RAID选项raid.disk.type.enable设置为“开”.有关详细信息，请参见第5.4节“混合配置二热备件和冷备件NetApp并不阻止管理员备有冷备件“NetApp建议尽快将故障驱动器从系统中移除，而备有冷备件可加快这些故障驱动器的更换过程。但是，冷备件不能代替系统中安装的热备件,热备件也用于更换故障驱动器，但是方法有所不同，冷备件可更换故障部件(加快退货

44、或更换过程)，但是热备件的用途有所不同：其作用是通过为RAID重建或RAID快速恢复操作提供目标驱动器，对驱动器故障做出实时响应。很难想象驱动器发生故障时管理员冲进实验室插入冷备件的场景会是什么样，冷备件面临更换时不起作用”的风险也较高，因为驱动器未安装在系统中时受到物理损坏的可能性往往较大。例如，由静电放电引起的装运损坏就是一种物理损坏，取回要在系统中安装的驱动器时可能会发生这种情况。鉴于冷备件与热备件用途不同，绝不能考虑使用冷备件来代替在存储配置中备有热备件。强制备有最少备件RAID选项raid.min_spare_count可用于指定系统中应备有的最小备件数C这对维护中心用户很有用，因为

45、如果将其值设置为2.那么当系统不再符合维护中心规定时，就会有效地通知管理员。NetApp建议将该值设置为根据该备件策略得到的系统中应备有的备件数，以便在降至建议数量以下时系统能够通知您*5.5 混合配置能够使用NetApp存储解决方案创建混合配置，对许多客户来说是一项显著优势。本节的目的不是反对使用混合配置，而是要展示随着技术的变革或引进，我们需要评估或重新评估混合配置，以确保其不会意外影响系统的故障恢复能力和/或性能。这并不是说仅仅创建混合配置就会影响故障恢复能力，因为现在支持多种与同等隔离配置相同故障恢复功能级别的混合配置。磁盘架技术由于NetApp实现了从DS14存储磁盘架系列到SAS存

46、储磁盘架系列(DS4243和DS2246)的过渡，因此一个系统上同时出现这两种磁盘架技术的情况很常见，SAS存储磁盘架系列具有新的独特故障恢复功能，这是DS14存储磁盘架系列所不具备的。例如，备用控制路径(ACP)就是SAS存储磁盘架系列所特有的功能。NetApp建议将DS14与SAS存储磁盘架技术的逻辑系统配置隔离开来。FC和SAS的等效性选项raid.disktype.enable在默认情况下设置为关。这意味着在创建聚合和选择备件时，DataONTAP会将FC和SAS驱动器同等对待。例如，SAS驱动器可用来更换FC驱动器，反之亦然。尽管FC和SAS驱动器从性能角度来看是等同的，但是从故障恢复能力角度来看确实不同的，因为这些驱动器所用的存储架差别很大。使用ESH2和ESH4磁盘架模块的DS14mk2和Ds14mk4磁盘架中提供FCo使用I0M3磁盘架模块的DS4243和使用IOM6磁盘架模块的DS2246中提供SAS0相较于DS14系列SAS磁盘架系列具有更强的故障恢复功能。例如，如果支持DS14的驱动器所更换的驱动器是完全包含在SAS磁盘架内的RAID组的一部分，则将其作为整体考虑时会大大降低该RAID组的故障恢复能力。NetApp建议将raid.disktype.enable选项设置为“开