Amazon EBSボリュームサイズの縮小


25

EBSのボリュームを増やすためにこの答えを見ましたが、私は1つを縮小したいと思います。

デフォルトのUbuntu Serverイメージは15 GBですが、実際には最大2 GBしか必要ありません(データ用に別のボリュームを使用しています)。ボリュームのサイズを縮小する方法はありますか?

回答:


27

私はあなたと同じ質問を持っていたので、それを行う方法を考え出した。

最初に、これは米国東部地域のUbuntu 32ビットEBS-backed amiから行いました。他のOSまたはイメージは異なる動作をする可能性があります。ただし、ext *ファイルシステムを使用している限り、大丈夫だと思います。他のファイルシステムでも動作する可能性がありますが、自分でサイズを変更する方法を理解する必要があります。

手順は基本的に次のとおりです。

  1. 実行中のインスタンスに2つのボリュームを接続します。1つ目は縮小したいスナップショットに基づいており、2つ目は縮小したい新しいサイズの空のボリュームです。

  2. 最初のボリュームのファイルシステムを確認し、エラーを修復します。

  3. 最初のボリュームのファイルシステムを縮小して、データを保持するために必要なサイズだけにします。

  4. ファイルシステムを最初のボリュームから2番目のボリュームにコピーします。

  5. 2番目のボリュームのファイルシステムを最大サイズに拡張します。

  6. 2番目のボリュームでエラーをチェックして、すべてが正常に見えることを確認します。

  7. 2番目のボリュームのスナップショットを作成します。

  8. 取得した2番目のボリュームのスナップショットに基づいてマシンイメージを作成します。

最初に、縮小するamiから情報を取得する必要があります。特に、カーネルIDとRAMディスクIDが必要です(縮小したイメージにはRAMディスクがありませんでした)。このすべての情報は、AMIウィンドウのaws管理コンソールから利用できるはずです。

カーネルIDはkia-xxxxxxxxのように見え、スナップショットIDはsnap-xxxxxxxxのように見え、RAMディスクIDはRIA-xxxxxxxxのように見えます。

次に、Linuxインスタンスを起動します。Ubuntuインスタンスを起動しました。必要に応じて、t1.microインスタンスを使用できます。これらの次のステップを実行するのにそれほど力は必要ありません。

マシンの実行後、最初のステップで書き留めたスナップショットを添付します。私の場合、/ dev / sdfに添付しました

次に、必要なサイズの新しいボリュームを作成します。私の場合、5GBのボリュームを作成しました。これは、それを縮小したいサイズだからです。スナップショットからこの新しいボリュームを作成しないでください。新しい空のボリュームが必要です。次に、実行中のインスタンスにアタッチします。私の場合は、/ dev / sdgとしてアタッチします

次に、マシンにsshしますが、接続されたボリュームはマウントしません。

この時点で、私はパラノイアの側で間違いを犯し、エラーがないことを確認するためだけに、大容量のファイルシステムをチェックすることにしました。存在しないと確信している場合は、この手順をスキップできます。

$ sudo e2fsck -f /dev/sdf

次に、ディスク上のデータと同じサイズになるように、大容量のファイルシステムのサイズを変更しました。

$ sudo resize2fs -M -p /dev/sdf

-Mはそれを縮小し、-pは進行状況を出力します。

resize2fsはshrunkinファイルシステムの大きさを教えてくれるはずです。私の場合、4Kブロック単位でサイズを指定しました。

shrunkinファイルシステムを新しいディスクにコピーします。16MBのチャンクでデータをコピーするため、コピーする必要がある16MBのチャンクの数を把握する必要があります。これは、縮小されたファイルシステムのサイズが役立つ場所です。

私の場合、スナップショットを取る前に基本的なUbuntuシステムに他の多くのプログラムをインストールしていたため、縮小されたファイルシステムは1 GBをわずかに超えていました。おそらく、ファイルシステムのサイズを最も近い16 MBに切り上げてコピーするだけで済みますが、安全にプレイしたかったのです。

したがって、16MBチャンクの128倍= 2GB:

$ sudo dd if=/dev/sdf ibs=16M of=/dev/sdg obs=16M count=128

EBSでは読み取りと書き込みのたびに料金を支払うため、16MBのブロックでコピーしました。そのため、可能な限りそれらの数を最小限に抑えたかったのです。この方法でそれを行ったかどうかはわかりませんが、おそらく害はありませんでした。

次に、新しいボリュームにコピーしたファイルシステムのサイズを変更して、ボリューム上のすべての利用可能なスペースを使用する必要があります。

$ sudo resize2fs -p /dev/sdg

最後に、それをチェックして、すべてが正常であることを確認します。

$ sudo e2fsck -f /dev/sdg

このマシンで行う必要があるのはこれだけです。ただし、テストとして、新しいボリュームをマウントすることはできませんでした。ただし、e2fsckは問題をキャッチするはずなので、このステップはほぼ確実にオプションです。

次に、新しいボリュームのスナップショットを作成し、それに基づいてAMIを作成する必要があります。マシンはこれで完了です。必要に応じて終了できます。

小さいボリュームがマウントされている場合はアンマウントされていることを確認してから、スナップショットを作成します。繰り返しますが、これは管理コンソールで実行できます。

最後のステップには、コマンドラインec2ツールが必要です。

編集:

この回答が投稿されたので、AWSコンソールでは、スナップショットを右クリックして[スナップショットからイメージを作成]を選択できます。適切なカーネルIDを選択する必要があります。リストに表示されない場合は、適切なアーキテクチャが選択されていることを確認してください。

