View a markdown version of this page

调整大小 - AWS 规范性指导
仓储服务节点数量和实例类型确定索引策略和分片计数CPU 使用率实例类型

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

调整大小

调整大小可帮助您为您的目标环境确定正确的实例类型、数据节点数量和存储要求。我们建议您先按存储空间来调整大小，然后再按容量调整大小 CPUs。如果您已经在使用 Elasticsearch 或 OpenSearch，则大小通常会保持不变。但是，您需要确定与当前环境等效的实例类型。为了帮助确定正确大小，我们建议使用以下准则。

仓储服务

要调整集群大小，请先定义存储要求。确定集群所需的原始存储。这是通过评测源系统（例如，生成日志的服务器或产品目录原始大小）生成的数据来确定的。确定您具有的原始数据量后，使用以下公式计算存储要求。随后，您可以将结果用作 PoC 的起点。

storage needed = (daily source data in bytes × 1.45) (number_of_replicas + 1) × number of days retained

该公式考虑了以下几点：

  • 索引的磁盘大小各有不同，但通常比源数据大 10%。

  • Linux 会预留 5% 的操作系统开销，用于系统恢复和防止磁盘碎片整理问题。

  • OpenSearch 为每个实例预留 20% 的存储空间，用于分段合并、日志和其他内部操作。

  • 建议额外保留 10% 的存储空间，以帮助最大限度地减少节点故障和可用区中断的影响。

综合起来，根据来源中的实际原始数据，这些额外开销和预留需要增加 45% 的空间。这就是将源数据乘以 1.45 的原因。接下来，将其乘以数据副本数量（例如，一个主副本加上您将使用的副本数量）。副本计数取决于您的韧性和吞吐量要求。对于一般使用案例，从一个主副本和一个副本开始。最后，乘以您希望将数据保留在热存储层中的天数。

Amazon Ser OpenSearch vice 提供热、温和冷存储层。温存储层使用 UltraWarm 存储。 UltraWarm 为在 Amazon OpenSearch 服务上存储大量只读数据提供了一种经济实惠的方式。标准数据节点使用热存储，其形式是连接到每个节点的实例存储或 Amazon Elastic Block Store（Amazon EBS）卷。热存储为索引和搜索新数据提供了尽可能快的性能。 UltraWarm 节点使用亚马逊简单存储服务 (Amazon S3) Service 作为存储，并使用复杂的缓存解决方案来提高性能。对于不主动写入或查询频率较低且性能要求不相同的索引， UltraWarm 可以显著降低每 GiB 数据的成本。有关的更多信息 UltraWarm，请参阅 AWS 文档。

创建 OpenSearch 服务域并使用热存储时，可能需要定义 EBS 卷的大小。这取决于您为数据节点选择的实例类型。您可以使用相同的存储要求公式来确定 Amazon EBS 支持的实例的卷大小。对于最新一代 T3、R5、R6G、M5、M5g、C5 和 C6g 实例系列，我们建议使用 gp3 卷。使用 Amazon EBS gp3 卷，您可以独立于存储容量预调配性能。Amazon EBS gp3 卷还提供了更好的基准性能，与现有的 gp2 卷相比，每 GB 的成本降低了 9.6%。 OpenSearch 借助 gp3，您还可以在 R5、R6g、M5 和 M6g 实例系列上获得更密集的存储，这可以帮助您进一步优化成本。您可以创建不超过支持的配额的 EBS 卷。有关配额的更多信息，请参阅 Amazon OpenSearch 服务配额。

对于具有 NVM Express (NVMe) 驱动器的数据节点，例如 i3 和 r6gd 实例，卷大小是固定的，因此 EBS 卷不是一种选择。

节点数量和实例类型

节点的数量基于运行工作负载 CPUs 所需的数量。的数量 CPUs 基于分片数。中的索引 OpenSearch 由多个分片组成。在创建索引时，您将指定索引的分片数。因此，您需要执行以下操作：

  1. 计算您打算存储在域中的分片总数。

  2. 确定 CPU。

  3. 找到最具成本效益的节点类型和数量，从而为您提供所需的数量 CPUs 和存储空间。

这通常是起点。运行测试以确定估计大小是否满足您的功能和非功能要求。

确定索引策略和分片计数

