Elasticsearch 8 enables scaling the number of shards in a cluster beyond what has been possible. Built on a foundation of new benchmark infrastructure, these advances protect from regressions and provide rigorous data on how Elasticsearch can scale.

blog-elasticsearch-8-x2-throughput.png

blog-elasticsearch-8-drop-in-latency.png

elasticsearch improvement in total time taken

blog-elasticsearch-8-97-improvement-total-time-taken.png

elasticsearch copies of entire cluster state for new snapshot

blog-elasticsearch-copies-of-entire-cluster-state-for-new-snapshot.png

blog-elasticsearch-8-nightly-elastic-logs.png

blog-elasticsearch-8-wait-duration.png

blog-elasticsearch-8-wait-error-rate.png

illustration-elevate-arrow-1680x980.png

Benchmark-driven optimizations — How we pushed scalability to the next level in Elasticsearch 8

Alors que nous testions une nouvelle fonctionnalité de la Suite Elastic, nous avons identifié un bug dans un noyau Linux qui impacte les disques SSD sur certains noyaux Linux. Une investigation a été lancée, dont le succès a reposé sur une formidable

Chez Elastic, nous innovons et proposons en permanence de nouvelles fonctionnalités.&nbsp;À chaque lancement, nous nous assurons également que ces dernières sont testées, solides et fiables. Parfois, nous identifions des bugs ou d'autres problèmes.
Alors que nous testions une nouvelle fonctionnalité, nous avons identifié un bug dans un noyau Linux qui impacte les disques SSD sur certains noyaux Linux. Dans cet article, nous vous racontons la manière dont une investigation a été lancée et comment son succès a reposé sur une formidable collaboration entre deux partenaires de confiance, à savoir Google Cloud et Canonical.
Suite à cette investigation, de nouveaux noyaux Ubuntu ont été lancés afin de <a href="#conclusion">régler le problème</a>.
 <h2>L'événement déclencheur</h2>En février&nbsp;2019, nous avons mené un <a href="/fr/blog/benchmarking-elasticsearch-cross-cluster-replication">test de stabilité de 10&nbsp;jours</a> pour <a href="/guide/en/elasticsearch/reference/7.8/xpack-ccr.html">la réplication inter-clusters (CCR)</a> à l'aide de l'<a href="https://esrally.readthedocs.io/en/stable/">outil standard d'évaluation comparative d'Elasticsearch, appelé Rally</a>, en nous fondant sur une <a href="https://github.com/elastic/rally-eventdata-track/blob/master/eventdata/challenges/bulk-update.json">charge de travail d'ingestion impliquant de nombreuses mises à jour</a>. La version d'Elasticsearch représente la dernière validation de l'unité&nbsp;7.0, qui n'était pas encore commercialisée à l'époque. Au bout de quelques jours, le test a échoué comme l'atteste le reporting des logs d'Elasticsearch&nbsp;:
