1TBのスナップショットから新しいEBSボリュームを作成するのにどのくらい時間がかかりますか？

Question

バックアップとして1TBEBS（Amazon Web Services Elastic Block Store）ボリュームの定期的なスナップショットを撮っています。 AZ（Availability Zone）全体が使用できなくなった場合、私のディザスタリカバリプランは、同じリージョン内の別のAZの最新のスナップショットから新しいEBSボリュームを作成することです。

新しいEBSボリュームの作成にかかる時間をどのように把握できますか？ 6時間のRTO（回復時間目標）があります。このアプローチでそれを満たすことはできますか？

おそらく違いはないはずですが、私はap-southeast-2地域（つまりシドニー）にいます。

Michael - sqlbot · Accepted Answer

新しいEBSボリュームの作成にかかる時間をどのように把握できますか？

一つ作る。

そして、それを使ってみてください。何時間も何日も使用し続け、観察した内容に注意してください。

あなたの質問に対する最初の答えは、実際には数秒しかかからないということです。

その答えの問題は、それが全体の話をしていないということです：

既存のEBSスナップショットから作成された新しいボリュームは、バックグラウンドで遅延ロードされます。つまり、スナップショットからボリュームが作成された後、接続されたインスタンスがボリュームとそのすべてのデータへのアクセスを開始する前に、すべてのデータがAmazonS3からEBSボリュームに転送されるのを待つ必要はありません。インスタンスがまだロードされていないデータにアクセスすると、ボリュームはリクエストされたデータをAmazon S3からすぐにダウンロードし、残りのデータをバックグラウンドでロードし続けます。

ただし、ここでは、「すぐに」という用語の意味を理解する必要があります。すぐに、ボリュームが最初は最終的には速くなることを意味しません。覚えておいてください：マイクロ秒とミリ秒の違いは直感的には小さいように見えますが、それでも1,000倍です。

[...]スナップショットから復元されたボリューム上のストレージブロックは、ブロックにアクセスする前に初期化（Amazon S3からプルダウンしてボリュームに書き込む）する必要があります。

この予備アクションには時間がかかり、各ブロックに最初にアクセスしたときにI/O操作の待ち時間が大幅に増加する可能性があります。

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

これが上記の私のポイントです。ボリュームの作成に必要なのはほんの数秒で、その時点で使用できますが、時間がかかります。

EBSボリュームは論理エンティティです。ボリュームがスナップショットから復元されると、ボリューム上のすべてのブロックがlogically存在し、logically新しいボリュームが使用可能になるとすぐに使用可能になりますが、必ずしも物理的に初めてボリュームを読み込もうとしたときにボリュームに存在します。

ブロックのロードの遅れは、全体として、ボリューム上の特定のブロックをすぐに利用できるようにするための小さな代償ですが、ボリュームの使用方法に一部依存する重要性があるため、影響は大きくなる可能性があります。

上記のリンクは、ddまたはfioを使用してウォームアッププロセスを高速化する方法を説明しています。ドキュメントで省略されているのは、これらのいずれかを読み取り専用モードで使用できるという事実ですボリュームがマウントされている、アクションの準備中にボリュームをすぐに利用できるという利点があります。これは最初のランダムアクセスにさらに悪影響を及ぼしますが、何もしなかった場合よりも早く痛みが終わります。そのため、おそらくそれが最善の選択になるでしょう...しかし、DRシナリオを実行する必要がありますそのペースを観察し、その動作を観察し、それに応じて戦略を調整します。

Tim · Answer

いつものように、マイケルはあなたの質問に素晴らしい答えを持っています。ボリュームを予熱することもできます。これには少し時間がかかりますが、すべてのブロックがより速く取り込まれるため、パフォーマンスを前面に出すことができます。別のAZでインスタンスをスピンアップするには、いくつかの実験が必要ですが、イベント、ラムダ、CloudFormationまたはOpsworksの組み合わせを使用してスクリプトを作成することもできます。ただし、これはAWSで通常行われる方法ではありません。

ユースケースと予算に応じて、もう1つの潜在的に優れたオプションは、自動スケーリングと複数の小さなインスタンスを備えたエラスティックロードバランサーを使用して、トラフィックを2つ以上のAZに分散することです。つまり、AZに障害が発生した場合、他のインスタンスはトラフィックを処理し続け、ELB/ASは動作中のAZでより多くのインスタンスを自動的に作成します。最初のAZが復旧すると、最終的にはすべてのAZ間で負荷が再び分散されます。

アプリケーションが1つの大きなインスタンスよりも2つの小さなインスタンスで同様に機能する場合、これはELBのコストが少し高くなり、RTOはゼロになります。価格が可用性よりも重要である場合は、元のRTOを使用して元の計画に従うことをお勧めします。

スナップショットは、AZ全体のリージョンに存在することに注意してください。リージョン全体が消えると、別のリージョンからそれらにアクセスできなくなります。