Elasticsearch:无状态世界中的数据安全

作者:来自 Elastic Henning Andersen

 

在最近的博客文章中,我们宣布了支持 Elastic Cloud Serverless 产品的无状态架构。通过将持久性保证和复制卸载到对象存储(例如 Amazon S3),我们获得了许多优势和简化。

从历史上看,Elasticsearch 依靠本地磁盘持久性来确保数据安全并处理陈旧或孤立的节点。在本博客中,我们将讨论无状态的数据持久性保证,包括我们如何使用安全检查隔离新的写入和删除,以防止陈旧节点不安全地确认这些操作。

在以下博客文章中,我们将介绍持久性承诺的基础知识以及 Elasticsearch 如何使用操作日志 (translog) 来快速安全地确认对客户端的写入。接下来,我们将深入研究问题,介绍对我们有帮助的概念,最后解释额外的安全检查,使我们能够自信地确认对客户端的写入。

持久性承诺和 translog

当客户端将数据写入 Elasticsearch 时(例如使用 _bulk API),Elasticsearch 将为该请求提供 HTTP 响应代码。Elasticsearch 仅在数据已安全存储时才提供成功的 HTTP 响应代码 (200/201)。我们使用操作日志(称为 translog),请求在确认写入之前附加并存储在其中。translog 允许我们重放未成功持久化到底层 Lucene 索引的操作(例如,如果在我们确认写入到客户端后节点崩溃)。有关 translog 和 Lucene 索引的更多信息,请参阅我们最近关于薄索引分片的博客文章中的此部分,其中我们解释了我们现在如何在对象存储中存储 Lucene 索引和 translog。

不知道是最糟糕的 - 问题

主节点将分片分配给索引节点,然后该节点负责将传入的数据索引到该分片中。但是,我们必须考虑此节点与主节点和/或集群其余部分失去通信的情况。

在这种情况下,主节点将(在超时后)假定该节点不再运行,并将受影响的分片重新分配给其他节点。先前的分配现在将被视为过时或陈旧(stale)。过时的节点可能仍在运行,试图索引和保存它收到的数据。

在这种情况下,可能有两个分片所有者试图确认写入但彼此失去通信,我们有两个问题需要解决:

  • 避免对象存储中的文件覆盖
  • 确保已确认的写入不会丢失

Primary terms - 数量增加以求得救

Elasticsearch 多年来一直使用我们称为 primary terms 的东西。每当将主分片分配给节点时,都会为其分配一个 primary term。如果主分片发生故障或从未分配(unassigned)变为已分配(assiined),主服务器(master)将在重新分配主分片之前增加 promary term 的值。这给出了主分片分配和所有权的严格顺序,在较低的 primary terms 之后分配较高的 primary terms。

对于无状态(stateless),我们在写入对象存储的索引文件路径中使用 primary terms,以确保不会发生上述第一个问题。如果分片发生故障并被重新分配,我们知道它将具有更高的 primary term。分片只会在 primary term 特定的路径中写入文件,因此较旧的分片分配和较新的分片分配不可能写入相同的文件。它们只是写入不同的路径。

Primary term 也用于最终提供耐用性保证,稍后会详细介绍。

请注意,主分片重定位不会增加 primary term 的值,而是涉及主分片重定位的两个节点通过明确的协议交接所有权。

Coordination term 和节点离开生成( node-left generation)

Elasticsearch 中的协调子系统是一种用于集群级别协调的强一致性机制,包括集群成员资格和集群元数据(均称为集群状态)。

在无状态(stateless)中,此系统还建立在对象存储之上,上传新的集群状态版本。与有状态一样,它为称为 “term” 的选举维护一个不断增加的数字(我们在此将其称为 coordination term,以将其与上一节中描述的 primary term 区分开来)。每当一个节点决定开始新的选举时,它都会在新的 coordination term 内这样做,该 term 高于之前看到的任何 term(有关有状态中此工作的更多详细信息,请参阅此处的博客文章)。

在无状态中,选举通过我们称为租约(lease file)文件的对象存储文件进行。此文件包含 coordination term 和声称该 term 是该 term 的当选主节点的节点。

此文件将有助于我们在此处感兴趣的安全检查。如果 coordination term 仍然相同,我们就知道当选主节点没有改变。

然而,仅有协调项是不够的,因为即使节点离开集群,这也不一定会发生改变。为了检测数据节点是否未离开集群,我们还将节点离开生成添加到租约文件中。这是一个递增的数字,每次节点离开集群时都会增加。当 term 发生变化时,它会从零重置(但在这里我们可以忽略这一点)。

租约文件作为持久化新集群状态的一部分写入对象存储。此写入发生在根据新集群状态采取任何操作(如分片恢复)之前。

对象存储先读后写语义

我们使用对象存储以无状态存储所有数据,因此对象存储的可见性保证非常重要。最终,安全检查建立在这些保证之上。

以下是我们依赖的主要对象存储可见性保证

  • 先读后写:成功写入后,任何读取都将返回新内容。
  • 先列表后写入:成功写入后,任何与新文件匹配的列表都将返回该文件。

这些在几年前并不是必然的,但现在已在 AWS S3、GCP 和 Azure blob 存储中提供。

