1小时ElasticSearch求生指南

先给出葵花宝典心法口诀：

    节点发现很重要，避免脑裂保平安；出现问题快踢掉，不然查询好不了

    自动恢复要慎重，过于仓促反很差，分片移动成本高，可以避免是最好

    副本开销也挺高，流量大时可去掉，等到夜里静悄悄，定时任务来生成

    拆分索引很靠谱，保留天数按须要，数据采集设拆分，定时删除有脚本

    多节点，是个宝，物理资源利用高，扩容缩容需规范，不能直接(节点)上下线

    写入参数能够调，注意观察看疗效，段合并调整是猛药，慎重避免反作用

1、陷阱的产生

 1.ES的节点类型以下图:

2. 默认的配置有问题：

3. a.ES默认安装后默认的节点类型：Maser-Eligible & Data & Ingest，三合一

4. b.默认设置里“minimum_master_nodes： 1”，只要看见一个节点，便可成立集群,异常状况下容易发生脑

5. c.原则：minimum_master_nodes应设置为 (master_eligible_nodes / 2) + 1

 2.Master节点存储信息多

    

    为管理ES集群，须要有一些元数据标明集群状态、索引/分片位置、in-sync shards …，这些信息被称为集群的Meta Data。

    集群的Meta data的变动都由Master节点完成，并通知到集群中的其它节点。因此Master稳定对集群很重要。

    默认Master同时做为Data节点，当负载较重时，容易致使稳定性问题

3.高成本的写过程

     

    a. 客户端向Node1 发送写请求

    b.Node1 算出文档属于分片0，因而将写请求转给分片0主分片P0所在的Node3

    c. Node3写成功后，继续将写请求并行转发到Node1和Node2的副本分片上，一旦副本分片报告成功（根据配置不一样可选择1个报告成功，多数报告成功，或全部报告成功），

       Node3向协调节点Node1报告成功

    d.Node1向客户端报告成功

  

  一些解释说明：

     a. 写请求到达分片后，先写Lucene文索引，再写Translog

     b.写Lucene索引时，新记录首先被写入缓存，经过定时刷新生成段文件，定时刷新的频率由“refresh_interval”参数控制，默认1s

     c.ES本身控制什么时候将生成的段文件持久化到磁盘

     d.Translog也是首先写到内存里，并在知足必定条件时flush到磁盘持久化。

       flush到磁盘的时机由两个参数定义：“flush_threshold_size”: “1024mb”；"sync_interval": "60s"

  

    关于段合并：Segments/段太多会给ES带来很大负担，严重影响搜索性能并带来大量文件句柄的消耗，因此ES会自动进行段合并以优化性能。

    可是段合并过程消耗大量I/O和CPU资源，而且ES会对段合并作节流控制，这个过程甚至会引起其它问题

4.高成本的搜索

  过程描述： 

        a. 默认搜索分为两个阶段，查询阶段与取回阶段

        b. 在查询阶段，客户端将Search请求发送给Node3，Node3将做为本次查询的协调节点。Node3将查询请求转发到每一个主分片或副本分片中，如图中的P1和R0，每一个主分片或副本分片搜索自身包含的符合查询条件的记录。

        c. 各分片返回本身符合条件，并已排好序的结果给协调节点Node3，由Node3合并各节点返回的结果并过滤出全局符合条件的结果。接下来进入取回阶段。

        d. 在取回阶段，协调节点Node3已在第三步知道全局结果里各记录分别属于哪一个分片，并向相应的分片发送取回请求。

        e. 相应分片响应取回请求，并将结果返回给Node3

        f. Node3将合并后的结果返回给客户端，搜索完成

   搜索的开销：

        为保证搜索性能，ES须要将大量段数据保存在内存中，带来至关大的内存开销；同时，排序、聚合等操做也会消耗大量CPU资源。纵观整个搜索过程，能够发现它须要付出高CPU、高I/O的代价。

   查询膨胀问题：

        在查询阶段，会带来搜索膨胀的问题。即协调节点要知道全局结果，必须汇总每一个分片的查询结果。

   Example：某索引有30个分片，要查询符合某个条件的第10000笔记录，其过程是什么？

        查询请求发到ES集群中某个节点，该节点充当协调节点并将查询转发到30个分片上

        每一个分片返回本身符合结果的前10000笔记录给协调节点，协调节点对总共30w笔记录排序，并肯定全局排序结果里第10000笔记录在分片N上

        向该分片N发送get请求，取回该笔记录

        将记录返回给客户端

