Schritt-für-Schritt-Anleitung zur Konfiguration eines grundlegenden Drei-Knoten-Clusters

Ein Drei-Knoten-Elasticsearch-Cluster ist die kleinste Form, die ich als echtes Cluster und nicht als Labor betrachten würde. Es kann einen Master per Mehrheit wählen, Replikate von Primären fernhalten und den Ausfall eines Knotens überleben, wenn die Daten und Rollen sinnvoll konfiguriert sind. Es ist immer noch keine Magie. Drei winzige VMs mit vollen Festplatten verhalten sich nicht allein aufgrund ihrer Anzahl wie eine belastbare Suchplattform.

Diese Anleitung verwendet ein grundlegendes modernes Elasticsearch-Layout: drei Knoten, alle master-fähig und datenfähig, auf privaten Netzwerkadressen. Das ist ein vernünftiger Ausgangspunkt für eine kleine Umgebung. Größere Produktionsbereitstellungen trennen oft dedizierte Master-Knoten, Daten-Tiers, Ingest-Knoten, Machine-Learning-Knoten und reine Koordinationsknoten. Beginnen Sie hier einfach, dann teilen Sie die Rollen auf, wenn die Arbeitslast es rechtfertigt.

Die Beispiele gehen von Linux-Hosts und Paket- oder Archivinstallationen aus. Passen Sie die Dienstbefehle an Ihre Umgebung an.

Bevor Sie die Konfiguration bearbeiten

Sie benötigen drei separate Hosts oder VMs. Stellen Sie nicht drei "Knoten" auf ein Laptop und nennen Sie es hochverfügbar. Sie können zwar nützlich zum Testen der Erkennung sein, teilen sich aber dieselbe Ausfall-Domäne.

Jeder Host benötigt:

• Dieselbe Elasticsearch-Version.
• Eine stabile private IP oder einen DNS-Namen.
• Transport-Konnektivität zwischen Knoten auf Port 9300 (Standard).
• HTTP-Zugriff auf Port 9200 von Ihrem Admin-Host oder Load Balancer, falls erforderlich.
• Ausreichend Speicher für Primär- und Replikat-Shards.
• Zeitsynchronisation über NTP oder einen ähnlichen Dienst.
• Einen konfigurierten Datenpfad auf zuverlässigem lokalen oder angeschlossenen Speicher.

Aktuelle Elasticsearch-Distributionen enthalten ein gebündeltes JDK. Wenn Ihre Paketierung oder Version ein externes JDK erfordert, verwenden Sie die unterstützte Java-Version für diese Elasticsearch-Version, anstatt zu raten.

Verwenden Sie private Adressen in discovery.seed_hosts. Vermeiden Sie öffentliche IPs, es sei denn, Sie haben ein sehr spezifisches Design und strenge Netzwerkkontrollen.

Für diese Anleitung sind die Knoten:

node-1  10.0.10.11
node-2  10.0.10.12
node-3  10.0.10.13

Gemeinsame Cluster-Einstellungen konfigurieren

Bearbeiten Sie auf jedem Knoten elasticsearch.yml. Der Dateispeicherort hängt von der Installationsmethode ab. Paketinstallationen verwenden üblicherweise /etc/elasticsearch/elasticsearch.yml; Archivinstallationen verwenden config/elasticsearch.yml im extrahierten Verzeichnis.

Setzen Sie denselben Clusternamen auf allen drei Knoten:

cluster.name: my-three-node-cluster

Setzen Sie die Erkennungs-Seed-Hosts auf allen drei Knoten:

discovery.seed_hosts:
  - 10.0.10.11:9300
  - 10.0.10.12:9300
  - 10.0.10.13:9300

Setzen Sie die anfänglichen Master-Knoten nur für den ersten Bootstrap:

cluster.initial_master_nodes:
  - node-1
  - node-2
  - node-3

Die Werte müssen mit node.name übereinstimmen, nicht mit IP-Adressen, es sei denn, Ihre Knotennamen sind IP-ähnliche Zeichenfolgen. Diese Einstellung dient nur zum Bilden eines brandneuen Clusters. Nachdem das Cluster erfolgreich gebildet wurde, entfernen Sie cluster.initial_master_nodes von allen Knoten und lassen Sie es bei zukünftigen Neustarts weg. Wenn Sie es belassen, kann dies bei der Notfallwiederherstellung oder versehentlichen erneuten Bootstrap-Versuchen zu Verwirrung führen.

Binden Sie an das private Interface oder einen sicheren Host-Wert:

network.host: 10.0.10.11
http.port: 9200
transport.port: 9300

