调整 Amazon OpenSearch Service 域的大小 - Amazon Opensearch Service
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

调整 Amazon OpenSearch Service 域的大小

没有确定 Amazon OpenSearch Service 域大小的完美方法。但是,通过了解您的存储需求、服务和 OpenSearch 本身,您可以对您的硬件需求做出有根据的初步估计。此估计可以作为调整域大小的大多数关键方面的有用起始点:用代表性工作负载测试它们并监控其性能。

计算存储要求

大多数 OpenSearch 工作负载分为两大类:

  • 长期有效的索引:您编写代码,以将数据处理为一个或多个 OpenSearch 索引,然后随着源数据的更改而定期更新这些索引。一些常见示例为网站、文档和电子商务搜索。

  • 滚动索引:数据持续流入一组具有索引周期和保留期限的临时索引,例如一组将保留 2 周的每日索引。一些常见示例是日志分析、时间序列处理和点击流分析。

对于长期有效的索引工作负载,您可以检查磁盘上的源数据并轻松确定它使用的存储空间。如果数据来自多个来源,只需一起添加这些来源。

对于滚动索引,您可以将代表性时间周期内生成的数据量乘以保留周期。例如,如果您每小时生成 200MiB 日志数据,即每天 4.7GiB,如果您的保留周期为 2 周,则任何给定时间的数据均为 66GiB。

但是,您的源数据的大小只是您的存储要求的一个方面。您还必须考虑以下方面:

  • 副本数量:每个副本都是一个索引的完整复制,需要同等量的磁盘空间。默认情况下,每个 OpenSearch 索引都有一个副本。我们建议至少具有一个,以防数据丢失。副本还可以提高搜索性能,因此如果您有需要进行大量读取操作的工作负载,则可能需要更多副本。使用 PUT /my-index/_settings 更新索引的 number_of_replicas 设置。

  • OpenSearch 索引开销:索引的磁盘大小各有不同,但通常比源数据大 10%。为您的数据编制索引后,您可以使用 _cat/indices?v API 和 pri.store.size 值计算确切的开销。_cat/allocation?v 还提供了一个有用的摘要。

  • 操作系统预留空间:默认情况下,Linux 将保留 5% 的文件系统供 root 用户处理关键流程、进行系统恢复和防止磁盘碎片问题。

  • OpenSearch Service 开销:OpenSearch Service 在每个实例中为分段合并、日志和其他内部操作保留 20% 的存储空间(最多可达 20GiB)。

    由于这个 20GiB 的最大值,预留空间的总量可能会相差悬殊,这具体取决于您的域中的实例数量。例如,某个域可能有三个 m6g.xlarge.search 实例,每个实例的存储空间为 500GiB,总存储空间为 1.46TiB。在这种情况下,只有 60GiB 的总预留空间。另一个域可能有 10 个 m3.medium.search 实例,每个实例的存储空间为 100GiB,总存储空间为 0.98TiB。在这里,总预留空间为 200GiB,即使第一个域大 50%。

    在以下公式中,我们对开销采用“最坏情况”估算值。该估算值包括额外的可用空间,可帮助最大限度地减少节点故障和可用区中断的影响。

总之,如果您在任何给定的时间有 66GiB 的数据并且需要一个副本,则最低 存储要求更接近 66 * 2 * 1.1 / 0.95 / 0.8 = 191GiB。您可以将此计算一般化,如下所示:

源数据 *(1 + 副本数量)*(1 + 索引开销)/(1 - Linux 预留空间)/(1 - OpenSearch Service 开销)= 最小存储要求

或者,您可以使用此简化版本:

源数据 * (1 + 副本数量) * 1.45 = 最小存储要求

存储空间不足是集群不稳定的最常见原因之一。所以,在选择实例类型、实例数量和存储量时,您应该交叉核对数字。

存在其他存储注意事项:

选择分片数量

在您了解存储要求后,便可以调查您的索引策略。默认情况下,在 OpenSearch Service 中,每个索引分为五个主分片和一个副本(共 10 个分片)。由于无法轻松更改现有索引的主分片的数量,在为第一个文档编制索引之前,应决定分片数量。

选择分片数量的总体目标是跨集群中的所有数据节点均匀分配索引。但是,这些分片不应该太大或太多。一般准则是,对于搜索延迟属于关键性能目标的工作负载,建议尽量将分片大小保持在 10-30GiB 之间;而对于写入密集型工作负载(如日志分析),则建议尽量将分片大小保持在 30-50GiB 之间。

大型分片可能使 OpenSearch 难以从故障中恢复,但因为每个分片使用一些数量的 CPU 和内存,拥有太多小型分片可能会导致性能问题和内存不足的错误。换句话说,分片应足够小,以便底层 OpenSearch Service 实例可以处理它们,但又不能太小,以免对硬件造成不必要的压力。

例如,假设您有 66GiB 的数据。您不希望该数字随着时间的推移而增加,您希望将每个分片保持在 30GiB 左右。因此,您的分片数量应大约为 66 * 1.1 / 30 = 3。您可以将此计算一般化,如下所示:

(元数据 + 增长空间) * (1 + 索引开销) / 所需的分片大小 = 主分片的大约数量

此等式可帮助补偿今后的数据增长。如果您预计这相同的 66GiB 数据将在下一年增长到原来的四倍,则分片的数量大约为 (66 + 198) * 1.1 / 30 = 10。但是,请记住,您还没有 这额外的 198GiB 数据。检查以确保为未来所做的这一准备不会创建目前消耗大量 CPU 和内存的多余微小分片。在这种情况下,66 * 1.1 / 10 分片 = 7.26GiB/分片,将消耗额外的资源且小于建议的大小范围。您可能会考虑 6 个分片的更折中方法,这种方法为您留下了现在的 12GiB 分片和未来的 48GiB 分片。而且,您可能更愿意从 3 个分片开始且在分片超过 50GiB 时为您的数据重新编制索引。

一个不太常见的问题涉及限制每个节点的分片数量。如果您适当地调整分片大小,您通常会在遇到此限制之前,很长时间才会用完磁盘空间。例如,m6g.large.search 实例的最大磁盘大小为 512 GiB。如果您的磁盘利用率低于 80%,并且分片大小为 20 GiB,则可容纳大约 20 个分片。Elasticsearch 7.x 和更高版本,以及 OpenSearch 的所有版本限制为每个节点 1000 个分片。要调整每个节点的最大分区数,请配置 cluster.max_shards_per_node 设置。有关示例,请参阅集群设置

适当调整分片大小几乎总是使您低于此限制,但您也可以考虑针对每 GiB 的 Java 堆的分片数。在给定节点上,每 GiB 的 Java 堆不超过 20 个分片。例如,一个 m5.large.search 实例有一个 4GiB 堆,因此每个节点应该有不超过 80 个分片。对于该分片计数,每个分片的大小大约为 5 GiB,远低于我们建议的大小。

选择实例类型和测试

当您计算存储要求并选择您需要的分片数量后,您可以开始进行硬件决策。硬件要求可能因工作负载而差异悬殊,但我们仍然可以提供一些基本建议。

一般而言,每个实例类型的存储限制映射到轻型工作负载可能需要的 CPU 和内存量。例如,某个 m6g.large.search 实例的最大 EBS 卷大小为 512GiB,该实例具有 2 个 vCPU 核心和 8GiB 内存。如果您的群集有许多分片,需要执行税收聚合、频繁更新文档或处理大量查询,则这些资源可能不足以满足您的需求。如果您的集群属于其中一个类别,请尝试从每 100GiB 存储要求更接近 2 个 vCPU 核心和 8GiB 内存的配置开始。

提示

有关分配给每个实例类型的硬件资源的摘要,请参阅 Amazon OpenSearch Service 定价

但是,即使这些资源也可能不足。某些 OpenSearch 用户报告称他们需要这些资源的许多倍才能满足要求。要为您的工作负载寻找合适的硬件,您必需进行明智的初步估计、使用代表性工作负载进行测试、调整并再次测试。

步骤 1:进行初步估计

若要开始,我们建议使用最少三个节点,以避免潜在的 OpenSearch 问题,如分裂大脑状态(当通信中断导致集群有两个主节点时)。如果您有三个专用主节点,我们仍建议至少将两个数据节点用于复制。

步骤 2:计算每个节点的存储需求

如果您的存储要求为 184GiB 而建议的最小节点数量为三个,则可以使用等式 184/3 = 61GiB 来找到每个节点需要的存储量。在此示例中,您可以选择三个 m6g.large.search 实例,每个实例使用一个 90GiB 的 EBS 存储卷,以便您有一个安全网和一些随时间增长的空间。此配置提供了 6 个 vCPU 核心和 24GiB 内存,因此适合更轻型的工作负载。

有关更具体的示例,请考虑 14TiB (14336 GiB) 存储要求和重型工作负载。在这种情况下,您可能会选择从 2 * 144 = 288 个 vCPU 核心和 8 * 144 = 1152GiB 内存开始测试。这些数量计为约 18 个 i3.4xlarge.search 实例。如果您不需要快速的本地存储,您还可以测试 18 个 r6g.4xlarge.search 实例,每个实例使用 1TiB EBS 存储卷。

如果您的群集包含数百 TB 的数据,请参阅Amazon OpenSearch Service 中的 PB 级规模

步骤 3:执行代表性测试

配置集群后,您可以使用之前计算的分片数添加索引、使用真实数据集执行一些代表性客户端测试,并监控 CloudWatch 指标以查看集群如何处理工作负载。

步骤 4:成功或迭代

如果性能满足您的需求、测试成功且 CloudWatch 指标正常,则集群便可以使用了。记得去设置 CloudWatch 警告以检测不正常的资源使用情况。

如果性能不可接受、测试失败,或者 CPUUtilizationJVMMemoryPressure 很高,则您可能需要选择其他实例类型 (或添加实例) 并继续测试。随着您添加实例,OpenSearch 会自动重新平衡分片在整个集群中的分配。

因为在动力过剩的集群中测量超额容量比在动力不足的集群中测量容量不足更简单,所以我们建议从比您认为您所需的集群更大的集群开始。接下来,测试并缩减为具有额外资源的高效集群,以确保活动增加期间稳定运行。

生产集群或具有复杂状态的集群可从专用主节点中受益,从而提高性能和集群可靠性。