web-dev-qa-db-ja.com

aws ec2インスタンス/エフェメラルストレージのバックアップを作成するにはどうすればよいですか?

Ec2インスタンスに付属するエフェメラルストレージを使用して、データベースを/ mntに保持しています。 ec2 apiツールを使用してバックアップを作成するには、ボリュームIDが必要ですが、awsコンソールでは8GBのルートストレージのみのボリュームIDを見つけることができます。

エフェメラルストレージのバックアップが必要な場合はどうすればよいですか?インスタンスストレージをバックアップするための代替手段はありますか?

17
Smita

何よりもまず、エフェメラルストレージに永続的な価値のあるものを保存しないでくださいAmazon EC2 自分が何をしているかを正確に知っている場合を除き、常に特定の時点のバックアップなどを用意する準備ができています。-あなたの質問のようで、一時的なストレージの概念について誤解されている可能性がありますAmazon EC2インスタンスストレージAmazon EBS と、データの安全性とバックアップ要件に関する重要な意味のそれぞれの違い:

エフェメラルストレージ停止/開始サイクルで失われますおよび通常はなくなる可能性がありますなので、絶対にありません永続的な価値のあるものをそこに置きたい、つまり一時的なデータだけをそこに置くと、簡単に失ったり再構築したりできますスワップファイルや、計算中に使用されている厳密な一時データなど。もちろん、たとえばそこに巨大なインデックスを保存することもできますが、何らかの理由(インスタンスの再起動、ハードウェア障害など)でストレージがクリアされた後、これらを再構築する準備をする必要があります。

問題解決

これらの説明は、EBSボリューム(つまりEBSスナップショット)にのみ適用されるメカニズムでエフェメラルストレージボリュームをバックアップできない理由を明確にする必要があります。したがって、前者は、選択した通常のオペレーティングシステムレベルのバックアップツールを介してバックアップできます。たとえば、私の回答で説明したように、 Duplicity がオプションで促進される一般的な選択肢です Amazon S to ライブLinuxサーバー用のバックアップソフトウェアを使用するのが最も簡単

30
Steffen Opel

エフェメラルストレージ、またはインスタンスストレージは、そのまま/ tmpフォルダーのようなもので、再起動するとその内容が消えます。もちろん、エフェメラルドライブの内容はソフトリブートで破棄されませんが、インスタンスがいつ終了するかを現実的に制御または予測することはできないため、破棄されたかのように扱う必要があります。

これはすでに指摘されています。

私が指摘したいのは、AMIを適切に作成および構成した場合でも、実際のストレージ用にEBSドライブを保持している限り、エフェメラルストレージを使用してスループットを大幅に向上(読み取り)できるということです。

私が現在使用しているのは、bcacheを備えたLinux(Ubuntu Tahr)インスタンスです。これは主に、bcacheカーネルのサポートが比較的新しく(IIRC、bcacheを使用した最初のサポートは3.10でした)、できるだけ新しいカーネルが必要なためです。また、TahrはUbuntuの次のLTSバージョンであり、私のプロジェクトが立ち上げに近づいたときに最終版になります;)

Bcacheは、デフォルト構成で、EBSの永続性を提供しながら、エフェメラルストレージのread速度の恩恵を受けることができます。高速キャッシュが必要です。デバイス(エフェメラルSSD)を使用して、低速デバイス(EBS)を高速化し、キャッシュデバイスを介して書き込みます(つまり、エフェメラルキャッシュとEBSに同時に書き込みます)。

つまり、インスタンスがクラッシュしたり停止したりした場合でも、キャッシュなしでEBSボリュームを直接マウントし、EBSボリュームのみを使用する場合と同じようにすべてのデータにアクセスできます。また、ワイプされたエフェメラルデバイスを再構成し、それらをEBSのキャッシュとして再構成して、非常に高速な読み取りとシークを楽しむこともできます。