<pre class="prettyprint">… 
Caused by: org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?)
</pre>Lors de la détection d'un index corrompu[<a href="#ref1" id="1">1</a>], Elasticsearch tente de le récupérer à l'aide d'une réplique. La plupart du temps, cette récupération s'effectue sans problème et la corruption est indétectable, sauf si l'utilisateur consulte les logs. Or, malgré la redondance des répliques, il est possible de perdre des données dans certains cas. Par conséquent, nous voulions comprendre la provenance de cette corruption et la manière dont nous pouvions résoudre le problème.
Tout d'abord, nous avons pensé que le problème venait d'une nouvelle fonctionnalité d'Elasticsearch, la <a href="/guide/en/elasticsearch/reference/7.8/xpack-ccr.html">CCR</a> ou les <a href="https://github.com/elastic/elasticsearch/issues/29530">suppressions partielles</a>. Toutefois, nous avons rapidement écarté cette possibilité, quand nous avons compris que nous pouvions reproduire la corruption de l'index à l'aide d'un seul cluster et en désactivant la fonctionnalité de CCR ou de suppressions partielles. Après avoir mené des recherches supplémentaires, nous avons compris que nous pouvions reproduire le problème dans des versions d'Elasticsearch antérieures au lancement de la version bêta de la CCR et des suppressions partielles. Comme le suggérait cette découverte, la CCR et les suppressions partielles n'étaient donc pas la cause de la corruption de l'index.
Cependant, nous avons noté que le test et les recherches ayant entraîné la corruption de l'index ont été menés sur Google Cloud Platform (GCP) à l'aide de l'<a href="https://console.cloud.google.com/marketplace/details/ubuntu-os-cloud/ubuntu-xenial">image de Xenial d'Unbuntu par Canonical</a> et de <a href="https://cloud.google.com/compute/docs/disks/local-ssd">SSD locaux</a> avec un noyau <code>4.15-0-*-gcp</code>. Nous avons remarqué que nous pouvions reproduire le problème dans un environnement nu avec les mêmes disques SSD et le même système d'exploitation (qui utilisent des <a href="https://wiki.ubuntu.com/Kernel/LTSEnablementStack">noyaux de compatibilité matérielle</a>&nbsp;4.13 ou 4.15).
Nous nous sommes alors intéressés à Elastic Cloud pour obtenir davantage de données sur le problème et son impact. Dans le cadre de tâches parallèles, nous avons écarté plusieurs causes suspectes en testant différents systèmes de fichiers, en désactivant RAID et, enfin, en utilisant un noyau à usage général plus récent. Aucune de ces actions n'a permis de résoudre le problème.
 <h2>Des recherches plus précises à l'aide du support technique de Google Cloud</h2>Nous avons créé un ensemble de <a href="https://gist.github.com/dliappis/54a9eedd5a272cf13b49ecaa85f87c7f">scripts de reproduction simples</a> afin de faciliter ce processus. Nous avons demandé à notre partenaire Google d'investiguer plus en détail les problèmes liés à l'environnement.
Le support technique de GCP a pu reproduire le problème de manière fiable à l'aide de ces scripts et d'un message d'erreur comme exemple&nbsp;:
<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>Lorsque le problème est survenu, le débit d'entrées et de sorties a dépassé 160&nbsp;Mo/s avec 16&nbsp;000&nbsp;entrées et sorties par seconde. Nous avons mené plusieurs tests et observé le même résultat à chaque fois. Étant donné qu'Elasticsearch utilise (par défaut) des <a href="/guide/en/elasticsearch/reference/7.8/index-modules-store.html#file-system">fichiers à la mémoire mappée pour une partie de son stockage</a>, nous avons pensé que certains accès de fichiers provoquaient des défaillances de pages encore plus importantes, ce qui augmentait le nombre d'opérations d'entrées et de sorties sur le disque et ainsi engendrait le problème. Pour diminuer l'apparition de la défaillance d'une page, nous avons essayé d'augmenter la mémoire des instances de GCP en la faisant passer de 32&nbsp;Go à 52&nbsp;Go. Grâce à cette mémoire accrue, le problème n'est pas réapparu et le débit des entrées et sorties s'élevait à seulement 50&nbsp;Mo/s avec 4&nbsp;000&nbsp;entrées et sorties par seconde.&nbsp;
Nous avons obtenu notre première avancée quand nous avons détecté une différence entre GCP et l'environnement nu. Le noyau de GCP était doté d'une fonctionnalité appelée <a href="https://lwn.net/Articles/738449/">couche de blocs multi-files d'attente</a> (blk_mq) qui était activée, contrairement au noyau de l'environnement nu[<a href="#ref2" id="2">2</a>]. Pour compliquer encore les choses, après une certaine version[<a href="#ref3" id="3">3</a>], il est impossible de désactiver blk_mq[<a href="#ref4" id="4">4</a>] sur l'image -gcp Ubuntu Linux via les options du noyau. Le support technique de GCP nous a montré comment désactiver blk_mq en exportant l'image Ubuntu de GCP et en la recréant sans la fonctionnalité guestOS VIRTIO_SCSI_MULTIQUEUE, qui active l'interface SCSI multi-files d'attente[<a href="#ref5" id="5">5</a>].
Nous avons obtenu une seconde avancée quand nous avons réussi à reproduire la corruption dans l'environnement nu seulement en activant explicitement la fonctionnalité <code>blk_mq</code> même en utilisant un noyau plus ancien comme <code>4.13.0-38-generic</code>. En outre, nous avons vérifié que les disques NVMe n'affichaient pas ce problème.
Nous savions donc que les corruptions survenaient lorsque les deux conditions suivantes étaient réunies&nbsp;:
<ul>
	<li>Les lecteurs SSD utilisent l'interface SCSI. (Les disques NVMe ne sont pas touchés.)</li>
	<li>La fonctionnalité blk_mq est activée.</li>
