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

选择实例类型和测试

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

通常，每种实例类型的存储限制与轻型工作负载可能需要的存储量CPU和内存相对应。例如，一个m6g.large.search实例的最大EBS卷大小为 512 GiB，CPU内核为 2 V，内存为 8 GiB。如果您的群集有许多分片，需要执行税收聚合、频繁更新文档或处理大量查询，则这些资源可能不足以满足您的需求。如果您的集群属于这些类别之一，请尝试从更接近 2 v CPU 内核的配置开始，每 100 GiB 的存储需求就有 8 GiB 的内存。

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

步骤 1：进行初步估计

首先，我们建议至少有三个节点，以避免潜在 OpenSearch的问题，例如大脑分裂状态（通信中断导致集群有两个主节点）。如果您有三个专用主节点，我们仍建议至少将两个数据节点用于复制。

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

如果您的存储要求为 184GiB 而建议的最小节点数量为三个，则可以使用等式 184/3 = 61GiB 来找到每个节点需要的存储量。在此示例中，您可以选择三个m6g.large.search实例，每个实例都使用 90-GiB 的EBS存储卷，这样您就有了安全网和一定的增长空间。此配置提供 6 v CPU 内核和 24 GiB 内存，因此适用于较轻的工作负载。

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

如果您的群集包含数百 TB 的数据，请参阅Amazon 服务中的 PB 级规模 OpenSearch 。

步骤 3：执行代表性测试

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

步骤 4：成功或迭代

如果性能满足您的需求，测试成功且 CloudWatch 指标正常，则集群已准备就绪。记得设置 CloudWatch 警报以检测不健康的资源使用情况。

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

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

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