ElasticSearch: Nginx は ElasticSearch クラスターにどのようなメリットをもたらしますか?-PHPチュートリアル-php.cn

ElasticSearch: Nginx は ElasticSearch クラスターにどのようなメリットをもたらしますか?

WBOY

リリース： 2016-08-08 09:18:53

オリジナル

2170 人が閲覧しました

Elasticsearch は、構造化データと非構造化データの全文検索とリアルタイム分析を提供する、高度で高性能、スケーラブルなオープンソース検索エンジンです。

その特徴は、HTTP経由でRESTful APIを使用できることであり、既存のWebアーキテクチャに簡単に統合できます。したがって、同時実行性が高い場合は、nginx リバースプロキシを使用して複数の Elasticsearch サーバーに負荷を分散できます。

アーキテクチャ図:

ElasticSearch: Nginx は ElasticSearch クラスターにどのようなメリットをもたらしますか?

それでは、nginxを使用する利点は何でしょうか?

1. 各 API アクセスリクエストのログを記録します。 (ElasticSearch 自体はこの機能をサポートしません。slowLog とサービスログのみをサポートします)

2. 多数のクライアント接続をサポートします。 ES の公式ブログでは、キープアライブを使用し、nginx と ES の間で長い接続を使用することを推奨しています。私の理解では、通常の状況では、ES はアーキテクチャの最下位層であり、通常は固定された上位層のサービスによってアクセスされます。この状況はキープアライブの使用に適しています。 (実際、nginx はキープアライブが使用されているかどうかに関係なく、より多くのクライアント接続をサポートできます)

3. Elasticsearch サーバーへのリクエストの負荷分散。

4. データをキャッシュして、同じコンテンツを Elasticsearch サーバーに再度リクエストする必要性を減らします。

5. アクティブなヘルス検出を提供し (nginx plus のみ)、バックエンド Elasticsearch サーバーが正常かどうかを常に検出し、アクティブに切り替えます。 (ES がハングアップすると、nginx はこのノードにリクエストを分散しません。ノードが通常に戻ると、自動的に元の場所に戻ります)

6. 豊富な監視インジケーター (nginx plus のみ) をレポートし、監視と管理を提供します。。

7. セキュリティの検証。アカウント名とパスワードを持つクライアントのみが ES クラスターへのアクセスを許可されます。

8. 「_shutdown」などの特別なインターフェイスへのアクセスを制限します。 (この機能は非常に実用的です)

9. ロールによるアクセス制御 (たとえば、ユーザーロールにはデータアクセス権があり、管理者ロールにはクラスター管理および制御権限があります)

====私は、設定例====

簡単な nginx 設定は次のとおりです:

長時間の接続、ロードバランシング、10 分間の有効なリクエストのキャッシュ、アクティブなヘルスモニタリング、およびステータスの収集。

====セキュリティ検証構成の境界線は私です====

セキュリティ検証を伴う構成は次のとおりです:

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;
    }
}

ログイン後にコピー

passwords ファイルと nginx.conf は同じディレクトリにあり、内部の形式は line-賢明な "ユーザー名: crypt (3) 暗号化されたパスワード文字列":

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;
    }
  }
}

ログイン後にコピー

が上記の構成を完了し、nginx を再起動すると、サービスへの直接アクセスが禁止されます。

$ printf "john:$(openssl passwd -crypt s3cr3t)n" > passwords

ログイン後にコピー

は正しいユーザー名とパスワードを使用してスムーズにアクセスできます。

$ curl -i localhost:8080
# HTTP/1.1 401 Unauthorized
# ...

ログイン後にコピー

====アクセス制限設定の境界線は私です====

$ curl -i john:s3cr3t@localhost:8080
# HTTP/1.1 200 OK
# ...

ログイン後にコピー

この設定を行った後は、_shutdown への直接アクセスが拒否されます:

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

  proxy_pass http://elasticsearch;
  proxy_redirect off;
}

ログイン後にコピー

現在のプロジェクトでは、上位層アプリケーションに必要なのはES 内のデータにアクセスするため、クラスターやノードなどの API インターフェイスは上位層アプリケーションへのアクセスを拒否する必要があります。同時に、削除すべきではないリソースに対する -DELETE も禁止する必要があります。これは ES クラスターのセキュリティを保証するものであり、そうでない場合、クラスター構成が簡単に変更されたり、大量のデータが削除されたりする可能性があります。

====私はマルチロール構成の境界線です====

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

ログイン後にコピー

は管理者とユーザーを区別しますが、管理者はすべての API にアクセスできますが、ユーザーは _search インターフェイスと _analyze インターフェイスのみにアクセスできます。

マルチロールのアクセス制限のコストは、各ロールが異なるポート番号を使用してクラスターにアクセスすることですが、これはアーキテクチャ的に合理的です。クライアントは 1 つのロールを持ち、1 つのアクセスポートに対応するだけで済みます。

lua を使用すると、より詳細な URL 権限制御を実行できます。nginx は lua の埋め込みも非常に適切かつ簡潔にサポートします。ここではこれ以上詳しく説明しません。興味があれば調べることができます。

参考ドキュメント:

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

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

著作権表示: この記事はブロガーによるオリジナル記事であり、ブロガーの許可なしに転載することを禁じます。

上記は ElasticSearch の紹介です。Nginx は ElasticSearch クラスターにどのようなメリットをもたらしますか? 、関連コンテンツも含めて、PHP チュートリアルに興味のある友人に役立つことを願っています。