计算 SAP HANA 的 EBS 存储需求 - SAP HANA 开启 Amazon
概览适用于 SAP HANA 的新亚马逊 EBS 存储指南使用 SAP HANA 硬件和云测量工具进行测试EBS 存储卷配置
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

计算 SAP HANA 的 EBS 存储需求

概览

本指南为在亚马逊上运行的 SAP HANA 工作负载提供了存储配置建议 EC2。了解如何配置 Amazon EBS 卷以满足 SAP 的存储关键性能指标 (KPIs)。

SAP HANA 主要在内存中存储和处理数据，并通过将数据保存到永久存储位置来防止数据丢失。为了实现最佳性能，用于 SAP HANA 数据和日志卷的存储解决方案应满足 SAP 的存储 KPI 要求。 Amazon 已与 SAP 合作认证了适用于 SAP HANA 工作负载的亚马逊 EBS 通用固态硬盘（gp2 和 gp3）和预配置 IOPS 固态硬盘（io1、io2 Block Express）存储解决方案。

适用于 SAP HANA 的新亚马逊 EBS 存储指南

本文档介绍了一种基于内存的存储大小调整公式方法，取代了之前针对特定实例的建议。这一变化使客户能够更好地了解存储配置逻辑，更好地控制性能优化决策。

新指南侧重于将 gp3 和 io2 Block Express 卷作为所有新部署的当前标准建议。虽然现有部署仍然支持 gp2 和 io1 卷，但由于其性能和成本效益可预测，我们建议将 gp3 用于新的实现，而 io2 Block Express 是需要额外性能的系统的升级途径。

注意

如果您的 SAP HANA 系统是按照之前的指南（包括使用 Launch Wizard）部署的，则无需更改配置。基于先前建议的现有配置继续满足必要的要求。

使用 SAP HANA 硬件和云测量工具进行测试

Amazon 已确保存储配置指南符合运行 SAP HANA 的关键性能指标 (KPIs)。但是，对于具有高性能要求或与标准建议不同的工作负载，我们强烈建议您使用 SAP HANA 硬件和云测量工具验证存储配置的性能。

请参阅：

EBS 存储卷配置

本节提供计算 SAP HANA 存储需求的公式和方法。计算要考虑内存大小和工作负载特性，以确定适当的卷大小和性能配置。根据您的具体工作负载要求和增长预测调整这些基准建议。

SAP HANA EBS 存储参考有关根据可用内存计算出的需求，请参阅。

重要

某些 EC2 实例类型可能包括实例存储，这种存储是临时性的，不得用于 SAP HANA 文件。配置 Amazon EBS 卷以满足所有 SAP HANA 存储要求。

根和 SAP 二进制卷

根卷包含操作系统文件、配置和日志。规模建议适用于大多数 SAP HANA 部署和规模，但可能因您的 AMI 策略和非 SAP 软件要求而异。考虑在高使用率环境中为/tmp文件系统使用单独的卷。

SAP 二进制文件卷 (default /usr/sap/<SID>/) 包含常见的 SAP 可执行文件和二进制文件。

存储类型

使用 gp3 卷作为根存储。基准性能特征符合操作系统的要求。

尺寸计算 

root_and_sap_volume_size = 50 GiB

IOPS 公式 

root_and_sap_iops_target = 3000 (fixed)

吞吐量公式 

root_and_sap_throughput_target = 125 MB/s (fixed)
示例

任何内存系统根卷：

  • 大小 = 50 GiB

  • IOPS = 3000

  • 吞吐量 = 125 MB/s

HANA 数据量

存储\ DATA 文件系统（默认/hana/data）存储 SAP HANA 内存中数据库的永久副本。虽然 SAP HANA 使用内存中的数据运行，但此容量可通过常规保存点确保数据的持久性。存储必须处理混合工作负载模式，包括正常操作期间的随机读取和写入以及保存点期间的顺序模式，同时保持持续的低延迟才能保持数据库性能。

尺寸计算

数据卷大小要求来自系统内存大小。虽然实际存储需求取决于您的具体工作负载、压缩率和增长预测，但请使用以下计算作为基准。要进行精确计算，请查阅 SAP 规模调整工具。

data_volume_size = MROUND(memory_size * 1.2, 100)

Where:
- Size factor = 1.2
- Rounding factor = 100
注意

