提高 EBS 快照支持卷的 I/O 速率

提高 EBS 快照支持卷的 I/O 速率

我正在使用一个系统,该系统每天轮流拍摄 42 个 EBS 快照,用于灾难恢复目的,这些快照来自其众多 (40) 个卷。EBS 卷聚合成一个 RAID 卷。通过在拍摄快照期间冻结文件系统来拍摄一组一致的快照。每个单独的卷只有 2 TiB。

在 DR 测试期间,我们发现需要超过 24 小时才能将 20+ TiB 的应用程序数据(PostgreSQL 数据库、许多大型表)从快照创建的 EBS 快照支持卷复制到新的非快照支持卷。由于 8 个 rsync 同时在不同的子树上工作,因此复制过程中具有相当大的并行性。

如果数据没有复制到新的 EBS 卷,那么基于 PostgreSQL 的应用程序就会像蜂蜜中的苍蝇一样运行很多天,大概直到 EBS 卷的块被弄脏,所以它们现在直接在 EBS 卷上,而不是来自快照。

相比之下,将相同的数据从一组非快照支持的 EBS 卷复制到另一组仅需几个小时,而使用类似规模的“真实”硬件执行此操作所需的时间则要少得多。

为什么我会看到快照卷和普通卷之间的性能差异如此之大?

我的假设是它正在执行写时复制,因此必须单独获取快照后未更改的干净块。如果该卷上有 40 个快照堆栈,那么它可能会难以快速找到它出现在最新快照中的块并获取它。

有没有什么方法可以强制 AWS 从快照中高效、线性地预填充整个新的 EBS 卷,而不是像它实际上表现的那样进行惰性写时复制?

还有其他解决这个问题的方法吗?如果恢复需要超过一天的时间,那么用于 DR 的一组快照就没那么有用了。

答案1

从恢复的卷读取就足够了。

当您从现有快照创建卷时,它会在后台延迟加载,以便您可以立即开始使用它们。如果您访问尚未加载的数据,卷会立即从 Amazon S3 下载请求的数据,然后继续在后台加载卷的其余数据。

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html

据传,使用顺序“强制读取”似乎dd比从文件系统读取的随机读取效果更好,但您当然可以同时执行这两项操作 - 继续安装它并开始执行您需要做的任何事情,但也使用从块设备读取和丢弃dd

这种明显的差异是有道理的,特别是如果 EBS 快照基础架构实际上没有将快照块存储在“块”大小(4096 字节)的块中。这似乎是一种非常低效的设计,每兆字节需要数千次操作。

如果您从不同的偏移量开始进行多次连续读取,可能会进一步改善恢复效果。未经测试,但gnudd显然可以“跳过”块并从头开始阅读。

但是,您绝对不需要创建“新”卷。一旦读取加载了块,它们就“在”EBS 中,而不是来自快照。

如果有 40 个快照堆栈支持该卷,那么它可能会难以在最新的快照中快速找到该块并获取它。

有多少快照支持它其实并不重要。数据并不存储在快照中。每个快照都包含指向组成它的所有数据块(而不仅仅是更改的数据块)的完整记录,我随便称之为“指针”,并且大概知道它们存储在快照基础架构使用的备份存储(S3)中的位置。

如果您从同一卷按顺序拍摄了快照 A、B 和 C,然后删除快照 B,则从 A 更改为 B 但未从 B 更改为 C 的所有块仍然可用于恢复快照 C,但当您删除快照 B 时,它们实际上并没有从 B 移动到 C。

当您删除快照时,EBS 会使用引用计数清除不再需要的块的后备存储。未被任何快照引用的块由后台的多步骤流程处理,首先将其标记为不需要,从而停止向您收取费用,然后在几天后确认它们的引用计数确实为 0 时实际删除它们。 来源。

因此,最初为恢复的卷贡献块的快照数量不应该对性能产生影响。


额外的、可能有用的信息:以下内容不会改变上述答案的准确性,但在某些情况下可能会有价值。

2019 年末,EBS 宣布了一项新功能,名为快速快照还原这使得从指定快照在指定可用区域中创建的卷可以立即变热,而无需预热。

使用信用桶并根据指定快照的大小(即快照所来自的磁盘卷的大小)——而不是目标卷的大小(目标卷的大小可能大于快照的大小)——此功能允许您每小时创建 1024G/size 的卷,因此 128 GiB 快照每小时可以创建 8 个预热卷。随着快照越来越小,每个可用区域每个快照每小时可以创建的卷数上限为 10。

该服务的价格也高得惊人——每小时、每个快照、每个可用区 0.75 美元(!?)——但是,这可能不是您需要持续运行的服务,从这个角度来看,它似乎具有一些潜在的价值。

当你激活该功能时,服务API 可以告诉您当它真正可供使用时,每 TiB 60 分钟是“优化快照”的规定时间表(从字里行间可以看出,这意味着从快照中构建和预热 EBS 内部的隐藏主卷,随后将由服务克隆以创建额外的 EBS 卷;该功能似乎只有在这个阶段完成后才可用,而在此之前从同一快照创建的卷只是普通卷)。

只要您有时间等待“优化”阶段,并且在不再需要时终止快速恢复行为(以避免非常大的意外账单费用),这似乎在有限的用例中具有适用性。

相关内容