EC2はサイズを増やした後にボリュームのサイズを変更できません

95

EC2ボリュームのサイズ変更の手順に従いました

  1. インスタンスを停止しました
  2. 現在のボリュームのスナップショットを取った
  3. 以前のスナップショットから、同じリージョンでサイズの大きい新しいボリュームを作成しました
  4. インスタンスから古いボリュームを切り離しました
  5. 同じマウントポイントでインスタンスに新しいボリュームを接続しました

古いボリュームは5GBで、私が作成したボリュームは100GBですが、インスタンスを再起動して実行すると、df -h Iこれが表示されます

Filesystem            Size  Used Avail Use% Mounted on
/dev/xvde1            4.7G  3.5G 1021M  78% /
tmpfs                 296M     0  296M   0% /dev/shm

これは私が走っているときに得られるものです

sudo resize2fs /dev/xvde1

The filesystem is already 1247037 blocks long.  Nothing to do!

私が走れば私cat /proc/partitionsは見る

 202       64  104857600 xvde
 202       65    4988151 xvde1
 202       66     249007 xvde2

私が正しい手順を実行したかどうかを理解すると、xvdeはxvde1と同じデータを持っているはずですが、それを使用する方法がわかりません

新しいボリュームを使用する方法、または代わりにxvde1をアンマウントしてxvdeをマウントするにはどうすればよいですか？

何が悪いのか理解できません

私も試しました sudo ifs_growfs /dev/xvde1

xfs_growfs: /dev/xvde1 is not a mounted XFS filesystem

ところで、これはCentOS 6.2 x86_64のLinuxボックスです

あなたの助けを事前にありがとう

amazon-ec2  centos  volume  image-resizing  snapshot 
— ウィルマンアランビレーテ
ソース

回答:

70

コマンドが正しく機能したウィルマンに感謝します。EBSをより大きなサイズに増やす場合は、小さな改善を考慮する必要があります。

  1. インスタンスを停止します
  2. ボリュームからスナップショットを作成する
  3. サイズを増やしているスナップショットに基づいて新しいボリュームを作成します
  4. 現在のボリュームマウントポイント（つまり/dev/sda1）を確認して記憶します
  5. 現在のボリュームを切り離す
  6. 最近作成したボリュームをインスタンスに接続し、正確なマウントポイントを設定します
  7. インスタンスを再起動します

  8. SSH経由でインスタンスにアクセスして実行する fdisk /dev/xvde

    警告：DOS互換モードは非推奨です。モードをオフにし（コマンド 'c'）、表示単位をセクターに変更する（コマンド 'u'）ことを強くお勧めします

  9. ヒット pして現在のパーティションを表示

  10. ヒット dして現在のパーティションを削除します（複数ある場合は、一度に1つ削除する必要があります）注：データが失われないことを心配しないでください
  11. ヒット nして新しいパーティションを作成します
  12. ヒット pしてプライマリとして設定
  13. ヒット 1して最初のシリンダーを設定します
  14. 希望する新しいスペースを設定します（空の場合、スペース全体が予約されます）
  15. ヒット aして起動可能にする
  16. ヒット1とw書き込み変化へ
  17. インスタンスを再起動するか、partprobe（からpartedパッケージ）をてカーネルに新しいパーティションテーブルを通知します
  18. SSH経由でログを記録し、resize2fs / dev / xvde1を実行します。
  19. 最後に、df -hを実行して新しいスペースを確認します。
