Durante la prueba de una característica nueva del Elastic Stack descubrimos un error que afectaba discos SSD en ciertos kernels de Linux. Conoce cómo la investigación involucró una gran colaboración con dos socios cercanos: Google Cloud y Canonical.

En Elastic innovamos y lanzamos características nuevas de forma constante.&nbsp;Mientras lanzamos características nuevas, también trabajamos para asegurarnos de que se hayan probado y sean sólidas y confiables; y a veces encontramos errores u otros problemas.
Durante la prueba de una característica nueva descubrimos un error de kernel de Linux que afectaba los discos SSD en ciertos kernels de Linux. En este blog abarcaremos la historia en torno a la investigación y cómo involucró una gran colaboración con dos socios cercanos: Google&nbsp;Cloud y Canonical.
La investigación resultó en el lanzamiento de nuevos kernels de Ubuntu <a href="#conclusion">para abordar el problema</a>.
 <h2>Cómo comenzó</h2>En febrero de&nbsp;2019, ejecutamos una <a href="/es/blog/benchmarking-elasticsearch-cross-cluster-replication">prueba de estabilidad de 10&nbsp;días</a> para la <a href="/guide/en/elasticsearch/reference/7.8/xpack-ccr.html">replicación entre clusters (CCR)</a> con la <a href="https://esrally.readthedocs.io/en/stable/">herramienta de evaluación comparativa de Elasticsearch, Rally</a>, usando una <a href="https://github.com/elastic/rally-eventdata-track/blob/master/eventdata/challenges/bulk-update.json">carga de trabajo de ingesta y con muchas actualizaciones</a>. La versión de Elasticsearch era la publicada más recientemente de la rama&nbsp;7.0 pendiente de lanzamiento (en ese entonces). Tras varios días, la prueba falló y en los logs de Elasticsearch se reportaba lo siguiente:
<pre class="prettyprint">… 
Caused by: org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?)
</pre>Al detectar[<a href="#ref1" id="1">1</a>] el daño del índice, Elasticsearch intentará recuperarse a partir de una réplica. En muchos casos la recuperación no presenta problemas y, a menos que el usuario revise los logs, el daño pasará desapercibido. Incluso con la redundancia que ofrecen las réplicas, es posible que se produzca la pérdida de datos en ciertas circunstancias. Por lo tanto, queríamos comprender por qué se producía el daño y explorar cómo podíamos remediar el problema.
Al principio, sospechábamos que una característica nueva de Elasticsearch, <a href="/guide/en/elasticsearch/reference/7.8/xpack-ccr.html">CCR</a>/<a href="https://github.com/elastic/elasticsearch/issues/29530">eliminaciones parciales</a>, causaba el problema. Descartamos rápidamente esta sospecha, sin embargo, cuando descubrimos que podíamos reproducir el daño en el índice usando un solo cluster y deshabilitando la característica de CCR/eliminaciones parciales. Después de más investigación, descubrimos que podíamos reproducir el problema en versiones anteriores de Elasticsearch previas al lanzamiento beta de CCR/eliminaciones parciales, lo que sugería que las CCR/eliminaciones parciales no eran la causa del daño en el índice.
Sin embargo, sí notamos que las pruebas e investigación que llevaron al daño en el índice se habían realizado en Google&nbsp;Cloud&nbsp;Platform&nbsp;(GCP) usando la <a href="https://console.cloud.google.com/marketplace/details/ubuntu-os-cloud/ubuntu-xenial">imagen Ubuntu Xenial de Canonical</a> y <a href="https://cloud.google.com/compute/docs/disks/local-ssd">SSD locales</a> con el kernel <code>4.15-0-*-gcp</code> y que no podíamos reproducir el problema en un entorno de metal expuesto con el mismo sistema operativo y discos SSD (ya sea con <a href="https://wiki.ubuntu.com/Kernel/LTSEnablementStack">kernels HWE</a> 4.13 o 4.15).
Nuestra atención se centró inmediatamente en Elastic&nbsp;Cloud para obtener más datos sobre el problema y su impacto. En un flujo de trabajo paralelo, descartamos varias sospechas probando diferentes sistemas de archivos, deshabilitando RAID y usando por último un kernel principal más nuevo. Pero nada de esto hizo desaparecer los daños.
 <h2>Profundizando con el soporte de Google&nbsp;Cloud</h2>En este punto, creamos un conjunto de <a href="https://gist.github.com/dliappis/54a9eedd5a272cf13b49ecaa85f87c7f">scripts de fácil reproducción</a> para facilitar las reproducciones e involucramos a nuestro socio Google para comenzar a investigar en mayor profundidad los problemas del entorno.
