NetApp 专家观点：大容量存储系统的注意事项

Data ONTAP® 7.2.4 引入了一些专门针对 SATA 磁盘接管和恢复的具体优化功能，可提高大容量 SATA 系统在故障转移和恢复方面的性能，使此解决方案与仅使用光纤通道磁盘的解决方案不相上下。为通过优化功能获益，我们建议对任何 NetApp 基于 SATA 的大容量 HA 存储解决方案使用 Data ONTAP 7.2.4 或更高版本。

有一个 NetApp 存储配置选项未得到充分利用，那就是多路径 HA。多路径 HA 确保从每个控制器到每个磁盘有两个单独的 I/O 路径，因而在出现线缆问题或其它硬件问题时，磁盘驱动器的访问不会中断。若采用 HA 配置，此类问题的出现会导致发生故障转移。多路径 HA 提供了从每个控制器到其存储的冗余数据路径，因此减少了故障转移的发生机率。多路径 HA 还可以通过将存储工作负荷分布到两个数据路径中，帮助增强性能的一致性。

数据保护

大容量存储系统的数据备份业已成为所面临的一项重大挑战。首推磁盘到磁盘备份方法，因为这样可能尽量缩短备份时间。然而，如果使用 NetApp SnapVault® 和 SnapMirror 等工具，创建大容量存储系统的基准副本所需的时间可能相当长。

NetApp 提供了两种工具：LREP（逻辑复制）和 SnapMirror to Tape，以帮助创建可植入到远程系统的基准。自此之后，将只复制改动过的数据块，从而降低对来源和目标控制器以及两者之间网络的影响。

RAID 重建

与大多数其它系统维护活动一样，RAID 重建时间会因采用大量 SATA 驱动器而延长。例如，如果有一个 1TB 磁盘发生故障，在没有其它负载的情况下，重建 NetApp 系统上的 RAID 大约需要 10 到 12 小时。此时间会随系统负载增加而延长。

平均故障时间 (MTBF) 数据表明，在一个拥有 1,176 个 1TB 磁盘驱动器的存储系统中，一个系统执行重建的时间可能相当于正常工作时间的 5%。而且，重建所花费时间的百分比值会随存储系统的整体工作负荷增加而增加。

介质扫描和 RAID 清理

NetApp 通过定期介质扫描和 RAID 清理来确保存储数据的完整性，而且我认为其他供应商也是提供类似功能来检测和解决问题。此过程与为一座大桥刷油漆相似，首先从大桥的一端开始刷，天天刷，月月刷，直至刷到大桥的另一端，然后又重新开始。这两个 NetApp 实用程序只是跟踪其进度，并继续处理存储子系统，直至检查了所有存储。后台介质扫描以较低速率连续运行，它使用内置的诊断功能来检测介质错误。默认情况下 RAID 清理每周运行六小时，它使用奇偶检验数据来检查数据完整性。

在大容量存储系统中，NetApp 建议提高介质扫描的数据速率，增加 RAID 清理的执行频率和持续时间，以确保可以及时检查那些不常访问的数据（通常在二级存储上）。

存储系统配置

在配置大容量系统时，您首先需要了解存储系统（以及 SAN 环境的主机操作系统）实施了哪些限制，并相应制定计划。例如，在 NetApp 系统中，您可能规定单个存储控制器上聚合或传统卷的最大值为 100，而且聚合、传统卷和精灵卷（FlexVol® 卷）的总值不能超过 500。看上去这些限制值定义得很高，然而有时仍会超出这些限制。例如，如果主机操作系统限定您使用 2TB 文件系统，或者您将每聚合的 FlexVol 卷数统一规定为一个较高值，则可能在充分配置最大容量系统之前就达到 500 个的数量限制。

其问题在于，您不能在处理大容量系统时一蹴而就。您必须了解各个存储限制，并制定必需的前期规划，以确保既能使用所有容量，又能留出空间应对无法预测的未来需求。

基础设施复杂性

在计划部署大容量系统时不能忽视的一个因素是整个磁盘基础设施的高度复杂性。我最近曾与一位客户合作过，他有 72 个磁盘架，共安装了 1,008 个磁盘。这些磁盘架进一步划分为 12 个存储环路，每个存储环路包含 6 个磁盘架。

在使用多路径 HA 存储连接的主动/主动环境下，每个存储环路需要 4 个连接，因而在这么多个存储机柜中存储与存储控制器之间需要 48 个连接。听上去布线很复杂，事实也如此。您不能首先预测事事顺畅，不做任何规划就开始为最大容量存储系统布线。您有许多前期工作要做，以确保每项工作能够顺利进行。前期规划、布线图绘制以及标记对大容量存储部署至关重要。

总结

在了解潜在限制，做好前期工作并明智选择应用程序之后，您就可以安全地部署存储系统，这些系统的容量非常大，仅仅在几年前还认为不可能达到这么大的容量。如果相对于最新 SATA 驱动器的容量与吞吐量性能仔细考虑了可用性及