安全检查

有了上述必要的构建块,我们现在可以进行实际的安全检查和安全论证。虽然 translog 保证了写入的持久性,但在确认写入之前,我们需要确保节点仍然是指定的索引节点。事实来源是集群状态,因此数据节点需要确定它具有足够新的集群状态,以确定确认写入是否安全。

我们只对非优雅事件感兴趣,例如节点崩溃、网络分区等。分片重定位等优雅事件通过显式交接来处理,以保证其正确性(我们不会在本篇博文中深入讨论这个问题)。

让我们考虑一个非优雅事件,例如主节点检测到保存分片的数据节点不再响应,因此它将节点从集群中弹出。我们将在这种情况下检查安全检查,看看它如何避免陈旧的节点可能错误地确认对客户端的写入。

安全检查在响应客户端之前添加了一项额外检查:

  • 从对象存储中读取租约文件。如果 coordination term 或节点左代已超过节点本地集群状态中的值,则它不能依赖集群状态,直到收到具有更高或相等coordination term 和节点离开生成的更新版本。有了足够新的集群状态,可以使用它来检查分片的 primary term 是否已更改。如果已更改,则写入将失败。

在理想情况下,这里不会有任何等待,因为与正常写请求的频率相比,term 和节点离开生成的变化非常不频繁。因此,这个检查的开销很小。

请注意,顺序是重要的:在安全检查之前,translog 文件已经成功上传。稍后我们将解释原因。

非正常的节点离开事件会导致租约文件中的节点离开生成编号递增。之后,一个新节点可能会被分配到该分片并开始恢复数据(这可能只是一次集群状态更新,但这里唯一重要的部分是租约文件写入和节点开始恢复的顺序,这一点是有保证的)。

新分配的节点随后会读取分片数据并恢复 translog 中包含的数据。

我们看到事件的顺序如下:

  • 原始数据节点在读取租约文件之前写入 translog。
  • 主节点在新数据节点开始恢复之前(因此也在读取 translog 之前)将递增的节点离开生成写入租约文件。
  • 对象存储保证了对租约文件和 translog 文件的先读后写(read-after-write)。

这里需要考虑两种主要情况:

  • 原始数据节点写入了 translog 文件,并读取了一个租约文件,表明它仍在集群中且是分片的拥有者(primary term 没有改变)。
    • 我们可以确定主节点在数据节点读取之前未成功更新租约文件。因此,原始数据节点对 translog 的写入发生在新节点分配读取 translog 之前,保证这些操作可供新节点进行恢复。
  • 原始数据节点写入了 translog 文件,但在等待租约文件中的信息反映的新集群状态后,它不再是分片的拥有者(导致写入请求失败)。
    • 我们不会成功响应该写入请求,因此不会承诺持久性。
    • translog 数据可能在恢复期间对新节点分配可用,但这没问题。写入失败的请求实际上持久化了数据,这也是可以接受的。

因此,我们可以看到,Elasticsearch 成功响应的任何写入将对同一分片的未来拥有者可用,进而证明了我们的安全性论点。

同样,我们可以论证主节点故障转移的情况也是安全的。在这种情况下,coordination term 而不是节点离开生成会发生变化。我们这里不再详细说明。

这种相同的安全检查也应用于其他一些关键情况:

  • 在索引文件删除期间。当 Lucene 合并段时,旧段可以被删除。我们在这里添加了安全检查,以防止删除新节点分配可能需要的文件。
  • 在 translog 文件删除期间。当对象存储中的索引数据包含所有操作时,translog 可以被删除。同样,我们在这里添加了安全检查,以防止删除新节点分配可能需要的 translog 文件。

结论

恭喜,你已经读到了最后,希望你喜欢这里的深入研究。我们描述了一种新颖的机制,用于确保 Elasticsearch 持久安全地将写入持久化到对象存储,即使在出现任何类型的中断导致 Elasticsearch 有两个节点拥有对同一分片的索引的情况下也是如此。我们非常关心这些方面,如果你也这样做,也许可以看看我们的开放职位

向 David Turner、Francisco Fernández Castaño 和 Tim Brooks 致敬,他们在这里完成了大部分实际工作。

准备好自己尝试一下了吗?开始免费试用

想要获得 Elastic 认证?了解下一次 Elasticsearch 工程师培训何时开始!

原文:Data safety in a stateless world — Search Labs

微信鸿蒙原生版开始内测邀请 Python 3.13.0 (final) 发布 Redis 7.4.1 发布 Tauri 2.0 稳定版发布,Rust 编写的下一代跨平台开发框架 不积跬步无以至千里,AtomUI 预览版发布! 黑神话:仙童,数据库自动反射魔法棒 1-8 月我国软件业务收入 85492 亿元,同比增长 11.2% 2024年诺贝尔物理学奖揭晓,获奖者之一是“深度学习教父” HashiCorp 创始人向 Zig 软件基金会捐赠 30 万美元 微信工程师:HarmonyOS NEXT 是一套新的技术框架,编程语言是独特的 ArkTS 语言
{{o.name}}
{{m.name}}

猜你喜欢

转载自my.oschina.net/u/3343882/blog/16223133