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

SAP HANA Azure 虚拟机存储配置

项目
03/21/2024

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

Azure 高级 SSD 或高级存储 v1/v2
超级磁盘
Azure NetApp 文件

若要了解这些磁盘类型，请参阅适用于 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 每四个工作器节点

最佳做法是调整 /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 的 ANF 的详细信息，请阅读适用于 SAP HANA 的 Azure NetApp 文件上的 NFS v4.1 卷文档。

后续步骤

有关详细信息，请参阅：