架构
建议更改
PDF
SAP HANA 主机使用冗余 FCP 基础架构和多路径软件连接到存储控制器。如果交换机或主机总线适配器（ HBA ）发生故障，则需要一个冗余 FCP 交换机基础架构来提供容错 SAP HANA 主机到存储连接。必须在交换机上配置适当的分区，以使所有 HANA 主机能够访问存储控制器上所需的 LUN 。
AFF 系统产品系列的不同型号可以在存储层混用并匹配，以满足增长以及不同的性能和容量需求。可以连接到存储系统的最大 SAP HANA 主机数由 SAP HANA 性能要求和所用 NetApp 控制器型号定义。所需磁盘架的数量仅取决于 SAP HANA 系统的容量和性能要求。
下图显示了一个配置示例，其中八个 SAP HANA 主机连接到一个存储 HA 对。
此架构可扩展到两个方面：
-
如果存储控制器提供的性能足以满足当前的 SAP HANA KPI 要求，请将更多的 SAP HANA 主机和存储容量附加到现有存储
-
通过为其他 SAP HANA 主机添加更多具有额外存储容量的存储系统
下图显示了一个配置示例，其中，更多 SAP HANA 主机连接到存储控制器。在此示例中，需要更多磁盘架来满足 16 个 SAP HANA 主机的容量和性能要求。根据总吞吐量要求，您必须为存储控制器添加额外的 FC 连接。
与部署的 AFF 系统无关， SAP HANA 环境也可以通过添加任何经过认证的存储控制器来进行扩展，以满足所需的节点密度，如下图所示。
SAP HANA 备份
所有 NetApp 存储控制器上的 ONTAP 软件都提供了一种内置机制，可在运行期间备份 SAP HANA 数据库，而不会影响性能。基于存储的 NetApp Snapshot 备份是一种完全受支持的集成备份解决方案，可用于 SAP HANA 单个容器以及具有单个租户或多个租户的 SAP HANA MDC 系统。
基于存储的 Snapshot 备份可使用适用于 SAP HANA 的 NetApp SnapCenter 插件来实施。这样，用户就可以使用 SAP HANA 数据库本机提供的界面创建一致的基于存储的 Snapshot 备份。SnapCenter 会将每个 Snapshot 备份注册到 SAP HANA 备份目录中。因此， SnapCenter 所做的备份可以在 SAP HANA Studio 或 Cockpit 中查看，您可以直接选择这些备份来执行还原和恢复操作。
通过 NetApp SnapMirror 技术，可以将在一个存储系统上创建的 Snapshot 副本复制到由 SnapCenter 控制的二级备份存储系统。然后，可以为主存储上的每个备份集以及二级存储系统上的备份集定义不同的备份保留策略。适用于 SAP HANA 的 SnapCenter 插件可自动管理基于 Snapshot 副本的数据备份和日志备份的保留，包括备份目录的管理。适用于 SAP HANA 的 SnapCenter 插件还允许通过执行基于文件的备份对 SAP HANA 数据库执行块完整性检查。
可以使用 NFS 挂载将数据库日志直接备份到二级存储，如下图所示。
与基于文件的传统备份相比，基于存储的 Snapshot 备份具有显著优势。这些优势包括但不限于：
-
备份速度更快（几分钟）
-
由于存储层上的恢复时间（几分钟）更快，备份频率更高，因此 RTO 减少
-
在备份和恢复操作期间， SAP HANA 数据库主机，网络或存储的性能不会下降
-
根据块更改，将节省空间和带宽的复制到二级存储
有关SAP HANA备份和恢复解决方案的详细信息，请参见 "TR-4614 ：《使用 SnapCenter 实现 SAP HANA 备份和恢复》"。
SAP HANA 灾难恢复
SAP HANA 灾难恢复既可以在数据库层使用 SAP HANA 系统复制，也可以在存储层使用存储复制技术。下一节概述了基于存储复制的灾难恢复解决方案。
有关SAP HANA灾难恢复解决方案的详细信息，请参见 "TR-4646 ：《使用存储复制实现 SAP HANA 灾难恢复》"。
基于 SnapMirror 的存储复制
下图显示了一个三站点灾难恢复解决方案，它使用同步 SnapMirror 复制到本地灾难恢复数据中心，并使用异步 SnapMirror 将数据复制到远程灾难恢复数据中心。
使用同步 SnapMirror 进行数据复制可提供零 RPO 。主灾难恢复数据中心与本地灾难恢复数据中心之间的距离限制为 100 公里左右。
通过使用异步 SnapMirror 将数据复制到第三个远程灾难恢复数据中心，可以防止主灾难恢复站点和本地灾难恢复站点发生故障。RPO 取决于复制更新的频率以及传输更新的速度。理论上，距离是无限的，但限制取决于必须传输的数据量以及数据中心之间的可用连接。典型的 RPO 值介于 30 分钟到多小时之间。
这两种复制方法的 RTO 主要取决于在灾难恢复站点启动 HANA 数据库并将数据加载到内存所需的时间。假设数据的读取吞吐量为 1000 Mbps ，则加载 1 TB 数据大约需要 18 分钟。
正常运行期间，灾难恢复站点上的服务器可用作开发 / 测试系统。发生灾难时，需要关闭开发 / 测试系统并将其作为灾难恢复生产服务器启动。
这两种复制方法均允许您执行灾难恢复工作流测试，而不会影响 RPO 和 RTO 。FlexClone 卷在存储上创建并连接到灾难恢复测试服务器。
同步复制提供 StrictSync 模式。如果由于任何原因未完成对二级存储的写入，则应用程序 I/O 将失败，从而确保主存储系统和二级存储系统完全相同。只有在 SnapMirror 关系恢复为 InSync 状态后，主系统的应用程序 I/O 才会恢复。如果主存储发生故障，则在故障转移后可以在二级存储上恢复应用程序 I/O ，而不会丢失数据。在 StrictSync 模式下， RPO 始终为零。
基于 NetApp MetroCluster 的存储复制
下图简要展示了解决方案。每个站点上的存储集群可提供本地高可用性，并用于生产工作负载。每个站点的数据会同步复制到另一位置，并可在发生灾难故障转移时使用。
