Elasticsearch 中的热点以及如何使用 AutoOps 解决它们

作者:来自 Elastic Sachin Frayne

探索 Elasticsearch 中的热点以及如何使用 AutoOps 解决它。

Elasticsearch 集群中出现热点的方式有很多种。有些我们可以控制,比如吵闹的邻居,有些我们控制得较差,比如 Elasticsearch 中的分片分配算法。好消息是,新的 desire_balance cluster.routing.allocation.type 算法(参见 shards-rebalancing-heuristics)在确定集群中的哪些节点应该获得新分片方面要好得多。如果存在不平衡,它会为我们找出最佳平衡。坏消息是,较旧的 Elasticsearch 集群仍在使用平衡(balanced)分配算法,该算法的计算能力较有限,在选择节点时容易出错,从而导致集群不平衡或出现热点。

在这篇博客中,我们将探讨这种旧算法,它应该如何工作以及何时不起作用,以及我们可以做些什么来解决这个问题。然后,我们将介绍新算法以及它如何解决这个问题,最后,我们将研究如何使用 AutoOps 来针对客户用例突出显示这个问题。然而,我们不会深入探讨热点的所有原因,也不会深入探讨所有具体的解决方案,因为它们太多了。

什么是 AutoOps?

平衡分配

在 Elasticsearch 8.5 及更早版本中,我们使用以下方法来确定在哪个节点放置分片,此方法主要归结为选择分片数量最少的节点:https://github.com/elastic/elasticsearch/blob/8.5/server/src/main/java/org/elasticsearch/cluster/routing/allocation/allocator/BalancedShardsAllocator.java#L242

float weight(Balancer balancer, ModelNode node, String index) {final float weightShard = node.numShards() - balancer.avgShardsPerNode();final float weightIndex = node.numShards(index) - balancer.avgShardsPerNode(index);return theta0 * weightShard + theta1 * weightIndex;
}
  • node.numShards():分配给集群中特定节点的分片数量
  • balancer.avgShardsPerNode():集群中所有节点的分片平均值
  • node.numShards(index):分配给集群中特定节点的特定索引的分片数量
  • balancer.avgShardsPerNode(index):集群中所有节点的特定索引的分片平均值
  • theta0:(cluster.routing.allocation.balance.shard) 分片总数的权重因子,默认为 0.45f,增加该值会增加均衡每个节点分片数量的趋势(请参阅  Shard balancing heuristics settings)
  • theta1:(cluster.routing.allocation.balance.index) 每个索引分片总数的权重因子,默认为 0.55f,增加该值会增加均衡每个索引分片数量的趋势每个节点(请参阅 Shard balancing heuristics settings)

该算法在整个集群中的目标值是以这样的方式选择一个节点,使得集群中所有节点的权重回到 0 或最接近 0。

示例

让我们探讨这样一种情况:我们有 2 个节点,其中 1 个索引由 3 个主分片组成,并且假设我们在节点 1 上有 1 个分片,在节点 2 上有 2 个分片。当我们向具有 1 个分片的集群添加新索引时会发生什么?

由于新索引在集群中的其他任何地方都没有分片,因此 weightIndex 项减少到 0,我们可以在下一个计算中看到,将分片添加到节点 1 将使余额回到 0,因此我们选择节点 1。

现在让我们添加另一个包含 2 个分片的索引,由于现在已达到平衡,因此第一个分片将随机分配到其中一个节点。假设节点 1 被选为第一个分片,则第二个分片将分配到节点 2。

新的平衡最终将是:

如果集群中的所有索引/分片在采集、搜索和存储要求方面都执行大致相同的工作量,则此算法将很好地发挥作用。实际上,大多数 Elasticsearch 用例并不这么简单,并且分片之间的负载并不总是相同的,请想象以下场景。

图 1:Elasticsearch 集群(夸张的分片大小表示分片实际上有多“繁忙”)
  • 索引 1,小型搜索用例,包含几千个文档,分片数量不正确;
  • 索引 2,索引非常大,但未被主动写入且偶尔搜索;
  • 索引 3,轻量级索引和搜索;
  • 索引 4,重度摄取应用程序日志。