El soporte de GCP logró reproducir el problema de forma confiable usando los scripts proporcionados, con un mensaje de error de ejemplo:
<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>Durante el período en el que ocurrió el problema, el rendimiento de E/S superó los 160&nbsp;MB/s con 16&nbsp;000&nbsp;IOPS. Esta observación fue coherente en varias pruebas. Como Elasticsearch (de forma predeterminada) usa <a href="/guide/en/elasticsearch/reference/7.8/index-modules-store.html#file-system">archivos mapeados en memoria en parte de su almacenamiento</a>, sospechábamos que algunos accesos a los archivos causaban fallas de la página más importantes, lo que aumentaba las operaciones de E/S en el disco y desencadenaba el problema en última instancia. Para reducir la ocurrencia de una falla de la página, intentamos aumentar la memoria de las instancias de GCP de 32&nbsp;GB a 52&nbsp;GB. Con el aumento de la memoria, el problema ya no ocurría y el rendimiento de E/S era de 50&nbsp;MB/s con 4000&nbsp;IOPS.&nbsp;
El primer descubrimiento sucedió cuando observamos una diferencia entre GCP y el entorno de metal expuesto: el kernel de GCP tenía una característica denominada <a href="https://lwn.net/Articles/738449/">capa de bloqueo multicolas</a> (blk_mq) habilitada, que el kernel de metal expuesto no[<a href="#ref2" id="2">2</a>]. Para complicar aún más las cosas, después de una versión determinada[<a href="#ref3" id="3">3</a>] ya no es posible deshabilitar blk_mq[<a href="#ref4" id="4">4</a>] en la imagen de Ubuntu Linux -gcp a través de las opciones de kernel. El soporte de GCP nos mostró cómo deshabilitar blk_mq exportando la imagen de Ubuntu de GCP y recreándola sin la característica VIRTIO_SCSI_MULTIQUEUE para SO invitado, que habilita SCSI multicola[<a href="#ref5" id="5">5</a>].
El segundo descubrimiento fue lograr reproducir el daño en metal expuesto: fue posible únicamente habilitando explícitamente <code>blk_mq</code> incluso usando un kernel más antiguo: <code>4.13.0-38-generic</code>. También verificamos que los discos NVMe no muestran este problema.
En este punto sabíamos que los daños ocurren cuando se cumplen las dos condiciones siguientes:
<ul>
	<li>Unidades SSD con interfaz SCSI (los discos NVMe no se ven afectados)</li>
	<li>blk_mq habilitado</li>
</ul>El soporte de GCP compartió dos soluciones alternativas adicionales (además de usar solo discos NVMe): aumentar la memoria de la instancia o crear imágenes de la instancia personalizadas con la opción SCSI multicola deshabilitada.
 <h2>Canonical se une al esfuerzo</h2>Si bien teníamos algunas soluciones alternativas, aún no estábamos satisfechos:
<ul>
	<li>El problema no era específico de las imágenes de Ubuntu en GCP, también sucedía en metal expuesto.</li>
	<li>No sabíamos cuál publicación de kernel introdujo el problema.</li>
	<li>No sabíamos si ya había una solución disponible en un kernel más nuevo.</li>
