本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
选择实例类型和测试
当您计算存储要求并选择您需要的分片数量后，您可以开始进行硬件决策。硬件要求可能因工作负载而差异悬殊，但我们仍然可以提供一些基本建议。
一般而言，每个实例类型的存储限制映射到轻型工作负载可能需要的 CPU 和内存量。例如，某个 m6g.large.search 实例的最大 EBS 卷大小为 512GiB，该实例具有 2 个 vCPU 核心和 8GiB 内存。如果您的群集有许多分片，需要执行税收聚合、频繁更新文档或处理大量查询，则这些资源可能不足以满足您的需求。如果您的集群属于其中一个类别，请尝试从每 100GiB 存储要求更接近 2 个 vCPU 核心和 8GiB 内存的配置开始。
提示
有关分配给每种实例类型的硬件资源的摘要，请参阅 Amazon OpenSearch 服务定价
但是，即使这些资源也可能不足。一些 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 服务中的 PB 级规模 OpenSearch 。
步骤 3：执行代表性测试
配置集群后，您可以使用先前计算的分片数量添加索引，使用真实的数据集执行一些具有代表性的客户端测试，并监控 CloudWatch 指标以了解集群如何处理工作负载。
步骤 4：成功或迭代
如果性能满足您的需求，测试成功且 CloudWatch 指标正常，则集群已准备就绪。记得设置 CloudWatch 警报以检测不健康的资源使用情况。
如果性能不可接受、测试失败，或者 CPUUtilization 或 JVMMemoryPressure 很高，则您可能需要选择其他实例类型 (或添加实例) 并继续测试。添加实例时， OpenSearch 会自动重新平衡整个集群中分片的分配。
因为在动力过剩的集群中测量超额容量比在动力不足的集群中测量容量不足更简单，所以我们建议从比您认为您所需的集群更大的集群开始。接下来，测试并缩减为具有额外资源的高效集群，以确保活动增加期间稳定运行。
生产集群或状态复杂的集群受益于专用管理器节点，从而提高性能和集群可靠性。