调整大小 - 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 OpenSearch 服务提供热、温和冷存储等级。温存储层使用 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. 确定中央处理器。

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

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

确定索引策略和分片数

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

  • 搜索用例 — 10—30 Gb/Shard

  • 日志分析用例 — 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 设计的定制芯片构建的。它们是亚马逊设计的硬件和软件创新，通过隔离的多租户、私有网络和快速的本地存储，可以提供高效、灵活和安全的云服务。

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