Amazon EBSボリュームサイズの拡大
AmazonのEC2およびEBSサービスには非常に感銘を受けました。 EBSボリュームを拡大できるかどうかを知りたかった。
例：50 GBのボリュームがあり、スペースが不足し始めた場合、必要に応じて最大100 GBまで増やすことができますか？
すべての優れた推奨事項と、必要な変更を実行するためにAmazon Web UIツールを使用してWindows Amazon EC2 EBSインスタンスを拡張することに関連するこの記事を追加すると思いました。 CLIの使用に不安がある場合、これによりアップグレードがはるかに簡単になります。
http://www.tekgoblin.com/2012/08/27/aws-guides-how-to-resize-a-ec2-windows-ebs-volume/
この記事を投稿してくれたTekGoblinに感謝します。
ストレージを拡張できますが、その場で実行することはできません。現在のブロックのスナップショットを作成し、新しい大きなブロックを追加して、スナップショットを再添付する必要があります。
簡単なウォークスルーがあります hereAmazonのEC2コマンドラインツール
必要に応じてその場でより多くのスペースを単に「バンプイン」することはできませんが、スナップショットでパーティションのサイズを変更できます。
手順は次のとおりです。
- eBSボリュームのマウント解除
- ebsスナップショットを作成します
- より多くのスペースを持つ新しいボリュームを追加します
- パーティションテーブルを再作成し、ファイルシステムのサイズを変更します
- 新しいebsボリュームをマウントします
http://aws.Amazon.com/ebs/ をご覧ください-EBSスナップショット：
スナップショットは、複数の新しいボリュームのインスタンス化、ボリュームのサイズの拡張、またはアベイラビリティーゾーン間でのボリュームの移動にも使用できます。新しいボリュームが作成されると、既存のAmazon S3スナップショットに基づいて作成するオプションがあります。そのシナリオでは、新しいボリュームは元のボリュームの正確なレプリカとして始まります。オプションで異なるボリュームサイズまたは異なるアベイラビリティーゾーンを指定することにより、この機能を使用して、既存のボリュームのサイズを増やしたり、新しいアベイラビリティーゾーンに複製ボリュームを作成したりできます。スナップショットを使用してボリュームのサイズを変更する場合、ファイルシステムまたはアプリケーションがデバイスのサイズ変更をサポートしていることを確認する必要があります。
私はすべての答えに従いました、すべてはすべての点で欠けているものがあります。
これらの手順に従うと、EBSボリュームを増やしてデータを保持できます（これはルートボリューム用ではありません）。簡単にするために、AWS consuleを使用してスナップショットを作成することをお勧めします。AWSコマンドラインツールを使用して行うこともできます。
ここではルートボリュームに触れていません。
AWSコンソールに移動します。
- インスタンスをシャットダウンします（数分間のみです）
- 成長させる予定のボリュームを切り離します（/ dev/xvdfなど）
- ボリュームのスナップショットを作成します。
- 作成したスナップショットを使用して、より大きなサイズの新しいボリュームを作成します
- 新しいボリュームをインスタンスにアタッチします
- インスタンスを開始します
インスタンスへのSSH：
$ Sudo fdisk -l
これにより、次のようになります。
Disk /dev/xvdf: 21.5 GB, 21474836480 bytes
12 heads, 7 sectors/track, 499321 cylinders, total 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xd3a8abe4
Device Boot Start End Blocks Id System
/dev/xvdf1 2048 41943039 20970496 83 Linux
StartおよびId値を書き留めます。 （この場合は2048と83）
Fdiskを使用して、パーティションxvdf1を削除し、同じブロック（2048）から正確に始まる新しいパーティションを作成します。同じID（83）を指定します。
$ Sudo fdisk /dev/xvdf
Command (m for help): d
Selected partition 1
Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-41943039, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-41943039, default 41943039):
Using default value 41943039
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 83
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
この手順については、こちらで詳しく説明しています： http://litwol.com/content/fdisk-resizegrow-physical-partition-without-losing-data-linodecom
ほぼ完了し、ボリュームをマウントしてresize2fsを実行するだけです。
Ebsボリュームをマウントします：（私の場所は/ mnt/ebs1です）
$ Sudo mount /dev/xvdf1 /mnt/ebs1
サイズを変更します。
$ Sudo resize2fs -p /dev/xvdf1
resize2fs 1.42 (29-Nov-2011)
Filesystem at /dev/xvdf1 is mounted on /mnt/ebs1; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
Performing an on-line resize of /dev/xvdf1 to 5242624 (4k) blocks.
The filesystem on /dev/xvdf1 is now 5242624 blocks long.
ubuntu@ip-xxxxxxx:~$
できた！ df -hを使用して、新しいサイズを確認します。
数分のダウンタイムで問題ない限り、Eric Hammondは実行中のEBSインスタンスのルートディスクのサイズ変更に関する良い記事を書いています： http://alestic.com/2010/02/ec2-resize -running-ebs-root
これは、AWSマネジメントコンソールから実行できます。プロセスは他の回答と同じですが、コマンドラインに移動する必要がなくなりました。
私の手順：
- インスタンスを停止する
- インスタンスに接続されているebsボリュームを見つけて、そのスナップショットを作成します
上記のスナップショットを使用して、より大きなディスク容量を持つ新しいボリュームを作成します。残念ながら、スナップショットを作成するためのawsコンソールのUIは、aws上のすべてのスナップショットを一覧表示しているため、ほとんど使用できません。コマンドラインツールの使用は、次のようにはるかに簡単です。
ec2-create-volume -s 100 --snapshot snap-a31fage -z us-east-1cインスタンスから既存のebs（より小さい）ボリュームをデタッチします
- 新しい（より大きな）ボリュームをインスタンスにアタッチし、インスタンスが期待しているのと同じデバイスにアタッチします（私の場合は/ dev/sda1です）
- インスタンスを開始する
できました！
上記の手順3以外に、aws管理コンソールを使用してすべてを実行できます。
ここで述べたように注意してください：
https://serverfault.com/questions/365605/how-do-i-access-the-attached-volume-in-Amazon-ec2
ec2インスタンスのデバイスは/ dev/xv *である場合がありますが、aws Webコンソールは/ dev/s *であることを通知します。
ところで：物理ディスクと同様に、LVMを使用すると便利かもしれません。例：
http://www.davelachapelle.ca/guides/ubuntu-lvm-guide/ http://www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/
大きな利点：スペースを動的に追加（または削除）できます。
また、インスタンス間で簡単に移動できます。
警告：
- 事前に設定する必要があります
- 単純なJBODセットアップでは、1つの「ディスク」を失うとすべてが失われます
Windows OSの場合は「diskpart」コマンドを使用します。こちらをご覧ください。 http://support.Microsoft.com/kb/300415 を使用してください。ダイナミックディスク）
スナップショットを作成したら、古いEBSボリューム（たとえば600GB）をマウント解除し、より大きなEBSボリューム（たとえば1TB）を作成し、この新しいEBSボリュームをマウントします。 atコマンドプロンプト（管理者として実行）
diskpart.exe
disk = 9を選択します
ボリューム= Zを選択
伸ばす
[ディスク9、Zというラベルの付いたボリュームは、サイズ600GBのec2スナップショットから作成されたサイズ1TBのボリュームでした。600GBを1TBにサイズ変更したいので、上記の手順に従ってこれを行うことができました。]
ルートボリュームがxfsファイルシステムの場合、このコマンドxfs_growfs /を実行します
オペレーティングシステムでサポートされている場合、すべてのEBSボリュームに論理ボリュームマネージャー（LVM）を強くお勧めします。 Linuxディストリビューションは一般的にそうです。それにはいくつかの理由があります。
論理ボリュームのサイズ変更と移動はライブで実行できるため、ダウンタイムを必要とするオフラインスナップショット全体の代わりに、別の大きなEBSボリュームを追加して、物理ボリューム（PV）としてLVMプールに追加し、論理ボリューム（LV）を追加し、プールから古い物理ボリュームを削除し、古いEBSボリュームを削除します。次に、論理ボリュームのサイズを変更し、その上のファイルシステムのサイズを変更します。これにはダウンタイムはまったく必要ありません！
ストレージを「物理」デバイスから抽象化します。ダウンタイムやマウントポイント/ fstabの変更を必要とせずにデバイス間でパーティションを移動することは非常に便利です。
AmazonがEBSボリュームをその場でサイズ変更できるようになればいいのですが、LVMではそれほど必要ではありません。