</ul>Outre l'utilisation exclusive de disques NVMe, le support technique de GCP a fait part de deux solutions temporaires supplémentaires, à savoir augmenter la mémoire des instances ou créer des images d'instances personnalisées en activant l'interface SCSI multi-files d'attente.
 <h2>Une aide bienvenue de la part de Canonical</h2>Bien qu'utiles, les solutions temporaires ne nous satisfaisaient pas&nbsp;:
<ul>
	<li>Le problème ne touchait pas que les images Ubuntu sur GCP. Il survenait aussi dans l'environnement nu.</li>
	<li>Nous ignorions quelle validation de noyau a engendré le problème.</li>
	<li>Nous ne savions pas si un nouveau noyau contenait déjà un correctif.</li>
</ul>Pour résoudre tous ces points encore en suspens, nous nous sommes tournés vers notre partenaire Canonical afin de mener une investigation plus poussée.
Canonical a lancé un test de grande ampleur en utilisant les <a href="https://gist.github.com/dliappis/54a9eedd5a272cf13b49ecaa85f87c7f">scripts de reproduction d'Elastic</a>, tout d'abord en confirmant que la corruption ne touchait pas les noyaux Ubuntu à usage général &gt;=5.0 utilisant des lecteurs SSD (avec soit des <a href="https://wiki.ubuntu.com/Kernel/Reference/IOSchedulers">planificateurs d'entrées et sorties multi-files d'attente</a> mq-deadline, soit aucun planificateur).
La prochaine étape a consisté à passer en revue les anciennes versions du noyau afin de trouver le delta minimum entre un noyau présentant la corruption et un autre non touché. À l'aide de plusieurs environnements de tests utilisés en parallèle (étant donné qu'un seul test peut prendre jusqu'à 5&nbsp;jours), Canonical a déterminé que <a href="https://kernel.ubuntu.com/~kernel-ppa/mainline/v4.19.8/">4.19.8</a> est le premier noyau Ubuntu à usage général à inclure les correctifs pour la corruption[<a href="#ref6" id="6">6</a>].
Les rétroportages manquants pour le noyau&nbsp;4.15.0 et les dérivés sont décrits dans le dispositif de suivi des bugs de Canonical sous la référence <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739">LP#1848739</a>. Pour en savoir plus à ce sujet, lisez <a href="https://lwn.net/Articles/774440/">cet article</a> et consultez <a href="https://bugzilla.kernel.org/show_bug.cgi?id=201685">cette page du site kernel.org</a>.
Après avoir confirmé qu'un noyau GCP corrigé, comprenant tous les rétroportages requis, <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/9">règle le problème</a>, Elastic et Canonical <a href="https://lists.ubuntu.com/archives/kernel-team/2019-December/106382.html">les ont fusionnés</a> dans le principal noyau&nbsp;4.15.0 Ubuntu. Par conséquent, tous les noyaux dérivés (y compris les noyaux -gcp) ont intégré les correctifs.
 <h2 id="conclusion">Conclusion</h2>Elastic s'est engagé à développer de nouvelles fonctionnalités de la Suite Elastic qui améliorent nos trois principales solutions. Pour atteindre cet objectif, plusieurs de nos talentueux ingénieurs et partenaires sont sur le pont en permanence. Par conséquent, dès la détection éventuelle de problèmes lors d'un test, Elastic et son réseau de partenaires proches mettront tout en œuvre pour vous garantir la meilleure expérience possible.
