Link Search Menu Expand Document Documentation Menu
文档

创建集群

在深入了解 OpenSearch 并搜索和聚合数据之前，您首先需要创建一个 OpenSearch 集群。

OpenSearch 可以作为单节点或多节点集群运行。配置这两种集群的步骤通常非常相似。本页将演示如何创建和配置多节点集群，但只需稍作调整，您就可以按照相同的步骤创建单节点集群。

要根据您的要求创建和部署 OpenSearch 集群，了解节点发现和集群形成的工作原理以及管理它们的设置非常重要。

设计集群有多种方法。下图展示了一个基本架构，其中包括一个四节点集群，该集群有一个专用集群管理器节点、一个专用协调节点，以及两个既可以是集群管理器又用于摄入数据的数据节点。

主节点现在被称为集群管理器节点。

multi-node cluster architecture diagram

节点

下表简要描述了节点类型

节点类型 描述 生产环境的最佳实践
集群管理器 管理集群的整体操作并跟踪集群状态。这包括创建和删除索引，跟踪加入和离开集群的节点，检查集群中每个节点的健康状况（通过运行 ping 请求），以及将分片分配给节点。 在三个不同区域中设置三个专用集群管理器节点是几乎所有生产用例的正确方法。这种配置确保您的集群永远不会失去法定人数。除了一个节点宕机或需要维护之外，两个节点在大部分时间都将处于空闲状态。
集群管理器资格 通过投票过程在其间选举一个节点作为集群管理器节点。 对于生产集群，请确保您有专用的集群管理器节点。实现专用节点类型的方法是将所有其他节点类型标记为 false。在这种情况下，您必须将所有其他节点标记为不具备集群管理器资格。
数据 存储和搜索数据。对本地分片执行所有数据相关操作（索引、搜索、聚合）。这些是集群的工作节点，需要比任何其他节点类型更多的磁盘空间。 添加数据节点时，请确保它们在区域之间保持平衡。例如，如果您有三个区域，请以三的倍数添加数据节点，每个区域一个。我们建议使用存储和内存密集型节点。
摄入 在将数据存储到集群之前对其进行预处理。运行一个摄入管道，在将数据添加到索引之前对其进行转换。 如果您计划摄入大量数据并运行复杂的摄入管道，我们建议您使用专用的摄入节点。您还可以选择将索引操作从数据节点卸载，以便您的数据节点专门用于搜索和聚合。
协调 将客户端请求委托给数据节点上的分片，收集并聚合结果为一个最终结果，然后将此结果发送回客户端。 对于搜索密集型工作负载，使用几个专用的协调节点是合适的，以防止瓶颈。我们建议使用尽可能多核的 CPU。
动态 将特定节点委托用于自定义工作，例如机器学习 (ML) 任务，从而防止消耗数据节点的资源，因此不会影响任何 OpenSearch 功能。  
Warm 提供对可搜索快照的访问。它结合了诸如频繁缓存使用过的段和删除最少使用的数据段等技术，以便访问可搜索快照索引（存储在远程长期存储源中，例如 Amazon Simple Storage Service [Amazon S3] 或 Google Cloud Storage）。 搜索节点包含一个分配为快照缓存的索引。因此，我们建议使用专用节点，这些节点应具有比存储容量（硬盘）更多的计算能力（CPU 和内存）。
搜索 搜索节点是专用节点，仅托管搜索副本分片，有助于将搜索工作负载与索引工作负载分离。 由于搜索节点托管搜索副本并处理搜索流量，我们建议将它们用于专用内存优化实例。

默认情况下，每个节点都是集群管理器资格、数据、摄入和协调节点。决定节点数量、分配节点类型以及为每种节点类型选择硬件取决于您的用例。您必须考虑诸如您希望保留数据的时间量、文档的平均大小、您的典型工作负载（索引、搜索、聚合）、您预期的性价比、您的风险承受能力等因素。

在评估所有这些要求之后，我们建议您使用像 OpenSearch Benchmark 这样的基准测试工具来配置一个小型示例集群，并使用不同的工作负载和配置运行测试。比较和分析这些测试的系统和查询指标，以设计一个最佳架构。

本页演示如何使用不同的节点类型。它假定您有一个类似于前述插图的四节点集群。

先决条件

在开始之前，您必须在所有节点上安装和配置 OpenSearch。有关可用选项的信息，请参阅安装和配置 OpenSearch。

