在测试 Elastic Stack 的一项新功能时，我们发现了一个 Linux 内核故障，会影响到某些 Linux 内核上的 SSD 磁盘。了解我们是如何与下面的两个密切合作伙伴携手展开默契调查的：Google Cloud 和 Canonical。

在 Elastic，我们一直在不断创新并发布新功能。&nbsp;在我们发布新功能的同时，也在努力确保让这些功能经过测试，并达到安全、稳定和可靠的运行状态，但有时确实会出现这样或那样的问题。
在测试一项新功能时，我们发现了一个 Linux 内核故障，会影响到某些 Linux 内核上的 SSD 磁盘。在这篇博客文章中，我们将介绍这项调查的来龙去脉，以及我们是如何与 Google Cloud 和 Canonical 这两个密切合作伙伴携手展开调查的。
调查结果是发布了新的 Ubuntu 内核来<a href="#conclusion">解决这个问题</a>。
 <h2>调查的来龙去脉</h2>早在 2019 年 2 月，我们使用标准的 <a href="https://esrally.readthedocs.io/en/stable/">Elasticsearch 基准测试工具 Rally</a>，对<a href="/guide/en/elasticsearch/reference/7.8/xpack-ccr.html">跨集群复制 (CCR)</a> 进行了<a href="/cn/blog/benchmarking-elasticsearch-cross-cluster-replication">为期 10 天的稳定性测试</a>，期间使用的是<a href="https://github.com/elastic/rally-eventdata-track/blob/master/eventdata/challenges/bulk-update.json">更新量繁重的采集工作负载</a>。Elasticsearch 版本是（当时）尚未发布的 7.0 分支提交的最新版本。几天后，测试失败，Elasticsearch 日志报告显示：
<pre class="prettyprint">… 
Caused by: org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?)
</pre>一旦检测到[<a href="#ref1" id="1">1</a>]索引损坏，Elasticsearch 将尝试从副本中恢复。在许多情况下，恢复是无缝进行的，除非用户查看日志，否则不会注意到损坏。即使副本提供了冗余，在某些情况下也可能造成数据丢失。因此，我们希望了解损坏发生的原因，并探究如何补救这一问题。
起初，我们怀疑是 <a href="/guide/en/elasticsearch/reference/7.8/xpack-ccr.html">CCR</a>/<a href="https://github.com/elastic/elasticsearch/issues/29530">软删除</a>这项新的 Elasticsearch 功能导致了这个问题。但这种怀疑很快就被打消了，因为我们发现在使用单个集群并禁用 CCR/软删除功能的情况下也可以重现索引损坏问题。经过进一步的研究，我们发现，在 CCR/软删除公测版启动之前的 Elasticsearch 早期版本中，我们可以重现这个问题，这说明 CCR/软删除并不是导致索引损坏的原因。
不过，我们也确实注意到，出现索引损坏的测试和研究是在 Google Cloud Platform (GCP) 上进行的，使用的是 <a href="https://console.cloud.google.com/marketplace/details/ubuntu-os-cloud/ubuntu-xenial">Canonical Ubuntu Xenial 映像</a>和<a href="https://cloud.google.com/compute/docs/disks/local-ssd">本地 SSD</a>，内核为 <code>4.15-0-*-gcp</code>，并且我们无法在具有相同操作系统和 SSD 磁盘的裸机环境（使用 4.13 或 4.15 <a href="https://wiki.ubuntu.com/Kernel/LTSEnablementStack">HWE 内核</a>）中重现这一问题。
接下来我们的注意力立即转向了 Elastic Cloud，希望获取有关该问题及其影响的更多数据。在并行工作流中，我们通过测试不同的文件系统、禁用 RAID，最后使用较新的主线内核，排除了许多疑点，但这些都不能避免发生损坏。
 <h2>在 Google Cloud 的支持下进一步挖掘</h2>此时，我们创建了一套<a href="https://gist.github.com/dliappis/54a9eedd5a272cf13b49ecaa85f87c7f">简单的复制脚本</a>来简化复制，并与我们的合作伙伴 Google 一起开始深入研究环境问题。
