借助 SnapCenter ，大多数 HANA 配置都支持自动发现以及自动还原和恢复，但 HANA 多主机系统需要手动配置除外。

下表显示了支持自动发现的 HANA 配置。

所有 HANA 架构均支持手动配置 HANA 资源；但是，它需要一个中央 HANA 插件主机。中央插件主机可以是 SnapCenter 服务器本身，也可以是单独的 Linux 或 Windows 主机。

下表显示了手动 HANA 资源配置支持的 HANA 配置。

可以在双节点 HA 配置中设置 SnapCenter 。在这种配置中，负载平衡器（例如 F5 ）使用指向活动 SnapCenter 主机的虚拟 IP 地址在主动 / 被动模式下使用。SnapCenter 会在两台主机之间复制 SnapCenter 存储库（ MySQL 数据库），以便 SnapCenter 数据始终保持同步。

如果在 SnapCenter 服务器上安装了 HANA 插件，则不支持 SnapCenter 服务器 HA 。如果您计划在 HA 配置中设置 SnapCenter ，请勿在 SnapCenter 服务器上安装 HANA 插件。有关 SnapCenter HA 的更多详细信息，请参见此处 "NetApp 知识库页面"。

下图显示了使用 SnapCenter 服务器作为中央插件主机的配置。SAP HANA 插件和 SAP hdbsql. 客户端软件安装在 SnapCenter 服务器上。

由于 HANA 插件可以通过网络使用 hdbclient 与受管 HANA 数据库进行通信，因此您无需在各个 HANA 数据库主机上安装任何 SnapCenter 组件。SnapCenter 可以使用中央 HANA 插件主机来保护 HANA 数据库，在该主机上为受管数据库配置所有用户存储密钥。

另一方面，要实现自动发现，还原和恢复自动化以及 SAP 系统刷新操作的增强工作流自动化，需要在数据库主机上安装 SnapCenter 组件。使用中央 HANA 插件主机时，这些功能不可用。

此外，如果在 SnapCenter 服务器上安装了 HANA 插件，则无法使用内部构建 HA 功能来实现 SnapCenter 服务器的高可用性。如果 SnapCenter 服务器正在 VMware 集群中的虚拟机中运行，则可以使用 VMware HA 实现高可用性。

下图显示了一种配置，其中使用一个单独的 Linux 主机作为中央插件主机。在这种情况下， SAP HANA 插件和 SAP hdbsql. 客户端软件安装在 Linux 主机上。

上一节所述的功能可用性限制也适用于单独的中央插件主机。

但是，使用此部署选项，可以为 SnapCenter 服务器配置内部 HA 功能。中央插件主机也必须为 HA ，例如，使用 Linux 集群解决方案 。

下图显示了在每个 SAP HANA 数据库主机上安装 SAP HANA 插件的配置。

当 HANA 插件安装在每个 HANA 数据库主机上时，所有功能都可用，例如自动发现以及自动还原和恢复。此外，还可以在 HA 配置中设置 SnapCenter 服务器。

如本节开头所述，某些 HANA 系统配置（例如多主机系统）需要一个中央插件主机。因此，大多数 SnapCenter 配置都需要混合部署 HANA 插件。

NetApp 建议您在 HANA 数据库主机上为支持自动发现的所有 HANA 系统配置部署 HANA 插件。其他 HANA 系统，例如多主机配置，应使用中央 HANA 插件主机进行管理。

以下两个图显示了混合插件部署，其中 SnapCenter 服务器或单独的 Linux 主机作为中央插件主机。这两种部署之间的唯一区别是可选的 HA 配置。

通常， NetApp 建议您在每个 SAP HANA 主机上部署 HANA 插件，以启用所有可用的 SnapCenter HANA 功能并增强工作流自动化。

对于不支持自动发现的 HANA 配置，例如 HANA 多主机配置，必须另外配置一个中央 HANA 插件主机。如果可以将 VMware HA 用于 SnapCenter HA ，则中央插件主机可以是 SnapCenter 服务器。如果您计划使用 SnapCenter 内部构建 HA 功能，请使用单独的 Linux 插件主机。

下表总结了不同的部署选项。