Verwenden Sie die eigene IP jedes Knotens für network.host. 0.0.0.0 ist in Beispielen praktisch, kann aber in der Produktion Elasticsearch auf Schnittstellen freigeben, die Sie nicht beabsichtigt haben. Wenn die automatische Sicherheitskonfiguration in Ihrer Version aktiviert ist, müssen Sie auch TLS-Zertifikate, Enrollment und Authentifizierung berücksichtigen.

Jeden Knotennamen konfigurieren

Auf Knoten 1:

node.name: node-1
network.host: 10.0.10.11
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

Auf Knoten 2:

node.name: node-2
network.host: 10.0.10.12
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

Auf Knoten 3:

node.name: node-3
network.host: 10.0.10.13
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

Wenn Sie für einen Test mehrere Knoten auf einer Maschine ausführen, verwenden Sie separate path.data- und path.logs-Werte. Für echte Cluster ist ein Knoten pro Host normalerweise das sauberere Modell.

Knotenrollen auswählen

Für ein kleines Drei-Knoten-Cluster können alle drei Knoten die Standardrollen tragen:

node.roles: [ master, data, ingest, remote_cluster_client ]

Dies gibt Ihnen drei master-fähige Knoten, sodass die Master-Wahl per Mehrheit funktioniert. Mit drei master-fähigen Knoten kann das Cluster einen verlieren und trotzdem einen Master wählen oder behalten. Wenn zwei weg sind, kann es keine sicheren Entscheidungen zum Cluster-Zustand treffen.

Für ein größeres Cluster sind dedizierte master-fähige Knoten oft besser, da schwere Daten- oder Ingest-Arbeit die Master-Aufgaben nicht aushungern kann. Das ist eine Verfeinerung der Skalierung, keine Anforderung für dieses grundlegende Setup.

Betriebssystem- und Netzwerkgrundlagen prüfen

Testen Sie vor dem Start von Elasticsearch die Transport-Konnektivität zwischen jedem Knotenpaar:

nc -vz 10.0.10.11 9300
nc -vz 10.0.10.12 9300
nc -vz 10.0.10.13 9300

Führen Sie diese nach Möglichkeit von jedem Knoten aus. Firewalls und Cloud-Sicherheitsgruppen müssen den Knoten-zu-Knoten-Transportverkehr zulassen. HTTP-Port 9200 ist für Clients und Admin-Aufrufe; Transport-Port 9300 wird von Cluster-Knoten verwendet, um miteinander zu kommunizieren.

Überprüfen Sie auch die Dateibesitzer für Daten- und Log-Verzeichnisse. Der Elasticsearch-Prozess muss in beide schreiben können.

Knoten starten

Für Paketinstallationen mit systemd:

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch
sudo systemctl start elasticsearch
sudo journalctl -u elasticsearch -f

Für Archivinstallationen während des Tests:

bin/elasticsearch

Starten Sie alle drei Knoten. Sie müssen nicht in einer perfekten Reihenfolge starten, aber beobachten Sie die Logs. Sie möchten sehen, dass sich das Cluster einmal bildet und Knoten beitreten. Wenn ein Knoten sagt, dass er keinen Master finden kann, konzentrieren Sie sich auf node.name, cluster.name, discovery.seed_hosts, Transport-Konnektivität und TLS/Sicherheitseinstellungen.

Sobald das Cluster gebildet ist, entfernen Sie cluster.initial_master_nodes aus der Konfiguration jedes Knotens und starten Sie später bei Bedarf während eines geplanten Fensters neu. Entfernen Sie es nicht, während Sie noch zum ersten Mal bootstrappen.

Cluster-Zustand überprüfen

Von einem Host, der Port 9200 erreichen kann:

curl -s "http://10.0.10.11:9200/_cluster/health?pretty"

Ein brandneues Cluster ohne Benutzer-Indizes kann grün mit null Shards anzeigen. Die zu überprüfenden Felder sind status, number_of_nodes und number_of_data_nodes.

Für eine kompakte Ansicht:

curl -s "http://10.0.10.11:9200/_cat/health?v"

Überprüfen Sie dann die Knotenmitgliedschaft:

curl -s "http://10.0.10.11:9200/_cat/nodes?v&h=ip,name,roles,master,cpu,heap.percent,ram.percent,disk.used_percent"

Sie sollten alle drei Knoten sehen. Ein Knoten hat die Markierung des gewählten Masters. Alle drei sollten die erwarteten Rollen anzeigen.

Testindex mit Replikaten erstellen

Erstellen Sie einen Testindex, um die Shard-Platzierung zu bestätigen:

curl -X PUT "http://10.0.10.11:9200/test-data-index?pretty"   -H 'Content-Type: application/json'   -d '{
    "settings": {
      "number_of_shards": 3,
      "number_of_replicas": 1
    }
  }'

Überprüfen Sie Shards:

curl -s "http://10.0.10.11:9200/_cat/shards/test-data-index?v"

