{"id":75796,"date":"2020-03-28T19:42:18","date_gmt":"2020-03-28T17:42:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb"},"modified":"2020-03-28T19:42:18","modified_gmt":"2020-03-28T17:42:18","slug":"klaster-elasticsearch-na-200-tb","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","title":{"rendered":"Elasticsearch-Cluster mit 200 TB+","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster mit 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ca7a31eca0b3d4faf648dfb24ffbe215.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Viele stehen vor der Herausforderung, elasticsearch zu nutzen. Aber was passiert, wenn man damit Logs \u201ein besonders gro\u00dfem Umfang\u201c speichern m\u00f6chte? Und das auch noch ohne schmerzhaft den Ausfall eines der mehreren Rechenzentren zu erleben? Wie sollte die Architektur aussehen und auf welche Stolpersteine k\u00f6nnte man sto\u00dfen?<\/p>\n<p><\/p>\n<p>Wir bei Odnoklassniki haben uns entschieden, mit elasticsearch das Problem des Log-Managements zu l\u00f6sen, und teilen nun unsere Erfahrungen mit Habr: sowohl zur Architektur als auch zu den Stolpersteinen.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Ich bin Peter Saizev und arbeite als Systemadministrator bei Odnoklassniki. Zuvor war ich auch Admin und habe mit Manticore Search, Sphinx Search und Elasticsearch gearbeitet. Wenn ein weiteres &#8230;search auftaucht, werde ich wahrscheinlich auch damit arbeiten. Au\u00dferdem bin ich an mehreren Open-Source-Projekten auf freiwilliger Basis beteiligt.<\/p>\n<p><\/p>\n<p>Als ich zu Odnoklassniki kam, sagte ich leichtfertig im Vorstellungsgespr\u00e4ch, dass ich mit Elasticsearch umgehen kann. Nachdem ich mich eingearbeitet hatte und einige einfache Aufgaben erledigte, bekam ich eine gro\u00dfe Aufgabe zur Reformierung des Log-Management-Systems, das zu diesem Zeitpunkt existierte. <\/p>\n<p><\/p>\n<h2 id=\"trebovaniya\">Anforderungen<\/h2>\n<p><\/p>\n<p>Die Anforderungen an das System waren wie folgt formuliert:<\/p>\n<p><\/p>\n<ul>\n<li>Als Frontend sollte Graylog verwendet werden. Denn das Unternehmen hatte bereits Erfahrung mit diesem Produkt, die Programmierer und Tester kannten es, es war f\u00fcr sie vertraut und komfortabel.<\/li>\n<li>Datenvolumen: im Durchschnitt 50-80 Tausend Nachrichten pro Sekunde, aber wenn etwas kaputt geht, ist der Datenverkehr unbegrenzt, das k\u00f6nnen 2-3 Millionen Zeilen pro Sekunde sein.<\/li>\n<li>Nachdem wir mit den Kunden die Anforderungen an die Verarbeitungsgeschwindigkeit der Suchanfragen besprochen hatten, verstanden wir, dass das typische Nutzungsmuster eines solchen Systems ist, dass die Leute die Logs ihrer Anwendung der letzten zwei Tage suchen und nicht l\u00e4nger als eine Sekunde auf das Ergebnis ihrer Anfrage warten m\u00f6chten. <\/li>\n<li>Die Administratoren bestanden darauf, dass das System bei Bedarf einfach skalierbar ist, ohne dass sie tief in die Funktionsweise eintauchen m\u00fcssen. <\/li>\n<li>Die einzige Wartungsaufgabe, die diese Systeme periodisch ben\u00f6tigten, bestand darin, etwas Hardware auszutauschen.<\/li>\n<li>Au\u00dferdem gibt es bei Odnoklassniki eine hervorragende technische Tradition: Jeder Service, den wir starten, muss einen Ausfall des Rechenzentrums (pl\u00f6tzlich, ungeplant und jederzeit) \u00fcberstehen.<\/li>\n<\/ul>\n<p><\/p>\n<p>Die letzte Anforderung f\u00fcr die Umsetzung dieses Projekts hat uns am meisten gefordert, wor\u00fcber ich sp\u00e4ter n\u00e4her berichten werde.<\/p>\n<p><\/p>\n<h2 id=\"sreda\">Umgebung<\/h2>\n<p><\/p>\n<p>Wir arbeiten in vier Rechenzentren, wobei die Elasticsearch-Datenknoten nur in dreien untergebracht werden k\u00f6nnen (aus verschiedenen nicht-technischen Gr\u00fcnden).<\/p>\n<p><\/p>\n<p>In diesen vier Rechenzentren befinden sich etwa 18.000 verschiedene Log-Quellen \u2013 Hardware, Container, virtuelle Maschinen.<\/p>\n<p><\/p>\n<p>Eine wichtige Besonderheit: Der Cluster wird in Containern gestartet <noindex><a rel=\"nofollow\" href=\"https:\/\/podman.io\">Podman<\/a><\/noindex> nicht auf physischen Maschinen, sondern auf <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/346868\/\">unserem eigenen Cloud-Produkt one-cloud<\/a><\/noindex>. Den Containern werden 2 Kerne garantiert, \u00e4hnlich wie 2.0Ghz v4, mit der M\u00f6glichkeit, die anderen Kerne bei Leerlauf zu nutzen. <\/p>\n<p><\/p>\n<p>Mit anderen Worten:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster mit 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/073bffbfc3cff761bfabe0773b7f4ebc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"topologiya\">Topologie<\/h2>\n<p><\/p>\n<p>Das Gesamtbild der L\u00f6sung erschien mir urspr\u00fcnglich wie folgt:<\/p>\n<p><\/p>\n<ul>\n<li>3-4 VIPs stehen hinter dem A-Record der Domain Graylog, das ist die Adresse, an die die Logs gesendet werden.<\/li>\n<li>Jeder VIP fungiert als LVS-Lastenausgleich.<\/li>\n<li>Danach gelangen die Logs in eine Graylog-Batterie, einige Daten werden im GELF-Format und einige im Syslog-Format gesendet.<\/li>\n<li>Anschlie\u00dfend werden all dies in gro\u00dfen Batches in eine Batterie von Elasticsearch-Koordinatoren geschrieben. <\/li>\n<li>Diese senden dann Lese- und Schreibanfragen an die entsprechenden Datenknoten. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster mit 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/21efcdf6992a07e0c5e9b477c567cca9.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"terminologiya\">Terminologie<\/h2>\n<p><\/p>\n<p>M\u00f6glicherweise sind nicht alle mit der Terminologie vertraut, daher m\u00f6chte ich etwas darauf eingehen.<\/p>\n<p><\/p>\n<p>In Elasticsearch gibt es mehrere Knotentypen \u2013 Master, Koordinator, Datenknoten. Es gibt noch zwei weitere Typen f\u00fcr verschiedene Log-Transformationen und zur Verbindung verschiedener Cluster, aber wir haben nur die genannten verwendet. <\/p>\n<p><\/p>\n<p><strong>Master<\/strong><br \/>\nPingt alle im Cluster vorhandenen Knoten an, h\u00e4lt die aktuelle Clusterkarte aufrecht und verbreitet sie zwischen den Knoten, verarbeitet die Ereignislogik und k\u00fcmmert sich um verschiedene Arten von clusterweiten Wartungsarbeiten. <\/p>\n<p><\/p>\n<p><strong>Koordinator<\/strong><br \/>\nF\u00fchrt eine einzige Aufgabe aus: nimmt Anfragen von Clients zum Lesen oder Schreiben entgegen und leitet diesen Traffic weiter. Wenn die Anfrage f\u00fcr eine Schreiboperation ist, fragt er wahrscheinlich den Master, in welchen Shard des relevanten Indexes er dies ablegen soll, und leitet die Anfrage weiter. <\/p>\n<p><\/p>\n<p><strong>Datenknoten<\/strong><br \/>\nSpeichert Daten, f\u00fchrt ankommende Suchanfragen und Operationen auf den darauf befindlichen Shards aus.<\/p>\n<p><\/p>\n<p><strong>Graylog<\/strong><br \/>\nDas ist eine Art Mischung aus Kibana mit Logstash im ELK-Stack. Graylog kombiniert sowohl UI als auch einen Verarbeitungs-Workflow f\u00fcr Logs. Unter der Haube arbeiten Kafka und Zookeeper in Graylog, welche die Konnektivit\u00e4t von Graylog als Cluster gew\u00e4hrleisten. Graylog kann Logs (Kafka) zwischenspeichern, falls Elasticsearch nicht verf\u00fcgbar ist, und fehlgeschlagene Lese- und Schreibanfragen wiederholen, sowie Logs anhand festgelegter Regeln gruppieren und taggen. Wie Logstash hat Graylog die Funktionalit\u00e4t, Strings vor dem Speichern in Elasticsearch zu modifizieren.<\/p>\n<p><\/p>\n<p>Dar\u00fcber hinaus verf\u00fcgt Graylog \u00fcber eine integrierte Service Discovery, die es erm\u00f6glicht, anhand eines verf\u00fcgbaren Elasticsearch-Knotens eine komplette Cluster-Karte zu erhalten und diese nach einem bestimmten Tag zu filtern, was die gezielte Abwicklung von Anfragen an bestimmte Container erm\u00f6glicht.<\/p>\n<p><\/p>\n<p>Visuell sieht das etwa so aus:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster mit 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/8673ba9c0300ea0153d34a9f98afbcf2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dies ist ein Screenshot von einem bestimmten Instance. Hier bauen wir ein Histogramm basierend auf der Suchanfrage auf und zeigen relevante Zeilen an.<\/p>\n<p><\/p>\n<h2 id=\"indeksy\">Indizes<\/h2>\n<p><\/p>\n<p>Zur\u00fcck zur Architektur des Systems m\u00f6chte ich n\u00e4her darauf eingehen, wie wir das Indexmodell erstellt haben, sodass alles korrekt funktioniert. <\/p>\n<p><\/p>\n<p>In dem vorher gezeigten Diagramm ist dies die unterste Ebene: Elasticsearch-Datenknoten.<\/p>\n<p><\/p>\n<p>Ein Index ist eine gro\u00dfe virtuelle Entit\u00e4t, die aus Elasticsearch-Shards besteht. Jeder dieser Shards ist nichts anderes als ein Lucene-Index. Und jeder Lucene-Index besteht wiederum aus einem oder mehreren Segmenten. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster mit 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/13b858cb102dce26b0851516b2d36c43.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Bei der Planung haben wir \u00fcberlegt, dass wir zur Erf\u00fcllung der Anforderungen an die Lesegeschwindigkeit bei gro\u00dfen Datenmengen diese Daten gleichm\u00e4\u00dfig \u00fcber die Datenknoten \"verteilen\" m\u00fcssen. <\/p>\n<p><\/p>\n<p>Das f\u00fchrte dazu, dass die Anzahl der Shards pro Index (mit Replikaten) streng gleich der Anzahl der Datenknoten sein muss. Erstens, um einen Replikationsfaktor von zwei zu gew\u00e4hrleisten (das hei\u00dft, wir k\u00f6nnen die H\u00e4lfte des Clusters verlieren). Und zweitens, um Lese- und Schreibanfragen mindestens auf der H\u00e4lfte des Clusters verarbeiten zu k\u00f6nnen.<\/p>\n<p><\/p>\n<p>Die Speicherzeit haben wir zun\u00e4chst auf 30 Tage festgelegt.<\/p>\n<p><\/p>\n<p>Die Verteilung der Shards kann grafisch wie folgt dargestellt werden:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster mit 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/242726053360d1a6bdf4e527edc6cae6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Das gesamte dunkelgraue Rechteck ist der Index. Das linke rote Quadrat darin ist der Primary-Shard, der erste im Index. Das blaue Quadrat ist der Replica-Shard. Sie befinden sich in verschiedenen Rechenzentren.<\/p>\n<p><\/p>\n<p>Wenn wir einen weiteren Shard hinzuf\u00fcgen, gelangt er in das dritte Rechenzentrum. Und letztendlich erhalten wir eine Struktur, die den Verlust eines Rechenzentrums ohne Verlust der Datenkonsistenz erm\u00f6glicht:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster mit 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/27cbe4d4606f5ae5f3013ea46504134b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Die Rotation der Indizes, d.h. die Erstellung eines neuen Index und die L\u00f6schung des \u00e4ltesten, haben wir auf 48 Stunden festgelegt (basierend auf dem Nutzungsverhalten des Index: An den letzten 48 Stunden wird am h\u00e4ufigsten gesucht).<\/p>\n<p><\/p>\n<p>Dieser Rotationsintervall der Indizes h\u00e4ngt von folgenden Gr\u00fcnden ab:<\/p>\n<p><\/p>\n<p>Wenn auf eine bestimmte Datenknoten eine Suchanfrage eintrifft, ist es aus Performance-Sicht vorteilhafter, wenn ein Shard befragt wird, dessen Gr\u00f6\u00dfe mit der Gr\u00f6\u00dfe des Heap der Knotens vergleichbar ist. Dies erm\u00f6glicht es, den \"hei\u00dfen\" Teil des Index im Heap zu halten und schnell darauf zuzugreifen. Wenn es viele \"hei\u00dfe Teile\" gibt, verschlechtert sich die Suchgeschwindigkeit im Index.<\/p>\n<p><\/p>\n<p>Wenn ein Knoten mit der Ausf\u00fchrung einer Suchanfrage auf einem Shard beginnt, weist er eine Anzahl von Threads zu, die der Anzahl der Hyper-Threading-Kerne der physischen Maschine entspricht. Wenn die Suchanfrage eine gro\u00dfe Anzahl von Shards betrifft, w\u00e4chst die Anzahl der Threads proportional. Dies hat negative Auswirkungen auf die Suchgeschwindigkeit und wirkt sich nachteilig auf die Indizierung neuer Daten aus. <\/p>\n<p><\/p>\n<p>Um die erforderliche Suchlatenz zu gew\u00e4hrleisten, haben wir beschlossen, SSDs zu verwenden. F\u00fcr eine schnelle Verarbeitung der Anfragen mussten die Maschinen, auf denen diese Container betrieben wurden, mindestens 56 Kerne haben. Die Zahl 56 wurde als bedingt ausreichend gew\u00e4hlt und definiert die Anzahl der Threads, die Elasticsearch w\u00e4hrend seiner Laufzeit erzeugen wird. Viele Parameter des Thread-Pools in Elasticsearch h\u00e4ngen direkt von der Anzahl der verf\u00fcgbaren Kerne ab, was wiederum die erforderliche Anzahl an Knoten im Cluster nach dem Prinzip &quot;weniger Kerne \u2014 mehr Knoten&quot; beeinflusst. <\/p>\n<p><\/p>\n<p>Letztendlich haben wir festgestellt, dass ein Shard im Durchschnitt etwa 20 Gigabyte wiegt, und auf 1 Index entfallen 360 Shards. Wenn wir diese alle alle 48 Stunden rotieren, haben wir 15 St\u00fcck. Jeder Index enth\u00e4lt Daten f\u00fcr 2 Tage.<\/p>\n<p><\/p>\n<h2 id=\"shemy-zapisi-i-chteniya-dannyh\">Datenaufzeichnungs- und -leseschemata<\/h2>\n<p><\/p>\n<p>Lass uns kl\u00e4ren, wie in diesem System Daten aufgezeichnet werden.<\/p>\n<p><\/p>\n<p>Angenommen, wir erhalten von Graylog eine Anfrage im Koordinator. Zum Beispiel m\u00f6chten wir 2-3 Tausend Zeilen indizieren. <\/p>\n<p><\/p>\n<p>Der Koordinator erh\u00e4lt von Graylog eine Anfrage und fragt den Master: \u201eIn der Indizierungsanfrage war der Index konkret angegeben, aber es wurde nicht angegeben, in welchen Shard dies geschrieben werden soll.\u201c <\/p>\n<p><\/p>\n<p>Der Master antwortet: \u201eSchreibe diese Informationen in Shard Nummer 71\u201c, danach wird sie direkt an den relevanten Datenknoten gesendet, wo sich der prim\u00e4re Shard Nummer 71 befindet.<\/p>\n<p><\/p>\n<p>Danach wird das Transaktionsprotokoll auf den Replica-Shard repliziert, der sich bereits in einem anderen Rechenzentrum befindet.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster mit 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/fdb6a77cb78b1eed290e440478569e3b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Von Graylog kommt eine Suchanfrage an den Koordinator. Der Koordinator leitet sie nach Index weiter, wobei Elasticsearch die Anfragen nach dem Round-Robin-Prinzip zwischen dem prim\u00e4ren Shard und dem Replica-Shard verteilt. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster mit 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/cb32bac878e04d6f50d103ebbc395a7f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Die Knoten, insgesamt 180, reagieren ungleichm\u00e4\u00dfig, und w\u00e4hrend sie antworten, sammelt der Koordinator die Informationen, die bereits von schnelleren Datenknoten \u201eausgespuckt\u201c wurden. Danach, wenn entweder alle Informationen eingetroffen sind oder der Zeit\u00fcberschreitungswert f\u00fcr die Anfrage erreicht wurde, gibt er alles direkt an den Kunden zur\u00fcck. <\/p>\n<p><\/p>\n<p>Das gesamte System verarbeitet im Durchschnitt Suchanfragen der letzten 48 Stunden in 300-400 ms, mit Ausnahme der Anfragen, die mit leading wildcard versehen sind.<\/p>\n<p><\/p>\n<h2 id=\"cvetochki-s-elasticsearch-nastroyka-java\">\u201eKleinigkeiten\u201c mit Elasticsearch: Java-Einstellungen<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster mit 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/fc9ac4b8ee41bc35f5f01b8d9c4ff2f6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Damit all dies so funktioniert, wie wir es uns urspr\u00fcnglich vorgestellt hatten, haben wir sehr lange an den unterschiedlichsten Aspekten im Cluster gefeilt. <\/p>\n<p><\/p>\n<p>Der erste Teil der entdeckten Probleme stand im Zusammenhang damit, wie Java in Elasticsearch standardm\u00e4\u00dfig voreingestellt ist. <\/p>\n<p><\/p>\n<p><strong>Problem eins<\/strong><br \/>\nWir haben eine sehr gro\u00dfe Anzahl von Meldungen festgestellt, dass auf Lucene-Ebene, wenn Hintergrundjobs laufen, die Merges der Lucene-Segmente mit einem Fehler enden. Dabei war in den Logs zu sehen, dass es sich um einen OutOfMemoryError handelt. Laut Telemetrie sahen wir, dass der Heap frei war, und es war unklar, warum dieser Vorgang fehlschlug. <\/p>\n<p><\/p>\n<p>Es stellte sich heraus, dass die Merges der Lucene-Indizes au\u00dferhalb des Heaps stattfinden. Die Container sind bei den verbrauchten Ressourcen ziemlich streng begrenzt. In diese Ressourcen passte nur der Heap (der Wert heap.size war ungef\u00e4hr gleich dem RAM), w\u00e4hrend bestimmte Off-Heap-Operationen bei einer fehlenden Einhaltung der ~500 MB, die bis zur Grenze verbleiben, mit einer Speicherzuweisungsfehler abst\u00fcrzten.<\/p>\n<p><\/p>\n<p>Die L\u00f6sung war ziemlich trivial: Das f\u00fcr den Container verf\u00fcgbare RAM-Volumen wurde erh\u00f6ht, danach hatten wir keine Probleme mehr.<\/p>\n<p><\/p>\n<p><strong>Problem zwei<\/strong><br \/>\nNach etwa 4-5 Tagen nach dem Start des Clusters bemerkten wir, dass die Datenknoten gelegentlich aus dem Cluster fielen und nach 10-20 Sekunden wieder eintraten. <\/p>\n<p><\/p>\n<p>Als wir anfingen, das Problem zu untersuchen, stellte sich heraus, dass der off-heap Speicher in Elasticsearch praktisch nicht kontrolliert wird. Als wir dem Container mehr Speicher zuwiesen, erhielten wir die M\u00f6glichkeit, verschiedene Informationen in den Direct Buffer Pools zu speichern, und dieser wurde nur nach einem expliziten GC von Elasticsearch geleert. <\/p>\n<p><\/p>\n<p>In einigen F\u00e4llen dauerte dieser Vorgang ziemlich lange, und in der Zwischenzeit hatte der Cluster diese Node bereits als ausgefallen markiert. Dieses Problem ist gut dokumentiert <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/elasticsearch-5-6-very-quickly-increasing-direct-buffer-pools\/119561\">hier<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Die L\u00f6sung war folgende: Wir beschr\u00e4nkten die Java-M\u00f6glichkeit, den Gro\u00dfteil des Speichers au\u00dferhalb des Heaps f\u00fcr diese Operationen zu nutzen. Wir limitierten ihn auf 16 Gigabyte (-XX:MaxDirectMemorySize=16g), wodurch der explizite GC deutlich h\u00e4ufiger aufgerufen wurde und viel schneller arbeitete, wodurch wir den Cluster nicht weiter destabilisierten.<\/p>\n<p><\/p>\n<p><strong>Das dritte Problem<\/strong><br \/>\nWenn Sie denken, dass die Probleme mit den \"Nodes, die den Cluster im ung\u00fcnstigsten Moment verlassen\" damit beendet sind, liegen Sie falsch. <\/p>\n<p><\/p>\n<p>Als wir die Arbeit mit Indizes konfigurierten, entschieden wir uns f\u00fcr mmapfs, um <noindex><a rel=\"nofollow\" href=\"https:\/\/discuss.elastic.co\/t\/benchmarks-default-niofs-vs-memory-mapped-mmapfs\/13118\/2\">die Suchzeit zu verk\u00fcrzen<\/a><\/noindex> bei neuen Shards mit hoher Segmentierung. Das war ein ziemlich grober Fehler, weil beim Einsatz von mmapfs die Datei in den Arbeitsspeicher gemappt wird, und wir danach mit der gemappten Datei arbeiten. Dadurch passiert es, dass wir beim Versuch, den GC zu stoppen, sehr lange zum Safepoint gelangen, und auf dem Weg dorthin h\u00f6rt die Anwendung auf, auf Anfragen des Masters zu antworten, ob sie noch lebt. Folglich denkt der Master, dass die Node nicht mehr im Cluster ist. Nachdem der Garbage Collector nach etwa 5-10 Sekunden arbeitet, belebt sich die Node wieder, kehrt in den Cluster zur\u00fcck und beginnt mit der Initialisierung der Shards. Das alles erinnerte stark an das \u201cProdukt, das wir verdient haben\u201d und war f\u00fcr irgendetwas Ernsthaftes nicht geeignet.<\/p>\n<p><\/p>\n<p>Um ein solches Verhalten zu vermeiden, haben wir zun\u00e4chst auf das Standard niofs gewechselt und sp\u00e4ter, nachdem wir von der f\u00fcnften auf die sechste Version von Elastic migriert hatten, hybridfs ausprobiert, wo dieses Problem nicht auftauchte. Mehr \u00fcber die Arten von Speicher kann man lesen <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/index-modules-store.html\">hier<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p><strong>Das vierte Problem<\/strong><br \/>\nDann gab es noch ein sehr aufschlussreiches Problem, das wir rekordverd\u00e4chtig lange behandelt haben. Wir haben es 2-3 Monate lang verfolgt, da das Muster absolut unklar war. <\/p>\n<p><\/p>\n<p>Manchmal gingen unsere Koordinatoren in den Full GC, normalerweise nachmittags, und kehrten von dort nicht zur\u00fcck. Dabei sah es beim Protokollieren der GC-Verz\u00f6gerungen so aus: alles lief gut, gut, gut, und dann pl\u00f6tzlich \u2013 alles war pl\u00f6tzlich schlecht. <\/p>\n<p><\/p>\n<p>Zuerst dachten wir, dass wir es mit einem b\u00f6sartigen Nutzer zu tun hatten, der eine Anfrage startet, die den Koordinator aus dem Arbeitsmodus wirft. Wir haben sehr lange Anfragen protokolliert, um herauszufinden, was passiert. <\/p>\n<p><\/p>\n<p>Letztendlich stellte sich heraus, dass in dem Moment, wenn ein Benutzer eine sehr gro\u00dfe Anfrage stellt und diese auf einen bestimmten Elasticsearch-Koordinator trifft, einige Knoten l\u00e4nger antworten als andere. <\/p>\n<p><\/p>\n<p>Und w\u00e4hrend der Koordinator auf die Antworten aller Knoten wartet, sammelt er die Ergebnisse von bereits antwortenden Knoten. F\u00fcr den GC bedeutet das, dass sich unser Heap-Nutzungsmuster sehr schnell \u00e4ndert. Und der GC, den wir verwendet haben, konnte mit dieser Aufgabe nicht umgehen. <\/p>\n<p><\/p>\n<p>Die einzige L\u00f6sung, die wir gefunden haben, um das Verhalten des Clusters in solch einer Situation zu \u00e4ndern, war die Migration auf JDK13 und die Verwendung des Garbage Collectors Shenandoah. Das hat das Problem gel\u00f6st, unsere Koordinatoren fielen nicht mehr aus. <\/p>\n<p><\/p>\n<p>Damit endeten die Probleme mit Java und die Probleme mit der Durchsatzleistung begannen. <\/p>\n<p><\/p>\n<h2 id=\"yagodki-s-elasticsearch-propusknaya-sposobnost\">\u00abB\u00e4rchen\u00bb mit Elasticsearch: Durchsatzleistung<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster mit 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/bb5c08193d7d764515235e825cd30ce5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Durchsatzprobleme bedeuten, dass unser Cluster stabil arbeitet, aber in Spitzenzeiten der zu indexierenden Dokumente und w\u00e4hrend der Man\u00f6ver die Leistung nicht ausreicht.<\/p>\n<p><\/p>\n<p>Das erste h\u00e4ufige Symptom: Bei \u201eExplosionen\u201c im Produktionsbetrieb, wenn pl\u00f6tzlich eine sehr gro\u00dfe Menge an Protokollen generiert wird, tritt in Graylog h\u00e4ufig der Indexierungsfehler es_rejected_execution auf. <\/p>\n<p><\/p>\n<p>Das geschah, weil thread_pool.write.queue auf einem Dataknoten standardm\u00e4\u00dfig nur 200 Anfragen cachen kann, bevor Elasticsearch die Anfrage zur Indexierung verarbeitet und die Informationen auf das Shard schreibt. Und in <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">der Elasticsearch-Dokumentation<\/a><\/noindex> wird sehr wenig \u00fcber diesen Parameter gesagt. Es wird nur die maximale Anzahl der Threads und die Standardgr\u00f6\u00dfe angegeben.<\/p>\n<p><\/p>\n<p>Nat\u00fcrlich haben wir diesen Wert angepasst und Folgendes herausgefunden: In unserem Setup kann bis zu 300 Anfragen recht gut zwischengespeichert werden, w\u00e4hrend ein h\u00f6herer Wert bedenklich ist, da wir sonst wieder in den Full GC geraten.<\/p>\n<p><\/p>\n<p>Au\u00dferdem musste Graylog so konfiguriert werden, dass es nicht h\u00e4ufig und in kleinen Stapeln, sondern in gro\u00dfen Stapeln oder alle 3 Sekunden, wenn der Stapel noch nicht voll ist, schreibt, da es sich um Pakete von Nachrichten handelt, die im Rahmen einer Anfrage ankommen. In diesem Fall wird die Information, die wir in Elasticsearch schreiben, nicht in zwei Sekunden, sondern in f\u00fcnf Sekunden zug\u00e4nglich, was f\u00fcr uns akzeptabel ist, aber die Anzahl der Retries verringert, die n\u00f6tig sind, um einen gro\u00dfen Informationsstapel durchzuschieben.<\/p>\n<p><\/p>\n<p>Dies ist besonders wichtig in Momenten, in denen etwas irgendwo abgest\u00fcrzt ist und dar\u00fcber heftig berichtet wird, um nicht einen vollst\u00e4ndig zugespammten Elasticsearch zu erhalten und nach einer Weile nicht mehr funktionierende Graylog-Knoten aufgrund \u00fcberf\u00fcllter Puffer.<\/p>\n<p><\/p>\n<p>Au\u00dferdem gab es Beschwerden von Programmierern und Testern, wenn diese Explosionen in der Produktion auftraten: In dem Moment, in dem sie diese Protokolle dringend ben\u00f6tigten, wurden sie sehr langsam bereitgestellt.<\/p>\n<p><\/p>\n<p>Wir haben uns darum gek\u00fcmmert. Auf der einen Seite war klar, dass sowohl die Suchanfragen als auch die Anfragen zur Indizierung im Wesentlichen auf denselben physischen Maschinen verarbeitet werden, was unweigerlich zu bestimmten Einbr\u00fcchen f\u00fchren wird. <\/p>\n<p><\/p>\n<p>Das konnte jedoch teilweise umgangen werden, da in den sechsten Versionen von Elasticsearch ein Algorithmus eingef\u00fchrt wurde, der es erm\u00f6glicht, Anfragen nicht nach dem Zufallsprinzip round-robin (Container, der mit der Indizierung besch\u00e4ftigt ist und den Primary-Shard h\u00e4lt, kann sehr besch\u00e4ftigt sein, daher wird es nicht m\u00f6glich sein, schnell zu antworten), zu verteilen, sondern diese Anfrage an einen weniger belasteten Container mit Replica-Shard zu richten, der deutlich schneller antwortet. Mit anderen Worten, wir sind zu use_adaptive_replica_selection: true gekommen.<\/p>\n<p><\/p>\n<p>Das Bild des Lesens beginnt so auszusehen:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster mit 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ae7c1645bb63692e580b1bca5c6e5db0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Der \u00dcbergang zu diesem Algorithmus hat es m\u00f6glich gemacht, die Abfragezeiten in Momenten deutlich zu verbessern, in denen ein gro\u00dfer Strom von Protokollen zur Speicherung l\u00e4uft.<\/p>\n<p><\/p>\n<p>Schlie\u00dflich bestand das Hauptproblem darin, das Rechenzentrum schmerzfrei auszuleiten.<\/p>\n<p><\/p>\n<p>Was wir vom Cluster sofort nach dem Verlust der Verbindung zu einem Rechenzentrum wollten: <\/p>\n<p><\/p>\n<ul>\n<li>Wenn sich im ausgefallenen Rechenzentrum der aktuelle Master befindet, wird er neu gew\u00e4hlt und wechselt als Rolle zu einem anderen Knoten in einem anderen Rechenzentrum.<\/li>\n<li>Der Master wird schnell alle nicht erreichbaren Knoten aus dem Cluster werfen.<\/li>\n<li>Anhand der verbleibenden Ressourcen wird er verstehen: In dem verlorenen Rechenzentrum hatten wir solche primary-Shards, schnell werden die komplement\u00e4ren replica-Shards in den verbleibenden Rechenzentren gef\u00f6rdert, und wir werden mit der Indizierung der Daten fortfahren. <\/li>\n<li>Infolgedessen wird die Durchsatzkapazit\u00e4t des Clusters beim Schreiben und Lesen langsam abnehmen, aber insgesamt wird alles, wenn auch langsam, stabil funktionieren.<\/li>\n<\/ul>\n<p><\/p>\n<p>Wie sich herausstellte, wollten wir etwas in dieser Art:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster mit 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/71fa3d19a61eb58ddb93a4df55c759c5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Und haben Folgendes erhalten:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster mit 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ab32be4dfbbb4bcc3279d57021707980.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wie kam es dazu? <\/p>\n<p><\/p>\n<p>Im Moment des Ausfalls des Rechenzentrums wurde unser Flaschenhals zum Master.<\/p>\n<p><\/p>\n<p>Warum?<\/p>\n<p><\/p>\n<p>Der Grund daf\u00fcr ist, dass im Master ein TaskBatcher existiert, der f\u00fcr die Verteilung bestimmter Aufgaben und Ereignisse im Cluster verantwortlich ist. Jeder Ausfall einer Node, jede Bef\u00f6rderung eines Shards von replica zu primary, jede Aufgabe zur Erstellung eines Shards irgendwo \u2014 all das gelangt zuerst in den TaskBatcher, wo es sequenziell und in einem Stream verarbeitet wird.<\/p>\n<p><\/p>\n<p>Im Moment des Ausfalls eines Rechenzentrums stellten sich alle Daten-Nodes in den \u00fcberlebenden Rechenzentren die Aufgabe, dem Master zu melden: \"Wir haben solche und solche Shards und Nodes verloren.\" <\/p>\n<p><\/p>\n<p>Die \u00fcberlebenden Daten-Nodes schickten all diese Informationen an den aktuellen Master und versuchten zu warten, bis er best\u00e4tigte, dass er sie erhalten hatte. Dies warteten sie jedoch vergeblich, da der Master die Aufgaben schneller erhielt, als er antworten konnte. Die Nodes wiederholten die Anfragen aufgrund des Timeouts, und w\u00e4hrenddessen versuchte der Master nicht einmal, darauf zu antworten, sondern war vollst\u00e4ndig damit besch\u00e4ftigt, die Anfragen nach Priorit\u00e4t zu sortieren.<\/p>\n<p><\/p>\n<p>In extremer Form bedeutet das, dass die Daten-Nodes den Master derart mit Anfragen \u00fcberh\u00e4uften, dass er in die Full GC ging. Danach wechselte die Rolle des Masters zu einer anderen Node, mit der das Gleiche geschah, und letztendlich brach das Cluster vollst\u00e4ndig zusammen. <\/p>\n<p><\/p>\n<p>Wir haben Messungen durchgef\u00fchrt, und bis zur Version 6.4.0, in der dieses Problem behoben wurde, reichte es aus, nur 10 von 360 Daten-Nodes gleichzeitig abzuschalten, um das Cluster vollst\u00e4ndig zum Absturz zu bringen.<\/p>\n<p><\/p>\n<p>So sah das ungef\u00e4hr aus:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster mit 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/3bed554b2703e7521339e9d943648ee4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nach der Version 6.4.0, in der dieser gef\u00e4hrliche Fehler behoben wurde, h\u00f6rten die Daten-Nodes auf, den Master abzuschalten. Aber \"kl\u00fcger\" wurde er dadurch nicht. Denn wenn wir 2, 3 oder 10 (jede Anzahl, die nicht eins ist) Daten-Nodes abschalten, erh\u00e4lt der Master eine erste Nachricht, die besagt, dass Node A ausgefallen ist, und versucht, dies Node B, Node C, Node D zu melden. <\/p>\n<p><\/p>\n<p>Und gegenw\u00e4rtig kann man nur durch das Festlegen eines Zeitlimits f\u00fcr die Versuche, jemandem von etwas zu erz\u00e4hlen, das etwa 20-30 Sekunden betr\u00e4gt, dagegen ank\u00e4mpfen und so die Geschwindigkeit der Ausschaltung des Rechenzentrums aus dem Cluster steuern.<\/p>\n<p><\/p>\n<p>Im Prinzip entspricht dies den Anforderungen, die urspr\u00fcnglich an das Endprodukt im Rahmen des Projekts gestellt wurden, aber aus der Sicht der 'reinen Wissenschaft' handelt es sich um einen Fehler. Dieser wurde \u00fcbrigens von den Entwicklern in Version 7.2 erfolgreich behoben.<\/p>\n<p><\/p>\n<p>Wenn eine Datenknoten ausfiel, stellte sich heraus, dass es wichtiger war, die Informationen \u00fcber ihren Ausfall zu verbreiten, als dem gesamten Cluster mitzuteilen, dass sich darauf bestimmte primary-shards befanden (um replica-shards in einem anderen Rechenzentrum zu einem primary zu bef\u00f6rdern, auf dem man Informationen schreiben konnte).<\/p>\n<p><\/p>\n<p>Daher werden die ausgefallenen Datenknoten, wenn alles 'vor\u00fcber' ist, nicht sofort als stale markiert. Folglich m\u00fcssen wir warten, bis alle Pings zu den ausgefallenen Datenknoten abgelaufen sind, und erst dann beginnt unser Cluster, dar\u00fcber zu informieren, dass dort und dort und dort die Aufzeichnung von Informationen fortgesetzt werden muss. Weitere Einzelheiten k\u00f6nnen Sie hier nachlesen. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/elastic\/elasticsearch\/issues\/46909\">hier<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Insgesamt dauert der Vorgang der Ausschaltung des Rechenzentrums heute etwa 5 Minuten zu Sto\u00dfzeiten. F\u00fcr so ein gro\u00dfes und unhandliches Gebilde ist das ein ziemlich gutes Ergebnis.<\/p>\n<p><\/p>\n<p>Schlie\u00dflich sind wir zu folgender Entscheidung gekommen:<\/p>\n<p><\/p>\n<ul>\n<li>Wir haben 360 Datenknoten mit Festplatten zu 700 Gigabyte.<\/li>\n<li>60 Koordinatoren f\u00fcr das Routing des Verkehrs zu diesen Datenknoten.<\/li>\n<li>40 Master, die als Erbe aus den Versionen vor 6.4.0 \u00fcbrig geblieben sind \u2013 um die Ausschaltung des Rechenzentrums zu \u00fcberstehen, waren wir mental darauf vorbereitet, einige Maschinen zu verlieren, um auch im schlimmsten Szenario einen Master-Quorum zu gew\u00e4hrleisten.<\/li>\n<li>Alle Versuche, Rollen in einem Container zu kombinieren, scheiterten daran, dass irgendwann die Knoten unter der Last zusammenbrachen. <\/li>\n<li>Im gesamten Cluster wird eine heap.size von 31 Gigabyte verwendet: Alle Versuche, die Gr\u00f6\u00dfe zu reduzieren, f\u00fchrten dazu, dass bei schweren Suchanfragen mit einem f\u00fchrenden Wildcard entweder einige Knoten abgest\u00fcrzt sind oder der Circuit Breaker in Elasticsearch selbst ausgel\u00f6st wurde.<\/li>\n<li>Dar\u00fcber hinaus haben wir versucht, die Anzahl der Objekte im Cluster so gering wie m\u00f6glich zu halten, um in der engsten Stelle, die wir bei den Meistern hatten, so wenig Ereignisse wie m\u00f6glich zu verarbeiten.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"naposledok-o-monitoringe\">Abschlie\u00dfend zum Monitoring<\/h2>\n<p><\/p>\n<p>Damit all dies so funktioniert, wie es gedacht war, \u00fcberwachen wir Folgendes:<\/p>\n<p><\/p>\n<ul>\n<li>Jeder Datenknoten berichtet in unser Cloud, dass er vorhanden ist und welche Shards sich darauf befinden. Wenn wir irgendwo etwas abschalten, meldet der Cluster nach 2-3 Sekunden, dass wir in Zentrum A die Knoten 2, 3 und 4 abgeschaltet haben \u2013 das bedeutet, dass wir in anderen Rechenzentren auf keinen Fall die Knoten abschalten d\u00fcrfen, auf denen Shards nur einmal vorhanden sind.<\/li>\n<li>Angesichts des Verhaltens des Masters achten wir sehr genau auf die Anzahl ausstehender Aufgaben. Denn selbst eine h\u00e4ngende Aufgabe, wenn sie nicht rechtzeitig abl\u00e4uft, k\u00f6nnte theoretisch in einer Notsituation der Grund sein, weshalb beispielsweise ein Replica-Shard nicht im Primary verarbeitet werden kann, was die Indizierung zum Stillstand bringen w\u00fcrde.<\/li>\n<li>Wir achten auch sehr genau auf die Verz\u00f6gerungen des Garbage Collectors, da wir damit bereits gro\u00dfe Schwierigkeiten bei der Optimierung hatten.<\/li>\n<li>Rejects nach Threads, um im Voraus zu verstehen, wo sich der Engpass befindet.<\/li>\n<li>Und die Standardmetriken wie Heap, RAM und I\/O.<\/li>\n<\/ul>\n<p><\/p>\n<p>Bei der \u00dcberwachung muss man die Eigenheiten des Thread-Pools in Elasticsearch auf jeden Fall ber\u00fccksichtigen. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">Die Elasticsearch-Dokumentation<\/a><\/noindex> beschreibt die Anpassungsm\u00f6glichkeiten und Standardwerte f\u00fcr die Suche, die Indizierung, aber schweigt vollst\u00e4ndig \u00fcber thread_pool.management. Diese Threads verarbeiten unter anderem Anfragen wie _cat\/shards und \u00e4hnliche, die sich gut f\u00fcr die \u00dcberwachung verwenden lassen. Je gr\u00f6\u00dfer der Cluster, desto mehr solcher Anfragen werden pro Zeiteinheit ausgef\u00fchrt, und der genannte thread_pool.management wird nicht nur nicht in der offiziellen Dokumentation dargestellt, sondern ist auch standardm\u00e4\u00dfig auf 5 Threads limitiert, was sehr schnell ausgelastet ist, woraufhin die \u00dcberwachung nicht mehr korrekt funktioniert.<\/p>\n<p><\/p>\n<p>Was ich abschlie\u00dfend sagen m\u00f6chte: Wir haben es geschafft! Wir konnten unseren Programmierern und Entwicklern ein Werkzeug geben, das in nahezu jeder Situation schnell und zuverl\u00e4ssig Informationen \u00fcber das Geschehen in der Produktion bereitstellen kann.<\/p>\n<p><\/p>\n<p>Ja, es war ziemlich komplex, aber dennoch gelang es uns, unsere W\u00fcnsche in bereits bestehende Produkte zu integrieren, ohne diese patchen oder umschreiben zu m\u00fcssen.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster mit 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/1e852123ca5ec5eaec27bdc66b6c4e83.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/494260\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0421 Elasticsearch \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u044e\u0442\u0441\u044f \u043c\u043d\u043e\u0433\u0438\u0435. \u041d\u043e \u0447\u0442\u043e \u043f\u0440\u043e\u0438\u0441\u0445\u043e\u0434\u0438\u0442, \u043a\u043e\u0433\u0434\u0430 \u0445\u043e\u0447\u0435\u0448\u044c \u0441 \u0435\u0433\u043e \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0445\u0440\u0430\u043d\u0438\u0442\u044c \u043b\u043e\u0433\u0438 \u00ab\u0432 \u043e\u0441\u043e\u0431\u043e \u043a\u0440\u0443\u043f\u043d\u043e\u043c \u043e\u0431\u044a\u0451\u043c\u0435\u00bb? \u0414\u0430 \u0435\u0449\u0451 \u0438 \u0431\u0435\u0437\u0431\u043e\u043b\u0435\u0437\u043d\u0435\u043d\u043d\u043e \u043f\u0435\u0440\u0435\u0436\u0438\u0432\u0430\u0442\u044c \u043e\u0442\u043a\u0430\u0437 \u043b\u044e\u0431\u043e\u0433\u043e \u0438\u0437 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0434\u0430\u0442\u0430-\u0446\u0435\u043d\u0442\u0440\u043e\u0432? \u041a\u0430\u043a\u043e\u0439 \u0441\u0442\u043e\u0438\u0442 \u0434\u0435\u043b\u0430\u0442\u044c \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0443, \u0438 \u043d\u0430 \u043a\u0430\u043a\u0438\u0435 \u043f\u043e\u0434\u0432\u043e\u0434\u043d\u044b\u0435 \u043a\u0430\u043c\u043d\u0438 \u043d\u0430\u0442\u043a\u043d\u0451\u0448\u044c\u0441\u044f? \u041c\u044b \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445 \u0440\u0435\u0448\u0438\u043b\u0438 \u043f\u0440\u0438 \u043f\u043e\u043c\u043e\u0449\u0438 elasticsearch \u0440\u0435\u0448\u0438\u0442\u044c \u0432\u043e\u043f\u0440\u043e\u0441 \u043b\u043e\u0433-\u043c\u0435\u043d\u0435\u0434\u0436\u043c\u0435\u043d\u0442\u0430, \u0430 \u0442\u0435\u043f\u0435\u0440\u044c \u0434\u0435\u043b\u0438\u043c\u0441\u044f \u0441 \u0425\u0430\u0431\u0440\u043e\u043c \u043e\u043f\u044b\u0442\u043e\u043c: \u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":75797,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-75796","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0421 Elasticsearch \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u044e\u0442\u0441\u044f \u043c\u043d\u043e\u0433\u0438\u0435.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u043b\u0430\u0441\u0442\u0435\u0440 Elasticsearch \u043d\u0430 200 \u0422\u0411+ | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0421 Elasticsearch \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u044e\u0442\u0441\u044f \u043c\u043d\u043e\u0433\u0438\u0435.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-03-28T17:42:18+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-03-28T17:42:18+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Elasticsearch-Cluster \u00fcber 200 TB+ | ProHoster","description":"Viele nutzen Elasticsearch.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u043b\u0430\u0441\u0442\u0435\u0440 Elasticsearch \u043d\u0430 200 \u0422\u0411+ | ProHoster","og:description":"\u0421 Elasticsearch \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u044e\u0442\u0441\u044f \u043c\u043d\u043e\u0433\u0438\u0435.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/klaster-elasticsearch-na-200-tb","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-03-28T17:42:18+00:00","article:modified_time":"2020-03-28T17:42:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"75796","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 17:49:32","updated":"2022-09-27 21:24:26","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/75796","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=75796"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/75796\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/75797"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=75796"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=75796"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=75796"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}