Grâce à notre collaboration étroite avec Google et Canonical, nous avons pu enquêter en profondeur sur le problème et proposer les noyaux Ubuntu HWE <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739">corrigés</a> suivants&nbsp;:
<ul>
	<li>AWS&nbsp;: lancement de <code>linux-aws - 4.15.0-1061.65</code> le <a href="https://changelogs.ubuntu.com/changelogs/pool/main/l/linux-aws/linux-aws_4.15.0-1061.65/changelog">21&nbsp;février&nbsp;2020</a>.</li>
	<li>Azure&nbsp;: lancement de <code>linux-azure - 4.15.0-1066.71</code> le <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/12">6&nbsp;janvier&nbsp;2020</a>.</li>
	<li>GCP&nbsp;: lancement de <code>linux-gcp - 4.15.0-1053.57</code> le <a href="https://changelogs.ubuntu.com/changelogs/pool/main/l/linux-gcp/linux-gcp_4.15.0-1053.57/changelog">5&nbsp;février&nbsp;2020</a>.</li>
	<li>Générique&nbsp;: lancement de <code>linux-gcp - 4.15.0-88.88</code> le <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/15">17&nbsp;février&nbsp;2020</a>.</li>
</ul>Grâce aux noyaux ci-dessus ou à des versions plus récentes, vous éviterez toute corruption quand vous utiliserez des disques SSD et activerez la fonctionnalité blk_mq sur l'interface SCSI.
Vous vous demandez comment protéger votre environnement contre cette corruption de données&nbsp;? Notre conseil&nbsp;: essayez <a href="/fr/elasticsearch/service">Elastic Cloud</a>. Nos utilisateurs sont déjà protégés.
 <h2>Notes</h2>[<a href="#1" id="ref1">1</a>] Elasticsearch ne vérifie pas en permanence la somme de contrôle, car cette opération est coûteuse. Certaines actions peuvent entraîner une vérification de la somme de contrôle plus régulière, comme la relocalisation des partitions ou lors de la prise d'un snapshot. Ainsi, les corruptions silencieuses sous-jacentes sont identifiées, même si ces actions les génèrent.
[<a href="#2" id="ref2">2</a>] Pour s'assurer de l'activation de la fonctionnalité blk_mq sur les disques de mappage des périphériques ou SCSI, utilisez <code>cat /sys/module/{scsi_mod,dm_mod}/parameters/use_blk_mq</code>.
[<a href="#3" id="ref3">3</a>] Après <a href="https://patchwork.kernel.org/patch/10198305">https://patchwork.kernel.org/patch/10198305</a>, la fonctionnalité blk_mq est activée pour les périphériques SCSI et ne peut pas être désactivée via les options du noyau. Ce correctif a été rétroporté sur le noyau <a href="https://launchpad.net/ubuntu/+source/linux-gcp/4.15.0-1010.10~16.04.1">linux-gcp</a> d'Ubuntu.
[<a href="#4" id="ref4">4</a>] Pour désactiver la fonctionnalité blk_mq, les paramètres suivants doivent être configurés dans le noyau, par exemple à l'aide de grub&nbsp;: <code>GRUB_CMDLINE_LINUX="scsi_mod.use_blk_mq=N dm_mod.use_blk_mq=N"</code>. Pour l'activer, configurez ces options sur N en gardant à l'esprit la note&nbsp;[3].
[<a href="#5" id="ref5">5</a>] Voici des exemples de commandes gcloud permettant de désactiver la fonctionnalité guestOS VIRTIO_SCSI_MULTIQUEUE en recréant l'image Ubuntu&nbsp;:
<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>] Rétroportages
<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 et Google s'associent pour éviter la corruption de données sous Linux