假设我们有 3 个节点和 4 个索引,它们只有主分片,并且故意处于不平衡状态。为了直观地了解正在发生的事情,我根据分片的繁忙程度以及繁忙的含义(写入、读取、CPU、RAM 或存储)夸大了分片的大小。即使节点 3 已经拥有最繁忙的索引,新的分片也会路由到该节点。索引生命周期管理 (ILM) 不会为我们解决这种情况,当索引滚动时,新的分片将放置在节点 3 上。我们可以手动缓解这个问题,强制 Elasticsearch 使用集群重新(cluster reroute)路由均匀分布分片,但这无法扩展,因为我们的分布式系统应该处理这个问题。尽管如此,如果没有任何重新平衡或其他干预措施,这种情况将继续存在,并可能变得更糟。此外,虽然这个例子是假的,但这种分布在具有混合用例(即搜索、日志记录、安全)的旧 Elasticsearch 集群中是不可避免的,尤其是当一个或多个用例是重度摄取时,确定何时会发生这种情况并不是一件容易的事。

虽然预测这个问题的时间范围很复杂,但在某些情况下行之有效的一个好的解决方案是保持所有索引的分片密度相同,这是通过在所有索引的分片达到预定大小(以 GB 为单位)时滚动所有索引来实现的(请参阅分片大小 -  size your shards)。这并不适用于所有用例,正如我们将在下面 AutoOps 捕获的集群中看到的那样。

所期望的平衡分配

为了解决这个问题和其他一些问题,一种可以同时考虑写入负载和磁盘使用情况的新算法最初在 8.6 中发布,并在 8.7 和 8.8 版本中进行了一些微小但有意义的更改:https://github.com/elastic/elasticsearch/blob/8.8/server/src/main/java/org/elasticsearch/cluster/routing/allocation/allocator/BalancedShardsAllocator.java#L305

float weight(Balancer balancer, ModelNode node, String index) {final float weightShard = node.numShards() - balancer.avgShardsPerNode();final float weightIndex = node.numShards(index) - balancer.avgShardsPerNode(index);final float ingestLoad = (float) (node.writeLoad() - balancer.avgWriteLoadPerNode());final float diskUsage = (float) (node.diskUsageInBytes() - balancer.avgDiskUsageInBytesPerNode());return theta0 * weightShard + theta1 * weightIndex + theta2 * ingestLoad + theta3 * diskUsage;
}
  • node.writeLoad():特定节点的写入或索引负载
  • balancer.avgWriteLoadPerNode():整个集群的平均写入负载
  • node.diskUsageInBytes():特定节点的磁盘使用情况
  • balancer.avgDiskUsageInBytesPerNode():整个集群的平均磁盘使用情况
  • theta2:(cluster.routing.allocation.balance.write_load)写入负载的权重因子,默认为 10.0f,增加该值会增加均衡每个节点的写入负载的趋势(请参阅 Shard balancing heuristics settings)
  • theta3:(cluster.routing.allocation.balance.disk_usage)磁盘使用情况的权重因子,默认为 2e-11f,增加该值会增加均衡每个节点的磁盘使用情况的趋势(请参阅 Shard balancing heuristics settings)

我不会在本博客中详细介绍此算法所做的计算,但是 Elasticsearch 用于决定分片应位于何处的数据可通过 API 获取:获取所需平衡(Get desired balance)。在调整分片大小时,遵循我们的指导仍然是最佳实践,并且仍然有充分的理由将用例分离到专用的 Elasticsearch 集群中。然而,此算法在平衡 Elasticsearch 方面要好得多,以至于它为我们的客户解决了以下平衡问题。(如果你遇到本博客中描述的问题,我建议你升级到 8.8)。

最后要注意的是,此算法没有考虑搜索负载,这很难衡量,甚至更难预测。6.1 中引入的自适应副本选择(Adaptive replica selection)对解决搜索负载大有帮助。在未来的博客中,我们将深入探讨搜索性能的主题,特别是如何使用 AutoOps 在搜索性能问题发生之前发现它们。

在 AutoOps 中检测热点

上述情况不仅难以预测,而且一旦发生也难以检测,我们需要对 Elasticsearch 有深入的内部了解,并且我们的集群需要满足非常具体的条件才能处于这种状态。