完成后，使用 SSH 连接到每个节点，然后打开 config/opensearch.yml 文件。您可以在此文件中设置集群的所有配置。

步骤 1：命名集群

为集群指定一个唯一的名称。如果您未指定集群名称，则默认设置为 opensearch。设置一个描述性的集群名称很重要，特别是当您希望在单个网络中运行多个集群时。

要指定集群名称，请更改以下行

#cluster.name: my-application

为

cluster.name: opensearch-cluster

在所有节点上进行相同的更改，以确保它们将加入以形成集群。

步骤 2：为集群中的每个节点设置节点属性

命名集群后，为集群中的每个节点设置节点属性。

集群管理器节点

为您的集群管理器节点命名。如果您未指定名称，OpenSearch 将分配一个机器生成的名称，这会使节点难以监控和排除故障。

node.name: opensearch-cluster_manager

您还可以明确指定此节点是集群管理器节点，即使它默认已设置为 true。将节点角色设置为 cluster_manager，以便更容易识别集群管理器节点。

node.roles: [ cluster_manager ]

数据节点

将两个节点的名称分别更改为 opensearch-d1 和 opensearch-d2

node.name: opensearch-d1

node.name: opensearch-d2

您可以将它们设为具有集群管理器资格的数据节点，这些节点也将用于摄入数据

node.roles: [ data, ingest ]

您还可以为数据节点设置任何其他属性。

协调节点

将协调节点的名称更改为 opensearch-c1

node.name: opensearch-c1

默认情况下，每个节点都是协调节点，因此要将此节点设为专用协调节点，请将 node.roles 设置为空列表

node.roles: []

步骤 3：将集群绑定到特定的 IP 地址

network.bind_host 定义用于绑定节点的 IP 地址。默认情况下，OpenSearch 在本地主机上侦听，这限制了集群只能是单节点。您还可以使用 _local_ 和 _site_ 绑定到任何回环或站点本地地址，无论是 IPv4 还是 IPv6

network.bind_host: [_local_, _site_]

要形成多节点集群，请指定节点的 IP 地址

network.bind_host: <IP address of the node>

确保在所有节点上配置这些设置。

步骤 4：配置集群的发现主机和初始集群管理器节点

现在您已配置网络主机，您需要配置发现主机并为初始集群选举指定集群管理器节点。请注意，这是节点名称，而不是 IP 地址、主机名或完全限定主机名。

例如，该设置如下所示

cluster.initial_cluster_manager_nodes: ["opensearch-cluster_manager"]

Zen Discovery 是内置的默认机制，它使用 单播来查找集群中的其他节点。

您通常可以将所有具有集群管理器资格的节点添加到 discovery.seed_hosts 数组中。当一个节点启动时，它会找到其他具有集群管理器资格的节点，确定哪个是集群管理器，并请求加入集群。

例如，对于 opensearch-cluster_manager，该行看起来像这样

discovery.seed_hosts: ["<private IP of opensearch-d1>", "<private IP of opensearch-d2>", "<private IP of opensearch-c1>"]

步骤 5：启动集群

设置配置后，在所有节点上启动 OpenSearch

sudo systemctl start opensearch.service

从 tar 存档安装 OpenSearch 不会自动创建 systemd 服务。如果您收到类似 Failed to start opensearch.service: Unit not found. 的错误，请参阅使用 systemd 运行 OpenSearch 服务以获取有关如何创建和启动服务的说明。

然后查看日志文件以了解集群的形成情况

less /var/log/opensearch/opensearch-cluster.log

在任何节点上执行以下 _cat 查询，以查看所有已形成集群的节点

curl -XGET https://<private-ip>:9200/_cat/nodes?v -u 'admin:<custom-admin-password>' --insecure

ip             heap.percent ram.percent cpu load_1m load_5m load_15m node.role cluster_manager name
x.x.x.x           13          61   0    0.02    0.04     0.05 mi        *      opensearch-cluster_manager
x.x.x.x           16          60   0    0.06    0.05     0.05 md        -      opensearch-d1
x.x.x.x           34          38   0    0.12    0.07     0.06 md        -      opensearch-d2
x.x.x.x           23          38   0    0.12    0.07     0.06 md        -      opensearch-c1

要更好地理解和监控您的集群，请使用 CAT API。

