简体中文版经机器翻译而成,仅供参考。如与英语版出现任何冲突,应以英语版为准。

设计

提供者

FlexPod for Epic 的架构基于 Epic , Cisco 和 NetApp 的指导,以及合作伙伴在与各种规模的 Epic 客户合作方面的经验。该架构具有适应性,可根据客户的数据中心战略应用 Epic 的最佳实践,无论该战略是小型还是大型,还是集中式,分布式还是多租户。

正确的存储架构可通过总 IOPS 大小来确定。性能本身并不是唯一的因素,您可能会根据其他客户需求决定增加节点数量。使用 NetApp 的优势在于,集群可以随着需求的变化轻松无中断地纵向扩展。您也可以从集群中无中断删除节点以重新利用,或者在设备刷新期间删除节点。

以下是 NetApp ONTAP 存储架构的一些优势:

  • * 轻松实现无中断纵向扩展和横向扩展。 * 可以使用 ONTAP 无中断操作升级,添加或删除磁盘和节点。客户可以从四个节点入手,然后无中断地迁移到六个节点或升级到更大的控制器。

  • * 存储效率。 * 利用重复数据删除, FlexClone ,实时压缩,实时数据缩减,精简复制, 精简配置和聚合重复数据删除。通过 FlexClone 功能,您几乎可以即时创建克隆,以支持备份和测试环境更新。只有在进行更改后,这些克隆才会占用额外的存储空间。

  • * OnCommand WFA 工作流备份和刷新 Epic 完整副本测试环境的能力。 * 此解决方案可简化架构并通过集成效率节省存储容量。这些架构在 Epic 备份解决方案中发挥了重要作用,并利用存储集成与任何备份解决方案集成。

  • * 灾难恢复卷影数据库服务器。 * 灾难恢复卷影数据库服务器是客户业务连续性策略的一部分(用于支持存储只读 [SRO] 功能,并可能配置为存储读写 [SRW] 实例)。因此,第三个存储系统的放置和规模调整在大多数情况下与生产数据库存储系统中相同。

  • * 数据库一致性(需要注意)。 * 如果在业务连续性方面使用 SnapMirror 备份副本,请参见文档《 Epic 业务连续性技术解决方案指南》。有关使用 SnapMirror 技术的信息,请参见 "TR-3446 :《 SnapMirror 异步概述和最佳实践指南》"

  • * 将生产与潜在的抢占资源的工作负载隔离是 Epic 的一个关键设计目标。 * 存储池是一个故障域,必须隔离和保护工作负载性能。ONTAP 集群中的每个节点都是一个故障域,可视为一个存储池。

ONTAP 系列中的所有平台均可运行适用于 Epic 工作负载的全部功能集。

存储架构

下图显示了一个 6 节点架构,这是 Epic 环境中常用的一种架构。此外,还可以部署 4 节点或 12 节点,但这些架构只是设计的参考或起点。必须在中验证工作负载 "SPM" 针对磁盘数量和控制器利用率的规模估算工具。所有 Epic 生产都部署在 AFF 阵列上。有关 Epic 存储布局要求,请参见《 Epic 全闪存参考架构战略手册》。

注 与 NetApp Epic 团队合作验证所有设计。Epic 要求使用 NetApp 规模估算方法正确调整 NetApp 存储系统的大小,以便在 Epic 环境中使用。有关详细信息,请参见 "TR-3930i :《 NetApp Epic 规模估算准则》"。要查看本文档,需要访问 NetApp Field Portal 。

六节点架构包含四个生产节点和两个灾难恢复节点。借助这种架构,在生产四节点的环境中,《 Epic 全闪存参考架构战略手册》指出,您可以将 Epic 报告工作负载与澄清问题分开。

使用六个节点具有以下主要优势:

  • 您可以从生产环境中卸载备份归档过程

  • 您可以从生产环境中卸载所有测试环境

生产在节点 prod-01 上运行。报告在节点 prod-02 上运行,该节点是生产环境的最新 Epic 镜像副本。支持,发布和版本验证(高级, REL 和 RELVAL )等测试环境可以从 Epic 生产,报告或灾难恢复即时克隆。下图显示了在生产环境中为完整副本测试环境创建的克隆。

第二个 HA 对用于满足生产服务存储要求。这些工作负载包括用于 clarity 数据库服务器( SQL 或 Oracle ), VMware ,超空间和 CIFS 的存储。客户可能会有非 Epic 工作负载,这些工作负载可以添加到此架构中的节点 3 和节点 4 ,或者最好添加到同一集群中的单独 HA 对。

SnapMirror 技术用于在存储级别将生产数据库复制到第二个 HA 。SnapMirror 备份副本可用于在第二个存储系统上为非生产环境创建 FlexClone 卷,例如支持,发布和版本验证。生产数据库的存储级别副本还可以支持客户实施灾难恢复策略。

或者,为了提高存储效率,可以从报告 Snapshot 副本备份创建完整测试克隆,并直接在节点 2 上运行。在这种设计下,不需要将 SnapMirror 目标副本保存在磁盘上。

错误:缺少图形映像

存储设计和布局

要满足 Epic 的 HA 和冗余要求,第一步是专门为 Epic 软件环境设计存储布局,包括将磁盘池 1 与磁盘池 2 隔离到专用高性能存储上。有关每个磁盘池中有哪些工作负载的信息,请参见 Epic 全闪存参考架构战略手册。

