EC2はサイズを増やした後にボリュームのサイズを変更できません
EC2ボリュームのサイズを変更する手順を実行しました
- インスタンスを停止しました
- 現在のボリュームのスナップショットを取得しました
- 以前のスナップショットから、同じリージョンでより大きなサイズの新しいボリュームを作成しました
- インスタンスから古いボリュームを切り離しました
- 新しいボリュームを同じマウントポイントのインスタンスにアタッチしました
古いボリュームは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をumountし、代わりにxvdeをマウントできますか？
私が間違っていることを理解できない
Sudo ifs_growfs /dev/xvde1も試しました
xfs_growfs: /dev/xvde1 is not a mounted XFS filesystem
ところで、これはCentOS 6.2 x86_64のLinuxボックスです
ご協力ありがとうございます
コマンドが正しく機能したウィルマンに感謝します。EBSをより大きなサイズに増やす場合は、小さな改善を考慮する必要があります。
- インスタンスを停止します
- ボリュームからスナップショットを作成する
- スナップショットに基づいて新しいボリュームを作成し、サイズを増やします
- 現在のボリュームマウントポイント（つまり、
/dev/sda1） - 現在のボリュームを切り離す
- 最近作成したボリュームをインスタンスに接続し、正確なマウントポイントを設定します
- インスタンスを再起動します
インスタンスにSSH経由でアクセスし、
fdisk /dev/xvde警告：DOS互換モードは非推奨です。モード（コマンド 'c'）をオフにし、表示単位をセクター（コマンド 'u'）に変更することを強くお勧めします
ヒット p 現在のパーティションを表示する
- ヒット d 現在のパーティションを削除するには（複数ある場合、一度に1つずつ削除する必要があります）注：データが失われないことを心配しないでください
- ヒット n 新しいパーティションを作成するには
- ヒット p プライマリとして設定する
- ヒット 1 最初のシリンダーを設定する
- 目的の新しいスペースを設定します（空の場合、スペース全体が予約されます）
- ヒット a 起動可能にする
- ヒット 1 そして w 変更を書き込む
- インスタンスを再起動OR
partprobeパッケージのpartedを使用して、新しいパーティションテーブルについてカーネルに通知します。 - SSH経由でログインし、resize2fs/dev/xvde1を実行します
- 最後に、df -hを実行している新しいスペースを確認します
インスタンスを停止し、EBSボリュームをデタッチしてサイズを変更する必要はもうありません！
2017年2月13日Amazonの発表： " Amazon EBSアップデート-新しいElastic Volumeはすべてを変更 "
このプロセスは、拡張するボリュームが実行中のインスタンスのルートボリュームであっても機能します！
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は8 GiB 16のパーティション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を使用することを提案します。これは、特にブートドライブを変更する場合、厄介でリスクがあり、エラーが発生しやすいプロセスです。
# 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% /
したがって、ダウンタイムはゼロで、使用する新しいスペースがたくさんあります。
楽しい！
上記のjperelliによる完全なコメント。
今日も同じ問題に直面しました。 AWSドキュメントでは、growpartについて明確に言及していません。私は難しい方法を見つけました、そして実際に2つのコマンドはUbuntuでM4.largeとM4.xlargeで完全に機能しました
Sudo growpart /dev/xvda 1
Sudo resize2fs /dev/xvda1
[解決済み]
これがやらなければならなかったことです
- インスタンスを停止します
- ボリュームからスナップショットを作成する
- スナップショットに基づいて新しいボリュームを作成し、サイズを増やします
- 現在のボリュームマウントポイント（つまり/ dev/sda1）を確認して記憶します
- 現在のボリュームを切り離す
- 最近作成したボリュームをインスタンスにアタッチし、正確なマウントポイントを設定します
- インスタンスを再起動します
- SSHを介してインスタンスにアクセスし、
fdisk /dev/xvdeを実行します - ヒット p 現在のパーティションを表示する
- ヒット d 現在のパーティションを削除するには（複数ある場合は、一度に1つずつ削除する必要があります）注：データが失われないことを心配しないでください
- ヒット n 新しいパーティションを作成するには
- ヒット p プライマリとして設定する
- ヒット 1 最初のシリンダーを設定する
- 目的の新しいスペースを設定します（空の場合、スペース全体が予約されます）
- ヒット a 起動可能にする
- ヒット 1 そして w 変更を書き込む
- インスタンスを再起動
- SSH経由でログインし、
resize2fs /dev/xvde1を実行します - 最後に、
df -hを実行している新しいスペースを確認します
これです
幸運を！
aWSウェブコンソールにログイン-> EBS->サイズを変更したいものを右クリック->「ボリュームを変更」->「サイズ」フィールドを変更して[変更]ボタンをクリック
growpart /dev/xvda 1resize2fs /dev/xvda1
これは、Dmitry Shevkoplyasの答えの簡単なバージョンです。 AWSのドキュメントには、growpartコマンドが表示されていません。これは、ubuntu AMIでは問題なく機能します。
- Sudo growpart/dev/xvda 1
- Sudo resize2fs/dev/xvda1
上記の2つのコマンドにより、AWS ubuntu ec2インスタンスの時間を節約できました。
このボリュームにパーティションを作成しましたか？その場合、最初にパーティションを拡張する必要があります。
これは、このコマンドを実行するだけでxfsファイルシステムで機能します。
xfs_growfs /
GCP googleクラウドプラットフォームをご利用の場合は、
これを試して：
Sudo growpart /dev/sdb 1
Sudo resize2fs /dev/sdb1
ブータブルフラグ（a）は私のケース（EC2、centos6.5）では機能しなかったため、スナップショットからボリュームを再作成する必要がありました。ブータブルフラグを除くすべての手順を繰り返した後、すべてが問題なく機能したため、その後に2fsのサイズを変更できました。ありがとうございました！
上記のコメントに十分な担当者がいない。ただし、上記のコメントごとに、1から開始するとインスタンスが破損する可能性があることに注意してください。 fdiskの起動後にパーティションを 'p'でリストする前に 'u'を押すと、実際には正しい開始番号が与えられるため、ボリュームが破損することはありません。 centos 6.5 AMIについても、上記のように2048が正しかった。
そのため、Caseでは、誰でも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
おかげで、@ Dimitry、それは私のファイルシステムに合わせて小さな変更を加えたチャームのように機能しました。
次に、次のコマンドを使用して、ファイルシステムのマウントポイントを置き換えます（サイズを変更するには、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 failed：メモリを割り当てることができないというエラーを受け取った場合、インスタンスのLinuxカーネルを更新する必要がある場合があります。詳細については、特定のオペレーティングシステムのドキュメントを参照してください。受信した場合、ファイルシステムはすでにnnnnnnnブロック長です。何もする必要はありません！エラー。Linuxパーティションの拡張を参照してください。