2008年（8065）
分类： 服务器与存储
2008-10-31 15:04:01
磁盘容量的快速增长使得配置容量惊人的单一存储系统成为可能。例如，用一个 NetApp FAS6080，添加 1,176 个 1TB SATA 磁盘驱动器，最后得到一个裸存储容量为 1 PB (1,000 TB) 的单一系统。
在许多 IT 工场中，大容量系统的优势越来越具吸引力。大容量驱动器可让每 GB 存储的价格降到最低。磁盘轴数减少，容量增加，这意味着需要管理的磁盘和存储系统数目减少，能耗降低，冷却要求下降，这些都是大多数数据中心的关注重点。
然而，有不好的一面吗？不一定，但是在使用大容量磁盘时，需要考虑几点重要事项。磁盘容量的增长速度明显快过磁盘质量或性能的提升速度。由于新的更大容量磁盘的故障概率与更小容量的磁盘相当，而且性能也没有改进，因此重建出故障的 1TB 磁盘就好象是使用花园的浇水软管给游泳池注水一样。您必须做好准备，耐心等待更长的重建进程完成。
虽然重建大容量 SATA 磁盘的时间延长，但这并不表明您不应该部署大容量系统，而是必须清楚知道大容量系统的独特需求及所受到的限制。本文介绍了在考虑大容量系统时应思考的几个问题，包括：
适合（不适合）大容量系统的应用程序大多数论点适用于所有大容量存储系统，但还有一些特殊说明仅适用于大容量的 NetApp 系统。
目标应用程序
关于大容量存储系统，您首先应当知道的一点是大容量存储系统受基本驱动器的性能特性限制，并不是适合所有应用程序。市场现有的最大容量驱动器都是 SATA 磁盘，而不是高性能的光纤通道磁盘。不管容量多大，现代 SATA 磁盘的转速都相同，提供的吞吐量也相同。此外，为达到给定存储容器（文件系统、LUN 等）的理想大小，您将部署更少的磁盘，而磁盘数目减少通常意味着存储容器的最大性能降低。
存储系统和（或）主机操作系统可能也实施了大小限制，这进而限制了可用于给定存储容器的轴数。例如, 默认 Linux® 文件系统 Ext3 的最大大小为 16TB，如果使用的是 1TB 磁盘，并且考虑到格式化等操作造成一定的容量损失，单一文件系统可能被限定为约 17 个轴。
在考虑大容量系统时，还应考虑二级存储，这些系统并不非常适用于 Exchange、数据库或其它需要低响应时间和高吞吐量的应用程序。理想应用程序包括：
磁盘至磁盘备份二级存储本身也非常适用于那些具有大型顺序数据流的应用程序，其中包括：
图像采集数据可用性
由于可能具有数百个 SATA 盘，因此还有几项关于大容量系统的数据可用性的重要事项需要考虑，其中包括：
RAIDSATA 磁盘的故障率通常比光纤通道磁盘高，因而实施 RAID 保护至关重要。NetApp 通常建议采用 NetApp 高性能的双奇偶 RAID 6 实施（即 RAID-DPTM）来避免可能因 RAID 组中双磁盘故障引起的数据丢失发生。其他供应商可能也提供了双奇偶 RAID 6 解决方案，具体视存储产品而定。不管选择哪位供应商，任何大容量存储系统都将因为 RAID 6 提供的更高数据弹性而受益。
尽管大容量存储系统常用作二级存储，部署了此类系统的 NetApp 客户常常会选择含主动/主动控制器及无单点故障的全面高可用性配置，以确保大型数据仓库始终可访问。对于大容量 HA 解决方案，需要考虑的一个重要事项是，一个控制器需要多长时间从另一个控制器中接管磁盘或将磁盘恢复到另一个控制器。与通常只采用光纤通道磁盘的解决方案相比，使用大量 SATA 磁盘的解决方案在控制器接管和恢复磁盘方面所花费的时间略长。这是因为与光纤通道磁盘相比，SATA 磁盘本身速度更慢，执行运行状况检查进程的时间更长。
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 驱动器的容量与吞吐量性能仔细考虑了可用性及数据保护需求，并且预先计划了配置及物理需求，则可以避免在进一步开发利用任何技术时可能遇到的不愉快问题，并可以享受因管理简化、直接存储成本降低以及电力和冷却要求下降而带来的好处。