2、如何被陷入

两大陷阱 -- 稳定性 & 性能

1. 稳定性

   
   

    a.稳定性陷阱 Example #1：分片丢失，集群变红

    

       问题现象：有分片丢失，集群进入Yellow/Red状态

       广泛程度：很是广泛，我估计大家全部项目均碰见过

       缘由 & 解决办法：几乎都是因为节点失联致使分片丢失。节点失联的缘由常见是gc，较少见的缘由包括“系统问题”和“网络不通”。

       如是gc致使问题，常见应对手段如关闭索引和部署多节点避免gc；如是其它环境因素，一般排除相关 因素后可解决问题

       有用的命令：

          查看未分片的缘由：curl -XGET ‘http://<es-ip>:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason

          查看gc的命令： jstat -gc <es-pid> 2000

    b.稳定性陷阱 Example #2：脑裂没法恢复

        问题现象：某个节点被踢出集群，并再也没法加入进来，集群随后进入分片恢复，当该丢失节点被手动加回集群后，

        广泛程度：较为广泛

        解决办法：合理设置参数，避免集群脑裂

        假设有3个Master Eligible节点：node.master: true

            至少看见2个Master Eligible才可组建集群：discovery.zen.minimum_master_nodes：2

    c.稳定性陷阱 Example #3：再平衡对性能的恶化

        问题现象：发现集群长时间处于黄色状态，大量分片处于分配中或待分配状态，每每伴随着一些节点处于高负载状态的现象。

        广泛程度：广泛

        缘由分析：

        当节点因为各类缘由失联一段事件后，主节点会：

        1）将失联节点上的每一个主分片的一个副本提高为新的主分片；

        2）从新在其它节点上分配副本；

        3）进行分片恢复动做；

        4）如此时失联节点从新加入，主节点将对集群作平衡，将一些分片移动到失联节点上，状况进一步变差

        以上恢复/再平衡过程是CPU、network-io、disk-io都很重的操做！

        如何缓解：合理设置分片恢复延迟，给系统更高的容错度

        “index.unassigned.node_left.delayed_timeout”: “5m“     （默认1分钟）

     d.稳定性陷阱 Example #4：查询响应慢

        问题现象：从ES里加载数据失败

        广泛程度：较为广泛

        缘由分析：

        ES集群有数据节点处于异常状态 (如长时间GC)，该节点未能被及时踢出集群，致使集群认为该节点仍存活，转发到该节点的查询长时间不能返回，致使页面的查询超时失败。

        在这种状况下，写入数据也会受到影响，如观察采集器状态和日志，很大概率会发现有数据写失败的状况。

        很多项目的ES集群会优化节点的心跳检测参数设置，以下降集群变红的几率和触发自平衡带来的影响，但这种优化在节点异常时，将加剧查询响应慢的问题

        如何应对：

        合理规划部署并优化配置，下降节点异常的几率

        非不得已应避免将心跳检测参数设置的过于激进，默认参数在大多数状况下适用，须要调整的状况下也不建议超过下面的值：

        “discovery.zen.ping_interval”: “10s“ 

        “discovery.zen.ping_timeout”: “5s”

        “discovery.zen.ping_retries”: 3

        稳定性陷阱的日志表现

        

    稳定性陷阱的总结:

    表现：ES节点掉出集群，或一段时间没有响应

    诱因

      jvm gc 【常见缘由】

      系统问题 【少见】

      网络缘由 【极少见】

    危害

      分片丢失，集群变红/黄

      脑裂

      再平衡致使集群性能恶化

      查询响应时间很长/超时

 2.性能陷阱：短板效应很明显

  a.性能陷阱 Example #1：I/O慢致使集群性能差

    问题现象：集群表现不稳定，采集器大量丢日志；查看ES日志常常出现长时间gc (> 30秒)；在监控页面中观察会发现多数节点CPU、load常常飙红，CPU使用率超过硬件能力的70%

    广泛程度：较少见

    缘由分析：ES为提升性能，作了不少优化，包括经过轮询操做替代睡眠、等待通知等阻塞操做（特别是段合并的节流控制处理逻辑）。

    当磁盘写速度跟不上时，段合并逻辑会不断重试合并，直到能够写入，表现为检测到磁盘I/O写入不高，但CPU，load很是高。

    如何解决：

        有条件采用RAID5 （很是有效，推荐）

        使用高性能磁盘 （有效）

    没有RAID5的状况下，部署多节点，给不一样节点分片的data目录分配不一样的磁盘以隔离I/O    （通常） 

    补充：评判硬盘性能是否知足数据量要求的条件不等式 (仅用于评估IO可否知足)

    (eps × 每条日志大小 × (1 + 副本数) × 2[1] × 1.5[2]) ÷ data节点数 < 磁盘写速度 × 0.4[3]

    其中[1]为ES写段和写Translog的影响因子；[2]为段合并的影响因子；

    3]为考虑两重影响因素的调整因子：

       1）ES data节点因为段合并有大量读操做，影响写入性能；

       2）ES的段落磁盘时不是顺序写文件 （均为经验参数，可根据实际状况调整）

      Example: 1w eps，日志平均1.5KB/条，1份副本，2个data节点，机器配置速度为180MB的硬盘，可否知足性能要求？

  答：不等式左边：10000 * 1.5K * 2 * 2 * 1.5 ÷ 2 ≈ 45MB；不等式右边：180 * 0.4 =72MB。能够知足