Pourquoi exécuter Elasticsearch sur des disques SSD avec les paramètres TRIM par défaut peut diminuer la performance et comment résoudre ce problème.

trim-elasticsearch-ssd.jpg

is-your-elasticsearch-trimmed-ssd.jpg

Is your Elasticsearch "Trimmed"?

Est-ce que votre Elasticsearch est « trimmé » ?

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

En confirmant votre envoi, vous reconnaissez que vous avez lu et que vous acceptez nos <a href="/fr/legal/elastic-cloud-account-terms" target="_self">Conditions générales d'utilisation</a>, et vous acceptez de recevoir les <a href="/fr/legal/privacy-statement#how-we-use-the-information" target="_self">types de notification sélectionnés</a> à l'adresse que vous avez fournie plus haut. Pour en savoir plus ou pour revenir sur votre décision (possible à tout moment), consultez la <a href="/fr/legal/privacy-statement/" target="_self">Déclaration de confidentialité d'Elastic</a>.

By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-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.By submitting this form, I agree to Elastic sharing my contact information with Google Cloud. I also agree to Elastic giving my information to the vendor for the purpose of shipping my food package.

GDPR Text + Google Cloud

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

En confirmant votre envoi, vous reconnaissez que vous avez lu et que vous acceptez nos <a href="/fr/legal/serverless-preview-terms" target="_self">Conditions générales d'utilisation</a>, et vous permettez à Elastic de <a href="/fr/legal/privacy-statement#how-we-use-the-information" target="_self">vous contacter</a> à propos de produits et services similaires en utilisant les informations que vous avez fournies plus haut. Pour en savoir plus ou pour revenir sur votre décision (possible à tout moment), consultez la <a href="/fr/legal/privacy-statement/" target="_self">Déclaration de confidentialité d'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

En envoyant votre demande d'inscription, vous acceptez les <a href="/fr/agreements/global/cloud-services-monthly" rel="nofollow">conditions générales d'utilisation d'Elastic Cloud</a>. Vos données personnelles seront traitées conformément à la <a href="/fr/legal/privacy-statement">déclaration de confidentialité d'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

En confirmant votre envoi, vous reconnaissez que vous avez lu et que vous acceptez nos <a href="/fr/legal/terms-of-use" target="_self">Conditions générales d'utilisation</a>, et vous permettez à Elastic de <a href="/fr/legal/privacy-statement#how-we-use-the-information" target="_self">vous contacter</a> à propos de produits et services similaires en utilisant les informations que vous avez fournies plus haut. Pour en savoir plus ou pour revenir sur votre décision (possible à tout moment), consultez la <a href="/fr/legal/privacy-statement/" target="_self">Déclaration de confidentialité d'Elastic</a>.

Explore similar demos

Overview

You'll also receive an email with related content.

You'll also receive an email with related content

Nous vous enverrons plus de contenu susceptible de vous intéresser.

Speakers

Close

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.

Le contenu de cette page n'est pas disponible dans la langue sélectionnée. Chez Elastic, nous mettons tout en œuvre pour vous proposer du contenu dans différentes langues. En attendant, nous vous remercions de votre patience !

See more insights

Articles by

Author

Learn more

Watch now (no PT)

Watch now

See all top stories

All (no PT translation)

Contact information

Press Release

Share on Reddit

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

Voir à quelle heure débute le webinar dans mon fuseau horaire

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

Si vous ne pouvez pas vous libérer le jour J, inscrivez-vous et nous vous enverrons l'enregistrement. Vous recevrez aussi un e-mail contenant des ressources connexes.

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

Read less

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

Nous vous remercions de votre inscription. Vous allez recevoir un e-mail de confirmation.

Author

Articles by Dimitrios Liappis

Software Engineer, Elastic

Benchmark-driven optimizations — How we pushed scalability to the next level in Elasticsearch 8

Canonical, Elastic et Google s'associent pour éviter la corruption de données sous Linux

Est-ce que votre Elasticsearch est « trimmé » ?