ELK相关问题解答

上了生活的贼船，就做快乐的海盗。

---

目录

## 一、ELK简述

## 二、问题一

### node.master与node.data两个属性的四种组合

## 三、问题二

###  3.1 在建设ES Cluster的时候，为什么都是3个节点，为什么不是2个或4个

### 3.2 如果三台机器磁盘存满了，需要扩容节点，是扩容三台机器进去，配置文件又该有哪些调整

---

## 一、ELK简述

        “ELK”是三个开源项目的首字母缩写，这三个项目分别是： Elasticsearch 、 Logstash 和 Kibana 。 Elasticsearch（核心） 是一个搜索和分析引擎。 Logstash 是服务器端数据处理管道，能够同时从多个来源采集 数据，转换数据，然后将数据发送到诸如 Elasticsearch 等 “ 存储库 ” 中。 Kibana 则可以让用户在 Elasticsearch 中使用图形和图表对数据进行可视化。

        Elastic Stack 是 ELK Stack 的更新换代产品。什么是 ELK Stack ？很简单，指的就是 Elastic Stack 。

官网： https://www.elastic.co/cn/products/elasticsearch

## 二、问题一

        ES（Elastic Stack）的配置中有两个参数，一个是node.master, 一个是node.data 分别代表什么意思？

        （1）node.master：这个属性表示节点是否具有主节点的资格

  注：此属性的值为true，并不意味着这个节点就是主节点。因为真正的主节点，是由多个具有主节点资格的节点进行选举产生的。所以，这个属性只是代表这个节点是不是具有主节点选举资格。

        （2）node.data：这个属性表示节点是否存储数据

### node.master与node.data两个属性的四种组合

        （1）这种组合表示这个节点即有成为主节点的资格，又存储数据。这个时候如果某个节点被选举成为了真正的主节点，那么他还要存储数据，这样对于这个节点的压力就比较大了。elasticsearch默认每个节点都是这样的配置，在测试环境下这样做没问题。实际工作中建议不要这样设置，这样相当于主节点和数据节点的角色混合到一块了。

node.master: true
 
node.data: true

        （2）这种组合表示这个节点没有成为主节点的资格，也就不参与选举，只会存储数据。这个节点我们称为data(数据)节点。在集群中需要单独设置几个这样的节点负责存储数据，后期提供存储和查询服务。

node.master: false
 
node.data: true

        （3）这种组合表示这个节点不会存储数据，有成为主节点的资格，可以参与选举，有可能成为真正的主节点。这个节点我们称为master节点。

node.master: true
 
node.data: false

       （4）这种组合表示这个节点即不会成为主节点，也不会存储数据，这个节点的意义是作为一个client(客户端)节点，主要是针对海量请求的时候可以进行负载均衡。

node.master: false
 
node.data: false

        默认情况下，每个节点都有成为主节点的资格，也会存储数据，还会处理客户端的请求。在一个生产集群中我们可以对这些节点的职责进行划分。

## 三、问题二

        在建设ES Cluster的时候，为什么都是3个节点，如果单纯是集群管理的话，两个节点也是集群，为什么是3个，不是两个或者4个，两台机器不是更方便吗，就只改两台机器的配置就好了。

###  3.1 在建设ES Cluster的时候，为什么都是3个节点，为什么不是2个或4个

脑裂：

        如果发生网络中断或者服务器宕机，那么集群会有可能被划分为两个部分，各自有自己的master来管理，那么这就是脑裂。例如：服务器一是Master宕机了，此时服务器二就有可能被选举成Master，但是当服务器一恢复后，不会变成slave加入原先的集群，还是Master单独存在，之后服务器一就会被单独出来成为新的集群。

脑裂解决方案：

        master主节点要经过多个master节点共同选举后才能成为新的主节点。就跟班级里选班长一样，并不是你1个人能决定的，需要班里半数以上的人决定。
解决实现原理：半数以上的节点同意选举，节点方可成为新的master。discovery.zen.minimum_master_nodes=(N/2)+1
N为集群的中master节点的数量，也就是那些 node.master=true 设置的那些服务器节点总数。

原因：