(高级) 步骤 6：配置分片分配感知或强制感知

为了进一步微调您的分片分配，您可以为分片分配感知或强制感知设置自定义节点属性。

分片分配感知

您可以在 OpenSearch 节点上设置自定义节点属性，以用于分片分配感知。例如，您可以在每个节点上设置 zone 属性，以表示节点所在的区域。您还可以使用 zone 属性来确保主分片及其副本分片在可用、不同区域之间均衡分配。在这种情况下，每个区域的最大分片副本数将等于 ceil (number_of_shard_copies/number_of_distinct_zones)。

默认情况下，OpenSearch 将单个分片的分片副本分配到不同的节点。当只有一个区域可用时（例如在区域故障后），OpenSearch 会将副本分片分配到唯一剩余的区域——它在计算每个区域允许的最大分片副本数时只考虑可用区域（属性值）。

例如，如果您的索引总共有 5 个分片副本（1 个主分片和 4 个副本分片），并且节点位于 3 个不同的区域中，那么 OpenSearch 将执行以下操作来分配所有 5 个分片副本

  • 每个区域分配不超过 2 个分片，这将要求在 2 个区域中至少有 2 个节点。
  • 将最后一个分片分配到第三个区域，第三个区域至少需要 1 个节点。

或者，如果您在第一个区域有 3 个节点，并在每个剩余区域有 1 个节点，那么 OpenSearch 将分配

  • 第一个区域 2 个分片副本。
  • 剩余 2 个区域各 1 个分片副本。

由于缺少节点，最后一个分片副本将保持未分配状态。

通过分片分配感知，如果某个区域中的节点发生故障，您可以确保您的副本分片分布在其他区域中，从而增加一层容错能力，以确保您的数据在区域故障中幸存下来。

要配置分片分配感知，请分别向 opensearch-d1 和 opensearch-d2 添加区域属性

node.attr.zone: zoneA

node.attr.zone: zoneB

更新集群设置

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.awareness.attributes": "zone"
  }
}

您还可以通过提供逗号分隔的属性字符串（例如 zone,rack）来使用多个属性进行分片分配感知。

您可以使用 persistent 或 transient 设置。我们推荐使用 persistent 设置，因为它在集群重启后仍然存在。临时设置在集群重启后不会保留。

分片分配感知试图将主分片和副本分片分离到多个区域。但是，如果只有一个区域可用（例如在区域故障后），OpenSearch 会将副本分片分配到唯一剩余的区域。

强制感知

另一种选择是要求主分片和副本分片永远不会分配到同一个区域。这称为强制感知。

要配置强制感知，请指定区域属性的所有可能值

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.awareness.attributes": "zone",
    "cluster.routing.allocation.awareness.force.zone.values":["zoneA", "zoneB"]
  }
}

现在，如果一个数据节点发生故障，强制感知不会将副本分配到同一区域的节点。相反，集群会进入黄色状态，并且只有当其他区域的节点上线时才会分配副本。

在我们的双区域架构中，如果 opensearch-d1 和 opensearch-d2 的利用率低于 50%，我们可以使用分配感知，以便它们各自有足够的存储容量在同一区域分配副本。如果不是这种情况，并且 opensearch-d1 和 opensearch-d2 没有容量容纳所有主分片和副本分片，我们可以使用强制感知。这种方法有助于确保在发生故障时，OpenSearch 不会使您最后剩余的区域过载，也不会因存储不足而锁定您的集群。

选择分配感知还是强制感知取决于您在每个区域中需要多少空间来平衡您的主分片和副本分片。

副本计数强制执行

为了在所有区域强制实现分片的均匀分布并避免热点，您可以将 routing.allocation.awareness.balance 属性设置为 true。此设置可以在 opensearch.yml 文件中配置，并使用集群更新设置 API 动态更新。

PUT _cluster/settings
{
  "persistent": {
    "cluster": {
      "routing.allocation.awareness.balance": "true"
    }
  }
}

默认情况下，routing.allocation.awareness.balance 设置为 false。当它设置为 true 时，索引的分片总数必须是任何感知属性最高计数的倍数。例如，考虑一个具有两个感知属性（区域和机架 ID）的配置。假设有两个区域和三个机架 ID。区域数量或机架 ID 数量的最高计数是三。因此，分片数量必须是三的倍数。如果不是，OpenSearch 将抛出验证异常。

