Ao testar um novo recurso do Elastic Stack, descobrimos uma falha no kernel do Linux que afetava discos SSD em certos kernels do Linux. Saiba como a investigação envolveu uma grande colaboração com dois parceiros próximos: Google Cloud e Canonical.

Na Elastic, estamos constantemente inovando e lançando novos recursos.&nbsp;Enquanto lançamos novos recursos, também trabalhamos para garantir que eles sejam testados, sólidos e confiáveis — e, às vezes, encontramos falhas ou outros problemas.
Ao testar um novo recurso, descobrimos uma falha no kernel do Linux que afetava discos SSD em certos kernels do Linux. Neste artigo do blog, vamos contar a história da investigação e como ela envolveu uma grande colaboração com dois parceiros próximos: Google Cloud e Canonical.
A investigação resultou no lançamento de novos kernels do Ubuntu para <a href="#conclusion">resolver o problema</a>.
 <h2>Como tudo começou</h2>Em fevereiro de 2019, realizamos um <a href="/pt/blog/benchmarking-elasticsearch-cross-cluster-replication">teste de estabilidade de 10 dias</a> para <a href="/guide/en/elasticsearch/reference/7.8/xpack-ccr.html">replicação entre clusters (CCR)</a> com a <a href="https://esrally.readthedocs.io/en/stable/">ferramenta de benchmark padrão do Elasticsearch, Rally</a>, usando uma <a href="https://github.com/elastic/rally-eventdata-track/blob/master/eventdata/challenges/bulk-update.json">carga de trabalho de ingestão com uso intenso de atualizações</a>. A versão do Elasticsearch era o commit mais recente do branch 7.0 não lançado (naquela época). Depois de alguns dias, o teste falhou com o relatório de logs do Elasticsearch:
<pre class="prettyprint">… 
Caused by: org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?)
</pre>Ao detectar[<a href="#ref1" id="1">1</a>] um índice corrompido, o Elasticsearch tenta se recuperar com uma réplica. Em muitos casos, a recuperação é perfeita e, a menos que o usuário analise os logs, a corrupção passa despercebida. Mesmo com a redundância oferecida pelas réplicas, a perda de dados é possível em certas circunstâncias. Portanto, queríamos entender por que a corrupção estava ocorrendo e explorar como poderíamos corrigir o problema.
A princípio, suspeitamos que um novo recurso do Elasticsearch, <a href="/guide/en/elasticsearch/reference/7.8/xpack-ccr.html">CCR</a>/<a href="https://github.com/elastic/elasticsearch/issues/29530">exclusões reversíveis</a>, estivesse causando o problema. Porém, essa suspeita foi rapidamente descartada quando descobrimos que poderíamos reproduzir a corrupção do índice usando um único cluster e desabilitando o recurso CCR/exclusões reversíveis. Após uma pesquisa adicional, descobrimos que conseguíamos reproduzir o problema em versões anteriores do Elasticsearch que precederam o lançamento beta do recurso CCR/exclusões reversíveis, sugerindo que CCR/exclusões reversíveis não eram a causa da corrupção do índice.
Observamos, no entanto, que os testes e pesquisas que resultaram na corrupção do índice tinham sido conduzidos no Google Cloud Platform (GCP) usando a <a href="https://console.cloud.google.com/marketplace/details/ubuntu-os-cloud/ubuntu-xenial">imagem Ubuntu Xenial da Canonical</a> e <a href="https://cloud.google.com/compute/docs/disks/local-ssd">SSDs locais</a> com kernel <code>4.15-0-*-gcp</code> e que não foi possível reproduzir o problema em um ambiente bare metal com o mesmo sistema operacional e discos SSD (usando <a href="https://wiki.ubuntu.com/Kernel/LTSEnablementStack">kernels HWE</a> 4.13 ou 4.15).
Nossa atenção imediatamente se voltou para o Elastic Cloud para obter mais dados sobre o problema e conhecer seu impacto. Em um fluxo de trabalho paralelo, descartamos várias suspeitas testando diferentes sistemas de arquivos, desabilitando o RAID e, finalmente, usando um kernel de linha principal mais recente; nenhuma dessas tentativas eliminou as corrupções.
 <h2>Exploração mais a fundo com o suporte do Google Cloud</h2>Nesse ponto, criamos um conjunto de <a href="https://gist.github.com/dliappis/54a9eedd5a272cf13b49ecaa85f87c7f">scripts de reprodução simples</a> para facilitar as reproduções e envolvemos nosso parceiro Google para começar a analisar problemas do ambiente mais profundamente.
