你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

SAP HANA Azure 虚拟机存储配置

对于正在运行 SAP HANA 的 Azure VM,Azure 提供其他适用的存储类型。 下面列出了一些可用于 SAP HANA 部署的 SAP HANA 认证的 Azure 存储类型:

若要了解这些磁盘类型,请参阅适用于 SAP 工作负载的 Azure 存储类型一文和选择磁盘类型一文

Azure 针对 Azure 标准和高级存储 v1/v2 上的 VHD 提供两种部署方法。 建议利用 Azure 托管磁盘进行 Azure 块存储部署。

有关存储类型的列表及其 IOPS 和存储吞吐量方面的 SLA,请查看有关托管磁盘的 Azure 文档

重要

无论选择何种 Azure 存储类型,对于特定操作系统和 DBMS,都需要 SAP 支持该存储所使用的文件系统。 SAP 支持说明 #2972496 列出了不同操作系统和数据库支持的文件系统,包括 SAP HANA。 这适用于 SAP HANA 可能访问的所有卷(以便为任何任务进行读取和写入)。 若为 SAP HANA 专门使用 Azure 上的 NFS,NFS 版本的其他限制将按本文后面的说明适用

不同存储类型的最低 SAP HANA 认证条件为:

  • Azure 高级存储 v1 - 需要 /hana/log 以便获得 Azure 写入加速器支持。 /hana/data 卷可以放置在高级存储 v1 上(无需 Azure 写入加速器),也可以放置在超级磁盘上。 Azure 高级存储 v2 或 Azure 高级 SSD v2 不支持使用 Azure 写入加速器
  • 至少将 Azure 超级磁盘用于 /hana/log 卷。 /hana/data 卷可以放置在高级存储 v1/v2 上(无需 Azure 写入加速器),也可以放置在超级磁盘上(旨在以更快的速度重启)
  • 对于 /hana/log 和 /hana/data,需要基于 Azure NetApp 文件的 NFS v4.1 卷 。 /hana/shared 的卷可以使用 NFS v3 或 NFS v4.1 协议

根据从客户处取得的经验,我们更改了对在 /hana/data 和 /hana/log 之间组合使用不同存储类型的支持。 支持组合使用基于 Azure NetApp 文件进行 HANA 和 NFS 共享认证的不同 Azure 块存储。 例如,可以将 /hana/data 放在高级存储 v1 或 v2 上,同时可以将 /hana/log 放置在超级磁盘存储上,以获得所需的低延迟。 如果将基于 ANF 的卷用于 /hana/data,则 /hana/log 卷也可以放置在 HANA 认证的 Azure 块存储类型之一上。 支持将基于 ANF 的 NFS 用于其中的一个卷(如 /hana/data)并将 Azure 高级存储 v1/v2 或超级磁盘用于另一个卷(如 /hana/log)

在本地环境中,很少需要考虑 I/O 子系统及其功能。 原因在于,设备供应商会确保满足 SAP HANA 的最低存储要求。 在自行构建 Azure 基础结构时,你应该注意其中的一些 SAP 颁发的要求。 SAP 所建议的某些最低吞吐量特征如下:

  • 在 I/O 大小为 1 MB、速率为 250 MB/秒的 /hana/log 上读/写
  • 对于 16 MB 和 64 MB I/O 大小的 /hana/data,读取活动的速率至少 400 MB/秒
  • 对于 16 MB 和 64 MB I/O 大小的 /hana/data,写入活动的速率至少 250 MB/秒

如果低存储延迟对于 DBMS 系统至关重要(即使对于 SAP HANA 等 DBMS 系统也是如此),请将数据保留在内存中。 存储中的关键路径通常围绕 DBMS 系统的事务日志写入。 同时,在故障恢复之后写入保存点或加载内存中数据的操作可能也很关键。 因此,必须对 /hana/data 和 /hana/log 卷使用 Azure 高级存储 v1/v2、超级磁盘或 ANF

