GitHub此前的搜索使用Solr实现,新上线的搜索基于elasticsearch,运行在多个集群上。由于代码搜索索引很大,GitHub专门为其指定了一个集群。目前该集群包括26个存储节点和8个客户端节点。存储节点负责保存构成搜索索引的数据,而客户端节点负责协调查询活动。每个搜索节点中有2TB的SSD存储。
 
      发生故障时,整个集群保存了大概17TB的代码。数据以分片方式跨越整个集群存储,每个分片(shard)在另一个节点上有一份复制作为冗余,整个索引用去大约34TB存储空间。整个存储容量占用了集群总存储空间的67%左右。代码搜索集群运行在Java 6和elasticsearch 0.19.9上。当时这个集群已经正常运行了好几个月。
 
      在1月17日、星期四,准备上线这个代码搜索功能,以完成整个统一搜索的实现。后来发现elasticsearch已经发布了0.20.2版本,其中包括多个功能修复和性能改进。
他们决定推迟代码搜索上线,先升级elasticsearch,希望这可以让新功能的上线更加顺畅。
 
       在1月17日完成了升级,集群中所有节点都成功上线,而且恢复到正常的集群状态。
问题就此开始出现。
 
      从这次升级开始,集群中出现两次故障。
elasticsearch与其他使用大量单一索引存储数据的索引服务不同,它使用分片模式切分数据,这样可以很容易地将数据分布在整个集群中,而且易于管理。每个分片自己是一个Lucene索引,elasticsearch使用Lucene合并索引来聚合所有的分片搜索查询。
 
      在升级后两个小时,第一次故障出现了,恢复的过程中要重启整个集群。我们在索引日志中发现的错误信息指出:有些分片无法分配到特定节点上。进一步检查后,我们发现:这些数据分片有些区段的缓存文件已经损坏,其他在磁盘上已经丢失,但elasticsearch仍然可以恢复有损坏区段缓存的分片,它也可以恢复丢失了一份复制的分片,但是总计510个分片中有7个分片,主分片和副本都已经丢失了。
 
      我们复核了发生故障的环境,当时的结论是:我们发现的问题,来源于集群恢复带来的高负载。对问题的进一步研究后,没有发现其他elasticsearch用户遇到过类似问题。在那个周末,集群没有问题,因此我们决定发布新功能。
 
      下一次故障出现在1月24日、星期四。引起团队注意的,是他们的异常跟踪和监控系统,其中检测到大量的异常爆发。进一步调查指出:大部分异常来自代码查询的超时,以及加入新数据时更新代码搜索索引的后台作业。
 
      这一次,我们开始同时检查集群中全部节点的整体状态和elasticsearch的日志。我们发现:看似随机性的多个存储节点出现高负载。大多数节点的CPU使用率都是个位数,有几个消耗量几乎100%可用的CPU核。我们可以消除系统和IO引起的负载,在这些服务器上唯一导致高负载的是运行elasticsearch的Java进程。现在搜索和索引还是会超时,我们也在日志中注意到:一些节点被很快选为master,此后又很快被移除。为了消除这种快速切换master角色带来的潜在问题,我们决定:最好的方法,是让集群完全停机,然后将其启动,禁止数据分片的分配和重新平衡。
      这种方式让集群恢复上线,但是他们发现elasticsearch日志中有一些问题。集群重启后,他们发现有些节点无法重新加入到集群中,有些数据分片试图二次分配到同一个节点上。这次,他们求助于elasticsearch公司的技术人员,并确认:
 
      这些无法分配的分片(主分片与复制合计23个)都有数据丢失。除数据丢失外,集群花费很多时间试图恢复剩余的分片。在这次恢复过程中,我们必须多次重启整个集群,因为我们加入了多次升级和配置变更,必须要验证和再次恢复分片。这是这次故障中最耗时的部分,因为多次从磁盘中加载17TB索引数据十分缓慢。
 
      和elasticsearch的技术人员一起,他们发现集群中有些地方配置错误,或是需要调优配置,才能得到最佳性能。这次问题也让elasticsearch的技术人员也发现了elasticsearch的两个bug。还有一个很重要的原因:
 
      我们当时运行的Java 6是2009年早期的版本,其中包含多个严重bug,影响elasticsearch和Lucene,同时造成大量内存分配,导致高负载。
 
      根据他们的建议,我们马上升级了Java和elasticsearch,并按他们的推荐调整了配置。具体做法是:在我们的Puppetmaster上,针对这些特定变更,创建了一个新的话题分支,并在环境中的这些节点上运行了Puppet。使用了新的配置、新版本elasticsearch和Java7之后,此前两次故障中遇到的负载不稳定和快速master选举问题再也没有出现了。
 
但是,1月28日,又出现一次故障。不过这次与之前没有关系,完全是人为错误。
 
      一名工程师要把包含有Java和elasticsearch更新的特性分支合并到我们的生产环境中。过程中,工程师将代码搜索节点上的Puppet环境回滚到了生产环境中,这是在部署合并代码之前。这导致elasticsearch在节点上重启,因为Puppet运行在上面。
 
      我们马上就发现了问题根源,并停下集群,防止在一个集群中运行多个版本Java和elasticsearch导致任何问题。当合并代码部署后,我们在所有代码搜索节点上再次运行Puppet,启动集群。我们没有选择在集群处于降级状态时建立索引和查询,而是等它完全恢复。当集群完成恢复后,我们将代码搜索功能打开。
 
      总结这几次故障,Will指出:
 
      在将代码搜索集群中的elasticsearch升级到0.20.2版本之前,我们没有在我们的基础设施中对其进行足够测试,也没在其他集群中测试。还有一个原因是:对于代码搜索集群,我们没有足够的上线前(staging)环境。
 
      现在运行的Java版本已经经过elasticsearch团队测试,而且代码集群配置也经过他们审核,未来的审核过程也已经安排确定。
 
      对于周一的故障,我们正在开发自动化过程,保证这样的效果:如果GitHub上的分支比Puppetmaster上分支更超前,确保这个环境中的Puppet不会运行。
 
最后,elasticsearch团队提供了对运行大集群的几点优化建议:
 
1.设置ES_HEAP_SIZE环境变量,保证JVM使用的最大和最小内存用量相同。如果设置的最小和最大内存不一样,这意味着当jvm需要额外的内存时(最多达到最大内存的大小),它会阻塞java进程来分配内存给它。结合使用旧版本的java情况就可以解释为什么集群中的节点会停顿、出现高负载和不断的进行内存分配的情况。elasticsearch团队建议给es设置50%的系统内存
2.缩短recover_after_time超时配置,这样恢复可以马上进行,而不是还要再等一段时间。
3.配置minimum_master_nodes,避免多个节点长期暂停时,有些节点的子集合试图自行组织集群,从而导致整个集群不稳定。
4.在es初始恢复的时候,一些节点用完了磁盘空间。这个不知道是怎样发生的,因为整个集群只使用了总空间的67%,不过相信这是由于之前的高负载和旧java版本引起的。elasticsearch的团队也在跟进这个问题。
 
原文地址