— DCF
ソース
1
「警告：DOS互換モードは非推奨です。モードをオフにし（コマンド 'c'）、表示単位をセクターに変更する（コマンド 'u'）ことを強くお勧めします」これは私には必要ありませんでした（Ubuntu 13.04）。それはすでにDOS互換性をオフにし、デフォルトでセクターを使用していました。を押してc、u実際に非推奨モードに切り替えました。
— wisbucky 2013年
6
ソリューションは見事に機能しましたが、インスタンスは感嘆符（ReadHat 6.5）で「1/2チェックに合格しました」でスタックしました。これを修正するために、「最初のシリンダー」を16に設定しました（以前と同様）。その後、インスタンスは「2/2チェックに合格」で正常に起動しました。これが誰かを助けることを願っています...
— user3586516 14
1
私も最初のシリンダーを変更する必要がありましたが、2048に変更する必要がありました。削除する前に、現在のパーティション設定を確認することをお勧めします。
— Doyley 2014年
9
インスタンスを再起動した後、SSH経由で接続できません。接続がタイムアウトし、awsコンソールにステータスチェックを開始できないことが表示されます。死んだと思います。どうすればいいですか？
— Richard
5
AWSがEBSボリュームのオンラインサイズ変更をサポートするようになったため、この回答は廃止されました。
— デールアンダーソン
303

サイズを変更するためにインスタンスを停止してEBSボリュームをデタッチする必要はもうありません！

2017年2月13日Amazonが発表：「Amazon EBSアップデート–新しいエラスティックボリュームがすべてを変える」

拡張するボリュームが実行中のインスタンスのルートボリュームであっても、プロセスは機能します。

Ubuntuのブートドライブを「オンザフライ」で8Gから最大16Gに増やしたいとしましょう。

ステップ-1）AWSウェブコンソールにログイン-> EBS->サイズを変更したいものを右クリック->「ボリュームの変更」->「サイズ」フィールドを変更し、[変更]ボタンをクリック

ここに画像の説明を入力してください

ここに画像の説明を入力してください

ここに画像の説明を入力してください

ステップ2）インスタンスにsshしてパーティションのサイズを変更

します。ボックスに接続されているブロックデバイスをリストします。 
lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  16G  0 disk
└─xvda1 202:1    0   8G  0 part /

ご覧のとおり、/ dev / xvda1は16 GiBデバイスの8 GiBパーティションであり、ボリュームには他のパーティションはありません。「growpart」を使用して、8Gパーティションのサイズを最大16Gに変更します。

# install "cloud-guest-utils" if it is not installed already
apt install cloud-guest-utils

# resize partition
growpart /dev/xvda 1

結果を確認してみましょう（/ dev / xvda1が16Gになったことがわかります）。

lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  16G  0 disk
└─xvda1 202:1    0  16G  0 part /

SOの回答の多くは、パーティションを削除/再作成してfdiskを使用することを提案しています。これは、特にブートドライブを変更するときに、厄介でリスクが高く、エラーが発生しやすいプロセスです。

ステップ3）ファイルシステムのサイズを変更して、新しいパーティションスペースを完全に使用できるように拡張する 
# Check before resizing ("Avail" shows 1.1G):
df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      7.8G  6.3G  1.1G  86% /

# resize filesystem
resize2fs /dev/xvda1

# Check after resizing ("Avail" now shows 8.7G!-):
df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       16G  6.3G  8.7G  42% /

したがって、ダウンタイムがなく、使用する新しいスペースがたくさんあります。
楽しい！

更新：更新：XFSファイルシステムでは、resize2fsの代わりにsudo xfs_growfs / dev / xvda1を使用します。

— ドミトリー・シェブコプリアス
ソース
パーティションのサイズ変更は大きな助けでした.... !! 最も素晴らしいことは、ルートボリュームでも機能することです。
— piyushmandovra 2017年
4
誰かがこれを正しい答えとして受け入れてくれますか？なぜなら...それはそうです。
— エドゥアルドール2017
— 確かに
4
ええと、公式のドキュメントはgrowpartについて言及していません、それが私が以前これを動作させることができなかった理由です。ありがとう！
— イブラヒム、
1
@シーハ、はい。それがすべてのポイントです。起動可能な「ルート」マウントドライブでさえ、再起動を必要とせずに安全に増やすことができます！
— Dmitry Shevkoplyas
42

上記のjperelliによる完全なコメント。

今日も同じ問題に直面しました。AWSのドキュメントでは、growpartについて明確に言及されていません。私は難しい方法を見つけました、そして実際に2つのコマンドはUbuntuでM4.largeとM4.xlargeで完全に機能しました

sudo growpart /dev/xvda 1
sudo resize2fs /dev/xvda1
— サチン・シントレ
ソース
添付するための2番目の回答とこの回答はサイズ変更のためです
— Adiii '31
すごい！私のt2.smallインスタンスで作業しました。ふew。それはそれよりも血に富むだろうと思った。ありがとう！
— publicknowledge
growpartを含むcloud-guest-utilsをインストールできないようです。Linuxバージョン3.16.0-4-amd64
— nettie
15

[解決済み]

これはそれがしなければならなかったものです

  1. インスタンスを停止します
  2. ボリュームからスナップショットを作成する
  3. サイズを増やしているスナップショットに基づいて新しいボリュームを作成します
  4. 現在のボリュームマウントポイント（つまり、/ dev / sda1）を確認して記憶します。
  5. 現在のボリュームを切り離す
  6. 最近作成したボリュームをインスタンスに接続し、正確なマウントポイントを設定します
  7. インスタンスを再起動します
  8. SSH経由でインスタンスにアクセスして実行する fdisk /dev/xvde
  9. ヒットpして現在のパーティションを表示
  10. ヒットdして現在のパーティションを削除します（複数ある場合は、一度に1つ削除する必要があります）注：データが失われないことを心配しないでください
  11. ヒット nして新しいパーティションを作成します
  12. ヒットpしてプライマリとして設定
  13. ヒット1して最初のシリンダーを設定します
  14. 希望する新しいスペースを設定します（空の場合、スペース全体が予約されます）
  15. ヒットaして起動可能にする
  16. ヒット1とw書き込み変化へ
  17. インスタンスを再起動
  18. SSH経由でログインして実行 resize2fs /dev/xvde1
  19. 最後に、実行中の新しいスペースを確認します df -h

これだよ

幸運を！

— ウィルマンアランビレーテ
ソース
1
Amazon EBSボリュームでは、fdiskで使用するのと同じサイズのマウントポイントをresize2fsで使用することが重要なようです。dfは/ dev / xvda1のようなものを接続されたEBSボリュームとして表示しますが、resize2fsコマンドは、fdiskで新しいパーティションを作成したときに使用した/ dev / sdf1識別子を使用した場合にのみ機能しました。
— Garreth McDaid、2014
これはAWSのドキュメントにあります。何が悪いのかというと、彼らの手順は、この3年間続けてもまだ不完全です。画像がある場合は、フォールバックできます。デスクトップを実行しているインスタンスから新しいディスクを一時的に停止することは常に可能ですが、gpartedの使用を考えていた場合、サイズ変更のためにマウントする必要があることは問題になる可能性があります。gcloudはその場でサイズを変更します。
— mckenzm
私のストレージデバイス（/ dev / xvda1）は、セクター1ではなくセクター16065から始まりました。したがって、私の場合、ステップ13（最初のシリンダーを設定するために1を押す）は16065でした。
— Simon Paarlberg、2017年
これらのソリューションを使用しないでください。データが失われる可能性があります。実際、私は、パーティションテーブルにパーティションリストの値を表示する場合、パーティションの削除オプションを選択しないと考えました。リストがそこにあると、文字通りパーティションが削除されるため、「それはできない削除」。パーティションサイズを拡張する方法があります。下部で、パーティションサイズをスムーズに拡張するのに役立つ他のユーティリティがあることを確認してください。
— piyushmandovra 2017年
6

  1. AWSウェブコンソールにログイン-> EBS->サイズを変更したいものを右クリック->「ボリュームの変更」->「サイズ」フィールドを変更し、[変更]ボタンをクリック

  2. growpart /dev/xvda 1

  3. resize2fs /dev/xvda1

これは、Dmitry Shevkoplyasの回答の簡単なバージョンです。AWSのドキュメントにはgrowpartコマンドは示されていません。これは、ubuntu AMIでは問題なく動作します。

— jperelli
ソース
6
  1. sudo growpart / dev / xvda 1
  2. sudo resize2fs / dev / xvda1

上記の2つのコマンドにより、AWS ubuntu ec2インスタンスの時間を節約できました。

— HD298
ソース
4

GCP google cloud platformを利用し
ている方がいらっしゃる場合に備えて、こちらをお試しください。

sudo growpart /dev/sdb 1
sudo resize2fs /dev/sdb1
— ユヌス
ソース
2

このボリュームにパーティションを作成しましたか？その場合は、最初にパーティションを拡張する必要があります。

— シャンテマン
ソース
いいえ、しませんでした。どうすればよいですか？アタッチしたこの新しいボリュームは、元のボリュームのスナップショットであるため、以前のすべてのデータが含まれていることに
— 注意してください
いいえ。ただし、パーティションが接続されていると、エラーが発生します。移動して、ボリュームが正しいサイズになっていることを再確認し、新しいボリュームをマウントしたことを再確認します。
— chantheman
また、これを行うためにインスタンスを停止する必要はありません。そのボリュームに書き込みがある場合でも安全ですが、インスタンスを実行した状態でスナップショットを作成できます。
— chantheman
1

ブータブルフラグ（a）が私の場合（EC2、centos6.5）で機能しなかったため、スナップショットからボリュームを再作成する必要がありました。起動可能なフラグを除くすべての手順を繰り返した後-すべてが問題なく動作したため、後でresize2fsを実行できました。ありがとうございました！

— サンダー
ソース
1

@Dimitryに感謝します。これは、ファイルシステムに合わせて少し変更を加えただけで魅力的に機能しました。

ソース：http : //docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-expand-volume.html#recognize-expanded-volume-linux

次に、次のコマンドを使用して、ファイルシステムのマウントポイントを置き換えます（XFSファイルシステムをマウントして、サイズを変更する必要があります）。

[ec2-user ~]$ sudo xfs_growfs -d /mnt
meta-data=/dev/xvdf              isize=256    agcount=4, agsize=65536 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=262144, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 262144 to 26214400

注xfsctlの失敗を受け取った場合：メモリを割り当てることができませんというエラーは、インスタンスのLinuxカーネルを更新する必要がある場合があります。詳細については、特定のオペレーティングシステムのドキュメントを参照してください。を受け取った場合、ファイルシステムはすでにnnnnnnnブロック長です。何もする必要はありません！エラー、Linuxパーティションの拡張を参照してください。

— user2125117
ソース
0

上記のコメントをするのに十分な担当者がいません。ただし、上記のコメントに従って、1から開始するとインスタンスが破損する可能性があることに注意してください。fdiskを開始した後、 'p'でパーティションをリストする前に 'u'を押すと、ボリュームが破損しないように、正しい開始番号が与えられます。centos 6.5 AMIの場合も、上記のように2048が適切でした。

— リース
ソース
0

したがって、ケースでは誰もが100％使用してこの問題に遭遇し、growpartコマンドを実行するスペースさえないという問題がありました（/ tmpにファイルを作成するため）

これは、EBSボリュームが使用されている間、およびec2にスペースが残っておらず、100％に達している場合でもバイパスすることがわかったコマンドです

/sbin/parted ---pretend-input-tty /dev/xvda resizepart 1 yes 100%

こちらのサイトをご覧ください：

https://www.elastic.co/blog/autoresize-ebs-root-volume-on-aws-amis

— CodeJunkie
ソース
このコマンドの後sudo resize2fs /dev/xvda1にupdateを実行する必要があります。その後、ディスク容量の増加が表示されます/etc/fstabdf -h
— karmendra
0

名前と番号の間にスペースを入れます。例：

sudo growpart /dev/xvda 1

デバイス名とパーティション番号の間にスペースがあることに注意してください。

各ボリュームのパーティションを拡張するには、次のgrowpartコマンドを使用します。デバイス名とパーティション番号の間にスペースがあることに注意してください。

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html

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