架构
建议更改
PDF
SAP HANA 主机使用冗余 FCP 基础架构和多路径软件连接到存储控制器。如果交换机或主机总线适配器（ HBA ）发生故障，则需要一个冗余 FCP 交换机基础架构来提供容错 SAP HANA 主机到存储连接。必须在交换机上配置适当的分区，以使所有 HANA 主机能够访问存储控制器上所需的 LUN 。
可以在存储层使用不同型号的 FAS 产品系列。连接到存储的最大 SAP HANA 主机数由 SAP HANA 性能要求定义。所需的磁盘架数量取决于 SAP HANA 系统的容量和性能要求。
下图显示了一个配置示例，其中八个 SAP HANA 主机连接到一个存储 HA 对。
此架构可扩展到两个方面：
-
假设存储控制器可以在新负载下提供足够的性能以满足关键性能指标（ KPI ）要求，则将额外的 SAP HANA 主机和磁盘容量附加到存储
-
为其他 SAP HANA 主机添加更多存储系统和磁盘容量
下图显示了一个配置示例，其中，更多 SAP HANA 主机连接到存储控制器。在此示例中，需要更多磁盘架来满足 16 个 SAP HANA 主机的容量和性能要求。根据总吞吐量要求，您必须为存储控制器添加额外的 FC 连接。
无论部署的 FAS 系统存储模式如何， SAP HANA 环境也可以通过添加更多存储控制器进行扩展，如下图所示。
SAP HANA 备份
NetApp ONTAP 软件提供了用于备份 SAP HANA 数据库的内置机制。基于存储的 Snapshot 备份是一种完全受支持的集成备份解决方案，可用于 SAP HANA 单容器系统和 SAP HANA MDC 单租户系统。
基于存储的 Snapshot 备份可通过适用于 SAP HANA 的 NetApp SnapCenter 插件来实施，该插件可通过 SAP HANA 数据库提供的接口实现基于存储的一致 Snapshot 备份。SnapCenter 会在 SAP HANA 备份目录中注册 Snapshot 备份，以便备份在 SAP HANA Studio 中可见，并可选择用于还原和恢复操作。
通过使用 NetApp SnapVault 软件，可以将在主存储上创建的 Snapshot 副本复制到由 SnapCenter 控制的二级备份存储。可以为主存储上的备份和二级存储上的备份定义不同的备份保留策略。适用于 SAP HANA 数据库的 SnapCenter 插件可管理基于 Snapshot 副本的数据备份和日志备份的保留，包括备份目录的管理。此外，适用于 SAP HANA 数据库的 SnapCenter 插件还可以通过执行基于文件的备份来对 SAP HANA 数据库执行块完整性检查。
可以使用 NFS 挂载将数据库日志直接备份到二级存储，如下图所示。
与基于文件的备份相比，基于存储的 Snapshot 备份具有显著优势。这些优势包括：
-
备份速度更快（几分钟）
-
存储层上的还原速度更快（几分钟）
-
备份期间不会影响 SAP HANA 数据库主机，网络或存储的性能
-
根据块更改，将节省空间和带宽的复制到二级存储
有关使用SnapCenter的SAP HANA备份和恢复解决方案的详细信息，请参见 "TR-4614 ：《使用 SnapCenter 实现 SAP HANA 备份和恢复》"。
SAP HANA 灾难恢复
SAP HANA 灾难恢复可以通过 SAP 系统复制在数据库层执行，也可以通过存储复制技术在存储层执行。下一节概述了基于存储复制的灾难恢复解决方案。
有关使用SnapCenter的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 的存储复制
下图简要展示了解决方案。每个站点上的存储集群均可提供本地高可用性，并用于生产工作负载。每个站点上的数据会同步复制到另一位置，并可在发生灾难故障转移时使用。
