使用Elasticsearch进行跨区域灾难恢复

毫不奇怪，在Rewind，我们有很多数据需要保护（超过2 PB）。我们使用的其中一个数据库叫做Elasticsearch（ES或Opensearch，目前在AWS中是已知的）。简单地说，ES是一个文档数据库，有助于快速搜索结果。当客户需要使用回放功能恢复特定文件或项目时，速度至关重要。停机时间的每一秒都很重要，因此我们的搜索结果需要快速、准确和可靠。

另一个考虑因素是灾难恢复。作为我们的系统和组织控制2级（SOC2）认证流程的一部分，我们需要确保我们有一个有效的灾难恢复计划，以便在整个AWS地区出现故障的情况下恢复服务。

“整个AWS地区？？这永远不会发生！”（除了发生的时候）

一切皆有可能，事情总会出错，为了满足我们的SOC2要求，我们需要一个可行的解决方案。具体而言，我们需要的是一种安全、高效、经济高效地将客户数据复制到其他AWS地区的方法。答案是做倒带做得这么好的事情——备份！

让我们深入了解Elasticsearch是如何工作的，我们如何使用它网络安全地备份数据，以及我们当前的灾难恢复过程。

快照

首先，我们需要上一堂快速的词汇课。调用ES中的备份快照。快照存储在快照存储库。有多种类型的快照存储库，其中一种由AWS S3支持。由于S3能够将其内容复制到另一个区域的存储桶中，因此它是解决这个特定问题的完美方案。

AWS ES为您预先启用了自动快照存储库。存储库默认配置为每小时拍摄一次快照，您无法对其进行任何更改。这对我们来说是个问题，因为我们想要每日的快照发送到由我们自己的一个S3存储桶支持的存储库，该存储桶被配置为将其内容复制到另一个区域。

自动快照列表是否获取\u cat/snapshots/cs automated enc？v&amp；s=id

 

 

 

 

 

 

 

 

 

我们唯一的选择是创建和管理我们自己的快照存储库和快照。

维护我们自己的快照存储库并不理想，听起来像是许多不必要的工作。我们不想重新发明轮子，所以我们寻找一种现有的工具来为我们完成繁重的工作。

快照生命周期管理（SLM）

我们尝试的第一个工具是Elastic的快照生命周期管理（SLM），该功能描述为：

定期备份群集的最简单方法。SLM策略会根据预设的计划自动拍摄快照。该策略还可以根据您定义的保留规则删除快照。

您甚至可以使用自己的快照存储库。然而，当我们试图在我们的域中设置它时，它就失败了。我们很快了解到AWS ES是Elastic的一个改进版本。AWS ES不支持co的ES和SLM。

馆长

我们研究的下一个工具叫做Elasticsearch Curator。它是开源的，由Elastic维护。共同合作。

Curator只是一个Python工具，可以帮助您管理索引和快照。它甚至还有用于创建自定义快照存储库的辅助方法，这是一个额外的好处。

我们决定将Curator作为一个Lambda函数来运行，该函数由计划的EventBridge规则驱动，所有这些都打包在AWS SAM中。

最终解决方案如下：

ES快照Lambda函数

Lambda使用Curator工具，负责快照和存储库管理。下面是逻辑图：

如上所述，这是一个非常简单的解决方案。但是，为了让它发挥作用，我们需要一些东西：

• 要授予权限的IAM角色
• 具有复制到另一个区域的S3存储桶
• 具有索引的Elasticsearch域

IAM角色

S3SnapshotsIAMRole拨款馆长创建快照存储库和管理实际快照本身所需的权限：

EsSnapshotIAMRole授予兰姆达馆长与Elasticsearch域交互所需的权限：

复制的S3存储桶

该团队之前为其他服务设置了复制的S3存储桶，以便于在Terraform中进行跨区域复制。（此处提供更多信息）

一切就绪后，生产初始测试中部署的cloudformation堆栈运行良好，我们完成了…；还是我们？

备份和恢复—a-thon I

SOC2认证的一部分要求您验证所有关键服务的生产数据库备份。因为我们喜欢玩得开心，我们决定每季度举办一次“备份和恢复大赛”。我们假设原始区域已经消失，我们必须从跨区域副本恢复每个数据库并验证内容。

有人可能会想：“哦，天哪，那是很多不必要的工作！”你说对了一半。这是一个很大的工作，但它是绝对必要的！在每次恢复活动中，我们都发现了至少一个服务未启用备份、不知道如何恢复或访问已恢复备份的问题。更不用说团队成员在实际工作中获得的实践培训和经验，而不是在真正停机的高压下。就像进行消防演习一样，我们每季度的恢复活动有助于我们的团队做好准备，随时应对任何紧急情况。

第一次ES Restore-a-thon是在该功能完成并在生产中部署数月后进行的，因此拍摄了许多快照，删除了许多旧快照。我们将该工具配置为保留5天的快照，并删除所有其他内容。

任何从我们的存储库恢复复制快照的尝试都失败了，出现了未知错误，并且没有其他需要继续的操作。

ES中的快照是增量的，这意味着快照的频率越高，完成的速度越快，大小越小。我们最大的域的初始快照需要1.5个多小时才能完成，所有后续的每日快照都需要几分钟！

这一观察结果使我们尝试保护初始快照，并通过在创建存储库后拍摄的第一个快照中使用名称后缀（-initial）来防止其被删除。然后，Curator使用正则表达式过滤器将初始快照名称从快照删除过程中排除。

我们清除了S3存储桶、快照和存储库，然后重新开始。在等待快照累积数周后，恢复再次失败，出现了相同的神秘错误。然而，这次我们注意到初始快照（我们保护的）也丢失了！

由于没有周期可以花在这个问题上，我们不得不把它停下来处理我们在Rewind这里处理的其他酷而棒的事情。

备份和恢复-a-thon II

不知不觉，下一个季度就要开始了，是时候再进行一次备份和恢复了，我们意识到这仍然是我们灾难恢复计划中的一个缺口。我们需要能够在另一个地区成功恢复ES数据。

我们决定向Lambda添加额外的日志记录，并每天检查执行日志。第1天到第6天的恢复工作非常顺利，我们可以列出所有快照，而最初的快照仍然存在。在第7天，发生了一些奇怪的事情-调用列出可用快照时，仅对初始快照返回了一个“未找到”错误。是什么外力在删除我们的快照？？

我们决定仔细查看S3 bucket内容，发现除了缺少的初始快照之外，所有的都是UUID（通用唯一标识符），其中一些对象与后快照相关。

我们注意到控制台中的“show versions”（显示版本）切换开关，认为bucket在其上启用了版本控制很奇怪。我们启用了版本切换，立即看到到处都是“删除标记”，包括损坏整个快照集的初始快照上的一个标记。

&之前；之后

我们很快意识到，我们使用的S3存储桶有一个7天的生命周期规则，该规则清除了所有超过7天的对象。

存在生命周期规则，以便自动清除存储桶中的非托管对象，以降低成本并保持存储桶整洁。

我们恢复了删除的对象，瞧，快照列表工作得很好。最重要的是，恢复是成功的。

本垒打

在我们的情况下，策展人必须管理快照生命周期，因此我们所需要做的就是使用规则上的作用域路径过滤器防止生命周期规则删除快照存储库中的任何内容。

我们创建了一个名为“/自动清除”的特定S3前缀，该规则的作用域为该前缀。将删除/自动清除中早于7天的所有内容，而保留桶中的所有其他内容。

我们再次清理了一切，等待&gt；7天之后，使用复制的快照重新运行了恢复，最终恢复工作完美无瑕——备份和恢复一次完成！

结论

制定灾难恢复计划是一项艰难的心理训练。实施和测试it的每一部分都更加困难，但这是一项重要的业务实践，可以确保您的组织能够经受住任何风暴。当然，不太可能发生房屋火灾，但如果真的发生了，你可能会很高兴在浓烟滚滚之前练习了该怎么做。

在您的基础架构的关键部分出现提供商停机时确保业务连续性带来了新的挑战，但它也提供了探索类似此处所述解决方案的绝佳机会。希望我们在这里的小冒险可以帮助您避免我们在制定自己的Elasticsearch灾难恢复计划时遇到的陷阱。