O suporte do GCP conseguiu reproduzir o problema de maneira confiável usando os scripts fornecidos, com um exemplo de mensagem de erro:
<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 o período em que o problema ocorreu, a taxa de transferência de E/S ficou acima de 160 MB/s com 16 mil IOPS. Essa observação foi consistente em vários testes. Como o Elasticsearch (por padrão) usa <a href="/guide/en/elasticsearch/reference/7.8/index-modules-store.html#file-system">arquivos mapeados na memória para parte de seu armazenamento</a>, suspeitamos que alguns acessos a arquivos estivessem causando mais falhas de página importantes, resultando em um aumento nas operações de E/S para o disco e desencadeando o problema. Para reduzir a ocorrência de uma falha de página, tentamos aumentar a memória das instâncias do GCP de 32 GB para 52 GB. Com o aumento da memória, o problema não ocorreu mais, e a taxa de transferência de E/S ficou em 50 MB/s com 4 mil IOPS.&nbsp;
A primeira descoberta aconteceu quando observamos uma diferença entre o GCP e o ambiente bare metal: o kernel do GCP tinha um recurso chamado <a href="https://lwn.net/Articles/738449/">camada de bloqueio de várias filas</a> (blk_mq) habilitado, que o kernel do bare metal não tinha[<a href="#ref2" id="2">2</a>]. Para complicar ainda mais, após uma determinada versão[<a href="#ref3" id="3">3</a>] não é mais possível desabilitar o blk_mq[<a href="#ref4" id="4">4</a>] na imagem Linux Ubuntu -gcp por meio das opções do kernel. O suporte do GCP nos mostrou como desabilitar o blk_mq exportando a imagem Ubuntu do GCP e recriá-la sem o recurso VIRTIO_SCSI_MULTIQUEUE guestOS, que habilita o SCSI de várias filas[<a href="#ref5" id="5">5</a>].
A segunda descoberta foi conseguir reproduzir a corrupção no bare metal: isso se tornou possível apenas habilitando explicitamente o <code>blk_mq</code>, mesmo usando um kernel mais antigo: <code>4.13.0-38-generic</code>. Também verificamos que os discos NVMe não apresentavam esse problema.
Nesse ponto, sabíamos que as corrupções aconteciam quando as duas condições a seguir eram atendidas:
<ul>
	<li>Unidades SSD usando a interface SCSI (discos NVMe não são afetados)</li>
	<li>blk_mq habilitado</li>
</ul>O suporte do GCP compartilhou duas soluções alternativas adicionais (além de usar apenas discos NVMe): aumentar a memória da instância ou criar imagens de instância customizadas com SCSI de várias filas desabilitado.
 <h2>A Canonical junta-se ao esforço</h2>Embora tivéssemos algumas soluções alternativas, ainda não estávamos satisfeitos:
<ul>
	<li>O problema não era específico das imagens Ubuntu no GCP; ele também aconteceu no bare metal.</li>
	<li>Não sabíamos qual commit do kernel introduziu o problema.</li>
	<li>Não sabíamos se já havia uma correção disponível em um kernel mais recente.</li>
