2017-09-18 26 views
0

300GBのルートボリュームを持つデータベースサーバーからAMIをベイクしています。ボリュームの80%が使用中です。 AMIのベーキングの背景にある理由は、毎日まったく同じデータを持つ複数の新しいインスタンスが必要であるということです。復元プロセスが非常に遅いため、AMIは適切なソリューションです。したがって、インスタンスの作成後にデータ復元プロセスを開始することはできません。私たちは、すべてのデータを使って7〜8分でインスタンスを準備したいと考えています。Big EBSボリュームを最適化する(ウォームアップ)

しかし、新しいインスタンスのパフォーマンスは非常に悪いです。その背後にある理由は、インスタンスがEBSを使用するため、このドキュメントで説明されているように初期化する必要があるためです。

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

残念ながら、初期化プロセスは5~6時間かかりますし、それは私たちのためのソリューションではありません。

したがって、基礎となるデータがAMIにある必要がある場合、AMIを焼くベストプラクティスは何ですか?

+0

これらのインスタンスではどのデータベースエンジンを実行していますか? –

+0

@ Michael-sqlbotデータベースエンジンとは関係ありません。私たちはMySQLまたはPostgreSQLを使用していません。修復はカスタムプロセスです。 –

+0

これは関連していないと私は理解しています。これは、具体的に実行していることに関係なく、スナップショットのAMIとEBSボリュームの性質の一部です。あなたがやっていることに応じて、AuroraのコピーオンライトクローンやEFSが実行可能なソリューションかもしれませんが、いずれの場合でも5〜6時間以内に300 GBのボリュームをウォーミングアップすることが可能です。 –

答えて

0

今、私はEBSボリュームの初期化に多大な貢献をしました。

EBSボリュームの初期化にはddまたはfioを推奨します。単一の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 &"

関連する問題