[[321617]]

这里的家是携程网。自从2013年接触ES以来，我们团队实践了0.9之间的各个版本。实时检索分析多个部门200余种日志数据。一路走来，我为大家感到欣慰，也为自己沾沾自喜。

目前，我们最大的单一日志集群有120个数据节点，运行在70台物理服务器上。数据大小如下：

业务高峰时段峰值索引率保持在百万条/秒。历史数据保留期限根据业务需要确定，范围为10天至90天。该集群共有3441个索引，17000个分片，总数据量约9300亿。总磁盘大小为600 多个Kibana 用户消耗1PB，每天有来自Kibana 和第三方的API 调用总计63 万次。查询响应时间百分位为75%:0.160s 90%:1.640s 95%:6.691s 99%:14.0039s。这么大规模的ES Cluster运维，有哪些值得注意的事情呢？

一. 必不可少的工具工欲善其事，必先利其器。从一开始，即使只有几个节点，也应该使用分布式配置管理工具来部署集群。随着应用的成熟和集群规模的逐步扩大，效率的提升将更加突出。官方提供了ES Puppet Module 和Chef Cookbook。熟悉这两个工具的同学可以直接使用。我们自己使用Ansible 并编写了一套playbook 来实现类似的效果。如果熟悉此类工具，集群的初始部署、批量配置更改、集群版本升级、重启故障节点都会更快、更安全。

第二个重要工具是感知插件。该插件直接调用集群的restful API，在检查集群和索引的状态以及更改索引配置时非常方便。语法提示和自动完成功能更加实用，减少浏览文档的频率。在Kibana5中，Sense已经成为内置控制台，不需要额外安装。

二. 硬件配置我们使用具有32vcore CPU + 128GB RAM 的服务器。大多数服务器的磁盘配置是由12个4TB SATA机械磁盘组成的Raid0。几台机器新装了6 800GB SSD raid0。主要目的是做冷热数据分离。后面讲集群架构的时候，我们会进一步讲解如何利用硬件资源。

三. 集群的管理首先需要对ES节点的角色进行划分和隔离。众所周知，ES的数据节点除了存储数据外，还可以充当Master和Client的角色。大多数学生会将这些角色混合到数据节点中。然而，对于拥有大量用户的大规模集群，Master和Client在某些极端使用情况下可能会出现性能瓶颈甚至内存溢出，导致共存的数据节点出现故障。数据节点故障恢复涉及到数据迁移，会消耗集群资源，很容易导致数据写入延迟或查询变慢。如果master和client分离，一旦出现问题，重启后几乎立即恢复，对用户几乎没有影响。另外，这些角色分离后，相应的计算资源消耗也会从数据节点分离出来，更容易掌握数据节点资源消耗与写入量、查询量的关系，方便容量管理和规划。避免过多的并发，包括控制分片和线程池的数量。只要能够满足写入量和查询性能，就为索引分配尽可能少的分片。太多的分片会带来很多负面影响，比如：每次查询后需要汇总和排序的数据较多；并发过多导致线程切换导致CPU消耗过多；索引删除和配置更新速度较慢Issue #18776;太多的分片也会带来更多的小段，太多的小段会带来非常显着的堆内存消耗，特别是配置了很多查询线程的情况下。配置过大的线程池会导致许多奇怪的性能问题。 Issue #18161 中描述的问题是我们所经历过的。默认Theadpool 大小通常效果很好。最好将热数据和冷数据分开。对于日志类型的应用，一般每天都会创建一个新的索引。当天的热门索引在写入的同时也会有更多的查询。如果还有比较久之前的冷数据，当用户进行大跨度的历史数据查询时，过多的磁盘IO和CPU消耗很容易导致写入速度变慢，导致数据延迟。所以我们利用机器的一部分来存储冷数据。我们可以使用ES为节点配置自定义属性，为冷节点添加“boxtype”:“弱”标识符，并每天晚上通过维护脚本更新冷数据。索引路由设置index.routing.allocation.{require|include|exclude}允许数据自动迁移到冷节点。冷数据的特点是不再写入，用户搜索频率较低，但幅度可能很大。比如我们每天有2TB的索引，用户要求保留过去90天的数据以供随时查阅。保持如此大量的索引打开不仅会消耗磁盘空间。 ES为了快速访问磁盘上的索引文件，需要在内存中存储一些数据（索引文件的索引），也就是所谓的段内存。稍微熟悉ES的同学都知道，JVM堆分配不能超过32GB。对于我们拥有128GB RAM 和48TB 磁盘空间的机器，如果我们只运行一个ES 实例，我们只能使用不到32GB 的堆。当堆几乎饱和时，此时磁盘上保存的索引文件还不到10TB，这显然是不经济的。因此，我们决定在冷节点上运行3个ES实例，每个实例分配31GB的堆空间，这样一台物理服务器上就可以存储超过30TB的索引数据，并保持开放供用户随时搜索。实际使用中，由于冷数据查找频率不高且没有写入，只剩下35GB内存供OS用作文件系统缓存，查询性能仍能满足需求。具有不同数据量的分片最好隔离到不同的节点组。