现在,使用 AutoOps 检测这个问题就轻而易举了。让我们看一个真实的例子;

在这个设置中,Elasticsearch 前面有一个排队机制,用于处理数据峰值,但是用例是近实时日志 - 持续的滞后是不可接受的。我们遇到了持续滞后的情况,必须进行故障排除。从集群视图开始,我们获取了一些有用的信息,在下图中我们了解到有 3 个主节点、8 个数据节点(以及 3 个与案例无关的其他节点)。我们还了解到集群是红色的(这可能是网络或性能问题),版本是 8.5.1,有 6355 个分片;最后这两个将在以后变得重要。

图片 2:集群信息

这个集群中发生了很多事情,它经常变成红色,这些都与离开集群的节点有关。节点离开集群的时间大约在我们观察到索引拒绝的时间,并且拒绝发生在索引队列过于频繁地填满后不久,黄色越深,时间块中的高索引事件越多。

图 3:集群中事件的时间线(重点突出数据节点断开连接)

转到节点视图并关注最后一个节点断开连接的时间范围,我们可以看到另一个节点(节点 9)的索引率比其他节点高得多,其次是节点 4,该节点在本月早些时候曾出现过一些断开连接的情况。你还会注意到,在同一时间范围内索引率下降幅度相当大,这实际上也与此特定集群中计算资源和存储之间的间歇性延迟有关。

图4:数据节点9,索引率高。

默认情况下,AutoOps 只会报告断开连接时间超过 300 秒的节点,但我们知道包括节点 9 在内的其他节点经常离开集群,如下图所示,节点上的分片数量增长太快,无法移动分片,因此在节点断开连接/重新启动后,它们必须重新初始化。有了这些信息,我们可以放心地得出结论,集群正在经历性能问题,但不仅仅是热点性能问题。由于 Elasticsearch 以集群的形式工作,它只能以最慢的节点的速度运行,而且由于节点 9 被要求比其他节点做更多的工作,它无法跟上,其他节点总是在等待它,偶尔也会断开连接。

图5:数据节点9,分片数量增加。

此时我们不需要更多信息,但为了进一步说明 AutoOps 的强大功能,下面是另一张图像,该图像显示了节点 9 比其他节点执行了多少工作,特别是它写入磁盘的数据量。

图 6:磁盘写入和 IOPS。

我们决定将所有分片从节点 9 移出,方法是将它们随机发送到集群中的其他节点;这是通过以下命令实现的。此后,整个集群的索引性能得到改善,延迟消失。

PUT /_cluster/settings
{"transient": {"cluster.routing.allocation.exclude._name": "****-data-9"}
}

现在我们已经观察、确认并解决了该问题,我们需要找到一个长期的解决方案,这又让我们回到了博客开头的技术分析。我们遵循最佳实践,分片以预定的大小滚动,甚至限制每个节点特定索引的分片数量。我们遇到了算法无法处理的边缘情况,即索引繁重且频繁滚动的索引。

我们考虑过是否可以手动重新平衡集群,但对于由 6355 个分片组成的约 2000 个索引,这并非易事,更不用说,在这种级别的索引下,我们将与 ILM 竞争重新平衡。这正是新算法的设计目的,因此我们的最终建议是升级集群。

最后的想法

本博客总结了一组相当具体但复杂的情况,这些情况可能会导致 Elasticsearch 性能出现问题。你今天甚至可能会在集群中看到其中一些问题,但可能永远不会像这个用户那样严重地影响集群。这个案例强调了跟上 Elasticsearch 最新版本的重要性,以便始终利用最新的创新来更好地管理数据,它有助于展示 AutoOps 在发现/诊断问题并提醒我们注意问题方面的强大功能,以免它们成为全面生产事件。

考虑迁移到至少 8.8 版 https://www.elastic.co/guide/en/elasticsearch/reference/8.8/migrating-8.8.html

Elasticsearch 包含许多新功能,可帮助你为你的用例构建最佳搜索解决方案。深入了解我们的示例笔记本以了解更多信息,开始免费云试用,或立即在你的本地机器上试用 Elastic。

原文:Hotspots in Elasticsearch and how to resolve them with AutoOps - Search Labs

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/475824.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

Statsmodels之OLS回归

