精简配置、FlexClone 和存储效率

　　最初，我们的所有存储卷均使用复杂配置，因为我们担心可管理性问题，但就在 18 个月之前，我们转为在整个 NetApp 存储环境中使用 精简配置。 通过精简配置，我们回收了约 1.9 PB 存储。 无论以什么标准而言，这都是巨大的节省，从根本上讲，如果不使用精简配置，过去 18 个月中我们将不得不购买 1.9 PB 存储并为其提供机架、支付电力和冷却费用。

　　通过 NetApp Operations Manager，我们可以在卷级和聚合体级设置警报。 这些警报会向上报告至我们全国运营中心中的企业管理工具。 我们设置的临界级别低于复杂配置环境中的临界级别。 聚合体的容量使用率达到约 70% 时，我们会停止向其添加新卷，保留剩余容量用于现有卷的自然增长。 我们每月进行容量管理，确保预先配置了足够的存储以满足增长需求。

　　我们通过利用 NetApp FlexClone 技术，可以在不占用大量额外存储的情况下快速配置测试环境。 FlexClone 使我们可以在数秒内对现有卷进行虚拟克隆，以便用于测试。 这些克隆仅在发生更改时才占用额外存储容量，测试完成后，我们只需释放克隆并立即回收使用的所有增量存储空间。

　　我们还转为在整个存储环境中实施 NetApp 重复数据删除，目前为止已回收约 120 TB 容量。 我们预计这个数字将进一步增加，尤其是当我们对 VMware 环境进行重复数据删除时。 我们的目的是在默认情况下，对我们目前正在部署的 VDI 环境执行重复数据删除。 我们希望通过重复数据删除将存储成本再降低 20% 至 30%。

　　安全多租户

　　在 Suncorp，我们在平台级别(Oracle、SQL Server、MySQL 等)实施安全多租户，而不是在各个应用程序级别实施。 我们将特定于平台的卷和 LUN 置于不同的逻辑安全区。

　　我们根据需要在特定区域内实施安全多租户，使用 NetApp MultiStore 的功能实现我们的特定目标。 此方法的关键要素如图 1 所示。 未来六个月中，我们将在 VMware 环境中部署 Cisco Nexus 1000V 分布式虚拟交换机，在此期间我们将逐步添加其他 SMT 功能(如最近一篇 Tech OnTap 文章 中所述)。

　　我们根据需要为每个区域中的每个平台使用 MultiStore 虚拟存储系统 (vFiler)。 在我们的灾难恢复站点的相同区域中，有相应的 vFiler 单元。 NetApp SnapMirror 用于在主数据中心和灾难恢复站点之间复制数据 (我们将在下一部分中介绍关于数据保护和灾难恢复的更多信息)。x86 和 AIX 上的主要应用程序均在此环境中运行，其中包括 VMware、SQL Server、Oracle、SAS 以及我们的 Guidewire ClaimCenter 索赔管理系统。

　　对我们而言，通过 SMT，我们可以在同一存储上部署多个应用程序，而无需担心安全性问题。SMT 还显著简化了管理。 如果没有 vFiler 结构，我们将不得不仔细记录每个卷和 LUN 的位置。 vFiler 单元为我们按照逻辑组织这一切，简化了新部署并加快了部署速度，同时允许我们应用特定于平台的策略。 未来几个月中，我们将部署 NetApp Protection Manager 和 NetApp Provisioning Manager，应用策略将变得更加简单。

　　存储服务目录

　　我们始终坚信需要有一个标准化服务目录，这是实施高效共享基础架构、虚拟化和云部署的前提条件。 但是，我们的上一代存储服务目录在实现产品和服务标准化方面未能给予我们足够的帮助。 现在，我们的服务目录只包括四项基本内容：

　　• 存储：基本存储容量

　　• 灾难恢复：在灾难恢复设施上进行灾难恢复

　　• 备份：操作数据备份和恢复

　　• 归档：符合法规遵从性的长期存储

　　每个类别中，我们都提供铜级、银级和黄金级服务。 例如，针对我们的灾难恢复服务，我们提供：

　　• 黄金级：10 分钟 RPO

　　• 银级：6 小时 RPO

　　• 铜级：24 小时 RPO

　　这些级别通过将 NetApp 卷 SnapMirror 设定为相应设置实现。 例如，对于结构化数据，我们通常需要黄金级服务，即我们需要每 5 分钟复制一次日志，以实现 10 分钟 RPO。

　　我们的备份服务提供 NetApp SnapVault 基于磁盘的备份，可以将数据连同指定性能和保留期限的子类别一起备份到单独的数据存储位置，以便用于操作备份和恢复。 目前，我们的所有归档操作均将数据归档到磁带，以满足严格的法规要求。

　　此服务目录很适合我们，但我们可能会继续努力对其进行简化，在不影响操作的情况下尽可能减少服务数量。