</ul>Para abordar esses pontos, entramos em contato com nossa parceira Canonical para nos aprofundarmos um pouco mais.
A Canonical iniciou um grande esforço de teste usando os <a href="https://gist.github.com/dliappis/54a9eedd5a272cf13b49ecaa85f87c7f">scripts de reprodução da Elastic</a>, primeiro confirmando que a corrupção não ocorreu nos kernels de linha principal do Ubuntu iguais ou superiores ao 5.0 com unidades SSD (usando <a href="https://wiki.ubuntu.com/Kernel/Reference/IOSchedulers">programadores de E/S de várias filas</a> mq-deadline ou nenhum).
A próxima etapa foi retroceder nas versões do kernel para encontrar o delta mínimo entre um kernel que exibe corrupção e outro que não exibe. Usando vários ambientes de teste paralelos (já que um teste completo pode levar até cinco dias), a Canonical descobriu que o 4.19.8 foi o primeiro kernel de linha principal do Ubuntu a incluir as correções de corrupção[<a href="#ref6" id="6">6</a>].
Os backports ausentes para o kernel 4.15.0 e derivados são descritos no controle de falhas da Canonical em <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739">LP#1848739</a>, e mais detalhes podem ser encontrados <a href="https://lwn.net/Articles/774440/">neste artigo</a> e na <a href="https://bugzilla.kernel.org/show_bug.cgi?id=201685">ocorrência de falha do kernel.org</a>.
Depois que a Elastic e a Canonical confirmaram que um kernel GCP com patch incluindo todos os backports necessários <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/9">corrigia o problema</a>, eles <a href="https://lists.ubuntu.com/archives/kernel-team/2019-December/106382.html">foram mesclados</a> ao kernel principal do Ubuntu 4.15.0 e, consequentemente, todos os kernels derivados (incluindo o -gcp) receberam as correções.
 <h2 id="conclusion">Conclusão</h2>A Elastic está empenhada em desenvolver novos recursos do Elastic Stack que aprimorem cada uma de nossas três soluções principais. Esses esforços têm o suporte de engenheiros e parceiros talentosos que estão sempre vigilantes para que você não precise se preocupar. Se e quando encontrarmos problemas durante os testes, saiba que a Elastic e sua rede de parceiros próximos não medirão esforços para garantir que você tenha a melhor experiência possível.
Por meio de nossa estreita colaboração com o Google e a Canonical, fomos capazes de chegar ao fundo do problema, o que levou ao lançamento dos seguintes kernels HWE do Ubuntu <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739">corrigidos</a>:
<ul>
	<li>AWS: a partir do <code>linux-aws - 4.15.0-1061.65</code> lançado em <a href="https://changelogs.ubuntu.com/changelogs/pool/main/l/linux-aws/linux-aws_4.15.0-1061.65/changelog">21 de fevereiro de 2020</a></li>
	<li>Azure: a partir do <code>linux-azure - 4.15.0-1066.71</code> lançado em <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/12">6 de janeiro de 2020</a></li>
	<li>GCP: a partir do <code>linux-gcp - 4.15.0-1053.57</code> lançado em <a href="https://changelogs.ubuntu.com/changelogs/pool/main/l/linux-gcp/linux-gcp_4.15.0-1053.57/changelog">5 de fevereiro de 2020</a></li>
	<li>Genérico: a partir do <code>linux - 4.15.0-88.88</code> lançado em <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/15">17 de fevereiro de 2020</a></li>
</ul>O uso das versões acima ou mais recentes evitará corrupções quando discos SSD forem usados junto com o blk-mq com SCSI habilitado.
Se você não quer se preocupar se seu ambiente está protegido contra essa corrupção de dados, experimente o <a href="/pt/elasticsearch/service">Elastic Cloud</a> — nossos usuários já estão protegidos.
 <h2>Notas de rodapé</h2>[<a href="#1" id="ref1">1</a>] O Elasticsearch não verifica os checksums o tempo todo, pois é uma operação cara. Certas ações podem disparar a verificação de checksum com mais frequência, como a realocação de shard ou a geração de um snapshot, fazendo com que corrupções silenciosas subjacentes pareçam ter sido causadas por essas ações.