SnapCenter 按以下顺序备份 SAP HANA 数据库：

SnapCenter 按以下顺序执行块完整性检查：

SnapCenter 通过根据 SnapCenter 备份策略中定义的保留删除主存储和 SnapCenter 存储库中的 Snapshot 副本来处理 SAP HANA 数据库备份和非数据卷备份的后台管理。

保留管理逻辑会对 SnapCenter 中的每个备份工作流执行。

也可以在 SnapCenter 中手动删除主存储上的本地备份。

SnapCenter 通过根据 SnapCenter 备份策略中定义的保留删除文件系统上的备份来处理基于文件的备份的管理。

保留管理逻辑会对 SnapCenter 中的每个备份工作流执行。

二级存储备份的保留管理由 ONTAP 根据 ONTAP 保护关系中定义的保留进行处理。

要在 SnapCenter 存储库中的二级存储上同步这些更改， SnapCenter 将使用计划的清理作业。此清理作业会将所有 SnapCenter 插件和所有资源的所有二级存储备份与 SnapCenter 存储库同步。

默认情况下，清理作业每周计划一次。与二级存储中已删除的备份相比，此每周计划会导致在 SnapCenter 和 SAP HANA Studio 中删除备份的延迟。为了避免这种不一致，客户可以将计划更改为更高的频率，例如每天更改一次。

有关如何调整清理作业计划或如何触发手动刷新的详细信息，请参阅一节 "" 更改与异地备份存储同步备份的计划频率。 ""

如果 SnapCenter 删除了任何备份，本地 Snapshot 或基于文件的备份，或者在二级存储上确定了备份删除，则此数据备份也会在 SAP HANA 备份目录中删除。

在删除主存储上本地 Snapshot 备份的 SAP HANA 目录条目之前， SnapCenter 会检查此备份是否仍存在于二级存储上。

SAP HANA 数据库会自动创建日志备份。这些日志备份会在 SAP HANA 中配置的备份目录中为每个 SAP HANA 服务创建备份文件。

要进行正向恢复，不再需要早于最新数据备份的日志备份，因此可以删除这些备份。

SnapCenter 通过执行以下步骤在文件系统级别以及 SAP HANA 备份目录中处理日志文件备份的管理工作：

默认情况下，日志备份保留管理处于启用状态。如果需要，可以按照一节中所述将其禁用 "" 在 HANA 插件主机上禁用自动发现。 ""

从 HANA 数据库角度来看， SnapCenter 支持两种不同的还原操作。

从存储角度来看，上述还原操作的执行方式必须有所不同，具体取决于所使用的存储协议（ NFS 或光纤通道 SAN ），已配置的数据保护（具有或不具有异地备份存储的主存储）， 以及用于还原操作的选定备份（从主备份存储或异地备份存储还原）。

从主存储还原整个资源时， SnapCenter 支持两种不同的 ONTAP 功能来执行还原操作。您可以在以下两个功能之间进行选择：

下表对不同的还原方法进行了比较。

从异地备份存储执行还原时，始终会使用 SnapVault 还原操作，其中存储卷的所有文件或所有 LUN 都会被 Snapshot 备份的内容覆盖。

还原单个租户需要执行基于文件的还原操作。根据使用的存储协议， SnapCenter 会执行不同的还原工作流。

自动发现的 HANA 单个容器和 HANA MDC 单租户系统可通过 SnapCenter 实现自动还原和恢复。对于这些 HANA 系统， SnapCenter 支持三种不同的还原和恢复工作流，如下图所示：

即使可以自动发现具有多个租户的 HANA MDC 系统，当前 SnapCenter 版本也不支持自动还原和恢复。对于具有多个租户的 MDC 系统， SnapCenter 支持两种不同的还原和恢复工作流，如下图所示：

这些工作流与上一节所述相同。

未启用手动配置的 HANA 资源以实现自动还原和恢复。此外，对于具有单个或多个租户的 MDC 系统，不支持单个租户还原操作。

对于手动配置的 HANA 资源， SnapCenter 仅支持手动恢复，如下图所示。手动恢复的工作流与前面几节所述的工作流相同。

下表根据 SnapCenter 中的 HANA 资源配置总结了还原和恢复操作。