GCP 支持人员能够使用提供的脚本可靠地重现问题，并提供了一条错误消息：
<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>在问题发生的时间段内，IO 吞吐量超过 160MB/s，IOPS 为 16,000。在好几次测试中都出现了上述观察结果。由于 Elasticsearch（默认情况下）使用<a href="/guide/en/elasticsearch/reference/7.8/index-modules-store.html#file-system">内存映射文件来存储部分内容</a>，因此，我们怀疑某些文件访问导致了更多严重的页面错误，进而导致磁盘的 IO 操作量增加，并最终触发了该问题。为了减少页面错误的发生，我们尝试将 GCP 实例的内存从 32GB 增加到 52GB。随着内存的增加，这个问题不再出现，IO 吞吐量为 50MB/s，IOPS 为 4,000。&nbsp;
当我们观察到 GCP 和裸机环境之间的差异时，这个问题首次有了突破：GCP 内核启用了一个叫作<a href="https://lwn.net/Articles/738449/">多队列块层</a> (blk_mq) 的功能，而裸机内核没有[<a href="#ref2" id="2">2</a>]。更复杂的是，在特定版本[<a href="#ref3" id="3">3</a>]之后，无法再通过内核选项在 Ubuntu Linux -gcp 映像上禁用 blk_mq[<a href="#ref4" id="4">4</a>]。GCP 支持人员向我们展示了如何通过导出 GCP 的 Ubuntu 映像并在不使用 VIRTIO_SCSI_MULTIQUEUE guestOS 功能（该功能可启用多队列 SCSI[<a href="#ref5" id="5">5</a>]）的情况下，重新创建它来禁用 blk_mq。
第二个突破是设法在裸机上重现损坏：只有通过显式启用 <code>blk_mq</code>，甚至使用旧的内核 <code>4.13.0-38-generic</code>，才有可能实现。我们还验证了 NVMe 磁盘，确认不会显示此问题。
至此，我们知道，当同时满足以下两个条件时，就会发生损坏：
<ul>
	<li>SSD 驱动器使用 SCSI 接口（NVMe 磁盘不受影响）</li>
	<li>启用了 blk_mq</li>
</ul>GCP 支持人员分享了（除了仅使用 NVMe 磁盘外的）另外两种解决方法：增加实例内存或在禁用多队列 SCSI 的情况下创建自定义实例映像。
 <h2>Canonical 加入了我们的调查行列</h2>尽管我们有了一些解决方法，但我们仍不满意：
<ul>
	<li>这个问题并不是 GCP 上的 Ubuntu 映像特有的问题，它也发生在裸机上。</li>
	<li>我们不知道是哪个内核提交导致了这个问题。</li>
	<li>我们不知道较新的内核中是否已经有了修复程序。</li>
</ul>为了解决这些问题，我们联系了我们的合作伙伴 Canonical 一道进行深入的研究。
Canonical 使用 <a href="https://gist.github.com/dliappis/54a9eedd5a272cf13b49ecaa85f87c7f">Elastic 复制脚本</a>开始了大规模的测试工作，首先确认了在使用 SSD 驱动器（不使用或使用 mq-deadline <a href="https://wiki.ubuntu.com/Kernel/Reference/IOSchedulers">多队列 I/O 调度程序</a>）且版本 &gt;=5.0 的 Ubuntu 主线内核上没有发生损坏。
下一步是倒推内核版本，找出出现损坏的内核和没有损坏的内核之间的最小增量。通过使用多个并行测试环境（因为整个测试运行最多可能需要五天），Canonical 发现 <a href="https://kernel.ubuntu.com/~kernel-ppa/mainline/v4.19.8/">4.19.8</a> 是第一个包含损坏修复程序的 Ubuntu 主线内核[<a href="#ref6" id="6">6</a>]。
Canonical 的故障跟踪器在 <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739">LP#1848739</a> 下描述了 4.15.0 内核及其派生版本缺少的反向端口，更多细节可以在<a href="https://lwn.net/Articles/774440/">本文</a>和 <a href="https://bugzilla.kernel.org/show_bug.cgi?id=201685">kernel.org bug</a> 中找到。
在 Elastic 和 Canonical 确认打已修补的 GCP 内核（包含所有必要的反向端口）<a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/9">修复这个问题</a>之后，它们被<a href="https://lists.ubuntu.com/archives/kernel-team/2019-December/106382.html">合并</a>到 Ubuntu 4.15.0 主内核中，因此，所有派生内核（包括 -gcp）都收到了修复程序。
 <h2 id="conclusion">结论</h2>Elastic 始终致力于开发新的 Elastic Stack 功能，不断改进我们的三大主要解决方案。这些努力得到了一些才华横溢的工程师和合作伙伴的鼎力支持，我们时刻保持警惕，所以您不必过于担心。如果我们在测试过程中发现问题，请记住，Elastic 及其密切的合作伙伴网络将不遗余力地查证问题，确保您拥有最好的体验。
