72

Canonicalの最近のUbuntuAMIを実行しているサーバーがあります。EBSブートボリュームのサイズは8GBです。スナップショットを取り、新しいボリュームを作成し、その上のパーティションを拡張することで、EBSボリュームのサイズを変更できることを知っています。マシンの実行中にボリュームのサイズを増やすにはどうすればよいですか？これが不可能な場合、最小限のダウンタイムでブートボリュームサイズを増やすための推奨される方法は何ですか？

4

7 に答える 7

73

新しいEBSFeatureElasticボリュームを使用してボリュームサイズを増やすことができます。ここに示すように、サイズを増やすには、次の手順に従う必要があります。

ボリュームが16Gで、32GBに増やしたと仮定します。

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

xvda1を16GBから32GBに拡張するには、growpartが必要です。growpartはcloudutilsの一部として利用可能です 

sudo apt install cloud-utils

cloud-utilsのインストール後、growpartコマンドを実行します

sudo growpart /dev/xvda 1

今lsblk、表示されます

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

ただし、df-hには16GBしか表示されません

xvda1を32GBに拡張するための最後のコマンドは

sudo resize2fs /dev/xvda1

XFSファイルシステムの場合、

sudo xfs_growfs /dev/xvda1 ありがとう卵

于 2017-04-06T10:02:54.617 に答える
39

残念ながら、 AmazonEC2インスタンスの実行中にAmazonEBSルートデバイスのストレージボリュームのサイズを増やすことはできません-EricHammondは、ルートディスクのサイズ変更に関する詳細な（「正規の」と言いがちです;）記事を書いています。実行中のEBSブートEC2インスタンス：

EC2インスタンスで少しのダウンタイム（数分）で問題がない限り、新しいインスタンスを開始しなくても、ルートEBSボリュームをより大きなコピーに変更することができます。

彼が説明する手順を適切に準備すれば（最初に使い捨てのEC2インスタンスでテストして手順を理解することを強くお勧めします）、実際には数分のダウンタイムでプロセスを完了できるはずです。

幸運を！

于 2012-03-07T15:50:13.143 に答える
22

この5歳の質問に対する遅い答え

AWSは、Elastic Volumesと呼ばれる新しいEBS機能を発表しました。これにより、ボリュームの使用中にボリュームサイズを増やしたり、パフォーマンスを調整したり、ボリュームタイプを変更したりできます。

詳細については、AWSブログのこちらをご覧ください。

于 2017-02-19T19:06:01.980 に答える
8

最初にスナップショットを作成する必要があり、そのスナップショットから別のボリュームを作成し、新しいボリュームの準備ができたら、インスタンスから古いボリュームを切り離して、新しいボリュームを接続する必要があります。このプロセスを開始する前にインスタンスを停止し、完了したらインスタンスを再起動してください。

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-expand-volume.htmlを参照してください

于 2014-04-30T18:52:57.880 に答える
-1

これは、xfsファイルシステムで機能します。このコマンドを実行するだけです。xfs_growfs /

于 2013-02-04T07:59:58.190 に答える
-1

centos6で/dev/xvda1として報告されていたルートパーティション/dev/ sda1を増やしようとすると、パーティションを拡張するためにボリュームをアンマウントできなかったことがわかりました。

これを回避するには、元のボリュームを/ dev / sda1としてマウントし、スナップショットを/ dev/sdbとしてマウントします。次に、イメージを再起動し、partedを使用して/ dev/sdb1パーティションのサイズを変更しました。

パーティション/dev/ sdb1のサイズが変更されたら、両方のボリュームをデタッチし、新しいボリュームを/ dev / sda1に再接続して、resize2fs / dev/xvda1を実行しました。

于 2015-09-07T21:04:39.320 に答える
-2

これはできません。ただし、ダウンタイムよりもコストに重点を置いている場合は、メインインスタンスのクローンを作成し、より大きなEBSストレージデバイスをシステムにマウントし、データをコピーしてから、トラフィックを新しいインスタンスにリダイレクトできる可能性があります。

必要に応じて、私が最近使用しているS3の方法には、バックアップと他のシステムへの展開の媒体があります。たとえば、既存のシステムを実行しているとします。N分/時間/日ごとにデータをs3にアップロードするスクリプトを設定します。次に、新しいインスタンスを起動してそのデータをダウンロードするときに使用するスクリプトを記述します。データが常に更新されているようなものでない場合、これは正常に機能するはずです（私にとっては、データ自体がec2データベースサーバーで管理されている間に、コードベースの更新バージョンを配布するためにこれを使用します）。

お役に立てば幸いです。

于 2012-03-08T17:22:39.500 に答える