タグ付けされた質問 「amazon-ebs」

これは、ec2サービスに関するAmazonのストレージサービスに関する質問です。

4
Amazon EC2の用語-AMI対EBS対スナップショット対ボリューム
私はAmazon EC2をいじくり回してきましたが、いくつかの用語について少し混乱しています。特にAMI、スナップショットとボリューム、およびEBSに関して 間違っている場合は修正してください。または、次のステートメントの重大なギャップを埋めてください。 AMI(Amazon Machine Image)は、オペレーティングシステムと構成の完全な「ディスク」キャプチャです。インスタンスを起動すると、AMIから起動します EBS(Elastic Block Storage)は、特定のAMIから起動した後に行った変更の状態を保持する方法です。私の考えでは、これはインスタンスとAMIの最終状態の差分のようなものです。 スナップショットは...まあ、よくわかりません。特定のインスタンスのスナップショットであると想定することはできますが、これがEBSに保存されている状態とどのように異なるかは明確ではありません。スナップショットは、既存のインスタンスからEBS AMIを作成することとどのように異なりますか? ボリュームは... AMI / EBSペアがロードされるマウントされたディスクスペースのように見えますか?私もこれについてはわかりません。(AWSコンソールから)スナップショットからボリュームを作成できること、およびボリュームをアタッチ/デタッチできることがわかりますが、その理由とタイミングは明確ではありません。

2
スナップショットの進行中にAmazon EBSボリュームを使用しても安全ですか?
スナップショットの作成中にEBSボリュームを使用しても安全ですか? 現在、100Gb EBSボリュームをマウントしています。現在スナップショットを作成中です。良さは遅い!! スナップショットに45分以上かかることになります。 私の質問:EBSボリュームはすでにコピーされており、どこかに保存されていますか?または、現在、スナップショットはマウントされたボリュームからアクティブにコピーしていますか? 基本的に、スナップショットが完了する前に使用を開始した場合、ホースは使用されますか? コピーに時間がかかるとは信じられません。使用中の100GBでさえありません。25Gbのようなものです。


3
Amazon EBSボリュームサイズの縮小
サーバーフォールトで回答できるため、 この質問はStack Overflowから移行されました。 9年前に移行され ました。 EBSのボリュームを増やすためにこの答えを見ましたが、私は1つを縮小したいと思います。 デフォルトのUbuntu Serverイメージは15 GBですが、実際には最大2 GBしか必要ありません(データ用に別のボリュームを使用しています)。ボリュームのサイズを縮小する方法はありますか?

4
Amazon EC2データ永続性
サーバーフォールトで回答できるため、 この質問はStack Overflowから移行されました。 10年前に移行され ました。 Amazon EC2 FAQによると、インスタンスが終了すると、データは失われます。インスタンスが再起動された場合にデータを保持するためにどのような手順を実行できますか?私はEBSとS3を検討していました-これらのいずれかがアクティブなデータベースを保存するのに役立ちますか?とにかくインスタンスはどのくらいの頻度で再起動されますか?

3
EBSとSSDの定義
インスタンスを作成する際のEBSとSSDの選択について混乱しています。 インスタンスパラメータを選択している間(ステップ2)、[ インスタンスストレージ(GB) ]列に2つのオプションが表示されます: EBSのみまたはSSD。 SSDとEBSは異なるものであるため、なぜこのオプションが存在するのか分かりません。なぜ一方を選択し、他方を選択しないのですか。 以下のインスタンスストレージ(GB)の定義は 、すべてが永続的であるため上記と矛盾しています。(列名にカーソルを合わせると、この定義が表示されます) インスタンスで使用可能なローカルインスタンスストアボリューム。インスタンスストアのデータは永続的ではありません。インスタンスの存続期間中のみ保持されます。 ステップ4で再びSSDまたは磁気を選択する必要があるのはなぜですか? どんな説明でも役立ちます。

1
実行中のインスタンスからのEC2 AMIイメージの作成とボリュームスナップショットからの作成
LinuxベースのEC2インスタンスをダウンタイムなしで実行中にバックアップし、後で新しいインスタンスを起動します。(インスタンスはWebサーバーとPostgresデータベースを実行しています。) これを行うには2つの方法があることがわかりましたが、それらの結果の違いについて混乱しています。 オプション#1:実行中のインスタンスからAMIを直接作成します。 実行中の元のインスタンスから新しいAMIを直接作成します。 AMIから新しいインスタンスを起動します オプション#2:スナップショットからAMIを手動で作成します。 実行中の元のインスタンスに接続されたボリュームからスナップショットを取得します スナップショットからAMIを作成し、アーキテクチャやカーネルIDなどの詳細を手動で入力します 手動で作成されたイメージから新しいインスタンスを起動します 紛らわしいのは、インスタンスから直接AMIを作成すると、EC2がデフォルトでインスタンスを再起動することです。次のツールチップのチェックボックス「再起動なし」があります。 有効にすると、Amazon EC2はイメージを作成する前にインスタンスをシャットダウンしません。このオプションを使用すると、作成されたイメージのファイルシステムの整合性は保証されません。 これら2つの方法のオプションの結果に本当に違いはありますか?私にとっては、とにかく自動化ウィザードが行うのと同じことを手動で行っているように感じます。スナップショットを生成し、カーネルIDとアーキテクチャを選択します。 なぜ一方に警告テキストがあり、もう一方にはないのですか?実行中のインスタンスのスナップショットは比較的安全であると見なされます。AMI作成でバックグラウンドでスナップショットを作成する場合、すべてを手動で行うよりも危険ですか?