目录 Statsmodels基本介绍OLS 回归实战实战1:实战2: Statsmodels基本介绍 Statsmodels 是 Python 中一个强大的统计分析包,包含了回归分析、时间序列分析、假设检验等等的功能。Statsmodels 在计量的简便性上是远远不及 Stata 等软件的&…

【接口封装】—— 1、加载样式表

函数定义 static void loadStyleSheet(QWidget* widget, const QString &fileName,const QString& otherStyleQString());&#xff08;头文件&#xff09;&#xff1a; #include <qfile.h> #include <QWidget> 源文件: void CommonUtils::loadStyleSheet(…

AI、VR与空间计算:教育和文旅领域的数字转型力量

在这个数字技术高速发展的时代&#xff0c;AI、VR技术及大空间计算技术&#xff0c;已成为推动多个行业革新的强劲动力。近日&#xff0c;世优科技推出了最新研发的VR大空间产品《山海经》&#xff0c;这一全新的沉浸式体验项目不仅重新定义了观展方式&#xff0c;还为文化旅游…

AWTK 最新动态:支持鸿蒙系统(HarmonyOS Next)

HarmonyOS是全球第三大移动操作系统&#xff0c;有巨大的市场潜力&#xff0c;在国产替代的背景下&#xff0c;机会多多&#xff0c;AWTK支持HarmonyOS&#xff0c;让AWTK开发者也能享受HarmonyOS生态的红利。 AWTK全称为Toolkit AnyWhere&#xff0c;是ZLG倾心打造的一套基于C…

数据库、数据仓库、数据湖、数据中台、湖仓一体的概念和区别

数据库、数据仓库、数据湖、数据中台和湖仓一体是数据管理和分析领域的不同概念&#xff0c;各自有不同的特点和应用场景。以下是它们的主要区别&#xff1a; 1. 数据库&#xff08;Database&#xff09; 定义&#xff1a;结构化的数据存储系统&#xff0c;用于高效地存储、检…

Linux运维篇-iscsi存储搭建

目录 概念实验介绍环境准备存储端软件安装使用targetcli来管理iSCSI共享存储 客户端软件安装连接存储 概念 iSCSI是一种在Internet协议上&#xff0c;特别是以太网上进行数据块传输的标准&#xff0c;它是一种基于IP Storage理论的存储技术&#xff0c;该技术是将存储行业广泛…

Django一分钟:django中收集关联对象关联数据的方法

场景&#xff1a;我有一个模型&#xff0c;被其它多个模型关联&#xff0c;我配置了CASCADE级联删除&#xff0c;我想要告知用户删除该实例之后&#xff0c;哪些关联数据将会被一同删除。 假设我们当前有这样一组模型&#xff1a; class Warehouse(models.Model):""…

iPhone 17 Air看点汇总:薄至6mm 刷新苹果轻薄纪录

我们姑且将这款iPhone 17序列的超薄SKU称为“iPhone 17 Air”&#xff0c;Jeff Pu在报告中提到&#xff0c;我同意最近关于 iPhone 17超薄机型采用6 毫米厚度超薄设计的传言。 如果这一测量结果被证明是准确的&#xff0c;那么将有几个值得注意的方面。 首先&#xff0c;iPhone…

Tcp协议Socket编程

&#x1f30e; Tcp协议Socket编程 本次socket编程需要使用到 日志文件&#xff0c;此为具体日志编写过程。以及 线程池&#xff0c;线程池原理比较简单&#xff0c;看注释即可。 文章目录&#xff1a; Tcp协议Socket编程 TCP Socket API简介 构建Tcp_echo_server      …

嵌入式系统中QT实现网络通信方法

大家好,今天主要给大家分享一下,如何使用QT中的网络编程实现。 第一:QT网络编程基本简介 QT中网络模块为提供了可以使用TCP/IP客户端与服务器的类。它提供了较低级别的类,例如代表低级网络概念的 QTcpSocket, QTcpServer 和 QUdpSocket,以及诸如 QNetworkRequest, QNetw…

【卡尔曼滤波】数据预测Prediction观测器的理论推导及应用 C语言、Python实现(Kalman Filter)

