問題タブ [amazon-ebs]

Amazon EC2 インスタンスでウェブサイトをホストしたいのですが、信頼性のために、基礎となるデータベースをより永続的なストレージ メディアに置きたいと考えています。ファイルのアップロードなどはありませんが、データベースのクエリと更新が迅速に行われるようにしたいと考えています。これには EBS または S3 を使用する必要がありますか?

さらに情報が必要な場合はコメントしてください

基盤となるデータベースを使用してWebサイトをホストする必要があります。インスタンス自体でデータベースを実行することも、EBSボリュームでデータベースを実行することもできます。私は頻繁にS3にバックアップする予定ですが、インスタンス自体ではなく、EBSでデータベースを実行することの利点は何であるか疑問に思いました。

私は、EBS ボリュームを毎日バックアップするための自動化メカニズムに取り組んでいます。

新しいスナップショットを作成する手順をよく知っています。どうやらそれはすべて非常に簡単です。スナップショットを作成できる EBS ボリュームがあり、いつでもスナップショットを復元できます。罰金。

しかし、私の懸念はスナップショットのサイズです。これらのスナップショットは S3 に圧縮されて保存されていることを知っています。スナップショットのサイズに応じて料金が発生します。大量のデータがある場合、作成するバックアップごとに請求額が大幅に増加します。

ただし、Amazon のページによると、これらのスナップショットは増分です。毎日のバックアップでは、最後のスナップショット以降に変更されたデータのみがアップロードされるため、これで問題は解決します。しかし、これは次の質問につながります。バックアップが増分であり、変更されたデータのみをアップロードしている場合、元のデータはどこに保存されているのでしょうか? (つまり、明らかにインクリメンタルに実行できなかった最初のスナップショット...)

残念ながら、Amazon のドキュメント全体でこの情報を見つけることができませんでした。

スナップショットとその課金の経験がある人はいますか?

助けていただければ幸いです、ありがとう！

私はCreateImage()既存のインスタンスから新しい AMI を作成するために使用していますDeleteImage()が、逆の方法で機能するものがあることを望んでいました。残念ながら、このメソッドは EC2Client には存在しません。

C# を使用して SDK から AMI を削除する適切な方法は何ですか?

次のシナリオで EC2 に PHP クラスをロードする最良の方法は何ですか (# は説明のためのものです)。-> Apache と APC を実行する 100 個の EC2 インスタンス -> リクエストごとにロードされる 100 個の php クラス (__autoload 経由) -> クラス間で 1 日あたり 100 個のコード変更 (多くのクラスには、cron によって定期的に更新される自動生成コードが含まれます)。

私が収集したものから、EC2 に php クラス ファイルをロードする方法は 3 つあります。

Apache インスタンスで APC が有効になっている場合でも、100 個のすべての Apache インスタンスでキャッシュされたクラスの無効化を 1 日に 100 回以上 (コードが変更された場合) 処理する方法がわからないため、APC で fstat を無効にできません。その結果、クラスが apc によって (fstat 呼び出しを実行するために) キャッシュされていたとしても、各クラスのロードがファイルシステムへの呼び出しを生成する場合、fstat を実行するためにネットワーク上で 100 回の往復があった場合、巨大な遅延は発生しません。またはすべての要求でファイルを読み取りますか?

説明されているシナリオでクラス ファイルをロードするための最良のオプション (または、ここにリストされていない新しい方法) は何ですか?

使用しなくなったAmazonEBSボリュームを削除できません。これは100GBのボリュームであり、デタッチ、強制デタッチ、および削除のオプションはすべて無効になっています。このボリュームを削除する方法が見つかりません。これはawsアマゾンパネル内のバグですか？

Amazon EC2+EBS が大規模な Oracle データベース (最初は 7TB) を処理できるかどうか疑問に思っています。EBS は最大 1 TB のストレージ ボリュームを持つことができ、同じ EC2 インスタンスに多くのストレージ ボリュームをアタッチすることができるようですが、データベースが 7 TB 以上に拡張できるように、これらのストレージ ボリュームを使用するように Oracle を構成することは可能ですか?

これを追求するために、私は Oracle DBA を支援してもらいますが、これが有効なアプローチであるかどうかを判断したいのですが、それとも他の方法を検討する必要がありますか?

クラウド内の大規模な (7 ～ 15 TB) データベースには、他にどのようなオプションがありますか?

EC2 で実行されている ebs-backed インスタンスがあります。私はそれを使用して、sdbに保存されている約16Gbのデータ（つまり、インスタンスに関連付けられたより大きなebsボリューム）に対して計算集約的なテキスト処理を実行しています。

このインスタンスのレプリカを作成し、それぞれに独自のデータのコピーを作成して、処理を並列化したいと考えています。インスタンスから AMI を作成できますが、イメージに sda (ルート ebs ボリューム) と、すべてのデータがあるボリュームである sdb の両方を含める必要があります。パッケージ全体のレプリカを作成するにはどうすればよいですか?

AWS マネジメント コンソールでイメージを作成すると、sda がコピーされるだけです (つまり、データを保持するには小さすぎるルート ボリューム)。

これは可能ですか？

(PS: AWS マネジメント コンソールの [Elastic Block Store] -> [Volumes] パネルに sdb ボリュームすら表示されません)

ありがとう！

私の仕事では、いくつかの既存の Enterprise Java アプリケーションを AWS に移行する必要があります。私は aws.amazon.com の多くのページに目を通し、十分にグーグルもしました。また、stackoverflow で関連するすべての質問を調べてみました。これらすべてにより、多くのことが明らかになりましたが、私はまだ混乱しています。アプリケーション構造は次のとおりです。

1. これは、Spring MVC をプレゼンテーション レイヤーとして使用し、ビジネスおよびデータ ロジックを処理するためのプレーンな Java インターフェイスおよびクラスを使用する Spring ベースのアプリケーションです。
2. MySQL は永続化のために使用されます。

したがって、アプリケーション アーキテクチャは十分に単純です。ただし、問題は、このアプリケーションの多くのインスタンスをデプロイする必要があることです。この数は現在 15 で、30 を超える可能性があります。もう 1 つのポイントは、これらすべてのインスタンスが共通のデータベースを共有していることです。

AWS に移行することで達成する必要があるのは次のとおりです。

1. アプリケーションの耐障害性が向上します。最近、専用ホスティングでサーバー/電源障害に直面し、数時間のダウンタイムが発生しました。
2. 応答時間とスループットに関して、アプリケーションのすべてのインスタンスのパフォーマンスが向上します。
3. MySQL の耐障害性が向上しました。最近、一部のハードウェア (ハード ドライブ) が原因で、サーバーの 1 つでアプリケーション インスタンスがダウンし、基本的に MySQL が予期せず停止しました。ハード ドライブのファイル システム全体が読み取り専用になり、そのサーバーでホストされているアプリケーション インスタンスの誤動作が発生しました。
4. インフラストラクチャ管理の総コストとオーバーヘッドを明らかに削減します。

これまでAWSインフラストラクチャを理解できる限り、セットアップのためにAWSで必要なものは次のとおりです。

1. Tomcat と MySQL がインストールされた EBS ベースの LINUX AMI の 4 つのインスタンス。それぞれが約 10 のアプリケーション インスタンスをホストします。
2. これら 4 つのインスタンスのそれぞれに対して、フォールト トレランス用に 1 つのインスタンスが必要であり、合計で 8 つのインスタンスが必要になると推測しています。
3. すべてのサーバー インスタンスには、約 160 GB の EBS があります。
4. 4 つのエラスティック IP
5. 4 つのエラスティック ロード バランサー
6. スナップショットなどのその他のもの

ここに私の質問があります：

1. EBS が AWS によって自動的にバックアップされ、ハードウェア障害が発生した場合に新しい EBS に同じデータを提供することを考えると、メイン サーバー インスタンスごとに追加のサーバー インスタンス (フォールト トレランス用) が本当に必要ですか?

2. 上記のシナリオで、すべてのサーバー インスタンス (4x2) 間でデータベースを共有するにはどうすればよいですか? 私が見ている 1 つのオプションは、これらのサーバー インスタンス間で MySQL クラスタリングを実装することです。たとえば、MySQL クラスターに 1 つの管理ノード、3 つの SQL ノード、および 4 つのデータ ノードが含まれているとします。ただし、この場合、クラスターを維持することは私たちにとって追加のオーバーヘッドになり、インフラストラクチャ管理を取り除きたいため、これは受け入れられない可能性があります.

3. データベースの代わりに RDS を使用し、すべてのサーバーインスタンス (4x2) から MySQL インスタンスを削除する必要がありますか? はいの場合、EC2 インスタンスに加えて RDS インスタンスを購入する必要がありますか (RDS 用に別のインスタンスを購入する必要がある場合、インフラストラクチャ全体のコストは少なくとも 75% 増加すると思います)、または RDS インスタンスはコンピューティング ユニットも提供します。アプリケーション開発のために、アプリケーション展開のためのインスタンスの総数を減らしますか?

4. RDS 実装の場合、EBS ベースの EC2 インスタンスが本当に必要ですか? RDS インスタンスを配置した EC2 インスタンスから EBS 要件を取り除くことができれば、総コストを削減できます。

問題を特定するのが明確でなく、任意の点についてさらに明確にする必要がある場合はお知らせください。

次のように /dev/sdh に EBS ボリュームを作成しました。

このチュートリアルhttp://aws.amazon.com/articles/1663に従って、「EBS ボリュームに XFS ファイル システムを作成」しようとしています。

しかし、私がそれをやろうとすると、次のようになります:

コンソールで EBS ボリュームを見ると、正常に動作しているようです。

編集: このインスタンスは EBS ストア インスタンスではありません。これは、EBS を使用できないということですか?