Heim  >  Artikel  >  Backend-Entwicklung  >  ElasticSearch:Nginx可以给ElasticSearch集群带来什么福利?

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

WBOY
WBOYOriginal
2016-08-08 09:18:532096Durchsuche

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教程有兴趣的朋友有所帮助。

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn