原文载于Elastic中文社区: https://elasticsearch.cn/article/120
尝鲜
10月26日，Elasticsearch5.0.0 GA终于放出，携程ES Ops团队也在第一时间在DEV和UAT环境分别进行了2.4.0 至5.0.0的升级和测试。升级完成后，除了部分Query不向前兼容（主要是Filtered Query)，需要在应用端做一些修改以外，未发现其他问题。通过监控系统看对比升级前后的主要系统指标，在同等索引量的情况下，CPU使用率有明显下降 ( 30% - 50%左右) ，相信性能方面5.0应该是有较大提升的。
在测试环境稳定运行了2周以后，我们决定选定一个生产集群进行升级，考验新版本在更为复杂的用户环境下的表现。 出于对业务影响最小化的考虑，用于日志分析的集群被圈定为升级目标。该集群也是携程十几个集群中规模最大的一个，共有120个数据结点运行于70台物理机上，总数据量接近1PB。
升级前需要做一些准备工作，下载官方的Migration Helper插件，检查集群设置和索引的兼容性。对于不兼容的配置项，MH会详尽列出，其中标注为红色部分为为升级前必须修改项。1.x版本创建的索引，是无法直接升级到5的，需要先在2.x集群里做一次reindex 。 MH提供了不兼容索引扫描功能，对于找到的不兼容索引，可以直接在UI上发起reindex操作，等待结束即可。 如果是用于业务搜索集群，数据可能比较重要，建议升级前做一个Snapshot，万一升级过程出现意外，可以回退版本从备份里快速恢复数据。我们的日志集群数据量极大，也没有对数据100%不丢的要求，因此升级前没有做Snapshot。 做完所有的准备工作后，预先通知所有用户集群升级的时间以及可能产生的影响，选定了周五深夜用户低峰期，开始正式升级工作。
首先通过Ansible将新版本批量部署到所有结点并统一配置，紧接着对原有集群做了Full Stop，校验所有的ES已经停下后，开始Full Start。整个过程比较顺利，所有结点正常启动，数据恢复完成后，集群重新回到正常服务状态。
周末两天运行，未发现有任何的异样，CPU利用率也降了不少，看起来很靠谱……直到周一
踏坑
周一早上，随着用户访问量高峰来临，马上浮现出一个诡异的现象： 索引速率遇到了瓶颈，数据开始在前置的消息队列(Kafka)里堆积。 从监控数据看，尽管所有的数据结点CPU消耗都比上周同期低，磁盘IO也很低，但索引速率却低了很多。反复对比查看升级前后各类监控指标后，终于发现一个可疑点，所有结点的网络流量比升级前高了好几倍！ 在集群架构上，我们是单独架设了几台client node做为数据写入和分发的入口，现在这几个node的网络流量已经饱和，成为数据写入的瓶颈。一开始，怀疑是否2.4启用了tcp压缩，而5.0取消了，但翻查官方文档后发现transport.tcp.compress在2.4和5.0里默认都是关闭的！ 这时候只有两个解决办法了，要么启用tcp压缩，要么扩容client node。 先考虑了一下tcp压缩的方案，快速扒了一下ES源码，在transport.TcpTransport这个类里，sendRequest和sendResponse两个方法会根据transport.tcp.compress设置来决定发送的消息是否要经过压缩，而在messageReceived方法则会读取消息头部的状态信息，探测消息是否经过压缩以及压缩的方法，而后决定是否需要解压，以及采用的解压方式。 这样看起来，ES是允许tcp压缩和不压缩的结点之间通讯的，那么只对client node启用压缩应该就可以了。测试环境测试过后，验证了想法的可行性。于是对生产的client node开启tcp压缩，同时在数据发送端(hangout的ES output)也启用tcp压缩，重启client node后入口网络流量降到和之前2.4差不多的程度，问题得到规避。 针对这个问题在Github上提交了issues#21612， 但未得到官方合理的解释。
解决好这个问题，另外一个问题来了，很多执行大量历史数据搜索的用户反映出不了结果。 从监控数据看，这类查询的搜索耗时非常久，直到网关300秒超时（查询api前置的nginx代理)。我们之前对集群设置过Global Search timeout为60s，用来保护集群资源过多被超高代价的查询消耗，在2.4版本是有效果的，现在看来不起作用了。手动测试了一下，这个参数果然失效！ 于是向官方报告了第2个问题：issues#21595。 这个问题很快被官方确认为Bug，修复也很快加入到了5.0.2。 为了规避这个问题，我们只好临时修改了一下Kibana以及第三方API访问要经过的nginx proxy，默认为所有的search request加入一个超时选项。此后，问题有一些缓解，但仍然发现用户查询大范围历史数据时，部分用于存储历史数据的结点响应很慢。
我们的集群是做了冷热分离的结构的，热节点主要承担写入和存放过去24小时数据，冷结点没有写入，查询频率也低，所以为了最大化利用硬件资源，一台物理机上跑了3个实例，这样一台128GB内存的机器可以存放下近30TB的索引。查看冷结点的监控数据，看到用户查询期间磁盘的read IO非常高，直接将磁盘IO Util%撑到100%，并且可持续数小时，同时search thread pool有大量的active thread处于无法完成状态，search queue不断攀升直至饱和、开始reject。 表象上看search thread似乎一直在尝试从磁盘大量读取数据，一次search甚至可以持续几十分钟至一个小时，耗尽了所有的搜索线程，导致拒绝后续的搜索服务。 于是Github上报了第3个issue: issues/21611 这个问题找到解决办法之前，我们只能通过反复重启有问题的冷结点来缓解。 和官方讨论过程中，得知5.0在Lucene文件访问方式上有一个比较大的改动，2.4使用mmapfs读取索引文件的部分，而5.0以后改为用mmapfs读取索引文件的全部。怀疑问题和这个变动有关，尝试将所有索引文件的设置改为NIOFS后，问题迎刃而解。 搜索性能一下回到了2.4时代，再也没出现搜索线程超长时间执行的问题。之后找时间复现了这个问题，并抓取了线程栈，看到长时间执行的搜索线程一直在做Global Ordinal的构造工作。 至于为何会这样，还不清楚。 从官方给出的信息看，底层索引文件的访问模式是没有变化的，仅仅是将文件读取方式全部改成了mmapfs，理论上应该性能更好，但是看起来在我们这种一台机器跑多个ES实例，所有分配的heap为系统缓存3倍的极端用例下，大范围的数据搜索可能造成过高的磁盘读IO，集群性能指数级下降。
以上问题前后耗了4天才完全规避掉，支持团队连续熬夜后集群总算回复到平稳状态。然而好景不长，运行一段时间以后，数据结点出现疑似内存泄漏现象。结点总数据没怎么增加、甚至还有减少的情况下，heap使用率一只呈攀升趋势，Old GC无法回收内存。这个问题对用户影响较小，通过监控我们可以及时发现内存即将用尽的结点，做一次重启很快就恢复了。 为排查根源，我们对一个有问题的结点做了dump，通过MAT工具分析，看到meta data相关的一个alias对象被实例化了有6600万次之多！ 在Github上提交了第四个issue: issues#22013，不多久被确认为已知问题pull#21284 ,在5.0.1已经修复。
最后还存在一个master node内存泄漏的问题，这个问题在2.4.0时代就存在了，升级到5.0.0以后依然没有修复。由于我们的master node和data node是分离的，所以这个问题比较容易通过监控发现，解决方式也很简单和迅速，重启master node即可，对用户完全无影响。之后不久，5.0.2版本正式发布，release notes里提到了对这个问题的修复 pull#21578。
上周周末我们将集群rolling upgrade到了5.0.2，global search timeout失效和两个内存泄漏的问题从根源上解决掉了。 网络流量增大的问题依然存在，仍然需要通过启用client结点的transport.tcp.compress规避。 冷结点搜索性能的问题没看到有提及，估计没解决，安全起见，还是保持索引的文件系统为NIOFS。升级完成运行一段时间后，可以肯定，5.0.2已经比较稳定。
心得
升到5.0.2后，对于其中一组数据结点这两天特意加了点索引负载，通过监控数据将v5.0.2与2.4.0做实际运行环境的索引吞吐量对比。
在近似的CPU使用率和load情况下，5.0.2能够支撑更大的吞吐量。另外5.0带来的Instant aggregation功能，对于跨多个索引的时序类型数据的聚合也可以有效Cache了，在使用Kibana的时候提速感觉非常明显。
升级过程虽然遇到很多波折，但由于集群架构上做了角色分离(client,master,data)和冷热分离，因而Bug引起的故障比较容易被限定在一个较小的范围而不至于影响所有的功能和所有的用户。 故障点定位更加容易，规避措施也更容易实施。 部分规避措施实施过程中甚至对用户是完全无影响的，比如: 重启内存泄漏的master node)。详尽的监控为问题的发现和诊断提供了有力的支持。
Elasticsearch是非常复杂的系统，官方的测试无法覆盖所有的用例场景和数据规模，一些极端的应用场景可能触发某个深藏的Bug或者缺陷而陷入困境。 因此对于稳定性要求极高的应用，最好还是采用经过长时间考验的版本，比如v2.4.2。
