Amazon Elasticsearch Service
开发人员指南 (API 版本 2015-01-01)
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 Amazon AWS 入门

调整 Amazon ES 域大小

调整 Amazon ES 域大小不存在一定成功的方法,但通过首先了解您的存储需求、服务和 Elasticsearch 本身,您可以对您的硬件需求作出明智的初步估计。此估计可以作为调整域大小的大多数关键方面的有用起始点:用代表性工作负载测试它们并监控其性能。

计算存储要求

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

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

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

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

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

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

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

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

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

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

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

    在以下公式中,我们对开销应用“最糟糕的情况”估计,此估计对每个实例的存储空间小于 100GiB 的域是准确的,但对更大的实例则是过度分配。

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

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

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

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

存储空间不足是群集不稳定的最常见原因之一,因此在选择实例类型、实例计数和存储卷时,您应反复检查数量。

注意

如果您的最小存储要求超过 1 PB,请参阅 Amazon Elasticsearch Service 的 PB 规模

选择分片数量

在您了解存储要求后,便可以调查您的索引策略。每个 Elasticsearch 索引分为一些分片数量。由于无法轻松更改现有索引的主分片的数量,在为第一个文档编制索引之前,应决定分片数量。

选择分片数量的总体目标是跨群集中的所有数据节点均匀分配索引。但是,这些分片不应该太大或太多。尽量使分片大小保持在 10–50GiB 之间是一种比较好的做法。大型分片可能使 Elasticsearch 难以从故障中恢复,但因为每个分片使用一些数量的 CPU 和内存,拥有太多小型分片可能会导致性能问题和内存不足的错误。换句话说,分片应足够小,以便底层 Amazon ES 实例可以处理它们,但又不能太小,以免对硬件造成不必要的压力。

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

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

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

注意

默认情况下,Elasticsearch 索引拆分为 5 个主分片。在创建索引时,您可以指定不同的设置。

选择实例类型和测试

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

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

提示

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

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

  1. 若要开始,我们建议最少三个实例,以避免潜在的 Elasticsearch 问题,例如分裂大脑问题。如果您有三个专用主节点,我们仍建议至少将两个数据节点用于复制。

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

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

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

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

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

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

    因为在动力过剩的群集中测量超额容量比在动力不足的群集中测量容量不足更简单,所以我们建议从比您认为您需要的更大的群集开始,然后缩减至具有足以确保在增加活动期间可稳定操作的资源的群集。

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