b.性能陷阱 Example #2：节点慢致使集群性能差

    问题现象：采集器丢日志，但经过监控页面观察，ES节点大多数时间正常，消耗资源较低，但长时间观察，能看到CPU，load飙红的状况，持续一段时间后消失，过段时间再出现，… …

    广泛程度：较少见

    缘由分析：当ES集群中存在配置较低，或速度较慢的节点时，该节点将拉慢其它正常节点的写速度，并触发段合并的节流机制，致使CPU、load飙升；

                     事实上，查询也会受到影响，会表现出有时查询慢的现象。

    如何解决：找出存在瓶颈的节点，并予以解决。

    问题排查的有效命令：

        curl –XGET “http://es-ip:9200/_cat/thread_pool?v&h=ip,bulk*”

     

  性能陷阱的总结：

    表现：ES集群性能差 -- 丢数据；CPU & load持续高位；采集器报错并陷入异常

    诱因

       磁盘I/O速度慢 【常见缘由】

       gc致使节点速度慢 【常见缘由】

       低配节点速度慢 【较少见】

    危害

        丢日志

        机器性能用不满、上不去

        CPU & load短期飙升，集群稳定性变差

3、如何避坑

    避坑的技术：调整部署 & 优化配置

 1.部署优化之加强稳定性

    节点的设置建议（4个以上数据节点，> 1.5w eps）：

    a. 主节点必须由master-only节点承担，Master-only节点配置8G内存

    b. 条件容许则部署单独的coordinate节点负责查询，coordinate节点内存16GB。Coordinate节点配置后，模块里链接ES的配置改成coordinate节点。

    c. 同物理机部署多Data节点，Data节点内存最大31G

        切记给每一个节点分配不一样的data路径以免异常状况（如因数据未能加载而形成的分片丢失），特别是在未使用RAID的状况下，让不一样的节点的data path在不一样硬盘上能够隔离I/O、提高性能

    d. 数据量< 1.5w eps时，物理机<4台，一般不需特殊配置，确保节点发现参数正确。原则：保证超半数master eligible节点被看见才可创建集群。

        原则：保证超半数master eligible节点被看见才可创建集群。

        例如3个Master Eligible节点：node.master：true

        至少看见2个Master Eligible才容许组成集群： discovery.zen.minimum_master_nodes：2

        在节点发现配置里配上全部的Master-Eligible节点：discovery.zen.ping.unicast.hosts: ["x.x.x.x", "x.x.x.y", "x.x.x.z"]

 2.部署优化之增长data节点

    Data节点的配置为：

        conf/elasticsearch.yml:    

        node.master: false    

        node.data: true

    设置好节点发现，将Master-Eligible节点放入配置

        conf/elasticsearch.yml:    

        cluster.name: hansihgt-enterprise    

        node.name: node_N    

        discovery.zen.ping.unicast.hosts: ["x.x.x.x", "x.x.x.y", "x.x.x.z"]

     等待集群自动平衡

  3.部署优化之减小data节点

        将分片迁移到其它节点：

        PUT _cluster/settings{  "transient" : {    "cluster.routing.allocation.exclude._ip" : “x.x.x.x"  }}

        待数据迁移完成，将节点下线

  4.部署优化之增长&减小Master节点

        增长Master节点：

        首先将‘minimum_master_nodes’参考变动到当前的“quorum/过半数“值，如，以前为3个Master-Eligible，如今要增长到4个，则quorum要由2提高到3：

        curl -XPUT localhost:9200/_cluster/settings -d '{    "persistent" : {  "discovery.zen.minimum_master_nodes" : 3    }}'

        再部署新的Master节点，并在配置文件里设置正确的发现参数

   5.部署优化充分利用硬件资源

        通常采用单台物理机上部署多节点的方式以充分利用内存，以及分散磁盘I/O

        数据节点的内存磁盘比

        给全部ES数据节点启动参数配置的内存之和记为M（注意不是机器的物理内存），天天的索引所占存储记为S，索引打开天数记为N，它们之间的关系应知足：

        M * δ > S * N

        δ为经验参数，取值在96 ~ 128之间 （根据现场经验，该值能够适当激进一些）

        Example：某集群7个数据节点，每一个节点配置31GB内存，天天数据量约2.5TB（含副本）， δ取100，则最大可打开的索引天数为：

            N < 31 * 7 * 100 ÷ (2.5 * 1024) ≈ 8天

   6.部署优化之合理选择硬件

        磁盘使用：I/O性能对ES性能有很大影响，建议

        有条件应尽可能上RAID5

        不能上RAID5尽量选择高性能硬盘

        网卡选择：数据量大时应使用万兆网卡，

        网络存储：最好都不用！

        无可奈何，惟一的选择：SAN

        因为写入延迟大，不要用NAS

        关于虚拟机：最好不用虚拟机 ，无可奈何，应尽可能保证硬件资源不被其它虚拟机竞争

    7.优化配置之使用方法优化

        流量高峰时不写副本，设置定时任务生成

       拆分索引，便于不一样业务数据源的数据保存不一样的时间周期。

    8.优化配置之ES参数优化

       a. 提高稳定性：

          正确设置节点发现参数，避免脑裂

         延迟迁移分片：“index.unassigned.node_left.delayed_timeout”: “5m“

       b.优化写性能 ： 

        下降段刷新频率："index.refresh_interval": "60s“

       c.下降IO阻塞：

            "index.merge.scheduler.max_thread_count": "1“

             action.wait_for_active_shards: 1  （ES 5.x之后）

             action.write_consistency: one (ES 2.x)

       d.段合并参数配置，减小段合并（慎重，有反作用！）

          "index.merge.scheduler.max_merge_count": 16

           "index.merge.policy.floor_segment": "128mb"

           "index.merge.policy.segments_per_tier": 128

           "index.merge.policy.max_merge_at_once”: 32

哈哈：方法千万条，稳定第一条，规划不完善，上线满头汗！