下面列出了有关选择 HANA 存储配置的一些指导原则:

  • 根据适用于 SAP 工作负载的 Azure 存储类型一文和选择磁盘类型一文,决定存储类型
  • 在调整 VM 大小或决定 VM 时,还要考虑总体 VM I/O 吞吐量和 IOPS 限制。 内存优化虚拟机大小一文中记录了总体 VM 存储吞吐量
  • 在决定存储配置时,请尽量使 /hana/data 卷配置低于 VM 的总体吞吐量。 通过写入保存点,SAP HANA 可以积极地发出 I/O。 写入保存点时,可能很容易达到 /hana/data 卷的吞吐量限制。 如果生成 /hana/data 卷的磁盘的吞吐量高于 VM 允许的吞吐量,则可能会出现以下情况:保存点写入所利用的吞吐量会干扰重做日志写入操作的吞吐量需求。 这种情况可能会影响应用程序吞吐量
  • 如果考虑使用 HANA 系统复制,则用于每个副本上的 /hana/data 的存储必须相同,用于每个副本上的 /hana/log 的存储类型也必须相同。 例如,不支持在一个 VM 中对 /hana/data 使用 Azure 高级存储 v1,而在运行同一 HANA 系统复制配置副本的另一个 VM 中对 hana/data 使用 Azure 超级磁盘

重要

在本文档或后续文档中,有关存储配置的建议旨在指导你如何开始使用它们。 运行工作负载并分析存储利用率模式后,你可能会意识到未利用完提供的全部存储带宽或 IOPS。 可以考虑缩减存储大小。 也或者相反,工作负载所需的存储吞吐量可能比配置的存储吞吐量更多。 这样就可能需要部署更多容量、IOPS 或吞吐量。 为了帮助用户在所需的存储容量、所需的存储延迟、所需的存储吞吐量和 IOPS 以及最低成本配置之间尽可能实现平衡(往往不易),Azure 提供了足够多的具有不同功能和不同价格的不同存储类型,以便用户为其 HANA 工作负载找到并调整到最合适的方案。

条带集与 SAP HANA 数据卷分区

使用 Azure 高级存储 v1 时,有助于获得最佳性价比的方法是将 /hana/data 和/或 /hana/log 卷条带化到多个 Azure 磁盘上。 而不是部署更大的磁盘卷来提供更多所需 IOPS 或吞吐量。 可以通过 LVM 和 MDADM 卷管理器(属于 Linux)跨多个 Azure 磁盘创建单个卷。 条带化磁盘的方法已有数十年历史,并且广为人知。 尽管这些条带化卷可达到所需的 IOPS 或吞吐量功能,但也因需要管理这些条带化卷而增加了复杂性。 尤其是在卷需要扩展容量的情况下。 至少对于 /hana/data,SAP 引入了一种替代方法,同样可实现跨多个 Azure 磁盘进行条带化的目标。 从 SAP HANA 2.0 SPS03 开始,HANA indexserver 可以将其 I/O 活动条带化到位于不同 Azure 磁盘上的多个 HANA 数据文件中。 优点是无需负责创建和管理不同 Azure 磁盘上的条带化卷。 以下文章详细说明了 SAP HANA 的数据卷分区功能:

通过这些详细信息可知,应用此功能可消除基于卷管理器的条带集的复杂性。 你还会认识到,HANA 数据卷分区不仅仅适用于 Azure 块存储(如 Azure 高级存储 v1/v2)。 利用此功能还可在 NFS 共享设有 IOPS 或吞吐量限制的情况下跨这些共享进行条带化。

Linux I/O 计划程序模式

Linux 提供多种不同的 I/O 计划模式。 Linux 供应商和 SAP 的常规建议是重新配置磁盘卷的 I/O 调度程序模式,即从“mq-deadline”或“kyber”模式配置为“noop”(non-multiqueue) 或“none”(multiqueue) 模式(如果 SLES saptune 配置文件尚未如此设置) 。 有关详细信息,请参阅:

在 Red Hat 上,原样保留由不同 SAP 应用程序的特定优化配置文件所设定的设置。

使用逻辑卷管理器时的条带大小