</ul>Para abordar estos puntos, recurrimos a nuestro socio Canonical para que profundizara un poco más.
Canonical inició un gran esfuerzo de pruebas usando <a href="https://gist.github.com/dliappis/54a9eedd5a272cf13b49ecaa85f87c7f">scripts de reproducción de Elastic</a>, primero confirmó que el daño no ocurría en kernels principales de Ubuntu &gt;=5.0 con unidades SSD (sin usar <a href="https://wiki.ubuntu.com/Kernel/Reference/IOSchedulers">programadores de E/S multicola</a> o usando los mq-deadline).
El paso siguiente fue retroceder en las versiones de kernel para encontrar el delta mínimo entre un kernel que mostraba daño y uno que no. En entornos de pruebas en paralelo múltiples (dado que una ejecución de prueba completa puede tomar hasta cinco días), Canonical descubrió que el kernel principal de Ubuntu <a href="https://kernel.ubuntu.com/~kernel-ppa/mainline/v4.19.8/">4.19.8</a> es el primero que incluye soluciones para el daño[<a href="#ref6" id="6">6</a>].
Los backports faltantes del kernel 4.15.0 y derivados se describen en el rastreador de errores de Canonical, en <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739">LP#1848739</a>, y se incluyen más detalles en <a href="https://lwn.net/Articles/774440/">este artículo</a> y en el <a href="https://bugzilla.kernel.org/show_bug.cgi?id=201685">error de kernel.org</a>.
Después de que Elastic y Canonical confirmaran que un kernel de GCP con parche y todos los backports necesarios <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/9">soluciona el problema</a>, se <a href="https://lists.ubuntu.com/archives/kernel-team/2019-December/106382.html">combinaron</a> en el kernel principal de Ubuntu 4.15.0 y todos los kernels derivados (incluido -gcp) recibieron las soluciones.
 <h2 id="conclusion">Conclusión</h2>Elastic está comprometido con desarrollar características del Elastic Stack nuevas que mejoren cada una de nuestras tres soluciones primarias. Estos esfuerzos cuentan con el soporte de algunos socios e ingenieros muy talentosos que siempre están atentos para que no debas preocuparte. Cuando encontramos problemas (si lo hacemos) durante las pruebas, debes saber que Elastic y su red de socios cercanos no descansarán hasta asegurarse de que tengas la mejor experiencia posible.
Gracias a nuestra estrecha colaboración con Google y Canonical, pudimos llegar a la raíz del problema, lo que llevó al lanzamiento de los siguientes kernels de HWE Ubuntu <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739">solucionados</a>:
<ul>
	<li>AWS: a partir de <code>linux-aws - 4.15.0-1061.65</code> lanzado el <a href="https://changelogs.ubuntu.com/changelogs/pool/main/l/linux-aws/linux-aws_4.15.0-1061.65/changelog">21 de febrero de 2020</a></li>
	<li>Azure: a partir de <code>linux-azure - 4.15.0-1066.71</code> lanzado el <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/12">6 de enero de 2020</a></li>
	<li>GCP: a partir de <code>linux-gcp - 4.15.0-1053.57</code> lanzado el <a href="https://changelogs.ubuntu.com/changelogs/pool/main/l/linux-gcp/linux-gcp_4.15.0-1053.57/changelog">5 de febrero de 2020</a></li>
	<li>Genérico: a partir de <code>linux - 4.15.0-88.88</code> lanzado el <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/15">17 de febrero de 2020</a></li>
</ul>El uso de las versiones mencionadas anteriormente o más nuevas evitará daños cuando se usen discos SSD junto con la opción SCSI blk-mq habilitada.
Si no quieres preocuparte por si tu entorno está protegido de los daños a los datos, prueba nuestro <a href="/es/elasticsearch/service">Elastic Cloud</a>; nuestros usuarios ya están protegidos.
 <h2>Notas al pie</h2>[<a href="#1" id="ref1">1</a>] Elasticsearch no verifica las sumas de comprobación todo el tiempo debido a que es una operación costosa. Ciertas acciones pueden desencadenar la verificación de sumas de comprobación con más frecuencia, como la reubicación de shards o mientras se realiza un snapshot, lo que hará que los daños silenciosos subyacentes aparezcan si fueron causados por estas acciones.
[<a href="#2" id="ref2">2</a>] Para comprobar si se usa blk_mq para SCSI o discos de mapeo de dispositivos, usa <code>cat /sys/module/{scsi_mod,dm_mod}/parameters/use_blk_mq</code>.
[<a href="#3" id="ref3">3</a>] Después de que se haya forzado <a href="https://patchwork.kernel.org/patch/10198305">https://patchwork.kernel.org/patch/10198305</a> blk_mq en dispositivos SCSI y no se pueda deshabilitar a través de las opciones del kernel. Este parche se aplicó en backport en Ubuntu <a href="https://launchpad.net/ubuntu/+source/linux-gcp/4.15.0-1010.10~16.04.1">linux-gcp</a>.
[<a href="#4" id="ref4">4</a>] Para deshabilitar blk_mq, se deben pasar los parámetros siguientes al kernel, por ejemplo, a través de grub: <code>GRUB_CMDLINE_LINUX="scsi_mod.use_blk_mq=N dm_mod.use_blk_mq=N"</code>. La habilitación se puede hacer configurando estas opciones como N, pero ten cuidado con [3].
[<a href="#5" id="ref5">5</a>] Comandos de ejemplo de gcloud para deshabilitar la característica VIRTIO_SCSI_MULTIQUEUE para SO invitado recreando la imagen de Ubuntu:
<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>

