你当前正在访问 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 中运行的软件使用,要么用于构建高可用性故障转移群集方案
- EDI(电子数据交换)流程或类似流程的 /sapmnt目录或通用文件共享。 这些共享内容要么由在多个 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 系列 | 不支持 | 不支持 | 建议 | 建议 | 建议 | 建议 | 不支持 |
DBMS 日志卷 SAP HANA M/Mv2 VM 系列 | 不支持 | 不支持 | 建议1 | 建议 | 建议 | 建议 | 不支持 |
DBMS 数据卷 SAP HANA Esv3/Edsv4 VM 系列 | 不支持 | 不支持 | 建议 | 建议 | 建议 | 建议 | 不支持 |
DBMS 日志卷 SAP HANA Esv3/Edsv4 VM 系列 | 不支持 | 不支持 | 不支持 | 建议 | 建议 | 建议 | 不支持 |
HANA 共享卷 | 不支持 | 不支持 | 建议 | 建议 | 建议 | 建议 | 建议 |
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 写入加速器
下面列出了不同存储类型的预期特征:
使用方案 | 标准 HDD | 标准 SSD | 高级存储 | 高级 SSD v2 | 超级磁盘 | Azure NetApp 文件 | Azure 高级文件 |
---|---|---|---|---|---|---|---|
吞吐量/IOPS SLA | 否 | No | 是 | 是 | 是 | 是 | 是 |
延迟读取 | 高 | 中到高 | 低 | submillisecond | submillisecond | submillisecond | low |
延迟写入 | 高 | 中到高 | 低(亚毫秒1) | submillisecond | submillisecond | submillisecond | low |
HANA 支持 | 否 | 否 | 是1 | 是 | 是 | 是 | 否 |
可以使用磁盘快照 | 是 | 是 | 是 | 是3 | 否2 | 是 | 否 |
使用可用性集时在不同存储群集上分配磁盘 | 通过托管磁盘 | 通过托管磁盘 | 通过托管磁盘 | 磁盘类型在通过可用性集部署的 VM 上不受支持 | 磁盘类型在通过可用性集部署的 VM 上不受支持 | 否3 | 否 |
适应可用性区域 | 是 | 是 | 是 | 是 | 是 | 为公共预览版 | 否 |
同步区域冗余 | 不适用于托管磁盘 | 不适用于托管磁盘 | 不支持 DBMS | 否 | No | No | 是 |
异步区域冗余 | 不适用于托管磁盘 | 不适用于托管磁盘 | 不支持 DBMS | 否 | 否 | 预览模式 | 否 |
异地冗余 | 不适用于托管磁盘 | 不适用于托管磁盘 | 否 | No | 否 | 可能 | 否 |
1 对 M/Mv2 VM 系列的日志/重做日志卷使用 Azure 写入加速器
2 创建不同的 Azure NetApp 文件容量池并不保证容量池部署到不同的存储单元
3 高级 SSD v2 或超级磁盘的(增量)快照在创建后不能立即使用。 必须先完成后台复制,然后才能从快照创建磁盘
重要
请查看本文档的“Azure NetApp 文件”部分,查找有关要求延迟小于 1 毫秒时 NFS 卷和 VM 的邻近放置的具体信息。
Azure 高级存储
现已推出 Azure 高级 SSD 存储,此类存储旨在提供:
- 低 I/O 延迟
- IOPS 和吞吐量的 SLA
- 更小的 I/O 延迟变化性
这种类型的存储针对 DBMS 工作负载、需要低个位数毫秒延迟的存储流量以及 IOPS 和吞吐量方面的 SLA。 Azure 高级存储的成本基础不是存储在此类磁盘中的实际数据量,而是此类磁盘的大小类别,与存储在磁盘中的数据量无关。 还可在高级存储中创建不直接映射到高级 SSD 一文中所示大小类别的磁盘。 此文中的结论如下:
- 存储按范围组织的。 例如,513 GiB 到 1,024 GiB 容量范围内的磁盘的功能和每月成本相同
- 每 GiB 的 IOPS 在各种大小类别中不是呈线性趋势。 低于 32 GiB 的较小磁盘的每 GiB IOPS 速率较高。 对于超过 32 GiB 到 1,024 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 不会对价格产生重大影响。 不过,我们还是让你来决定 Premium 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 写入加速器支持 | 否 | - |
磁盘突发 | 否 | - |
可以使用磁盘快照 | 是1 | - |
可以使用 Azure 备份 VM 快照 | 是 | - |
成本 | 中 | - |
1 高级 SSD v2 或超级磁盘的(增量)快照在创建后不能立即使用。 必须先完成后台复制,然后才能从快照创建磁盘
与 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 写入加速器支持 | 否 | - |
磁盘突发 | 是 | - |
可以使用磁盘快照 | 是1 | - |
可以使用 Azure 备份 VM 快照 | 是 | - |
成本 | 高于高级存储 | - |
1 高级 SSD v2 或超级磁盘的(增量)快照在创建后不能立即使用。 必须先完成后台复制,然后才能从快照创建磁盘
摘要:Azure 超级磁盘是适合各种 SAP 工作负载的亚毫秒级低延迟存储。 到目前为止,超级磁盘只能与通过可用性区域(区域部署)部署的 VM 结合使用。 与所有其他存储不同,超级磁盘不能用作基本 VHD 磁盘。 超级磁盘非常适合 I/O 工作负载极不稳定且你想让已部署的存储吞吐量或 IOPS 适应存储工作负载模式(而不是调整大小以最大程度地利用带宽和 IOPS)的情况。
Azure NetApp 文件
Azure NetApp 文件是 Azure 本机第一方企业级高性能文件存储服务,已获得认证可用于 SAP HANA。 它提供卷即服务,你为其创建 NetApp 帐户、容量池和卷。 使用 Azure NetApp 文件,你可以选择服务和性能级别并管理数据保护,以使用已经熟悉的以及在本地依赖的相同协议和工具创建和管理高性能、高度可用且可缩放的文件共享。
Azure NetApp 文件卷支持以下类型的 SAP 工作负荷:
- SAP DBMS 工作负荷
- SAPMNT 共享
- 全局传输目录
Azure NetApp 文件有三个服务级别,每个级别都有自己的吞吐量和定价规范。 哪一个适合部署取决于部署的大小。 Azure NetApp 文件 TCO 估算器上的 SAP 中提供了自定义大小调整建议。
有关服务级别的信息,请参阅 Azure NetApp 文件的服务级别。
部署卷
为获得最佳结果,请使用适用于 SAP HANA 的应用程序卷组来部署卷。 应用程序卷组使用相关性和反相关性规则将卷放置在 Azure 基础结构中的最佳位置,以减少争用并实现最佳吞吐量和最低延迟。
注意
容量池是 Azure NetApp 文件的基本预配单元。 容量池的大小从 1 TiB 开始;可以以 1 TiB 的增量扩展容量池。 容量池是卷的父单元。 有关大小调整信息,请参阅 Azure NetApp 文件资源限制。 有关定价,请参阅 Azure NetApp 文件定价。
有多种 SAP 工作负荷方案支持 Azure NetApp 文件:
- SAP HANA 部署,为 /hana/data 和 /hana/log 卷以及 /hana/shared 卷使用 NFS 共享,如 SAP HANA Azure 虚拟机存储配置所述
- 为 SAP 的全局传输目录提供 SMB 或 NFS 共享
- 高可用性方案中的共享 sapmnt,如以下文档中所述:
- 基于 Suse 或 Red Hat Linux 的 Azure VM 中的 IBM Db2
- 为 Oracle 数据和重做日志卷使用 dNFS 的 Oracle Linux 来宾 OS 中的 SAP on Oracle 部署。 有关更多详细信息,请参阅适用于 SAP 工作负载的 Azure 虚拟机 Oracle DBMS 部署一文
- Suse 或 Red Hat Linux 来宾 OS 中的 SAP on ASE
- Suse 或 Red Hat Linux 来宾 OS 中的 AP on MAXDB
- 使用 SMB 卷的 SAP on Microsoft SQL Server
注意
对于 Linux 上的 DBMS 工作负荷,请使用 Azure NetApp 文件上的基于 NFS 的卷。
将吞吐量与卷大小分离
数据库应用程序的存储通常具有不随卷大小线性缩放的吞吐量要求,即日志卷的大小相对较小,但需要高级别的吞吐量。
借助 Azure NetApp 文件,在使用类型为手动 QoS 的容量池时,你可以独立于卷大小分配卷吞吐量。
下面是一个示例:
- 数据库文件的卷需要 500 MiB/秒的吞吐量和 39 TiB 的容量
- 日志文件的卷需要 2000 MiB/秒的吞吐量和 1 TiB 的容量
可以为此方案创建手动 QoS 容量池,并独立于卷大小分配吞吐量。 所需的总容量为 40 TiB,总吞吐量预算为 2500 MiB/秒。 高级服务级别(每个分配的 TiB 有 64 MiB/秒的吞吐量)中的容量池同时满足性能和容量要求(40 MiB * 64 MiB/秒/TiB = 2560 MiB)。
线性性能缩放需要大量过度预配日志卷才能达到吞吐量要求。 为了实现日志卷 2000 MiB/秒的吞吐量,需要在超级层(每个分配的 TiB 有 128 MiB/秒的吞吐量)中部署 16 TiB 的容量池,导致过度预配,因此导致 15 TiB 的容量被浪费。
使用 Azure NetApp 文件性能计算器获取你的方案的估计值。
下面是 Azure NetApp 文件上的 SAP 工作负荷的功能矩阵:
功能 | 注释 | 备注/链接 |
---|---|---|
OS 基本 VHD | 使用托管磁盘 | - |
数据磁盘 | 适用 | SAP HANA、Oracle Linux 上的 Oracle、SLES/RHEL 上的 Db2 和 SAP ASE、MAXDB、SQL Server |
SAP 全局传输目录 | 是 | SMB(仅限 Windows)和 NFS(仅限 Linux) |
SAP sapmnt | 适用 | SMB(仅限 Windows)或 NFS(仅限 Linux) |
备份存储 | 适用 | 使用快照和/或 Azure NetApp 文件备份;HANA 的日志备份也可以用作基于文件的备份目标 |
共享/共享磁盘 | 是 | SMB、NFS |
复原 | LRS 和 GRS | 具有跨区域复制功能的 GRS;具有跨区域复制功能的 ZRS |
延迟 | 极低 | 通常不到 1 毫秒 |
IOPS SLA | 是 | - |
IOPS 根据容量线性变化 | 采用自动 QoS 的线性缩放;可以使用手动 QoS 独立配置 | 有 3 个服务级别可用 |
吞吐量 SLA | 是 | Azure NetApp 文件 TCO 估算器上的 SAP 中提供了大小调整建议 |
吞吐量根据容量线性变化 | 采用自动 QoS 的线性缩放;可以使用手动 QoS 独立配置 | 有 3 个服务级别可用 |
HANA 认证 | 是 | - |
可以使用磁盘快照 | 是 | 请参阅 Azure NetApp 文件快照的工作原理 |
应用程序一致性快照和备份编排 | 否 | 使用 AzAcSnap 或 SnapCenter |
成本 | 使用 TCO 估算工具 | 使用 Azure NetApp 文件 TCO 估算器上的 SAP 并输入布局的大小 |
Azure NetApp 文件存储的其他内置功能:
- 能够使用 AzAcSnap 执行应用程序一致性卷快照
- 为了测试和开发从快照克隆 Azure NetApp 文件卷
- 从快照还原卷(快照还原),以便从损坏和错误中快速还原
重要
特别是对于数据库部署,你希望至少为重做日志实现低延迟。 特别是对于 SAP HANA,SAP 对较小容量的 HANA 重做日志写入的延迟要求小于 1 毫秒。 若要了解此类延迟,请参阅以下可能性。
重要
部署 Azure NetApp 文件卷时,请记下虚拟机所在的或将要部署到的区域。 确保选择相同的区域。 有关此功能的信息,请参阅管理 Azure NetApp 文件的可用性区域卷放置一文。 SAP HANA 的应用程序卷组使用相同的功能将卷部署到尽可能靠近应用程序 VM 的位置。
采用这种可用性区域对齐的动机是,通过将 NFS 共享置于应用程序 VM 所在的可用性区域来减少风险面。
- 使用适用于 SAP HANA 的应用程序卷组为 SAP HANA 部署部署 Azure NetApp 文件卷。 应用程序卷组的优点是数据卷部署在多个存储终结点上,从而减少网络争用并提高性能。
摘要:Azure NetApp 文件是经认证的 SAP HANA 低延迟存储解决方案。 该服务提供从一个或多个容量池中划分出来的卷。 容量池有三个服务级别,定义了分配的总容量和吞吐量。 可以调整卷大小,并且可以调整分配的吞吐量而无需中断服务,以便满足不断变化的需求并控制成本。 该服务提供将卷复制到其他地区或区域以实现灾难恢复和业务连续性的功能。
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 共享
- 用作 SAP 系统和 EDI 进程的接口的共享
- 高可用性方案中的共享 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 文件共享缩放目标章节。
注意
由于 Azure 高级文件的分层架构,访问存储在共享中的文件的元数据时延迟明显高于 Azure NetApp 文件。 这种更高的延迟可能会影响文件的大规模创建和删除。 但它还会明显影响列出包含数十万个文件的大型目录的内容所需的时间。 出现这种更高的元数据延迟影响的主要用例是作为接口共享使用,在这种用例中,客户每天可能会遇到数十万甚至数百万的文件创建和大规模删除。 因此,你应该频繁地测试接口共享场景。 若要确定你的工作负载是否为元数据繁重的,请查看元数据或命名空间繁重的工作负载
下面是 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 快照 | 是 | - |
成本 | 低 | - |
摘要:对于非生产 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 越小,可以附加的磁盘就越少。 此限制不适用于 Azure NetApp 文件。 由于装载了 NFS 或 SMB 共享,因此你不会遇到要附加的共享卷数的限制
- VM 具有 I/O 吞吐量和 IOPS 方面的限制,高级存储磁盘和超级磁盘很容易超出该限制
- 对于 Azure NetApp 文件和 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 存储已在 Azure 存储后端保持数据磁盘冗余
- 应用条带集的磁盘必须具有相同的大小
- 使用高级 SSD v2 和超级磁盘时,容量、预配的 IOPS 和预配吞吐量需要相同
跨多个较小的磁盘进行条带化是使用 Azure 高级存储实现良好性价比的最佳方法。 据了解,条带化可能会产生一些额外的部署和管理开销。
有关具体的条带大小建议,请参阅不同 DBMS 的文档,例如 SAP HANA Azure 虚拟机存储配置。
后续步骤
阅读以下文章: