Bei Tests für ein neues Feature haben wir einen Linux-Kernel-Bug mit negativen Auswirkungen auf SSDs auf bestimmten Linux-Kerneln gefunden. Lesen Sie, wie wir zur Untersuchung mit 2 engen Partnern zusammengearbeitet haben: Google Cloud und Canonical.

Wir bei Elastic arbeiten ständig an Innovationen und neuen Features.&nbsp;Bevor diese neuen Features veröffentlicht werden, testen wir sie, um sicherzustellen, dass sie so funktionieren, wie sie sollen, und verlässlich sind. Dabei stoßen wir mitunter auf Bugs oder andere Probleme.
Bei Tests für ein neues Feature haben wir einen Linux-Kernel-Bug mit negativen Auswirkungen auf SSDs auf bestimmten Linux-Kerneln gefunden. In diesem Blogartikel beschreiben wir, wie wir bei der Untersuchung des Bugs vorgegangen sind und wie wir dabei erfolgreich mit zwei engen Partnern zusammengearbeitet haben: Google Cloud und Canonical.
Unsere Untersuchung hat zur Veröffentlichung neuer Ubuntu-Kernel geführt, <a href="#conclusion">mit denen das Problem behoben wurde</a>.
 <h2>Vorgeschichte</h2>Im Februar 2019 führten wir einen <a href="/de/blog/benchmarking-elasticsearch-cross-cluster-replication">10-tägigen Stabilitätstest</a> für die <a href="/guide/en/elasticsearch/reference/7.8/xpack-ccr.html">clusterübergreifende Replikation (Cross-Cluster Replication – CCR)</a> durch. Getestet wurde ein <a href="https://github.com/elastic/rally-eventdata-track/blob/master/eventdata/challenges/bulk-update.json">Ingestionsaufkommen mit hohem Aktualisierungsanteil</a> und als Tool kam <a href="https://esrally.readthedocs.io/en/stable/">Rally, das Standard-Benchmarking-Tool von Elasticsearch</a>, zum Einsatz. Für den Test wurde das neueste Elasticsearch-Commit aus dem (damals) noch nicht veröffentlichten 7.0-Branch verwendet. Nach ein paar Tagen schlug der Test fehl und in den Elasticsearch-Logs war Folgendes zu lesen:
<pre class="prettyprint">… 
Caused by: org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?)
</pre>Nach der Entdeckung[<a href="#ref1" id="1">1</a>] einer Indexkorruption versucht Elasticsearch, den Index anhand eines Replikats wiederherzustellen. Diese Wiederherstellung läuft in vielen Fällen problemlos und die Datenkorruption bleibt vom Nutzer letztlich unbemerkt, sofern sich niemand die Logdaten ansieht. Unter bestimmten Umständen kann es jedoch trotz der durch Replikate sichergestellten Redundanz zu Datenverlust kommen. Wir wollten daher der Ursache für die Datenkorruption auf den Grund gehen und herausfinden, wie sich das Problem lösen lässt.
Zunächst verdächtigten wir ein neues Elasticsearch-Feature, <a href="/guide/en/elasticsearch/reference/7.8/xpack-ccr.html">CCR</a>/<a href="https://github.com/elastic/elasticsearch/issues/29530">Soft Deletes</a>, als Verursacher. Dieser Verdacht löste sich jedoch schnell in Luft auf, denn wir stellten fest, dass wir die Indexkorruption auch mit nur einem Cluster und deaktiviertem „CCR/Soft Deletes“-Feature reproduzieren konnten. Im Zuge unserer weiteren Recherchen konnten wir das Problem auch in Elasticsearch-Versionen nachstellen, die älter waren als die Betaversion des „CCR/Soft Deletes“-Features. Dieses Feature war also unschuldig.
Wir recherchierten weiter und stießen darauf, dass sich die Indexkorruption zwar auf der Google Cloud Platform (GCP) mit dem <a href="https://console.cloud.google.com/marketplace/details/ubuntu-os-cloud/ubuntu-xenial">Ubuntu-Xenial-Image von Canonical</a> und <a href="https://cloud.google.com/compute/docs/disks/local-ssd">lokalen SSDs</a> mit dem <code>4.15‑0‑*‑gcp</code>-Kernel, nicht aber in einer Bare-Metal-Umgebung mit demselben Betriebssystem und SSDs mit 4.13- oder 4.15-<a href="https://wiki.ubuntu.com/Kernel/LTSEnablementStack">HWE-Kerneln</a> reproduzieren ließ.
Das lenkte unsere Aufmerksamkeit sofort auf Elastic Cloud, von wo wir uns mehr Daten über das Problem und seine Auswirkungen erhofften. Parallel dazu konnten wir durch Maßnahmen wie Tests mit unterschiedlichen Dateisystemen, die Deaktivierung von RAID und schließlich auch die Verwendung eines neueren Mainline-Kernels eine Reihe von weiteren Verdächtigen ausschließen&nbsp;– keine dieser Maßnahmen brachte eine Besserung.
 <h2>Weiteres Nachforschen mithilfe des Google Cloud-Supports</h2>Zur Vereinfachung der Problemreproduktion erstellten wir ein paar <a href="https://gist.github.com/dliappis/54a9eedd5a272cf13b49ecaa85f87c7f">einfache Reproduktionsskripte</a> und wandten uns an unseren Partner Google, damit dieser sich eingehender mit etwaigen Problemen in seiner Umgebung beschäftigen konnte.
Der GCP-Support konnte anhand der von uns bereitgestellten Skripte das Problem zuverlässig reproduzieren. Bei Google sahen die Fehlermeldungen zum Beispiel wie folgt aus:
<pre class="prettyprint">org.apache.lucene.index.CorruptIndexException: codec footer mismatch (file 
truncated?): actual footer=-2016340526 vs expected footer=-1071082520 
(resource=BufferedChecksumIndexInput(MMapIndexInput(path="/home/dl/es/data/nodes/0/indices/IF1vmFH6RY-MZuNfx2IO4w/0/index/_iya_1e_Lucene80_0.dvd")))
</pre>Innerhalb des Zeitraums, in dem das Problem auftrat, stieg der E/A-Durchsatz über 160&nbsp;MB/s bei einem IOPS-Wert von 16.000. Das Ergebnis blieb auch nach mehreren Tests dasselbe. Da Elasticsearch (standardmäßig) <a href="/guide/en/elasticsearch/reference/7.8/index-modules-store.html#file-system">für einen Teil des Datenspeichers speichereingeblendete Dateien verwendet</a>, vermuteten wir, dass einige Dateizugriffe zu mehr großen Seitenfehlern führten und damit einen Anstieg bei den E/A-Operationen für den Datenträger bewirkten, wodurch dann schließlich das Problem ausgelöst wurde. Um das Auftreten von Seitenfehlern zu reduzieren, versuchten wir es mit einer Vergrößerung des Arbeitsspeichers der GCP-Instanzen von 32&nbsp;GB auf 52&nbsp;GB. Nach dieser Arbeitsspeichervergrößerung trat das Problem nicht mehr auf und der E/A-Durchsatz erfolgte mit 50&nbsp;MB/s bei 4.000&nbsp;IOPS.&nbsp;
Der erste Durchbruch war unsere Beobachtung, dass es zwischen GCP und der Bare-Metal-Umgebung einen wichtigen Unterschied gab: Auf dem GCP-Kernel war ein Feature namens <a href="https://lwn.net/Articles/738449/">Multi-Queue Block Layer</a> (blk_mq) aktiviert, das es auf dem Bare-Metal-Kernel nicht gab[<a href="#ref2" id="2">2</a>]. Allerdings ist es so, dass es beim ‑gcp-Image von Ubuntu Linux nach einer bestimmten Version[<a href="#ref3" id="3">3</a>] nicht mehr möglich ist, blk_mq[<a href="#ref4" id="4">4</a>] über die Kerneloptionen zu deaktivieren. Der GCP-Support zeigte uns, wie wir blk_mq deaktivieren können, indem wir das Ubuntu-Image von GCP exportieren und es ohne das VIRTIO_SCSI_MULTIQUEUE-guestOS-Feature, das Multi-Queue-SCSI[<a href="#ref5" id="5">5</a>] ermöglicht, neu erstellen.
Der zweite Durchbruch kam, als wir es schafften, die Indexkorruption in der Bare-Metal-Umgebung zu reproduzieren. Dazu mussten wir <code>blk_mq</code> explizit aktivieren, wobei dies auch auf einem älteren Kernel gelang: <code>4.13.0-38-generic</code>. Wir konnten auch bestätigen, dass das Problem auf NVMe-SSDs nicht auftritt.
Damit wussten wir, dass es zwei Bedingungen gab, die zu den Datenkorruptionen führten, und dass beide gleichzeitig vorliegen mussten:
<ul>
	<li>Es werden SSDs mit SCSI-Schnittstelle verwendet (NVMe-SSDs waren nicht betroffen).</li>
	<li>blk_mq ist aktiviert.</li>
</ul>Der GCP-Support steuerte zwei weitere Workarounds bei (zusätzlich zur ausschließlichen Verwendung von NVMe-SSDs): mehr Arbeitsspeicher für die Instanzen oder Erstellen individueller Instanz-Images mit deaktiviertem Multi-Queue-SCSI-Feature.
 <h2>Einbeziehung von Canonical</h2>Wir kannten zwar nun ein paar Workarounds, aber das stellte uns noch nicht zufrieden:
<ul>
	<li>Das Problem war nicht nur auf Ubuntu-Images auf GCP beschränkt, sondern es trat auch auf Bare Metal auf.</li>
	<li>Wir wussten nicht, welcher Kernel-Commit für das Problem verantwortlich war.</li>
	<li>Wir wussten nicht, ob das Problem bei einem neueren Kernel vielleicht schon gelöst wurde.</li>
</ul>Dies alles war Anlass für uns, uns mit unserem Partner Canonical zusammenzusetzen, um weiter nachzuforschen.
Canonical begann daraufhin mit umfangreichen Tests anhand der <a href="https://gist.github.com/dliappis/54a9eedd5a272cf13b49ecaa85f87c7f">von Elastic bereitgestellten Reproduktionsskripte</a>. Dabei wurde festgestellt, dass das Problem bei Ubuntu-Mainline-Kerneln ≥&nbsp;5.0 und der Verwendung von SSDs (sowohl ohne als auch mit mq-deadline-<a href="https://wiki.ubuntu.com/Kernel/Reference/IOSchedulers">Multi-Queue-I/O-Schedulern</a>) nicht auftrat.
Als Nächstes wurden frühere Kernel-Versionen unter die Lupe genommen, um das Mindest-Delta zwischen einem Kernel zu finden, bei dem die Indexkorruption auftrat, und einem Kernel, bei dem das nicht der Fall war. Durch Nutzung mehrerer paralleler Testumgebungen (ein ganzer Testdurchlauf kann schließlich bis zu fünf Tage dauern) stellte Canonical fest, dass der erste Ubuntu-Mainline-Kernel, bei dem das Problem behoben worden ist[<a href="#ref6" id="6">6</a>], der Kernel mit der Nummer <a href="https://kernel.ubuntu.com/~kernel-ppa/mainline/v4.19.8/">4.19.8</a> war.
Die fehlenden Backports für den Kernel 4.15.0 und dessen Derivate werden im Canonical-Bug-Tracker unter <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739">LP#1848739</a> beschrieben. Weitere Details können <a href="https://lwn.net/Articles/774440/">diesem Artikel</a> und dem <a href="https://bugzilla.kernel.org/show_bug.cgi?id=201685">kernel.org-Bug</a> entnommen werden.
Nachdem Elastic und Canonical bestätigt hatten, dass ein GCP-Kernel-Patch mit allen notwendigen Backports <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/9">das Problem beseitigt</a>, wurde alles im Ubuntu-Mainline-Kernel 4.15.0 <a href="https://lists.ubuntu.com/archives/kernel-team/2019-December/106382.html">zusammengeführt</a> und die Kernel-Derivate (einschließlich ‑gcp) wurden ebenfalls aktualisiert.
 <h2 id="conclusion">Fazit</h2>Elastic arbeitet ständig daran, neue Features für den Elastic Stack zu entwickeln, um jede unserer drei Hauptlösungen weiter zu verbessern. Dabei werden wir von wirklich talentierten Entwicklern und Partnern unterstützt, die stets wachsam sind, damit Sie Ihre Arbeit in Ruhe erledigen können. Sollten wir bei unseren Tests einmal auf ein Problem stoßen, können Sie sicher sein, dass sowohl wir bei Elastic als auch die Partner, mit denen wir eng zusammenarbeiten, alles tun, um Ihnen ein bestmögliches Nutzungserlebnis zu bieten.
Unsere enge Zusammenarbeit mit Google und Canonical ermöglichte es uns, dem Problem auf den Grund zu gehen, was schließlich zur Veröffentlichung der folgenden <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739">korrigierten</a> HWE-Ubuntu-Kernel führte:
<ul>
	<li>AWS: ab <code>linux-aws - 4.15.0-1061.65</code>, veröffentlicht am <a href="https://changelogs.ubuntu.com/changelogs/pool/main/l/linux-aws/linux-aws_4.15.0-1061.65/changelog">21.02.2020</a></li>
	<li>Azure: ab <code>linux-azure - 4.15.0-1066.71</code>, veröffentlicht am <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/12">06.01.2020</a></li>
	<li>GCP: ab <code>linux-gcp - 4.15.0-1053.57</code>, veröffentlicht am <a href="https://changelogs.ubuntu.com/changelogs/pool/main/l/linux-gcp/linux-gcp_4.15.0-1053.57/changelog">05.02.2020</a></li>
	<li>Nicht plattformgebunden: ab <code>linux - 4.15.0-88.88</code>, veröffentlicht am <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/15">17.02.2020</a></li>
</ul>Mit den oben genannten oder neueren Versionen kommt es nicht mehr zu Indexkorruptionen, wenn SSDs zusammen mit dem aktivierten SCSI-Feature blk-mq genutzt werden.
Falls Sie sich keine Gedanken machen möchten, ob Ihre Umgebung vor diesem Problem geschützt ist, probieren Sie unseren <a href="/de/elasticsearch/service">Elastic Cloud</a>-Service aus – die Nutzer dieses Service sind bereits geschützt.
 <h2>Fußnoten</h2>[<a href="#1" id="ref1">1</a>] Aus Kostengründen verzichtet Elasticsearch auf standardmäßige Prüfsummenverifizierungen. Bestimmte Aktionen, wie zum Beispiel das Transferieren von Shards oder das Aufnehmen von Snapshots, können eine häufigere Prüfsummenverifizierung auslösen. In diesen Fällen kann der Eindruck entstehen, dass es diese Aktionen waren, die zugrunde liegende schleichende Datenkorruptionen verursacht haben.
[<a href="#2" id="ref2">2</a>] Zur Prüfung, ob bei SCSI- oder Device-Mapper-SSDs blk_mq aktiviert ist, können Sie <code>cat /sys/module/{scsi_mod,dm_mod}/parameters/use_blk_mq</code> verwenden.
[<a href="#3" id="ref3">3</a>] Nach <a href="https://patchwork.kernel.org/patch/10198305">https://patchwork.kernel.org/patch/10198305</a> ist blk_mq für SCSI-Geräte standardmäßig aktiviert. Das Deaktivieren über die Kerneloptionen ist nicht möglich. Dieser Patch wurde auf Ubuntu <a href="https://launchpad.net/ubuntu/+source/linux-gcp/4.15.0-1010.10~16.04.1">linux-gcp</a> zurückportiert.
[<a href="#4" id="ref4">4</a>] Zur Deaktivierung von blk_mq müssen dem Kernel die folgenden Parameter übergeben werden (z.&nbsp;B. mit grub): <code>GRUB_CMDLINE_LINUX="scsi_mod.use_blk_mq=N dm_mod.use_blk_mq=N"</code>. Eine Aktivierung kann erfolgen, indem diese Optionen auf „N“ gesetzt werden, dabei ist aber unbedingt [3] zu beachten.
[<a href="#5" id="ref5">5</a>] Beispiele für gcloud-Befehle zur Deaktivierung des VIRTIO_SCSI_MULTIQUEUE-guestOS-Features durch Neuerstellung des Ubuntu-Images:
<pre># gcloud compute images export --image-project ubuntu-os-cloud --image-family ubuntu-1604-lts --destination-uri=gs://YOUR_BUCKET/ubuntu_16.04.tar.gz 
# gcloud compute images create ubuntu-1604-test --family ubuntu-1604-lts --source-uri=gs://YOUR_BUCKET/ubuntu_16.04.tar.gz
</pre>[<a href="#6" id="ref6">6</a>] Backports
<pre> - blk-mq: quiesce queue during switching io sched and updating nr_requests 
 - blk-mq: move hctx lock/unlock into a helper 
 - blk-mq: factor out a few helpers from __blk_mq_try_issue_directly 
 - blk-mq: improve DM's blk-mq IO merging via blk_insert_cloned_request feedback 
 - dm mpath: fix missing call of path selector type-&gt;end_io 
 - blk-mq-sched: remove unused 'can_block' arg from blk_mq_sched_insert_request 
 - blk-mq: don't dispatch request in blk_mq_request_direct_issue if queue is busy 
 - blk-mq: introduce BLK_STS_DEV_RESOURCE 
 - blk-mq: Rename blk_mq_request_direct_issue() into 
 blk_mq_request_issue_directly() 
 - blk-mq: don't queue more if we get a busy return 
 - blk-mq: dequeue request one by one from sw queue if hctx is busy 
 - blk-mq: issue directly if hw queue isn't busy in case of 'none' 
 - blk-mq: fix corruption with direct issue 
 - blk-mq: fail the request in case issue failure 
 - blk-mq: punt failed direct issue to dispatch list
</pre>

cloud-gcp-region-blog-banner.png

blog-thumb-cloud-gcp-region.png

Canonical, Elastic, and Google team up to prevent data corruption in Linux

Canonical, Elastic und Google arbeiten eng zusammen, um Datenkorruption in Linux zu verhindern

Warum die Standard TRIM-Einstellungen der meisten Linux-Distributionen auf SSD-Laufwerken negative Auswirkungen auf die Leistung von Elasticsearch haben kann.

trim-elasticsearch-ssd.jpg

is-your-elasticsearch-trimmed-ssd.jpg

Is your Elasticsearch "Trimmed"?

Habt ihr Elasticsearch schon „getrimmt“?

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Software Engineer

Dimitrios Liappis

By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_self">Terms of Service</a>, and you agree to receive the <a href="/legal/privacy-statement#how-we-use-the-information" target="_self">selected communications</a> at the contact details you provided above. See <a href="/legal/privacy-statement/" target="_self">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Communication Preferences - ONLY for /communication-preferences

Durch das Absenden erklären Sie, dass Sie unsere <a href="/de/legal/elastic-cloud-account-terms" target="_self">Nutzungsbedingungen</a> gelesen haben und mit ihnen einverstanden sind und dass Sie Elastic erlauben, <a href="/de/legal/privacy-statement#how-we-use-the-information" target="_self">ausgewählte Nachrichten und Informationen</a> an die oben von Ihnen bereitgestellten Kontaktangaben zu senden. Weitere Informationen, darunter auch dazu, wie Sie Ihre Einwilligung zurückziehen können, finden Sie in der <a href="/de/legal/privacy-statement/" target="_self">Datenschutzerklärung von Elastic</a>.

By submitting you acknowledge that you've read and agree to our <a href="/legal/serverless-preview-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Serverless GDPR Text

Durch das Absenden erklären Sie, dass Sie unsere <a href="/de/legal/serverless-preview-terms" target="_self">Nutzungsbedingungen</a> gelesen haben und mit ihnen einverstanden sind und dass Sie Elastic erlauben, bezüglich unserer zugehörigen Produkte und Dienstleistungen und unter Nutzung der von Ihnen oben bereitgestellten Kontaktangaben <a href="/de/legal/privacy-statement#how-we-use-the-information" target="_self">mit Ihnen in Kontakt zu treten</a>. Weitere Informationen, darunter auch dazu, wie Sie Ihre Einwilligung zurückziehen können, finden Sie in der <a href="/de/legal/privacy-statement/" target="_self">Datenschutzerklärung von Elastic</a>.

By submitting you agree to <a href="/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud Terms of Service</a>. Your personal data will be processed in accordance with <a href="/legal/privacy-statement">Elastic's Privacy Statement</a>.

Cloud Trial GDPR Text

Beim Absenden akzeptieren Sie die <a href="/de/agreements/global/cloud-services-monthly" rel="nofollow">Nutzungsbedingungen von Elastic Cloud</a>. Die Verarbeitung Ihrer personenbezogenen Daten unterliegt der <a href="/de/legal/privacy-statement">Datenschutzerklärung von Elastic</a>.

By submitting you acknowledge that you've read and agree to our <a href="/legal/terms-of-use" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Newsletter GDPR Text

Durch das Absenden erklären Sie, dass Sie unsere <a href="/de/legal/terms-of-use" target="_self">Nutzungsbedingungen</a> gelesen haben und mit ihnen einverstanden sind und dass Sie Elastic erlauben, bezüglich unserer zugehörigen Produkte und Dienstleistungen und unter Nutzung der von Ihnen oben bereitgestellten Kontaktangaben <a href="/de/legal/privacy-statement#how-we-use-the-information" target="_self">mit Ihnen in Kontakt zu treten</a>. Weitere Informationen, darunter auch dazu, wie Sie Ihre Einwilligung zurückziehen können, finden Sie in der <a href="/de/legal/privacy-statement/" target="_self">Datenschutzerklärung von Elastic</a>.

Explore similar demos

Overview

Speakers

Close

See more insights

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

The content on this page is not available in the selected language.

Der Inhalt dieser Seite ist in der ausgewählten Sprache nicht verfügbar. Wir bei Elastic arbeiten daran, die bereitgestellten Inhalte in verschiedenen Sprachen anzubieten. Bis dahin bitten wir Sie um etwas Geduld und hoffen auf Ihr Verständnis!

Author

Watch now (no PT)

Watch now

See all top stories

All (no PT translation)

Contact information

Press Release

Share on Reddit

Articles by

Share this story

Share by Email

Thank you for your interest!

Contact Info

Follow us on Youtube

Load More

Share on LinkedIn

Follow us on LinkedIn

Search Integrations

All Solutions

Video for

Follow us on Twitter

See when this webinar starts in my time zone

Register to Watch

Register now

See All Posts

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

Sie können nicht dabei sein? Registrieren Sie sich, damit wir Ihnen die Aufzeichnung zukommen lassen können. Außerdem erhalten Sie eine E‑Mail mit Begleitmaterial.

Small image for

On-demand webinar

Featured webinar

Register to Attend

Share on Facebook

Reset all

Upcoming webinar

View more posts

Print

Hosted by

Sign In to Attend

View next

Follow us on Facebook

Share

Highlights

Learn More

Read less

You'll also receive an email with related content

Wir schicken Ihnen zudem relevante Informationen, die von Interesse sein könnten.

Thank you for registering. We will send you a confirmation email soon.

Vielen Dank für Ihre Registrierung. Sie erhalten in Kürze eine Bestätigungs-E‑Mail von uns.

Author

Articles by Dimitrios Liappis

Software Engineer, Elastic

Canonical, Elastic und Google arbeiten eng zusammen, um Datenkorruption in Linux zu verhindern

Habt ihr Elasticsearch schon „getrimmt“?