EC2 の基本的な AMI の 1 つからいくつかの AMI を構築しています。インスタンス タイプの 1 つは Tomcat を実行しており、多くの Lucene インデックスが含まれています。別のインスタンスが MySQL を実行しており、それに応じて大量のデータが必要になります。
私がオーサリングしている AMI にそれらを含めるための最良の方法を定義しようとしています。と をマウントする/mnt/luceneと/mnt/mysql、それらは生成された AMI に含まれません。したがって、これらに対処するための好ましい方法は、それぞれに EBS を用意し、スナップショットを作成し、最新のスナップショットに基づいて独自の EBS を持つインスタンスをスピンアップすることです。それが最善の方法ですか？
インスタンスストレージのポイントは何ですか? 一時的な保管場所としてしか機能しないようですが、何が足りないのでしょうか? おそらく、Amazon が標準のラージ インスタンスで最大 800 GB のストレージを提供するのには理由があります...
インスタンスストレージは EBS より高速です。インスタンスで何をするかについては言及していませんが、一部のアプリケーションでは、耐久性よりも速度が重要になる場合があります。主に大規模なデータベースでデータ マイニングを行うアプリケーションの場合、DB をホストするローカルの高速ストレージを数百ギガ用意することが有益な場合があります。MapReduce クラスター内のワーカー ノードも、ジョブの種類によっては、インスタンス ストレージの優れた候補になる可能性があります。
インスタンス ストレージのもう 1 つのポイントは、独立していることです。多くの EBS 停止がありました (google 例 "site:aws.amazon.com ebs 停止")。インスタンスが実行されている場合は、インスタンス ストレージが利用可能です。明らかに、インスタンス ストレージに依存している場合は、複数のインスタンスを (複数のアベイラビリティ ゾーンで) 実行し、単一のインスタンスの障害を許容する必要があります。
これがゲームに遅れていることは知っていますが、もう1つ、ほとんど事実とは見なされていません...
EBS ストレージでは AMI を非常に簡単に作成できますが、インスタンス ストア ベースのストレージでは、AMI の作成をマシン自体でローカルに行う必要があり、AMI を準備、保存、登録するための一連の作業が必要になります。