林州网站建设熊掌号,网页打不开无法连接服务器,app开发工具,湖南做网站 都来磐石网络作者#xff1a;来自 Elastic Henning Andersen 在最近的博客文章中#xff0c;我们宣布了支持 Elastic Cloud Serverless 产品的无状态架构。通过将持久性保证和复制卸载到对象存储#xff08;例如 Amazon S3#xff09;#xff0c;我们获得了许多优势和简化。
从历史上…作者来自 Elastic Henning Andersen 在最近的博客文章中我们宣布了支持 Elastic Cloud Serverless 产品的无状态架构。通过将持久性保证和复制卸载到对象存储例如 Amazon S3我们获得了许多优势和简化。
从历史上看Elasticsearch 依靠本地磁盘持久性来确保数据安全并处理陈旧或孤立的节点。在本博客中我们将讨论无状态的数据持久性保证包括我们如何使用安全检查隔离新的写入和删除以防止陈旧节点不安全地确认这些操作。
在以下博客文章中我们将介绍持久性承诺的基础知识以及 Elasticsearch 如何使用操作日志 (translog) 来快速安全地确认对客户端的写入。接下来我们将深入研究问题介绍对我们有帮助的概念最后解释额外的安全检查使我们能够自信地确认对客户端的写入。 持久性承诺和 translog
当客户端将数据写入 Elasticsearch 时例如使用 _bulk APIElasticsearch 将为该请求提供 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