虽然SAP已将其规模系数建议从1.2更新为1.5以适应业务需求，但 Amazon 仍将1.2系数作为初始部署的基准。这是一种经济实惠的方法，它利用 EBS 卷的动态扩展功能，允许您随着需求的增长在线扩展存储容量。当需要更多空间时，您可以轻松地增加卷大小，而无需中断服务。

存储类型选择

  • 使用带有自定义 IOPS/throughput 音量限制的 gp3

  • 当需要稳定的亚毫秒延迟时，可以考虑 io2 Block Express

  • 对于基于 Xen 的实例，请使用 gp2（条带化）或 io2 Block Express，因为 gp3 可能不符合日志写入的 SAP HANA 存储延迟 KPI。

IOPS 公式 

data_iops_target = MROUND(7200 + (0.45 * memory_size), 100)

Where:
- Base IOPS = 7200
- IOPS factor = 0.45 per GiB of memory
- Rounding factor = 100

  • 大型实例可能需要多个卷才能实现指定的 data_iops_target。请参阅下面的条带化指南。

  • 满足 SAP HANA KPIs 数据要求的最低 IOPS 为 7000。

吞吐量公式 

data_throughput_target = MIN(MROUND(450 + (0.2 * memory_size), 125), 2000)

Where:
- Base throughput = 450 MB/s
- Throughput factor = 0.2 MB/s per GiB of memory
- Maximum throughput = 2000 MB/s (see exception)
- Rounding factor = 125

  • 对于使用 gp3 卷的大型实例，单个卷可能无法达到要求。data_throughput_target有关使用多个卷的更多信息，请参阅何时对卷进行条带化。

  • 在我们的公式MB/s. The base throughput value of 450 MB/s中，SAP 对 HANA 数据量的最低吞吐量要求为 400，这可确保这个 SAP KPI 得到额外的预留空间以实现最佳性能。

  • 每种实例类型都有自己的 Amazon EBS 最大吞吐量。有关详细信息，请参阅文档中的 Amazon EBS 优化实例。 Amazon

  • 例外：对于 32 TB 及更大的实例（当前实例类型 u7inh-32tb.480xlarge），我们建议预置 4000 或更高的吞吐量。 MB/s 对于所有其他实例大小，如果您需要超过 2000 MB/s 的吞吐量，则可以相应地调整公式中的最大吞吐量值。

音量条带化

当您需要满足特定的技术限制、性能要求或操作要求时，可实施音量分条。有关何时何时对卷进行条带化适合进行条带化的详细指导，请参阅。

对于 gp3 卷，吞吐量通常是您将遇到的第一个限制。对于 io2 Block Express 卷，吞吐量按照 IOPS × I/O 大小计算。SAP HANA 工作负载通常使用 256 KiB 的 I/O 操作——在这个规模下，一个 io2 Block Express 卷可以在 16,000 IOPS 下实现 4,000 个 MB/s 吞吐量。鉴于这些功能，io2 Block Express 上的大多数 HANA 部署都不需要进行卷条带化。如果需要更高的吞吐量，则可以相应地调整预配置 IOPS。

如果对数据卷实施条带化，请使用 256 KB 的条带大小来优化数据操作。

示例

512 GiB 内存系统 HANA 数据量：

  • 存储类型选择 = GP3

  • 大小 = MROUND ((512 GiB * 1.2) 100) = 600 GiB

  • IOPS = MROUND (7,200 + (0.45 * 512)，100) = 7,460 IOPS

  • 吞吐量 = 最小（MROUND（450 +（0.2 * 512）、125）、2,000）= 500 MB/s

  • 条带化 = 不需要。

4 TiB 内存系统 HANA 数据量：

  • 存储类型选择 = GP3

  • 大小 = MROUND (4,096 GiB * 1.2) 100) = 4,900 GiB

  • IOPS = MROUND（7,200 +（0.45 * 4096），100）= 9,000 IOPS

  • 吞吐量 = 最小（MROUND（450 +（0.2 * 4,096），125），2000）= 1250 MB/s

  • 条带化 = 吞吐量所必需的。考虑一下 2 x 2,450 GiB 文件系统、4500 IOPS、625 吞吐量 MB/s

HANA 日志量

