Elasticsearch 6.5.4这个版本在很多人眼里已经算“老家伙”了但直到今天它仍然活跃在一大堆公司的生产环境里日志平台、订单检索、商品搜索甚至一些跑了好几年没敢动的业务系统。前段时间我把内网一套ES从单节点扩成3节点集群中间踩了不少坑也把常见的报错挨个处理了一遍。这篇文章就把整个 elasticsearch-6.5.4 集群部署过程完整记录下来从环境初始化、配置文件解读到三节点联调最后把部署和运行时最常见的错误全部贴出来附上报错现场、原因分析和解决办法。不管你是刚从单机ES迁移到集群的运维还是第一次在测试环境搭ES集群的开发这篇都能直接照着抄。1. 项目概述与集群设计思路1.1 为什么从单节点升级到三节点集群很多人一开始接触ES都是单节点跑着玩装好、启动、建索引、写数据看起来一切正常。可一旦数据量上来单节点的问题就藏不住了JVM堆内存涨上去之后GC越来越卡机器宕机数据直接不可用想给索引配副本都配不了——因为副本分片不能和主分片放在同一个节点上这不只是ES的限制而是分布式系统的基础逻辑。ES集群的核心就是把一个索引拆成多个分片shard散到不同节点上每个分片还能配副本replica。这样单点挂了其他节点上的副本还能继续服务查询也可以并行打到多个分片吞吐量比单机高出一截。生产环境里最常见的起步配置就是三节点原因很简单三节点可以同时容忍一个节点宕机还能正常选出主节点。两个节点看着省钱实际上很容易出现集群脑裂或主节点选举僵局维护成本反而高。这次部署的硬件环境是三台CentOS 7.6虚拟机配置都是4核16G内存、100G数据盘。ES版本固定为6.5.4主要考虑是这套环境和现有的日志采集链路已经跑通升级大版本会牵扯到数据迁移、插件兼容、客户端版本等一系列改动代价不小。如果是全新项目我会建议直接上更新的版本但存量系统里6.5.4稳定跑着别乱动就是最好的方案。1.2 节点角色和硬件规划ES 6.5.4里节点角色主要通过两个参数控制node.master和node.data。简单理解node.master: true表示这个节点有资格参与主节点选举负责集群级别的元数据管理、索引创建删除、分片分配等操作node.data: true表示这个节点负责存储数据、执行搜索和写入请求。规划节点角色时不要想得太复杂。小集群3到5个节点最省事的做法是每个节点都同时承担 master 候选和 data 角色也就是“混合节点”。只有当集群规模到了几十个节点、主节点负载明显偏高时才需要拆出专门的 master 节点避免数据节点频繁执行大查询把主节点拖垮。这次三台机器的角色规划如下节点名IP角色内存数据盘node-1192.168.80.101master候选 data16G100Gnode-2192.168.80.102master候选 data16G100Gnode-3192.168.80.103master候选 data16G100G三节点全部设为 master 候选是因为minimum_master_nodes这个防脑裂配置在奇数节点下最好算候选节点数除以2加1三节点就是2。如果只有两个节点是 master 候选公式是2/212也能运行但一旦其中一个挂了剩下的节点凑不够法定票数整个集群就会停止服务没有意义。1.3 大数据集群部署的基本策略做集群部署最忌讳的是“装完再说”。ES集群虽然是软件层面的事情但真正决定它稳不稳定的往往是装之前的规划。我的习惯是先走一遍下面的清单再动手指安装网络规划三台机器内网互通防火墙放行9200和9300端口/etc/hosts里写好三台机器的解析记录。这一步没做好后面会出现各种诡异的节点连接失败。系统参数JDK版本、vm.max_map_count、文件句柄数、内存锁定限制这些必须在启动ES之前调整完否则会撞上一连串bootstrap check错误。目录规划数据目录、日志目录单独划分磁盘不要和系统盘挤在一起。ES的写入放大效应很明显数据盘满了会直接导致集群只读。部署顺序先单节点启动确认没报错再逐台加入最后统一验证集群状态。这套思路不光是ES适用搭其他大数据组件比如Kafka、HDFS也是同一个套路先设计再实施启动失败时通过日志定位而不是反复重启碰运气。2. 环境准备与基础配置2.1 JDK 1.8 安装与版本确认ES 6.5.4官方要求JDK 1.8及以上这里我直接用的是系统安装的OpenJDK 1.8。如果不想在服务器上装额外的东西发行包里也带了自检逻辑但生产环境我建议还是手动装一个明确的JDK版本方便后续排查问题。# 查看是否已安装JDK java -version # CentOS 7下用yum安装OpenJDK 1.8 yum install -y java-1.8.0-openjdk-devel # 确认JAVA_HOME echo $JAVA_HOME # 如果没有输出在/etc/profile里加一行并source # export JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk这里有一个容易忽略的坑如果服务器上同时存在多个JDK版本JAVA_HOME指到了JDK 11甚至更高版本ES 6.5.4在启动时可能会报版本不兼容或者一些奇怪的类加载错误。所以在启动ES之前先单独执行一次java -version确认是1.8再往下走。2.2 系统参数调优内核、文件句柄、内存锁定ES官方文档里特别强调的Linux系统参数有三个少一个都会导致启动失败或运行期性能问题。第一个是vm.max_map_count默认值是65530ES要求至少262144。这个参数控制的是进程最多能拥有的内存映射区域数量ES用mmap加载索引段文件数据量大以后很容易触到上限。启动时如果没调错误信息长这样[1] bootstrap checks failed [1]: max virtual memory areas vm.max_map_count [65530] likely too low, increase to at least [262144]解决办法就是改内核参数并持久化sysctl -w vm.max_map_count262144 echo vm.max_map_count 262144 /etc/sysctl.conf sysctl -p第二个是文件句柄数。ES进程需要打开大量文件每个分片、每个索引段、日志文件都要占用fd默认的4096根本不够。修改方式是在/etc/security/limits.conf里给ES用户加上限制cat /etc/security/limits.conf EOF esuser soft nofile 65536 esuser hard nofile 65536 esuser soft nproc 4096 esuser hard nproc 4096 esuser soft memlock unlimited esuser hard memlock unlimited EOF第三是内存锁定。如果你打算在elasticsearch.yml里设置bootstrap.memory_lock: true就必须给用户配置memlock unlimited否则启动会报“memory locking requested for elasticsearch process but memory is not locked”。所以limits.conf里那两行memlock不要漏掉。2.3 创建用户与目录规划ES出于安全考虑不允许用root直接启动报错信息很直接“can not run elasticsearch as root”。所以需要单独建一个系统用户。groupadd esgroup useradd -m -s /bin/bash -g esgroup esuser mkdir -p /data/es-data /data/es-logs chown -R esuser:esgroup /data/es-data /data/es-logs数据目录和日志目录分开放这个细节看着不起眼实际很有用。ES运行一段时间后数据目录体积会涨得很快日志如果也写在里面排错时想清理日志就很不方便数据盘和日志盘混在一起还容易相互影响。下载和安装直接解压就行cd /usr/local wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.5.4.tar.gz tar -zxvf elasticsearch-6.5.4.tar.gz mv elasticsearch-6.5.4 /usr/local/elasticsearch chown -R esuser:esgroup /usr/local/elasticsearchES的安装包是免编译的解压就能用这也是它部署起来相对快的原因。但解压之后一定要记得改属主否则以esuser用户启动时会遇到权限问题的报错很容易被误判成别的问题。3. 集群核心配置详解3.1 集群名称、节点名称与角色划分ES的配置文件在/usr/local/elasticsearch/config/elasticsearch.yml。第一个要改的是cluster.name这是集群的“身份证”只有相同cluster.name的节点才会加入同一个集群。默认值是“elasticsearch”生产环境一定要改成自己的名字否则内网里如果有别的ES实例可能发生节点串集群的尴尬事故。node.name是节点在集群里的名字必须唯一。建议和机器名保持一致这样在监控面板里一眼就能看出是哪台机器出了问题。我在node-1上配置如下cluster.name: es-cluster-prod node.name: node-1 node.master: true node.data: truenode.master和node.data都设为true在自定义ES的时候要特别注意如果一个节点node.master和node.data都是false那这个节点就是个客户端节点只转发请求不存储数据。小集群里一般不需要这样的节点白白浪费一台机器。3.2 网络绑定、端口与跨域设置网络配置是初学者最容易懵的地方。network.host决定ES监听在哪个IP上。默认是127.0.0.1也就是只能本机访问。要让集群节点间互相通信必须绑到内网IP最简单的写法是network.host: 192.168.80.101 http.port: 9200 transport.tcp.port: 9300http.port是供REST API调用的端口Kibana、head插件、业务代码都走这个端口。transport.tcp.port是节点间内部通信的端口集群的发现和数据复制都走9300。生产环境里防火墙一般要同时放行这两个端口很多人只放9200结果节点死活加入不了集群排查到最后才发现是9300被挡了。还有一个跨域配置如果你打算用elasticsearch-head这个浏览器插件来管理集群必须在yml里开启CORShttp.cors.enabled: true http.cors.allow-origin: *不加这两行head插件会一直报连接失败因为浏览器的跨域策略直接拦截了请求。这个错误我在后面会专门列出来。3.3 节点发现与脑裂防护ES 6.5.4用的是ZenDiscovery机制节点通过discovery.zen.ping.unicast.hosts指定的地址列表来互相发现。配置方法是把集群里所有节点的IP和transport端口都写进去discovery.zen.ping.unicast.hosts: - 192.168.80.101:9300 - 192.168.80.102:9300 - 192.168.80.103:9300这里有个细节要注意列表里的IP要写全每个节点都写同样的列表而不是只写自己。这样任何一个节点启动后都能通过列表里的其他节点找到整个集群。防脑裂的配置是discovery.zen.minimum_master_nodes这也是6.x版本里最重要的一个参数。脑裂指的是集群被分成两个“小集群”各自以为自己是主数据写入互相冲突。防止办法就是要求选举主节点时必须凑够法定票数三节点集群计算公式为3 / 2 1 2discovery.zen.minimum_master_nodes: 2有些人图省事不配这个参数默认值是1这在三节点集群里是致命的。一旦网络抖动两个从节点可能各自都认为自己是主节点整个集群的写入就乱了。3.4 JVM堆内存怎么设置最合理ES的JVM堆内存配置在/usr/local/elasticsearch/config/jvm.options。6.5.4默认是1G生产环境肯定不够。我的经验是设置成物理内存的一半但最好不要超过30G。-Xms8g -Xmx8g为什么是30G这个数字因为JVM的CompressedOops压缩指针技术只对堆内存小于32G的情况有效超过32G后指针会变宽同样的数据占用更多内存GC性能反而下降。所以即使机器有128G内存ES堆内存也建议控制在31G以内剩下的内存留给操作系统做文件缓存这对ES的读取性能帮助很大。-Xms和-Xmx要设成一样大避免JVM运行中动态扩容导致GC抖动。还有一个原则是不要随便改GC策略6.5.4默认的GC在绝大多数场景下已经够用强行换成别的GC调优没有压测数据支撑基本是给自己挖坑。4. 三节点集群部署实操全流程4.1 节点一node-1完整部署所有系统参数和用户准备完后开始配node-1。先编辑elasticsearch.yml把完整配置写出来cluster.name: es-cluster-prod node.name: node-1 node.master: true node.data: true path.data: /data/es-data path.logs: /data/es-logs bootstrap.memory_lock: true network.host: 192.168.80.101 http.port: 9200 transport.tcp.port: 9300 http.cors.enabled: true http.cors.allow-origin: * discovery.zen.ping.unicast.hosts: - 192.168.80.101:9300 - 192.168.80.102:9300 - 192.168.80.103:9300 discovery.zen.minimum_master_nodes: 2我建议用systemd来管理ES进程比bin/elasticsearch -d直接后台跑更规范开机自启和异常重启都方便。写一个systemd服务文件/etc/systemd/system/elasticsearch.service[Unit] DescriptionElasticsearch Afternetwork.target [Service] Typesimple Useresuser Groupesgroup LimitNOFILE65536 LimitNPROC4096 LimitMEMLOCKinfinity ExecStart/usr/local/elasticsearch/bin/elasticsearch Restartalways [Install] WantedBymulti-user.target注意systemd里也要设置LimitNOFILE和LimitMEMLOCK即使已经在limits.conf里配置过了systemd服务默认还是会用自己的一套限制这两个地方必须同时改。配置完成后重载并启动服务systemctl daemon-reload systemctl enable elasticsearch systemctl start elasticsearch启动后先不要急着操作观察日志。ES启动比较慢第一次启动可能要等十几秒看日志文件tail -f /data/es-logs/es-cluster-prod.log看到类似下面的输出说明启动成功[INFO ][o.e.n.Node] [node-1] initialized [INFO ][o.e.n.Node] [node-1] started [INFO ][o.e.n.Node] [node-1] adding [node-1] to [es-cluster-prod]...然后验证HTTP接口curl -s http://192.168.80.101:9200/?pretty正常会返回集群名、节点名和版本号信息。这时候集群里只有node-1一个节点状态是yellow这很正常因为分片的副本还没地方放。4.2 节点二、节点三加入集群node-2和node-3的配置和node-1几乎一样只有两个地方不同node.name改成自己的机器名network.host改成自己的IP。其他配置保持一致尤其是discovery.zen.ping.unicast.hosts列表里要写三个节点这一点不能漏。node-2的/etc/systemd/system/elasticsearch.service和node-1相同elasticsearch.yml只需要改两行node.name: node-2 network.host: 192.168.80.102node-3同理改成node-3和192.168.80.103。我一般会把node-1的整个配置目录用scp复制过去再改这两个字段这样不容易打错字scp -r /usr/local/elasticsearch/config esuser192.168.80.102:/usr/local/elasticsearch/复制完记得改属主。然后分别启动node-2和node-3再回到node-1上看集群状态curl -s http://192.168.80.101:9200/_cluster/health?pretty如果看到status: green、number_of_nodes: 3、unassigned_shards: 0就说明集群已经构建成功。我部署时第一次没看到green而是卡在yellow后来发现是之前测试留下的索引副本还没分配完等几十秒让ES自动重新分配就好了。如果等了几分钟还是黄色就要用下面第5部分的方法排查了。4.3 集群健康检查与功能验证集群状态green只代表分片分配没问题业务功能还得实际测一下。我习惯在部署完成后创建一个测试索引写入几条数据再搜一遍curl -s -XPUT http://192.168.80.101:9200/test-index -H Content-Type: application/json -d { settings: { number_of_shards: 3, number_of_replicas: 1 } }然后写入一条文档curl -s -XPUT http://192.168.80.101:9200/test-index/_doc/1 -H Content-Type: application/json -d { title: cluster test, content: this is a test doc }再执行搜索curl -s http://192.168.80.101:9200/test-index/_search?qtitle:clusterpretty能看到正常返回结果说明集群的写入、分片、副本和查询链路都通了。如果还需要Kibana只需在Kibana的kibana.yml里配好一个节点的地址比如elasticsearch.hosts: [http://192.168.80.101:9200]Kibana会自动感知集群里的其他节点。5. 常见错误与排查技巧实录5.1 启动失败类错误这部分是部署ES时遇到最多的问题几乎每个新手都会在这里卡一轮。我把最常见的几个启动失败错误列出来都是真实报错信息。错误一max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]这个错误在初次部署时出现频率极高。原因是ES进程的文件句柄上限不够。在limits.conf里配了65536之后重开SSH会话或者重启服务才会生效。如果你用的是systemd还要检查服务文件里的LimitNOFILE是否也设置了。# 确认当前进程的limit cat /proc/es_pid/limits | grep open files错误二max virtual memory areas vm.max_map_count [65530] likely too low这个在前面已经提过直接执行sysctl -w vm.max_map_count262144临时生效再写进/etc/sysctl.conf持久化。有时候你明明执行了sysctl命令但ES还是报同样的错误可能是你改了宿主机的参数但ES跑在容器里或者systemd开启了不同的命名空间需要确认修改作用于ES所在的隔离环境。错误三memory locking requested for elasticsearch process but memory is not locked如果你启用了bootstrap.memory_lock: true这个错误说明锁定内存失败。检查limits.conf里的memlock是否为unlimitedsystemd服务里是否加了LimitMEMLOCKinfinity。如果想要省事可以把bootstrap.memory_lock设为false但生产环境建议还是开启避免ES堆内存被交换到磁盘导致性能骤降。错误四can not run elasticsearch as rootES出于安全考虑禁止root启动用之前创建的esuser用户来启动就好。检查当前用户whoami如果是root切换到esusersu - esuser -c /usr/local/elasticsearch/bin/elasticsearch5.2 节点无法加入集群类错误三台机器都配好启动后节点之间能不能正常组集群这是绕不开的一个坎。经典报错是日志里反复出现[INFO ][o.e.d.z.ZenDiscovery] [node-2] master not discovered yet, waiting for [30s]看到这个别慌这不是立刻失败是节点在等主节点。如果等了很久还是这个日志就要往这几个方向排查先看discovery.zen.ping.unicast.hosts配置是否完整三台机器的IP和9300端口都要写进去。再看防火墙是否放行了9300端口# 在node-1上测试到node-2的9300端口是否连通 telnet 192.168.80.102 9300telnet能通说明网络没问题不通就去查防火墙。很多云环境的安全组规则也要检查服务器本地防火墙可能关了但安全组把你的9300端口挡在外面了。再看cluster.name是否一致。三个节点集群名必须一模一样这玩意不匹配节点互相看不到对方会一直重复“waiting for master”的循环。我在测试环境里犯过一次这个错误node-1写的是es-cluster-prodnode-2的配置是从别的环境复制来的集群名还是es-cluster-test结果node-2永远进不了集群日志里也不报明显的错误排查了半小时才发现是这种低级问题。如果日志里有类似failed to send join request to master重点检查transport端口和节点间网络。这类问题排查思路跟“点击一个按钮没反应时先看页面报了什么错”是一样的不要猜先看节点日志日志指向哪个方向就顺藤摸瓜。5.3 集群运行期错误分片未分配、磁盘水位、索引只读集群启动成功不代表万事大吉运行期的问题才是真正考验排错能力的地方。分片未分配unassigned shards集群状态yellow或者red最直接的表现就是_cluster/health里的unassigned_shards不为0。先看哪些分片没分配curl -s http://192.168.80.101:9200/_cat/shards?v curl -s http://192.168.80.101:9200/_cluster/allocation/explain?prettyallocation/explain接口会直接告诉你为什么分片分配不了是磁盘空间不足、还是副本数大于可用节点数、还是节点没起来。我用这个接口的时候有一次是因为索引副本数配成了2但集群只有3个节点主分片占掉一个节点后两个副本至少要4个节点才能放下自然分配不了。把副本数改成1问题立即解决。如果节点宕机后重启分片暂时显示UNASSIGNED是正常的ES会自动重新分配。但如果等了很久还没恢复可以尝试触发一次重新分配curl -s -XPOST http://192.168.80.101:9200/_cluster/reroute?retry_failedtrue这个命令只是重新触发分配流程不会帮你解决根本问题最终还是要看explain接口指出的原因。磁盘高水位high disk watermark [90%] exceededES默认在磁盘使用率达到85%时停止分配新分片到90%时会尝试把分片迁移到其他节点防止磁盘写满。数据量大的业务索引和分片涨得飞快磁盘说满就满。日志里会出现[WARN ][o.e.c.r.a.DiskThresholdMonitor] [node-2] high disk watermark [90%] exceeded on [node-2], all copies of the shards are allocated to other nodes这时的解决办法不是改配置而是先清理磁盘。删掉过期索引或者扩磁盘才是正路。临时降低水位线虽然能让ES继续写但会带来很大的数据风险比如磁盘真的写满导致节点崩溃我一般只在应急的时候才用用完之后立刻恢复默认值cluster.routing.allocation.disk.watermark.low: 85% cluster.routing.allocation.disk.watermark.high: 90%索引变成只读磁盘水位出问题时ES在某些版本里会自动把索引置为只读来保护数据表现就是业务方写入报错。清理完磁盘后记得手动解除索引的只读状态curl -s -XPUT http://192.168.80.101:9200/your-index/_settings -H Content-Type: application/json -d { index.blocks.read_only_allow_delete: null }5.4 常见错误速查表下面这些是我在实际部署和运维里遇到过的错误汇总整理成速查表方便大家直接对号入座错误现象根本原因快速解决办法can not run elasticsearch as root用root启动了ES创建esuser并切换用户max file descriptors [4096] too low文件句柄限制不够limits.conf systemd LimitNOFILEvm.max_map_count [65530] too low内存映射区域太少sysctl -w vm.max_map_count262144memory locking not availablememlock未放开limits.conf systemd LimitMEMLOCK bootstrap.memory_lockmaster not discovered yet节点发现失败检查unicast.hosts、防火墙9300、cluster.namefailed to send join requesttransport通信失败检查9300端口连通性node.id重复 / node.name冲突多个节点配了同一个名字修改node.name保持唯一high disk watermark exceeded磁盘空间接近上限清理磁盘扩容数据盘unassigned_shards不为0分片无法分配allocation/explain接口定位原因head插件连不上ES跨域未开启http.cors.enabled: truesystem call filters failed容器环境不支持seccomp物理机别管容器里按需调整bootstrap配置Permission denied目录属主不对chown -R esuser:esgroupheap size mismatchXms和Xmx不一致两个参数设置相同值5.5 排查思路像调试点击事件一样定位集群问题很多人遇到ES报错就慌了到处翻博客、试命令最后问题没解决反而把集群状态搞得更差。我自己的排错思路非常固定和调试前端页面上的一个点击事件几乎一样先看事件有没有触发再顺着调用链一层层看哪里断了。ES的“事件触发信息”就是它的日志和健康接口。打开节点日志看启动时有没有ERROR看运行中有没有WARN打开_cluster/health看status是green、yellow还是red打开_cat/nodes看所有节点是否都正确加入了集群。这一套下来大部分问题的范围能缩小到“配置问题、网络问题、资源问题”三类。接着就是顺着链路逐级排查。比如head插件点了连接没反应第一步看浏览器开发工具的网络请求请求是否到达了9200端口如果到达了看ES返回的是什么状态码如果ES返回CORS相关的错误就去检查yml里的跨域配置如果请求根本没到去看Kibana或者其他前端代理是否正常工作。每个节点上排查都遵循“日志为主、猜测为辅”的原则不要凭感觉改配置每次只改一个参数改完看日志验证改错了就回滚。6. 集群上线后的日常运维建议6.1 每天/每周该看哪些指标集群部署完不是终点日常运维才是长期要做的事。我建议每天固定看一次_cluster/health确认status是green同时看节点的CPU、内存、磁盘使用率。每周再花几分钟看看JVM堆内存的使用趋势、分片数量是否异常膨胀、查询的响应延迟有没有明显上升。# 快速查看集群健康 curl -s http://192.168.80.101:9200/_cluster/health?pretty # 查看节点状态 curl -s http://192.168.80.101:9200/_cat/nodes?v # 查看索引大小和分片分布 curl -s http://192.168.80.101:9200/_cat/indices?v如果发现某个节点堆内存长期维持在85%以上就要考虑扩容或者清理数据了。ES集群的容量规划要留出余量磁盘用到70%左右就该准备清理或扩容等到90%报警再处理基本就处于很被动的状态了。6.2 数据备份与安全创建分片副本只是提供了高可用不是备份。如果业务数据很重要一定要配置ES的快照功能把索引备份到独立的存储上。# 注册快照仓库 curl -s -XPUT http://192.168.80.101:9200/_snapshot/my_backup -H Content-Type: application/json -d { type: fs, settings: { location: /data/es-backup } }注意location目录要提前创建好并且确保ES进程有权限写入。生产环境里最好把快照仓库挂载到独立的共享存储或者对象存储别跟数据盘放一起否则整台机器挂了数据盘和备份盘都没了等于没备份。6.3 关于6.5.4版本和未来升级的实话6.5.4这个版本在ES的版本历史里不算新官方也早已停止了维护。如果你的系统是新建的我建议直接用7.x甚至8.x的版本如果你是存量系统短时间内动不了那至少要做到两点一是不要轻易跨大版本升级ES的升级路径有严格限制5.x到6.x、6.x到7.x的迁移规则都不一样二是所有插件都要严格匹配版本比如IK分词器有专门的6.5.4版本装错版本会导致es启动后插件加载失败。我个人的体会是ES集群的坑大多数集中在部署初期真正跑起来之后反而相对稳定。把环境参数调好、把角色规划清楚、把常见错误准备好排查套路这套集群就能安安静静地为你服务很长一段时间。