如果使用 LVM 或 mdadm 跨多个 Azure 高级磁盘生成条带集,则需要定义条带大小。 这些大小在 /hana/data 和 /hana/log 之间有所不同 。 建议:对于条带大小,建议使用:

  • 256 KB 的 /hana/data
  • 64 KB 的 /hana/log

注意

根据在较新 Linux 版本方面的客户体验,/hana/data 的条带大小已从之前要求 64 KB 或 128 KB 这一建议更改为 256 KB。 256 KB 的大小提供的性能略佳。 我们还将建议的 /hana/log 条带大小从 32 KB 更改为 64 KB,以通过更大的 I/O 获得足够吞吐量。

注意

不需要使用 RAID 卷配置任何冗余级别,因为 Azure 块存储为一个 VHD 保留三个映像。 使用 Azure 高级磁盘的条带集纯粹是为了配置可提供足够 IOPS 和/或 I/O 吞吐量的卷。

在条带集下面累积多个 Azure 磁盘可以提高 IOPS 和存储吞吐量。 因此,如果使用 3 倍的 P30 Azure 高级存储 v1 磁盘构建条带集,则单个 Azure 高级存储 v1 P30 磁盘的 IOPS 和存储吞吐量会提高 3 倍。

重要

如果使用 LVM 或 mdadm 作为卷管理器跨多个 Azure 高级磁盘创建条带集,则不能将 /data、/log 和 /shared 这三个 SAP HANA 文件系统置于默认或根卷组。 强烈建议遵循 Linux 供应商指南,该指南通常用于为 /data、/log 和 /shared 创建各自的卷组。

HANA 共享文件系统的注意事项

在调整 HANA 文件系统大小时,最关注的是数据和日志文件 HANA 系统。 不过,/hana/shared 在运行稳定的 HANA 系统方面也发挥着重要作用,因为它托管 HANA 二进制文件之类的重要组件。
如果过小,/hana/shared 可能会因过多的读/写操作而变得 I/O 饱和 - 例如,在写入大型转储时、在密集跟踪期间、或在将备份写入 /hana/shared 文件系统时,情况就是如此。 延迟也可能增加。

如果 HANA 系统采用 HA 配置,则共享文件系统(即 /hana/shared)响应缓慢可能会导致群集资源超时。 这些超时可能会导致不必要的故障转移,因为 HANA 资源代理可能会错误地认为数据库不可用。

SAP 针对 /hana/shared 建议大小的指南如下所示:

体积 建议的大小
/hana/shared scale-up 最小值(1 TB,1 x RAM)
/hana/shared scale-out 1 x 工作器节点 RAM
每四个工作器节点

如需更多详细信息,请参阅以下 SAP 说明:
3288971 - 常见问题解答:SAP HANA 系统复制环境中的 SUSE HAE/RedHat HAA Pacemaker 群集资源管理器
1999930 - 常见问题解答:SAP HANA I/O 分析

最佳做法是调整 /hana/shared 的大小以避免性能瓶颈。 请记住,大小合适的 /hana/shared 文件系统有助于提高 SAP HANA 系统的稳定性和可靠性,尤其是在 HA 场景中。

HANA 的 Azure 高级存储 v1 配置

有关使用 Azure 高级存储 v1 的详细 HANA 存储配置建议,请阅读 SAP HANA Azure 虚拟机高级 SSD 存储配置文档。

HANA 的 Azure 高级 SSD v2 配置

有关使用 Azure 高级 SSD v2 存储的详细 HANA 存储配置建议,请阅读 SAP HANA Azure 虚拟机高级 SSD v2 存储配置文档。

适用于 SAP HANA 的 Azure 超级磁盘存储配置

有关使用 Azure 超级磁盘的详细 HANA 存储配置建议,请阅读 SAP HANA Azure 虚拟机超级磁盘存储配置文档。

Azure NetApp 文件上的 NFS v4.1 卷

若要详细了解适用于 HANA 的 Azure NetApp 文件,请阅读 Azure NetApp 文件上适用于 SAP HANA 的 NFS v4.1 卷文档。

后续步骤

有关详细信息,请参阅: