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

适用于 Epic 的 NetApp 存储参考架构

提供者

适当的存储架构可通过数据库的整体大小和总 IOPS 来确定。性能本身并不是唯一的因素,您可能会根据其他客户需求决定使用更大的节点数。

根据 Epic 软件环境的存储要求, NetApp 根据环境大小提供了三种参考架构。Epic 要求使用 NetApp 规模估算方法正确调整 NetApp 存储系统的大小,以便在 Epic 环境中使用。有关定量性能要求和规模估算指导,请参见 NetApp "TR-3930i :《 NetApp Epic 规模估算准则》"。要查看本文档,需要访问 NetApp Field Portal 。

此处列出的架构是设计的起点。必须在 SPM 工具中验证工作负载的磁盘数量和控制器利用率。与 NetApp Epic 团队合作验证所有设计。

所有 Epic 生产都部署在全闪存阵列上。在本报告中,旋转磁盘所需的磁盘池已整合到三个全闪存阵列磁盘池中。在阅读本节之前,您应查看 Epic 全闪存参考架构战略手册,了解 Epic 存储布局要求。

三种存储参考架构如下:

  • * 小型 * 四节点架构,生产环境中有两个节点,灾难恢复环境中有两个节点(全球引用少于 5 M )

  • * 中型 * 六节点架构,在生产环境中有四个节点,在灾难恢复环境中有两个节点(全球参考量超过 5 百万)

  • * 大型。 * 生产中包含 6 到 10 个节点的 12 个或更多节点架构( 5M-10M 全球参考)

注 全局引用 = (读取 IOPS + (每 80 秒写入突发的写入操作数 /45 )) * 225 。这些数字来自客户专用的 Epic 硬件配置指南。

存储布局和 LUN 配置

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

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

由于 Epic 允许为非生产需求共享存储资源,因此存储系统通常可以同时满足 clarity 服务器和生产服务存储需求,例如虚拟桌面基础架构 (VDI) , CIFS 和其他企业功能。

Epic 数据库存储布局建议文档针对每个数据库的 LUN 大小和数量提供了建议。这些建议可能需要根据您的环境进行调整。请务必与 Epic 支持人员一起查看这些建议,并最终确定 LUN 数量和 LUN 大小。

注

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

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

为清晰起见,每个卷使用一个 LUN 进行 Epic 生产。对于大型部署, NetApp 建议为 Epic 数据库配置 24 到 32 个 LUN 。决定要使用的 LUN 数量的因素包括:

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

无论架构是小型,中型还是大型:

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

  • NetApp OnCommand Workflow Automation 工作流可以备份和刷新 Epic 完整副本测试环境。此解决方案可简化架构并通过集成效率节省存储容量。

  • 灾难恢复影子数据库服务器是客户业务连续性策略的一部分(用于支持 SRO 功能,并可能配置为 SRW 实例)。因此,第三个存储系统的放置和规模估算通常与生产数据库存储系统中的放置和规模估算相同。

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

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

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

小型配置:四节点参考架构,全球参考数少于 5 M (总 IOPS 高达 ~22 K )

小型参考架构是一种四节点架构,在生产环境中有两个节点,在灾难恢复环境中有两个节点,全球参考数不到 5 M 。全球引用量少于 5 百万的客户可以使用此架构。在这种规模下,不需要将报告与清晰分开。

借助 NetApp 提供的独特多协议支持, QoS 以及在同一集群中创建故障域的能力,您可以在一个 HA 对上运行磁盘池 1 和磁盘 Pool2 的所有生产工作负载,并满足所有 NetApp 最佳实践和 Epic 的高舒适性评级要求。所有磁盘池 1 都将在 node1 上运行,而所有磁盘池 2 都将在 Pool2 上运行。

借助 ONTAP 在同一集群中隔离工作负载的能力以及 ONTAP 多协议支持,所有生产 Epic 工作负载(生产,报告,澄清, VMware , Citrix , CIFS 以及与 Epic 相关的工作负载)可以在单个集群中的单个 HA 对上运行。通过此功能,您可以满足 Epic 的所有要求(记录在 Epic 全闪存参考架构战略手册中)以及所有 NetApp 最佳实践。基本上, pool1 在节点 prod-01 上运行,而 Pool2 在 prod-02 上运行,如下图所示。NAS 1 工作负载可以放置在具有 NetApp 多协议 NAS 和 SAN 功能的节点 2 上。

对于灾难恢复, Epic DR 池 3 会在 HA 对中的两个节点之间拆分。Epic DR 在节点 dr-01 上运行, DR 服务在 dr-02 上运行。

可以根据工作负载的需要设置 NetApp SnapMirror 或 SnapVault 复制。

错误:缺少图形映像

从存储设计和布局角度来看,下图显示了生产数据库以及构成 Epic 工作负载的其他构造的高级存储布局。

错误:缺少图形映像

中型配置:六节点参考架构,适用于超过 500 万个全局参考(总 IOPS 22K-50000 )

中型参考架构是一种六节点架构,在生产环境中有四个节点,在灾难恢复环境中有两个节点,并具有 5M-10M 全局参考。

对于这种规模,《全闪存参考架构战略手册》指出,您需要将 Epic Report 工作负载与 clarity 分开,并且在生产环境中至少需要四个节点。

六节点架构是 Epic 环境中最常部署的架构。全球参考超过 5 , 000 , 000 次的客户需要将报告和澄清信息放置在单独的故障域中。请参见 Epic 全闪存参考架构战略手册。

全球参考数少于 5 , 000 , 000 的客户可以选择使用六个节点,而不是四个节点,以获得以下主要优势:

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

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

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

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

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

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

错误:缺少图形映像

下图显示了六节点架构的存储布局。

错误:缺少图形映像

大型配置:适用于超过 10M 全局引用(超过 50K IOPS )的参考架构

大型架构通常是一种 12 个或更多节点的架构,在生产环境中有 6 到 10 个节点,全球引用超过 10M 。对于大型 Epic 部署, Epic 生产, Epic 报告和 clarity 可以放置在一个专用 HA 对上,其中存储在节点之间均匀平衡,如下图所示。

大型客户有两种选择:

  • 保留六节点架构并使用 AFF A700 控制器。

  • 在专用的 AFF A300 HA 对上运行 Epic 生产,报告和灾难恢复。

您必须使用 SPM 比较控制器利用率。此外,在选择控制器时,还应考虑机架空间和电源。

错误:缺少图形映像

下图显示了大型参考架构的存储布局。

错误:缺少图形映像