我正在烘焙一个数据库服务器的AMI,数据库服务器有300 an的根卷。80%的体积在使用中。烘焙AMI背后的原因是,我们每天需要多个具有完全相同数据的新实例。AMI是适当的解决方案,因为恢复过程非常缓慢。因此,不能在创建实例之后启动数据恢复过程。我们希望所有数据在7-8分钟内准备就绪。
但是,在新实例中的性能非常差。其背后的原因是实例使用EBS,需要像本文档中所描述的那样进行初始化。
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-initialize.html
不幸的是,初始化过程需要5-6个小时,这不是我们的解决方案。
那么,当底层数据需要在AMI中存在时,什么才是烘焙AMI的最佳实践呢?
发布于 2017-10-16 18:39:39
现在,我有一些东西在初始化EBS卷方面有很大帮助。
AWS建议使用dd
或fio
来初始化EBS卷。运行单个dd
进程需要花费太多时间。因此,使用多个dd
进程从给定块中提取一小块数据可以使初始化过程非常快速。
nohup seq 0 $(($(cat /sys/block/xvda/size) / (1 << 10))) | xargs -n1 -P8 -I {} sudo dd if=/dev/xvda of=/dev/null skip={}k count=1 bs=512 > /dev/null 2>&1 &"
发布于 2022-11-16 10:46:43
亚马逊现在正在提供一个服务呼叫快速恢复快照。使用它,您可以将AMI的快照标记为创建新实例所需的区域/可用性区域的快速恢复快照。它可能会占用1小时,1 1TiB的体积,是可以收费的。
但是,这里的好处是,从这个快照创建的卷可以在iops提供的全部容量下使用。这样,你就不必等待或做任何手动阅读块。
一旦创建了卷,就可以禁用快速还原,以防止任何进一步的电荷累积。
https://stackoverflow.com/questions/46284897
复制相似问题