ec2-registerアプリケーションを使用して、取得したスナップショットに基づいてAMIを登録するため、取得したスナップショットからsnap-xxxxxxxx値を書き留めます。

次に、次のようなコマンドを使用する必要があります。

ec2-register -C cert.pem -K sk.pem -n The_Name_of_Your_New_Image
-d Your_Description_of_This_New_AMI --kernel aki-xxxxxxxx
-b "/dev/sda1=snap-xxxxxxxx" --root-device-name /dev/sda1

もちろん、カーネルIDを最初に書き留めたものと置き換え、スナップショットIDを前の手順で作成したものと置き換える必要があります。また、上記の秘密鍵(sk.pemと呼ばれる)とx509証明書(cert.pemと呼ばれる)を指定する必要があります。もちろん、名前と説明に必要なものを選択できます。

お役に立てれば。


おかげで、助けてくれました!大容量(1TBなど)の場合、この手順はマイクロインスタンスで長時間かかります。no-fsck、rsyncベースのボリュームコピー(例:ubuntuforums.org/showpost.php?p = 9866025&postcount = 27)を見てきましたが、非ルートボリュームでもddベースのアプローチははるかに信頼性が高いと感じています。
クロノス

最初のコマンドsudo e2fsck -f /dev/sdfは、サイズ変更を行う前に必要な手順である場合があります(私の特定のインスタンスであるAmazon Linux AMIにありました)。
notacouch

1
当然のことですが、AWS docsに従って、ボリューム(/ facepalm)にファイルシステムを作成することを忘れないでくださいsudo mkfs -t ext4 /dev/sdg
notacouch

1

ええ、私もこれを疑問に思っています。次のチュートリアルはやり過ぎですが、必要なツールが含まれていると思います:http : //www.linuxconfig.org/Howto_CREATE_BUNDLE_UPLOAD_and_ACCESS_custom_Debian_AMI_using_ubuntu

上記のように新しいディスクイメージにインストールする代わりに、大きなAMIを起動し、新しいEBSを作成し、実行中のインスタンスにEBSを接続し、実行中のAMIを新しいEBSにコピーする必要があります。最後に、新しいEBSをAMIとして登録します。

さらなる背景、特にfreremarkによるコメントについては、このブログ投稿をご覧くださいhttp ://alestic.com/2010/01/public-ebs-boot-amis-for-ubuntu-on-amazon-ec2

最後に、euca2oolsはec2-ami-toolsの優れた代替品のようです。euca2oolsには実際のマンページが含まれています。これらの名前はすべてec2- *コマンドと同じで、プレフィックスはeuca-のみです。 http://open.eucalyptus.com/wiki/Euca2oolsUsing


0

一般的なEC2インスタンスで使用されるボリュームのサイズを小さくしたかった。ここで他の回答と同様の手順に従いましたが、問題が発生しました。ルートボリュームを縮小するには、次のようにします。

AWSコンソールで

 1. Stop the source EC2 instance
 2. Create a snapshot of the volume you want to shrink
 3. Use the snapshot to create a new 'source' volume
 4. Created a new volume with smaller size (made sure it was big enough for the data on source)
 5. Attached both volumes to any EC2 instance (mine were /dev/sdf = source & /dev/sdg = target)
 6. Start the EC2 instance

EC2インスタンス上

 7. sudo su -   (everything from here is run as root)
 8. mkdir /source /target
 9. mount -t ext4 /dev/sdf /source
 10. mkfs.ext4 /dev/sdg
 11. mount -t ext4 /dev/sdg /target
 12. rsync -aHAXxSP /source/ /target 
     ** notice that there is no trailing '/' after target if 
       you put one there your data will be copied to 
       /target/source and you will have to move it up a directory
 13. cat /boot/grub/grub.conf  (indicated that grub is using root=LABEL=/)
 14. cat /source/etc/fstab (indicated that fstab was also using LABEL=/)
 15. e2label /dev/sdg /
 16. umount /source
 17. umount /target

AWSコンソールに戻る

 18. Stop the instance
 19. Detach ALL volumes from the instance
 20. Attach the 'target' volume to the instance using /dev/sda1 as the device
 21. Start the instance

ここで、私が見つけることができる限り言及されていない問題に遭遇しました。 インスタンスは問題なく開始されました。しかし、インスタンスにsshしようとしたときに、接続できませんでした。上記のステップの多くのバリエーションの後、私はついに、新たにスピンアップされたEC2インスタンスからルートボリュームを使用することにしました。

AWSコンソールで

 1. Create a new EC2 instance with the right sized root volume
 2. Stop the new instance
 3. Detach the /dev/sda1 volume from the new instance
    ** used the 'source' volume from before & the new volume we just detached
 4. Attached both volumes to the original EC2 instance (/dev/sdf & /dev/sdg)
 5. Start the instance with the attached volumes

EC2インスタンス上

 1. sudo su - 
 2. mkdir /source /target (only need to do this if you don't already have these directories)
 3. mount -t ext4 /dev/sdf /source
 4. mount -t ext4 /dev/sdg /target (no need to create a file system because it is already there)
 5. rsync -aHAXxSP /source/ /target 
 6. umount /source
 7. umount /target

AWSコンソールに戻る

 1. Stop the instance
 2. Detach the 'source' and 'target' volumes from instance
 3. Attach the 'target' volume to the instance from step 1 using /dev/sda1 as the device
 4. Start the instance
 5. ** we use an elastic IP so we just reassigned the IP to the new instance

これが誰かを助けることを願っています


ボリュームのサイズは、増加することはできますが、減少することはできません。スナップショットから。
Ankit Kumar Rajpoot
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.