计算 SAP HANA 的 EBS 存储需求 - SAP HANA on AWS
概览适用于 SAP HANA 的新 Amazon EBS 存储指南使用 SAP HANA 硬件和云测量工具进行测试EBS 存储卷配置

计算 SAP HANA 的 EBS 存储需求

概览

本指南针对在 Amazon EC2 上运行的 SAP HANA 工作负载提供了存储配置建议。您将了解如何配置 Amazon EBS 卷来满足 SAP 的存储关键性能指标（KPI）要求。

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

适用于 SAP HANA 的新 Amazon EBS 存储指南

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

新指南重点讲解 gp3 和 io2 Block Express 卷，推荐将其作为所有新部署的最新标准。虽然现有部署仍然支持 gp2 和 io1 卷，但建议将 gp3 用于新的实施，因为其性能和成本效益是可预测的；对于需要更高性能的系统，可选择 io2 Block Express 作为升级路径。

注意

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

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

AWS 已确保存储配置指南符合运行 SAP HANA 的关键性能指标（KPI）要求。但是，对于性能要求较高或偏离了标准推荐的工作负载，强烈建议您使用 SAP HANA 硬件和云测量工具验证存储配置的性能。

请参阅：

EBS 存储卷配置

此部分提供计算 SAP HANA 存储需求的公式和方法。相关计算会将内存大小和工作负载特征纳入考量，以确定合适的卷大小和性能配置。请根据自己的具体工作负载要求和增长预测调整这些基准建议。

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

重要

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

根和 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 以满足运营需求，但 AWS 仍将 1.2 因子作为初始部署的基准。这是一种经济高效的方法，利用了 EBS 卷的动态扩展功能，使您可以随着需求的增长在线扩展存储容量。需要更多空间时，您可以轻松增加卷大小而无需中断服务。

存储类型选择

  • 使用具有自定义 IOPS/吞吐量（不超过卷上限）的 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 KPI 要求所需的最低 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。有使用多个卷的更多信息，请参阅何时对卷进行条带化。

  • SAP 对 HANA 数据卷的最低吞吐量要求为 400 MB/s。在我们的公式中，450 MB/s 的基本吞吐量值可确保满足此 SAP KPI 要求，同时还留有额外的余量以实现最佳性能。

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

  • 例外情况：对于 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 卷可实现 4000 MB/s 的吞吐量，IOPS 为 16000。考虑到此容量，io2 Block Express 上的大多数 HANA 部署都不需要进行卷条带化。如果需要更高的吞吐量，则可以相应地调整预调配 IOPS。

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

示例

512 GiB 内存系统 HANA 数据卷：

  • 存储类型选择 = GP3

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

  • IOPS = MROUND(7200 + (0.45 * 512), 100) = 7460 IOPS

  • 吞吐量 = MIN(MROUND(450 + (0.2 * 512), 125), 2000) = 500 MB/s

  • 条带化 = 非必需。

4 TiB 内存系统 HANA 数据卷：

  • 存储类型选择 = GP3

  • 大小 = MROUND((4096 GiB * 1.2),100) = 4900 GiB

  • IOPS = MROUND(7200 + (0.45 * 4096), 100) = 9000 IOPS

  • 吞吐量 = MIN(MROUND(450 + (0.2 * 4096), 125), 2000) = 1250 MB/s

  • 条带化 = 视吞吐量而定。建议采用 2 x 2450 GiB 文件系统，对应 4500 IOPS，吞吐量 625 MB/s

HANA 日志卷

存储\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/吞吐量（不超过卷上限）的 gp3

  • 需要稳定的亚毫秒延迟时，建议使用 io2 Block Express

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

IOPS 公式 

log_iops_target = 3000

Where:
- Base IOPS = 3000

  • 满足针对数据的 SAP HANA KPI 要求所需的最低 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 日志卷的最低吞吐量要求为 250 MB/s。在我们的公式中，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

  • 吞吐量 = MIN(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 系统，每部署 4 个 worker 节点，/hana/shared 文件系统就需要与一个 worker 节点内存大小相等的磁盘空间。

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

横向扩展部署示例

Worker 节点内存

节点数量

计算

所需大小

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 文件系统为基于 SAP HANA 文件的备份（包括数据和日志备份）提供了本地存储。虽然本地文件系统备份可能对非关键系统有用，也可以作为辅助备份方案，但它们却在生产环境中带来了几个挑战：

  • 需要执行额外的同步步骤才能将备份移动到 Amazon S3 等持久存储

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

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

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

重要

AWS 建议使用 AWS Backup for SAP HANA 或 AWS 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 卷类型。

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

IOPS 公式 

backup_iops_target = n/a
注意

ST1 基准为 500 IOPS，但这是不可配置的。备份操作通常更多地依赖吞吐量，而不是 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

横向扩展部署示例

Worker 节点内存

卷

吞吐量

4 TiB

1

500 MB/s

12 TiB

2

1000 MB/s

24TiB

4

2000 MB/s

何时对卷进行条带化

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

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

技术限制

  • 吞吐量需求超出了单个卷的最大值（对 gp3 为 1000 Mb/s，对 io2 Block Express 为 4000 MB/s）。

    • 对于 io2 Block Express 卷，吞吐量的计算方式为 IOPS × I/O 大小。SAP HANA 工作负载通常使用 256 KiB I/O 操作，在这种大小下，单个 io2 Block Express 卷可实现 4000 MB/s 的吞吐量，IOPS 为 16000。考虑到此容量，io2 Block Express 上的大多数 HANA 部署都不需要进行卷条带化。如果需要更高的吞吐量，则可以相应地调整预调配 IOPS。

  • IOPS 需求超出了单个卷的最大值（对 gp3 为 16000，对 io2 Block Express 为 256000）。

  • 卷大小需求超出了单个卷的最大值（对 gp3 为 16 TiB，对 io2 Block Express 为 64 TiB）。

操作需求

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

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

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

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

重要

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