了解存储要求后，您可以决定需要索引的数量并确定每个索引的分片计数。通常，搜索使用案例有一个或几个索引，每个索引代表一个可搜索的实体或一个目录。对于日志分析使用案例，索引可以表示每日或每周的日志文件。在决定索引数量之后，从以下扩展指引开始，然后确定适当的分片数：

  • 搜索使用案例 – 10–30 GB/分片

  • 日志分析使用案例 – 50 GB/分片

您可以将单个索引中的总数据量除以您在使用案例中想要的分片大小。这将为您提供索引的分片数量。确定分片总数将帮助您找到适合您工作负载的正确实例类型。这些分片不应该太大或太多。较大的分片可能使故障恢复变得困难，但是由于每个分片会占用一定数量的 CPU 和内存，因此拥有过多的小分片可能会导致性能问题和错误。 OpenSearch out-of-memory此外，对数据节点的分片分配不平衡可能导致偏差。如果索引包含多个分片，请尝试将分片数量设为数据节点数量的偶数倍。这有助于确保分片在数据节点之间均匀分布，防止出现热节点。例如，假设您有 12 个主分片，则数据节点计数应为 2、3、4、6 或 12。但是，分片数量不如分片大小重要，如果您只有 5GiB 的数据，则仍应使用单个分片。在可用区内均匀平衡副本分片计数还有助于提高韧性。

CPU 使用率

下一步是确定您的工作负载需要多少 CPUs 工作量。我们建议从活动分片的 1.5 倍的 CPU 数量开始。活动分片是指正在接收大量写入的索引的任何分片。使用主分片计数来确定正在接收大量读取或写入请求的索引的活动分片。对于日志分析，通常只有当前索引处于活动状态。对于搜索使用案例，所有主分片都将视为活动分片。虽然我们建议每个活动分片 1.5 个 CPU，但这在很大程度上取决于工作负载。请务必测试和监控 CPU 利用率并相应地进行扩展。

保持 CPU 利用率的最佳做法是确保 OpenSearch 服务域有足够的资源来执行其任务。CPU 使用率一直较高的集群可能会降低集群稳定性。当您的集群过载时，Serv OpenSearch ice 将阻止传入的请求，从而导致请求被拒绝。这是为了防止域出现故障。CPU 使用率的一般准则将是平均约为 60%，最大 CPU 使用率为 80%。偶尔达到 100% 的峰值仍然是可以接受的，并且可能不需要扩展或重新配置。

实例类型

Amazon OpenSearch 服务为您提供多种实例类型供您选择。您可以选择最适合您的使用案例的实例类型。Amazon OpenSearch 服务支持 R、C、M、T 和 I 实例系列。您可以根据工作负载选择实例系列：内存优化、计算优化或混合。确定实例系列后，选择最新一代的实例类型。通常，我们推荐 Graviton 及更高版本，因为与上一代实例相比，它们旨在以更低的成本提供更高的性能。

根据针对日志分析和搜索使用案例进行的各种测试，我们建议进行以下操作：

  • 对于日志分析使用案例，一般准则是从数据节点的 R 系列 Graviton 实例开始。我们建议您运行测试，根据您的要求建立基准，并为您的工作负载确定合适的实例大小。

  • 对于搜索使用案例，我们建议对数据节点使用 R 和 C 系列 Graviton 实例，因为与日志分析使用案例相比，搜索使用案例需要更多的 CPU。对于较小的工作负载，您可以使用 M 系列 Graviton 实例同时进行搜索和日志记录。I 系列实例提供 NVMe 驱动器，供有快速索引和低延迟搜索要求的客户使用。

集群由数据节点和集群管理器节点组成。虽然专用主节点不处理搜索和查询请求，但它们的大小与实例大小及其管理的实例、索引和分片数量高度相关。AWS 文档提供了一个矩阵，其中推荐了最低限度的专用集群管理器实例类型。

AWS 针对由 AWS Graviton2 处理器提供支持的亚马逊服务 OpenSearch 版本 7.9 或更高版本提供通用型 (m6g)、计算优化 (c6g) 和内存优化 (r6g 和 r6gD)。这些实例是使用 Amazon 设计的定制硅芯片构建的。它们是 Amazon 设计的硬件和软件创新，通过隔离的多租户、私有网络和快速本地存储，可提供高效、灵活和安全的云服务。

与 OpenSearch 服务中提供的上一代基于英特尔的实例（M5、C5、R5）相比，Graviton2 实例系列可将索引延迟减少多达 50%，查询性能提高多达 30%。