从1TB快照创build新的EBS卷需要多长时间？

我怎样才能知道创build新的EBS卷需要多长时间？

创build一个。

然后，尝试使用它。 继续使用它几个小时和几天，并注意你观察。

你的问题的第一个答案是，它实际上只需要几秒钟。

这个答案的问题是，它不能说明整个故事：

从现有的EBS快照创build的新卷在后台中加载时间很长。 这意味着，在从快照创build卷之后，在连接的实例可以开始访问卷及其所有数据之前，不需要等待所有数据从Amazon S3传输到EBS卷。 如果您的实例访问尚未加载的数据，则卷会立即从Amazon S3下载所请求的数据，并继续在后台加载其余数据。

但是，在这里，您必须了解术语“立即”的含义。 立刻并不意味着音量就像最终一样快。 记住：微秒和毫秒之间的差别看起来很小，但仍然是1000倍。

在从快照中恢复的卷上的存储块必须初始化（从Amazon S3中下拉并写入卷），然后才能访问该块。

这个初步行动需要时间，并且可能会导致在每个块第一次访问时I / O操作的等待时间显着增加。

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-initialize.html

这是我的观点，上面 – 创build卷只需要几秒钟的时间，在这一点上，它是可用的，但速度慢。

EBS卷是逻辑实体。 从快照中恢复卷时，只要新卷可用，卷上的每个块就会逻辑地存在，并且在逻辑上可用，但在第一次尝试读取卷时不一定会在卷上物理存在。

加载块的滞后性总体来说是一个很小的代价，要立即获得该块上任何特定块的可用性，但影响可能是显着的，其意义部分取决于如何使用该块。

上面的链接继续解释如何加快与dd或fio的热身过程。 文档省略的事实是，您可以在装入卷的情况下以只读模式使用其中任何一种，并在准备执行卷时获得即时可用性的好处。 这会对最初的随机访问产生进一步的负面影响，但是如果你什么都不做，痛苦就会结束，因此可能会成为你的最佳select……但是你必须通过DRscheme它的步伐，观察其运作，并相应地调整你的策略。

迈克尔一如既往地对你的问题做出了很好的回答。 你也可以预热你的音量，这需要一点时间，但所有的块更快，所以你把性能打在前面。 在另一个AZ上旋转实例可能会用一些事件，lambda和CloudFormation或Opsworks的组合来编写脚本，尽pipe这需要一些实验。 但是，这不是通常在AWS中完成的方式。

根据您的使用情况和预算，另一个更好的select是使用具有自动扩展和多个较小实例的弹性负载平衡器，将您的stream量分布在两个或更多个可用区域。 这意味着，如果您的AZ失败，您的其他实例将继续提供stream量，您的ELB / AS将自动在工作AZ中创build更多实例。 一旦第一个AZ回来，它将最终平衡所有AZ的负载。

如果您的应用程序在两个较小的实例上运行得比一个大的实例运行得更好，那么这个ELB的成本就会更高一些，RTO为零。 如果价格比可用性更重要，那么你可能希望按照你最初的计划与原始的RTO。

请注意，快照存在于AZ中的某个区域。 如果整个地区出去，你不能从另一个地区访问他们。

创buildEBS快照主要取决于卷的大小，以及磁盘上的读/写，networking延迟（次要影响）。 我个人不会build议以EBS根卷快照作为备份，因为操作系统的问题。 如果该卷是数据磁盘，则可以使用快照作为备份。

我相信你的RTO应该足以恢复音量。