本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 调整亚马逊 OpenSearch 服务域名的大小
没有完美的方法可以调整亚马逊 OpenSearch 服务域名的大小。但是，首先要了解您的存储需求、服务及其 OpenSearch 本身，就可以对硬件需求做出有根据的初步估计。此估计可以作为调整域大小的大多数关键方面的有用起始点：用代表性工作负载测试它们并监控其性能。
**Topics**
+ [计算存储要求](bp-storage.md)
+ [选择分片数量](bp-sharding.md)
+ [选择实例类型和测试](bp-instances.md)
# 计算存储要求
大多数 OpenSearch 工作负载分为两大类之一：
+ **长效索引**：您编写的代码将数据处理为一个或多个 OpenSearch 索引，然后随着源数据的变化定期更新这些索引。一些常见示例为网站、文档和电子商务搜索。
+ **滚动索引**：数据持续流入一组具有索引周期和保留期限的临时索引，例如一组将保留 2 周的每日索引。一些常见示例是日志分析、时间序列处理和点击流分析。
对于长期有效的索引工作负载，您可以检查磁盘上的源数据并轻松确定它使用的存储空间。如果数据来自多个来源，只需一起添加这些来源。
对于滚动索引，您可以将代表性时间周期内生成的数据量乘以保留周期。例如，如果您每小时生成 200MiB 日志数据，即每天 4.7GiB，如果您的保留周期为 2 周，则任何给定时间的数据均为 66GiB。
但是，您的源数据的大小只是您的存储要求的一个方面。您还必须考虑以下方面：
+ **副本数量**：每个副本都是主分片的一个完整副本，索引的存储大小显示主分片和副本分片占用的大小。默认情况下，每个 OpenSearch 索引都有一个副本。我们建议至少具有一个，以防数据丢失。副本还可以提高搜索性能，因此如果您有需要进行大量读取操作的工作负载，则可能需要更多副本。使用 `PUT /my-index/_settings` 更新索引的 `number_of_replicas` 设置。
+ **OpenSearch 索引开销**：索引的磁盘大小各不相同。源数据加上索引的总大小通常为源数据的 110%，索引最多为源数据的 10%。为您的数据编制索引后，您可以使用 `_cat/indices?v` API 和 `pri.store.size` 值计算确切的开销。`_cat/allocation?v` 还提供了一个有用的摘要。
+ **操作系统预留空间**：默认情况下，Linux 将保留 5% 的文件系统供 `root` 用户处理关键流程、进行系统恢复和防止磁盘碎片问题。
+ **OpenSearch 服务开销**： OpenSearch 服务会为每个实例预留 20% 的存储空间（最多 20 GiB），用于分段合并、日志和其他内部操作。
由于这个 20GiB 的最大值，预留空间的总量可能会相差悬殊，这具体取决于您的域中的实例数量。例如，某个域可能有三个 `m6g.xlarge.search` 实例，每个实例的存储空间为 500GiB，总存储空间为 1.46TiB。在这种情况下，只有 60GiB 的总预留空间。另一个域可能有 10 个 `m3.medium.search` 实例，每个实例的存储空间为 100GiB，总存储空间为 0.98TiB。在这里，总预留空间为 200GiB，即使第一个域大 50%。
在以下公式中，我们对开销采用“最坏情况”估算值。该估算值包括额外的可用空间，可帮助最大限度地减少节点故障和可用区中断的影响。
总之，如果您在任何给定的时间有 66GiB 的数据并且需要一个副本，则*最低* 存储要求更接近 66 \$1 2 \$1 1.1 / 0.95 / 0.8 = 191GiB。您可以将此计算一般化，如下所示：
**源数据 \$1（1 \$1 副本数量）\$1（1 \$1 索引开销）/（1-Linux 预留空间）/（1- OpenSearch 服务开销）= 最低存储要求**
或者，您可以使用此简化版本：
**源数据 \$1（1 \$1 副本数量）\$1 1.45 = 最小存储要求**
存储空间不足是集群不稳定的最常见原因之一。所以，在[选择实例类型、实例数量和存储量](bp-instances.md)时，您应该交叉核对数字。
存在其他存储注意事项：
+ 如果您的最小存储要求超过 1 PB，请参阅 [Amazon 服务中的 PB 级规模 OpenSearch](petabyte-scale.md)。
+ 如果您有滚动索引并希望使用热-暖架构，请参阅 [UltraWarm 亚马逊 OpenSearch 服务的存储空间](ultrawarm.md)。
# 选择分片数量
在您了解存储要求后，便可以调查您的索引策略。默认情况下，在 S OpenSearch ervice 中，每个索引分为五个主分片和一个副本（总共 10 个分片）。这种行为不同于开源 OpenSearch，后者默认为一个主分片和一个副本分片。由于无法轻松更改现有索引的主分片的数量，在为第一个文档编制索引*之前*，应决定分片数量。
选择分片数量的总体目标是跨集群中的所有数据节点均匀分配索引。但是，这些分片不应该太大或太多。一般准则是，对于搜索延迟属于关键性能目标的工作负载，建议尽量将分片大小保持在 10-30GiB 之间；而对于写入密集型工作负载（如日志分析），则建议尽量将分片大小保持在 30-50GiB 之间。
较大的分片可能使故障恢复变得困难，但是由于每个分片会占用一定数量的 CPU 和内存，因此拥有过多的小分片可能会导致性能问题和内存不足错误。 OpenSearch 换句话说，分片应该足够小，以便底层 S OpenSearch ervice 实例可以处理它们，但不能太小以至于给硬件带来不必要的压力。
例如，假设您有 66GiB 的数据。您不希望该数字随着时间的推移而增加，您希望将每个分片保持在 30GiB 左右。因此，您的分片数量应大约为 66 \$1 1.1 / 30 = 3。您可以将此计算一般化，如下所示：
**（源数据 \$1 增长空间）\$1（1 \$1 索引开销）/所需的分片大小 = 主分片的大约数量**
此等式可帮助补偿今后的数据增长。如果您预计这相同的 66GiB 数据将在下一年增长到原来的四倍，则分片的数量大约为 (66 \$1 198) \$1 1.1 / 30 = 10。但是，请记住，您*还没有* 这额外的 198GiB 数据。检查以确保为未来所做的这一准备不会创建目前消耗大量 CPU 和内存的多余微小分片。在这种情况下，66 \$1 1.1 / 10 分片 = 7.26GiB/分片，将消耗额外的资源且小于建议的大小范围。你可以考虑六个分片的更多 middle-of-the-road方法，这样你今天就有 12-GiB 的分片，将来有 48-GiB 的分片。而且，您可能更愿意从 3 个分片开始且在分片超过 50GiB 时为您的数据重新编制索引。
一个不太常见的问题涉及限制每个节点的分片数量。如果您适当地调整分片大小，您通常会在遇到此限制之前，很长时间才会用完磁盘空间。例如，`m6g.large.search` 实例的最大磁盘大小为 512 GiB。如果您的磁盘利用率低于 80%，并且分片大小为 20 GiB，则可容纳大约 20 个分片。Elasticsearch 7 *x* 及更 OpenSearch高版本，以及所有不超过 2.15 的版本，每个节点的分片上限为 *1,000* 个。要调整每个节点的最大分区数，请配置 `cluster.max_shards_per_node` 设置。对于 OpenSearch 2.17 及更高版本， OpenSearch 服务支持每 16GB 的 JVM 堆内存使用 1000 个分片，每个节点最多支持 4000 个分片。有关示例，请参阅[集群设置](https://opensearch.org/docs/latest/opensearch/rest-api/cluster-settings/#request-body)。有关分片计数的更多信息，请参阅 [分片计数限额](limits.md#shard-count)。
适当调整分片大小几乎总是使您低于此限制，但您也可以考虑针对每 GiB 的 Java 堆的分片数。在给定节点上，每 GiB 的 Java 堆不超过 25 个分片。例如，一个 `m5.large.search` 实例有一个 4 GiB 堆，因此每个节点应该有不超过 100 个分片。对于该分片计数，每个分片的大小大约为 5 GiB，远低于我们建议的大小。
# 选择实例类型和测试
当您计算存储要求并选择您需要的分片数量后，您可以开始进行硬件决策。硬件要求可能因工作负载而差异悬殊，但我们仍然可以提供一些基本建议。
一般而言，每个实例类型的[存储限制](limits.md)映射到轻型工作负载可能需要的 CPU 和内存量。例如，某个 `m6g.large.search` 实例的最大 EBS 卷大小为 512GiB，该实例具有 2 个 vCPU 核心和 8GiB 内存。如果您的群集有许多分片，需要执行税收聚合、频繁更新文档或处理大量查询，则这些资源可能不足以满足您的需求。如果您的集群属于其中一个类别，请尝试从每 100GiB 存储要求更接近 2 个 vCPU 核心和 8GiB 内存的配置开始。
**提示**
有关分配给每种实例类型的硬件资源的摘要，请参阅 [Amazon OpenSearch 服务定价](https://aws.amazon.com/opensearch-service/pricing/)。
但是，即使这些资源也可能不足。一些 OpenSearch 用户报告说，他们需要很多次这些资源来满足他们的需求。要为您的工作负载寻找合适的硬件，您必需进行明智的初步估计、使用代表性工作负载进行测试、调整并再次测试。
## 步骤 1：进行初步估计
首先，我们建议至少有三个节点，以避免潜在 OpenSearch的问题，例如*大脑分裂*状态（通信中断导致集群有两个主节点）。如果您有三个[专用主节点](managedomains-dedicatedmasternodes.md)，我们仍建议至少将两个数据节点用于复制。
## 步骤 2：计算每个节点的存储需求
如果您的存储要求为 184GiB 而建议的最小节点数量为三个，则可以使用等式 184/3 = 61GiB 来找到每个节点需要的存储量。在此示例中，您可以选择三个 `m6g.large.search` 实例，每个实例使用一个 90GiB 的 EBS 存储卷，以便您有一个安全网和一些随时间增长的空间。此配置提供了 6 个 vCPU 核心和 24GiB 内存，因此适合更轻型的工作负载。
有关更具体的示例，请考虑 14TiB (14336 GiB) 存储要求和重型工作负载。在这种情况下，您可能会选择从 2 \$1 144 = 288 个 vCPU 核心和 8 \$1 144 = 1152GiB 内存开始测试。这些数量计为约 18 个 `i3.4xlarge.search` 实例。如果您不需要快速的本地存储，您还可以测试 18 个 `r6g.4xlarge.search` 实例，每个实例使用 1TiB EBS 存储卷。
如果您的群集包含数百 TB 的数据，请参阅[Amazon 服务中的 PB 级规模 OpenSearch](petabyte-scale.md)。
## 步骤 3：执行代表性测试
配置集群后，您可以使用先前计算的分片数[添加索引](indexing.md)，使用真实的数据集执行一些具有代表性的客户端测试，并[监控 CloudWatch 指标](managedomains-cloudwatchmetrics.md)以了解集群如何处理工作负载。
## 步骤 4：成功或迭代
如果性能满足您的需求，测试成功且 CloudWatch 指标正常，则集群已准备就绪。记得[设置 CloudWatch 警报](cloudwatch-alarms.md)以检测不健康的资源使用情况。
如果性能不可接受、测试失败，或者 `CPUUtilization` 或 `JVMMemoryPressure` 很高，则您可能需要选择其他实例类型 (或添加实例) 并继续测试。添加实例时， OpenSearch 会自动重新平衡整个集群中分片的分配。
因为在动力过剩的集群中测量超额容量比在动力不足的集群中测量容量不足更简单，所以我们建议从比您认为您所需的集群更大的集群开始。接下来，测试并缩减为具有额外资源的高效集群，以确保活动增加期间稳定运行。
生产集群或具有复杂状态的集群可从[专用主节点](managedomains-dedicatedmasternodes.md)中受益，从而提高性能和集群可靠性。