通过与 Google 和 Canonical 的密切合作，我们得以弄清问题的真相，从而发布了以下<a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739">装有修复程序</a>的 HWE Ubuntu 内核：
<ul>
	<li>AWS：从 <code>linux-aws - 4.15.0-1061.65</code> 开始，发布于 <a href="https://changelogs.ubuntu.com/changelogs/pool/main/l/linux-aws/linux-aws_4.15.0-1061.65/changelog">2020 年 2 月 21 日</a></li>
	<li>Azure：从 <code>linux-azure - 4.15.0-1066.71</code> 开始，发布于 <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/12">2020 年 1 月 6 日</a></li>
	<li>GCP：从 <code>linux-gcp - 4.15.0-1053.57</code> 开始，发布于 <a href="https://changelogs.ubuntu.com/changelogs/pool/main/l/linux-gcp/linux-gcp_4.15.0-1053.57/changelog">2020 年 2 月 5 日</a></li>
	<li>常规：从 <code>linux - 4.15.0-88.88</code> 开始，发布于 <a href="https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/15">2020 年 2 月 17 日</a></li>
</ul>如果在启用 SCSI blk-mq 的情况下使用 SSD 磁盘，使用上述或更高版本可避免发生损坏。
如果您想保护自己的环境不受数据损坏，那么请试试我们的 <a href="/cn/elasticsearch/service">Elastic Cloud</a> 吧，我们的用户已经受到很好地保护了。
 <h2>脚注</h2>[<a href="#1" id="ref1">1</a>] Elasticsearch 不会一直验证校验和，因为这是一项昂贵的操作。某些操作可能会更频繁地触发校验和验证，例如分片重定位或在拍摄快照时，使潜在的静默损坏看起来好像是由这些操作引起的。
[<a href="#2" id="ref2">2</a>] 要检查 blk_mq 是否正在用于 SCSI 或设备映射器磁盘，请使用 <code>cat /sys/module/{scsi_mod,dm_mod}/parameters/use_blk_mq</code>
[<a href="#3" id="ref3">3</a>] 在 <a href="https://patchwork.kernel.org/patch/10198305">https://patchwork.kernel.org/patch/10198305</a> 之后，blk_mq 被强制用于 SCSI 设备，并且无法通过内核选项禁用。这个补丁在 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>] 要禁用 blk_mq，需要通过 grub 将以下参数传递给内核：<code>GRUB_CMDLINE_LINUX="scsi_mod.use_blk_mq=N dm_mod.use_blk_mq=N"</code>。可以通过将这些选项设置为 N 来启用，但要注意 [3]。
[<a href="#5" id="ref5">5</a>] 通过重新创建 Ubuntu 映像来禁用 VIRTIO_SCSI_MULTIQUEUE guestOS 功能的示例 gcloud 命令：
<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>] 反向端口
<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 和 Google 联手防止 Linux 中出现数据损坏

开始免费试用

Blog Footer CTA

注册 Elastic Cloud 免费试用版

Blog Footer

Christopher Newcomer (Canonical)

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.

Newsletter GDPR Text

提交即表示您确认您已阅读并同意我们的<a href="/cn/legal/elastic-cloud-account-terms" target="_self">服务条款</a>，并且 Elastic 可以使用您提供的上述详细信息与您联系，以向您介绍我们相关的<a href="/cn/legal/privacy-statement#how-we-use-the-information" target="_self">产品和服务</a>。如需了解更多信息，或想随时取消订阅，请参阅 <a href="/cn/legal/privacy-statement/" target="_self">Elastic 的隐私声明</a>。

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.

本页内容尚不支持所选语言。Elastic 正在不断努力，以实现对多种语言内容的支持。感谢您在此期间给予的耐心与陪伴！

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

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

无法实时参加？注册后我们会给您发送录像。您还将收到相关内容的电子邮件。

Elasticsearch Platform

ELK Stack

Elastic Cloud

可观测性

安全性

搜索

按行业

按解决方案

客户聚焦

开发人员

保持联系

学习

帮助

了解 Elastic 的最新动态

作者

文章作者 Christopher Newcomer

Canonical、Elastic 和 Google 联手防止 Linux 中出现数据损坏

注册 Elastic Cloud 免费试用版

关注我们

关于我们

加入我们

新闻稿

合作伙伴

信任和安全性

投资者关系

卓越奖

关于我们

加入我们

新闻稿

合作伙伴

信任和安全性

投资者关系

卓越奖