Mit drei primären Shards und einem Replikat sollten Sie sechs Shard-Kopien sehen, die über die Knoten verteilt sind. Elasticsearch vermeidet es, ein Replikat auf demselben Knoten wie sein Primär zu platzieren.

Wenn das Cluster gelb ist, fragen Sie warum:

curl -X GET "http://10.0.10.11:9200/_cluster/allocation/explain?pretty"   -H 'Content-Type: application/json'   -d '{}'

Häufige Ursachen sind nicht genügend berechtigte Datenknoten, Disk-Watermarks, deaktivierte Allokation oder Allokations-Awareness-Regeln, die nicht zu Ihren Knotenattributen passen.

Verhalten bei einem Knotenausfall testen

Stoppen Sie in einem Nicht-Produktionstest einen Knoten:

sudo systemctl stop elasticsearch

Überprüfen Sie den Zustand von einem anderen Knoten:

curl -s "http://10.0.10.12:9200/_cluster/health?pretty"

Das Cluster sollte immer noch einen Master haben, da zwei von drei master-fähigen Knoten übrig sind. Abhängig vom Timing, der Shard-Verschiebung und der Replikat-Platzierung kann der Zustand grün oder gelb sein, während Elasticsearch reagiert. Starten Sie den Knoten erneut und beobachten Sie die Wiederherstellung:

sudo systemctl start elasticsearch
curl -s "http://10.0.10.12:9200/_cat/recovery?v&active_only=true"

Dieser Test ist sinnvoll, bevor das Cluster wichtig wird. Er lehrt Sie, wie eine normale Wiederherstellung aussieht, sodass ein echter Vorfall weniger überraschend ist.

Ein paar Produktionsleitplanken

Aktivieren und verstehen Sie die Sicherheit für Ihre Elasticsearch-Version. Setzen Sie keine unauthentifizierte HTTP-API dem Internet oder einem breiten internen Netzwerk aus.

Erstellen Sie Snapshots, bevor Sie sich auf das Cluster verlassen. Replikate schützen vor Knotenverlust; Snapshots schützen vor Löschung, Korruption und betrieblichen Fehlern.

Überwachen Sie die Festplattennutzung, den JVM-Heap-Druck, die Knotenanzahl, den Cluster-Zustand, ausstehende Aufgaben und den Snapshot-Erfolg. Ein Drei-Knoten-Cluster ist nur belastbar, wenn es genügend Kapazität zur Wiederherstellung hat.

Halten Sie die Shard-Anzahl bescheiden. Viele kleine Shards erzeugen Overhead. Ein grundlegendes Cluster kann von Tausenden winziger Indizes überwältigt werden, selbst wenn das Datenvolumen nicht groß ist.

Dokumentieren Sie schließlich die Bootstrap-Einstellungen und entfernen Sie cluster.initial_master_nodes nach der Bildung. Die meisten Probleme bei der Einrichtung von Drei-Knoten-Clustern resultieren aus kleinen Unstimmigkeiten: Knotennamen, die nicht mit Bootstrap-Namen übereinstimmen, blockierte Transport-Ports, wiederverwendete Datenverzeichnisse von alten Clustern oder Annahmen über Sicherheitsstandards. Überprüfen Sie diese zuerst, bevor Sie exotischere Einstellungen ändern.

Sicherheitshinweise für aktuelle Elasticsearch-Versionen

Viele moderne Elasticsearch-Installationen aktivieren Sicherheitsfunktionen während der Einrichtung. Das bedeutet, dass HTTP-Aufrufe möglicherweise HTTPS, ein CA-Zertifikat und Anmeldeinformationen erfordern. Wenn Ihr Cluster automatisch mit TLS konfiguriert wurde, könnte eine Zustandsprüfung eher so aussehen:

curl --cacert /etc/elasticsearch/certs/http_ca.crt \
  -u elastic \
  https://10.0.10.11:9200/_cluster/health?pretty

Deaktivieren Sie die Sicherheit nicht nur, damit ein Tutorial-Befehl funktioniert. Passen Sie stattdessen die Beispiele an Ihre Zertifikatspfade und Dienstkonten an. Erstellen Sie für die Produktion benannte Benutzer oder API-Schlüssel mit den erforderlichen Berechtigungen, anstatt den integrierten Superuser für die tägliche Arbeit zu verwenden.

Transport-TLS kann auch Knotenbeitritte beeinflussen. Wenn Knoten nicht beitreten können und die Logs Zertifikatsvertrauen, SAN-Konflikt, Handshake-Fehler oder Remote-Transport-Fehler erwähnen, überprüfen Sie die Zertifikate, bevor Sie die Erkennungseinstellungen ändern. Eine perfekte discovery.seed_hosts-Liste hilft nicht bei Knoten, die sich während des TLS-Handshakes gegenseitig ablehnen.