1. 故障转移协商和脑裂
2. 存储
3. 性能和成本效益
4. 滚动更新

        性能和成本效益是指，如果某个节点在三节点群集中发生故障，则只有三分之一的群集资源会消失。

1、故障转移协商和脑裂

        在双节点群集中，群集逻辑更难确定在存在通信（网络）问题而不是节点故障时要执行的操作。如果群集节点彼此之间失去通信，节点如何知道是否从无法与之通信的节点故障转移工作负载？通常，这是通过某种群集见证来处理的。集群见证（或在某些情况下的多个见证人）是第三个接触点，理论上，它仍然可以通过一个或两个节点联系，并且可以仲裁集群状态。见证服务器必须位于群集外部，因此除了群集之外，它将成为网络中要管理的另一个对象。

        如前所述，这在“理论上”有效，但实际上，它更复杂。与真正的第三个节点不同，群集见证服务器并不是群集的真正完全活动成员，并且其对群集状态的评估也可能受到通信问题的阻碍。糟糕的见证实施可能会使群集陷入可怕的裂脑场景，其中两个节点都开始运行所有工作负载，一旦发生这种情况，恢复将是一场噩梦。1 为了进一步阅读，本文探讨了基于强化企业级服务器与双节点备用服务器对/集群的架构与集成自主超融合系统

（如 Scale Computing Platform）的架构的成本和运营优缺点。

        至少具有三个节点可以确保群集始终具有节点仲裁，以维护正常运行的主动群集。对于两个节点，仲裁不存在。没有它，就不可能可靠地确定既能最大限度地提高可用性又能防止数据损坏的行动方案。当然，没有什么是绝对可靠的，即使是三节点群集也可能因网络问题和仲裁丢失而脱机。但是，如果发生这种情况，则可能会发生比群集脱机更大的问题，并且使用三节点群集进入裂脑方案的可能性几乎为零。

2，存储

        据已经说明的成本效益，您可能会问：“如果我使用 SAN 或 NAS 等共享存储设备，该怎么办？嗯，曾经有一段时间，这是创建高可用性集群的唯一方法，但时代已经改变。如果您使用共享存储设备，则只需将成本转移到单独的硬件上即可。您的存储设备是否也群集以实现高可用性，或者它现在是群集的单点故障？

        存储也应群集以实现高可用性，现在您具有相同的双节点群集注意事项。例外情况是，对于存储，您始终希望复制因子至少为 2，这意味着无论您有多少节点，您的可用存储都将始终小于原始存储的 50%。与两个节点相比，使用三个节点不会获得更好的资源效率，但确实可以获得更好的高可用性。

        用于群集的共享存储设备在软件定义存储的现代世界中是一个过时的想法。通过在群集节点上使用软件定义的存储和存储资源，将存储分布在群集中的三个或更多节点上比尝试单独群集多个存储设备要容易得多。它也更具成本效益。

3、性能和成本效益

        考虑建立双节点群集所需的资源。你可以决定在群集的两个节点之间拆分工作负载（称为主动/主动群集），但由于其中一个节点都可能发生故障，因此另一个节点必须能够随时承担所有群集工作负载（VM 和数据）。这意味着每个节点都需要足够的资源来运行所有组合的工作负载，以及维持正常运行和允许额外增长的一些开销。这意味着运行所有内容所需的所有 CPU、RAM 和存储。

        在双节点群集中，实际计算资源使用率始终需要小于群集中可用资源的 50%（实际上可能小于 45%，因此每个节点至少有 10% 的可用资源）。与三节点群集相比，在某些情况下，您可以使用多达 67% 或更多，并且仍然可以吸收全节点故障。如果某个节点在三节点群集中发生故障，则只有三分之一的群集资源会消失。当丢失节点中的工作负载故障转移到剩余的两个节点时，可以在剩余的两个节点之间拆分它们，并且剩余的两个节点可以比单个剩余节点更轻松地分担资源负担。

        当一个节点在三节点群集中发生故障时，您只剩下两个节点，就像双节点群集一样，但是，在还原丢失的节点之前，另一个节点发生故障的可能性非常小，您不必在资源分配中考虑它。您只需要考虑一次发生故障的三个节点中的一个。将资源分散到三个节点而不是两个节点上意味着每个节点永远不会运行整个群集工作负载，并且服务器规格不需要那么高即可保持可接受或等效的性能，从而节省购买服务器的成本。

        另一个需要考虑的性能因素是重建故障节点的性能成本，这在双节点群集中尤为严重。当两个节点中的一个发生故障时，另一个节点不仅必须承担所有群集工作负载，直到另一个节点恢复，而且还必须在恢复的节点重新联机时重建该节点，发送数据，直到该节点再次成为完全冗余的伙伴。这会给运行所有群集工作负载的群集的主动节点带来额外的性能负载，直到其他节点完全恢复。在三节点群集中，修复过程不太重要，因为即使第三个节点发生故障，其余两个节点仍继续充当群集。存储仍然可以保持冗余，当第三个节点恢复时，跨群集