blog-banner-cloud-gcp-region.png

blog-thumb-cloud-gcp-region.png

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

Canonical, Elastic y Google se unen para evitar el daño de datos en Linux

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Christopher Newcomer (Canonical)

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

Al enviar, confirma que ha leído y acepta nuestras <a href="/es/legal/elastic-cloud-account-terms" target="_self">Condiciones de servicio</a>, y que acepta recibir las <a href="/es/legal/privacy-statement#how-we-use-the-information" target="_self">comunicaciones seleccionadas</a> en los detalles de contacto que proporcionó anteriormente. Consulte la <a href="/es/legal/privacy-statement/" target="_self">Declaración de privacidad de Elastic</a> para obtener más información o para cancelar su suscripción en cualquier momento.

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

Al enviar, confirma que ha leído y acepta nuestras <a href="/es/legal/serverless-preview-terms" target="_self">Condiciones de servicio</a>, y que Elastic puede <a href="/es/legal/privacy-statement#how-we-use-the-information" target="_self">ponerse en contacto con usted</a> acerca de nuestros productos y servicios relacionados. Consulte la <a href="/es/legal/privacy-statement/" target="_self">Declaración de privacidad de Elastic</a> para obtener más información o para cancelar su suscripción en cualquier momento.

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

Al enviar esta información, aceptas los <a href="/es/agreements/global/cloud-services-monthly" rel="nofollow">Términos de servicio de Elastic</a>. Los datos personales se procesarán de conformidad con la <a href="/es/legal/privacy-statement">declaración de privacidad de 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

Al enviar, confirma que ha leído y acepta nuestras <a href="/es/legal/terms-of-use" target="_self">Condiciones de servicio</a>, y que Elastic puede <a href="/es/legal/privacy-statement#how-we-use-the-information" target="_self">ponerse en contacto con usted</a> acerca de nuestros productos y servicios relacionados. Consulte la <a href="/es/legal/privacy-statement/" target="_self">Declaración de privacidad de Elastic</a> para obtener más información o para cancelar su suscripción en cualquier momento.

Hosted by

All Solutions

Follow us on Youtube

Watch now (no PT)

Articles by

Share by Email

Filters

All (no PT translation)

Contact information

See when this webinar starts in my time zone

Ver cuándo comienza este webinar en mi zona horaria

Thank you for your interest!

Register to Attend

Small image for

Register to Watch

Continue reading

Featured webinar

What to explore next...

Reset all

Load more press releases

Sign In to Attend

Share

Upcoming webinar

Learn more

Search Integrations

Share on Reddit

Share on Twitter

Share on Facebook

Load more news

View more posts

On-demand webinar

Follow us on Facebook

Author

Press Release

You'll also receive an email with related content.

You'll also receive an email with related content

Además, te enviaremos contenidos relevantes

Print

Contact Info

Overview

Video for

Read less

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

El contenido de esta página no está disponible en el idioma seleccionado. Elastic está trabajando para garantizar que el contenido esté disponible en varios idiomas.Gracias por tu paciencia mientras trabajamos.

Register now

Share this story

See All Posts

See all top stories

View next

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

¿No puedes asistir? Regístrate y te enviaremos la grabación. También recibirás un correo electrónico con contenido relacionado.

Follow us on LinkedIn

Highlights

Explore similar demos

Follow us on Twitter

Share on LinkedIn

Load More

See more insights

Speakers

Close

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

Gracias por registrarte. Te enviaremos un correo electrónico de confirmación pronto.

Author

Articles by Christopher Newcomer

Canonical, Elastic y Google se unen para evitar el daño de datos en Linux

Sign up for Elastic Cloud free trial