Loading... # Elasticsearch(二) ## ES安装 1. 配置jdk 2. 下载ES并解压 3. 配置 - 开发模式: ES默认不用修改配置文件，开箱即用，在该模式下，ES会将一些问题以warning的方式打印出来，不会影响使用 - 生产模式: 修改了ES的网络或集群配置，会触发ES的引导检查，检查内存、JVM、集群节点等一系列配置，如果有问题，会以ERROR的形式展现，程序将无法启动 ### 配置 vi config/elasticsearch.yml ``` network.host: 0.0.0.0 # 远程访问 http.port: 9200 # http 端口 discovery.seed_hosts: ["127.0.0.1"] cluster.initial_master_nodes: ["node-1"] # 单机环境，解开注释并删除一个节点 node.max_local_storage_nodes: 100 # 一台服务器可以运行的节点数目 ``` vi /etc/security/limits.conf 追加以下内容； ``` * soft nofile 65536 * hard nofile 65536 ``` 此文件修改后需要重新登录用户，才会生效。登录后使用`ulimit -S -n`和`ulimit -H -n`查看。 修改es的内存权限大小，在root用户下执行`sysctl -w vm.max_map_count=262144`，执行之后查看结果`sysctl -a|grep vm.max_map_count`成功会显示`vm.max_map_count = 262144`,但该设置重启之后会失效，所以还要修改`/etc/sysctl.conf`文件，在文件最后添加: ``` vm.max_map_count=262144 ``` ### 启动ES ES不支持在root用户下启动，因此需要创建新的用户 ``` adduser elasticsearch # 添加用户elasticsearch passwd elasticsearch # 修改elasticsearch用户的密码 chown -R elasticsearch /usr/local/elasticsearch # 将ES文件夹权限赋给用户 su elasticsearch # 切换到elasticsearch用户 ``` 进入ES的bin目录，执行`./elasticsearch`启动ES，如需后台启动执行`./elasticsearch -d`,启动之后浏览器访问`http://IP:9200`,输出节点信息，表示启动成功。 ## Kibana安装 下载Kibana并解压，Kibana依然是开箱即用，默认连接的是本机上的ES，可以修改`config/kibana.yml` ``` server.port: 5601 # Kibana的服务端口 server.host: "0.0.0.0" # Kibana的服务地址，配置0.0.0.0远程访问 elasticsearch.hosts: ["http://localhost:9200"] # ES服务的访问地址 ``` 修改之后进入bin目录，执行`./kibana`启动Kibana，如果在root用户下，需要执行`./kibana --allow-root`,启动之后访问`http://IP:5601`就可以访问Kibana可视化web界面。 ## 安装Head插件(选装) Head插件提供可视化操作页面，对ES搜索引擎进行各种设置和数据检索功能，可以很直观地查看集群的健康情况，索引分配情况，还可以管理索引和集群以及通过方便快捷的搜索功能等等。 ### 下载地址 > https://github.com/mobz/elasticsearch-head 安装需要依赖nodejs和grunt管理工具 1. 安装node，然后执行`npm install -g grunt-cli`命令，安装grunt管理工具 2. 下载Head插件，并解压 3. 进入elasticsearch-head-master目录，修改Gruntfile.js文件，添加`hostname: '*'` ``` connect: { server: { options: { hostname: '*', port: 9100, base: '.', keepalive: true } } } ``` 4. 在当前目录执行`npm install`安装依赖。如果遇到`Failed at the phantomjs-prebuilt@2.1.16 install script`错误，就先执行`npm install phantomjs-prebuilt@2.1.14 --ignore-scripts` 5. 在当前目录下执行`npm run start`启动Head插件 6. 启动之后访问`http://IP:9100`,查看web界面 7. 如果无法发现ES节点，尝试在ES配置文件中设置允许跨域 ``` http.cors.enabled: true http.cors.allow-origin: "*" ``` ## 集群健康值 ### 健康值检查 ``` http://IP:9200/_cat/health http://IP:9200/_cat/health?v http://IP:9200/_cluster/health ``` ### 健康值状态 1. Green: 所有Primary和Replica均为active状态，集群健康 2. Yellow: 至少一个Replica不可用，但是所有Primary均为active，数据仍然是可以保证完整性的 3. Red: 至少有一个Primary为不可用状态，数据不完整，集群不可用 ## 基本操作 1. 创建索引: `PUT product?pretty` 2. 查询索引状态: `GET _cat/indices?v` 3. 删除索引: `DELETE product?pretty` 4. 插入数据: ``` PUT /index/_doc/id # 由于ES7.x取消了type的概念，统一用_doc代替,id为该document的id { Json数据 } ``` 5. 查询数据: `GET product/_doc/_search` 6. 更新数据: 1. 全量替换: 使用插入操作，设置相同的id，会对document进行全量替换，但是需要指定所有的field，新的直接取代老的 2. 指定字段更新，将PUT操作改为POST操作 ``` POST product/_doc/1/_update { "doc":{ "price":13999 # 将product的_doc下id为1的记录的price修改为13999 } } ``` 7. 删除数据: `DELETE product/_doc/id` ## ES分布式 ### ES如何实现高可用 生产环境均为一台机器一个节点。 1. ES在分配单个索引的分片时，会将每个分片尽可能分配到更多的节点上。但是，实际情况取决于集群拥有的分片和索引的数量以及它们的大小，不一定总是能均匀地分布。 2. ES不允许Primary和它的Replica放在同一个节点中，并且同一个节点不接受完全相同的两个Replica。Shard的状态: - relocating_shards: 迁移中的分片数量 - initializing_shards: 初始化中的分片数量 - unassigned_shards: 未成功分配的分片数量 - 因为同一个节点不接受完全相同的两个Replica，如果有2个节点，有3个Primary然后每个Primary有2个Replica，总共有9个shard，但是只能分配6个，另外3个Replica将无处分配，处于unassigned_shards状态，集群状态就是Yellow，但不影响使用 3. 同一个节点允许多个索引的分片同时存在 ### 容错机制 ES在局部出错异常的情况下，保证服务正常运行并且有自动回复能力 #### ES-node 1. Master: 主节点，每个集群都有且只有一个 - 尽量避免Master节点`node.data=true` 2. Voting: 投票节点 - `node.voting_only=true`,仅投票节点，即使配置了`node.master=true`，也不会参选，但是仍然可以作为数据节点 3. Coordinating: 协调节点,每个节点都是一个隐式的协调节点，如果同时设置了`node.master=false`和`node.data=false`,那么此节点将成为仅协调节点 4. Master-eligible node: 候选节点 5. Data node: 数据节点 6. Ingest node: 预处理节点 7. Machine learning node: 机器学习节点 #### node.master和node.data 1. `node.master=true`,`node.data=true`，这是ES的默认配置，既作为候选节点，又作为数据节点，这样的节点一旦被选举为Master，压力是比较大的，通常来说Master节点应该只承担较为轻量级的任务，比如创建删除索引，分片均衡等。 2. `node.master=true`,`node.data=false`只作为候选节点，不作为数据节点。可参选Master节点，当选后成为真正的Master节点。 3. `node.master=false`,`node.data=false`,既不当候选节点，也不作为数据节点，那就是仅协调节点，负责负载均衡。 4. `node.master=false`,`node.data=true`,不作为候选节点，但是作为数据节点，这样的店节点主要负责数据存储和查询服务。 #### 容错机制步骤 1、当Master宕机后，选举新的Master ![ES 选举.jpg][1] 选举过程如上图，可能会产生脑裂问题，即多个Master节点同时对外服务，解决方法是设置`discovery.zen.minimum_master_nodes=N/2+1` ![ES脑裂.jpg][2] 如上图，有两个节点，一个Master，一个Slave。然后通讯出现了故障，Slave发现Master失联，发起投票，投了自己一票，晋升成Master，此时网络恢复，就会造成两个Master对外提供服务。解决: `discovery.zen.minimum_master_nodes=N/2+1` ![ES Cluster01.jpg][3] 投票节点通常与候选节点配置数量相同，这种情况只要有一半以上的投票节点可用，集群就可以正常工作。三个或四个候选节点，可以容忍一个节点宕机，如果有两个或更少的候选节点，则它们必须都保持可用。 集群中通常有奇数个候选节点，如果是偶数，Elasticsearch将其中一个排除在投票配置之外，以确保候选节点大小为奇数，这样不会降低集群的容错能力。这样为了保证网络被分为两个相等大小的分区时，选举的可用性。 ![ES Cluster02.jpg][4] 如图，4个节点，只能容忍一个节点宕机，如果其中两个节点在A机房，两个节点在B机房，此时A机房与B机房之间通信故障，由于必须票数过半才能选出新的Master，4个节点就是需要3张选票，但是每一边都是2个节点，导致无法选出可用的Master，对外表现就是集群不可用。但是如果减少一个节点，只需要两票就能选出Master，就保证了其中一方可以选出新的Master，保证了一半节点的可用状态。 2、Replica容错，新的(或者原有)Master节点会将丢失的Primary对应的某个副本提升为Primary 3、Master节点会尝试重启故障机 4、数据同步，Master会将宕机期间丢失的数据同步到重启机器对应的分片上去 ## 总结 如何提高ES分布式系统的可用性以及性能最大化 1. 每台节点的Shard数量越少，每个Shard分配的CPU、内存、IO资源越多，单个Shard的性能越好，当一台机器一个Shard时，单个Shard性能最好。 2. 稳定的Master节点对于集群健康非常重要！理论上讲，应该尽可能地减轻Master节点的压力，分片数量越多，Master节点维护管理Shard的任务越重，并且节点可能就要承担更多的数据转发任务，可增加“仅协调”节点来缓解Master节点和Data节点的压力，但是在集群中添加过多的仅协调节点会增加整个集群的负担，因为选择的主节点必须等待每个节点的集群状态更新确认。 3. 如果相同资源分配的前提下，Shard数量越少，单个Shard的体积越大，查询性能越低，速度越慢，这个取舍应该根据实际集群状况和结合应用场景等因素综合考虑。 4. 数据节点和Master节点一定要分开，集群规模越大，这样做的意义也就越大。 5. 数据节点处理与数据相关的操作，例如CRUD、搜索和聚合。这些操作是I/O、内存和CPU密集型的，所以它们需要更高配置的服务器以及更高的带宽，并且集群的性能冗余非常重要，宕机有可能是超过了负载，三台机器都扛不住，变成两台更扛不住，所以一定要保证性能冗余。 6. 由于仅投票节点不参与Master竞选，所以和真正的Master节点相比，它需要的内存和CPU较少。但是，所有候选节点以及仅投票节点都可能是数据节点，所以它们都需要快速稳定低延迟的网络。 7. 高可用性(HA)集群至少需要三个节点，其中**至少两个不是仅投票节点**。即使其中一个节点发生故障，这样的集群也将能够选举一个主节点。生产环境最好设置3台仅Master候选节点(`node.master=true`,`node.data=false`) 8. 为确保集群可用，集群**不能同时停止投票配置中的一半或更多节点**。只要有一半以上的投票节点可用，集群仍可以正常工作。这意味着，如果存在三个或四个候选节点，则集群可以容忍其中一个节点不可用。如果有两个或更少的候选节点，则它们必须都保持可用。 [1]: https://www.princelei.club/usr/uploads/2020/07/145502507.jpg [2]: https://www.princelei.club/usr/uploads/2020/07/417216800.jpg [3]: https://www.princelei.club/usr/uploads/2020/07/1415342712.jpg [4]: https://www.princelei.club/usr/uploads/2020/07/2657930737.jpg Last modification：July 21st, 2020 at 10:44 pm © 允许规范转载