重新平衡数据和工作负载所需的重建强度要低得多。

4、滚动更新

        群集还可以提供将更新应用于单个节点的功能，而无需通过先将这些工作负载移动到群集的另一个节点来使群集工作负载脱机。这称为滚动更新，因为工作负载在更新发生时从一个节点滚动到另一个节点。在双节点群集中，此过程始终仅限于在更新时将所有工作负载移动到单个节点。

        在真正的故障/故障转移情况下（比更新更不常见），您更有可能忍受性能降级，因为强制单个节点运行每个工作负载可能会强调其资源限制。您是否也愿意在每次要使用新软件/固件更新群集时忍受性能下降？应该不会。因此，除了需要指定每个节点足够大以运行故障转移方案中的每个工作负载之外，还必须考虑每次需要应用更新时，规范需要多大才能轻松运行所有工作负载。规格越大，成本越高。

        在三节点群集中，由于您有两个其他节点在故障转移或更新期间拆分工作负载，因此当节点脱机进行维护时，您可以以较低的规格和更低的成本提供合理的性能。

原因：

 1. 容错性与高可用性：

•避免单点故障：在只有两个节点的集群中，任何一个节点的故障都会导致集群失去半数以上的节点，可能导致集群无法正常工作或进入只读模式（取决于集群的配置）。而拥有3个节点的集群，即使有一个节点宕机，剩下的两个节点仍然可以维持多数派（quorum），确保集群的写入操作继续进行，保持服务的高可用性。

•数据冗余与恢复：对于分布式存储系统，通常需要数据冗余以应对节点故障导致的数据丢失。在ES的默认设置中，索引的数据会被分片（shard）并复制（replica）。每个分片至少有一个副本。在3节点集群中，即使有一个节点离线，每个分片的主分片和副本分片仍能在剩余的两个节点上保持分布，确保数据的完整性和查询服务的可用性。

2. 数据一致性与选举机制：

•避免脑裂（Split Brain）：在只有两个节点的集群中，一旦网络分区（partition）发生，可能导致两个节点各自认为自己是多数派，形成两个独立的集群（即脑裂现象），造成数据不一致。拥有3个节点时，即使网络出现短暂的分区，也更容易确保只有一个集群能够达到多数派，从而避免脑裂问题。

•主分片选举：当主分片节点不可用时，需要选举新的主分片。在3节点集群中，选举过程更为可靠，因为即使一个节点无法参与选举，剩余的两个节点依然可以达成共识，选出新的主分片。

3. 资源利用率与成本考量：

•资源平衡：增加第3个节点可以更均匀地分布系统负载，提高资源利用率。在2节点集群中，如果一个节点故障，剩余节点需要承载全部负载，可能导致资源紧张。而3节点集群在单节点故障时，剩余节点只需承担额外50%的负载，压力相对较小。