私の特定のセットアップは、mdadmを使用してストライプモードでレイドされた2つのEBSデバイスと、同じ方法でレイドされた2つのエフェメラルSSDデバイスです。次に、エフェメラルアレイをキャッシュとして使用し、EBSアレイを「バックアップ」デバイスとして使用して、bcacheを使用してそれらを構成しました。 EBSドライブは任意のサイズにすることができ、いつでも拡張できます(EC2では、現在のEBSボリュームのスナップショットを作成してから、そのスナップショットに基づいて新しい大きなボリュームを作成する必要があるため、少し注意が必要です。サイズを変更することはできません。既存のEBSボリューム)。

もちろん、起動時にインスタンス内で実行されるスクリプトを作成して、エフェメラルストレージを構成し、EBSでバックアップされたバックアップデバイスのキャッシュデバイスとして接続する必要があります。 mdadm および bcache を読み、実験することをお勧めします。

記録のために、Cassandraストレスツールでテストすると、エフェメラルでキャッシュされたEBSボリュームでbetter読み取りパフォーマンスが得られます一時的なドライブをストライピングするよりもドライブです。これは、bcacheで使用されているアルゴリズムが非常に巧妙であるためです。

エフェメラルドライブをキャッシュとして使用すると、ネットワークトラフィックが減少し、EBSのI/Oが減少し、それによって毎月の請求額が減少するため、費用効果が高くなります。

また、bcacheが提供するさまざまなタイプのキャッシュにも注意してください。

  1. 書き戻し:SSDを読み取り/書き込みデバイスとして使用し、ページをキャッシュから削除する必要がある場合にのみバックアップデバイスに書き込みます。これはnotEC2エフェメラルセットアップには役立ちません。これは、クラッシュまたは停止時にバックアップデバイスが役に立たなくなるためです。
  2. ライトスルー:すべての書き込みはキャッシュとバックアップの両方に送られます。これにより、バックアップデバイスは常にキャッシュデバイスと同じくらい最新であり、キャッシュデバイスなしでいつでも使用できます。 EC2に役立ちます。
  3. ライトアラウンド:すべての書き込みはバックアップデバイスに直接送信され、将来そのデータに対して読み取り要求が発生するまでキャッシュデバイスに書き込まれません。読み取りのみがキャッシュデバイスにキャッシュされます。これはライトスルーと同じくらい安全であり、書き込みが近い将来に読み取られる可能性が低いことがわかっている場合に役立ちます。これにより、頻繁に要求されないデータでキャッシュデバイスがいっぱいになるのを回避できるため、isが要求されたデータ用のスペースが増えます。いくつかの例としては、ファイルアップロードサーバー、大量のログデータを書き込むシステムなどがあります。データセット全体が一時的なストレージサイズよりも大幅に大きいことがわかっている場合は、これが最も効率的である可能性があります。多数のユースケースでのオプション。

ソフトウェアRAIDミラーを設定できる場合は、EBSでバックアップされたディスクをインスタンスに接続し、ミラーを設定して、レプリケーションが完了するのを待つことができます。インスタンスを作成した後、このメソッドを使用して「エフェメラル」データをEBSに移動することに成功しました(シャットダウンして再起動したくありませんでした)。

EBSのデータを取得したら、EBSイメージでバックアップします。

この方法は、異なる同一のインスタンスで実行されているデータの複数のコピーがある場合に特にうまく機能しますが、EBSに永続化する必要があるのはそのうちの1つだけです(私の場合、Couchbaseサーバーを使用すると、CBデータはエフェメラルドライブにありましたが、私は1つ持っていましたEBSにミラーリングされたインスタンスのうち、クラスター上のすべてのデータがEBSに格納されるようになりました)。

2
theMayer

(EBSスナップショットに基づかない)ファイルレベルのバックアップソリューションは、エフェメラルストレージをバックアップできます。とはいえ、エフェメラルストレージをいつ使用するかを検討し、永続データに使用する十分な理由がある必要があります。 Cassandraなどの特定のアプリケーションでは、これが推奨される構成です。その場合、バックアップソリューションは、ほとんどの場合、エフェメラルストレージからスナップショットされるEBSボリュームに、または直接S3にデータをダンプします。場合によっては、レプリケーションを定義して、エフェメラルデバイス内のすべてのデータがEBSボリュームにもレプリケートされるようにすることができます。

0
OK1