本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 计算 SAP HANA 的 EBS 存储需求 ## 概述 本指南为在亚马逊上运行的 SAP HANA 工作负载提供了存储配置建议 EC2。了解如何配置 Amazon EBS 卷以满足 SAP 的存储关键性能指标 (KPIs)。 SAP HANA 主要在内存中存储和处理其数据，并通过将数据保存到持久性存储位置来防止数据丢失。为了实现最佳性能，用于 SAP HANA 数据和日志卷的存储解决方案应满足 SAP 的存储 KPI 要求。 AWS 已与 SAP 合作认证了适用于 SAP HANA 工作负载的亚马逊 EBS 通用固态硬盘（gp2 和 gp3）和预配置 IOPS 固态硬盘（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 的关键性能指标 (KPIs)。但是，对于性能要求较高或偏离了标准推荐的工作负载，强烈建议您使用 SAP HANA 硬件和云测量工具验证存储配置的性能。 请参阅： + SAP Note：[2493172 - SAP HANA Hardware and Cloud Measurement Tools](https://me.sap.com/notes/2493172) + SAP 文档：[SAP HANA Hardware and Cloud Measurement Tools](https://help.sap.com/viewer/product/HANA_HW_CLOUD_TOOLS/latest/en-US) ## EBS 存储卷配置 此部分提供计算 SAP HANA 存储需求的公式和方法。相关计算会将内存大小和工作负载特征纳入考量，以确定合适的卷大小和性能配置。请根据自己的具体工作负载要求和增长预测调整这些基准建议。 有关根据可用内存计算得出需求的信息，请参阅 [SAP HANA EBS 存储参考](hana-storage-config-reference-layout.md)。 **Topics** + [根和 SAP 二进制文件卷](#root_and_sap) + [HANA 数据卷](#hana_data) + [HANA 日志卷](#hana_log) + [HANA 共享卷](#hana_shared) + [HANA 备份卷（可选）](#hana_backup) + [何时对卷进行条带化](#_when_to_stripe_volumes) **重要** 某些 EC2 实例类型可能包括[实例存储](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)，这种存储是临时性的，不得用于 SAP HANA 文件。请为所有 SAP HANA 存储需求配置 Amazon EBS 卷。 ### 根和 SAP 二进制文件卷 根卷包含操作系统文件、配置和日志。大小调整建议适用于大多数 SAP HANA 部署和大小，但可能因您的 AMI 策略和非 SAP 软件需求而异。在高使用率环境下，建议为 `/tmp` 文件系统单独配置一个卷。 SAP 二进制文件卷（`default /usr/sap//`）包含常见的 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) ``` **示例** *任意内存系统根卷：* **Example** + 大小 = 50 GiB + IOPS = 3000 + 吞吐量 = 125 MB/s ### HANA 数据卷 存储\$1DATA 文件系统（默认 `/hana/data`）用于存储 SAP HANA 内存数据库的持久副本。虽然 SAP HANA 在运行时会将数据置于内存中，但该卷会通过定期保存点来保证数据持久性。存储必须处理混合工作负载模式（包括正常运行期间的随机读写以及保存点期间的顺序模式），同时保持持续的低延迟以保持数据库性能。 **大小计算** 数据卷大小需求源自系统内存大小。虽然实际存储需求取决于您的具体工作负载、压缩比和增长预测，不过可以使用以下计算作为基准。要进行精确计算，请查阅 SAP 大小调整工具。 + SAP 文档：[SAP Benchmark Sizing](https://www.sap.com/about/benchmark/sizing.html) ``` 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/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\$1iops\$1target。请参阅下面的条带化指南。 + 满足 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`。有使用多个卷的更多信息，请参阅[何时对卷进行条带化](#_when_to_stripe_volumes)。 + 在我们的公式MB/s. The base throughput value of 450 MB/s中，SAP 对 HANA 数据量的最低吞吐量要求为 400，这可确保这个 SAP KPI 得到额外的预留空间以实现最佳性能。 + 每个实例类型都有自己的 Amazon EBS 吞吐量最大值。有关详细信息，请参阅文档中的 [Amazon EBS 优化实例](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html)。 AWS + 例外：对于 32 TB 及更大的实例（当前实例类型 u7inh-32tb.480xlarge），我们建议预置 4000 或更高的吞吐量。 MB/s 对于所有其他实例大小，如果您需要超过 2000 MB/s 的吞吐量，则可以相应地调整公式中的最大吞吐量值。 **卷条带化** 当您需要满足特定的技术限制、性能要求或运营要求时，请实施卷条带化。有关何时适合实施条带化的详细指导，请参阅[何时对卷进行条带化](#_when_to_stripe_volumes)。 对于 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 数据卷：* **Example** + 存储类型选择 = GP3 + 大小 = MROUND((512 GiB \$1 1.2),100) = 600 GiB + IOPS = MROUND(7200 \$1 (0.45 \$1 512), 100) = 7460 IOPS + 吞吐量 = MIN(MROUND(450 \$1 (0.2 \$1 512), 125), 2000) = 500 MB/s + 条带化 = 非必需。 *4 TiB 内存系统 HANA 数据卷：* **Example** + 存储类型选择 = GP3 + 大小 = MROUND((4096 GiB \$1 1.2),100) = 4900 GiB + IOPS = MROUND(7200 \$1 (0.45 \$1 4096), 100) = 9000 IOPS + 吞吐量 = MIN(MROUND(450 \$1 (0.2 \$1 4096), 125), 2000) = 1250 MB/s + 条带化 = 视吞吐量而定。考虑一下 2 x 2,450 GiB 文件系统、4500 IOPS、625 吞吐量 MB/s ### HANA 日志卷 存储\$1LOG 文件系统（默认为 `/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 条带大小，以针对日志操作典型的顺序写入模式进行优化。请参阅[何时对卷进行条带化](#_when_to_stripe_volumes)部分，了解在哪些情况下需要使用条带化才能实现吞吐量、IOPS 或性能目标。 **示例** *512 GiB 内存系统 HANA 日志卷：* **Example** + 存储类型选择 = GP3 + 大小 = MROUND512 GiB \$1 0.5) ,100 = 300 GiB（最大 500 GiB 以内） + IOPS = 3000 + 吞吐量 = MIN(MROUND(300 \$1 (0.015 \$1 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 1 | 2 TiB | | 2 TiB | 5-8 个节点 | 2048 \$1 2 | 4 TiB | | 2 TiB | 9-11 个节点 | 2048 \$1 3 | 6 TiB | | 2 TiB | 12-15 个节点 | 2048 \$1 4 | 8 TiB | **存储类型选择** + GP3 为纵向扩展部署提供了所需的性能特征 + Amazon EFS 是针对纵向扩展和横向扩展部署的可行方案，可实现跨所有节点的共享访问并具备所需的性能特性。有关横向扩展配置，请参阅[配置存储（EFS）](configure-nfs-for-scale-out-workloads.md) **IOPS 公式** ``` shared_iops_target = 3000 Where: - Base IOPS = 3000 (fixed) ``` **吞吐量公式** ``` shared_throughput_target = 125 Where: - Base throughput = 125 MB/s (fixed) ``` **示例** *512 GiB 内存系统 HANA 共享卷：* **Example** + 大小 = 512 GiB + IOPS = 3000 + 吞吐量 = 125 MB/s ### HANA 备份卷（可选） `/backup` 文件系统为基于 SAP HANA 文件的备份（包括数据和日志备份）提供了本地存储。虽然本地文件系统备份可能对非关键系统有用，也可以作为辅助备份方案，但它们却在生产环境中带来了几个挑战： + 需要执行额外的同步步骤才能将备份移动到 Amazon S3 等持久存储 + 如果磁盘或硬件出现故障，恢复点目标可能会受到影响 + 需要通过事务管理和监控来仔细管理本地存储容量 + 在横向扩展中，卷需要能够可供所有节点访问 **重要** AWS 建议使用 [AWS Backup for SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-backup.html) 或 [AWS Backint Agent](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-backup.html) 来代替基于文件的备份。这些解决方案提供了到持久存储的直接备份，并简化了备份管理。 **大小计算** 备份卷的大小在很大程度上取决于系统的使用情况。以下内容应作为初始基准，但在部署后需根据备份大小、变更量、本地副本保留策略和应急需求进行调整。 ``` 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 卷类型](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html)。 + 对于多节点部署，我们建议使用 Amazon EFS for SAP HANA 执行基于文件的备份。它可以支持超过 10 个 IOPS GB/sec 和超过 500,000 个 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 为 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 为 16000，对 io2 Block Express 为 256000）。 + 卷大小需求超出了单个卷的最大值（对 gp3 为 16 TiB，对 io2 Block Express 为 64 TiB）。 操作需求 + 需要在特定时段内完成的大型数据加载或备份 + 内存大小大于 4 TiB 且数据操作持续时间超出了可接受值的系统 + 需要持续并行 I/O 的高吞吐量分析工作负载 + 预计增长将超出单卷限制 **重要** 在实施条带化之前，请首先考虑使用性能较高的 EBS 卷类型，或者在单卷限制内调整 IOPS 和吞吐量设置。分条需要相同类型和大小的体积以及平衡的 I/O 图案才能有效。