将每个磁盘池放置在一个单独的节点上会创建对生产和非生产工作负载进行 Epic 隔离所需的故障域。每个节点使用一个聚合可最大程度地提高磁盘利用率和聚合关联性,以提高性能。这种设计还可以通过聚合级重复数据删除最大限度地提高存储效率。

由于 Epic 允许为非生产需求共享存储资源,因此存储系统通常可以同时满足 VDI , CIFS 和其他企业功能等 clarity 服务器和生产服务存储需求。

下图显示了 6 节点架构的存储布局。每个存储系统都是一个完全冗余的 HA 对中的一个节点。此布局可确保每个控制器的利用率达到最大,并提高存储效率。

错误:缺少图形映像

存储节点配置

  • 高可用性 *

在 HA 对中配置了节点的存储系统可减轻节点故障的影响,并实现存储系统的无中断升级。连接到具有多个路径的节点的磁盘架可防止单路径故障,同时提高节点故障转移期间的性能一致性,从而提高存储故障恢复能力。

  • 硬件辅助故障转移 *

硬件辅助故障转移可使一个节点的远程 LAN 模块或服务处理器模块能够比检测信号超时触发器更快地通知其配对节点故障,从而最大限度地缩短存储节点故障转移时间,从而缩短故障转移前所用的时间。存储虚拟化后,故障转移时间会缩短,因为在故障转移期间,控制器标识不需要移动。仅软件磁盘所有权更改。

  • NetApp 支持工具和服务 *

NetApp 提供了一整套支持工具和服务。应在 NetApp 存储系统上启用并配置 NetApp AutoSupport 工具,以便在发生硬件故障或系统配置不当时回电。对于任务关键型环境, NetApp 还建议使用 SupportEdge Premium 软件包,该软件包可提供操作专业知识,延长支持时间并缩短部件更换的响应时间。

  • AFF A300 和 AFF A700 控制器上的全闪存优化特性 *

要使 AFF 解决方案正常运行,必须在全闪存优化的 FAS80x0 系统 HA 对中的两个节点上将环境变量 bootarg.init.flash_optimized 设置为 true 。具有纯闪存优化特性的平台仅支持 SSD 。

卷配置

  • Snapshot 副本 *

应为为生产数据库提供存储的卷设置每晚卷级 Snapshot 计划。卷级 Snapshot 副本也可用作克隆生产数据库的源,以便用于开发,测试和暂存等非生产环境。NetApp 为 Epic 开发了 OnCommand WFA 工作流,用于自动备份生产数据库和更新测试环境。这些工作流会冻结和解冻数据库以创建应用程序一致的 Snapshot 副本。生产备份副本会自动提供给测试服务器,以供支持,发布和发布验证使用。这些工作流还可用于备份流和完整性检查。

Snapshot 副本可用于支持 Epic 生产数据库的还原操作。

您可以使用 SnapMirror 在独立于生产环境的存储系统上维护 Snapshot 副本。

对于 SAN 卷,在每个卷上禁用默认 Snapshot 策略。这些 Snapshot 副本通常由备份应用程序或 OnCommand WFA 工作流管理。NetApp 建议启用所有效率设置,以最大程度地提高磁盘利用率。

  • 卷关联性 *

为了支持并发处理, ONTAP 会在启动时评估其可用硬件,并将其聚合和卷划分为不同的类,称为相关性。一般来说,属于一个关联性的卷可以与处于其他关联性的卷并行提供服务。相反,处于同一相关性的两个卷通常需要轮流等待节点 CPU 的计划时间(串行处理)。

AFF A300 和 AFF A700 在每个节点上具有一个聚合关联性和四个卷关联性。为了获得最佳节点利用率并使用卷关联性,存储布局应为每个节点一个聚合,每个节点至少四个卷。通常,一个 Epic 数据库使用八个卷或 LUN 。

LUN 配置

文档《 Epic 数据库存储布局建议》详细介绍了每个数据库的 LUN 大小和数量。客户必须了解,借助 Epic 支持,确定 LUN 数量和 LUN 大小;这些数量可能需要稍作调整。

建议从较大的 LUN 开始,因为 LUN 本身的大小不会对存储产生任何成本。为了便于操作,请确保 LUN 数量和初始大小在三年后能够远远超出预期要求。与扩展时添加 LUN 相比,扩展 LUN 更容易管理。如果对 LUN 和卷进行精简配置,则聚合中仅显示已用存储。

为清晰起见,每个卷使用一个 LUN 进行 Epic 生产。对于大型部署, NetApp 建议为 Epic 数据库配置 24 到 32 个 LUN 。

决定要使用的 LUN 数量的因素包括:

  • 三年后 Epic 数据库的总大小。对于较大的数据库,请确定该操作系统的 LUN 大小上限,并确保有足够的 LUN 可扩展。例如,如果您需要一个 60 TB 的 Epic 数据库,并且操作系统 LUN 的最大容量为 4 TB ,则需要 24 到 32 个 LUN 才能提供扩展和余量。

注 EPIC 要求通过 FC 将数据库,日志以及应用程序或系统存储作为 LUN 提供给数据库服务器。