1
Amazonスナップショットの実際のサイズを決定する方法は?
Amazon EBSスナップショットは、変更されたブロックをベースラインからキャプチャするため、多くの場合、スナップショットはソースボリュームよりはるかに小さくなります。請求は実際のサイズに基づいて行われますが、これは素晴らしいことです。ただし、スナップショットの実際のサイズを特定する方法は見つかりません。ec2-describe-snaphotsは、スナップショットされたボリュームのサイズのみを提供します。 他に理由がなければ、請求を確認するためにこの情報が必要です。しかし、ボリュームを再構成することで、またボリュームで何をするかによって、増分スナップショットのサイズを削減できることを発見できる可能性があるため、それも必要です。



4
EBSボリュームサイズではないEC2ドライブ
500GB EBSボリュームを作成したEC2インスタンスがあります。残念ながら、EC2インスタンスには8GBしか使用できません。 ドライブは1つしかありませんが、これは正しいです。 [root@ip-10-244-134-250 ~]# ls -la /dev/x* brw-rw---- 1 root disk 202, 1 Aug 7 08:54 /dev/xvda1 しかし、そのドライブはわずか8GBです [root@ip-10-244-134-250 ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda1 8.0G 1.3G 6.7G 16% / tmpfs 3.7G 0 3.7G 0% /dev/shm ただし、fdiskと/ proc / partitionsは両方とも正しいサイズを示します [root@ip-10-244-134-250 ~]# fdisk -l …

4
AWS EBSルートボリュームサイズを減らす方法
EC2インスタンスを拡大するのは簡単です(たとえば、AMIを作成し、そこからインスタンスを起動してから、ストレージサイズを変更するなど)。 しかし、それを減らすことはより困難になります。Amazon Web Services(AWS)EC2インスタンスのElastic Block Store(EBS)のルートボリュームサイズを縮小したいと思います。ネット上にはいくつかの古い高レベルの手順があります。私が見つけたより詳細なバージョンは、StackOverflowの質問に対する1年前の答えです:どのようにebsボリューム容量を減らすことができますか、ステップはかなり高いレベルです: 希望するサイズの新しいEBSボリュームを作成します(例/ dev / xvdg) インスタンスを起動し、両方のEBSボリュームをそれに接続します (元のルートボリュームの)ファイルシステムを確認します。(例)e2fsck -f / dev / xvda1 元のルートボリュームを最大に縮小します(例:ext2 / 3/4)resize2fs -M -p / dev / xvda1 ddを使用してデータをコピーします。 チャンクサイズを選択します(16MBが好きです) チャンクの数を計算します(resize2fs出力のブロック数を使用):blocks * 4 /(chunk_size_in_mb * 1024)-安全のためにビットを切り上げます データをコピーします:(例)dd if = / dev / xvda1 ibs = 16M of = / dev / xvdg …

4
EC2インスタンスを実行するための最速時間
VPSからEC2への移行を検討しています。EC2は弾力性があり、価格も同じです。インスタンスをオンデマンドで起動し、1時間ごとにインスタンスがアクティブにならない場合はシャットダウンすることができます。 そのプロセスにはどれくらい時間がかかりますか?EBSから起動するマイクロインスタンスを想定しています。Linux(おそらくUbuntu)を想定しています。Windowsで言及された10分の時間は私を感動させない。遷移はec2-run-instance(保留状態で)またはである可能性がありますec2-start-instance。他のクラウドを知っていれば、他のクラウドの起動時間についてもお気軽にご連絡ください。

1
EC2インスタンス用の一時ストレージはどこですか
次の質問、特にAmazon EC2で「Instance Store Volumes」ストレージを使用する方法を確認しました。 しかし、答えはありませんでした。EBSをルートデバイスとしてEC2スモールインスタンスを作成しました。AWSインスタンスタイプは、 160ギガバイトの「インスタンスストア」をリストアップ。しかし、それはどこですか? $ df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda1 7.9G 3.6G 4.3G 46% / tmpfs 1.9G 0 1.9G 0% /dev/shm $ mount /dev/xvda1 on / type ext4 (rw,noatime) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on …

4
EBSボリュームを新しいスポットインスタンスに自動接続しますか?
私はEC2スポットインスタンスを実験していますが、終了間でデータを保持する必要があります。今理解したように、現在の価格が上限を超えたとき。入札すると、自動的に終了します。私が持っている初期化スクリプトはすべてシャットダウン時に実行されるので、アンマウントする前にデータをEBSにプッシュできると想定しています。 私の質問は、最初にルートボリュームにロードしたinitスクリプトがないため、価格が下がったら新しいEBSインスタンスに同じEBSボリュームを自動的にマウントするにはどうすればよいですか? カスタムAMIを作成する必要がありますか、またはこれを達成する他の方法はありますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.