【卡尔曼滤波】数据预测Prediction观测器的理论推导及应用 C语言、Python实现&#xff08;Kalman Filter&#xff09; 更新以gitee为准&#xff1a; 文章目录 数据预测概念和适用方式线性系统的适用性 数据预测算法和卡尔曼滤波公式推导状态空间方程和观测器先验估计后验估计…

大模型时代的具身智能系列专题(十三)

迪士尼研究中心 瑞士苏黎世迪斯尼研究中心致力于不同领域的业务活动&#xff0c;其中包括电影、电视、公园和度假村以及消费产品。我们针对所有这些领域进行科研工作。我们开发能使我们将后道生产元素整合到前级生产中的技术。由此可节省许多昂贵的效果&#xff0c;这些效果最…

IDEA2023设置控制台日志输出到本地文件

1、Run->Edit Configurations 2、选择要输出日志的日志&#xff0c;右侧&#xff0c;IDEA2023的Logs在 Modify option 里 选中就会展示Logs栏。注意一定要先把这个日志文件创建出来&#xff0c;不然不会自动创建日志文件的 IDEA以前版本的Logs会直接展示出来 3、但是…

o1的风又吹到多模态,直接吹翻了GPT-4o-mini

开源LLaVA-o1&#xff1a;一个设计用于进行自主多阶段推理的新型VLM。与思维链提示不同&#xff0c;LLaVA-o1独立地参与到总结、视觉解释、逻辑推理和结论生成的顺序阶段。 LLaVA-o1超过了一些更大甚至是闭源模型的性能&#xff0c;例如Gemini-1.5-pro、GPT-4o-mini和Llama-3.…

AJAX的基本使用

AJAX的基本使用 &#x1f389;&#x1f389;&#x1f389;欢迎来到我的博客,我是一名自学了2年半前端的大一学生,熟悉的技术是JavaScript与Vue.目前正在往全栈方向前进, 如果我的博客给您带来了帮助欢迎您关注我,我将会持续不断的更新文章!!!&#x1f64f;&#x1f64f;&#x…

DDei在线设计器V1.2.43版发布

2024-11-21-----V1.2.43 一、bug 修复 1. 修复只读情况下&#xff0c;连线依然可以通过特殊点调整的 bug 2. 修复了同一页面多个实例时&#xff0c;部分方法只会引用最后一个实例的问题 3. 修复了组合控件和容器控件改变容器后没有清理的问题&#xff0c;优化了容器的实现 4. …

C++进阶:哈希表实现

目录 一:哈希表的概念 1.1直接定址法 1.2哈希冲突 1.3负载因子 1.4实现哈希函数的方法 1.4.1除法散列法/除留余数法 1.4.2乘法散列法 1.4.3全域散列法 1.5处理哈希冲突 1.5.1开放地址法 线性探测 二次探测 ​编辑 双重散列 1.5.2链地址法 二.代码实现 2.1开放地址…

鸿蒙NEXT开发案例:血型遗传计算

【引言】 血型遗传计算器是一个帮助用户根据父母的血型预测子女可能的血型的应用。通过选择父母的血型&#xff0c;应用程序能够快速计算出孩子可能拥有的血型以及不可能拥有的血型。这个过程不仅涉及到了简单的数据处理逻辑&#xff0c;还涉及到UI设计与交互体验的设计。 【…

(十八)JavaWeb后端开发案例——会话/yml/过滤器/拦截器

目录 1.业务逻辑实现 1.1 登录校验技术——会话 1.1.1Cookie 1.1.2session 1.1.3JWT令牌技术 2.参数配置化 3.yml格式配置文件 4.过滤器Filter 5.拦截器Interceptor 1.业务逻辑实现 Day10-02. 案例-部门管理-查询_哔哩哔哩_bilibili //Controller层/*** 新增部门*/Pos…

2024.5 AAAiGLaM:通过邻域分区和生成子图编码对领域知识图谱对齐的大型语言模型进行微调

GLaM: Fine-Tuning Large Language Models for Domain Knowledge Graph Alignment via Neighborhood Partitioning and Generative Subgraph Encoding 问题 如何将特定领域知识图谱直接整合进大语言模型&#xff08;LLM&#xff09;的表示中&#xff0c;以提高其在图数据上自…