众所周知，ES会自行平衡集群中分片的分布。这个自动平衡逻辑主要考虑三个因素。首先，同一索引下的分片应尽可能分散到不同的节点；其次，每个节点上的分片数量要尽可能接近；三个节点的磁盘要有足够的剩余空间。该策略只能保证分片数量均匀分布，但不能保证数据大小均匀分布。在实际应用中，我们有200多种索引，数据大小差异很大，从每天几个TB到每月几个GB，并且每种类型数据的保留期限差异很大。提出的问题是如何平衡并充分利用所有节点的资源。针对这个问题，我们仍然通过添加属性标签的方式对节点进行分组，并结合索引路由控制来实现一些精细化的控制。不同量级的数据尽量使用不同组的节点，这样每组节点上的数据量更容易自动平衡。定期进行索引强制合并，最好将每个分片合并成一个段。前面提到，堆的消耗也和段的数量有关。强制合并可以显着减少这种消耗。合并成段的另一个好处是，对于term聚合，搜索时不需要构造Global Ordinals，可以提高聚合速度。四. 版本选择我们在2.4版本上已经稳定运行很长时间了。比较保守的同学可以上2.4，激进、有活力的同学可以考虑最新的5.0。两周前我们的集群从v2.4.0 升级到了v5.0.0。除了升级第一周遇到不稳定的问题之外，我觉得新版本带来的以下特性还是值得升级的：

节点启动的Bootstrap流程增加了对很多关键系统参数设置的验证，比如Max File Descriptors、Memory Lock、Virtual Memory设置等，如果设置不正确，会拒绝启动并抛出异常。与其从不正确的系统参数开始并导致将来出现性能问题，不如在启动失败时将问题告知用户。这是一个很好的设计！指数性能得到改善。升级后，在相同的索引速率下，我们看到CPU消耗有非常显着的下降。除了有助于提高索引率之外，还会在一定程度上提高搜索率。新的数值数据结构具有更小的存储空间和更快的范围和地理位置计算。 Instant Aggregation 可以缓存像now-7d 到现在这样的范围查询聚合。实际使用后，效果明显。用户在Kibana 上运行它。这是过去一周数据的汇总。前两次刷新比较慢，后面有缓存的时候几乎是瞬间刷新！更多的保护措施保证了集群的稳定性，比如限制搜索命中的分片数量、增强熔断等。功能可以更好地保护集群资源免遭不良查询耗尽。升级第一周，我们的冷数据节点出现了间歇性无响应的问题，因此我们提出了3个问题并提交给官方：

问题#21595 问题#21612 问题#21611

第一个问题已确认为bug，将在5.0.2中修复。另外两个的根本原因目前未知，似乎只在我们的应用场景中遇到。幸运的是，我们已经找到了解决这些问题的方法。实施这些措施后，我们的集群在过去一周已经恢复到之前2.4版本的稳定状态。

五. 监控如果你不缺钱又没时间摆弄，建议还是买官方的xpack省心。如果你有精力去摆弄它，只需使用ES丰富的统计API，使用熟悉的监控工具来收集数据，并将其可视化即可。监控指标这么多，最关键的是以下几类：

各种线程池的使用情况，active/queue/reject都可视化。判断集群是否存在性能瓶颈，可以通过查看业务高峰期各个队列是否很高，是否频繁出现拒绝等情况来判断。您基本上可以了解正在发生的事情。 JVM的堆使用百分比和old GC的频率。如果old GC频率很高，多次GC后heapused%很难降下来，说明堆压力过大，需要考虑扩容。 （也可能是查询或聚合有问题造成的，需要根据用户访问记录来判断）。段内存大小和段数。当节点上存储的索引较多时，这两个指标值得关注。要知道段内存是驻留在堆中的，不会被GC回收。因此，当堆压力过大时，可以结合这个指标来判断是否是由于节点上存储的数据过多，需要扩容。段的数量也很关键。如果有很多小段，比如几千个，即使段内存本身不多，当搜索线程很多时，仍然会消耗相当多的堆。原因是Lucene提供了每个段都会在线程本地记录状态信息。该块的堆内存开销与（段数*线程数）有关。需要记录用户的访问记录。我们只向用户开放http api，并预装一个nginx作为http代理，并通过访问日志记录用户所有的第三方api访问记录。通过分析访问记录，当集群出现性能问题时，可以快速找到问题的根源，对于故障排查和性能优化非常有帮助。

关于大规模Elasticsearch 集群管理指南，的介绍到此结束，希望对大家有所帮助。