Storage\ LOG 文件系统（默认/hana/log）存储重做日志文件，以确保数据的持久性和一致性。该文件系统使用高频、小量、顺序写入来处理写入密集型工作负载。由于写入日志会直接影响数据库的响应时间和事务性能，因此存储卷需要稳定的亚毫秒级延迟。

尺寸计算

日志卷大小要求源自系统内存大小。可以根据事务量和日志备份频率进行修改。

log_volume_size = MROUND((memory_size * 0.5),100)

Where:
- Minimum Size = 50 GiB
- Maximum Size = 500 GiB
- Rounding factor = 100
存储类型选择

  • 使用带有自定义 IOPS/throughput 音量限制的 gp3

  • 当需要稳定的亚毫秒延迟时，可以考虑 io2 Block Express

  • 对于基于 Xen 的实例，请使用 gp2（条带化）或 io2 Block Express，因为 gp3 可能不符合日志写入的 SAP HANA 存储延迟 KPI。

IOPS 公式 

log_iops_target = 3000

Where:
- Base IOPS = 3000

  • 满足 SAP HANA KPIs 数据要求的最低 IOPS 为 3000。

吞吐量公式 

log_throughput_target = MIN(MROUND(300 + (0.015 * memory_size), 300), 500)

Where:
- Base throughput = 300 MB/s
- Throughput factor = 0.015 MB/s per GiB of memory
- Maximum throughput = 500 MB/s
- Rounding factor = 300

  • SAP 对 HANA 日志卷的最低吞吐量要求为 250MB/s. The base throughput value of 300 MB/s，我们公式中的四舍五入系数可确保随着大小的变化，该值保持不变，并且 SAP KPI 有额外的余量来实现最佳性能。

音量条带化

对于日志卷，使用 gp3 或 io2 Block Express 卷log_throughput_target时，通常不需要进行条带化即可实现。单个卷通常为日志操作提供足够的性能。

如果对日志卷实施条带化，请使用 64 KB 的条带大小来优化日志操作中典型的顺序写入模式。请参阅何时对卷进行条带化本节以了解为了实现吞吐量、IOPS 或性能目标而需要进行条带化处理的地方。

示例

512 GiB 内存系统 HANA 日志量：

  • 存储类型选择 = GP3

  • 大小 = MROUND512 GiB * 0.5) ,100 = 300 GiB（最大 500 GiB 以内）

  • IOPS = 3000

  • 吞吐量 = 最小（MROUND（300 +（0.015 * 512）、300）、500）= 300 MB/s

  • 条带化 = 不需要。

HANA 共享卷

HANA 共享文件系统（默认/hana/shared）包含 SAP HANA 安装文件、跟踪文件和共享配置文件。

注意

在横向扩展部署中，所有节点都必须可以访问此文件系统。

尺寸计算

对于单节点部署：

shared_volume_size = MIN(memory_size, 1024)

Where:
- memory_size is system memory in GiB
- 1024 represents 1 TiB maximum

对于横向扩展部署：

对于横向扩展 SAP HANA 系统，/hana/shared 文件系统需要的磁盘空间等于部署中每四个工作节点的一个工作节点的内存。

shared_volume_size = worker_node_memory * CEILING(number_of_worker_nodes/4)

Where:
- worker_node_memory is the memory size of a single worker node in GiB
- number_of_worker_nodes is the total number of worker nodes
- CEILING rounds up to the nearest whole number

横向扩展部署示例

工作节点内存

节点数

计算

所需尺寸

2 TiB

1-4 个节点

2048 * 1

2 TiB

2 TiB

5-8 个节点

2048 * 2

4 TiB

2 TiB

9-11 个节点

2048 * 3

6 TiB

2 TiB

12-15 个节点

2048 * 4

8 TiB
存储类型选择

  • GP3 为纵向扩展部署提供了所需的性能特征

  • Amazon EFS 是横向扩展和横向扩展部署的可行选择，它提供了具有所需性能特征的所有节点之间的共享访问权限。有关横向扩展配置，请参阅配置存储 (EFS)

IOPS 公式 

shared_iops_target = 3000

Where:
- Base IOPS = 3000 (fixed)

吞吐量公式 

shared_throughput_target = 125

Where:
- Base throughput = 125 MB/s (fixed)
示例

512 GiB 内存系统 HANA 共享卷：

  • 大小 = 512 GiB

  • IOPS = 3000

  • 吞吐量 = 125 MB/s

