首页  >  文章  >  后端开发  >  ElasticSearch:Nginx可以给ElasticSearch集群带来什么福利?

ElasticSearch:Nginx可以给ElasticSearch集群带来什么福利?

WBOY
WBOY原创
2016-08-08 09:18:532164浏览

Elasticsearch是一种先进的,高性能的,可扩展的开源搜索引擎,提供全文搜索和实时分析的结构化和非结构化的数据。

它的特点是可以通过HTTP使用 RESTful API,很容易的融入现有的web架构。因此在高并发的情况下,我们可以采用nginx反向代理负载均衡到多台Elasticsearch 服务器上。

架构图:

ElasticSearch:Nginx可以给ElasticSearch集群带来什么福利?

那么使用nginx有什么好处呢?

1. 记录每个API访问请求的日志。(ElasticSearch本身不支持这个功能,只有slowLog和服务日志)

2. 支持大量的客户端连接。ES官方的blog中推荐使用keep-alives,在nginx和ES之间使用长连接。我理解是因为在通常情况下,ES都是架构中的底层,访问它的一般是固定的上层服务,这种情况是适用于使用keep-alive的。(实际上不管用不用keep-alive,nginx都可以起到支持更大量客户端连接的作用)

3. 负载均衡的请求Elasticsearch服务器。

4. 缓存数据,减少同一内容再次请求Elasticsearch服务器。

5. 提供主动健康检测(仅nginx plus),不断检测后端Elasticsearch服务器是否正常,并主动的进行切换。(当某台ES挂掉的时候,nginx不分发请求到此结点,当结点重新恢复正常时,自动归位)

6. 报告丰富的监控指标(仅nginx plus),提供监控和管理。

7. 安全验证。只让持有账户名密码的客户端访问到ES集群。

8. 对特殊接口如"_shutdown"限制访问。(这个功能相当实用)

9. 带角色的访问控制(比如user角色拥有数据访问权限,admin角色拥有集群管控权限)

====我是配置例子的分割线====

一个简单的nginx配置如下:

upstream elasticsearch_servers {
    zone elasticsearch_servers 64K;
    server 192.168.187.132:9200;
    server 192.168.187.133:9200;
    keepalive 40 ;
}
match statusok {
    status 200;
    header Content-Type ~ "application/json";
    body ~ '"status" : 200';
}
server {
    listen 9200;
    status_zone elasticsearch;
    location / {
        proxy_pass http://elasticsearch_servers;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_cache elasticsearch;
        proxy_cache_valid 200 302 10m;
        proxy_cache_valid 404 1m;
        proxy_connect_timeout 5s;
        proxy_read_timeout 10s;
        proxy_set_header Connection "Keep-Alive";
        proxy_set_header Proxy-Connection "Keep-Alive";
        health_check interval=5s fails=1 passes=1 uri=/ match=statusok;

    } 
    # redirect server error pages to the static page /50x.html
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root /usr/share/nginx/html;
    }
    access_log logs/es_access.log combined;
}
server {
    listen 8080;
    root /usr/share/nginx/html;
    location / {
        index status.html;
    }
    location =/status {
        status;
    }
}
长连接、负载均衡、对有效的请求缓存10分钟、主动的健康监测、状态收集。

====我是安全验证配置的分割线====

一个带安全验证的配置如下:

events {
  worker_connections  1024;
}

http {

  upstream elasticsearch {
    server 127.0.0.1:9200;
  }

  server {
    listen 8080;

    auth_basic "Protected Elasticsearch";
    auth_basic_user_file passwords;

    location / {
      proxy_pass http://elasticsearch;
      proxy_redirect off;
    }
  }
}
passwords文件和nginx.conf在同一目录,里面的格式是按行的"用户名:crypt(3)加密后的密码串":
$ printf "john:$(openssl passwd -crypt s3cr3t)n" > passwords
做完以上配置后重启nginx,则直接访问服务会被禁止:
$ curl -i localhost:8080
# HTTP/1.1 401 Unauthorized
# ...
通过正确的用户名密码则可顺利访问:
$ curl -i john:s3cr3t@localhost:8080
# HTTP/1.1 200 OK
# ...

====我是访问限制配置的分割线====

location / {
  if ($request_filename ~ _shutdown) {
    return 403;
    break;
  }

  proxy_pass http://elasticsearch;
  proxy_redirect off;
}

做了此配置之后,直接访问_shutdown会被拒绝:

$ curl -i -X POST john:s3cr3t@localhost:8080/_cluster/nodes/_shutdown
# HTTP/1.1 403 Forbidden
# ....

针对我目前的项目,上层应用仅需要访问ES中的数据,所以cluster和node等API接口都应拒绝上层应用的访问。同时,对不应被删除的资源进行-DELETE也应禁止。这对ES集群是一种安全保证,否则轻易就可以被修改集群配置或删除大量数据。

====我是多角色配置的分割线====

events {
  worker_connections  1024;
}

http {

  upstream elasticsearch {
      server 127.0.0.1:9200;
  }

  # Allow access to /_search and /_analyze for authenticated "users"
  #
  server {
      listen 8081;

      auth_basic           "Elasticsearch Users";
      auth_basic_user_file users;

      location / {
        return 403;
      }

      location ~* ^(/_search|/_analyze) {
        proxy_pass http://elasticsearch;
        proxy_redirect off;
      }
  }

  # Allow access to anything for authenticated "admins"
  #
  server {
      listen 8082;

      auth_basic           "Elasticsearch Admins";
      auth_basic_user_file admins;

      location / {
        proxy_pass http://elasticsearch;
        proxy_redirect off;
      }
  }

}
区分admins和users两种权限,admins可以访问一切API,而users只允许访问_search和_analyze接口。

多角色访问限制的代价是每个角色使用不同的端口号访问集群,这在架构上是合理的——一个客户端只需要拥有一种角色,也对应一个访问端口。

使用lua可以进行更细致的url权限控制,nginx对lua的嵌入也支持得很好很简洁,此处不做更多深入的探究。有兴趣可以了解。

参考文档:

http://www.ttlsa.com/nginx/nginx-elasticsearch/

https://www.elastic.co/blog/playing-http-tricks-nginx

版权声明:本文为博主原创文章,未经博主允许不得转载。

以上就介绍了ElasticSearch:Nginx可以给ElasticSearch集群带来什么福利?,包括了方面的内容,希望对PHP教程有兴趣的朋友有所帮助。

声明:
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn