{"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 \u00fcber 200 TB+","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster \u00fcber 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 Elasticsearch. Aber was passiert, wenn Sie damit \u201ein besonders gro\u00dfem Umfang\u201c Protokolle speichern m\u00f6chten? Und das ganz ohne Probleme bei einem Ausfall eines der mehreren Rechenzentren? Welche Architektur ist erforderlich und auf welche Fallstricke m\u00fcssen Sie achten?<\/p>\n<p><\/p>\n<p>Wir bei Odnoklassniki haben uns entschieden, mit Elasticsearch das Log-Management zu optimieren und teilen nun unsere Erfahrungen mit Habr: sowohl zur Architektur als auch zu den Fallstricken.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>\u042f \u2014 \u041f\u0451\u0442\u0440 \u0417\u0430\u0439\u0446\u0435\u0432, \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u043c \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u043e\u043c \u0432 \u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0430\u0445. \u0414\u043e \u044d\u0442\u043e\u0433\u043e \u0442\u043e\u0436\u0435 \u0431\u044b\u043b \u0430\u0434\u043c\u0438\u043d\u043e\u043c, \u0440\u0430\u0431\u043e\u0442\u0430\u043b \u0441 Manticore Search, Sphinx search, Elasticsearch. \u0412\u043e\u0437\u043c\u043e\u0436\u043d\u043e, \u0435\u0441\u043b\u0438 \u043f\u043e\u044f\u0432\u0438\u0442\u0441\u044f \u0435\u0449\u0451 \u043a\u0430\u043a\u043e\u0439-\u043d\u0438\u0431\u0443\u0434\u044c &#8230;search, \u0432\u0435\u0440\u043e\u044f\u0442\u043d\u043e \u0431\u0443\u0434\u0443 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0438 \u0441 \u043d\u0438\u043c. \u0422\u0430\u043a\u0436\u0435 \u0443\u0447\u0430\u0441\u0442\u0432\u0443\u044e \u0432 \u0440\u044f\u0434\u0435 \u043e\u043f\u0435\u043d\u0441\u043e\u0440\u0441\u043d\u044b\u0445 \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432 \u043d\u0430 \u0434\u043e\u0431\u0440\u043e\u0432\u043e\u043b\u044c\u043d\u043e\u0439 \u043e\u0441\u043d\u043e\u0432\u0435.<\/p>\n<p><\/p>\n<p>Als ich zu Odnoklassniki kam, sagte ich in meinem Vorstellungsgespr\u00e4ch unvorsichtigerweise, dass ich mit Elasticsearch umgehen kann. Nachdem ich mich eingearbeitet und einige einfache Aufgaben erledigt hatte, wurde mir eine gro\u00dfe Aufgabe zur Reformierung des zu diesem Zeitpunkt bestehenden Log-Management-Systems \u00fcbertragen. <\/p>\n<p><\/p>\n<h2 id=\"trebovaniya\">Anforderungen<\/h2>\n<p><\/p>\n<p>Die Anforderungen an das System wurden wie folgt formuliert:<\/p>\n<p><\/p>\n<ul>\n<li>Als Frontend sollte Graylog verwendet werden. Das Unternehmen hatte bereits Erfahrung mit diesem Produkt, die Entwickler und Tester kannten es gut, es war ihnen vertraut und bequem.<\/li>\n<li>Datenvolumen: durchschnittlich 50-80 tausend Nachrichten pro Sekunde, aber wenn etwas kaputt geht, ist der Verkehr unbeschr\u00e4nkt, es k\u00f6nnen 2-3 Millionen Zeilen pro Sekunde sein.<\/li>\n<li>Nach Diskussion der Anforderungen mit den Kunden bez\u00fcglich der Geschwindigkeit der Verarbeitung von Suchanfragen erkannten wir, dass das typische Nutzungsmuster eines solchen Systems darin besteht, dass die Nutzer nach den 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 sein sollte, ohne dass sie tiefes Verst\u00e4ndnis daf\u00fcr aufbringen mussten, wie es aufgebaut ist. <\/li>\n<li>Das einzig notwendige Wartungsaufgaben f\u00fcr diese Systeme sollte gelegentlich das Austauschen von Hardware sein.<\/li>\n<li>Dar\u00fcber hinaus gibt es bei Odnoklassniki eine gro\u00dfartige technische Tradition: Jeder Dienst, den wir starten, muss einen Ausfall des Rechenzentrums \u00fcberstehen k\u00f6nnen (pl\u00f6tzlich, unvorhergesehen und zu jeder Zeit).<\/li>\n<\/ul>\n<p><\/p>\n<p>Die letzte Anforderung f\u00fcr die Umsetzung dieses Projekts hat uns am meisten zu schaffen gemacht, \u00fcber die ich noch genauer berichten werde.<\/p>\n<p><\/p>\n<h2 id=\"sreda\">Umgebung<\/h2>\n<p><\/p>\n<p>Wir arbeiten mit 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 ungef\u00e4hr 18.000 verschiedene Logquellen \u2013 Hardware, Container, virtuelle Maschinen.<\/p>\n<p><\/p>\n<p>Ein wichtiges Merkmal: 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 sind 2 Kerne garantiert, vergleichbar mit 2,0 GHz v4, wobei die restlichen Kerne bei Leerlauf genutzt werden k\u00f6nnen. <\/p>\n<p><\/p>\n<p>Anders ausgedr\u00fcckt:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster \u00fcber 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 folgenderma\u00dfen:<\/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-Lastverteiler.<\/li>\n<li>Danach gelangen die Logs zu einem Graylog-Cluster, wobei ein Teil der Daten im GELF-Format und ein Teil im syslog-Format vorliegt.<\/li>\n<li>Anschlie\u00dfend wird alles in gro\u00dfen Batches an einen Cluster von Elasticsearch-Koordinatoren geschrieben. <\/li>\n<li>Diese wiederum senden Lese- und Schreibanfragen an die entsprechenden Datenknoten. <\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster \u00fcber 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>Vielleicht sind nicht alle mit der Terminologie vertraut, daher m\u00f6chten wir etwas darauf eingehen.<\/p>\n<p><\/p>\n<p>In Elasticsearch gibt es mehrere Knotentypen \u2013 Master, Koordinator und Datenknoten. Es gibt noch zwei weitere Typen f\u00fcr unterschiedliche Log-Transformationen und die Verbindung zwischen verschiedenen Clustern, aber wir haben nur die genannten verwendet. <\/p>\n<p><\/p>\n<p><strong>Master<\/strong><br \/>\nPinged alle Knoten im Cluster, h\u00e4lt die aktuelle Clusterkarte und verbreitet sie zwischen den Knoten, verarbeitet die Ereignislogik und k\u00fcmmert sich um verschiedene clusterweite Wartungsaufgaben. <\/p>\n<p><\/p>\n<p><strong>Koordinator<\/strong><br \/>\nF\u00fchrt eine einzige Aufgabe aus: nimmt Lese- oder Schreibanfragen von Clients entgegen und leitet diesen Traffic weiter. Wenn es sich um eine Schreibanfrage handelt, wird er wahrscheinlich den Master fragen, in welchen Shard des relevanten Indexes er diese platzieren soll, und die Anfrage weiterleiten. <\/p>\n<p><\/p>\n<p><strong>Datenknoten<\/strong><br \/>\nSpeichert Daten, f\u00fchrt Suchanfragen und Operationen auf den Shards, die sich auf ihm befinden, aus.<\/p>\n<p><\/p>\n<p><strong>Graylog<\/strong><br \/>\nEs ist eine Art Kombination aus Kibana und Logstash im ELK-Stack. Graylog vereint sowohl die Benutzeroberfl\u00e4che als auch die Pipeline zur Verarbeitung von Logs. Im Hintergrund arbeiten Kafka und Zookeeper in Graylog, die die Koh\u00e4renz von Graylog als Cluster sicherstellen. Graylog ist in der Lage, Logs (Kafka) zwischenzuspeichern, falls Elasticsearch nicht verf\u00fcgbar ist, und gescheiterte Lese- und Schreibanforderungen zu wiederholen sowie Logs nach vordefinierten Regeln zu gruppieren und zu kennzeichnen. \u00c4hnlich wie Logstash bietet Graylog Funktionen zur Bearbeitung von Zeilen, bevor diese in Elasticsearch geschrieben werden.<\/p>\n<p><\/p>\n<p>Au\u00dferdem bietet Graylog eine integrierte Service Discovery, die es erm\u00f6glicht, basierend auf einer verf\u00fcgbaren Elasticsearch-Node die gesamte Cluster-Karte zu erhalten und nach einem bestimmten Tag zu filtern, was die M\u00f6glichkeit gibt, Anfragen an bestimmte Container zu richten.<\/p>\n<p><\/p>\n<p>Visuell sieht das ungef\u00e4hr so aus:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster \u00fcber 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 einer bestimmten Instanz. Hier erstellen wir ein Histogramm basierend auf der Suchanfrage und zeigen relevante Zeilen an.<\/p>\n<p><\/p>\n<h2 id=\"indeksy\">Indizes<\/h2>\n<p><\/p>\n<p>Wenn wir zur Architektur des Systems zur\u00fcckkehren, m\u00f6chte ich genauer darauf eingehen, wie wir das Modell der Indizes aufgebaut haben, damit alles korrekt funktioniert. <\/p>\n<p><\/p>\n<p>Auf dem zuvor gezeigten Diagramm ist dies die unterste Ebene: Elasticsearch-Datenknoten.<\/p>\n<p><\/p>\n<p>Ein Index ist eine umfassende virtuelle Entit\u00e4t, die aus Elasticsearch-Shards besteht. Jeder dieser Shards ist nichts anderes als ein Lucene-Index. Und jeder Lucene-Index setzt sich wiederum aus einem oder mehreren Segmenten zusammen. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster \u00fcber 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 ber\u00fccksichtigt, dass wir, um die Anforderungen an die Lesegeschwindigkeit bei gro\u00dfen Datenmengen zu erf\u00fcllen, 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) strikt der Anzahl der Datenknoten entsprechen muss. Erstens, um einen Replikationsfaktor von zwei zu gew\u00e4hrleisten (das hei\u00dft, wir k\u00f6nnen die H\u00e4lfte des Clusters verlieren). Zweitens, um die Lese- und Schreibanfragen mindestens auf der H\u00e4lfte des Clusters bearbeiten zu k\u00f6nnen.<\/p>\n<p><\/p>\n<p>Die Speicherdauer 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 \u00fcber 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 dieser ins dritte Rechenzentrum. Am Ende erhalten wir eine Struktur, die einen Verlust des Rechenzentrums erm\u00f6glicht, ohne dass die Konsistenz der Daten verloren geht.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster \u00fcber 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/27cbe4d4606f5ae5f3013ea46504134b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wir haben die Rotationszeit der Indizes, also die Erstellung eines neuen Index und das L\u00f6schen des \u00e4ltesten, auf 48 Stunden festgelegt (basierend auf dem Nutzungsmuster des Index: Die letzten 48 Stunden werden am h\u00e4ufigsten abgefragt).<\/p>\n<p><\/p>\n<p>Dieser Rotationsintervall der Indizes h\u00e4ngt mit folgenden Gr\u00fcnden zusammen:<\/p>\n<p><\/p>\n<p>Wenn eine Suchanfrage an einen bestimmten Datenknoten gesendet wird, ist es aus Performance-Sicht vorteilhafter, wenn nur ein Shard befragt wird, sofern dessen Gr\u00f6\u00dfe mit der Gr\u00f6\u00dfe des Heap des Knotens vergleichbar ist. Das erm\u00f6glicht es, den \"hei\u00dfen\" Teil des Index im Heap zu halten und schnell darauf zuzugreifen. Wenn es zu vielen \"hei\u00dfen Teilen\" kommt, 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 an Threads zu, die der Anzahl der hyperthreading-f\u00e4higen Kerne der physischen Maschine entspricht. Wenn die Suchanfrage eine gro\u00dfe Anzahl von Shards betrifft, steigt die Anzahl der Threads proportional an. Dies wirkt sich negativ auf die Suchgeschwindigkeit aus und beeintr\u00e4chtigt die Indizierung neuer Daten. <\/p>\n<p><\/p>\n<p>\u0427\u0442\u043e\u0431\u044b \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0442\u044c \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u044b\u0439 latency \u043f\u043e\u0438\u0441\u043a\u0430, \u043c\u044b \u0440\u0435\u0448\u0438\u043b\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c SSD. \u0414\u043b\u044f \u0431\u044b\u0441\u0442\u0440\u043e\u0439 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432 \u043c\u0430\u0448\u0438\u043d\u044b, \u043d\u0430 \u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u0440\u0430\u0437\u043c\u0435\u0449\u0430\u043b\u0438\u0441\u044c \u044d\u0442\u0438 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u044b, \u0434\u043e\u043b\u0436\u043d\u044b \u0431\u044b\u043b\u0438 \u043e\u0431\u043b\u0430\u0434\u0430\u0442\u044c \u043f\u043e \u043c\u0435\u043d\u044c\u0448\u0435\u0439 \u043c\u0435\u0440\u0435 56 \u044f\u0434\u0440\u0430\u043c\u0438. \u0426\u0438\u0444\u0440\u0430 \u0432 56 \u0432\u044b\u0431\u0440\u0430\u043d\u0430 \u043a\u0430\u043a \u0443\u0441\u043b\u043e\u0432\u043d\u043e-\u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u0430\u044f \u0432\u0435\u043b\u0438\u0447\u0438\u043d\u0430, \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u044f\u044e\u0449\u0430\u044f \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u0442\u0440\u0435\u0434\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0431\u0443\u0434\u0435\u0442 \u043f\u043e\u0440\u043e\u0436\u0434\u0430\u0442\u044c Elasticsearch \u0432 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0435 \u0440\u0430\u0431\u043e\u0442\u044b. \u0412 Elasitcsearch \u043c\u043d\u043e\u0433\u0438\u0435 \u043f\u0430\u0440\u0430\u043c\u0435\u0442\u0440\u044b thread pool \u043d\u0430\u043f\u0440\u044f\u043c\u0443\u044e \u0437\u0430\u0432\u0438\u0441\u044f\u0442 \u043e\u0442 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u0430 \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0445 \u044f\u0434\u0435\u0440, \u0447\u0442\u043e \u0432 \u0441\u0432\u043e\u044e \u043e\u0447\u0435\u0440\u0435\u0434\u044c \u043f\u0440\u044f\u043c\u043e \u0432\u043b\u0438\u044f\u0435\u0442 \u043d\u0430 \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e\u0435 \u043a\u043e\u043b-\u0432\u043e \u043d\u043e\u0434 \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 \u043f\u043e \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u0443 &quot;\u043c\u0435\u043d\u044c\u0448\u0435 \u044f\u0434\u0435\u0440 \u2014 \u0431\u043e\u043b\u044c\u0448\u0435 \u043d\u043e\u0434&quot;. <\/p>\n<p><\/p>\n<p>Insgesamt haben wir herausgefunden, dass ein Shard durchschnittlich etwa 20 Gigabyte wiegt und auf 1 Index 360 Shards entfallen. Wenn wir diese alle alle 48 Stunden rotieren, haben wir 15 davon. Jeder Index speichert die Daten f\u00fcr 2 Tage.<\/p>\n<p><\/p>\n<h2 id=\"shemy-zapisi-i-chteniya-dannyh\">Datenspeicher- und -leseschemata<\/h2>\n<p><\/p>\n<p>Lassen Sie uns kl\u00e4ren, wie in diesem System Daten gespeichert werden.<\/p>\n<p><\/p>\n<p>Angenommen, wir erhalten eine Anfrage von Graylog an den Koordinator. Zum Beispiel m\u00f6chten wir 2.000 bis 3.000 Zeilen indizieren. <\/p>\n<p><\/p>\n<p>Der Koordinator fragt den Master: \u201eIn der Anfrage zur Indizierung haben wir spezifisch den Index angegeben, aber nicht, in welchen Shard dies geschrieben werden soll.\u201c <\/p>\n<p><\/p>\n<p>Der Master antwortet: \u201eSpeichere diese Informationen im Shard Nummer 71\u201c, woraufhin sie direkt an den relevanten Datenknoten gesendet wird, wo sich der prim\u00e4re Shard Nummer 71 befindet.<\/p>\n<p><\/p>\n<p>Anschlie\u00dfend 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 \u00fcber 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 anhand des Index weiter, wobei Elasticsearch grunds\u00e4tzlich im Round-Robin-Verfahren Anfragen zwischen dem prim\u00e4ren Shard und dem Replica-Shard verteilt. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster \u00fcber 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/cb32bac878e04d6f50d103ebbc395a7f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Die 180 Knoten antworten 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 eingegangen sind oder bei Erreichen eines Timeouts, liefert er alles direkt an den Kunden aus. <\/p>\n<p><\/p>\n<p>Das gesamte System bearbeitet im Durchschnitt Suchanfragen der letzten 48 Stunden in 300-400 ms, abgesehen von jenen Anfragen mit einem f\u00fchrenden Platzhalter.<\/p>\n<p><\/p>\n<h2 id=\"cvetochki-s-elasticsearch-nastroyka-java\">\u201eBl\u00fcmchen\u201c mit Elasticsearch: Java-Konfiguration<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster \u00fcber 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/fc9ac4b8ee41bc35f5f01b8d9c4ff2f6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Um sicherzustellen, dass alles so funktioniert, wie wir es urspr\u00fcnglich wollten, haben wir unterschiedlichste Aspekte im Cluster intensiv getestet. <\/p>\n<p><\/p>\n<p>Ein Teil der entdeckten Probleme hing mit der standardm\u00e4\u00dfigen Java-Konfiguration in Elasticsearch zusammen. <\/p>\n<p><\/p>\n<p><strong>Problem eins<\/strong><br \/>\n\u041c\u044b \u043d\u0430\u0431\u043b\u044e\u0434\u0430\u043b\u0438 \u043e\u0447\u0435\u043d\u044c \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0439 \u043e \u0442\u043e\u043c, \u0447\u0442\u043e \u0443 \u043d\u0430\u0441 \u043d\u0430 \u0443\u0440\u043e\u0432\u043d\u0435 Lucene, \u043a\u043e\u0433\u0434\u0430 \u0437\u0430\u043f\u0443\u0449\u0435\u043d\u044b background job&#8217;\u044b, \u043c\u0435\u0440\u0434\u0436\u0438 \u0441\u0435\u0433\u043c\u0435\u043d\u0442\u043e\u0432 Lucene \u0437\u0430\u0432\u0435\u0440\u0448\u0430\u044e\u0442\u0441\u044f \u0441 \u043e\u0448\u0438\u0431\u043a\u043e\u0439. \u041f\u0440\u0438 \u044d\u0442\u043e\u043c \u0432 \u043b\u043e\u0433\u0430\u0445 \u0431\u044b\u043b\u043e \u0432\u0438\u0434\u043d\u043e, \u0447\u0442\u043e \u044d\u0442\u043e OutOfMemoryError-\u043e\u0448\u0438\u0431\u043a\u0430. \u041f\u043e \u0442\u0435\u043b\u0435\u043c\u0435\u0442\u0440\u0438\u0438 \u043c\u044b \u0432\u0438\u0434\u0435\u043b\u0438, \u0447\u0442\u043e \u0445\u0438\u043f \u0441\u0432\u043e\u0431\u043e\u0434\u0435\u043d, \u0438 \u043d\u0435 \u0431\u044b\u043b\u043e \u043f\u043e\u043d\u044f\u0442\u043d\u043e, \u043f\u043e\u0447\u0435\u043c\u0443 \u044d\u0442\u0430 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u044f \u043f\u0430\u0434\u0430\u0435\u0442. <\/p>\n<p><\/p>\n<p>Es stellte sich heraus, dass die Merges der Lucene-Indizes au\u00dferhalb des Heaps stattfanden. Die Container waren in ihrem Ressourcenverbrauch stark limitiert. Nur der Heap passte in diese Ressourcen (der Wert heap.size war etwa gleich der RAM-Gr\u00f6\u00dfe), w\u00e4hrend einige Off-Heap-Operationen mit einem Allocationsfehler abst\u00fcrzten, wenn sie aus irgendwelchen Gr\u00fcnden die verbleibenden ~500 MB vor dem Limit nicht einhielten.<\/p>\n<p><\/p>\n<p>Die L\u00f6sung war ziemlich trivial: Der f\u00fcr den Container verf\u00fcgbare RAM wurde erh\u00f6ht, und danach haben wir vergessen, dass wir \u00fcberhaupt solche Probleme hatten.<\/p>\n<p><\/p>\n<p><strong>Das zweite Problem<\/strong><br \/>\nNach etwa 4-5 Tagen nach dem Start des Clusters bemerkten wir, dass die Datenknoten anfingen, sporadisch aus dem Cluster auszutreten und nach etwa 10-20 Sekunden wieder einzutreten. <\/p>\n<p><\/p>\n<p>Als wir anfingen, das Problem zu untersuchen, stellte sich heraus, dass der sogenannte Off-Heap-Speicher in Elasticsearch nahezu unkontrolliert bleibt. Als wir dem Container mehr Speicher gaben, erhielten wir die M\u00f6glichkeit, die Direct Buffer Pools mit unterschiedlichen Informationen zu f\u00fcllen, die nur dann geleert wurden, wenn ein expliziter GC von Elasticsearch ausgel\u00f6st wurde. <\/p>\n<p><\/p>\n<p>In einigen F\u00e4llen dauerte dieser Vorgang ziemlich lange, und in der Zwischenzeit konnte der Cluster diesen Knoten bereits als ausgefallen markieren. Dieses Problem ist gut beschrieben <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 wie folgt: Wir beschr\u00e4nkten die Java-M\u00f6glichkeit, den gr\u00f6\u00dften Teil des Speichers au\u00dferhalb des Heaps f\u00fcr diese Operationen zu verwenden. Wir limitierten ihn auf 16 Gigabyte (-XX:MaxDirectMemorySize=16g), wodurch der explizite GC deutlich h\u00e4ufiger aufgerufen wurde und schneller ablief, wodurch er den Cluster nicht mehr destabilisierte.<\/p>\n<p><\/p>\n<p><strong>Das dritte Problem<\/strong><br \/>\nWenn Sie denken, dass die Probleme mit \"Knoten, die den Cluster im ungelegensten Moment verlassen\" damit beseitigt sind, irren Sie sich. <\/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 ziemlicher grober Fehler, denn bei der Verwendung von mmapfs wird die Datei in den Arbeitsspeicher gemappt, und anschlie\u00dfend arbeiten wir mit der gemappten Datei. Dadurch ergibt sich, dass wir beim Versuch, den GC zu stoppen, sehr lange zum Safepoint brauchen, und auf dem Weg dorthin h\u00f6rt die Anwendung auf, auf die Anfragen des Masters zu antworten, ob sie noch aktiv ist. In der Folge geht der Master davon aus, dass der Knoten nicht mehr im Cluster vorhanden ist. Nach etwa 5\u201310 Sekunden wird der Garbage Collector aktiv, der Knoten erwacht, tritt wieder in den Cluster ein und beginnt mit der Initialisierung der Shards. All dies erinnerte stark an \"die Produktion, die wir verdient haben\" und war f\u00fcr etwas Ernsthaftes nicht geeignet.<\/p>\n<p><\/p>\n<p>Um dieses Verhalten zu vermeiden, sind wir zun\u00e4chst auf den Standard niofs umgestiegen. Als wir dann von der f\u00fcnften auf die sechste Version von Elastic migrierten, haben wir hybridfs ausprobiert, bei dem dieses Problem nicht auftrat. Details zu den Speichertypen finden Sie hier. <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 ein weiteres sehr interessantes Problem, das wir au\u00dfergew\u00f6hnlich lange beheben mussten. Wir haben es \u00fcber 2-3 Monate hinweg verfolgt, da das Muster v\u00f6llig unklar war. <\/p>\n<p><\/p>\n<p>Manchmal gingen unsere Koordinatoren in den Full GC, normalerweise nachmittags, und kehrten nicht mehr zur\u00fcck. Bei der Protokollierung der GC-Verz\u00f6gerungen sah das so aus: Alles lief gut, gut, gut, und dann pl\u00f6tzlich \u2014 und alles war schlagartig schlecht. <\/p>\n<p><\/p>\n<p>Zun\u00e4chst dachten wir, dass wir einen b\u00f6sartigen Benutzer haben, der eine Anfrage ausf\u00fchrt, die den Koordinator aus dem Betriebsmodus wirft. Wir haben sehr lange die Anfragen protokolliert, um herauszufinden, was vor sich geht. <\/p>\n<p><\/p>\n<p>Am Ende stellte sich heraus, dass in dem Moment, in dem ein Benutzer eine sehr gro\u00dfe Anfrage ausl\u00f6st und diese auf einen bestimmten Elasticsearch-Koordinator gelangt, einige Knoten langsamer antworten als andere. <\/p>\n<p><\/p>\n<p>W\u00e4hrend der Koordinator auf die Antworten aller Knoten wartet, speichert er die Ergebnisse, die von den bereits antwortenden Knoten gesendet wurden. F\u00fcr die GC bedeutet das, dass sich unser Nutzungsmuster des Heaps sehr schnell \u00e4ndert. 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 einer solchen Situation zu \u00e4ndern, ist die Migration auf JDK13 und die Nutzung des Garbage Collectors Shenandoah. Das hat das Problem gel\u00f6st, unsere Koordinatoren h\u00f6ren auf abzust\u00fcrzen. <\/p>\n<p><\/p>\n<p>Damit endeten die Probleme mit Java und es begannen die Probleme mit der Durchsatzrate. <\/p>\n<p><\/p>\n<h2 id=\"yagodki-s-elasticsearch-propusknaya-sposobnost\">Die \u201aKirschen\u2018 mit Elasticsearch: Durchsatzrate<\/h2>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster \u00fcber 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 l\u00e4uft, aber w\u00e4hrend der Spitzenzeiten der zu indexierenden Dokumente und bei Man\u00f6vern die Leistung unzureichend ist.<\/p>\n<p><\/p>\n<p>Das erste bemerkte Symptom: Bei bestimmten \u201aAusbr\u00fcchen\u2018 in der Produktion, wenn eine sehr gro\u00dfe Anzahl von Protokollen schnell generiert wird, erscheint in Graylog oft der Fehler der Indizierung es_rejected_execution. <\/p>\n<p><\/p>\n<p>Dies geschah, weil der thread_pool.write.queue auf einem Datenknoten standardm\u00e4\u00dfig nur 200 Anfragen zwischenspeichern kann, bevor Elasticsearch in der Lage ist, eine Indizierungsanfrage zu verarbeiten und die Informationen auf die Festplatte in einen Shard zu \u00fcbertragen. 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 lediglich die maximale Anzahl an Threads und die Standardgr\u00f6\u00dfe angegeben.<\/p>\n<p><\/p>\n<p>Nat\u00fcrlich haben wir diesen Wert angepasst und Folgendes herausgefunden: Speziell in unserem Setup k\u00f6nnen bis zu 300 Anfragen ziemlich gut zwischengespeichert werden, w\u00e4hrend h\u00f6here Werte dazu f\u00fchren, dass wir erneut in eine Full GC-Phase geraten.<\/p>\n<p><\/p>\n<p>Dar\u00fcber hinaus mussten wir auch Graylog anpassen, sodass es nicht h\u00e4ufig in kleinen Batch-Gr\u00f6\u00dfen, sondern in gro\u00dfen Batches oder alle 3 Sekunden schreibt, falls der Batch noch nicht voll ist. In diesem Fall wird die Information, die wir in Elasticsearch schreiben, nicht nach zwei Sekunden, sondern nach f\u00fcnf Sekunden verf\u00fcgbar, was f\u00fcr uns vollkommen in Ordnung ist, w\u00e4hrend die Anzahl der Retries, die erforderlich sind, um ein gro\u00dfes Informationspaket durchzudr\u00fccken, verringert wird.<\/p>\n<p><\/p>\n<p>Dies ist besonders wichtig in den Momenten, in denen wir hier oder dort einen Ausfall haben, und dies mit Nachdruck meldet, um zu vermeiden, dass das Elastic komplett zugespammt wird und nach einer gewissen Zeit die Knoten von Graylog aufgrund \u00fcberf\u00fcllter Puffer nicht mehr funktionieren.<\/p>\n<p><\/p>\n<p>Au\u00dferdem erhielten wir Beschwerden von Programmierern und Testern, wenn in der Produktion diese Explosionsprobleme auftraten: In dem Moment, in dem sie wirklich auf diese Logs angewiesen waren, wurden sie ihnen sehr langsam bereitgestellt.<\/p>\n<p><\/p>\n<p>Wir begannen zu analysieren. Einerseits war klar, dass sowohl die Suchanfragen als auch die Indexierungsanfragen im Grunde auf denselben physischen Maschinen verarbeitet werden, und dass es daher zu bestimmten Einbr\u00fcchen kommen w\u00fcrde. <\/p>\n<p><\/p>\n<p>Aber dies konnte teilweise umgangen werden, da in den sechsten Versionen von Elasticsearch ein Algorithmus eingef\u00fchrt wurde, der es erm\u00f6glicht, Anfragen nicht zuf\u00e4llig im Round-Robin-Verfahren zwischen relevanten Datenknoten zu verteilen (ein Container, der mit der Indexierung besch\u00e4ftigt ist und den Primary-Shard h\u00e4lt, kann sehr besch\u00e4ftigt sein, sodass er nicht schnell antworten kann), sondern diese Anfrage an einen weniger belasteten Container mit Replica-Shard zu richten, der wesentlich schneller antwortet. Mit anderen Worten, wir haben uns f\u00fcr use_adaptive_replica_selection: true entschieden.<\/p>\n<p><\/p>\n<p>Das Bild des Lesens sieht nun so aus:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster \u00fcber 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 die Abfragezeit erheblich verbessert, insbesondere wenn wir einen hohen Log-Schreibstrom hatten.<\/p>\n<p><\/p>\n<p>Das Hauptproblem bestand schlie\u00dflich darin, das Datenzentrum schmerzfrei au\u00dfer Betrieb zu nehmen.<\/p>\n<p><\/p>\n<p>Was wir von dem Cluster erwarteten, nachdem die Verbindung zu einem Rechenzentrum verloren ging: <\/p>\n<p><\/p>\n<ul>\n<li>Wenn sich im ausgefallenen Rechenzentrum der aktuelle Master befindet, wird er ausgew\u00e4hlt und wechselt seine Rolle zu einem anderen Knoten in einem anderen Rechenzentrum.<\/li>\n<li>Der Master wird schnell alle nicht erreichbaren Knoten aus dem Cluster entfernen.<\/li>\n<li>Auf der Grundlage der verbleibenden Knoten wird er verstehen: Im verlorenen Rechenzentrum hatten wir bestimmte Prim\u00e4r-Shards, wird schnell die komplement\u00e4ren Replica-Shards in den verbleibenden Rechenzentren bef\u00f6rdern, und die Datenindizierung wird fortgesetzt. <\/li>\n<li>Infolgedessen wird die Durchsatzleistung des Clusters f\u00fcr Schreiben und Lesen allm\u00e4hlich abnehmen, jedoch insgesamt wird alles, auch wenn es langsam, stabil funktionieren.<\/li>\n<\/ul>\n<p><\/p>\n<p>Wie sich herausstellte, wollten wir etwas in dieser Richtung:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster \u00fcber 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/71fa3d19a61eb58ddb93a4df55c759c5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Und erhielten Folgendes:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster \u00fcber 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/ab32be4dfbbb4bcc3279d57021707980.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wie ist das passiert? <\/p>\n<p><\/p>\n<p>Im Moment des Ausfalls des Rechenzentrums wurde der Master zu unserem Engpass.<\/p>\n<p><\/p>\n<p>Warum?<\/p>\n<p><\/p>\n<p>Der Master enth\u00e4lt einen TaskBatcher, der f\u00fcr die Verteilung bestimmter Aufgaben und Ereignisse im Cluster verantwortlich ist. Jeder Knotenabgang, jede F\u00f6rderung eines Shards von Replica zu Primary und jede Aufgabe zur Erstellung eines Shards \u2014 all dies gelangt zun\u00e4chst zum TaskBatcher, wo es sequenziell und in einem einzigen Prozess verarbeitet wird.<\/p>\n<p><\/p>\n<p>Beim Ausfall eines Rechenzentrums stellten alle verbleibenden Datenknoten in den \u00fcberlebenden Rechenzentren fest, dass es ihre Pflicht war, dem Master zu berichten: \"Wir haben bestimmte Shards und Datenknoten verloren.\" <\/p>\n<p><\/p>\n<p>Die \u00fcberlebenden Datenknoten \u00fcbermittelten diese Informationen an den aktuellen Master und warteten auf die Best\u00e4tigung, dass er sie erhalten hatte. Diese warteten jedoch vergebens, da der Master die Aufgaben schneller erhielt, als er antworten konnte. Die Knoten wiederholten die Anfragen nach Ablauf der Zeit, w\u00e4hrend der Master in der Zwischenzeit nicht mehr versuchte zu antworten, sondern vollst\u00e4ndig mit der Sortierung der Anfragen nach Priorit\u00e4t besch\u00e4ftigt war.<\/p>\n<p><\/p>\n<p>Im Terminaldaten f\u00fchrte es dazu, dass die Datennodes den Master so stark spammten, dass er in einen vollst\u00e4ndigen Garbage Collection (GC) \u00fcberging. Danach wechselte die Rolle des Masters zu einem anderen Node, wobei dasselbe Problem auftrat, und letztendlich fiel der Cluster komplett auseinander. <\/p>\n<p><\/p>\n<p>Wir f\u00fchrten Messungen durch und bis zur Version 6.4.0, in der dieses Problem behoben wurde, gen\u00fcgte es, gleichzeitig nur 10 von 360 Datennodes abzuschalten, um den gesamten Cluster 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 \u00fcber 200 TB+\" src=\"\/wp-content\/uploads\/2020\/03\/3bed554b2703e7521339e9d943648ee4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nach Version 6.4.0, in der dieser nervige Fehler behoben wurde, h\u00f6rten die Datennodes auf, den Master zu t\u00f6ten. Aber kl\u00fcger ist er dadurch nicht geworden. Konkret: Wenn wir 2, 3 oder 10 (jede Anzahl au\u00dfer eins) Datennodes abschalten, erh\u00e4lt der Master eine erste Nachricht, die ihm mitteilt, dass Node A ausgefallen ist, und versucht, dies Node B, Node C und Node D zu erz\u00e4hlen. <\/p>\n<p><\/p>\n<p>Aktuell kann man nur mit einem Timeout f\u00fcr die Versuche, jemandem etwas zu berichten, k\u00e4mpfen, der irgendwo zwischen 20 und 30 Sekunden liegt, und somit die Geschwindigkeit des Ausfalls des Datencenters aus dem Cluster steuern.<\/p>\n<p><\/p>\n<p>Im Prinzip erf\u00fcllt dies die 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 Bug. Dieser wurde \u00fcbrigens erfolgreich von den Entwicklern in Version 7.2 behoben.<\/p>\n<p><\/p>\n<p>Wenn ein Datenknoten ausfiel, stellte sich heraus, dass es wichtiger war, die Informationen \u00fcber seinen Ausfall zu verbreiten, als dem gesamten Cluster zu berichten, dass sich auf ihm bestimmte Primary-Shards befanden (um Replica-Shards in einem anderen Rechenzentrum auf Primary zu promoten, wo dann Informationen geschrieben werden konnten).<\/p>\n<p><\/p>\n<p>Deshalb werden die ausgefallenen Datenknoten nach dem 'Sturm' nicht sofort als stale markiert. Folglich m\u00fcssen wir warten, bis alle Pings zu den ausgefallenen Datenknoten timeouten, und erst danach beginnt unser Cluster zu berichten, wo die Fortsetzung der Informationsaufzeichnung erforderlich ist. Weitere Details k\u00f6nnen hier gelesen werden. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/elastic\/elasticsearch\/issues\/46909\">hier<\/a><\/noindex>. <\/p>\n<p><\/p>\n<p>Letztendlich dauert der Ausfall eines Datenzentrums heute in der Hauptsaison etwa 5 Minuten. F\u00fcr so eine gro\u00dfe und unbewegliche Maschine ist das ein recht gutes Ergebnis.<\/p>\n<p><\/p>\n<p>Daher sind wir zu folgender L\u00f6sung gekommen:<\/p>\n<p><\/p>\n<ul>\n<li>Wir haben 360 Datenknoten mit 700 Gigabyte Festplatten.<\/li>\n<li>60 Koordinatoren f\u00fcr das Routing des Traffics \u00fcber diese Datenknoten.<\/li>\n<li>40 Master, die wir als Erbe aus Zeiten vor Version 6.4.0 behalten haben \u2013 um den Ausfall des Rechenzentrums zu \u00fcberstehen, waren wir moralisch darauf vorbereitet, einige Maschinen zu verlieren, um selbst im schlimmsten Fall einen Master-Quorum zu haben.<\/li>\n<li>Jede Versuche, Rollen in einem Container zu kombinieren, scheiterten daran, dass irgendwann der Knoten unter der Last zerbrach. <\/li>\n<li>Im gesamten Cluster wird eine Heap-Gr\u00f6\u00dfe 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 Knoten abgest\u00fcrzt sind oder der Circuit Breaker in Elasticsearch ausgel\u00f6st wurde.<\/li>\n<li>Dar\u00fcber hinaus haben wir zur Sicherstellung der Suchleistung versucht, die Anzahl der Objekte im Cluster so gering wie m\u00f6glich zu halten, um so wenig Ereignisse wie m\u00f6glich an dem engsten Punkt, den wir im Master hatten, zu verarbeiten.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"naposledok-o-monitoringe\">Zuletzt noch zur \u00dcberwachung.<\/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 meldet unserem Cloud-System, dass er vorhanden ist und welche Shards sich darauf befinden. Wenn wir irgendwo einen Knoten abschalten, berichtet das Cluster nach 2-3 Sekunden, dass wir in Rechenzentrum A die Knoten 2, 3 und 4 abgeschaltet haben \u2013 das bedeutet, dass wir in anderen Rechenzentren auf keinen Fall die Knoten abschalten k\u00f6nnen, auf denen sich Shards im Einzelnen befinden.<\/li>\n<li>Da wir das Verhalten des Masters genau kennen, achten wir sehr sorgf\u00e4ltig auf die Anzahl der ausstehenden Aufgaben. Selbst eine einzige h\u00e4ngende Aufgabe, die nicht rechtzeitig Zeit\u00fcberschreitung erh\u00e4lt, kann theoretisch in einer Notfallsituation der Grund sein, weshalb wir beispielsweise die Promotion des Replica-Shards in den Primary nicht umsetzen k\u00f6nnen, was zur Stilllegung der Indizierung f\u00fchren w\u00fcrde.<\/li>\n<li>Wir achten auch sehr genau auf die Verz\u00f6gerungen des Garbage Collectors, da wir damit bereits erhebliche Schwierigkeiten bei der Optimierung hatten.<\/li>\n<li>Rejects in den Threads, um im Voraus zu verstehen, wo das \u201eFlaschenhals\u201c liegt.<\/li>\n<li>Und die Standardmetriken wie Heap, RAM und I\/O.<\/li>\n<\/ul>\n<p><\/p>\n<p>Beim Aufbau des Monitorings m\u00fcssen unbedingt die Besonderheiten des Thread Pools in Elasticsearch ber\u00fccksichtigt werden. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/guide\/en\/elasticsearch\/reference\/6.8\/modules-threadpool.html\">Elasticsearch-Dokumentation<\/a><\/noindex> beschreibt die Konfigurationsm\u00f6glichkeiten und Standardwerte f\u00fcr Suche, Indizierung, erw\u00e4hnt jedoch nicht das thread_pool.management. Diese Threads verarbeiten unter anderem Abfragen wie _cat\/shards und \u00e4hnliche, die sich gut f\u00fcr das Monitoring eignen. Je gr\u00f6\u00dfer der Cluster, desto mehr solcher Abfragen werden in einer bestimmten Zeit ausgef\u00fchrt, und der erw\u00e4hnte thread_pool.management ist nicht nur in der offiziellen Dokumentation nicht enthalten, sondern ist au\u00dferdem standardm\u00e4\u00dfig auf 5 Threads limitiert, was sehr schnell ersch\u00f6pft ist und dazu f\u00fchrt, dass das Monitoring 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 an die Hand 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 ist es uns gelungen, unsere Anforderungen in die bereits bestehenden Produkte zu integrieren, ohne diese patchen oder neu schreiben zu m\u00fcssen.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Elasticsearch-Cluster \u00fcber 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 4.9.10 - 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. \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\" \/>\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) 4.9.10\" \/>\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. \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\" \/>\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 mit \u00fcber 200 TB | ProHoster","description":"Viele stehen vor der Herausforderung mit Elasticsearch. Was passiert jedoch, wenn man damit Logs in \"besonders gro\u00dfer Menge\" speichern m\u00f6chte? Und das ganz ohne schmerzhafte Ausf\u00e4lle durch den Ausfall eines der mehrere Rechenzentren? Welche Architektur sollte man w\u00e4hlen und wo verstecken sich die Stolpersteine? Wir bei Odnoklassniki haben uns entschieden, das Log-Management mit Elasticsearch zu l\u00f6sen und teilen nun unsere Erfahrungen mit der Community:","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. \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","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"},"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}]}}