•经济性：虽然增加第3个节点会带来一定的硬件成本和运维成本，但相对于集群的稳定性和数据安全而言，这是必要的投资。而且，相对于增加更多节点（如4个或更多），3节点集群在成本效益上往往更具吸引力，因为增加节点带来的边际收益递减，而成本却在增加。

        综上所述，建设ES集群时选择3个节点，是在容错性、高可用性、数据一致性、资源利用率和成本之间权衡的结果。尽管从配置数量上看，两台机器似乎更方便，但在实际运行和维护中，3节点集群能够提供更高的稳定性和数据安全保障，这对于大多数生产环境来说是至关重要的。当然，具体节点数量的选择还需根据实际业务需求、数据规模、可用预算等因素综合考虑。在某些特定场景下，可能需要更多或更少的节点来满足特定需求。

        一个节点启动之后， 采用 Zen Discovery机制去寻找集群中的其他节点， 并与之建立连接， 集群会从候选主节点中选举出一个主节点， 并且一个集群只能选举一个主节点， 在某些情况下， 由于网络通信丢包等问题， 一个集群可能会出现多个主节点， 称为“脑裂现象”， 脑裂会存在丢失数据的可能， 因为主节点拥有最高权限， 它决定了什么时候可以创建索引， 分片如何移动等， 如果存在多个主节点， 就会产生冲突， 容易产生数据丢失。

        要尽量避免这个问题， 可以通过discovery.zen.minimum_master_nodes 来设置最少可工作的候选主节点个数（即节点获得的票数必须大于该值才能成为master）。 建议设置为（候选主节点/2） + 1 比如三个候选主节点，该配置项为 （3/2）+1 ,来保证集群中有半数以上的候选主节点， 没有足够的master候选节点， 就不会进行master节点选举，减少脑裂的可能。

### 3.2 如果三台机器磁盘存满了，需要扩容节点，是扩容三台机器进去，配置文件又该有哪些调整

        在Elasticsearch集群中，当现有节点的磁盘空间不足，需要进行节点扩容时，可以按照以下步骤进行操作，并对相关配置文件进行适当调整：

1. 硬件准备：

•准备好三台具有足够磁盘空间的新服务器或虚拟机，确保它们的硬件配置（如CPU、内存）与现有集群节点相当或更高，以保持集群性能的均衡。

2. 安装Elasticsearch：

•在新节点上安装与现有集群相同版本的Elasticsearch。

3. 配置文件调整：

•elasticsearch.yml：

•设置集群名称（cluster.name），确保与现有集群一致，以便新节点能加入到正确的集群。

•设置节点名称（node.name），为每个新节点指定一个唯一名称，避免与现有节点重复。

•设置网络配置（network.host、network.publish_host、transport.host等），确保新节点与其他节点间能够正常通信。

•如果有特定的节点角色（如主节点、数据节点、协调节点等），需设置相应的参数（如node.master、node.data、node.voting_only等）。

•如果使用了自定义的路径（如数据路径、日志路径等），需设置相应的路径参数（如path.data、path.logs等）。

•重要：如果使用了任何插件，确保在新节点上也安装相同的插件版本。

4. 数据分片与副本调整：

•可选：如果原集群的分片与副本设置不足以应对新增节点后的容量需求，可以考虑调整索引的分片数量和副本系数。这通常涉及以下步骤：

•使用PUT _settings API 更新索引的index.number_of_shards（分片数量）和index.number_of_replicas（副本系数）。注意，调整分片数量通常只能在创建索引时进行，后期一般只能调整副本系数。

•调整后，Elasticsearch会自动进行分片的重新分配，以充分利用新增节点的存储空间。

5. 加入新节点：

•启动新节点上的Elasticsearch服务。

•新节点会自动发现并加入到现有的集群中，可以通过GET _cat/nodes?v命令查看节点状态，确认新节点已成功加入。

6. 监控与调整：

•在新节点加入集群后，密切关注集群状态（GET _cluster/health）、分片分配情况（GET _cat/shards?v）以及节点资源使用情况（如CPU、内存、磁盘空间等）。

•根据实际情况，可能需要进一步调整索引的分片分配策略、节点的角色分配等，以优化集群性能和资源利用率。

        总结来说，扩容ES集群时，主要是准备新节点、安装Elasticsearch、配置文件调整、数据分片与副本调整、加入新节点以及后续的监控与调整。确保新节点与现有集群在版本、配置、插件等方面保持一致，并根据实际需求调整分片与副本设置，以充分利用新增节点的存储空间。在整个过程中，密切监控集群状态，确保扩容过程平稳进行。