Häufige Startfehler

Wenn die Knoten kein Cluster bilden, überprüfen Sie zuerst die einfachen Dinge.

cluster.name muss auf allen Knoten übereinstimmen. Ein Knoten mit einem anderen Clusternamen wird nicht beitreten, nur weil er in der Seed-Host-Liste erscheint.

node.name muss mit den Werten übereinstimmen, die während des ersten Bootstraps in cluster.initial_master_nodes verwendet werden. Wenn die Konfiguration node-1 sagt, aber der Bootstrap es-node-1 auflistet, kann die Erkennung ins Stocken geraten.

Der Transport-Port muss zwischen Knoten erreichbar sein. HTTP-Zugriff auf 9200 reicht nicht. Verwenden Sie bei Bedarf nc, Sicherheitsgruppen-Inspektion oder Paketaufzeichnungen.

Datenverzeichnisse dürfen keine Metadaten von einem alten Cluster enthalten, es sei denn, Sie beabsichtigen, genau diesem Cluster wieder beizutreten. Die Wiederverwendung einer Festplatte von einem vorherigen Test kann verwirrende Fehler bezüglich Cluster-UUIDs oder unsicherem Bootstrap erzeugen.

Speicher- und Bootstrap-Prüfungen sind wichtig, wenn Sie an eine Nicht-Loopback-Adresse binden. Elasticsearch kann Prüfungen für Dateideskriptoren, virtuellen Speicher, Speichersperrung und Erkennungskonfiguration erzwingen. Lesen Sie das Startprotokoll, anstatt blind zu wiederholen.

Nachdem das Cluster funktioniert

Erstellen Sie ein Snapshot-Repository, bevor das Cluster wichtige Daten trägt. Replikate sind keine Backups. Ein schlechter Löschvorgang, ein Mapping-Fehler oder ein Anwendungsfehler replizieren schnell auf jede Kopie.

Notieren Sie die Knotennamen, IPs, Rollen, Datenpfade, Zertifikatsorte und Bootstrap-Verlauf in Ihrem Runbook. Während eines Ausfalls möchte niemand rückentwickeln, ob node-2 master-fähig sein soll.

Richten Sie Alarme für Knotenverlust, roten Zustand, langen gelben Zustand, Disk-Watermarks, JVM-Heap-Druck, fehlgeschlagene Snapshots und häufige Master-Wahlen ein. Ein Drei-Knoten-Cluster gibt Ihnen Raum, einen Ausfall zu überleben, aber nur, wenn Sie ihn bemerken und reparieren, bevor der zweite Ausfall eintritt.

Planen Sie die Kapazität mit Blick auf die Wiederherstellung. Wenn jeder Knoten mit sehr hoher Festplattenauslastung läuft, kann der Verlust eines Knotens zu wenig Platz für den Wiederaufbau von Replikaten lassen. Gesunde Cluster benötigen freie Kapazität, nicht nur genug Platz für die heutigen Primären.

Übung für Rolling Restart

Üben Sie einen Rolling Restart, bevor Sie ihn für ein Paket-Upgrade benötigen. Starten Sie einen Knoten neu, warten Sie, bis er wieder beitritt, bestätigen Sie Zustand und Wiederherstellung, und fahren Sie dann mit dem nächsten Knoten fort. Starten Sie nicht alle drei Knoten gleichzeitig neu, es sei denn, Sie führen absichtlich eine vollständige Cluster-Abschaltung durch.

Eine einfache Sequenz ist:

sudo systemctl restart elasticsearch
curl -s "http://10.0.10.11:9200/_cat/nodes?v"
curl -s "http://10.0.10.11:9200/_cluster/health?pretty"

Wenn das Cluster große Shards hat, überlegen Sie, ob die verzögerte Allokation vor geplanten Neustarts angepasst werden sollte. Ziel ist es, unnötigen Replikat-Wiederaufbau zu vermeiden, wenn ein Knoten in wenigen Minuten zurück ist. Überprüfen Sie nach der Wartung, dass die Allokation aktiviert ist und temporäre Einstellungen entfernt wurden.

Testen Sie auch das Client-Verhalten. Anwendungen sollten mehr als einen Elasticsearch-Endpunkt oder einen Load Balancer verwenden, der ausgefallene Knoten entfernt. Ein Drei-Knoten-Cluster hilft nur, wenn Clients die verbleibenden gesunden Knoten erreichen können, wenn ein Knoten ausfällt.

Eine letzte Gewohnheit hilft: Bewahren Sie eine Kopie der endgültigen elasticsearch.yml für jeden Knoten im Konfigurationsmanagement auf. Manuelle Bearbeitungen während der Einrichtung neigen dazu, abzuweichen, und Abweichungen sind genau das, was den nächsten Knotenersatz schwieriger macht als nötig.