routing.allocation.awareness.balance 仅在设置了 cluster.routing.allocation.awareness.attributes 和 cluster.routing.allocation.awareness.force.zone.values 时才生效。

routing.allocation.awareness.balance 适用于所有创建或更新索引的操作。例如，假设您正在运行一个具有三个节点和三个区域的集群，并且启用了区域感知设置。如果您尝试创建一个带有一个副本的索引，或者将索引设置更新为一个副本，那么尝试将因验证异常而失败，因为分片数量必须是三的倍数。类似地，如果您尝试创建一个带有一个分片且没有副本的索引模板，尝试将因同样的原因而失败。然而，在所有这些操作中，如果您将分片数量设置为一，将副本数量设置为二，那么分片总数是三，尝试将成功。

(高级) 步骤 7：设置热温架构

您可以设计一种热温架构，其中您首先将数据索引到热节点（快速且昂贵），并在一定时间后将其移动到温节点（慢速且便宜）。

如果您分析很少更新的时间序列数据，并且希望将旧数据存储到更便宜的存储中，那么这种架构可能是一个很好的选择。

这种架构有助于节省存储成本。您无需增加热节点的数量并使用快速、昂贵的存储，而是可以为不经常访问的数据添加温节点。

要配置热温存储架构，请分别向 opensearch-d1 和 opensearch-d2 添加 temp 属性

node.attr.temp: hot

node.attr.temp: warm

您可以将属性名称和值设置为任何您想要的值，只要它在所有热节点和温节点上保持一致即可。

将索引 newindex 添加到热节点

PUT newindex
{
  "settings": {
    "index.routing.allocation.require.temp": "hot"
  }
}

查看 newindex 的以下分片分配情况

GET _cat/shards/newindex?v
index     shard prirep state      docs store ip         node
new_index 2     p      STARTED       0  230b 10.0.0.225 opensearch-d1
new_index 2     r      UNASSIGNED
new_index 3     p      STARTED       0  230b 10.0.0.225 opensearch-d1
new_index 3     r      UNASSIGNED
new_index 4     p      STARTED       0  230b 10.0.0.225 opensearch-d1
new_index 4     r      UNASSIGNED
new_index 1     p      STARTED       0  230b 10.0.0.225 opensearch-d1
new_index 1     r      UNASSIGNED
new_index 0     p      STARTED       0  230b 10.0.0.225 opensearch-d1
new_index 0     r      UNASSIGNED

在此示例中，所有主分片都分配给 opensearch-d1，这是我们的热节点。所有副本分片都未分配，因为我们强制此索引仅分配给热节点。

将索引 oldindex 添加到温节点

PUT oldindex
{
  "settings": {
    "index.routing.allocation.require.temp": "warm"
  }
}

oldindex 的分片分配

GET _cat/shards/oldindex?v
index     shard prirep state      docs store ip        node
old_index 2     p      STARTED       0  230b 10.0.0.74 opensearch-d2
old_index 2     r      UNASSIGNED
old_index 3     p      STARTED       0  230b 10.0.0.74 opensearch-d2
old_index 3     r      UNASSIGNED
old_index 4     p      STARTED       0  230b 10.0.0.74 opensearch-d2
old_index 4     r      UNASSIGNED
old_index 1     p      STARTED       0  230b 10.0.0.74 opensearch-d2
old_index 1     r      UNASSIGNED
old_index 0     p      STARTED       0  230b 10.0.0.74 opensearch-d2
old_index 0     r      UNASSIGNED

在这种情况下，所有主分片都分配给 opensearch-d2。同样，所有副本分片都未分配，因为我们只有一个温节点。

一种常见方法是配置您的索引模板，将 index.routing.allocation.require.temp 值设置为 hot。这样，OpenSearch 会将您最新的数据存储在热节点上。

然后，您可以使用索引状态管理 (ISM) 插件定期检查索引的年龄并指定对其执行的操作。例如，当索引达到特定年龄时，将 index.routing.allocation.require.temp 设置更改为 warm，以便自动将数据从热节点移动到温节点。

后续步骤

如果您正在使用安全插件，之前对 _cat/nodes?v 的请求可能已因初始化错误而失败。有关使用安全插件的完整指南，请参阅安全配置。

剩余 350 字符

有问题？。

想要贡献？或。