Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Search-/Log-Analytics-Cluster leiden nicht nur an RAM: falsche Shards, wachsende Retention, teure Aggregationen und wenig Disk-Puffer schaden Cluster Health. OpenSearch empfiehlt dedizierte Cluster-Manager-Nodes.
OpenSearch nennt drei dedizierte Cluster-Manager-Nodes als passenden Production-Ansatz für fast alle Fälle. Data Nodes tragen Storage/Search/Indexing und sollten über Zonen verteilt werden.
Cluster-Manager verwalten Cluster-State, Data Nodes speichern/suchen Shards, Ingest Nodes verarbeiten Pipelines und Coordinating Nodes verteilen Queries.
Elastic nennt als allgemeine Orientierung 10–50 GB pro Shard und unter 200 Mio. Dokumente pro Shard; reales Optimum per Benchmark bestimmen.
Replicas, Merges, Segment-Overhead und Watermark-Puffer erhöhen Storage über Primary Data hinaus.
Endpoint und Auth an eigenes Cluster anpassen.
Türkei (Türkisch)
Germany (German)
Worldwide (English)
curl -s http://localhost:9200/_cluster/health?prettycurl -s http://localhost:9200/_cat/nodes?vcurl -s http://localhost:9200/_cat/shards?v | head -n 40curl -s http://localhost:9200/_cat/indices?v&s=store.size:desc | head -n 30Neue Nodes lösen Oversharding oder schlechte Index-Lifecycle-Policies nicht automatisch.
Sie haben gemeinsame Wurzeln, sind aber separate Projekte. Version/Plugins separat prüfen.
Elastic nennt oft 10–50 GB als Orientierung; Search, Recovery und Ingest benchmarken.
Es läuft, bietet aber keine Replica-Redundanz/Node-Failure-Toleranz; für kritische Production Multi-Node erwägen.
Teilen Sie täglichen Ingest, Retention, Index-Anzahl, Query-Typ und Shard-Verteilung; Nodes/RAM/NVMe planen.