[<a href="#2" id="ref2">2</a>] Para verificar se o blk_mq está em uso para discos SCSI ou de mapeamento de dispositivos, use <code>cat /sys/module/{scsi_mod,dm_mod}/parameters/use_blk_mq</code>
[<a href="#3" id="ref3">3</a>] Após <a href="https://patchwork.kernel.org/patch/10198305">https://patchwork.kernel.org/patch/10198305</a>, o blk_mq é forçado para dispositivos SCSI e não pode ser desabilitado por meio das opções do kernel. Foi feito o backport desse patch no 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 desabilitar o blk_mq, os seguintes parâmetros precisam ser passados para o kernel, por exemplo, via grub: <code>GRUB_CMDLINE_LINUX="scsi_mod.use_blk_mq=N dm_mod.use_blk_mq=N"</code>. A habilitação pode ser feita definindo essas opções como N, mas cuidado com [3].
[<a href="#5" id="ref5">5</a>] Exemplo de comandos gcloud para desabilitar o recurso VIRTIO_SCSI_MULTIQUEUE guestOS recriando a imagem 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>

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 e Google unem-se para evitar a corrupção de dados no Linux

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Lynn Asiimwe (Google Cloud)

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

Ao enviar a confirmação, você reconhece que leu e concorda com nossos <a href="/pt/legal/elastic-cloud-account-terms" target="_self">Termos de Serviço</a> e também concorda em receber <a href="/pt/legal/privacy-statement#how-we-use-the-information" target="_self">comunicações especiais</a> por meio dos dados de contato que forneceu acima. Consulte a <a href="/pt/legal/privacy-statement/" target="_self">Declaração de Privacidade da Elastic</a> para saber mais detalhes ou para cancelar a qualquer 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

Ao enviar a confirmação, você reconhece que leu e concorda com nossos <a href="/pt/legal/serverless-preview-terms" target="_self">Termos de Serviço</a> e que a Elastic pode <a href="/pt/legal/privacy-statement#how-we-use-the-information" target="_self">entrar em contato com você</a> para divulgar nossos produtos e serviços relacionados usando os dados que você forneceu acima. Consulte a <a href="/pt/legal/privacy-statement/" target="_self">Declaração de Privacidade da Elastic</a> para saber mais detalhes ou para cancelar a qualquer 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

Ao enviar, você concorda com os <a href="/pt/agreements/global/cloud-services-monthly" rel="nofollow">Termos de Serviço do Elastic Cloud</a>. Seus dados pessoais serão tratados de acordo com a <a href="/pt/legal/privacy-statement">Declaração de Privacidade da 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

Ao enviar a confirmação, você reconhece que leu e concorda com nossos <a href="/pt/legal/terms-of-use" target="_self">Termos de Serviço</a> e que a Elastic pode <a href="/pt/legal/privacy-statement#how-we-use-the-information" target="_self">entrar em contato com você</a> para divulgar nossos produtos e serviços relacionados usando os dados que você forneceu acima. Consulte a <a href="/pt/legal/privacy-statement/" target="_self">Declaração de Privacidade da Elastic</a> para saber mais detalhes ou para cancelar a qualquer momento.

Explore similar demos

Explore outras demonstrações semelhantes

Overview

Load More

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.

O conteúdo desta página não está disponível no idioma selecionado. A Elastic está trabalhando para garantir que o conteúdo esteja disponível em vários idiomas.Agradecemos a compreensão.

Author

Articles by

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

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

Consultar a hora de início do webinar no meu fuso horário

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

Não vai conseguir participar? Inscreva-se e nós lhe enviaremos a gravação. Você também receberá um email com conteúdo relacionado.

Author

Articles by Lynn Asiimwe

Canonical, Elastic e Google unem-se para evitar a corrupção de dados no Linux

Sign up for Elastic Cloud free trial