HANA Backup 卷（可选）

/backup文件系统为基于 SAP HANA 文件的备份（包括数据和日志备份）提供本地存储。虽然本地文件系统备份可能对非关键系统有用，也可以作为辅助备份选项，但它们在生产环境中却带来了几个难题：

  • 要将备份移至诸如 Amazon S3 之类的持久存储，还需要执行额外的同步步骤

  • 如果磁盘或硬件出现故障，恢复点目标可能会受到影响

  • 需要通过内部管理和监控来仔细管理本地存储容量

  • 在横向扩展中，卷需要可在所有节点上访问

重要

Amazon 建议使用 Amazon Backup for SAP HANA 或 Amazon Backint Agent 来代替基于文件的备份。这些解决方案提供对持久存储的直接备份，并简化了备份管理。

尺寸计算

备份卷的大小在很大程度上取决于系统的使用情况。应将以下内容用作初始基准，但在部署后根据备份大小、变更量、本地副本的保留情况和应急情况进行调整。

backup_volume_size = memory_size * 3

Where:
- memory_size is system memory in GiB
存储类型选择

  • 对于单节点部署，我们建议使用适用于 SAP HANA 的 Amazon EBS 吞吐量优化型 HDD (st1) 卷来执行基于文件的备份。此卷类型提供专门用于大型顺序工作负载的低成本磁性存储。SAP HANA 使用 I/O 带有大块的顺序备份数据库，因此 st1 卷为这种情况提供了低成本、高性能的选项。要了解有关 st1 卷的更多信息，请参阅 Amazon EBS 卷类型。

  • 对于多节点部署，我们建议使用适用于 SAP HANA 的 Amazon EFS 来执行基于文件的备份。它可以支持超过 10 个 IOPS GB/sec 和超过 500,000 个 IOPS 的性能。

IOPS 公式 

backup_iops_target = n/a
注意

ST1 基准为 500 IOPs ，但这是不可配置的。Backup 操作通常更多地依赖吞吐量，而不是 IOPS 性能。

吞吐量公式

对于 ST1 卷，使用此公式作为起点来确定备份吞吐量所需的卷数。根据您的实际备份窗口要求和性能监控数据调整最终卷数。

backup_volumes_for_throughput = CEILING(memory_size/6000) * 500

Where:
- memory_size is system memory in GiB
- 6000 represents the GiB threshold for striping
- 500 is maximum throughput MB/s per st1 volume
- Result indicates number of volumes needed for throughput

横向扩展部署示例

工作节点内存

卷

吞吐量

4 TiB

1

500 Mb/s

12 TiB

2

1000 Mb/s

24TiB

4

2000 Mb/s

何时对卷进行条带化

Linux 逻辑卷管理 (LVM) 条带化可将数据分发到多个 EBS 卷以提高性能。 I/O 条带卷充当单个逻辑卷，读取和写入分布在条带集中的所有卷上。

在以下场景中实现存储卷条带化：

技术限制

  • 吞吐量要求超过单个卷的最大值（gp3 为 1,000 MB/s ，io2 Block Express MB/s 为 4,000）。

    • 对于 io2 Block Express 卷，吞吐量按照 IOPS × I/O 大小计算。SAP HANA 工作负载通常使用 256 KiB 的 I/O 操作——在这个规模下，一个 io2 Block Express 卷可以在 16,000 IOPS 下实现 4,000 个 MB/s 吞吐量。鉴于这些功能，io2 Block Express 上的大多数 HANA 部署都不需要进行卷条带化。如果需要更高的吞吐量，则可以相应地调整预配置 IOPS。

  • IOPS 要求超过单个卷的最大值（gp3 为 16,000，io2 Block Express 为 25.6,000）

  • 卷大小要求超过单个卷的最大值（gp3 为 16 TiB，io2 Block Express 为 64 TiB）

操作要求

  • 需要在特定时间窗口内完成的大型数据加载或备份

  • 内存大于 4 TiB 且数据操作超过可接受持续时间的系统

  • 需要持续并行 I/O 的高吞吐量分析工作负载

  • 预计增长将超过单卷限制

重要

在实施条带化之前，请首先考虑使用性能更高的 EBS 卷类型，或者在单卷限制内调整 IOPS 和吞吐量设置。分条需要相同类型和大小的体积以及平衡的 I/O 图案才能有效。