你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
适用于 SAP 工作负载的 Azure 存储类型
Azure 具有多种存储类型，它们在功能、吞吐量、延迟和价格上各不相同。 某些存储类型不可用于 SAP 方案，或者只能在此类方案中受限使用。 但是，有几种 Azure 存储类型非常适合特定的 SAP 工作负载方案或针对特定的 SAP 工作负载方案进行了优化。 尤其是对于 SAP HANA，某些 Azure 存储类型经认证可在 SAP HANA 中使用。 本文档将介绍不同类型的存储、其功能以及在 SAP 工作负载和 SAP 组件中的可用性。
有关整篇文章中使用的单位的注解。 公有云供应商已改用 GiB (Gibibyte) 或 TiB (Tebibyte)（而不是 GB 或 TB）作为大小单位。 因此，所有 Azure 文档和定价都使用这些单元。 在整篇文档中，我们只会提到这些 MiB、GiB 和 TiB 大小单位。 你可能需要使用 MB、GB 和 TB 进行规划。 因此，如果需要适用于 400 MiB/秒吞吐量（而不是 250 MiB/秒吞吐量）的大小，请注意计算中的一些细微差别。
Microsoft Azure 存储复原
Microsoft Azure 的标准 HDD 和标准 SSD 存储、Azure 高级存储、高级 SSD v2 和超级磁盘将基本 VHD（含 OS）和 VM 附加的数据磁盘或 VHD 在三个不同存储节点上保留三个副本。 如果存储节点发生故障，故障转移到另一个副本并为新副本设定种子是透明的。 由于这种冗余，不需要跨多个 Azure 磁盘使用任何类型的存储冗余层。 这称为本地冗余存储 (LRS)。 LRS 是 Azure 中此类存储的默认设置。 Azure NetApp 文件提供足够的冗余来实现与其他本机 Azure 存储相同的 SLA。
还有其他多种冗余方法，Azure 存储复制一文中介绍了所有这些方法，它们适用于 Azure 提供的某些不同存储类型。
注意
使用 Azure 存储来存储数据库数据和重做日志文件，LRS 是目前唯一受支持的复原级别
另请注意，不同的 Azure 存储类型会影响虚拟机 SLA 中发布的单一 VM 可用性 SLA。
Azure 托管磁盘
托管磁盘是 Azure 资源管理器中的一种资源类型，可用来代替 Azure 存储帐户中存储的 VHD。 托管磁盘会与其所附加到的虚拟机[可用性集][virtual-machines-manage-availability]自动保持一致。 通过这样的对齐方式，你将体验到虚拟机的可用性和在虚拟机中运行的服务的改进。 有关详细信息，请阅读概述文章。
注意
我们要求全新部署的、对磁盘使用 Azure 块存储（除 Azure NetApp 文件和 Azure 文件存储以外的其他所有 Azure 存储）的 VM 为基本 VHD/OS 磁盘以及存储 SAP 数据库文件的数据磁盘使用 Azure 托管磁盘。 不管你是通过可用性集、跨可用性区域还是独立于集和区域部署 VM，都需要满足此要求。 用于存储备份目的的磁盘不一定需要是托管磁盘。
SAP 工作负载的存储方案
Azure 中部署的各种堆栈组件中的 SAP 工作负载需要持久性存储。 这些方案最起码需要满足如下所述的要求：
- 持久保存 VM 的基本 VHD，其中包含操作系统以及在该磁盘中安装的其他软件。 该磁盘/VHD 是 VM 的根目录。 对它所做的任何更改都需要持久保存， 以便下次停止再重启 VM 时，以前所做的所有更改都仍会保留。 在 Azure 将 VM 部署到其他主机（而不是最初运行该 VM 的主机）时，这一点尤其重要
- 永久性数据磁盘。 这些磁盘是附加的 VHD，用于存储应用程序数据。 此应用程序数据可以是数据库的数据和日志/重做文件、备份文件或软件安装。 这表示除包含操作系统的基本 VHD 以外的任何磁盘
- 包含 NetWeaver 或 S/4HANA 全局传输目录的文件共享或共享磁盘。 这些共享内容要么由在多个 VM 中运行的软件使用，要么用于构建高可用性故障转移群集方案
- /sapmnt 目录或 EDI 进程的公用文件共享，或类似内容。 这些共享内容要么由在多个 VM 中运行的软件使用，要么用于构建高可用性故障转移群集方案
接下来的几个部分将介绍适用于上述四种 SAP 工作负载方案的不同 Azure 存储类型及其可用性。 Azure 有哪些可用的磁盘类型？一文中介绍了不同 Azure 存储类型的一般用法分类。 有关使用适用于 SAP 工作负载的不同 Azure 存储类型的建议没有太大的差别。
有关 SAP NetWeaver/S/4HANA 应用层的 Azure 存储类型的支持限制，请阅读 SAP 支持说明 2015553。 有关 SAP HANA 认证和支持的 Azure 存储类型，请阅读文章 SAP HANA Azure 虚拟机存储配置。
介绍不同 Azure 存储类型的部分将提供有关使用 SAP 支持的存储时的限制和各种可行性的更多背景信息。
使用 DBMS 复制时的存储选择
我们的引用体系结构预见到了 DBMS 功能的使用，如 SQL Server Always On、HANA 系统复制、Db2 HADR 或 Oracle 数据防护。 如果在两个或多个 Azure 虚拟机之间使用这些技术，则为每个 VM 选择的存储类型都必须相同。 表示 DBMS HA 配置中活动节点和副本节点之间的存储配置需要相同。
SAP 存储方案的存储建议
在深入到细节之前，我们先根据本文档开头部分的内容提供汇总和建议。 特定 Azure 存储类型的详细信息将在本文档部分结束后提供。 表格中汇总了适用于 SAP 存储方案的存储建议：
| 使用方案 | 标准 HDD | 标准 SSD | 高级存储 | 高级 SSD v2 | 超级磁盘 | Azure NetApp 文件 | Azure 高级文件 |
|---|---|---|---|---|---|---|---|
| OS 磁盘 | 不适用 | 受限适用（非生产） | 建议 | 不可用 | 不可用 | 不可用 | 不可用 |
| 全局传输目录 | 不支持 | 不支持 | 建议 | 建议 | 建议 | 建议 | 重点推荐 |
| /sapmnt | 不适用 | 受限适用（非生产） | 建议 | 建议 | 建议 | 建议 | 重点推荐 |
| DBMS 数据卷 SAP HANA M/Mv2 VM 系列 | 不支持 | 不支持 | 建议 | 建议 | 建议 | 建议2 | 不支持 |
| DBMS 日志卷 SAP HANA M/Mv2 VM 系列 | 不支持 | 不支持 | 建议1 | 建议 | 建议 | 建议2 | 不支持 |
| DBMS 数据卷 SAP HANA Esv3/Edsv4 VM 系列 | 不支持 | 不支持 | 建议 | 建议 | 建议 | 建议2 | 不支持 |
| DBMS 日志卷 SAP HANA Esv3/Edsv4 VM 系列 | 不支持 | 不支持 | 不支持 | 建议 | 建议 | 建议2 | 不支持 |
| HANA 共享卷 | 不支持 | 不支持 | 建议 | 建议 | 建议 | 建议 | 建议3 |
| DBMS 数据卷非 HANA | 不支持 | 受限适用（非生产） | 建议 | 建议 | 建议 | 仅适用于 SLES/RHEL Linux 上 Oracle Linux、Db2 和 SAP ASE 上的特定 Oracle 版本 | 不支持 |
| DBMS 日志卷非 HANA M/Mv2 VM 系列 | 不支持 | 受限适用（非生产） | 建议1 | 建议 | 建议 | 仅适用于 SLES/RHEL Linux 上 Oracle Linux、Db2 和 SAP ASE 上的特定 Oracle 版本 | 不支持 |
| DBMS 日志卷非 HANA 非 M/Mv2 VM 系列 | 不支持 | 受限适用（非生产） | 适用于最大为中型的工作负载 | 建议 | 建议 | 仅适用于 SLES/RHEL Linux 上 Oracle Linux、Db2 和 SAP ASE 上的特定 Oracle 版本 | 不支持 |
1 对 M/Mv2 VM 系列的日志/重做日志卷使用 Azure 写入加速器
2 使用 ANF 需要 /hana/data 和 /hana/log 位于 ANF 上
3 到目前为止，仅在 SLES 上进行了测试
下面列出了不同存储类型的预期特征：
| 使用方案 | 标准 HDD | 标准 SSD | 高级存储 | 高级 SSD v2 | 超级磁盘 | Azure NetApp 文件 | Azure 高级文件 |
|---|---|---|---|---|---|---|---|
| 吞吐量/IOPS SLA | 否 | No | 是 | 是 | 是 | 是 | 是 |
| 延迟读取 | 高 | 中到高 | 低 | submillisecond | submillisecond | submillisecond | low |
| 延迟写入 | 高 | 中到高 | 低（亚毫秒1） | submillisecond | submillisecond | submillisecond | low |
| HANA 支持 | 否 | 否 | 是1 | 是 | 是 | 是 | 否 |
| 可以使用磁盘快照 | 是 | 是 | 是 | 否 | No | 是 | 否 |
| 使用可用性集时在不同存储群集上分配磁盘 | 通过托管磁盘 | 通过托管磁盘 | 通过托管磁盘 | 磁盘类型在通过可用性集部署的 VM 上不受支持 | 磁盘类型在通过可用性集部署的 VM 上不受支持 | 否3 | 否 |
| 适应可用性区域 | 是 | 是 | 是 | 是 | 是 | 为公共预览版 | 否 |
| 同步区域冗余 | 不适用于托管磁盘 | 不适用于托管磁盘 | 不支持 DBMS | 否 | No | No | 是 |
| 异步区域冗余 | 不适用于托管磁盘 | 不适用于托管磁盘 | 不支持 DBMS | 否 | 否 | 预览模式 | 否 |
| 异地冗余 | 不适用于托管磁盘 | 不适用于托管磁盘 | 否 | No | 否 | 可能 | 否 |
1 对 M/Mv2 VM 系列的日志/重做日志卷使用 Azure 写入加速器
2 成本取决于预配的 IOPS 和吞吐量
3 创建不同的 ANF 容量池并不保证容量池部署到不同的存储单元
重要
请查看本文档的“Azure NetApp 文件”部分，查找有关要求延迟小于 1 毫秒时 NFS 卷和 VM 的邻近放置的具体信息。
Azure 高级存储
现已推出 Azure 高级 SSD 存储，此类存储旨在提供：
- 低 I/O 延迟
- IOPS 和吞吐量的 SLA
- 更小的 I/O 延迟变化性
这种类型的存储针对 DBMS 工作负载、需要低个位数毫秒延迟的存储流量以及 IOPS 和吞吐量方面的 SLA。 Azure 高级存储的成本基础不是存储在此类磁盘中的实际数据量，而是此类磁盘的大小类别，与存储在磁盘中的数据量无关。 还可在高级存储中创建不直接映射到高级 SSD 一文中所示大小类别的磁盘。 此文中的结论如下：
- 存储按范围组织的。 例如，513 GiB 到 1024 GiB 容量范围内的磁盘的功能和每月成本相同
- 每 GiB 的 IOPS 在各种大小类别中不是呈线性趋势。 低于 32 GiB 的较小磁盘的每 GiB IOPS 速率较高。 对于超过 32 GiB 到 1024 GiB 的磁盘，每 GiB 的 IOPS 速率为每 GiB 4-5 IOPS。 对于最大 32,767 GiB 的较大磁盘，每 GiB 的 IOPS 速率将低于 1
- 此存储的 I/O 吞吐量不会根据磁盘类别大小线性变化。 对于较小的磁盘，例如容量为 65 GiB 到 128 GiB 的类别，吞吐量大约为 780 KB/GiB。 对于极大型磁盘（例如 32,767 GiB 磁盘），吞吐量大约为 28 KB/GiB
- 在不更改磁盘容量的情况下无法更改 IOPS 和吞吐量 SLA
下面是 SAP 工作负载的功能矩阵：
| 功能 | 注释 | 备注/链接 |
|---|---|---|
| OS 基本 VHD | 适用 | 所有系统 |
| 数据磁盘 | 适用 | 所有系统 - 特别适用于 SAP HANA |
| SAP 全局传输目录 | 是 | 支持 |
| SAP sapmnt | 适用 | 所有系统 |
| 备份存储 | 适用 | 用于短期存储备份 |
| 共享/共享磁盘 | 不可用 | 需要 Azure 高级文件存储或第三方存储 |
| 复原能力 | LRS | 不为磁盘提供 GRS 或 ZRS |
| 延迟 | 低到中 | - |
| IOPS SLA | 是 | - |
| IOPS 根据容量线性变化 | 托架中为半线性变化 | 托管磁盘定价 |
| 每个磁盘的最大 IOPS | 20,000 与磁盘大小相关 | 还要考虑 VM 限制 |
| 吞吐量 SLA | 是 | - |
| 吞吐量根据容量线性变化 | 托架中为半线性变化 | 托管磁盘定价 |
| HANA 认证 | 是 | 特别适用于 SAP HANA |
| Azure 写入加速器支持 | 否 | - |
| 磁盘突发 | 是 | - |
| 可以使用磁盘快照 | 是 | - |
| 可以使用 Azure 备份 VM 快照 | 是 | - |
| 成本 | 中型 | - |
Azure 高级存储不使用 Azure 高级存储提供的常用缓存类型来实现 SAP HANA 存储延迟 KPI。 若要实现 SAP HANA 日志写入的存储延迟 KPI，需要根据启用写入加速器一文中所述使用 Azure 写入加速器缓存。 Azure 写入加速器可为所有其他 DBMS 系统的事务日志写入和重写日志写入带来好处。 因此，我们建议在所有 SAP DBMS 部署中使用它。 对于 SAP HANA，/hana/log 的 Azure 写入加速器必须与 Azure 高级存储结合使用。
摘要：Azure 高级存储是建议用于 SAP 工作负载的 Azure 存储类型之一。 此建议适用于非生产和生产系统。 Azure 高级存储适合处理数据库工作负载。 使用 Azure 写入加速器将显著降低针对 Azure 高级磁盘的写入延迟。 但是，对于具有高 IOPS 和吞吐率的 DBMS 系统，你需要过度预配存储容量。 或者，你需要使用 Windows 存储空间或 Linux 中的逻辑卷管理器等功能来生成条带集，在一端你提供所需的容量。 还要以最佳成本效率提供必要的 IOPS 或吞吐量。
适用于高级存储的 Azure 突发功能
我们为容量低于或等于 512 GiB 的 Azure 高级存储磁盘提供突发功能。 磁盘突发一文中介绍了磁盘突发的具体工作原理。 阅读该文章可以了解当 I/O 工作负载低于磁盘的额定 IOPS 和吞吐量时 IOPS 和吞吐量累积的概念（有关额定吞吐量的详细信息，请参阅托管磁盘定价）。 磁盘当前用量与额定值之间的 IOPS 和吞吐量增量将会累积。 突发限制为最长 30 分钟。
可以计划使用此突发功能的理想情况可能是卷或磁盘包含不同 DBMS 的数据文件。 这些卷（尤其是包含中小型系统的卷）所需的 I/O 工作负载预期类似于：
- 低等到中等的读取工作负载，因为理想情况下数据缓存在内存中。 或者与 SAP HANA 一样，应完全在内存中
- 定期发出的数据库检查点或保存点触发的写入突发
- 没有通过存储快照执行备份时在持续工作流中读取的备份工作负载
- 对于 SAP HANA，在实例重启后将数据加载到内存中
尤其是在工作负载每秒仅处理几百个事务的小型 DBMS 系统上，此类突发功能对于存储事务或重做日志的磁盘或卷也很有用。 此类磁盘或卷的预期工作负载类似于：
- 定期写入磁盘，这取决于工作负载和工作负载性质，因为应用程序每次发出的提交都可能触发 I/O 操作
- 执行操作任务（如创建或重新生成索引）时，吞吐量的工作负载会更高
- 执行事务日志或重做日志备份时读取突发
Azure 高级 SSD v2
Azure 高级 SSD v2 存储是高级存储的新版本，目的是：
- 为较小的读取和写入 I/O 大小提供亚毫秒 I/O 延迟
- IOPS 和吞吐量的 SLA
- 按预配 GB 支付容量费用
- 为每个磁盘提供一组默认的 IOPS 和存储吞吐量
- 可以为每个磁盘添加更多 IOPS 和吞吐量，并为这些额外的预置资源单独付费
- 无需借助 Azure 写入加速器或其他缓存等其他功能即可通过 SAP HANA 认证
这种类型的存储针对 DBMS 工作负载、需要亚毫秒级延迟的存储流量以及 IOPS 和吞吐量方面的 SLA。 高级 SSD v2 磁盘的默认设置为 3,000 IOPS 和 125 MBps 吞吐量。 以及为单个磁盘添加更多 IOPS 和吞吐量的可能性。 存储定价的结构是增加更多的吞吐量或 IOPS 不会对价格产生重大影响。 不过，我们将保留你决定高级 SSD v2 的存储配置的外观。 对于基本启动，请阅读 SAP HANA Azure 虚拟机高级 SSD v2 存储配置。
对于实际区域，这种新的块存储类型可用，实际限制请阅读文档高级 SSD v2。
下面是 SAP 工作负载的功能矩阵：
| 功能 | 注释 | 备注/链接 |
|---|---|---|
| OS 基本 VHD | 不支持 | 无系统 |
| 数据磁盘 | 适用 | 所有系统 |
| SAP 全局传输目录 | 是 | 所有系统 |
| SAP sapmnt | 适用 | 所有系统 |
| 备份存储 | 适用 | 用于短期存储备份 |
| 共享/共享磁盘 | 不可用 | 需要 Azure 高级文件或 Azure NetApp 文件 |
| 复原能力 | LRS | 不为磁盘提供 GRS 或 ZRS |
| 延迟 | submillisecond | - |
| IOPS SLA | 是 | - |
| IOPS 根据容量线性变化 | 半线性 | 托管磁盘定价 |
| 每个磁盘的最大 IOPS | 80,000 与磁盘大小相关 | 还要考虑 VM 限制 |
| 吞吐量 SLA | 是 | - |
| 吞吐量根据容量线性变化 | 半线性 | 托管磁盘定价 |
| HANA 认证 | 是 | - |
| Azure 写入加速器支持 | 否 | - |
| 磁盘突发 | 否 | - |
| 可以使用磁盘快照 | 否 | - |
| 可以使用 Azure 备份 VM 快照 | 否 | - |
| 成本 | 中型 | - |
与 Azure 高级存储相反，Azure 高级 SSD v2 满足 SAP HANA 存储延迟 KPI。 因此，你不需要按照启用写入加速器一文中所述来使用 Azure 写入加速器缓存。
摘要：Azure 高级 SSD v2 是适合 SAP 工作负载的最佳性价比的块存储。 Azure 高级 SSD v2 适合处理数据库工作负载。 亚毫秒级延迟是要求苛刻的 DBMS 工作负载的理想存储。 尽管它是 2022 年 11 月发布的较新的存储类型。 因此，在接下来的几个月中，仍有一些限制可能会消失。
Azure 超级磁盘
Azure 超级磁盘为 Azure IaaS VM 提供高吞吐量、高 IOPS 和一贯低延迟的磁盘存储。 超级磁盘的一些优势包括能够动态更改磁盘以及工作负载的 IOPS 和吞吐量，而无需重启虚拟机 (VM)。 超级磁盘适用于数据密集型工作负载，例如 SAP DBMS 工作负载。 超级磁盘只能用作数据磁盘，而不能用作存储操作系统的基本 VHD 磁盘。 我们建议使用 Azure 高级存储作为基本 VHD 磁盘。
创建超级磁盘时，可以定义三个维度：
- 磁盘的容量。 范围为 4 GiB 到 65,536 GiB
- 磁盘的预配 IOPS。 不同的最大值适用于磁盘容量。 有关更多详细信息，请参阅超级磁盘一文
- 预配的存储带宽。 根据磁盘容量应用不同的最大带宽。 有关更多详细信息，请参阅超级磁盘一文
单个磁盘的成本根据可为特定磁盘单独定义的三个维度来确定。
下面是 SAP 工作负载的功能矩阵：
| 功能 | 注释 | 备注/链接 |
|---|---|---|
| OS 基本 VHD | 不起作用 | - |
| 数据磁盘 | 适用 | 所有系统 |
| SAP 全局传输目录 | 是 | 支持 |
| SAP sapmnt | 适用 | 所有系统 |
| 备份存储 | 适用 | 用于短期存储备份 |
| 共享/共享磁盘 | 不可用 | 需要第三方组件 |
| 复原能力 | LRS | 不为磁盘提供 GRS 或 ZRS |
| 延迟 | 极低 | - |
| IOPS SLA | 是 | - |
| IOPS 根据容量线性变化 | 托架中为半线性变化 | 托管磁盘定价 |
| 每个磁盘的最大 IOPS | 1,200 到 160,000 | 与磁盘容量相关 |
| 吞吐量 SLA | 是 | - |
| 吞吐量根据容量线性变化 | 托架中为半线性变化 | 托管磁盘定价 |
| HANA 认证 | 是 | - |
| Azure 写入加速器支持 | 否 | - |
| 磁盘突发 | 否 | - |
| 可以使用磁盘快照 | 否 | - |
| 可以使用 Azure 备份 VM 快照 | 否 | - |
| 成本 | 高于高级存储 | - |
摘要：Azure 超级磁盘是适合各种 SAP 工作负载的亚毫秒级低延迟存储。 到目前为止，超级磁盘只能与通过可用性区域（区域部署）部署的 VM 结合使用。 超级磁盘不支持存储快照。 与所有其他存储不同，超级磁盘不能用作基本 VHD 磁盘。 超级磁盘非常适合 I/O 工作负载极不稳定且你想让已部署的存储吞吐量或 IOPS 适应存储工作负载模式（而不是调整大小以最大程度地利用带宽和 IOPS）的情况。
Azure NetApp 文件 (ANF)
Azure NetApp 文件是 Microsoft 与 NetApp 合作的成果，旨在提供高性能的 Azure 原生 NFS 和 SMB 共享。 其重心是提供高带宽、低延迟的存储以实现 DBMS 部署方案，并最终通过 Azure 实现 NetApp 存储的典型操作功能。 NFS/SMB 共享在区分存储吞吐量和价格的三个不同服务级别中提供。 Azure NetApp 文件的服务级别一文中介绍了服务级别。 对于不同类型的 SAP 工作负载，强烈建议使用以下服务级别：
- SAP DBMS 工作负载：“性能”级别，最好是使用“超级”级别
- SAPMNT 共享：“性能”级别，最好是使用“超级”级别
- 全局传输目录：“性能”级别，最好是使用“超级”级别
注意
最小预配大小为一个 4 TiB 单位（称为容量池）。 然后，在此容量池中创建卷。 可以构建的最小卷为 100 GiB。 可以 TiB 为增量扩展容量池。 有关定价信息，请查看 Azure NetApp 文件定价一文
目前有多种 SAP 工作负载方案支持 ANF 存储：
- 为 SAP 的全局传输目录提供 SMB 或 NFS 共享
- 高可用性方案中的共享 sapmnt，如以下所述：
- 为 /hana/data 和 /hana/log 卷使用 NFS v4.1 共享和/或为 /hana/shared 卷使用 NFS v4.1 或 NFS v3 卷的 SAP HANA 部署，如 SAP HANA Azure 虚拟机存储配置一文中所述
- Suse 或 Red Hat Linux 来宾 OS 中的 IBM Db2
- 为 Oracle 数据和重做日志卷使用 dNFS 的 Oracle Linux 来宾 OS 中的 Oracle 部署。 有关更多详细信息，请参阅适用于 SAP 工作负载的 Azure 虚拟机 Oracle DBMS 部署一文
- Suse 或 Red Hat Linux 来宾 OS 中的 SAP ASE
注意
目前，基于 Azure NetApp 文件的 SMB 不支持 DBMS 工作负载。
与 Azure 高级存储一样，如果需要遵守吞吐量的某些下限，则每 GB 的固定或线性吞吐量大小可能是个问题。 SAP HANA 就属于这种情况。 使用 ANF 时，此问题可能比使用 Azure 高级磁盘时更明显。 使用 Azure 高级磁盘时，可以采用每 GiB 吞吐量相对较高的多个较小磁盘，并条带化这些磁盘，使其更具经济效益，并以更低的容量实现更高的吞吐量。 此类条带化不适用于 ANF 上托管的 NFS 或 SMB 共享。 此项限制会导致部署容量过多，如下所述：
- 例如，若要在 ANF 上托管的 NFS 卷中实现 250 MiB/秒的吞吐量，需要部署“超级”服务级别的 1.95 TiB 容量。
- 若要实现 400 MiB/秒的吞吐量，需要部署 3.125 TiB 容量。 但是，可能需要过度预配容量才能实现所需的卷吞吐量。 这种容量过度预配会影响较小 HANA 实例的定价。
- 在 ANF 顶层为 SAP /sapmnt 目录使用 NFS 时，通常还远远达不到 Azure NetApp 文件强制实施的下限容量（100 GiB 到 150 GiB）。 但是，客户体验表明，12.8 MiB/秒的相关吞吐量（使用“超级”服务级别）可能不足，并可能对 SAP 系统的稳定性产生负面影响。 在这种情况下，客户可以通过增大 /sapmnt 卷的容量来避免出现问题，以便为该卷提供更高的吞吐量。
下面是 SAP 工作负载的功能矩阵：
| 功能 | 注释 | 备注/链接 |
|---|---|---|
| OS 基本 VHD | 不起作用 | - |
| 数据磁盘 | 适用 | SAP HANA、Oracle Linux 上的 Oracle、Db2 和 SLES/RHEL 上的 SAP ASE |
| SAP 全局传输目录 | 是 | SMB 和 NFS |
| SAP sapmnt | 适用 | 所有系统 SMB（仅适用于 Windows）或 NFS（仅适用于 Linux） |
| 备份存储 | 适用 | - |
| 共享/共享磁盘 | 是 | SMB 3.0、NFS v3 和 NFS v4.1 |
| 复原能力 | LRS 和 GRS | GRS 可用 |
| 延迟 | 极低 | - |
| IOPS SLA | 是 | - |
| IOPS 根据容量线性变化 | 严格线性 | 取决于服务级别 |
| 吞吐量 SLA | 是 | - |
| 吞吐量根据容量线性变化 | linear | 取决于服务级别 |
| HANA 认证 | 是 | - |
| 可以使用磁盘快照 | 是 | - |
| 可以使用 Azure 备份 VM 快照 | 否 | - |
| 成本 | 高于高级存储 | - |
ANF 存储的其他内置功能：
- 执行卷快照的功能
- 从快照中克隆 ANF 卷
- 从快照还原卷（快照还原）
- 适用于 SAP HANA 和 Oracle 的应用程序一致的快照备份
重要
特别是对于数据库部署，你希望至少为重做日志实现低延迟。 尤其是对于 SAP HANA，SAP 需要小于 1 毫秒的延迟，因为 HANA 重做日志写入的大小较小。 若要了解此类延迟，请参阅以下可能性。
重要
即使对于非 DBMS 用法，也应该使用预览功能，以便在放置应将 NFS 共享装载到的 VM 所在的同一 Azure 可用性区域中创建 NFS 共享。 有关此功能的信息，请参阅管理 Azure NetApp 文件的可用性区域卷放置一文。 拥有这种类型的可用性区域对齐的动机是，通过在未在其中运行 VM 的另一个 AvZone 中拥有 NFS 共享来降低风险面。
- 实现 VM 与 NFS 共享之间的最佳邻近放置，可使用应用程序卷组进行安排。 除安排最佳邻近放置和实现最低延迟外，应用程序卷组的优点还在于，可跨 Azure NetApp 文件后端群集中的不同控制器分布适用于 SAP HANA 部署的不同 NFS 共享。 此方法的缺点是需要再次执行固定过程。 这是一个结束将 VM 部署限制为单个数据中心的过程。 而不是第一种方法中介绍的可用性区域。 这意味着更改装载了 NFS 卷的 VM 的 VM 大小和 VM 系列不再那么灵活。
- 不使用可用性放置组的当前过程。 到目前为止，此过程仅适用于 SAP HANA。 此过程还使用与可用性卷组相同的手动固定过程。 此方法是过去三年使用的方法。 此过程的灵活性限制与使用可用性卷组的过程相同。
作为基于 ANF 针对数据库特定用途分配 NFS 卷的首选项，应首先尝试在 VM 所在的同一区域中分配 NFS 卷。 尤其适用于非 HANA 数据库。 仅当延迟被证明不足时，才应执行手动固定过程。 对于较小的 HANA 工作负载或非生产 HANA 工作负载，还应遵循区域分配方法。 仅在性能和延迟不足的情况下，才应使用应用程序卷组。
摘要：Azure NetApp 文件是经过 HANA 认证的低延迟存储，可用于部署 NFS 和 SMB 卷或共享。 该存储具有三个不同的服务级别，以线性方式为卷的每个 GiB 容量提供不同的吞吐量和 IOPS。 通过 ANF 存储，可以使用备用节点部署 SAP HANA 横向扩展方案。 该存储适用于根据需要为 /sapmnt 或 SAP 全局传输目录提供文件共享。 ANF 存储附带可作为本机 NetApp 功能提供的功能可用性。
Azure 高级文件
Azure 高级文件是一种共享存储，它以适中的价格和足够的延迟提供 SMB 和 NFS，以处理 SAP 应用层的共享。 最重要的是，Azure 高级文件自动提供共享的同步区域复制，如果一个副本失败，另一个区域中的另一个副本可以接管。 与 Azure NetApp 文件相反，没有性能层。 也不需要容量池。 收费基于不同份额的实际预配容量。 Azure 高级文件还完全没有作为 SAP 工作负载的 DBMS 存储进行测试。 但相反，SAP 工作负载的使用场景侧重于所有类型的 SMB 和 NFS 共享，因为它们在 SAP 应用层上使用。 Azure 高级文件也适用于 /hana/shared。
注意
到目前为止，基于 Azure 高级文件的共享卷不支持任何 SAP DBMS 工作负载。
Azure 高级文件支持的 SAP 方案列表如下：
- 为 SAP 的全局传输目录提供 SMB 或 NFS 共享
- 高可用性方案中的共享 sapmnt，如以下所述：
- 使用 Azure 文件存储上的 NFS 在 SUSE Linux Enterprise Server 上的 Azure VM 实现 SAP NetWeaver 高可用性
- 使用 Azure 文件存储上的 NFS 在 Red Hat Enterprise Linux 的 Azure VM 上实现 SAP NetWeaver 高可用性
- 使用适用于 SAP 应用程序的 Azure 文件存储高级 SMB 实现 Windows 上 Azure VM 的 SAP NetWeaver 高可用性
- 在 SUSE Linux Enterprise Server 上使用 HSR 实现 SAP HANA 横向扩展系统的高可用性
与 Azure NetApp 文件相比，Azure 高级文件以 100 GB 的最小共享大小开始具有更大的 IOPS。 这个更高的 IOPS 标准可以避免为实现特定 IOPS 和吞吐量值而过度预配容量。 有关 IOPS 和存储吞吐量，请阅读 Azure 文件可伸缩性和性能目标中的 Azure 文件共享缩放目标章节。
下面是 SAP 工作负载的功能矩阵：
| 功能 | 注释 | 备注/链接 |
|---|---|---|
| OS 基本 VHD | 不起作用 | - |
| 数据磁盘 | 不支持 SAP 工作负载 | - |
| SAP 全局传输目录 | 是 | SMB 和 NFS |
| SAP sapmnt | 适用 | 所有系统 SMB（仅适用于 Windows）或 NFS（仅适用于 Linux） |
| 备份存储 | 适用 | - |
| 共享/共享磁盘 | 是 | SMB 3.0、NFS v4.1 |
| 复原 | LRS 和 ZRS | Azure 高级文件没有可用的 GRS |
| 延迟 | low | - |
| IOPS SLA | 是 | - |
| IOPS 根据容量线性变化 | 严格线性 | - |
| 吞吐量 SLA | 是 | - |
| 吞吐量根据容量线性变化 | 严格线性 | - |
| HANA 认证 | 否 | - |
| 可以使用磁盘快照 | 否 | - |
| 可以使用 Azure 备份 VM 快照 | 否 | - |
| 成本 | low | - |
摘要：Azure 高级文件是一种低延迟存储，允许部署 NFS 和 SMB 卷或共享。 Azure 高级文件为 SAP 应用程序层共享提供了出色的性价比。 它还为这些共享提供同步区域复制。 到目前为止，我们不支持 SAP DBMS 工作负载的这种存储类型。 虽然它可以用于 /hana/shared 卷。
Azure 标准 SSD 存储
与 Azure 标准 HDD 存储相比，Azure 标准 SSD 存储提供更高的可用性、一致性、可靠性和更低的延迟。 它已针对需要在较低 IOPS 级别保持一致性能的工作负载进行优化。 此存储是 IOPS 和吞吐量需求较低的非生产 SAP 系统使用的最低配存储。 下面是 SAP 工作负载的功能矩阵：
| 功能 | 注释 | 备注/链接 |
|---|---|---|
| OS 基本 VHD | 受限适用 | 非生产系统 |
| 数据磁盘 | 受限适用 | IOPS 和延迟需求较低的某些非生产系统 |
| SAP 全局传输目录 | 否 | 不支持 |
| SAP sapmnt | 受限适用 | 非生产系统 |
| 备份存储 | 适用 | - |
| 共享/共享磁盘 | 不可用 | 需要第三方组件 |
| 复原能力 | LRS、GRS | 不为磁盘提供 ZRS |
| 延迟 | high | 对于 SAP 全局传输目录或生产系统过高 |
| IOPS SLA | 否 | - |
| 每个磁盘的最大 IOPS | 500 | 与磁盘大小无关 |
| 吞吐量 SLA | 否 | - |
| HANA 认证 | 否 | - |
| 可以使用磁盘快照 | 是 | - |
| 可以使用 Azure 备份 VM 快照 | 是 | - |
| 成本 | LOW | - |
摘要：对于非生产 VM 的基本 VHD，以及对延迟相对不敏感和/或 IOPS 和吞吐率较低的最终 DBMS 部署，建议的最低配置是 Azure 标准 SSD 存储。 此 Azure 存储类型不受支持，不再用于托管 SAP 全局传输目录。
Azure 标准 HDD 存储
在 2014 年当 Azure 基础结构经认证适用于 SAP NetWeaver 工作负载时，Azure 标准 HDD 存储是唯一的存储类型。 在 2014 年，Azure 虚拟机都比较小，而且存储吞吐量较低。 因此，此存储类型刚好能够满足需求。 该存储非常适合对延迟不敏感的工作负载，而在 SAP 空间中很难遇到这种工作负载。 随着 Azure VM 吞吐量以及这些 VM 生成的工作负载不断增长，我们不再认为此存储类型适合在 SAP 方案中使用。 下面是 SAP 工作负载的功能矩阵：
| 功能 | 注释 | 备注/链接 |
|---|---|---|
| OS 基本 VHD | 不适用 | - |
| 数据磁盘 | 不适用 | - |
| SAP 全局传输目录 | 否 | 不支持 |
| SAP sapmnt | 是 | 不支持 |
| 备份存储 | 适用 | - |
| 共享/共享磁盘 | 不可用 | 需要 Azure 文件存储或第三方存储 |
| 复原能力 | LRS、GRS | 不为磁盘提供 ZRS |
| 延迟 | high | 对于使用 DBMS 的方案、SAP 全局传输目录或 sapmnt/saploc 过高 |
| IOPS SLA | 否 | - |
| 每个磁盘的最大 IOPS | 500 | 与磁盘大小无关 |
| 吞吐量 SLA | 否 | - |
| HANA 认证 | 否 | - |
| 可以使用磁盘快照 | 是 | - |
| 可以使用 Azure 备份 VM 快照 | 是 | - |
| 成本 | 低 | - |
摘要：标准 HDD 是只能用于存储 SAP 备份的 Azure 存储类型。 仅应将其用作相当不活跃的系统（例如用于在此处查找数据的停用系统）的基本 VHD。 但是，活动的开发、QA 或生产 VM 不应基于该存储， 数据库文件也不应在该存储上托管
存储流量中的 Azure VM 限制
与本地方案相反，所选的单个 VM 类型在可以实现的存储带宽方面发挥着重要作用。 对于不同的存储类型，需要考虑：
| 存储类型 | Linux | Windows | 注释 |
|---|---|---|---|
| 标准 HDD | Azure 中 Linux VM 的大小 | Azure 中 Windows VM 的大小 | 可能很难改变中大型 VM 的存储限制 |
| 标准 SSD | Azure 中 Linux VM 的大小 | Azure 中 Windows VM 的大小 | 可能很难改变中大型 VM 的存储限制 |
| 高级存储 | Azure 中 Linux VM 的大小 | Azure 中 Windows VM 的大小 | 很容易达到存储配置中的 IOPS 或存储吞吐量 VM 限制 |
| 高级 SSD v2 | Azure 中 Linux VM 的大小 | Azure 中 Windows VM 的大小 | 很容易达到存储配置中的 IOPS 或存储吞吐量 VM 限制 |
| 超级磁盘存储 | Azure 中 Linux VM 的大小 | Azure 中 Windows VM 的大小 | 很容易达到存储配置中的 IOPS 或存储吞吐量 VM 限制 |
| Azure NetApp 文件 | Azure 中 Linux VM 的大小 | Azure 中 Windows VM 的大小 | 存储流量使用的是网络吞吐量带宽，而不是存储带宽！ |
| Azure 高级文件 | Azure 中 Linux VM 的大小 | Azure 中 Windows VM 的大小 | 存储流量使用的是网络吞吐量带宽，而不是存储带宽！ |
在限制方面，你需要注意：
- VM 越小，可以附加的磁盘就越少。 此限制不适用于 ANF。 由于装载了 NFS 或 SMB 共享，因此你不会遇到要附加的共享卷数的限制
- VM 具有 I/O 吞吐量和 IOPS 方面的限制，高级存储磁盘和超级磁盘很容易超出该限制
- 对于 ANF 和 Azure 高级文件，流到共享卷的流量将使用 VM 的网络带宽（而不是存储带宽）
- 对于两位数 TiB 容量空间中的大型 NFS 卷，基于 Linux 对与共享卷交互的单个会话的限制，从单个 VM 中访问此类卷的吞吐量将趋于平稳。
在 SAP 系统的生命周期中增大 Azure VM 的大小时，应评估新的和更大 VM 类型的 IOPS 和存储吞吐量限制。 在某些情况下，根据 Azure VM 的新功能调整存储配置也很合理。
条带化或不条带化
通过将包含多个 Azure 磁盘的条带集创建为一个更大的卷，可以将各磁盘的 IOPS 和吞吐量累积到一个卷中。 它仅用于 Azure 标准存储和 Azure 高级存储。 Azure 超级磁盘无需使用条带集，因为你可以在其中不受磁盘容量的影响配置吞吐量和 IOPS。 基于 NFS 或 SMB 的共享卷无法条带化。 由于 Azure 高级存储吞吐量和 IOPS 具有非线性特性，因此你可以使用相同的 IOPS 和吞吐量来预配比大型单个 Azure 高级存储磁盘更小的容量。 这就是使用 Azure 高级存储以更低成本实现更高吞吐量或 IOPS 的方法。 例如，跨两个 P15 高级存储磁盘进行条带化可提供：
- 250 MiB/秒的吞吐量。此类卷将具有 512 GiB 的容量。 如果要使用单个磁盘来提供每秒 250 MiB 的吞吐量，则需要选择具有 2 TiB 容量的 P40 磁盘。
- 400 MiB/秒的吞吐量，这是通过条带化四个 P10 高级存储磁盘（条带化后总容量为 512 GiB）实现的。 如果要使单个磁盘的每秒最低吞吐量为 500 MiB，则需要选择具有 8 TiB 容量的 P60 高级存储磁盘。 由于高级存储的成本与容量几乎成线性关系，可以使用条带化来节省成本。
条带化时需要遵循一些规则：
- 不应使用在 VM 中配置的存储，因为 Azure 存储已经使数据保持冗余
- 应用条带集的磁盘必须具有相同的大小
- 使用高级 SSD v2 和超级磁盘时，容量、预配的 IOPS 和预配吞吐量需要相同
跨多个较小的磁盘进行条带化是使用 Azure 高级存储实现良好性价比的最佳方法。 据了解，条带化可能会产生一些额外的部署和管理开销。
有关具体的条带大小建议，请参阅不同 DBMS 的文档，例如 SAP HANA Azure 虚拟机存储配置。
后续步骤
阅读以下文章：