ElasticSearch: Welche Vorteile kann Nginx für den ElasticSearch-Cluster bringen?

Elasticsearch ist eine fortschrittliche, leistungsstarke und skalierbare Open-Source-Suchmaschine, die eine Volltextsuche und Echtzeitanalyse strukturierter und unstrukturierter Daten ermöglicht.

Seine Besonderheit besteht darin, dass es die RESTful-API über HTTP nutzen kann, die sich leicht in die bestehende Webarchitektur integrieren lässt. Daher können wir bei hoher Parallelität den Nginx-Reverse-Proxy verwenden, um die Last auf mehrere Elasticsearch-Server auszugleichen.

Architekturdiagramm:

Was sind also die Vorteile der Verwendung von Nginx?

1. Zeichnen Sie das Protokoll jeder API-Zugriffsanforderung auf. (ElasticSearch selbst unterstützt diese Funktion nicht, nur slowLog und Serviceprotokolle)

2. Unterstützt eine große Anzahl von Clientverbindungen. Der offizielle ES-Blog empfiehlt die Verwendung von Keep-Alives und die Verwendung langer Verbindungen zwischen Nginx und ES. Nach meinem Verständnis ist ES unter normalen Umständen die unterste Schicht der Architektur und der Zugriff darauf erfolgt normalerweise über feste Dienste der oberen Schicht. Diese Situation eignet sich für die Verwendung von Keep-Alive. (Tatsächlich kann Nginx eine größere Anzahl von Client-Verbindungen unterstützen, unabhängig davon, ob Keep-Alive verwendet wird)

3. Lastausgleichende Anforderungen an den Elasticsearch-Server.

4. Daten zwischenspeichern, um Anfragen an den Elasticsearch-Server für denselben Inhalt erneut zu reduzieren.

5. Stellen Sie eine aktive Zustandserkennung bereit (nur Nginx Plus), erkennen Sie ständig, ob der Back-End-Elasticsearch-Server normal ist, und wechseln Sie aktiv. (Wenn ein ES auflegt, verteilt Nginx keine Anfragen an diesen Knoten. Wenn der Knoten wieder normal ist, kehrt er automatisch an seinen ursprünglichen Standort zurück)

6. Melden Sie umfangreiche Überwachungsindikatoren (nur Nginx Plus), Bereitstellung von Überwachung und Management.

7. Sicherheitsüberprüfung. Nur Clients mit Kontonamen und Passwörtern dürfen auf den ES-Cluster zugreifen.

8. Beschränken Sie den Zugriff auf spezielle Schnittstellen wie „_shutdown“. (Diese Funktion ist sehr praktisch)

9. Zugriffskontrolle mit Rollen (z. B. verfügt die Benutzerrolle über Datenzugriffsberechtigungen und die Administratorrolle über Berechtigungen zur Clusterverwaltung und -steuerung)

== == Ich konfiguriere das Beispiel Splitting line====

Eine einfache Nginx-Konfiguration sieht wie folgt aus:

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

Lange Verbindung, Lastausgleich, Zwischenspeicherung gültiger Anfragen für 10 Minuten, aktive Gesundheitsüberwachung und Statuserfassung.

====Ich bin die Trennlinie der Sicherheitsüberprüfungskonfiguration====

Eine Konfiguration mit Sicherheitsüberprüfung sieht wie folgt aus:

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

Die Passwortdatei befindet sich im selben Verzeichnis als nginx.conf, innen Das Format ist „Benutzername: crypt(3) verschlüsselte Passwortzeichenfolge“ pro Zeile:

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

Nach Abschluss der obigen Konfiguration und Neustart von Nginx wird der direkte Zugriff auf den Dienst gesperrt:

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

Mit dem richtigen Benutzernamen und Passwort können Sie problemlos darauf zugreifen:

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

====Ich bin die Trennlinie der Zugriffsbeschränkungskonfiguration====

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

  proxy_pass http://elasticsearch;
  proxy_redirect off;
}

Nachdem diese Konfiguration vorgenommen wurde, wird der direkte Zugriff auf _shutdown verweigert:

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

Für mein aktuelles Projekt müssen Anwendungen der oberen Schicht nur auf Daten in ES zugreifen, daher sollten API-Schnittstellen wie Cluster und Knoten den Zugriff für Anwendungen der oberen Schicht verweigern. Gleichzeitig sollte auch -DELETE für Ressourcen verboten werden, die nicht gelöscht werden sollen. Dies ist eine Sicherheitsgarantie für den ES-Cluster, da sonst die Clusterkonfiguration leicht geändert oder große Datenmengen gelöscht werden können.

====Ich bin die Trennlinie für die Konfiguration mit mehreren Rollen====

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

}

Unterscheiden Sie zwischen Administratoren und Benutzern, während Benutzer nur darauf zugreifen dürfen um auf die Schnittstellen _search und _analyze zuzugreifen.

Der Preis von Zugriffsbeschränkungen für mehrere Rollen besteht darin, dass jede Rolle eine andere Portnummer verwendet, um auf den Cluster zuzugreifen, was architektonisch sinnvoll ist – ein Client muss nur eine Rolle und einen entsprechenden Zugriffsport haben.

Mit Lua kann eine detailliertere URL-Berechtigungskontrolle durchgeführt werden. Nginx unterstützt auch die Einbettung von Lua sehr gut und prägnant. Wenn Sie interessiert sind, können Sie es herausfinden.

Referenzdokumentation:

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

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

Urheberrechtserklärung: Dieser Artikel ist ein Originalartikel des Bloggers und darf nicht ohne die Erlaubnis des Bloggers reproduziert werden.

Das Obige stellt ElasticSearch vor: Welche Vorteile kann Nginx dem ElasticSearch-Cluster bringen? Ich hoffe, dass es Freunden, die sich für PHP-Tutorials interessieren, hilfreich sein wird, einschließlich relevanter Inhalte.